Dropped DMAs, split DMAs

[flamewing]

One issue with the DMA queue (which it shares with the original queues) is that it silently drops off DMAs if the queue is full. This leads to graphical corruptions due to misaligned art and sprite/plane maps.

Maybe I should add an option to generate hard errors (say, through a trap instruction) instead of dropping a DMA or DMA piece. This could be used in debug mode by hackers to see if they need to increase the size of the queue.

Something similar applies to split DMAs: there should be a flag for generating a hard-error when the need for splitting one DMA arises. This would allow hackers to easily find these cases, and align the problematic art appropriately.

[vladikcomper]

When designing a similar system for my homebrew, I was also thinking of hard-flushing the queue when buffer overflow is about to occur.
This basically means executing all the queued transfers in-place (optionally, waiting for start of new VBlank before flushing), then accepting the new transfer request in now-empty buffer.

While this, as well, may lead to severe side effects like graphics corruption (due to sprites and/or scrollplanes not being updated before new graphics are transferred), if pulled off carefully, these any unwanted effects will be only limited to one 1 TV-frame as opposed to (potentially) longer-lasting glitches when some requests are just being dropped silently.

Of course, buffer overflows should be avoided at all costs, so it only makes sense to handle them as errors in development builds.
In the release builds, however, when cannot be avoided, hard-flushing the buffer may seem like a better strategy than dropping transfers upon overflows (as the latter may potentially cause longer-lasting side effects).

P.S.: I haven't implemented the said flushing logic in my own project yet, but I most likely will. But I have a good reason to do so, because my system is not limited to DMA. In fact, it's a general-purpose "draw commands buffer", which stores pretty much everything the game may want to update in VRAM during VBlank (including tile transfers, drawing on scrollplanes, etc.), so in my case it's important that everything in this buffer is transferred correctly and nothing is dropped. It may not be as critical when the transfer system is limited to DPLCs exclusively.

[flamewing]

Hm. Having the hard flush as an option is definitely a good idea. I'll add it to my todo list.