SpritesMind.Net

Is the following issue possible?

- use the DMA queue to sync a few kb
- the v-int callback does not wait for DMA
- thus the frame code can start *while the DMA is going*
- then, if there's early frame code that accesses the VDP, even with interrupts disabled, it can conflict and blow up

I believe I'm hitting this, but I'm not certain.

Yep, sticking VDP_waitDMACompletion() at the frame start seems to fix the corruption.

I guess you are doing some DMA fill operation then... nothing to do with the DMA queue which is used only for DMA transfer (ROM/RAM to VRAM) and retains BUS (and so the 68k) while it is operating.

No, just a normal ROM-to-VRAM copy. And the DMA queue is the only DMA I use, so how could that fix it?

edit: The corruption was visible in the couple tiles following the last DMA target. As if the DMA copy randomly wrote too much, or if it interrupted another VDP call, leaving the dest address there.

But, as mentioned, adding the wait at the frame start fixed it. Very curious.

ROM to VRAM copies lock the 68K out of the bus until they are done so waiting for DMA completion should have no effect.

Indeed, yet it has an effect. On multiple emulators, not yet tested on hw.

It must have something to do with the DMA due to which tiles get corrupted - ones right after the final DMA copy. How would you track this?

edit: Another idea. Is the following possible:

- the frame takes just slightly too long, and the last thing has ints disabled
- we enter VDP_waitVSync one line after the v-int would have fired
- thus the v-int does not fire that frame, the DMA queue is not flushed
- the next frame adds the new DMAs to the queue, going over the 7.2kb limit

That would explain the corruption, but not why the DMA wait fixes it.

Indeed, on some frames the DMA queue is not empty at the start. Trying to clear it now.

The DMA queue implementation has changed since the current guthub version, will try to push the changes soon. Hopefully it will have better handling of case where you are going over DMA bandwidth limit.

According to the code, it's not possible for the queue to have contents after waitVSync, yet that's what I repeatably saw. This is a very interesting bug.

Look like github already contains a recent version of dma.c file. In fact it all depends if you defined a maximum transfer size per frame (using DMA_setMaxTransferSize(..) method), in which case the DMA won't transfer more than the given size, but by default there is no limit indeed.

I did not set any limit.

So i don't see how the queue can have some entries after the vint callback :-/ Are you sure you don't retain interrupts disabled for too much time ??

They may be disabled long enough for the framerate to drop to 30fps temporarily. But they are always enabled before waitVSync.