PDP-9 Restoration Blog 2026

2/14/26

• We finally got power to the PDP-9 and the TU20 tape drive. The PDP-9 powers up, but none of the console switches have any effect. It will not run the built in diagnostics from microcode. This should not be difficult to diagnose and repair because we are very familiar with the timing circuitry for the microcode.

• The TU20 was powered up for the first time in several years. The vacuum pump works OK. The upper tape hub is difficult to rotate and the lower hub is frozen. This should also be simple to fix. We have a diagnostic box for the TU20 so we can test the tape drive offline. Once we get it working fairly well we can connect it to the TC59 controller in the PDP-9 and run diagnostics.

3/14/26

• On a whim we powered on the PDP-9 and tried the maintenance tests that are built into the microcode. Much to our surprise it ran these simple retister-to-register tests that show that the adder works and registers can exchange data. 

•  We toggled in a JMP-JMP pair of instructions, and it actually executed them.

• We loaded MAINDEC-9A-D0BA ISZ Test and let it run for 20 minutes without errors.

• We loaded MAINDEC-9A-D0CA Memory Address Test and let it run while we worked on the PDP-11/40. After more than an hour the processor stopped executing instructions, but the Program Stop indicator was not lit. This means that the Run/Stop flip-flop was still in the Run state, but the next instruction was not starting.

• We could EXAM and DEP memory, so at least the microcode is cycling.

• Page 40 of the processor schematics shows the RUN flip-flop. We need to look at the CLK, CLK POS, and PWR CLK POS signals are active when the RUN flip-flop is on.

• Page 47 of the processor schematics shows the Control Memory Timing circuitry. We need look at the circuitry to see if the timing circuitry is not running.

3/18/26

• We toggled in a simple JMP-JMP loop and it ran OK.

• We tried to run some diagnostics from paper tape. They look like they load OK, but they get stuck in a JMP loop. After looking through the source code we found that it was TSF IOT instruction trying to write to the serial console terminal. We didn't have a terminal plugged in, so it got stuck there. After plugging in a terminal the MAINDEC-9A-D1FA PDP-9 Extended Memory Address Test ran OK.

• MAINDEC-9A-D1BA PDP-9 Extended Memory Checkerboard Test, MAINDEC-9A-D0BA ISZ Test ran OK.

7/8/26

• We loaded and ran  MAINDEC-9A-D1BA PDP-9 Extended Memory Checkerboard Test. It ran for just a few minutes and the processor stopped, but the PRGM STOP indicator was not on. The PC was 00022.

• Restarting the Maindec didn't work correctly. The processor didn't stop, but the pattern of Memory Buffer indicators didn't show the correct pattern.

• Reloading the Maindec resulted in correct operation for about 10 minutes. Reloading it again the processor ran for more than 45 minutes.

• The built-in diagnostics worked OK.

• We connected the I/O cable between the processor and the TC02 DECtape controller. We expected to see lots of indicator lights on the TC02, but only saw the C2 counter indicator. After lots of wiggling of power cables and I/O cables the indicator lights are on. We sent some commands from the processor to the TC02 and can control the DECtape drives.

• We tried to boot ADSS from DECtape. The tape drive behaves as expected, but we don't see a prompt on the serial console. The processor is running code around address 00020 which is not correct. We need to run DECtape diagnostics to see if it is actually reading the ADSS tape. 

7/15/26

• We created a little program to send characters out the serial console port. When we tried to enter the program we noticed that DEPOSIT NEXT and EXAMINE NEXT always goes to address zero. After running the built-in MAINT diagnostics for a few seconds DEPOSIT NEXT and EXAMINE NEXT behaved OK

• When booting ADSS it reads the DECtape and ends up at address 00021 which contains 000000, a CAL 0000. Memory 000000 contains a 617646, a JMP 17646, which is the restart address for the DECtape bootstrap.

• After more tries it looks like the JMS instruction is not working, or setting SING INST does not go through the subroutine.

• We loaded and ran MAINDEC-9A-D01A Instruction Test Part 1. It looks like it is running OK.

• We loaded and ran MAINDEC-9A-D02A Instruction Test Part 2. It halted immediately displaying 00250, so the halt instruction is at 00247. The address 00247 corresponds to symbol E1135 which means that the DZM instruction did not work correctly. Memory location 06347 should contain 777777 and actually contained 377777. We corrected the memory location and restarted the diagnostic. It halted with 00541 displayed so the halt instruction is at 00540 which corresponds to symbol E1170 which means that an AND instruction did not work correctly. We determined that 

7/18/26

• We reloaded and ran MAINDEC-9A-D02A Instruction Test Part 2. It halted immediately displaying 00250, the same as before. We fixed the constant at 06347 to fix the dropped bit 0. We restarted the diag and it halted at 00541. We determined that location 00774 was not read from the paper tape correctly. Every location after 00773 was shifted to a lower memory address.

• We found the copy of MAINDEC-9A-D02A Instruction Test Part 2 that we made many years ago. This tape has a note about a dropped bit at location 007303 written on it. We loaded and ran this tape. This time it ran for several seconds and halted at 005720. This corresponds to label E1549 where it is checking the status bits for pending interrupts and got an interrupt with not bits set. We fount that bit 9 was on which corresponds to no tape in the paper tape punch. we put some paper tape under the sensor and the bit turned off. Now Instruction Test Part 2 runs OK.

• At this point all of the processor diagnostics ran OK.

• We tried to boot ADSS V5 8k from DECtape. It looks like it boots OK, but gets stuck in a loop where location 004012 contains 604012, and then goes to 000021 which contains 004013. We tried the ADSS FOCAL tape and it booted OK.

• We need to relearn the commands to link and load FOCAL and the HELLO program written in FORTRAN.

7/22/26

• We decided to work on the TU20 1/2" Magnetic Tape drive. It powered on without smoke, the vacuum pump worked OK, but the brake for the lower spindle was stuck on. We partially disassembled the brake and managed to free it up. After electrically turning off the brakes we could manually turn the spindle, and after more fiddling it turned freely.

• We tried to load a tape, the vacuum columns and sensors worked OK, but the tape went right past the BOT (Beginning Of Tape) marker and didn't stop. We put a shiny test BOT foil in the BOT sensor and the LOAD POINT indicator turned on, so we know that the sensor and the sensor electronics are working OK.

• We noticed that the right-most fan below the control chassis is not working. We removed the fan, peeled off the fan manufacturer's label, and dissasembled all of the parts that hold the fan blade assembly in place. The shaft was completely dry, so that explains why the fan didn't spin. We cleaned and lubricated the shaft and rotor, soaked the felt pads in oil, and reassembled the fan. Now it spins easily, and spun up when power was applied. The left fan is reluctant to spin up. We lubricated the left and center fans, so maybe we won't need to disassemble them.

• The drive doesn't stop at the load point when the BOT reflective tape is present. The HP Datamec tape drive manual suggests that there may be a problem with one of the vacuum sensing switches. We will leave that task for Saturday.

7/25/26

• We found the operator error problem with the TU20 tape drive. It will now load and go to the BOT marker without problems.

• We reconnected the TU20 tape drive to the TC59 tape controller. We loaded MAINDEC-15-D4AC, Magnetic Tape Control Instruction Test. It ran off the end of the paper tape, so the RIM loader isn't working correctly. The paper tape says that the loading address is 17700, but the documentation says that it is 17720. We tried both addresses. Using 17700 it runs off the end of the tape. Using 17720 it never loads the binary part of the tape. We need to get a listing of the BIN loader and try single stepping it to see what it is doing wrong.

• We booted ADSS just to see if the system is working OK. It loaded and ran on the first try.

• We only have a paper tape for one of the TC59 magnetic tape diagnostics. We need to transcribe the other diagnostics from the listings so we can make a paper tape and run the diagnostics. That should be fun...

7/29/26

• We used Mike's PDP-9 disassembler to create source code from the two copies of the TC59 magnetic tape controller diagnostics. This also gave us the loading and starting address for diagnostics that we don't have any documentation for.

• We set the SING INST console switch on and loaded the MAINDEC-15-D4AC, Magnetic Tape Control Instruction Test paper tape. Since SING INST was on it loaded the BIN loader that was in HRI format and only executed one instruction of the BIN loader. We used the EXAMINE and EXAMINE NEXT switches to compare the BIN loader that was loaded from the paper tape to the listing that Mike's PDP-9 disassembler made. Unfortunately they were different.

• We punched a copy of the BIN loader from the beginning of the diagnostic so we can annotate the paper tape and disassemble it by hand. We found that the BIN loader on the beginning of the paper tape matched the disassembled code from the MAINDEC-15-D4AC, Magnetic Tape Control Instruction Test paper tape image.

• That means that the HRI loader built into the PDP-9's microcode or the paper tape reader didn't read the paper tape correctly. We tried loading the BIN loader from the copy of the paper tape. That worked OK. We tried loading the BIN loader from the original paper tape and that also worked OK. Maybe it liked being powered on for a few hours?

• Loading the MAINDEC-15-D4AC, Magnetic Tape Control Instruction Test from paper tape didn't work. We compared more of the BIN loader in memory to the listing and found that after address 017732 the BIN loader was corrupted. We reloaded the BIN loader from the copy of the paper tape and this time it loaded correctly.

• We positioned the MAINDEC-15-D4AC, Magnetic Tape Control Instruction Test tape just after the BIN loader, and ran the BIN loader that was in memory. The reader went off the end of the paper tape, so we know that there was a problem with the BIN loader or the paper tape reader. 

• We tried to load the EUFB DECtape formatter because it has a BIN loader. It failed. We tried the D3RB TC02 Random Exerciser and D3BB TC02 Basic Exerciser. Both failed to load correctly. So it looks like any diagnostic with a BIN loader on the front will not load correctly.

• We loaded D01A Instruction Test #1 that is in HRI format. It loaded correctly and runs OK.

8/5/26

• We disassembled the BIN loader that is on the front of MAINDEC-15-D4AC, Magnetic Tape Control Instruction Test. We compared it to PDP-9 and PDP-15 listings and made source code with comments. The MACRO assembler will put the BIN loader at the front of large paper tape images to reduce the size of the paper tape.

• The PDP-9 and PDP-15 BIN loader will read from either the high-speed or the low-speed paper tape reader. It sends commands to both to see if paper tape is available. We need to insure that the serial console is connected so that the low-speed reader doe. sn't send spurious characters.

• We loaded MAINDEC-15-D4AC, Magnetic Tape Control Instruction Test into the high-speed reader, turned SING INST on, and pressed the READ IN switch. This loaded the BIN loader, but did only executed one of the instructions. The PC is set to 17701.

• We compared the code in memory starting at 17700 to the decompiled listing of the RIM loader. Everything was OK up to 17717. After that address the code looked reasonable, but it was incorrect.

• We read the paper tape of the BIN loader by hand and compared it to the decompiled listing of the RIM loader.  The paper tape matches the decompiled listing of the RIM loader. 

• We loaded the RIM loader again from paper tape, and this time it correctly loaded correctly. Maybe it likes being powered on for a few hours?

• We loaded the MAINDEC-15-D4AC, Magnetic Tape Control Instruction Test and it ran off the end of the paper tape instead of running the diagnostic.

• We single-stepped the BIN loader so we could watch it read the paper tape and write to memory. At 17741 it read three liness, and at 17764 the AC contained 700112. It should have read an address of 000100 and the contents of 777754. This doesn't match the paper tape at all.

• Either the RSB instruction is not assembling the three paper tape reads into the correct 18-bit data, or the RRB instruction is transferring incorrect data from the paper tape reader buffer into the AC. Turning the DISPLAY REGISTER switch to RDR shows 700112 and to AC shows 700112. That probably means that the RSB instruction failed, but the RRB instruction worked OK.

• We toggled in a RSB, RRB, JMP ,-2 loop. When it runs the paper tape reader buffer always contains 700144, and the AC alternates between 700112 and 700144. It looks like the RSB instruction is broken. This instruction does three paper tape reads and assembles the data into an 18-bit word. The data from the paper tape never makes it into the 18-bit buffer.

8/8/26

• We punched a tape with just feed holes and then a section with rubout characters (All holes punched) on the ASR-33 Teletype to test the paper tape reader. We turned the DISPLAY switch to RDR so we could see the paper tape reader buffer contents. We executed an RSA IOT instruction (700104) to read the paper tape in alphanumeric mode. The REGISTER DISPLAY showed reader buffer positions 10-17 contained all 1s. This is correct.

• We executed an RSB IOT instruction (700144) to read the paper tape in binary mode. The REGISTER DISPLAY showed reader buffer positions 0-17 contained all 1s. This is correct.

• The 1s in the reader buffer are not transferred to the AC when executing an RCF or RRB IOT instruction (700102 or 700112). So the problem is with the RCF or RRB instructions, not with the RSA or RSB instructions.

8/12/26

• The RDR ON BUS signal gates the RBxx(1) signals through the B141 flipchips, onto I/O Bus B, and eventually to the AC. The RDR ON BUS signal is generated by the R111 NOR flipchip in slot D17 in the I/O chassis, as shown in section D5 on schematic sheet KD09-A-7 sheet 1. If either the IOT 0102(1) signal or the RDR-D signal is active high then the RDR ON BUS signal will be active low. The IOT 0102(1) signal  comes from the IOT 0102(1) flip-flop is in section C7 of schematic sheet KD09-A-9 sheet 1. RDR-D comes from the DISPLAY REGISTER switch on the console and is shown in section B6 of schematic sheet CS-9-0-3. Since the RD BUFFER is displayed on the console by selecting RDR on the DISPLAY REGISTER switch the pin S input of the R111 in slot D17 and the pin U output are working.

• We measured all of the diodes, transistors, and resistors on the R111 in slot D17 of the I/O chassis that makes the RDR ON BUS signal. Everything looked OK. We did the same for the S202 in slot D02, and the R111 in slot C04. Everything looked OK.

• See schematic page KD09--A-7 (1). We connected a 'scope to pin S (RDR-D) of the R111 in slot D17. We can see a -4V 30 kHz square wave when the REGISTER DISPLAY switch is set to RDR and -4V when it is not. Pin U (RDR ON BUS) shows the same 30 kHz square wave and ground when not, so the pin S input of the R111 inverter is working. This is how you display the contents of the Reader Buffer on the console lights.

• We looked at Pin R (IOT 0102 (1) of the R111 in slot D17. We can see a 1uS pulse to ground when we execute an RSA or RSB instruction. We can see the same pulse, but inverted, on pin U, so the pin R input of the R111 inverter is working. The AC still does not show the contents of the Reader Buffer.

• We looked at Pin N (RDR ON BUS), Pin M (RB 00 (1)), and Pin D (Mux Output). When we execute an RSA or RSB instruction the input on Pin M gets inverted and sent to the output on Pin D when Pin N goes low. All of this looks OK.

• We looked at Pin H (IO BUS 00 (B))of the R123 Input Mixer in slot D12. It shows the inverted signal from Pin D of the Mux as a 1uS pulse when there is a hole in column 0 and when there is not. All of this looks OK.  

• When we execute an RSA or RSB instruction we need to look at the LIO signal on schematic page KC13 section D6 that gates I/O Bus B onto the O Bus, and then at ACI(1) on schematic page KC19(2) section C5 that gates the O Bus on schematic page KC20 section B8 into the AC on schematic page KC20 section D7.