The University of Arizona

The Illinois Zephyr

The Zephyr computer was modeled after the central processor architecture of the CDC 6000 series. It was designed and built by the University of Illinois in 1988 to run server software of the PLATO system. This page describes the Zephyr and how it differed from a CDC 6000.

Downloadable Documentation

Zephyr Hardware Manual, second edition
Lippold Haken and Sarah Williams
CERL, University of Illinois, 1989
7 MB PDF file with small block diagram

Full-size block diagram, 33 × 22 inches
2 MB GIF or PDF file

Background

The CDC 6000 Architecture

In the 1960s Seymour Cray designed the model 6600 computer for Control Data Corporation (CDC). This was the first supercomputer and arguably the first RISC design. User code ran in the central processor unit (CPU), a word-based 60-bit machine with an 18-bit address space. Each 60-bit word held ten 6-bit (upper case) characters.

Most of the operating system ran in ten peripheral processor units (PPUs) which were 12-bit general-purpose computers with 4096 words of private memory and with shared access to I/O channels and central memory. The PPUs shared circuitry in a round-robin fashion foreshadowing today's hyperthreading processors.

CDC produced other compatible machines, both slower and faster, into the 1980s. These included dual-CPU systems, systems with more or fewer PPUs, and systems with additional COBOL-oriented CPU instructions. The CDC 6000 architecture encompasses this family of designs.

The PLATO System

PLATO was an early computer-based teaching system. Developed in the Computer Education Research Laboratory at the University of Illinois, PLATO used custom software running on CDC equipment to serve thousands of remote terminals simultaneously. The custom terminals included several novel features for the time such as a touch-sensitive bit-mapped plasma display screen.

PLATO supported electronic mail, interactive chatting, multiplayer games, and other pioneering features. The PLATO trademark was eventually transferred to CDC, with Illinois continuing development under the NovaNet name. NovaNet is now part of Pearson Digital.

The Zephyr

In the 1980s, CDC began moving to a new and incompatible processor architecture. The PLATO project had a large investment in software that required a CDC 6000 CPU architecture. CERL decided to build their own CDC-compatible processor. Because they ran their own custom software, they did not need a CDC software license for this custom system.

A Zephyr CPU was modeled after the CDC 6000 design. Each CPU had 256K words of memory (262K in CDC terminology), half of which was accessible to external front-end processors. Bulk memory was analogous to CDC's Extended Core Storage (ECS) and was shared by up to four CPUs.

Zephyr CPU, open for maintenance
In this photograph, Lippold Haken is debugging the wirewrapping of one of the CPU boards. A PLATO terminal can be seen beside the Zephyr CPU. (Photo by Sarah Williams)

Zephyr Differences

Hardware Design

The original CDC 6000 series used discrete semiconductor components: transistors, resistors, and diodes. Subsequent compatible Cyber 70 and 170 computers used integrated circuits. All operations were implemented in hardware.

The Zephyr was implemented on several large wire-wrapped boards using ECL logic chips. Air-cooled boards mounted in a mainframe pivoted outward for access in a manner reminiscent of the CDC mainframes.

On the Zephyr, instructions were implemented by 256 words of 80-bit microcode. Some floating-point operations were incompletely implemented and would trap if presented with rare abnormal operands. These traps were caught by the operating system and the repaired in a manner transparent to the programmer.

Peripheral Processors

The Zephyr implemented a CDC-compatible CPU but made no attempt to model the peripheral processors. I/O and other operating system functions were handled by the CPU running in monitor mode. Sun workstations connected to the Zephyr functioned as front end processors.

Execution Modes

A CDC 6000 CPU executed code in problem mode or monitor mode. Problem mode was for unprivileged user code and monitor mode was for the operating system. On the original 6000 architecture the only difference was in the details of an exchange jump (hardware context switch) instruction. On the Zephyr, there were extra registers and extra instructions available in monitor mode, but there were also some added restrictions.

Registers

The standard CDC architecture defined eight 18-bit A registers, eight 18-bit B registers, and eight 60-bit X registers. The Zephyr added several more registers which were mostly restricted to use in monitor mode: eight T registers that swapped with the X registers on a context switch; six P registers associated with hardware breakpoints; and eight C registers used to remember additional state for help in debugging the microcode.

Problem Mode Compatibility

In problem mode, the Zephyr was a faithful implementation of Seymour Cray's CPU instruction set with a few minor variations. Two new instructions were added:

016jk  XXj Xj+Tk  add monitor register Tk into Xj
017jk  XXj Xj,K   add memory word CM[K] into Xj
The 016 instruction provided a way to read one of the new T registers that were otherwise restricted to monitor mode.

The 017 instruction provided a way to load a word from memory without altering any of the A registers as was required on a standard CDC processor. Because it used T registers as scratch space, this instruction was allowed only in problem mode.

Monitor Mode Features

In monitor mode, more differences were apparent. New instructions accessed the Zephyr's additional registers:

001jk  XCj Xk     copy register Xk into Cj
002jk  XXj Ck     copy register Ck into Xj
003jk  XPj Xk     copy register Xk into Pj (set breakpoint)
004jk  XXj Pk     copy register Pk into Xj
005jk  XTj Xk     copy register Xk into Tj
006jk  XXj Tk     copy register Tk into Xj

In program mode, these instructions functioned as program stop (00) instructions.

Floating point addition, subtraction, and division were prohibited in monitor mode because the microcode used T registers for scratch space. Floating-point multiplication was allowed; the Zephyr devoted an entire circuit board to multiplication.

Exchange Jump

An exchange jump was a hardware context switch that exchanged the working registers with a set of memory locations, an exchange package. These registers included the program counter, so a jump was effected. On the original 6600, only a peripheral processor could initiate an exchange jump, but an optional central exchange jump instruction was soon added and became ubiquitous. In monitor mode, the running program specified the address of the exchange package, but in problem mode, the address was taken from a monitor address register loaded by the previous exchange jump.

Exchange jumps functioned very differently on the Zephyr. Exchange packages were only three words long and began with an XJ (exchange jump) instruction code. Exchange packages included the program counter but no A, B, or X registers. Preservation of other registers relied on software.

In problem mode, an exchange jump swapped the X and T registers and moved A6 and A7 to T4 and T5. The program counter and a few other registers were loaded from an exchange package found at a preset location. In monitor mode, the three words beginning with the XJ instruction were used as the exchange package. A6 and A7 were restored from T4 and T5, and the X and T registers were swapped back.

More Information

Many of these sites have long lists of additional links:

Lippold Haken discussed the Zephyr in a 1991 episode of High Tech Heroes.

For more technical details about the Zephyr, download the documentation linked at the top of this page.

Acknowledgements

Lippold Haken generously sent a copy of the Zephyr Hardware Manual and granted permission to scan and distribute copies. He also supplied the photograph and other historical details.