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.

8/19/26

• Last week we determined that data was being transferred from the Paper Tape Reader to the Reader Data Buffer, and through the Input Mixer to I/O Bus B to the O Bus. We need to determine if the data from the I/O Bus B is being transferred to the O Bus, and from the O Bus to the AC.

• We triggered the 'scope on the LIO signal that gates the paper tape reader data from I/O Bus B to the O Bus. We also looked at bit-0 on I/O Bus B, and bit-0 on the O Bus. When we executed the RSB/RCF instructions and we saw a 10 us low going pulse on the LIO signal.

• We tried the DTRA instruction to read the TC02 Status Register A and we saw a 150 ns low going pulse on the LIO signal. We tried the DTRB and the MTRS and we also saw the same low going pulse on the LIO signal.

• We triggered the 'scope on the RDR ON BUS signal on, but didn't see that signal. Time to go back to the Paper Tape Reader circuitry that drives the I/O Bus B.

• We triggered the 'scope on the IOT 0102 (1) signal on pin R of the R111 in I/O slot D17 and looked at the RDR-D and RDR ON BUS signals. When we executed the RCF instruction we saw a 1 us high going pulse on the IOT 0102 (1) signal, the RDR-D signal was always low, and saw a 1 us low going pulse on the RDR ON BUS signal on pin U.

• We also looked at the LIO signal pin T of the B169 in processor slot B06. We did not see an LIO pulse coincident with the RDR ON BUS signal.

• We looked at LIO (1) signal on pin N of the B213 in processor slot D12 and did not see an LIO pulse coincident with the RDR ON BUS signal. We looked at LIO (0) signal on pin P of the B213 in processor slot D12 and did not see an LIO pulse coincident with the RDR ON BUS signal.

• We looked at the AC RD (B) signal on pin U of the B213 in processor slot D12. We did not see an AC RD (B) pulse coincident with the RDR ON BUS signal.

• The AC RD (B) comes from schematic page KC19(2) section C7. We looked at pin h of the R111 in processor slot E36. There was no activity on the AC RD (B) output signal or on pin D the AC RD input signal.

• The AC RD signal is on schematic page KD3(3) section D3. We looked at the AC RD signal on pin N of the W612 in I/O slot F18, and the input on pin R. There was no activity on either pin.

• We looked at the output on pin N of the R111 in I/O slot F19, and the input signal RD RQ (B) on pin K. There was no activity on either pin.

• We looked at the output on pin U of the R111 in I/O slot F19, and the input signal RD RQ on pin R. There was no activity on either pin.

• We looked at the INT RD RQ BUS signal on pin S of the R111 in I/O slot F19.  There was no activity on that pin.

• We looked at the IOT 0102 (1) input on pin P of the R141 in I/O slot F24. There was a negative going pulse coincident with the RDR ON BUS signal. It looks like the R141 NOR gate is not passing the signal from pin P. We found a B141 in the slot where the R141 should be. The B FlipChips are faster than the R FlipChips so it should work OK. We measured the forward and backward voltage drop of D21-D24. All four diodes looked OK. We measured the base-emitter and base-collector voltage drop of Q5. The base-emitter was 0.755V and the base-collector was 2.616V. We measured other transistors and both drops were about 0.75V. It looks like Q5, a 2N4258 is bad. We replaced it with a NOS DEC 2N4258 transistor.

• With a test paper tape with all holes punched in the when the RSB/RCF instructions are executed all of the bits in the AC are ones. Looks like it is fixed.

• We successfully loaded the MAINDEC-15-D4AF TC-59 Instruction Test paper tape. We will try it with the TU20 Magnetic Tape Drive on Saturday.

8/22/26

• Today's project is to run MAINDEC-15-D4AF TC-59 Instruction Test, and see if the TC59 is working. If so, then we can try the TU20 magnetic tape drive and see how that works.

• We ran the TC-59 Instruction Test starting at test 00, IOT Test Part 1. Test 00 ran for just a second and switched to test 01, Command Register Bit and Data. Test 01 ran for 17 seconds and switched to test 02, Data Buffer Bit and Data.  Test 02 ran for  seconds and switched to test 03. Looking at the Memory Buffer indicator lights on the PDP-9 console, it looks like test 03 went into the weeds and continues to run past the expected 23 seconds.

• Test 03 uses Data-Break to transfer data to/from the Data Buffer in the TC-59 Magnetic Tape Controller and core memory in the PDP-9. Instead of stopping at 23 seconds it runs forever. We posted a YouTube video in 2014 of this system successfully running test 03, so we know that it is capable.

• We booted the ADSS operating system from DECtape just to prove that Data-Break in the processor is working OK.

8/26/26

• We have the documentation for MAINDEC-09-D4AF, but don't have the paper tape. We have no documentation for MAINDEC-15-D4AF, but we have the paper tape. We used Mike's PDP-9/15 disassembler on the paper tape for MAINDEC-15-D4AF and the resulting source is somewhat different from the listing of MAINDEC-09-D4AF.  We added comments and symbol names from the MAINDEC-09-D4AF listing to the reconstructed source for MAINDEC-15-D4AF. Eventually we should be able to use MACRO to reassemble the paper tape image from the reconstructed source.

• We need to determine why MAINDEC-15-D4AF Test 03, Transfer Direction and DCH Control Test runs forever instead of finishing in 23 seconds. Since the Data-Break hardware in the processor works with the TC02 DECtape controller when we run the ADSS operating system, and we have successfully run this test from this paper tape in the past, the fault must be within the TC59 Magnetic Tape controller.

• There is code within Test 03, Transfer Direction and DCH Control Test that runs a "scope loop" if it finds an error. We need to determine if that is what is happening.

• We reloaded and ran MAINDEC-15-D4AF TC-59 Instruction Test from test 00. Tests 00, 01, and 02 ran OK and completed in the expected amount of time. When test 03 is running the We see the COMMAND set to 4 which is a WRITE, and the DATA BUFFER and WRITE BUFFER lights are flickering. The PDP-9 console shows the MEMORY BUFFER lights counting.

• We set the SING INST switch on so we could single-step the processor. It stopped at address 01272 (XCT DSCOPE). We stepped it to 01250, then 1276, 1251, 1272, 1252, 1276, 1254, 7237, 7215, 7237, 7217. This sequence of instructions doesn't match the disassembled code.

• We started test 03 at 01232 and the address sequence was 1232, 1233, 1234, 1235, 1236, 1237, 1240, 1241, 1242, 7122, 7123, 7124, 7125, 7126, 1243, 1244,
  1245, 1246, 1247, 1272, 1250, 1273, 1251, 1272, 1252, 1273, 1253, 7332, 7312, 7333, 7313, 7336, 7314, 7337, 7315, 1276, 1256, 1257, 1260, 1261, 1262, 1263,
  1264, 1265, 1266, 1267, 1270, 1273, 1271, 1272, 1272, 1273, 1273, 1276, 1274, etc.

8/29/26

• We don't have a copy of the MAINDEC-9A-D4AF TC-59 Instruction Test paper tape, but we do have a copy of the MAINDEC-15-D4AF TC-59 Instruction Test. We have the documentation and listing of the MAINDEC-9A-D4AF TC-59 Instruction Test, but nothing for the MAINDEC-15-D4AF TC-59 Instruction Test. I wrote a disassembler for PDP-9 paper tapes and used it to disassemble the PDP-15 Instruction Test paper tape. The code is nearly the same as the PDP-9 version so we have been able to reconstruct the source and comments for the PDP-15 paper tape.

• The first three tests in the Instruction Test run OK and take the expected amount of time. The fourth test covers the data-break capability of the processor and tape controller. The system will run the ADSS operating system from DECtape so we know that the data-break circuitry in the processor works OK. When we run the TC59 data-break test we can see the contents of the TC59 data buffer changing and we see a counting sequence on the console lights. This test never finishes.

• We single stepped the data-break test code and noted the Program Counter values as we single stepped it. When the first data-break happens it starts executing two streams of code by alternating the PC between the two streams. I know that this processor doesn't support Hyper-Threading, but that looks like what it is doing.

• We looked at the reconstructed source code for the TC-59 Instruction Test and traced the execution. When the PDP-9 gets to 01247 it is getting a data-break request from the TC59. It should continue executing at 01250, but it jumps to 1272 and then back to 1251. We need to study the data-break microcode more to see if we can find a clue about what it is doing and why.

9/2/26

• MAINDEC-15-D4AF TC-59 Instruction Test, Test 03, checks the data read and write capability of the TC59 by forcing a data-break. When test DCHCTC runs, it executes a CAF instruction to clear all of the I/O controller flags, writes the Word Count (32) and Current Address (33) values into memory, writes a 004000 (Write) into the Command Register (MTCM), and sets the Data Flag (MTSDF). When the next instruction completes the processor will increment the Word Count and if it is not zero will transfer data from the TC59 Data Buffer into the memory location pointed to by the Current Address and increments the Current Address. When part of the test executes we see the processor start the "Hyperthread" behavior alternating between two code streams.

• When the MTSDF instruction executes it decodes to Set Data Flag signal. That signal goes into the R601 Pulse Amplifier in slot B21 which generates the +1 -> DF signal. That signal sets the Data Flag R203 flip-flop in slot B08. To be continued...

9/5/26

• From our discussion about what could be going wrong with the data-break we noticed that the W104 flip-chip that controls the data-break state in the TC59 drives I/O address lines 13, 14, & 16 to tell the processor what the Current Address should be. ORing these address lines with the Program Counter would account for the addresses that we see when the program "Hyperthreads". Data-break only occurs every other instructions, so one instruction with the correct address, one with the wrong address when influenced by a broke data-break circuit.

• We connect a 'scope to DCH RQ and DCH GRANT on the W104 flipchip. After the Set Data Flag instruction is executed it takes about a microsecond for the DCH REQ to get set and another microsecond for the DCH GRANT from the processor to arrive and the DCH RQ to be cleared. This looks OK.

• After some repeated tests we are not seeing the DCH RQ/DCH GRANT signals go active. We connected the 'scope to the DATA FLAG flip-flop to insure that it is being set by the MTSDF instruction. We can see the flip-flop being set for 4 uS. About 3 uS after DATA FLAG is set we see DCH RQ go active, and 1 uS later we see DCH GRANT go active. We then see WRITE RQ go active about 1uS after DCH GRANT goes active, and stays active. It seems to be a a little strange for WRITE RQ to stay active.

• We verified that IO SYNC is active. We see pulses about every 1 uS.

• We looked at DATA EN A. It gets set by DCH GRANT AND IO SYNC and stays set until I/O RESET is pressed. As long as the DATA EN A flip-flop is set the W104 will drive the I/O ADDR 13, 14, & 16 signals.

• On Wednesday we will debug the W104 flip-chip in the TC59 and hopefully get it to pass the diagnostics.

9/9/26

• We removed the W104 flipchip from slot EF18 in the TC59 magnetic tape controller. We checked all of the transistors and diodes, but did not find anything wrong. We don't have any spare W104 flipchips. We noticed that there are two W104 flipchips in the TC59. One for data-break and one for API requests. Since we don't have the API feature in the PDP-9 we don't need the W104 in slot EF17. For a test, we swapped the W104 flipchips in slots EF17 and EF18. We swapped the W104 flipchips back to their original positions.

• When we ran MAINDEC-15A-D4AF TC-59 Instruction Test from the beginning, it passed tests 00-02, but had the same failure mode on test 03. So it looks like the W104 is actually OK. We need to spend more debugging time on the data-channel process and determine why the DATA EN A flip-flop on the W104 is not getting cleared. The F-97 PDP-9 Maintenance Manual has a very long and detailed description about how data-break works, but doesn't explain about clearing the DATA EN A flip-flop.

• We took a closer look at the DATA EN A flip-flop on the W104 flipchip. We triggered the 'scope on the DCH GRANT signal going low, and watched the IO SYNC, DATA EN A (0) and DATA EN A (1) signals. When the DCH GRANT signal goes low and the IO SYNC goes low (active), the DATA EN A (0) on pin EV goes low, and the DATA EN A (1) signal on pin EP goes high. this all looks OK. We noticed that the DCH GRANT signal stays low for more than 5 seconds. That is not right,

• We verified that the DATA RQ flipflop is getting cleared when DCH GRANT goes low. We After the single data-break transfer the DCH GRANT signal should go back to the high (inactive) state. We need to determine why DCH GRANT is not going inactive.

• During the CA Cycle, DCH(1) (KC19-1) from the microcode sets BK 1 (KD3-3) which it clears DCH SYNC (KD3-2), which disables the DCH GRANT (KD3-1) signal. This needs to be the next set of signals to explore on Saturday.

9/12/26

• We studied the microcode steps to determine what is different for a data-break read and write. The microcode for data-break is really complicated and involves lots of discrete signals that modify the target microword address. It will take some more studying to understand what is going wrong with the data-break write.

9/16/26

• Today's project is to understand how the DCH RQ signal from the W104 in the TC59 propagates to the I/O Controller and the Processor, and how the CDH GRANT signal propagates back to the TC59. When the DCH RQ (Schematic page KD3(2) 7C) signal from the TC59 goes inactive, the DCH GRANT (Schematic page KD3(1) A4) signal from the I/O Controller should go inactive.

• We triggered the 'scope on DCH GRANT and looked at IO SYNC, DATA EN A, and DATA EN B. We can see the DCH GRANT signal go low coincident with IO SYNC going low. This causes pin EP of DATA EN A to go low, and the next time IO SYNC goes low pin EE of DATA EN B goes low. This all looks OK. 

• We triggered the 'scope on DCH GRANT and looked at IO SYNC, DATA EN B. and WRITE RQ. The signals are the same as in the previous test, but when EE of DATA EN B goes low we see WRITE RQ go high. We also looked at READ RQ and it stays low. All of this looks OK.

• When BK0(0) resets (Process Word 36) it allows WR RQ to pass through the S602 Pulse Amplifier (Schematic page KD3(2) D7) and clears the DCH SYNC flip-flop. The DCH SYNC(1) signal goes through a B213 Jam Flip-Flop (Schematic page KD3(1) A5) that acts as a bus driver to make the DCH GRANT signal.

• We looked at the DCH SYNC(1) and DCH GRANT signals from the B213 Jam Flip-Flop. The DCH SYNC(1) signal went high and the DCH GRANT signal went low and stayed low for more than 3 seconds. That is not right.

• We looked at the DCH SYNC(0) and DCH SYNC(1) signals. Pin E of the S203 in slot H07 went high and pin F went low and stayed low for more than 3 seconds.  That is not right.

• We triggered DCH SYNC(1) and looked at the DCH SYNC(1), BK0(0) and WR RQ signals. We saw the DCH SYNC(1) on pin F go low, 1 us later we saw WR RQ go high, and 2 us later BK0(0) also went high. At this point the DCH SYNC flip-flop should have cleared. Pin V is always in the active (ground) state. We need to investigate pin V.

• We triggered the 'scope on DCH SYNC(1) going active low. About 1 us later *WR RQ(B) went low, and another 1 us later BK1(1) went high and toggled every 2 us. Since either Pin P or Pin H is low Pin M of the S107 inverter stayed high (ground) the whole time. This should make S602 Pin V inactive low all the time. Pin V was not driven all the way to the inactive -3V state.

• We pulled the S107 Inverter from slot H05 in the I/O controller. All of the transistors and diodes measured OK except for diodes D8 & D11 that are used to make the -3V signal clamping voltage. With the shorted diodes the clamping voltage will be -1.8V which would make all of the inverter's outputs neither high or low. We replaced D8 & D11 with NOS DEC D662 diodes from one of our DEC field service kits.

• The diagnostic still shows the same incorrect behavior. The output on pin L of the S107 in slot H05 still does not go to -3V when inactive.

• We substituted a NOS R107 for the S107. The R107 has lighter pull-down resistors than the S107. The output on pin L of the S107 in slot H05 still does not go to -3V when inactive. Diagnostic steps 00-04 completed and the diag failed on step 5. The printout said: Test 5, ADDRS 007517, 001000, (AC) 000000, (WC) 000002, (CA) 017701, COMD 001000, STAT 540000, CADATA 7777777. The ERROR FLAG, ILLEGAL, 7 TRACK, and TUR indicators are lit on the TC59 panel. All the other indicators are out except for P in the WRITE BUFFER and the COMMAND contains 1.

• I would call this progress. Saturday we need to check the input pin V on the S602 in slot J09 of the I/O Controller. It is possible that diode D38 is shorted and not allowing the signal to go to -3V.

9/19/26

• We pulled the S602 Pulse Amplifier from slot J09 in the I/O Controller. We checked all of the diodes and transistors. As we suspected, D38 on pin V was bad. We replaced it with a NOS DEC D664 diode from one of our DEC field service kits. The system will now run tests 00-03 without errors. Test 04 halted because we didn't have the tape drive powered on.

• We restarted at test 04 with the tape drive powered on and on-line. This time test 04 passed, but it halted on test 05. The printout said: Test 5, ADDRS 007517, 001000, (AC) 000000, (WC) 000002, (CA) 017701, COMD 001000, STAT 540000, CADATA 7777777. 

• During the week we will disassemble the diagnostic to see what it is trying to do and what is going wrong.

9/23/26

• We added comments from the MAINDEC-9A-D4AF TC-59 Instruction Test to the disassembled code from MAINDEC-15A-D4AF TC-59 Instruction Test Step 05. Test 05 does a rewind command while the tape is at the BOT. This turns on the ERROR FLAG and the ILLEGAL bits in the status register. The diag retrieves the contents of the Status Register (440000), ands it with 40000 to mask off the ILLEGAL bit, and does a SZA. Since the AC is not zero it does not skip and it does a JMS to the TESTOK subroutine at 07311.

• The TESTOK subroutine does an ISZ twice on the return address (02012) to skip over the ERROR subroutine when it returns. After it cleared the ERFLAG it returned to 02014. Address 2014 is a JSR to 7517. This code is not in the PDP-9 version of this diagnostic. The subroutine gets the TC59 Status Register contents, ANDs it with 000010 and ends up in the ERROR subroutine. The registers in the TC59 are all 12-bit because most of the controller design is shared with the 12-bit TC58 controller. It is possible that the PDP-15 DW15 adapter turns bit-14 on, which is why this code was added to the PDP-15 version of the diagnostic.

• We replaced the JMS 07517 with a NOP in the three instances in test #05. We restarted the diagnostic from the beginning, test #00. It printed an error message from test #04 that said it had a problem at address 001644 where it executed a 703312. We don't know of any PDP-9 peripheral that has an I/O address of 33, so maybe this is PDP-15 specific? The TU20 tape transport was not ready so this test failed. We set the TU20 to ONLINE and restarted the diagnostic. Test #04 passes this time.

• We restarted the diagnostic. Tests #00-04 passed. Test #05 is running and not reporting any errors, but it seems to be stuck in a loop, the Command Register contains a 1, the ERROR FLAG and ILLEGAL indicators are on, and the TU20 is offline. We set the TU20 ONLINE, but there was no change. After about one minute the TU20 went OFFLINE.

• We halted the diagnostic and the PC= 02006. This is in the code were it does a rewind at the load point and checks that ILLEGAL got turned on. The ERROR FLAG, BOT, and ILLEGAL bits are on in the status register. Our modification where we put a NOP where the JMS 07515 caused the code to loop forever in this test. We will do more NOPs.

• Test #05 passed, but test #06, INITAL TAPE MOTION, failed at address 002407. This test starts at 02177

• After fiddling with debugging the code we restarted test #06. It went on to test #07 COMBINED FUNCTIONS and stopped with the ERROR FLAG ON, and a WRITE EOF in the COMMAND REGISTER. We halted the processor and the PC = 02414. If we step through the instructions and then press CONTINUE the diag will run some commands.

• I think that we will need to hand write some simple diagnostics to see if the individual TC59 commands are working.