PDP-9 Restoration Blog Starting 2019

Go to the earlier restoration blog.


Moved to the new Lab space.

3/2/19 Hours: 40412.4

We powered up the PDP-9 for the first time in the new lab space. Bit-9 is stuck on in all of the registers so that is the first thing to fix.


We made a longer power cord out of 12-3 SOO cord.

We measured the power consumption at 11A @ 120VAC, so it will $0.30/hour to run the CPU.

We swapped the B131 modules in slots A21 and A23, these are the Adder modules for bits 8 & 9.

The stuck bit moved to bit 8, so we know that the B131 that came out of slot A23 is defective.

We don't have a spare, so we will need to repair it.


The A BUS input on pin S was at -.011V (logic 0) and the other boards were at -3.46 (logic 1).

The SUM output on pin V was at -.3.53V (logic 1) and the other boards were at -0.11 (logic 0).

We measured the input and output voltages on the misbehaving B131 FlipChip, and on the two working neighbors.

Right away we could see that the output voltage was not correct on the broken B131, which explains the stuck bit-9.

The Adder circuitry in the PDP-9 is very fast (for its time), very complicated, and mostly analog.

The internal circuitry has four possible current/voltage levels depending on the state of the four inputs.

We made a benchtop test setup for the B131 so we could manipulate the input signals and measure the output signals.

Then we compared the behavior of a good B131 to the bad B131.

After a few hours of pondering the schematic to see how it works we were able to devise tests that would show if each of the individual transistors were working correctly.

Eventually we determined that Q4, a 2N3669 transistor was not working at all.

We replaced it with a New Old Stock part, and now the B131 is working again, and the stuck bit-9 is gone.

Alex is making an LT Spice model of this FlipChip so we can better understand how it works.

Click on the image of the B131 Adder for a larger view.

When running at the slowest possible speed the PDP-9 will run two JMP instructions.

Otherwise the behavior is inconsistent, and the Deposit & Examine doesn't always work on the first try.

This sounds like timing issues, so we need to go through the procedures in the System Adjustment manual.


We did some more debugging on Sunday to determine what instructions work and found that the JMP instruction goes to the wrong address.

After some digging we found a stuck bit-17 in the AC register.

We swapped the B213 module on slot C39 that holds that AC register bit, the B169 in slot A38 that gates the output to the A BUS, and the B169 in slot B38 that gates the input, but did not see any changes.

We have spare B213 and B169 modules so this should be an easy fix.


Well, the fix was not so easy.

After several hours of boards swaps and debugging we eventually found a bad B213 FlipChip in slot C39.

This FlipChip provides bits 16 & 17 in the AC register and was the cause of the stuck bit 17.

After this repair the system ran MAINDEC-9A-D1AA-D PDP-9 Basic Memory Checkerboard Test for a few minutes and then halted at location 223.

This is the correct behavior when it detects a memory error.

The DEC-9A-H0AA-D PDP-9 System Adjustment Manual describes a procedure to adjust:

    • Clamp and Slice voltages in the Core Memory
    • MA Setup, Stagger Delay, Strobe Delay, Pause Delay, and the Write Delay timing in the Core Memory
    • Current Start Delay, Start Delay, Width Delay, Loop Delay, Strobe Start Delay, CLR Position Delay, and Current Delay in the Control Memory
    • And check other system timing and pulse width values

We will run through the System Adjustment procedure And then try it again.

We will also run the MAINDEC-9A-D01A-D_Instruction_Test_Part_I_Nov67 and MAINDEC-9A-D02A-D_Instruction_Test_Part_II_Nov67 to make sure that all of the instructions are working.


We fiddled with the system a little before we made all of the adjustments.

We ran MAINDEC-9A-D1AA-D PDP-9 Basic Memory Checkerboard Test for a few minutes and then halted at location 223.

C(AC) = 000000 = Memory Address where the error occurred

Press CONTINUE C(AC) = 200000 = Correct data word

Press CONTINUE C(AC) = 740044 = Incorrect data word

Press CONTINUE C(AC) = 000000 = Pattern control word, should be a 000000 or a 777777

Hopefully if will behave better after we adjust everything.


We decided to run MAINDEC-9A-D01A Instruction Test Part 1 to make sure that the processor is fully functional.

The diagnostic failed immediately at address 000575, which is E83.

After reading through the source code we restarted the diagnostic at 000551 and single stepped the processor.

This test clears the AC and Link, compliments the Link, and rotates the Link bit left through all of the AC bits.

It failed when it tried to rotate the bit from bit-12 to bit-11.

We swapped the B169 modules between slots B22 and B26 and the error moved to bit 9/10.

We put the B169 from slot B26 back in B22 and put a replacement B169 in slot B26.

Instruction Test Part 1 now runs OK.

In the video below we configured the PDP-9 in Single Instruction mode, locked Continue on, enabled Repeat, and set the repeat speed to the minimum.

This causes the machine to run a few instructions per second so you can watch what it is doing.

The upper register on the right shows the contents of the memory that is being accessed and usually contains the instruction being executed.

The lower display is set to show the AC register, part of the machine being tested.

We were able to successfully run other diagnostics, but not at full speed.


We spend most of the time wiring new AC outlets for the PDP-9, so only a little debug time.

The core memory seems to be working OK even after we fiddled with the voltage and delay settings.

The core memory still needs the final tuning.

We found that the JMP instruction just goes to the next sequential address instead of to the address in the instruction.

That will be our next debuging project.

We also noticed that one of the G882 FlipChips is missing from the TC02 DECtape controller.

We will need to find a replacement before we can try reading/writing DECtapes.

A very generous Anders Sandahl sent us a G882 from his collection.


We did a lot of studying of the circuitry that makes up the Control Memory, known as microcode on a modern computer.

We determined the correct sequence of events, and made a plan to check the Control Memory sequence and why it wasn't executing Control Word 74 for the JMP instruction.

Click on the image for a larger view.

After a lot of 'scope work we determined that we could actually see the signals go active in the Read Only Program memory and could verify which Control Memory words were being executed.

In the 'scope image above the yellow trace is CM CURRENT signal that cause the contents of the Control Memory to be read.

The green trace is the CM STROBE that latches the data from the Control Memory. The signal going positive and negative is actually a DEC standard pulse.

The purple trace CMP7 signal and the blue trace CMG4 are the address lines for the Control Memory that select the Control Word for the JMP instruction.

Oops, you can see in the third sequence where purple goes up and blue goes down that Control Word 74 is being executed.

So much for the out of sequence Control Memory theory.

The last of the four Control Word sequences in the 'scope image is 10, BGN, where it gates the PC into the MB, and waits for the core memory to fetch the next instruction.

The processor will stop at this point if the Single Instruction switch is turned on, which we did.

Now that we knew that Control Word 74 was being executed we verified that all of the bits in the Control Word were being latched.

We quickly found that the PCI bit that latches the new memory address into the program counter was inactive.

That explains why it would not JMP.

We replaced the B213 Jam Flip-Flop module in slot D21 and now the JMP instruction is working again.

Time to go back to adjusting and tuning the core memory and processor, and then on to connecting and debugging the TC02 DECtape controller.


last week we found that one of the Control Memory Flip-Flop FlipChips was defective and replaced it with a spare.

That fixed the PCI (Program Counter In) Control Memory signal, and the JMP instruction.

Unfortunately it looks like we broke many of the other instructions in the process of fixing the JMP instruction.

Each of the B213 modules Flip-Chips, like the one that we replaced, contains two Flip-Flops.

Replacing the B213 in slot D21 fixed the PCI bit, but now it looks like the other half of the FlipChip is broken, and that is affecting the PCO Control Memory signal.

Having a misbehaving PCO (Program Counter Out) signal would explain why many of the other instructions are misbehaving.

We have a few more untested B213 modules we can try, and then it will be time to fix the pile of broken B213 modules we have.

Click on the image of the B213 for a larger view.

We don't have a FlipChip tester that is capable of testing the B/R/S negative logic modules, so we will need to make a bench test setup.

We have a connector module that will hold the FlipChip, and a 3x voltage power supply that we can use to power it.

All we will need for testing is a signal source for a -3V->GND fast pulse for the strobe, and a logic level for the data input.

We even have NOS 2N3009 and 2N3639 transistor for replacements.


We installed the G882 FlipChip Anders Sandahl donated in slot C23 the TC02 DECtape controller.

We borrowed two TU50 DECtape drives from the PDP-8/I. It still has three TU50 drives.

We installed both drives above the TC02 controller in the expansion cabinet and cabled them to the TC02 controller.

We still need to borrow a 779 power supply from the PDP-8/I and also install it in the expansion cabinet.

The 779 power supply will power the TC02 controller and both TU50 DECtape drives.

The bottom controller is the TC-59 for the TU20 1/2" 7-track magnetic tape drive.

The upper controller is the TC02 for the DECtape drives.

The lower of the TU50 DECtape drives is older and has an extruded aluminum frame instead of a cast frame.


We spent the day chasing the JMP instruction not working issue.

We checked the system timing using the procedures in the DEC-9A-H0AA-D PDP-9 System Adjustment Manual.

All of the timing measurements were within specifications.

We checked all of the microcode bits in each microword and found that the PCI flip-flip was not being set in microword 74.

This will prevent the address from the JMP instruction from being transferred to the PC register and prevent the JMP from going to the correct address.

The PCI flip-flip was being set in microword 21, so we knew that the transformer for the PCI signal on the G920 module was OK.

The MBO flip-flop was being set in both Microword 21 and 74, so we knew that the microcode was being executed in the right sequence.

In this 'scope image you can see that the PCI flip-flip was being set in microword 21m and not in microword 74.

It looks like the CMSL13 signal from the G920 transformer is near ground at microword 21, but is near -2V in microword 74.

We think that this is why the PCI flip-flop is not being set.

It will take a lot of investigating to determine why the PCI flip-flop is not being set.


After pondering the Microcode problem for a week we spent an afternoon verifying that the microcode sequence is what we expected.

An instruction starts with Microword 10, then 21, then 12, then it decodes the instruction and with the JMP goes to 74, and back to 10.

The processor will stop after Microword 10 if Single Instruction mode is on.

Click on the image for a larger view.

Lots of 'scope and Logic Analyzer probes on the Control Memory.

Microword 10 was executed before the processor stopped because we had the Single Instruction switch turned on.

We started with Microword 21, then went to 12, then to 74, then to 10, and stopped again.

This sequence shows that the complex logic for determining the next microword in the sequence is working correctly.

We added the CMP 2 (yellow) and CMG 1 (light blue) signals that drive the "21" wire for microword 21.

The purple trace shows the CMSL signal for the PCI microcode bit as it comes from the G920 flipchip.

The state of the CMSL signal is latched when the CM STROBE signal goes high.

In this case the first time the CM STROBE A signal went high the PCI flip-flop was set.

The next time the CM STROBE A signal went high the CMSL 13 signal was low so the PCI flip-flop was cleared.

This is good to see and means that the PCI transformer on the G920 board and the PCI flip-flop are OK.

We changed the yellow and light blue probes to the CMP 7 and CMG 4 signals that drive the "74" wire for the JMP instruction.

The third time the CM STROBE A signal went high the purple CMSL 13 signal should have been high and caused the PCI flip-flop to set.

You can see that the CMP 7 signal went to ground and the CMG 4 signal went to -15V so the drive current for the "74" wire was available.

We didn't see a pulse on the CMSL 03 for MBO, CMSL 18 for LI, or for CMSL 21 for DONE when the "74" wire wa activated.

This leads us to believe that there is a problem with one of the steering diodes or a wire connection on the G920 microcode board.

We will test and hopefully repair the G920 next week.


We finally found the problem with the PDP-9 Processor.

One of the diodes on the G920 Control Memory board had a voltage drop of 1.1V where it should have been about 0.65V.

This slight difference caused the current flowing through the wire for Microword 74 for the JMP instruction to be a little low, and it didn't set any of the microcode bits for that Microword.

The Program Counter didn't get updated with the new target address, so the JMP never happened.

Click on the image for a larger view.

Click on the image for a larger view.

The fourth diode from the top was defective.

The third diode from the top looks like it is cracked, so that one will likely fail too.

The G920 board holds all of the Microcode that controls how the processor behaves.

When a Microword is selected one of the 64 possible wires is connected to ground at the left side of the board, and to -15V on the right side.

This creates a magnetic field in the 36 transformers, and the direction of the magnetic field is determined by the wire being routed through the right or left side of the transformer.

When the -15V is disconnected, the magnetic field collapses, much like in an ignition coil, and it induces a ground or -4V signal in the secondary side of the transformer.

This signal is captured by Jam Flip-Flops for 200nS, and then the cycle starts again.

We don't have a schematic or a BOM for this board so debugging was a challenge.

We found that most of the diodes on the G920 had a voltage drop of 0.65V, but a few had a voltage drop of 0.76V.

These are also candidates for replacement.

We had a selection of diodes in our spares and decided that the 1N4149 was the best fit for this application.

The system now passes Instruction Test 1, Instruction Test 2, the JMP, ISZ, and JMS tests, and the Basic Memory Checkerboard.

It reports a few errors during the Memory Addressing test.

We still need to do the final timing and voltage tuning for the processor and memory, so hopefully that will fix the memory problem.

Finally we will be able to connect the TC02 DECtape controller and the TU55 DECtape drives and start debugging those parts.

Eventually we will get an OS running from DECtape. We could even think about making an emulator for the RS09 disks!


Now that the processor is running again, we tried to finish the Core Memory tuning.

Click on the image for a larger view.

This shows the Core Memory sense strobe in yellow and a composite of many memory reads in aqua.

This is the same as Figure-7 in the PDP-9 System Adjustment manual for adjusting the Stagger Time.

One of the final adjustments is setting the Slice Voltage in the Core Memory.

You run the Extended Memory Checkerboard Maindec, flip a switch to power some of the FlipChips in the Memory Controller from the +10V margin voltage, and then adjust the +10V margin voltage up and down until the diagnostic reports errors.

Then you fiddle with the Slice Voltage setting until the amount you increase and decrease the +10 Margin Voltage to cause errors is symmetric.

In this case adjusting the Margin Voltage all the way up or down did not cause any memory errors.

We need to determine if the Margin Voltage is actually getting to the Memory Controller FlipChips.


The PDP-9 System Adjustment manual says to turn on Margin Switch 7, run the Memory Checkerboard, set the Margin Power Supply to +10V, and adjust the +10V up and down until the diagnostic reports errors.

We did that, but never saw memory errors reported.

We didn't know if the Margin power supply was working correctly so we opened the Memory fan housing that also contains the Margin switches and PCB.

We traced the path of the +10V, and -15V Margin power from the diagnostic control panel, through the wire harness to the switch panel.

We then traced the power through Margin switch 7, through the fuses, to the flipchips that send the power to the Memory Controller.

We then traced the wire-wrap wires that supply the power to just a small selection of flipchips.

Once we knew which flipchips were powered from Margin switch 7 it was rather easy to find pages in the schematics (MC70-B-17) that showed which flipchips were powered from which Margin switches.

In this case Margin switch 7 supplies a reference voltage to pin D of all 18 of the the G009 Sense Amplifiers.

Other Margin switches supply the +10V and -15V power to pins A & B of the G009s.

We will need to verify that the +10V margin voltage on on D of the G009s is being adjusted in a wide range.


We went through the Slice Level Setup procedure in section of the System Adjustment Manual.

We connected a DVM to pin D of the G009 Sense Amplifiers to verify that the +10MC reference voltage was really changing when we adjusted the +10V Margin Voltage.

We adjusted the +10MC voltage on pin D of the Sense Amplifiers +/-7V from the nominal +10V while running MAINDEC-9A-D1BA-D PDP-9 Extended Memory Checkerboard Test.

No memory failures were observed while adjusting the +10MC voltage.

We should have seen memory errors which would have caused us to tune the Slice Voltage.

Oh well, no memory errors is a good thing.

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

We ran MAINDEC-9A-D7AD-D PDP-9 Basic Exerciser.

Since we haven't fixed the paper tape punch yet, it got stuck looking for the status of the punch.

We put NOP instructions in place of the JMP instructions were it was looking for the paper tape punch status, and it runs OK.


Alex is working on LT Spice simulations for the G008 and G009 modules in the Core Memory.

Today we will capture real Core Memory Sense Amplifier signals using our fancy Rigol 'scope, and save them as a CSV file.

We can import the CSV file into LT Spice and use it in the simulations.

After a lot of reading of manuals and Alex studying the G009 schematics we found that when switch #7 is on, the +10 Margin input can be varied +/-10V.

We originally thought that the +/-7V value in the System Adjustment Manual was the limit for the Margin voltage.

The +/-7V is actually the range which the Margin voltage should be able to be adjusted without causing memory errors.

We will rerun the MAINDEC-9A-D1BA-D PDP-9 Extended Memory Checkerboard Test and vary the +10 Margin through the whole range of +/-10V.

Then we can tune the Slice Voltage to make the Margin that causes memory errors symmetric.

We adjusted the +10 Margin Voltage to the Sense Amplifiers through the range of 2V to 20V.

At the high end of the range there were infrequent errors on bit-8.

We swapped the G009 Sense Amplifiers for bit-8 and bit-9, but it didn't make any difference.

There is a Digit Driver board for each bit, so we swapped the board for bit-8 and bit-9, but it didn't make any difference.

We decided to leave the Slice Voltage adjustment as it is, and declare it fixed.

Next we can mount and wire the power supply to the TC02 DECtape controller and the TU55 DECtape drives.

If we get through that, we can try some of the TC02 diagnostics and see if the controller responds.


We measured the output voltages from the G008 Slice Control so Alex can simulate the G009 Sense Amplifier.

When Halted, Pin H Slice: 5.50V, Pin M 1st Clamp: -11.23V, Pin N: 2nd Clamp: -8.95V.

When Running Checkerboard, Pin H Slice: 5.53V, Pin M 1st Clamp: -11.08V, Pin N: 2nd Clamp: -8.80V.

We inventoried the FlipChips in the TC02 DECtape controller


    • A10, R002, Installed unknown condition R002
    • B10, S123, Installed unknown condition slower R123
    • E17, S203. Installed unknown condition slower R203
    • D14, S127, Holds an S107, need to compare to other TC02s (Looks like this is correct and the error in the documentation was fixed in later versions)
    • D19, empty, board is in C19
    • D20, empty, board is in C20
    • D24, R113, Installed unknown condition R113
    • D28, S202. Installed unknown condition slower R202
    • E17, S203. Installed unknown condition slower R203
    • E30, S002, Installed unknown condition R002


Anders will trade an RK05 blower motor that I have for the missing S modules for the TC02 DECtape controller.

Much easier to put the right flipchips in instead of changing resistors on the R modules to convert them to S modules.

Click on the image for a larger view.

We made an LT Spice simulation of the G008, G008, and G010 FlipChips so we can understand how the core memory works.

The two signals in the top pane are the sense wire outputs from the bottom 4k field of core memory.

The red signal in the bottom pane is the output from the sense amplifier, and the grey is the strobe that causes the data to be latched.

Other than an enable signal not working yet, the simulation is doing what it is supposed to.

It is pretty amazing that the sense amplifier can extract good data from the noise on the sense wire.

The input signals to the the LT Spice simulation is actual sense wire data from the PDP-9 captured with the Rigol 'scope.

Newer versions of computers use a monolithic integrated circuit sense amplifier that replaces the complete G009 FlipChip.


We received S series FlipChips from Anders to fill the empty slots in the TC02.

We wired the DC power to the TC02 DECtape controller and the two TU55 DECtape drives that we recently installed in the PDP-9 I/O cabinet.

We were not sure that the power supply for the TC59 that was already installed in the cabinet had enough output to also power the TC02 DECtape controller, and two TU55 DECtape drives.

Click on the image for a larger view.

When we first powered on the cabinet the +10V and the -15V from the power supply would not go to up to the normal voltage range.

I was quite close to the wiring while checking the voltages and then this electrolytic capacitor blew with a big bang!

The voltages then went to and acceptable range, so we knew where all the power was going.

The bridge rectifier on the power supply is getting quite warm, so we will replace the power supply with a larger one.

Click on the image for a larger view.

We still need to make ribbon cables to connect the indicator panel to the TC02 controller.

Without the cables installed all of the indicators should be on.

It looks like we have some bad connections, and possibly bad transistors on the indicator panel to debug and repair.

After we get the wiring completed we can see if the TC02 will talk to the PDP-9.

The TC02 is very similar to the TC01 DECtape controller that is in the PDP-8/I, so we are familiar with how it works and how to debug and repair it.

Once we get the TC02 controller and one of the TU55s drives working we will need to make a PDP-9 Advanced Software System Keyboard Monitor System DECtape and see if it will boot.

We will use the Dave Supnick's SIMH PDP-9 simulator to Sysgen an ADSS DECtape image to match our PDP-9's configuration.

Then we can use a PDP-8/e with a TC8E DECtape controller to write the PDP-9's ADSS DECtape.

Maybe, just maybe, we can get ADSS to run on the PDP-9.


The original power supply in the I/O cabinet for the TC59 Magnetic Tape controller didn't have enough power to also feed the TC02 DECtape controller.

We added another +10V/-15V power supply just for the TC02 and TU55 DECtape drives.

Now the supply voltages for everything in the cabinet are OK.

Click on the image for a larger view.

We replaced all of the defective bulbs in the indicator panel, and now they all light up.

The only thing left to do before debugging the controller is wire the 115VAC power for the TU55 motors, and make 3x indicator panel cables for the TC02.

Maybe next Saturday we can wire up the I/O cables, load the TC02 Basic Exerciser and see if the controller is alive.


We borrowed the Indicator Lamp Cables from the TC59 Magnetic Tape Controller for temporary use in the TC02 DECtape controller.

The TC02 powers up OK, but there is no response to any IOT instructions from the processor.


During the week we discussed the unresponsive TC02.

The first thing that we need to check today is the S107 Inverter module in slot D14.

We suspect that this is broken and preventing any of the W103 modules from decoding instructions.

Turned out that the S107 was fine.

There are margin switches on the left of the TC02 chassis that disconnect the normal power supplies and connect to an adjustable power supply in the processor cabinet.

We had not installed the margin power cable, and some of the margin switches were turned on, so there were parts of the TC02 that were not powered.

Turning all of the margin switches off got power to all of the TC02.

With all of the TC02 powered we see more reasonable behavior on the indicator lamps.

There are still problems with the IOT instruction decoding.

The maintenance instruction to load the Data Buffer works, but the Data Buffer is not cleared first.

The instruction to clear Status Register A doesn't work.

The instruction to XOR the AC with Status Register A loads the register and immediately clears it.

The instruction to read Status Register B doesn't work.

All of these instruction decoding issues may be timing related.


After a few hours of debugging we found an R202 Dual-Flip module in the slot where an R002 Diode Cluster module should have been.

This prevented all of the Status Register A related IOT instructions from working.

Now we can select a DECtape drive and tell it to go forward and backward.

There is still an issue with selecting DECtape drive 1 that we need to debug.

The Status Register B instructions still have issues.

If we read Status Register B the contents don't stay in the AC for long.

This could be a problem in the Processor or the TC02 DECtape controller.

There are two undocumented maintenance instructions that let you read/write the Data Buffer in the TC02.

Writing to the Data Buffer ORs the AC with the Data Buffer.

My guess is that the Data Buffer is not being cleared first.

On the TC59 Magnetic Tape controller you can execute an IOT instruction to force a data break.

You can read/write the Data Buffer to see of the data break worked correctly.

There is one unused decoded IOT instruction on the TC02, so maybe we can implement this same test capability.

We are making progress, but are not read to run diagnostics yet.


We can read now the Status Register A.

The Idle indicator is on when the controller is idle.

We can force a Select Error by selecting a drive that doesn't exist or executing Command 7, Select Error.

We can read now the Status Register B.

Loading a Move command into Status Register A causes the GO signal to the tape drive for 160ms and then it sends the STOP signal to the tape drive

The END error indicator is on, so it thinks that the tape went into the End Zone

The PWR CLR + ES signal goes high for 200ns and is clearing the MR1 flip-flop which clears GO

The END(1) signal on E27D goes high 160ms after the command which cause the PWR CLR + ES to go high

TP0 pulse 160 MS after command and MK END is high to it sets the END FF

TP0 should not go on until UP To Speed is active

0->WINDOW is high, and 150ms after the command goes low, then goes high after error

The Window Shift Register is active after the move command is sent, and eventually contains the code for END and stops the tape.

Where is the data for the Window Shift Register coming from? The G882s oscillate until they see real tape data

Why is TP1 active before the tape is up to speed?

Why is TP ENABLE active without the tape moving?

SWTM\ on D24J is not low enough, -1.8V, and is enabling TP ENABLE

Swapped S107 in slot C18, no change

Removed R113 in slot D24, no change

Is there another FlipChip connected to SWTM\?

The plan is to pull of the FlipChips that drive and sink the SWTM\ signal, make sure that the wiring is OK, and then put the FlipChips back one at a time

Hopefully we can find one that is loading the signal too much.


I looked at the SWTM and SWTM\ signals in the TC01 DECtape controller in the PDP-8/I

The signals are wired through an S107 Inverter FlipChip and go between -3.8V and -0.4V when active and not active

Time to investigate all of the connections to SWTM\ on the TC02

We found another slower R202 where the faster S202 belongs, and replaced it with the correct part

After removing and replacing all of the FlipChips tied to the SWTM\ signal it is now -2.3V when active

The END error is no longer present when we command the TU55 DECtape drive to move

We don't see the GO signal go active at the TU55 command cable and STOP is active

The X STA signal on the input pin H of the S107 in slot C18 is a nice -4V pulse, but the inverted output on pin F only went to -1V

We replaced the S107 in slot C18 of the TC02 with a spare

The XSA DY signal looks OK now

GO at the DECtape Control cable goes active for 150ms and then goes inactive

The END error indicator is on, so we are back to chasing the original issue from yesterday

Mattis kindly punched the DECtape diags and DECtape formatter for us

I formatted a DECtape in PDP-9 format on my PDP-8/e

It was a little confusing because the word size in the formatter questions is in 12-bit words and the tape specification for the PDP-9 has 18-bit words

I think that I had it right with 384 decimal words to make 600 octal 12-bit words or 400 octal 18-bit words per block

The DECtape block size is the same on the PDP-9 and the PDP-10, but the PDP-10 uses it as 200 octal 36-bit words


We had LOTS of visitors today, so we didn't get much done on the TC02 debugging

We still see the END error go on about 160ms after we command the TU55 DECtape to move

We checked all of the circuitry that clears the Window Register that holds the Mark Track data

All of the signals that start the R303 170ms Integrating One-Shot in slot C20 running are working OK

That One-Shot starts another 70us One-Shot in slot C19 running

That One-Shot sets the UP TO SPEED Flip-Flop in slot D27

The Flip-Flop gets inverted by the S107 in slot S22

The rising edge of the signal from the inverter clears the Window Register

Unfortunately by the time the Window Register is cleared the random data from the G882 modules is decoded to make the MK END signal

The MK END signal is gated by the TP0 pulses and sets the END Flip-Flop in slot E28

At this point the STOP Flip-Flop clears and the tape drive motion stops

We need to determine why the END error is going on

Are the TP0 pulses supposed to go to the END Flip-Flop this soon?

It looks like TP0 is enabled by TP ENABLE, which is enabled by UP TO SPEED (1)

When UP TO SPEED goes active it creates 0 -> WINDOW which will clear the WINDOW register

We should check again to see when the TP0 pulses go active

We should verify the One-Shot timing for U = M to make sure that it is set to 140 ms


The R303 module in slot C20 needed to be readjusted to have pin D go low for 140ms (see page 10 section B2 in the schematics)

Adjusting the module did not improve the TU55 DECtape drive behavior

140ms after the Move command the UP TO SPEED flip-flop goes active and 0->WINDOW goes inactive

About 8ms after UP TO SPEED the MK END error signal goes high (see page 8 section C7 of the schematics)

It looks like the problem is in the TU55 DECtape drive

With a tape in place, if I manually spin the drive reel, the controller is happy until I stop spinning

Now I suspect that the drive motor is not switching from the tension to the drive mode when commanded to move

The drive works correctly when in the LOCAL mode, but not in the REMOTE mode

The motor control circuits must be working OK when controlled by the switches, but not by the tape command bus interface

The control bus signals look OK on both sides of the W513 module in slot B07 in the TU55 DECtape drive

We chased the signals that control the MOTION and DIRECTION flip-flops

The DIRECTION flip-flop works OK from the bus, but not the MOTION

It looks like ALL HALT is always on

This signal stops the tape motion if the processor halts

We looked at the RUN (1) B2 signal in the TC02 that is ALL HALT in the TU55

It doesn't change when the processor is running or halted

We looked at RUN (1) B from the processor, and it changes when the processor is running or halted

The S107 inverter in slot F18 that makes the RUN (1) B2 from RUN (1) B is broken

We don't have a spare, so we will need to fix it


Transistor Q5 on the S107 in slot F18 in the TC02 controller was completely open

We replaced the Q5 transistor on the S107, but it didn't fix the inverter

Then we discovered that the leads on the replacement transistors were CBE on the EBC on original transistor

We removed and reversed the transistor, and now the inverter works OK.

In the process of testing and comparing several S107 inverters we found a bad Q2 and D3 clamp diode

Yay, the DECtape now moves when we send a MOVE command to the TC02 DECtape controller

We loaded the paper tape for MAINDEC-9A D3BB-PB TC02 Basic Exerciser that Mattis Lind punched and sent us

We ran test #0, Basic Motion

This test puts the tape in Forward Motion and watches for the End Mark on the Mark Track, then reverses the motion of the tape

You can see from the indicator lights that the TC02 controller behavior is not correct, so more debugging is needed

We also tried test #11, Instruction test

This immediately halted at 03762, so the controller is generating an interrupt when it should not

One more thing to fix...


Today MAINDEC-9A D3BB-PB TC02 Basic Exerciser test #11, Instruction test, is halting at 004021 with bit #9 on in the AC

This means that Status Register A could not be set and read back with the same value

The diag will run when single-stepped at a slow repetition rate.

So we probably have a partially failing FlipChip.

We tried the motion tests that start at 004222.

It halts at 004405 where it should interrupt when PIE=1

Not sure what that means yet, or what is broken.


We continued with MAINDEC-9A D3BB-PB TC02 Basic Exerciser test #0 that just moves the tape from end to end

After a few minutes the tape stopped moving

The FWD and REV signals to the TU55 tape drive were both active so it would not move

We found a bad Q4 transistor on the S107 inverter in slot A09

We replaced the transistor and now the DECtape drive moves again

We looked at the data from the TU55 while it was in motion

Timing Track, Mark Track, Data 1, and Data 2 all looked OK

Data 0 looked really crappy

The input on Slot C26 Pins D & J from the tape head has a -500mV bias and should have none.

The input on pins K & D looks OK

We disconnected the data cable to the lower (not debugged yet) drive, no change

We measured the resistance of the head coils and found that the D0+ connection was open

We replaced the head with one from a drive that was in poor condition and that was donated by Victor Nahigian a few months ago

We measured the replacement head before we removed it to make sure that it was OK, it was

The data looks OK now, and running MAINDEC-9A D3BB-PB TC02 Basic Exerciser test #0 still moves the tape from end to end

This means that at least the Timing and Mark tracks are being read and interpreted

We tried MAINDEC-9A D3BB-PB TC02 Basic Exerciser test #1, Search Scope Loop

We can see block numbers counting in the AC when this is running

That means that a large amount of the TC02 controller and the TU55 DECtape drive is working now

Oops, the core memory broke

Everything reads as zeros

I guess that is what we will work on tomorrow


The memory is working again

The B310 delay line in slot EF36 that takes CLK and makes POST CLK\ had a non-monotonic output on pin FU so the B602 pulse amplifier in slot E34 that takes POST CLK\ and makes POST CLK was double triggering

That made a mess of the core memory subsystem timing

We replaced the B310 with spare and are back to debugging the TC02 DECtape controller

Alex found a bad diode D7 on the B310, so we will repair it and put it back in the PDP-9.


Bit 1 from the DECtape is not getting latched into the RWB 4 Flip-Flop

It looks like the S603 Pulse Amplifier in slot C17 has a dead pin M output.

Mike Lill found a bad DEC-664 diode D20 and Emilio replaced it with a 1N4149 diode

We put the S603 back in the TC02 and now the RWB 4 flip-flop is working

The R201 Flip-Flop in slot C02 for RWB1 would not latch tape data so we were missing one bit of the data from the DECtape

We replaced it with an unknown spare and got lucky, it works

Mike Lill found a bad transistor on the broken board, so we will replace it and add it to our spares.

Alex found that the diode D7 on the B310 delay line from the core memory was a diode in one direction and a resistor in the other

He replaced D7 on the broken B310 in slot EF36 in the Core Memory with a 1N4148 and put the B310 back in the PDP-9

The memory is still working.

Ran MAINDEC-9A D3BB-PB TC02 Basic Exerciser test #1, Search Scope Loop

We can see the block number in the AC on the console display count up and down as the tape moves from end to end

Ran MAINDEC-9A D3BB-PB TC02 Basic Exerciser test #4, Search Find All Blocks

Printout said that there was no interrupt when it found the end of the tape.

ENI(1) on pin P of the R113 in slot D18 is not low when pin R goes low (schematic page 16 section B2)

ENI Flip-Flop goes on for 200ns and then turns back off

I swapped the S202 dual flip-flop from slot A05 with another from A4, and now the interrupt enable stays on.

That means that the problem is in the S202 on slot A5

We have lots of spare R-series flipchips, but very few spares of the faster S-series flip-chips

Mike Lill checked all of the diodes and transistors on the S202 with a DVM, but all looked OK

We will have do some active testing to determine what is broken on this flipchip, and then repair it


Since we are only using TU55 drive #0 we don't need any bits in the USR part of Status Register A

We tagged the misbehaving S202 flipchip from slot A05 so we can fix it later

We swapped the S202 flipchips between slots A01 (bits 0 & 1 of the USR) and A05 (FR bit 3 and IEN) in Status Register A

We ran MAINDEC-9A D3BB-PB TC02 Basic Exerciser test #11, TC02 Instruction Test

Halted at 04034

This is much further in the diag that we have gotten before, so the behavior of Status Register A seems to have improved with the S202 flipchip swap

This part of the diag is testing the XOR capabilities of Status Register A

The AC contains a copy of Status Register A, which should be all zeros

The AC contained 002000 so bit #7 is on and should not be

We swapped the S202 flipchips between slots A02 and A04 to see if the Status Register A issue would move

This time the diag halted at 04657, so moving the S202 modules again improved the behavior of Status Register A

It is possible that some of the transistors on the S202 modules now in slots A01 and A02 have low drive capability, and these slots have a lower load than slots A04 and A05

The halt at 04656 is where the diag was waitied 56 ms for a second databreak (DMA), and it didn't happen

The MR (Mark Track Error) light is lit, so it is possible that the MR error stopped the tape and therefore stopped the second databreak from happening.

The MR error could be from tape head skew because we replaced the tape head, problems with the tape that I formatted on my PDP-8/e, or problems in the TC02 controller

I will format another DECtape in PDP-9 format, and we can also try a PDP-10 tape we have to eliminate the tape format problem

We can borrow a different TU55 from the PDP-8/I to eliminate the tape head skew problem

We can continue digging into the TC02 controller to see if something else is broken


So, three issues with the TC02 to fix; interrupt when it when it shouldn't, no interrupt when it should, and a Mark Track error when reading tape

We will work in the Mark Track error first

We ran MAINDEC-9A D3BB-PB TC02 Basic Exerciser test #11, TC02 Instruction Test

Tried three more DECtapes, two formatted on my 8/e (one on the left drive and one on the right drive), and one formatted on the PDP-10 at UNH in the 1970s

All tapes show the same error in the same place on the tape

That eliminates the DECtape formatting as the source of the problem

The problem is either in the electronics in the TC02, or is caused by a head skew problem in the repaired TU55 tape drive

We will swap the TU55 with one from the PDP-8/I so we can eliminate the replaced tape head as a source of the problem

We looked at the signals that can set the MKTK flipflop on sheet 5 of the TC02 schematics

Rising edge of C0 (0) and the signal E28J being at ground sets the MKTK flipflop

E28J goes low just 250ns after the rising edge of C0 (0)

ST IDLE (0) going high causes E28J to go low

This looks like it might be a timing error in C0 (0) where the C0 (0) rising edge is a little early and causes the MKTK flipflop to set

The TC02 timing diagrams show the period of the C0 (0) pulses being consistent

In this case the C0 (0) pulses period was short

The Counter is driven by the TP0 pulses which are derived from the READ T TRK (0) pulses that are derived from G882 and the timing tracks on the DECtape

We need to look at the Timing Track data because that is most sensitive to tape head skew


I rewired the AC power in the I/O cabinet that feeds the TU55 tape drives, and the main power cord

Now the wiring looks like DEC did it at the factory

I thought that the interrupt issue might be easier to fix than the MKTK error, so I looked into that

The MAINDEC-9A D3BB-PB TC02 Basic Exerciser test #11, TC02 Instruction Test is halting at 03762 saying that it is interrupting when there are no DT or DFT flags

Both the ENI(1) and the BEF(1) v BDTF(1) signals are at ground (inactive), so the INT signal is also at ground (Inactive)

The REQ(1) and INT signals going into the S111 module at F16 are both at ground (inactive) but the output PROG INT REQ on the I/O bus is at ground (active)

I checked all of the diodes and transistors on the S111 module, and all looked OK

Pin T on the S111 module is slightly below ground, so the transistor Q3 on the S111 module should be off, and PROG INT REQ signal should be -3V (inactve)

I swapped the S111 module and there was no change

Something else on the PDP-9's I/O bus must be pulling the signal high

That was a wild goose chase

I didn't have the console terminal connected, so the TTY input port was generating the interrupt request

I connected the console terminal, and now it halts at 04656 with a MT error

I will work on that next weekend


I looked at the TP0 and TP1 signals on page 10 that are derived from the timing track

They both look OK

I looked at the C0, C1, and C2 signals on page 6 that are derived from the TP0 signal

They all look OK

I triggered the 'scope on MKTK error asserted and then ran MAINDEC-9A D3BB-PB TC02 Basic Exerciser test #11

I looked at the MK TRK data going into the Window Register W9 flip-flop and the TP1 strobe

This looked OK.

I looked at the rest of the Window Register flip-flops and could see the data shifted through the register

When I got to the W1 register it was not latching the data from the W2 register

I swapped the S203 in slot E29, but it did not make a difference


From the prior work sessions we saw that the Window Register in the TC02 is not working correctly

The bits from the Mark Track are first latched into the W9 flipflop, and then are shifted left through the Window Register

The chart below shows the Mark Track Control Code for the Reverse End Mark being shifted into the Window Register until the 55 is in W4-W9

The next Reverse End Mark will leave a 555 in the Windows Register, and this pattern will repeat until the Interblock Sync Mark shows up

Then the Windows register eventually gets contains a 725 and triggers the C-SYNC signal

We can connect the logic analyzer to the Window Register and C-SYNC signals at slot D31 to see if this pattern is showing up

I don't think that the W1 flipflop will latch a 1, and will cause problems

I have the Rigol 'scope/logic analyzer connected to the Window Register bits, 0->WINDOW, and TP1 signals.

If I trigger on 0->WINDOW I can see the Mark Track bits shift through the Window Register

I can also see the W1 flipflop latch the data from the W2 flip-flop, so the S203 is actually working OK

If I trigger on the MKTK (Mark Track) error flip-flop I can see the last state of the Window Register that set the MK error

It looks like the last Mark Track Code that was received was Reverse Guard Mark (32)

The previous Mark Track Code can only be a Forward Block Mark (26)

Window Register bits 2 & 3 contain a 1 & 0, so this is the last bits from the Forward Guard Mark

This looks OK, so this Window Register contents should not have set the Mark Track error condition

Looking at the MKTK flip-flop on schematic page 5

180us before MKTK gets set pin J goes high, then pin H C0(0) goes high and sets the MKTK flip-flop

E31 pins K & L are both low, and pin M goes low 180us before MKTK gets set

E30 pin p ST BLK goes low 180us before MK TK gets set

I think that this is OK and is just indicating that BLK START went high

The ST REV Ck state is set 200us before the MKTK error gets set

This error gets set even when doing a SEARCH looking for block numbers

The ST BLK MK flip-flop is cleared 200us before the MKTK error gets set

The ST REV CK flip-flop is set 200us before the MKTK error gets set

The DATA flip-flop is never set, so we need to determine why the TC02 is not happy when it sees the Reverse Guard Mark while searching


We looked at all of the Mark Track decoding signals on page 8 of the schematics

It looks like all of the Mark Track decoding circuitry is working, but inconsistently

I think that sometimes it is missing the beginning or end of a block

D15: 0->WINDOW

D14: (100)->C0-2






D08: MR0

D15: 0->WINDOW

D14: (100)->C0-2






D08: MKTK Error

This shows MK BLK START going active at the beginning of a block, then MK DATA for the block, then MK BLK END at the end of the block,

then MKTK going active to indicate a Mark Track decoding error

Time to look at all of the inputs to the MKTK flip-flop to see what is triggering the error


During the week I studied the Mark Track decoding to understand the sequence of events when Mark Track is read

We connected the logic analyzer to the outputs of the flip-flops in the State Register.

We could see the IDLE state latching into the ST BLK MK flip-flop

We could see the ST BLK MK state latching into the ST REV CK flip-flop for about 30 ns, and then it would revert back to the previous state

We replaced the S202 in slot F27 with an R202 but it didn't make any difference

We looked at the S123 in slot F14 because it is connected to the ST REV CK (1) Black Diamond output

Transistor Q3 that drives ORs the ST BLK MK (1) and the MK BLK START signals and drives the N output to the SH ST EN signals is completely open

We replaced Q3, and noticed that the emitter and collector pins on the replacement transistor were reversed from the original

This failure caused the STATE shift register to not transition from the ST BLK MK to the ST REV CH state and caused problems with the MARK TRACK decoding

D15: ST IDLE (1)

D14: ST BLK MK (1)

D13: ST REV CH (1)

D12: DATA (1)

D11: ST FINAL (1)

D10: ST CK (1)

This shows the STATE shift register correctly moving through the Mark Track decoding states

When running MAINDEC-9A D3BB-PB TC02 Basic Exerciser test #1, the block numbers displayed in the AC look good

The Data light in the STATE display is constantly on and the DTF light is flickering

This indicator display looks very good

When running MAINDEC-9A D3BB-PB TC02 Basic Exerciser test #2, it continuously reads data from the tape, hits the end zone, reverses, and reads until the end zone

This looks like it is also running without errors

When running MAINDEC-9A D3BB-PB TC02 Basic Exerciser test #3, it continuously writes data from the tape, hits the end zone, reverses, and reads until the end zone

This looks like it is also running without errors, even using different data patterns

When running MAINDEC-9A D3BB-PB TC02 Basic Exerciser test #4, it continuously reads blocks from the tape, hits the end zone, and prints a message about finding block 1101 and wanting block 1102

This looks like it is also running without errors, even using different data patterns

When running MAINDEC-9A D3BB-PB TC02 Basic Exerciser test #5, it continuously writes data on the tape, hits the end zone, reverses, and reads until the end zone

We had an issue with text #4 complaining about the number of blocks on the tape. Telling it that we had PDP-7 tapes fixed it.

This looks like it is also running without errors

When running MAINDEC-9A D3BB-PB TC02 Basic Exerciser test #6, it continuously writes data on the tape while fiddling with the parity, reads the tape back and verifies the parity, hits the end zone, reverses, and reads until the end zone

This looks like it is also running without errors

When running MAINDEC-9A D3BB-PB TC02 Basic Exerciser test #7, it reads blocks from the tape, asks for a Compare or Print, and prints a message with the block numbers

This looks like it is also running without errors, even using different data patterns

When running MAINDEC-9A D3BB-PB TC02 Basic Exerciser test #10, it reads blocks from the tape, stops, turns around and reads blocks

This is used to check the torque and brake settings

This looks like it is also running without errors, even using different data patterns

When running MAINDEC-9A D3BB-PB TC02 Basic Exerciser test #11, it runs for a few seconds and then prints END on the console

I guess that this means that the controller passes the instruction Test!

You can watch the video of the random read/write test here:

This means that we likely have the only running PDP-9 on the planet, and definitely the only PDP-9 with working DECtape.

The next project is to modify the dump/rest programs to write an ADSS boot DECtape in PDP-9 format on my PDP-8/e

Then we need to punch an ADSS bootstrap paper tape, probably on the ASR33 Teletype

Then we can see if ADSS will boot and run on the PDP-9

Another project is to implement the H34 graphics option on the PDP-9 so we can run Spacewar


During the week I booted some of the DECtape images made by Anders on SIMH, and sysgened two for the smaller configuration we have on our PDP-9.

I worked with Dave Gesswein to modify his resttd8e program to make DECtapes with the larger blocksize used by the PDP-9.

Earlier I wrote a PDP-9 disassembler, and made a listing of the DECtape bootstrap for ADSS.

I started commenting the ADSS bootstrap so I could understand what it does.

I swapped a lot of email with Bob Supnick, the author of SIMH. He said that the PDP-9 uses both checksums in a block, so the ADSS tape that I wrote on the PDP-8/e should read OK on the PDP-9.

Bob also sent me the source for several ADSS bootstraps, so I can reconstruct the source for the PDP-9 bootstrap.

I toggled in the ADSS bootstrap and tried both of the ADSS DECtapes that I made on my PDP-8/e.

The block is being read from DECtape into core, but the contents is not what I expected to see.

The LPB contents are different on different boot tries

The place on the DCtape where it detects the parity error is different on different tries.

It looks like the ADSS DECtapes that I made on my PDP-8/e don't contain good data.

We got the broken GNT 4601 paper tape reader punch from the warehouse.

Dawson, our new volunteer from U of M in Duluth, found the schematics and manuals for the reader/punch.

The rubber grommets that isolate vibrations from the punch motor have "perished".

I stuffed some folded paper under the motor to put enough tension on the belt to keep it in place.

When we plugged it in the RIFA capacitor made an incredible amount of really stinky smoke, so we just cut it out.

After fiddling with serial cables, and using an RS-232 breakout box, we were able to punch the ADSS bootstrap that came with SIMH.

To cold boot ADSS you just put the bootstrap in the paper tape reader and press the READ IN switch.

The bootstrap loads, runs, and tries to read the DECtapes.

Sometimes the DECtape boot actually completes, but ADSS doesn't start.

Last night I dumped the ADSS DECtapes that I made and looked at the contents with a SIMH media tool that I wrote.

The dump of the ADSS tape showed that the tape was far from correct.

I am now fiddling with modified dumprest for 18-bit images.

Hopefully I will be able to determine why the tapes were written incorrectly and make a good ADSS DECtape.


None of the ADSS DECtapes that I formatted and wrote on my PDP-8/e & TD8E will read correctly on the PDP-9.

Looks like I have some homework to do. I will write tapes and read them back to see what I get.

I tried to run the DECtape formatters from the paper tapes that Mattis punched for us.

The EUFB version halts after the BIN loader runs and reads one frame from the paper tape

The EUFA version doesn't like the input from the VT220 that we have been using for a console.

Entering a "0" for the DECtape number loads a 360 in the AC instead of just a 060.

No matter what characters I enter the 3xx is added to the entered character.

Maybe there is a problem with the VT220 or the serial input board on the PDP-9.

I tried our current loop to RS-232 adapter and the result was the same.

I even tried it with a Teletype, and the result was the same.

Time to fix the TTY input circuitry. Probably a broken S202 flip-flop.


I swapped a lot of email with Anders, Mattis, and Josh about dumping and restoring PDP-9 DECtapes.

Anders modified the PC side of the Dave Gesswein's dumptd8e.c to reformat the data read from the DECtapes into SIMH PDP-9 format.

I need to make the same set of modifications to resttd8e.c so that the data from the SIMH PDP-9 file can be written by a PDP-8.

This will be some non-trivial work, so we may not get ADSS running for a few weeks.

In the mean time I will fix the TTY input circuitry.

I was also thinking about using the TC02 diagnostics to write a data pattern on a DECtape.

Then I can use the DECtape with known data on it to test the ability to read/write PDP-9 DECtapes my PDP-8/e.


I wrote a little program to read the serial console port into the AC

It looks like bit 10 is always on

The F5 key on the VT220 will make bit 10 blink, but it goes back on solid

We swapped the S202 flip-chips in slots B34 & B35, but there was no change in the behavior

We swapped the B141 flip-chips in slots B11 & B13, but there was no change in the behavior

More debugging next week

Oops, I tried to read a paper tape, and it failed

So, maybe there is something wrong one of the B141 flip-chips


I put the B141 flip-chips back in their original B13 & B11 locations and now the paper tape reader works OK

That means that there is something broken on one or both of these flip-chips, but it is not affecting anything that we are using

We will eventually debut these two flip-chips and repair them

I read the DECtape Formatter documentation from the PDP-15, and it says that you can't format a DECtape on unit 0

That non-unit 0 restriction was not mentioned in the PDP-9 DECtape formatter documentation

I tried formatting a DECtape after setting the TU55 to unit 1, and it would not select the drive

It works OK when the TU55 is set to unit 2

There is something broken in the drive select logic in the TC02 DECtape controller, or in the TU55 DECtape drive

Setting the DECtape formatter program to 256 (decimal) word blocks and 576 (decimal) blocks on the tape ran off the end of the tape

Setting it to 256 word blocks and 10 blocks worked OK

At least we know that the formatter program works OK, and so does the hardware

Time to experiment with the number of blocks to see what will fit on the DECtapes that we have

510 256 word blocks fit on the tape, more blocks doesn't fit.


Charles Lasner and I talked about the DECtape formatting problem, and decided that either the DECtape motors are running slow, or the timing track clock signal is slow

The motors in the TU55 are AC synchronous, so they can't run slow

There is a R401 clock flipchip in the TC02 DECtape controller that generates a 120kHz reference signal for the timing track

This clock is only used to format a DECtape, and was used for the first time yesterday

We found that the clock is running at 114kHz, so the tape would take longer to format, and will run off the end of the tape

With the clock adjusted to 123kHz it does not run off the end of the tape

Adjusted to 121kHz, it does run off the end of the tape

We looked at the CK0 flip-flop that should have a 33.3uS period per line of tape

We adjusted the clock to run a little fast, and this period is 32.2uS

We formatted two tapes, and will try to dump them on my PDP-8/e

The contents should be all 777777 in the data blocks

If the tapes work on my PDP-8/e, then the next project is to write the code to dump a SIMH ADSS tape to a real DECtape on my 8/e

We are getting really close to getting ADSS to boot on the PDP-9


We reached a major milestone today with the PDP-9.

We got it to boot the ADSS V4E monitor from DECtape.

We still need to repair the second TU55 DECtape drive, the second power supply, and the paper tape punch, so we are not done.

Tomorrow we will try some other versions of ADSS to see how they run.


We tried ADSS-15 V5A, and ADSS V4E Master. Both cause parity errors

The ADSS-15 V5A that was sysgened for an 8k core machine boots, but it doesn't include the non-EAE math libraries

The other four ADSS tapes that we made show parity errors when read.

Maybe there is a tape head misalignment between my PDP-8/e and the PDP-9?

We connected an ASR33 to the console port.

Much better experience than the VT220

Looks like I need to do some work with SGEN to build a version of ADSS for our little 8k system.

We also need to get the second TU55 DECtape drive working if we want to do a SGEN on the PDP-9


I am working with Bob Supnick to get ADSS to work correctly on our PDP-9.

It looks like the problem is devices that are included in the ADSS configuration that are not on our PDP-9.

Bob is going to see if he can "patch" out the unsupported IOT instructions and get ADSS to work correctly in SIMH.

If so, then we can make another physical DECtape and then boot it on our PDP-9.


We tried booting different versions of ADSS made from different SIMH tape images

Version 4E and earlier either constantly or periodically get IOPS4 errors

This means that a device is busy, so it can't run and application or boot the OS

All of these DECtapes were made from SIMH images that were sysgened for larger machines and include support for peripherals that we don't have

We will need to modify the SIMH tape images to remove the peripherals that we don't have, and make new physical DECtapes

ADSS V5A and V5B when sysgened for an 8k system get an IOPS1 error on the PDP-9 or SIMH

I suspect that this newest version of ADSS doesn't like running on our little 8k machine


I made new ADSS DCtapes for two different V5A distributions

These DECtape images worked OK on an 8k SIMH PDP-9

I noticed that only the small versions of FORTRAN and MACRO, F4I and MACROI would run in 8k

I also noticed that these small versions don't use DATs for I/O redirection

They are hard wired to use DT1 for input and DT2 for output

That means we will need three TU55 DECtape drives on the PDP-9

I tried to boot one of these new DECtapes and found that the PDP-9 is not running correctly

Time to load instruction test #1 and see what works


After being powered on for an hour it started behaving OK.

Monitor V4B Master booted OK, but trying to run any application causes a .SYSLD 4 error

Monitor V4E booted OK, but trying to run any application causes a .SYSLD 4 error, and sometimes gets a PAR error

Monitor V4E Master gets an IOPS 4 error and does not boot

Monitor V4E booted OK, but trying to run any application causes a .SYSLD 4 error

Monitor V5A BDC gets a PAR and TIM error when booting

Monitor V5A Master gets a PAR and TIM error when booting

I will reformat the last four DECtapes and rewrite them


Bob Supnik (the creator of SIMH) found that the ADSS .SYSLD 4 error is caused by a problem in one of the values passed to the DAT checking routine

That explains why we can't get ADSS earlier than V5A to behave in an 8k of core configuration

Looks like we have some ADSS debugging to do


We got ADSS V5A to boot from DECtape after a few tries

Applications like MACROI, F4I, and PIP work OK

Unfortunately the little versions of MACRO and F4 don't use DAT slots and need three DECtape drives to work

We need to clean an polish the tape guides for the second TU55 drive, and then fix the control for the left motor

We will have to scrounge a third TU55 drive and install it in the CPU cabinet

Then we should be able to do some software development on this system


During the week we polished the very corroded tape guides from the lower (and older) TU55 DECtape drive

The aluminum oxide on the tape guide surface is very hard and needs to be scraped off before polishing.

We reinstalled the polished tape guides

The next step is debugging the inoperative left reel motor, and seeing if the drive will respond to commands.


We replaced the G850 SCR Motor Controller board for the left motor

It works OK now under local control

We replaced the missing G851 Head Relay board with one from a parts TU55 DECtape drive

The drive will decode selections for Units 0 and 2-7, but not for Unit 1

Wiggling the cables and boards related to drive select in the TC02 DECtape controller fixed it

The drive will go Forward under Remote command, but not Reverse

There was some really poor soldering by DEC in the W990 FlipChip that jumpers the control signals in slot B07

The L-M jumper on the W990 was openCLK on , so the REV signal never made it from the control cable to the motor control circuitry

Reflowing all of the solder joints made it work much better

Now the drive will go forward and reverse

We tried reading DECtape on the second drive

We are not getting timing track data

It looks like the C pin from the tape head which should be connected to track 1 is open

After fiddling with the tape cable connectors and the G851 switch FlipChip we are getting Timing Track data from track 10

That seems to be enough to read tapes

After seeing some unusual behavior with the TC02 DECtape diags we decided to run the processor diags

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

MAINDEC-9A-D02A-D Instruction Test Part 2 fails when it is testing the Real Time Clock

Having a broken RTC would explain why the DECtape diagnostics don't run correctly

The clock count in core location 7 does not change when the clock is enabled


We are looking at the broken RTC and why the Interrupt Enable doesn't clear on Reset problems today

See schematic page KD09-A-3 Sheet 2

The 60Hz RT CLK signal looks OK on pin J07K

The SW CLK\ on J04S looks OK and switches with the console CLK switch

The CLK EN(1) signal on J04E goes active (low) when the CLON instruction is executed

The IOT PWR CLK POS signal goes active when the I/O RESET switch is pressed

The IOT PWR CLR signal is always inactive

See schematic page KD09-A-3 Sheet 1

The PWR CLR POS signal on pin J10J is at -3.5V

The CLK signal in pin J10D is 1MHz

The K10 signal on pin J10E signal goes high when the I/O RESET switch is pressed

We replaced the S603 Pulse Amplifier in slot J10 with a spare

The IOT PWR CLR is now a series of pulses when the I/O RESET switch is presses

The CLK EN and PIE flip-flops and indicators will now clear when the I/O RESET switch is pressed

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

Time to go back to running the DECtape diagnostics


Now that the RTC is working again we can go back to running the TC02 DECtape controller diagnostics

This will make sure that the TC02 is working correctly before we test the recently repaired TU55 DECtape drive

Just to make sure that we had a good starting point we tried to format a DECtape on the upper TU55 DECtape drive

The DEC-9A-EUFC DECtape formatter program ran normally, but said that there was a "BLOCK NUMBER SEQUENCE BROKEN" error

This error happened on every DECtape, including DECtapes that had previously formatted OK

We ran the MAINDEC-9A-D3BB-D TC02 Basic Exerciser using the upper DECtape drive

Test #11 ran OK, so at least we know that most of the TC02 DECtape controller is working OK

Test #0 MOVE SCOPE LOOP, and test #1 SEARCH SCOPE LOOP both worked OK

This means that we could read the Timing and MARK tracks from the DECtape


This means that we can read previously written data and write data patterns to the DECtape


It said that it was looking for block #10 and found block #0

We also noticed that when we were running the SEARCH SCOPE LOOP test bit #14 in the AC was never illuminated when it displayed the last block number

We will need to study the test #1 source code to see how it is reading the block number and then determine how bit #14 of the block number is being dropped



When MAINDEC-9A-D3BB-D TC02 Basic Exercise is running test #1 the block number found is displayed in the AC

Bit #14 in the AC, the block number, was always 0 when it should have been part of the counting pattern

The PDP-9 DECtape has 578 (decimal) or 1102 (octal) blocks

The first three data bits from the block number are read into RWB[3..5]

The next three data bits from the block number are read into RWB[3..5], and the contents of those flip-flops is copied into RWB[0..2]

Once 6 bits of tape data are in RWB[0..6] it is copied to DTB[12..17]

When the next 6 bits of tape data are available DTB[12..17] is copied into DTB[06..11] and RWB[0..6] it is copied to DTB[12..17]

When the next 6 bits of tape data are available DTB[06..11] is copied into DTB[00..05], DTB[12..17] is copied into DTB[06..11] and RWB[0..6] it is copied to DTB[12..17]

During a Search function the block number in the DTB is copied to core location pointed to by the CA in core location 31

The bit in question, is stored in DTB14 which is in the S205 in slot B08

If this flip-flop for DTB14 was defective the data for bits 5 and 2 would also be 0

Since the maximum block number is 1101 (octal) we only need DTB08 through DTB17

DTB14 must be OK since DTB05 had good data in the AC

That points to the S123 in slot D06 which gated DTB14 onto I/O BUS 14 as the most likely fault


It looks like we didn't guess the fault correctly

When MAINDEC-9A-D3BB-D TC02 Basic Exerciser is running test #1 the DATA BUFFER lights are off for DTB14, DTB08, and DTB02.

The 'scope shows that the inputs for the half of the S205 in slot B08 that implements DTB14 has active inputs on pins L & K, but static outputs on pins E & J

We replaced the D662 diode D21 in the S205 in slot B08 with a NOS part and now all of the block number bits are working and all of the DTB bits are lighting

All tests in MAINDEC-9A-D3BB-D TC02 Basic Exerciser work OK

We booted ADSS V5 from the upper TU55 drive

We were able to make a new empty directory on the lower TU55 drive, and it read back as empty

We tried to use PIP to copy a file from the upper drive to the lower drive

We need to determine what key sequence on the VT220 equals the left pointing arrow (at the top of the O key) on the ASR33

Shift O on the Teletype makes 37 octal, and Control O makes 17 octal

The _ character works on SIMH, but not on a real PDP-9


We added a third TU56 tape drive to the PDP-9 so we could run the 8k versions of MACROI and F4I

We had to remove, polish, and reinstall the really corroded tape guides

The motors would drive the tape forward and backward, but the brakes would not turn on

We replaced the R303 Integrating One-Shot in slot A04 with an untested spare

The brakes now work OK

We loaded MAINDEC-9A-D3BB-D TC02 Basic Exercise, and are running the tests

We can actually see block numbers when running test #1 Search Scope Loop, so we know that all of the tracks are working

We got some data errors in the read/write test, so we decided to format the DECtape on this drive

The first DECtape that we tried got a Mark Track error near the end of the tape

The second DECtape that we tried got a Mark Track error near the beginning of the tape

Both DECtapes formatted Ok on the upper drive

Looks like we still have some debugging to do on the left drive


We did some more work with ADSS using 3x TU55 DECtape drives

It looks like two of the DECtapes that we had written ADSS V5A on using my PDP-8/e have bad blocks

I tried to reformat them in PDP-9 format on the PDP-8/e, but they failed in phase 4 of the format process

The tapes may still be usable on a PDP-8 if the cut off the beginning of the tape and reformat it

We were able to format two other DECtapes in PDP-9 format on the PDP-8/e

One of the ADSS tapes included SCTEST.SRC, so we assembled it with MACROI


We tried to use the 18-bit version of dumprest to write ADSS V5A to the newly formatted DECtapes

Dumprest looks like it is talking correctly to the Windows application that is sending the DECtape image, but it didn't write to the DECtape

Dumprest worked OK a few months ago, so some debugging to do

At this point the DECtapes for ADSS V4B and ADSS V4E will boot OK

Unfortunately any ADSS version before V5A gets a .SYSLD 4 error when you try to load any application

The behavior is the same on SIMH is the same, so we know that the PDP-9 is behaving OK

We will assemble the ADSS source code that is misbehaving so we can get a listing and the memory locations

Then we can single step the PDP-9 and see where it is going wrong


We made some new ADSS tapes on the PDP-8/e

Unfortunately they can't be read on the PDP-9

Oh well, time for some more debugging

Go to the later restoration blog.