PDP-10/its: building the Incompatible Timesharing System from source

An operating system from 1960s, still running

The description is three lines and it is the whole story.

ITS, the Incompatible Timesharing System, is an operating system for the PDP-10 computer family. It was created by hackers at MIT in the 1960s. The MIT site was shut down in 1990, but enthusiasts continue to operate ITS systems to this day.

The name is the joke and the joke is the point. The system was called incompatible because it was, deliberately, a different thing from the other timesharing systems available at the time, and the name was adopted with a straight face. The MIT operation is the part that surprises people: a research operating system that ran a community of users for decades, and then a group of enthusiasts who kept running it afterwards.

That is why a repository like this exists at all. A PDP-10 is a machine you can buy parts for and never assemble, so the only way to run ITS is on an emulator, and the only way to get ITS onto an emulator is to build it. Which brings the repository's stated purpose: it contains source code, tools and scripts to build an ITS system from scratch.

The primary language in the repository is assembly, with the rest in the various languages the system hosted, which is a good indicator of what you are looking at. It is not a modern operating system, and it is not pretending to be.

The feature list reads like a wish list from 1968

The notable features are listed, and they are worth reading as a snapshot of what a hacker operating system in the 1960s thought mattered.

It hosted the first versions of Emacs, Zork, Macsyma, Maclisp, Scheme and multi-player Maze War. That list is the legacy: those are still the programs people run on ITS today, and most of them were written by the same small group of people who wrote the system.

Then the technical features. Virtual memory. User-space device drivers. Networking with TCP/IP, ARPAnet and Chaosnet, the last of which was MIT's own network and the reason Chaosnet has its own repository elsewhere. A transparent network file system, so a file on a remote machine looks like a local file. Terminal-independent text output. And graphical workstations.

User-space device drivers in the 1960s is the item that would have surprised a contemporary systems programmer, and it is the feature that most directly shaped the architecture: a driver that runs in user space is a driver that can crash without taking the system down, which is exactly the kind of bet a small group of hackers would make and then argue about for twenty years.

The terminal-independent output and the network file system are the two that make the emulator story work, because they are what allow a modern machine to present a 1960s system sensibly.

The goals are about the build, not the system

The about-this-project section states the goals, and they are surprisingly modern in their framing.

The first is to provide an automated build from start to end, with no user intervention necessary. The second is to check which programs have source code and which are missing source code, with a link to the tracking issue. The third is to ensure that we know how to build all programs. The fourth is to update programs with the latest bug fixes and enhancements. And the fifth is to be able to set configurable options across the whole system, such as host name, IP address and hardware devices.

Read together, those are the goals of a reproducible build system, and the second and third are the ones that catch the eye. A repository that knows which of its programs have no surviving source is doing something that a modern project would call provenance, and the fact that it can state a number, because the missing ones are tracked as issues, is the kind of honesty that is unusual in a retro project.

The build runs on the SIMH and KLH10 emulators, and the readme adds a line that says the maintainers would be delighted to test it on a real KS10. Which is a nice way of saying that the real hardware is out of reach, and that the emulators are the supported path.

The fifth goal is the one that makes the thing usable. A timesharing system has a host name and an address baked into it, and being able to change those from configuration is what turns a fixed museum piece into something you can put on a network and talk to.

One make command, five emulators

The build instructions are a single command with a variable, and the dependency table that follows is honest about what each option needs.

make EMULATOR=simh

The other options are the KA, the KL, the KS and the KLH10, and the result is left in an output directory, some of the files in which are disk images with ITS already installed.

The dependency lists differ by emulator and the differences are meaningful. The KLH10 needs the shortest list, with git, a C compiler, make, expect, curses and autoconf. The SIMH build adds the SDL2 libraries. The KA and the KL builds add the image and network components of SDL2 and the GTK3 toolkit, and the KS needs only the base SDL2. That spread is a direct consequence of what each emulator can display, since the ones that can render a graphical terminal need a graphics stack.

Expect appearing in every list is worth a note. It is the tool used to drive the interactive parts of a build, which is exactly what you need when a step has to type commands at a running system and react to what comes back. A build of a 1960s operating system involves a lot of that, and the presence of expect in the requirements is a good hint about the shape of the process.

The Makefile itself shows the same care. The emulator variable defaults to one of the PDP-10 models, and the machine code is derived from it, with the host name updated accordingly unless the machine is the DEC one. It includes the network configuration from a separate file, and it maintains a long list of source directories, each of which is a program in the system, and it is those directories that get placed on the sources tape.

So the build is a list of programs, and the build system is the thing that knows how to assemble and install each of them.

Getting in, and the telnet ports

The usage section is the part most people will actually use, and it is written as a sequence of keystrokes, which is appropriate.

You start the system with a script, and then the sequence depends on which emulator you are in. On the KLH10 you type go at the prompt. On the others you get a disk dump prompt, and you type its and then a key combination to get to the system console, and eventually a message tells you the system job is using that console, at which point you log in with a control key combination. The documentation has a separate page listing useful commands for the debugger, and another page for creating a new user.

There is a second way in, and it is the one most people want. Instead of logging in at the system console, which is always showing daemon messages, you can open a separate terminal session and connect over telnet to a port, and then log in there with the same control key combination.

telnet localhost <port>

The port depends on the emulator, and the table gives the mapping. On the KA, the ports are 10000 for a time-sharing system, 10002 for a Datapoint kludge, and 10003 for a Morton box. On the SIMH and the KS it is 10004 for a DZ11. On the KL it is 10007 for a DTE2, and 10008 is listed for a DL10.

Shutting down has the same attention to detail. You lock the system, and then take it down, and the readme warns you to log yourself out first to avoid a five minute grace period, and tells you to wait for a message saying the shutdown is complete before stopping the emulator. Then a control key combination gets you back to the simulator prompt, and a command closes it.

Terminal emulators, and a matrix of what works where

ITS had its own peripherals, and the repository builds emulators for several of them, which is a lovely problem to have.

The list is a set of real machines from the period. There is a type 340, which was a vector display. There is the GT40, which was a PDP-11 graphics system, and an Imlac PDS-1, which was a vector display with a different lineage, along with a version of it built for the SIMH emulator. There is the Knight TV, a PDP-11 system, and a console for it, with the latter being a raster display rather than a vector one. There is a Datapoint 3300, a text terminal. There is a VT52, and a Tektronix 4010, which is a vector display.

The table that follows is a compatibility matrix, and it is the most informative artefact in the readme. It has a column per PDP-10 emulator and a row per peripheral, and the cells say whether the combination is set up to work.

The pattern is clear. The VT52, a text terminal, works with every emulator including the KLH10. The Tektronix vector display works with the KA, the KL and the SIMH. The graphical and vector machines, the type 340, the Imlac and the Knight TV console, only work with the KA, with the exceptions of the Imlac clone and the GT40, which also run on the SIMH and the KS.

So the KA emulator, which is the default the Makefile chooses, is the one with the deepest peripheral support, and that is a good reason to start there if you want to see the graphical workstations rather than a text terminal.

The repository layout, the docs and the applications

The tree is organised by build stage, and the readme walks through it.

There is a directory of binary files necessary to bootstrap the system, the build scripts, the configuration for building ITS, the documentation, the source code for ITS and all the programs, the build tools, the build output, and a directory of optional user files installed into the running system.

The documentation is the part that makes this more than a curiosity. Most of it appears in the system's own documentation system, so the manuals are part of the operating system, and then there is a set of short introductions for beginners, with a page for creating a new user, a debugger cheat sheet for people used to Unix, a guide to basic editing in the editor, a survival guide for the text editor, a debugging guide for newcomers, an introduction to the assembler, an introduction to the Lisp, an introduction to the Muddle language, a page on the dump and the star utility, a page on games, one on printing, one on assembling the system, one on the communication link, one on the logo language, one on the older machine, and one on networking.

The applications list is the other half of the story, and it is a period piece. There is the adventure game, a C compiler, a language called CLU, the debugger, the editor, the logo interpreter, two chess programs, the Lisp and the Muddle interpreters, the symbolic math system, the maze game, the assembler, the music players, and the editor's predecessor.

The repository carries several continuous integration configurations, and the readme is clear that the whole point is that a build needs no human at the keyboard.

Editorial conclusion

PDP-10/its suits a retrocomputing or computer history enthusiast who wants the original operating system running rather than a museum reconstruction, and it is a remarkable reference implementation of a build system for a machine with no remaining hardware. It is a poor fit as a source of operating system code to learn from, because the code is authentic rather than modern, and a poor fit if you need the build to be reproducible outside a Unix-like environment, since the toolchain expects a Unix shell with the usual tools. Before you start, pick the emulator you want, because the dependency list differs, and read the build documentation, since the documentation for the build itself lives in the repository rather than only in the readme.

Frequently asked questions

Official sources

1. Issues
2. PDP-10/its on GitHub
3. README