With that in mind, I'm going to have to write some test code to answer questions about some specific behaviour from the blitter, unless some kind soul here already knows the answer (and can save me the precious time of writing a test program by explaining whatever it is I have overlooked or maybe confirming my assumptions below).
Anyway, I'm currently looking into whether the blitter suffers the same penalty as the 68000 CPU for writes (or in this case blits) to odd addresses.
I have to re-write my code, as I may have overlooked something, but from using my visualisation routines, it seems that if I offset a write to palette index 0 by one byte i.e. to start at $ff8241, or I don't; either way, I get White (colour value 1911/%0111 0111 0111) which is the first colour sent to the palette:
- Evenpalblit1.jpg (14.39 KiB) Viewed 3538 times
- Oddpalblit1.jpg (7.46 KiB) Viewed 3538 times
However, if the colour data is offset by a byte and the shifter can only accept a full word, so will 'double up' the byte, shouldn't I be seeing magenta (red+blue) on index 0 as with the offset only the (what were the red) bottom 3 bits from the top byte are now residing in the bottom byte of the palette word with them being repeated in the top byte too? (All blits in the pictures are to background/palette 0, with just the first needed for the example).
Seems that possibly the MMU is even aligning the blit..? (Better than a bus error I guess).
