You got it pretty much bang on there Eric. Not bad for someone who's never coded for a Spectrum!
The Spectrum display is broken up into the display file and the attribute file. The display file runs from $4000-$57ff and represents a bitmap of size 256x192 (=6144/$1800 bytes). Each row is 32 bytes in width and each one of those 32 bytes represents 8 bits (or pixels, if you prefer to call them that!) (32x8=256 pixels wide). If a bit is set then that pixel is on, if a bit is clear then that pixel is off. The display file layout is non-linear and to a non-Spectrum programmer it would appear to be an extremely strange layout. It starts to make much more sense when you code in assembly language but I won't go into the complexities of it in this post. (simply put you can use INC H to move down 1 line in the display file and DEC H to move up 1 line in the display file, but it gets a little more complicated than that as the display file is actually comprised of three distinct segments).
The attribute file runs from $5800-$5aff and is a 32x24 grid of colour information for each 8x8 block (tile) of the display file. Each byte of the attribute file is comprised as follows :-
bits 0-2 = ink (pen) colour (8 possible colours from 3 bits)
bits 3-5 = paper colour (8 possible colours from 3 bits)
bit 6 = brightness level (on or off)
bit 7 = flash (on or off)
So, each 8x8 tile displayed on screen can contain a maximum of 2 colours (an ink colour and a paper colour) at any one time. To move a sprite you need to update the display file with the new position of the bitmap of the sprite and then update the attribute file to ensure that the colour information moves in tandem with the sprite bitmap data. Sprites were usually done in a pre-shifted fashion, moving 2 pixels at a time. Therefore you would need to define 4 sprites to move a character 8 pixels left or right. This technique consumed quite a fair amount of ram (especially if your game had many varieties of sprites) but allowed for smooth character movement. If the character moved 2 pixels per frame then it would cover the width of the screen in 128 frames (2.56 seconds for a 50Hz PAL Spectrum). This was considered too fast for many games so character movement was usually done every other frame or even every third frame to slow things down to a more playable speed.
The reason the Spectrum suffered from colour clash was because, as the sprites moved around the screen, they would move into areas where the attribute file contents for the 8x8 tile they were moving in to had different colours to the attribute file contents of the sprite and because each 8x8 attribute file tile can only contain a maximum of two colours at any one time something had to give. So either the sprite's colours got messed up or the background tile's colours got messed up, depending on the draw order of sprite vs other sprite or sprite vs background tile.
Colour clash is the reason why many Spectrum games ended up being monochromatic, after all, it's impossible to have colour clash if the entire screen only uses 2 colours!
As strange as it sounds, to me the colour clash was really a big part of the Spectrum's heart and soul and, IMHO, kind of helped to make it the machine that it was. To that end I'm even considering adding a special 'colour clash' mode in my CE2 remake on L System (toggle-able via dip switch). Hmm, maybe I should add that feature as paid DLC!
cmonkey2015-07-10 00:44:29