ZX Spectrum - Screen memory layout

The Sinclair 48K Spectrum was just about the cheapest home computer you could buy in 1982 that had colour graphics.

There was a reason...

Just about every corner was cut in producing the ZX Spectrum: it had no custom hardware of any kind, short of a very simple ULA chip that did as little as it could get away with in order to have a working computer system, and the 16K ROM chip, with BASIC in it.

One consequence of this cost-cutting exercise was the strange, non-linear screen memory layout...

The Spectrum provided 256 pixels along the x-axis, and 192 lines along the y-axis.

Each byte in screen memory contained eight pixels, with no colour information. The colour was set in the attributes, a sequence of single bytes that were placed in memory immediately after the pixel information, and which specified the foreground and background colours for each 8x8 pixel cell.

Though the attributes are placed linearly, the pixels themselves are not. You can see this quite clearly when Spectrum games load their title screens:

The loader here is simply reading all the bytes from $4000 (16384) to the end of screen RAM at $5AFF, in order. As you can see, the pixels are arranged in a very "interesting" fashion...

This makes accessing screen memory a little bit more involved than simply adding Y lots of TotalXBytes to find the line.

Finding screen line addresses from a Y Coordinate

Given a Y coordinate stored in an 8-bit register:

Y Coordinate bit layout (MSB to LSB):
zzxx xnnn

we can produce a 16-bit address in a register pair by placing these bits as follows:

Register pair bit layout (R are the bits for the x-axis offset, 010 provides the base address $4000):
010z znnn xxxR RRRR

Who knows why on earth the engineers designing the Spectrum decided to swap the position of the nnn and xxx bits... but they did.

(I'm sure it was the same kind of reasoning as providing a console with half an altivec unit... ahem.)

Geek Moment - Some code to use this stuff

Here is some Z80 code that makes use of this knowledge, to clear the screen - not in the order as shown in the loader above, but sequentially (from the user's point of view).

; Clear the screen in an ordered, top to bottom fashion

;

; Entry: None

; Exit: A, BC, D, HL all trashed
;       (push on stack if needed)

;

; Notes:

;

; This is obviously slower than simply blatting from

; $4000 to $5800, but that would reveal the three sectors

; of the screen AND the alternate line pattern
; (both seen when loading screens)

; This is an example method to show how to address screen
; RAM using a Y coordinate instead, so we can move from
; top to bottom, line by line.

;

clearscreen_ordered:

                LD   B,192 ; num y lines

                XOR  A ; clear the accumulator
                       ; (MUCH faster than LD A,$00)

                LD   C,A ; c == y coord

; Here, we create the screen line pointer in HL,
; based upon the given y-coordinate in C.

; The y coordinate needs to be shuffled about a bit to be
; in the correct format for the Spectrum's bizarre
; hardware.

ylinesloop:

                LD   A,C

                AND  $7 ; get first three bits,
                        ; in the same position in H

                LD   H,A

                LD   A,C

                AND  $38 ; next three bits need to be
                         ; shifted left twice,
                         ; and placed in L

                RLA

                RLA

                LD   L,A

                LD   A,C

                AND  $C0 ; last two bits need to be
                         ; shifted right three times,
                         ; and placed in H

                RRA

                RRA

                RRA

                OR   H

                OR   $40 ; also include the base address
                         ; (screen mem starts at $4000)

                LD   H,A ; HL = ptr to line

; Individual lines are thankfully arranged in a linear
; fashion in memory. We can simply increase the
; pointer by one each time to clear a single line.

                LD   D,32 ; bytes per line (256 pixels)

xbytesloop:

                LD   (HL),$00 ; all pixels cleared

                INC  HL

                DEC  D

                JP   NZ,xbytesloop

                INC  C

                DEC  B

                JP   NZ,ylinesloop

                ret 

This code ignores the attribute memory for convenience's sake (that is linear, and would be a straight blat anyway... though it might be nice to do it in sync with each group of 8 lines... ;-))