PDP-8/E Restoration Log


Dan and Mike picked up the system, made an inventory of the components, and took lots of pictures.

This is Mike's first PDP-8 in his personal collection.


We removed all of the boards, the front panel, and the Omnibus backplane.

We picked the acorn shell parts from the Omnibus connectors, and blew off the dust with compressed air.

There is a manufacturing date on the Omnibus backplane of 5/14/74.

We vacuumed the mouse turds from inside of the chassis and cleaned the dust and grime from the sheet metal chassis.

We powered up just the power supply. All of the output voltages were within a few mV of the desired voltages.

We installed the Omnibus backplane. All of the voltages on the backplane were within specification.

We installed the front panel and powered on the power supply.

Some of the lamps glowed dimly. It may be designed this way to get the bulbs to turn on faster.

We replaced the defective bulbs with real Oshino OL-2 bulbs.

We need to get some Oshino OL-367BP (no longer made) or Chicago Miniature CM2309 spare bulbs because the Oshino OL-2 bulb is no longer available.

We installed all of the processor boards, but no memory boards.

The two processor boards were installed backwards when we picked it up.

There are some signs of life in the system.

If you push the EXAMINE or DEPOSIT switch the MEMORY ADDRESS increments.

This is the expected behavior, so something is working.

We installed both 8k x 12 core memory stacks and powered the system on.

Now when you push the EXAMINE or DEPOSIT switch the RUN light goes on.

You can see in the above image that the FETCH and EXECUTE indicators are both on.

Next week:

Remove both core stacks to see if the EXAMINE and DEPOSIT switches are operational again.

Install one core stack and test the EXAMINE and DEPOSIT switches.

Install the other core stack and test the EXAMINE and DEPOSIT switches.

This should show if one of the core stack boards is holding a signal on the Omnibus.


We removed both core stacks and found that pushing the the EXAMINE or DEPOSIT switch causes the MEMORY ADDRESS to increment.

So we have life back in the processor and know that one or both of the core stacks causes the processor problem

We put the lower 8k core stack back in and EXAMINE or DEPOSIT still works.

We can actually store and retrieve data from the core.

Installing the second core stack caused the failure again.

We pulled the upper core stack, but left the the Sense/Inhibit and the XY boards installed.

The processor still worked.

This is where Warren would say that I still need adult supervision.

I never noticed that the core stack was installed up-side down and shorted lots of Omnibus lines.

Dan noticed it right away and suggested that I turn the board over.

The processor now works with 16k installed.

We entered a simple ISZ loop and were rewarded with an incrementing AC.

So lots of the processor is working correctly.

The system is sensitive to vibration, especially the core stacks.

We pulled all of the core stack boards, and cleaned and treated the gold edge fingers and backplane connectors with DeoxIT.

The vibration sensitivity is now gone.

I tried a small program to transfer the AC to the MQ and back.

It looks like bit-3 of the MQ is stuck on.

I ordered some Signetics 8271 chips because they are used to make up all of the registers.

The ISZ loop seems to run much faster in the upper 8k of core than in the lower 4k.

This needs investigation because both core stacks are the same speed.

We swapped the current loop cable that was connected to the M8650 KL8-E console teletype control with a BC01V cable.

The BC01V cable enables the RS-232 capability of the KL8-E interface.

We connected the BC01V cable through a null-modem cable, to a 25-pin to 9-pin adapter, and to the 36" flat screen system running a terminal emulator.

We entered a program that sends all possible characters to the console, but never saw them on the screen.

A character echo program didn't see any characters entered from the console either.


In between lots of visitors today we did some more debugging on Mike's PDP-8E.

Last week we toggled in a small program that read characters from the serial console through the M8650 Asynchronous Data Control board and wrote back to the serial console.

It would not echo characters typed on the serial console.

This week we found that the receiver in the M8650 worked OK, but the data sent back to the serial console was not correct.

Any characters typed into the serial console would show up in the AC (Accumulator) correctly.

The program sends the received data back out to the serial console.

The data to send to the console is correct when it is latched from the Omnibus signals and sent to the 8271 chips that make up the UART.

The data is not correct when it leaves the serial port.

We have very good documentation on the M8650 board so we should be able to repair it.


Last week we could get data from a terminal into the PDP-8/E, but not back out.

After some debugging we found that there was a start-bit, 8 data-bits, and no stop-bits going out the serial port.

That really confused the terminal.

The 7474 flip-flop E20 on the M8650 KL8-E board was defective.

We replaced it with a NOS spare IC.

Now it talks both directions to a terminal.

The defective IC had slightly rusty leads, just like we found in the PDP-8/I and PDP-8/L.

We replaced lots of rusty IC in the 8/I and 8/L before they behaved well.

Hopefully this 8/E won't require as much surgery.

We toggled in the RIM loader, then sent the BIN loader and the Instruction Test #1 through the serial port from a terminal emulator.

The instruction test failed very quickly.

It looks like the CLA instruction didn't work.

So we have some debugging to do in the processor.


I found that bits 2 & 3 in memory fields 2 & 3 (the upper 8k) are always on.

It also looks like there might be a problem with memory location 7764 in field 0 (the bottom 4k).

The instruction 7510 gets changed to 3510 so the RIM loader doesn't work correctly.

I should be able to load the RIM loader in to memory field 1 for now to get around the problem.

I plan to install a 32k RAM memory board in this system, so fixing the core memory may not be necessary.

I tried all of the toggle-in tests for the PDP-8.

So far it looks like the processor is working OK.

Even the stuck bit in the MQ register seems to be OK now.


I picked up an RX08 8" Floppy Disk Controller and a KL8E Asynchronous Interface while on a business trip to Germany.

There are lots of RX01 and RX02 drive systems in the RICM collection so getting one to work should not be too difficult.

Kyle Owen wrote a program that emulates a disk drive connected to a serial port.

I can jumper the KL8E to be the second serial port and for a faster baud rate.

The 8E should be able to boot OS8 from the emulated disk.

Once that is working, it should be easy to make some bootable OS8 floppies.


I removed the SYKESdisk 8" floppy subsystem because it is very unlikely that I will ever find an Omnibus controller for it.

I installed a DEC RX01 8" floppy subsystem in the cabinet where the SYKESDisk was. Fortunately they were the same size.

I swapped the 30A plug on the cabinet power cord for a 20A because we have 20A receptacles available.

I powered up the whole cabinet and found that the fan at the top of the cabinet works.

The 716-B power supply that powers the DC side of the TU56 makes +5V, but does not make -15V.


I received a first article version of a 32k RAM board kit this week.

It only took about an hour to assemble it and give it a try.

The 8/e had just the basic processor, the memory extension, and a serial interface installed in a 20 slot backplane.

I removed the 6x core boards and installed the RAM board at the back of the chassis next to the bus loads card.

The processor was so far mostly untested because of problems with the original core memory boards.

I could deposit and examine locations in all 8x fields from the front panel.

It is very cool having 32k of memory in a PDP-8!

I tried a little ISZ loop and that worked OK.

The RIM loader worked OK and loaded the BIN loader.

The BIN loader worked OK and loaded MAINDEC-8E-D0AB, Instruction Test 1.

The instruction test worked OK, so I ran it for 30 minutes.

This is good news, so I guess that some of the processor is probably OK.

I loaded MAINDEC-8E-D0BB, Instruction Test 2.

This failed right away at 4327 in IOT test #9.

Investigation showed that the mask at 0064 that should have been 5200 was 0.

I fixed the mask and the diag failed again at the same location with the same problem.

I moved the RAM board to the front of the backplane in the slot just behind the serial interface and ran Instruction Test 2 again.

This time it ran OK, so I let it run for 30 minutes.

More good news, lots of the processor is working OK.

I loaded MAINDEC-8E-D0CC-D, 8E Adder Tests.

That ran OK, but I didn't have the patience to run it for 4 hours to see if all 8x fields worked.

I loaded MAINDEC-08-D1EC-D, Extended Memory Checkerboard.

I set it for 8x fields of 4k.

It failed several times in field 3 at loca