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.

First languages: Rich Alderson

I was introduced to computers in the form of “Computer Math”, a high school class in programming in FORTRAN IV on the IBM 1401. My first exposure was as a guest of friends from the chess club, who were taking CM in the autumn of 1968; I was sorry that I had not known about the 1-semester class when I was signing up for my senior classes the previous spring.

This was the second year the class was taught, and demand was so high that the school district decided to offer it again in the spring. I rearranged my schedule, with the aid of the faculty adviser of the chess club (chair of the English department), and so began my life with computers.

The FORTRAN class was the usual, with lots of math oriented assignments as one might expect, since the teacher was the chair of the Math department. We learned to calculate areas of triangles, parallelograms, and so on, and how to make the printer and card punch do tricks. Exciting stuff (NOT).

Fortunately for me, my friends from the chess club were offered the opporunity to do a second semester of programming, taking classes in COBOL and PL/1 on Saturdays at the Illinois Institute of Technology. They used programmed instruction texts (read a paragraph or two, answer a question, see the answer on the next page, lather, rinse, repeat to end of book). I borrowed the two texts, read them cover to cover over the weekend, and proceeded to do all my assignments in 3 different languages.

I quickly fell in love with PL/1, which combined the mathematical capabilities of FORTRAN IV with the commercial processing capabilities of COBOL, and threw in marvelous string handling. Since I was interested in human languages already, this was a wonder and delight to me, to be able to string characters together on the fly instead of laboriously building a FORMAT statement to print a single line of text over and over.

For our final project in Computer Math, we were allowed to choose from several possibilities, such as “compute pi or e to 1000 places”. One possibility was to calculate the payroll for a mythical company; this is what I chose. I even used the 1968 tax tables, which included formulae for each bracket, to calculate deductions from people’s checks.

When it came time to turn in our projects, I showed the teacher all three versions of my program. He was dumbfounded. I got an A.

That began my lifelong interest in programming languages. Over the years, I have learned a couple of dozen, and have written compilers or interpreters for a few. I was always more interested in what I could do with a computer than in the physical details of how the computer worked, for years and years. That lasted until I went to work for a company building a new generation of one of the systems on which I made a living for decades.

But that’s a topic for another day.

First computers: Rich Alderson

I first learned to program on a 1401, a commercial computer from IBM. The particular system on which I learned FORTRAN IV had 12K characters in memory, a 1402 card reader/punch, a 1403 printer, and two 1311 disk drives with a whopping 400K character capacity. The character encoding was Binary Coded Decimal (BCD).

Note that I said “character” rather than “byte”. The 1401 came out in 1960, before the term byte came into broad use; originally, “byte” referred to portions of a longer memory word and did not refer to a specific size.

Characters are addressable in the 1401, and consist of 6 data bits, a parity bit, and a word mark bit which is used to define larger areas (“fields”) in memory. We’ll come back to the word mark in a moment.

The data bits in a character are labeled B-A-8-4-2-1. The B and A bits are called “zone bits”, and map fairly directly to zone punches on a Hollerith card to define alphabetic and special characters. The numeric bits directly encode the decimal digits 1-9 in binary; zero (“0”) is encoded specially, as 8+2, so that a space character can be represented as having no bits turned on at all. Alphabetics and special characters use a combination of numeric bits and one or both zones (e.g., “A” is B-A-1, “I” is B-A-8-1).

Data is operated on in fields, addressed by the highest numbered character in memory for each field. Processing of data begins at that location, and moves lower in memory for each step in the process: For example, addition starts with the 1’s place, then moves to the 10’s place, the 100’s place, etc. How do we know when to stop? This is the purpose of the word mark bit! The lowest numbered character in the field has the word mark turned on (set to 1), and the hardware takes notice of this and stops when that character is processed.

All of this is invisible to a FORTRAN programmer, or a user of any other high level language such as COBOL or RPG, but it is critical to anyone who needs to write in a machine language representation like an assembler program. The 1401 comes with two assemblers, the earlier, more primitive Symbolic Programming System (SPS) and the more powerful Autocoder.

The 1401 instruction set consists of individual characters, chosen to be mnemonic wherever possible: _A_ is the Add instruction, and _M_ is the Move instruction which transfers data from one field to another. SPS uses the instruction characters directly, so that a programmer has to know each one, and numeric addresses of fields. Autocoder instead uses English words such as “ADD” and “MOVE” for instructions, and allows the use of names with lengths assigned in place of numeric addresses for fields.

Finally, there are three predefined fields in memory which are used to move data between the card reader, the card punch, and the printer: Word marks are permanently set at locations 1, 101, and 201; a MOVE from location 80 reads a card from the reader and puts the new data into the destination field, a MOVE into location 180 punches a card from the source field, and a MOVE into location 333 causes a 132 character line to be printed. (The first character in a printed line does things like skip to a new page or double space).

That’s the first computer I used–even though I didn’t learn the messy internals for several years!

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.