DMA fills with auto-increment result in stray byte at the start

[Matt Grum]

To perform a DMA fill you need to set up the VDP registers appropriately first, then perform a word write to the VDP data port containing the value you want to fill with. The problem is that this write to the data port is treated as a regular VDP data write of 16-bits (not eight) which messes up the alignment.

For example, if you want to write the value 0xFF and have a gap of one byte between each write (auto-increment is set to 2) then what you actually get is:

FF FF 00 FF 00 FF 00 FF 00 FF etc.

This means you have to subtract one byte from the destination address, then go back and fix the stray 0xFF afterwards. Is there a way to avoid this behaviour (i.e. make the write to the data port not be treated as a normal write)?

[Matt Grum]

After reading all the DMA fill posts I can find here it appears the answer is no, you're always going to have to go back and fix the start after performing a DMA fill with increment greater than 1.

[Mask of Destiny]

After reading all the DMA fill posts I can find here it appears the answer is no, you're always going to have to go back and fix the start after performing a DMA fill with increment greater than 1.

I think the one exception might be in 128KB mode. When that's enabled, one byte of the initial write will be sent to the non-existent (except on the Teradrive) second VRAM chip. I believe the actual fill operation is also 16-bit wide in 128KB mode, but one byte of the word is discarded on most hardware. The one fly in the ointment with this is that the mapping between logical VRAM addresses and physical row/column VRAM addresses is a bit different between 64K mode and 128K mode, but if you can work around that then it might do what you want