Timesharing on the MIT Weather Radar PDP-8/IX

[bill75]

This is the story of how a surplus PDP‑8/I became the digital heart of MIT’s weather radar lab — and how a 19‑year‑old student ended up modifying the CPU and writing its timesharing system.

On summer afternoons in 1973 when a line of thunderstorms rolled in across central and eastern New England, I’d stand in the radar room on the 18th floor of building 54 on MIT’s campus in Cambridge. Lights were turned off and excitement was in the air as people huddled around the radar screens, with their iconic radial line sweeping a circle around a CRT and showing the shape and intensity of rainfall. People wondered and wagered on what the storms would do. Would highly localized and intense “cells” emerge, where and how often? Might there be hail?

Grad students from across the hall would wander in to have a look. Professors and meteorologists would come up from the 16th floor. Maybe Ed Lorentz, father of chaos theory, would stop by.

Dr. Pauline Austin would be there, principal investigator of MIT’s Weather Radar Research Project. She’d earned a PhD in physics, with a specialty in electromagnetic theory, from MIT in 1942. After contributing to the war effort at the Radiation Lab where they designed and produced military radars, she became one of the founders of radar meteorology as a scientific discipline. She was a mild-mannered woman—just as mild-mannered Clark Kent was secretly the man of steel, Polly was the mind of steel, and it was no secret.

Spiros “Speed” Geotis, my boss, would be there, project engineer renowned for his work on the development of weather radars, mentor to numerous meteorology grad students and to me. From Speed I learned how to extract what one wants to know about the world from what an imperfect instrument can directly measure, which would be crucial for me in my later career in industrial machine vision.

In a corner of the room was another radar screen replicating the same live image, and with a camera attached to record the images for later analysis. The camera had a 100 foot roll of film, and automatically advanced one frame for each rotation of the radar. The films would be processed in our darkroom, stored on shelves, and analyzed by grad students.

And standing behind everyone, across the room, was a DEC PDP-8/I, interfaced to our two weather radars. WR66 was a klystron-powered 10 cm behemoth, all vacuum tubes, with a massive 18 foot dish enclosed in the radome on the roof, perhaps the most iconic feature of the Cambridge skyline. WR73 was a magnetron-powered 5 cm, all transistor from Enterprise Electronics in Enterprise Alabama. With its 8 foot dish, WR73 was somewhat portable and would later travel to Africa and Malaysia.

The PDP-8’s job was to replace the camera setup with digital data, recorded on DECtape and machine readable for computer analysis and display. But that summer the PDP-8 would not even be powered up.

Speed had hired me in late spring that year to wire wrap TTL SSI/MSI circuit boards for a big project (GATE) that would take WR73 on a ship off the coast Africa the following summer. I was a sophomore course 6 (EE) student at MIT, looking to avoid another summer working in a department store. My only apparent qualification was that I knew how to solder. At $2.75/hour, surrounded by radars and computers, I was in nerdvana.

We had acquired the PDP-8 surplus from the Air Force before I was hired. The Air Force had welded it to the deck of a C-130 and flown it as part of their Hurricane Hunters program. It had the rugged enclosures and general feel of military equipment. DEC designed the PDP-8 to be a lab machine and accept custom interfaces to all sorts of equipment, in our case radar interface circuitry that we also had inherited from the Air Force.

The 8 was powered off because we had no software to acquire, process, record, and display radar data. Any software would have to be custom-written, in assembler, and the meteorologists and grad students weren’t programmers. We had one highly skilled hardware engineer who could write code, but he was fulltime busy on GATE, and had no time for or interest in the PDP-8. The GATE project was to use a more modern 16-bit mini, the TI-980, one of the first machines to use DRAM instead of core, but its custom interfaces were in development and would not be operational until actually arriving in Africa a year later.

One day Speed asked me if perhaps I could get the 8 to record radar data. At this point I had written probably less than a dozen computer programs in my life. I had written some code in PL/1 on 029 keypunches for a course, and been exposed to IBM 360 assembler in another course. I can’t remember whether I had yet found the now-famous PDP-1 and had maybe written some code there in ASM and Lisp.

But I was 19 and loved computers with all my heart, briefly though I had known them. So of course I said yes I could and he literally handed me the physical keys to the machine.

In subsequent posts I will describe in nerd detail:

• Our PDP-8’s specifications, options, and I/O devices

• Basic principles of radar meteorology at the dawn of the digital era

• The PDP-8 / radar interface

• What is a PDP-8/IX? How and why did it come to be?

• The timesharing system I wrote for simultaneous, real-time radar data acquisition, processing, recording, and display. Interrupt service, the process scheduler, the traffic controller, semaphores, calling conventions. I’ve got the full source code listing, so buckle up there will be details.

[granz]

Great beginning to this story. Looking forward to your continuation of this.
Thanks.

[bill75]

I’d like to post some pictures to go along with the intro, but apparently I don’t yet have permission to post images. Not sure how that works here.

[EdS]

@bill75

apparently I don’t yet have permission to post images

Hmm, I would have guessed that new users can paste a limited number of images into a post. A new user is promoted automatically when they’ve spent enough time and read enough topics, broadly speaking. I’ve bumped you up as you were close anyway.

[bill75]

In the next few posts I’ll share some photos to go along with the introductory post.

What I called a “radar screen” is technically known as a Plan Position Indicator (PPI). Weather radars have several different displays, but the PPI is the iconic radar screen that everyone looks at.

This is the WR73 PPI during action off the coast of Africa in September 1974. In radar coordinates, the angle around the circle (azimuth) is measured in degrees clockwise from due North at the top of the display. This is contrary to usual mathematics where angle is measured anticlockwise from the x axis, which would be to the right. By 1974 our PPI displays were computer-enhanced (TI-980) in real time to show 50 km range rings, rainfall intensity (properly explained later) quantized to three distinct shades, and, totally awesome in 1974, alphanumeric timestamp displayed around the outer circle.

[bill75]

Here are the upper floors and roof of building 54, the Green Building, as it was arranged in 1973. We are looking south towards Boston across the Charles River. The Weather Radar Project at MIT peaked after WWII and declined slowly over the next five decades as the field moved from research to operational practice. Well before my time the project had its own airplane. The machine shop was dismantled as soon as our machinist retired. The PDP-8 killed the darkroom. By the time Speed passed in 1993, the lab was no more. Today, after decades of renovations, 54-1815 is just a small closet. But you may still see some of our waveguides bolted to the ceilings in the new lab space, out of everyone’s way and testifying to what was.

[bill75]

Me in 1975 showing off the PDP-8. You can see the blue Air Force cabinets. That’s a high-speed paper tape reader and punch above the 8, and part of a DECtape drive on the left. The green console behind me is WR73. The amber cabinet also behind me is the TI-980 system with its IBM-compatible mag tape drives, after returning from Africa. WR66 would be off the frame on the right, opposite the PDP-8.

[bill75]

Speed on the roof under the WR66 radome.

WR73 on board the Gilliss out of the University of Miami, ready to sail to Africa.

[NoLand]

@bill75

The amber cabinet also behind me is the TI-980 system with its IBM-compatible mag tape drives

I love the artful lettering (“MIT GATE…”), which is so in contrast to thie utilitarian environment. It may tell some about the culture…

(Of course, I also love the story and am looking forward to the next installment.)

[davidb]

It seems that the Green Building also influenced computing history in another way: » MIT and GUE (or, The Annotated Lurking Horror) The Digital Antiquarian

[bill75]

The “artful lettering” was made with the strips of plastic that came with new reels of mag tape. The strips would keep the tape from accidentally unspooling when not in use. We’d end up with tons of extra strips and stick them to the front of the tape drive. The mostly obscured word below “GATE” spells “Lollipop”, our nickname for the ship because the round radome on top of the mast looked like one.

[bill75]

I’m holding in my hands the complete assembler listing of the RADAR timesharing system in its final form before the 8 was retired—the multithreading kernel in field 0, radar data acquisition and recording in field 1, display generation in field 2. All memory-resident, as it had to be. The listing is 267 pages of PAL8 assembler, including the symbol tables. I know that I wrote the entire thing using a line editor on an ASR33 Teletype, with its 10 characters/sec printer and roll of paper, but today after over fifty years writing code with EMACS and equivalent, I can’t even imagine how I did that. I guess I was young, in love with the machine, and had no choice.

Oh, and a debugger for an interrupt-driven multithread system did not exist. I’ll say more about debugging later.

(If you’re wondering how I made a 267-page listing on a Teletype, I didn’t. By then the PDP-8 had a high-speed interface to the much more capable TI-980, which had 100 DPI Gould printer/plotter.)

So let’s have a look at the hardware and software environment I was working with.

The PDP-8/I was built with DEC’s R-series Flip Chip modules, plugged into a machine wire-wrapped backplane. The modules were mostly TTL SSI digital logic. TTL (transistor-transistor logic) was the king of digital logic families back then and for many years, and Weather Radar had an excellent TTL logic lab to support creating the TI-980’s custom interfaces. I got to use the lab for hacking the PDP-8, and as an EE major the combination of coursework and absorbing the practical engineering brilliance at Weather Radar quickly gave me the skill and confidence to do so.

I learned one practical lesson the hard way when trying to read digital antenna position (azimuth and elevation) from WR73. The readings were very unreliable, and at first I tried increasingly complex software hacks to try to extract a reliable reading from an unreliable stream of inputs.

The real problem, however, was that you just can’t run TTL signals willy-nilly over 30 feet of ribbon cable, particularly in a space with as much electronic noise as the radar room. You run alternate grounds for shielding, with proper termination. The standard termination at the time was 220 ohms pulling up and 330 ohms pulling down, which looks like a mild 550 to the power supply but only 132 at high frequency, roughly matching the dynamic impedance of the alternate grounds. With no current flowing it sits at 3V, a perfect match for TTL.

The alternate grounds would only be connected on one end. With radars and computers that needed a shared ground for analog signals, you want no unnecessary connected grounds, where any current flowing would mean that the two systems disagreed on where ground is. A ground loop around the entire room was forbidden, it would be one big antenna picking up noise. You could tell you had one when 60 Hz hum appeared in the radar signal, and they were hell to find and fix.

SSI (small scale integration) refers here to the first generation of digital integrated circuits that provided simple logic gates, flip flops, and the like. That the PDP-8/I was mostly TTL SSI, and we had a great digital lab, plays an important role what I was able to do.

So the 8 was an amalgam of stuff from DEC, stuff from the Air Force, and stuff we added.

Basic stuff we had from DEC:

Memory Extension Control MC8/I with 4 fields of core, 16K 12-bit words total.

Extended Arithmetic Element (EAE) KE8/I
It is now well known that there was an undocumented but enormously useful EAE instruction to swap the AC and MQ. I discovered it one day by wondering what would happen if I OR’d MQL (7421) with MQA (7501) to get 7521, which is the hidden gem.

ASR33 Teletype, interface

High speed paper tape reader and punch.
We didn’t use the reader. One of the display generation applications punched ASCII that, when fed into an ASR38 paper tape reader, made nice two-color displays. I think “high speed” meant something like 50 characters/sec, so the 8 could finish quickly and then let the ASR38 take its time.

2 TU55 DECtape drives, TC01 controller, TC01 bus converter
The TC01 used DEC’s older, discrete transistor logic modules with 0 and -3V logic levels, and needed the bus converter to talk to the CPU. A reel of DECtape could store 184K 12-bit words, so the total mass storage available was 368K words, about 552K bytes, at tape access speeds. We had no disk or drum—these things were fragile and the Air Force was not about to fly one into hurricanes.

AD01 64-channel Analog/Digital converter
The 20 ms conversion time and need for software control was too slow for radar, so we had a separate system for that. We mostly didn’t use this, but I hooked it up to a pair of potentiometers for a version of Pong I wrote.

My sources for the above include the source code listing, DEC’s 1970 Small Computer Handbook, and Microsoft Copilot working with what I remember.

From the Air Force we got:

Tektronix 611 storage scope
Storage scopes were popular before refresh display technology was available. With the 611 I could set X and Y coordinates and write a dot there, or erase the entire display. I could make plots and write characters with a 5x7 dot matrix font I kept in memory.

Interval timer
Very simple. I could set a time interval (LIT) in units of 50 ms, and skip (SIT) or interrupt when done.

Clock
Interrupts every 125 ms. The only clock instruction that seems to have been used is 6372, which clears the interrupt. There must have been other 637x instructions, but I didn’t use them.

Priority interrupt encoder
In typical PDP-8 interrupt handlers, a skip chain would be used to determine the highest priority device that raised the interrupt. Here is one element of such a chain:

With the priority encoder, I could just read a 4-bit code indicating the device, and JMP through a table of handlers:

TC is the address of the traffic controller, explained later, for just ignoring non-existent devices. It’s a hardware error, but I’d rather ignore than crash. Lower codes are higher priority, with DECtape the highest, needing immediate service to work.

Air Force documentation said I had to read the code until two consecutive reads agreed. Perhaps they worried that the priority encoder would get into a metastable state.

Looking at this loop now, it could have been done better, with only one read per iteration.

Radar video integrator
Explained later. Need some principals of radar meteorology first.

Various switches, dials, and 7-segment displays.
In one such display I showed the percentage of time that RADAR was idle. I used some dials and the CPU switch register to select an address and display or modify its contents while the system was running, so I could check and fix things without bringing the system down during storms.

Stuff added by me:

• WR66, WR73 interface for setting and reading antenna position.
• Supervisor call interrupt, for calls to RADAR timesharing system.
• TI-980 interface for high speed data transfer.
• Magic for PDP-8/IX.

Next up, the software environment.

[oldben]

I think the PDP 8 had a better well tested IO design than modern (1970’s) micro controllers
as it did JUST what was needed, or you could build something. Micro’s tend need
more coding and bug work a rounds for the NEW programmable devices.

[bill75]

One thing I loved about the 8/I is that loop execution time could be determined by inspection, since it was just 1.5 microsecs times the number of memory cycles (except for some EAE instructions). Since I spent my career writing code that needed to run as fast as possible on a given machine, I loved machines with this property, such as the MC68000, the TI C64 VLIW DSP, and the 32-bit ARMs. With more modern highly pipelined superscalar machines with multilevel data caches you can’t predict execution time, so finding efficient loops is more trial and error. x64 CPUs are the worst for this, along with having ugly instruction sets. But the x64 is fast, and sometimes that’s all that matters. 64-bit ARM/Neon is my current favorite ASM, but loops can’t be timed by inspection.

[EdS]

(I’ve just split a couple of posts off - this is looking like a very rich personal history thread, and it would be a shame to dilute it half way through.)

[bill75]

My first task in the quest to replace photographic film with recorded digital data was to learn how to boot OS/8 from DECtape. This was a very intimate dance with the front panel switches—there was no clicking “reboot” with a mouse. The 8/I front panel switches were a delight to work with—silky smooth action, carefully laid out so one could set or clear a contiguous set of switches with a quick swipe of the fingers. Nerdvana, as I’ve written.

It was Steve, an EE undergrad a year ahead of me, who taught me how to do it. As with me, Steve’s main job was to help build the custom TI-980 interfaces that master digital architect Ken was designing for the GATE project. Steve and Speed had done preliminary setup of the PDP-8 before I arrived, getting all the peripherals hooked up, and analog radar video wired to the Air Force’s interface. I’d add the antenna position interfaces later, and it was Ken who taught me the right way to run TTL signals on a long ribbon cable (I think he first had a good laugh at my foolishness).

Steve had also written a little program on the 8 that would print out what WR66 was detecting right above Polly Austin’s house in Concord, Massachusetts. She had a tipping bucket rain gauge at the house, and the idea was to compare its measurement of rainfall rate with the radar set. The program had the side benefit of confirming that the analog 8/radar interface was working, but it only saw that one spot and didn’t record, so it was not going to replace film.

Booting from DECtape would load block 0 into memory page 7600, and start at 7600. The official TC01 boot code from DEC required loading 11 memory locations from switches:

What Steve taught me, however, required only 5 locations, but a little more dancing with the switches:

       1000       *1000
 01000 7604       CLA OSR     / SWITCH REGISTER -> AC
 01001 6766       DTLA        / DECTAPE LOAD REGISTER A
 01002 7402       HLT
	
       7754      *7754
 07754 7577      7577         / 200 WORDS
 07755 7577      7577         / TO LOCATION 7600

After loading these locations, you’d do this:

Switch Register	Action
1000	Load Address
0600	Start
	Wait for tape to rewind
1000	Load Address
0220	Start
	Wait for tape to read
7600	Load Address, Start

This works because the TC01 doesn’t care that the CPU is halted. I don’t know who came up with this method. After a while I could do the whole thing in a rapid blur of choreography, and it felt great. Actually doing this was rare, however, since magnetic core memory is nonvolatile, so this boot was only needed when the memory-resident portion of OS/8 had been corrupted.

OS/8 could be thought of as an early disc operating system—single user, interactive, with a small memory-resident kernel and most operations swapped in from a mass storage device. It was certainly best with a disc, but it worked off of DECtape. Painfully slow, of course. I don’t remember how long it took to assemble my RADAR timesharing system, but you can imagine.

After the TI-980 returned from Africa I build a high-speed parallel interface between the 8 and the 980, which did have a pair of 10 MB disc drives. I wrote an OS/8 device driver that allowed it to use a 980 disc as an OS/8 block structured device. Probably sped up assembling RADAR by a factor of ten, as long as the 980 wasn’t needed for anything else.

So I’m writing code with a line editor on a Teletype under a tape OS. It may sound awful but quite the contrary it was awesome. At the time it was nearly impossible for an undergrad to get time on a computer. You might have limited access with punch cards for a machine problem in a course, but to get on MIT’s main IBM 370, or Multics, you needed an account with money. I eventually discovered the PDP-1 and became a user, but quite frankly the atmosphere in that room was intimidating for a novice undergrad. So to have my very own PDP-8 that I could use anytime day or night, except when it was busy during storms—you get the idea.

OS/8 had Fortran II, which was useless for realtime work on custom devices. Besides, while Fortran was the most commonly used language at MIT then, it was in bad odor in the EE department. If you weren’t using a block-structured language like Algol or PL/1, or doing symbolic computation in Lisp, or were an assembly language hacker, you were a loser. (MIT did not and does not have a separate computer science department, it was and is all part of EE, course 6.)

OS/8 also had the SABR assembler, which was like PAL8 expect that it allowed you to ignore page boundaries. I never used it—I wanted complete control of memory layout.

The OS/8 debugger was called Octal Debugging Technique (ODT). I can’t remember if I ever used it, and I certainly didn’t for debugging RADAR since all OS/8 applications ran polled I/O with interrupts off. Instead I used the “get it right the first time” technique, which may sound a little arrogant but hear me out.

The very first programs I ever wrote were on punch cards for a couple of courses as a freshman. You submitted a deck of cards and picked up line printer output the next day. You had exactly six runs to get it right, and some students couldn’t even get their code to compile in six runs. If you needed to add a print statement for debugging, it cost you one run. I wasn’t going to waste any runs, so I spent considerable time understanding the language syntax and carefully hand-simulating the code before submitting my deck to be sure it was right. I hardly ever had a compiler error, but of course these were smallish programs.

It helped that I have the good fortune of having the right brain wiring. I had to work to understand physics, but code just comes naturally to me. So with my foundational years and good fortune, to this day I can write a hundred lines of C++20 and usually get it nearly correct as first typed in, and I almost never use a debugger. If code doesn’t work I propose a testable theory that explains the symptoms, and then make changes only to prove or disprove the theory. A change that makes a symptom go away is not a fix—if you don’t have a testable theory of what’s happening, you can’t be sure you’ve fixed the bug.

Still, sometimes I have to use a debugger after all. On the PDP-8 I mostly used strategically placed halt instructions and the panel lights and switches.

Next up, basic principles of radar meteorology. I’ll need a few days to write this up, so bear with me.

[larsbrinkhoff]

Wonderful writing. We have too little of this. Thanks for writing it up.

[abc123]

A big THANK YOU Bill for relating first-hand the history of this research project and your quest through Nerdvana.

And also THANK YOU to Eds for maintaining this site. I rarely login but I do check the posts from mailing - very useful.

[bill75]

(I’d like to be able to send a DM, but I think I don’t yet have a sufficient trust level. If that can be fixed great, if not I’ll be patient.)