flamewing/ultra-dma-queue

Super fast DMA queue for the Sega Genesis

ultra-dma-queue's Issues

Dropped DMAs, split DMAs

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.

topic addition for better community reach

Hey,
for better reach of the community, I would like to suggest to add the following topic to the repository: motorola-68000

How to do this

Sonic3_Complete Queue

The DMA queue from the S&K disassembly has been improved by @Clownacy; as a result, it is a lot better than it was before. This causes the README.md file to present incorrect cycle counts and analysis of the function.

I need to cycle-count the new function and reanalyze the results.

A tiny speed&size optimization suggestion

I was reading through your source code, and the optimizations and tricks you used are beyond impressive.

However, this particular line in InitDMAQueue caught my attention:

ultra-dma-queue/DMA-Queue.asm

Line 373 in 176b3c1

move.b #$94,d0

Since it's used to fill in bytes in the loop below, as you know, this can be obviously optimized into:

	moveq	#$FFFFFF94,d0

Which saves 1 bus cycle and 2 bytes.

I know, this code is nothing critical and it's run only once, but seeing how tight your other optimizations are, I thought you might want to consider this one as well (because you actually unrolled the loop inside InitDMAQueue after all, even though wasting cycles here won't make any noticeable difference, since this is non-heavy initialization code, which is run once in a game's lifetime).

On the other hand, the optimization in question may slightly worsen the code readability. If this is the exact reason it wan't made, please ignore my suggestion.