Rich Alderson – ENGBLG

The XKL Toad-1 System

The XKL Toad-1 System (hereafter “the Toad”) is an extended clone of the DECSYSTEM-20, the third generation of the PDP-10 family of computers from Digital Equipment Corporation. What does that mean? To answer that requires us to step back into the intertwined history of DEC, BBN,¹ SAIL,² and other parts of Stanford University’s computing community and environs.

It’s a long story. Get comfortable. I think it will be worth your time.

The PDP-10

The PDP-10 family (which includes the earlier PDP-6) is a typical mainframe computer of the mid-1960s. Like many science oriented computers prior to IBM’s System/360 line, the PDP-10 architecture addressed binary words which were 36 bits long, rather than individual characters as was common in business oriented systems. In instructions, memory addresses took up half of the 36 bit word; 18 bits is enough to address 262,144 locations, or 256KW, a very large memory in the days when each bit of magnetic core cost about $1.00.³ Typical installations had 64KW or 96KW attached. The KA-10 CPU in the first generation PDP-10⁴ could not handle any more memory than that.

Another important feature of the PDP-10 was timesharing, a facility by which multiple users of the computer each was given the illusion that each was alone in interacting with the system. The PDP-6 was in fact the first commercially available system to feature interactive timesharing as a standard facility rather than as an added cost item.

TENEX

In the late 1960s, virtual memory was an important topic of research: How to make use of the much larger, less expensive capacity of direct access media such as disks and drums to extend the address space of computers, instead of the very expensive option of adding more core.⁵ One company which was looking at the issue was Bolt, Beranek, & Newman, who were interested in demand paged virtual memory, that is, viewing memory as made up of chunks, or pages, accessed independently, and what an operating system which had access to such facilities would look like.

To facilitate this research, BBN created a pager which they attached to a DEC PDP-10, and began writing an operating system which they called TENEX for “PDP-10 Executive”⁶ TENEX was very different from Tops-10, the operating system provided by DEC, but was interactive in the same way as the older OS. The big difference was that more programs could run at the same time, because only the currently executing portions of each program needed to be present in the main (non-virtual) memory of the computer.

TENEX was popular operating system, especially in university settings, so many PDP-10s had the BBN pager attached. In fact, the BBN pager was also used on a PDP-10 system which ran neither TENEX nor Tops-10, to wit, the WAITS system at SAIL.⁷

The DECsystem-10

The second generation of the PDP-10 underwent a name change, to the DECsystem-10, as well as gaining a faster new processor, the KI-10. This changed the way memory was handled, by adding a pager which divided memory up into 512 word blocks (“pages”). Programs were still restricted to 18 bits of address like previous generations, but the CPU could now handle 22 bits of address in the pager, so the physical memory could be up to four megawords (4MW), which is 16 times as much as the KA-10.

This pager was not compatible with, and was much less capable than, the BBN device, although DEC provided a version of TENEX modified to work with the KI pager for customers willing to pay extra. Some customers considered this to be too little, too late.

SAIL and the Super FOONLY

In the late 1960s, computer operating systems were an object of study in the broader area of artificial intelligence research. This was true of the Stanford Artificial Intelligence Laboratory, for example, where the PDP-6 timesharing monitor⁸ had been heavily modified to make it more useful for AI researchers. When the PDP-10 came out three years later, SAIL acquired one, attached a BBN pager, and connected it to the PDP-6, modifying the monitor (now named Tops-10) to run on both CPUs, with the 10 handing jobs off to the 6 if they called for equipment attached to the latter. By 1972, the monitor had diverged so greatly from Tops-10 that it received a new name, WAITS.

But the hardware was old and slow, and a faster system was desired. The KI-10 processor was underpowered from the perspective of the SAIL researchers, so they began designing their own PDP-10 compatible system, the Super FOONLY.⁹ This design featured a BBN style pager and used very fast semiconductors¹⁰ in its circuitry. It also expanded the pager address to 22 bits, like the KI-10, so was capable of addressing up to 4MW of memory. Finally, unlike the DEC systems, this system was build around the use of a fast microcoded processor which implemented the PDP-10 architecture as firmware rather than as special purpose hardware.

DECSYSTEM-20 and TOPS-20

DEC was aware of the discontent with their new system among customers; to remedy the situation, they purchased the design of the SuperFOONLY from Stanford, and hired a graduate student from SAIL to install and maintain the SUDS drawing system at DEC’s facilities in Massachusetts. The decision was made to keep the KI-10 pager design in the hardware, and implement the BBN style pager in microcode.

Because of the demand for TENEX from a large part of their customer base, DEC also decided to port the BBN operating system to the new hardware based on the SAIL design. DEC added certain features to the new operating system which had been userland code libraries in TENEX, such as command processing, so that a single style of command handling was available to all programmers.

When DEC announced the new system as the DECSYSTEM-20, with its brand new operating system called TOPS-20, they fully expected customers who wanted to use the new hardware would flock to it, and would port all of their applications from Tops-10 to TOPS-20, even though the new OS did not support many older peripherals on which the existing applications relied. The customers rebelled, and DEC was forced to port Tops-10 to the new hardware, offering different microcode to support the older OS on the new KL-10 processor.

Code Name: Jupiter

DEC focused on expanding the capabilities of their flagship minicomputer line, the PDP-11 family, for the next few years, with a planned enhancement to take the line from 16 bit mini to 32 bit supermini. The end result was an entirely new family, the VAX, which offered virtual memory like the PDP-10 mainframes in a new lower cost package.

But DEC did not forget their mainframe customer base. They began designing a new PDP-10 system, intended to include enhanced peripherals, support more memory, and run much faster than the KL-10 in the current Dec-10/DEC-20 systems. As part of the design, codenamed “Jupiter”, the limited 18 bit address space of the older systems was upgraded to 30 bits, that is, a memory size of one gigaword (1GW = 1024MW), which was nearly 2.5 times the size of the equivalent VAX memory, and far larger than the memory sizes available in the IBM offerings of the period.

Based on the promise of the Jupiter systems, customers made do with the KL-10 systems which were available, often running multiple systems to make up for the lack of horsepower. Features were added to the KL, by changes to the microcode as well as by adding new hardware. The KL-10 was enhanced with the ability to address the new 30-bit address space, although the implementation was limited to addressing 23 bits (where the hardware only handled 22); thus, although a system maxed out at 4MW, virtual memory could make it look like 8MW.

DEC also created a minicomputer sized variant of the PDP-10 family, which they called the DECSYSTEM-2020. This was intended to extend the family into department sized entities, rather than the corporation sized mainframe members of the family.¹¹ There was also some interest in creating a desktop variant; one young engineer was well known for pushing the idea of a “10 on a desk”, although his idea was never prototyped at DEC.

DEC canceled the Jupiter project, apparently destined to be named the DECSYSTEM-40, in May 1983, with an announcement to the Large Systems customers at the semiannual DECUS symposia. Customer outrage was so great that DEC agreed to continue hardware development on the KL-10 until 1988, and software development across the family until 1993.

Stanford University Network

In 1980, there were about a dozen sites at Stanford University which housed PDP-10 systems, mostly KL-10 systems running TOPS-20 but also places like SAIL, which had attached a KL-10 to the WAITS dual processor. Three of the TOPS-20 sites were the Computer Science Department (“CSD”), the Graduate School of Business (“GSB”), and the academic computing facility called LOTS.¹²

At this time, local-area networking was seen as a key element in the future of computing, and the director of LOTS (whom we’ll call “R”) wrote a white paper on the future of Ethernet¹³ on the campus. R also envisioned a student computer, what today we would call a workstation, which featured a megabyte of memory, a million pixels on the screen, a processor capable of executing a million instructions per second, and an Ethernet connection capable of transferring a millions bits of data per second, which he called the “4M machine”.

Networking also excited the director of the CSD computer facility, whom we’ll call “L”.¹⁴ L designed an Ethernet interface for the KL-10 processors in the DEC-20s which were ubiquitous at Stanford. This was dubbed the Massbus-Ethernet Interface Subsystem, or MEIS,¹⁵ pronounced “maze“.

The director of the GSB computer facility, whom we’ll call “S”, was likewise interested in networking, as well as being a brilliant programmer herself. (Of some importance to the story is the fact that she was eventually married to L.) S assigned one of the programmers working for her to add code to the TOPS-20 operating system to support the MEIS, using the PUP protocols created at PARC for the Alto personal computer.¹⁶

The various DEC-20 systems were scattered across the Stanford campus, each one freestanding in a computer room. R, L, and S ran miles of 50ohm coaxial cable, the medium of the original Ethernet, through the so-called steam tunnels under the campus, connecting all the new MEISes together. Now, it was possible to transfer files between DEC-20s from the command line rather than by writing them to a tape and carrying them from one site to another. It was also possible to log in from one DEC-20 to another–but using one mainframe to connect to another seemed wasteful of resources on the source system, so L came up with a solution.

R’s dream of a 4M machine had borne fruit: While still at CSD, he had a graduate student create the design for the Stanford University Network processor board. L repurposed the SUN-1 board¹⁷ at the processor in a terminal interface processor (“EtherTIP”), in imitation of the TIPs used by systems connected to the ARPANET and to commercial networks like Tymnet and Telenet. Now, instead of wiring terminals directly to a single mainframe, and using the mainframe to connect from one place to another, the terminals could be wired to an EtherTIP and could freely connect to any system on the Ethernet.

A feature of the PUP protocols invented at PARC was the concept of internetworking, connecting two or more Ethernets together to make a larger network. This is done by using a computer connected to both networks to forward data from each to the other. At PARC, a dedicated Alto acted as the router for this purpose; L designated some of the SUN-1 based system as routers rather than as EtherTIPs, and the Stanford network was complete.

Stanford University also supported a number of researchers who were given access to the ARPANET as part of their government sponsored research, so several of the PDP-10s on campus were connected to the ARPANET. When the ARPANET converted to using the TCP/IP protocols which had been developed for the purpose of bring internetworking to wide area networks, our threesome were ready, and assigned programmers from CSD, GSB, and LOTS to make L’s Ethernet routers speak TCP/IP as well as PUP. TOPS-20 was also updated to use TCP/IP, by Stanford programmers as well as by DEC.

S and L saw a business opportunity in all this, and began a small company to sell the MEIS and the associated routers and TIPs to companies and universities who wanted to add Ethernet to their facilities. They saw this as a way to finance the development of L’s long-cherished dream of a desktop PDP-10. They eventually left Stanford as the company grew, as it had tapped the exploding networking market at just the right time. The company grew so large in fact that the board of directors discarded the plan to build L’s system, and so the founders left Cisco Systems to pursue other opportunities.

XKL

L moved to Redmond in 1990, where he founded XKL Systems Corporation. This company had as its business plan to build the “10 on a desk”. The product was codenamed “TOAD”, which is what L had been calling his idea for a decade and a half because “Ten On A Desktop” is a mouthful. He hired a small team of engineers, including his old friend R from Stanford, to build a system which implemented the full 30-bit address space which DEC had abandoned with the cancelled Jupiter project, and which included modern peripherals and networking capabilities.¹⁸ R was assigned as Chief Architect; his job was to insure that the TOAD was fully compatible with the entire PDP-10 family, without necessarily replicating every bug in the earlier systems.

R also oversaw the port of TOPS-20 to the new hardware, although some boards¹⁹ had a pair of engineers assigned: One handled the detailed design and implementation of the board, while the other worked on the changes to the relevant portion of the operating system. R was responsible for the changes which related to the TOAD’s new bus architecture, as well as those relating to the much larger memory which the TOAD supported and the new CPU.²⁰

The TOAD was supposed to come to market with a boring name, the “TD-1”, but ran into trademark issues. By that time, I was working at XKL, officially doing pre- and post-sales customer advocacy, but also working on the TOPS-20 port.²¹ Part of my customer advocacy duties was some low-key marketing; when we lost the proposed name, I pointed out that people had been hearing about L’s TOAD for years, and we should simply go with it; S, considered the unofficial “Arbiter of Taste” at XKL, agreed with me.²² We officially introduced the XKL Toad-1 System at a DECUS trade show in the spring of 1995.

On COBOL and Legacy Systems

Two recent articles¹ (and I’m sure there are more which I haven’t seen yet) responding to a call for help from Gov. Phil Murphy of New Jersey decry the continued use of the COBOL programming language in legacy systems which have been in place for decades.

What’s irritating about these articles is the notion that COBOL is outmoded, outdated, old fashioned, because the language was first defined and implemented more than 60 years ago, and the applications which are having issues currently were written more than 40 years ago. I say, so what?

I spent several years—40 years ago!—programming in COBOL, supporting the financial systems of the University of Chicago. The most important thing to remember in financial systems is the maxim, If it ain’t broke, don’t fix it! The second is When it breaks, fix it right!

COBOL had two standards when I used it in my job, from 1968 and 1974. The differences were minuscule, mostly tightening up some ambiguities and eliminating minor features which had proven unuseful. Since then, new standards addressing new conditions came out in 1985 (structured programming primitives, freeform source permitted), 2002 (object-oriented paradigm added), and 2014 (whose changes I haven’t seen, yet, but I will, just because). Contrast this stability with the weekly updates from Microsoft, Apple, and the GNU/Linux communities.

The article by Steinberg points to the “pain” suffered in legacy systems when the so-called Y2K bug was a concern in the late 1990s. As those of us in the industry since the late 1960s are aware, that was a great deal of worry over nothing, because we had been aware of the possibility of our systems lasting that long when we wrote them. Yes, there were managers who insisted that none of this code would last long enough for two-digit years to be an issue, but front-line programmer/analysts who were supporting legacy code from the 1950s knew better, and did the right thing.

Those who do not know COBOL buy into the notion that somehow it is less secure because it is old, but data security has always been a concern in financial systems in traditional data processing shops, where the mainframe has been king all along. Who has ever heard of an on-line exploit targeting a weakness of a COBOL program running on a mainframe operating system, whether IBM or Unisys?² The security systems created for those operating systems have always been strong, and were very rarely (never?) retrofits trying to fix weaknesses discovered by crackers.³

So, in my not so very humble opinion, the call to scrap these legacy systems and redo all the work in the flavor of the moment system is misguided, to say the least. The governor has the right idea: Get some people who know COBOL to fix the problems the right way, perhaps updating the language used where that is called for, and move on smartly. His call for “volunteers” to do the work is a wistful dream, of course, because the people who can do this work command hourly rates in the range of $200/hour, but they’re out there if the State of New Jersey is willing to do things right.

Of course, that’s just my opinion. I could be wrong.
–Dennis Miller

The PDP-10, Macro-10, and Altair 8800 BASIC

When the Altair 8800 microcomputer was announce by MITS in the January 1975 issue of Popular Electronics, it excited the dreams of two young men in Cambridge, Massachusetts, Paul Allen and Bill Gates. These two had long wanted to write a version of the BASIC language in which they had first learned to program several years earlier in High school, and here was a system for which they could do that.

How do you write a program for a computer which you don’t have? You use another computer and write a program to write your programs with. Paul Allen had already done this once, for an earlier project called Traf-o-Data which the two had created. To understand how it worked, we’ll first look at the computer on which they first developed their skills at system design and programming, the Digital Equipment Corporation PDP-10¹.

The PDP-10

The PDP-10² was the second generation of a line of mainframe computers from DEC, introduced in 1967 as a follow-on to the PDP-6 using the technology invented for the PDP-7 minicomputer. These systems arose in a time before the ubiquitous fixed size 8-bit byte, following an older standard with 36 bits per word in memory or on tape or disk media. Here, bytes were defined by the programmer for specific uses, and could be anywhere from 1 to 36 bits long as needed.

A feature of the PDP-10 which is important for our story has to do with the machine language of the central processor, which divides the 36 bit word³ up into several meaningful portions: A 9 bit instruction specifying an operation (“opcode”), 4 bits to select a register destination for the operation (“AC”), 1 bit to indicate whether the operation takes place on the data pointed to by the instruction or instead on data pointed to by the address pointed to by the instruction (“indirect”), 4 bits to select a register holding part of the address on which the instruction will operate (“index”), and 18 bits specifying part or all of the address or data on which the instruction will operate (“address”).

Now 9 bits can specify up to 512 different possible instructions, but the PDP-10 only defines a few more than 360.⁴ In most processors, that would be the end of the discussion, but DEC did things differently: They created a way for the otherwise unused instructions to be available to the programmer or the operating system, and called them UUOs.⁵ There were 2 classes of UUOs: “Monitor UUOs”, defined as opcodes 040-077,⁶ are used by the operating system⁷ to implement complex system calls such as opening files, moving data between peripherals, etc., while “user UUOs” (opcodes 001-037) were available to any programmer as a fast way to call routines in her program in the same way system calls worked.⁸

The monitor UUOs are assigned names like OPEN, CLOSE, INPUT, and so on, so that the programmer can simply use them like other instruction mnemonics like MOVE or ADD, but the user UUOs do not have names since they are intended to be program specific. The assembler language program, called Macro-10, provides a way to give a name to an operation, and will use that name just like the predefined mnemonics provided by DEC.

Macro-10

Assembler programs have existed since the early days of computing, as a way to eliminate programmer errors introduced by translating instructions into numerical representations by hand. They originated as simple tables of substitutions, but grew in capabilities as experience showed the possibilities for computers to manipulate text files. The most important such capability was the invention of “macroinstructions”, a way for the programmer to define a group of instructions which differed in specific ways which could be defined so that the assembler program could build a program more efficiently. An example will make this more clear.

The idea of a macro is to give a name to a block of text. Then when we mention the name, the corresponding text appears in the program and is treated by the assembler as if it were there all along. Our specific example is⁹

        MOVEI   2,15
        IDPB    2,1
        MOVEI   2,12
        IDPB    2,1
        MOVEI   2,0
        IPDB    2,1

This code takes a byte pointer in location A which points to the end of a text string, and adds an ASCII carriage return (octal 15 = ^M = CR), line feed (octal 12 = ^J = LF), and a null character (octal 0 = ^@ = NUL) to the end of the string.

Writing these 6 lines of code repeatedly throughout a program would be tiresome, so we define a macro to do this for us:

    DEFINE ACRLF <
        MOVEI   2,15
        IDPB    2,1
        MOVEI   2,12
        IDPB    2,1
        MOVEI   2,0
        IPDB    2,1 >;End of ACRLF

We can now use ACRLF to “Add a CR and LF” anywhere in our program that we might type an instruction.

Suppose we want to be able to put a byte from any AC, not just 2, into any string pointed to by a byte pointer, not just AC 1. In that case, we define our macro to take arguments, which will be substituted for by the assembler program when the macro is used:

    DEFINE ACRLF (ACC,BYP) <
        MOVEI   ACC,15
        IDPB    ACC,BYP
        MOVEI   ACC,12
        IDPB    ACC,BYP
        MOVEI   ACC,0
        IPDB    ACC,BYP >;End of ACRLF

Now, to use our macro to pad the string pointed to by PTR-1(Y) using the AC which we have named C in our program:

        ACRLF C,PTR-1(Y)

which will expand to (that is, the following code will appear to the assembler as if we had typed it in directly)

        MOVEI   C,15
        IDPB    C,PTR-1(Y)
        MOVEI   C,12
        IDPB    C,PTR-1(Y)
        MOVEI   C,0
        IPDB    C,PTR-1(Y)

Why is this important?

Paul Allen’s 8008 Simulator Program

Years before Microsoft, Paul Allen and Bill Gates started another company called Traf-o-Data, to build a traffic counter using the Intel 8008 microprocessor chip. While the Traf-o-Data hardware was being designed an built, Paul wanted to begin programming the 8008 but had no computer for the purpose, so he wrote a PDP-10 program to simulate the chip instead.¹⁰

The way it worked was simple. Intel published a data sheet which described what each instruction did with every 8 bit byte decoded. Paul wrote routines to perform the same operations on data in the PDP-10, storing the 8 bits of the 8008’s words in the 36 bits of the PDP-10’s. He defined UUOs to call these routines, and wrote macros which looked like the 8008 instructions published by Intel but expanded into his PDP-10 UUOs when assembled with Macro-10. Now Paul and Bill could write 8008 code for their Traf-o-Data hardware and test the resulting program using a PDP-10!

Altair BASIC

Paul had always wanted to write a version of BASIC, but Bill pointed out the inadequacy of the 8008 for Paul’s ideas. Not to be put off, Paul kept watching the news of the electronics world, and when Intel brought the 8080 he noted to Bill that all of the objections to the 8008 had been addressed in the new chip. Bill responded that no one build a computer which used the 8080. That was the state of things when the January 1975 issue of Popular Electronics hit the news stands in mid-December 1974, announcing the Altair 8800.

Paul and Bill were excited to learn that although the PE article said that BASIC was available for the new computer, no such program existed yet. Paul revised his 8008 simulator for the 8080 instruction set, and they began writing a version of BASIC using the new simulator program to test their code.

The 8080 simulator still exists on DECtapes belonging to Paul Allen’s estate. The contents of these tapes were copied onto the XKL Toad-1 which Paul purchased in 1997, and later onto the DECSYSTEM-2065 on which he debugged the early version of Altair BASIC which also resides on those DECtapes and which he demonstrated for Leslie Stahl on “60 Minutes” in 2011.

The following is a typeout of a short session on the DECsystem-10 at LCM+L with the 8080 simulator running an early version of Altair BASIC:

 *
 * Authorized users only - All activity is monitored.
 * To request access visit https://livingcomputers.org
 * Visit https://wiki.livingcomputers.org for documentation.
 *
 * Use ssh kl2065@tty.livingcomputers.org to connect.
 *
 * CTRL-] quit to return to the menu
 *
 PDPplanet DECsystem-10 #3530 TOPS-10 v7.04 
 .login alderson
 Job 16  PDPplanet DECsystem-10  TTY7
 Password: 
 [LGNLAS Last access to [20,20] succeeded on 24-Mar-120:12:38:55]
 14:09   24-Mar-120   Tuesday

 .run tbasic[20,10]

 * SIM-8080 EXECUTION *
 
 MEMORY SIZE? 8192

 STRING SPACE? 1024

 WANT SIN-COS-TAN-ATN? Y

 1276 BYTES FREE

 ALTAIR BASIC VERSION 1.1
 [EIGHT-K VERSION]

 OK
 PRINT 2+2

 4 

 OK
 10 FOR I=0 TO 10

 20 PRINT I

 30 NEXT I

 40 END

 LIST

 10 FOR I=0 TO 10
 20 PRINT I
 30 NEXT I
 40 END
 OK
 RUN

  0 
  1 
  2 
  3 
  4 
  5 
  6 
  7 
  8 
  9 
  10
 
 OK
 ^C

 .kjob
 Job 16  User ALDERSON [20,20]
 Logged-off TTY7  at 14:11:36  on 24-Mar-120
 Runtime: 0:00:01, KCS:40, Connect time: 0:02:04
 Disk Reads:173, Writes:6, Blocks saved:80570

Descendants of this simulator were used at Microsoft to write a number of products to the end of the 1980s, when microcomputers finally became powerful enough to host sophisticated development environments.

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!

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.¹ 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.² 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,³ 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.

IBM at LCM+L

As anyone familiar with LCM+L knows, the museum initially grew out of Paul Allen’s personal collection of vintage computers. Many of the larger systems in the collection reflected his own experiences with computers beginning in when he was still in high school. Among the systems he used then were System/360 mainframes manufactured by IBM, most of them stodgy batch processing systems with little appeal for a young man who had been exposed to interactive computing on systems from General Electric and Digital Equipment Corporation. There was, however, one member of the family which was different, IBM’s entry into the world of timeshared interactive computing, the System/360 Model 67.

The heart of the difference between the 360/67¹ and other members of the System/360 family is the operating system, composed of two independent parts. CP-67, the control program, provides timeshared access to all of the system’s features in the form of “virtual machines”; CMS, the Cambridge Monitor System, runs in each user’s own virtual machine and provides the interactive facilities for programming, text editing, and everything else the user might want to accomplish. The combination was known as CP/CMS.²

I came to work for Paul Allen in 2003, to improve and expand his collection and eventually to turn it into a museum. The wish list we developed was large, and of course included several models of the System/360, including and especially the 360/67. The quixotically intense search met with minimal success for years because IBM almost never sold their large computers, instead leasing them to customers so as to control the supply: IBM did not want to compete against their own products for market share. This meant that retired systems rarely made their way into the hands of collectors; they were instead sold overseas, leased to new customers, or scrapped. For a while, the best we could do was the lights panel from the console of a 360/91 from which all circuitry (rich in gold) had been removed.

The first major break came with a story on the Australian Broadcasting Company’s web site about the impending demise of systems owned by the Australian Computer Museum Society.³ My colleague Keith Perez contacted the ACMS and learned that they owned a 360/40, which they were not interested in deaccessioning. This conversation continued for a while, then tapered off until 2011, when Keith encountered an acquaintance of Tony Epton, president of the ACMS, while on a business trip to Sainte-Nazaire, France. The ensuing renewed discussions resulted in another colleague, Ian King, making a side trip to Perth in February before returning from a trip to Adelaide to have a look at an IBM 7090 system.⁴ Ian visited the barn in which the ACMS was storing two 360/40 systems, and recommended that we purchase one of them. The system arrived in Seattle in September 2011.

Once the 360/40 arrived, we brought in a retired IBM Customer Engineer to assess its prospects for restoration. At this point we learned something important about IBM mainframes of the 1960s and 1970s: No two are exactly alike, and without the system specific Automated Logic Diagrams (ALDs) which document how it was assembled, the chances of restoring one to operating condition are greatly reduced. The former CE also noted the amount of dust caked on the circuitry–the system had been stored in a barn in a desert–which would decrease the likelihood of a successful restoration. He passed on the opportunity to work on the project.

In 2012, we acquired three IBM systems (a 360/20, a 360/44, and a 360/65) from the American Computer Museum⁵ in Montana, none in working condition: The internal disk drive in the Model 44 had broken loose from its housing and was held in place by a piece of rope, and the internal console cables of the Model 65 had all been cut. The 360/65 was particularly painful: More than a dozen bundles of 50 to 100 identical wires each were made useless. Neither system could be repaired with our facilities.

Bob Barnett, the museum’s business manager, also located a 360/65 in Virginia which belonged to one of the principals at Sine Nomine Associates, David Boyes. David had contacts within IBM who he believed could be helpful in arranging for LCM+L to obtain licenses for the software we wanted to run, and was eager to help us put up a large System/360.⁶

The 360/20 is a 16-bit minicomputer only marginally related to the main System/360 line. As a stopgap, to be able to say we had a running System/360, the one we acquired from the American Computer Museum was restored to running condition by an enthusiastic pair of contractors, Glen Hermmannsfeldt and Craig Arno, with help from Keith Hayes and Josh Dersch of LCM+L; it was displayed in the Computer Room from 2015 to 2017, initially while the restoration work was done and then as an example of a small batch system. As is often done for vintage systems at LCM+L, virtual peripherals–a card reader and punch–were created for the 360/20.

By 2015, the desire for an IBM system capable of providing a timesharing experience led to the acquisition of a 4341 system⁷ from Paul Pierce of Portland, Oregon.⁸ By this time, we had established an ongoing dialogue with the team who had successfully restored an IBM 1401 at the Computer History Museum (CHM) in California. One of the members of the team introduced us to Fundamental Software Inc.⁹ Faced with the task of restoring 40-year-old tape and disk drives, or creating our own emulations, we decided that we would instead acquire an FSI FLEX-CUB to provide disks, tapes, and terminal services to the 4341.

Jeff Kaylin was given the task of making the 4341 CPU run. Beginning in July 2015, he spent seven months getting the power system into working condition; first power up was on 12 February 2016.

Once the system was working to this extent, we ordered a FLEX-CUB from FSI and began attaching 3278 terminals to the built-in controller for testing. Also at this time, David Boyes informed us that he had arranged licensing for the VM/SP HPO operating system for us.

The FLEX-CUB arrived at LCM+L on 1 June 2016, with a minimal VM/370 installation in place courtesy of our friends at FSI. After some phone consultations with FSI Support, we were able to IPL¹⁰ the system into VM/370. Three weeks of getting additional terminals configured followed, with discussions of the OS configuration between FSI and me, replacements of capacitors and CRTs in terminals, and so on. Progress halted on 20 June, when Jeff arrived on a Monday morning to find the system halted with the words CHECK STOP and an error code on the console.

We obtained an 8in diskette with diagnostics from FSI. Memory tests showed that the memory was working; swapping of boards with spares commenced. The power sequence was a suspect for a long time. Jeff began making schematics for the various boards in order to understand where faults might occur that matched the diagnostic callouts. For two months, Jeff wrestled with the system with no progress.

Our consultant from CHM advised Cynde Moya, our Collections Manager, of the existence of 4341 and 4361 systems housed in a warehouse in Sacramento, California. I spoke with the owner, Daniel de Long, and learned that he had a working 4361 plus spares in the form of another 4361 and two 4331s. I traveled to Sacramento a week later to have a look, seeing the 4361 IPLed and running under DOS/VSE.¹¹ After some discussion, the 4361 equipment began arriving at LCM+L on 2 November 2016.

In December 2016, Jeff began pulling the power supplies out of the 4361, to check the capacitors. All were within tolerance, but since 2004 our policy has always been to replace all aluminum electrolytic capacitors in any device we restore.¹² The new capacitors were installed and the power supplies replaced in the chassis in the remaining weeks of 2016.

In mid-January 2017, the newly refurbished 4361 replaced the 4341 in the Computer Room. FSI, who have been very helpful throughout the project, advised us on how to cable the FLEX-CUB to the new system. A different power outlet was installed to accommodate the different plug on the 4361.

When the power button was pushed, the built-in floppy drives’ motor spun, but stopped as soon as the button was released. Jeff tried attaching the operator console, with no change in behavior. A phone call to Dan de Long revealed that the system was wired for 230V rather than 208V, necessitating either a change in the room wiring or a reconfiguration of the system’s power supplies; the latter was a simple matter of changing jumpers on four transformers to provide single-phase 208V, after which the system powered up and stayed up.

Power issues continued to plague Jeff. The first supply in the system would come up, with its test point providing 1.5V as expected, and all the proper voltages supplied; the second and thrid supplies showed no voltages. Going through the ALDs allowed him to trace through all four supplies with no luck in determining the problem.

After a couple of weeks, I suggested that Jeff contact Dan again, who pointed out that the system requires that a printer be attached in order to complete the power sequence. We ordered capacitors for the printer, and had additional outlets installed under the raised floor. The printer was ready to go a month later, after degraded old foam insulation was replaced along with the power supply rebuild.¹³

With the printer installed, the system would now power up, but the printer would not stay powered on. A long correspondence, with pictures, commenced between Jeff and Dan. This went on from mid-March to mid-May, when a suggestion to swap the cables on the floppy disk drives led to the replacement of one drive. The system would now perform an Initial Microcode Load (“IML”), after which it suggested running the Problem Finder diagnostic tool. Progress! A few more days of fiddling about (bad breakers in the power supplies, etc.) led to the indicator lights on the console keyboard signalling “Power Complete”.

Jeff cabled the FLEX-CUB to the 4361, and changed some system settings on the console to allow it to run VM/370 instead of DOS/VSE. I sent the FLEX-CUB configuration which had been set up for the 4341 to Fundamental Software; they sent one back which had the proper incantations for the 4361 instead and installed it for us remotely.

After I checked over Jeff’s revised settings on the console, we tried to IPL the system, which could not find the configured IPL device. The Problem Finder tool likewise did not find it. I reviewed the FLEX-CUB configuration, and did not find anything problematic there, so stopped for the evening, asked Jeff to locate the Operating Procedures manual for the 4361, and sent pictures to FSI of the console screen showing the Unit Control Words (UCWs) defined for the devices attached to the system. The next day, I got back suggestions for updated UCWs and updated the settings on the console while Jeff moved the channel cables to their new places. Although the system still did not come up, it did report channel status on the console so we knew the system was alive.

The next day, I revised the UCWs again on advice from FSI, to change the controllers on all disks and tapes to 3880s. Several attempts to IPL the system were unsuccessful, but in the mean time we attached more 3278/3279 terminals and got the correct keyboards on them. A day later, after telling the system that the 3279-2A display was a 1052 Selectric-style printing terminal with no printer attached and another IPL, we were prompted for date and time; FSI advised issuing the command CP ENABLE ALL to make the attached terminals live in the system. FSI did little more configuration on the FLEX-CUB, and they and I were able to log on to the MAINT account! That was the end of May, 2017.

Now my task of installing a full operating system began. Several weeks of reading manuals ensued, along with the installation of the Hercules emulator¹⁴ on a Windows desktop and on a Linux server. By the end of June, 2017, I had the public domain VM/370 running on both, a task made simpler due in equal parts to the existence of turnkey installations and an active Hercules community.¹⁵ In particular, the members of the Hercules-VM group have been very helpful over the last year, offering suggestions, advice, software, and general excitement for our project.

I reached out to David Boyes to ask that he put us in touch with his IBM contact for licensing VM/SP, the preferred version of VM/CMS for our hardware. David wrote back to me that his contact was no longer at IBM, but that he would try to find us the proper person to talk to; he also told me that the tapes he had preserved had been shipped off to CHM a while back, and that he was asking that images be made. A week later, I had the name of IBM’s Product Manager for z/VM and Related Products,¹⁶ George Madl, and sent him a message outlining LCM+L’s mission and place of the 4361 and VM/SP in the museum’s offerings. He forwarded the request to Glenda Ford in IBM’s licensing department. Glenda shepherded the request through IBM’s processes for four months and by mid-November had worked out a very favorable license with reasonable restrictions (no support, no commercial use of the system, no fees).

While waiting for an answer to the license question, I moved on with planning for VM/SP, starting with a review of the differences between VM/370 and VM/SP installation. As the weeks went by, I proposed a backup plan in which we would begin by installing VM/370, and upgrade to VM/SP when the licensing came through. This took us to the end of 2017.

In January 2018, with help from FSI, I configured eight 3350 disk drives on the 4361. As we worked together to finalize the new setup, they set up a production VM/370 system on three drives, along with an emulated card reader and punch and an emulated printer. (We even uncovered a bug in the FLEX-CUB software, so the benefit was not all in one direction!) I set up guest accounts for two users who had been asking since the 4341 restoration began, and collected their impressions.

For further planning, I returned to the Hercules emulator, looking at access to language processors and other utilities. I planned to provision our new VM/370 from the prebuilt Hercules disk images, so had to learn the ins and outs of DDR (the DASD Dump/Restore program).¹⁷ I added three more 3350 disks to the system, in order to hold the desired contents from the Hercules ready-built VM/370 system. I had to remember to re-IPL the system in order to make the new drives available; the 1970s had no concept of “plug-and-play” peripherals.

It became clear that the integration of the Hercules “6-pack” (made up of six 3350 disk images) was very tight, and the simplest way forward might be to install these images onto our FLEX-CUB disks via DDR. I consulted with the H390-VM mailing list, who concurred in that idea. However, at this point two people came forward with offers of assistance.

One of the architects of the Hercules “6-pack VM” system had available the installation tapes for VM/SP Release 5, which was our original target for the 4361. He provided us with images of the tapes and images of 3350 disks onto which the installation files had been placed, and gave us a hand from the UK in getting things set up under Hercules.

The other is Drew Derbyshire, one of the VM/370 beta testers. Drew is a contract programmer with 10 years’ experience in the VM/CMS world, including a long stint working on the CP nucleus for IBM. He is also local to Seattle, and a member of LCM+L, so was well placed to help us move forward with the installation and configuration of VM/SP for our particular purpose.

On 1 March 2018, I was able to IPL the 4361 under VM/SP, having copied the installation disk images over to the FLEX-CUB with help from FSI and our helpers. These were still 3350s, so I created sixteen new 3380-K disk images on the FLEX-CUB, a total of just under 20GB of storage space,¹⁸ as the first step in making the system available to the public by 1 April.

At this point Drew, as a contractor, and I began a fruitful working relationship, trading configuration notes, ideas for further work, and so on. Drew set up a Hercules mimic of the 4361’s exact configuration in order to experiment when the museum was not open. This was helpful when the 4361’s disks were clobbered due to errors in configurations, and Drew did the artwork for the VM/SP splash page on display terminals connecting to the system.

Over the next 10 weeks, Drew and I built CP nucleuses¹⁹ with different parameter settings, different numbers of terminals defined, 3380 disks instead of 3350, and so on. In mid-May, the 4361 had a machine check, which Jeff and I traced down over the next week to a memory issue.²⁰ Jeff pulled memory modules from the 4341 to replace those called out by the IBM diagnostics; I began backing up all the disks to tapes, taking the system down every night and bringing it up the next morning.

The interruption was annoying because the developer/maintainer of the Stanford Pascal Compiler was installing his program on the system when the memory fault occurred. Once that was repaired, Drew and he completed testing of the installation and declared it good.

I booted the 4361 on Friday evening, 18 May 2018, for a test run over the weekend. Drew accidentally crashed it from a remote location on Saturday morning, but brought it back up during open hours at LCM+L. The system ran for a week without incident, so I posted an invitation to the H390-VM list for anyone interested to apply for a beta account. This was as much to test the account management software Drew had written as to shine a light on any blind spots we had with regard to software for the casual user.

Since 1 June 2018, Drew has installed the PL/I Optimizing Compiler, Fortran/VS, and other pieces of software to make the system more hospitable. In addition, one of the beta test users installed a version of the IND$FILE file transfer program by cutting and pasting a hexadecimal dump of the binary program into his directory, then let us know about it to install for general use. Drew has made great use of it to make updates from his Hercules testbed to the running 4361.

Future possibilities include installing RSCS and NJE, the remote-job entry subsystem for VM, to create a BITNET-style network site,²¹ and creating subsidiary virtual machines running other interactive operating systems such as the Michigan Terminal System or the McGill University MUSIC timesharing system, so stay tuned for further developments!