As I walked into the huge high bay that was to be my part-time office for the next couple of years, I was greeted by all manner of abandoned equipment haphazardly scattered around the room. As I later learned, this place was a graveyard for old research projects, cast aside to be later gutted for parts or forgotten entirely. This was my first day on the job as a co-op student at the Georgia Tech Engineering Experiment Station (EES, since renamed to GTRI). The engineer who gave me the orientation tour that day pointed to a dusty electronic rack in one corner of the room. Steve said my job would be to bring that old minicomputer back to life. Once running, I would operate it as directed by the radar researchers and scientists in our group. Thus began a journey that resulted in an Arctic adventure two years later.
The computer in question was a Data General (DG) mini computer. DG was founded by former Digital Equipment Corporation (DEC) employees in the 1960s. They introduced the 16-bit Nova computer in 1969 to compete with DEC’s PDP-8. I was gawking at a fully-equipped Nova 2 system which had been introduced in 1975. This machine and its accessories occupied two full racks, with an adjacent printer and a table with a terminal and pen plotter. There was little to no documentation. Just to turn it on, I had to pester engineers until I found one who could teach me the necessary front-panel switch incantation to boot it up.
Not all Novas are the same, as they were avaialble in various configurations and could also be upgraded in the field. That said, the basic specifications of this machine were as follows:
- 16-bit CPU
- 64 Kb magnetic core memory
- Floating Point Arithmetic Unit
- Ten-slot chassis
- Two 9-track Tape Drives
- Dual density
- phase-encoded or NRZI
- up to 10-1/2 in reels
- Two Diablo Systems Hard Disks, each with
- one fixed 5 MB platter
- one removeable 5 MB platter
- Paper Tape puncher / reader
- GE Terminet Quasi-Line Printer
- Nicholet Zeta Pen Plotter
- ADM-3A Terminal
At twenty years old, this was a dream come true. I had programmed a TRS-80 in high school which is a very hands-on experience. I had also programmed in Fortran using the Georgia Tech central mainframe computer, which was the complete opposite of hands-on. Enshrined behind glass walls, you handed punched cards to the operator and waited around for your printouts. The notion of having a “big” computer all to myself was both exciting and a bit scary.
Who is Fred?
Everyone fondly called this computer “Fred Nova”. The story I heard was that the system was initially procured by a researcher named Fred Dyer. But when I recently tried to track this story down, it wasn’t so clear. Back in the 1970s, these Nova mini-computers were both popular and affordable. There were quite a number of them at EES, used all around in different laboratories on different projects. You could almost say they were the IBM PC or the Raspberry Pi of the era — cheap enough to own multiple systems, and veratile enough to pass around to new projects as old ones wrapped up. I’m pretty sure that this particular Nova originated from a project called Earth Resources Data Analysis System (ERDAS). This was a NASA-sponsored project to study the decline of peach tree orchards throughout the Southeastern United States.
Switches and Blinkin’ Lights
The first hurdle I overcame was how do you boot such a computer? The TRS-80 had a power switch and it magically came to life. The campus mainframe never turned off as far as I knew. The Nova minicomputer just sat there doing nothing when you turned it on. In modern computers, we have the BIOS which can be configured to boot from different devices, and there are tools like GRand Unified Bootloader (GRUB) to select between different OS partitions. Doing the same thing on the Nova was simpler but not at all obvious. There was a short program one had to key into the computer via the front panel. One of the values in the program selected the boot device. But I quickly discovered that this model had a special option for lazy operators. You only switched in the address of the device you wanted to boot from, and toggled the Program Load switch. This loaded a short boot program from the optional boot PROM, thus saving the painstaking process of toggling in a dozen or so words.
What’s with all the switch toggling and blinking lights? Well this is the most basic way to interact with the computer, speaking its own language. The Nova family of computers had 16-bit words, and the front panel had a row of 16 toggle switches. Using these switches, you could store any value you wanted into any address, first toggling in the address into a register (indicated by lamps) followed by toggling in the data and loading it. If you are entering a program, thankfully the address register auto-incremented with each data load. The lamps showed the current address and data. While this process is tedious to the extreme, I found it really helpful in learning the computer inner workings. I also gained an deep appreciation for keyboard-based memory monitors.
One quirk of the Nova, and other machines of the era, is that the the panel and all the supporting ecosystem of documents used octal notation. This seems a strange choice for 16-bit word sizes. Indeed, by the time I encountered the Nova, most of the industry was using hexadecimal. Jumping back and forth between hex and octal was annoying, and I’m glad octal eventially fell out of favor. Hexadecimal makes more sense, given that word sizes of modern machines are almost always an integer multiple of the 4-bit hex nibbles,
Base eight is just like base ten, really — if you’re missing two fingers! – Tom Lehrer
Magnetic Core Memory
At the time, I was vaguely aware of magnetic core memory — just to the extent that it keeps its contents when power is removed. But I wondered if that property was helpful in the context of a mini-computer system, since that there were so many connected accessories. So one day I did a test. I fired up a large compilation that I knew would take a more than ten minutes. Once started, I went around to the back of the machine and yanked the big plug out of the wall. The front panel lights went out and all motors whirred down to a stop. Satisfied that it was really off, I went to lunch. Coming back an hour later, I plugged it back into the wall. To my surprise, it picked right up where it left off — comilation completed as if nothing had happened. Later, one of the engineers told me there was a small option board installed on this model which sensed power being removed, gaving the OS a few milliseconds to save a handful of CPU registers to scratchpad core memory.
At the campus mainframe, the printer was a true line printer that struck one entire line of text with one whack. This Nova’s printer was similar, but unlike anything I’ve seen before or since. It was 120 columns wide with 120 tightly-packed, individually-controlled hammers. In front of these hammers ran a long belt holding type fingers. The fingers contained a complete set of the printable characters, repeated a few times along its length. This belt was in continuous motion during operation. When printing, the printer would buffer one line of text, and then fire all the necessary hammers in sequence with the rotating belt of type fingers, each hammer striking it’s assigned letter at the precise moment that letter passed by. This isn’t exactly a line printer, but it sounded almost like one. Instead of one whack per line, there was a very quick burst of sound each line — like a stuttering swarm of angry mechanical wasps. It was a fascinating mechanism to behold and hear.
Nicholet Zeta Pen Plotter
Many of the assignments that I received from the researchers involved producing plots, and I used the plotter like that in the advertisement above — notice one feature is a starting price of less than $6000. The researchers would give me a complicated formula and / or measured experimental data, and request various plots. Quite often these programs would run for hours just to generate one plot, sometimes requiring overnight shift work. One scientist was writing a book at the time, and I made dozens of graphs and charts for him. For the next couple of decades, I would find those same graphs in various radar reference books. One plotter program they asked me to write was actually the opposite of a plotter — it was to input already printed graphs. One of the “pens” you could get was in fact a clear “bomb sight”, complete with cross-hairs. You would manually steer the pen over a desired point on the paper, line it up exactly, enter the value in user units on the termina, and press OK to digitize the point. That program turned out to be surprisingly simple. You first digitize the origin and a point along each axis, then just enter all the desired points along each curve of interest.
Most of the programming I did on this computer was in Fortran, although the EES used a preprocessor called Fortran Language Extended Control Structures ( FLECS ). FLECS took away some of the annoying aspects of Fortran by providing structured programming features, like IF-THEN-ELSE structures, DO-WHILE-UNTIL loops, and internal procedures (kind of like an inline function). But the most interesting project, the subject of this article series, was using assembly language to control custom hardware in order to record radar measurement data — in the frozen Arctic. I will begin covering that in part two.