PDP-9 Restoration Blog Starting 2021

Go to the earlier restoration blog.

3/6/21

We tried to demonstrate ADSS last week, but it would not boot. After testing with toggled in instructions we found that all of the instructions that we tried worked OK, except for the JMP instruction.

We connected 'scope and the logic analyzer to the microcode address to see if we could see it execute the microcode steps. We were thinking that it was not getting to the microword for the JMP instruction. After lots of fiddling we were never able to get the logic analyzer to decode the negative logic levels and display the correspond logic states. After many hours of fiddling we demonstrated what was wrong to one of our volunteers, and of course it worked. After several tried it booted ADSS. Something is marginal, and we will need to find out what it is to make the machine more reliable. A project for next week.

3/13/21

The PDP-9 booted OK and ran fine for a few hours, but then the TU-55 DECtape drive in the CPU cabinet stopped working. The right hub motor had no torque in any state. I swapped the G850 SCR flipchip for the right motor with one we borrowed from the PDP-8/I and the drive works OK. We will either find a replacement or fix the one we have.

6/26/21

We ran an ADSS demonstration and left the system powered up in case other visitors wanted to see it in operation. After a few hours of power on the DECtapes would not work. Time for some diags to see what is broken.

7/2/21

MAINDEC-9A-D01A-D Instruction Test Part 1 failed at address 25. SKP not working? I toggled in a little program to test the SKP instruction and it works OK. Not loading the paper tape correctly? I loaded MAINDEC-9A-D1AA-D PDP-9 Basic Memory Checkerboard Test and it runs, but the lights don't look right and it doesn't beep periodically. I toggled in a little program to copy the switches to the Status A register in the TC02, and can make it move the tape in both directions. At least much of the CPU, I/O, and TC02 are working.

7/17/21

We ran the built-in diagnostics and noticed that the Memory Buffer display shows bits 8-17 counting, bit 7 is off, and bits 6-0 on. This pattern is reflected in all of the other registers. In step one this diagnostic gates the Adder Register onto the O-bus, turns on the +1 signal to increment the Adder Register, and gates the O-bus into the Memory Buffer register. In step two it gates the Memory Buffer onto the O-bus and gates the O-Bus into the Accumulator, Adder, Program Counter, and MQ Registers, and also gates the console switches onto the O-bus. Turning on the 7 Address switch on the console turns on that bit on all registers except the Memory Buffer register. It looks like the problem is in the Adder or the Memory Buffer. Since we have seen failures in the B213 JAM Flip-Flops before we will look there first.

We swapped the B213 Jam Flip-Flops in slots B16 and B20 that implement Memory Buffer bits 6, 7, 8, and 9. It didn't change the behavior.

We swapped the B169 Inverters in slots B17 and B21 that multiplex lots of inputs to the adder bits 6, 7, 8, and 9. It didn't change the behavior.

We swapped the B131 Adders in slots A17 and A19 that implements bits 6 and 7. The broken bit moved from bit 7 to bit 6, so the broken flipchip is now in slot A17.

We swapped the B131 Adder in slots A19 and A21 that implements bits 7 and 8. The broken bit moved from bit 7 to bit 8, so the broken flipchip is now in slot A21.

So now we know which B131 is broken, the one originally in slot A19. We checked all of the diodes and transistors on the B131 with the diode voltage drop function in a DVM, and they all looked OK. After we put the board back in the PDP-9 it worked OK. Oh well, just a bad connection.

We tried to boot ADSS, but no luck. We tried the run the Instruction Test #1, but it looked like it didn't load correctly. Maybe we need to investigate the paper tape reader and controller?

7/21/21

We tried to run the ISZ test MAINDEC-9A-D0BA. It printed garbage on the console. We single stepped the program and found that the operate instruction CLA!CLL!CMA set the AC to 775777, so bit-7 in the adder is still broken.

We entered a little program to clear and compliment the AC. It showed that bit-7 was always off.

We moved the B131 from slot A19 to slot A21 and the problem moved to bit-8.

So, the B131 that is in slot A21 is broken again. We need to fix that next.

7/23/21

We replaced Q1, a Fairchild 2n3009, with a real DEC2009B transistor on the B131 that was in slot A21.

7/24/21

The system will now run MAINDEC-9-D01A Instruction Test #1, so that is promising. We will run the rest of the processor and memory tests to make sure that everything is OK. Then we can start on the TC02 DECtape tests.

It would not boot ADSS from DECtape. There was no motion on the tapes, and it halted. We will need to find the source listing of the TC02 DECtape bootstrap to see why it halted.

7/27/21

MAINDEC-9A-D01A Instruction Test Part 1 still runs OK, so that is a good sign.

MAINDEC-9A-D02A-D Instruction Test Part 2 runs OK.

MAINDEC-9A-D2BA-D PDP-9 TTY Test runs OK.

MAINDEC-9A-D0BA-D ISZ Test halted with the message ISZ DID NOT SKIP, LOC 017400

MAINDEC-9A-D0CA Memory Address Test runs OK.

MAINDEC-9A-D0DB-D JMP Self Test runs OK.

MAINDEC-9A-D0EA-D JMP-Y Interrupt Test runs OK.

MAINDEC-9A-D0FA-D JMS-Y Interrupt Test runs OK.

MAINDEC-9A-D1AA-D PDP-9 Basic Memory Checkerboard Test

Halted at 000223. AC = 013414, should be = 000000, was = 002000. I set switch 7 on to ignore the failed bit, and it halted again with a bit 9 failure. I set switch 9 on and it runs OK.

Halted at 000223. AC = 017525, should be = 000000, was = 002000.

Halted at 000223. AC = 017515, should be = 000000, was = 002000.

Halted at 000223. AC = 017515, should be = 000000, was = 002000.

We need to look at the B169, G219, G009, and W612 modules that are associated with bit-7.

7/31/21

We ran MAINDEC-9A-D1AA-D PDP-9 Basic Memory Checkerboard Test. After a few seconds it halted at 000223, the normal error location. The AC contained 013515, the address of the memory problem. After we pressed Continue the AC contained 000000. This is what the memory location should contain. After we pressed Continue the AC contained 002000, what the memory location actually contained. This is the same bit-7 problem that we observed last week. Pressing Continue twice restarted the diagnostic and the same error halt occurred within a few seconds. We raised the 7 switch to ignore bit-7 errors, and the diagnostic ran continuously.

There are several FlipChips that could cause problems with bit-7. The B169 Mux FlipChip in slot C31 and the G009 Sense Amplifier in slot B25 can be ignored. If one of these failed all of the memory locations would have a bit-7 error.

That leaves the G219 Memory Selector FlipChips in slots AB09 and EF09 for the bit-7 Digit Drive circuit, and the G219 FlipChips in slots HJ23-HJ30 for the Word Select circuit. We can look at the failing address to narrow down which G219 in the Word Select circuit could be the problem. Of course the system is running this diagnostic without errors now, so maybe we need to try it again when it is cold.

MAINDEC-9A-D1BA-D PDP-9 Extended Memory Checkerboard Test runs OK.

8/4/21

ADSS V5 booted after several tries. Most of the time it got an IOPS4 error. This error for a DECtape means Unit Not Ready. It may be that the TC02 DECtape controller and handler software was retrying a read and got a timeout. We need to format some DECtapes on the PDP-9 and run the DECtape diagnostics. Hopefully we can find some adjustments that will improve the DECtape behavior.

8/15/21

We tried to demonstrate the system to some visitors, but its broken again.

8/18/21

MAINDEC-9A-D01A Instruction Test Part 1 runs OK

MAINDEC-9A-D02A-D Instruction Test Part 2 runs OK

MAINDEC-9A-D1BA-D PDP-9 Extended Memory Checkerboard Test runs OK

MAINDEC-9A-D3BB-D TC02 Basic Exerciser

1. Search Scope Loop, works OK

2. Read Scope Loop, works OK

3. Write Data Scope Loop, skipped

4. Search Find All Blocks, works OK but had to configure the tapes as PDP-7 format. The upper drive in the I/O cabinet needs adjusting.

5. Read/Write Data Test, skipped

6. Parity Generation and Checking Test, skipped

7. Basic Search Routine, runs OK

8. Start/Stop/Turnaround Test, runs OK

9. TC02 Instruction Test, skipped

After a few failed attempts it booted ADSS V5A, loaded and ran the "Hello World" program. Something is a little flaky, so it needs more testing.

12/4/21

The system would not boot ADSS from DECtape when we tried to demonstrate it. The Processor is running, but does not move the DECtapes. The built-in maintenance program run normally for all registers.

12/11/21

We loaded MAINDEC-9A-D01A INSTRUCTION TEST PART 1. This diagnostic only takes 5 mS per pass, so it tests the Operate, LAC, AND, XOR, TAD, ADD, and SAD instructions 200x per second. The processor did not halt, so this is running OK.

We loaded MAINDEC-9A-D02A INSTRUCTION TEST PART 2. This diagnostic only takes 5 mS per pass, so it tests the DZM, DAC, ISZ, JMP, JMS, TIME CLOCK, DBR instructions, and the interrupts 200x per second.

The processor immediately halted at 05762, error E1551. This part of the diagnostic starts at address 05745. It loads the AC with 05762 (the location of the HALT at the end of this section) and stores it at location 00001 (the interrupt vector), stores zero at location 00000 (the return address), loads the AC with 17777 and stores it at location 00007. Then it turns interrupts off, turns on the real time clock, waits for the clock flag to turn on (which should generate an interrupt), turns the interrupts on and immediately off. If the interrupt is not generated it will skip over the next instruction, a HALT. It halts, so it handled an interrupt.

I am a little surprised that you can have a pending interrupt, turn interrupts on, immediately turn interrupts off, and not have an interrupt occur. Another interesting thing about the PDP-9 is that the interrupt circuitry is in the I/O controller, not in the processor.

I single stepped this code. The ION instruction at 05757 turned the interrupts and the PIE light on, but the next instruction, an IOF, did not turn the interrupts and the PIE light off. So, it looks like the ION instruction is working, but the IOF instruction is not. Next weekend we will see if the IOF instruction us being decoded and just the Interrupt Enable flip-flop is not.

After toggling in some test code I found that the ION instruction enables interrupts, but the IOF instruction does not disable interrupts. It looks like the S202 Flip-Flop in slot J07, or the B213 JAM Flip-Flop in slot F15 has failed. We have replaced and repaired a bunch of B213s, so that will be the first to try this week.

12/15/21

We swapped the S202 FlipChip in slot J07 with a spare R202 just for a test. The code that enables and disables the interrupts now works.

We check all of the transistors and diodes on the S202 FlipChip. All looked OK. We cleaned the gold fingers with a white eraser and reinstalled the S202. The code that enables and disables the interrupts still works.

We reloaded MAINDEC-9A-D02A INSTRUCTION TEST PART 2. It ran OK for a few minutes and then halted at 05762, E1551. That means that there was an interrupt when there should not have been.

We single stepped the diag starting at 05745 and found that the IOF instruction is not working again. we swapped the R202 for the S202 in slot S07 and the IOF instruction still does not work.

We swapped the B213 FlipChip in slot F15. That fixed the problem for about 20 seconds. We toggled in some code with an ION, IOF and JMP .-2 and ran it at various speeds. It worked fine and the PIE light turned on and off. After a few minutes the IOF instruction stopped working.

We connected the 'scope to the D & E pins of the B213 Jam FlipFlop in slot F15. The SD0 and SD0P signals look OK and are opposite polarity. See the I/O controller schematic page sheet 1, location D1.

We looked at the P & V inputs of the S202 FlipFlop in slot J07. Since they are the signals from the B213 FlipFlop they look OK. We added the IOT 0002 signal on pin N, and that signal strobes when the inputs are steady state, and again after they flip their state. The S & T outputs did not change their state.

We replaced the S202 with an R202, and again the S & T outputs do not change their state. It looks like the S output is not wired to anything.

We tried the CLON & CLOF instructions in a loop. The CLK EN and PIE flipflops share the input SD0 and SD0P signals so maybe the problem is with the IOT 0002 signal because the clock uses the IOT 0004 signal.

Next time we should look at the R111 in slot E23 and the IOP2(1) signal on I/O controller schematic page 1.

12/18/21

A refresher on how the Input/Output Transfer instructions work. Bits 0-3 contain the OP Code which is always 70, and bits 4-5 are unused. Bits 6-13 contain the 8-bit device selection code, Bits 6-11 are for the peripheral's controller, and bits 12-13 select the operational mode of the controller, or the controller's subdevice. That means we could theoretically attach 64 peripheral controllers to the PDP-9, but some controllers use more than one device selection code, and the Processor uses six device selection codes too. Bits 14-17 are the command code that is unique to each peripheral controller. Bit 15 will generate and IOP pulse 4 at event time 3, Bit 16 will generate and IOP pulse 2 at event time 2, Bit 17 will generate and IOP pulse 1 at event time 1, and Bit 14 will clear the AC at IOT bit time 1.

When the IOT instruction executes it takes one machine cycle for the Fetch, and one machine cycle for each of three event times. The event times are 1 uS each. The IOP 1 and IOP 2 pulses are 1 uS, and the IOP 4 pulse is about 500 nS.

The ION instruction is 700042 and the IOF instruction is 700002.

We ran MAINDEC-9A-D02A-D Instruction Test Part 2, and of course it is running OK with the R202 for the PIE flip-flop in place. We will let it run for a while to see if it starts failing when it warms up. It ran for about 5 minutes and then halted at 05717, E1549. In this case we had an interrupt get processed when no peripheral requested it. Bits 3 & 9 in the Status Register were on indicating that there was a character waiting from the serial port and the paper tape punch was out of paper. We reset the machine and it ran the diag for an hour without problems.

The machine halted at 05762, E1551, indicating that it got a Clock interrupt when the interrupts were turned off. We reset the machine and restarted the diag. It quickly halted at 05762 again. Pressing Continue halts at 05766.

Address 00000 contains 005763 which is the address after the instruction that was executing when the interrupt occurred. The address 05762 contains a HLT instruction, so maybe it got an interrupt when it was executing the HLT.

We replaced the JMP .-1 instruction at 05756 with a NOP and ran the diag. It halted at 06020, E1554. It expected the return address from the interrupt to be 06006 and it was 06003, the CLSF instruction. It looks like the interrupts were left on when they should have been off. We are back to the IOF instruction not working reliably.

Next time we will toggle in a small program that will enable interrupts, read the status word, check that bit-0 is on and if not halt, disable interrupts, read the status word, check that bit-0 is off and if not halt, and loop back. If this fails we will know that either enabling or disabling interrupts is not reliable.

We also need to look closely at the part of MAINDEC-9A-D02A-D Instruction Test Part 2 that is failing and determine exactly when interrupts are enabled and disabled, and determine exactly what the correct behavior is.

The ION instruction will not have any effect if the next instruction is an IOT or XCT until that instruction finishes execution.

12/22/21

We studied the section of the PDP-9 User's Manual that describes how interrupts work. It says that the ION Interrupt On instruction will not turn interrupts on if the next instruction is an IOT instruction. MAINDEC-9A-D02A-D Instruction Test Part 2 has an ION followed by an IOF and the diag will halt if an interrupt occurs. Our PDP-9 processes and interrupt so the diag halts. We need to study how the ION is delayed until a non-IOT instruction is executed.

We toggled in a small program that turns interrupts on, turns interrupts off, and checks to see that interrupts are off, and halts if interrupts are on. The program works OK when it is single-stepped, or run in repeat mode at less than full speed. At full speed it immediately fails.

We replace the two 2N3639 transistors on the the S202 board from slot J07 that implements the PIE flip-flop, and put it back in the processor. The processor now ran the little instruction loop OK for a few minutes, and then halted. We will let it cool off and try it again. The results were the same, it ran OK for a few minutes, then failed.

Next time, after the system warms up and will fail, we will trigger the 'scope on the RUN flip-flop (pins E&J on the S206 in CPU slot J31), and watch the the PIE interrupt flip-flop (S202 in slot J07) and maybe we see can see it misbehave. This will let us see the signals leading up to the failure. With the four-channel oscilloscope we can trigger on the RUN flipflop when the processor halts, and see the IOT 0002, SD0\, and SD0P signals that are the inputs to the PIE flipflop. The input signals on pins P & V must be stable before the IOT 0002 signal on pin N goes to ground. The IOT 0002 signal must stay at ground for 400 nS to enable the DCD gate in the S202 flioflop. If all of these signals look OK just before the processor halts, then we can look at the S & T pins that are the outputs of the PIE flipflop instead of the SD0\ and SD0P input signals. The S output pin is not wired to anything so we really only need to look at the T output pin. This should tell us if the problem is the with input signals to the PIE flipflop, the PIE flipflop itself, or maybe the modules that are connected to the T output pin. A shorted input connected to the T output of the PIE flipflop could stop the PIE flipflop from changing state.

12/27/21

We decided to trigger the 'scope from pin T of the S202 that implements the PIE flipflop. This signal goes to -3V for 4 uS between the ION and IOF instructions. We also looked at the SD0\ and SD0P input signals on pins P&V of the S202. These pins are opposite phase from each other and go to ground when active. The IOT 0002 signal goes to ground for 1 uS each time the ION or IOF instruction is executed.

The system ran the little ION/IOF check loop for 36 minutes before it failed with the PIE enabled after an IOF instruction was executed.

Looking at the 'scope we can see the IOT 0002 signal go active twice 4 uS apart, then there is a pause, and then the pair repeats. When it fails, the ION instruction is executed which generates the IOT 0002 signal, but the IOT 0002 signal from the IOF instruction is missing, so the PIE flipflip never cleared.

We toggled in a loop of three instructions; ION, IOF, JMP. Triggering the 'scope on pin T of the PIE flipflop shows jitter in the behavior of the flipflip when it should have a square wave. We looked at the IOT 0002 signal that gates the SD0\ and SD0P signals into the PIE flipflop. There is noticable jitter in this signal that corresponds with the jitter on the PIE flipflop output. IOT 0002 is generated by the NOR of the signal when device 00 is selected, and IOP 2(1). We looked at pin L output of the IOP2 flipflop and saw the same jitter. The IO CLK POS signal in pin N has no jitter. The IOP 2P signal on pin K has jitter. Signal MB16(1) in pin K and the output on pin J of the S107 in slot J18 look OK. When I put the 'scope probe on pin H of the S602 in slot H12 the PIE flipflop stops toggling. This is the IO 1 (1) signal.

When BK1(1) is low so it disables the RD RQ input to the S602 in slot H21, and the inverted MB16(1) signal on pin J is high, and the IO1(1) signal om pin H goes high, we should see a high-going signal on pin K. We see a high-going 200nS pulse that is the IOP 2P signal. The IOP2 flipflop is toggling every 8uS, and stays active for 1uS. That looks good.

We are back to an intermittent IOT 0002 signal.so the IOF signal is not reliable

12/28/21

The last time we tried to boot ADSS the DECtape did not move, so we decided to see if any other IOT instructions were not working. We toggled in a few instructions that read the console switches and write them to Status Register A in the DECtape controller. We should be able to move the DECtape back and forth by fiddling with the console switches. We can select a DECtape drive and set the Motion Control bits in Status Register A and move the DECtape. That means that at least some of the IOT instructions are working OK when the machine is cold. We should run the machine for a while and see if it stops working.

We tried the ION/IOF instruction loop. It works OK when the processor repeat speed is 5 or less, but halts when the processor is run at full speed. At full speed the processor will execute many ION/IOF loops, but then misses an IOT 0002 pulse from the IOF instruction and the loop halts.

We triggered the 'scope on the RUN flipflop when the processor halts. We looked at the R111 module in slot E23. We monitored the IOP2(1) signal on pin D, and the 00XXEN(B) signal on pin E. When the processor halts the IOP2(1) signal is missing a low-going pulse for the IOF instruction, and the 00XXEN(B) signal is has a slightly short low-going pulse for the IOF instruction.

We triggered the 'scope on the RUN flipflop when the processor halts. We looked at the S203 in slot E18. We monitored the IOP2(1) signal on pin L, the IOP1P signal on pin D, and the IO CLK POS signal on pin N. When the processor halts, we are missing a low-going pulse IOP2(1), we are missing a high-going pulse IOP1P, and the IO CLK POS runs until the processor halts.

We triggered the 'scope on the RUN flipflop when the processor halts. We looked at the S602 Pulse Amplifier in slot H20. We monitored the IOP2P signal on pin K, the IO1(1) signal on pin H, and the MB16(1) signal on pin J. 3uS after start we see a short positive-going pulse IOP2P coincident with the rising edge of the IO1(1) signal, and MB16(1) is high at the time. 4uS later we should see another pulse on IOP2P, but it is missing. The MB16(1) signal is high at the time, but there is no rising edge on the IO1(1) signal. 7uS later there is a rising edge on IO1(1), but MB16(1) is low at the time so there is no IOP2P pulse.

There is an explanation of the Gray Code Counter IO0/IO1 in section 3.8.1.4 of the Maintenance Manual.

We triggered the 'scope on the RUN flipflop when the processor halts. We looked at the IOT(B) signal that is an input to the Gray Code Counter. This signal goes low when an IOT instruction is decoded by the processor. This signal goes low three times for the ION, IOF, and IORS instructions, so this signal is not the cause of the missing IO1(1) signal.

We triggered the 'scope on the RUN flipflop when the processor halts. We looked at the IO CLK(B), IOT(B), and the output of the R111 in slot J12. The ION instruction gates three pulses into pin K of the S202 in slot J18, The IOF instruction only gates 2 pulses, and the IORS gates three pulses. When the IOF instruction is executing the IOT(B) signal turns off 1uS early so the third IO CLK(B) pulse is never gated to the S202 in J18. We looked at the IOT(1) signal on pin E of the S107 in slot F22. The levels are inverted, but is still one clock short for the IOF instruction.

We got a 'scope image of the signals when we single-stepped the processor through the IOF instruction. It gated three CLK(B) pulses. So it looks like this explains the behavior where the IOF instruction works OK, except when the processor is running at full speed.

The IOT(1) signal comes from the Control Memory in the processor.

We triggered the 'scope on the RUN flipflop when the processor halts. We looked at the CM STROBE C signal on Pin J of the B213 in CPU slot F15. The number and timing of the pulses for the ION and IOF instructions are the same. We looked at the LOT(1) signal on pin K, and see a strobe at the beginning and end of each IOT instruction. We looked at the IR3(0) signal and it is longer for the ION than it is for the IOF instruction when the processor halts, but the same length for the previous executions.

We swapped the B213 for IOT in slot F15, and there was no change in behavior.

We swapped the B213 for the IR3 in slot F13, and there was no change in behavior.

We looked at the microcode for the IOT instructions. When the IOT control word is executed, there is no CONT(1) or SM(1) so the control memory waits for three clock cycles. The IO RESTART signal from the I/O controller restarts the Control Memory timing.

We looked at the IO RESTART signal on pin D of the R002 in processor slot F34. This signal goes active when the IOT instruction is complete. It goes active too early when executing the IOF instruction.

We need to capture the 'scope image that has the IO RESTART signal again, but with the 'scope running at 5 uS/CM so we see more history. It will be interesting to see if there is an IO RESTART pulse at the beginning of the IOF instructions that work correctly, or only when the IOF instruction fails to turn PIE off.

Schematic page 117 shows the circuitry that generates the IO RESTART signal. If I am reading the schematic correctly, at the inputs to the R111 in slot J20 we should see IO0(0) low "AND" IO1(1) low, "OR" IOT(B) low "AND" UM(1) low to drive pin F of the S602 Pulse Amplifier in slot H20 high. On the S602 the DLY signal gates the pin F input from the R111 when it goes high, "OR" the IOP4(1) signal when it is high.

The IO0(0) and the IO1(1) signals come from the Gray Code counter at the bottom left of schematic page KD3(3). The first high-going pulse from IO CLK POS sets the counter to 00, the second pulse sets the counter to 10, the third pulse sets the counter to 11, and the fourth pulse sets the counter to 01. When the counter goes to 01, and the DLY signal goes high, the IO RESET signal will go active and end the I/O Controller's part of the IOT instruction.

It is possible that the extra IO RESET pulse at the end of the processor's instruction fetch cycle for the last IOF instruction indicates that the Gray Code Counter was not left in the correct state from executing the prior ION instruction.

Go to the later restoration blog.