DEC PDP-12 Restoration
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.
PDP-8 Works: IAC, RAL, RTL, CLL, CLA, LINC
PDP-8 Broken: CMA, CML, RAR, RTR, OSR
LINC Works: COM, ATR, RTA, RSW, LSW, PDP
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.
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.
We ran MAINDEC-12-D3AE-PB PDP-12 TAPE CONTROL TEST, PART 1 OF 2.
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.
DO, START 20
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.
We reran MAINDEC-12-D3GA Tape Control Test Part 2 of 2.
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