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-101.

The PDP-10

The PDP-102 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 word3 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.4 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.5 There were 2 classes of UUOs: “Monitor UUOs”, defined as opcodes 040-077,6 are used by the operating system7 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.8

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.


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 is9

        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:

        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:

        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.10

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
 * Visit for documentation.
 * Use ssh 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
 [LGNLAS Last access to [20,20] succeeded on 24-Mar-120:12:38:55]
 14:09   24-Mar-120   Tuesday

 .run tbasic[20,10]






 PRINT 2+2


 10 FOR I=0 TO 10


 30 NEXT I

 40 END


 10 FOR I=0 TO 10
 30 NEXT I
 40 END


 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.

At home with Josh

A Tour of my Workspace

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

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

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

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

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

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

Even More Computers

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

PDP-8s abound!

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

Computer potpourri

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

North Wall: Way too much stuff

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

Ridge 32 and VAX-11/730

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

VAX on the beach

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

Where was I?

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

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

The middle row of computer junk

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

A Bit Of Background on LMI and the Lambda

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

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

My Lambda

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

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

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

Restoration Plan

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

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

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

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

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

My First Computer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How I Use Excel

I use Excel spreadsheets to organize my projects.

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

A listing of PDFs in the Sigma9 directory

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

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

KaliedoscopeDECtape panelLogo HandshakeRendered Logo handshake

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

Clue Detective Sheet
Detective Pad for the game of Clue

Or visualize data in a giant oscilloscope:


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.


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 ***