Timesharing on the MIT Weather Radar PDP-8/IX

[NoLand]

Slightly off-topic: Ed Fredkin wrote the World Oceanographic Display System for the PDP-1 (described in the first DECUS Conference Proceedings, 1962, p. 31), which apparently had some kind of a GUI (as in data point selection and parameter manipulation via light-pen) and also the probably related Vortex Ocean Model (written entirely in DECAL, described at p.33, ibidem).
I wonder, given your knowledge of the field and familiarity with Ed Fredkin, do you know anything about this?

(Note: This should probably become a thread of its own, if there’s a more extensive answer.)

[bill75]

In an earlier post I mentioned the paper I gave at the 17th conference on radar meteorology in 1976. Here’s a little reminder of what it was like to prepare a paper for publication back then.

We wrote the copy by hand on yellow notepad paper, which then was typed up on an IBM Selectric by our secretary. The Selectric was a fabulous typewriter. It could handle even the fastest typers, and had a great feel under the fingers. Its typeball could be exchanged for different fonts, including the Greek alphabet that scientists and mathematicians frequently used.

We had photos, and both hand-drawn and computer-generated graphs and charts. All of this source material—typed copy, photos, charts—would be given to our draftsman, a full-time processional position employed by Weather Radar. He would redraw the hand-drawn charts for scientific publication with the tools and skills of his trade. He would prepare camera-ready galleys by cutting and pasting everything onto stock as specified by the publisher. Of course cutting was done with a knife, and pasting with glue. I guess that’s where the terms “cut” and “paste” come from.

[bill75]

@NoLand

do you know anything about this

Sorry, no. I met Fredkin 16 years later, in 1978, when his interests were all about Digital Physics.

[bill75]

Gate bumper sticker:

Needed proof of vaccination to travel to Dakar:

My pass authorizing my presence in the port of Dakar (they got my name wrong):

[bill75]

Correction (this is very minor but it’s bothering me): The sine/cosine chip set does not “look up interpolation coefficients from low-order bits”. It looks up both sin/cos and interpolation coefficients from the same high order bits, and then uses the low order bits with the coefficients to do the interpolation. The 980 didn’t do the interpolate, it got sin/cos from the chip set.

Sine and cosine values, which are in the range [-1.0 .. 1.0], can be represented as 16-bit fixed point values with the binary point just to the right of the sign bit. This format covers the range [-1.0 .. 1.0). 1.0 itself could not be represented, the highest value is around 0.99997. It’s also possible to give up one bit of precision to allow 1.0 to be represented. I don’t remember what we did.

[bill75]

When I landed in Dakar the Gillis was in port for replenishment and some crew changes, after a six-week stint on station in the Atlantic. I was scheduled to join Speed and Ken, who had been on board since Maimi, for another six-weeks at sea, replacing Steve as junior radar operator. But the Gillis was in trouble.

The Gillis’s main propulsion system consisted of a huge electric motor driving a screw propeller, and two equally huge diesel engines generating electricity for the motor. It’s a very flexible and efficient design. The electric motor could be controlled over a wide range of torque and RPM, and reversed electronically and instantly. It had max torque at low RPM, just where it’s needed. The diesel engines could be run at a constant, ideal RPM.

A cooling pipe in the motor had broken, flooding it with sea water. Everyone understood that sea water is really bad for electric motors; no one knew what to do about it.

Somehow someone managed to make contact with the Guy. The Guy was quiet and mostly kept to himself, so I didn’t get to know him all that well. He apparently travelled the world fixing big problems. He didn’t sleep much, just took 20-minute naps in a chair throughout the day. He was the Guy you called when your huge electric motor is flooded with sea water.

The Guy decided that the motor first needed to be dried out by heating the coil to enhance evaporation, which otherwise was hindered by the humid summertime tropical air. What he planned to do about the salt and gunk that would be left behind after the water evaporated, I don’t recall. He borrowed a spare 5 volt, 10 amp power supply from us, to use to heat the coil (Weather Radar travelled with spares for everything of course, except apparently gears).

Five volts is not enough to make the motor do anything motor-like, but it did what the Guy wanted. I don’t recall how long he kept the current running, but I’d guess it was maybe 48 hours. Then there was a big discussion and lots of concern about what would happen when he shut the power off. A coil that large stores lots of energy when current is flowing. The voltage across an ideal coil is proportional to the rate of change of current:

(A real coil is like an ideal coil with a resistor in series.) So when you shut off the power, dI/dt is huge and so V is huge. You get very high voltage ready to push lots of stored energy. This could easily kill someone.

Note that when the power is shut off dI/dt is negative so V is negative. The voltage is reverse of what was applied. With smaller coils the stored energy can be drained off with a robust diode across the coil that, oversimplifying a little, is open circuit when voltage is applied and closed circuit when it reverses. I think we gathered up all the robustest diodes we could find. If they were all destroyed by the coil when the power was shut off, at least they’d drain off some energy before bursting into flames.

All in all we were stuck in Dakar for about two dreary weeks. But then the ship was declared seaworthy and we headed out to our station, a buoy that we were to stay within 3 km of about 800 miles off the coast. It would take a couple of days to get there.

The Gillis was just under 200 feet, on the small side for GATE ships. It was a university research vessel, not a navy ship, so protocol and discipline were relaxed (very relaxed it turned out). Weather Radar was not the only scientific crew on board—one crew launched ballons, another dropped gizmos into the sea to measure salinity and temperature at various depths.

On the first day out the Captain invited us to lunch with him in the officer’s mess. Suddenly everyone noticed a change in the ship’s background noise and sense of motion. Soon the chief engineer emerged and announced to the Captain that the engines had stopped and he didn’t know why. All I could think of was Scotty on the bridge of the Enterprise giving Kirk the same announcement.

I never found out what the problem was, but they got it fixed and we continued on. Seasickness for me was a sudden affair. One minute I’m convincing myself that I’m just fine, that the fancy prescription motion sickness pills will keep me safe, and the next minute I’m hanging over the rail. Lasted 48 hours, then I’m just fine.

On station the radar operator’s job was simple. Monitor the PPI for weather and be prepared to enter record commands into the system console ASR-38. If there wasn’t much activity, record every hour. Recording intervals would be reduced to half-hour or 15 minutes depending on weather activity and the operator’s judgement. When a tape fills up label it, store it, and load a new one. And whatever you do, DO NOT in any way mess with Ken’s program running on the TI-980.

I had the graveyard shift, 20:00 to 08:00. Twelve hours, easy duty. Speed and Ken split the daylight shifts.

The first night on duty I had to switch from a normal wake-sleep cycle to the reverse. So I decided to have myself a cup of coffee. I was 20 and this was going to be my first ever cup of coffee. This was not going to be Disney cruise coffee, this was what the ship’s crew drank. I drank it black. That was what might be called a rookie mistake. For the rest of my shift I could do nothing but lie on the steel deck behind the computer racks and groan.

But the rest of my time at sea was excellent. The stars at night 800 miles from anywhere were stunning. The Galilean moons of Jupiter could be seen easily with binoculars. There was a party every night of clear weather out on the fantail. Discipline was, as I said, relaxed. It was 1974. Use your imagination.

[bill75]

Here is some info on the Gillis. Page 1 is a short history, and page 2 is ship specs, including the propulsion system:

[bill75]

Here is a block diagram and microcode instruction set summary for Ken’s integrator. All instructions are 32 bits and execute in one clock. The clock frequency was chosen to synchronize with round-trip speed of light time for 250-meter range bins. For example with a clock period of 333 ns, five instructions would be executed for each 250m. I don’t recall the actual clock period and number instructions per 250m.

As you can see in the block diagram, all data paths were 16 bits wide. There were four 512 x 16-bit shift registers for holding computed quantities associated with range bins. There was a 16 x 16-bit register file for holding scalar quantities. The register file output passed through bi-directional shift registers.

The instruction word specified a 4-bit opcode, two 4-bit source operands, a 5-bit destination operand, some control bits, and a 16-bit immediate operand. This was typical of microcode—wide instructions with fields to control all of the data path options. Many combinations of fields made no sense, but the idea is to keep all options open, avoid complex decode logic, and execute one instruction per clock.

The 4-bit source operands allowed selection among four inputs, or the negative of an input, or for some inputs the absolute value, or the constants 0, 1, or -1. Negation was done with exclusive OR gates to invert the bits, and with injection of a carry into the LSB of the adder to get complement and increment. One of the source B inputs, labelled RADAR in the diagram, is the digitized raw radar signal.

Both Ken and I wrote microcode for the integrator. None survives.

[bill75]

To satisfy the GATE contract, Weather Radar needed a 16-bit minicomputer system with two mag tape drives for recording, two disc drives to support a DOS, and various peripherals like the ASR-38 console terminal. The DOS would provide an interactive single-user environment with basic tools for software development—editor, assembler, linker, debugger, Fortran, file system. Such a system could be purchased essentially turnkey from a vendor, with the vendor supplying interface cards and device drivers for its proprietary DOS. We could then focus on developing our custom, state-of-the-art digital sweep integrator.

But like with the stable platform, we felt that we didn’t have the budget for the extravagance of a turnkey system, and so we made the second consequential decision—we’d buy all the components a la carte and design our own interface cards for everything, not only saving money but giving us control over how everything behaved. We had 18 months to get ready—what could go wrong?

The TI-980 seemed like a great choice, and in many ways it was. Compared to PDP-11s at that time it was inexpensive, compact, fast, and rugged. We particularly liked the power supply specs—it seemed solid enough for use on a ship where AC power was expected to be noisy. It had a 4 MHz clock, and used the first generation of 1 kb DRAMs instead of core. Memory cycle time was three clocks, 750 ns. Battery backup kept the DRAMs non-volatile.

Compared to the PDP-11, the instruction set architecture was another matter. The 11 was a masterpiece of enormous influence on the trajectory of the industry. The 980 was apparently designed by people who had found themselves with the ability to fabricate a CPU with a bank of eight registers, but couldn’t quite move beyond the single-accumulator mindset. So the registers were all special purpose:

The instruction set was as non-orthogonal as you’d expect with all CPU registers dedicated to particular purposes. Memory was word-addressed, with oddball byte instructions that used specific combinations of the registers. I found it quite an improvement over the PDP-8, in performance if not elegance, but I was young and hadn’t yet seen enough to realize just how uninspired the instruction set was.

TI provided a DOS with the basic software development tools needed, but of course it couldn’t run until at least the disc interface was ready. And since it’s a custom interface, we’d need a custom device driver for the DOS. With no software development tools available yet, writing that driver would be a problem. So we’d get around to the DOS later. We needed to focus on designing and testing the integrator that would be the heart of the system and keep MIT in the forefront of digital radar development. Second in importance was the mag tape interface. CPU, integrator, and mag tape were the bare minimum needed to fulfil the GATE contract.

Who needs an operating system, right? Who needs an editor and assembler? Ken didn’t.

Ken needed to write code to help test the integrator and the other interfaces. The diagnostic code was pretty simple, and he created a method of bare-machine software development that would make do until the DOS came online. He wrote a simple loader that could read hexadecimal addresses and data typed in on the ASR-38. The loader itself was initially loaded from the front panel switches, and stayed resident in the battery-backed memory. If memory was accidentally overwritten by errant code, the loader would be reentered from the switches.

The ASR-38 had a built-in paper tape reader and punch. Human-readable hex machine language programs could be stored on a collection of paper tapes and reloaded as needed. If a bug might have overwritten even one word of memory, everything would be reloaded because you could no longer trust any computation.

He’d write a program in an assembly-like language on paper, hand-assemble it, and type in hex machine language while simultaneously making a paper tape copy. Editing the program to add functionality or fix bugs was painful, however. If you needed to insert instructions into existing code, you had two choices. You could either re-hand-assemble and retype the entire thing, or you could install a patch paper tape—replace the instruction at the insertion point with a branch to a location containing the new and replaced instructions, and a branch back to the original code. Here is the 980 instruction set summary Ken created for writing machine language.

With heroic effort this was workable for small programs. Sooner or later, though, small programs became all programs. As all engineers find out, everything takes longer than you expect. The disc interface was eventually finished and working, but there was no time for DOS. Ken planned to continue work while on route from Maimi to Dakar, but seasickness and the gear panic spoiled those plans. So we arrived for GATE will all the code on various bundles of paper tape, patched up with months of additions and bug fixes. Reloading the code if necessary took a long time and lots of care. It did the job, though.

It’s no surprise then that Ken made it clear that under no circumstances was anyone to mess with the code running on the TI-980. Speed certainly wasn’t going to mess with it. Ken’s admonition was directed at me, and for good reason.

[bill75]

After the seasickness and coffee troubles, I settled into an easy and delightful routine on the Gillis. I was logging 84 hours/week at time and a half overtime, with no expenses. The international scientific crews were loads of fun, particularly in the middle of the night. But I was itching to contribute something more meaningful than typing commands to record radar data at various intervals.

The only thing I could really contribute was software, and one day I hit upon something that I could confidently do and that would, it seemed to me, be of some benefit. The disc drives were functional but without software to run them. I would write a simple disc file system that would allow us to write selected portions of memory, or all of memory, to disc, and retrieve them as needed. There would be no file names or directory structure, just hexadecimal addresses. It could supplement, or better yet replace, the cumbersome and awkward paper tape system.

I tried to persuade Ken that this was a worthy effort, but he flatly rejected it. In hindsight after a long career in software development, he was right. We had, after much trouble, a working system. It was doing what was needed, even if patched together in violation of every rule and lesson of proper software development. The risks of running code written by a 20-year-old undergrad on such a fragile system were plainly unacceptable. Any trouble would be Ken’s responsibility, no matter who wrote the code.

I didn’t see it that way at the time. The paper tape system was absurd with a working disc drive. I was absolutely confident that I could write and run the code without breaking anything. It would be like all those meticulously crafted machine problems I ran in school on punch cards. In hindsight after a long career in software development, I still believe I could have done it with no trouble. But that didn’t make it a good idea.

Regardless, I wrote the code at night, when Speed and Ken were asleep. I kept it secret. I followed Ken’s bare-machine development method and produced a machine language paper tape. At this point, unfortunately, my memory becomes fuzzy and none of the code survives. I don’t recall if I actually loaded and ran it for testing. I certainly could have. The code sat in an unused section of memory and Ken’s loader could be executed from the console. I was young, confident, and itching to contribute. All I know for certain is that the code was not used, and that I didn’t break anything while writing it.

The MIT Weather Radar contribution to GATE was ultimately successful. We returned home with a large cache of IBM-compatible mag tapes, providing data for study by meteorologists for years to come. Eventually the tapes were shipped to some national archive.

WR73 and the TI-980 system returned to the 18th floor. Ken got the TI DOS working while I continued my work on the PDP-8. My RDADR system was more capable than the 980 for a while, but that wouldn’t last forever—the 980 was much faster, had more memory (and a flat address space), better tape storage, and Ken’s world-class integrator.

Bringing up TI DOS was Ken’s last act at Weather Radar. I took over all systems programming on the 980, and almost all applications programming. Alan replaced Ken as master hardware architect. Ed joined us as an undergraduate researcher.

Using everything I’d learned writing a timesharing system for the PDP-8, I completely replaced the TI DOS with a general-purpose timesharing system that could support software development, analysis and display applications, and real-time recording. We had several terminals around the lab where people could use the system for whatever they needed. I don’t recall much about that system, and no code survives. One thing I do recall is that the low-level memory resident code (interrupt handlers, multi-thread kernel) was written in assembler, while the higher-level code swapped in from disc as needed (file system, command interpreter) was written in Fortran.

By this time I had seen Emacs and vowed to never use a line editor again. Thanks to Alan we had a number of display terminals interfaced to the 980—Hazeltine 1500s, VT52s, and one of Alan’s own design. I wrote an editor that was as close to Emacs as I could make it, entirely in assembly language. It is the only TI-980 code that survives—I have the complete 72-page listing, which is how I know what terminals we had.

My editor used the gap-buffer design that I think was, and maybe still is, common practice. One large buffer with no internal structure, every byte used for text. All text before the insertion point contiguous at the beginning of the buffer, all text after the insertion point contiguous at the end of the buffer, and a gap in the middle. Almost all editing operations happen at or near the insertion point and are O(1) operations. Rarely does an operation need to work across the gap. Someone had mentioned the gap concept to me in passing, and I immediately recognized its advantages.

The editing and display update operations were completely independent—the edit operations did not inform display update about what changes were made, and display update didn’t ask. No edit-display communication, no edit-display bugs.

With 980 timesharing in place, the PDP-8 was gradually retired. I can see from the RADAR source listing that it was still in use in January 1977, but it wouldn’t last long after that. I don’t know what happened to the machine. I could have had it if I wanted, and sometimes I regret not taking it, but hauling it around from apartment to houses over decades would have been crazy.

I have one more thing I’d like to write about RADAR, and then conclude this history with an epilog. If folks are interested in ongoing discussions after that, I’m happy to participate. Questions and comments are welcome at any time.

[larsbrinkhoff]

I - and I’m sure, Finseth - would be interested in that Emacs listing. I’m curious about the timeline here; about when did you write your TI-980 Emacs? In the late 1970s there were only a few, so it seems to me yours must have been one among the first. E.g. Multics Emacs was started in March 1978.

Spoiler alert? I think this is a good place to point to Bill’s
E8 Emacs editor for OS/8: E8: Home

[bill75]

I can scan and post the listing. I don’t know the exact date, but it couldn’t be later than 1978. Due to my vow not to use line editors, I’ve written three Emacs style: TI-980, Z80, and the recent PDP-8 you mentioned.

[bill75]

I also have the Z80 listing, date July 1981. That’s the date on the documentation but it must have been written earlier than that, 1980 would be my guess

[bill75]

I want to describe RADAR’s character I/O system, because it follows a very straightforward 1970’s style that illustrates how RADAR handles process synchronization. I learned Dijkstra’s P and V operations on counting semaphores in coursework, and implemented them exactly as he described. They are the only process synchronization method used in RADAR, other then just shutting interrupts off for a mutex.

Consider a resource that provides a sequence of discrete items, for example characters typed or printed. A counting semaphore has a counter and a process queue. The counter indicates the number of items that are immediately available to a process, without being blocked waiting for a slow device. The counter can have any integer value. If the value is negative, for example -n, it means that n processes have claimed future items that are not yet available, and those n processes are waiting on the queue. Think of a negative count as being like a negative balance in a bank account, a claim on future deposits. In RADAR, all counts are >= -1—processes could share semaphores, but they don’t need to.

The P operation claims an item and decrements the count. If the count was > 0 an item is immediately available and the process continues execution. If it was <= 0 no item is available and the process is scheduled on the queue and blocked. P operations are only executed by processes.

The V operation releases an item and increments the count. If the count was < 0, a process is removed from the queue and scheduled on the ready list. V operations can be executed by processes and interrupt handlers.

RADAR supports two TTYs and a paper tape punch—three character output devices and two character input devices. Each character I/O device has a semaphore and a FIFO implemented by a 20-character ring buffer. The resource items being counted by the semaphore are slots in the ring buffers. This allows significant parallel operation of the device and the CPU that produces or consumes characters, keeping both busy.

Consider, for example, a process that intermittently produces bursts of characters. A burst goes in the ring buffer so the process doesn’t get blocked waiting for the printer. The printer can print from the buffer at its full speed while the next burst is being computed.

On the input side, lots of characters can be typed without loss even if no process is yet ready to receive them. They go in the ring buffer for retrieval when the process is ready.

Here is what the output buffer and semaphore would look like with five characters in the ring. The ring has an associated pre-increment read pointer, post-increment write pointer, and an ISZ count to determine if the ring is empty. Note that the semaphore count is 15 because 15 ring slots are available. Octal addresses in memory for TTY1 are given so you can correlate the data structures with the source code listing.

Here are flowcharts for printer interrupt handlers and the process character write subroutine. Octal addresses are for TTY1, although most of the code is shared among all printers. Note that there is no need to explicitly test for buffer full—the P operation blocks the process until a ring slot is available. If a character is to be printed, the ring is empty, and the printer is finished with the last character, it is printed immediately and not placed in the ring.

Here is what the input buffer and semaphore would look like with five characters in the ring. The ISZ counter is used to determine if the ring is full. Note that the semaphore count is 5 because 5 characters are available.

Here are flowcharts for keyboard interrupt handlers and the process character read subroutine. Note that if a character interrupt occurs and the ring is full, the character is lost.

Devices like the integrator also use semaphores. Since there is only one item for the integrator, the semaphore count is -1, 0, or +1.

[larsbrinkhoff]

@bill75

it follows a very straightforward 1970’s style

Having typed almost 2000 lines now, I can confirm the coding style is indeed very clear and straightforward. I appreciate this, having seen a lot of code that is either too clever for its own good, or too complex for doing what is really a simple task.

[bill75]

@larsbrinkhoff

I - and I’m sure, Finseth - would be interested in that Emacs listing.

Here it is. The first page was crinkled, the rest are good.

[bill75]

Epilog—PDP-8 Timesharing at Bowdoin College, 2014

Sometime around 2009 I felt the urge to pass along to the next generation things I’d learned over the years. I found that Bowdoin College was the closest school that had a computer science department, and better yet a RoboCup team (competitive soccer-playing humanoid robots). There was a significant vision component to the effort, and I used my industry experience to convince the professor who led the team to talk to me (the MIT brand also opens doors). He told me about a significant problem they had with code that was important for distinguishing the ball, goalposts, field, and other robots, but running much too slow. It didn’t take me long to identify the problem—extremely poor data cache hit rate, easily fixed by just rearranging the indices into a 3D table. After that I was in for good.

In 2011 he asked me if I wanted to teach a course, and that I could teach whatever I wanted. I felt that one of the holes in the CS curriculum was computer architecture. Academic CS in liberal arts schools does a good job with theory, but kids would graduate without much understanding of what the machine was actually doing, even to the extent of not knowing what a data cache does, or what twos complement means. There was a course in the catalog called Computer Organization, which hadn’t been taught in years, so I revived it with my own curriculum.

They made me an adjunct lecturer, the lowest possible academic rank, which was fine with me. I was doing it as a volunteer, and just donated to charity what they paid me. Normally they don’t let people without PhD’s teach, but they made an exception. I taught the class in 2012 and again in 2014.

I decided that the way to give kids some real intuition for computer architecture was to make them write assembly language. The machine I chose to start with was the PDP-8. I wanted to ease into it with the simplest useful stored program machine of all time, and I had (and have) a great PDP-8/I simulator, a desktop app with fully functioning lights and switches. After four machine problems on the 8, we switched to 32-bit ARM assembler, a beautiful, then-state-of-the-art RISC architecture.

Quoting from machine problem 1, “you will explore the fundamental stored program concepts of addressable memory, machine state, instruction set, and addressing modes.” I gave the kids an assembly language program to bounce back and forth a light in the AC, and the assignment was to translate it into octal machine language, load it with the switches, and run it. Everyone should see machine language once. Not more than once, mind you, but once.

In machine problems 2 and 3 we explored assembly language, polled I/O, and extended precision twos-complement arithmetic. In the 2012 course MP4 was all about interrupts and exceptions. We did interrupt-driven character I/O, reminiscent of the stuff I posted about it for RADAR.

In the 2014 course, we went all out and did timesharing. The objective was to write a multi-threading kernel and use it to let a few independent apps share the CPU, including the extended precision arithmetic code from MP3. I wanted students to see first hand how this actually works. Note that this was to run on a standard PDP-8—no index register.

Of course, there was no way that the kids could write such a kernel in two weeks. I simplified it in a number of ways. There were just three I/O devices—keyboard, printer, and clock. Each device had a simple, three-state, device-specific semaphore. There were three threads, created and fixed at assembly time. I provided an assembly language framework, and the students just had to fill in interrupt handlers, system calls, and the traffic controller. Here is my framework, with “/ **** Your code goes here ****” in various places. Here is how I would fill in the code.

This is my last narrative post. It’s been great fun, and I appreciate the interest from the retro community. I’d be delighted to continue the topic in a conversational form in any way that people are interested.

[EdS]

An excellent series of posts, @bill75 - many thanks for taking the time and setting out your experiences.

[larsbrinkhoff]

Thank you. I was particularly curious about your teaching since you mentioned it at the beginning of this thread. What was the reception among the students? Their thoughts about the PDP-8?

[bill75]

I had a handful of students each time I taught it who were quite engaged by the course in general, and the PDP-8 in particular. The students were mostly sophomores who had seen a little Python and Java and nothing else. So to see what’s actually going on inside a computer was for them exciting. I remember one kid who went beyond what was required for some of the PDP-8 assignments.

Most of the class, as you’d expect, just wanted to get through it. I don’t recall anyone interested in the PDP-8 from a historical/retro perspective.