PDP-9 Restoration Blog 2022

Go to the earlier restoration blog.


When the diag fails by leaving the PIE enabled after an IOF instruction, we see an IO RESTART pulse at the end of the fetch cycle of the IOF instruction, and 2 mS later we see another IO RESTART. We should not see the IO RESTART pulse after the fetch and we should see an IO RESTART pulse 4 mS after the beginning of the IOF instruction. The early IO RESTART pulse could terminate the IOF instruction execution just after the fetch cycle by restarting the Control Memory, so the IOT parts of the IOF instruction are not processed and the PIE is not disabled.

After running the toggle-in PIE test for a few minutes the processor halted with PIE on, so the fault can be reproduced.

We had temporarily replaced the S202 flipflop in I/O slot J07 with an R202 flipflop. The only difference between the S202 and the R202 is that the S202 has stronger pull-down resistors for faster edges, or heavier loads. We had replaced transistors Q3 & Q4 in the S202 with new 2N3639 parts, but it made no difference in the earlier testing, When we put the S202 back in the processor would not run the PIE test at full speed. It ran OK at REPEAT SPEED 5. We put the R202 back in, and the processor ran OK, but halted with the PIE On.

The other half of the S202  flipchip is the flipflop for CLK REQ. Maybe that part of the S202 is broken? All of the transistors and diodes measure OK when diode-tested with a DVM. We replaced Q1 & Q2 with new 2N3639 parts. We looked at the behavior of the original transistors on the Tektronix transistor curve tracer and saw that one transistor was really non-functional. We replaced the S202 in I/O slot J07 and the processor is back to halting with PIE on. Now we can look at the IO RESTART pulses, and why there are too many of them. 

We looked at the signals that are used to create the IO RESTART signal and eventually got to the S202 flipchip in slot J18 that implements the IO 0 and IO 1 flipflops that make the Gray Code counter. We noticed that the signal on pin S did not have a sharp rise time, so maybe it had a weak Q3 transistor. We replaced Q3 & Q4 with 2N3639 parts, and reinstalled the S202 in I/O slot J18. The processor now runs the toggle-in ION/IOF test. The 'scope traces of the behavior of the Gray Code counter look good.

PDP-9 Restoration Blog Starting 2022

We tried to boot ADSS, but there was no DECtape motion. Instruction Test #2 ran OK for a few minutes and then halted at 05717, E1549. The status register showed that there was a keyboard interrupt pending when there should not be any interrupts. We were fiddling with the VT220 serial console setup at the time, so it is likely that a character was sent to the PDP-9 and caused an interrupt. We had some difficulty with the VT200 setup and finally found that 7-bits, Mark Parity was the correct setting. We restarted the diag, and it ran OK.

We decided to try MAINDEC-9A-D3RB-D TC02 DECtape Random Exerciser to see if the DECtape controller is responding to the IOT instructions correctly.  It looks like the DECtape controller and the drives are working OK.

The ADSS paper tape bootloader loads into the very top of the 8k of core at addresses 17637-17777, and then starts executing at 17646. We are not sure why the ADSS bootstrap is not moving drive 0 and booting ADSS. There is a HLT instruction at 17704 if there was an error with a DECtape command. We need to try the ADSS bootstrap again, and pay attention to the halt address and the contents of the AC that is the TC02 Status Register B and contains the error bits. There are also some error lights on the TC02 display panel that we should look at. That will be the project for next week.


It looks like the booting problem was due to operator error. I didn't position the ADSS bootloader paper tape early enough on the reader, so it missed the first few words that get loaded, and made a mess of the bootloader. I repositioned the paper tape so there was a few inches of blank paper tape before the optical reader, and it booted ADSS. It looks like everything is working again.

That was short lived. After running for about 30 minutes it is now printing garbage on the serial console. It is printing 10x Nul characters (000) and a CR-LF instead of "KM9-15 V5A", a CR-LF, an EX-LF (003) instead of a (215), an ET character (004) instead of a "$" (244). We tried the Teletype and got the same results, so the problem is in the PDP-9.

We toggled in a short serial console loopback program. The results were mixed. Most characters work OK, but many double type. Some, like "I" display an "I" and then a tab.

We loaded MAINDEC-9A-D01A-D Instruction Test Part 1.  The diag immediately halted at 12017 (around E963), so the processor is broken again.

Examining address 00000 puts 00020 in the AR, so bit 13 is stuck somewhere.  Bits 11 & 12 in the AR cannot be loaded from the switches. Looks like this problem was a flaky bit 13 switch. After wiggling it, it seems to work OK. We will continue the debugging on Saturday.


We ran the built-in maintenance tests. The Memory Buffer, Program Counter, Adder Register, and Accumulator are all working OK. We let it run for a while to warm up and see if it will fail. After 90 minutes there no signs of failure.

We booted ADSS V5A from DECtape, and it seems to work OK.


A while ago crew at the LCM+L got UNIX V0 running on their PDP-7, the same model of machine that Thompson & Ritchie originally used to develop UNIX. The PDP-7 at Bell Labs had a DEC/Burroughs single platter disk drive that had 1/2 of the capacity of the RB09 disk for the PDP-9. Their PDP-7 didn't have a disk, so they made a simple I/O device to emulate a disk and wrote a new UNIX driver for it. They were able to login to UNIX using Ken Thompson's userid and password. A very impressive feat.

Since the PDP-9 is a more modern & faster version of the PDP-7 it can also run UNIX V0. We have the same problem of not having a disk, and an additional problem of not having the EAE (Extended Arithmetic Element) option. We have most of the boards needed to add the EAE option. We could adapt the disk emulator that the LCM+L made for their PDP-7 to the I/O bus on the PDP-9.

Another possibility is to write a TC02/TU55 DECtape driver for UNIX V0 and use DECtape for the mass storage. Since DECtape is a block addressable read/write device it could work, but would be slower than than a disk. All we would need is the EAE option and some software.

The PDP-9 restarted ADSS V5A that was left in core, and seems to be running OK. We experimented with FORTRAN IV and DDT. This machine only has 8k of core memory so it only supports the abbreviated versions of FORTRAN IV and Macro. The abbreviated versions use a command syntax that is different than the full sized versions that are in the documentation. We are struggling a little to figure out the syntax or the abbreviated versions.


We demonstrated the machine today. As usual it was a little flaky, but we got it to run OK. The unit select switch for what we usually us a drive 2 was flaky. We had to rotate the drum a few times to get the select to go on.  Something to fix next time.


We started reverse engineering the special interface chassis that used to transfer data from a PDP-11/23. The PDP-11/23 had DL11-W GPIO boards to talk to the PDP-9 interface chassis. It will be interesting to find out how they handled the interface between the +5V TTL logic in the PDP-11 with the -3V transistor logic on the PDP-9.

The signals from the PDP-11/23 go to a W500 High Impedance Follower FlipChip, and then to 9x R203 Triple Flip-Flop FlipChips. So it looks like data can be transferred from the PDP-11/23 to the PDP-9, but not from the PDP-9 to the PDP-11/23.

We had hopes that we could use this interface with a Raspberry Pi to emulate a disk drive. Since it is unidirectional that is not possible. Looks like we will have to invent a 3.3V TTL to PDP-9 negative logic interface. We can use the negative bus driver cards from a PDP-8/I as an example, and then SPICE simulate the circuits before we prototype them.


We continue to reverse engineer the special interface chassis. We are creating a spreadsheet with the source and destination of the Wire-Wrap wires. When it is complete we can use the spreadsheet to make a schematic.

Some of the wiring to the W103 Device Selector FlipChips looks a little strange. We also noticed that one FlipChip is in an unwired slot, and there are wired slots without FlipChips. Hopefully we can figure all of this out. It might be useful for transferring media images to core memory, or to create DECtapes or 7-Track Magnetic Tapes from images.


We demonstrated the PDP-9 to a group of enthusiasts. We ran the "Hello World" program, and it seems to be working OK.


It ran fine for an hour, and then died and would not boot ADSS from DECtape. It passes MAINDEC 9A-D01A INSTRUCTION TEST PART 1, so most of the processor is functional. It halted at E1135 in MAINDEC-9A-D02A Instruction Test Part 2. This part loads 777777 from memory into the AC, deposits zeros into memory at 17777, compliments the AC, and skips over the HALT instruction if the AC = 0. The memory location contained 773777 instead of 777777 so it failed. Now we need to determine if the paper tape loader microcode failed or if there is a problem with memory. I will fix this on Saturday if we don't have too many visitors. 


We had lots of visitors today, so not much time for debugging. We reloaded MAINDEC-9A-D02A Instruction Test Part 2. The constants that start with K0 @ 006307 were all off by a few words. It looks like it skipped loading 7 constants starting @ 006307 and loaded the rest.

We loaded MAINDEC-9A-D0DB JMP-Self Test. It looks like it is running OK. The CLK light is on, but the PIE light is not on. We manually set interrupts on and the PIE light stayed on. It looks like this behavior is normal. We changed the settings from Ring Bell On Error to Ring Bell After Program Loops, and the bell sounds every 20 seconds. It looks like this program runs OK.


We ran MAINDEC-9A-D0EA JMP-Y Interrupt Test. It ran, didn't report errors, but there were no changes to the pattern of lights on the console. We stopped the diag, and single-stepped it so we could watch what it does. The instructions in memory didn't match the program listing. The program starts at 17400. Core locations 17400-17417 all contain 000000 instead of the expected instructions. We reloaded the diag, and the core locations 17400-17417 contained the expected instructions. We reran the diag and this time it ran and rang the terminal bell about every 6 seconds, so it must be running OK. You can also see the AC lights on the console contain the BELL character, 000207, when it rings the bell.

We ran MAINDEC-9A-D0FA JMS-Y Interrupt Test. It ran OK in 6 second cycles.

We ran MAINDEC-9A-D0BA ISZ Test. It ran OK in 2 second cycles.

We ran MAINDEC-9A-D0CA Memory Address Test. It beeped after about a minute. The remainder of the test took 20 minutes to complete and then beeped the terminal.

We ran MAINDEC-9A-D1AA PDP-9 Basic Memory Checkerboard Test. It ran for a few seconds and then halted at 000223. The AC contained 16034 which is the address of the core memory error. The core memory location should have contained 000000, but actually contained 002000. The pattern control word was 037700. The manual says that the pattern control word should be 000000 or 777777.

We continued running the diag and this time it said that the memory problem was at 16054, and the contents should have been 000000 but were 002000. We turned on switch 7 to disable testing bit 7. We continued running the diag again, and now it is running OK, but ignoring errors on bit 7. I am guessing that there is a problem with the G219 Digit Drive FlipChips for bit 7 in slots AB09 or EF09, or less likely the G009 Sense Amplifier in slot B25. The problem might even be the G805 in slot HJ03, or the G622 in slots H11 and H12. Now the only error that it is getting is at address 17515. We ran the diag for a while with it configured to ignore bit-7 errors. When we enabled bit-7 errors it ran OK and reported no errors at all. We don't like the idea that the problem went away, because we know that it will be back.

We tried to boot ADSS from DECtape, and got a Timing Error from the TC02 DECtape controller. We tried several tapes and continued to get the timing error. Next time we need to try a different tape drive to make sure that the problem is in the TC02, and not in the TU55 tape drive that we used.


We tried booting ADSS from the lower right TU55 DECtape. The DECtape rewound, and it looks like it read some blocks and then executed them.  Bit-0 in the MB was cycling from dim to bright every few seconds and the processor stayed running. Retrying the boot yielded the same results. Reloading the DECtape bootstrap paper tape yielded the same results. The timing (TIM) indicator is lit at this time. Retrying the boot yielded the same results.

We loaded MAINDEC-9A-D3BB TC02 Basic Exerciser to see what parts of the TC02 DECtape controller work. We tried the TC02 Control Test described in section of the documentation. It halted at 240 as expected. Se continued the test, and it got stuck in a loop. We tried to single-step the diag starting at address 200, and noticed that the AR register actually contained 220. We turned all of the address switches off, pressed EXAMINE, and the AR and the MB contained 20. It looks like we have a stuck bit-13. We powered off the system so we could get access to the card cages on the back door. After powering on, the stuck bit was gone.

We tried: