DEC PDP-9 Restoration

12/22/12

We removed the 709 power supply and checked for physical damage. Everything looked OK.

We reformed all of the capacitors in the power supply because it had not been powered on in a long time.

This is a process were a power supply is voltage limited to a little less than the rated voltage of the capacitors

and is current limited to about 20mA is connected to the capacitors. The voltage on the capacitors will build to

the set voltage over several minutes. Once this is completed the oxide insulating layer is rebuilt in the capacitors

and the will work OK. If you just turn on the power supply you will likely damage the capacitors.

We also reformed the electrolytic capacitors on the boards in the core memory system.

Click on the image for a larger view.

We used a power supply current limited to 20mA to reform the capacitors.

We attached a resistive load to the power supply and measured the output voltages. All looked OK.

The fan was sticky so we sprayed some WD40 in the end bearing to free it up.

It is noisy, but it works OK a few seconds after it is powered on.

Eventually we will need to disassemble the fans and lubricate them with oil.

We reinstalled the power supply and connected the AC wires.

We connected 110VAC to the power cord to the 841A power controller.

We could control the power state with the power switch on the console.

We connected the remaining red/white AC wires to the 709 power supply and found that all of the chassis fans work OK.

Some of the fans are noisy so may have to disassemble all of the fans to lubricate them with machine oil.

1/19/13 update: I was able to buy two NOS Howard fans on eBay. They have the same motor, but difference fan blades.

We can probably transfer the blades from a worn out PDP-9 fan to one of the new motors.

Click on the image for a larger view.

It looks like the distance between the mounting holes is 4-1/8".

Click in the image for a larger view.

A close-up of the fan motor.

The second 709 power supply is missing the fan. Let us know if you have a source for replacements.

The hour meter runs and we add a few tenths of an hour to the 40,163 hours already on the system.

That is 20 years of 8 hours per day of run time.

We connected the DC wires to the 709 power supply.

It looks like the system was designed to have two of the 709 power supplies.

The connections to the other non-installed power supply are jumpered.

We turned the power supply on for a few seconds at a time and measured the voltages on the chassis test points.

The voltages looked OK and some lights on the console turned on.

We didn't smell anything burning and left the power on.

Warren measured the temperature of the modules in the system and found just a few above the ambient temperature.

Click on the image for a larger view.

We tried the basic Examine/Deposit functions, but did not get the expected response.

We can turn the PRGM STOP light on and off with the I/O RESET and START switches.

With the REGISTER DISPLAY switch in the API position the REGISTER lights flicker.

The rate of the flicker can be controlled with the REPEAT SPEED switch.

We connected the AC power to the paper tape reader/punch.

The punch motor didn't turn on with the AC power to the system.

We need to check the power switch on the front of the punch.

It looks like reader/punch has been modified and gets some of it's power through

additional wires, and some through the signal ribbon cable.

We will need to investigate this further.

Later this week we will do some basic debugging to see if any of the processor is working as expected.

12/28/12

We explored the Margin Power Supply control panel today because the voltage gauge was not working.

We found that the contacts in the wafer switch were really dirty.

We disassembled the switch, cleaned the contacts, and reassembled everything.

Of course our efforts didn't fix the voltage gauge.

Click on the image for a larger view.

The rear of the dissasembled Maintenance Panel.

Click on the image for a larger view.

One of the maintenance switch wafers before cleaning.

We traced the connections from the voltage gauge, through the wafer switch, and through the wiring harness.

The margin voltage sense wires terminated in a 2x3 contact connector mounted to a metal panel.

It turns out that the margin voltage sense wires get daisy chained from the CPU, to the TC59, to the TU20.

There was a cable to interconnect the margin bus from the TC59 to the TU20.

The "out" connector in the TU20 had a "loopback" plug plugged in.

We can't find the margin sense harness that goes from the CPU to the TC59. We should have it somewhere.

We plugged the loopback plug into the CPU margin connector and now the margin voltage gauge works.

At the same time we looked for the I/O bus cable that goes from the CPU to the TC59.

We should have it, but it is missing somewhere in the warehouse right now.

We repaired two of the partially delaminated flexprint cables for the front panel.

We need to replace one flexprint with some ribbon cable so the rest of the lights on the front panel will work.

We connected the I/O cables and DC power cables to the paper tape reader/punch.

The punch motor runs when you push the feed switch.

The capstan for the punch does not advance because it is binding.

We need to disassemble the punch to clean and lubricate it.

The reader does not advance when you push the feed switch.

That will need some debugging because the controller actually controls the stepper motor.

12/29/12

Decided to look at why the Program Stop switch does not turn on the PRGM STOP light.

See page D-BS-KC09-A-10 Clock, Run, and Display (Sheet 1).

The PWR OK\ signal on pin L, and the CLK signal on pin D of the R409 in slot J22 look OK. (section D7 on the schematic)

The PWR OK\ goes active 150mS before the -15V is in regulation.

The CLK POS signal from pin F of the S603 in slot J23 is active when the RUN flip-flop in slot J31 is on. (section D6 on the schematic)

The KSP (Key Stop) signal going into the D pin of the R111 in slot J27 is active when the STOP key is pressed. (section C3 on the schematic)

The buffered KSP (Key Stop) signal going into the S pin of the R111 in slot J28 is active (-4V) when the STOP key is pressed. (section C3 on the schematic)

The R pin of the R111 in slot J28 is 0V. (section C3 on the schematic)

The L pin of the R111 in slot J28 is 0V.

The DONE(1) sognal on the K pin of the R111 in slot J28 is 0V. This indicates that the core memory cycle is not done.

The RUN(0) sognal on the N pin of the R111 in slot J28 is 0V when the processor is not running.

It turns out that the instruction didn't finish execution, so DONE(1) is not active, so the Program Stop switch is not enabled.

The I/O RESTART signal on pin D of the R002 in slot F34 is always low.

The CM CLOCK signal on pin U of the B105 in slot H22 is active.

The CLK POS signal on pins D & F of the R002 in slot J34 is active when the processor is running. (1MHz)(section C5 on the schematic)

The CM CLK signal on pin N of the B602 in slot H33 is active when the processor is running. (1MHz)(section C5 on the schematic)

See page D-BS-KC09-A-16 CM Timing.

The CM CLK signal on pin R of the R111 in slot E22 is active. (section C5 on the schematic)

The SM(1) signal on pin S of the R111 in slot E22 is high, so the CM CLK signal will not get to pin U.

The AM SYNC BUS(0) signal on pin P of the R002 in slot E21 is low (-4V).

12/30/12

We looked at the signals that select addresses in the Control Memory.

Since the processor is not running we set the Maintenance Panel in Deposit and turned repeat on.

Speed = 4 = 150 uSec repeat rate.

Maintenance = Examine.

Repeat = On.

See page D-BS-KC09-A-16 CM Timing.

The signals IN CLR and CLR are active (high) when the Deposit, Deposit Next, Examine, Examine Next, and I/O Reset keys are pressed.

The signals CM STROBE A, B, C, & D are all active. (section D3 & D2 on the schematic)

We found that the CM CURRENT signal was two 50ns pulses where it should have been a single 80ns +25ns/-0ns pulse. (section C2 on the schematic)

The pulses coming from the B105 module in slot F28 (section B3 on the schematic) looked OK.

The pulse from the B105 module is wire-Ored with the 25ns delayed pulse from the B310 module in slot EF29.

So, the B310 delay module is about 12ns slow and the two pulses are not merged.

Click on the image for a larger view.

The upper trace is the CM CURRENT signal (broken). The lower trace is the EAE STROBE DLYD signal.

We replaced the B310 with a spare module and now the CM CURRENT pulse is about 85ns. This is OK.

These signals are inverted.

Click on the image for a larger view.

The upper trace is the CM CURRENT signal (working). The lower trace is the EAE STROBE DLYD signal.

These signals are inverted.

See page D-BS-KC09-A-17 CM Addressing.

We looked at the CMP 0-3 & CMG 0-3 signals. (section D5 & D6 on the schematic)

There is what looks like a voltage as a result of the CM current pulse on all of these signals.

We thought that maybe there were shorted diodes on the G210 that would enable all of the outputs.

All of the diodes on the G210 tested OK.

The input and output signals on pins D & E of the B105 in slot H21 were complementary.

Next Saturday we need to determine if only one CM line is being activated.

We also need to see if the CM address starts at 0, then goes to 1, then to the rest of the Deposit cycle.

01/05/13

See page D-BS-KC09-A-16 CM Timing

We looked at the CM CURRENT signal in section C2.

The signal went low when when the Deposit, Deposit Next, Examine, Examine Next, and I/O Reset keys are pressed.

See page D-BS-KC09-A-19 CM Sense Flip-Flops (Sheet 1)

We looked at the 0->CMA signal in section C7.

It goes low at power up or when the Deposit, Deposit Next, Examine, Examine Next, and I/O Reset keys are pressed.

The PK CLR signal in section C5 has the same behavior.

We looked at the 0 and 1 outputs of the CMA 0 Flip-Flop in section C6.

Both outputs were at ground level.

There was no -15V on the B pin of the module.

We eventually traced the problem to a dirty 04 margin switch.

When the -15 was restored to the Flip-Flop it worked correctly.

With the CM sense Flip-Flops working we started seeing some signs of life in the system.

The address set in the switches gets copied to the ADR register when the EXAMINE switch is pressed.

A lot of the system has to be functional for this to happen.

When the system is powered on all of the CM Sense Flip-Flops are cleared by the 0->CMA and PK CLR pulses.

When the EXAMINE switch is pressed the KIOA signals are set to 3.

When the CM CURRENT signal is activated the CM data at location 01 is read.

The CM STROBE * signals latch this data into the CM Sense Flip-Flops.

The ADSO, MBI, and SM bits in the CM data are set so the Address Switch contents are gated to the I/O Bus (B).

Then Address Switch contents are gated to the O Bus, and then to the AR Register and the MB register.

The next CM address from the contents of 01 is 25.

The CM content turns on MBO, ARI, and KEY.

This copies the contents of the MB register to the AR register.

At this point the MC hangs waiting for the Memory Read Strobe.

The behavior of the MC is not consistent and is affected by the Speed switch setting.

Next week we will connect a logic analyzer to the CM Flip-Flops to make sure that everything is working correctly.

We also need to determine why the CM is not getting a response from the Core Memory Controller.

01/12/13

The Mode Info flexprint cable #26 that goes from the front panel to slot CP H36 had peeled apart.

I replaced the flexprint with modern ribbon cable because the signals in the cable are static.

The SING STEP, SING INST, and REPT lights work now.

We ran the maintenance test described in section 3.7.7.3 of the PDP-9 maintenance manual.

To start the diag you press the I/O RESET switch, turn the console REPT switch on, set the maintenance switch in the MAINT position, and latch the START switch up.

The contents of the AR register are copied to all of the other registers. You can use the REGISTER DISPLAY switch to see the contents of the registers.

The contents of the AR go onto the A bus, are run through the ADR to increment the value, and then onto the O bus, and into the MB.

The contents of the MB go onto the B bus, the B bus goes through the ADR, and onto the O bus.

The O bus is loaded into the AC, AR, and PC registers. It would also go into the MQ register if this system had the EAE.

The contents of the address switch register can also be inclusive-ORed with the ADR.

All of this behavior looks OK, so that means that large parts of this system are functional, especially the Control Memory.

See page D-BS-KC09-A-10 CM Clock, Run, and Display (Sheet 1).

We looked at the A, B, and C flip-flops in section D2 & D3 because they control much of the CP timing.

The REPT CLK period is 8 uS, 28 uS, 200 uS, 2.6 mS, and 80 mS for switch settings of 5-1.

This is close to the values in the table on page D-BS-KC09-A-10 CM Clock, Run, and Display Timing.

Click on the image for a larger view.

The top trace is the REPT CLK. The bottom trace is the flip-flop C(0) output on pin J.

The period of the REPT CLK is 200 uS so the REPT SPEED switch was set to position 3.

This looks OK, and was also OK at other speed settings.

There was no output on pin J when the processor was running. This is OK.

Click on the image for a larger view.

The top trace is the flip-flop C(0) output on pin N of flip-flop B.

The bottom trace is the flip-flop B(0) output on pin P.

The period of the C(0) is about 18 uS so the REPT SPEED switch was set to position 5.

The output of the B flip-flop has glitches when the input signals change.

We swapped the S206 modules in slots J29 & J30. There was no change in the behavior.

We need to fix this or the CP timing will be really confused.

The Hours Meter showed 40181.9 when we finished.

01/19/13

EXAMINE and DEPOSIT are not working.

We need to determine if this is a processor or memory problem.

We spent some more time looking at the system's behavior when it is doing an EXAMINE.

We are actually getting three CM CURRENT pulses, not just two as we originally though.

One was 5uS before the other two when were running in a slow speed, so we didn't see it on the 'scope.

The first CM word has the SM bit turned on so it will wait to synchronize with the core memory controller timing.

The second and third words run asynchronously with the core memory controller.

Click on the image for a larger view.

The top trace is RUN.

The bottom trace is CM CURRENT.

The first CM CURRENT pulse should be reading CM word 01.

The second pulse should be reading CM word 25.

The third pulse should be reading CM word 26.

We looked at all of the CP/Memory Interface signals on page D-BS-KC09-A-24 CP/Memory Interface.

All of the signals looked reasonable, so the core memory controller is alive.

We didn't see any data from the sense amps.

It is possible that we have written all ones to all core locations with our experiments.

Click on the image for a larger view.

We looked at all of the signals on page D-BS-KC09-A-29 System Timing.

Everything here looks OK.

The IO RESTART signal was static so it was not included.

We spent some time looking at the schematics trying to determine the difference between the Examine and Deposit behavior.

From the schematics it is not obvious.

01/26/13

We looked at the D-BS-KC09-A-19 CM Sense Flip-Flops (Sheet 3) to see if the SAO flip-flip is working correctly.

We were thinking that if the SAO signal was always off the processor would always do a DEPOSIT cycle and never read core.

Click on the image for a larger view.

The top trace is RUN.

The bottom trace is SAO(1) for an EXAMINE cycle.

Click on the image for a larger view.

The top trace is RUN.

The bottom trace is SAO(1) for a DEPOSIT cycle.

So, it looks like the SAO signal is active and is different for an EXAMINE and DEPOSIT cycle.

Now that we know that the signal is active we need to verify that the timing is OK.

We decided to look again at the behavior of the A/B/C flip-flops on page D-BS-KC09-A-10 CM Clock, Run, and Display Timing.

We also looked at the timing diagram on page D-BS-KC09-A-11 CM Clock, Run, and Display Timing.

Click on the image for a larger view.

The top trace is RUN.

The bottom trace is C(1) for a repeated EXAMINE cycle.

We noted on 01/12/13 that the B flip-flop had glitches on the output and was not doing a divide-by-two.

Click on the image for a larger view.

The top trace is RUN.

The bottom trace is B(1) for a repeated EXAMINE cycle.

Since RUN(1) is tied to the preset input of the B flip-flop the B(1) output gets forced back high when it tries to flip low.

So this is normal behavior after all.

02/02/13

We decided to look at the operation of the core memory controller today.

With the system in maintenance mode performing repeated deposits we can see the address switches moving to the MB and then to the AR.

We can see the data switches moving to the MB.

A large part of the system needs to be functional for just that to work.

See page D-BS-MC70-B-11, Memory Test Connections.

We looked at all of the core memory signals available on the test connectors.

All of the signals are active, have reasonable wave forms, and reasonable timing.

Click on the image for a larger view.

These traces show the read and write current going through the current limiting resistors.

See page D-BS-MC70-B-4, Digit Drive Bits 0-17 (Sheet 1).

All of the address and data signals used for bit 0 look OK in their high and low states.

The Digit Write Sink (1) signal is 800 ns after the CLK signal. That looks reasonable.

The +V Digit 00 Res and -V Digit 00 Res signals look OK for all 16 possible memory address combinations, and for read and write.

That means that all of the steering diodes, drive transistors, and core wiring is OK.

The MBS00 through MBS17 signals all look OK in their high and low states.

That means that the data switches are getting to the core.

See page D-BS-MC70-B-5, Word Selection.

All of the address signals look OK in their high and low states.

The WR ^ MA5(1) and the WR ^ MA5(0) signals look OK and occur 800 ns after the CLK. Looks OK.

The WW ^ MA5(0) and the WW ^ MA5(1) signals are just high. There is no WORD READ strobe.

This would prevent the core from being read.

Click on the image for a larger view.

The top traces are 100 ns/division.

The bottom two traces are 200 ns/division.

See page D-BS-MC70-B-1, Memory Control (Sheet 1).

The MA5(0) and MA591) signals look OK.

The WORD WRITE(1) signal looks OK.

The WORD READ(1) signal is just high.

So the problem is not with these inverters.

See page D-BS-MC70-B-1, Memory Control (Sheet 2).

The READS OFF and WORD READ ON signals look OK and the timing looks reasonable.

The WORD READ(0) signal look OK, but the WORD READ(1) signal is just high.

We replaced the B213 flip-flop module in slot H33 with a spare.

Now we can read the original contents of core memory, but it is not rewritten.

We cannot deposit to core.

This is some real progress!

We looked at the outputs of the rest of the flip-flops on this schematic page.

All look OK except that DIGIT WRITE SINK(1) only goes down to -3V and the rest go to -4V.

We replaced the B213 in slot B16 with a spare, but it did not change the signal shape.

This signal goes to all 18 G219 Memory Selector modules.

We pulled all of the G219 modules, replaced 2, and looked a the DIGIT WRITE SINK(1) signal.

The signal looked OK until we got to the G219 in slot AB09.

We replaced the G219 with a spare module and the DIGIT WRITE SINK(1) still looked OK.

We had hoped that the core would read and write now, but found that the data switches are not transferred to the MB.

Oh well, now we know what to look at next week.

The Hours Meter showed 40193.5 when we finished.

02/09/13

No work due to blizzard.

02/16/13

Just to make sure that the registers, microcode, I/O buses, etc were working OK we ran the build in maintenance test.

All the register contents looked OK so we continued debugging the core memory write problem.

On 2/2/13 we noticed that we could read core, but the rewrite or deposit did not work.

Warren scanned core addresses and found a location that has bit-7 on.

We looked at the B169 module in slot C31. See page D-BS-MC70-B-3, Memory Input Multiplexer.

Pin J was high indicating that the MB07(0) signal was present.

Pin F Mode(0) was low indicating that the processor was granted access to the core memory.

Pin D was low indicating that the MBS07 was present.

We looked at the MBS07 signal on the G219 modules in slots AB09 and EF09.

The signal was present on both. See page D-BS-MC70-B-4, Digit Drive Bits 0-17 (Sheet 4)

So at least we know that the bits that were read from core made it back to the Digit Drive modules.

We wanted to make sure that the data switches from the console made it to the Digit Drive modules and changed the current waveform.

See page D-BS-MC70-B-4, Digit Drive Bits 0-17 (Sheet 1).

We looked at the -V DIGIT RES 00 signal on pin FF of the G219 in slot EF07.

We could see a 20V pulse when the bit-0 data switch was on.

So now we have verified that the Digit Drive signals look OK.

That only provides 1/2 of the current needed to write core, so it was time to look at the Word Selectors.

Click on the image for a larger view.

The top trace is CLK.

The bottom trace is -V WORD RES.

See page D-BS-MC70-B-5, Word Selection.

We looked at the -V WORD RES signal on pin JF of the G219 module in slot HJ27.

The signal was a steady -30V. This should have a pulse on it that was similar to the -V DIGIT RES 00 signal.

Without this pulse the write current to the core will be 1/2 of the required current and it will not work.

We looked at the +V WORD RES signal on pin HH of the G219 module in slot HJ27.

We saw a -30V pulse similar to the +V DIGIT RES 00 signal.

Since the +V WORD RES signal looked OK we knew that all of the MA signals were OK.

We previously has a problem with the WR(1)^MA5(1) v WW(1)^MA05(0) signal that was caused by a faulty G219 module.

Click on the image for a larger view.

The top trace is CLK.

The bottom trace is WR(1)^MA5(0) v WW(1)^MA05(1).

We looked at the WR(1)^MA5(0) v WW(1)^MA05(1) signal on pin HV of the G219 in slot HJ27.

The pulse should have gone to -4V, but only went to -2V.

Since this signal only goes to the Word Drive G219 modules we pulled all eight of the modules associated with the Word Drive circuitry.

Without the G219s installed the WR(1)^MA5(0) v WW(1)^MA05(1) signal went to -4V so we knew that we had another defective G219 module.

After replacing the G219 modules one at a time we found that the one in slot HJ24 was the defective one.

After replacing the G219 with a spare the WR(1)^MA5(0) v WW(1)^MA05(1) signal went to -4V.

A quick test showed that we could examine, rewrite, and deposit to core.

This was a major milestone and meant that we could see if the processor would do anything.

We did some instruction testing to see what works.

The RAL, RAR, RTL, RTR, CLL, STL, CML, CLC, CLA, and CMA instructions work OK.

If the IZS instruction is not doing a skip it works OK. If the ISZ does a skip it sometimes goes to location 0.

The JMP instruction sometimes stores the contents of the PC where the JMP instruction was.

Well, the processor is alive, and lots of the instructions seem to work OK.

We will work on the flakeyness in the JMP and ISZ instructions next week.

Maybe connecting a logic analyzer to the ROPE memory sense amps would show if the microcode is working correctly.

02/23/13

Last week we found that the JMP and ISZ instructions were unreliable.

They worked OK when single stepping, or when running at a very low speed.

The processor would go off into the weeds when running at full speed.

This week we connected Warren's Logic Analyzer to the Control Memory address lines so we could see the micro-instruction flow while it was executing a JMP instruction.

It took a few tries to determine which signals and which polarity of the signals we needed to watch, but we eventually figured it out.

Click on the image for a larger view.

Warren's USB logic analyzer is the little silver box on the 'scope cart.

In conjunction with a digital 'scope we can really see what the processor is doing.

I can't imagine how a DEC field service person would have fixed the processor issues without a logic analyzer.

See schematic page D-FD-KC08-A-6 Key Flow and schematic page D-FD-KC08-A-18 CM Wiring Matrix and Program (Sheet 1)

It you push the IO RESET key the CM address lines would go to 01.

This confirms that the processor will just sit on the KEY NOP CM word.

When you press the EXAMINE key the processor goes to:

CM word 01 which copies the address switches to the MB, and starts a memory cycle.

CM word 25 which copies the address in the MB to the AR and is displayed on the console.

When the memory cycle finishes the contents of the core location will be in the MB and is displayed on the console.

CM word 26 which copies the PC to the MB in preparation for an EXAMINE NEXT.

We entered a JMP 000200 at address 000200 and ran it.

The processor would execute a few JMP instructions correctly and then execute the wrong micro-instructions.

When it failed the CM CURRENT strobe was about 1/2 of the expected duration.

Click on the image for a larger view.

The top trace is CM CURRENT.

The traces below are the CM address lines A1, A2, A3, A4, A5, and A6.

The address bits on the logic analyzer were grouped into a bus to make it easier to interpret. Unfortunately we got the bits in reverse order.

At the left the CM was left in the Fetch state, CM word 21, by the EXAMINE we had performed earlier.

The CM CURRENT strobe read CM word 6, the START key.

The next CM address in the cycle is 21, the FETCH state.

Click on the image for a larger view.

At the top left the CM CURRENT strobe finally happens after a long delay.

This is the FETCH state, CM word 21.

Then the CM word 12 is processed to decode the instruction.

The next CM address in the sequence is 24, but it is never used.

When the instruction is decoded it modifies the next address to CM word 74, the JMP.

Click on the image for a larger view.

Then we go to CM word 10, BGN.

Then we go to CM word 21 to fetch the next instruction.

Unfortunately the CM CURRENT strobe for the fetch is only 25ns long when it should be 70ns.

The next CM word 14 instead of 12 and then CM word 37 and the processor stops.

See schematic page D-FD-KC08-A-16 CM Timing.

The Control Memory Timing Circuit takes the output from pin D of the B602 Pulse Amplifier in slot F30, runs it through a B105 inverter in slot F28.

The output from the inverter goes to the B310 25ns delay line in slot EF29.

The output from the B105 inverter is wire-ORed with the output from the B310 delay line to stretch the 25ns signal into a 50ns signal.

When the processor fails the CM CURRENT strobe is only 25 ns long.

The short CM CURRENT signal does not put enough energy into the ROPE memory so it does not work correctly.

We think that the B130 delay line in slot EF29 that we replaced at the beginning of our debug efforts is defective.

The system behavior is better when it is cold, so maybe one of the transistors on the B130 is partially bad.

The two spare B130 delay lines that we tried were also broken.

We will repair two B130 modules this week and continue our work next week.

03/02/13

We bought some DEC3639 (2N3639) transistors from Circuit Specialists to repair the two defective B310 delay lines that are spares.

The D-664 diodes measured OK and we replaced all four transistors.

We also found lots of broken solder joints at the delay lines that probably were the cause of the problem in these spare boards.

See schematic page D-FD-KC08-A-16 CM Timing.

This week we added a lot more connections to the Logic Analyzer so we could see all of the signals that generate the CM CURRENT pulse.

The pulse that generates the CM CURRENT pulse for a fetch cycle starts with the CM CLK and SM(1) signals going to the R111 in slot E22.

This pulse is shorter than the pulse for the other types of processor cycles.

The schematic says that the CM CURRENT pulse needs to be 80 ns +25 ns / - 0ns.

The pulse from the fetch cycle is sometimes as short as 25 ns and sometimes there are two pulses.

The pulse that generates the CM CURRENT pulse for the other processor cycles comes from the B104 in slot F31.

These CM CURRENT pulses look OK.

We found that B310 delay line in slot EF29 had been change from the factory setting to reduce the delay by 12.5 ns.

The replacement wire-wrap was the wrong wire size, was not installed with the correct tool, and was loose and a poor connection.

Click on the image for a larger view.

The new wire from pins FN to FR was loose on the backplane pins so we replaced it with the factory setting from FN to FP.

If you look to the right of the 'scope probe you can see another timing jumper change from the factory setting.

Next week we will go through the process of measuring and adjusting the Control Memory circuit delays.

The processor is running reliably if we set the speed to 5 and lock the CONT switch on.

This runs the processor about 50 times slower than normal.

Hopefully adjusting the timing will let it run at the full 1 MHz speed.

Not bad for a 45 year old machine.

We tested a few more instructions and found that the LAC (Load Accumulator) and TAD (Twos Compliment Add) instructions work OK.

The DAC (Deposit Accumulator) instruction puts the contents of the AC back in memory, but then goes to the wrong address to execute the next instruction.

It looks like the contents of the AC is getting transferred to the PC.

That should not be too difficult to debug.

We also found that the ISZ (Increment and Skip if Zero) instruction does not increment the contents of a memory location.

03/10/13

Some of the delay settings in the CM timing circuit have been changed from the factory settings.

One changed wire was wire-wrapped correctly, so it may have been done at the factory or by DEC field service.

Two of the delay changes were a hack, and looked like the wires were just twisted around the wire-wrap post with pliers.

We removed these two wires and put them back to the locations shown in the schematic.

Click on the image for a larger view.

The system will now run at full speed!

We tried the LAW (Load AC with "n") instruction and it works OK. Only bits 5-17 can be used for the constant.

The ISZ is still broken. Fixing that should be our project for next week.

These are the original and the current settings for the B310 delay lines for the Control Memory.

See schematic page D-FD-KC08-A-16 CM Timing.

There is a chart at the top of this schematic page that lists a sequence for measuring and setting the Control Memory delays.

The first check is the delay from the CLK at C01H to the CM CURRENT at F26U. The delay should be 26ns +/- 10ns, and measured 50ns. This is a "check only" so we will look at this again later.

The second check is the delay from CLK at C01H to CM STROBE D at E27N. The delay should be 100ns +/- 10ns, and measured 96ns. We will leave this alone.

The third check is the width of CM CURRENT at F26U. The width should be 80ns + 25ns - 0ns, and measured 60ns. We will try to make this longer to get more current into the CM cores.

We tried replacing the R111 module at F26. There was no change to the width of CM CURRENT.

We tried replacing the R111 module at E24. There was no change to the width of CM CURRENT.

We thought that a bad diode on one of the G210 CM Driver modules could load the CM CURRENT signal.

We pulled both G210 modules, but without a load we couldn't see the CM CURRENT signal.

All of the diodes on the G210 measured OK.

We thought that a bad diode or resistor on the W005 at F27 might not pull down the CM CURRENT signal enough.

We tried two different W005 modules, but there was not change to the CM CURRENT signal.

The system runs at full speed now, so we will focus our efforts on getting all of the instructions to work correctly.

We will revisit the delay adjustments later.

The Hours Meter showed 40210.1 when we finished.

03/16/13

Click on the image for a larger view.

This is the MC09 (G920) ROP (Read Only Program) memory from the PDP-9. It is the 45 year old equivalent to a ROM and stores the microcode for the processor.

There are 64 wires that go through the 36 transformers. The wires go through either the "1" side or the "0" side of the transformer.

When a pulse is sent down one of the 64 wires it creates either a "1" bit or a "0" bit in each of the 36 transformers.

The B213 JAM Flip-Flop detects and latches the bits that then control the behavior of the processor and indicate the next microcode step.

SLAC found that 80% of their PDP-9 CPU failures were in this module, so they designed a more reliable replacement.

We hope that our PDP-9 doesn't have the level of failures that SLAC observed.

We worked on the broken ISZ instruction. We found that the CJIT bit (pins D & E on B213 in slot D28) from the Control Memory was inactive.

The signal was about -2V and should have been either -4V or 0V.

The problem could only be in the B213 JAM Flip-Flop or the ROP memory.

We replaced the B213 JAM Flip-Flop in slot D28 with a spare. The voltage level was OK now, but the CJIT signal was still inactive.

We looked at the CM SL11 signal (pin K on B213 in slot D28) and found it inactive.

If a transformer connection is OK we should measure the very low resistance across the sense coil in the transformer.

If the connection is bad we will either measure an open, or the 470Ω +/-10% terminator resistor across the coil.

We removed the ROP memory and measured the resistance across all of the transformers.

We found three transformers (AR0, CJIT, CMA1) that measured ~500Ω when they should measure about 0.5Ω.

Warren resoldered the connections on the PCB and the resistance went to 0.5Ω.

We hope that this is not an indication of the legendary unreliability of the Control Memory in the PDP-9.

Lichen Wang at SLAC found that 80% of the failures in their PDP-9 were in the MC09 module.

SLAC article on a more reliable replacement for the DEC ROP memory.

The ISZ instruction now works. This instruction is always used in programs so it is vital that it work correctly.

Click on the image for a larger view.

The top trace is CM CURRENT and the bottom trace is the CJIT signal in the MC09 ROP Memory.

You can see a "1" and a "0" bit and crosstalk from the other wires.

We tried some other instructions and found that the NOP, HLT, LAS, ION, IOF, CLON, and CLOF all work.

The DAC and DZM instructions work, but the processor stops executing instructions after the instruction.

The DAC and DZM instructions will be our project for next week.

The Hours Meter showed 40214.4 when we finished.

03/23/13

Click on the image for a larger view.

The top trace is CM CURRENT and the bottom trace is the STROBE DLYD in the CM Timing circuit.

This is a NOP, NOP, DZM, JMP -3 loop. The first 11 CM CURRENT signals are OK.

The 12th CM CURRENT signal is early and was not synchronized with the Core Memory controller.

We moved many of the logic analyzer probes from the Control Memory signals to the microcode flip-flops so we could see if the microcode contents were reading correctly.

When we ran the DAC or DZM instructions we observed a CM CURRENT signal that was early, because it did not wait to synchronize with the Core Memory controller.

We eventually traced the problem to a CONT(0) CM signal that was a little early and triggered an extra CM CURRENT pulse.

We measured the Control Memory timing again and slowed down the B310 delay line in slot EF33 that controls the CM LOOP timing.

We moved the wire-wrap wire from pins EE-EH to pins EE-EF.

Adding 12.5ns to the delay increased the LOOP timing enough to stop the false triggering of the CM CURRENT signal.

The CM Timing circuit then waited for the CM CLOCK ^ SM(1) to synchronize with the Core Memory before generating a CM CURRENT pulse.

The slower Control Memory timing eliminated the extra STROBE DLYD signal and now DAC and DZM instructions work OK.

The Hours Meter showed 40218.3 when we finished.

03/30/13

The PDP-9 was reluctant to run when we first powered it on Saturday. After about 10 minutes it ran fine.

There are many things that can go wrong with a 45 year old computer, but we will eventually need to find the cause of that behavior.

We worked on the paper tape reader so we can load instruction diagnostics.

See schematic page D-BS-KD08-A-9 Reader Control (Sheet 1).

Pushing the FEED button on the paper tape reader resulted in just one jog of the sprocket wheel.

The RDR A and RDR B flip-flops should generate the four signals for the stepper motor as long as the FEED button is pressed, but we saw just one step.

We saw just one RDR INDEX and just one RDR CLK pulse when the FEED button was pressed.

We had several spares for R401 Clock flip-chip in slot E03 that controls the acceleration, speed, and deceleration of the paper tape reader, so we tried that.

We measured the resistance of the trimpot on the broken R401 and set the trimpot to the same value on the replacement R401.

The resulting frequency from the R401 was a nearly perfect 600 Hz to make the paper tape reader run at 300 CPS.

Now the paper tape reader fed as long as the FEED button was pressed.

We tried reading a paper tape that came with the system, but it would only read three characters and stop.

Warren quickly pointed my poor choice of a tape because it was in BIN format not HRI format.

Using a short diag tape, this time in HRI format, yielded better results.

We compared the bits on the tape with what was in memory and found that bit 10 was always a zero.

See schematic page D-BS-KD08-A-9 Reader Control (Sheet 2).

The RD HOLE (2,8) signal from the paper tape reader looked OK, but the S205 flip-flop in slot D07 never changed.

We didn't have a spare S205 Dual Flip-Flop flip-chip, so we substituted an R205. The R205 is the same module but with weaker pull-down resistors.

We will repair the S205 is put it back in the system.

Now we can load binary paper tapes, almost always correctly, into core.

We need to perform the Tape Reader Adjustments in the PDP-9 Maintenance Manual to improve the reliability.

We looked through the TC59 boot loader paper tape. Hopefully we will be able to locate the 1/2" software tapes, or recreate the tapes.

The PDP-9 paper tape reader controller is much more complicated than the one in the PDP-8 because the PDP-9 can load binary paper tapes into core without running a loader program.

You enter the load address for the program in the console switches and press the "Read In" button.

The controller hardware/microcode reads three characters from the paper tape, assembles them into an 18-bit word, stores it in core, increments the target address, and continues until it sees hole 7 punched.

When it sees hole 7 it executes the last instruction loaded from the paper tape.

The instruction is usually a HLT to stop the processor, or a JMP to run the program that was just loaded.

We also looked at the Teletype interface.

See schematic page D-BS-KD08-A-11 Teletype Control (Sheet 2).

The TTO LOAD signal causes the bits to propagate through the flip-flops and out the serial port is not active, so we didn't get very far.

We need to look at the S603 Pulse Amplifier in slot C39, the R450 Variable Clock in slot C40.

Since we didn't have the W070 TTY cable connected maybe the Teletype input was busy and inhibited the output?

04/06/13

We used the PDP-8/S to make binary images of the PDP-9 diagnostic paper tapes, and to make duplicates that we can use.

The original paper tapes are 40+ years old and are fragile.

To Do:

Install the W070 in slot A33 in the I/O chassis and debug the console serial port.

Tune the paper tape reader so it always works correctly.

Load instruction diagnostics through the serial port or the paper tape reader and test all of the instruction combinations and interrupts.

04/13/13

We connected the W070 TTY cable to a RS-232-to-Current-Loop converter and then to a PC.

We have standardized on a current-loop cable connector that mates with a VT52 or VT420 on all systems.

The TTY controller actually worked on the first try.

Good thing, because there are about 30 Flip-chips in the TTY interface, so debugging would have been a challenge.

The diagnostic paper tapes for the PDP-9 are dried out and cracking.

We tried to use the PDP-8/S in the museum to make tape images and duplicates.

Unfortunately the PDP-8/S was reluctant to run today.

We finally found an oxidized edge connector on one of the Flip-chips that caused an instruction decoding problem.

We made binary images of two tapes, and will make the rest next weekend.

We are scanning the PDP-9 diagnostic manuals and will post the the manuals and paper tape images on Bitsavers.

I am writing a PDP-9 HRI tape disassembler so that we can make MACRO source code from the binary tapes.

We can also use the program to verify the binary images of the tapes against the source listings in the manuals.

04/20/13

We started working on the broken PDP-9 paper tape punch while the processor was running the MAINDEC-9A-D0CA Memory Address Test.

The punches were a little rusty after being unused for a very long time. That was easy to fix with cleaning and oiling.

The solenoid that enables the tape feed would not activate.

Replacing the W040 solenoid driver flip chip didn't help.

It looks like the sensor that detects the position of the punch drive shaft is not working.

It may be a challenge to find a replacement or to fix the one that we have.

We used the PDP-8/S to make images of most of the diagnostic paper tapes.

We will get them posted to Bitsavers when they are ready.

The scans of the diagnostic documentation are already on Bitsavers.

The Hours Meter showed 402226.2 when we finished.

04/27/13

MAINDEC-9A-D0BA ISZ Test showed just one error during a 20 minute run.

That is probably a memory problem too.

MAINDEC-9A-D0CA Memory Address Test, MAINDEC-9A-D0DB JMP Self Test, MAINDEC-9A-D0EA JMP-Y Interrupt Test, and MAINDEC-9A-D0FA JMS-Y Interrupt Test all ran OK.

MAINDEC-9A-D1AA Basic Memory Checkerboard ran for about 20 minutes with a single error.

MAINDEC-9A-D1BA Extended Memory Checkerboard ran fine for about 15 minutes, and then showed some errors.

We have not run through the whole system adjustment procedure.

Hopefully adjusting the memory voltages and timing will fix these errors.

MAINDEC-9A-D1FA Extended Memory Address Test ran without errors.

MAINDEC-9A-D01A Instruction Test Part 1 ran for about 45 minutes, and then halted at E587, address 006206.

Now the processor is acting strange, so something in the Control Memory is broken again.

That will be the project for next week.

05/4/13

We tried the basic functions of the system to see what still worked.

We found that examine/deposit and the built-in maintenance test worked OK.

That means that the Core Memory, the Control Memory, some of the CPU, and some of the I/O are working.

At least we have enough working to start diagnosing what is broken.

We tried a few simple instructions like a JMP and LAC and found that they worked OK.

Memory reference instructions like an ISZ or a DAC fail and end up with the PC = 0 instead of the correct value.

When the ISZ instruction is executing the microcode goes through addresses 06, 21, 12, 24, and 32.

The microcode should have gone to address 30 instead of 32, so there is a problem with the Control Memory address promotion circuitry.

We narrowed down the problem to the R111 module in slot F23.

We replaced the module with a spare, and the ISZ worked.

We put the original R111 back and the ISZ instruction still worked.

So, it looks like we have a backplane connector reliability problem or a bad solder joint on the module.

We also found that the LAC and DAC instructions worked OK, but the DZM instruction did not work.

We found that the microcode was going to the correct 63 address, but then it went to address 0 instead of address 10.

Address 0 is a NOP and will hang the processor.

We wiggled and reaseated all of the modules in the control memory circuit and then the DZM instruction worked OK.

We ran the MAINDEC-9A-D1AA Basic Memory Checkerboard for 90 minutes without an error.

That means that large parts of the Core Memory, CPU, and I/O controller are working OK.

We tried the MAINDEC-9A-D1BA Extended Memory Checkerboard.

This diagnostic does a more exhaustive Core Memory test than the previous basic test and showed errors last week.

The diagnostic failed and we found that the DAC instruction used by the diagnostic was not working correctly.

We replaced the R111 in slot H23 and then the diagnostic then ran OK.

To test our theory about backplane connector reliability problems or a bad solder joints I banged on the back of the chassis while the diagnostic was running.

The CPU stopped immediately and would not run until we reaseated the Control Memory modules again.

So, it looks like we need to clean the contacts for the Control Memory modules and inspect the modules for bad solder joints.

This will be our project for next week.

05/11/13

We worked on the vibration sensitivity problem in the PDP-9.

The PDP-9 Maintenance Manual describes "Aggravation Tests" for intermittent faults.

Warren ran an ISZ, JMP, JMP program and watched the console lights while I aggravated the modules in the Control Memory circuitry by tapping on the handles.

We quickly found that the B310 delay line in slot EF29 was a problem.

We had previously tagged this module as suspect so we replaced the module with a repaired spare.

The vibration sensitivity was gone, but the ISZ instruction didn't work correctly.

Warren reflowed the solder joints on the original B310 module and put it back in the system.

The ISZ instruction worked correctly and the vibration sensitivity was gone.

Click on the image for a larger view.

The system runs OK with a Sharpie inserted below the MC09.

We continued aggravating the modules and found that the MC09 Control Memory was vibration sensitive.

Warren reflowed all of the solder joints on the MC09.

The processor worked OK sometimes, but worked OK only if we pushed up on the right side of the MC09.

I pushed a Sharpie below the MC09 and everything worked OK.

Warren gave me lots of grief about my diagnostic techniques and insisted that I post an image of the "repair".

We ran a series of diagnostics and during the tests the bit-6 light in the register display stopped working.

It didn't take long to determine that the I/O signal that turns on the light was OK.

Wiggling the module that carries the bit-6 signal to the back of the front panel fixed the light.

That was much easier than disassembling the front panel and replacing a bulb.

All of the diagnostic programs now run OK except for the Instruction Test II.

This fails during XCT instruction testing, so we still have debug work to do.

The processor halted at 00417. This corresponds with E1432 in the source code.

Memory location 20 contained 00616. Constant K21 contained 000021.

These are compared during the diagnostic, so this was a failure.

The processor is nearly completely functional now, so hopefully we have just a little more debugging to do before we can look at the TC59 1/2" magnetic tape controller and the TU20 tape drive.

The Hours Meter showed 40240.7 when we finished.

05/18/13

We took one step forward and one step backwards on the PDP-9 today.

We removed and replaced the solder on all of the connections on the MC09 Control Memory board during the week.

The system worked OK when the board was reinstalled today and ran the MAINDEC-9A-D1AA Basic Memory Checkerboard without errors.

The MAINDEC-9A-D0BA ISZ Test test worked OK for a few minutes and then started reporting errors.

Now none of the memory reference instructions work.

There is a problem in the Control Memory circuitry where the MBI signal is turning on when it shouldn't and makes any instruction that fetches memory get the wrong data.

The result is that the instruction is stored in the memory location were the data belongs.

We pulled the B602 Pulse Amplifier in slot E23 to disable the 1->MBI signal.

After that the memory reference instructions worked OK.

Now all we need to do is find out why the 1->MBI signal is getting activated when it shouldn't.

Fixing that will be the project for next week.

At least we don't need the Sharpie next to the MC09 to keep the system running now.

We removed the inductive position sensor from the paper tape punch.

The wire in the coil is broken internally, so it will need to be rewound.

We will measure the diameter of the wire to see what gauge it is.

Then we will unwind the coil, counting the turns as we go.

Then we can rewind the coil with new wire.

Hopefully the punch will work with a repaired sensor.

05/24/13

We made good progress on the PDP-9 restoration yesterday.

Unlike last Saturday the system worked OK when we powered it on.

We loaded the MAINDEC-9A-D1AA Basic Memory Checkerboard which ran fine for a few seconds and then stopped.

The built-in Maintenance Test would not even run, so something is really broken in the Control Memory.

We connected the logic analyzer and 'scope and started searching for the fault.

Of course once we had all of the tools connected the system decided to run OK again.

We ran successfully several of the basic diagnostics, and tried the MAINDEC-9A-D2BA TTY Test for the first time.

We don't have a working Teletype yet, so we connected a VT220 terminal.

During some character test patterns we saw errors on the display.

We measured the transmit speed and found that it was running at about 102 baud instead of the required 110 baud.

We adjusted the trimpot on the R450 Variable Clock module in slot C40.

There are four trimpots on the R450. Three were still sealed with paint.

The one that had the paint removed was the one that we needed to adjust.

The TTY diagnostic works OK now.

We were able to run the MAINDEC-9A-D02A Instruction Test Part 2 for the first time.

That ran for 20+ minutes without a fault.

While it was running we bumped into the system and it stopped.

A power cycle was required to get it running again.

So, when the system is running everything in the processor, core memory, and I/O is working OK.

There is some loose connection or defective module in the system that makes it vibration sensitive.

We need to find the loose connection or it will cause problems forever.

Soon it will be time to power up the TC59 tape controller and TU20 tape drive and see how much of that works.

It looks like the 834 AC power controller in the TC59 cabinet supplies the TU20 cabinet.

The DC power supply in the TU20 cabinet feeds the TC59 controller.

The 728 DC power supply that was in the TC59 cabinet was removed.

The power supply in the TU20 cabinet should have more than enough capacity to power the TC59.

We have a spare power supply from the PDP-8/S that we could put in the TC59 cabinet.

The Hours Meter showed 40250.7 when we finished.

06/1/13

The intermittent problem in the PDP-9 was permanent today so debugging was a lot easier.

Even a simple function like Examine didn't execute the correct microcode sequence.

We looked at the Control Memory signals with the logic analyzer and a 'scope.

The logic analyzer trace showed double strobe signals to the Control Memory flip-flops.

The first strobe latched the correct signals, the second did not.

That caused the processor to execute the wrong microcode and do strange things.

After looking at Control Memory Timing circuitry we found that yet another B310 delay line in the Control Memory Timing circuitry was misbehaving.

This one generates the Control Memory flip-flop strobes and is a B310 that we had previously repaired.

The two repaired spare modules also misbehaved.

Both of the spare B310 modules had one of the four transistors that were leaky.

Click on the image for a larger view.

We connected a spare backplane connector to -15V through a 100 Ohm resistor for a load, to Ground, and the CLK signal from the processor so we could see how the remaining delays worked.

We found that there was severe ringing on 2 of the three remaining delays.

This might be an artifact from the 12" wires between the module and the power/ground on the backplane.

Next week we will make a better test setup and replace the bad transistors.

06/8/13

Last week we couldn't find the 2N3639 transistors that we bought from Circuit Specialists so I ordered more transistors.

Today we borrowed a transistor from one broken B310 delay line to fix another.

The repaired B310 fixed the problem that we saw last week with the Control Memory strobe.

Of course, after we borrowed a transistor from a broken B310 we found the package of 100 new transistors.

The B310 repair fixed the Control Memory so it would cycle through the built-in diagnostics

Unfortunately the Memory Buffer contents would not display on the console, so we chased that issue for quite a while.

We finally found that the 1->MBI signal was active when it should not be so the MB contents got clobbered. See D-FD-KC09-A-19 CM Sense Flip-Flops (Sheet 2).

That signal is generated by the IN CLR signal which was active when it should not be.

The IN CLR signal comes from the B310 on D-FD-KC09-A-16 CM Timing.

It looks like the signal should be inhibited by the KEY (1) signal, but was not.

The scope showed the same signals on pins E & D of the B104 module in slot F31.

We pulled the module and found that the transistor used in this circuit had different resistance readings compared to the other three on the module.

We replaced the module with a spare B104 module after we measured the transistors in a spare.

We now found the processor misbehaving even more.

It was still really broken when we put the original B104 module back.

The KEY (1) signal is now inactive. That signal comes from a Control Memory flip-flop.

Oh well, at least we know what circuit to chase next week.

06/15/13

Of course the KEY(1) signal worked fine this week, so we looked at why EXAMINE does not work.

We misunderstood the microcode sequence for Examine and Deposit, so we spent quite a bit of time looking at address promotion logic.

It turns out that there is hardware logic that controls the different behaviors, not microcode.

We could not get the microcode sequences to run correctly and consistently.

Without microcode working this processor will do nothing.

We repaired the broken B310 delay line, and put it back in slot EF29, but that didn't help.

The Control Memory Current signal was a little short so we replaced the B602 pulse amplifier in slot E32 with a spare.

That didn't help either.

At this point it will not execute the microcode sequences correctly, so it really won't do anything.

The documentation is more than a little confusing, so we have some studying to do.

06/22/13

We then found that the DEI microcode signal was always active and was enabling a circuit that modifies the next microcode address in the sequence.

We traced that problem to a bad sense amplifier in slot D20 in the Control Memory circuit.

When that module was replaced with a spare the microcode sequence looked much better, but not correct.

Sometimes the next microcode address was correct, sometimes not.

We found that one of the delay line modules was creating a double pulse instead of a single pulse and making reading the microcode contents unreliable.

We replaced the M310 delay line in slot EF29 with a repaired module.

When that module was replaced the processor started behaving correctly again.

After lots of frustrating debugging it was nice to see the system back to somewhat normal behavior.

When we executed the built-in maintenance test we found that there is a problem in the adder, registers,

or one of the buses that is preventing the adder from carrying a 1 from bit 7 to bit 6.

We were surprised to find that the carry signal from one adder to the next is not the normal negative logic.

The adders are a unusual design to make them fast enough to add in a single microcycle.

We swapped B131 and B133 modules for bit 6 and bit 7 of the adder, registers, and bus multiplexers, but haven't found the problem yet.

Next week we will try replacing the B133 in slots A16 & A20 that are connected to the adder outputs for bits 6 & 7.

06/29/13

We continued the bit-6 problem that we found last week.

The incrementing between bits 7 & 6 did not work when running the built in diagnostic.

We swapped the B133 modules in slots between A20 & A24, and A16 & A24.

See D-BS-KC09-A-21 Mb and Adder (Sheet 2)

At the point we have swapped All of the components for bits 6 & 7 for the adder with no change in the behavior.

We decided to take different path and tried to examine the highest possible core address.

Bit 6 from the switches did not get to the address lights on the console.

We traced the light driver signals through the I/O controller and compared the signals for bits 6, 7 & 8.

The IO BUS 06 signal was different from IO BUS 07 and IO BUS 08.

See D-BS-KD09-A-7 Input Mixer (Sheet 1)

The IO BUS 06 (B) signal actually comes from the processor chassis.

We continued comparing the signals for 6, 7 & 8 and eventually that the AR register had the wrong value for bit-6.

We replaced the B213 JAM Flip-Flop in slot C18 with a spare and now the built in maintenance program worked correctly.

We ran the D1AA, D01A, D02A, D0BA, D0CA, D0DB, D0EA, and D0FA diagnostics for a total of 5.5 hours without a failure.

I guess that the processor is back to a running state again.

07/5/13

We tried to demonstrate the system to the visitors from MARCH, but it would not run.

Examine/Deposit are not working.

The built-in maintenance program runs OK.

Hardware read-in of a paper tape works OK, but without Examine it is difficult to tell if it put anything in core.

We will fix this tomorrow.

07/6/13

Yesterday we found that we could not Examine or Deposit Core memory.

We have seen this behavior several times before, and the problem was always in the Control Memory.

We spent several hours verifying that the Control Memory was in fact working OK.

See page D-BS-MC70-B-2 Memory Timing Chain

We verified that the system CLK signal was present, and POST CLK and SYNC CLK looked OK.

See page D-BS-MC70-B-1 Memory Timing Chain (Sheet 1)

We verified that the MA JAM WORD, MA JAM PAR, and MA JAM DIGIT signals looked OK.

We verified that we could see the address switches loaded into the MA register during an Examine or Deposit.

See page D-BS-MC70-B-2 Memory Timing Chain (Sheet 2)

We verified that the READS OFF, DIGIT READ ON, WRITES OFF, and WRITES OFF signals looked OK and their timing was OK.

We verified that the DIGIT READ DRIVE, and DIGIT READ SYNC signals looked OK and their timing was OK.

We found that the WORD READ signal was inactive. That would stop core from working.

The READS OFF signal on pin F of the B213 in slot H33 looked OK.

The WORD READ ON signal at pin H was inactive.

See page D-BS-MC70-B-2 Memory Timing Chain

There was no signal on pin D of the Pulse Amplifier in slot E33.

The input signal on pin F was inactive.

The signal on pin H of the B360 in slot D33 was present, but there was no output on pin L.

The signal on pin H of the B360 in slot D30 was present, and there was a signal on output pin L.

We replaced the B360 in slot D33 with a spare. Now we see the WORD READ ON signal on pin L.

We adjusted the timing of the WORD READ signal.

The leading edge is adjusted with the B360 in slot D33 that we just replaced.

The trailing edge is adjusted with the B360 in slot F33. This adjustment was OK.

Now the core memory Examine/Deposit works again.

We ran the D0CA Memory Address Test, and the D1FA Extended Memory Address Test.

Both ran perfectly. I guess that the processor is back to a running state again.

If it runs next Saturday we will power up the TC59 and see if the PDP-9 can talk to it.

07/13/13

The PDP-9 actually ran OK when we powered it up today.

It ran the Extended Memory Address Test and the Extended Memory Checkerboard diagnostics for about two hours, and then we found a problem with address bit 16.

We started by looking at the AR bits 16 & 17 to see if they change when the switches are changed and they Examine is pressed.

Bit 17 changed and bit 16 did not, so the problem is not in the AR register. See page D-BS-KS09-AC, AR, MQ, PC (Sheet 3).

The address & data switches are actually an I/O device, so we looked at the IO BUS 16 (B) and IO BUS 17 (B) signals.

The IO BUS 17 (B) signal changed with the switches, and the IO BUS 16 (B) signal dod not.

These signals come from the I/O controller on page D-BS-KD09-A-7 Input Mixer (Sheet 2).

We compared the outputs of the B141 diode gates for buts 16 & 17.

The signal on pin D of the B141 modules in slots B17 & B18 both changed with the switch settings.

That only left the R123 Diode Gate module in slot D15 as the culprit.

We changed the module, and everything worked again.

The 2N3639 transistors on the module that drives pin P measured about 50 Ohms resistance between the emitter and collector.

This is the same transistor part number used on the many B modules that have failed, so we have lots of spares.

We replaced the defective module with a spare and tagged the module for repair.

We tried to run the D2CD High Speed Reader Test.

It failed because it reads the processor status word and found that there was no tape in the paper tape punch.

We either need to modify the program to ignore the tape-out bit or fix the paper tape punch.

We ran the D7AD Basic Exerciser today for the first time.

We had to inhibit the paper tape punch test because the punch is not fixed yet.

It seems to run OK and the terminal beeps every 5 minutes or so.

Periodically it stops with the PC = 0 so we still have some repair work to do.

We powered up the TC59 tape controller from a laboratory power supply.

No smoke, and some lights came on.

We need to make some AC power cords for next week so we can power the TU20, TC59, and the PDP-9 at the same time.

It looks like we need to find some obsolete, non-NEMA, Hubbell 3333C receptacles to make the power cords.

Next week we will connect the I/O cables between the PDP-9 processor and the TC59 tape controller to see what works.

07/20/13

We wired new AC outlets for the PDP-9 and the TU20 tape drive.

We borrowed the pigtail from the PDP-9 that has a Hubbell 3333C receptacle on one end and a NEMA 5-20P on the other end.

We powered up the tape drive and it is actually mostly functional

After we learned the right sequence of button pushes we actually mounted a tape.

The lower capstan actuator was a little sticky and caused the tape to creep.

After fiddling with it for a while it works OK.

When loading the transport doesn't stop at the load point.

The light is on, so we will need to check the operation of the photo-diode.

The transport doesn't respond to the FWD and REV buttons, but that is likely because the transport is not "ready".

We manually operated the capstan pinch rollers and were able to verify that the reel motors, brakes, tape position sensors, and vacuum pump are mostly functional.

Most of the indicator lights are out.

The PDP-9 processor worked normally when we powered it up today.

07/27/13

The PDP-9 worked fine this weekend. That is three weeks of running OK. Cross your fingers that it stays reliable for a while!

We took apart the status display for the TU20 tape drive.

It is not exactly designed for easy service. Almost all of the bulbs were burned out.

Fortunately Chicago Miniature still makes them and Mouser has them in stock.

Click on the image for a larger view.

The bulb for the Unit Number display had been repaired by soldering a grain-of wheat bulb to the original bulb contacts.

We will try replacing it with a LED car dome light bulb that will be bright, but will not make much heat.

The one we are getting has 8x LEDs in it so we can remove some of the LEDs if it is too bright.

The vacuum pump, reel motors, and reel brakes in the TU20 are working OK.

We need to debug the BOT/EOT sensors so we can get it to go ready.

Click on the image for a larger view.

We fixed a spare power supply from a PDP-8/S and installed it in the TC59 tape controller cabinet.

Apparently there are two versions of the power supply, one with 19" mounting designed to attach directly to the cabinet, and one that is narrower that is designed to mount to the swinging door.

Ours was the larger version so we couldn't mount it to the swinging door.

It works fine, but we may try modifying the power supply base so we can attach it to the swinging door.

We did more work on the AC power wiring.

That was a bit of a challenge because the obsolete twist-lock plugs used in this system don't follow the current ground/line/neutral connections.

We checked the wiring about five times before we powered it up. Works OK.

07/30/13

John W. Rogers donated two B310s, four B213s and a pair of B169 modules to our restoration effort.

We have had plenty of problems with the B310 Delay Lines, and the B213 JAM Flip-Flops.

There are lots of B169 Inverters in the system, but none have failed yet.

These spares will be really helpful.

08/3/13

The PDP-9 worked fine this weekend. That is four weeks of running OK. Cross your fingers that it stays reliable for a while!

We finished wiring the new AC outlets for the PDP-9 and TU20 tape drive.

We had the PDP-9 processor, the TC59 tape controller, and the TU20 tape drive all powered at the same time while the PDP-9 ran diagnostics.

The AC controller in the TC59 is connected to a switched outlet on the PDP-9.

When you power on the PDP-9 it tells the TC59 to power on too.

Click on the image for a larger view.

We replaced all of the indicator lights in the TU20 with the with the CM7370 bulbs that we got from Mouser.

During testing we found a burned trace on the display panel that prevented the POWER light from working.

Warren soldered a wire where the trace was.

The LED car dome light bulb that we got on eBay will work work nicely.

It is not too bright and won't make enough heat to melt the film with the unit numbers.

We need to get some thin double-sided adhesive tape so we can put the unit number display back together.

The REV function of the tape drive decided to work this week, but the FWD doesn't.

The BOT sensor that was always on last week is now off.

Maybe we should just leave the tape drive powered on for a while to see what else starts to work.

We connected the I/O bus from the PDP-9 to the TC59.

We don't have the two BC09 quad-cables that are used for the PDP-9, PDP-10, and PDP-15 I/O so we used 8x cables from a PDP-8.

We can actually write bits from the Accumulator to the Command Register in the TC59.

That means that lots of the TC59 are functional.

We need to reconstruct the TC59 diagnostic tapes for the PDP-9 so we can start testing the controller.

We have tape images of the PDP-15 versions of the TC59 diagnostic tapes and a source listings for the PDP-9 versions.

I wrote a PDP-9/PDP-15 disassembler in C#. It even seems to work OK.

We could disassemble the PDP-15 tapes into MACRO source, edit the source to match the PDP-9 listings, then assemble the source using the SIMH PDP-9 simulator, and punch a tape with the PDP-8/S.