The Zilog Z80 has turned 50

The Zilog Z80 processor, launched in 1976, has officially reached its 50th anniversary. This article explores its historical significance, technical evolution from the Intel 8008/8080, and its lasting legacy in computing history.
As of writing, the Zilog Z80 processor was officially launched 50 years ago, in July of 1976, less than 4 years after the last human had walked on the moon, decades closer to WWII than to the present day, roughly at a half way point between the Kennedy assassination and the fall of the Berlin wall, closer to the Korean war than to 9/11 which is itself an event that happened a quarter of a century ago. (Sorry…)
The processor was extremely successful, being used in many 8 bit microcomputers, including early personal computers, home & hobby computers, as well as many embedded, industrial applications.
Together with the 8080 & 8085 that it is binary compatible with, it contributed to creating a de facto hardware standard for 8 bit micros, allowing a de facto software standard of CP/M, and Microsoft BASIC.
The Z80 itself also spawned many clones and derived architectures over the years, famously including the Sharp LR35902, used in the original GameBoy. Zilog themselves eventually gave up their line of 16 and 32 bit derived architectures and returned to Z80 based microcontrollers and variants like the pipelined and higher clocked eZ80, mainly for continued use in industrial applications.
I myself am much too young to have seen the home computing side of this (ignoring the aforementioned GameBoy), but the widespread use in industrial applications means that the original Z80 is still around and in use with Zilog finally discontinuing it mere 2 years ago.
My own first encounter with the Z80 was as a late teenager, when I was browsing an electronics company catalog, surprised to find them still being sold. I designed my own little Z80 computer and convinced a school teacher to let me use the photo lab at night, so I could etch some PCBs.
As several of my former teachers got curious what I was up to, I ended up hearing a lot of interesting anecdotes about old home computers, consoles and a story about DIY wire wrap computer in a Tupperware box, running CP/M and WordStar, hooked up to a "borrowed" IBM terminal that was used to write a thesis on. Over time I ended up being gifted a number of old chips from dusty drawers that made it into my own DIY project, including a bunch of MCS-85 parts, several Z80s, 8085s, 6502s and 6522s.
The whole thing sure taught me a number of interesting lessons about systems engineering and some unexpected ones (reliable power-on reset is surprisingly hard; writing a linker is a lot harder than writing an assembler, writing a compiler is something you can actually do).
Anyway, that is my claim to being allowed to reminisce about the Z80. While I originally wanted to limit myself to some technical details based on my own experience, comparing the Z80 with the 8080 that it was derived from, I ended up diving down a rabbit hole of the Computer History Museums oral history panel, where the people involved recalled even more anecdotes about the development of those chips. The whole "I'll try to write a blog post (again)" idea quickly ballooned in scope.
Once upon a time, the Computer Terminal Corporation (CTC) built a new, programmable terminal, the Datapoint 2200, sporting an 8 bit processor constructed from individual TTL chips. Intel was supplying CTC with shift registers and memory chips at the time.
The idea was floated to replace parts of TTL cemetery with custom ICs, eventually it was considered to try and get the entire 8 bit CPU on a single chip. Two different companies were ultimately contracted for this task: Texas Instruments and Intel.
Neither company finished their design in time. When Intel had the chip ready, originally named 1201 based on a systematic naming convention, CTC were already selling terminals based on the TTL design.
Engineers at CTC were also unsatisfied with the performance of the chips and they had already made changes to the architecture for the next generation of the terminal anyway.
While TI ultimately canned their design, Intel went ahead and successfully commercialized their version as the 8008 (like the 4004, renamed by marketing).
___ ___
-9V ---|1 |_| 18|<- IRQ
AD7 <->|2 17|<- READY
AD6 <->|3 16|<- CLK1
AD5 <->|4 15|<- CLK2
AD4 <->|5 14|-> SYNC
AD3 <->|6 13|-> S0 __
AD2 <->|7 12|-> S1 > State
AD1 <->|8 11|-> S2 __|
AD0 <->|9 10|-- +5V
|_________|
The 8008 has 7 registers: A, B, C, D, E, H, L. Where A is the designated accumulator, the others can be used as operands or scratch. As the name might imply, H and L together form the High and Low part of a memory pointer. Accessing memory is done through an 8th pseudo register M, representing the memory byte that HL points to.
The processor internally keeps track of ALU state (Cary, Parity, Zero, Sign) in a few flag bits on which it can perform conditional jumps (including call and return).
The program counter PC is pretty much never visible directly. There are dedicated function call & return instructions, but the processor uses an internal return address stack that is 8 levels deep. The reason for this was that the Datapoint 2200 was originally supposed to use serial memory, a call stack in memory was considered to end up a performance bottle neck.
Memory addresses are 14 bits wide, there is a separate I/O address space with a total of 32 I/O ports (the addresses are always immediate and bit-stuffed into the opcode).
For interrupt handling, there is a special "restart" instruction that essentially calls into 1 of 8 slots (0x00, 0x08, 0x10, 0x18, ..., 0x38) at the beginning of the address space. The slot index is bit-stuffed into the RST opcode itself. When an interrupt occurs, the processor signals to the periphery that it got the hint and then blindly executes the current contents of the data bus that better be an RST instruction.
From there, it gets a bit tricky. The CPU does not have a general purpose stack that it can safe registers to, all memory access needs HL, but you don't want to clobber HL in the interrupt handler. The intended way to solve this was through external latches on the I/O bus, serving as scratch registers.
All in all, the architecture is fairly simplistic, requiring about 3500 transistors and used a DIP18 package. Address and data were multiplexed, requiring external latching. Internal decode/execution state was exposed that needed to be decoded to drive latches and figure out what the processor is attempting to do (read from or write to memory, or the I/O bus).
The processor needed two phase-shifted clock signals (it ran at 500kHz), a +5V positive supply and -9V negative supply.
The shortcomings of the Datapoint 2200 derived 8008 architecture were known during development, and in typical engineering fashion, before development was even wrapped up, ideas were thrown around for an improved architecture.
Federico Faggin, who was brought over from the 4004 project, was pushing to start work on an improved version, but management insisted to first see how the market would react to their two microprocessors. Competitors eventually announced their own 8 bit designs in the making and the delays ended up costing Intel a total of 9 months of their lead time.
Even before the project was finally approved, Federico Faggin got approval to hire Masatoshi Shima away from Busicom to work on the 8080 design. In many ways similar to how CTC had a hand in the development of the 8008, Busicom was involved in the development of the 4004, originally wanting a set of custom chips for their calculators.
Criticism and feedback from potential customers that the 8008 was demonstrated to, also influenced the design of the 8080, and it was decided early on to set aside binary compatibility.
+----------+----------+
| A | F |
+----------+----------+
| B | C |
+----------+----------+
| D | E |
+----------+----------+
| H | L |
+----------+----------+
| SP |
+---------------------+
| PC |
+---------------------+
The 8080 has in essence the same register set as the 8008, but it replaces the internal return address stack with an external one that lives in memory and is accessed via a stack pointer (SP).
Source: Hacker News















