The hardware

The design I came up with probably contains few surprises and is inspired by various designs that are floating around on the internet.

Chips used

• For the TTL chips, the familiar HC or HCT family can be used. There is only one exception. The 74F163 really needs to be from the F family since the HC/HCT version can’t handle the 25.175 MHz dot clock. The ones I had all topped out at around 22 MHz.

• When using the HC/HCT family of TTL chips I measured a total power consumption of the board to be around 400 mA (2 Watt). That would be substantially more when the LS family of TTL chips would be used.

• For the RAM, I used 3 7164S20TPG chips (8K bytes RAM). One is used for the CPU (I called it USER RAM) to store variables (and some code as well (see later)) and is mapped to 0x8000 - 0x9FFF. The other 2 are used as video RAM. One is used to store the characters to be displayed (mapped to 0xE000 - 0xFFFF) and the other for storing the colours (mapped to 0xC000 - 0xDFFF).

• The 8 bits of the colour RAM is split in 2 times 4 bits to define the font colour and the background colour. 3 Bits are used for RGB and 1 bit is used as a intensity bit. In that way we have 16 colours for the font and 16 colours for the background.

• I ended up choosing 8k Byte RAM chips while 4K RAM would have been sufficient (although the maximum resolution would then be limited to 80 by 51 lines instead of 80 by 60). However, 4K RAM parts are hard to find these days it seems and they’re quite expensive as well. So I ended up with 8K Byte RAM parts.

• To store the code and fonts, I used 2 SST39SF010 chips. These are 128 kBytes NOR Flash.

  • Only 32 KByte is used for the code (0x00000 - 0x7FFF).

  • The NOR Flash used to store the fonts can hold 16 fonts (only one font can be used at the same time). Each font takes up 8 KBytes (allowing characters being 32 pixels high). The selection of the font happens by setting the 4 LSB bits on port 0x20.

• For the PS/2 keyboard decoding I use a modern ATMEGA328P as used in the popular Arduino Uno’s. I found some place to add a second PS/2 connector that could be used with a PS/2 mouse.

  • The keyboard codes are sent over a serial line from the ATMEGA328P to the second serial port of the Z180 at 115.200 baud.

  • Currently, the code only supports a US QWERTY keyboard layout. But adding other layouts should be simple and is simply a matter of making a corresponding lookup table for the keyboard scan codes.

  • A piezo buzzer is connected to the ATMEGA328P. At this moment this is only used as an audio feedback if a PS/2 keyboard has been detected during start-up. If detected, you’ll here a happy tone. If not, then a continuously sad tone will be played.

  • Mouse support isn’t implemented yet at the time I write this.

  • I used the PS2KeyAdvanced Library from techpaul.

• Flicker reduction, when the CPU is writing to video RAM, is handled by the flip flops in U27 (74HCT175). An idea I found in an old Elector VDU project (September 1983 edition). That works pretty well except when the background is not black. E.g if you have a blue background, then you can see black horizontal stripes of 8 pixels wide when the CPU writes to the video RAM (as shown in the picture below). I hope to improve this in a next revision of the board.

  • There is an experimental feature on the PCB. Installing the jumper J4 will connect the video blanking signal to the WAIT pin of the Z180. This will force the Z180 to only write to video RAM when nothing is displayed on the screen. Screen flicker is greatly reduced but the CPU runs at less than half its normal speed and when running the serial port at 115.200 baud flat out, characters get lost. That’s the case when running Turbo Pascal. WordStar 4 seems to write characters to the screen a bit slower than Turbo Pascal and WordStar was happy to run with the jumper in place without losing characters. Although I didn’t try it, running at ‘only’ 57.600 baud might be OK if you can live with such a lower baud rate.

Power and Reset

The terminal can be used on its own. In which case the power connector and reset circuitry needs to be in place. But it can also be plugged in the RC2014 bus from which it then takes power and the reset signal. Also the RX/TX signals can be taken from the RC2014 bus. This can be controlled with jumpers as well in case the PCB is build for both configurations.

• J3 - When the jumpers are in place, the RX/TX signals from the RC2014 bus will be passed through to the Z180 CPU. When no jumpers are in place, it’s assumed that a serial cable (e.g. a USB serial port) is connected to J2.

• J10 - with both jumpers in place, power and reset signal will be taken from the board it self. When not present, the board assumes it’s connected to a RC2014 bus and take power and reset from there.

The RGB DAC

Originally, the design had fixed resistor values for the RGB DAC. When testing the terminal on various monitors, it was noticed that different intensity of the same colour was sometimes barely distinguishable (depending of which monitor I used). E.g. often green and bright green was clearly different, while white and bright white had basically the same brightness. I decided to replace the fixed resistors with trimmers so that the terminal can be optimally adjusted for the monitor in use. Those trimmers are a bit expensive though and if you want to save some money you can safely replace RV1, RV2 and RV3 with 390 Ohm resistors and RV4, RV5 and RV6 with 820 Ohm resistors.

• As it is, the terminal can’t display the brown colour (instead of yellow as it sometimes used to be in the good old days) and this would need some extra circuitry to generate brown instead of the current yellow. This will require an extra chip and thus board space which is bit tight for the moment.

The PCB

To be able to route all the required traces without using an [expensive] 4 layer board I reduced the trace width to 5 mills (0.127 mm). The smallest width that is commonly supported by PCB manufacturers. That allowed me to pass 2 traces between 2 legs of an IC. Something I needed to do a lot. But the end result is that I could cram 29 chips on a 10 by 20 cm PCB board using only 2 layers.

Since all components are through hole, soldering the board shouldn’t be too hard but it should probably not be your first soldering project. As mentioned, those traces are really very thin and applying too much heat for too long might damage the PCB.

I prefer to use a hot iron (mine is set to 360 C). By doing so, I can very quickly solder a leg from a part since the leg is on temperature almost immediately. In less than a second a leg is soldered while the heat doesn’t get the time to spread deeper into the component. I’ve seen recommendations to set the temperature very low (barely 290 C). That means you need to apply the heat to a leg for a long time to bring it up to temperature so that the solder starts melting. More time means there is more time to spread the heat further into the component you solder and potentially damage it. So, using a lower temperature might result in actually damaging a component IMHO. The same holds for the PCB. The longer you apply heat, the more chance you have to damage a trace. I also use solder with lead. It solders easier (and at a lower temperature than solder without lead). Solder with lead also gives a visual clue for a bad solder joint by giving a dull look (instead of a shiny solder joint).

In part 3 I’ll discuss setting up the 6845.