dk'tronics 4k Graphics rom: mapped at 8192 The Kayde and dk'tronics boards were essentially the same and worked by extending the memory range that the display hardware could fetch character pixel patterns from. As well as containing 4K of ROM, the boards could also be fitted with 1K or 2K of RAM to allow 2 or 4 sets of user definable characters. Kayde released software titles Space Invaders, Centipede and Peckman for use with their Graphics ROM. dk'tronics released software titles Space Invaders, Centipede, Asteroids, Defender and Meteor Storm for use with their Graphics ROM. The Chroma 81 interface provides the ability to locate the character set pixel patterns within the full range of the lower 16K region. This makes it possible to use a ROM cartridge containing a copy of the ZX81 ROM and the Kayde or dk'tronics Graphics ROM and to display the alternate character sets provided by the Graphics ROM. This allows the range of enhanced graphical games designed to utilise the ROMs to be played without the need for the original hardware. The Chroma 81 interface can alternatively populate the region between the BASIC ROM and the BASIC program area with 8K of RAM. This makes it possible for a user to define their own character set. ___________________________________ WRX True High Resolution Graphics The WRX graphics mechanism achieves a true high resolution display using a combination of hardware and a custom video driver. It requires that the /RFSH control signal is redirected to the 16K RAM to allow pixel data to be read from it during the construction of the TV picture (on a standard ZX81 system the pixel data can only be obtained from the ROM space). The Chroma 81 interface add the WRX graphics support to all of its onboard RAM if configuration switch 2 is set to on. ___________________________________ The Chroma 81 interface was released in October 2014. The case was released in June 2018. The Chroma 81 interface provides the following facilities: - 16K RAM pack. - 8K RAM located between $2000-$3FFF, which allows support for user definable characters. - 16K RAM pack located in the 48K-64K region of the memory map, which can be used for data storage. - Attribute colour mode (15 ink and 15 paper colours per character position). - Character code colour mode (15 ink and 15 paper colours per line of each normal and inverse character). This mode allows existing games to be colourised! - Quicksilva Character Board emulation, which can be used with the Quicksilva games that supported the original board. - WRX hi-res graphics support for the onboard RAM. - RS232 socket, allowing connection to a variety of serial devices, such as a printer or a PC. - LOAD/SAVE sounds output through the SCART socket to the TV speaker(s). - ZX Interface 2 style ROM cartridge socket, allowing the internal ZX81 ROM to be completely overridden. - Cursor joystick socket, with support for auto-fire joysticks. - Reset button. - Configuration switches to enable / disable the new features. ______________________________________________________ the QS character board Jonathan Cauldwell (well known for his Spectrum games) has in recent years shifted focus to the ZX81 and many of his ZX81 games include support the QS character board. The QS Character board contained 1K of RAM and would override the ROM when the character pixel patterns were accessed. The board allowed the 64 non-inverse and 64 inverse characters to be separately redefined. The QS Character Board had to be manually enabled using an onboard switch, and so this functionality is replicated on the Chroma 81 interface using its configuration switch 4. The original board also had 4 DIL switches, which I believe were used to adjust the timing of when the RAM overrode the ROM (Chroma doesn’t replicate these since it automatically overrides the ROM at precisely the correct time). The QS Character board’s 1K of RAM appears in the memory map at $8400-$87FF. The RAM is always accessible for reading/writing, but the onboard switch determines whether the pixel patterns are fetched from the RAM or from the ZX81 ROM. Addresses $8400-85FF contain the pixel patterns for the ‘non-inverse’ characters (character codes $00-$3F), and $8600-$87FF contain the pixel patterns for the ‘inverse’ characters (character codes $80-$BF). The ZX81 display hardware automatically inverts the pixel characters for any of the ‘inverse’ characters. This means that the pixel patterns must be stored in RAM in inverted form such that the ZX81 display hardware inverts them back to non-inverted form. Games, such as QS Scramble, would load in two parts. The first sets up the QS character pixel patterns in RAM. It then puts up a message to the user informing them to ‘switch on’ the character board. Then after a few seconds, it would load the second part, which contained the actual game. Chroma’s extra 16K RAM is not only used for the colour attributes file / colour look-up table, but also the QS character board RAM. When configuration switch 4 is on, accessing $8400-$87FF or $C4000-$C7FF both access the same physical locations of the extra 16K RAM. If a game wants to use a colour attributes file and QS characters then it needs to make sure the attributes file does not overlap with the RAM used for the QS characters (which it does by positioning the display file accordingly). The Chroma 81 Technical Description document contains a diagram showing how the RAM overlay works: http://www.fruitcake.plus.com/Sinclair/ZX81/Chroma/ChromaInterface_Documentation.htm Chroma’s 16K RAM at $4000-$7FFF is enabled/disabled via configuration switch 1 (if off then the internal 1K RAM is present in the memory map). When the 16K is enabled, it can be made WRX enabled or not (via configuration switch 2). 8K of the extra 16K of RAM can also be made to appear at $2000-$3FFF (via configuration switch 3). This RAM can also be made WRX enabled or not via configuration switch 2. If any of Chroma’s RAM is enabled, then Chroma masks out MREQ and RFSH signals to its rear expansion bus. This prevents a ZXpand (or other interface) connected behind Chroma from also responding to these memory requests. As a result, if configuration switch 1 is on then Chroma provides the 16K RAM at $4000-$7FFF, with configuration switch 2 determining whether the RAM supports WRX. But if configuration switch 1 is off then it would be the ZXpand that provides the 16K RAM and its RAM is always WRX enabled (Chroma configuration switch 2 is ignored). The same mechanism applies to Chroma configuration switch 3 that enables RAM in the $2000-$3FFF region. In other words, Chroma’s RAM (if enabled) always takes precedence over the RAM of a device connected behind it. --- Two colour modes are provided – one mode is an attributes file similar to that on the Spectrum that can only be exploited by new software, and the other is a colourisation mode that assigns colours to each of the characters in the character set and so existing games can be coloured without the need for any changes to the games themselves. The range of colours supported is similar to the Spectrum. The border can also be set to any of the colours. A fully decoded I/O port is used to select which (if any) colour mode is active and what the border colour is. The port can also be read to determine whether Chroma colour is available. Chroma provides an extra 16K of RAM located in the 48K-64K region. This is used to hold the attributes file or the colourisation look-up table. For the attributes file mode (colour mode 1), the attributes file is situated at DFILE + $8000. The attributes file has the same ‘shape’ of the DFILE. This means that when a display file character is fetched during the display generation, the corresponding attributes byte is fetched from the corresponding location in the 48K-64K region. In your emulator, you would add 16K of RAM in the memory map at 48K-64K and allow it to be read from and written to normally. On a M1 read from the display file RAM, the emulator also fetches the corresponding attribute byte. You then render the pixel pattern for the character using the ink and paper colours defined by the attribute byte. This operation is repeated 8 times per character and so the same attribute bytes is read 8 times. The attributes file is technically situated at DFILE | $C000, which also allows support for a DFILE in the 8K-16K and the 32K-48K regions (but at present no games use colour with a DFILE in these regions). This approach means that colour attributes mode works with a collapsed display file or fully populated display file without the need for any special logic in the emulator. For the colourisation mode (colour mode 0), the first 1K (48K-49K region) holds a colour look-up table consisting of 128 characters each of 8 lines. After a character has been fetched from the display file, the pixel pattern for that character is looked-up from the ROM. As well as doing this look-up, the emulator needs to look up the corresponding attribute value from the 1K colour table. The table consists of 8 bytes per character corresponding to the 8 lines of pixel data for the character, i.e. it is possible to colour each line separately. The table begins with 0.5K for the 64 non-inverse characters and then 0.5K for the 64 inverse characters, i.e. the inverse characters can be independently coloured. And that is all there is to it. The emulator just needs to fetch the attribute value to render the 8 pixels of a character’s line from either DFILE | $C000 or look it up via $C000+(char*8)+line. Or default to black/white if Chroma colour is not available/enabled. Each attribute value consists of 4 bits for the ink and 4 bits for the colour. The 4 bits are RGB + Bright, i.e. ink and paper have separate Bright bits and there is no Flash bit as there is on the Spectrum. The above mechanisms for reading the colour attribute values also work when using pseudo hi-res, true WRX hi-res display drivers, CHR$128 UDGs or QS UDGs. So, get things working for lo-res and they just work automatically for hi-res.