DEC PDP-8/I Restoration
We did an initial survey of the system. There is some corrosion on the modules. The corrosion is not extensive and can be cleaned without damaging the modules.
Click on the image for a larger view.
There is some corrosion on the AC power distribution terminals in the cabinets.
This can be cleaned. One of the red AC wires needs a new faston terminal installed.
The capacitors in the 704A and the two 779 power supplies need to be reformed.
We can use a Variac to reform the capacitors on the 779 power supplies. We did this for the PDP-8/S.
Warren recommended using an adjustable DC power supply to reform the capacitors on the 704A power supply.
We used a current limiting laboratory power supply to reform the capacitors in the 704A and 799 power supplies.
We set the current limit to 10 mA and the voltage to what the capacitor was rated for.
After a short time the current consumption went nearly to zero and the voltage went to the limit.
We performed this procedure for each capacitor in each power supply, and all worked OK.
The power switch on the console was not working, the power was always on.
After inspection we found that the switch was corroded, melted, and shorted.
We jumpered the power to always be on and disconnected the damaged switch.
We powered on the PDP-8/I power supply, and even with a load connected the voltages looked. OK.
We used a trick, connecting the Ground & +15V power backwards on the front panel to turn on all of the lights.
We were a little surprised to see that all of the lights worked except for EXECUTE and RUN.
The RUN light will be very useful, so we will take the front panel apart and replace the lights.
We started cleaning the modules in the system. A little work with a brass wire brush, a tooth brush, and some isopropyl did wonders.
We will need to finish cleaning the modules in the CPU, the TC01 Dectape controller, and all 5 of the TU55 tape drives.
We connected the power supply to the CPU to see if there was any life. We were rewarded with some lights and random CPU behavior.
At least we are familiar with the CPU design from resurecting the PDP-8/L, so this job should not be too dificult.
Click on the image for a larger view.
Warren decided to skip this Saturday because of the weather. I left after three hours because there was about 6" of unplowed snow in front of the entrance.
I finished cleaning the processor boards. The oxidation on the PC traces cleans up easily with isopropyl and a tooth brush.
I had to scrub the gold fingers a bit to clean up some of the black deposits.
I powered on the system again to see if there was any improvement.
Now there are some changes to the lights when you press the start key, but not what you would expect.
I suspect that this system will be more challenging than the PDP-8/L to get running.
I reconnected the AC to the power supply for the first three TU55s.
The voltages looked OK, so I reconnected the DC outputs to the drives and the TC01.
Two of the drives have some strange behavior with the brakes and the motors when you press the forward or rewind buttons.
I will take better notes of their behavior next Saturday.
There was no AC to the power supply for the fourth and fifth TU55s.
I think that this power supply is fed from the corroded AC distribution block at the top of the cabinet.
We need to crimp on a new faston connector one one of the red wires. That may fix the AC power problem.
We repaired the broken AC wire where it connected to the terminal block at the top of the cabinet.
Now all five TU55 tape drives powered up.
We were also rewarded with lights on the display panel of the TC01 Dectape controller.
With drive #1 at the top left and going down and then left to drive #5, the state of the TU55 drives is:
The drive defaults to the rewind state.
Both motors can be put in the tension and torque states.
Both brakes are inoperative.
Everything works, except that there is never any back tension.
The mounting bracket is broken off the brake drum.
We will see if we can disassemble the brake and spot weld the parts together.
Everything works OK.
The left motor is inoperative.
We discussed the best way to approach the processor restoration.
Since there is so much wrong with this processor we will install the modules, one at a time, in the PDP-8/L for testing.
Once we test and repair the processor modules we will reinstall them in the PDP-8/I and start the system debug process.
When we get the processor working OK we can start on the TC01 Dectape controller.
Click on the image for a larger view.
We started testing the modules from the 8/I in the 8/L.
This will save us a lot of debugging time by having know good modules (well at least know to work in the 8/L) in the 8/I.
We tested all of the M220 modules first because you can't get much debugging done without working registers.
One of the M220 modules has defective SN7474 chip and the other has a defective SN7453.
I will repair these this week so they are available for testing next Saturday.
We also had issues with the M216 modules in the 8/L, and found two defective ones.
These modules control instruction and memory states so it is very important that they work correctly.
The M310 modules control timing, so again they are important.
We found four defective ones. We had three working spares, and will repair the fourth.
We tested the repaired M220 and M310 modules in the 8/L.
One of the M220 modules works OK and the M310 works OK.
One of the M220 modules has yet another problem, this time a SN7474. I will replace that IC this week.
We continued testing the modules from the 8/I in the 8/L.
We found 8 more broken modules today.
Some we replaced with spares from the parts 8/L, the rest will be repaired.
We tested the M160 modules that I repaired in the 8/L. All but one worked. We have enough good ones for the 8/I and a spare.
One of the repaired M220 modules works OK now so it was reinstalled in the 8/I.
We found two more bad chips on one of the repaired M220 modules. I will replace those this week.
We tested the repaired M707 in the 8/L. It is still broken and not debugged. We actually have two that need repair.
At this point the 8/I is starting to show some signs of life.
There were more than one instruction indicator on at the same time so we knew that there were some bad M115 modules.
We tested the M115, M117, and M700 modules in the 8/L. We found 4 bad M115, 2 bad 117, and a bad M700.
The 8/I is actually responding to some of the key switches.
We measures the signals from the switches on the backplane pins and found that some were not working and some were flaky.
Warren dumped some isopropyl into the broken switches and they are working now.
We started with some basic memory Examine/Deposit tests and found that MB bits 7 & 8 were always on.
We pulled M228 modules and tested them in the 8/L.
We found three bad M228 modules. I will repair two this week and one was replaced with a spare.
We tested the G228 modules that I repaired this week. They work OK and were installed in slots A37 and B36.
We finished testing all of the modules from the 8/I in the 8/L.
We found a G020 that caused the odd bit to be stuck on and replaced it with a spare from with a spare from the parts 8/L.
We found a G221 that didn't decode the addresses correctly and replaced it with a spare from the parts 8/L
We measured all of the resistors on the G624 modules. The looked OK.
At this point the processor looked like it was actually responding to the front panel switches.
Examining the memory almost always yields just zeros and a deposit doesn't change memory.
We measured the voltage between the MEMORY SUPPLY - and the MEMORY SUPPLY + on the 8/L and compared it to the 8/I.
The voltage on the 8/I was very high. Since the voltage was not 30V or 0V we thought that the shunt transistor on the G085 module was probably OK.
We tested the G826 from the parts 8/L in the 8/L and the resulting memory voltage was only about 1.0V different so this module is probably OK.
We tested the G826 from the 8/I in the 8/L and the resulting memory voltage was the same as what we saw when it was installed in the 8/I.
We installed the G826 from the parts 8/L in the 8/I and now the memory voltage looked reasonable.
Well, the memory still doesn't work.
Just to be sure we looked at the output of the MEM ENABLE, FIELD, READ, INHIBIT, and WRITE flip-flops.
They all seem to be working OK. This took a long time to get working correctly on the 8/L.
The READ(1) and WRITE(1) signals to the G228 modules looked OK.
In single ended mode the signals on the X R/W SOURCE, X R/W RETURN, and the Y R/W SOURCE, Y R/W RETURN look OK.
We will look at these in differential mode next week.
We looked at the STROBE\ signal from the M360 in slot B23. This signal looked OK, but is was very late compared to the MEM START signal.
It is possible that the M360 delay is adjusted too long. That will be a project for next week.
We also noticed that two of the upper bits in the MA do not increment correctly so there is still a problem in one of the M220 boards.
I replaced three ICs on one of the spare M220 modules, but it still doesn't work. Warren took one to work on.
Adjust the MEMORY SUPPLY - and the MEMORY SUPPLY + voltage to 22.5V with trimpot R28 on the G826 module in slot AB2. (Done)
Adjust the M360 in B23 so that the STROBE\ signal is 500 ns after the MEM START signal. (Done)
Check the width of the STROBE FIELD 0 signal. It should be less than or equal to 80 ns. (Done)
Debugging the inoperative memory.
Based on a recommendation from Anders Sandahl we looked at the output of the sense amplifier on pin E1 of the G020 module in slot A31 and the STROBE FIELD 0 signal.
The first time we looked at the signal there was nothing that resembled a 0 or a 1 in the data.
The signal should have resembled that shown on page 5-13 of the PDP-8/I Maintenance Manual Volume I.
Anders also recommended that we pull the core stack and measure the diodes and wire continuity.
We tested all of the diodes on the core stack. There must be hundreds, and they were all OK.
Much to our disappointment we found that the sense wires for bits 7, 8, and 11 were open and should have been about 16 Ohms.
It will be a tremendous amount of work to disassemble the core and repair the broken wires.
We pulled the core from the parts 8/L system and were surprised to see that the model number on it was 8/I.
All of the wires were intact, so we installed it in the 8/I.
Click on the image for a larger view.
The STROBE FIELD 0 signal is in yellow at the bottom and the output of the sense amplifier is in green at the top.
The high signal above the left STROBE FIELD 0 signal is a "1".
The low signal above the middle STROBE FIELD 0 signal is a "0".
We tried raising and lowering the memory voltage to find out where it breaks.
The idea was to leave it to the middle of the range.
Increasing the voltage to 27.8V and lowering it to 18V made no difference, so we set it to where it originally was, 22.39V.
We did some experimenting with small instruction loops and the processor seems to be working.
All of the rotate, clear, and compliment instructions seem to work OK.
We ran some of the IOT instructions for the TC01 to see if anything would happen.
We were pleased to see that we could read/write the status register A and actually select on of the TU55 tape drives.
That means that major portions of the logic on the 8/I and the TC01 are actually working.
We tried some of the TC01 bootstrap program and got some unexpected behavior.
It looks like one of the IOT instructions is enabling interrupts and the processor jumps into the weeds.
We did some experimenting with the IOTs for the TC01 to see if we could cause DECtape motion.
It looks like bit 4, Start/Stop motion is not getting from the accumulator to Register-A in the TC01.
There are lots of possible failures for that behavior, so we have some debugging to do.
I brought some self adhesive Teflon tape to the warehouse with the idea that we could apply it to the corroded tape guides.
With our first attempt the tape easily peeled off and took a layer of corrosion with it.
We scraped several layers of corrosion off the tape guides and cleaned it with alcohol.
This time the Teflon tape stuck securely to the corroded tape guides.
The surface is really slippery and will probably cause less wear on tape than polished aluminum would.
We looked at the M160 in slot E13 to see why Single Step doesn't work. The signals looked OK.
We tried swapping the M216 module in slot E23, but it didn't change anything.
I will repair three M216 modules this week so we will have some spares.
Last week we observed some strange behavior with bits in the PC.
Sometimes bits from the SR would not transfer to the PC, and sometimes the wrong bit would transfer.
We swapped some of the M220 modules to see if the behavior would follow the M220.
Unfortunately we found that the "new" M220 that we installed is actually broken.
I will repair another M220 module and install it next week.
We looked into the nonfunctional Single Step switch. See page 8I-0-2 of the schematics.
The KEY SS signal on pin M1 of the M160 in slot E13 followed the Sing Step switch operation so the switch is working OK.
With the Sing Step switch on and the Sing Inst switch off the signal on pin R1 of the M160 in slot E13 is always low.
The F SET signal on pin F1 of the M160 in slot E13 was always high.
We looked at the F SET\ on pin S1 of the M117 in slot F23. It was always low.
The signals on pins R1, P1, N1, and M1 were all low so one of the SN7420s on the M117 is broken.
We borrowed a M117 from the PDP-8/L until I can repair the M117.
Now with the Sing Inst switch on the pin R1 of the M160 in slot E13 strobes low with the F Set signal.
With the Sing Step switch on the pin R1 of the M160 in slot E13 is always low.
The FETCH light is now going out so we are making some progress.
The ISZ instruction is still incrementing the next core location instead of the correct memory address.
We tried some simple toggle-in programs to see what instructions are working.
So far the Group 1, Group 2, Operate, ISZ, JMS, IAC, and JMP instructions are working.
This is a little strange because the ISZ instruction did not work two weeks ago.
It is possible that we have a temperature dependent problem because the warehouse was much warmer.
Since the instructions were working we decided to see if we could get some tape motion from the TU55 drives.
We could not get the Start Motion (GO) bit in Status Register A to go on.
We swapped the M651 modules in 8/I slots H08 and H09. That did not change anything.
We swapped the S202 modules in TC01 slots E13 and E14. That did not change anything.
We swapped the flexprint cables for BAC[0..8] and BAC[9..1]. That did not change anything.
After looking at the prints some more Warren finally discovered that the R002 in slot E23
would clear the Start Motion bit if the processor was not running.
We pulled the R002 and could set the Start Motion bit.
Sending IOTs to the TC01 always showed a select error, even when a drive was selected.
We won't get any tape motion with Select Error set.
Periodically the JMP instruction would go to the wrong address when running a program.
The JMP instruction seemed to work fine when single-stepping.
We replaced the M160 in slot E26 because lots of the AC Load and PC Load logic is on that module.
Things seem to behave better now.
We didn't get much accomplished other than determining what was broken on the M707 TTY Transmitter board.
We entered the TC01 bootstrap code and tried to get some response from the TC01 controller.
At this point the processor is not reliable enough to run the boot code.
We debugged the two M707 modules. They will get repaired this week.
Click on the image for a larger view.
Warren brought the prototype of his Flip Chip tester.
We were able to test the repaired Flip Chips and determine what was broken on lots of Flip Chips.
We tested all of the M216 and M113 Flip Chips in the 8/I.
One of each worked OK in the 8/L, but failed in the tester. These modules were replaced with repaired and tested spares.
We were having so much fun testing the boards, and expected to just verify that the ones in the 8/I were OK, that we didn't keep track of the ones that failed.
We tried to run the 8/I after replacing the M113 and M216 and found that it is really broken. Load Address doesn't work.
Oh well, fixing the 8/I goes to the top of the list for next week.
Warren added created more test programs for his flipchip tester.
We tested all of the M115, M117, and M671 modules, both in the 8/I and the spares.
I have a large pile of modules to repair this week.
We tested the M113 and M216 modules that I repaired last week and now have a good selection of spares.
We also found that an M617 and M117 in the 8/L that worked OK in the 8/L failed on the tester.
These were replaced with repaired and tested spares.
We did some debugging on the strange behavior in the 8/I after we replaced the M113 and M216 modules last week.
After replacing the M113 and M216 modules this week the behavior is better, but still not correct.
It looks like the accumulator carry is being activated when you toggle LA.
We looked at the control signals for the Major Register Gating.
If more than one was active it could account for the strange behavior.
Using the HP Logic Probe the AC Enable was not behaving as expected.
We replaced the M617 in slot E32. That did not help so we put the original module back.
The S1 output from the M671 in slot E32 was floating.
We put the module on an extender so we could probe the IC pins.
The output was about 0.7V. Not as low as it should be for a high current drive part.
We looked at the input signals and I was surprised to see that the input to IC E3 that goes to tab R1 was grounded.
Since this system does not have EAE installed this should be pulled high.
Eventually Warren showed me that pin 8 on the SN7440 was supposed to be ground and that the M617 schematic was wrong.
The later version of the M617 module has the R1 tab going to pin 9, not pin 8. We marked up the schematic.
We replaced the M617 in slot E32 with a repaired and tested spare.
The 8/I is still not behaving correctly so we will continue debugging next week.
Warren added about 500 test vectors to the M220 test program. The M220s from the 8/I all passed, except that one had a
failure in the circuit that supports some kind of datacom option. That circuit is not used in the 8/I so we tagged the module and put it back in the 8/I.
We started debugging the strange LA behavior.
We put the low order M220 on an extender and looked at the enable signals for the adder.
We found that the MEM ENABLE 9-11 was always on.
We swapped the M117 in slot F11, bit it did not change the strange behavior.
The M2 input to the M117 was always active.
We put the M617 in slot F31 on an extender and looked at the input signals.
The B1 input to the M617 was always active.
We put the M160 in slot E29 on an extender and looked at the inputs.
We found that the E1 input was floating.
We put the M216 in slot E19 on an extender and looked at the E1 output.
It was floating, so we replaced the module with a tested spare.
Now the 8/I was back to normal!
We ran some of the toggle-in tests and found that the CPU seems to be behaving OK.
We tried the TC01 bootstrap to see if we would get any tape motion.
The select light on TU55 #8 just flickered and the 8/I hung in an IOT loop.
This will take some serious debugging, so we will work on that next weekend.
We removed the front panel so we could replace the RUN and EXECUTE lamps.
We borrowed on of the lamps from the unused Sequence Counter bulbs and replaced the burned out RUN lamp.
We put the individual paddles in Warren's module tester and connected the front panel to a _15V source.
We found that all of the lights worked, including the EXECUTE lamp.
While we had the front panel out we cleaned all of the switched with isopropyl alcohol.
We were surprised to see that none of the lamps on the front panel have ever been replaced.
Click on the image for a larger view.
We reinstalled the front panel, and were rewarded with lots of lights.
The STOP switch now works, and the other switches work more reliably.
Of course the RUN light is not working. We will debug that next week.
Click on the image for a larger view.
The RUN light is still non-functional, and now the MB6 light is sometimes not working.
We are not sure if the problem is one of the SN7400s on the paddle cards, or one of the transistors next to the lamps.
We disconnected all of the TC55s except for the one that seems to be functional.
We then tried the TC01 bootstrap with a PDP-11 data tape on the drive.
We were rewarded with the tape rewinding a little, moving forward to the first block, and then stopping with a TIM (Timing Error).
This means that a substantial part of the TC01 controller is working.
We need to obtain or make a bootable Dectape to see if the controller is really working.
We borrowed the Teletype cable from the PDP-8/S to see if the Teletype echo program would work.
We can write to the VT220, but the input is 0xFF, even if you don't type anything.
We swapped the M706 module with the known-good one from the PDP-8/L, but the behavior was the same.
We borrowed the Teletype cable from the PDP-8/L and now the Teletype echo program would works fine.
It seems that the cable from the 8/S W070 is enough 8/L W076 so that it won't work.
We put a connector on the end of the 8/I Teletype cable so we could plug it into the VT220 and that works fine.
Last week when we tried the DECtape bootloader we saw tape motion and then a TIM error.
We speculated that the TIM error was because we used a PDP-11 formatted DECtape.
We found a data tape that was used with a PDP-8 and tried that.
This time we saw an END status so the TC01 is probably doing the right thing.
We experimented with some modifications to the bootloader to see if the data-break was actually reading the tape into core.
We never saw data from the tape, but that may be due to our lack of understanding of the TC01 behavior.
We toggled in the low-speed RIM loader, and used Warren's RS-232-to-Current-Loop converter and TTY emulator to download the BIN loader.
We ran the BIN loader and downloaded the maindec-08-d3bc-pb TC01 Basic Exerciser. The AC was not all zeros, so the load didn't work.
We adjusted the frequency of the TTY port, but that did not fix the loading issue.
After a watching the transmit and receive signals with a 'scope we found that the termina