At home with Josh

A Tour of my Workspace

Like many of you, I’ve been spending most of my time at home these days. While the museum is closed to the public, the engineers and other awesome staff are hard at work planning future exhibits and tours, polishing up our on-line systems, and working on hardware and software projects from the comfort of their couches. Or in my case, a workbench in the basement.

While I’ve been working from home, I’ve been hacking on a bit of emulation on the Unibone, archiving a huge pile of 8″ floppy disks and doing some preparatory research for a future emulation project. But I thought some of you might be interested what I’ve been working on in my spare time, which, as it turns out, is mostly identical to what I would usually be doing in my day-to-day when on site at the museum.

I have what might charitably be called a “hoarding problem” and as such I have ended up with a tiny computer museum in my basement that I’ve been adding to for the past twenty or thirty years. What started as a couple of Commodore 64s and TRS-80s (and so, so, so many TI-99/4As) scavenged from garage sales for $5 a pop when I was eleven has grown to encompass micros, minis and a few supercomputers crammed into an ever-shrinking space in my basement. Over the years I’ve learned to restore and maintain these systems, and since starting work as an engineer at LCM+L, I’ve gained even more knowledge but I still have a lot more to learn. In my spare time I tinker on machines in my collection, getting them to work again and making them do stupid/clever things.

So, here’s a brief tour of my basement museum, after which I’ll introduce you to my current restoration project.

So much computer, so little space. Note the fine wood-grain paneling on the walls. No basement should be without it.

Starting on the left-hand end of the west wall, we have an AT&T 3B2/600G UNIX system (1986) on top of a DEC PDP-11/73 (1983) and MicroVAX-I (1984). A classic LSI ADM-3A terminal adorns the 3B2. The PDP-11/73 was the first DEC system (and first minicomputer, even though DEC referred to it as a micro) I acquired, when I was still in high school. At the time it was running Micro-RSX, now it runs 2.11BSD. The large system to the right is a DEC VAX-11/750 (1980) with TU80 9-track drive. The 750 is restored and when I need to heat up the room, it runs 4.3bsd-Quasijarus or VMS. There’s currently a Data General Dasher D200 terminal on top of the TU80; it’s awaiting the completion of an Eclipse S/230 system.

Even More Computers

Moving further to the right, the DEC and Data General equipment continues: In the left rack I have a 1971 Data General Nova 820 (well, it’s a Canadian “DataGen” system but apart from a faint maple syrup smell…) on top of a DEC PDP-8/I (1968) with an OEM front panel. The Diablo 30 belongs to the Nova and has yet to be restored. In the right rack is a PDP-11/40 system (1973), with two RL02 removable pack drives (capacity 10mb) and one RK05 drive (capacity 2.5mb). The 11/40 runs a variety of systems: RT-11, RSX, Ultrix-11, and I plan to play around with RSTS on it sometime in the not-too-distant future. The PDP-8/I is in working condition but currently lacks peripherals beyond the basic teletype interface.

PDP-8s abound!

Continuing our tour, we are confronted with even more DEC equipment. The Straight-8 on the left is one of my favorite systems and I’m incredibly lucky to have found it. The Straight-8 is the first of the PDP-8 line, introduced in 1965. This particular unit is serial number 14, making it a very early example of this system (about 1500 of this model were made). It is nearly fully restored — there is a random glitch in the teletype interface that causes it to hang at random times and I haven’t yet tracked down the cause (though I suspect an intermittent backplane connection.) The next rack contains my workhorse PDP-8: a PDP-8/m with TU56 DECtape drive, RX02 floppy drive, RK05 removable pack drive and PC05 high-speed paper-tape reader and punch (these latter two are currently obscured by the ASR33 Teletype sitting in front of them). At the moment I have TSS/8 running on it.

Computer potpourri

The next rack to the right contains a miscellaneous assortment of minicomputers in various states of repair. From top to bottom: Texas Instruments 990/4 (1975, Data General Nova 800 (1971), Texas Instruments 980B (1974), PDP-8/e (1971), and mostly hidden is a Bunker Ramo BR-2412 (1971), an obscure 12-bit system originally manufactured by Nuclear Data. Tucked away in the corner is an AMT DAP 610, c. 1990. This is a massively parallel array processor, sporting 4096 1-bit processors in a 64×64 array. Each processor runs at 10Mhz, has its own memory and can communicate with its immediate neighbors via high-speed links. The system is capable of 40 billion boolean operations per second. It’s also technically a SCSI peripheral! The front-end processor for the DAP is a run-of-the-mill Sun Sparcstation LX.

North Wall: Way too much stuff

Progressing along the north wall, we have a smattering of systems and terminals, the most notable being the Inmos ITEM (“Inmos Transputer Evaluation Module”) which contains 40 Transputer processors, the PDP-11/34 (1977) which I’m using for Unibone development while working from home. The Tektronix 4051 computer and 4014 terminal are really cool examples of Tektronix’s Direct-View Storage Tube technology. The blue system in the corner is what remains of an Imlac PDS-1D (with front panel console box in front) and in front of that is a small rack with an Interdata Model 70 processor in it. Way back in the corner are shelves full of calculators and miscellaneous items too numerous to cover in detail. Also it’s a mess over there, and I try not to look at it too long. Avert your eyes…

Ridge 32 and VAX-11/730

Along the east side of the basement are a couple more systems: A Ridge 32 Supermini and a VAX-11/730. The Ridge 32 (1984) is an early 32-bit RISC design designed to be a VAX killer but hobbled by its operating system, ROS. ROS was a UNIX-alike system and at the time that just wasn’t enough, despite the system’s extremely fast CPU. The VAX-11/730 (1982) is one of my favorite systems — it’s the world’s slowest VAX at slightly less than 1/3 the speed of the original VAX-11/780 (0.3 VUPS) but it’s small, relatively quiet, and clever — The entire VAX processor was compressed into three hex-height boards. A couple of years back, I took this system to the beach:

VAX on the beach

Where it ran for 5 days providing dial-up service at 300 baud and a splendid time was had by all. We only tripped the breakers a few dozen times and it only rained once…

Where was I?

LispM’s, PERQs, and Suns, oh my!

Next up along the east wall is a collection of workstations; from left to right these are: Symbolics XL1200 (1990), Symbolics 3630 (1986), Three Rivers PERQ 1A (1981), and a Sun 2/120 (1986). The Symbolics systems are part of a class of systems known as “Lisp Machines” (LispM’s for short). They are near and dear to my heart — sophisticated systems from a lost era of computing. The PERQ 1A is a computer that came out of Pittsburgh in the early 1980s — a graphical workstation inspired by the Xerox Alto with local storage, a high resolution (768×1024) display, ethernet, and a microcoded CPU. It was an immensely clever design and was a very powerful machine for the time (and for the price) but Three Rivers never quite figured out how to compete in the market against Sun, Apollo and others. It is quirky and strange and hacked together, and I love it so much I wrote an emulator for it way back in 2006

The middle row of computer junk

Finally we have the center row of benches where I have a few notable systems set up, including two currently slated for restoration: a Xerox Alto and an LMI Lambda. I picked these two up on a recent trip out east, and they are two systems I never thought I’d own. I’m really looking forward to restoring them both, and my plan is to document the restoration here on this blog over the coming weeks. I’ve chosen the Lambda for the first restoration — I love the Alto more than just about anything else in my collection (I wrote an emulator for it even) but there are already several restored specimens in the world (including at LCM+L, of course) and there are, at the time of this writing, no LMI systems in operating condition in the world. (The Lambda in my basement is one of six known to exist.)

A Bit Of Background on LMI and the Lambda

The history of Lisp Machine Incorporated (LMI) and of lisp machines in general has been written about fairly extensively in various places (see here and here) and this post is running a bit long already, so I’ll provide an abridged version in this post:

In the mid-1970s a group of hackers at MIT’s AI Lab designed a series of computer systems for the specific purpose of running Lisp programs efficiently. The first was known as the CONS, and its successor the CADR was a sufficiently successful design that it was proposed to create a commercial product in the nascent Lisp AI space. Opinions differed on the best course of action and so two competing endeavors ensued: Lisp Machine Inc., and Symbolics. Both companies started off selling commercialized versions of the CADR (LMI’s as the LMI CADR, Symbolics’s as the LM-2) before expanding off into their own designs. Symbolics emerged the victor: their follow-up to the CADR, the 3600 series, was extremely successful while LMI struggled to sell their Lambda workstation — fewer than 200 were sold. LMI went bust in 1987 before it could produce its Lambda successor, the K-Machine.

My Lambda

My Lambda came out of a drafty Pennsylvania garage it had been sitting in for over twenty years. It was covered in a fine grit of mouse droppings, dust, and bits of shingle from when the garage’s roof was replaced several years back. It also has a fine patina of rust and corrosion on nearly every surface.

It’s also missing the tape drive and disk drive. The good news is that both of these are at least somewhat still possible to find: The tape drive was a standard Cipher F880 9-track drive with a Pertec interface, and the hard drive was a Fujitsu Eagle SMD drive. It’s likely that any Pertec-compatible tape drive will work, and it should be possible to find a suitable SMD disk that still functions.

Apart from the missing drives, the system appears to be complete: The backplane is fully populated with boards and in fact is a 2×2-PLUS system (two LISP CPUs and a 68010-based UNIX CPU in one chassis!). Two consoles were included with cabling, but only one keyboard and mouse, alas.

Restoration Plan

So my hope is to restore this system to operating condition, and since I’ll be here at home a lot more than usual I’ll have ample spare time to do it in! As I progress in the restoration in my off hours I’ll post updates here to keep you all in the loop and to give you an idea of the kind of steps we typically undertake when restoring systems at LCM+L.

It’s important to have a plan for this sort of thing; so here’s my current plan of attack, which is of course subject to change depending on how things go:

  1. General cleanup. After twenty years in the garage, this thing smells fairly musty and as mentioned previously, is quite dirty. The chassis, consoles, cables and all assorted ephemera need to be cleaned out and inspected for damage. If mice get into computer hardware they can do serious damage. I haven’t seen any evidence of this but it’s best to be sure.
  2. Inspection, cleaning, and testing of the system power supplies. Just plugging a system like this in after so many years lying dormant is a bad idea. The supplies will be removed from the system, checked out and tested with dummy loads prior to reinstallation. Any necessary repairs to the supplies will be undertaken at this time.
  3. Inspection and cleaning of the boards in the backplane, and the backplane itself. This entails cleaning of corroded pins on socketed ICs and inspecting for serious damage.
  4. Power up of a subset of boards, starting with the SDU (System Diagnostic Unit). The SDU can be used to inspect and test the rest of the boards in the system, once a tape drive has been procured.
  5. Find a working tape drive and disk drive; write out a copy of the LMI Installation and System tapes.
  6. Use the SDU to test the rest of the boards in the system.
  7. Restore one or both of the Lambda consoles; use the SDU to test them.
  8. Install the system to disk.
  9. Boot the system.
  10. Do a dance of some kind.

Daniel Seagraves (author of LambdaDelta, a most-excellent LMI Lambda emulator) is undertaking a similar effort as I type this; he rescued two Lambdas from a much worse garage than the one mine came from and is documenting his restoration efforts here. We’ve been chatting and he’s been extremely helpful in inspecting my Lambda and has sent me some updated SDU ROMs and an Ethernet interface for my system. His help will be instrumental in getting my system going.

Whew. I think that’s enough for one blog post. The next post will bring everything up to date with the current status of the restoration.

My First Computer

Hi, my name is Bruce, and I am a Computer Nerd! I have been a computer nerd for over 50 years, so I will probably always be a computer nerd.

In 1969, as a Senior at Lincoln High School, in Seattle Washington I accepted the challenge of taking a class in Fortran IV. I was also taking what was then called “typing” so I got to use a brand new IBM 029 card punch machine to punch my own programs to submit to the Seattle Public Schools IBM 360/40 in downtown Seattle. I had a great time figuring out how to teach the IBM to do what I wanted, as opposed to what I told it.

I had been one of those typical “under-achievers” in high school, so the big schools weren’t chasing after me, but I got a lot of marketing stuff from smaller schools. I went and interviewed a Computer Programming school, in downtown Seattle, and was not impressed. I ended up signing up at a private school in Lynnwood to become an electronics technician at a price of around $2000, or the same as the new Volkswagen Bug my brother had just bought.

After finishing at CTC Education Systems, I got a job at Tally Corporation, in Kent, repairing paper tape readers, and line printers. After building a little exerciser widget for the paper tape readers I worked on, one of the engineers handed me a data book for the just out Intel 8008, and asked me if I thought it could test those paper tape readers.

WOW! A Whole computer in a tiny little chip! I spent all my spare time, for about two weeks, reading that book! I discovered it wasn’t really a “whole” computer, but it was a good starting point. I decided that the 8008 was not really fast enough to do what we wanted. I think I have since figured out a different way to do what we wanted with the 8008, but long after I left Tally.

It didn’t take me a very long time to get tired of fixing paper tape readers. My brother Bob had moved to Livermore, California to work at Lawrence Livermore National Laboratory. That was only about 45 minutes from “The Silicon Valley”, the Mecca of the Electronics Industry, where that company Intel was.

I took a couple of days off, and drove to Livermore to visit Bob, and poke around the “valley” a little bit. I applied at Intel, and HP. HP didn’t want to talk to me because they wouldn’t hire someone without at least a two year degree, not some little private school. Intel said “we don’t have a position for you at this time”. I thought that was that. They called back 3 months later, and I had a phone interview with the head of the test engineering department. Intel and I came to an agreement, and I moved in with Bob on Memorial Day weekend, 1973, and started at Intel the next Tuesday.

In my spare time, I started designing all the stuff to go around an 8008 to make my own computer. Intel gave me a chip to encourage me. Eventually the 8080 came out, and it was a much better chip, but I was already heavily into building my 8008, and didn’t accept one when they offered it. The Altair 8800 came out, and the price of the kit was less that the price of the 8080 if you had to buy one.

After a while, I got another job, and the 8008 project foundered. In January 1976, I bought an IMSAI 8080 kit, with 8K bytes of memory and some peripherals. It didn’t work very well when I got it assembled, but having spent 2 years at Intel fixing memory testers, I determined that the memory was bad, so IMSAI swapped it out, and then everything was fine. Bob and I had a great time learning how to use it.

I would occasionally go to a Homebrew Computer Club meeting in Palo Alto on the way home from work, getting home to Livermore pretty late. Bob and I went to the Lawrence Livermore National Labs Computer Club meetings most months. Members would sometimes come over on weekends, and we would play, or I would help them debug their computers.

On one detour to the Homebrew Meeting on the way home from work, I remember Lee Felsenstein reading a letter from Bill Gates accusing most of us of stealing his software. I guess I have to admit that was true.

At that time, the computer cost about $395, before memory and I/O. If you bought an Altair 8800, Altair BASIC cost you $75. If you didn’t own an Altair, Altair wanted $400 for Altair BASIC. There weren’t any Microsoft dealers that we knew of, just the Byte Shops, which were Altair dealers. We and the denizens of the LLNLCC spent many a happy hour figuring out how to get MITS 12K BASIC to run on our IMSAI’s. 12K BASIC would do more stuff, but it was huge and much slower than the smaller version, so I didn’t use it after I got it working.

At another Homebrew meeting, I heard about some new software just coming out, called CP/M, a floppy disk operating system for 8080 machines. That was pretty cool, but disk drives were pretty expensive. Shortly thereafter, the president of the Lawrence Livermore National Labs Computer Club got a request for some help debugging a floppy disk interface to S100 machines like the IMSAI. He said “You should talk to the Sherry Brothers”. That was how I met John Torode.

John Torode, and his wife Patty, lived in Livermore too, and had a company called Digital Systems, that built floppy disk systems out of their house. They actually built the hardware that CP/M first ran on. They wanted to expand into the S100/Altair/IMSAI market, but they didn’t have an S100 machine!

We used my IMSAI to debug Johns S100 interface, and the Sherry Brothers became one of the earliest CP/M users in the Bay Area, as somehow John left one of his machines at our house, in case more debug was needed. Oh man, was this great!

Up till then, we had been using a Tarbell Cassette Tape Interface to load and store programs. The Tarbell really only liked a particular JC Penny portable cassette player, and you had to keep track of where on the tape you had stored a particular program. Soon we had several cassettes of programs like Altair 4K BASIC, Wangs Tiny BASIC, a Star Trek game, and others.

If we wanted to write an assembly language program, we would have to load what we would now call an IDE, or Integrated Development Environment. I think we had something like that from Processor Technology, the SOL computer folks.

CP/M had an assembler, an editor, a debugger, and lots of storage, on the 8″ single density floppy drives we had. Each 8″ floppy could hold a quarter of a million bytes of data! That is like a whole novel of the day. Novels have gotten longer since then.

John Torode and I became friends, and when he was having trouble debugging his Double Density floppy disk controller, I would stop by on the way home, and lend a hand for a while.

I had recently convinced my boss to buy a “logic analyzer” to help us debug our designs. He was pretty reluctant, but he agreed that the first time he tried it, he found a bug he had been looking for for a month. He decided it had paid for itself in that one use.

After work, I would bring the logic analyzer along with me, and John and I would debug his controller, till I was falling asleep. It didn’t take too long with the analyzer before John found his bug, and then he had a double density controller to sell, so the same 8″ floppy could hold half a million bytes.

Using the single density system John had left at my house, I got a copy of the source to Li-Chen Wang’s Palo Alto Tiny BASIC, and started converting it to run on CP/M. Once I had done that, I added a bunch of commands to talk to I/O ports, Memory, and interface to assembly language routines you might add. Between the assembly language source, the listing file, and the object file, it filled a whole single density floppy.

As far as I know, the Sherry Brothers Tiny Basic source I contributed to the Homebrew Computer Club Library is the only computer readable version of Li-Chen Wang’s Palo Alto Tiny BASIC available on the net. It is also the version of BASIC we run on the IMSAI at LCM+L.

All in all, I have many fond memories of using my IMSAI to learn about computers and software. I still have the front panel of mine, but the rest of it didn’t make the trip back from Silicon Valley to the Seattle area. Both of my brothers ended up buying IMSAIs, and you can see my brother Gales in the Museum at REPC in Sodo.

How I Use Excel

I use Excel spreadsheets to organize my projects.

Often my first sheet is a list of files useful for the project.  It is usually generated by taking a directory listing of the document directory.  And that makes it usually alphabetical.  Then I’d make a column of links to those files so I can just click on them to open them.  Then I’d make another column to give a summary of what is in the file (as in schematics or tables or pretty worthless for anything technical).  Being an alphabetical list, I’d copy that sheet to another and organize it into hardware and software and promotional files.  I make a COPY because “Never crunch original data” (ever!)

A listing of PDFs in the Sigma9 directory

But I also use the VBA function to crunch data ( not the original data.)  I take tables from documents and convert them to different number bases, and fill in missing values (by saying this value is not defined.)  Or I make a compiler to create binary code from assembly language.

I also may generated diagrams.  I use arrays of tiny circles or line segments to draw Kaleidoscopes or Spirographs or printed circuit boards.

KaliedoscopeDECtape panelLogo HandshakeRendered Logo handshake

I sometimes print out template sheets so I can record labels for connector pins, or connections between pins on a backplane.  This one is for the game of Clue.

Clue Detective Sheet
Detective Pad for the game of Clue

Or visualize data in a giant oscilloscope:

Waveforms

Robotis Mini

For crunching numbers, or processing files, Excel is my goto program.

Microsoft Software I Have Loved

With Microsoft’s 45th birthday coming up, I thought it’d be appropriate to reflect on the Microsoft tools I use regularly in my day-to-day work at the museum. Well, maybe not day-to-day: some days I’m out there probing hardware or installing an operating system on a PDP-8 and on those days most software I’m using either predates Microsoft or isn’t software at all.

But on those days when I’m working on my emulation-project-du-jour or any of a handful of tools in use around the museum, I’m sitting at my desk staring at the latest incarnation of Visual Studio. My first introduction to it was in 1999 in one of my comp. sci classes in college (our curriculum was fairly evenly split between programming on Windows and Solaris systems) and I ended up using it in my classes on graphics and multimedia where I learned to use OpenGL and DirectX, as well as for a course where I needed to do some development for Windows CE (on the original Compaq iPAQ — remember those?)

Visual Studio 2017, editing Darkstar

Microsoft has always treated its developers well and Visual Studio has always been an extremely polished piece of software. It has an excellent debugger and decent integration with a variety of source control systems. I’m a big fan of C# for most of my projects, hence ContrAlto, Darkstar, and sImlac being written in it.

And heck, since I’m feeling nostalgic, allow me to wax rhapsodic about Microsoft QuickBASIC. As a kid I graduated from BASICA to QBasic and abandoned line numbers in favor of structured (or at least slightly-more-structured) programming. QB.EXE was my IDE of choice for many years, until I graduated to Borland Turbo C++ 3.0 for DOS. (Hot take: C++ was, in many ways, a step down from QuickBASIC.) And I will not hear a bad word spoken about GORILLA.BAS, perhaps the finest piece of software Microsoft ever wrote (runner up: NIBBLES.BAS):

Mainframe Computer Connector Failure and Solution

We have uncovered another interesting phenomena which has impacted our collection.  As the subject line indicates, we have identified a failure mode concerning the gold finger contacts on the numerous circuit boards in our large systems.  Specifically, a hard, mostly carbon (with an amalgam of other unknown atmospheric particles) film has adhered selectively to the plated gold.  It is highly resistant to cleaning with anything from alcohol to acetone.  The only way to remove the film is with mild abrasion ( 3M Scotchbrite ).

When the collection was first started, the large mainframes suffered from reliability issues that was subsequently tied to buildup of soot and dust on the gold finger contacts of the printed circuit boards. This was back in 2002, and alcohol cleaning did not entirely solve the reliability issue as the intermittency recurred after several months. In doing our research, we found a product online called “Stabilant 22”.  It is a polymer substance that becomes conductive when a voltage differential occurs between two planes of metal, as between the contact fingers of a printed circuit board and the PCB connector. When we applied it, the problem was solved and did not recur for several years.

In the last couple of years, two of our large mainframes ( and other machines ) have became unstable once again. But this time, alcohol cleaning and application of Stabilant 22 has not fixed the problem. While evaluating the nature of the problem, I experimented by applying mild abrasion to the circuit board contact fingers, and then cleaned them with Kim-Wipes and alcohol. Previously, where no visible residue was left on the wipe, there was now a significant quantity of dark residue removed.

Samples of unknown carbon residue taken off with light abrasion

Once the contacts were again treated with the contact enhancer, the intermittent failures went away.

We applied this fix to all of the circuit cards in both machines and re-established the robust reliability we had experienced previously.

Our speculation for this phenomenon is that the carbon deposited on the PCB contact fingers is in the form of 2D graphene glass, which is a good insulator and quite transparent. The abrasion breaks the surface of the glass and the carbon converts to the particulate form we are used to which is easily removed with alcohol.

        The step by step process we have developed to successfully restore the contact integrity is:

  1. Use an alcohol soaked KimWipe to first clean the contact of loose surface material.
  2. Lightly rub the contact fingers with a super fine grade Scotchbrite pad.
  3. Use an alcohol soaked KimWipe to remove the carbon rich material shown in the photo.
  4. Repeat step 3 till the wipe no longer accumulates material.

So far, we have reached out to a number of resources for a definitive determination of the nature of the material we are cleaning off, with no confirmation. We invite the assistance of the technical community at large to help us with this determination.

What I Did on my Summer Vacation, 1991:

The first computer I can remember using — as in actually sitting down in front of it and interacting with it — was in 1986 in my dad’s office at Lincoln Land Community college. I was 6.

Yours truly, at the seat of a screamin’ machine. If only I’d known what was to come…
IBM Personal Computer PIECHART (Copyright IBM Corp 1981, 1982)

The computer was an off-brand IBM PC clone and I vividly remember playing with a program that drew pie charts and another that played really crude music through the PC’s speaker. (These were two of the demo BASICA programs that came with IBM PC-DOS 3.0.)

IBM Personal Computer MUSIC (Copyright IBM Corp 1981, 1982)

My school at the time had a few Bell & Howell Apple II machines but I don’t recall ever actually getting to use one. A few years later I had friends with Commodore 64s and Ataris and one with a Coleco ADAM (I still feel sorry for that family). The computer lab at Lakeside Elementary (no relation to the one Bill and Paul went to) was stocked with Apple IIs on which we used Appleworks to write stories and to play video games (mostly the latter). I didn’t have a computer of my own until 1991.

The first computer that was all mine was an IBM 5150, the original IBM PC (introduced 1981) that went on to conquer the world. It was given to our family in the spring of 1991 (by a family that had just upgraded to something better) right as I was finishing the 5th grade. It came equipped with two 360K floppy drives, a whopping 640K of RAM (should be enough for anybody), a 4.77Mhz Intel 8088 processor, and an IBM CGA adapter connected to an Amdek Color II display. It also came with a couple of boxes of software and the IBM PC-DOS and IBM BASIC reference manuals.

My copy of the IBM PC BASIC Reference Manual.

While I don’t necessarily recommend it, one can teach one’s self BASIC by reading the IBM BASIC Reference manual, and this is how I got my start with computer programming. The summer following 5th grade I learned how to manipulate the crude graphics of the CGA board (4 colors! Well, three colors really, and none of them ones you’d want to use for anything) producing drawings and animations, and to make the speaker emit crude beeps. My addiction at the time was Ms. Pac-Man and so what I wanted most in the world was to write my own rendition.

It took me some time to get there and… well, it wasn’t very good but I did eventually write something that kind of resembled Pac-Man if you squinted just right and also didn’t care about gameplay or fun.

PAC-GUY: It’s just like PAC-MAN except in every possible way. Not shown: fun.

In 1991 the 16-bit 8088-based IBM PC was already ten years old — the state of the art was the new 32-bit i80486 at speeds of up to 50Mhz. (My dad had a Northgate 486 system in his office at work for running Maple really quickly). But technology moved slower then: you could still go to your local Electronics Boutique and buy new software that came on 5.25″ 360K disks and ran on the original PC with CGA graphics. Heck, in those days you could still buy a new system based on the 8088 or 8086 — many of the cheaper laptops and portables of the day were still 8086 systems (albeit at 8Mhz) with 640K of memory and CGA graphics. I bought Print Shop Pro and printed out the most awesome banners on the IBM Graphics Printer. I played Monty Python’s Flying Circus: The Computer Game, and indulged myself on scads of older games scrounged from local BBSes and traded with friends.

Me, 1994, with CompuAdd laptop, demonstrating COMPUTER PROGRAMMING at my 8th grade Job Faire. Yes I did get beat up a lot, why do you ask?

And I yearned for more speed and maybe more than four colors on my display. And over the coming years I saved my money to pay for half of a new computer (my parents were very generous): In the summer of 1993 I bought a CompuAdd 425TX laptop (25Mhz 486, 4MB memory, SVGA greyscale display at 640×480 pixels, and an 80 megabyte hard drive which filled up more quickly than I’d expected) which I used and cherished until 1998… but the IBM PC will always hold a special place in my heart.

HP9100B

My “first” computer experience.
It was a high school class, “man made world”, which got me interested in computers. Before that I was interested in Science, but mostly in math.
This class taught logic with relays, and control with an analog computer. We also learned Fortran by punching cards on an IBM 26 keypunch. Those decks of cards would go into an inter-office envelope and wander its way to the central school computer; where, later, a printout would be sent back in the same slow way.
Printer Art was the fashion then, and I printed Fonebone from Mad Magazine, and a portrait of a schoolmate, but mostly did Spirographs.
When I got into a higher math class there was a programmable calculator with a plotter. It was an HP9100B. You can see an HP9100 in the original movie “The Andromeda Strain”. The van finding the plane crash plots the triangulation with the HP9100 and plotter. In the movie it is not model HP9100B as the keyboard was slightly different between the revisions.
In free time, I had access to the calculator where I made Spirographs and Random Duckies and Vector Art and Letters.

Logic with relays used an AMF Logic Circuit Board Model 800.  It has 4 switch inputs, 4 relays, and 4 output lamps.  We used it mostly to make noise and blinking lights.  However, I once programmed it for a combinations lock, where the sequence of flipping switches enabled one relay to latch, then another — until you got all 4 relays to latch (without all clearing with a wrong switch flip) and then light a lamp.

Analog control used an AMF Educational Computer Model 665/D.  It has an integrator, differentiator, 2 mixers, and knobs.  We used it mostly to make circles or watch exponential decay.  I figured out how to use a diode to take the maximum between a Sin and Cosine wave, put that on the display Y axis, then combine the Sin and Cosine on the X axis to make a Heart.

At one point, a few enthusiastic students of the class visited the school district computer.  Not much to see, a big iron box here, another big iron box there…  I asked how large the accumulator was, the answer being “32 bits”.  What I actually wanted to know was physical size.  I suspect it would have been multiple boards, but we never got to peer inside the cabinets.  But: *** now I get to peer inside of cabinets ***

Conway’s Game of Life — Parallel Processing

The simple algorithm lends itself to multi-cell processing.

Using a numerical keypad for reference, and using the 5 key as referring to the current bug, then the neighbors above would be in positions 789, the neighbors to the sides are 4 and 6, and the neighbors below are 123.

Numerical Keypad
Numerical Keypad

If we use each bit in a word to hold our bug information, and call our data locations current, above and below, then neighbor 4 would be current shifted right by a single bit, and neighbor 6 would be current shifted left by a single bit. Handling of what gets shifted in could be 0 if it is at an edge, or a bit from the next/previous current location if the game board extends for multiple words per row, or can roll the data to make a closed (torus) game board. Neighbor 7 would be above shifted right, neighbor 8 would be above, neighbor 9 would be above shifted left. Neighbor 1 would be below shifted right, neighbor 2 would be below, and neighbor 3 would be below shifted left.

Now we want to count how many bugs we have as neighbors. Let’s set up 8 empty words. Well, it is easy to count the first neighbor — we’ll just put neighbor 1 into the first count space. For neighbor 2, we can AND it with the first location — giving CARRY to put in the second count space. Then we can OR neighbor 2 back into the first count space. Bits in the first count space will say there is at least one bug as a neighbor, and bits in the second count space will say there are at least two bugs as neighbors. Continuing with neighbor 3 we AND it with the first count location, generating a CARRY, and OR it with the first location. Then the CARRY AND the second location generate a new CARRY’ for the third location. The original CARRY will OR into the second location. Continue this for all 8 neighbors, keeping careful track of old CARRY and new CARRY’. Actually, when you get beyond the fourth count, we won’t be using them anymore so you can stop there.

Now to calculate the next generation. Take the inverse of the current data AND count location 3 placing it back in the current data. This means we have an empty cell with at least 3 neighbors so generate new life. Now AND it with count location 2. This means we have at least 2 neighbors so we remain alive. And finally, AND it with the inverse of count location 4. This means we have at least 4 neighbors and we die.

The counting method:
data is the input, and is updated along the way.
count[] is the 8 word array.
carry holds the carry.
For n = 0 to 7
    carry = count[n] And data
    data = data Xor carry
    count[n] = count[n] + data
    data = carry
Next n
The generation method:
game[] is the array holding all bug data.
count[] is the array holding the results of the counting method.
game[j, i] = game[j, i] + (count[2] And Not game[j, i])
game[j, i] = game[j, i] And count[1]
game[j, i] = game[j, i] And Not count[3]

I wrote this program for a PDP-7, which has a word size of 18 bits. The display I use has a reasonable 44 character mode, and a tiny 88 character mode. So I chose 36 x 36 as my first game board, later expanding to 72 x 72. That would be 2 18-bit words per line or 4 18-bit words per line. The PDP-7 has an instruction to shift using the Link (carry) register. There is no OR function, that is why I XOR the CARRY with the data so I can ADD it back.

Life Game
Life 36 x 36

Time-sharing in 12KW: Running TSS/8 On Real PDP-8 Hardware

But first, a little history

Digital Equipment Corporation’s PDP-8 minicomputer was a small but incredibly flexible little computer. Introduced in 1965 at a cost of $18,000 it created a new market for small computers, and soon PDP-8s found themselves used for all sorts of tasks: Industrial control, laboratory data capture and analysis, word processing, software development, and education. They controlled San Francisco’s BART Subway displays, ran the scoreboard at Fenway Park and assisted in brain surgery.

They were also used in early forays into time sharing systems. Time-sharing stood in stark contrast to the batch processing systems that were popular at the time: Whereas batch processing systems were generally hands-off systems (where you’d submit a stack of punched cards to an operator and get your results back days later) a time-sharing system allowed multiple users to interact conversationally with a single computer at the same time. These systems did so by giving each user a tiny timeslice of the computer: each user’s program would run for a few hundred milliseconds before another user’s program would get a chance. This switching happens so quickly it is imperceivable to users — providing the illusion that each user had the entire computer to themselves. Sharing the system in this manner allowed for more efficient use of computing resources in many cases.

TSS/8 was one such time-sharing endeavor, started as a research project at Carnegie-Mellon University in 1967. A PDP-8 system outfitted with 24KW of memory could comfortably support 20 simultaneous users. Each user got what appeared to them as a 4K PDP-8 system with which they were free to do whatever they pleased, and the system was (in theory, at least) impervious to user behavior: a badly behaved user program could not affect the system or other users.

With assistance from DEC, TSS/8 was fleshed out into a stable system and was made available to the world at large in 1968, eventually selling over a hundred copies. It was modestly popular in high schools and universities, where it provided a cost-effective means to provide computing resources for education. While it was never a widespread success and was eventually forgotten and supplanted on the PDP-8 by single-user operating systems like OS/8, TSS/8 was a significant development, as Gordon Bell notes:

“While only a hundred or so systems were sold, TSS/8 was significant because it established the notion that multiprogramming applied even to minicomputers. Until recently, TSS/8 was the lowest cost (per system and per user) and highest performance/cost timesharing system. A major side benefit of TSS/8 was the training of the implementors, who went on to implement the RSTS timesharing system for the PDP-11 based on the BASIC language.”

Gordon Bell, “Computer Engineering: A DEC View of Hardware Systems Design,” 1978

It is quite notable that DEC made such a system possible on a machine as small as the PDP-8: An effective time-sharing system requires assistance from the hardware to allow separation of privileges and isolation of processes — without these there would be no way to stop a user’s program from doing whatever it wanted to with the system: trampling on other users’ programs or wreaking havoc with system devices either maliciously or accidentally. So DEC had to go out of their way to support time-sharing on the PDP-8.

PDP-8 Time-Sharing Hardware

In combination with the MC8/I memory extension (which allowed up to 32KW of memory to be addressed by the PDP-8), the KT8/I was the hardware option that made this possible, and was available on the PDP-8/I as an option at its introduction. The KT8 option was made available for the original PDP-8 around this time as well.

So what does the KT8/I do (in combination with the MC8/I) that makes time-sharing on the PDP-8 feasible? First, it provides two privilege levels for program execution: Executive, and User. The PDP-8 normally runs at the Executive privilege level — at this level all instructions can be executed normally. Under the User privilege level, most instructions execute as normal, but certain instructions are forbidden and cause a trap. On the PDP-8, trappable instructions are:

  • IOTs (I/O Transfer instructions, generally used for controlling hardware and peripherals).
  • The HLT (Halt) instruction, which normally stops the processor.
  • The OSR and LAS instructions, which access the front panel’s switch register.

Under a time-sharing system such as TSS/8, the operating system’s kernel (or “Monitor” in TSS parlance) runs at the Executive privilege level. The Monitor can then control the hardware and deal with scheduling user processes.

User processes (or “Jobs” in TSS) run at the User level (as you might have guessed by the name). At this level, user programs can do whatever they want, but if one of the classes of instructions listed above is executed, the user’s program is suspended (the processor traps the instruction via an interrupt) and the PDP-8’s processor returns to the Monitor in Executive mode to deal with the privileged instruction. If the instruction is indeed one that a user program is not allowed to execute, the Monitor may choose to terminate the user program. In many cases, IOTs are used as a mechanism for user programs to request a service from the Monitor. For example, a user program might execute an IOT to open a file, type a character to the terminal, or to send a message to another user. Executing this IOT causes a trap, the Monitor examines the trapped instruction and translates it into the appropriate action, after which the Monitor resumes execution of user’s program in User mode.

Thus the privileged Executive mode and the unprivileged User mode make it possible to build an operating system that can prevent user processes from interfering with the functioning of the system’s hardware. The MC8/I Memory Extension hardware provided the other piece: Compartmentalizing user processes so they can’t stomp on other user programs or the operating system itself.

A basic PDP-8 system has a 12-bit address space and is thus capable of addressing only 4KW of memory. The MC8/I allowed extending memory up to 32KW in 4KW fields of memory — it did so by providing a three bit wide Extended Memory Address register (which thus provided up to 8 fields.) This did not provide a linear (flat) memory space: The PDP-8 processor could still only directly address 4096 words. But it did allow the processor to access data or execute instructions from any of these 8 fields of memory by executing a special IOT which caused future memory accesses and/or program instructions to come from a new field.

With this hardware assistance it becomes (relatively) trivial to limit a user program to stay within its own 4KW field: if it attempts to execute a memory management IOT to switch fields the KT8/I will cause a trap and the Monitor can either abort the user’s program or ensure that the field switch was a valid one (swapping in memory or moving things around to ensure that the right field is in the right place). (This latter proves to be significantly more difficult to do, for reasons I will spare you the details on. You’re welcome.)

This article’s supposed to be about running TSS/8 on a real PDP-8, let’s talk about that then shall we?

Where were we. Oh yes, TSS/8.

TSS/8 was initially designed to run on a PDP-8/I (introduced 1968) or the original PDP-8 (1965) equipped with the following hardware at minimum:

  • 12KW of memory
  • KT8/I and MC8/I or equivalent
  • A programmable or line-time clock (KB8/I)
  • An RF08 or DF32 fixed head disc controller with up to four RS08s or DS32 fixed head disks

Optionally supported were the TC08 DECtape controller and a DC08 or PT08 terminal controller for connecting up multiple user terminals. As time went on, TSS/8 was extended to support the newer Omnibus PDP-8 models and peripherals: The PDP-8/e (1970), 8/f, 8/m and the 8/a introduced in 1976.

TSS/8 used an RF08 or DF32 disc for storing the operating system, swapping space, and the user filesystem. Of these the most critical application was swapping: each user on the system got 4KW of swap space on the disk for their current job — as multiple users shared the system and there became more users than memory, a user’s program would be swapped out to disk to allow another user’s program to run, then swapped back in at a later time. Thus the need for fast transfer rate with minimal latency was required: The RF08 being a fixed-head disk had very little latency (averaging about 17ms due to rotational delays) and had a transfer rate of about 62KW/second.

Fixed head disks also had the advantage of being word addressable, unlike many later storage mechanisms which read data a sector at a time. This made transfers of small amounts of data (like filesystem structures) more efficient as only the necessary data needed to be transferred.

Our RF08 Controller with two RS08 drives (256KW capacity each)
Our RF08 Controller with two RS08 drives (256KW capacity each)

We’ve wanted to get TSS/8 running at the museum for a long time. The biggest impediment to running TSS/8 on real hardware in this year of 2019 is the requirement for a fixed-head disk. There are not many RF08s or DF32s left in the world these days, and the ones that remain are difficult to keep operational in the long term. We have contemplated restoring a PDP-8/I and the one RF08 controller (with two RF08 discs) in our collection or building an RF08 emulator, but I thought it would be an interesting exercise to get it to run on the PDP-8/e we already have on exhibit on the second floor, with the hardware we already have restored and operational.

LCM+L's PDP-8/e.  RK05 drive on the left.
LCM+L’s PDP-8/e. RK05 drive on the left.

Our 8/e is outfitted with an RK05 drive, controlled by the usual RK8E Omnibus controller. The RK05 is a removable pack drive with a capacity of approximately 2.5MB and a transfer rate of 102KW/sec. On paper it didn’t seem infeasible to run a time-sharing system with an RK05 instead of a RF08 — each user’s 4K swap area transposes nicely to a single track on an RK05 (a single track is 16 sectors of 256 words yielding 4096 words) and the capacity is larger than the maximum size for an RF08 controller (1.6MW vs 1.0MW). However, the seek time of the RK05 (10ms track-to-track, 50ms average vs. no seek time on the RF08) means performance is going to be lower, the only question is by how much. My theory was that while the system would be slower it would still be usable. Only one way to find out, I figured.

Finding TSS/8 Sources

Of course, in order to modify the system it would be useful to have access to the original source code. Fortunately the heavy lifting here has already been done: John Wilson transcribed a set of source listings way back in the 1980s and made them available on the Internet in the early 2000s. Since then a couple of PDP-8 hackers (Brad Parker and Vincent Slyngstad) combined efforts to make those source listings build again, and made the results available here. Cloning that repository provides the sources and the tools necessary to assemble the TSS/8 source code and build an RF08 disk containing the resultant binaries along with a working TSS/8 filesystem. I began with this as a base and started in to hacking away.

Hacking Away

The first thing one notices when perusing the TSS/8 source is that it has comments. Lots of comments. Useful comments. I would like to extend my heartfelt thanks to the original authors of this code, you are the greatest.

Lookit’ them comments: That’s the way you do it!

There are two modules in TSS/8 that need modifications: INIT and TS8. Everything else builds on top of these. INIT is a combination of bootstrap, diagnostic, backup, and patching tool. Most of the time it’s used to cold boot the TSS/8 system: It reads TS8 into fields 0 and 1 of the PDP-8’s memory and starts executing it. TS8 is the TSS/8 Monitor (analogous to the “kernel” in modern parlance). It manages the hardware, schedules user jobs, and executes user requests.

It made sense to make changes to INIT first, since it brings up the rest of the system. These changes ended up being fairly straightforward as everything involved with booting the system read entire 4K tracks in at a time, nothing complicated. (I still have yet to modify the DECtape dump/restore routines, however.)

The code for TS8, the TSS/8 Monitor, lives in ts8.pal, and this is where the bulk of the code changes live. The Monitor contains the low-level disk I/O routines used by the rest of the system. I spent some time studying the code in ts8.pal to understand better what needed to be changed and it all boiled down to two sets of routines: one used for swapping processes in and out 4KW at a time, and one used for filesystem transfers of arbitrary size.

I started with the former as it seemed the less daunting task. The swapping code is given a 4K block of memory to transfer either to (“swapping out”) or from (“swapping in”) the fixed-head disk. For the DF32 and RF08 controllers this is simple: You just tell the controller “copy 4KW from here and put it over there” (more or less) and it goes off and does it and causes an interrupt to let the processor know when it’s done. Simple:

SWPIN,    0
     DCMA        /TO STOP THE DISC
     TAD SWINA   /RETURN ADDRESS FOR INTURRUPT CHAIN
     DCA I DSWATA    /SAVE IT
     TAD INTRC   /GET THE TRAC # TO BE READ IN
     IFZERO RF08-40 <     
     TAD SQREQ   /FIELD TO BE USED     
     DEAL     
     CLA     
     NOP     /JUST FOR PROPER LENGTH     >
     IFZERO RF08 <     
     DXAL     
     TAD SQREQ   /FIELD TO BE SWAPPED IN     
     TAD C0500   /ENABLE INTERRUPT ON ERROR AND ON COMPLETION     
     DIML     >
     DCA DSWC    /WORD COUNT
     CMA
     DCA DSMA    /CORE ADDRESS
     DMAR
     JMP I SWPIN

SWPTR,    JMP SWPERR      /OOPS
     TAD FINISH      /DID WE JUST SWAP IN OR OUT?
     SMA
     JMP SWPOK       /IN; SO WE'RE FINISHED
     CIA
     DCA FINISH      /SAVE IT
     JMS SWPIO       /START SWAP IN
     DISMIS          /GO BACK TO WHAT WE WERE DOING

For the RK05 things are a bit more complicated: The RK8E controller can only transfer data one sector (256 words) at a time, so my new swapping code would need to run 16 times (and be interrupted 16 times) in order to transfer a full 4KW. And it would have to keep track of the source and destination addresses manually. Obviously this code was going to take up more space, and space was already at a premium in this code (the TSS/8 Monitor gets a mere 8KW to do everything it needs to do). After fighting with the assembler and optimizing and testing things I came up with:

SWPIN, TAD SQREQ                 / GET FIELD TO BE SWAPPED IN
     TAD C0400                   / READ SECTOR, INTERRUPT
     DLDC                        / LOAD COMMAND REGISTER:
                                 / FIELD IS IN BITS 6-8;
                                 / INTERRUPTS ENABLED ON TRANSFER COMPLETE
                                 / OF A 256-WORD READ TO DRIVE ZERO.
     TAD     INTRC               / GET THE TRACK # TO READ FROM
     TAD     RKSWSE              / ADD SECTOR
     DLAG                        / LOAD ADDRESS, GO
     JMP I   SWPIT
     
 / FOR RK05:
 / ON EACH RETURN HERE, CHECK STATUS REG (ERROR OR SUCCESS MODIFIES
 / ENTRY ADDRESS TO SWPTR)
 / ON COMPLETION, INC. SECTOR COUNT, DO NEXT SECTOR.  ON LAST SECTOR
 / FINISH THE SWAP.
 SWPA,    SWPTR                  /RETURN ADDRESS AFTER SWAP
 
 SWPTR, JMP SWPERR      /OOPS
     TAD RKADR
     TAD C0400       /NEXT ADDRESS
     DCA RKADR
     TAD RKSWSE      /NEXT SECTOR
     IAC
     AND C0017   
     SNA             /SECTOR = 16? DONE?
     JMP SWFIN       /YEP, FINISH THINGS UP.
     DCA RKSWSE      /NO - DO NEXT SECTOR
     JMS SWPIO       /START NEXT SECTOR TRANSFER
     DISMIS          /GO BACK TO WHAT WE WERE DOING
 SWFIN, TAD FINISH   /DID WE JUST SWAP IN OR OUT?    
     SMA
     JMP SWPOK       /IN; SO WE'RE FINISHED
     CIA
     DCA FINISH      /SAVE IT
     JMS SWPIR       /START SWAP IN
     DISMIS          /GO BACK TO WHAT WE WERE DOING      
     

The above is only slightly larger than the original code. Like the original, it’s interrupt driven: SWPIN sets up a sector transfer then returns to the Monitor — the RK8E will interrupt the processor when this transfer is done, at which point the Monitor will jump to SWPTR to process it. SWPTR then determines if there are more sectors to transfer, and if so starts the next transfer, calculating the disk and memory addresses needed to do so.

After testing this code, TSS/8 would initialize and prompt for a login, and then hang attempting to do a filesystem operation to read the password database. Time to move on to the other routine that needed to be changed: the filesystem transfer code. This ended up being considerably more complicated than the swapping routine. As mentioned earlier, the RF08 and DF32 disks are word-addressable, meaning that any arbitrary word at any address on disk can be accessed directly. And these controllers can transfer any amount of data from a single word to 4096 words in a single request. The RK05 can only transfer a sector’s worth of data (256 words) at once and transfers must start on a sector boundary (a multiple of 256 words). The TSS/8 filesystem code makes heavy use of the flexibility of the RF08/DF32, and user programs can request transfers of arbitrary lengths from arbitrary addresses as well. This means that the RK05 code I’m adding will need to do some heavy lifting in order to meet the needs of its callers.

Like the swapping code, a single request may require multiple sector transfers to complete. Further, the new code will need to have access to a private buffer 256 words in length for the transfer of a single RK05 sector — it cannot copy sector data directly to the caller’s destination like it does with the RF08/DF32 because that destination is not likely to be large enough. (Consider the case where the caller wants to read only one word!) So for a read operation, the steps necessary are:

  1. Given a word address for the data being requested from disk, calculate the RK05 sector S that word lives in. (i.e. divide the address by 256).
  2. Given the same, calculate the offset O in that sector that the data starts at (i.e. calculate the word address modulo 256)
  3. Start a read from the RK05 for sector S into the Monitor’s private sector buffer. Return to the Monitor and wait for an interrupt signalling completion.
  4. On receipt of an interrupt, calculate the length of the data to be copied from the private sector buffer into the caller’s memory (the data’s final destination). Calculate the length L as 256-O (i.e. copy up to the end of the sector we read.)
  5. Copy L words from offset O in the private sector buffer to the caller’s memory.
  6. Decrement the caller’s requested word count by L and see if any words remain to be transferred: If yes, increment the sector S, reset O to 0 (we start at the beginning of the next sector) and go back to step 3.
  7. If no more words to be transferred, we’re done and we can take a break. Whew.

Doing a Write is more complicated: Because the offset O may be in the middle of a sector, we have to do a read-modify-write cycle: Read the sector first into the private buffer, copy in the modified data at offset O in the buffer, and then write the whole buffer back to disk.

This code ended up not fitting in Field 0 of TS8 — I had to move it into Field 1 in order to have space for both the code and the private sector buffer. So as not to bore you I won’t paste the final code here (it’s pretty long) but if you’re curious you can see it starting around line 6994 of ts8.pal.

This code while functional has some obvious weaknesses and could be optimized: the read-modify-write cycle for write operations is only necessary for transfers that start at a non-sector boundary or are less than a sector in size. Repeated reads from the same sector could bypass the actual disk transfer (only the first read need actually hit the disk). Similarly, repeated writes to the same sector need only commit the sector to disk when a new sector is requested. I’m waiting to see how the system holds up under heavy use, and what disk usage patterns emerge before undertaking these changes, premature optimization being the root of all evil and whatnot.

The first boot of TSS/8 on our PDP-8/e!

I tested all of these changes as I was writing them under SIMH, an excellent suite of emulators for a variety of systems including the PDP-8. When I was finally ready to try it on real hardware, I used David Gesswein’s dumprest tools to write the disk image out to a real RK05 pack, and toggled in the RK05 TSS/8 bootstrap I wrote to get INIT started. After a a couple of weeks of working only under the emulator, it was a real relief when it started right up the first time on the real thing, let me tell you!

TSS/8 is currently running on the floor at the museum, servicing only two terminals. I’m in the process of adding six more KL8E asynchronous serial lines so that we can have eight users on the system — the hope is to make the system available online early next year so that people around the world can play with TSS/8 on real hardware.

I’ve also been working on tracking down more software to run on TSS/8. In addition to what was already available on the RF08 disk image (PALD, BASIC, FOCAL, FORTRAN, EDIT) I’ve dug up ALGOL, and ported CHEKMO II and LISP over. If anyone out there is sitting on TSS/8 code — listings, paper tape, disk pack, or DECtape, do drop me a line!

And if you’re so inclined, and have your own PDP-8 system with an RK05 you can grab the latest copy of my changes on our Github at https://github.com/livingcomputermuseum/cpus-pdp8 and give it a whirl. Comments, questions, and pull requests are always welcome!

Unix Version 0 on the PDP-7 at LCM+L

In February 2016, a wonderful piece of news came to the attention of the international vintage computing community: The source of the original implementation of the Unix operating system, written for the DEC PDP-7 computer, had come to light, in the form of listings for the kernel and several user programs (including the editor and the assembler program). The announcement came from Warren Toomey, founder of The Unix Historical Society (TUHS) in Australia.

Warren asked if we might be interested in participating in the recovery of this historic software, and perhaps run it on the PDP-7 here.1 We were very interested, and Josh Dersch began thinking about how to do this without a disk drive, since our PDP-7 did not have one.

Two months later, Fred Yearian visited the museum and told us that he had a PDP-7 in the basement of his house. Fred, a retired Boeing engineer, had acquired the system many years earlier from Boeing Surplus, and kept it in semi-running condition. In 2018, Fred made arrangements to donate his PDP-7 to the museum, and it was moved to the computer room on the third floor, where Fred worked with Jeff Kaylin to put it into good running order.

This PDP-7 included a non-DEC interface which was installed by Boeing, and which was apparently a controller for a magnetic tape drive. Jeff and Fred traced the circuitry for the interface, and Jeff created schematics for it.

Fred had a utility program for the PDP-7 which was written as a set of binary numbers (represented in octal = base 8) in an assembly lnaguage program for a Varian minicomputer. He translated the binary representations of the PDP-7 instructions into an assembly language program for the PDP-7, which Rich Alderson compiled using a program for Windows originally created for the family of simulation programs for DEC’s 18 bit computers.2 Fred added new features as the restoration of his PDP-7 progressed and new needs were recognized.

Meanwhile, enthusiasts had added features to the SimH PDP-7 simulator such as a simulated disk of the kind used on the PDP-7 at Bell Labs where Unix was created, which allowed the operating system to be run under a PDP-7 simulation. Some programs were missing from the source listings provided to Warren Toomey, including the shell command processor, and these had to be recreated from scratch based on early documentation and programming notes.

As part of our Unix@50 programming, celebrating the 50th anniversary of the Unix operating system, we moved Fred’s PDP-7 from the third floor computer room to the second floor exhibit hall in June 2019. It formed one of the anchors of a private event hosted by https://SDF.org for attendees of the Usenix Technical Conference in July.

Following the move to the exhibit hall, Fred and Jeff continued the restoration in view of the public, answering questions as they worked. Jeff also designed a device, dubbed the JK09,3 which looks to the PDP-7 like a kind of disk connected to the interface installed by Boeing. Once that was debugged, it was time for the software to be revisited.

Josh Dersch took the lead, copying the Unix Version 0 sources and modified SimH PDP-7 simulator from GitHub, then modifying that to use the JK09 device instead of the RB09 simulated by SimH. Once he had Version 0 running under SimH, he created a disk image which was loaded into the JK09 attached to the PDP-7, and Unix was booted on the system.