Someone once asked me about the DMA manager I wrote for my Genesis kernel, so I figured I'd just post some sections here: ; ; kStartDMA: ; ; Start the queued DMA transfers to the Video Display Processor's VRAM. ; ; Parameters: ; None ; ; Returns: ; None ; kStartDMA: lea VDP,a6 lea kern_DMATable(a5),a0 ; get the start of the queue move kern_DMAQueue(a5),d0 ; get the number of requests beq.s kInitDMA subq #1,d0 .dmaLoop: move.l (a0)+,VCTRL(a6) ; set the VDP DMA registers move.l (a0)+,VCTRL(a6) move (a0)+,VCTRL(a6) move.l (a0)+,VCTRL(a6) dbra d0,.dmaLoop ; ; kInitDMA: ; ; Initialize the queue to perform a DMA transfer to the Video Display ; Processor's VRAM. ; ; Parameters: ; None ; ; Returns: ; None ; kInitDMA: lea kern_DMATable(a5),a0 ; get the start of the queue move.l a0,kern_DMACurrent(a5) ; reset the current pointer clr kern_DMAQueue(a5) ; clear the queue rts ; ; kQueueDMA: ; ; Insert into the queue a request to perform a DMA transfer to the Video ; Display Processor's VRAM. ; ; Parameters: ; d0 -> Source address ; d1 -> VDP VRAM location ; d2 = Size of the transfer in WORDs ; d3 = VRAM memory bank ; ; Returns: ; None ; kQueueDMA: move.l d4,a1 addq #1,kern_DMAQueue(a5) ; increment the queue move.l kern_DMACurrent(a5),a0 move.l #$94009300,d4 ; DMA size move.b d2,d4 lsr #8,d2 swap d4 move.b d2,d4 move.l d4,(a0)+ ; set the DMA size registers lsr.l #1,d0 move.l #$96009500,d4 ; DMA source mid and low WORDs move.b d0,d4 lsr #8,d0 swap d4 move.b d0,d4 move.l d4,(a0)+ ; set the DMA source register move #$9700,d4 ; DMA source high WORD swap d0 move.b d0,d4 move d4,(a0)+ ; set the DMA source register move d1,d4 ; get VDP destination address and #$3fff,d4 or d3,d4 ; set the VRAM bank move d4,(a0)+ ; DMA VRAM location high bits rol #2,d1 ; compute dest register bits and #3,d1 or #$80,d1 move d1,(a0)+ ; DMA VRAM location low bits move.l a0,kern_DMACurrent(a5) ; save the new queue start move.l a1,d4 rts ; ; kWaitDMA: ; ; Wait for the DMA transfer to finish, so the application can then ; synchronize with the video memory. ; ; Parameters: ; None ; ; Returns: ; a6 -> VDP hardware address ; kWaitDMA: lea VDP,a6 ; init common address register .waitDMA: move VCTRL(a6),d0 ; get the status WORD and #VDPF_DMA,d0 ; check for DMA done bne.s .waitDMA rts
Nice, though I usually just use macros. Wrote a nice queue once, heh I wish I had more time to do Megadrive stuff
I know what you mean, I haven't done any programming on the Genesis since the 90's... I really did enjoy working on that platform. I'm working on a Atari 2600 project right now, but maybe after that looking at the 68K again. Hmm, wonder what would be a good project to do on the Genesis these days? :icon_bigg --Selgus
Not strictly Genesis, but e.g. I recently ported Sonic 1 to 32x (and even released the source), that was interesting. Mainly because 32x is such a hell to develop
Its such a pity the S1-32X is not too useful on real HW Some folks (me one of them ), are doing this http://www.piersolar.com it might give you ideas
That does look pretty cool there. Good luck with the project! I was thinking of some sort of 3D game, as I developed a whole bunch of raster scanline rendering routines for the Genesis that I only used once. --Selgus
Panorama Cotton like ? That game is software scaling and mad raster effects from top to bottom If you need sound and music, I have a sound system worked out (and its still in the making, but it can do most stuff you will ever need in a game)
I've used GEMS in the past, with a slightly modified z80 playback routine, though I don't have a Genesis any longer with the DB9 port. But before I did that, I would need to convert the debugger I wrote from my old par port hardware and routines, to something more modern, like USB. I don't think I would want to redesign Dave Ashley's card to support USB, so I would have find/make a USB->parallel port converter. Not sure I want to open that can of worms. --Selgus
I do my MD stuff mostly on PC using few emulators like Kega Fusion (the most accurate, but no debugging stuff...) and Gens Kmod (not so accurate, but awesome debugging stuff). I am working on PC + MD setup, things are going slow though. Small example (sound is not the only thing it could do) : http://www.youtube.com/watch?v=xh6i4JBXrpA Only thing needed is a LPT cable, something that you can use to run code on MD and soft on PC side. Once I'm done with it, I'll release the protocol specs and some demos, and possibly build some cables and carts and sell them.
Cool! Have you ported the disassembled code? I can't imagine how hard is that. What we can expect from future hacks? Better graphics and sounds? I can't wait to try this rom at home =)
I have in past fully disassembled several games (including Sonic 1) so that the output could be recompiled and worked 100%, but I used a more recent and fresh disassembly by a friend. It is indeed difficult and extremely time/energy-consuming, but you also learn a lot. In fact I'd recommend it to anyone who wants to learn some low-level programming. I programmed a sound driver in it that supports the 32x PWM (Pulse Width Modulation, very nice stereo PCM), which was quite hard considering the Herculean task of finding good 32x documentation.I started a sort-of 32x sprite engine with scaling and rotating and stuff, but my vacation ended and I never finished it. I might pick up on it in the summer, but don't take my word for it Like I said, I released the source to the thing and someone is even using it in a serious Sonic 1 hack. The 32x PWM is useful because normally, a whole FM channel (out of 6) is taken on the Genesis. Using the PWM frees that channel (which can be used for better music) and allows better sample rates. Plus it was much easier to add sample mixing to it, so in effect you have 4 8-bit PCM channels (which is quite an improvement over 1 channel I hear). Normally it is done using the Z80 and sucks. The only good game which does that is Ristar I think. And hardly any Genesis games do mixing at all. Personally I'm not interesting in making a content hack, or add graphics, or anything. It's just a proof of concept for me (32x is a bitch to work with, ask any 32x dev), and I'm happy people are using it. If you want to read more, see this topic (link). There's a readme.txt there which explains more and says things I forgot since making it, and of course the binaries and source. Have fun
Thanks. I will follow the other topic. You've done a great job. I hope to see more progress in summer ;-)
Oh yes, definitely. Once you get a good hang of the parallel CPUs (and the funny way SH2 works sometimes), it's nice and easy from there. While we're on the topic, do you have any idea why Sega forbid the use of TAS in 32x? Maybe Saturn too, I haven't checked. It's quite a nifty thing to have in a parallel environment, so I have to wonder why there was an explicit anathema on it. Speaking of TAS reminds me of all the fun of race conditions etc.
If I remember correctly, the early Genesis hardware didn't handle the write-back bus cycle on the TAS instruction. --Selgus
all MDs before MD3 did not perform TAS correctly... actually I have no idea what the result is, but on Genny3, games that use TAS will not work because TAS is "fixed" on those units.
