@Qube
Interesting competition
Both of your colour clash routines are correct, the clash was usually based on 'colour priority' of the sprite (in the attribute table) which would be programmer coded.
One space would be 8 pixels due to the size of the char graphics. So, if you wanted to animate the movement by pixel (which was possible but very tricky) you had to use a bit operation of that byte to move the pixels left or right within each of the 8 lines of that char graphic.
This was the same for the Speccy.
If you wanted to animate it going up and down then you'd had to look at the next or prev line of that char graphic and poke that number into the previous location. Then, every 8th time you did this you would just reset it back to the original image and move the block.
If only that were the case for the Speccy too, but it soooo wasn't that easy
The screen pixel and colour (attribute) data was made up of 6912 bytes of data starting at address 16384.
The pixel data was 6144 bytes folowed by 768 bytes of attribute data for a 256x192 pixel display.
Each attribute square was made of 8x8 pixels with just 2 of the 16 colours allowed in each attribute square - 1 byte per square - 32 squares by 24 squares - 768 bytes.
It would have been nice to have the pixel data for those squares layed out in sequentially in memory but it wasn't. It was made of 3 sections of horizontal blocks, with each block being pixel data for 32 square by 8 squares. So you had 8 blocks by 3 sections to give 24 blocks (192 pixels) high.
To make matters even worse the sequential memory access of the pixel data area would work as follows:
the first 32 bytes would be for line 1 of the 1st row of 8x8 pixels,
the next 32 bytes would be for line 1 of the 2nd row,
the next 32 for line 1 of row 3,
the next 32 for line 1 of row 4,
the next 32 for line 1 of row 5,
the next 32 for line 1 of row 6,
the next 32 for line 1 of row 7,
the next 32 for line 1 of row 8 of the first 3 horizontal section.
the next 32 for line 2 of the 1st row,
the next 32 for line 2 of the 2nd row,
the next 32 for line 2 of row 3,
the next 32 for line 2 of row 4,
the next 32 for line 2 of row 5,
the next 32 for line 2 of row 6,
the next 32 for line 2 of row 7,
the next 32 for line 2 of row 8 of the first 3 horizontal section.
At the end of the 32nd byte of row 8, the next byte would be line 1 of row 1 of section 2 and the previous pattern continued, until the end of section 2 then the same pattern occurred for section 3. Immediately after the pixel data memory follows the 768 bytes attribute table.
Ahh the good ole days
I'm sure that description was as confusing as hell itself so here's a loading screen on Youtube showing the data being loaded sequentially straight into the screen memory location.
