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 terminal emulator was set to 1 stop bit, not 2.
We reloaded the TC01 Basic Exerciser, but the checksum was still wrong. Not sure what the problem is.
We ran the program anyway, bot saw no activity on the TC01 controller.
We loaded maindec-08-d05b-pb.bin, the Random JMP-JMS Test. We ran 5 passes without error.
This showed that the BIN loader and the TTY emulator are working OK, as well as some of the instructions.
We loaded the DEC-08-EUFB-PB.BIN DECtape formatter. It loaded without a checksum error.
We ran the formatter, but never saw TC01 activity or DECtape motion.
Warren heard some arcing in the back of the system, so we powered it off and inspected everything.
We didn't see anything burned, so we powered it on and measured power supply voltages.
The +10V supply for the first three DECtapes had no output.
That might explain the lack of response from the TC01 diag and formatter.
The cap for the +10V is OK, but there is only a little output from the diode block.
Next week we can swap the two DECtape power supplies and see if we can make some more progress.
The +10V in the power supply for the first three DECtapes failed, but the -15V is OK. looks like the diode block has failed.
The two 799 power supplies are a little different so we didn't swap the complete power supplies.
The +/-15 from the power supply for the last two DECtapes is not used so we swapped the diode blocks.
We were a little surprised to see that the +10V was still very low.
We measured the AC going into the diode block, and it was very low.
Our guess is that the ferroresonant capacitor has failed. This is a common failure.
We loaded and ran Instruction Test - Part 2B, and it failed in lots of places.
It looks like there may still be some repair work to do.
We loaded the TC01 basic diags so when the power supply is fixed we can see anything works.
We replace the two ferroresonant capacitors in the power supply for the first three DECtapes.
It is making the correct voltages again and the TC01 is lit up again.
We ran the dec-08-eufa-pb TC01 formatter.
It displayed the expected messages and it looks like it formatted a tape.
We ran the MAINDEC-08-D3RA-PB TC01 Random Exerciser.
It ran for a short time and displayed a message about 5500 and 4500 in the B status register.
It looks like we still have some debugging to do.
We replaced the ferroresonant capacitors in the power supplies for the DECtapes.
All of the DECtapes and the TC01 are powered again.
The MAINDEC-08-DITCA TC01 Basic Exerciser ran for a few seconds and died where it checks the Status A register.
After a few more tries the diag program would not run anymore, and the contents of core did not match the program listing.
We did some quick checks to see if we could store zeros and ones in core and found that bits 8 & 9 displayed correctly
in the switch register, but always read back as a one. We replaced the G228 in slot B37 and memory worked OK again.
We replaced one of the SN7440 chips on the G228 and I will replace the other this week.
After a quick discussion we decided to run the processor diags again before trying the TC01 diags.
We loaded and ran MAINDEC-8I-D01C, Instruction Test 1. This diag ran fine for several minutes.
We loaded and ran MAINDEC-8I-D02B, Instruction Test 2. This diag ran for a second and halted at 2710.
The diag was testing the interrupt capability of the M707 Teletype transmitter, and it did not interrupt.
The interrupt signal comes directly from the SN7474 E13 on the M707. We will replace that IC this week.
We replaced the M707 with a tested spare. This time the _5V breaker tripped immediately when the system was powered on.
The M707 worked in Warren's module tester and only drew 220mA, so we are not sure what the problem is.
We borrowed the M707 from the PDP-8/L and continued testing.
The contents of core were a mess, probably from tripping the +5V breaker.
We reloaded the RIM loader, then the BIN loader, and then MAINDEC-8I-D02B.
The terminal emulator finished sending the diag, but the BIN loader didn't see any more characters on the input.
We swapped the M706 with the one from the PDP-8/L, but it did not change the behavior.
At this point we are not sure what is wrong. It is possible that something is broken in the IOT logic.
Since the RIM loader seems to work Warren will make RIM versions of MAINDEC-8I-D01C, Instruction Test 1, and MAINDEC-8I-D02B, Instruction Test 2.
We decided to work on the PDP-8/L this week and make sure that it is working OK.
Then we can use it as a test bed to make sure that the modules in the 8/I are working OK.
It looks like we have the PDP-8/L working again so we can use it to test the modules in the PDP-8/I.
We tested the core stack from the 8/I in the 8/L. Everything works perfectly.
We tested all of the G221 modules from the PDP-8/I in the PDP-8/L and found that one was broken. It was replaced with a spare.
Next week we will test the remaining modules using Warren's tester and the PDP-8/L.
Once we are convinced that all of the modules are OK we can continue debugging this system.
We replaced the borrowed M220 with a repaired and tested spare.
It was tested in Warren's tester and running Instruction Test 1 & 2 in the 8/L.
We found a strange problem where bit PC4 was not transferred to the MA.
If you set the PC to 0200 and did an examine the PC was set to 0001.
After a lot of testing of the M220s and the register steering logic we decided to look at anything that was connected to MA.
We found that the G221 in slot C33 was causing this problem.
The repair on this module only lasted a few hours.
We found that on a defer cycle it was using the contents of the MA instead of the MB.
After a lot of speculating and module swapping we found that the M160 in slot E29 caused this problem.
It was replaced with a repaired and tested spare.
There is still a lot of strange behavior in this system that needs debugging.
We tested the M216 modules in Warren's tester and the all look OK.
We will test more modules next week.
I tried reading/writing memory, and found bit-8 in the MB was always on when depositing.
I swapped the G020 modules in slots B32 & B33. There was no change.
I swapped the G228 modules in slots B36 & B37. There was no change.
I swapped the M220 modules in slots EF38 & EF39. The bad bit moved to bit-10.
I put the M220 in the 8/L for debugging and found that the SN7474 in position E11 was bad.
I tagged the module for repair and borrowed a M220 from the 8/L so I could continue debugging.
I tried to toggle in the group-1 instruction tests. Memory location 0004 contained should contain a 7020 but contained a 7030.
I tried storing the memory address of a core location in the core location.
Addresses 0-3 were OK, 0004 contained a 0014, 0024 contained a 0034, 0020 contained an 0030, and 0040 contained 0050.
I replaced the G221 in slot C32 with a repaired and tested spare.
The memory works OK now.
Group 1 instructions work OK.
The IAC loop program ran for a while and then died.
I tried a lot of module swapping again and found that replacing the G221 in slot C38 fixed the bad behavior again.
I tried loading the RIM loader, but there were more memory problems. Bit-4 was getting dropped.
We observed some strange memory behavior with dropping and picking up bits.
Warren tested all of the G221s and found that diode D7 that drives pin K2 was bad on the one in slot C32.
The G221 was replaced with a repaired and tested spare.
After replacing the G221 module we could execute some simple programs.
We toggled in the RIM loader, and loaded MAINDEC-08-d1b1, the Memory Address test.
It actually ran for a few minutes before it halted.
We will try it again next week and see if anything else is broken.
It was nice to see this system running again.
I loaded the MAINDEC-08-D1B1 Memory address test (low). It ran for a second and died.
Examining memory near where it died showed that the contents were incorrect.
I tried to write 0000 to memory, but on examination the MA was 0010 and the AC 0010.
I replaced the M220 in slot EF38 with a repaired and tested spare.
MAINDEC-08-D1B1 Memory address test (low) runs OK now.
I loaded MAINDEC-8I-D01B 8/I Instruction Test 1. It halted at 2221 in the RTL Test 14.
Memory location 2213 contained a 1034. It should have contained a 1024 so we picked up bit 7.
I fixed that memory location. When the diag was restarted it halted at 4157.
The source code doesn't use that location.
I loaded and ran MAINDEC-08-D1L1 Basic Memory Checkerboard (Low).
It seems to run OK, but the light pattern when running is different than what you seen on the 8/L.
It makes me think that it is not really running correctly.
I loaded and ran MAINDEC-08-D1L2 Basic Memory Checkerboard (High).
It ran for a few seconds and then halted.
Pressing continue will put the contents of the memory in the AC.
Pressing continue again will put the failing memory address in the AC.
There were lots of failing addresses.
All of the bad memory locations contained a 0040 or a 0010 when it should have been 0000.
Maybe we have a bad G0020 sense amp or G228 inhibit driver.
Next Saturday we will fix this memory issue and continue testing.
We tested the G221 modules in the 8/L using the Memory Address Test.
We found two that misbehaved, the ones from slots C33 & C32. These were replaced with repaired and tested spares.
We still had a problem with picking up bits 6 & 8 in some memory locations.
We swapped the related M220, G020, and G228 modules, but found no behavior changes.
We looked at the relationship between the STROBE FIELD 0 signal and a 1 bit in memory.
We found that the STROBE signal was nearly 150 ns earlier than it should be.
We adjusted the M360 module to the correct delay, and now memory works OK.
We ran successfully MAINDEC-08-D1B1 Memory address test (low),
the MAINDEC-08-D1L1 Basic PDP-8, PDP-8/I Memory Checkerboard, and
the MAINDEC-8I-D01C PDP-8I Instruction Test Part 1.
The MAINDEC-8I-D02B PDP-8I Instruction Test Part 2B dies when it tried to test the interrupts from the M707 TTY transmitter.
Both repaired M707 modules failed this test. We borrowed the M707 module from the PDP-8/L and the diagnostic ran OK.
At this point we declared the PDP-8/I processor to be running correctly and started working on the TC01 controller.
We loaded the MAINDEC-08-DITCA-A TC01 BASIC EXERCISER. It ran for a second and halted at 1135.
The diag wrote to status register A, but read something different back.
We traced the program in that area and found that IOT 761 instruction was causing a skip and the processor was skipping over the next instruction, a CIA.
We also found that bit 7 could be written, but not read back from status register A.
We didn't know if the problem was in the skip logic in the 8/I or in the TC01.
We swapped M506 Negative Input Converter modules in slots J15 & J16. That didn't fix the skip problem.
We pulled the S111 module in slot D24 of the TC01. The 8/I did not skip after the IOT 761 instruction.
Now we new that the skip problem was in the TC01.
We replaced the S111 with a spare R111, but there was no change in the behavior.
We took at look at the W103 Device Selector modules.
There was some corrosion, but cleaning it did not fix the skip problem.
We tried pulling the W102 for the IOT 77x, but it still skipped.
So, for next week we can chase down why the IOT 761 causes a skip and why we cannot read back bit 7 from Status Register A.
I repaired two of the M707 TTY transmitter modules this week.
We loaded MAINDEC-8I-D02B PDP-8I Instruction Test Part 2B first to verify that the 8/I is still running OK and then to test the M707 modules.
It failed the diag and halted at 2710. The listing said that the interrupt from the TTY transmitter didn't happen.
We tried the other M707 modules and saw no difference in the behavior.
We entered the toggle-in TTY echo test and found that one of the repaired TTY transmitter modules had a stuck bit. I will repair it again this week.
The TTY transmitter and receiver modules have their interrupts ORed together, see page 12 of the 8/I schematics.
Pin S1 of the M117 in slot F19 wiggled when the TTY transmitter interrupt was generated.
Pin V2 of the M113 in slot E12 also looked OK for interrupts.
The interrupts for the TTY, memory parity, the Posibus, and the local punch and reader controllers are all ORed together. See page 10 of the 8/I schematics.
Pin E1 of the M506 in slot J15 looked OK for interrupts.
We tried swapping the M506 modules in slots J16 and J14, but the diag still failed.
We tried to follow the INT RQST signal, but found that this 8/I does not have this signal connected to the M117 in slot F11. This schematic page 7 must be newer than the system.
All of the signals for the INT SYNC flip-flop on the M216 module in slot E33 looked OK.
The INT OK signal from the M113 module in slot F21 looked OK.
The TP4 gated INT OK signal on the M113 in slot E24 looked OK so the IR had to have a JSR forced into it.
We reloaded the diag and it ran OK for about 20 minutes, and then died with the same halt address.
So, now we have a module that works fine when it is cold, and dies after running for about 20 minutes.
We never got to testing the TC01 because we need working interrupts for the TC01 exerciser.
For next week we can fix the interrupt problem and chase down why the IOT 761 causes a skip and why we cannot read back bit 7 from Status Register A from the TC01.
We disassembled the front panel and connected it to Warren's flip-chip tester.
We activated each bulb and gave it a little wiggle.
We knew that six bulbs were either not working or intermittent, and the wiggle test found two more bulbs that needed to be replaced.
We replaced the eight nearly impossible to find Oshino OL-1 bulbs with Chicago Miniature P/N CM7370 from Mouser.
These are slightly higher output, but higher voltage than the originals.
When turned on we could not see any difference between the original Oshino OL-1 bulbs and the replacement Chicago Miniature CM7370 bulbs.
We also replaced the two bulbs at the lower left that we borrowed from the step counter display.
It is nice the have all of the lights working again, especially the RUN light.
Click on the image for a larger view.
The front panel power switch was melted and burned when we got this system.
We moved the AC wires on the front panel to always turn on the power supply so we could get started debugging.
Today we disconnected the Panel Lock switch and used it to replace the power switch.
It is much more convenient to turn this system on from the front instead of using the breaker on the back.
We tested the M707 TTY Transmitter modules in the PDP-8/L using MAINDEC-8I-D02B PDP-8I Instruction Test Part 2B so we know that they work OK.
We tested the M216 module that has all of the flip-flops for interrupt control in the 8/L for 25 minutes and it worked OK.
We loaded MAINDEC-8I-D02B PDP-8I Instruction Test Part 2B to continue debugging the interrupt problem.
This diag will run for a while and then hang at 2710. That halt is for a missing interrupt from the TTY transmitter board.
We traced the interrupt related signals from the M707 module all the way to the instruction decoder circuit.
Everything looked OK, so we are not sure why it missed the interrupt.
If you turn the system off for a few minutes, when powered on it will run the diag for a few minutes.
Our best guess is that there is a chip that is failing when it gets warmed up from running.
For Monday, we will swap the the limited number of modules in the interrupt circuit with tested ones to see if we can find the misbehaving one.
We decided to start swapping modules in the interrupt circuit starting from the source of the interrupts.
We first swapped the M113 module in slot E12.
Much to our surprise the 8/I ran Instruction Test 2B for 20 minutes without an error.
That fix we more due to just dumb luck than science and logic.
We tried to load maindec-08-d3bb TC01 Basic Exerciser, but it would not load.
There was no indication of input from the BIN loader.
We toggled in a short TTY echo program and never saw the TTY receive flag go on.
We borrowed the M706 module from the 8/L and then the diag loaded OK.
The D3BB diag is supposed to print a "WD" when you hit "F", but it did not.
When we single stepped through the diag the "WD" was printed on the console.
So, we have yet another case where a module works OK in single step, but not at full speed.
We loaded and ran MAINDEC-8I-D01C Instruction Test Part 1.
It ran perfectly for 45 minutes.
We loaded MAINDEC-08-D04B PDP-8 Random JMP Test.
It quickly halted at 1675 when jumping from 4735 to 1675.
We loaded MAINDEC-08-D03 Basic JMP-JMS test.
It ran fine for quite a while.
We loaded MAINDEC-08-D07B PDP-8 Random ISZ Test.
It quickly halted.
From the front panel indicators it looked like the M220 modules were not behaving correctly.
We individually swapped all of M220 modules that had the wrong bits, but it did not fix the problem.
After much fiddling and wiggling we got to the point where the core contents looked OK, but the panel indicators did not.
This leads us to believe that maybe there is a problem with the TAD instruction.
We will look into that next Saturday.
We tested the M220 modules in the 8/L using the MAINDEC-08-D07B PDP-8 Random ISZ Test.
They ran perfectly for 20 minutes, so they are not the cause of the ISZ diag problem.
The MAINDEC-08-D07B PDP-8 Random ISZ Test failed on the 8/I within 2 minutes.
The failure was consistent and was always one of two cases:
F = 6363, T = 7170, O = 3474, F = 4606, R = 4610, S = NS
F = 6363, T = 7170, O = 3474, F = 4206, R = 4210, S = NS
In both cases the contents of core was OK, so the diag should not have failed.
We ran MAINDEC-8I-D01C Instruction Test Part 1 for 5 minutes without a failure, so the basic instructions work OK.
We decided to load the MAINDEC-08-DITCA-A TC01 BASIC EXERCISER and insert HLT instructions to see why it would not echo the prompts.
Of course this time it worked as it should.
The diag failed with some unexpected bits read from Status Register B.
Warren suspected that the W103 device selectors were not working correctly and ORin Status A with Status B.
We found that the 76 device selector was responding to both the 76 and 77 IOTS, so that explains the unexpected bits.
After more debugging we found that some of the BMB bits on the Negibus were not what they should be.
We will take a look at the M651 modules next week.
We knew that the only difference between the IOT 66 and IOT 67 for the TC01 were the BMB08(0) and BMB08(1) signals. We connected a 'scope to pins K2 and S2 of the M651 in slot H17. We were not surprised to see that the BMB08(1) signal was changing when the contents of the Memory Buffer changed, but the BMB08(0) signal was not changing. We swapped the M651 module and didn't see any change in the signals. We connected the 'scope to pins N2 and K2 of the M651 in slot H17 and saw that the MB08(0) signal worked OK, but the BMB08(0) signal did not. We noticed that the MB08(0) signal went up to 3.0V, and other MB signals went to 4V. We made a fruitless search of modules that are connected to the MB08(0) signal that might have an excessive load. We swapped two of the M220 modules, but that only made a small signal voltage difference. We looked at the M2 pin on the M651 in slot H17 and were surprised to see that the pullup was only bringing the signal to 1.5V. We pulled the M651 in slot H17 and saw only a little difference. We pulled the M651 in slot H18 and now the pullup went to 3.0V. We tried the rest of the M651 modules in slot H17 and found that 8 of the 14 M651 modules pulled the pullup to 1.5V so they must have defective SN7410 chips. We replaced all of the defective SN7410 chips on the M651 modules.
We reran the MAINDEC-08-DITCA-A TC01 BASIC EXERCISER. Now the "good" TU55 DECtape drives is passing some diagnostic tests. This is quite a milestone to have the processor, TC01, and one of the TU55 drives working.
The tape guides in the TU55 DECtape drives are machined aluminum that have a polished surface where the tape touches. Unfortunately the polished surface on these drives was very corroded from being stored in an uncontrolled environment. We covered the rough corroded surface of the tape guide with Teflon tape to make it slippery. It looks like that the magnetic tape is actually sticking to the Teflon surface when it is not moving and stopping the drive from working smoothly. The next project will be to remove the aluminum guides, clean off the corrosion, and polish the surface. We also need to repair a brake on one TU55 drive and debug electrical/electronic problems on the other three TU55 drives.
Today we removed the very corroded aluminum tape guides from TU55 DECtape drive #3, scraped most of the corrosion off, sanded it smooth with 400 grit sand paper, and polished the tape surface with a ScotchBrite. They look great now. We reassembled the drive and found that the tape slides across the polished aluminum surface much easier than on the guides on drive #2 that we covered with Teflon tape. Now we just need to do the same procedure to the other four DECtape drives.
One of the brake assemblies on TU55 #3 was broken. There is a flat plate bolted to the back of the drive motor that was separated from the bowl shaped electromagnet. I thought that the fix was going to be spot welding the pieces back together, but we found that they were originally just glued together. We used some 5 minute epoxy to repair the brake and it works fine now.
We tried running the DEC-08-EUFB-PB TC01-TU55 DECtape Formatter with the newly repaired TU55 drive. It wrote the timing tracks, rewound a little, moved forward to write the block numbers and hung in a loop waiting for the DECTape Flag to turn on. The DECtape flag should have turned on at the end of the first sector when it was in the Forward Search mode.
Next week we will run the TC01 BASIC EXERCISER to make sure that all of the motion commands work with TU55 #3. It that is OK then we will debug the DECtape Flag problem in the TC01 controller.
We reran the TC01-TU55 DECtape Formatter to confirm that the CPU was behaving OK and the TC01 misbehavior was still the same.
The Diag hung waiting for the DECtape Flag to go on.
We ran the TC01 BASIC EXERCISER and it worked fine with both of the functioning TU55 Dectape drives.
With the Diag in the Search All mode, which just moves the tape from end to end, we did not see the DECtape Flag go on.
We replaced the tape with one that Warren formatted on Victor's PDP-8/I and we saw the DECtape Flag go on.
We triggered the 'scope on the READ STATUS B signal and looked at the DTF(1) signal.
We followed the signal through the ribbon cable and into the 8/I logic. Everything looked OK.
We finally came to the conclusion that the Mark Track on the tape that we formatted did not have the correct contents.
During formatting, the contents of the Mark Track is created in the 8/I CPU and transferred to the TC01 via Data-Break.
The problem had to be between the 8/I and the TC01.
We looked at all of the signals between the 8/I and the TC01 and found that BMB6(1) signal was stuck at ground.
We looked at the BMB06(1) output signal on pin K2 of the M650 in slot H16 was always at ground.
The MB06(1) input signal on pin H2 was about 1.5V so something is either loading the signal or the driver is bad.
The front panel and the Inhibit Drivers use the MB06(0) signal from the M220 so the front panel light looks OK.
It could be a bad output driver on the SN7447 on the M220 so we swapped it with the adjacent M220.
That had no effect so it must be the input to another logic gate that is loading the signal.
We continued our work on the MB06(1) signal based on a list of modules in the CPU that use that signal.
At the M220 in slot EF37 the MB06(0) and MB06(1) signals looked OK.
At the M651 in slot H16 the MB01(0) signal was either 0V or 4V, but the MB01(1) was always 1.8V.
We measured the resistance from the MB06(1) signal at the M220 module to the M651 module and it was open.
We looked at the MB06(1) signal at the M160 in slot E30, the M113 in slot F32, the M117 in slot F23 and all were OK.
The MB06(1) signal at the M707 in slot EF02 and at the M651 in slot H16 was always 1.8V.
The resistance between the MB06(1) signal at the M707 in slot EF02 and at the M651 in slot H16 was 0 Ohms.
Well, now we knew that the MB06(1) signal made it to all of the parts of the CPU except for the TTY interface and the Negibus interface.
After a long look at the Wire-Wrap wires on the backplane we found a broken wire between the M2 pin in the slot for the
A701 module for the VC8I option and pin D1 in slot J33 for the M714 module for the CR8I.
The broken wire was orange, probably indicating that it was installed by hand instead of by a CNC Wire-Wrap machine.
The first few turns if the insulated part of the broken wire should have been tight against the Wire-Wrap pin.
The turns were loose which probably allowed the wire to vibrate and eventually break.
We jumpered across broken wires and now the MB06(1) signal made it to the M651 and M707 modules.
We reran the TC01-TU55 DECtape Formatter, but the result was always a configuration error.
Warren reminded me that I had disconnected the flexprint cable that carries the BMB0(1) signal last week during debugging.
After the cable was reinstalled the diag ran further than previous attempts, but when it got to Phase 3 to check the block numbers it failed.
The error message was: 0000 SHOULD BE 0040 BLK ERROR PHASE 3.
Warren thinks that there may still be problems with the Data-Break (DMA) circuitry which is largely untested.
The broken Wire-Wrap wire at slot H23 pin M2 was long enough to strip the end and rewrap.
That fixed the MB06(1) problem.
Click on the image for a larger view.
We ran the Search Scope Loop in the MAINDEC-08-D3BB-D TC01 Basic Exerciser.
It runs the tape forward and backward when it detects the end of the tape.
That works fine, so the timing and Mark tracks are being read and at least partially interpreted.
The DECtape flag signal is toggling so the TC01 is finding the block number.
The Search Scope Loop also displays the current block number in the AC and it does count up and down.
All of the AC bits for the block number look reasonable except for Bit 6 which sometimes blinks out of sequence.
A problem with bit 6 would explain the error message: 0000 SHOULD BE 0040 BLK ERROR PHASE 3 during tape formatting.
There is a huge list if things that could cause the AC to contain the wrong block number.
We looked at the Data Bit 0(1) through Data Bit 11(1) signals on the TC01 and they look reasonable.
We still need to look at the Data Address signals.
Maybe we should connect a logic analyzer to the CPU and catch all of the writes to address in location 7755 to see if the block number really is increasing or decreasing by one.
We ran MAINDEC-08-D3BB-D TC01 Basic Exerciser to see if anything was still working.
The Basic Motion test worked OK on the drive that we polished the tape guide.
The drive that we applied the Teflon tape to the guides has a "sticktion" problem when first moving the tape.
We will need to remove the Teflon tape and polish the guide to get this drive working better.
We tried all of the tape Unit IDs to see if the drive selection electronics were working OK.
When the Unit ID was set to 2 the drives were not selected.
We replaced the S151 module in slot D13 with a spare R151 that we had.
This module sends the 8 individual drive selection signals to the drives.
In this configuration any Drive ID with the 2 or 4 bit on also turned on bit 1.
We put the original S151 module back in and now all of the Drive IDs work OK.
Must have had a bad connection on the module.
We ran the Search Scope Loop with SA=0201.
The diag is supposed to display the block address in the accumulator.
Bit 6 in the accumulator was always off.
We examined memory locations to find one with bit 6 on to verify that the bulb and the accumulator were OK.
We looked at the inputs and outputs of the S603 Pulse Amplifier in slot DTC01.
The inputs looked OK, but the output was always at ground.
Replacing the S603 did not make a change, so we replaced the R201 Flip-Flop in slot DTD01.
Now bit 6 looks OK in the accumulator when running the Search Scope Loop.
This also made the block numbers display more solidly. We saw occasional block number flickering earlier.
We ran the rest of the Basic Exerciser tests and found problems with the Read/Write Data Test, SA=0204
It looks like some of the bits are skewed in the data blocks.
Debugging this problem will need to wait until next week.
We ran the DEC-08-EUFB-PB TC01-TU55 DECtape Formatter on repaired TU55 drive.
It wrote the timing and mark tracks, wrote the block numbers, but failed when it tried to read block number 2701.
It read the block number 3773 instead of 2701.
We tried this process several times and the results were consistent.
We a different binary image of the DEC-08-EUFB-PB TC01-TU55 DECtape Formatter.
This image also behaved the same.
We ran the MAINDEC-08-D3BB-D TC01 Basic Exerciser.
The Basic Motion and Search Scope Loop worked OK.
The Search Find all Blocks actually read the last block on the tape as 2701.
We went back to the basic diagnostics to see if the CPU was behaving OK.
Warren loaded and ran the MAINDEC-08-D1L1 Basic Memory Checkerboard (Low).
The diag failed at address 7160 where a 7577 should have been a 7777.
The DECtape formatter uses that address for the input buffer.
Oh well, back to fixing the processor next week.
We loaded and ran the MAINDEC-08-D1L1 Basic Memory Checkerboard (Low).
The diag failed at address 7402 where a 7677and 7577 should have been a 7777.
The diag results with MAINDEC-08-D1L2 Basic Memory Checkerboard (High) were the same.
We loaded and ran MAINDEC-08-d1b1, the Memory Address test.
This ran fine, so the G221 and G228 modules are probably OK.
Since this was just one core location that was misbehaving we assumed that this was a processor problem.
We loaded and ran MAINDEC-8I-D01C, Instruction Test 1. Worked OK.
We loaded and ran MAINDEC-8I-D02B, Instruction Test 2. Worked OK.
We loaded and ran MAINDEC-08-D04B, PDP-8 Random JMP Test. Worked OK.
We loaded and ran MAINDEC-08-D05B, Random JMP-JMS Test.
This diag failed with From: 1757, Target: 3736, (To): 1560. This should be 1760 so we dropped bit 4.
We tried replacing the M220 module in slot EF36 that has the bit 4 registers. No change in the behavior.
We loaded and ran MAINDEC-08-D07B PDP-8 Random ISZ Test.
This diag failed with F: 6301, T: 7137, O: 7456, F: 7647, R: 7450. This should be 7650 so we dropped bit 4.
At this point we decided to swap all of the modules that used MB04 to see if we had a bad input.
We swapped the M115 in slot F28, the M160 in slot E30, and the M117 in slot F19. No change in the behavior.
Even though a Sense module should affect all core locations we swapped the G020 module in slot A33 with slot A32.
We loaded and ran the MAINDEC-08-D1L1 Basic Memory Checkerboard (Low) and found that the failed bit moved to Bit 2.
We put the G020 module in slot A32 back in slot A33 and replaced the G020 in slot A32 with a spare.
The Memory Checkerboard ran for 15 minutes without a failure.
With the processor running OK again we went back to working on the TC01.
We loaded and ran DEC-08-EUFB DECtape formatter.
We hoped that the fixing the processor would allow the formatter to run this time. No such luck.
The formatter failed in pass 3 where it was looking for block 2701 and found block 3773.
We loaded and ran MAINDEC-08-D3BB-D TC01 Basic Exerciser.
The motion tests work OK, so the Mark and Timing tracks were written OK by the formatter.
The read/write test failed where it expected 2525/5252 and saw 0000/7777.
We loaded and ran MAINDEC-08-D07B PDP-8 Random ISZ Test to make sure that the processor was still behaving.
We loaded and ran DEC-08-AJAE Focal. This is usually the final test to see if everything is OK. It ran just fine.
We loaded and ran MAINDEC-08-D3BB-D TC01 Basic Exerciser.
The basic Search with SA=0202 found all of the forward block numbers.
A reverse search from the end of the tape showed that the last block was #3773, no #2701.
We repeated the test with a tape that was formatted on Victor's PDP-8/I and it worked OK.
So, now we know that the processor is OK and that tapes formatted on a different machine work OK.
We ran the Search Find All Blocks, SA=0201 with Victor's tape. It ran OK for 45 minutes.
We ran the Start/Stop/Turnaround test, SA=203, and it worked OK.
Click on the image for a larger view.
Old technology meets new. A USB Logic Analyzer is used to debug the TC01.
Click on the image for a larger view.
This is what the data signals from the DECtape controller look like.
We connected Warren's logic analyzer to the TC01 so we could watch it read a tape.
We watched the Timing, Mark, and Data 0-2 tracks.
Everything looks OK when reading blocks up to #2701.
When reading block #2701 backwards there is no data between the end zone and the data area.
We repeated the test using Victor's tape and everything looks OK.
Now we know that the short part of the formatting program that writes the reverse block number for #2701 didn't work.
That should not be too difficult to track down.
While Warren was setting up his USB logic analyzer I loaded and ran DEC-08-EUFB DECtape formatter.
I expected it to fail when it was writing the reverse block numbers to 2701 in the initial phase of formatting.
Much to our surprise it formatted fine and passed the forward and reverse format checking.
Warren's speculation is the cold temperature in the warehouse, ~40F, affected the behavior of one of the TC01 modules.
We took advantage of the working TC01 and formatted five DECtapes. All formatted OK.
We loaded and ran MAINDEC-08-D3BB-D TC01 Basic Exerciser.
The Search Find All Blocks, SA=201, ran OK.
The Write/Read Data Test, SA=204, worked OK for all eight patterns.
We loaded the DEC-D8-SBAF-PB 4k Disk System Monitor System Disk System Builder.
Even though the title says that it is a Disk System Monitor it can be configured for just DECtapes.
We told the System Builder that we had 4k of core, no high-speed paper tape, no RF08s, and no DF-32s.
The System Builder wrote the Monitor, Loader, Command Decoder, Directory, and Storage Allocation Block Maps to the DECtape.
We entered the DECtape bootstrap program and were rewarded with the "." prompt from the monitor.
We tried to follow the procedure for loading additional programs like PIP onto the DECtape.
It looked like it loaded about 1500 characters from the paper tape image to core and the took the remainder as console input.
We tried several variations on the input procedure, but none worked.
We will ask some PDP-8 experts how to perform this procedure.
This is some really amazing progress from where we were a year ago.
Once we repair the other four DECtapes the restoration on this system is done.
We are a little concerned that the TC01 controller will fail again when the warehouse warms up in the spring.
Oh well, we can debug that when the time comes.
Last week we unsuccessfully tried to follow the instructions in the 4k Monitor Users manual to save PIP on the DECtape.
This week we determined that the 4k Monitor stops the paper tape input while it saves modifications to core addresses
in the range of 7200-7577 to the user area on the DECtape. We don't have the reader control from the 8/I wired to the
serial port on the laptop, so it just keeps sending characters when the 4k Monitor doesn't want them and confused
the bin loader. This week Warren will add reader control to the 20mA-RS232 adapter.
Next week we should be able to finish building the 4k Monitor Dectape.
We did save images of MAINDEC-8I-D01C, Instruction Test 1 and MAINDEC-08-D07B PDP-8 Random ISZ Test
to DECtape. It was way fast to just type "D01C" and have the diag read from DECtape and run in a few seconds.
The 4k Monitor started right up so it looks like the processor and TC01 are still behaving.
Last week we discovered that we needed Reader Control to turn off sending data to the processor while it was writing to the DECtape.
Warren added another signal to the current-loop to RS-232 signal converter.
We connected this to the Relay +/- signals and to the serial port CTS signal.
We enabled CTS flow control on the terminal emulator, and now have flow control.
If there is a character already in the TTY input module the CTS signal is turned off.
When the character is read by the processor the CTS signal turns on and the terminal emulator sends another character.
Once the character is received the CTS signal turns off again.
We had to disable the FIFO capability for the serial port in the PC so the control would work for each character.
I tried to load the PIP program onto the DECtape, but the BIN loader halted with a non-zero AC.
This means that there might be a problem with the PIP image that we loaded.
A little later Warren was able to save PIP to DECtape and have it run OK from DECtape even though the BIN loader indicated a problem.
We have a standard pinout for the 20mA connector that we will use for all of the systems.
This lets us plug the connector directly into a VT220 or the current-loop to RS-232 signal converter.
The pinout that we are using is:
Load additional programs onto the 4k Monitor DECtape.
Jack Rubin came for a visit today.
He just bought the chassis of a PDP-8/I and wanted to take some pictures of a running system.
So...I plugged in the system, entered and the TC01 bootstrap, and it didn't read the DECtape.
It was behaving a little strangely when loading the bootstrap where sometimes it would zero an adjacent memory location.
I wiggled all of the flip-chips to see if it would improve the behavior.
Now it won't read core, everything is just ones.
Oh well, we will fix this after we finish the PDP-9.
We moved the 8/I to the nice warm RICM Learning Lab space and started analyzing its behavior.
Of course, everything seemed to work OK, and it would execute toggled in programs.
We made another trip to the warehouse to move small equipment to the Learning Lab and then tried the 8/I again.
This time it would only get ones when you examined memory.
It runs fine, but is just running 7777 instructions.
The front panel indicators look OK when doing an LA, and reflect the switch settings.
The MB looks correct when doing a deposit, but is always 7777 after an examine.
The voltages from the main power supply look OK.
The +5V is +4.85, within tolerance.
On page BS 8I-0-13 of the processor schematics:
B21-F1 is a pulse every 1.477 uS when running.
B21-C1 is a pulse every 1.477 uS when running.
B22-B1 MEM START is a pulse every 1.477 uS when running.
B22-A1 B POWER CLEAR/ is always high.
B22-C1 is always high.
B22-D1 is always high.
B22-E1 is always low. I need to verify this.
B22-F1 is always high. I need to verify this.
B22-K1 MEM BEGIN/ is low for 100 nS every 1.47 uS when running.
If these observations are correct, then we never get the B MEM ENABLE signal and the Core Sense Flip-Flops won't get gated to the register bus.
Now that the TU56 DECtape is working on the 8/E it will be easy to copy paper tape images to the 4k Monitor DECtape for the 8/I.
We had replaced two of the SN7474 ICs on the M216 in slot B22, so of course the IC that we did not replace failed.
In the future we will replace all of the SN7474 ICs on a flip-chip when we repair it.
We replaced the M216 in slot B22 with a repaired board where all three SN7474 ICs had been replaced.
The core memory works again.
Well, that didn't last long.
While we were testing ISZ and JMP instructions the processor started behaving strangely.
When powered on lots of the indicators on the front panel were on.
This is usually a sign that an initialization signal is not working.
Pushing the EXAM would turn the RUN indicator on.
Only a power cycle would clear that.
We measured the supply voltages at the power supply.
The +5 was 4.92, a little low but OK.
The -15V and 30V were OK too.
See schematic page BS 8I-0-13.
We looked at the POWER CLEAR\ and POWER OK\ signals on pins AS2 and AJ2 of the G826 flip-chip in slot AB2.
Both looked OK.
The POWER CLEAR\ signal goes inactive about 200ms after power on.
We looked at the POWER CLEAR\ signal on pin V2 of the M113 in slot B21.
The signal is non-monotonic, but that should be OK.
We looked at the B POWER CLEAR\ signal on pin S1 of the M617 in slot C12.
The signal is non-monotonic, but that should be OK.
We discussed the behavior with Warren.
He suggested that we look at the MANUAL PRESET signal on schematic page BS 8I-0-2.
This signal is derived from B POWER CLEAR\ or LA, EX, DEP, STOP, and CONT switch presses.
We also need to look at the behavior of the MFTS1 and MFTS2 flip-flops, and the MFTP0, MFTP1, and MFTP2 signals.
Click on the image for a larger view.
We worked on the "too many lights" problem on the PDP-8/I today.
All of the front panel lights except for the current instruction decoding should be out at power up.
From the image above you can see that isn't the case.
Since we have seen so many sn7474 failures we tried replacing each M113 flip-chip, but saw no changes.
We tried the M113 boards and the one in slot E15 fixed many of the issues.
Pushing the Load Address switch causes the processor to go into the RUN state.
Pushing Load Address, Examine, or Deposit does random things to the lights.
Most of the signals for the manual operations come from the M700 flip-chip so we started there.
We found a two defective sn7400 ICs on the M700 board.
After replacing them most of the lights on the front panel are out on power up.
EXAM and DEP increment the MA, but don't read or write core.
The SW is not loaded in to the MA on LA or into the MB on a DEP, so we still have problems with the manual timing signals.
12/13/14 (Last sequential date for 89 years)
The M700 Manual Timing Generator in the 8/I contains one SN7474 and seven SN7400 ICs.
Since we have seen a high failure rate with these part number ICs we just replaced them all.
It still didn't behave after the repaired module was reinstalled.
It took about two hours of careful signal tracing to find the solder bridges left from replacing all of the ICs.
We found that SN7400 ICs behave very strangely when you short the outout to the input.
Removing two solder bridges solved the "too many lights" problem and now the front panel works correctly.
We started testing the individual instructions with David Gesswein's toggle-in programs to see if anything else was broken.
The ISZ instruction loop resulted in the accumulator going from 7777 to 7700, so the carry bit was not flowing through the M220 modules.
This also showed up as the bit-8 light in the MB register not working.
We gound a dead SN 7440 in location E11 on the M220 in slot EF37.
After replacing it the ISZ loop actually worked!
The CLA CLL instructions should have left the link containing 0 and the accumulator containing 0000 but it actually contained 0001.
The M220 modules that contain all of the registers and adder logic are very complicated and we have had a lot of problems with them.
We went to lunch and tried it an hour later.
We now found that bit-8 in all of the registers was stuck on.
We spent quite a bit of time tracing the behavior of the half-adders, but we haven't figured that issue out yet.
It looks like the SN7482 half-adder IC one one of the M220 modules is broken, or the carry-in logic for the ISZ instruction is broken.
We spent some more time on the stuck register bits problem where bit-9 is on in all of the registers.
This made debugging a challenge because that address and memory bit was always on.
We could execute all of the instructions other than operate because we could reference addresses that always had bit-9 on.
Operate instructions like OSR that had bit-9 on also worked.
We decided to swap some of the M220 Major Register modules to see if the issue would follow a module.
Swapping the M220 modules in slots EF39 and EF38 moved the problem from bit-9 to bit-7.
We moved the suspect M220 to EF34 and the problem changed to the Link register always being on.
Now we could use any address and execute any instruction so debugging was easier.
To me, this looked like a problem where the Carry bit from the M220's Half-Adder was always on.
I checked the Half-Adder's behavior against the TI SN7482 data sheet, and everything looked OK.
Warren called on Skype and helped with the debugging by providing "adult supervision".
We spend a few hours chasing the Carry and Link logic and came to the conclusion that the ADDER L\ signal was always low and it should go high during a CLL instruction.
We eventually decided that the problem with the M220 probably wasn't with the Carry bit and was elsewhere in the M220 logic.
We moved the problem M220 back to slot EF39 and the all of the register's bit-9 were always on.
At least the problem is not intermittent.
During our next debugging session we will look at the rather complex signal multiplexing logic on the M220.
The 8/I can shift AC bits right/left by one or two bits, complement the AC, clear the AC, etc, so there are lots of interconnections between the M220 modules.
There are lots of SN7453 and SN7430 expandable OR gates on the M220 and we have seen quite a few of those IC fail.
We can use the CLA OSR instruction to clear the AC and compare the behavior of bit-8 and bit-9 on the good M220 to see what signals are coming from the bad M220.
We did some more debugging on the M220 problem.
With the problem M220 installed, the next most significant M220 has its low order bits in all registers stuck on.
The output of the low order half-adder on next most significant M220 is always low, which is wrong.
If I pull the problem M220 the half-adder in the next most significant M220 works OK.
So, I think that one of the SN7453 multiplexer ICs that is connected to the next most significant M220 has a shorted input pin.
We will try putting some tape on the card-edge connector contact that connects the half-adder to the SN7453 to see if it will behave with the problem M220 installed.
We started by testing some of the basic register manipulation instructions to see what works.
The CLA instruction should make the AC = 0000, but it was 0001.
The CLL instruction should make the LINK = 0 and not touch the AC, but it made the AC = 0002.
On schematic page 8I-0-8 we started tracing signals on the M220 Major Registers module in slot EF39 to see why the CLA did not make the AC = 0000.
We triggered on the Clock signal on pin 11, and looked at the Data signal on pin 12.
The Data signal should have been low and was high at the leading edge of the Clock signal.
On schematic page 8I-0-9 we looked at the output of the half-adder E13 to see if the problem was in rotate signals or in a data signal.
The output on pin 1 was always low and should have been high.
The Carry input on pin 5 was low and should have been high.
On schematic page 8I-0-8 we looked at the signals going into the M160 in slot F33 that make the signal on pin T2.
Everything looked OK.
We looked at all of the input signals that make the output on pin R1.
We expected to see only the NO SHIFT signal active, but also found that the LEFT SHIFT was active.
On schematic page 8I-0-5 we looked at the signals going into the M617 in slot E31 that make the signal on pin P2.
There was activity on the LEFT SHIFT signal on pin P2 and there should not have been any.
On schematic page 8I-0-5 we looked at the signals going into the M115 in slot F26 that make the signal on pin M2.
The logic on the M115 module decodes the Operate instruction bits and controls the register shifting.
The MB09(1) signal on pin J2 was high even when the corresponding bit in the MB register was not on.
On schematic page 8I-0-8 we looked at the MB09 register signals on the M220 Major Registers module in slot EF39.
Both outputs of the SN7474 flip-flop E8 matched the state of the memory contents.
We looked at the outputs of the SN7440 IC E7 that buffers the MB09 signals.
IC E7 pin-8 went high and low corresponding to the memory contents.
IC E7 pin-6 was always high.
Just to be sure we compared IC E7 pins 8 & 9 and they were correctly opposite.
IC E7 pin-5 changes with the memory contents, but pin-9 was always high.
We replaced the defective SN7440 IC.
This failure caused the Shift & Carry Gate Control logic to have the NO SHIFT and the LEFT SHIFT signals active at the same time.
This made a mess of the multiplexer behavior resulting in one of the half-adders output always being low resulting in all of the corresponding register bits being stuck on.
It also caused the LINK bit to misbehave.
It looks like the processor is mostly working OK now.
The next step is to connect a laptop, download the instruction tests, and see what else is broken.
We spend a little more time in the 8/I.
This time bit-2 of the PC would not go on when doing an LA.
We looked at the outputs of the PC flip-flop on the corresponding M220, and it looked OK.
We chased the PC signals up to the front panel, and found that the bulb had burned out.
Changing bulb in the 8/I front panel is a little painful.
We fixed the console cable.
It got caught on something when the processor was slid out and broke two wires.
The cable has been repaired many times over the last 40 years and should be replaced.
Just for fun we toggled in the TC01 DECtape bootstrap and ran it.
It rewound the tape on unit 0, read a few blocks, and went into space.
At least it showed that the Negibus works and the TC01 is partially alive.
We ran the rest of the toggle-in tests, including console echo and everything works OK.
We loaded the RIM and BIN loaders and then loaded MAINDEC D01C Instruction Test 1.
It halted immediately.
There are many different versions of this diagnostic on the net.
The version that we ran was different from the source code we had, so it is difficult to determine what did not work.
To see if the basic functions of the processor and memory were working we ran D04B Random JMP, D05B Random JMP-JMS, and D1L1 Memory Checkerboard.
They all ran OK.
We ran a different version of D01C Instruction Test 1 and it halted at 2303 in Group 1 Operate Test 2.
This test loads a 2525 pattern in the AC, does a CLA CMA, then another CMA, and then makes sure that the AC = 0.
We found that the CLA and CMA instructions will work independently, but the CLA does not happen when combined with the CMA.
Debugging that will be the project for next week.
We toggled in a set if instructions to test the CLA, CMA, and combined CLA CMA instructions.
The individual CLA and CMA instructions work OK, but the combined CLA CMA instruction does not set all of the AC bits to 1s.
I was surprised to see that the CLA, CMA and combined CLA CMAA instructions are all separate cases in the instruction decoding.
The combined CLA CMA uses the AC LOAD, NO SHIFT, AC ENABLE\, and AC ENABLE signals.
Tracing with a 'scope found that the AC ENABLE was not active during the combined CLA CMA instruction.
We tried replacing the M116 in slot E31, but there was no change.
Replacing the M160 in slot E30 fixed the missing AC ENABLE signals and fixed the combined CLA CMA instruction.
The D01C Instruction Test 1 and D02C Instruction Test 2 diagnostica ran OK, so the processor is probably working fine.
We ran the MAINDEC-08-DITCA-A TC01 BASIC EXERCISER.
It waited for console input so we entered the example codes to run the tape back and forth, but it didn't move the tape.
This was probably due to operator error, so for next week we need to read the manual on this diag before we try it again.
We reran the MAINDEC-08-DITCA-A TC01 BASIC EXERCISER, but this time we didn't enter a RETURN at the end of each command.
We were able to move the tape forward and backward, could see the Timing Track bits, and could see data.
We ran the diag that moves the tape to the End Zone, reverses direction, and looks for the End Zone again.
The AC contained the Block Number. That was nice to see.
We ran the diag that searches for all blocks.
It reversed the tape into the End Zone, and waited for an interrupt.
It never received an interrupt and eventually halted.
We put a HLT instruction in location 1, enabled the interrupts, and put the processor into a loop.
When we hit a key on the console terminal the processor halted at loacation 1, so the interrupts are working.
We connected a 'scope to pin U of the S111 in slot C07 of the TC01.
We saw the state of the INT RQST signal change when the tape went into the End Zone.
We looked at the signal INT RQST on pin J2 of the M506 in slot J15 of the 8/I.
We did not see the state of the signal change when the tape went into the end zone.
Next week we will look into the behavior of the M506 module in slot J15.
After a Skype call with Warren, we ran the the earlier version of the TC01 diag today, MAINDEC-08-D3BB-D TC01 Basic Exerciser.
The idea was that Warren could duplicate the tests we were running if we had questions on correct behavior.
The diag D3BB is made up of several tests.
The test that starts a 0201, Find All Blocks, failed with an interrupt not received, and halted a 0252.
Same as last week when tested with MAINDEC-08-DITCA-A TC01 BASIC EXERCISER.
We went back and forth between the Negibus signals from the TC01 and the Negibus signals in the 8/I.
In the TC01, we found that the DTF (DECtape Flag) bulb did not illuminate, but the corresponding flip-flop was working OK.
The bulb and the bulb drivers are OK, so we will work on this issue later.
The ENI (Enable Interrupts) bulb was not working, but wiggling the bulb fixed it.
We ran the diag that starts at 0210, Search Scope Loop, and saw that the logic in the TC01 was generating an Interrupt Request when the DTF or EF, Error Flag, was set.
In the 8/I, the Interrupt Request from the Negibus was arriving at the M506, Negative Input Converter module in slot J15.
The INT RQST signal from teh M506 was not going into the 8/I, so no interrupt from the TC01.
We eventually found a bad 2N3009B transistor on the board.
We didn't have any spares, so we borrowed one from a spare flip-chip.
It looks like the plastic 2N3009B parts are difficult to find, so we ordered some PN3569 substitutes.
After replacing the transistor, test 201 still failed, but just a little further into the diag at 0257.
The code listing doesn't have comments in this area, so we are not sure what it is looking for.
We tried all of the other diags, and everything worked except for the test at 205, including reading and writing the tape.
Test 205 for the parity detection circuits failed.
When we went back to test 201 it ran just fine.
Maybe our test DECtape had data that diag 201 didn't like, and running the other tests fixed it.
Since the read/write diags worked OK, we got brave, and decided try to boot the 4k Monitor from DECtape.
After toggling in and running the bootstrap, the DECtape wiggled a lot, and it halted.
We had disabled write enable for the DECtape as a precaution.
After we enable writing on the DECtape, and restarting the bootstrap, we were rewarded with a ".".
We loaded and ran PIP from the DECtape, and listed the files that are on the DECtape.
This is the first time that the 8/I booted the 4k Monitor from DECtape in about two years.
Next week we need to fix the DTF indicator and determine what is wrong with the parity circuit in the TC01.
We need to load more programs onto the 4k Monitor DECtape, especially some games for demonstrations.
We need to remove the tape guides from the second DECtape drive so we can remove the corrosion and polish the surface.
The 8/I restarted the 4k monitor OK.
All you need to do is set the switches to 7600, and press Load Addr and Start.
We bought some PN3569 transistors as a substitute for the DEC3009B (2N3009) parts on the M506 Negibus interface module.
Now that we have spares we will never need them.
We started loading software onto the 4k Monitor DECtape.
It is a little slow loading through a 110 baud serial port, but fortunately the files are small.
It will be interesting to edit, compile, and run a FORTRAN program on this system.
We removed the tape guides from the second DECtape drive.
We need to clean off the corrosion and polish the tape guide surface.
This drive worked OK other than the problem with the corroded tape guides.
The other drives all have motor control problems.
We should be able to get a third drive working with just swapping parts from the other broken drives.
The 8/I started the 4k Monitor OK.
We installed the polished tape guides for the second DECtape drive.
We had to adjust the brake drag for the left reel to reduce the drag a little.
We rain MAINDEC-08-D3BB, the TC01 basic exerciser.
The motion for DECtape drive 1 looks like it is working OK.
It can find the endzone, so the Timing and Mark tracks are being read OK.
When running the search scope loop, the block number is in the AC.
In the block numbers, bit-1, bit-4, and bit-7 looked erratic, and sometimes the wrong block number was read.
We ran same tests on drive 0 to make sure that the controller was OK. It was.
We swapped tapes to make sure that both tapes were OK.
Both tapes worked OK on drive 0.
Eventually we remembered that bit-1, bit-4, and bit-7 are all the same tape track.
There is nearly nothing in the tape drive related to data, other than wires and a relay board.
So, this pointed to a interconnection problem between drive-0 and drive-1.
We pulled the interconnecting cables and found that there was corrosion between the traces on the boards.
We scrubbed the corrosion, cleaned the gold fingers with a white eraser, and cleaned everything with 91% alcohol.
The flickering block number lights were gone, so the connections were now reliable.
The drive failed the search find all blocks, but we have seen this failure before on a tape that was used for diags.
The Start/Stop/Turnaround showed a little jerkiness in the left hub. That may be brake adjustment.
The Read/Write Data test worked OK.
We tried to load DEC-08-EUFB-PB TC01-TU55 DECtape Formatter, but the BIN loader halted.
We reloaded the BIN loader and tried again, but there was no change.
We tried several different binary images of EUFB, but none would load.
We loaded MAINDEC-8I-D01C Instruction Test 1 to see if the processor is still OK.
Since we had issues after we connected the second TU55 DECtape drive last week, we disconnected it to make sure that the TC01 and the first TU55 DECtape drive was still working OK.
We ran the newer diag, MAINDEC-08-DITCA TC01 Basic Exerciser, because it has a thorough register test that MAINDEC-08-D3BB does not.
That passed OK, so we knew that the Negibus and the registers in the TC01 were OK.
We ran Search Find All Blocks, but it halted at 2564.
Oops, it is supposed to do that if SW11 = 0. It runs OK with SW11=1.
Setting SW11=1 made it repeat the test without halting.
The Start/Stop/Turnaround Test, and the Write/Read Data Test passed OK.
The Parity Generation and Checking Test failed.
We knew there was a problem with the parity circuit, but since everything else was working OK we have been putting off debugging this issue.
Now seemed as good a time as any to fix it.
The LPB Register that checks the parity is just a set of six flip-flops.
The flip-flops are cleared at the start of a data block, and each time six data tracks are read, a zero bit in the track will flip the state of the flip-flop.
Reading the checksum at the end of the block should set all of the flip-flops to a 1 state, which will make the LPB=1 signal go to ground.
During the parity diag, wrong parity is written with lots of different patterns to make sure that all faults are detected.
In our case, the parity errors were detected because the LPB (not equal) 1 signal was at -3V.
That signal gets NORed with READ DATA to set the PAR flip-flop if there is a parity error during a read.
The signal to the PAR flip-flop was always inactive, so we replaced the R113 in slot E26.
That didn't make any difference, so it was likely that the input to the S203 flip-flop was sorted to ground.
We didn't have a spare for the high power S203 flip-flop, so we swapped the S203 modules in slots D25 and D26.
The parity diag worked after that change, so we knew that we had just moved the PAR problem to the TIM flip-flop.
Swapping the S203 modules back to their original positions restored the parity problem.
There are a number of possible faults on the S203 that we need to look for. D49 could be shorted to -0.6V.
We might be able to see that on the 'scope if we set the trigger threshold low enough.
Q4 could have an emitter to base short.
The only difference between the R203 modules that we have, and the S203 modules that we do not have, is the stronger 3k pulldown on the S203 and the 4.7k pulldown on the R203.
We can borrow components from and R203 to fix the S203 if we need to.
So, the project for next week is to fix the S203 in slot D25.
We should also fix the indicator bulb for the DECtape flag, and make sure that the PAR indicator is working.
We also need to put the original R113 back in slot E26.
We replaced a 2N3639 transistor and a D662 diode on the S203 in slot D25.
The TC01 DECtape controller and first TU55 DECtape drive now pass all diagnostics.
We connected the second TU55 DECtape drive. It also passes diagnostics.
We booted the 4k monitor from the first DECtape drive.
We loaded PIP and did a directory listing of the second DECtape, but it just caused the tape to go from end-to-end.
Our guess is that you need to somehow initialize the tape for the 4k monitor, but nothing about this is mentioned in the manuals.
We ran the system builder (dec-d8-sbaf-pb.bin) and made a new bootable DECtape on drive 1.
Booting from drive 0 and listing the directory on drive 1 now works.
Next week we will see what is wrong with the other three TU55 DECtape drives and see if we can swap parts and get another one working.
We will need to remove an polish the tape guides too.
We need to connect the VT52 terminal and load some games on the DECtape so we can demonstrate this system.
I would also like to get the Music program working.
Having a Fortran source file on DECtape would let us demonstrate the whole edit/compile/debug/run software development cycle.
We copied the system files on the first 4K System Monitor DECtape to the new 4K System Monitor DECtape that we made last week.
It looks like the files get copied a block at a time, so it really wiggles the tapes a lot.
Both DECtapes are bootable.
We copied the rest of the 4K System Monitor paper tape images to the DECtapes, so we have all we need to develop FORTRAN programs.
The process is a little cumbersome, you run the Loader, load the program into memory through the serial console at 100 baud, and then Save the contents of the memory to DECtape.
We tried to go through one of the simple examples for editing, compiling, and running a FORTRAN program.
Yes, this can be done with just 4k of memory.
The 4k Monitor manual doesn't have the complete information on the Editor, just what is different between the paper tape version and the 4k Monitor version.
Looking in both manuals for the Editor command details was painful.
The FORTRAN compiler started to run, but died with a 6226 error, Error while loading .FT..
We could have made an error when copying the files to DECtape, or the original paper tape image may have problems.
We ran the 4k Monitor on the SIMH simulator to see if the FORTRAN compiler works OK.
We didn't notice that the example that were using had an intentional error to show how the debugging tools work.
We found that the FORTRAN compiler didn't like getting the source from and putting the binary on DECtape #1, a non-system device.
We haven't figured out how to change an existing text file with the editor yet, so we cut and paste from Windows.
Click on the image for a larger view.
We changed the current-loop connector on the VT52 terminal to match what is on the back of a VT220.
Now we can swap the VT52 and VT220 between the PDP-8/S, PDP-8/L, PDP-8/I, and the PDP-9.
We tried to compile a simple FORTRAN program, but the compiler always reported a 6226 error.
This is a memory location, not a compilation error, so maybe the processor or core isn't working correctly.
The MAINDEC-08-D05B Random JMP-JMS test is on the 4k Monitor DECtape, so we ran that.
It ran fine and printed 05 on the console every 12 seconds.
The MAINDEC-8I-D01C Instruction Test 1 was also on the DECtape, so we ran that too.
It also ran OK.
We tried reloading the FORTRAN compiler, but at the end of loading it halts with a non-zero AC, so it didn't load correctly.
We had the same problem when we tried to load FOCAL, and PALD.
During the week we experimented with running the 4k Monitor under SIMH and everything worked OK, so we know the paper tape images are OK.
All of the previous files that we copied to DECtape were small and worked OK.
These files are large so the process is a little different.
During the copy the LOADer occupies some of the core memory that would normally be used for the compiler.
It looks like the LOADer copies some of the core memory to DECtape, and then continues reading the file from the serial console port.
An ASR-33 Teletype is usually used as the console and to load the files.
We are emulating the TTY with a program running under windows.
When the PDP-8/I turns off READER RUN, the serial port on the PC should stop sending characters immediately.
We had the serial port FIFO enabled so it is likely that the PC kept sending data after the PDP-8/I told it to stop.
There is also a hardware flow control option for the Windows serial port, so we can try that too.
David Gesswein wrote a set of dump/restore programs for the PDP-8 that will copy disk or tape images between a PDP-8 and a PC.
These tools worked great when we made RX01 and DECtape images on the PDP-8/e.
Next week we will try copying a DECtape image built with SIMH to a real DECtape on the PDP-8/I.
The processor and DECtapes have been working OK for about two months!
We tried tried to load the FORTRAN compiler to DECtape from a paper tape image again.
Last week we had left the Windows serial port in the default configuration with the FIFO on.
With the FIFO on, the serial port would continue to send characters after the CTS signal from the PDP-8/I had turned off.
We turned off the FIFO, but we still saw a non-zero AC after the paper tape image was loaded.
We halted the processor and saw CTS hold in the terminal emulator go on, so we know that the Reader Run wiring and flow control are working.
Not sure why this doesn't work when loading a program.
This week Warren Stearns built a working DMS DECtape on a Classic PDP-8 using the high-speed reader for input.
Warren will send us a physical DECtape of DMS including the large files that we can't load and FOCAL.
We can make a new empty DMS tape on the PDP-8/I and copy the large files from Warren's tape to the new tape to make more working DMS tapes.
SIMH running DMS works fine when using the high-speed reader for paper tape input, but it doesn't really simulate using the console as the file input.
It was easy to make a working DMS DECtape image using the high-speed reader in SIMH.
David Gesswein's standalone dumprest programs for the TC08/TC01 assumed 8k of memory, so we couldn't use it to dump a SIMH simulated DECtape image to a physical DECtape.
David kindly modified his program to run in only 4k, so we will try that next time.
No progress for two weekends while I was in Germany.
Warren Stearns sent us two DMS DECtapes that he built on a Classic PDP-8 using his laptop for input.
The DMS DECtape that Warren made works perfectly!
We have not determined why he can load large programs to DECtape from his laptop and we can't.
We now have FORTRAN, PALD, FOCAL, games, and diags on the DECtape.
This works much better than loading programs through the serial console port at 110 baud.
NAME TYPE BLK
PIP .SYS (0) 0025
EDIT.SYS (0) 0016
LOAD.SYS (0) 0011
.CD..SYS (0) 0007
PALD.SYS (0) 0037
FORT.SYS (0) 0010
.FT..SYS (0) 0035
FOSL.SYS (0) 0007
.OS..SYS (0) 0025
STBL.SYS (0) 0001
DIAG.SYS (0) 0004
DDT .SYS (0) 0002
STAT.FTC BIN 0003
FRMT.SYS (0) 0013
COPY.SYS (0) 0007
FOCL.SYS (0) 0037
FC01.SYS (0) 0037
LUNR.SYS (0) 0037
HAMI.SYS (0) 0037
CLNR.SYS (0) 0037
ZERO.SYS (0) 0001
DTCR.SYS (0) 0015
DUMP.SYS (0) 0004
REST.SYS (0) 0004
CONTROL CALLING LUNAR MODULE.MANUAL CONTROL IS NECESSARY
YOU MAY RESET FUEL RATE K EACH 10 SECS TO 0 OR ANY VALUE
BETWEEN 8&200 LBS/SEC. YOU'VE 16000 LBS FUEL.ESTIMATED
FREE FALL IMPACT TIME-120 SECS.CAPSULE WEIGHT-32500 LBS
FIRST RADAR CHECK COMING UP
COMMENCE LANDING PROCEDURE
TIME,SECS ALTITUDE,MILES+FEET VELOCITY,MPH FUEL,LBS FUEL RATE
= 0 = 120 = 0 = 3600.00 = 16500.0 K=:6
= 10 = 110 = 1191 = 3436.60 = 15500.0 K=:50
= 20 = 100 = 4070 = 3370.55 = 15000.0 K=:50
= 30 = 91 = 2649 = 3302.87 = 14500.0 K=:50
= 40 = 82 = 2234 = 3233.50 = 14000.0 K=:50
= 50 = 73 = 2848 = 3162.39 = 13500.0 K=:50
= 60 = 64 = 4519 = 3089.48 = 13000.0 K=:50
= 70 = 56 = 1992 = 3014.71 = 12500.0 K=:50
= 80 = 48 = 577 = 2938.01 = 12000.0 K=:50
= 90 = 40 = 301 = 2859.31 = 11500.0 K=:100
= 100 = 32 = 2058 = 2659.65 = 10500.0 K=:200
= 110 = 25 = 3356 = 2196.94 = 8500.0 K=:200
= 120 = 20 = 1177 = 1692.63 = 6500.0 K=:200
= 130 = 16 = 1465 = 1139.13 = 4500.0 K=:200
= 140 = 13 = 5010 = 526.59 = 2500.0 K=:50
= 150 = 12 = 3565 = 389.78 = 2000.0 K=:10
= 160 = 11 = 3121 = 390.66 = 1900.0 K=:10
= 170 = 10 = 2666 = 391.35 = 1800.0 K=:10
= 180 = 9 = 2203 = 391.84 = 1700.0 K=:10
= 190 = 8 = 1733 = 392.14 = 1600.0 K=:10
= 200 = 7 = 1261 = 392.24 = 1500.0 K=:10
= 210 = 6 = 789 = 392.14 = 1400.0 K=:10
= 220 = 5 = 319 = 391.83 = 1300.0 K=:10
= 230 = 3 = 5136 = 391.33 = 1200.0 K=:10
= 240 = 2 = 4681 = 390.61 = 1100.0 K=:10
= 250 = 1 = 4239 = 389.69 = 1000.0 K=:50
= 260 = 0 = 4910 = 237.85 = 500.0 K=:100
FUEL OUT AT= 265.00 SECS
ON THE MOON AT= 289.40 SECS
IMPACT VELOCITY OF= 150.25 M.P.H.
FUEL LEFT:= 0.00 LBS.
SORRY,BUT THERE WERE NO SURVIVORS-YOU BLEW IT!
IN FACT YOU BLASTED A NEW LUNAR CRATER= 41.74 FT.DEEP.
Well, the FOCAL game works, but I need some Lunar Lander pilot training.
The third DECtape drive has motor control logic problems.
The brakes on the motors do not go on when it is in LOCAL.
That should not be difficult to diagnose and fix.
At least the motors work at all three torque levels, so the motors and motor drive boards are OK.
We removed the corroded tape guides so they can be cleaned and polished.
Next week we will reassemble the third DECtape drive and fix the drive control logic.
We removed, cleaned, and polished, and reinstalled the tape guides from the third TU55 DECtape.
The brakes would not go on when the drive was in LOCAL or REMOTE.
We checked the outputs of the W701 modules that are connected to the switches, all were OK.
The BRAKE ENABLE output from the R111 in slot B06 was OK.
The output of the DIRECTION and MOTION flip-flops were OK.
The DELAY output from the R303 in slot A04 never changes.
Click on the image for a larger view.
The R303 was covered with corrosion, so that may have had something to do with the failure.
We swapped the R303 from the second drive, and the brakes now work.
The borrowed R303 was also covered with corrosion.
We borrowed another corroded R303 from the fourth DECtape drive.