StreetFighter2 sprite corruption: memory timing problem?

[prophet36]

I kinda lost enthusiasm for my USB Megadrive DevKit because so few people are interested in such things these days. But the other day several people found it and were really enthusiastic about it so yesterday I dusted off the hardware, got the software from GitHub and got it running again, with a view to laying it out on a custom cartridge PCB (i.e a single custom PCB incorporating FPGA, SDRAM, USB interface & SD-card slot rather than a bridge to a Nexys2).

So here's one great thing about collaboration rather than working alone: other people think of things that you don't. I had always naively assumed that all accesses to cartridge memory would look as described in the 68000 datasheet, and therefore (ignoring bank-switch issues) if one game works, all of them will work.

Uh-oh. Not so. Apparently the Megadrive does DMA accesses to the cartridge address space, and probably with tighter memory timing requirements. I read somewhere that Street Fighter 2 does a lot of DMA from cart memory, so I tried it on my UMDKv2 prototype, and this is the result:



Can anyone who knows Megadrive programming decipher what's going on here? It only happens on stuff which animates, not static backgrounds. The game basically works and is playable, but with this corruption of the sprite data. It doesn't look like random corruption though, it looks more like an off-by-one error in the sprite data addressing or something. TBH I don't know enough about the Megadrive internals to comment so I'm just guessing.

At least now I can set up some test logic in the FPGA to observe what's going on and hopefully solve the problem, but I thought I'd post it here just in case anyone has any hints.

[Chilly Willy]

Yes, you can DMA from the rom, and yes, the DMA cycle is MUCH faster than a 68000 cycle. If you are doing 68000-only cycle timing on the rom, you're so slow that the data you're presenting to the DMA is about a cycle behind the data it SHOULD be getting. Some old games realized that the DMA was too fast for the speed rom they were going to use, so they copy the data to ram with the 68000, and then DMA from ram.

[prophet36]

Do you know how much shorter the DMA cycles are? In other words, what's the minimum length of C_OE asserts and the minimum spacing between asserts? And how is the 68000 held off during DMA? And are the address lines still guaranteed valid at the falling edge of C_OE as they are with the 68000?

[Chilly Willy]

You'd probably need someone like Charles to answer to that detail.