ZX Spectrum ULA

From Sinclair Wiki
Revision as of 21:20, 6 April 2014 by Zub (talk | contribs) (→‎Keyboard Half-rows: Use wikitable class)
Jump to navigation Jump to search

The ULA (Uncommitted Logic Array) is a chip which controls most of the interfaces between the Z80 CPU and peripheral functions. On a ZX Spectrum 16k/48k, it is a Ferranti 5C102, 5C112 or 6C001 (the '102 had a timing fault which necessitated an extra board called the "spider mod"; the 6C001 alters the timing of the colour burst signal to improve performance with certain TV sets. (This info from the Spectrum Service Manual; don't know how to do citations on this wiki)).

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
0xFBFE Q W E R T 0xDFFE Y U I O P
0xFDFE A S D F G 0xBFFE H J K L Enter
0xFEFE Caps Z X C V 0x7FFE B N M Sym Space

Example

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 Caps-V and P-Y, 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.

Contention

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.

IO Contention

Weirdly, the ULA also applies contention to IO port reads/writes if A15 =0 and A14 =1. (details should go here; IO 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)