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

In all cases the location should have been 0000 or 7777 and was some other value.

Warren suggested that the issue might be from rolling over from the address 30777 to 31000.

In this case 9x address lines would transition from the ground to high state.

Warren also suggested looking at the WRITE EN\ signal to see if there were any glitches, and to look at the power/ground on the RAM chips.

I was thinking maybe the memory Address and Data bus loading is probably very light because of the modern interface chips in the RAM board.


After many discussions last week the consensus was that the 74ABT540 IC that generates the Write Enable signal for the RAM chips was too fast.

It was decoding glitches on the MD DIR\ signal which cause the RAMs to store random data.

I replaced the 74ABT540 with a slower 74LS540, and everything works OK now.

I ran MAINDEC-08-D1EC-D, Extended Memory Checkerboard for 90 minutes without seeing a single error.

I also installed the board in the back of the backplane where memory normally goes, and that worked OK too.

I installed a second 8650 serial interface, this one is the -YA variant that supports speeds above 110 baud.

I had to change the default device code from 03/04 to 40/41 for the second port, and set it for 2400 baud.

I ran some simple diagnostics, and it seems to work OK.

I couldn't find another BC01 serial cable to connect this board my my laptop so I will need to make one.

I loaded and ran the MAINDEC-08-DIRXA-C RX8-RX01 Diagnostic Program.

I am not sure that I configured it correctly and it showed some errors.

I need to study the source code and see what it was trying to do.

Configured to test only the RX8E Omnibus interface with the SW set to 7000.


607 600 600 177 0 0

425 404 404 0 0 0


Now that the RAM board in the PDP-8/e is working OK, we did some more experimenting.

Kyle Owen wrote a disk server program that emulates a DEC RK05 disk drive.

We configured the second serial port in the 8/e to 38,400 baud and made a special cable to connect the KL8E serial controller to the PC's 9-pin serial port.

You run the disk server on a PC, connect the PC to a second serial controller in the 8/e, toggle in a serial bootstrap program, and the 8/e boots the OS/8 operating system from the emulated disk.

The RK05 disk image on the disk server PC is in the same format as used with the SIMH PDP-8 simulator, so there are several images available to try.

The disk image needs to be modified to replace the RK05 disk handler (device driver) with the serial disk handler, but Kyle wrote a program to do that.

After running the serial boot strap it took just a few seconds to boot OS/8.

The disk image that I used contained lots of diag programs, so it was much more convenient than loading the paper tape images through the serial port.

Unfortunately the disk image did not contain a copy of the MAINDEC-08-DIRXA-C RX8-RX01 diagnostic program.

The RX01 manual says that the default Device Code for the RX8E is 70, so that is what we used last week.

After some digging through OS/8 source code we found that it needs to be set to 75.

If you tell the diag program to use 70 it will actually use 75.

That diag explains the failures last week.

We loaded the MAINDEC-08-DIRXA-C through the serial port and tried it again.

It looks like the basic controller tests take just a second to run.

The tests for the connection to the RX01 controller failed, and behaved strangely so I don't believe the results.

Next time we will dig deeper into the RX8E and RX01.


I tried to boot OS/8 from the serial disk server again. It did very little.

I toggled in the RIM loader, but it would not load the BIN loader.

I single-stepped the processor and was surprised to see it jump to location 0.

I toggled in some simple instruction tests and found that BSW, RTL, RTR, and JMP were broken.

I bought an M8300 Major Registers board in eBay a few weeks ago, so I swapped it.

I was a little amazed that it actually fixed the problem.

I booted OS/8 and tried to run the DHKAFA.DG 8E/M/F INSTRUCTION TEST 1.

It halted the processor, and the contents of core did not look the same as the MAINDEC-8E-D0AB Instruction Test 1.

I need to research OS/8 diagnostics.


The plan for today was to test the 32k RAM memory board behavior after substituting slower 74ALS245 bus drivers for the faster 74ABT245 drivers.

Modern fast ICs react to Omnibus glitches that the original slower parts ignore, and the fast rise/fall time of the modern parts causes more crosstalk.

Unfortunately the 8/e decided that it would not write to memory.

If the 8/e still had core memory this fault would have wiped memory because core destroys data when it reads.

The RAM memory does not do a destructive read, so it read fine, just would not write.

Both the EXAM and DEP switches did an EXAM.

I disassembled the front panel so I could get a DIP-Clip on the ICs and see the signals.

I looked the signals from the EXAM and DEP switches and what signals they affected.

I found that the MD DIR IN signal from pin 10 of E4 normally had a few mV of noise on the signal, but went to ground when the EXAM switch was pressed.

It looks like the MD DIR IN signal should float high and get pulled low by the EXAM switch.

That would put the memory bus always in the read direction and never allow a write.

I pulled the Omnibus boards one at a time and looked at the MD DIR IN signal.

When I pulled the M8330 Timing Generator board the MD DIR IN signal went to 4V.

The 8/e doesn't have the EAE option so I could put the M8330 on an extender board.

I traced the MD DIR IN signal on from AK2 on the PCB to pin 10 of the 7417 IC E35.

That IC is in section E7 on the schematic.

Pin 11 of E35 was always low, so the open collector output was always active.

The signal for the driver comes from the 1 output from the 74H74 IC E30.

The clock signal on pin 3 was active when the processor was running and pulsed when EXAM or DEP was pressed.

The FAST(0) signal on pin 2 was always low, so that explained the driver chip always active.

The 74H74 IC E31 in section B1 of the schematic creates the FAST(0) signal.

When DEP was pressed there was a pulse on clock pin 3 of E31 and the the data on pin 2 was high.

The output on pin 5 went high on the rising edge of the clock signal, but went low again on the falling edge of the clock signal.

So, it looks like the SN74H74 IC E31 has failed.

We have replaced lots of 7474 parts on other restorations, so finding a faulty one in the 8/e was not a surprise.

The SN74H74 parts have been obsolete for a very long time, so eBay to the rescue.

I will repair the board this week and try again next Saturday.


Our debugging of the M8330 KK8-E Timing Generator last week was correct.

I bought some NOS TI 74H74 ICs on ebay and replaced the defective IC E31 on the Timing Generator.

The system is operational again and booted OS/8 from the serial disk emulator.

I tried to run the DIRXA-D RX01 diagnostic from OS/8, but it complained about an unknown interrupt and died.

I need to research the procedure for running diags from OS/8 more.

I modified the BIN loader so it would use the second serial port, the one that runs at 38,400 baud instead of 110 baud.

Loading the MAINDEC-08-DIRXA-D from the tape image resulted in a loop where it kept asking for the Switch Register settings.

I installed the M8357 RX8-E diskette controller and tried loading MAINDEC-08-DIRXA-C.

This time the BIN loader would not load the diag.

After much fiddling I found that removing the RX8-E controller let the BIN loader work correctly.

Either there is an IOT decoding problem on the RX8-E, or the board is holding an Omnibus signal that it should not.

That will be the project for next week.


Lots of visitors again today with some nice donations so not so much time to debug the RX8E diskette controller.

We ran the MAINDEC-08-D1EC-D Extended Memory Checkerboard for 60 minutes without errors.

We replaced the 74ABT245 bus drivers on the 32k RAM board with slower 74AALS245 parts.

We again ran the MAINDEC-08-D1EC-D Extended Memory Checkerboard for 30 minutes without errors.

The slower bus drivers will make less noise on the Omnibus and seem to work fine.

During some debugging the processor broke again.

Anytime you pressed the EXAM key the processor would go into the RUN state.

We replaced the M8330 KK8-E Timing Generator with a spare M8330-YA board and now the processor works OK.

We wrote some simple diagnostics for the RX8E diskette controller.

We looked at the MD03..MD08 L and BUS I/O PAUSE L signals from the backplane when executing IOT instructions to device 75.

All of the signals look OK.

We verified the inputs to the Signetics 314 7-input NOR gate E34 and all go low when the BUS I/O PAUSE L signal is active.

Unfortunately the pin 3 output of E34 is always high so the RX8E will be selected for any IOT address.

This explains what we observed last week where the RIM and BIN loaders would not work with the RX8E installed.

We will try to get a replacement Signetics 314 chip this week so we can continue debugging next week.


We did more debugging on the RX8E 8" diskette controller in the PDP-8/e.

Last week we found a bad Signetics SP314A 7-input NOR gate E35.

Vincent kindly donated a replacement part.

That fixed the problem of the RX8E being selected by any IOT address and lets the serial ports work with the RX8E is installed.

Just to be sure the IOT logic was working correctly we toggled in a program that executed all 8 possible IOTs for the RX8E.

We looked at the output pins on the SN7442 BCD-to-Decimal IC E41 and triggered the 'scope on the RX8 SEL signal from pin 3 of E35.

For each output pulse from each pin of E41 we saw 8 pulses on the RX8 SEL signal.

That meant that all of the IOT decoding was working correctly.

The next issue we found was the address bit 10 was always on when we pushed the LOAD ADDRESS front panel key.

Removing the RX8E fixed the problem, so we knew the problem was on the RX8E.

We didn't know if the problem was the output of the 8881 E29 or the input of the 8837 E25.

We cut pin 10 of E29 and it fixed the address problem.

Even though this is not a fix, it let us continue debugging.

We will beg for some replacement DEC 8881or SN7439 ICs this week.

The Signetics N8881N might be a suitable replacement, but we need to do some more checking.

We could use a SN7401, but the sink current is much lower than that of the real parts.

A toggled in test program that did an INIT function showed that all of the flags were off.

Then we turned Maintenance Mode to force the flags to turn on and checked the flags.

That didn't work.

We found that the SN7474 E2 would not stay set so we will replace it.

Click on the image for a larger view.

The upper trace is E32 pin 13 and the lower trace is E32 pin 12.

Pin 12 is stuck at 0.8V instead of having the inverse of the signal on pin 13.

We looked at the other signals going to E2 and happened to find that the BTP3 H signal was missing.

The SN7404 E32 has no output from pin 12 even though the signal is present on the input pin 13.

We will replace that IC too.


Another busy Saturday. We fixed an iMac G5 for a visitor. Not sure what was broken, but it worked after we disassembled it, wiggled things, and put it back together.

We replaced the defective SN7474 flip-flop for the MAINT signal, the SN7404 inverter for the BTP3 signal, and the DEC 8881 bus driver for the BUS DATA[8..10] signals.

The serial ports now work correctly with the RX8E installed.

I used the RIM loader to load the simple diag that I am writing.

Some quick testing showed that bit 5 in the diag that I just loaded was always off

Trying to store 7777 to any memory location resulted in 7677.

The 'scope showed good data on the bus, and bit 5 changed with the setting of the bit 5 switch on the front panel.

I am so conditioned to looking for IC failures that it didn't occur to me to check the bulbs in the front panel.

Replacing the bulb for bit 5 fixed everything.

Another case for Warren's adult supervision.

I wrote some simple diagnostic tests to check the state of the DONE, TRANSFER REQUEST, and ERROR flags.

They all work now and control the processor's skip functions correctly.This is good progress.

I ran three different versions of the MAINDEC-08-DIRXA-C-D RX8-RX01 Diagnostic Program to test just the RX8E controller board.

They all ran and didn't report errors, but they looked like they were stuck in a loop.

They responded to a ^C character from the keyboard so they were still alive, but they never reported completing a test loop.

We have the source listing for the diagnostics, but they are very complicated and difficult to understand.

I need to find someone who has a functional RX8E and can run the diags to prove the the diags actually work OK.

I went back to writing my own tests that exercise the circuitry on the RX8E, but I need to use a 'scope to see if everything is working OK.

I will write more diags this week and test more circuitry next week.

Tested and working:

INIT flip-flop and related signals, INTR instruction.

XFER flip-flop and related signals, STR instruction.

ERR flip-flop and related signals, SER instruction.

DONE flip-flop and related signals, SDN instruction.

MAINT flip-flop and some of the related signals, some parts of the LCD instruction.

8/12 flip-flop and some of the related signals, some parts of the LCD instruction.

I need to highlight the parts of the circuitry that have been tested on a schematic to make sure that everything gets tested.

RX08 To Do:

Test the Transfer Register. It looks like I can read/write the TR in MAINT mode.

Use the PDP-11/44 to test the RX01 and borrow the RX02 from the 11/44.


The RX8E controller looks like it is working well now, so we connected it to an RX01 single-density diskette drive to see what it would do.

The diskette drives should make a clunk when the clear button on the 8/e control panel is presses, but no luck.

We traced the INIT signal from the RX8E, to the M7726 Floppy Disk Control Board, to the M7727 Read/Write Control board, to the solenoids for the diskette heads.

R82 on the M7727 was quite warm, so the head solenoid for drive-0 was activated.

Even though the INIT signal looked OK there was no clunk.

Since we have lots or RX01 and RX02 drives in the warehouse we did a survey of the other RX01 drives instead of debugging this one.

We were a little surprised that all but one RX01 had RX02 control boards inside.

We tried several RX02 drives with varying levels of success.

A this point we are not sure if the diagnostics are working correctly, if there is a still problem in the RX8E controller, or there is a problem in the RX01 or RX02 drives that we tried.

It would be really helpful if someone had a working diskette system on a PDP-8/e/f/m system and can verify that the diagnostics actually work.

With DIRXA-C and one of the RX02 drives the MAINDEC said:


423 404 404 0 0 0 0

443 404 404 0 0 204 0

With DIRXA-D and a different RX02 drive the MAINDEC said:


2200 26 0 170 200 23 25 30 0 0

The code=170 means DATA AM NOT FOUND IN TIME

With DIRXA-C and yet another of the RX02 drives the MAINDEC said:


423 404 404 14 14 4 0

1440 1260 1401 14 14 4 0

With DIRXA-C and no drives the MAINDEC said:


1416 1260 1401 14 14 4 0

I wrote a little program to get the RX8ES and ERCOD registers from the RX8E.

RX8ES = 0014, bit-8 = RX01, bit-9 = Init Done

ERCOD = 7220, I don't know what this means so it is probably wrong.

Next week we will use one of the PDP-11 systems to test the diskette drives, and try another RX01 drive that we found today on the 8/e.


Because we don't know if any of the RX01 or RX02 drives are working correctly, or if the RX8E is completely fixed I went back to a more structured approach to testing

I used the small diags that I wrote to exercise parts of the RX8E circuitry, looked at the signals with a 'scope to make sure that everything was OK.

I used a highlighter to mark the signals and gates on the RX8E schematic that have been tested and have about 85% test coverage now.

I need to figure out how to get data into and out of the Transfer Register in Maintenance Mode to get the test coverage to about 95%.

I will need partially working RX01 or RX02 diskette subsystem to be able to test the remaining 5% of the RX08 circuitry.

Once I get to 100% test coverage I will go back to debugging an RX01.

Many people said that the RX02 diskettes will not pass all of the diags and will not boot OS/8 in double density with a 32 instruction or less bootloader that will fit in a MI8E board, so I will stick with and RX01 drive.

The system was powered on for most of the day while we were reassembling the CRAY J916.

After I got back to testing it looks like something is broken in the processor.

It will read/write memory and will execute a JMP instruction, so there are no major failures.

Next week I will run the toggle-in tests to see if most of the instructions are OK, and then run the MAINDEC instruction tests.


I spent a few hours on the RX8E today. The 8/e processor died yesterday and I didn't want to leave it broken.

It would run all the instructions except Operate instructions which would cause the PC to get loaded with an address that was not even close to the next address.

I tried the spare M8310 Major Register Control that I had and it actu