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,1 SAIL,2 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.3 Typical installations had 64KW or 96KW attached. The KA-10 CPU in the first generation PDP-104 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.5 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”6 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.7

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 monitor8 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.9 This design featured a BBN style pager and used very fast semiconductors10 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.11 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.12

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 Ethernet13 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”.14 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,15 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.16

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 board17 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.18 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 boards19 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.20

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.21 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.22 We officially introduced the XKL Toad-1 System at a DECUS trade show in the spring of 1995.

Line Segments of a Regular Dodecahedron

Websites like to tell you the 20 vertices of a dodecahedron, and how they relate to the Golden Ratio, but they don’t specify the 30 edges.

The Golden Ration being about 1.618 and the inverse being about 0.618.


So, here they are:

111to01.6180.618
111to0.61801.618
111to1.6180.6180
11-1to01.618-0.618
11-1to0.6180-1.618
11-1to1.6180.6180
1-11to0-1.6180.618
1-11to0.61801.618
1-11to1.618-0.6180
1-1-1to0-1.618-0.618
1-1-1to0.6180-1.618
1-1-1to1.618-0.6180
-111to01.6180.618
-111to-0.61801.618
-111to-1.6180.6180
-11-1to01.618-0.618
-11-1to-0.6180-1.618
-11-1to-1.6180.6180
-1-11to0-1.6180.618
-1-11to-0.61801.618
-1-11to-1.618-0.6180
-1-1-1to0-1.618-0.618
-1-1-1to-0.6180-1.618
-1-1-1to-1.618-0.6180
01.6180.618to01.618-0.618
0-1.6180.618to0-1.618-0.618
0.61801.618to-0.61801.618
0.6180-1.618to-0.6180-1.618
1.6180.6180to1.6180-0.6180
-1.6180.6180to-1.618-0.6180
Edges for a Regular Dodecahedron

At Home With Josh Part 4: High-Resolution Terminal Restoration

In my previous installment I tested the Lambda’s fans and the power supply and powered things up for the first time. A few of the fans were non-functional even after cleaning and lubricating and so an eBay order was placed. While waiting for those fans to arrive, I started taking a look at the Lambda’s monitor, referred to in the documentation variously as “High-Resolution Terminals” or “High-Resolution Monitors.” Whatever they’re called, they were in need of a bit of sprucing up:

LMI Lambda monitors, mid-cleaning
If you look closely you can see the scarring on the picture tube’s face.

I cleaned the exterior with a bit of Simple Green and some liberally applied Magic Eraser to get some of the grungier parts off. Exposure to the elements had left some interesting etchings on the anti-glare coating on the CRT; I’m not sure if they ate it away or if they just deposited a thin layer of something on the surface– either way light scrubbing with the Magic Eraser either removed the deposits or removed the rest of the anti-glare coating to match, it’s difficult to say. Eventually the external dirt and grime were removed and the monitors looked much better.

Shiny Happy Monitor

One of the two monitors has a CRT with “cataracts” (also referred to as “CRT Rot”) in the corners. This is a problem that plagues older televisions and monitors and is caused by degradation of the thin PVA glue layer between the front of the CRT glass and the implosion-protection lens. Over time, the PVA breaks down causing small spots to appear. The cataracts here are relatively minor; on an ADM-3A terminal I recently repaired the PVA breakdown was so extreme it had started leaking out onto the circuit boards and was an absolute bear to clean up (fortunately it’s organic so it washes off with water, but not without a fight.)

Close-up of CRT cataracts

On some CRTs this can be repaired, typically by carefully separating the implosion lens from the rest of the CRT, cleaning all the PVA residue and reassembling. (Here’s an interesting write-up of one such process for old TV picture tubes.) On the Lambda’s CRTs, this is made much more difficult — there is a metal band around the tube with a “lip” that extends around the front of the tube, helping to hold the whole assembly in place. This band is glued in place with a potting compound making removal of this band extremely difficult; and due to the lip the implosion lens cannot be removed without removing this band. Fortunately the cataracts on this tube are not bad enough to warrant attempting to do this — I’m happy to put up with it — and the other monitor’s tube is free of cataracts, so far.

Inspecting the Internals

Much like with the rest of the Lambda system, we have to give the internals a thorough inspection. One of these monitors was left on top of the Lambda in the garage; the other (the one with the cataracts) was on the floor near the door and was exposed a slightly more harsh environment as a result. However, they both cleaned up very nicely on the outside so my expectation was that internally they’d be similar as well.

The interior of the monitor with the back covers removed.

Looking at the interior from the rear (as in the above photos) reveals a relatively clean monitor — though you can see some obvious rust in places like the ground strap going across the bell of the picture tube. The interior of the other monitor is very similar in terms of condition. On the left side is the monitor’s power supply, on the right is the deflection board which scans the CRT’s electron beam across the screen to form a raster, and in the middle is the “neck board”, so called because it plugs into the neck of the CRT. It supplies power to the CRT’s heaters and takes the incoming video signal from the Lambda and feeds it to the tube appropriately.

Safety First, People:

It’s important to note at this time that safety is important when working on CRTs: they tend to make use of extremely high voltages (5-10KV in monochrome tubes, up to 25KV in color sets) and you can get zapped if you’re not careful. Picture tubes can build up a charge even while sitting unplugged and unused; so even though this tube hasn’t been powered up in a couple of decades it still has the potential to bite. Discharging of the tube before working on it is a good idea, as is working with one hand behind your back (to avoid causing current flow across your heart, should you grab ground with one hand and 20KV with the other, inadvertently.)

The CRT envelope is made of glass and contains a powerful vacuum; if the glass breaks the tube can potentially implode — sending glass shards everywhere. While modern tubes (like the ones in the Lambda) have implosion protection measures in place, it never hurts to be careful around large tubes like this: watch your hands, watch your tools and make sure they don’t strike the neck of the tube where the glass is thinnest and the most likely to take damage.

The Inspection Continues:

Looking closer at the power supply you can get a better idea of the cleanup necessary here — everything is covered in a layer of dirt and shingle detritus from when the garage’s roof was replaced. Just as with the Lambda’s chassis and power supplies, I’m looking for out-of-place things and broken or damaged components. All three of these boards contain socketed chips, so checking the sockets and the ICs in them for corrosion is important. I’m also keeping my eyes open for damaged capacitors. Monitors can be hard on capacitors, especially high-resolution monitors like this one. Monitors don’t typically have fans so they tend to run hot, and heat leads to shorter lifespans of internal components.

And sure enough I found my first victims on the power supply board.

RIFA film capacitors, top view.
Exploded RIFA, from the side

These are film capacitors, used as AC line-filters in the power supply. Or at least they were film capacitors — as you can see the casings have cracked and split and have turned a deep brown in places (they’re normally golden-yellow colored). These were manufactured by RIFA, and are absolutely notorious for failing in this way, and when they do fail they emit an unforgettable odor, though not an entirely bad one (we’ll get to those smells later). Kinda like burning paper. Which is not a coincidence because these are made of metallized paper. As they age, moisture seeps in and eventually causes a short-circuit resulting in smoke, but not usually fire. (There was this one time at the museum when one of these died in action and set off the smoke detectors and the fire department came. That was a fun day…)

Even if they haven’t already clearly failed as these have, they should be replaced as a matter of course, because they will fail if you don’t. Probably within the first thirty minutes of being powered up.

Original RIFA next to its brand-new replacement.

Moving along onto the deflection board: There are a few socketed chips, and the sockets don’t look so hot. These sockets have deeply recessed pins and my suspicion is that as a result they hold onto moisture longer, increasing the chances of corrosion. As you can see in the picture below, some of the pins show the original gold-plating, while others are green or grey. It’s likely that these sockets will provide poor contact with the IC, so I replaced it with a spare I had on-hand, a nice turned-pin socket from Mill-Max:

On this same board I found the first instance in this restoration of a visibly-bad electrolytic capacitor:

That capacitor is supposed to be a uniform silver in color. It is browned and blackened likely due to heat while in operation due to its proximity to that transformer, and it might have been a slightly under-specced part as well. Instant candidate for replacement, no questions asked.

On the neck board we find another kind of capacitor that can often cause issues; look closely at the four blue raindrop-shaped components in the below picture:

One of these things is not like the others.

Well, they’re all supposed to be blue, but the second one from the left is black and sure enough it’s a dead short, rather than a capacitor. These are tantalum capacitors and they have a tendency to explode in a tiny little fireball when they go bad — and they can scorch other components when they do so. And the smell they make is decidedly unpleasant. Given the state of the black one it seemed prudent to replace all four just to be on the safe side. Takes a long time to get that odor out of an already stuffy basement, I’m not taking any chances.

There is one further board in these monitors, called the “headboard” — it lives in the monitor stand and breaks out the signals on the cable from the Lambda into keyboard, mouse, and video. It also includes a tiny speaker and three controls for brightness, contrast, and volume:

Ugh. Just, ugh.

The one in the monitor that had been sitting on top of the Lambda was just a bit dusty, but the one that’d been on the floor… yow. Some serious insect activity in here over the years, and everything was pretty well covered in… insect stuff. I took the board out of the housing and scrubbed the base-plate down in the utility sink. I went over the PCB with a soapy toothbrush and Q-Tips to get as much gunk off as possible. It cleaned up pretty well!

Ahh, much better.

Having assessed the condition of the boards (and having gone through and cleaned everything as thoroughly as possible), I made the decision to do a complete “re-cap” of the three main boards in both monitors: a replacement of all of the electrolytic capacitors and the problematic-looking tantalums. I placed an order for replacement parts (I tend to use Mouser or Digi-Key for this sort of thing) and 3-5 days later a box of capacitors arrived on my doorstep.

Replaced tantalum capacitors on the neck board

At this point it’s a straightforward matter: desolder the old components, and solder in the new ones, one at a time. I have a Hakko desoldering iron (just like the ones we use at work) and a Weller soldering station that have served me well over the years. I didn’t take any pictures of the actual desoldering/resoldering process because I only have two hands and I don’t own a tripod… I’m lame.

All the replaced capacitors from the power supply board, next to the re-capped supply. On a really ugly benchtop.
Woo-hoo!

With everything reassembled in the first monitor, the only thing left to do was to put it on the bench, plug it in, cross my fingers, and turn it on. I wasn’t entirely sure it would do anything without being hooked up to a running Lambda with functioning video hardware: some monitors of this era won’t light up unless they’re getting sync pulses from their video input (Sun-3 monochrome workstation monitors for example). Others will display a “free-running” blank raster instead. Turns out the Lambda console is one of these latter:

I got very lucky and things appeared to be working as perfectly as could be determined without a valid video signal to feed it. I let it burn in on the bench for a half an hour and no issues arose. If you’ve accidentally put an electrolytic capacitor in backwards, you’ll know within the first few minutes, if not sooner… (another fun smell you don’t want in your house.)

The next day I took on the second console, going through exactly the same steps — like deja vu all over again. However, I wasn’t as lucky with this one; no smoke or fire but also no action on the display at all, and no faint chatter of the yoke indicating deflection, no static on the face of the tube indicating the presence of high voltage. The neck of the picture tube lit up, however — so at least a few things were functional. The voltages coming out of the power supply (it generates +48V and +32V) were in the right ballpark at +45 and +33. There is a potentiometer on the power supply to adjust these voltages, so I gave it a small tweak to get closer to +48V and at that point I heard the HV kick into gear, but I don’t understand why — the voltages were a little off but not enough to prevent the deflection board from running, and I’d only tweaked it up to +46V anyway. This seems like a sign of a bad connection: a loose wire, dirty connector, or maybe a cold solder joint. At this point I had high voltages and could hear evidence of deflection but there was nothing on the display, no free-running raster like on the first monitor.

I powered it down and took a closer look at everything; cleaned the various cables and connectors on the power supply and inspected my soldering job — still nothing jumped out at me as being obviously wrong. But I put it back together and it was still working as before, deflection running and high voltages being generated, though I was still getting nothing on the display at all. At this point I needed a break and decided to shelve the second monitor for the time being. One working display was enough to use with the Lambda (assuming I ever did get it to do anything) and at that point I’d return to debugging the other.

In my next write-up I’ll see if I can get the Lambda to load and run diagnostics from the world’s slowest 9-track tape drive, after dealing with a minor setback. The anticipation, you can hardly stand it!

At Home with Josh, Part 3: Power Supply Testing and Initial LMI Lambda Power-up

Last time around I went through the cleaning and inspection of the Lambda. Overall, apart from a few errant screws and a faint musty odor, things looked pretty good. We’re inching closer to the point where we can power this thing on and see what it does, but there are a few things left to go over before we can get there.

Power Supplies!

We haven’t yet looked at the power supplies in the Lambda beyond verifying that mice haven’t eaten all the wires away. LMI made this task pretty easy, and I want to thank the person who designed the chassis: the whole power supply assembly is on rack-mount slides and just pulls right out of the rear of the cabinet like so:

The LMI Lambda Power tray, inside the cabinet.
Disconnect the two cables and slide it right out. Magic!

The fan tray in the rear is normally situated right below the card cage, and serves to keep the logic well-ventilated. There are two power supplies mounted in the front of the tray. The narrow ACDC Electronics supply on the left provides +/-5V and +/-12V to the backplane, and the large blue LH Research supply on the right provides +5V at 150 Amps. That’s a lot of power, and it’s used to run the majority of the logic in the system. The smaller supply provides power to run the ECL components for the high-resolution terminal interface, the RS-232 drivers for the console ports, and other odds and ends.

The screw is a tightening atrocity.

As with the card cage inspection, it’s important to go through both of these supplies with a fine-toothed comb looking for damage and for things that don’t belong inside power supplies. For example, this screw that fell out of the smaller supply as I was opening it up to take a closer look.

And like our misplaced screw from the last entry I have no idea how it ended up in here, but there it was. Had this supply been powered up with that screw in place it could have shorted something out and done serious damage.

What I usually look for in a visual inspection of a power supply are obviously bad parts: bulging electrolytic capacitors, charred tantalum capacitors or transistors, burned traces, things broken off, etc. Passing a visual inspection by no means indicates the supply will work — many parts can (and often do) fail invisibly. But visibly broken parts obviously won’t work and so it’s a good starting point.

Unfortunately, I did my power supply inspection just before I decided to start thoroughly documenting the restoration process, so I don’t have any detailed photos of the insides of these supplies as I was examining them and testing them (and it’s a sufficient amount of work to remove them again that I’m not taking them back out to take pictures now. I apologize for my laziness.) Suffice it to say, apart from that screw, nothing out of the ordinary was found and everything looked much cleaner than I expected — no corrosion or signs of damage of any kind.

It’s at this point where I usually debate with myself whether to just preemptively replace the electrolytic capacitors in the supplies. Shotgun replacement of caps isn’t always a good idea (and I suspect there are engineers out there who will take umbrage with even suggesting such an approach) but for a supply of this age, and for one that’s sat in sub-optimal conditions (cold, dry Pennsylvania winters, hot humid summers for 20+ years) there’s a good chance that the capacitors have dried out and gone out of spec. At LCM+L we typically go one step further than capacitor replacement: Since our goal is to run many of our systems 24×7 (or at least during museum hours) we will often bypass the original supplies and retrofit more efficient and reliable modern supplies (this is usually done alongside the originals so that the system can be returned to its original configuration if need be). I don’t have the budget for that option (150A 5V supplies are expensive), so I’m sticking with the original supplies.

I also figured, what the heck, let’s test the supplies with the original capacitors and see what happens. This is done by hooking up a “dummy” load to the power supply — switching supplies don’t like being powered up without a load to power — and measuring voltages and testing the supplies for ripple. Ripple is a deviation from a nice, flat DC voltage and an excessive amount of it (more than 50-100mV typically) indicates trouble in the power supply: bad smoothing capacitors or dead rectifiers or transistors typically. The exact effects and causes differ depending on the type of power supply but it’s never a good thing to have.

Again I lament my lack of foresight as far as taking pictures of this portion of the restoration. On the positive side: everything tested out fine. All voltages were present and working under load within specifications. I let the supplies run for an hour or so. No funny smells were emitted, and the magic smoke remained safely ensconced in the supplies. I may still end up replacing the capacitors in the supplies at some point in the future, but for the time being I’m leaving well-enough alone.

Fans!

Dirty, filty, ugly, naughty fan…

The importance of cooling in your average computer system cannot be overstated, and thus it is vital to ensure that all the fans are spinning freely and actually moving air around. A closeup shot of one of the fans in the fan tray pre-restoration is to the right. You can see how much crud and rust has accumulated on it over the years. Of the six fans in the tray, two of them spin freely, and the others make a noise not unlike a kazoo when given a spin. However, these are well-made fans and the three exposed screws on the underside there indicate that they were probably made to be serviced — it should be possible to disassemble, clean, and lubricate them.

Sure enough, they come right apart. The major thing to keep track of is the Circlip that holds the fan blade rotor onto the shaft, as well as the numerous washers involved. Cleaning the bearing shaft off and applying some light machine oil to it and to the felt washers is all that’s required to make one of these spin freely again; I also took the time to clean the fan blades as thoroughly as possible. They’re never going to look like new again, but at least they’re not dirty anymore.

Go on, give it a good spin!
eBay photo of the replacement fan

After reassembly, I applied power to the fans and four out of the six worked just fine — they made no appreciable noise and they spun at the right speed, moving a lot of air. The other two spun up very slowly even with help and never reached the proper speed. I suspect that the windings in these motors have been damaged (possibly while in service years ago). These two fans will need to be replaced. I was able to find an exact replacement on eBay, new-old stock. You can find just about anything on eBay.

First Power-up

The power supplies are tested and seem to be working, and enough of the fans are spinning so as to keep things cool at least for a little while — let’s power this sucker up and see what happens.

As discussed in the last write-up, the System Diagnostic Unit (SDU) is the nexus of the Lambda: it bridges the two buses in the backplane and is responsible for booting the operating system. It also provides a diagnostic console over its RS-232 serial interface, which is what I’ll be talking to a lot in the coming weeks. For the initial power-up the only board I will have installed in the backplane is the SDU. This will confirm the functionality of the power supplies, wiring, the backplane and hopefully the SDU itself.

I pulled the other boards out of the backplane, leaving them in the slots but pulled out so they are disconnected, and wired up my trusty Qume dumb-terminal to the serial port marked “Remote” on the rear bulkhead and configured it to 9600 baud, 8 bits, 1 stop bit, no parity. I plugged the power cable into the wall, crossed my fingers, and flipped The Switch.

The Switch.
Serial cabling on the rear bulkhead panel
It’s difficult to make out in this picture, but all three LEDs are stuck on. Not what I wanted to see.

Fans spun, the LEDs on the front panel and the SDU itself came on. No smoke! But also nothing on the terminal. And all three lights on the front panel were on. This indicates a fault — under normal operation the LEDs should progress through a pattern and then end after a few seconds with just the RUN light on (and probably the SET UP light as well, this indicates that the battery-backed up settings have been erased — expected since I’d pulled the long-since-dead battery out.) Per consulting with Daniel, if all three lights are stuck on, this means that the SDU isn’t passing its initial round of self-tests. This could be caused by any number of things — bad RAM or EPROM, a clobbered CPU bus, or the RESET signal to the CPU being stuck on.

I rechecked power supply voltages and they measured fine. I pulled the SDU out and re-examined the pins on all of the socketed chips and found that a few pins on the 8088 CPU were still pretty grungy (sloppy work on my part during my earlier cleaning/inspection pass, I suppose) so I went over them again.

Powered up the system with the re-cleaned SDU installed and… hey! After a few seconds, just the RUN and SET UP lights were on. Looks like I got lucky here. Still nothing on the terminal, though. Hm.

Wankel-Rotary Switch

I consulted further with Daniel Seagraves and he suggested checking the rotary selector switch on the rear of the cabinet; this selects one of several actions when the system is powered on or reset. Normally it should be at “0” to force the monitor console onto the serial port, but depending on the revision of the SDU’s ROM monitor, it might want to be at “1” instead. I turned the switch to “1”, turned the system on and:

Success!

Alright! Now we’re cookin’ with gas. The SDU is talking to me at last, the power supplies are working acceptably, and the faint musty odor of the air being wafted at me out of the cabinet by the chassis fans smells like victory.

My plan now is to hunt down a suitable 9-track tape drive so that I can use it to load diagnostics into the system and test the various components in the system. While that’s going on, I’m going to take a look at the Lambda’s High-Resolution Terminals (aka “monitors”) and see what needs to be done to make them work again. Stay tuned for the next exciting installment!

On COBOL and Legacy Systems

Two recent articles1 (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?2 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.3

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

Homebrew Computer Club

Back in the days when I commuted to Intel in Santa Clara, California, form Livermore, on the back of a dinosaur, I heard about a group of fellow geeks that met at The Standford Linear Accelerator Center, that called themselves “The Homebrew Computer Club”.

At the time, I was trying to build my own computer out of an Intel 8008 that had been donated to me by the Intel Product Engineering group that handled the 8008. If I recall, the i8008 needed high voltage clocks, and hadn’t learned much about straight transistor design then, so it was taking some head scratching.

I remember talking to the other technicians about the Altair when it came out, and noting that if you wanted a chip from Intel, it was $400, but you could get the Altair kit for $395.

Back to Homebrew: They met in an Auditorium on top of a hill at S.L.A.C. S.L.A.C. is kind of an interesting place, their main claim to fame is this 1 mile long Linear Accelerator that runs under the Interstate 280 Freeway! In the auditorium, we would all take seats, and Lee Felsenstein would moderate the discussion. Gordon French, the librarian, would stand and mention whatever new thing had appeared in the library. Other folks would talk about anything related to computers that they wanted.

Getting off of work at 4, hanging around the south bay for 2 hours +, then going to Homebrew, spending an hour driving home after the meeting made for a very long day, but I did it from time to time. I was young and foolish then. Later in my time at Intel, I got off at 5PM, which meant less wasted time, but I got to work at 5AM, so those were REALLY long days.

I don’t remember when I discovered the Santa Clara Byte Shop. I remember seeing an Apple I sitting on a table in the corner of the store. A computer on a single board! It had a 6502 in it so I kind of looked down my nose at it, being an Intel guy and all. I had my Imsai 8080 by then.

I remember going to a Homebrew meeting one time, and seeing the prototype Apple ][ there, with the prototype case. They hadn’t had time to get it painted yet. All in one box, and it would do color graphics to boot! Steve Wozniak did AMAZING things with almost no hardware! It boggled the mind. But it still had a 6502 in it.

If you look at me, Woz and Jobs, I guess you can tell who wins. Well, Jobs is dead, but he did go out in a blaze of glory.

Bruce Sherry

At Home With Josh, Part 2: Lambda Cleaning and Inspection

As mentioned in my last post, the LMI Lambda I acquired spent most of the last two decades in a garage somewhere in Pennsylvania. It wasn’t a climate-controlled garage. It wasn’t a leak-proof or a rodent-proof garage. The door to said garage wouldn’t even close all the way. So this machine was in rough condition when I picked it up. The first thing I did before bringing it in the house was to clean it out, thoroughly.

The Lambda, just outside the garage.

Unfortunately I neglected to take too many “before” photos (at the time I hadn’t yet considered documenting this whole process) but they’d only really reveal a cabinet covered in a thin layer of grit and grime.

The outside and inside walls of the cabinet were cleaned off with some Simple Green and some elbow grease, and while this was underway I inspected the interior for rodent-related damage.

The Lambda after cleaning, sitting in its new home in my basement. Still kind of rusty, but smelling less musty.

Fortunately, apart from the hole in the door near the top (which is hard for small animals to reach) the Lambda’s cabinet is free of any holes large enough for a mouse to squeeze into and no damage was observed. This is good: mice love to chew up wires, and their urine and droppings can eat the traces off of printed circuit boards and corrode the legs on ICs and other components. While a lot of this sort of damage can eventually be repaired, it’s difficult and messy (and smelly) work to deal with.

Removal of Batteries

After a thorough wash-down of the cabinet, things were smelling better so I had a good look at the card cage and backplane. Daniel Seagraves alerted me to the fact that the SDU (System Diagnostic Unit) contains a soldered-on nickel-cadmium battery, and that’s where I started my inspection.

Anyone who’s worked on any of a variety of old computers knows that batteries are bad news. Tiny cells soldered to motherboards have been the death of many a PC, Amiga and VAXStation (and they’re not kind to arcade games either.) Over time, the batteries leak or outgas — and what comes out of them eats away at circuit boards and dissolves traces. So as I pulled the SDU out I kept my fingers crossed that the damage would be minimal — the SDU is one board I don’t have spares for. And as luck would have it, even though this thing had been sitting in a rather unforgiving environment for a long time, the battery hadn’t leaked at all:

Intact NiCad battery on the SDU. Got very lucky here.

Whew. I got out a pair of wirecutters and immediately removed it from the board. I’m not taking any chances, and this battery will need to be replaced anyway. The rest of the SDU was in decent shape — some rust on some IC legs, and one rather rusty looking clock crystal but overall not too shabby.

Inspecting the Card Cage

When inspecting a cardcage like this, generally it’s important to make sure that everything’s in its right place: In addition to making sure that nothing’s missing, some slots may have designated purposes (where having the wrong board in the wrong slot can cause catastrophic damage) and some busses don’t like having empty slots in the wrong places. (Some backplanes don’t even have the concept of a bus at all, and each slot is hard-wired for a specific board.)

The Lambda’s cardcage as-received, still sitting on the loading dock.

Additionally, when inspecting a cardcage in a system that’s been in an unfriendly environment it’s a good idea to carefully inspect everything for damage or foreign matter up front so you know what you’re going to be up against. It’s also a good time to do minor cleanup of corroded pins on chips that are socketed.

This is also a good time to start collecting as much information and documentation about the system as possible — this will be required in order to assess what’s missing and what goes where, and it will be essential if repairs need to be made. Bitsavers is always good place to start.

First thing’s first, let’s see what we have in the system. The Field Service Manual is a good reference to have handy while doing this, although it’s slightly outdated in some areas. The backplane is divided into sections, and slots are numbered from right to left, starting at zero. The first 8 slots are NuBus slots with a processor interconnect for the Lambda CPUs (there are two sets of four boards) and these slots are specifically designated for these processor boards. Slots 8-14 are general-purpose NuBus slots, slot 15 is for the SDU and the remaining slots are Multibus slots for peripheral controllers (Disk, Tape, and Ethernet typically). Here’s a handy table showing what’s where in my system:

SlotBoard
0RG (CPU 0): “ReGisters Board”
1CM (CPU 0): “Control Memory”
2MI (CPU 0): “Memory Interface”
3DP (CPU 0): “Data Paths”
4RG (CPU 1): (as above)
5CM (CPU 1)
6MI (CPU 1)
7DP (CPU 1)
8VCMEM (0): High-resolution terminal (keyboard, mouse, display) interface for CPU 0
94MB Memory: Memory for the Lisp processors
10VCMEM (1): High-resolution terminal (keyboard, mouse, display) interface for CPU 1
11CPU: 68010 processor for UNIX
1216MB Memory: Memory for the Lisp processors
13Empty
14Empty
15SDU: System Diagnostic Unit
16Disk: Multibus SMD Disk Controller
17Tape: Multibus Pertec Tape Controller
18Empty
19Empty
20Memory: TI-Manufactured 4MB Board

The RG, CM, MI, and DP boards together contain the logic for the Lambda’s Lisp processor, one specially designed to run Lisp code efficiently.

Lambda CPU: RG “Registers” board

This system is outfitted with two sets of these boards. This was a way to make the system more cost (and space) effective: A single Lambda could run two processors and two consoles (and thus service two simultaneous users) while sharing a single disk. Since Lisp Machines were typically single-user machines, reducing the overall cost and footprint in this way would make the LMI more attractive to buyers concerned about investment in very expensive computers. (Symbolics did something similar with their 3653 workstation: it contained three 3650 Lisp CPUs in a single chassis.)

Lambda CPU: MI “Memory Interface” board.

The logic in the Lambda is built entirely from 7400-series TTL (Transistor-Transistor Logic) parts along with a few PALs (Programmable Array Logic) and EPROMs (Erasable-Programmable Read-Only Memory). The most complicated IC involved is the 74181 ALU used on the Data Paths board. The 74181 was a 4-bit ALU used in many processors of the time, though it was a bit outdated by the time of the Lambda (The Xerox Alto used them way back in 1973, for example).

Lambda CPU: DP “Data Paths” board – note the 3×3 array of 74S181 ALU chips.

That’s good news — TTL, PAL and EPROM parts are still readily available so they can be replaced if they fail. The trick, of course, is being able to debug the hardware to the point where the bad chips can be accurately identified. At the moment, circuit schematics are not available so this will likely be a challenge.

Lambda CPU: CM “Control Memory” board
The Motorola 68010-based UNIX CPU Board, for when you want to contaminate the beauty of your Lisp Machine with UNIX.

The “CPU” board in slot 11 contains a Motorola 68010 processor and allowed the Lambda to run UNIX alongside Lisp. This configuration, with two CPUs and the 68010 UNIX board, was referred to as the 2×2/PLUS. (See the exciting product announcement here!)

The VCMEM boards each drive a single high-resolution terminal — a black and white monitor into which a keyboard and mouse plug in, connected to the Lambda by a very long cable. (The terminals typically lived far away from the Lambda itself since no one would want to work very close to a machine this loud.) I got two consoles with the machine, but only one keyboard and mouse, alas.

VCMEM board — framebuffer memory and display, keyboard, and mouse controller
16MB of memory

The memory boards provide memory for the Lisp processors to use. Each processor can address up to 16MB of memory.

System Diagnostic Unit

The SDU sits in the middle of the cardcage and acts as a middle-man, so to speak: it negotiates communication between the NuBus boards on its right from the Multibus boards on its left. Additionally, it is responsible for booting the system and can be used to run diagnostics, to format drives, and to reinstall the operating system from tape. It is based around the Intel 8088 CPU.

Multibus Interphase SMD 2181 Drive Controller, in carrier.

The Multibus controllers sit in special carriers that adapt the boards to the form-factor that the Lambda’s card cage uses. The disk, tape, and ethernet controllers were off-the-shelf parts made by other manfacturers: 3Com for the Ethernet controller, Ciprico for the Tape controller, and Interphase for the Disk controller.

From the looks of things, everything is in the right slot, except for that TI Memory board in slot 20. That’s a Multibus slot and the Lisp memory boards won’t work there at all (and in fact could end up getting damaged if installed there when power is applied). Someone likely put it there to keep the board safe while in storage or in transit. I removed that board and put it in a static-proof bag for safekeeping.

The misplaced Texas Instruments-manufactured memory board, easily distinguishable by its use of surface-mount rather than through-hole parts.

Board Inspection and Cleaning

While going through the card cage I took every board out for inspection and cleaning. Things to look for are severe amounts of dirt, dust, rust or corrosion, physically broken or burned components, damaged circuit board traces, bent pins, and other things that don’t belong on a circuit board.

Socketed chips are good to look at closely: the sockets and the pins on the ICs are more prone to corrosion in my experience (not entirely sure why — some of this is due to being more exposed to the elements than soldered-in chips, moisture may linger in the sockets for a longer time than elsewhere; it may also be partially due to reactions between the different metals used in the sockets and the IC pins). On these boards it was not at all uncommon to find chips like this:

Fairly corroded legs on an Intel 8089 I/o Coprocessor

Light oxidation manifests as a dull grey patina on IC legs and socket connectors; corrosion as more obvious orange or brown rust or green verdigris. Any of these will cause poor connection with the sockets and must be eliminated. Oxidation and corrosion can usually be removed with some fine-grit sandpaper or gentle scraping with a sharp X-Acto knife blade. Sometimes such cleaning will reveal legs that have corroded away so much that they fall off — which is always disappointing to find. This fortunately has not happened to any of the ICs in the Lambda so far.

Occasionally you run across something like this:

IC with a bent leg found as-is in a socket!

This is more common than you might think — the pin got bent over when placed in the socket when the board was manufactured, but still made good contact with the top of the socket pin so the fault was never discovered. Over time, this can cause intermittent failures. Luckily it’s pretty easy to bend these back without breaking them.

And then sometimes you find something completely inexplicable:

How’d that screw get there?

I have no idea how or when this happened, but that screw was very firmly wedged in-between those two ICs. Given that the boards are vertically oriented in the chassis, it seems really unlikely that a screw fell in the top and managed to get stuck in there. Very strange. Also not good for operational integrity. Note also the grey oxidized pins on the blue socket in the lower right of that picture. When new, those were shiny and chrome. Luckily that’s a spare socket and is unused.

Inspecting the Rear Chassis

The logic boards plug into the front of the chassis. Around back, there’s another set of connectors which small “paddle cards”plug into, breaking out signals into cables that connect to peripherals and run to bulkhead connectors like these:

The back of the CPU card cage. Some light pitting on the aluminum of the rear panel.

That rear panel hinges outward and reveals the rear side of the Lambda’s backplane:

Behind the rear panel

You can see how the backplane is segmented here: On the top running from right to left you have the NuBus portion, which ends on the left with the NuBus Terminator paddle card. (There is a similar terminator on the right side as well). On the lower-left you can see two sets of four slot backplanes for the CPU interconnects. To the right of those are the paddle cards for the VCMEM slots: These bring out the connections for the high-resolution terminals, which are cabled to DB-25 connectors on the bulkhead panels. Further to the right you can just make out the SDU paddle card. Everything to the right of the SDU slot is Multibus — the middle section of these slots carry the Multibus signals, while the top and bottom sections carry device-specific signals for disk, tape, and ethernet cabling.

The important thing to check here is that all the paddle cards are present, in the right places, and are in decent shape. This appears to be the case. All the cabling looks to be intact as well. Good news all around.

Conclusion

After a lot of careful inspection and cleaning, the Lambda’s chassis looks to be in solid shape. In my next installment I’ll go over the power supplies and fans, and do the first power-up of the system. See you then!

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.

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

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





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.