=============================== CHROMA 81 TECHNICAL DESCRIPTION =============================== (c)2014-2022 Paul Farrow, www.fruitcake.plus.com Version 1.13, 25 Apr 2022 -------- Overview -------- Chroma 81 is a multi-function SCART interface for the ZX81, providing a clear, sharp picture on most modern TV sets. Note that modern Panasonic TVs do not implement the SCART specification correctly, with the result that Chroma may display shifted to the left or at worse the picture may be unstable jumping left/right. Chroma 81 is not intended for use with the ZX80 (some of its facilities need to be implemented in an alternate way to be compatible with the ZX80 hardware). Chroma 81 is compatible with all 3 ULA versions produced for the ZX81 (2C158E, 2C184E and 2C210E), and with all 3 editions of ROM that were released. ---------- Connection ---------- To avoid the risk of bending the edge connector contacts of the Chroma interface when plugging it in, it is recommended to visually check that the interface is properly aligned before attempting to insert it. -------- Switches -------- All facilities provided by the Chroma interface that use I/O ports can be disabled, thereby ensuring I/O compatibility with other devices (note that there might still be electrical or physical reasons that cause incompatibilities). Switch 1: ON=Enable onboard 16K RAM [$4000-$7FFF]. Switch 2: ON=Enable WRX graphics support for the onboard RAM. Switch 3: ON=Enable onboard 8K RAM [$2000-$3FFF]. Switch 4: ON=Enable Quicksilva Character Board emulation. Switch 5: ON=Enable RS232 socket. Switch 6: ON=Enable colour facilities / additional 16K RAM [$C000-$FFFF]. All combination of switch settings are supported. ----------------- Power Consumption ----------------- The ZX81 was originally sold with a 0.7A power supply. This was later upgraded to a 1.2A power supply when the ZX Printer was released. Care must be taken to ensure that these ratings are not exceeded otherwise the power supplies might dangerously overheat. The approximate current consumption used by various devices is shown below, but note that these are typical values and peak values might be higher. Where possible, always use a 1.2A power supply. ZX81 = 330mA Chroma interface = 330mA ROM cartridge = 50mA ZX Printer = 210mA ZXpand interface = 120mA ------------ SCART Socket ------------ The Chroma interface requires a standard RGB SCART cable since it only outputs a RGB picture (there is no composite video or S-video support). Sound is also output through the SCART socket (see below). Chroma provides the necessary signalling voltages to instruct the TV to automatically switch to display the SCART input as RGB. A SCART socket does not necessary have to support RGB and some TVs only support different video formats on each of their SCART sockets. Therefore always try all SCART sockets on the TV if a picture cannot be obtained from the first one tried. A bi-directional SCART cable should be wired as follows: 1 - 2 2 - 1 4 - 4 3 - 6 6 - 3 5 - 5 7 - 7 8 - 8 9 - 9 11 - 11 13 - 13 15 - 15 16 - 16 17 - 17 18 - 18 19 - 20 20 - 19 21 - 21 ------------ Sound Output ------------ The video signal is output to the audio channels of the SCART socket whenever video synchronisation is lost, e.g. during LOAD and SAVE. In FAST mode, this can also provide an audible indication whenever a key press is detected (useful when typing in a program). The sound facility also allows programs that produce musical tones by precisely toggling the video signal output to be heard (and without the background hiss that a mis-tuned analogue TV always used to superimpose). ------------------ Rear Expansion Bus ------------------ A full rear expansion bus is provided. Not all signals are directly connected to the ZX81 expansion bus. This is to allow the majority of onboard facilities to override those presented by a rear device. This is achieved by controlling the /MREQ and /RFSH lines. The onboard RAM and ROM cartridge sockets will prevent /MREQ and /RFSH signals appearing on the rear expansion bus, thereby allowing these facilities to have priority to the memory map space. ------------ Reset Button ------------ This connects directly to the /RST line. Press and hold for about one second to ensure the CPU is properly reset. Note that the CPLD may be held in reset longer than the Z80 and so a ROM cartridge program should delay attempting to control the colour or RS232 facilities for about a second or so at start-up. -------------------- ROM Cartridge Socket -------------------- The ROM cartridge socket is identical to that of the ZX Interface 2 for the Spectrum. This allows my range of ZXC ROM cartridges to be used, thereby avoiding the additional cost of custom cartridges just for the Chroma interface. The latest in the range of ZXC ROM cartridges is the ZXC4. This supports a 4MB FLASH ROM, which is directly programmable from the ZX81. With a ROM cartridge plugged in, the /MREQ and /RFSH lines of the rear expansion bus is held high to prevent a device plugged in behind seeing ROM address accesses. This ensures the ROM cartridge overrides the ROM of a rear device. The ROM cartridge socket also overrides the character bitmap generator inside the ZX81. It is therefore possible to completely replace the ZX81 ROM with a copy of one of the commercially available ROM replacements, e.g. the Skywave FORTH ROM or the Comprocsys ASZMIC ROM, and to run it directly from a ROM cartridge. A ROM cartridge can populate all of the ROM address space from $0000-$3FFF, thereby allowing an extended version of the ZX81 ROM to be produced. A ROM cartridge will override the onboard 8K RAM facility if it is enabled. The ZX81 was released with three editions of its ROM. The first edition had an infamous bug that resulted in the SQR 0.25 yielding a result of 1.3591409 instead of 0.5. The bug was caused by 3 unnecessary instructions that caused corruption to the computed result. Rather than throw away all ROMs that had been manufactured, Sinclair crafted a small hardware board that was soldered across the Z80 CPU. It intercepted the execution of one of the erroneous instructions and changed it such that the 3 surplus instructions no longer had an effect on the floating point calculation. Due to the manner in which the hardware fix intercepts the fetch of one of the rogue floating point instructions, it would also intercept and override an instruction fetch at the corresponding location from a ROM cartridge. This places constraints on the programs that can be run from a ROM cartridge that is plugged into a ZX81 fitted with a hardware fix board. The hardware fix is designed to intercept the rogue instruction at $1735. This location contains a LD H,A instruction (opcode $67) and the hardware board forces bit 6 to 0 thereby transforming the instruction into DAA (opcode $27). The corruption of the floating point result is now avoided, with only harmless side effects. The hardware fix only partially decodes the instruction fetch address and so would actually trap 8 addresses ($0335, $0735, $1335, $1735, $2335, $2735, $3335 and $3735), but the only address that will be intercepted when using a first edition ZX81 ROM is $1735 (the other locations contain the operand for an instruction and not the opcode). To successfully use a ROM cartridge on a ZX81 fitted with the hardware fix board, either the 8 intercepted addresses must not contain the start of an instruction or if they do then the instruction opcodes must have bit 6 reset. It is often possible to determine whether a hardware fix board is fitted by looking through the expansion bus slot. Alternatively it can be determined by executing three BASIC instructions and comparing the results to the figures shown below: Edition 1 Edition 1 & Edition 2 Edition 3 Hardware Fix PRINT PEEK 3823 33 33 205 205 PRINT PEEK 3901 253 253 205 253 PRINT SQR 0.25 1.3591409 0.5 0.5 0.5 --------------- Joystick Socket --------------- The joystick socket only supports the cursor format. The socket is read using two input ports - $F7FE and $EFFE. The data read in from the ports is formatted as follows: Port $F7FE (xxxx0xxx xxxxxxx0) - IN: Port $EFFE (xxx0xxxx xxxxxxx0) - IN: +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | | | | | | | | | | | | | | | | | | | | | | | +-------- 0=Left. | | | | | | | +-------- 0=Fire. | | | | | | +------------ X=Not used. | | | | | | +------------ X=Not used. | | | | | +---------------- X=Not used. | | | | | +---------------- 0=Right. | | | | +-------------------- X=Not used. | | | | +-------------------- 0=Up. | | | +------------------------ X=Not used. | | | +------------------------ 0=Down. | | +---------------------------- X=Not used. | | +---------------------------- X=Not used. | +-------------------------------- X=Not used. | +-------------------------------- X=Not used. +------------------------------------ X=Not used. +------------------------------------ X=Not used. The physical joystick socket is wired as follows: Pin Function --- -------- 1 Up 2 Down Female 9-Way D-Type 3 Left _____________________ 4 Right / 1 2 3 4 5 \ 5 n/c \ o o o o o / 6 Fire \ 6 7 8 9 / 7 +5V \ o o o o / 8 0V \_______________/ 9 n/c The +5V line provides support for auto-fire joysticks. The data lines are normally held in a high impedance state. They will be brought low when a joystick direction or button is activated. This allows the Cursor joystick to coexist with the keyboard (and other Cursor joystick interfaces). ------------ RS232 Socket ------------ The RS232 socket can be used to connect to a variety of serial devices. A standard non-crossover 9-way cable can be used to connect directly to a PC or a serial printer. These two purposes require slightly different wiring, differing only with regard to the handshaking input line used by the Chroma interface to determine whether it can send data. For a PC, the RTS line should be used, whereas for a serial printer the DTR line should be used. A jumper is present on the Chroma interface to select which handshaking line to receive. The RS232 socket is enabled using configuration switch 5. The RS232 socket is controlled by I/O port $FEEF (11111110 11101111). The address lines are fully decoded. The data is sent and received inverted and so a CPL instruction is necessary within software before sending and after receiving. Upon resetting the ZX81 or disabling of the RS232 socket via switch 5, the output lines are set to the IDLE state. Port $FEEF (11111110 11101111) - OUT: +---+---+---+---+---+---+---+---+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +---+---+---+---+---+---+---+---+ | | | | | | | | | | | | | | | +-------- TX data [output] (data inverted, 0=Idle). | | | | | | +------------ CTS [output] (0=Signal do not send, 1=Signal Ok to send). | | | | | +---------------- Reserved for future use (always set to 0). | | | | +-------------------- Reserved for future use (always set to 0). | | | +------------------------ Reserved for future use (always set to 0). | | +---------------------------- Reserved for future use (always set to 0). | +-------------------------------- Reserved for future use (always set to 0). +------------------------------------ Reserved for future use (always set to 0). Port $FEEF (11111110 11101111) - IN: +---+---+---+---+---+---+---+---+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +---+---+---+---+---+---+---+---+ | | | | | | | | | | | | | | | +-------- 0=RS232 facility enabled. | | | | | | +------------ X=Not used (reserved for future use). | | | | | +---------------- X=Not used (reserved for future use). | | | | +-------------------- X=Not used (reserved for future use). | | | +------------------------ X=Not used (reserved for future use). | | +---------------------------- X=Not used (reserved for future use). | +-------------------------------- RTS/DTR [input] (0=Do not send, 1=Ok to send). +------------------------------------ RX data [input] (data inverted, 0=Idle). Bit 0 can be used to determine whether the RS232 facility is available. However, it does require the assumption that the value returned when reading port $FEEF is from the Chroma interface (in theory the RS232 facilities could be disabled on Chroma and another device instead responds to reads from port $FEEF). With carefully timed software it is possible to achieve transmission speeds up to 57600 baud. Note that the IN port bit assignments are different to those of the Chroma 80 interface for the ZX80 and hence data receiving routines are not directly interchangeable between the computers. ----------- Onboard RAM ----------- The Chroma interface contains 32K of RAM. 16K of this can be enabled as a 16K RAM pack. The additional 16K is shared between three other facilities - 8K RAM [appears at $2000-$3FFF], Quicksilva Character Board emulation [appears at $8400-$87FF], and colour attributes [appears at $C000-$FFFF]. It is also possible to just use the RAM as 16K of storage space [at $C000-$FFFF]. Each facility uses specific locations from the second 16K RAM and so they can be viewed as overlays over the same 16K. As a result, it is possible to utilise certain combinations at the same time, e.g. Quicksilva Character Board emulation and colour. The specific areas used by each facility are summarised below: ADDITIONAL 16K RAM $0000 +------+ | | \ \ | | |__ Colour Mapping Table [Colour Mode 0] | | | | (appears in memory map at $C000-$C3FF) | | | / | $0400 +------+ | | | \ | | | |__ Quicksilva Character Board Emulation | | | | (appears in memory map at $8400-$87FF | | | / and $C400-$C7FF) | +------+ | $0800 | | | | | | | | | | | | | | | | | | | | | | | |__ Colour Attribute File [Colour Mode 1] $2000 +------+ | (appears in memory map between | | \ | $C000-$FFFF, at DFILE+$8000) | | | | | | | | | | | | | | | | | | | | | | | | | | |__ 8K RAM | | | | (appears in memory map at $2000-$3FFF, | | | | $A000-$BFFF, and $E000-$FFFF) | | | | | | | | | | | | | | | | | | | | | | | / / $3FFF +------+ An onboard RAM region will override equivalent RAM in a device connected ahead of the Chroma interface, so long as that device monitors its rear expansion bus /RAMCS line. It will also override equivalent RAM in a device connected behind the Chroma interface. This is achieved by disabling the /MREQ and /RFSH lines to the rear device whenever the onboard RAM is accessed. Note that the /RFSH line will also be disabled for any RAM enabled on the Chroma interface, thereby allowing certain games to function correctly, e.g. the 'Super Zapper' bomb in Software Farm's Z-Xtricator. ------- 16K RAM ------- 16K of the onboard 32K RAM can be enabled as a 16K RAM pack using configuration switch 1. If switch 1 is set to OFF then the internal 1K RAM is present in the memory map (unless overridden by a device connected ahead or behind Chroma, e.g. a Sinclair 16K RAM pack). ------ 8K RAM ------ This facility enables RAM in the upper 8K region of the ROM space within the memory map, i.e. $2000-$3FFF, and is also echoed at $A000-$BFFF. It allows a display file to exist within the 8K-16K region. The 8K RAM facility is enabled using configuration switch 3. It uses the upper 8K locations of the additional onboard 16K RAM, and so when switch 6 is on then the RAM also appears at $E000-$FFFF. The RAM can be used to hold alternate user definable character sets, or to store data that will survive NEW or RAND USR 0. The original Chroma specification only allowed 64 characters to be redefined, and hence was compatible with the user definable mode provided by the dk'tronics/Kayde Graphics ROM board when fitted with onboard RAM. An optional upgrade to the Chroma logic (version 1.05) extends the capability to support the CHR$128 user definable character mode, which allows all 128 characters to be redefined. WRX graphic support must be disabled in order to use CHR$128 mode. If a ROM cartridge is present then it will override the 8K RAM (including its echo) and will appear in the memory map instead. When used on a ZX81 fitted with a first edition ROM and the hardware fix board (described under the ROM cartridge section), instruction fetches from locations $2335, $2735, $3335 and $3735 will be intercepted and bit 6 forced to 0. -------------------- WRX Graphics Support -------------------- This facility will cause memory refreshes to read from the 16K RAM pack (if enabled), 8K RAM region (if enabled) or 48K-64K region (if colour facilities are enabled), and allows true high resolution graphics to be generated by the ZX81. The facility is enabled using configuration switch 2. This feature only applies to the onboard RAM and does not affect the /MREQ line that appears on the rear expansion bus, i.e. switch 2 will not provide WRX support to a standard RAM pack connected behind Chroma. When onboard RAM and WRX graphic support are enabled then the /MREQ and /RFSH lines to the rear expansion bus are disabled whenever an access occurs to the onboard RAM, i.e. Chroma services the RAM request and has priority over RAM provided by a device connected behind it. The WRX configuration switch has no effect if none of the onboard RAM is enabled. ------------------------------------ Quicksilva Character Board Emulation ------------------------------------ This facility emulates the QS Character Board produced by Quicksilva. This board operated by overriding access to the character bitmaps held in the ZX81 ROM with 1K of RAM, thereby allowing alternate, user defined character patterns to be displayed. The RAM of the QS Character Board is accessed within the memory map at $8400-$87FF. Locations $8400-$85FF hold the bitmaps for the normal 64 characters, and locations $8600-$87FF hold the bitmaps for the inverse characters. Note that the bitmap for the inverse characters must be stored inverted. Several Quicksilva games supported the QS Character Board, namely QS Asteroids, QS Invaders, QS Scramble and Cosmic Guerilla. Hewson Consultants' Puckman and Artic Computing's ZX-Forth also support the QS Character Board. The QS Character Board used a DIL switch to enable/disable its operation. Programs could not read the state of this switch and so either just had to assume the board was present or would prompt the user to enable it. A program could attempt to determine whether RAM existed between $8400-$87FF but couldn't guarantee that this was due to a QS Character Board instead of a 64K RAM pack. When switch 6 is on, the QS Character Board RAM also appears at $C400-$C7FF. QS Character Board emulation is enabled on the Chroma interface using configuration switch 4. ------------ Colour Modes ------------ By default, the ZX81 will power up in standard monochrome display mode. Two colour modes are supported: Colour mode 0 - Character code colour mapping. Colour mode 1 - Attributes display file. Each mode supports independent colours for the reset pixels (paper) and set pixels (ink), and both allow the border colour to be selected. 15 colours are supported for ink and 15 colours for paper. This consists of green, red and blue bits and a bright bit (as per the Spectrum), and hence bright black and black both appear the same. The border may be set to any of these 15 colours. With colour mode 0 or 1 enabled, the additional 16K RAM appears at $C000-$FFFF within the memory map. Any locations not used by the colour mode (or by Quicksilva Character Board emulation, or for the 8K RAM region) may be freely used for storage by a program. However, the existing restriction that (mostly) prevents the execution of code from any location above $7FFF still applies. The colour facilities operate in both SLOW and FAST mode. The colour facilities are enabled using configuration switch 6. I/O ports --------- I/O port $7FEF is used to select the active colour mode and to determine whether the colour facilities are enabled. The address lines are fully decoded. Port $7FEF (01111111 11101111) - OUT: +---+---+---+---+---+---+---+---+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +---+---+---+---+---+---+---+---+ | | | | | | | | | | | | | +---+---+-------- Border colour (format: GRB). | | | | +-------------------- Border colour bright bit. | | | +------------------------ Mode (0=Character code, 1=Attribute file). | | +---------------------------- 1=Enable colour mode. +---+-------------------------------- Reserved for future use (always set to 0). If configuration switch 6 is set to OFF, the colour mode is forcibly disabled, colour mode 0 (character code mapping) selected, and the border restored to bright white. Port $7FEF (01111111 11101111) - IN: +---+---+---+---+---+---+---+---+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +---+---+---+---+---+---+---+---+ | | | | | | | | | | | +---+---+---+---+-------- X=Not used (reserved for future use). | | +---------------------------- 0=Colour modes available, i.e. configuration switch 6 is set to ON. +---+-------------------------------- X=Not used (reserved for future use). If the colour facilities have not been enabled using configuration switch 6 or the Chroma interface is not connected then reading from port $7FEF will return $FF (the default value of the data lines). With the Chroma interface present but colour facilities disabled, a read from port $7FEF will not set any data lines, thereby allowing another device exclusive access to this input port. A consequence of this is that a read of the port cannot differentiate between Chroma responding and another device responding. However, hopefully a user would not attempt to run a program that requires the Chroma colour facilities if they have a known conflicting device attached. Colour mode 0 ------------- This mode allows existing games to be colourised. A table is used to map colours for each character the ZX81 is capable of displaying. Colours can be mapped for the normal 64 characters and also for the inverse 64 characters. The colour mapping is per pixel line of each character, with separate paper and ink colours defined for each line. The mapping table appears at $C000-$C3FF in the memory map and is ordered with the mappings for the normal 64 characters first, followed immediately by the mappings for the inverse 64 characters. Each character's mapping entry consists of 8 bytes corresponding to the 8 pixel lines of the character bitmap (beginning with the top line). Therefore the entries for character 0 reside at $C000-$C007, the entries character 1 reside at $C008-$C00F, the entries for character 2 reside at $C010-$C017, etc. Each entry uses the following format: +---+---+---+---+---+---+---+---+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +---+---+---+---+---+---+---+---+ | | | | | | | | | | | | | +---+---+-------- Ink colour (format: GRB). | | | | +-------------------- Ink colour bright bit. | +---+---+------------------------ Paper colour (format: GRB). +------------------------------------ Paper colour bright bit. To colourise an existing game, the colour mapping table entries must first be configured, colour mode 0 enabled and then the game loaded. The border colour can also be set prior to loading the game by writing to port $7FEF (as defined above). The mapping colours will remain active until the ZX81 is reset, i.e. they will survive NEW and RAND USR 0 but not the reset button. The mapping colours are read from the RAM each time the display is generated and so it is possible for a program to dynamically adjust the colours. However, this would require explicit software created to do this. Colour mode 1 ------------- This mode can only be exploited by software explicitly written to control it. It utilises an attributes file located in the upper 16K of the memory map (between $C000-$FFFF) which is situated at DFILE+$8000, i.e. bit 15 is set. The attributes file has the same 'shape' as the display file. This approach makes it easy for a program to find the corresponding attribute cell for a particular display file cell. It also means that if the display file shifts in memory then so too will the attributes file. Note that the Chroma interface assumes the display file will always exist between $4000-$7FFF, i.e. colour mode 1 cannot be applied to a display file that resides between $2000-$3FFF. Colour mode 1 uses a single attribute byte per character, and hence only one paper colour and one ink colour may be applied to the 8x8 pixel character cell. Each attribute cell is formatted as follows: +---+---+---+---+---+---+---+---+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +---+---+---+---+---+---+---+---+ | | | | | | | | | | | | | +---+---+-------- Ink colour (format: GRB). | | | | +-------------------- Ink colour bright bit. | +---+---+------------------------ Paper colour (format: GRB). +------------------------------------ Paper colour bright bit. A consequence of the attribute file having the same shape as the display file is that it also contains gaps for the end of row NEWLINE markers. However, these locations are not used and so do not need to be set. The locations are available for use as storage by a program if desired. The attribute colours are read from the RAM each time the display is generated and so it is possible for a program to dynamically adjust the colours. -------------- I/O Port Usage -------------- The Chroma interface uses base I/O port $EF (11101111). The address lines are fully decoded. The upper address lines A18-A15 are then used by Chroma to control different facilities provided by the interface. At present this only consists of the RS232 and colour facilities, but further I/O ports with base address $EF may be used in future versions of the interface. These I/O port addresses are therefore considered reserved for use by future Chroma interfaces. ------------- Compatibility ------------- Chroma 81 is compatible with the standard ZXpand and ZXpand+ interfaces. If the AY daughter board is fitted to the ZXpand interface then a GAL logic update is required to it to achieve compatibility. The AY support integrated into the ZXpand+ is already compatible. The GAL logic update for the AY daughter board for the original ZXpand interface was released 17th March 2022.