DMA from ROM to CRAM, results are garbage

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

BigEvilCorporation
Very interested
Posts: 209
Joined: Sat Sep 08, 2012 10:41 am
Contact:

DMA from ROM to CRAM, results are garbage

Post by BigEvilCorporation » 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.
A blog of my Megadrive programming adventures: http://www.bigevilcorporation.co.uk

Stef
Very interested
Posts: 2987
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » 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.

Mask of Destiny
Very interested
Posts: 591
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » 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.

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Re: DMA from ROM to CRAM, results are garbage

Post by Charles MacDonald » 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.

BigEvilCorporation
Very interested
Posts: 209
Joined: Sat Sep 08, 2012 10:41 am
Contact:

Post by BigEvilCorporation » 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?
A blog of my Megadrive programming adventures: http://www.bigevilcorporation.co.uk

Stef
Very interested
Posts: 2987
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » 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.

HardWareMan
Very interested
Posts: 727
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » 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?

Mask of Destiny
Very interested
Posts: 591
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » 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.

BigEvilCorporation
Very interested
Posts: 209
Joined: Sat Sep 08, 2012 10:41 am
Contact:

Post by BigEvilCorporation » Tue Jul 28, 2015 6:58 pm

Same story with VRAM:

Image
A blog of my Megadrive programming adventures: http://www.bigevilcorporation.co.uk

BigEvilCorporation
Very interested
Posts: 209
Joined: Sat Sep 08, 2012 10:41 am
Contact:

Post by BigEvilCorporation » 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 :(
A blog of my Megadrive programming adventures: http://www.bigevilcorporation.co.uk

Count SymphoniC
Very interested
Posts: 149
Joined: Sat Nov 17, 2012 3:58 am

Post by Count SymphoniC » 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?

BigEvilCorporation
Very interested
Posts: 209
Joined: Sat Sep 08, 2012 10:41 am
Contact:

Post by BigEvilCorporation » 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.
A blog of my Megadrive programming adventures: http://www.bigevilcorporation.co.uk

Count SymphoniC
Very interested
Posts: 149
Joined: Sat Nov 17, 2012 3:58 am

Post by Count SymphoniC » 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.

BigEvilCorporation
Very interested
Posts: 209
Joined: Sat Sep 08, 2012 10:41 am
Contact:

Post by BigEvilCorporation » 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.
A blog of my Megadrive programming adventures: http://www.bigevilcorporation.co.uk

bastien
Very interested
Posts: 208
Joined: Mon Jun 25, 2007 7:19 pm
Location: Besançon,France
Contact:

Post by bastien » Wed Jul 29, 2015 5:07 pm

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

Post Reply