Bug in genesis.c?

[furrykef]

I'm converting dma_vram_copy from genesis.c into ASM and I think I found a bug in it, at least the version I have. (I got it from one of his examples, so maybe he's updated it since then...)

Code: Select all

void dma_vram_copy(uint source,ushort dest,ushort len)
{
    register volatile ushort *pw;
    register uint *pl;

    /* Halt the Z80 for DMA */
    pw = (ushort *) Z80_HALT;
    *pw = 0x100;

    /* Point to GFX register */
    pw = (ushort *) GFXCNTL;

    /* Setup DMA length */
    len >>= 1;
    *pw = 0x9300L + (len & 0xff);
    *pw = 0x9400L + ((len >> 8) & 0xff);

    /* Setup DMA address */
    source >>= 1;
    *pw = 0x9500L + (source & 0xff);

    source >>= 8;
    *pw = 0x9600L + (source & 0xff);

    source >>= 8;
    *pw = 0x9700L + (source & 0xff);

    /* Enable DMA */
    pl = (uint *) GFXCNTL;
    *pl = GFX_DMA_ADDR((uint) dest);

    /* Enable Z80 */
    pw = (ushort *) Z80_HALT;
    *pw = 0;
}

The suspected error is in this part:

Code: Select all

    pl = (uint *) GFXCNTL;
    *pl = GFX_DMA_ADDR((uint) dest);

The problem is that we don't know where the result of GFX_DMA_ADDR is stored. I bet it'd be stored in a register, in which case it basically compiles to "move.l d0, GFXCNTL", which violates the rule that the instruction that activates the DMA transfer must use RAM, so it'd probably crash on the actual hardware. You need to do something like push it on the stack and move it form there into GFXCNTL, right?

I haven't tested to see how this code actually compiles, but I think it's irrelevant anyway; it's still an error in the code even though it may compile into the correct operation. I think the only way to be absolutely sure that the operation uses memory would be to use inline ASM.

- Kef

[TmEE co.(TM)]

You need to have code in RAM only if you're DMAing from outside the ROM area (i.e from MD RAM to VRAM).

[HardWareMan]

I use this method:

Code: Select all

        move.w   #$9320,(a6)            ;Lower byte of size => #19
        move.w   #$940D,(a6)            ;Upper byte of size => #20
        move.w   #$9500,(a6)            ;Lower byte of origin => #21
        move.w   #$96C0,(a6)            ;Middle byte of origin => #22
        move.w   #$977F,(a6)            ;Upper byte of origin => #23
        move.l   #$40200080,(a6)        ;Write to VRAM at offset 0x0000 

It is works on hardware.

[furrykef]

You need to have code in RAM only if you're DMAing from outside the ROM area (i.e from MD RAM to VRAM).

But that's not what the official documentation says:

Source address are $000000-$3FFFFF(ROM) and $FF0000--$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.

Whichever way is correct, there's still a bug because the function doesn't know whether the source address is in RAM or not -- not the way it's written, anyway.

move.l #$40200080,(a6) ;Write to VRAM at offset 0x0000

Shouldn't that write to 0x0200? Or am I confused?

- Kef

[TmEE co.(TM)]

hmmm.... I have not had any issues with DMA, except when I discovered that DMA doesn't cross 128KB blocks... I do extensive testing on real HW and I've not had a single problem with any of my programs.

[furrykef]

And you've tested it on all variations of the hardware? Just checkin'.

[HardWareMan]

move.l #$40200080,(a6) ;Write to VRAM at offset 0x0000

Shouldn't that write to 0x0200? Or am I confused?

You are right. That is old comment, so it is not correct.

[furrykef]

Sounds like you should revise your code. After all, bad comments are worse than no comments.

- Kef

[HardWareMan]

Sounds like you should revise your code. After all, bad comments are worse than no comments.
- Kef

Not all code. This example is copy-pasted from one project and comment was rewritten. I guess I just missed this number.

[TmEE co.(TM)]

And you've tested it on all variations of the hardware? Just checkin'.

It works on MD2 VA1, MD1 VA4, MD1 VA6, Nomad, Xeye(basically same as MD2 VA1) and Wondermega... no trouble so far...

[furrykef]

So are the docs completely wrong, or are there cases where you do indeed need to access RAM in the instruction where you activate DMA?

[TmEE co.(TM)]

Nobody can say they're wrong... there's over 10 other models of MDs around that I don't have... I've never had any problems with what I've got when doing ROM to VRAM transfers. I guess when I'm doing more serious work on my game, I might run into some quirks... I'm more specialized in MD sound part...

[notaz]

Many commercial games start ROM->VRAM (and even RAM->VRAM) DMAs while running from ROM, so there is nothing to worry about.

[furrykef]

According to the manual, the instruction doesn't have to run from RAM (although that is one way to do it), it just has to use RAM. So do those games do something like this?

Code: Select all

    move.l d0, -(a7)
    move.l (a7), GFXCTNL
    move.l (a7)+, d0

Or do they just do this?

Code: Select all

    move.l d0, GFXCTNL

[Stef]

I wrote the code in this way because i tested it on hardware and i never met any problems with it. I don't say it will never happen, i do know the officials documents said we must write the last command from RAM but if i can avoid all the "obscure tricks" to make things work then i avoid them. Maybe i'll need to fix that later but for now it works so it's ok for me. Same is true for the IO read functions : officials documents said you have to disable Z80 but i never needed it so i never do it