PDP-9 Restoration Blog 2022


Go to the earlier restoration blog.

1/1/22

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.

1/5/22

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.

1/7/22

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.

1/12/22

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.

1/15/22

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.

1/26/22

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.

2/5/22

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.

6/25/22

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

7/13/22

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. 

7/16/22

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.

7/20/22

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.

7/20/22

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 5.3.1.2 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:

Now it doesn't halt at 240 when a new test is first run. It looks like the program in core memory is corrupted.

MAINDEC 9A-D01A INSTRUCTION TEST PART 1 runs OK.

MAINDEC-9A-D02A Instruction Test Part 2: The diag didn't load correctly from paper tape. Location 7203 should contain the bad contents 407757 that is to be corrected to 407777, but it actually contained 132000. Oops, bit 13 in the AR is stuck on again. Bits 12 & 13 of the AR are stored in the B213 in slot C30. We swapped the B213 in slot C30 for the one in slot C34 to see if the stuck bit moves to bit 15. After correcting core location 7203 the diag runs OK. Maybe a bad solder joint or bad connection on the gold fingers?

MAINDEC-9A-D1AA PDP-9 Basic Memory Checkerboard Test runs OK. 

We tried to boot ADSS, and got a Timing (TIM) error on the TC02 DECtape controller. It looks like we are back to debugging the TC02.

7/27/22

We loaded MAINDEC-9A-D3BB TC02 Basic Exerciser, and started debugging the Timing (TIM) error in the TC02 DECtape controller.

We tried to run just the part of the TC02 Instruction Test that doesn't need tape motion. It got stuck in a loop around address 000276.  We single-stepped through the diag, and everything looked OK. We ran the first part of the TC02 Instruction Test at full speed, and it worked OK. We ran the second part of the TC02 Instruction Test, and it got stuck in a loop. We halted the processor, and tried to single-step through the code. The CONTINUE switch is not working now. We restarted the TC02 Basic Exerciser, and it halted as expected at 000205. The CONTINUE switch would not restart the diag. We power-cycled the system, and there was no change. Now the diag won't run. It looks like memory above 004045 contains all 044044. We reloaded the diag, and it runs OK, but gets the same Timing error. The CONTINUE switch restarted the diag after the normal halt at 000240, but after we pressed PROGRAM STOP the CONTINUE switch does not do anything.

7/30/22

MAINDEC-9A-D3BB TC02 Basic Exerciser was still in core memory from our work on Wednesday.

We ran test #0, Move Scope Loop with the switches set to zero so it would change directions in the End Zone of the DECtape. This works OK, and the End Zone (END) error flipflop turns on for 23 ms, until the TC02 is commanded to move the other direction. Only the Timing and Mark tracks are used with this test, and none of the data is read. The TC02 stays in the Idle state during this test. It takes 30 seconds for the DECtape to travel the full length of the reel. This test ran OK for a long time.

We ran test #1, Search Scope Loop. It moved the tape just a little, and lit the TIM error, and stopped tape motion. The processor is in a loop. The DTF and RDY lights are on. When pin L of the S203 in slot E29 that implements the TIM flip-flop goes high (active), there is a positive 200 ns pulse the ROTATE DTB12-17/RWB signal on pin N, and the TIM EN signal on pin P is high (active). This will turn on the TIM error flip-flop. See TC02 schematic page D-BS-TC02-0-5 section D3.

We looked at input pin M of the S107 inverter in slot F18. Since the output on pin L of the inverter makes the TIM EN signal high, the input signal should always be low, and it was.

Now we need to look at the DF(1), DT ENA(1), and DT ENB(1) inputs to the S111 NOR gate in slot C11 to see why it is always driving the output signal on pin N low. DF(1) on pin K of the S111 NOR gate in slot C11 is always inactive low. DT ENA(1) on pin L of the R002 in slot C12 is always active high.  DT ENB(1) on pin L of the R002 in slot C12 is always active high.

The DT ENA(1) white diamond and DT ENB(1) white diamond signals come from the W104 flipchip in slot EF12. See schematic page D-BS-TC02-0-16 section C6 & C5. DT ENA(1) white diamond is always active high, and DT ENA(1) black diamond is always active low. Pressing the I/O RESET switch sets the DT ENA(1) white diamond is always active low, and DT ENA(1) black diamond is always active high.

We increased the time scale on the 'scope to see how far in advance of the ROTATE DTB12-17/RWB pulse the DT ENA(1) signals change state. There are 9 ROTATE DTB12-17/RWB pulses every 75 us, and just after the pulse before the TIM error is set the DT ENA(1) signals change state.

We looked at the possible sources of the timing (TIM) error:

Since the DTF light was on, we decided to investigate error cause #2. The DF flip-flop is set after the 8th ROTATE DTB12-17/RWB pulse and cleared about 20 uS later at the same time DT ENA(1) signals change state. The The DTF flip-flop is set at this time too. The PWR CLR signal clears the DTF flip-flop when the I/O RESET switch is pressed, and does not go active afterwards. The 0->DTF signal stays low inactive. The I/O BUS 11(0) is very active before setting the DTF flip-flop, and again after TIM error is set, but stays active low between the 8th and 9th ROTATE DTB12-17/RWB pulses. The XSTA (XOR Status A I/O instruction) signal is always high inactive, and needs to go low active to clear the DTF flip-flop. XSTA white diamond is always low inactive, and XSTA black diamond is always high inactive.

I toggled in a little loop of CLA, DTXA and a JMP instruction.  I can see the XSTA white diamond and XSTA black diamond toggling. That means that the W103 FlipChip in slot EF09 is decoding the DTXA instruction. We can also see the 0->DTF signal go active high, so the S123 FlipChip in slot F14 is OK. After the DTF flip-flop goes active, we don't see any DTXA instructions being decoded, so the the DTF flip-flop is not cleared. The 1->DTF pulse goes high active, the DTF flip-flop is set, but there is not another 1->DTF, so cause #2 is not the problem.

Maybe we should investigate cause #1? 

8/3/22

MAINDEC-9A-D3BB TC02 Basic Exerciser was still in core memory from our work on Saturday.

The Move Scope Loop works OK because it only reads the Timing and Mark tracks. The Search Scope Loop requires data-break to transfer the block number from the TC02 and core memory. If the TC02 requests a data-break, and it doesn't happen within 66 us, the TC02 will turn on the Timing Error and reset the TC02.

The DF (Data Flag) flip-flop indicates that a data-break is needed. We looked at the DF flip-flop on schematic page TC02-0-6 section D3. DF(1) black diamond is low and white diamond is high, WC(1) white diamond is high and 1->DF white arrow is low. After the tape moves there is a 100 ns positive pulse on 1->DF which causes the DT flip-flop to set. After 2 to 6 us there is a positive 300 ns pulse on the CLR DF signal and the DF flop-flop resets. Having the WC(1) signal always active looks odd. It looks like the data-break request is satisfied within 6 us, so TIM fault cause #1 is not the problem.

Time to look at the DTF flip-flop again. Pressing the I/O RESET switch causes continuous 600 ns positive pulses on the PWR CLR input to clear the DTF flip-flop. After the tape moved there was a 100 ns positive pulse on the 1->DTF signal which set the DTF flip-flop. I didn't see another 1->DTF pulse for 10 us after the first. The TIM error logic for cause #2 is elsewhere.

The diag should be executing a DTXA instruction with bit-11 set to clear the DTF flip-flop. We triggered the 'scope on the DTXA instruction and watched I/O BUS 11(0), DTF(1), and 1->DTF. We can see five DTXA instructions spaced at 35 ms intervals, a short positive 1->DTF pulse, the DTF flip-flop sets, and no more DTXA instructions. After the DTF flip-flop sets the I/0 BUS 11(0) bit is very busy.

We looked at the code in D3BB starting at 00720 that implements the Search function. We don't see a DTXA instruction that would clear the DTF flip-flop, so we really don't understand how this diag works. The CONTINUE switch with SING INST on is not functioning. We will need to fix that so we can single step the SREZLP function in D3BB and see why the it is not working. CONTINUE with SINGLE STEP is working, so we can use that for now.

We ran the D3BB program at REPEAT SPEED 5. The AC always contains 020577 which should be the block number.

8/10/22

MAINDEC-9A-D3BB TC02 Basic Exerciser was still in core memory from our work on Saturday.

Today we will look at the signals that set the TIM flip-flop. See schematic page D-BS-TC02-0-5 section D3. We see 9x positive pulses at a 65 us interval on the ROTATE DTB 12-17/RWB signal on pin N of the TIM flip-flop.  We also looked at the MK BLK MK signal on schematic page D-BS-TC02-0-8 section C1. The MK BLK MK signal goesl low for 18 us just before the 8th ROTATE DTB 12-17/RWB pulse. The TIM EN signal goes high after the MK BLK MK signal goes inactive. At the next ROTATE DTB 12-17/RWB pulse the TIM flip-flop sets.

Why does the TIM EN signal go high after the 8th ROTATE DTB 12-17/RWB pulse?

The signal on pin M of the inverter in slot F18 is the opposite phase of the TIM EN signal.

The DF(1) signal on pin L of the R113 in slot C11 pulses active high for 3 us just when the TIM EN signal changes state. Since the R113 is a NOR gate it should not latch, and this signal should not be the trouble maker.

PDP-9 Restoration Blog Starting 2022

Yellow=TIM(1), Teal=DF(1), Cyan=DTEN A(1), Blue=DTEN B(1)

The DF(1) signal initially goes high and turns on the TIM EN signal, and just before DF(1) turns off, the DTEN A(1) signal on pin L of the R002 in slot C12 goes high and keeps the TIM EN signal on. The DTEN B(1) signal on pin M of the R002 in slot C12 also goes active high and can also keep the TIM EN signal high. When the ROTATE DTB 12-17/RWB signal pulses with the TIM EN signal active the TIM flip-flop sets and causes the timing error.

Why are the DTEN A(1) and DTEN B(1) signals active?

Both of these signals are generated on the W104 flipchip in slot EF12.

8/13/22

MAINDEC-9A-D3BB TC02 Basic Exerciser was still in core memory from our work on Wednesday.

We still need to determine why the TIM error is being set. It looks like both the DTEN A(1) and the DTEN B(1) signals active, which makes TIM EN active, and when ROTATE DTB 12-17/RWB pulses it sets the TIM flip-flop. The DTEN A(1) and the DTEN B(1) signal originate on the W104 module that is part of the selection and data-break circuitry. The problem could still be in the processor if it is not controlling the I/O bus signals correctly.

There is also an issue in the processor that we need to debug. If you halt the processor when it is running D3BB after the TIM error is set, if you turn on SING STEP the CONTINUE switch has no effect. If you press I/O RESET then CONTINUE works normally.

We had lots of visitors, so we didn't get much debugging work done.

8/14/22

MAINDEC-9A-D3BB TC02 Basic Exerciser was still in core memory from our work on Saturday.

Today we will investigate the W104 Flip-Chip that handles the Data-Break signals. It also contains the flip-flops for the DTEN A(1) and the DTEN B(1) signals. Our guess is that maybe DTEN A(1) and DTEN B(1) should be cleared, which would not allow the TIM EN signal to set the TIM flip-flop.

We looked at the DT REQ flip-flop. See schematic page D-BS-TC02-0-16 section C7. We could see a negative pulse on I/O SYNC, then DF(1) go high, then another negative pulse on I/O SYNC, then the DT REQ flip-flop sets. It stays set for about 1 us, then there is another negative pulse on I/O SYNC, DF(1) and DT REQ clears. We also looked at the CLR DT signal. There is a high going 400 ns pulse on CLR DT that clears the DT REQ flip-flop. We also looked at the DCH RQ, DCH EN IN, and DCH EN OUT signals, and everything looks OK other than there is a lot of ringing on the I/O SYNC signal. Does this I/O bus need a terminator?

Next we looked at the DTEN A and DTEN B flip-flops and the resulting SELECTION(76) signal. We can see two positive pulses on the SELECTION(76) signal about 7 us apart, but they are only maybe 20 ns long. That seems very short. Then 8 ms later the SELECTION(76) signal goes high and stays high until I/O RESET is pressed. That doesn't sound right and probably means we are getting close to the problem.

Time to look at more of the DTEN A and DTEN B flip-flop related signals. After the DECtape moves we see DT REQ(1) go active high, then 1 us later (about one instruction execution time) DCH GRANT goes active low, then the DTEN A flip-flop sets and the DT REQ flip-flop clears.

Yellow=DTEN A(1), Teal=I/O SYNC, Cyan=DTEN B(1), Blue=DCH GRANT

The DTEN A flip-flop sets, then 3 us later there is a I/O SYNC pulse and the DTEN B flip-flop sets. At this point the state of everything is static, except that there are I/O SYNC pulses every 1 us. If the DCH GRANT signal went inactive the DTEN A and then 1 us later the DTEN B flip-flops would clear and the SELECTION(76) signal would go inactive.

If we halt the processor, turn on SING STEP, and try to single step using the CONTINUE switch, nothing happens. We suspect that the processor is in a weird state because the data-break never finished. 

What causes the DCH GRANT from the processor to go inactive high and clear the DTEN A flip-flop? The processor is running when it is stuck in this state. Is this stuck state part of the reason that CONTINUE in SING STEP doesn't work when the processor is halted from this state?

The DCH Timing diagram in the PDP-9 interface manual shows the DCH GRANT signal staying active for 3 us for data output. When DTEN B is set, the processor should do a Word Count cycle, then a Current Address cycle, then DCH GRANT should go inactive, then a Data cycle, then DTEN A should clear , and then DTEN B should clear.

It looks to me like the Data Break in the processor is not working. We don't have the TC59 magnetic tape controller connected to the I/O bus. If we did, there is a controller only Data Break test in the TC59 diagnostics. That would let us determine if the Data Break problem is in the processor or in the TC02. I think it is in the processor.

The DCH RQ from the TC02 goes active when a block number us found, then the DCH GRANT signal from the processor goes active, SELECT(76) goes active to indicate that the TC02 has been selected and it can put the Word Count address on the I/O Bus, and then it hangs like that. The processor stays running the MainDEC code, but the data-break never finishes. Since the DCH GRANT signal from the processor stays active the DTEN A and DTEN B signals stay active, and the ROTATE DTB 12-17/RWB signal finally goes active and turns on the TIM error flip-flop. The TIM error stops everything.

8/27/22

MAINDEC-9A-D3BB TC02 Basic Exerciser was still in core memory from our work on Saturday.

We are learning about how Data Break is implemented in the PDP-9. Data Break is similar to DMA on more modern machines, but instead of being implemented in a DMA controller chip it is implemented in the processor. The PDP-9 is a little more complicated than most DEC machines because it is microcoded, and has separate core memory and I/O controllers. The I/O controller isn't intelligent enough to perform the Data Break, so it needs help from the processor. On DEC machines, the processor stops executing the program, performs one or more data transfers between core memory and the peripheral, and then resumes running the program. The PDP-9 does support DMA, but it takes a separate chassis full of electronics to implement it, and it is only used for disk drives that we don't have.

When we run the diagnostic we can see the DECtape move a few inches and stop, and the TC02 displays a TIM error. What is likely happening is the TC02 DECtape controller moved the DECtape, found a block number on the DECtape, the controller activated the DCH RQ signal to tell the processor that it needed data (the block number) transferred from the TC02 to core memory, the I/O controller (or the processor) activated the DCH GRANT signal to tell the TC02 to put the address of the Word Count on the I/O bus, and then the Data Break never completed.

Section 3.8.2.2 and later in the F-97 PDP-9 Maintenance Manual explains how the Data Break works. The related timing diagram is Figure 3-24. It says that the DCH GRANT signal from the I/O Controller to the TC02 should clear the DT REQ flip-flop on the W104 flipchip.

We looked at the DT REQ, DCH GRANT, and CLR DF signals on the W104 board in slot EF12.

The processor is acting very strangely. We tried to reload MAINDEC-9A-D3BB, but it did not stop at the end of the paper tape. We loaded MAINDEC-9A-D01A Instruction Test Part 1 and it runs OK. That means that the majority of the processor is working OK. We loaded MAINDEC-9A-D02A Instruction Test Part 2 and it halted at 05762. That is E1551 which says PI OCCURRED IOF FAILED. It looks like this test disables interrupts, turns the clock on, waits for the clock flag, turns the interrupts on and off. An interrupt occurred which should not happen. We work on this Wednesday so we can make sure that all of the processor instructions are working OK.

8/31/22

We tried to reload the MAINDEC-9A-D3BB TC02 Basic Exerciser so we could look at the behavior of the signals on the W104 flipchip in the TC02 DECtape controller. It read just a little of the paper tape and stopped.

The build in maintenance tests ran OK, so at least the microcode is working. A pair of JMP instructions in a loop work OK so some instruction decoding is working. A loop of instructions to copy the console switches to the Status A register in the TC02 works OK.

We loaded and ran MAINDEC-9A-D01A Instruction Test Part 1 and it runs OK. We loaded and ran MAINDEC-9A-D02A Instruction Test Part 2 and it ran for a few seconds and then halted at 05762 @E1551. We pressed CONTINUE and it immediately halted at 05766 @E1552. These two errors show that with a CLK interrupt waiting, executing the ION & IOF instruction pair allowed an interrupt to occur. We pressed CONTINUE and it ran for a few seconds and then halted at 05762 @E1551, back to the original halt.

We single-stepped the instructions starting at 05757, the ION instruction. The PIE light turned on when the ION instruction was executed, but the PIE light stayed on when the IOF instruction was executed. We tried this later, and the IOF instruction worked OK.

We single-stepped the instructions starting just after E1550 at 05745 with the LAC IRET4. The AC was loaded with 605762, a JMP to 05762, which was then stored @ 00001. The AC was cleared and stored @ 00000. The AC was loaded with 777777 and then stored @ 00007. The Interrupts were disabled, the clock enabled, then the processor looped waiting for the clock flag to go on. The status word contained 006000 so the clock is enabled and has overflowed. The interrupts were enabled, then disabled, but the PIE light didn't go out.

In the schematics there was a note that we repaired the S202 FlipChip that implements the PIE flipflop on 12/22/21. I looked through the restoration notes for 2021 and the symptoms were the same as what we have now. 

We toggled in a little program that does an ION & IOF and then looks at the status word to see if the interrupts are enabled, and if so it halts. We triggered the scope on pin E of the RUN flipflop in slot J31 of the processor going low. We looked at the SD0\, SD0P, and IOT 0002 signals on the PIE flipflop in slot J07 of the I/O controller. We can see the SD0P signal go high and then a positive pulse on the IOT 0002 signal. This will set the PIE flipflop. Then we see the SD0\ signal go high and then a positive pulse on the IOT 0002 signal. This should clear the PIE flipflop. All of this looks OK, but since the processor halted the PIE flipflop was not cleared by the IOF instruction.

We triggered the scope on pin E of the RUN flipflop in slot J31 of the processor going low. We looked at the SD0\, IOT 0002, and PIE(1) signals on the PIE flipflop. When we run the instruction loop we can see pairs of IOT 0002 signals as the PIE flipflop is set and cleared, and when the processor halts the IOT 0002 pulse is missing for the IOF instruction. It executes LOTS of loops before it halts.

Yellow=RUN(1), Teal=SD0\, Cyan=IOT 0002, Blue=PIE(0)

So we are sometimes missing an IOT 0002 pulse when the IOF instruction is executed which causes the interrupts to stay enabled, and it fails Instruction Test #2. The ADSS operating system turns interrupts on and off, so periodically not being able to turn interrupts off could cause an OS crash. We looked at the source of the IOT 0002 signal, the R111 flipchip in slot E23 (KD3 sheet 1). Quite a bit of logic is involved in generating this signal, so we have some debugging to do.

Now the machine is really dead. The EXAMINE, DEPOSIT, RUN, and I/O RESET switches do nothing. The build-in register diagnostics run OK, so some of the processor is alive.

We decided to start with the basics, the I/O RESET switch makes the KIO signal. The flexprint cable from the console switches plugs into slot CP slot H37. The KIO signal is on H37 pin M. The KIO signal goes to ground when the switch is pressed and to -15V when not pressed. The same is true for the EXAMINE and EXAMINE NEXT switches. So, the cabling from the console to the CP is OK and the pull-down to -15 and grounds on the console are OK. The KIO signal goes to pin H on the S602 Pulse Amplifier in I/O slot H11. It goes to ground when the switch is pressed. Pin E has 1 MHz positive going pulses, and pin K also has 1 MHz positive going pulses making the signal IO PWR CLR POS. I think that the RDY indicator in the TC02 should go out when I/O RESET is pressed, and it does not.

Next we will look at the logic on schematic page KC10 sheet 1 to see if the signals all the way to RUN(0) are being activated by the switches. We noticed that repeated pressing of the EXAMINE NEXT would sometimes cause some console activity.

9/3/22

We started by looking at the console key signals on schematic page KC10-1. Looking at the KEY BUS signal, we see a positive going edge when any key except for PROGRAM STOP is pressed. We also looked at the signal on pin V of the R302 delay in slot J32. It should have a 50 MS negative going pulse. It actually has a 68 MS delay, and the trimpot has no effect on the delay time. This is likely just for console switch debouncing, so the delay time is probably not critical. We will leave it as it is and look further in the signal chain.

There is a 50 uS negative going pulse on pin M of the R302 delay in slot J32. Pin N of the R111 NAND gate in slot J28 is always at ground. Pressing most of the keys will stop the processor from running, and that looks like it is what this signal does.

SINGLE STEP will stop the processor when running. SINGLE INST and STOP will not stop the processor when running. 

9/5/22

We looked at why the STOP key does not clear the RUN flipflop on schematic page KC10-1 section C3. Pin D of the R111 NOR gate in slot J27 is at -15V when the switch is inactive and at ground when the switch is active. Pin H of the R111 NOR gate in slot J27 is at ground when the switch is inactive and at -3V when the switch is active. Both are OK. Pin S of the R111 NAND gate in slot J28 is at ground when the switch is inactive and at -3V when the switch is active. The RUN(0) signal on pin U of the R111 NAND gate in slot J28 is at -3V when the processor is running, and will get driven to ground and clear the RUN flipflop when the STOP switch is pressed. For this to happen when the STOP switch is pressed the DONE(1) signal on pin R needs to be at -3V, the LOCK\ signal on pin T of the R002 in slot H29 needs to be a -3V, and the F35N signal needs to be a -3V. The LOCK\ signal is at -15V and the F35N signal is at -3V. The done signal is at ground when the processor is running so the STOP switch will not stop the processor. Why is the DONE flipflop not set? The DONE signal indicates that an instruction has completed execution and the next instruction can be fetched.

Time to look at the Control Memory timing. We started with the 1 MHz clock on schematic page KC10. The 1 MHz CLK POS is positive going pulses on pin F of the S603 pulse amplifier in slot J23. This also means that the RUN flipflop is set. Stopping the processor with the EXAMINE switch turned off the CLK POS clock. When the processor is running there are negative going CM CURRENT pulses on pin U of the R111 NOR gate in slot F26. There is a single CM CURRENT pulse when EXAMINE is pressed. 

The Maintenance Manual has lots of detail about how DEPOSIT works, so we will start there. There is a 85.1 KHz clock on pins E & J of the S206 flipflop in slot J29. This makes the C signal that is active when the processor is not running. There is a 28.1 KHz clock on pins R & P of the S206 flipflop in slot J30. This makes the B signal. There is a single clock on pins E & J of the S206 flipflop in slot J30 when one of the switches is pressed. The REPT flipflop turns on at the same time as C(1) and off a little later. The KEY INIT POS 100 ns positive pulse is present on pin U of the S603 pulse amplifier in slot J25. The pulse occurs about half way through the C(1) signal. That looks OK. We need to remember that the R302 delay in slot J32 that is supposed to be about 50 MS is actually about 68 MS and delays the KEY DELAY signal.

The KEY INIT POS signal should start the Control Memory timing sequence. The KEY INT POS pulse is on pin E of the R002 OR gate in slot F34. The resulting RESTART NODE pulse on pin F of the R002 in slot F24 looks strange. If is mostly at ground and goes to -3V every 6 us for 1 us. If the RESTART NODE signal is already positive, the KEY INIT POS pulse will have no effect. We looked at the CONT(0) signal, a negative going pulse 10 us after KEY INIT POS, and the MEM STROBE, always at -3V. MEM STROBE is a negative going strobe, so it being always low doesn't sound right. Ah, the IO RESTART signal matches the funny looking RESTART NODE signal.

Time to look at IO RESTART that comes from the I/O Controller. I put Mylar tape over the gold finger for pin D on the R002 on slot F34. Now the RESTART NODE signal matches the KEY INIT POS signal and the console switches are working again. I entered a little JMP-JMP instruction loop and it ran fine with SINGLE STEP and REPEAT. 

Pin K of the S602 pulse amplifier in I/O Controller slot H20 has the really strange looking IO RESTART signal. Pin L has the INPUT TO RESTART signal which is always inactive low. The DLY signal on pin E is always inactive ground. Pin F has a combination of lots of signals and is slightly below active ground. Pin J has the IOP4(1) signal which us very active. We swapped the S602 Pulse Amplifiers in slots H21 and H21, and now the processor is really dead. We replaced the S603s and removed the S203 in slot E18 that makes the IOP flipflops and this made no change. and the wacky IO RESTART signal is still there. We removed the R111 in slot J20 and the wacky IO RESTART signal is still there.  I removed the R002 in processor slot F34 and the IO RESTART signal looks much better. We tried a different R002 and it didn't make a difference. I put the Mylar tape back over pin C of the R002 in processor slot F34 and the console is still completely broken. Maybe the repeated power cycling broke something?

Time to look at the processor timing again. The KEY BUS and KEY INIT POS signals look OK. The RESTART NODE signal on pin F of the R002 in slot F34 looks OK. The output on pin D of the B602 pulse amplifier in slot F32 looks OK. There are lots of pulses on pin FL of the B310 delay in slot EF33. I pulled the B104 in slot F31 and the only signal on pin FL of the B310 delay in slot EF33 is the pulse from KEY INIT POS. I tried a different B104 in slot F31 and there was no change in the behavior, still lots of activity on the pin FL of the B310 delay in slot EF33.

9/10/22

Since the processor is really broken we will start by looking at the KEY INIT POS signal on schematic page 10 sheet 1. That signal goes to schematic page 16 and starts the control memory timing chain. There is no KEY INIT POS signal. KEY BUS(B) is present when a switch is pressed. The C flipflop outputs are toggling at the REPT CLK rate. The B flipflop outputs are toggling at half of the REPT CLK rate. IND CLK has positive pulses at a 29.1 kHz rate. The output of the S107 inverter in slot H34 has an inverted IND CLK. The REPT flipflop toggles once when a key is pressed. The A flipflop toggles at the end of the REPT signal.

Looking at the R111 NAND gate in slot J26, KCT\ is at -15V, A(1) goes low for 17 us when a key is presses, and pin H goes high for 17 us. Looking at the S602 Pulse Amplifier in slot J25, IND CLK\ goes low for 2 us, KEY INIT POS goes high for 100 ns. 

Looking at the R002 OR gate in slot F34, IO RESTART is at ground because we disconnected it, KEY INIT POS goes high for 100 ns, RESTART NODE goes high for 100 ns. Pin D of the B602 Pulse Amplifier in slot F32 goes low for 50 ns. Pin L of the B310 Delay in slot EF33 is toggling every 200 ns. That will really confuse things. We replaced the B310 with an unknown spare, and it didn' t change anything. We removed the B104 inverter in slot F31, and now the output on pin L of the B310 Delay in slot EF33 is a single pulse. We replaced the B104 inverter with an unknown spare, but it didn't change anything. Pin N of the B104 Inverter in slot F31 is toggling every 200 ns. Pin EM of the Delay in slot is toggling every 200 ns. This is the CM STROBE D signal. CM STROBE A and CM STROBE B look the same.

Looking at STROBE DELAYED, it is pulses at a 3 MHz rate. Pin FD33 in the B310 delay is quiet, so KEY INIT POS is not the source of the problem. 

Looking at the B104 inverter in slot F31, pin N is pulses at 4.5 MHz, pin P is always low, and pin R is pulses at 4.5 MHz. That means that CONT(1) is always active. I think that this should only be active when the CONT microcode bit is present.

Looking at the B213 JAM FLIPFLOP in slot D28 that makes the CONT signals. Both the P and N pins are low, so that looks broken. We looked at other B213 flipchips and they are in the same state. We looked at the +10V and -15V that feeds many of the Control Memory and found that the +10V was missing. The +10V margin switch #4 was not all of the way to the left or right, so not +10V to a section of the chassis. We cycled the switch a few times, and now the processor is functioning correctly again. Next time we will cycle all of the margin switches to make sure that we have power everywhere.

Looking at the IO RESTART signal on pin D of the R002 OR flipchip in slot F34. The signal is always high. We removed the Mylar tape from Pin D and now there is a a 6 us repetition rate. The processor is broken in this state.

Looking at the S602 Pulse Amplifier in slot H20 in the I/O chassis. Pin K has the 6 us (200 KHz) repeating signal. Pin K has INPUT TO RESTART always inactive low, so that is not the source of the problem. The DLY signal on pin D is always inactive high, pin F is always active high, and pin J has a square wave signal IOP 4(1) repeating every 12 us. Maybe the Pulse Amplifier is bad? We swapped the S602 Pulse Amplifier for an unknown R602 and the signal on pin K is the same. We removed the R602 and the 200 kHz signal is gone and the pin is always low. At least we know the signal is coming from the S602 in slot H20.

Looking at the S203 flipflop in slot E18 that is the source of the IOP 4(1) signal. The flipflop for the IOP 4 signal is toggling rapidly. We replaced the S203 with an unknown R203, and now the IOP 4(1) signal is not toggling. We don't have any spare S203 flipchips, so we will need to repair the defective one. 

9/14/22

We really need to get the IO RESTART signal to behave. The Control Memory in the Processor stalls after the IOT instruction fetch cycle waiting for the I/O Controller to perform the I/O. When the I/O Controller completes the I/O it sends the IO RESTART signal to the Processor to restart the Control Memory cycles. We see lots of IO RESTART signals from the S602 Pulse Amplifier in I/O slot H20 which is really screwing up the Control Memory.

I put Mylar tape over the gold finger for pin D on the R002 on slot F34. This disconnects the misbehaving IO RESTART signal from the processor and lets us run instructions. We toggled in a little loop to turn the CLK on and off. When we executed the CLON instruction the PIE also turned on. This should be easy to fix. We triggered on the falling edge if the IOT(B) signal, and looked at the IOP 1P, IOP 2P, and IOP 4P signals. These should be staggered edges at 1 us intervals. We actually see lots of pulses at about a 7 us interval. That would make a mess of the I/O instruction decoding.

The OXEN signal goes low coincident with the IOT(B) signal, indicating that the IO device selected is part of the I/O controller. We also looked at the IOP 1P, IOP 2P, and IOP 4P signals. These are instruction bits 17, 16, & 15 gated by the IO 0(1) signal. That means that the Gray Scale counter IO 0 & IO 1 is constantly running.

We looked at the function of the R111 NAND gate in slot E15. This only lets the CLK POS signal through when IOT(B) signal is active. The output of the S603 Pulse Amplifier that makes the IO CLK POS signal is only active when IOT(B) is active. Unfortunately without the IO RESTART signal restarting the control memory IOT(B) stays active, and therefore IO CLK POS stays active.

We looked at the inputs to the R111 NAND gate in slot J20. About 2.2 us after IOT(B) goes low we also see IOT 0(0) and IOT 1(1) go low. The output of the R111 NAND gates in slot J20 is almost at ground until IOT 0(0) and IOT 1(1) go low and then it goes up to ground. When IOT 0(0) and IOT 1(1) both go high we see the NAND output get pulled low in an RC curve.

We replaced the R111 with an unknown spare, and now the output on pin N of R111 is starts low and goes to ground when IOT 0(0) and IOT 1(1) go low. This looks much better. We took the Mylar tape off of the R002 in processor slot F22, and the console is dead again.

9/17/22

Now that we replaced the R111 in slot J20 the input to pin F of the S602 Pulse Amplifier in slot H20 should be at ground when IOT 0(0) and IOT 1(1) are low, and when the DLY signal goes low the IO RESTART signal from the Pulse Amplifier should pulse high. That should restart the Control Memory timing in the processor. Right now the console is dead with IO RESTART connected to the processor, so that is the signal that we need to look at.

I put Mylar tape over the gold finger for pin D on the R002 on slot F34 so we could toggle in IOT instructions and run them.

Both PIE and CLK get turned on by either the 700044 CLON instruction or the 700042 ION instruction. This should be easier to fix than the IO RESTART problem so we will start here. We looked at the IOT 0002 and IOT 0004 signals on schematic page KD9-3(1) and triggered on IOT(B). Both signals went active ground coincident with IOT(B) going high. Even a 700040 signal wound trigger both the the IOT 0002 and IOT 0004 signals.

We looked at the 00XXEB(B), IOP2(1), and IOT0002 signals when IOT(B) goes active. Before IOT(B) goes active low, IOP(1) is active low and 00XXEB(B) is inactive high. About 50 ns after IOT(B) goes active 00XXEN(B) goes active low. About 250 ns later IOP2(1) goes inactive ground, and then 1 us later it goes active low. This causes about a 250 ns active ground IOT0002 signal, about a 750 ns inactive low signal, and then a long active ground signal. I don't think that IOP2(1) should be active at the beginning of the IOT instruction.

The IOP4(1) signal is also active low at the start of the IOT instruction, and about every 12 us. We need to go back and fix the S203 in slot E18 that implements the IOP1, IOP2, and IOP4 signals. The IOP1 and IOP2 signals start running when the IOT instruction is executed. The IOP4 signal is always running. We looked at the DLY\, IOP 4P, and IOP 4(1) signals. When executing a 700040 instruction DLY\ is always active ground, IOP 4P is toggling every 6 us, and IOP 4(1) is toggling every 12 us. We tried 700041, 700042, and 700044 instructions and there was no change in the behavior of any of the signals for IOP 4. We temporarily swapped an unknown R203 for the S203 and the toggling on the IOP 4 is gone, but the output is only at -1V, so not deterministic.

We replaced Q5 & q6 on the S203 Flipchip and now IOP4 is not constantly toggling. When executing a 700047 instruction DLY\is always high, but this a rising edge triggered gate so inactive, IOP 4P is constantly toggling, and IOP 4(1) is always active low. Why no DLY\ signal, and why more than one IOP 4P signal?

 Looking at the DLY\ signal, IO CLK POS is a positive going pulse at 1 MHz. The inverted output IO CLK(B) looks OK. There is no output on pins D & F of the B301 Delay in slot H22. We don't have any spare B301 Delays so we put the B301 on an extender board so we can debug the board with the system running. After it executes an IOT instruction the IO CLK (B) signal is active and running at 1 MHz. Pin R is the collector of the first transistor, and has the inverted version of the IO CLK (B) signal, but with a higher voltage transition. The Anode of diode D14 has a positive going spike coincident with the low going edge of the IO CLK (B) signal. The cathode side of D14 shows no activity.

9/24/22

We worked on the LT Spice simulation of the B301 Delay. We need to get better models of the transistors to get it working. The circuit that adjusts the delay is a mystery. Hopefully we can get the simulation working and get a better understanding of how the B301 works. The LT Spice experts said that we could measure the inductance of the primary and secondary sides of the three transformers on the B301 and enter the values into the Spice model of the transformers. They said that the number of turns of wire are not as important in the simulation as the ration of the inductance.

There are three transformers on the B301, T1 is a T-2010, T2  is a T-2027, and T3 is a T-2057.

We put an R401 clock flipchip and the misbehaving B301 delay in a receptacle block, and connected it to +10VDC and -15VDC power supplies. We adjusted the R401 so it runs at 1 MHz, just like the PDP-9. We connected the pin D output of the R401 to the pin T input of the B301, grounded pins N and E, and interconnected pins P & U.  This should be close to replicating the system environment for the B301 delay, and will give us much better access to the signals on the B301.

We can see the 1 MHz signal on pin R of the B301, so we know that Q6 is switching OK. We wee very little signal on terminal 7 of T3, and also very little on the base of Q1. We see the -3VDC derived from the -15VDC. The collector of Q1 is mostly at ground and rings +/1 1VDC at the leading edge of the inpit pulse.

9/25/22

I ordered a replacement B301 and some other spare FlipChips from Jörg Hoppe in Germany.

9/28/22

With the R401 running at 1 MHz, the signal on pin R of the B301 is mostly at ground, but goes to -4V for 200 ns coincident with the input on pin T going high.

We finished reverse engineering the B301 board and made a partially translucent image of the board with all of the reference designators shown. That will be very useful for finding components on the board.

We used a FLIR camera to look at component temperatures when the board was powered up. We were surprised to find that transformer T2 was warm, when all other components were cool. Maybe transistor Q5 is always on and always passing current through T2?

In circuit D5 didn't look good, but when removed and using a voltage drop test in a DVM looks OK.

The voltage across the Zener D2 is about 7.17VDC. I think that it is supposed to be a 6.8V Zener.

We removed transistors Q1 and Q3 for checking. The B-E and B-V voltage drops for Q1 look OK. The B-C for Q3 looks OK, but the B-E is open. A NOS replacement transistor showed the same voltage drops and had a beta of 0. I replaced Q3 with a general purpose NPN NTE287. It did not improve the behavior. After looking at the voltages on Q3, I am not sure that it was installed correctly at the factory, and I installed the replacement the same way.

10/4/22

I received the replacement B301, and some other spare FlipChips from Jörg Hoppe today. I will try it in the PDP-9 tomorrow after I test it on the bench. I will record the waveforms at various stages in the circuitry to aid in repairing the broken B301.

10/5/22

We tried the replacement B301 in the bench test fixture. We fed a 1 MHz signal into pin T, and saw a 200 ns -5V pulse at a 1 MHz rate on pin R. That means that transistor Q6 is working. We saw a 500 ns -5V pulse at a 1 MHz rate on pin F. That means that transistors Q1, Q3, Q4, and Q5 are working. Adjusting R14 changes the duration of the 500 ns pulse. We grounded pin E and saw a DEC Standard Pulse at a 1 MHz rate on pin D. Adjusting R14 changes the delay from the rising edge of the pulse input on pin E to the falling edge of the pulse on pin D. We set the delay to 500 ns.

10/8/22

I went on an HP rescue mission with Kyle and then did a warehouse tour so I got a late start.

I put the B301 in the PDP-9, triggered on the falling edge of the IO CLK(B) input, and looked at the DLY and CLK DLY'D signals. There should be a 500 ns delay and it should be adjustable by the trimpot on the B301 flipchip. The delay was closer 550 ns, and the trimpot had no effect. The trimpot adjustment worked fine when the B301 was in the benchtop test fixture.

We need to revisit the adjustment of the B301.

I set the 'scope to trigger on the falling edge of the IO RESTART signal on pin k of the S602 in slot H20. I ran a little program to turn interrupts on and off, but 'scope didn't trigger, so we need to find out why that signal was not generated. It is possible that the delay for the DLY and CLK DLY'D signals is not 500 ns, so the signals are not making it through the S602 Pulse Amplifier.

10/12/22

We put the B301 back in the bench test fixture and set the delay to 500 ns. When the B301 is installed in the PDP-9 and the processor is running the delay from pin T to pin D is 50 ns, not the 500 ns that we need. I put the B301 on an extender board. I measured the supply voltages to the B301 and found that the switch 5 +10V fuse that feeds the B301 was blown. This stopped Q3 from being able to adjust the delay. I replaced the fuse and adjusted the B301 delay to 500 ns. I removed the extender board and installed the B301 directly in the chassis. I had to adjust the delay again to make it 500 ns. I power cycled the machine, started the processor, and the delay was still 500 ns.

I looked at pins E, F, J, & K of the S602 pulse amplifier in slot H20. Pin K, the IO RESTART signal has a 120 ns positive going pulse coincident with the rising edge of the DLY signal in pin E. At this time the pin F is high and the IOP 4(1) signal on pin J is low. This looks reasonable.

Turning on the IOP 4 bit in the IO instruction turns on the IOP 4(1) signal on pin J until the rising edge of the DLY signal. This also looks OK.

I removed the Mylar tape from pin C of the R002 in processor slot F34. The processor console is still working, and I can single-step and IOT instruction. This is really good progress.

The CLON and CLOF instructions enable and disable the Real Time Clock. The ION instruction enables Program Interrupt, but the IOF instruction does not disable Program Interrupt. This is about where we started with the processor problem. This problem should be relatively easy to fix.

The right hand reel on the TU55 at the top right is constantly running and wound the tape off the reel. I disconnected the AC input to the drive for now.

10/15/22

Fix the problem with the IOF instruction not deactivating Program Interrupt.

We toggled in a short program to enable and disable interrupts. We put a NOP instruction after the ION and IOF instructions because these instructions won't work if an IOT instruction comes after the ION or IOF instruction.

We looked at the IOT 0002, SD0\ and SD0 P signals that control the PIE flipflop in slot J07. We can see the SD0\ and SD0 P signals toggling, but the IOT 0002 signal is always low.

We looked at the R111 NAND gate in slot E23 that makes the IOT 0002 signal. The 00XX EN(B) signal is toggling at a 250 kHz rate, so that looks OK. The IOP2(1) signal is always high (ground), so the NAND gate won't do anything.

We looked at the IOP 2 S203 flipflop in slot E18. The IO CLK POS is running at 1 MHz, but it is only going down to -2V. That is suspicious. The IOP 2P is always low. The outputs, M is always low and L is always high, so the flipflop is always cleared. I think that we should see IOP 2P going high periodically to set the flipflop.

The IOP 1P, IOP 2P, and IOP 4P signals are always low.

We looked at the IO 0, and IO 1 flipflops on the S202 in slot J18. Pins H & J on the IO 0 flipflop are active. Pins S & T for the IO 1 flipflop are always high and low. We replaced it with a spare and now both IO 0 and IO 1 are toggling. The interrupt enable PIE is also toggling.

So, it looks like the Processor might be fixed now. Time to run the Instruction 1 & 2 diags.

MAINDEC-9A-D01A Instruction Test Part 1 runs OK.
MAINDEC-9A-D02A Instruction Test Part 2 runs OK.
MAINDEC-9A-D0BA ISZ Test runs OK. runs OK.
MAINDEC-9A-D0CA Memory Address Test failed.
MAINDEC-9A-D0DB JMP Self Test runs OK.
MAINDEC-9A-D0EA JMP-Y Interrupt Test halted at 00227. This should not happen.
MAINDEC-9A-D0FA JMS-Y Interrupt Test halted at 03026. This should not happen.
MAINDEC-9A-D1AA PDP-9 Basic Memory Checkerboard Test failed.
MAINDEC-9A-D1FA PDP-9 Extended Memory Address Test runs OK.
MAINDEC-9A-D1BA PDP-9 Extended Memory Checkerboard Test runs OK.

We reran Instruction Test Part 1 and Instruction Test Part 2 for 30 minutes each. Both ran OK.

I will declare victory and call the processor fixed.

Fix the problem with the right hand hub on the TU55 at the top right constantly running.

We swapped the two G850 SCR Motor Driver boards and the problem moved to the left hub. That means that the G850 in slot A12 is defective. We borrowed a G850 from the left drive, and now both motors work OK.

We tried to boot ADSS from DECtape and get TIM (Timing) errors from the TC02 controller. We tried another ADSS DECtape and saw the same TIM error. Looks like there is more debugging to do.

10/19/22

We took a quick look at the failed G850 FlipChip and compared it to the other three failed G850s we have. The forward & backward voltage drop of the 2N4443 SCR on the four G850s are all different. We will look at these later.

We are back to where we were debugging on 7/20/22.

The TIM (Timing) error on the TC02 can come from three possible sources:

It is not cause #3. We will look at cause #2.

On the W104 in slot EF12, when DF(1) goes active and then I/O SYNC pulses the DT REQ flipflop should set and cause the DCH RQ signal to go active. The Processor will finish the current instruction, should send a BK SYNC to the Control Memory and a DCH GRANT to the W104 in the TC02. The TC02 should then put its Word Count on the secondary I/O bus, which is used by the Processor to determine if a data transfer should occur, or the transfers are complete.

See Processor schematic page KD2(2) for the Data-Break circuitry in the I/O Controller

When we execute the DECtape bootstrap:

10/22/22

BK SYNC on I/O controller pin F10H goes low during DECtape boot. It stays low more than 500 ms, so that is not right.

We don't have any PDP-9 I/O cables. These are a block of 4x flipchips so you only need 2x BC09 I/O cables. The BC09 cables are nearly identical to the BC10 I/O cables for the KA10. The LCM has lots of those, but isn't willing to part with any. 

For now we are using 8x PDP-8 I/O cables. This works OK, but is a little more complicated to wire. We don't have a second set of 8x PDP-8 I/O cables to connect from the TC02 DECtape controller to the TC59 Magnetic Tape controller. I will probably try using a set of Vincent's ribbon cable FlipChips to see if those will work OK.

We also need 3x cables that connect to the indicator lamps on the TC02. These are direct finger to ribbon cable on one end and finger to ribbon cable through a diode on the other end. I will work out with Vincent what we can use, and if we need to reproduce one of the FlipChips.

We decided to use the TC59 1/2" Magnetic Tape controller to test the Data-Break functionality. This controller has a feature that will net you write to the Data Buffer, and then force a Data-Break transfer. We put the indicator and the I/O bus cabling back on the TC59. We loaded MAINDEC-9A-D4AF TC-59 Instruction Test. The instructions say that the paper tape is in ABS format and should load at address 17720. The paper tape has a note that says to load at address 17700. This means that the paper tape has a BIN loader in RIM format at the beginning of the paper tape that will automatically run and then load the rest of the tape in the more compact BIN format.

Tests 0 & 1 that test the initial IOT commands and all possible combinations of the Command Register works OK. Test 2# that tests writing and reading all possible values of the Data Buffer failed. This may be a problem in the processor, or in the TC59.

We wrote some little programs to fiddle with the Data Register to determine what is going wrong with test #2. We found that you need the Write or the Write/Compare command in the Command Register before you can use the maintenance commands to read/write the Data Register.  We also found that the connection from the I/O bus to the Data Register has the I/O bits tied to both inputs of the R203 flipflops. That means that a 1 input will compliment the existing contents of the flipflop. This seems pretty complicated, so I wanted to look at the code in the diagnostic. Unfortunately the printed manual and listing for the diagnostic are an early version, and the only image of the diagnostic that we actually have is a later one that works for both the PDP-9 and the PDP-15. I am working on a paper tape disassembler to get a source listing from the paper tape image. Then I can see if I can pull comments from the earlier listing to make a working new listing.

We tried the TC-59 Instruction Test again, and even test #0 failed. We tried reloading the diag, and it ran off the end of the paper tape. So now the processor is broken again.

Instruction test #1 runs OK, Instruction test #2 halts at 05767, E1552. It looks like it got a clock interrupt after an ION IOF instruction sequence. It looks like we need to fix some more things in the I/O section of the processor.

10/26/22

A good place to start might be the IOT pulse timing to make sure that they are about 1 us long for the first two and 500 ns long for the third.

We tried Instruction test #2 today, and of course it runs OK. Maybe the PDP-9 didn't like being powered on for most of Saturday?

We toggled in a little loop containing an IOT instruction with the IOP 1, 2, and 4 bits turned on. The three bits start on the 1 us IO CLK POS clock tick. IOP 1 & 2 are a little less than 1 us long, and IOP4 is about 500 ns long. That all looks OK. Maybe it will break again if we leave it turned on for several hours.

Time to go back to testing the TC59 magnetic tape controller.

MAINDEC-9A-D4AF TC-59 Instruction Test would not load from paper tape. This diag has a loader at the front that is in RIM format, automatically runs after it is loaded, and loads the rest of the paper tape in BIN format. It isn't loading anything at all into memory.

MAINDEC-9A-D01A Instruction Test Part 1 ran OK.

MAINDEC-9A-D02A Instruction Test Part 2 ran for a few minutes and then halted at 05767 E1552, just like on Saturday. 

We toggled in a program that is ION, IOF, JMP. This should never turn on the interrupts, but it does. That is the debugging project for Saturday.

10/29/22

In the failing part of MAINDEC-9A-D02A Instruction Test Part 2, it looks like the diag loads the address of E1551 (05767) into memory location 1, clears location 0, loads a -1 into memory location 7. This memory location contains the number of clock ticks before it will generate an interrupt. The clock is using a form of data-break to increment the counter in memory location 7. The interrupts are turned off, the clock is started, the processor loops until the clock flag goes on, which should be just one clock tick. The interrupts are enabled and then disabled. The clock interrupt should not be serviced, so it skips over the halt at 05767 E1551. Then it clears the clock flag, and checks that memory location 0 contains zeros.

We saw a 1 in memory location 0 when it should contain a 0. If it contained the address of the IOF instruction then we would know that the IOF did not happen and the interrupt was executed. We don't see the address of the IOF instruction, so something else is happening. 

We setup the 'scope to trigger on processor halt, and then watched the CLK EN and CLK FLG flipflops. We toggled in a small program like the diag that will halt after the clock flag is set. The 'scope shows CLK EN active, then CLK FLG goes active for 6 us then inactive, then CLK EN goes inactive, then 2 us later the processor halts. This behavior looks OK, but the run time for the program varies from 50 ms t0 200 ms. Something is wrong with the way that the clock is ticking. The clock actually does a data-break cycle to increment the counter at memory location 7. We think that the data-break memory increment function is not working correctly. That should be fun to debug.

The RT CLK signal is a 20V sine wave at 60 Hz (16.7 ms) and the W501 in I/O slot J05 converts it to a standard negative logic 60 Hz square wave. The CLK REQ flip-flop goes active at a 60 Hz (16.7 ms) rate. The last time we ran the test program there were 6 clock ticks before CLK FLG went active, and there should have been 131,071 clock ticks. We ran the test program several times and the number of clock ticks was very inconsistent. The OFLO signal from the processor and the IO OFLOW flip-flop go active about 10 us before the processor halts and causes the CLK FLG flip-flop to go active. On each clock tick pin H of the CLK REQ flip-flop goes high and pin J goes low. Pin J is qualified by DONE(1) B from the processor so that the CLK SYNC flip-flop won't go active until the current instruction has finished executing. The CLK SYNC flip-flop goes active nearly immediately after the CLK REQ flip-flop goes active. BK SYNC goes active immediately after CLK SYNC goes active. The BK flip-flop goes active and causes the the CLK RQ flip-flop to go inactive. The INC MB signal that increments the Memory Buffer contents goes active when the CLK SYNC flip-flop goes active. The EXT flip-flop in the processor that gates the external I/O bus into the processor is going active every time there is a clock tick.

We need to study the abbreviated data-break cycle that increments the clock counter. It really looks like the memory data from address 7 is being mangled and causing a short count until the clock flag is activated. This could be related to the problems with the 1/2" magnetic tape controller and the DECtape controller not working.

11/2/22

Section 3.9.4 in the PDP-9 Maintenance Manual describes in detail how the Real-Time Clock should work. We loaded the counter at memory location 7 with a -1, enabled the clock, waited for the clock flag to go on, and halted the processor. There should only be one clock data-break request, the counter will be incremented to zero, and the processor will halt. We actually see many more than one clock data-break request before the processor halts. There are many potential causes for this misbehavior. We might not get address 7 put on the I/O Bus, so the wrong location gets incremented, or the contents of memory location 7 might not be read and incremented.

Schematic page KD5 has the logic that puts 7 on the IO ADDR 15 (B) through IO ADDR 17 (B) signals. We triggered the 'scope on the RUN (1) signal on pin J31J on schematic page KC10(1) going high to indicate that the processor has halted. This should happen after just one clock tick. We can see the IO ADDR 15 (B) through IO ADDR 17 (B) signals go low each time CLK REQ (1)on pin J07H sheet KD3(2) goes active, so at least address 7 is being generated by the I/O controller.

We triggered the 'scope on EXT(1) schematic page KC19, the signal that transfers the I/O Bus to the O Bus. We can see multiple strobes on EXT(1) before a halt. We looked at the O BUS 15 through O BUS 17 signals. About 100 ns after EXT(1) goes active we can see the IO ADDR 15 (B) through IO ADDR 17 (B) signals gated onto the O Bus, and they stay active for 100 ns. So the address 7 is getting from the I/O controller to the O Bus.

About 50 ns after EXT(1) goes active we see a pulse on the 1->MBI signal on pin E23D schematic page KC19(2). We see another pulse on the 1->MBI signal 200 ns later. The second 1->MBI pulse might be worth investigating later. 

We looked at the MBI(1) signal on pin D26N and the 1->MBI signal on pin D26S. About 100 ns after EXT(1) goes active we see 1->MBI go active, and then MBI(1) goes active for 100 ns. About 150 ns later MBI(1) goes active again.

We looked at the MB register bits 15-17. When MBI(1) goes active we should see the address 7 from the O Bus latched into the MB. We see bit 17 get latched for 200 ns, but bits 15 & 16 are not latched. Something doesn't look right here. 

11/5/22

On Wednesday we speculated about why we have found so many component failures recently. One of the ideas was a poor ground on the AC outlets feeding the PDP-9 and it's I/O cabinet. That would have been an easy fix, but unfortunately the power wiring is all correct.

We looked at the 1->MBI pulse to see why it is triggered so much. See schematic page KC19(2). There are 5x signals that are ORed together, including the EXT(1) signal that we are interested in. These are ANDed with SM(1) (Start Memory), RUN(1), and MEM DONE, to make the RQ MBI signal, and then ORed with the IN CLR signal.

We triggered the 'scope on EXT(1) going active high for about 120 ns. That would be the time that CM word 11 was active. Looks reasonable. The OR output was active low for a long time before EXT(1) went active, but went inactive high 200 ns before EXT(1) went active. That doesn't look right. PCO(1) goes active 500 ns after EXT(1) goes inactive. That is probably from CM word 10 starting a new instruction after the clock data-break completed. CAL(1) goes active about 400 ns after PC0(1) goes inactive. We don't have any CAL instructions in the loop, so I don't know why that signal is activating. The PV(1) signal is always inactive low.

I am really confused now. The CP schematic says that the PV(1) signal enters the R012 flipchip in slot F01 on pin N that is part of the KX09 Memory Protect option. There is no flipchip in that slot, and the Memory Protect option is not installed in our PDP-9. The KX09 Memory Protect manual shows no connection to slot F01. The R001 schematic doesn't match the R012 wiring, and the R012 is not described in the KX09 documentation.

We looked at the Delta MB signal on schematic page KC19(2) and the NOR inputs. When Delta MB goes active low the first time, PCO(1) has been active high for 10 us. After that, PCO(1) is inactive most of the time and goes active 200 ns pulses. That looks reasonable. We see CAL(1) go active high about 400 ns before each PCO(1), so that doesn't look right. ARO(1) and EXT(1) are inactive at this time.

We looked at the CAL flipflop on schematic page KC12. We see the CAL flipflop toggling to an inactive state every 1 us even though there is no CAL instruction in the loop. We looked at IRI(1) and can see it go active low when the flipflop toggles. At the time IRI(1) goes active, we also see DEI(1), IR0(0) IR1(0), IR2(0) IR3(0), and EXT(0) go active low.  The DEI(1) is tied to the preset input on the B213 flipchip, so even with inactive inputs the flipflop will still set. Pin F15S is always high which seems strange.

We looked at the IR0 IR1, IR2 IR3, and IR4 flipflops when we executed a JMP instruction. All of the bits were correct on both sides of the flipflop. After looking at the schematic again, it looks like DEI(1) will go on for every instruction and will preset the CAL flipflop.

We went back to looking at the MB register behavior during a clock data-break. We triggered on EXT(1) going high and see SM(1) going low at the same time. We see the Delta MB signal going low just a little later which looks OK. MEM DONE is low at this time. RQ MBI goes active high at the same time as EXT(1) and SM(1) and goes low at the same time as EXT(1). The RQ MBI V IN CLR signal goes high and low coincident with RQ MBI, but also goes active high about 100 ns later for about 25 ns. IN CLR goes active high coincident with the second pulse on RQ MBI V IN CLR. 1->MBI has a pulse coincident with RQ MBI, and again coincident with IN CLR. Since EXT(1) is inactive during the second pulse in 1->MBI it might clear the MB and cause the contents of memory location 0 to be incremented instead of 7. We examined memory location 0 and it is not changed by the program loop.

IN CLR is generated by a very complicated timing chain on schematic page KC16. We will check the signal timing later.

We triggered on EXT(1) going high and looked at MBI(1). MBI(1) goes active low 300 ns after EXT(1) goes high and stays low for 450 ns. The I/O Device Address on the O Bus needs to be stable when MBI(1) is low. O BUS 15, O BUS 16, and O BUS 17. When MBI(1) goes low O BUS 15, O BUS 16, and O BUS 17 are all high. When MBI(1) triggers goes low 500 ns later, O BUS 15, O BUS 16, and O BUS 17 are all high. We ran the loop multiple times and saw MBI(1) go low for 100 ns 75 ns after EXT(1) went high. The O BUS 15, O BUS 16, and O BUS 17 signals were all high at this time for I/O address 7. This looks like the correct behavior. We ran the loop several times and periodically captured a screen without the MBI(1) going low when it should. This inconsistent behavior is what we are looking for. When this is working correctly the contents of the MB stays valid for 350 ns. Next time we need to determine why the MBI(1) signal sometimes does not go active 75 ns after EXT(1) goes active.

11/8/22

We are getting closer to the cause of the clock data-break problem. When a data-break from the clock is granted, a bit in the microcode gates the Word Count address from the I/O controller to the O bus in the processor. This part is working reliably. There is complex circuitry combined with microcode bits that then gates the Word Count address from the O bus into the Memory Buffer register. This sometimes works OK, sometimes it doesn't. That would make the data-break increment the wrong Word Count address in memory, and cause the clock to work erratically.

In the first 'scope image below trace 1 is the EXT(1) microcode bit that gates the data-break address onto the O bus. Trace 2 is one of the data-break address bits on the O bus. Trace 3 is the corresponding bit in the MB register. Trace 4 is the MBI(1) microcode bit that actually gets set by complex circuitry. When trace 4 goes low coincident with trace 2, the data bit gets latched into the MB.

Yellow=EXT(1), Teal=Data-Break Address 1, Cyan=MB 0 (1), Blue=MBI(1)

As shown below sometimes the MB(1) bit doesn't get set, and the data-break address doesn't get latched into the MB. Since this is a very asynchronous machine, there are 6 B310 adjustable delay lines in some really complex Control Memory timing circuitry that eventually should set the MB(1) bit. If the cumulative delay is off by 25 ns or so, the AND gating logic doesn't work and MB(1) won't get set. You will also artifacts where signals get enabled for a short time when they shouldn't. That is probably what is making the spikes on traces 2 & 3.

Yellow=EXT(1), Teal=Data-Break Address 1, Cyan=MB 0 (1), Blue=MBI(1)

What we need to do now is check the Control Memory timing adjustments in the chart below, and look for jitter on any of the clock signals. There are wire-wrap jumpers on the processor backplane that can be changed to adjust the timing of each delay.

I think that we have something in the clock circuitry that is intermittent and is causing jitter in the clock signals. We have had this problem before with the B310 flipchips shown below. The long black devices are inductive delay lines. They have 5 wires on the back soldered to the PCB. Because of the difference in thermal expansion between the delay line and the PCB the solder joints crack and go intermittent. The newer versions of the N310 have the delay lines rotated 90 degrees to the PCB so there is some wire between the delay line and the PCB that can flex and absorb the thermal expansion. We don't have enough of the newer B310 modules to replace them all. We could also have a failing transistor on one of the delay lines, or elsewhere in the CM timing circuitry that is causing the jitter.

11/9/22

When the PDP-9 is first turned on the MBI(1) signal seems to be reliable, and the WC address for the clock is stored in the MB register.

We checked the Control Memory timing on schematic page KC16 and using the PDP-9 System Adjustment Manual.

The CM STROBE A, B, C & D pulses are all about 40 ns long.

All of these delays look close enough to leave as they are.

We looked at the IO RESTART NODE signal on pin CP F32D. We see two I/O RESTART NODE pulses after a CLK pulse. This matches the incorrect setup Figure 20 in the PDP-9 System Adjustment Manual. This means that the pulse from a MEM START and from IO RESTART are not coincident.

Figure 20 I/O Restart, Incorrect Set Up 100 ns/cm @ 5 V/cm

According to section 4.1 of the PDP-9 System Adjustment Manual we adjusted the B301 One Shot Delay in slot I/O H22 (The one that we replaced on 10/5/22) so that the pulses from MEM START and from IO RESTART were coincident.

Figure 21 I/O Restart, Correct Set Up 100 ns/cm @ 5 V/cm

It looks like the short program to test the clock is working reliably now.

We loaded and ran Instruction Test Part 2. This diagnostic tests I/O devices including the clock and interrupts, and it is working!

We loaded MAINDEC-15-D4AF TC-59 Instruction Test and started with test #0. Test #0 through #5 all failed. We have a diag tape from a PDP-15, and the documentation from a PDP-9, so that makes finding the error in the source code challenging. We will have to match the disassembled PDP-15 paper tape code to the PDP-9 listing to figure out what it was doing, and why it failed. That will be the project for Saturday.

11/12/22

We worked on the disassembly of the MAINDEC-15-D4AF TC-59 Instruction Test. The disassembler is not putting the code in the right memory address, so we need to do more work on how the binary loader determines addresses that are embedded in the code.

We single stepped some of the diagnostic code and found that the MTLC command works OK, but the MTRC command loads just zeros in the AC. This could be a problem in the TC59, I/O Controller, or the Processor.

11/17/22

We toggled in a little program to test the TC-59 Command Register and it worked OK. We reloaded and ran MAINDEC-15-D4AF TC-59 Instruction Test. It ran test 0, the IOT Test, and test 1, the Command Register test OK. It stopped on test 2 Data Buffer Bit and Data at address 676. This test writes and reads all possible combinations of the Data Register. We can see it loading Read and Write commands into the Command Register, and must be using the maintenance LDB (707404) and RDB (707402) commands to read and write the Data Register.

The diagnostic is writing the 18-bit word 400000 to the Data Register, and reads it back. The single bit that is on is making it from the Data Register in the TC-59, onto the I/O bus, but not into the AC. We looked at the bit that is on as it travels from the TC-59 to the processor.

Bit 00 from the TC-59 Data Register is on the I/O bus, and all of the other bits are 0 as they should be. The bit is coincident with the IOP 2 signal that the I/O controller uses to read data from external devices. Bit 00 is gated from IO BUS 00 to IO BUS 00 (B) through the R123 Flipchip in slot D12. Bit 00 (B) is on the cable from the I/O Controller to the Processor. We looked at the register gates and registers on schematic sheet KC20(1). We found that coincident with the IOP 2 signal the IO BUS 00 (B) signal was a 1, the ACI(1) signal that loads the data into the AC register was active, but the LIO signal that gates the I/I Bus onto the register bus is not active, it is always inactive high. This would explain why the I/O data does not get into the AC register.

The Maintenance Manual says that the AC RD signal should gate the data on the I/O bus to the O bus and into the AC register. The AC RD (B) signal is present at pin U of the B213 in slot D12. See schematic page KC13. The resulting LIO signals are active coincident with the IOP 2 signal. LIO is also present on the B163 mux Flipchips on schematic page KC20(1,2,3). The I/O data is present on pin E, the O bus, of the B163 in slot B06. The I/O data is present on pin K of the B213 in slot C07. Both the I/O data and ACI(1) are present at the same time at the inputs to the B213. The I/O data is being latched into the B213 in slot C70. There is a second ACI(1) signal 1 us after the first that loads zeros into the AC register. This second pulse should not exist. We have seen this two pulse issue before in other parts of the machine when delay lines are not adjusted correctly. A few weeks ago we adjusted an I/O Controller delay line to get the RTC working. I really hope that we don't end up in a conflict with the optimal delay line settings for the RTC and the external controllers.

After running the two instruction program for a few the processor could not read the Command Register in the TC-59. Maybe accessing the TC-59 every 5 uS warmed up a component so that it misbehaved? Time to go home for the day.

11/23/22

We will pickup where we left off last Saturday, but this time we will run the processor in Single Instruction mode with a repeat of about 5 instructions per second. If something is heating up in the I/O Controller running it slower should reduce the power consumption and heating significantly.

Triggering on IOP 2(1) in the I/O Controller we can see I/O Bus 00 (B), but no LIO signal to gate the I/O data onto the O Bus. After running for a few minutes we can now see two LIO pulses, one in the middle of the IOP 2(1) pulse, and another 1 us later. We can see the I/O Bus 00 (B) data on the O Bus when the LIO signal is active. The ACI(1) signal is active during both LIO pulses. During the first LIO pulse the ACI(1) signal is active for 2 us, and during the second LIO pulse the ACI(1) is only active for the same duration as the LIO pulse of 100 ns. This will load the I/O Bus data into the AC, and then load zeros into the AC. There are no ACI signals generated from the microcode, so the behavior is only controlled by the 1->ACI signal, which looks like it is generated from the AC RD signal. See schematic page KC19(2). The LIO signal is also generated from the AC RD signal. See schematic page KC13. The AC RD signal on pin E36D looks like the output of a pulse amplifier and is active at the same time as the LIO signal.

The AC RD signal is sourced from the I/O controller. See schematic page KD3(3) section D3. One of the inputs to the AC RD signal is CLK DLY'D which comes from the B301 that we replaced and adjusted according to the System Adjustment Manual.

We triggered on the signal that makes AC RD on Pin N of the R111 NAND gate in slot F19, and looked at RD RQ(B) on pin K, IO 1 (1) on pin L, and on pin M which had the dioded CLK DLY'D signal. RD RQ(B) is always active, IO 1(1) goes active 500 ns before the first RD RQ pulse, and there are four CLK DLY'D pulses, two before IO 1(1) goes active, and two after. This explains where the double AC RD pulses are coming from. We also need to investigate why RD RQ(B) is always active.

Yellow=AC RD, Teal=RD RQ(B), Cyan=IO 1 (1), Blue=CLK DLY'D

When the processor is running at full speed we can see the CLK DLY'D signal pulsing every 1 us, an the IO 1(1) signal go active for 2 us, which lets two pulses through and makes two AC RD pulses. RD RQ(B) is always active. Maybe this is broken, and this is why two pulses are getting through the R111 flipchip. We looked at the RD RQ and INT RD RQ BUS signals on pins R and S of the R111 in F19. RD RQ is always active high, which will make RD RQ(B) always active. The RD RQ signal comes from the TC-59, so maybe the Magnetic Tape Controller is causing the problem.

See schematic TC59-2. We looked at READ RQ signal on pin J of the R123 NAND gate in slot F31. It is always active high. CM->I/O BUS is inactive high and STATUS->I/O BUS is inactive high. We looked at the R123 in slot F26. READ is always active low and DATA EN B(1) is always inactive high. Either the R123 in slot F31 or the R123 in slot F26 is driving the READ RQ when it should not. We replaced the R123 in slot F31 and later F26 with an unknown spare and there was no change to the READ RQ signal.

11/26/22

We missed a source of the READ RQ signal in the TC-59. It is on page 1 of the schematic in section C4. This generated by the RDB instruction that we are using for the test. The PDP-9 Interface Manual includes timing diagrams that show the RD RQ signal in the I/O Controller only being active during IOP 2 and possibly delayed by 500 ns by cable delays.

We should check the RDB pulse from the W103 data selector flipchip in slot EF12 pin EL, schematic page TC59-3. It should be just a positive going pulse when the RDB IOT instruction is executed. The RDB pulse goes to the W640 pulse amplifier in slot F30 and makes the DB->I/O BUS (00-09) and DB->I/O BUS (10-17) negative going pulses, schematic page TC59-2(2). The DB->I/O BUS (10-17) pulse goes to the R107 inverter in slot F28 and then to the R002 diode in slot F25 to make the READ RQ high signal, schematic page TC59-1.

We checked the +10VDC and -15VDC voltages on the TC-59 backplane. Both were within specification.

We looked at the RDB signals on pins L & M of the W103 in slot EF12. When the the machine is not running pin L is inactive low, and pin EM is inactive high. When an RDB instruction is executed there is a 150 ns pulse on pins L & M. There is a 3 us pulse on pin FD for the SELECT signal. We looked at the W640 pulse amplifier in slot F30 that takes the RDB signal and makes the DB->I/O BUS (00-09)and the DB->I/O BUS (10-17). The DB->I/O BUS (00-09) signal on pin U has a 1 us negative going pulse, but the DB->I/O BUS (10-17) signal on pin H is always inactive high. We replaced the W640 in slot F30 with an unknown condition spare. That fixed the problem with the DB->I/O BUS (10-17) signal, but the TC-59 still fails diagnostics.

The DB->I/O BUS (10-17) signal on pin P of the R107 inverter in slot F28 has a 1 us negative going pulse, and the output on pin N has a 1 us positive going pulse. This signal then goes to pin D on the R002 diode in slot F25 and comes out of pin F to make the READ RQ signal. The READ RQ signal is always active high. We checked all of the diodes on the R002 board and they are OK. We left the R002 board out, and the READ RQ is still always active high, so that is not the source of the problem.

We looked at the R123 flipchips on schematic page tc59-2.  We pulled the R123 in slot F31 and then in F26, and the READ RQ signal stayed active high. We removed I/I Bus cable in slot E02, the R002 and the two R123 flipchips and measured the resistance from pin F25F to ground. The resistance is megohms so there is probably no other flipchip on that signal. We added a 10k Ohm pulldown resistor to -15V on the READ RQ signal and powered the PDP-9 on. The READ RQ signal went to -15V. We added the R002 flipchip and the signal went to -5V when powered on. We added the two R123 flipchips and the signal stayed at -5V. I imagine that the pulldown to the inactive state for the READ RQ signal is in the I/O Controller so the signal would be inactive without I/O cables plugged in.

Yellow=RDB, Teal=RDB, Cyan=SELECT, Blue=READ RQ

MAINDEC-15-D4AF TC-59 Instruction Test passed tests 00, 01, and 02, but failed the Data Channel Transfer Test. The ADDRS of 001550 is the starting address of the test that failed.

We ran the MAINDEC-15-D4AF TC-59 Instruction Test starting at test 00. It passed the IOT Test Part 1, Command Register Test, and the Data Buffer Bit Test. It started the Data Channel Transfer Test and hung. The PC contained 01572 when stopped. That memory location contains 777777 which might be a LAW instruction to load the AC with all ones. We did a single-step and the MB contained 703302 and the PC contained 01561. Maybe memory location 01560 is supposed to be a 707302 RCM instruction and we dropped a bit? We changed it to 707302 and it didn't change the behavior.

We looked at the SET DATA FLAG signal on pin EE of the W103 in slot EF12. When we run test 03 we can see a positive going pulse so we know the test is trying to force a data-break. We see DATA FLAG(1) go active high 50 ns after SET DATA FLAG, and go inactive 4 us later. We see DATA REQ(1) go active low 3 us after SET DATA FLAG and go inactive 1 us later. We see CCH GRANT to active low 4 us after SET DATA FLAG, so this is what is clearing  DATA FLAG(1) and DATA REQ(1) by generating the CLR DATA FLAG signal.

We zoomed out on the 'scope and see can see 23 of the above sequences at 42 ms intervals, and then DCH REQ goes inactive but DCH GRANT stays active. It always fails on the 23rd data-break 1.2 ms after the pattern starts.

Memory location 32, WC, contains all zeros, and memory location 33, CA, contains 32. The zero WC should stop the data-break. The 32 in the CA would do data-break  transfers to the WC. That doesn't sound like a good idea. Time to finish disassembling the diagnostic to see how it works.

11/30/22

The 703302 in location 01560 was a CAF instruction that we changed to a 707302 RCM instruction. We changed it back to a CAF instruction.

After looking at the I/O controller schematics we can see that there are three pull-down resistors on the RD RQ signal on two W005 Flipchips. The W005 has a 3k Ohm pull-down resistor to -15VDC and a diode clamp to -3V. There was some oxide on the fuses and margin switch #5 so the -15VDC was not getting to W005 Flipchips in I/O slots H19 and F17 on schematic page KD3(3). We wiggled all of the fuses, and switched the margin switches back and forth to clean the connections.

Now TC-59 tests 00,01, and 02 run OK, but it hangs on test 03 Data Channel Transfer Test. The PRGM STOP light is not on, so the processor is still in the run state even though there is no indication that the processor is executing instructions.

The EXT flip-flop gets set by Control Word 11 when a Data-Break starts. When we start test #03 we can see EXT go active about every 50 us. That is reasonable considering the number of instructions that are executed to setup for the Data-Break. When the processor hangs, the Data-Breaks are executed every 3 us, so no instructions are executed. Memory location 32 contains 777777 which is a -1 so just a single Data-Break transfer will be executed before overflow is indicated and stops the transfers.

We can see the DCH RQ then DCH GRANT then BK SYNC then EXT sequence for the first few Data-Breaks. Then DCH RQ and DCH GRANT go inactive, BK SYNC stays active, and the processor gets stuck in the Data-Break loop. With BK SYNC always active the processor will always execute Control Word 11 for a Data-Break instead of Control Word 10 to execute a normal instruction. BK SYNC comes from the I/O Controller, so time for some investigation there.

During the first few Data-Breaks we only see DCH SYNC(1) go active high. After a while both API BK RQ(1) and DCH SYNC(1) are always active, so BK SYNC is always active low which hangs the processor. Since we don't have the API option the API BK RQ(1) signal may be floating high when DCH SYNC(1) goes active.

We triggered on BK SYNC going active low and looked at DCH SYNC(0) and DCH SYNC(1). After 23 Data-Breaks DCH SYNC(0) and DCH SYNC(1) hang in the active state. It looks like the output of the Pulse Amplifier in slot J09 is what clears the DCH SYNC flip-flop. Pin V on the Pulse Amplifier is always inactive low. The WR RQ signal on pin R on the Pulse Amplifier pulses active high 12 times, and then the INC MB signal on pin T pulses active high 10 times, and then the flip-flop stays active.

We looked at the WR RQ(B)\ signal on pin H of the S107 inverter in slot H09, and it is always inactive low. We looked at the BK 1(1) signal on pin P of the S107 inverter in slot H09, and it is always inactive low.

We looked at the BK 0 flip-flop pins H & J and they toggle about the same time as BK SYNC goes active. We looked at the BK 1 flip-flop pins S & T and they are inactive. We swapped the S202 in slot J19 for two different unknown R202s, and there was no difference in the behavior of BK 1.We looked at the IO CLK POS, BK 0(0), and BK 0(1) inputs to the BK 1 flip-flop. IO CLK POS goes active high every 1 us. BK 0(0), and BK 0(1) change state just after BK SYNC goes inactive high. BK 0(1) was not active when IO CLK POS was active so BK 1 will not set. We ran the diag several times and captured an instance where there were only three DCH 1 pulses and they did line up with BK 0(1) so BK 1 should have set. Now we can see BK 1 set, but the processor still hangs.

We looked at the BK 1(1) input on pin P of the S107 inverter in slot H9. We can see the signal go active high for 2 us, 2 us after BK SYNC goes active. We looked at the output on pin N and it is always inactive high. We replaced the S107 inverter with a unknown spare, and there was no difference in the behavior. Something is grounding the output of the S107 inverter. Maybe a shorted input on the S107 inverter in H5? We replaced the S107 inverter in slot H5 with an unknown spare and there was no difference in the behavior. We will start with this on Saturday.

12/1/22

The outputs of the S107 inverter in slot H09 are open collector. For the combined N & F outputs of the S107 to go active low, both the P & H inputs must be active high. When this happens the signal will propagate through the S107 inverter in slot H05, then to the S602 pulse amplifier in slot J09, and finally clear the S203 flip-flop in slot H07 for the DCH SYNC signals. We need to determine if the data-break writes are working, but the data-break reads are not. We need to get good disassembled output of the TC-59 Instruction Test so we can see exactly what the diagnostic is doing when it fails.

12/3/22

We fixed the bugs in the PDP-9 Disassembler and were able to get a good source listing of the MAINDEC-15-D4AF TC-59 Instruction Test. We guessed that setting switch #7 when we ran the diag would enable the mode where it halted before and after a test. That turned out to not be true. The diag executes the instruction at 07317 before and after a test. This is currently a CLL instruction. We will change it from 744000 to 744040 which is a CLL!HLT. This should cause the halts before and after a test. When the diag was started at 00200 it changed location 073017 back to a 744000. We changed it back to a 744040 and started the diag at 01232. The diag halted at 01245, when it executed the XCT DSCOPE instruction. Now we can run individual sub-tests in the DCHCTS test, follow the diag through the test sequence, and see what works and what causes the processor to hang.

The diag successfully executed TC-59 Write, Read/Compare, Space Forward, and Space Reverse tests starting at 001412. Then it tried TC-59 Read tests starting at 001550. The first of the Read tests hung the processor in the Data-Break loop.

We triggered the 'scope on DCH RQ on pin J of the S203 in slot H07, and looked at DCH SYNC(1), BK 1(1), and WR RQ(B)\. The WR RQ(B)\ should have been active high, but was inactive low when the TC-59 Read command was executed. We looked at the WR RQ\ and WR RQ(B)\ signals on pins M & L of the S107 in slot H09. Both signals were low, so the inverter was not working. We measured the voltage drop on the 2N3639 transistors on the S107 and found that Q4 for output L was completely open. We replaced the transistor with a NOS spare and now DCH SYNC clears when BK 1(1) and WR RQ(B)\ go active.

The processor will now execute the first of the TC-59 Read tests without hanging. Unfortunately the second Read test hung the processor.

It looks like the circuitry that increments the WC and the CA got left on after the TC-59 Read command was executed. The contents of the memory locations after the data-break executed are +1 from what they should be. That really messed up the execution of subsequent Read tests.

We reloaded MAINDEC-15-D4AF TC-59 Instruction Test and started it at the beginning. It ran tests 00, 01, 02, 03, and failed on test 04 IOT Test Part 2. It looks like it wants the TU20 tape drive connected and ready. Since the drive isn't connected it died. We will declare victory and try booting ADSS from DECtape.

Well, that didn't go as planned. The processor hangs when running the ADSS bootstrap. We poked through the memory and the TC-59 diag was still in memory. We tried the bootstrap again and ADSS booted!

This is the console output after booting ADSS, the ADVANCED Software System and running a previously compiled FORTRAN IV Hello World program. The KM9-15 banner means that support for both a PDP-9 and a PDP-15 are included in the monitor. We would have a little more usable memory if we ran the System Generator and removed support for the PDP-15. This is V5A of ADSS. We have booted V4E, which uses a little less memory, but none of the software development tools will run. There seems to be a problem with the V4E System Loader that we need to debug.

GLOAD is the command to invoke the Linking Loader, but to have the resulting executable binary program loaded into memory and run, instead of being saved for later execution. The "_" in front of "HELLO" is a <- character and the "~" is an ALT-MODE or ESC character when a Teletype is used for the console instead of a VT220. At this point the Linking Loader scans the libraries for the required routines, adds them to the HELLO program, and then runs the program.

Because this machine only has 8kW of core memory we need to use the small versions of the FORTRAN compiler and MACRO assembler. That means we need three DECtapes, one for ADSS, one for the source code, and one for the resulting binary file.

12/7/22

We have some projects to complete, like making cables for the TC02 display, making I/O cables so we can have the TC02 and the TC59 connected at the same time, fix the paper tape punch, fix light #6 on the Console Register display, add the EAE option, add the 34H graphics option, make a disk drive emulator, and write a DECtape device driver for UNIX V0 so we can run it on this system.

We need to look at the duration of the DCH BK DLY in pin M of the R302 One Shot Multivibrator in I/O slot A24 that is trigered by the DCH GRANT P signal on pin E. When we looked at the The DCH BK DLY signal a while ago it went low for 40 us. Schematic page KD3(1) says that it should go low for 100 us, so it is on long enough to illuminate the lamp on the console. According to the schematic, the wiring of the R302 is for a fixed delay so the trimpot should not have any effect on the on time. We need to verify that pin J is jumpered to pin L as in the schematic, or is really jumpered to pin K so the trimpot will work. The schematic says that there is an external 0.02 uf or 20 nf or 20,000 pf capacitor connected between pins H & J, and an external 1k Ohm resistor connected between pins J & L. That makes the total capacitance 20,220 pf and the total resistance 2k Ohms, which the DEC Logic Handbook says should make the delay 40 us, which is what we observed. With the 20,220 pf of capacitance we need about 4.9 kOhms of resistance to yield a 100 us delay. We could try replacing the external 1k Ohm resistor with a 4k Ohm resistor to increase the on time for the indicator, or we could change the jumper between pins J & L to pins J & K so the trimpot works. Then we can adjust the trimpot to 4k Ohms to get a 100 us on time.

The Register indicator lamp for bit 6 has been intermittent for years. Usually tapping on the console or wiggling flexprint cable #29 fixes the problem for quite a while. The indicator has failed solidly so we need to fix it. All of the indicator lamps are on a single PCB. Unfortunately the lamps are #1762 grain-of-wheat style. They have really tiny wires from the lamps that get soldered into the PCB. The probability of damaging a lamp during removal and reinstallation of the PCB are very high, so this should be a really fun project.

12/10/22

The PDP-9 is still runing!

The DECtape drive above the Paper Tape reader won't drive to the right, but will drive to the left. We will look at that Wednesday.

The indicator lamp for Register bit #6 has been intermittent for years and finally failed. With much trepidation we removed the panel that holds all of the lamps for the front panel. We found black rings in the solder joints for several of the connectors for the flexprint cables that go to the I/O controller. We removed the old solder and resoldered all of the connector pins. We connected a current-limited power supply to the lamp board and powered up the panel with the voltage reversed. This will force all of the switching transistors on the panel to turn on so we can test the lamps. All of them worked! We replaced the panel and now the Register #6 lamp is working again.

The DATA lamp that indicates that a Data-Break is in progress has never worked. The schematic says that the signal that turns on the lamp should be on for 100 us. We checked the wiring, and it is correct. The way it is wired the signal should only be on for 40 us, and that is the duration that we measured. We need to insure that the signal is getting to the switch transistor on the lamp board. The flexprint cable for the DATA signal is in poor condition, so it is possible that the signal is not getting to the lamp board. If it is, we will try lengthening the on-time for the signal to give the lamp more time to turn on.

12/14/22

Check that the DATA signal is getting to the switch transistor on the lamp board and that the lamp is getting turned on. If it is, increase the external resistance on the R302 one-shot to increase the on-time for the lamp signal.

Swap the G850 boards for the left and right motors in the TU55 in the processor cabinet to see if the no-drive condition moves from the right hub to the left hub. We have no working spare G850 boards and lots of broken ones.

We need to determine how to get FOCAL to run from DECtape so we can make more demonstrations.

We tried the V5A 7/1/70 tape that includes FOCAL.BIN. We tried to load FOCAL using the GLOAD command. It read FOCAL.BIN from DECTAPE #1, then scanned the libraries on DECtape #0, then printed .LOAD 1, then rebooted. The .LOAD 1 error means that the loader ran out of memory building the symbol table. It is possible that we can't load-and-go FOCAL because it is so large, it takes 23 DECtape blocks. Each DECtape block hold 256 (decimal) 18-bit words, so the FOCAL.BIN file is about 5,888 words. With the ADSS monitor and the LINKER in memory there many not be enough room for FOCAL and the needed library routines. We will try this on Simh with a 16k PDP-9 to see if it will load-and-go.

We tried the V4E 2/20/70 tape. It looks like the DATs for the LOADER and SYSLOADER were never set to DTA0, so it reports an IOPS 4 DATA error when you try to run a program. Running SYSGEN would fix this. We also noticed that the Monitor restarts, but does not reload when you enter a ^C. We looked at the system configuration, and noticed that DECtape, Magnetic Tape, Disk, and Drum storage are configured, as well as a Line Printer and Punched Card Reader.

We tried to GLOAD STAR1 (Star Trek) and got a .LOAD 1 Memory Overflow error. Again, it probably won't run on an 8k PDP-9. We will also try this on Simh on a larger memory PDP-9.

We looked at the right hub motor problem on the TU55 in the Processor cabinet. The G850 FlipChip for the right motor is missing. We forgot that we borrowed it on 10/15/22 to fix the TU55 in the top of the I/O cabinet. We have no working spares, so it is time to fix some.

We picked up some A601 and A604 FlipChips from the warehouse so we can eventually populate the 34H Oscilloscope Display option. We need and have the following FlipChips for the 34H:

We looked at the G850 SRC Motor Driver from the TU55 DECtape. The Motorola MDA 943-5 diode bridge has a shorted diode. The 2N4443 SCR  has a gate to cathode short, probably caused by the failed diode bridge. We started by replacing the D664 diode D20 because it looked shorted. We kept the original because it was actually OK.

12/17/22

We observed the behavior of the console lamps when booting ADSS from DECtape. The DATA light is working, but it is very dim. When we loaded PIP the LINK light flickered, probably every time it found a new DECtape block when searching for PIP. When it found the program the DATA lamp illuminated dimly for a short time while it loaded PIP from the DECtape. We copied a DECtape from one drive to another and the DATA lamp did not illuminate enough to see. Maybe we should change the external resistor on the R302 in slot A24 from a 1k Ohm to a 4.7k Ohm. That would increase the on time for the DATA lamp from 40 us to 100 us as noted on the schematic page KD3(1).

We only have one bootable ADSS DECtape. The others have developed read errors. We reformatted one of the non-working DECtapes and used PIP to copy bootable the DECtape to the freshly formatted DECtape using the (S) option. This copies all of the system files, and then copies the user files. We had several failures due to reading the bootable DECtape, and eventually had a directory reading problem. We will make new bootable tapes on Mike's PDP-8/e.

We had lots of visitors today so we didn't get much else done.

12/18/22

I did some digging on running the FOCAL language interpreter on this system. There are several different versions of FOCAL for the PDP-9 and PDP-15. There is a stand-alone version that loads from paper tape, a DECtape version, a Disk version, and a 2 or 4 user Foreground-Background version. If the system has more than 8k of memory and DECtape the FOCAL.BIN file is loaded with the GLOAD command. Our system only has 8k, so we need to load the FOCAL.XCT file with the EXECUTE command. FOCAL and EXECUTE need specific device assignments so the command sequence to run FOCAL is:


$A DTE0 -1, -4/DTE1 3, 5, 7, 10

$E FOCAL

This works using a Simh simulated 8k non-EAE PDP-9, but the math functions don't work. Enabling EAE gets math working. This is curious because other versions of FOCAL run OK without EAE.

I looked through the source code for FOCAL 9A, the one that we have in EXECUTE format. It looks like it can be built for the PDP-9, PDP-15, or both the PDP-9 and PDP-15 by setting definitions in the code. The version that we experimented with says "FOCAL V9A" when it starts, so that means that we have the PDP-9 and PDP-15 version. The FOCAL code does not contain any EAE instructions. FOCAL uses the FORTRAN IV math library. Now the question is why is FOCAL using the version of the FORTRAN IV library that needs EAE instead of the non-EAE library? Can we make a new FOCAL.XCT file that uses the non-EAE library using the CHAIN command?

12/21/22

We replaced the external 1k Ohm resistor across pins J & L of the R302 Delay FlipChip in I/O slot A24 with a 4.7k Ohm resistor. The resistor and Termipoint connectors came from the donated DEC field service kit. This lengthened the on-time for the DATA lamp on the console from 40 us to 100 us. The lamp is much brighter now, and you can see a lot more indicator activity when the DECtape is being used. 

The original external Resistor and Capacitor on the R302 Delay FlipChip in I/O Slot A24. This pair set the on-time to 40 us and barely lit the DATA lamp on the console. The schematic shows the delay as 100 us. The DEC Logic Manual has examples of possible R-C pairs and the resulting on-time. Keeping the original 0.02 uF capacitor and using a 4.7k Ohm resistor changes the on-time to 100 us, as in the schematic. This works much better.

Since this machine only has 8k of memory we cannot run the full sized FORTRAN IV compiler, MACRO assembler, and FOCAL interpreter. We can run the "abbreviated" FORTRAN IV compiler and MACRO assembler, and the Execute version of the FOCAL interpreter. We tried the CHAIN command that is used to build small memory versions of programs by breaking them up into overlays. The ADSS manuals that we have are probably for ADSS V4E and we are running ADSS V5A. The way that you interact with CHAIN is very different than what is in the manuals that we have. We have the source code for V5A of CHAIN, so we will have to go through the painful process of making our own documentation.

12/24/22

We looked at the FlipChip & ribbon cable assemblies that we need for the status indicators on the TC02 DECtape controller. They have W018 Flipchips on one end and W023 FlipChips on the other end. The W018 FlipChip is a W020 FlipChip with all of the 1.5k Ohm resistors replaced with D664 (1N3606 75V 2mA or 1N914 100V 4mA) diodes so that all of pins can be used for status indicators. The Wo23 FlipChips normally have pins A & B disconnected so they don't connect +10VDC and -15VDC to the ribbon cable. Power is not run to the slots for the W023 FlipChips so jumpers need to be added for pins A & B so they can be used for status indicators. We have a selection of W series prototyping FlipChips that we can use to make indicator cables. The W990 has split terminals wired to all connector pins. We soldered the wires from a ribbon cable to the split pins and used double-sided adhesive tape and a cable tie to hold the ribbon cable to the FlipChip. We used a W998 that has the whole board drilled in a 0.1" pattern of holes and all connector pins wired to pads. We soldered diodes to the pads and to the wires of the ribbon cable. We had lots of Fairchild FDH400 diodes, and since these are just for powering indicator lamps we decided to use these diodes instead of D662 diodes. When I went looking for ribbon cable to use I found two indicator cable assemblies for a TC02 DECtape controller. One looks OK as is, one needs an additional ribbon cable.

We installed the indicator cables and found that the lamp for Data Buffer 12 doesn't work. Changing the lamp made no difference. The TC02 DECtape manual does not include a schematic for the indicator board. The same board is used in the TC59 and that manual includes a schematic. The DEC6534 transistor had an open collector which would explain why the lamp did not work. We replaced it with a NOS spare, and now the lamp does not turn off. We ordered some replacement MPS6534 transistors and work on this again Wednesday. On the TC59 Data Buffer lamp 14 does not work, so we need to fix that 18-bit indicator board too. We also ordered some 600V 1.5A bridge rectifiers so we can repair the G850 SCR Drivers in the TU55 DECtape drive.

12/27/22

Frank Pascucci donated some DEC spares that we can use to maintain the PDP-9.

I put the DEC6534 transistor in the correct way this time and it works OK. The Motorola and Fairchild parts have different indicators for where the Base lead is. That fixed the problem with the lamp for Data Buffer 12. Now it looks like Data Buffer lamp 3 is always on. We will debug that on Saturday. There is also a problem with the lamp for Data Buffer 14 in the TC59 Magnetic Tape controller that we need to fix.

12/31/22

The PDP-9 is running OK and of course the TC02 Data Buffer 3 indicator is working fine today.

We looked at the three broken G850 boards from the TU55 DECtape drives. The transformer that feeds pins U & V makes 46VAC. We are getting some weird interaction between the source of the 46VAC for the trigger circuit and the 'scopes ground, so we see sine waves where we should just see signals.

Lots of visitors today, so not much time for debugging.

Our last work day this year, and time to start the 2023 restoration blog.

To the 2023 Restoration Blog.