DEC PDP-12 Restoration

Moving day.

Moving the DEC_PDP-12

The RICM rescue and moving team.



I couldn't resist cleaning up the really pretty front panel before doing anything else. The left side of the panel controls the PDP-8/I processor and the right side controls the LINC processor. The pivot pins on one of the lime green switches are broken. We will need to repair the pivot pins, or find a replacement switch.

Today's mission is to:

  • Reform the capacitors in the power supply (working on it)

  • Reform the capacitors on the core memory controller boards (done)

  • Clean the processor cabinet (done)

  • Clean the I/O expansion cabinet (this can wait a while)

  • Replace the 30A plug with a 20A plug so it will plug into a normal wall socket. (done)

  • Slowly power the power supply on with a Variac to make sure that nothing gets damaged. (done)

Reforming the monster capacitors in the power supply. We also reformed the capacitors on the G624 Resistor Board in the Core Memory subsystem. While the capacitors were reforming we started cleaning. Everything was coated with dust and cobwebs, but otherwise was in very good condition. We cleaned the TU56, VR14, and PC04 and reinstalled them in the processor cabinet. We cleaned the front of the DW8E, RK05, and RX02 and reinstalled them in the expansion cabinet.

The Poly Vinyl Acetate adhesive between the CRT glass and the external implosion shield in the VR12 is failing. This is called screen rot or cataracts. Others have successfully removed the outer protective layer and removed the failed Polyvinyl Acetate adhesive. Some fellow vintage computer enthusiasts suggested looking at a YouTube video on how to remove the outer glass lens and the Polyvinyl Acetate that adheres the outer lens to the CRT. The process involved heating the tube and using a hot air gun to remove the outer shield. Without practice it looked like an easy way to make a mess of the tube. Others suggested using a hot wire to cut through the PVA. That procedure sounded like it had less chance for destroying the tube. We also had a suggestion to soak the front of the tube in water for a few weeks.

We disconnected the wire harnesses from the power supply output. When we powered on the power supply we were pleased to see that the output voltages were all OK. We reconnected the wire harnesses but saw no indicators on the front panel. After checking the power supply harnesses we found two of the power connectors were not retained on the sheet metal of the power supply, so were not fully connected. We had to hold the power supply connectors to get the wire harness connectors fully connected.

After the power supply connectors were connected correctly we had lights on the front panel.

  • The controls on the front panel are a little different from the ones on the PDP-8/I, so we need to do a little studying.

  • The EXAM and STEP EXAM set the MA and increment the MA, but the MB is always zero.

  • FILL and STEP FILL set the MA and increment the MA, and set the MB, but the data is not stored in core.

  • Pressing I/O PRESET sets the INST FIELD to 2 and the DATA FIELD to 3. (Warren read the manual and said that this is normal.)

  • Switching the MODE switch between LINC and 8 always leaves the machine in 8 MODE. (The manual says to set the MODE switch and then press I/O Preset.)

  • Pressing DO, START or CONT turns on the RUN light and you can see cycling in the MA lights.

  • All of the LEFT and RIGHT SWITCHES work OK.

  • The INST FIELD switches have no effect.

We reassembled the peripherals in the processor and expansion cabinet. Looks very nice. The orange cabinets on the right are the recently restored are the PDP-8/I. This week we will scan and post the processor and RK8-F documentation. Time to do some studying and create a debugging plan. Debugging the core memory will be the top priority. Next week we will reconnect the cables to the TU56, and the VR14. Hopefully the TU56 will work OK.


Dan (the donor) brought more manuals, diags on paper tape, and his very nice color oscilloscope. Dan removed the noisy fan and will see if he can get some oil into the noisy bearing. If not, we will borrow one from one of the 11/45 I/O cabinets in the warehouse. After reading the manual and getting instructions from Warren, we found that some of the misbehaving front panel was due to operator (me) error. The Mode switch to change between LINC and 8 operation only has an effect after you press the I/O Preset switch, so that is working correctly.

When you press I/O Preset the INST FIELD is set to 1 and the DATA FIELD is set to 3. We though that this was wrong for an 8k machine. If you look at the front panel picture you will see three bits for the INST FIELD and DATA FIELD then an additional 2 bits. So part of this is for the 8 and all of it is for the LINC, and it is working correctly.

We recabled the VR14 and TU56. The Local Forward and Reverse switches on the TU56 do not get the correct behavior from the motors.

The Line fuse on the VR14 blew when we turned it on. We will replace the fuse and try a slow power up with a Variac.

We received lots of comments on reforming the capacitors in the power supply and strong recommendations from experts to just replace them. Since new caps are a different physical size, and would cost about $250 we decided to continue with reforming the originals.

We measured the voltage ripple on the backplanes near the power connectors.

Dan's 'scope displays these values at the side of the trace window. Very nice!

    • +5.0V = 5.01V (should be between +5.25V and +4.75V), 200 mV PTP ripple

    • +10.0V = 5.9V (should be between +12.00V and +8.00V), 200 mV PTP ripple

    • -15.0V = -14.2V (should be between -16.5V and -13.5V), 800 mV PTP ripple

    • -30.0V = -31.2V (should be between -33.00V and -27.00V), 800 mV PTP ripple

The 800mV of ripple on the -30 is a sign that the caps in the power supply were not working well enough, and the voltage is probably too noisy for the core to work. We tried to measure the capacitance of the power supply capacitors using Alex's ancient, but very nice, GenRad capacitor meter, but unfortunately the caps were too big to measure. Alex suggested that more power on time for the caps might improve their behavior.

We started the processor checkout and found that bits 4 and 11 in the Program Counter were always on. We looked at the flip-flops on the M221 modules in the processor that make up the PC register, and they the contents matched what was set on the console switches. We need to determine why the indicator lights on the front panel do not exactly reflect the internal state of the registers in the processor so we can continue debugging. After running the system for about four hours the ripple on the -30V was down to 180mV, so the capacitors are getting better. More run time will hopefully reduce the ripple to an acceptable level. If not, we will have to replace them.


We didn't find the allowable ripple in the PDP-12 documentation, but Warren said that it is in the Classic PDP-8 docs. It says 700mV on the +10V and -15V, so we are well within those levels now. The -30V ripple is supposed to be below 50mV when measured on the output of the regulator modules. So next Saturday we will measure the -30V on the G624 modules.


Today we removed the front panel for test and repair. That was a bit of a project because of the long flexprint cables that go from the front panel to the processor chassis in the back of the cabinet. We used Warren's flip-chip tester to activate the individual inputs to the M900 flip-chips. We found an SN7400 that was bad, IC E3 on the M900 in slot N29, that was causing the PC04 light to always be on. We found that the AC03, NP, and LI11 bulbs were bad, and a few were not making good contact. We replaced the bad bulbs and wiggled the others. We swapped the STEP EXAM switch that had broken pivot pins with the INST FIELD 0 switch that we don't need. So, now we think that the front panel is working and we can rely on it for debugging.

This is Warren testing the PDP-12 front panel. This system allows you to enter one instruction in the left switches and the execute it with the DO switch.

Even with the core memory not working this let us try a few instructions. In 8-Mode the CLA, ION, IOF, and CAM work. The INA works, but increments from bit 10 instead of bit 11. The rotate instructions do some really strange things. The Instruction Register has bits 6, 8, and 9 stuck on so that will affect our debugging. We think that some of the SN7474 ICs on the M216 cards that make up the IR are defective. We have replaced LOTS of SN7474 ICs during other repair projects. We will test and repair the the M216 flip-chips on Saturday.


Bits 6, 8 & 9 of the IR were always on, so we suspected that this might be the cause of some of the rotate instructions misbehaving. We swapped the M216 flip-chips in slots H39 & H40, and the stuck bits moved to bits 0, 2 & 3. This meant that the M216 that was in slot H40 was bad. We replaced it with a repaired and tested M216 from spares. The IR works OK now. We tested some of the PDP-8 and LINC instructions to see what works.




LINC Broken: We can read and write the relay register and the relays change state. Two of the relays have high resistance contacts, so they probably need to be cleaned. We have seen LOTs of problems with SN7474 chips on other restorations. We already found a bad SN7474 in this system so we pulled all of the M216 flip-chips and tested them. We found a bad SN7474 chips on the M216 flip-chip in slot E8. This M216 controls the core memory states, so it was likely the problem with the memory not working. With the M216 in the core memory replaced with a repaired and tested spare, the core memory now works! We started going through the troubleshooting guide in Maintenance Volume-II. We noticed that the PC04 light didn't work, so we pulled it and measured its resistance. The bulb measured about 50 Ohms, so we put back in, and now it works, um, no it doesn't. We filled memory with 7777 using FILL STEP and AUTO, and then looked at memory with STEP EXAM and AUTO. We saw a flickering pattern, so we knew that some locations were not working OK. After experimenting we found that 1xxXXX did not work. We swapped the G221 in slot C09 with a repaired spare. All of the bottom 4k of memory works OK now. A JMP instruction, 5000, puts 5000 in the PC and then in the MA. There is some gating logic to only use the lower 9 bits for the address, so that must be including the upper three bits. Maybe the RCB EN MA0-4 H signal on the RCB schematic sheet is causing the problem with the JMP instruction. That signal comes from the M113 in slot K28 that uses just SN7400 ICs.


We looked at the prints to see which flip-chip might be causing the problem with the JMP instruction. We speculated that the M113 (three SN7400 ICs) in slot K28 was the problem. We tested it with Warren's flip-chip tester and found that it was OK. We continued testing the M113 flip-chips. The M113 in slot J33 had the F2 output stuck low. See sheet INS signal (L JMP * XEQ 0) L. We replaced it with a tested spare, and now the JMP instruction works. The M113 in slot K30 had a bad V2 output where the U2 input was ignored. See sheet CST, something to do with AUTO. We tried some instructions and found that ISZ will clear the AC during the Execute cycle. We looked through sheet RCL of the schematics, found all of the flip-chips that generate the RCL LOAD AC H signal, and tested them. We found that the M119 in slot H28 had the J2 pin stuck high (active). This would cause other instructions to load the AC. We replaced the M119 with a repaired and tested spare and now ISZ works OK.

Memory in field 1 with addresses X5XX did not work. We replaced the G221 in slot D10 with a repaired and tested spare and now it works. Now we have 8k of core that is working. The LINK light stopped working, but the LINK register works. The bulb is OK.

We tried the Teletype. It powers on, but the platen is difficult to turn. After running it for a few minutes the keys started working. We can send characters from the PDP-12 to the Teletype, but not to the PDP-12. The M707 transmitter module passes Warren's flip-chip test. The M706 receiver module fails Warren's flip-chip test. Our spare M706 is broken too.

We ran the toggle-in tests. It looks like the processor is mostly functional. We need to run the DEC Instruction diags to really know if everything is OK.


We spent some time on the console Teletype that came with the PDP-12. The platen was nearly impossible to move, so the Line Feed did not work. We removed the platen, and found that the plastic in the bearing area had swollen and was binding. We sanded, cleaned, and lubricate the bearing surface and the platen turned freely. On reassembly we found that none of the Control Characters like Line Feed or Bell would work in Local Mode. We fiddled for quite a while, but did not find a problem. We speculated that something got bent when it could not move the binding platen. We found a bad SN7474 E13 on the M706 Teletype Receiver flip-chip from the PDP-12. We will repair and test it next week. We borrowed the M706 Teletype receiver from the PDP-8/I and connected the Teletype to the PDP-12. We loaded and ran a toggle-in program that echos the keyboard to the printer. We were a little surprised when everything in the Teletype worked OK. We were even more surprised when the Teletype now worked correctly in local mode. We borrowed the console cable from the PDP-8/I and connected my laptop to the PDP-12. The terminal emulator worked correctly and echoed characters to the PDP-12 and back. We toggled in the RIM loader and then loaded the LBAA BIN loader from my laptop. We ran the BIN loader and loaded and ran the PDP-8/I Instruction Test #1. It actually works OK! We tried twice to load MAINDEC-8I-D02B-D Instruction Test #2, but failed both times. Running that diagnostic and others will be the project for next week.


Warren repaired and tested the M706 Teletype receiver. It works OK doing an character echo test.

Loaded and ran:

MAINDEC-08-D04B-D Random JMP Test

MAINDEC-08-D05B-D Random JMP-JMS Test

MAINDEC-08-D07B-D Random ISZ test


MAINDEC-8I-D02B-pb Instruction Test 2

The Tape Quickie test passed for about a minute, and now fails on an AC comparison. This test runs in both LINC and PDP-8 modes, so it is using a lot of logic that has not been used for a long while. We reloaded and ran the MAINDEC-8I-D01C Instruction Test 1 to make sure that the PDP-8 processor was OK. We reloaded and ran the MAINDEC-8I-D02B Instruction Test 2 to make sure that the PDP-8 processor was OK. MAINDEC-08-D07B-D Random ISZ test ran for a while, then started failing.


F 1543 T 4660

O 2330 F 7747 R 7710 NS

F 1543 T 4660

O 2330 F 7750 R 7711 NS

F 1543 T 4660

O 2330 F 7751 R 7712 NS

F 1543 T 4660

O 2330 F 7752 R 7713 NS

F 1543 T 4660

O 2330 F 7753 R 7714 NS

F 1543 T 4660

O 2330 F 7754 R 7715 NS

F 1543 T 4660

O 2330 F 7755 R 7716 NS

F 1543 T 4660

O 2330 F 7756 R 7717 NS

F 1543 T 4660

O 2330 F 7757 R 7720 NS

MAINDEC-08-D1B1 Memory Address Test Low ran a short time and started failing.

MAINDEC-08-D1B2 Memory Address Test High ran a short time and started failing.

We swapped the G221 module in slot G08, but saw no changes in the behavior.

We tested all of the G221 modules, and they were all OK.

A4053 C4052

A4173 C4073

A7400 C1275

A7401 C3273

A7402 C1276

A7403 C3303

A7404 C1273

A7405 C3673

A7406 C2273

A7407 C2303

A7410 C5204

A7411 C1275

A7412 C3273

A7413 C1276

A7414 C3303

A7415 C1673

Dan-the-donor brought more parts, including the M706 and M707 for the second serial port. They tested OK, but the output signal from the baud rate generator is low, so it only works at 110 and 300 baud.


We reloaded MAINDEC-08-D07B-D Random ISZ test and ran it. It ran for two passes and then started failing. It looks like it is dropping bits during the read/modify/write cycle of the ISZ. We ran MAINDEC-08-D1EC-D Extended Memory Checkerboard on field 1. There were a few core locations that consistently picked up and dropped bits. Time for memory tuning.


Dave Tumey sent us 10 new rubber hammer for the Teletype. It looks great and fits nicely.

The new Teletype hammer, and a brand new mostly dried out ribbon.

We measured the ripple on the power supplies with an oscilloscope. The values are much better than when we first started debugging.

    • +5V: +/-250mV, is 150mV

    • +10V: +/-300mV, is 400mV

    • -15V: +/-750mV, is 600 mV

    • -30V: +/-3000mV, is 800mV

Warren made an Arduino based baud rate generator for both serial ports. We configured it for 300 on the console and 110 for the Teletype on the second serial port. The ISZ and Memory Checkerboard diags are failing. It looks like it is picking up and dropping bits in quite a few memory locations, all above 1000.

We measured the START MEM to STROBE FIELD 0 delay. It was set to 550ns, exactly the default value. Warren wrote a better memory checkerboard program that shows the bits that were being picked up or dropped in the MQ register. We tried adjusting the STROBE FIELD 0 delay about +/- 100nS, but there was no setting that resulted in completely working memory. Changing the delay did change the location and number of bits that were picked up or dropped. Since the failing addresses were all above 1000 we tried replacing the G221 modules in slots C07 and C08. There was no change.

Blue is the Sense Amplifier Test Output, Yellow is FIELD 0 STROBE. We loaded Warrens program into the first field and tested the second field. We also saw bits picked up and dropped. Since many of the locations were supposed to be zeros, but contained ones, we are speculating that there is a problem with the inhibit circuits in the core. That will be the project for next week.


Warren updated the code in the Arduino baud rate generator, so we did some more debugging. The current loop adapter is powered from the RS-232 signals and doesn't want to work faster than 110 baud.


Core stack serial numbers:

Field 0: Electronic Memory P/N 906819-A04, S/N 23139, Spec TS906819, 1/2/70

Field 1: Electronic Memory P/N 906819-A04, S/N 25743, Spec TS906819, 4/6/72

Spare: Dataram P/N 2100270, S/N 5192, Repaired by 3-Delta Corp

Spare: Electronic Memory P/N 906819-A04, S/N 22732, Spec TS906819, 4/7/69

We looked at the LINK indicator problem. The FLK LINK(1) L signal on the M900 in slot N31 looked OK We put the M900 on an extender and looked at E8 Pin 1 & 2, the FLK LINK(1) L signal, which was OK. The output of the SN7400 on pin 3 and on R1 was OK. The LINK bulb was blown. Q39 was completely open, so it looks like he bulb shorted and took the transistor out. We replaced Q39 with a 2N3569, twice because the first time I put the transistor in I didn't notice that the leads were bent backwards compared to the original. The LINK light works!

We ran Warrens updated memory diagnostic. The failed bits were 1561. The stack 0/1 thermister measured 0.540 mV. The stack 0/1 regulator is set to 19.25 with tune3 running in field 1 and testing field 0. The 1k trimpot on the G826 module was set 106 Ohms. We adjusted the voltage to 19.86. The field 0 runs without errors now.


A little explanation of tuning the core...

You can't read the contents of core memory. You can write a one to core, and if the core originally contained a zero you will see a pulse in the sense line when the core changes the direction of its magnetism. In the image above you can see the signal from the core memory sense amplifiers in blue and the strobe signal in yellow. This core originally contained a zero, so you can see a big pulse when the strobe goes active, If it originally contained a one there would be no pulse. We need to adjust the timing of the strobe so that the output of the sense amplifiers is latched at the correct time. The manual says to start with a setting of 550ns after the START MEM signal, and then adjust for best behavior. You also need to adjust the amount of electrical current going through the core. To low, and you will see some ones turn to zeros. Too high, and you will see zeros turn to ones. Ours was too low, so we periodically turned ones into zeros. You are supposed to use a current probe to measure the core current on special wires on the backplane, and adjust the core memory regulator voltage to get the right amount of current. The appropriate amount of current varies by the manufacturer of the core. My current probe went missing so we can only measure the core memory voltage and work from that. The manual says to start with the regulator set to 22.5V and work from there. We increased the voltage until we saw failures, decreased the voltage until we saw failures, and set the voltage in the middle.

With the machine just powered on the stack 0/1 thermister measured 0.465 mV and the stack 0/1 regulator output was 20.04. With tune3 running in field 1 and testing field 0 the stack 0/1 thermister measured 0.518 mV and the stack 0/1 regulator output was 19.93. No memory errors were reported. When the voltage was adjust up to 22.5 and down to 19.96 we saw a few failures. We adjusted the voltage to 21.3. No errors were observed when testing field 0 or field 1.

We successfully loaded and ran 10 passes of:

MAINDEC-08-D1B1 Memory Address test.

MAINDEC-08-D1B2 Memory Address test.

MAINDEC-08-D07B-D Random ISZ test.

We ran these diags without errors


MAINDEC-12-D8AB Relay Register Test

The problems that we observed in the TU56 DECtape drive motors is actually dirty switches. Warren took the VR14 home so he can fix it.


Dan-the-donor dropped off the serial cable that was used with the second serial port. It looks like it is an opto-isolated current loop module.

We bought some replacement Intersil IM4702 Baud Rate Generator ICs so we can repair the custom baud rate module for the second serial port. Warren tuned the behavior of the current loop to RS-232 converter that he made for better performance. We remove the capacitor C1 from the W076 console module so we could run baud rates faster than 110. We tried baud rates up to 19200 and found that 9600 worked reliably. We tried to load and run FOCAL, but it started executing instructions in non-existent memory. We tried to run MAINDEC-8I-D01C Instruction Test 1, but it halted at 2222, a rotate instruction failed. Location 2213 was a 1034 and should have been a 1024. When we corrected the instruction it ran OK.

We suspected that we were getting errors when loading the programs, so we set the serial port for slower speeds. 1200 baud seems to be the best compromise between reliability and performance. Loading programs 10x faster than normal is really great. We reran some diags and tried some new ones.

MAINDEC-8I-D02B Instruction Test 2 ran OK.

We keep forgetting to connect the Teletype to the second serial port so that it will not generate interrupts and cause problems with Instruction Test 2.

MAINDEC-12-D0GA-A Tape Quickie ran OK.

MAINDEC-12-D3AD-D-D Tape Control Test Part 1 of 2 ran, but displayed an error message "LGP GP=GPC PRESET.

We will need to do some research on this to determine what the problem is.

MAINDEC-12-D3GA-D-D Tape Control Test Part 2 of 2, runs OK as long as you hold the MARK switch down.

The need for the MARK switch was hand written in the manual.

MAINDEC-12-D3FB-PB Tape Data Test, works for a long time, but eventually halted at 1302 (E3) with MQ=0000, AC=1777.

Lots of the test time was spent writing and reading patterns in a small section of the tape. The diag failed when it tried to verify that the block numbers were written sequentially.

MAINDEC-8I-D0AA Inst test 3A EAE, ran for a while and stopped after 8 seconds at 2616 with MW & AC=0000, MB=0020, IR=7413=DVI.

We don't have any documentation on the EAE diags. If we can't find documentation on the EAE diags we will need to disassemble the code and see what it was trying to do.

MAINDEC-12-D1DA Memory Checkerboard, runs OK.

We noticed that the PC(05) and IR(06) indicators on the front panel were not working. We checked the SN7400 ICs on the M900 modules and the bulbs, and they are OK. We need check the transistors on the front panel.


We replaced Q60 and Q32 on the front panel with 2N3569 parts to fix IR(06) and PC(05). They both work OK now.

MAINDEC-12-D0GA-A Tape Quickie ran OK.

MAINDEC-12-D3AD-D-D Tape Control Test Part 1 of 2 ran, but displayed an error message "LGP GP=GPC PRESET.

The documentation says that it is testing the M216 module in slot B37. We replaced the M216, but it did not change the behavior. This could either be a problem in the LINC mode of the processor or in the TC12 LINCtape controller.

MAINDEC-12-D0AB CP Test-2 halts at 22.

We need documentation to figure this one out.

MAINDEC-12-D0CB CP Test-3 runs OK.

The LINC mode light is always on and it sends a bell every 19 seconds, and continues to run.

MAINDEC-12-D1BA JMP Self won't load.

Probably a bad paper tape image.

MAINDEC-12-D1AC Extended Memory Control runs OK if you set the right switches to the number of fields of memory, 0001.


We reran MAINDEC-12-D3AD-D-D Tape Control Test Part 1 of 2 and scoped the signals on M216 in slot B37. The same error message "LGP GP=GPC PRESET" was printed, and it halted at 3400. The docs say: The LGP GP=GPC flip-flop was set to a one, tape preset attempted to clear it, and failed to do so. The halt is in test GPCNT2 that starts at 3357. The bit 0010 in the status register was on and should not be not. The status register contained 4370. We think that this part of the diag should be setting the flip-flop, clearing it, and testing it, but the test never set the flip-flop. Other tests did set the flip-flop, so we know that it works. Warren setup the 'scope to trigger on the LIP TAPE PRESET L signal, and watched the GP EQ GPC flip-flop 1 output. Every time the diag halted at 3357 the 1 output of the GP EQ GPC flip-flop was on, should not be. The LGP GP EQ GPC (1) H signal from the flip-flop goes into the M222 in slots AB21. Warren swapped the M220 modules in slots AB18 and AB21. After the module swap the diag halted at 1215 in the test RWBSH1. Warren moved the modules back to the original locations, but the diag halted at 1215. We probably need to clean the gold fingers on the M222 modules. While looking through my home collection for an Amphenol connector to mate with the VT14 display connector I found my missing current probe. Now we can look at the core memory current waveforms, instead of just fiddling with the core memory regulator voltage.


J. Victor Nahigian donated some M221 and M222 boards for the processor and TC12 LINCtape controller. They are in pretty bad condition, but are repairable. Nice to have some spares. Dan-the-donor brought over the now lubricated top of cabinet fan. He disassembled it and lubricated the dry bearings. We will reinstall it next week. He also dropped off the system logbook and more diagnostic manuals. More scanning for Bitsavers!

The LCM scanned some of the missing MAINDEC documentation so we were able to run:

    • MAINDEC-12-D1AC-D Extended Memory Control (EXTMC12)

    • MAINDEC-12-D8CC-D_KW12A_Clock_Test Fails test #11 where the AC should be 0000 and is 7777 on the CLRB instruction.

    • MAINDEC-12-D8CA-D-(D) KW12 Real Time Clock Diagnostic (KW12TST) shows the same failure mode as D8CC.

  • MAINDEC-12-D6BA VR12 Display Test Runs, but we have no display connected.

We connected the 'scope to the outputs of the VC12 display controller when MAINDEC-12-D6BA was running. Without a way to interpret the intensify signal, and no persistence in the phosphor, the resulting image was not too good. At least we know that the display controller is responding to commands and outputs signals that look reasonable.

We reran MAINDEC-12-D3AD-D-D Tape Control Test Part 1 of 2.

It still fails at 3400 with the error message "LGP GP=GPC PRESET" printed.

We reran MAINDEC-12-D3GA-D-D Tape Control Test part 2 of 2.

That runs fine.

I bought the matching terminator for my current probe and was able to give it a try today.

This shows the resulting Field-0 current waveform with the terminator set for 10mA/mV. The normal setting for PDP-12, PDP-8/I, and PDP-8/L core is 320mA. We set the core memory voltage regulator to the middle of the high and low voltage settings that caused periodic errors. The low going part is the read current and the high going is the rewrite current. The result turned out to be 316mV for the read. Not too bad!


Since it was nice an cool in the Learning Lab today we spent some more time debugging the "LGP GP=GPC PRESET" issue with the TC12 LINCtape controller.

The MAINDEC-12-D3AE-PB PDP-12 TAPE CONTROL TEST, PART 1 OF 2, halts at 3400 in test GPCNT2.

This part of the diagnostic executes a LINC RCG, read and check consecutive blocks command to set the GP=LGP flip-flop, then forces a TC12 TP2 clock cycle, forces a tape preset signal, copies the TC12 state to the AC, and checks to see if bit 8 is off. In our case the bit is on, so the diag halts.

We replaced the JMS instruction in location 3376 with a HLT to reduce the number of instructions that are executed after the fault is detected. We connected Warren's logic analyzer to all of the signals on the GP=GPC flip-flop on page TC12-0-LGP of the prints. When the diagnostic halted the processor we could see normal flip-flop behavior, the preset signal went active and cleared the flip-flop, and then the LTT TP2 H signal went active for 25ns and set the flip-flop. If the LTT TP2 H signal did not go active the flip-flop would have stayed cleared and the diag would have passed.

Looking at page TC12-0-LTT of the prints.

We connected the logic analyzer to C18-L1, C18-S1, C18-S2, C20-J1, and we already had the signal on C20-P1. Just before the halt we could see the S2 signal go low for 25ns, then the TP0 H, then TP1 H, then TP2 H signals would go active in a cascade. We connected the logic analyzer to E19-A1, E19-B1, E19-C1, and E19-D1. Just before the halt we could see E19-D1 go high for 50ns. We connected the logic analyzer to D16-H1, D16-J1, and C18-D1. Just before the halt we could see D16-J1 LTS TIMING OK go low for 25ns.

Looking at page TC12-0-LTS of the prints.

We tested the M119 module in slot C22. It was OK. We connected the logic analyzer to C22-M1, C22-R1, C22-R2, C22-S2, C22-T2, and C22-U2. Just before the halt we could see the MAINT (0) H signal on C22-M1 go inactive. So, the maintenance mode flip-flop was somehow cleared, let some signals pass through the circuit, starting the timing cascade, and set the GP-GPC flip-flop.

Looking at page TC12-0-LTMR of the prints.

We connected the logic analyzer to B37-K2. Just before the halt we could see the LTMR TAPE PRESET signal go low. This was caused by the diag, but should have cleared the GP=GPC flip-flop.

Warren thinks that when the Maintenance flip-flip is preset, the random data from the TU56 heads starts the timing cascade and set the GP=GPC flip-flop. The TIMING OK signal is active, and probably should not be at this point. We are discussing another possibility where the LIP PRESET L signal is not active when it should be and is not presetting the GP=GPC flip-flop.

We reinstalled the fan in the top of the processor cabinet. Nice and quiet!


We saw the MQ12 bulb flicker and go out so we replaced it.

Last week Dan-the-donor dropped off more documentation on the system. Among other things, the box contained diag documentation for the LINC instruction diagnostics. These were scanned and are on Bitsavers now.

We ran MAINDEC-12-D0AB-B-D CP Test 2 (Skip And Data Handling) and it halted at 6631.

We kept hitting the Continue button to go to the next test and found that all of the variations on the SHD instruction were failing. A quick look through the schematics showed an M160 module in slot K31 that enabled all of the SHD instructions. That module failed in Warren's tester so we replaced the module with a repaired spare.

MAINDEC-12-D0AB-B-D CP Test 2 and MAINDEC-12-D0CB CP Test 3 both run OK now.

We continued to work on the GP=GPC problem in the TC12 LINCtape controller. Last week we determined that the LTC Timing OK signal was letting timing data from the TU56 tape head into the TC12 logic. We tested the M119 in slot C22 and the M111 in slot C21 that generate the LTC Timing OK signal. Both were OK.


It ran OK for more than an hour while we had lunch. We put the broken M160 back in and reran the diag. It ran OK even with the broken M160 installed. I guess that the TC12 tape controller diagnostic doesn't use the LINC SHD instructions.

Earlier today I had changed the drive numbers on the TU56. Last week I had the right drive as 0 and the left as drive 1. With the left TU56 set to drive 0 and the right TU56 set to drive 1 the diag will pass. With the right TU56 set to drive 0 and the left TU56 set to drive 1 the diag will fail.

We started looking at the differences in the signals that are TU56 drive related.

The LTR T READ H signal (the timing track data from the TU56) is different at the time the Maintenance flip-flop is preset. We swapped the M882 modules in slots F04 and F05 (Timing and Mark tracks) but it made no difference. We swapped the relay cards in the TU56, but it made no difference.

On the TU56 in my 8/e I saw an oscillation problem because of an open timing track coil in a tape head. We measured the resistance of both tape heads. All of he coils in the left head read the normal 2-3 Ohms. The timing track coils on the right head read open and 400 kOhms, so there is a bad internal solder connection in the head. We will borrow a head from the TU56 in the warehouse to fix the right drive.

We ran MAINDEC-12-D3FB-D_Tape_Data_Test.

The diag displays the block number in the AC during one of the tests. The block numbers are not always correct. Sometimes bit 0 goes on. With a LINCtape the maximum block number is 0777 (octal) so bit 0 should never go on. When bit 3 is supposed to be off it sometimes flickers. When it is supposed to be on, it is solid on and works OK. We swapped the M222 boards in slots AB17 (bits 0 & 1) and AB18 (bits 2 & 3), but it didn't make a difference. We swapped the G882 boards in slots F07 (bits 0,1,2,3) and F09 (bits 8,9,10,11) but it didn't make a difference. Next week we need to put the logic analyzer on the Tape Block Number outputs from the M222 modules and see what the tape block number signals look like. It is possible that the block number data is OK, but the register enables are misbehaving. We should also investigate the TAPE REG ENABLE CTRL circuitry on sheet TC12-0-LRE of the schematics.


We found the System Number on the service paperwork, #696.


We borrowed a TU56 tape head from the TU56 in the warehouse and replaced the broken right head. We reran ran MAINDEC-12-D3AE-PB PDP-12 TAPE CONTROL TEST, PART 1 OF 2. The diag runs OK, so at least the timing track in this tape head is OK. We reran MAINDEC-12-D3FB-D_Tape_Data_Test. This diag searches for the block number, but rocks the tape back and forth looking for the block. If you put the tape a long way from the beginning of the tape the diag will move the tape in the correct direction. We connected Warren's logic analyzer to the data signals that from the tape heads where they go into the M222 TC12 register cards. We also connected the logic analyzer to the register outputs that have the current block number. It looks like there are glitches on Data Track 1. We swapped the G882 modules in F07 and F09 for tracks D1 and D3. D1 looks much better Swaped the G882 modules back to the original slots and both D1 and D3 look OK.


We reran MAINDEC-12-D3FB-D Tape Data Test.

It failed in the same way. Instead of chasing the failure we decided to test all of the modules in the upper chassis that Warren had tests for. We found a M617 module in slot B28 that had a bad E1 output. The failure mode of the M617 would never be present in this slot in the TC12. We didn't find any other modules that were broken. The data for track D1 didn't look good. We swapped the G882 cards for tracks D1 and D2, but it didn't make any difference. I moved the tape to the right drive, the one with the borrowed tape head. I executed a 0707 instruction with various block numbers. It found each block and stopped. Lots of the Tape Data Test diag ran, including the write/read test T3 that had failed before. After it moved forward quite a bit the diag hung in the seek mode while it looked for a block. I reset the diag and started it again. It halted at 1231 I put the first LINCtape back on. The diag is stuck at 0035 in test X2 where it is looking for block 374. It looks like the first LINCtape that we have been using has bad blocks around block 374 and the second tape around block 5.


Dave Gesswein was able to pull the MARK12 LINCtape formatting program off a LAPS-DIAL tape image and convert it to a PDP-8 BIN formatted paper tape image. We will try to format a tape using this program. We could also try to boot a PDP-12 version of OS/8 from a LINCtape.


We loaded the MARK12 LINCtape formatting program that we got from Dave Gesswein. Since we don't have a working VR14 display we are "flying blind" when we enter the formatting commands. We entered a "1" for a standard LINC tape, and a CTRL-J for a Line Feed. We then set the right drive to REMOTE and pressed the MARK switch on the front panel. The tape moved about a foot and then the processor halted at 4412 in BLOCK, the subroutine that writes a block to tape. It looks like it is writing the End Marks at the beginning of tape, calls to the BLOCK subroutine, and then halts because the number of data words in a block is less than 14 words.

We reloaded the program and looked at the parameters passed to the BLOCK subroutine.

@4044 should be 2000 is 2000

@4045 should be 7777 is 7677

@4046 should be 0400 is 0400

@4047 should be 7770 is 7370

@4050 should be 7770 is 7770

@4051 should be 1024 is 1024

@4052 should be 0005 is 0005

@4053 should be 0010 is 0010

@4054 should be 4000 is 4000

We fixed the bits and did a AUTO STEP EXAM and the bits changed, so we have a memory problem. We loaded Warren's tune3 memory diagnostic. The 4000 to 4777 range in Field 0 has problems. We tried replacing the G221 in slot C08, but it didn't make a difference. It looks like there is a problem with a diode on the core stack. We replaced stack S/N 23139 with spare stack S/N 22732. The memory test works OK now.

We reran the MARK12 program. One tape reformatted OK, the second failed. We stopped the format program where the bad spot on the tape was, cut off about 30 feet of tape, and started the program again. This time the much shorter tape formatted OK.

We reran the MAINDEC-12-D3FB-D Tape Data Test and it works much better with the reformatted tapes.

We booted DIAL from LINCtape that contained diagnostics. Even without a monitor display we were able to load a diagnostic from the LINCtape and run it. We connected three different 'scopes to the display outputs, but could not get a readable display. We booted OS/12 from LINCtape.

LS=0702 RS=0000


Earlier we noticed that the right drive would work OK unless the left drive was set to REMOTE. There seems to be something wrong with the drive select logic that is not isolating the left drive.

We reran MAINDEC-12-D3AD Tape Control Test Part 1 of 2.

Ran OK.

We reran MAINDEC-12-D3GA Tape Control Test Part 2 of 2.

Ran OK.

We reran MAINDEC-12-D3FB Tape Data Test on the right drive with the longer scratch LINCtape.

Not sure if it is working OK. We will work on it next week.


Warren disassembled the VR14 further and found that all of the brown goo in the bottom of the chassis had actually leaked from the CRT. Since the PVA that leaked from the CRT is just industrial white glue it cleans up easily with soap and water. The metal bezel that holds the CRT into the chassis was glued to the CRT with silicone. We dug out the silicone, and removed the bezel.

The PVA was about 1/8" thick so we were able to pick at the edges to make removing the blast shield easier. While we were digging at the edges of the PVA we noticed that the blast shield was moving relative to the CRT We were a little surprised to find that most of the PVA had separated from the CRT and there was only a small area where they were stuck together. We were able to carefully separate the blast shield a little at a time and then cut the remaining PVA that held the blast shield in place.

This process was much easier than expected.

You can see that the PVA is nearly opaque so we would not be able to see anything on the CRT with it in place. When we first powered on the PDP-12 the main fuse in the VR14 display blew. A replacement fuse blew instantly too. Warren removed the high-voltage power supply so we could bench test it. We connected it to a Variac so we could slowly power it up, but didn't get any high-voltage output. Warren suggested reforming the caps in the voltage-doubler circuit. The high-voltage output that goes to the CRT is connected across both caps. We could only make 64VDC with our bench power supply, but that showed that the caps were not shorted and had low leakage. We repowered the high-voltage power supply with 10VAC from the Variac and saw 1,000VDC on the output. Warren connected 10 500 kOhm in series to the high-voltage output and ground and turned up the Variac. The resistors quickly started smoking, and showed that we were getting the 10,000VDC output. We bought some 0.093" LEXAN at Home Depot. We will make a small oven to heat and form it to the inside of the blast shield, and then use Silicone glue to assemble everything.


We put the sheet of LEXAN on top of the back side of the implosion shield and put it in an oven. We slowly increased the temperature and when it hit 325F the LEXAN sagged and conformed to the implosion shield. We trimmed the excess LEXAN with a radial arm saw, router, and belt sander. The plan was to sandwich the LEXAN between the CRT and the implosion shield. During assembly we found that if the LEXAN sheet touched the face of the CRT you could see diffraction patterns that almost looked like oil or water between the two parts. We made a spacer out of two layers of 1/4" wide double-sided foam tape to hold the LEXAN away from the CRT. Then we glued the CRT, LEXAN, and implosion shield together with silicone, and after it cured we glued the metal bezel on with silicone. Some restorers just use double-sided tape to hold the implosion shield in place. Since the PDP-12 is in a public space we added the LEXAN to improve safety.

The leaking decomposed PVA from the CRT ate the paint from the steel shield for the CRT. We repainted it with satin finish black and it looks like new. Tomorrow we will reassemble the VR14 and start debugging and testing.


We reassembled the VR14. It looks very nice, but it still blows the main fuse. We disconnected everything but the high-voltage power supply and the fuse does not blow. With just the G836 Power Supply and Regulator board connected it blows the main fuse. We started disconnecting things and got to the point where the G836 was installed, but the main fuse did not blow.

We found that a diode in one of the diode blocks for the +/- 43VDC power supply was shorted. Dan (the donor) had given us a spare, so the repair was easy.

Tomorrow we will reinstall the VR12 in the PDP-12 and see if it works.


We reinstalled the VR14 into the PDP-12. We ran the MAINDEC-12-D6BC-D VR14 VR20 DisplayTest and we have a working display! The vertical gain was way too high and would not adjust lower. The A225 flip-chip in slot A3 controls the vertical gain and offset, and the trimpot for the gain is open. We swapped the vertical and horizontal A225 flip-chips and adjusted the vertical gain. The vertical gain trimpot measured 1.1kOhms, so we soldered a fixed resistor across the open trimpot. The VR14 display works great!

The VR14 monitor looks just beautiful after the CRT was rebuilt.

We booted the MAINDEC-12-D7AH-UO tape, this is a LAP6-DIAL tape containing the diagnostic files.

We entered the PX command and displayed the contents of the tape. The dim parts of the text have not been refreshed for a while, so the issue is with the camera, not the CRT. When we got back from lunch and powered up, the system the X deflection on the VR14 did not work. We swapped the vertical and horizontal flip-chips, but there was still no horizontal deflection. The fuses for the deflection amps were OK. We eventually found that the video cable was caught between the VR14 and a bracket and had partially pulled out of the backplane. After lunch we powered the system up again, but this time it could not find any blocks on the tape. The tape controller diags showed the same results. Oh well, we will work on the TC12 next weekend. There is some interaction with the two drives in the TU56. If only one drive is activated it works OK, but if two drives are activated it can't find blocks on the tape. Warren tested the M series flip-chips an they were all OK. Maybe one of the relay boards is not turning all of the signals off?


Since we now have a working display we tried reformatting LINCtapes to see if the diags would work better. We tried the short tape on both the left and right drives. It wrote the Timing, Mark, and Data tracks in one pass, and then got stuck searching for blocks when it tried to verify the tape. We tried the long tape in the right drive, and it also got stuck searching for blocks. Warren connected his logic analyzer to the TC12 LINCtape controller so we could see what it is doing. We have lots of data from the TC12, but are not sure that the problem is in the TC12 LINCtape controller, the TU56 tape drive, or in the tapes. We respooled a DECtape (backwards) onto a LINCtape, but this one did not format correctly either. This makes us believe that the tapes are OK. We entered the LINC instruction to check a single block (0707) in the left switches and a block number (0777-0000) in the right switches. When we pressed the DO key it should go to that block on the LINCtape. With large block numbers (07xx) and with the tape positioned half way through the tape it worked OK. With lower block numbers it sometimes could not find the block and searched back-and-forth on the tape. The logic analyzer showed that the block numbers were correct in a sequence of several blocks, and then it will read a bad block number. The TC12 would tell the TU56 to turn around, it would read a good block number, realize that it was going the wrong direction, and turn the tape around. It would then read a good block number, and then a bad block number, and turn around. We also observed that sometimes the tape would move in one direction, slow down, pick up speed, and continue in the same direction. The logic analyzer showed that the TC12 was turning off the TAPE MOTION signal for about 500ns. This is a very short glitch and should not affect the TU56 motion, but is worth investigating. With large block numbers (77xx) the 0707 Check 1 Tape Block instruction works OK. With small block numbers (0007) the controller gets stuck in search mode.

We ran MAINDEC-12-D6CC-D-D_A_To_D_Test to see if the analog input

The eight knobs to the left of the console are connected to the first eight AC converters. These are used for program inputs and to control the cursor position when editing a text file in LAP6-DIAL. AD converter #16 is one of eight inputs at the bottom left of the picture. It reads 0103 when it should read 0, so the trimpot on the board need to be adjusted. The other AD converters and the pots on AD 0-7 all work OK. There are an additional 20 AD converters that we did not test.

We reran MAINDEC-12-D0GA-PM_Tape_Quickie to make sure that the TC12 registers worked OK.

Charles Lasner suggested that we swap the TU56 with a TU55 from the PDP-8/I. That would tell us if the TU56 is working OK on a known good TC01 DECtape controller. It would also let us test the TC12 with a known good TU55 tape drive. We will try this next week to see if we can isolate the tape problem to the TU56 or the TC12.


Victor disassembled the remains of a PDP-12 At Charle's warehouse and brought us the M222 and M221 modules. The modules were in bad condition, and several ICs had very rusty leads. Even with the rusty leads, three of the M222 boards passed testing in Warren's flip-chip tester. We will replace the ICs with rusty leads and retest the boards. If the still work OK, we will add them to our set of spares. We tried connecting a TU55 DECtape drive from a PDP-8/I to the TC12 LINCtape controller to see if the problem is in the drive or the controller. Unfortunately there was a problem with the tape control signals and the drive would not move in response to commands from the TC12. Warren looked through the logic analyzer data from last week's TC12 debugging and found that in some cases the block number jumped by 16. I swapped the M222 in slot AB19, but it didn't make a difference. I swapped the M222 modules in slots AB18 and AB17 and also saw no difference. I just realized that I swapped the endianness of the bits and should have swapped the M222 in slot AB20. We will try swapping the M222 modules in slots AB20, AB21, and AB22 on Sunday. Since we only observed problems with very low block numbers I installed the LAP6-DIAL maintenance tape, and ran the tape in about 10 feet. LAP6-DIAL booted OK, and I was able to list the directory, read source files, and load binary programs into core memory.

The crew at the LCM have a PDP-12 that they regularly demonstrate with a kaleidoscope program. They sent us the listing of the program, I toggled it in through the front panel, and it works OK.

08/28/2015 & 08/29/2015

Two more days of debugging on the PDP-12 LINCtape controller didn't accomplish much. We now a lot more about what is not broken, but haven't found the intermittent problem with reading tapes. We reran the Tape Quickie and TAPE CONTROL TEST, PART 1 and 2 to make sure that the controller was still OK. We tried reformatting LINCtapes on the right drive in the TU56. It sometimes worked OK, sometimes not. It doesn't seem to matter what tape we use, the intermittent behavior is the same. A LINCtape that formatted OK worked fine on the Tape Data diagnostic for quite a while and then halted. We noticed that if we were searching for a tape block on the right drive with the left drive OFF, it usually worked OK. With the left drive in LOCAL or REMOTE the right drive had trouble finding blocks. The only change between OFF and LOCAL & REMOTE is that the power to the motors is enabled. The motor power supply voltages looked OK in OFF and LOCAL & REMOTE. We swapped lots of boards between the left and right drives, but didn't see any difference. During the board swapping I put an M040 module in the wrong slot. That made for some really strange drive select behavior because it was shorting control signals. We need to investigate this issue further. Since we replaced the tape head on the right drive we speculated that we introduced a tape head skew problem that was causing problems when reading tapes created on other drives. The left drive was untouched, so we thought that one might work better. The left motor for the left drive in the TU56 was sticking so much that it would not turn under its own power. We suspected bad bearings, so that should be an easy mechanical fix. When we removed the motors we found that the motor shafts turned freely. We found that there is a pair of bushings and spring on the motor shaft that take up the play and make the tape alignment more accurate. The lubricant on bushings and shaft had dried out and was sticky, making it difficult to rotate the shaft. Unfortunately after cleaning and reassembly we found that the left drive would barely read a tape. Maybe this is related to the previous problem?

Warren has lots of logic analyzer traces that he can look through this week. Warren saw evidence on the logic analyzer traces that might indicate a timing problem in the TC12 LINCtape controller.

Volume II of the PDP-12 documentation includes many procedures to adjust the timing in the TC12 LINCtape controller.

The 3.5.2 LTD XTLK Delay notes say that the TC12 LINCtape controller may have trouble finding blocks if this is not adjusted correctly.

The 3.5.3 LDT TTOK Delay notes say that the tape may rock in one position when searching for a block if this is not adjusted correctly.

The 3.5.5 LTD ACIP Delay notes sat that the TC12 LINCtape controller may have trouble finding blocks if this is not adjusted correctly.

The 3.5.6 Mark Clock Adjustment notes say that the TC12 LINCtape controller may have problems writing to a LINCtape if this is not adjusted correctly.

Section 3.7 describes two adjustments on the TU56 tape drive for the brake timing and the oscillator.

Next Friday we will check all of these adjustments.


The PDP-12 Maintenance Manual-II describes the procedures for checking and adjusting the TC12 timing and warns that misbehaving can be due to incorrect settings. We hoped to find an incorrect setting that was causing the problem with the LINCtapes. Most of the delays in the TC12 are controlled by M307 One Shot flip-chips. These boards have Fairchild 9601 ICs in them. We didn't have any spares, so we bought some on eBay just in case...

The TC12 has extensive maintenance capabilities and will let the processor simulate just about any condition in the TC12. With a short toggle-in program we were able to check all of the basic timing signals LTT TP0 L, LTT TP2 L, LTT TP3 L, and LTT TP4 L signals. We were also able to exercise the M307 One Shot boards that control the timing in the TC12 LINCtape controller. We adjusted LTD XTLK H from 9.15 us to 9.5 us according to the written notes in the maintenance manual.

We adjusted LTD TTOK from 47 to 48 us.

We left the LTD TAPE FAIL Delay at 304 ms because the sample accuracy of the scope was only +/-4 ms.

We adjusted the LTD ACIP Delay from 145 ms to 180 ms.

We adjusted the Mark Clock from 7.7 to 7.5 us.

Unfortunately none of these adjustments made any difference, and the LINCtapes still misbehave.


Warren wrote some more flip-chip test programs and found an M121 NAND-NOR gate in slot B32 where the J2 output was bad. We replaced the SN7450 E1 on the flip-chip and it tests OK now. The J2 output is part of the Group Counter control logic on schematic page TC12-0-LGP. The particular failure condition will never occur in the TC12. We always fix these issued because we might swap the flip-chip into another location and cause debugging problems. He also found an M161 in slot J40 that had four bad unused outputs. We replaced the SN7420 E8 and it tests OK now. We adjusted R5 on the G869 module in the TU56 tape drive. It was set to 36 Hz and should be set to 40 Hz. This will make the tape motors run about 10% slow. After readjusting the motor speed we successfully formatted three LINCtapes.

We ran MAINDEC-12-D3DB Tape Data Exerciser.

It sometimes had problems finding blocks, but ran for about 10 minutes. We tried it with both drives and it immediately failed when it used the left drive.

We ran MAINDEC-12-D3FB Tape Data Test.

It showed the same behavior for trying to find blocks. There seems to be a problem where it moves forward looking for a block, almost stops the tape, then picks up speed again. We will likely need to write some small diag programs to help us determine what the problem is.

09/25/2015 & 09/26/2015

We got diverted for a while by Thi dropping off her Printrbot kit. It is now assembled and working. Very cool!

We finally followed Charles Lasner's recommendation and swapped the TU56 DECtape drive from the PDP-12 with a TU55 from the PDP-8/I. We had to add a wire to deliver +10V to the TU55 in the PDP-12. Neither drive works in the other system. Both drives get selected, the brakes turn off, but there is no motion, very strange. Setting the TU55 drive to unit 1, and setting the unit to 1 in a TC12 instruction cause no drive to be selected. The drive select signals should be about -4V when inactive, and ground when active. We saw most of the drive select signals sitting at ground when inactive. If you changed the drive unit number to match the drive select, the signal when to about -1.5V. There are pulldowns on the W512 boards that drive the select signals, so it should not do this. There is a pulldown on the SELECT signal in the TU55 so that explains the existing bad behavior. We will debug this more later this week. Last week we adjusted the 40HZ signal that controls the speed of the TU56 DECtape drive. The speed was about 10% lower than it should have been. Increasing the tape speed seems to have made the tape behavior worse. I put my hand on the tape reels to slow them down and it actually booted OS/12, so there is a speed or timing issue with the TU56 and TC12.


The project for today is to determine why the TU55 doesn't work in the PDP-12, and why the TU56 doesn't work in the PDP-8/I. We put the processor in LINC mode, set the left switches to 0707(check a tape block on drive 0), and did a "DO".

In the TU55:

  • Pin A05V goes to Ground when drive 0 is selected.

  • Pin A05M stays at -3.5V.

  • When the TU55 is set to unit 8 the select light goes on.

We put the processor in LINC mode, set the left switches to 0717 (check a tape block on drive 0), and did a "DO".

In the TU55:

  • Pin A05V stays at -3.5V.

  • Pin A05M stays at -3.5V.

  • When the TU55 is set to any unit the select light goes does not go on.

We finally figured out that the control signal connection on the TU55 is single-sided and double-sided on the TU56. We borrowed a one-to-one control cable from the PDP-8/I and now the TU55 select and motion signals work OK. The TC12 misbehavior is the same with the TU55 drive as it was with the TU56 drive. Time for more TC12 debugging. After the system had been powered on for a few hours it started behaving OK. LAPS6-DIAL would not boot, but OS/12 did boot.

The tape included BASIC, so we gave that a try.




20 END








ABSLDR.SV 0070 5 20-SEP-74

CCL .SV 0075 17 02-NOV-74

FOTP .SV 0116 8 22-OCT-74

PIP .SV 0126 11 02-NOV-74

DIRECT.SV 0141 7 02-NOV-74

RESORC.SV 0150 10 20-SEP-74

BOOT .SV 0162 5 20-SEP-74

BUILD .SV 0167 33 02-NOV-74

HANGMN.SV 0230 8 25-OCT-74

SNOOPY.SV 0240 15 25-OCT-74

MOON .SV 0257 14 25-OCT-74

HANGMN.BN 0275 5 25-OCT-74

PING .SV 0302 8 25-OCT-74

HANGMN.WD 0312 2 25-OCT-74

CHESOV.PA 0314 17 25-OCT-74

CHESS .SV 0335 22 25-OCT-74

CHESS .BN 0363 21 25-OCT-74

CHESS8.SV 0410 17 25-OCT-74

DIALPS.SV 0431 21 25-OCT-74

CUBIC .SV 0456 8 25-OCT-74

KALEID.SV 0466 2 25-OCT-74

EDIT .SV 0470 10 18-JAN-74

MARK12.SV 0502 7

SOS .BN 0511 2 10-DEC-74

SOSDEF.PA 0513 2 10-DEC-74

BLINK .PA 0515 1 26-NOV-74

BLINK .BN 0516 1 26-NOV-74

EPIC .SV 0517 14 02-NOV-74

BASIC .SV 0535 73 02-NOV-74

TECO .SV 0646 12 02-NOV-74

PAL8 .SV 0662 16 02-NOV-74

EDU200.SV 0702 31 02-NOV-74

CREF .SV 0741 13 02-NOV-74

DESCR .TM 0756 2 02-NOV-74

TC12F .SV 0760 11 26-NOV-74

SSINST.WU 0773 6 10-DEC-74

SOS .PA 1001 14 10-DEC-74

MAGSPY.SV 1017 27 19-MAY-72

TEMP .TM 1052 73 07-NOV-71

FENWEL.FT 1163 2

<EMPTY> 1165 8

BTEMP .FT 1175 1 31-MAR-75

<EMPTY> 1176 3

ATEMP .FT 1201 1 31-MAR-75

<EMPTY> 1202 12

BETA .FT 1216 2 01-APR-75

<EMPTY> 1220 6

FENWAL.FT 1226 3 01-APR-75

<EMPTY> 1231 5

LINES .FT 1236 3 02-APR-75

TEMP .FT 1241 1 02-APR-75

<EMPTY> 1242 63






01 SYS LINC RWF 737 SYS 0 A 07

02 DSK LINC RWF 737 16 1 A 11

03 LTA0 LINC RWF 737 16 0 A 10

04 LTA1 LINC RWF 737 16 1 A 11

05 LTA2 LINC RWF 737 16 2 A 12

06 LTA3 LINC RWF 737 16 3 A 13

07 TTY TTY RW 17+ KL8E C 176

10 TV VR12 W 20+ A 13

11 PTP 41 W 21 00

12 PTR 42 R 21 115


OS/8 V3

The TV device is the VR14 display. We used PIP to copy a text file to the CRT and it actually worked! It has been running OK for a few hours, and now it is back to the bad behavior. Using the LINCtape that we formatted this afternoon on the TU55, a 0702 read LINC instruction finds and reads a block on the first try. A 0700 read & check LINC instruction retries constantly and displays a different, non 7777, result in the AC each time. I believe that a 7777 in the AC indicates that the checksum was OK.

MAINDEC-12-D3AD Tape Control Test Part 1 of 2 runs OK.

MAINDEC-12-D3GA Tape Control Test Part 2 of 2 runs OK.


We did some more debugging on the LAP6-DIAL boot problem. The 0701 7300 boot instruction will read & check tape block 300 plus 7 more blocks. The first four blocks go into Instruction Field 0000-1777, and the second four blocks go into Data Field 0000-1777. The boot block executes a 0720 4310 instruction to read & check tape block 310 into Data Field 0000-1777. It then reads blocks 311-314, and executes the code starting at 0026. The code then reads tape blocks 315-321, but gets a checksum error when it reads block 316. This may be a data sensitivity problem, or a bad spot on the tape. We filled LINC memory block 0 (in the Instruction Field) with a pattern that alternated the bits on data tracks 1, 2, and 3. We then executed the LINC instruction to write this memory block to a tape block. With most tape blocks it would write, backup, read, get a CRC error, and retry the process. Sometimes after a number of retries it would work and stop with the AC=7777. Warren connected his logic analyzer to the LTR * READ H outputs of the W603 module in slot F16, and a some of the control signals. We could see the TC12 search for a block, switch to write mode, backup the tape, search for the block, and read the data.

During the write process we saw glitches on data track 3. We had previously swapped the G882 READER/WRITER modules, and it didn't make a difference. We suspect that there is a problem on the W603 module, but the diodes and transistors all have reasonable resistance values. We have some transistors that we can use for replacements for the DEC3009B transistors on the W603 module.


Yahoo! Based on the finding from last week we replaced the W603 Positive Level Amplifier in slot F16 with an untested spare. OS/8 booted up without any issues and seems to be running OK. Well, it was premature thinking that the TC12 was fixed. LAP6-DIAL and the DEMO tape will not boot. We swapped the G882 for data track 3 in slot F09 with one from the TC01 in the PDP-8/I. It didn't make any improvement. We still see glitches on track 3. We swapped the G882 modules in slots F07 and F09 for tracks 1 and 3. The track 3 behavior is better, but not perfect. We swapped the W512 modulein slot F13, but there was no improvement. We swapped the R107 inverter in slot F12, but there was no improvement. We swapped the three G882 modules in slots F07, F08, and F09 with ones from the PDP-8/I with no change, We put the G882 modules from the PDP-12 into the PDP-8/I and the 8/I still boots OK. We swapped the TU56 back into the PDP-12 and the TU55 back into the PDP-8/I.


We are still looking for the problem in the TC12 LINCtape controller. The TU56 tape drive is back in, and doesn't work as well as the TU55 drive did. We swapped the drive track data inputs to the logic analyzer to make sure that we didn't have bad input instead of a bad data signal. We connected a 'scope to the input P2 and output N2 of the W603 module in slot F16. We can see the track 3 glitches on both the input and output of the W603 module. We looked at the LTR WRITE ENABLE ON L signal, but didn't see any glitches during reads. We are now officially stumped about what is broken in the TC12 LINCtape controller.


The RX8-E diskette controller and the RX02 (configured to be an RX01) were tested in Mike's PDP-8/e. Both work OK, so when we connect the DW8E-PC Omnibus Expansion Chassis we should have working floppy diskette drives. We bolted the two cabinets together, interconnected the AC power control, and it works OK. The AC power to the RK05, DW8E, and RX02 is not obvious. It looks like the DW8E is powered from the I/O cabinet power controller, and everything else is powered from the processor cabinet. We reformed the capacitors in the DW8E, and powered it on. The voltages looked good for about 3 minutes, then there was a flash when a pico fuse blew, and then the +5V went to about 1.0V. The power supply is not complicated, so it should not be difficult to fix. We removed the M841 Line Printer Controller and replaced it with a RX8-E controller for the RX02 floppies.


The -15V feed wires for the memory backplane go right next to the pins on the G882 for track 3. We moved the wires out of the way, but it did not change the tape behavior. We put jumpers between the drive signal cable paddle card slot and the G882 for track 3, but it did not make a difference in the behavior. We decided to take a break from the TC12 and see if any of the other peripherals would work.

We looked at the voltages in the DW8E power supply again. The -15V is working OK. Fuse F1 is blown, so there is no power to the +15 and +5 regulators. We connected a lab supply up to the load end of blown F1 fuse, and slowly increased the voltage while watching the current. Up to about 6.2V the output on the +5 regulator is OK, and it only draws about 200mA. When the input voltage gets to 7V and the output gets to 6.3V, the input current go to more than 1A and the output voltage falls to 0. So, the crowbar in the +5V regulator is firing because the output voltage got too high. We disassembled the chassis and power supply. After we fiddled with the voltage adjustment it regulated correctly. We replaced the 15A pico fuse with a full size 10A fuse so we could continue debugging. We reassembled the chassis and measured the voltages in the Omnibus. As soon as I plugged in my dual extender card the fuse blew again. It turns out that my extender connects pins A1 across the two slots, so that shorted +15V to +5V and blew the fuse. We replaced the fuse again, and measured the voltages with a single wide extender. All of the voltages look OK. We reinstalled the DW8E in the PDP-12 and connected the I/O cables. The RIM loader would not run and the I/O bus hung as soon as any IOT was executed. By the process of elimination we determined that the cables from the RK8F to the RK05 drive were on backwards. Once we disconnected the RK05 cables the processor ran normally. We loaded and ran some simple RX8-E diags that I wrote. It looks like there are problems with the DONE flag in the RX8-E. The RX8-E and RX02 drive worked fine in my PDP-8/e, so the problem is likely in the DW8E. We can work on that next week.


Vincent Slyngstad donated a M452x Baud Rate Generator and a W076x TTY Interface replacement that he designed and made. The baud rate generator is switch configurable from 110 to 19200 baud. The TTY interface has the same RS-232 connector interface as a PDP-8/a hex-serial card, or a PDP-11 serial card. Warren made a serial cable and it works OK. Last week my simple RX01 skip tests showed that the DONE flag was on after the I/O PRESET was pressed. The skips for Transfer Request and Error Flag are working OK. It works OK if you disconnect the cable to the RX02. I forgot to put that note in my source code.

We loaded and ran MAINDEC-08-DIRXA-D-D RX8-RX01 Diagnostic Program.

It reports errors that are very repeatable from the start, then after the errors it runs OK.


OD = 1 ID = 114 FIRST = 1 LAST = 32



425 404 404 4 0 204 0

445 404 404 4 4 204 0


1440 1260 1401 4 4 204 0

1440 1260 1401 4 4 204 0

1440 1260 1401 4 4 204 0

1440 1260 1401 4 4 204 0

1440 1260 1401 4 4 204 0

1440 1260 1401 4 4 204 0

1440 1260 1401 4 4 204 0

It looks like it is dropping the INIT [DONE] bit in the first error and the SEL DRIVE RDY bit in the subsequent errors. I am not convinced that this is a problem. It is much happier running a full set of diskette diagnostics, instead of just the controller diags. We tried to boot OS/8 from a floppy that works OK on a PDP-8/e. It read the floppy a little, and halted at 0425. It may be because we have only 8k of core, and the diskettes from my 8/e all run in 32k. We may have to run build and limit OS/8 to 8k. We ran some additional diagnostics just to see how the console port works at 19,200 baud. It looks like there are some problems with the MQ register.


We have both serial ports working. The console port uses Warren's current loop adapter and Vincent's baud rate generator. The second port uses Vincent's RS-232 adapter and the donor's home-made baud rate generator. We tried to boot OS/8 with Kyle's SerialDisk server from the second serial port. It loaded part of OS/8 and then tried to read the wrong part of the RK05 disk image. This needs further debugging, and when working will provide an easy way of getting files from/to the PDP-12. We made an RX01 diskette containing OS/8 on my PDP-8/e. Warren will try to boot the PDP-12 from the RX01 diskette. This should work, but was never a supported configuration on the PDP-12.


Previous attempts to boot OS/8 from the RX01 failed. Warren traced the problem to the M7102 in slot AB17 in DW8E, the Omnibus expansion chassis. We replaced IC E14, a SP380, and now it works. We were able to boot OS/8 from the RX01 diskette. This may be the only PDP-12 to ever do that. Booting from the SerialDisk failed because the disk handler included the BSW instruction that is only supported on the PDP-8/E/F/M systems. We modified the handler to replace the BSW instruction with three shift instructions, and reassembled it. Kyle's handler installer didn't like the modified handler, so we have some debugging to to.


Warren finished the modifications to the SerialDisk handler. We were able to boot OS/8 from an RK05 image from a SerialDisk server running on a laptop. We did a log of experimenting with OS/8 BUILD trying to add the SerialDisk handlers to OS/8. All attempts were unsuccessful because the OS/8 images that we are running expect more than 8k of memory. At the end of the day the PDP-12 was behaving strangely.


The PDP-12 booted OS/8 from diskette and SerialDisk OK. We tried limiting the memory that OS/8 would use to 8k words, and OS/8 started doing strange things. We ran processor and memory diags just to make sure that they are still working OK.

We ran:

  • MAINDEC-8I-D01C Instruction Test 1

    • Runs OK.

  • MAINDEC-8I-D02B Instruction Test 2

    • Runs OK.

  • MAINDEC-12-D0AB CP Test 2

    • The LINC CLR instruction @4646 did not clear the MQ.

    • The M617 flip-chip in slot J21 had a 7440 chip with an output stuck active.

    • This failure is unrelated to any of the unusual behavior we observed when running OS/8 from SerialDisk.

    • We replaced the M168 with a NOS tested spare.

    • Runs OK.

  • MAINDEC-12-D0CB CP Test 3

    • Halted @5242 with an unexpected interrupt.

    • The diag was resetting the peripherals. After about 5 seconds the RX8-E finally went ready and generated and interrupt.

    • Unplugged the power to the RX01 to prevent the RX8-E from generating going ready.

    • Runs OK.

  • Warren's Memory Tuning and Diagnostic program

      • Field 0 and 1 both tested OK.


We ran some EAE diagnostics for the first time. MAINDEC-08-D0BA Instruction Test 3A EAE runs OK MAINDEC-801-3A and the newer MAINDEC-08-D0AA Inst test 3A EAE, look like the find that the SHL instruction hangs the processor. We found the T2 output of the M160 module in slot M35 was bad and replaced it with a repaired spare.

MAINDEC-801-3A runs OK now.

We reran the rest of the PDP-12 processor diagnostics, and they all run OK.

We ran MAINDEC-12-D8CC-D_KW12A_Clock_Test.

It printed TST11 CLBA FAILED, 0000 7777, and halted at 5034. A small toggle-in test showed that we can't write-read the Buffer Preset Register.


Warren found a bad SN7430 on the M103 module from slot D25. This prevented all of the IOT signals from getting to the KW12 clock. We replaced the M103 with a tested spare.

We reran MAINDEC-12-D8CC-D_KW12A_Clock_Test.

It halted at 1336 with the message TST34 O'FLO FAILED TO SET O'FLO FLOP. The previously tested M216 module in slot F19 was bad. We replaced the M216 with a repaired and tested spare. It halted again at 1336 with the same message TST34 O'FLO FAILED TO SET O'FLO FLOP. The fault in the M216 was actually for the CLR COUNT flip-flop, not this particular issue.

We visit RCS/RI and used their PDP-12 to format some LINCtapes. We booted from our OS/12 tape to get MARK12 running. The version on our OS/12 tape is older than the paper tape image that we have been using and does not have the option to format long LINCtapes.


We spent most of the day debugging the KW12A Clock where the Overflow flip-flop was not getting set. There was an ECO EM12-0055, applied to the KW12A about 1971, that changed the behavior enough so that MAINDEC-12-D8CA KW12 Clock Test would not run. Since this system was manufactured in 1973, we guesses that the ECO was applied during manufacturing. I had read somewhere that the MAINDEC-12-D8CC KW12 Clock Test would run on KW12s with the ECO applied. After spending several hours with a logic analyzer and the prints were unable to understand how this should work. Warren reread 1974 Field Service Technical manual and found that we needed MAINDEC-12-D8CD KW12 Clock Test. We could not find a copy on any Internet archive, but found a copy on a LINCtape image at PDP-8 Online. I wrote a C# Windows application a while ago that will read and interpret a LINCtape image. We used this program to create a BIN format paper tape image from the file on the LINCtape image. Warren edited the resulting BIN paper tape image so that it would not overwrite the RIM and BIN loaders.

The resulting MAINDEC-12-D8CD KW12 Clock Test ran OK.

So we did have a hardware problem in the device selector in the KW12, but that was the only problem. Unfortunately we also found that the prints that came with the system do not include ECO EM12-0055. There are wiring differences in both the KW12 and the core memory that we do not have documentation for.


We worked on the PC04 paper tape reader/punch today. We removed all of the flip-chips, fuses, reformed the capacitors, and cleaned everything we could reach. We powered up each section of the power supply separately, and all of the voltages were OK. We reinstalled the PC04 in the rack and connected it to the PC8-E controller in the DW8E Omnibus chassis. Loading a paper tape with the BIN loader failed. I guess that was wishful thinking. A little toggle-in program sent all binary combinations to the punch, and everything looks OK. Another toggle-in program tried to read characters from the paper tape and display them in the AC. Sometimes the reader did not index forward one hole. The stepper problem could either be the pair of SN7474 flip-flops on the PC8-E controller or M040 flip-chips in the PC04. The data from the paper tape is not read correctly. This could be an artifact of the tape not stepping correctly and not generating a feed-hole strobe signal. There is a threshold adjustment on the G918 Photo Transistor Amplifier that may also fix this. The reader issues should not be difficult to debug and fix.


We made some progress on the PC04 paper tape reader/punch. The ramp generator and triggered free-running multivibrator on the PC8-E controller is supposed to slowly speed up and down the stepper motor that moves the paper tape so the tape does tear. This one was ramping up nearly instantly, and could not be adjusted. It turned out that the -15V power supply in the DW8E expansion chassis that holds the PC8-E controller had failed again. The fuse was blown so that was an easy fix. Well, it worked for just a few minutes and failed again. After lots of debugging we decided that there was probably a bad solder joint on the PCB, so we re-soldered every connection in the -15V part of the power supply. The -15V power supply works reliably now. The stepper motor in the paper tape reader works correctly now, but it still does not read data from the paper tape. That will be the next debugging project. We are getting close to looking at the RK05 disk drive. We discussed disassembling the disk pack so we can clean it. I think that we have a disk pack cleaner in the warehouse that we could try. The foam seals in the disk drive have decayed. Home Depot has weatherstripping that we can use, but some disassembly will be required. After we clean the heads, we can try to manually move them onto the spinning disk pack. If that goes well, we can see if the disk drive will go ready, and then try to boot from the drive. There are nicad batteries in the disk drive that retract the heads on a power failure that need to be replaced.


We moved the position of the drive wheel and the stepper motor to align the holes in the paper tape with sensors. We readjusted the threshold of the Photo Transistor Amplifier. The feed hold strobe signal looks OK now. We readjusted the timer on the PC8-E that strobes the stepper motor. It reader behaves much better now. We adjusted the Photo Transistor Amplifier threshold adjustment while a count 0-256 tape was being read. We adjusted the speed of the reader to as close to 300 CPS as we could. It appears to be working. We loaded FOCAL-69 from paper tape. It said that we successfully loaded FOCAL on a PDP-5.


We continued working on the PC04 paper tape reader/punch. Bit-7, feed hole 8 on the PC04 punch is always on. Swapped the M044 between slots A04-A05 and the problem moved to another punch pin. The R output on the M044 module in slot A05 is stuck on because transistor Q1 is bad. We replaced it with a tested spare. We noticed that the optical light assembly in the PC04 reader was loose. We adjusted it for minimum voltage from the feed hole phototransistor. We checked the power supply voltages. They were 5.08 and 15.04, so no adjustment was necessary.

We tried running the new MAINDEC-08-DHPCA-A-D High-Speed Reader-Punch Test, but it doesn't work correctly.

The DW8E doesn't support IOT instructions that end in 0, like used to enable and disable interrupts on the PC8-E. This may be causing problems with the tests. We tried running the old MAINDEC-08-D2FA High-Speed Reader-Punch Test, but it doesn't work correctly. It fails on timing tests. It is possible that the 750 controller that it expects behaves differently from the Omnibus PC8-E that we have.

We ran some more diags from paper tape.


MAINDEC-12-D3AE Tape Control Test Part 1 of 2

MAINDEC-12-D3GA Tape Control Test Part 2 of 2


We ran all of the diags that we have not run so far.

MAINDEC-08-D02B PDP-8 Instruction Test Part 2B, runs OK

MAINDEC-08-D0BA Instruction Test 3B, runs OK, prints 3B

MAINDEC-08-D1AC Memory Power On/Off Test, runs OK

MAINDEC-08-D1EC Extended Memory Checkerboard

MAINDEC-08-D1GD Extended Memory Control, runs OK

MAINDEC-08-D1HA Extended Memory Address Test, runs OK

MAINDEC-08-D1KA KP8I POWER FAIL TEST, don't have the option



MAINDEC-12-D1BA JMP Self, runs OK

MAINDEC-12-D1EA Float 1s and 0s Through Memory, runs OK

MAINDEC-12-D1FA Basic Memory Control Test, runs OK

FOCAL-69 won't run on this system because it executed a 6762 instruction intended to initialize a TC01 DECtape controller. The 6762 instruction causes a PUSH instruction to field 2 to be executed by the Automatic Priority Interrupt controller and starts executing instructions in non-existent memory. We replaced the 6762 instruction at 4376 with a 7000 NOP and now FOCAL-69 runs OK. It also identified the system as a PDP-12.


We planned to do some fine tuning in the PDP-12's paper tape reader/punch, but it would only run at about 10% of the normal speed. This was one of the original symptoms that we observed on 12/26/15. We quickly confirmed the -15VDC power supply in the DW8E Omnibus expansion chassis had failed again. At least this time if failed hard so we could finally track down the intermittent fault.

We powered the supply through a Variac so the -15VDC would not go above -18VDC, trip the crowbar, and blow fuse F2. Transistor Q22 was full on, so the output voltage would go to nearly -40VDC if the crowbar didn't trip at -18VDC and blow the fuse. The adjustment trimpot R26 had no effect on the output voltage. We replaced the two XA05 transistors, Q24 & Q25, in the power supply regulation circuitry with 2Nxxxx transistors. The power supply will now regulate, but can't be adjusted low enough to make only -15VDC. We need to do some more research and finish this repair next week.


We replaced all of the transistors in the -15VDC power supply in the DW8E chassis, but it still does not regulate correctly. We need to do some more research and give it another try.


The PDP-11/05 uses the same power supply regulator board as the DW8E, so we got a chassis from the warehouse to use for comparison. The power supply in the 11/05 shows switcher behavior on the +5 and -15 without any load. Increasing the load increases the frequency of the switcher, but not the pulse duration. The power supply from the DW8E shows switcher behavior on the +5 with a load, but a steady 5.2V and no switching without load. It is possible that it really is switching, but at a once every two or three seconds rate. We will probably ignore this because it works OK with a small load. We removed Q24 and were able to turn Q23/Q22 on and off, so those transistors that we replaced last week work OK. Last week we noticed that the NTE288 replacement for the XA55 transistor Q26 had the Emitter and Collector leads swapped from the originals. Last week we replaced Q26 with a new part installed in the correct orientation, but didn't see any difference in the switching behavior. When I went to put a new Q24 back in Warren suggested that I check the Emitter and Collector lead locations. Warren refers to this process as adult supervision. Of course these NTE287 transistors also had the leads swapped. I put the new Q24 in and replaced Q26 and Q21 that were also in backwards. Now the power supply has a very low output voltage and is not switching. At least it does not trigger the crowbar and blow the fuse. Warren and Alex will work in the power supply this week, and hopefully solve the mystery.


While I was in Germany Warren and Alex replaced Q26 again and now the -15V is working OK. We ran the power supply under load for a while and then adjusted the voltages about 5% high to take care of cable losses. After reassembling everything the paper tape reader is back to running at full speed. If you read a single character it actually reads two. That is fixed by one of the adjustments on the PC8-E controller board. Alex and I are creating LTspice models of the power supply so we can better understand how it works. When the models are working OK we will post them on this page.


We worked on the LTspice model of the -15V power supply and compared the model to the real power supply's behavior. We used Alex's GenRad LCR bridge to measure the resistance and inductance of the power transformer and loaded the values into the model. The model is now very accurate and lets see things, like transistor base current, that are difficult to measure in the real supply. We restarted the work on the paper tape reader, where we left off a few weeks ago. It seems to read OK at full speed, but reads more than one character when you ask for just one. We fiddled with the position of the paper tape relative to the reader's photo-diodes by adjusting the position of the drive stepper motor. We also adjusted the photo-diode threshold to get a 150ms feed-hole strobe signal. It seems to work better now, so next week we will run the diagnostics.


We spent most of the day working on the LTspice model of the H740 power supply. The +15V and -15V parts of the LTspice model are working very well, but the +5V regulator needs some debugging. We have come to the conclusion that transistors that we replaced in the power supply were probably OK. From studying the simulated behavior of the -15V regulator, we found that it is very sensitive to the behavior of the main capacitor, and that capacitor was not working well. Alex spent a lot time reforming and exercising C14, the 3000 uF capacitor on the -15V output, and dramatically improved its behavior. After the reforming the capacitor the -15V regulator worked correctly. The repaired power supply and paper tape reader are still working OK.


We found that the +5 switcher in the H740 real power supply and the model don't work well with output capacitors that have a low value. We continued working on the paper tape reader. The MAINDEC-08-DHPCAB diagnostic said that the reader is running at 304 characters per second, where 300 is perfect. This is close enough, so we will leave the speed adjustment as it is.

We started cleaning the RK05 Disk drive. The foam that seals the blower, and the foam that seals the air supply