Code Like It's 198x

Attribute-Aware Design

Designing for the ZX Spectrum's two-colours-per-cell rule

TechniquesSource-checked

How Spectrum designers and programmers worked with the rule that each 8×8 cell has one ink and one paper colour: one-colour rooms, colour kept where the sprites are not, sprites that wear the background's colour, black masks, whole-cell movement, and the attribute byte reused as a map.

CRASH graded Spectrum games on their colour. From its first issue in February 1984, each review’s comments box carried a “Use of colour” line, and the reviewers learnt to look for one problem in particular. In November 1984 they praised Avalon because its playing area “avoids messy attribute problems”. Later in the same issue, Zombie Zombie was “not the ideal game because of attribute problems”. When Ultimate’s Knight Lore arrived, the review explained why it looked so clean: “only one colour is used per screen which avoids any attribute problems.”

The problem was built into the hardware, and the manual that came with every Spectrum explained it: “you cannot possibly have more than two colours in a given block of 64 dots.” Attribute-aware design is the set of ways Spectrum programmers and artists found to live with that rule. The colour clash entry covers the artefact itself.

The rule

Each 8×8 cell has one ink colour and one paper colour. A moving sprite takes the colours of the cells its pixels occupy, so a yellow character crossing green scenery forces a choice: let the character change colour, change the scenery’s colour, or arrange the artwork so they do not share a cell.

BRIGHT and FLASH also belong to the whole cell. Colour by the cell explains the memory layout, attribute bits and the resulting limits. The design question is what the renderer should do when objects overlap that grid.

What the renderer decides

Every Spectrum game makes a choice about attribute memory, whether its programmer thought of it that way or not:

  • Rewrite the attribute. The sprite routine sets each cell it touches to the sprite’s colour. The background pixels in that cell change colour too, and the sprite drags a block of recoloured scenery with it. Anything printed through the ROM behaves this way by default: “any printing will set the corresponding attribute at all the character positions it uses.”
  • Leave the attribute alone. The sprite routine changes only the pixels, and the sprite takes whatever ink each cell already has. The scene’s colours never move. The sprite changes colour as it crosses them.
  • Design so the question never arises. Arrange the screen so that a sprite never shares a cell with a different colour.

Six ways of living with it

1. One colour per room. Give every cell on the screen the same ink and paper, and the sprites can go anywhere. Knight Lore (Ultimate Play The Game, 1984) drew each room of its castle in a single ink on black, sprites included, and changed the ink from room to room. CRASH noticed that the game still did not look drab: “each screen has its own colour.”

A Knight Lore room: isometric stone arches and a standing figure, the whole playfield drawn in the same green ink on black.
Knight Lore (Ultimate Play The Game, 1984, ZX Spectrum). The room and the player are both drawn in one ink on black. Only the status panel below the playfield uses other colours. Captured from the original tape.

2. Colour where the sprites are not. Put the colour in places the moving objects never go. Avalon kept its “borders very colourful” and its playing area “quite simple”. Ultimate’s Sabre Wulf (1984) did the same thing on a larger scale. Its jungle is dense, multicoloured foliage that forms the walls of the maze, while the paths the explorer walks are black.

A Sabre Wulf screen: a thick border of multicoloured jungle foliage around a black clearing, with small red figures in the clearing.
Sabre Wulf (Ultimate Play The Game, 1984, ZX Spectrum). The colour is in the foliage, which the player cannot walk through. The clearing where everything moves is black. Captured from the original tape.

3. Let the sprite wear the background. Change only the pixel bytes and never the attributes, so the sprite takes the colour of each cell it enters. The scenery stays intact, and the sprite changes colour as it crosses it. Sinclair BASIC has a version of this built in. INK 8 and PAPER 8 mean “transparent”: “the old attribute shows through”. A BASIC program can therefore print over a coloured scene without recolouring it.

4. Black masks. Surround the sprite with a band of black pixels wide enough that the scenery behind it is blanked out. The cells around the figure then hold the sprite and black, so the sprite’s colour has nothing to clash with. The cost moves to the scenery, which gets cut away around the figure. Your Sinclair spotted the technique in an August 1986 preview of Dark Sceptre from Beyond: “Look at the size of that mask — no attribute problems here.”

A Dark Sceptre screen: a large white skeletal warrior standing in front of a green vine arch, with the arch interrupted by black around his outline.
Dark Sceptre (Beyond, ZX Spectrum). The warrior stays white against coloured scenery because the arch behind him stops at a black margin that follows his outline. Captured from the original tape.

5. Move in whole cells. If a sprite only ever moves in steps of eight pixels, it always fills whole cells. Each cell it enters can take the sprite’s colours outright and get the scenery’s colours back when it leaves, so colour never bleeds past the sprite’s edge. The cost is movement that jumps rather than glides.

6. Accept it. Some games decided that smooth movement or detailed backgrounds mattered more. CRASH found that the main character of Frankie Goes to Hollywood “clashes a great deal with the background”, and gave its colour “excellent once you accept the attribute problems”. In 1989 the Software Creations team explained the choice they had made for Ghouls ‘n’ Ghosts: “The design of the backgrounds is severely limited by the scrolling technique, but the continuous smooth scrolling adds so much to the gameplay that this limitation can be endured.”

The attribute as data

The attribute area contains 768 bytes from address 22528 ($5800), one for each cell in the 32×24 grid. BASIC can read a cell with ATTR; machine code can read its byte directly. Because there is exactly one attribute byte per cell, the attribute area also works as a map of the screen. A program can read a cell’s byte to find out what is there, as well as what colour it is. If walls, floors and doors each have their own colour, one LD A,(HL) tells the program both how a cell looks and how it behaves. CRASH singled out Mike Follin’s Vectron, published by Firebird and reviewed in January 1986, for doing this with its maze: “Using the attribute file to overlay a map of the maze was an inspired idea.”

Sources

  • Steven Vickers, Sinclair ZX Spectrum BASIC Programming (Sinclair Research, 1982), chapter 16, pp. 110–114: attributes, the two-colours-per-cell rule, flashing, printing sets attributes, INK 8 and PAPER 8, the ATTR function; chapter 24, p. 164: the display file and attribute area in memory.
  • CRASH issue 1, February 1984: the “Use of colour” line in review comment boxes.
  • CRASH issue 10, November 1984, p. 51 (Avalon) and pp. 140–141 (Zombie Zombie).
  • CRASH issue 12, January 1985: Knight Lore review.
  • CRASH issue 6, July 1984, pp. 62–63: Sabre Wulf review, a game played in “a massive maze”.
  • CRASH issue 19, August 1985, p. 35: Frankie Goes to Hollywood review.
  • CRASH issue 24, January 1986, p. 36: Vectron review.
  • Your Sinclair issue 8, August 1986: Frontlines preview of Dark Sceptre.
  • Sinclair User issue 92, November 1989: Software Creations on programming Ghouls ‘n’ Ghosts.

See also

Checked. Verified against primary sources and signed off by a person.