At the time of their conception, there were already hobbyist computers around, and all used conventional designs. The processor ROM and RAM where separate from the video generator RAM and character generator ROM.
The ZX micros were designed to provide a real, working computer at a very competitive price. Some bright person saw that a processor could be used to generate the sequential video data addresses and thus avoid the need for a video controller chip. Secondly, the processor's ROM could also be used as the character generator ROM. Thus, a working computer could be made with very few large chips indeed.
The disadvantage is that while the CPU is generating the display, it cannot be doing anything else. The ZX80 simply didn't bother to generate video when it was busy running programs or responding to the keyboard. This was a compromise which one had to accept in return for the low cost. One could type in a program (although the display flickered on each key press), set it running, and the display would re-appear when it had a result.
The ZX80 sold well, and Sinclair advanced the design into the ZX81. Cost was further reduced by cramming all the TTL logic into a single 40-pin custom chip. This was Ferranti's Uncommitted Logic Array (ULA), which was customised by a final metal layer that connected the array of logic gates.
The ZX81 also added a flicker free display mode, by having the display generated when demanded by a non-maskable interrupt. Generating the display took only about 75% of the CPU time, so when it had finished generating a frame it could return to the program it was running. Thus the programs ran at a quarter speed, but at least you could now have programs that used the display.
Finally the ZX81 also had an 8K BASIC chip, which allowed floating-point maths.
The ZX micro stores the display data in the second 16K block of the 64K memory map. The bottom 32K also appears in the upper 32K. When the Z80 generates video, it jumps to the address of display data in the top 32K. The glue logic of the ZX micro is such that Z80 gets nop codes when it tries to execute machine code in the top 32K. This is done by the open collector buffers IC14 and IC15 pulling the data bus lines D0-7 down to 0V.
The Z80 data bus D0-7 has eight 1K resistors between it and the RAM/ROM data bus D0'-7' so although D0-7 are forced low, the RAM or ROM is still able to drive D0'-7' high or low. This true video character data byte is latched in IC5.
The BASIC ROM (IC2) does double duty as the character generator ROM. Normally, the multiplexers IC6,7,8 route the Z80 address lines into the ROM. However, when the Z80 has fetched a machine code instructions it then does a memory refresh cycle. ZX micros use this cycle to use the ROM as a character generator. When /RFSH is low, the multiplexers route the latched character data (from IC5) and the character line count (from IC21) into the ROM. The data from the ROM is loaded into the shift register IC9 and shifted out.
IC9 has true and complimentary outputs, so you can set a link to choose white-on-black or black-on-white video.
D6 and D7 of the character data are never routed to the ROM. Instead, D7 controls whether the pixels are true (if zero) or inverted.
D6 has a special function to play. After accessing a row of characters, we do no want the Z80 to continue, so it has to be stopped. If D6' is high, nop codes are not forced onto D0-7, so the Z80 sees the data as a true instruction. I believe this is the NEWLINE character, 0x76, binary 01110110. This happens to be the Z80 opcode for the HALT instruction.
This works in a very similar manner. It requires a minor alteration to the ZX81 BASIC ROM. Instead of replacing it completely, it merely substitutes a 256-byte section of the G007 ROM. Thus it appears both at 0x2C00 and 0xC000. This can be done because the ZX81 has a 680R resistor between the signal /ROMCS and the ZX81 logic that drives it. Normally this has no effect, but it allows an external device (such as the G007) to over-ride the normal memory mapping without the damaging effects of shorting two outputs together. The ZX80 has a resistor to do this function on the /RAMCS line, but not the /ROMCS line, so be aware of this if using the G007 with a ZX80 that has been upgraded to ZX81 functionality.
In some ways, high-res graphics is simpler than character graphics. Bytes are loaded straight into the shift register, instead of indirectly through the ROM. There is no need for the counter IC21 to count the lines of the characters. The G007 logic ensures the graphic pixels appear on D0'-7' when the character pixels would normally have appeared.
If you wished to design a ZX81 with integrated G007 graphics, you could reduce the amount of logic. For example:
1) The ZX81 and G007 use separate ROMs.
You could blow them into a single 16K EPROM.
2) The G007 has to decode the 256-byte of ROM patched into the BASIC ROM.
If you modify the BASIC ROM, then this logic and the patch in the G007 area are redundant.
3) You could mop up much of the logic into one or two GAL22V10 chips.
This would cut down the amount of fiddly wiring, PCB area, and
potential wiring mistakes.
I compared the current consumptions: a PALCE22V10 consumes about
30mA. The 74HC series chips consume between 20 and 40 microamps
each. So it depends if you wish to impress friends with a
micro-power ZX81 that runs off flashlight batteries, or one that
shows off your GAL design skills. Personally I think the latter
would be more impressive to a potential employer. You need a TV
or monitor to show it working, so you should never be far from
mains power. You could do both, and cover both bases!
Ian Bradbury reports having mopped the ZX81 into five GALs, one of which which re-mapped the available 10x4 membrane keypad into a ZX81-compatible matrix. The GALs are slightly more advanced than the typical 22V10, in that they allow buried terms (these act like output pins with no external connection). Thus they can almost be like having two 22V10 chips in one package. Click here for picture.
4: You could mop everything into a Xilinx or Actel FPGA
If you have access to the expensive development tools, of
course. Personally I haven't!
Bodo Wenzel
reports having done this with a Xilinx 3042 logic cell array in
his ZX97 project. It even drives a monchrome 320x240 LCD. Current
consumption is about 70mA including the converter for the LCD
interface. He has the VHDL source files on his web site, but not
the schematic yet. The latter was conveted to an Eagle format
schematic by Kai Fischer of the German ZX team, but isn't
available on their web site yet.
N.B. This isn't the same as Wilf Ritger's project of the same
name.
