PDP-8/M Restoration Project

Pre-Cleaning Teardown Pics

This machine was received in rather rough condition. The previous owner had gotten it with a couple of other machines, and this was the "ugly duckling" of the group. Clearly from these pictures, one of the most obvious issues with it is the grunge inside. Even before these pictures were taken, one first cut at cleaning the front panel was made.

Post-Cleaning Before Reassembly

Replacing the Power Cord

The first hardware repair that was needed was the power cord. As received, this was the power cord:

The original cord contained the usual color coding of green for ground, white for neutral, and black for hot as used in the US. These are also the colors referenced in the engineering drawings as well. I decided the best option for a replacement cord was to use one of the seemingly infinite supply of IEC power cords that have accumulated in my basement. Naturally, I cut off the female end and stripped back the outer insulation. However, the green, white, and black insulation on the individual conductors were not to be found. Instead, I found a blue wire, one with yellow insulation with a green strip, and one dark brown, so dark I thought it was black at first. A little Googling later and I learned these are the colors commonly used in Europe where the yellow/green is ground, the blue is neutral, and the brown is hot. Wired accordingly and cleaning the power entry resulted in:

Power Supply

Here is the newly cleaned chassis with the power supply and power cord reinstalled and ready for testing.

Because of my earlier experience with H740 power supplies, I know that, unlike some switchers, they run fine with no load. So the second picture shows the first test with a cheap multimeter on the 5V line. The +15V and -15V lines also tested good. The next step is to put together a dummy load array to test the power supply under load. If it looks good under load in terms of level, ripple, etc, then I'll run it for at least 10 or 20 hours solid before powering any boards with it.

So I had a mishap tonight. A couple of light bulbs made a pretty good dummy load. The 5V line was showing some interesting ripple. Unfortunately, in an attempt to use another light bulb to increase the load to see what that did to the ripple, I seem to have blown a fuse. At least I'm pretty sure it's a blown fuse. The symptoms are much like what I've seen before with the H740 and the H740 maintenance manual indicates that a failure of both the +5 and +15V lines is consistent with a blown fuse. New fuses and resistors for a more thorough dummy load are now on order. More to come...

Two steps forward, one step back. The fuses and resistors came in yesterday. I replaced the fuse and was able to adjust the power supply to a little tighter tolerance than it originally was. However, in the process of replacing the fuse, I accidentally knocked loose a thermal switch. It appears to have been glued on, and a first attempt at regluing it didn't succeed. Hopefully, I'll find the right way to reattach it tonight.

Well, a second try at using superglue worked. So it looks like the power supply is ready to go. I've started a little more testing with some high-power resistors for a dummy load. More testing soon.

Reassembly

Here are a couple of pictures of the cleaned front panel during reassembly.

Procuring Other Parts

This machine came into my position without a few of the necessary boards. In particular, I had no M8320 Bus Load board or M8650 Async communications board. This machine also lacked the H851 over-the-top connectors that jumper the two CPU boards together. After locating them, I ordered the parts I needed.

Memory

While waiting for the parts to arrive, I decided to tackle the need for memory. It's been pretty clear from the beginning that I won't be using period memory. PDP-8/Ms were originally outfitted with core memory, and the design of the memory control reflects that. In particular, the sequence of signals that drive the memory are all built around a read-modify-write sequence. This is necessary because the mechanism for reading core also has the effect of erasing the data there.

My original plan was to purchase a modern Omnibus memory board if available. These boards were designed by Vince Slyngstad, the details of which can be found at http://so-much-stuff.com/pdp8/cad/cad.php. It's based on a design by Steve Lafferty described at http://tronola.com/html/ram_for_pdp-8e.html. Unfortunately, at the present time, Vince doesn't have any boards available.

As it turns out, however, I happen to have had an Omnibus prototype board for a number of years. So as a stopgap until more of the memory boards might become available, I decided to build a 32KW memory design on my prototype board. Also basing my design on Steve's, I chose to leave out some features to simplify the design. In particular, I omitted the battery backup and the ability to selective unmap specified 4KW regions from my memory board. The result was a design that only needed 5 chips, as illustrated in the following pictures:

After fixing a couple of bugs, the memory board worked well without the extended memory board, effectively limiting the machine to 4KW. At this stage no testing had been done on the extended memory capability.

System Testing and Debugging

In beginning to test the system with a full complement of boards, several issues were found.

Double Address Increment

One of the first issues that arose was that everytime the deposit function was activiated (and on those occasions when examine worked correctly), the address incremented by two instead of one. In beginning to track what appeared to be a stuck LSB in the data path, the problem basically disappeared. At some later point in testing, it reappeared for a few minutes, but then cleared itself up again. Until the problem returns, I pretty much have no choice but to treat it as cured.

Load Address Failure

At the same time as the double address increment problem was affecting testing, things were made more complicated by the fact that the Load Address front panel operation wasn't working reliably. For that matter, most of the operations with the exception of Halt and Deposit weren't working well. Naturally, I was looking for a chip failure when it was asked of me, "you did use some contact cleaner, right?" After looking at the way the operational switches are wired, I realized that if the NC contact on the Deposit switch were dirty, it would prevent the other switches from working. A little more playing, and I could get things to behave better by wiggling the deposit switch. With more use, things have become pretty reliable. It's still due for a little contact cleaner though.

First Running Code

Once I could put things into memory and control the machine from the front panel, it was time to try running the first checkout test from the maintanence manual. This very short program just increments the accumulator and delays so that the counting is visible on the front panel. The code looks like:

Seeing that running was a major landmark in the restoration project. After a while though, I couldn't help but decide to write a little program to having the lights run back and forth like a Cylon. Doing so, however, requires a longer delay than the counter and that makes things a little more involved. The first cut looks like:

Indirect Jump False Alarm

So naturally the next step was to improve the code with a subroutine for the delay. Not only would that simplify the code a little, but it would also test the JMS instruction, and the indirect jump for the return. Starting at location 0000, the delay routine fell at address 0013. The PDP-8 puts the return address in the first location of the called routine, and an indirect jump through the first location of the routine serves as a return. With the code set up in this way, the back and forth program failed to work and the accumulator appeared to stay at the value 1. In tracking down the "problem" I found that instead of returning to location 0005, the routine was returning to location 0006. Fortunately, before spending too much time debugging, I came across a reference to a feature of the 8 with which I was previously unfamiliar. Locations 0010–0017 in each field are autoindex locations. The contents of such a memory location is incremented before being fetched in an indirect reference. Because the first location of the delay routine was an autoindex location, the indirect jump returning from the routine was behaving exactly as it was supposed to, and there was no fault after all.

Testing the M8650 Boards

In the course of procuring components, I got two M8650 serial cards, an M8650B and an M8650D. The B card is a YA card that came with a 19.6608 MHz crystal. It was jumpered for 1200 baud and receive/transmit ports 30/31. The D card arrived with a 14.418 MHz crystal and jumpered for 110 baud and ports 01/02. In initial testing, the M8650B board failed to produce proper output, and the M8650D board running at 110 baud did not work with the USB serial device I used for testing. However, pulling out an actual terminal that was capable of running at 110 baud showed that the M8650D board was running properly for output. Initially, it appeared that input was not working correctly. Upon examining the schematics for the M8650 board, however, it became clear that a pair of pins on the terminal connector needed to be jumpered together for the input signal to be properly received. Once that was done, the M8650D worked for both input and output at 110 baud. To put together a more usable console, I transferred the 19.6608 MHz crystal to the M8650D board and jumpered it for 1200 baud and the conventional console addresses of 03/04. The result was a system that could run the printing, input, and echo test programs from the Maintenance Manual.

Fixing MA2–3

With a working console, the next step naturally was to toggle in the RIM loader and attempt to load some code over the console port. That's when I saw a fairly serious fault condition. The RIM loader starts at address 7756. Putting 7756 on the switches and hitting "Load Address" so far so good. Putting the first word of data on the switches and toggling "Deposit" not so good. Rather than a next address of 7757, the address lines showed 6357. In other words, address lines 2 and 3 dropped to 0. After a little more playing, it was clear that this behavior was systematic; it wasn't dependent on the addresses involved.

Digging through the schematics and knowing that "Load Address" did work correctly, the problem seemed most likely to be in the data path involving either certain MUXes that weren't part of loading the address or the PC register itself. A little quality time on the logic analyzer later, and the problem was narrowed down to one of the chips implementing the PC. It consists of three 8271 chips which are 4-bit shift registers being used essentially as quad D flip-flops. (They're being used in a way that one would probably use a 74LS175 had the '175 been around that early.) The pictures below show the testing of that chip. From the traces on the logic analyzer, it's clear that two of the flip flops are correctly changing state and two aren't.

Fortunately, the non-functioning M8650 board had a few 8271s on it. So naturally, I stole one from it and used it to replace the faulty one in the CPU. (I've since bought a few on eBay and will use one of them to replace the pilfered one on the M8650 card.) With the faulty chip replaced, the upper address lines worked correctly, and I was able to toggle in the RIM loader and use it to load the BIN loader.

Fixing the OSR Instruction

Earlier in testing the serial interface boards, I had discovered that the OSR instruction was failing. One of the test programs in the Maintanence manual allowed the user to toggle ca character into the front panel switches and have that character repeatedly transmitted to the console. This test failed because the instruction to OR the switch register with the accumulator (OSR) wasn't working. My thinking at the time was that's a relatively unimportant instruction, and I'll worry about it later. Then when starting to use the BIN loader, the OSR instruction failure again became an issue, as the BIN loader looks at the switches to determine whether to read from the console port or from a high-speed papertape reader. It's a simple patch to force the loader to use the console, but the MAINDEC for testing the instruction set also makes heavy use of the OSR instruction. Clearly, "later" had come and it was time to track down why OSR wasn't working.

Attempting to observe what was happening by stepping through single cycles of the instruction, the contents of the switch register did not seem to be making it to the DATA bus. As usual, I began by poring over the schematics to see what might be the problem. It appeared most likely that the problem was on the front panel board resulting in the circuitry that turns on the DATA bus drivers. The good news was that it was pretty simple combinational logic; the bad news was that much of it was made from DEC chips that border on unobtainable. In the course of looking at the behavior on the logic analyzer, it seemed that something was running on the hairy edge. Sometimes some of the bits would correctly get into the accumulator when fiddling with the analyzer probes, on one particular signal. When looking at the signal with a scope, it pretty always seemed to work. So I started to wonder if I could get away with pulling the signal to ground through a resistor. Sure enough, after experimenting with a few resistor values, I found that pulling E5 Pin 3 to ground through a 6.8K resistor makes the OSR instruction work reliably. It's probably not a long-term solution, but at least it buys me some time to attempt to find replacements for the chips involved.

Interrupt Problems

With the OSR instruction working, the BIN loader became easier to use and one of the MAINDEC instruction set tests was passsing. Another MAINDEC test, however, was failing and the point in code where it was failing pointed to a problem with interrupt handling. In construction a few little tests of my own, it was clear that the M8650 was capable of generating interrupts and that the CPU would handle them correctly. I was able to write up a little interrupt-driven echo test that convinced me that much was working correctly.

It turned out, however, that the MAINDEC test was never explicity turning on the card's interrupts. The reason is that the board is supposed to initialize with interrupts turned on, as confirmed by the drawings. So thinking that I might have a bad flip-flop that wasn't clearing or presetting correctly, I pulled the board to attach the logic analyzer. Locating the chip and looking at the back side of the board showed I needn't bother. There was a small modification to the board which swapped the behavior of the clear and preset lines on the interrupt enable flip-flop. A past owner of the board had apparently needed one configured that didn't have interrupts turned on at initialization. Reversing the modification resulted in a board that worked correctly and passed the MAINDEC.

Testing M837 Extended Address Card

With the CPU, memory, and async card working for a basic 4KW system, it was now time to put the extended address card into the system and test it. By comparison, this turned out to be anticlimactic. Putting the card into the system, everything continued to work as before. Some hand testing at the front panel confirmed that I could work with memory outside the first 4KW memory field. Finally, the system passed the MAINDEC test for the extended addressing on the first attempt. At that point, I had a functioning 32KW PDP-8/M!

MAINDECs

These final bits all came together the weekend of 3/28/2015 and 3/29/2015. As a result, the system passed the following diagnostics that weekend:

Running FOCAL

Once everything was running and passing the MAINDECs, the first major application that I ran was FOCAL. The pictures below show the system running one of the demo programs from the FOCAL manual.

Emulating an ASR33 for a Paper Tape Computing Experience

A Very Quick&Dirty Shell for a Desktop PDP-8/M

There's a picture of a PDP-8/M on the net that shows it mounted in an interesting desktop cabinet. It's the only picture I've ever seen of one that looks like that. Since I don't have peripherals that would require rack mounting, I thought it would be cool to build a little shell around my machine that was inspired by that picture. Unfortunately, as VCFe drew near, I threw together one in way too much of a hurry. I'm kind of considering it a rough-out that hopefully I'll get a chance to come back and rebuild more carefully, so it doesn't look quite so awful.

VCF East X

These pics are of the exhibit of this machine from the 10th Vintage Computer Festival, East, April 17–19, 2015.

A New Crystal, Key, and Switch Paddle

Many thanks to three people who attended VCF East this year. One gave me one of the XX2247 ACE keys that fits the PDP-8/M, saving me a lot of trouble (and potential expense) in getting one made from the lock assembly. None of the locksmiths I contacted seemed to feel like they could cut one just from the codes that have been figured out in the community, and one that I took the lock to said it would probably be at least $45 to get one made based on the lock. Another kind soul gave me a a 3-D printed replacement switch paddle that fills in the blank spot on my front panel. As I prepare to take the machine to VCFSE in Roswell, GA this weekend, I've reordered the switches so that the colors are in the right place and the new replacement looks like a good match next to a paddle of a contrasting color. The third person gave me a 19.6608MHz crystal so that I can run both M8650 boards at baud rates higher than 110.

Replacing the Front Panel LEDs

Relatively early in the restoration process, I noticed that the indicator for MA6 wasn't always illuminating when needed. By the time of VCF East, it had stopped working altogether. After the festival, I verified that the problem was the LED itself and not the driver chip. Naturally, none of the LEDs I had lying around properly fit. All the ones I had were the right diameter, but were longer than standard ones and stuck out the front of the plastic frame around the LEDs. So I ordered some replacements, and knowing that they would almost certainly be brighter (or at least a different shade of red), I ordered enough to replace them all. Unfortunately, my desoldering tool was getting clogged, so the job didn't turn out as clean as I'd like, but I do have them all replaced. The panel looks quite a bit better with the brighter LEDs, but interestingly, when things are running, the AC display shows a dim glow on bits that don't have any activity. (First world problems... :))

Repairing the Second M8650

With replacement 8271s and a new crystal in hand, the time had come to address the non-working M8650. Not surprisinginly, with the parts replaced, it functioned as incorrectly as it had on first testing. That's good because consistent misbehavior is always easier to debug than intermitent behavior.

In attempting to sort out the behavior on the transmit side, there were serveral interesting things happening. When running the print test from the maintenance manual that prints the whole ASCII character set, I saw only a few values printed with greater frequency than once every 128 characters. When running the transmitter test that repeatedly transmits the character entered on the switches, I got a different set of values printed. In many cases, the behavior seemed to be determined strictly by the lower 4 bits of the value. I did some other tests that were driven by single stepping the TLS instruction. Doing it this way, I got a mostly different set of outputs.

Given this behavior and knowing that the characters are transmitted LSB first, it seemed pretty clear that there was something going wrong with characters not being transmitted completely. Sure enough some quality time with the logic analyzer confirmed that after the start bit, it was often only transmitting 5 bits rather than 9 (8 data + stop bit). the problem was a bad 8271 shift register (a different one than the one I had pulled and replaced for the PC). Replacing it got the transmit side working.

The receive side was more troublesome. The card seemed to be completely ignoring the incoming bytes. Early testing showed that the bits were getting through the EIA receiver and to the shift register chips, but none of the clocking sequence was getting triggered by the start bit. It took quite a few observations to pin down what wasn't happening. Finally, I was able to identify one NAND gate in a 7400 that wasn't working correctly. I didn't have any straight 7400s in stock, but decided to try a 74LS00. The timing is very close to the original straight 7400s, and it seemed worth a try. The original 7400 basically crumbled as I removed it from the board, but the new 74LS00 went in without any problems. However, the receiver still didn't work.

With the 7400 replaced, the first character received after power-up did now start the timing sequence. However, the sequence never stopped, and no further characters changed the state of the board. The problem was that although the reader active state was being entered, no clock signal was getting generated for the shift registers. The way this clock is generated is in a D flip-flop where there's a fast clock on the preset pin and a slower bit clock on the clock line with the D input grounded. At first on the logic analyzer, it appeared that the rising edge of the clock was occuring during a time when the preset line was low. However, after comparing to the working board and zooming in on the timing, it was clear that the clock edge was occuring when it needed to, suggesting that the flip-flop was bad. Fortunately, I had plenty of 7474s lying around and replacing it resulted in a working board. Next step: getting the serial disk working.

VCFSE

Pecha Kucha Presentation on the PDP-8