SpritesMind.Net

Posted: **Mon Jul 27, 2015 8:55 pm**

Hi!

I'm at my wits end here. I'm slowly updating my framework to use DMA for all VDP transfers, and I've been trying to figure out why I can't do a DMA from ROM to CRAM. It works fine with an intermediary buffer in work RAM.

I'm following these instructions from Sega2f.doc:

Source address are $000000-$3FFFFF(ROM) and $FFOOOO--$FFFFFF(RAM)
for memory to VRAM transfers. In the case of ROM to VRAM transfers,
a hardware feature causes occasional failure of DMA unless the
following two conditions are observed:

--The destination address write (to address $C00004) must be a word
write.
--The final write must use the work RAM.
There are two ways to accomplish this, by copying the DMA program
into RAM or by doing a final "move.w ram address $C00004"

so to ensure these conditions are met, the final address write is split into two word-size moves, and the values come from the stack:

Code: Select all

	move.l  d0, -(sp)
	move.w  (sp)+, vdp_control
	move.w  (sp)+, vdp_control

Again, this is all fine if the source address is in work RAM, but from ROM I end up with a garbage palette.

I've verified the source address is word aligned.

Posted: **Mon Jul 27, 2015 10:20 pm**

Oh so it might have with the ROM speed then ! When you do ROM --> CRAM DMA the DMA is going 2x faster than ROM --> VRAM DMA (because CRAM bus is 16 bits wide) so it seems your ROM is just not fast enough for the CRAM DMA.

Posted: **Tue Jul 28, 2015 12:13 am**

That's really only true after the FIFO fills up though. First four words should be at the same speed regardless of target so if you're ROM is too slow you should be seeing at least a little corruption with VRAM transfers too.

Posted: **Tue Jul 28, 2015 1:14 am**

The source data in ROM can't cross a 128K boundary too, so maybe confirm the data is within a 128K block.

E.g. if the palette data starts at $05FFF0, the DMA will wrap to $040000 past $05FFFF instead of continuing from $060000 like you think it should.

Posted: **Tue Jul 28, 2015 7:47 am**

This is with a Cross Products MegaCD devkit, I have no idea what kind of "ROM" it's being read from (it's got a few banks of EEPROMs inside, I think).

I've checked the 128k boundary, and moved the palette to just underneath the CPU vector table just in case, but same result.

I'll try throwing some tiles at VRAM to see if I get a corrupt result. I could also try building for emulation and run it through Exodus. Does it do any speed throttling for ROM reads?

Posted: **Tue Jul 28, 2015 8:26 am**

Mask of Destiny wrote:That's really only true after the FIFO fills up though. First four words should be at the same speed regardless of target so if you're ROM is too slow you should be seeing at least a little corruption with VRAM transfers too.

True, i wonder how first game developers handle that... It seems that first used roms where too slow to handle CRAM DMA, but indeed the first words are transfered at full speed even for VRAM DMA so i guess developers had to think about this issue and somehow starts DMA some words ahead and waste a bit of space in VRAM.

Posted: **Tue Jul 28, 2015 9:35 am**

Is there difference in CAS0/CAS2/CE0 signals timings on slot when it comes from M68K or VDP? Any real measurements?

Posted: **Tue Jul 28, 2015 4:15 pm**

I have a logic analyzer capture of DMA around somewhere. From what I remember, one of the enable signals (maybe !OE?) is held low for the entire request. Each access takes a signal slot (generally 16 master clock ticks in H40, with some variation due to the behavior of EDCLK during HSYNC) whereas an access by the 68K takes 28 master clock ticks. I'll try to dig up the actual capture when I get home.

Posted: **Tue Jul 28, 2015 6:58 pm**

Same story with VRAM:

Posted: **Tue Jul 28, 2015 7:05 pm**

All fine in Exodus. I suspect you're correct, the not-quite-ROM inside my kit is too slow

Posted: **Tue Jul 28, 2015 7:13 pm**

Hey I thought you said you weren't an artist.

What is this you're working on out of curiousity?

Posted: **Tue Jul 28, 2015 7:32 pm**

Count SymphoniC wrote:Hey I thought you said you weren't an artist.

What is this you're working on out of curiousity?

I found one! Two, actually.

Full steam ahead on an original title, a Flashback/Limbo/Abe's Oddysee style platformer. Prototype coming in December.

Posted: **Wed Jul 29, 2015 1:38 am**

Flashback is a childhood classic for me. Were you guys going to attempt the fluid animation style that Flashback had?

Sounds like a cool project.

Posted: **Wed Jul 29, 2015 8:11 am**

Count SymphoniC wrote:Were you guys going to attempt the fluid animation style that Flashback had?

I should hope so. Priority is fast and easy traversal of terrain, needs to be snappy and responsive when trying to jump for ledges, etc. It'll look weird without the smooth anims to go with it. I'm hoping for a lot of chase scenes and memory reliant routes like the final levels of Paramonia and Scrabania in Abe's Oddysee.

Posted: **Wed Jul 29, 2015 5:07 pm**

that's sound promising !
and what's is the target console ?

SpritesMind.Net

DMA from ROM to CRAM, results are garbage

DMA from ROM to CRAM, results are garbage

Re: DMA from ROM to CRAM, results are garbage