Geekery peak

see copyright notice. Page created 15-Jan-2009 updated 2-Nov-2019. Use the button groups above to navigate quickly around the site.

The Z80 microprocessor is central to several of the projects featured on these pages. Of course other 8-bit CPUs were available in the 1980s, including some with more "regular" instruction sets and/or easier hardware interfacing. But the Z80 was established as the go-to solution in my day job, so it made sense to extend my knowledge and experience from there to my hobby activities.

I make no apology for this page being the most geeky one on the site (so far!). I hope it's of interest to a few kindred souls, who remember the days when memory was measured in kilobytes, floppy disks greatly outnumbered hard drives, and the command-line user interface reigned supreme!

The DialFile

In 1987, I decided to do something useful with a 16-character LCD left over from the Rewbichron MSF clock project. Pocket-sized computers were starting to appear, but I had this idea for a more elegant user interface than a lilliputian keyboard. An immediate application would be to store a telephone list and address book, which would be as easy to use as the mechanically-indexed pop-up things which adorned many telephone tables. (Yes, in those days The Telephone was sufficiently large and important to have its own table!)

On one side of the box is a thumbwheel, on the other a single pushbutton (the prototype is for right-handed use, but no doubt a production model could have sported a rotatable display for left-handers). Turning the wheel scrolls the displayed text vertically (line-by-line) through the top-level items in a hierarchical list (e.g. people's names). With an item selected, a push of the button takes you to the next level, such as the person's phone number and address, which again scrolls through line-by-line in response to the thumbwheel. Lines longer than 16 characters scroll horizontally (character-by-character) to the end before moving to the next line. All these operations are bidirectional, i.e. you can move the thumbwheel the other way to scroll "left" and "up". To move back up through the hierarchy, you hold the button down for more than one second; this function auto-repeats until the top level is regained. Oh, and there's no "on-off" switch - the first press of the button switches the thing on, and after 30 seconds of inactivity it quietly goes back to sleep.

The crucial component is a smooth-running thumbwheel with bidirectional stepwise motion sensing. At the time I couldn't find anything that would do this and fit into the 16mm or so available depth, so as usual I went for the DIY approach. I found a large plastic edgewise control knob - a relic from the days when the set that stood on the Wireless Table had them - which I proceeded to mutilate by drilling out 12 regularly-spaced holes, and applying a coat of matt black paint. That bit was easy; making the CPU track the wheel's rotation was more of a challenge. The temptation was to put an IR LED above the holes with two offset photodiodes below to sense motion, but I came up with a cunning alternative that saves a lot of power and circuitry.

Because the firmware and database are in a single 32kB RAM chip, the CPU's A15 address line never goes high in normal operation. So, in a reversal of the original plan, I put two LEDs below the ring of holes, with a single photodiode above, driven by the circuit shown below (at first there wasn't quite enough vertical space for the optical devices, but I filed down their domed ends until there was!)

When the CPU needs to sense thumbwheel movement, it does a dummy memory read from address 0A000H, then another from 0C000H. These addresses make A15 go high, together with either A13 or A14, slamming a whopping great pulse from the capacitor through one or other of the LEDs. Depending on which one(s) can be "seen" through the nearest hole by the photodiode, anything from 0 to 2 nonmaskable interrupts are generated, which the firmware decodes into motion and direction.

Power drain is just 8mA (working) and 6µA (standby), so the PP3 battery lasts a very long time. The firmware and database are prepared and combined on a Z80 development system, and then loaded directly into the CMOS static RAM chip, in-situ. To do this, firstly two links are fitted to free up the buses. Then the chip is connected via a clip, ribbon cable and 28-pin header to an EPROM programmer adapted to generate RAM-compatible signals. All this was easier to arrange than it sounds, because both the development system and the EPROM programmer are also home-made!

The CLB

By 1988 I'd almost run out of things to do with Z80s, but one challenge remained - to cram a processor (fully equipped with 64kB memory), two serial I/O ports and a file-based "operating system", into a pocket-sized box. It became known as the Clever Little Box, or CLB, and provided me with a neat means of transferring files between my microprocessor systems at home and the VAX computers at my daytime workplace.

The CLB is activated by connecting its "console" port to a serial terminal set to 9600 baud. The picture shows it plugged into the back of a VT100 that I've managed to preserve in working order - it sits in my office on what used to be my parents' Television Table (see above). The Box shuts down automatically when the terminal is disconnected.

The firmware (CLOS - Clever Little Operating System) lets the terminal user maintain the filing system, and send and receive files via the "data" port at the other end of the Box. A very important feature is that the terminal can talk "through" the CLB to the data port as if the Box isn't there, instructing a connected computer to send or receive file data, then make the CLB receive or transmit that data to/from its own files.

Sizewise, the CLB has about the same footprint as the main box in the DialFile described above, but with a bit more depth. This means a PP3 battery fits in on its edge, with room alongside for three stacked circuit boards, provided no component stands taller than a DIL package. I drew heavily on the DialFile design, but this time used a crystal-controlled clock generator, because serial port baud rates were involved. The circuit boards, interconnected by quite a lot of 32swg enamelled wire, are folded concertina-wise, with the two 32kB static RAMs on the top one, as the firmware is loaded into one of these as per the DialFile. I managed to keep the entire resident firmware below 4kB, by using a skill that's all but died out since - economical code-writing. This left nearly 60kB for the file store.

I made a brave decision to implement the two serial ports using simple latches, gates and makeshift line drivers/receivers. No UART, all the coding and decoding is done in software. With a 1.6MHz system clock, and given that the ports have to be able to send and receive simultaneously (X-ON/X-OFF flow control) this turned out to be one of the hairiest pieces of Z80 coding I've ever done. But it works! And there's a nice power-saving feature, whereby the CPU stops its own clock while it's waiting for input from the terminal.

The following GIF images were created from actual photos of the VT100 screen.

CLOS responds to a small set of commands, which it lists in response to HELP (or just HE, since it accepts abbreviations. It also prompts for any missing parameters). SET and SHOW maintain boolean flags which affect how file data is imported and exported. SET CR_START, for example, makes the CLB send a carriage-return character (<CR>) to the computer at the start of each subsequent IMPORT operation.

In the directory listing below, FILES-11 veterans will notice that the files have version numbers (;n after the file type), which makes file maintenance so much easier!. The special file named CLBEDITOR.EXE contains Z80 code, which executes in response to the EDIT and PATCH commands. The working version can alter memory contents in hex or ASCII, but the planned text file editor is still "work in progress".

Shown here is an example of a file (named ESSEXSPEAK.TXT) being exported to a connected computer running the VMS operating system (its command lines start with a dollar prompt). Once a connection has been made through the CLB, a CREATE command instructs VMS to create a new file. Control-D connects the terminal back to CLOS, which sends the file data in response to EXPORT. While this is happening CLOS echoes any printable content to the terminal on a single line, which explains the mess remaining on the screen shot!

Here, a file named LOGIN.COM is imported from VMS to CLOS. To do this, a TYPE command is issued to VMS but terminated with the Control-D escape to get back to CLOS. IMPORT sends a <CR> to VMS to complete the TYPE line, and then captures the data, once again echoing it to the terminal on a single line.

top ▲