ZX Spectrum ULA

Revision as of 01:22, 12 October 2015 by Zub (talk | contribs) (IO → I/O as per Zilog Z80 and Spectrum BASIC manuals and Wikipedia)

The ULA (Uncommitted Logic Array) is a chip which controls most of the interfaces between the Z80 CPU and peripheral functions.

The ZX Spectrum 16K/48K ULA went through multiple revisions and is either a 5C or 6C series Ferranti ULA.

On a ZX Spectrum+ 128K, or ZX Spectrum +2 the ULA is the Ferranti 7K010E (labelled Amstrad 40056 in +2)

The ZX Spectrum +2A/2B, +3/3B machines use an entirely different gate array. See The Amstrad gate array

Sinclair also experimented with an alternative AMI SAGA chip in a special batch.


ULA Functions

The ULA is responsible for:

  • Generating the display (in conjunction with the UHF modulator)
  • Tape and audio I/O
  • Reading the keyboard

From Z80 code, the ULA functions are accessible on any even-numbered I/O port (as the ULA performs very partial port decoding), but conventionally port 0xFE is used.

IN from port xxFE will read the keyboard state and tape input. Each bit of the high byte selects a keyboard half-row; that row is read if the bit is low. If a key is pressed on any selected half-row, the corresponding bit of the data byte is low; this accounts for bits d0–d4. d6 is the value at the EAR socket (polarity?); d5 and d7 are not used.

OUT to port xxFE (the high byte is ignored) will set the border colour to {d2, d1, d0}, drive the MIC socket with d3 and the loudspeaker with d4.(again, polarity?) d5–d7 are not used.

Keyboard Half-rows

row d0 d1 d2 d3 d4 row d4 d3 d2 d1 d0
0xF7FE 1 2 3 4 5 0xEFFE 6 7 8 9 0
0xFDFE A S D F G 0xBFFE H J K L Enter
0xFEFE Caps Z X C V 0x7FFE B N M Sym Space


If the keys Caps Shift, T, and O are held down, and the Z80 does an IN on port 0xDEFE (5708610), this selects the half-rows CapsV and PY, so d0 is low because of the Caps Shift, d1 is low because of the O, and the T has no effect because its row is not selected. Thus the returned data byte is 0x1C (that is, 0b00011100, or 2810) assuming EAR (d6) is low.

ULA versions

Need some text here about the different versions of the ULA and which board revisions they are compatible with


Sinclair produced a special batch of Spectrums with an AMI SAGA instead of the Ferranti ULA. Only one machine belonging to this batch has been found and confirmed as having a genuine AMI SAGA board. The board was of Issue 6A, mounted in a Spectrum+ case, with a sticker instructing that the machine should be sent back to Sinclair Research should it require repair, marked for the attention of the QA manager. The AMI SAGA was found to run at a much lower temperature than the ULA, and does not require the Spectrum's chroma bias circuitry which was absent from the aforementioned board. The clock signal is clean enough to drive the Z80 directly, without any amplification, as this is also absent from the special batch board. One other machine has been reported to be found, but no photographs of this machine have yet been released.


The ULA has priority for reading from RAM, since it needs to be able to generate the display promptly. Thus if the Z80 attempts to read/write memory from the range 0x4000 to 0x7FFF (ie. A15 =0, A14 =1) while the display is being generated, the ULA will stop the Z80 (by disabling the CPU clock) until it has finished reading VRAM. This is known as "RAM contention" and the range 0x4000 to 0x7FFF is the "contended RAM". While the TV scan is within the display area, contention is applied for 6 T-states out of every 8.

I/O Contention

Weirdly, the ULA also applies contention to I/O port reads/writes if A15 =0 and A14 =1. (details should go here; I/O contention is more complicated somehow)

The Snow Effect

  • This article or section may be in need of copyediting for readability. You can help!

Contention is also indirectly responsible for the famous "Snow Effect", produced by setting the Z80's 'interrupt vector' (I) register to a value in the range 0x40–0x7F. This interacts with the Z80's memory refresh cycle: in the 3rd and 4th T-states of the M1 (opcode fetch) cycle, the Z80 pulls the MREQ and RFSH lines low, and asserts the R register in the low byte of the address bus; this is for dynamic RAM refresh. However, when doing this, it also asserts the I register on the high byte of the address bus. If I is in the range 0x40–0x7f, this will look to the ULA like an access to contended RAM (because the ULA doesn't check the RD, WR or RFSH lines, only the MREQ). However, the ULA will only halt the Z80 on the first T-state of any M-cycle.

The result of this is that the ULA won't assert the address it wants on the address bus, but it will still try to read the byte from RAM. This means it reads from whatever address was present on the bus, and uses that as the data to put on the screen. The upshot of all this is that the screen becomes filled with 'noise', almost as though the screen RAM had become corrupted — but the effect can be undone; putting the I register back will cause the screen to return to normal.

(I think there's more to it than this, I think you have to be running a sequence of 1-cycle instructions or something? Should probably find an example snow program to include)

(Also when people are talking about the snow effect they always seem to mention Arkanoid; presumably it uses the snow effect at some point)

Flash attribute timing bug

The flash attribute suffers from a timing bug, in that the flash signal is not in sync with the pixel with which it is XORed. On frames where the flash signal is inactive, this bug is not apparent, but where the flash signal is active, and used within an attribute block, flash will also affect the very right-hand edge of the preceding block, and in attribute blocks where flash is not set, flash will fail to affect the very right-hand edge of the preceding block. This bug only affects instances where there is a transition in pixel value between one character block and the next, but the flash attribute reverses that transition. As such, this does not affect the Spectrum's flashing cursor, as its graphic has edges matching the surrounding "paper" and not the ink. No existing emulator known to implement this display artifact.