DEC PDP-8/I Restoration

1/07/12

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.

1/14/12

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.

1/21/12

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.

1/28/12

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:

Drive #1:

The drive defaults to the rewind state.

Both motors can be put in the tension and torque states.

Both brakes are inoperative.

Drive #2:

Everything works, except that there is never any back tension.

Drive #3:

The mounting bracket is broken off the brake drum.

We will see if we can disassemble the brake and spot weld the parts together.

Drive #4:

Everything works OK.

Drive #5:

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.

2/4/12

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.

2/11/12

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.

2/18/12

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.

2/25/12

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.

3/3/12

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.

It works!

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.

3/10/12

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.

3/17/12

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.

3/31/12

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.

4/7/12

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.

4/14/12

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.

4/21/12

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.

4/28/12

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.

5/12/12

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.

5/12/12

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.

5/19/12

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.

5/20/12

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.

5/26/12

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.

6/2/12

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.

6/9/12

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.

7/14/12

We tested the core stack from the 8/I in the 8/L. Everything works perfectly.

7/21/12

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.

7/28/12

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.

8/4/12

We tested the M216 modules in Warren's tester and the all look OK.

We will test more modules next week.

8/5/12

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.

8/11/12

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.

8/13/12

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.

8/13/12

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.

8/25/12

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.

9/1/12

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.

9/3/12

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.

9/8/12

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.

9/15/12

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.

9/22/12

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.

Before

After

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.

9/29/12

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.

10/05/12

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.

10/07/12

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.

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.

12/1/12

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.

12/9/12

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.

12/15/12

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:

Next Week:

Load additional programs onto the 4k Monitor DECtape.

09/28/13

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.

11/29/14

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.

12/6/14

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.

12/8/14

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.

12/20/14

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.

12/22/14

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.

12/27/14

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.

12/28/14

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.

1/3/15

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.

1/10/15

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.

1/17/15

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.

1/25/15

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.

1/31/15

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.

2/7/15

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.

2/14/15

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.

2/21/15

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.

2/28/15

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.

3/7/15

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.

3/14/15 9:26:53

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.

4/4/15

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.

.PIP

*OPT-L

*IN-S:

FB=1755

NAME  TYPE    BLK

AF

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

.DDT.USER(0) 0022

CDE1.ASCII   0007

STAT.ASCII   0003

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

D801.BINARY  0004

D802.BINARY  0002

D803.BINARY  0001

D01A.BINARY  0004

D02A.BINARY  0003

D03A.BINARY  0001

D04B.BINARY  0003

D05A.BINARY  0003

D07A.BINARY  0004

D111.BINARY  0003

D112.BINARY  0003

D1L1.BINARY  0003

D1L2.BINARY  0001

D2AA.BINARY  0002

D2CA.BINARY  0002

D2BA.BINARY  0003

D1AA.BINARY  0001

D1CA.BINARY  0003

D1EC.BINARY  0003

D1GD.BINARY  0003

D3BB.BINARY  0003

D3BC.BINARY  0003

D3EB.BINARY  0003

D3RA.BINARY  0003

*OPT-

.LUNR

?

?00.00

*GO

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

NOT POSSIBLE...................................................K=:100

    =  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.

CONTROL OUT*

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.

4/11/15

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.

After cleaning the R303 module the brakes on the third DECtape drive work.

We booted DMS from the first DECtape drive, and installed another DMS tape on the third DECtape drive.

We can read the directory from the third DECtape!

Well, it wrecked the tape when we wrote to it.

That will be the debugging project for next week.

Warren sent us paper tape and DECtape images of DECUS-8-195 POLY BASIC.

This version of BASIC should boot from DECtape, and load and save programs from the DECtape.

It should also run in just 4k of core.

4/18/15

We loaded the MAINDEC-08-D3BB-D TC01 Basic Exerciser.

The Basic Motion test works, so at least the motors and brakes are OK.

The Search Scope Loop displays all of the blocks in the AC.

The first tape that we used had a bad spot in the middle, so we are using one from a PDP-11.

I don't want to wreck one that we formatted on this system.

The Search Find All Blocks works, but always displays an error message at the end of the tape.

SEARCH FWD

1102

1101

5000

We reformatted the tape on DECTAPE drive #3.

It didn't work last week, so maybe exercising it with the diags made it work better.

We used DECtape Copy to copy a DMS tape from drive #0 to drive #2.

We changed the drive numbers so that the top left drive was #0, and rebooted DMS.

DMS started right up and seems to be working.

So, it looks like all that is left to do is fix the indicator lights on the TC01 DECtape controller.

We need to make a POLY BASIC DECtape from the image that Warren sent us.

We need to print boot and run instructions so anyone can use this system for demonstrations,

5/2/15

No activity last week due to a board of director's meeting.

Booted DMS and formatted four DECtapes from the collection in the warehouse.

These tapes didn't have a directory listing in the container, and said DATA on the label.

There are a bunch of DECtapes with RT-11 directory listings in the container that we will preserve.

We loaded the DECUS-08-195 POLY BASIC loader and then fed it the POLY BASIC SYSTEM tape.

After about 25 seconds the loader wrote a little of the SYSTEM on the DECtape, and waited for more data.

A half-hour later it printed READY, and the AC lights are blinking in an unusual pattern.

7/27/15

We booted DMS just to make sure it still runs.

10/10/15

The 8/I is back together after we borrowed a TU55 to help with debugging the PDP-12.

We modified the PDP-12 console cable and the PDP-12 Teletype cable to have the standard 8-pin AMP 20mA connector.

We then connected the Teletype from the PDP-12 to the console cable for the 8/I.

It is a very different experience to have a Teletype as a DMS console instead of a terminal emulator on a Windows laptop.

The three TU55 DECtapes in the left cabinet are all working.

12/3/16

We ran the DMS monitor from DECtape just to see if the system was still behaving OK.

After resetting the DECtape configuration and other switches that our visitors changed it booted and ran OK.

We ran PIP and listed the directory on the DECtape.

We need to replace the ribbon and fix the line feed mechanism in the Teletype.

4/1/17

Charles Lasner asked us to run a short program to determine what the MB lights will display.

After the light check we decided to run the DMS monitor from DECtape just to see if the whole system was still behaving OK.

DECtape 0 would not select and move.

We got out the 'scope and chased the drive select signals in the TC01 DECtape controller.

Status register A contains the drive select bits, so we entered a short program to read the console switches and write to Status register A.

The bits could be written, but not cleared.

We found that the CLEAR STATUS A signal was missing.

That is generated by the IOP2 signal and it was missing on the Negibus cable.

The BIOP 2(0) was not present on pin K2 of the M651 module in slot H11.

The signal was present on pin N2, so it looks like there is a problem in the M651 module.

We cleaned the gold fingers, and it looks like it is behaving again.

Next week we will see what else is misbehaving.

4/8/17

Last week we found that the gold fingers on one of the M651 modules were dirty enough to make a bad BIOP 2(0) signal connection on the Negibus.

This week we cleaned the rest of the M651 and M506 module fingers.

We loaded ran MAINDEC-08-DITCA-A-BP TC01 BASIC EXERCISER.

It halts at address 1135, so it looks like the CIA instruction is no working.

The first thing that this disg does is write to the status registers, read the register back, and compare the reading to the original value that was written.

Since the PDP-8/I can subtract you need to do 2s compliment addition.

The diag uses the CIA instruction to compliment the value read from Status Register A, and then increment the value, turning into the negative of the original value.

Then it does a 2s compliment add (TAD) of the original value, and checks to see that the result of the addition is zero.

In our case the value was the original value, so the value read from the register was not complimented.

We made a small loop to test the CIA instruction and it it works OK when single-stepping.

It does not work when the processor is running at full speed.

We have seen this behavior before when a driver transistor in an IC partially fails, and cannot drive the capacitive signal load at full speed.

This issue should not be too difficult to debug and repair.

4/15/17

We looked at the #AC ENABLE signal from pin V2 on the M617 in slot E32.

It shows a 2.8V 30nS positive pulse.

We looked at the OP1 and MB06 signals on pins H2 and J2 on the M113 in slot F32.

The MB06 signal (CMA) is about 1.4uS, there is a 220nS OP1 pulse, and then a 40nS pulse at the end of the MB06 pulse.

The output on pin K2 looks OK and there is no glitch at the end of the MB06 pulse.

We replaced the M617 in slot E32, but the #AC ENABLE signal did not change.

We put the original M617 back in, and now the #AC ENABLE signal looks OK.

We cleaned the gold fingers on the M617 in slot E32, and hopefully it will behave OK for a while.

We ran MAINDEC-8I-D01C Instruction Test 1 for several hours, and it works OK

We ran MAINDEC-8I-D02A Instruction Test 2 for 30 minutesran OK and printed 2A on the console.

I looks like it is fixed again.

The MAINDEC-08-DITCA TC01 BASIC EXERCISER was halting at 1135 showing that the CIA instruction was not working.

Now it is halting at 1143 showing that the CMA instruction is not working.

More debugging for next week...

4/22/17

We toggled in an instruction loop to test the CIA and TAD instructions using the register values from the failing MAINDEC-08-DITCA TC01 BASIC EXERCISER.

Everything worked OK.

We toggled in an instruction loop based on the DITCA register test, and it fails.

The CIA instruction was followed by a JMP, but it didn't JMP to the correct address.

Based on the behavior of the instructions, it looks like there is a memory problem.

We ran the processor and memory tests to see if they find any problems.

MAINDEC-08-D01C Instruction Test 1, runs OK.

MAINDEC-08-D02B Instruction Test 2, runs OK.

MAINDEC-08-D04B Random JMP Test, runs OK

MAINDEC-08-D05B Random JMP-JMS Test, runs OK.

MAINDEC-08-D07B Random ISZ test, runs OK.

MAINDEC-08-D1B1 Memory Address Test Low, runs OK.

MAINDEC-08-D1B2 Memory Address Test High, runs OK.

MAINDEC-08-D1L1 Memory Checkerboard Low, runs OK.

MAINDEC-08-D1L2 Memory Checkerboard High, runs OK.

MAINDEC-8I-D01C Instruction Test 1, runs OK.

MAINDEC-8I-D02B Instruction Test 2, runs OK.

Well, all of the diagnostics run OK, so the processor must be OK.

The instruction loop that failed this morning works OK now.

MAINDEC-08-DITCA TC01 BASIC EXERCISER, runs OK.

The TC01 register test that failed before works OK now.

The Search Find All Blocks works OK and displays the block number in the AC.

The read/write diag worked for about 10 minutes, and now periodically finds the wrong blocks.

It is running well enough to boot DMS, but the TC01 errors still need to be fixed.

It will be interesting to see if it runs OK next week.

4/29/17

I set the console switches to 7600, pressed Load Add, then Start, and DMS came right up.

I used PIP to make see what was on this tape, because loading Maindecs from DECtape is much faster than through the 110 baud serial console.

.PIP

*OPT-L

*IN-S:

FB=1755

NAME  TYPE    BLK

AF

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

.DDT.USER(0) 0022

CDE1.ASCII   0007

STAT.ASCII   0003

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

D801.BINARY 0004 Instruction Test

D802.BINARY 0002 Memory Checkerboard Test

D803.BINARY 0001 Address Test

D01A.BINARY 0004 Instruction Test, part 2A

D02A.BINARY 0003 Instruction Test, part 2B

D03A.BINARY 0001 BASIC JMP JMS TESTS

D04B.BINARY 0003 Random JMP Test

D05A.BINARY 0003 Random JMP/JMS Test

D07A.BINARY 0004 Random ISZ Test

D111.BINARY 0003

D112.BINARY 0003

D1L1.BINARY 0003 Memory Checkerboard (Low)

D1L2.BINARY 0001 Memory Checkerboard (High)

D2AA.BINARY 0002 Family of 8 Teletype Tests

D2CA.BINARY 0002 High Speed Reader/Punch Tests

D2BA.BINARY 0003 TTY Test

D1AA.BINARY 0001 Memory Power On/Off Test

D1CA.BINARY 0003

D1EC.BINARY 0003 Extended Memory Checkerboard

D1GD.BINARY 0003 Extended Memory Control Test

D3BB.BINARY 0003 TC01 Basic Exerciser

D3BC.BINARY 0003 TC01 Basic Exerciser

D3EB.BINARY 0003 TC01 Extended Memory Exerciser

D3RA.BINARY 0003 TC01 Random Exerciser

*OPT-

We loaded and ran MAINDEC-08-D3BB TC01 Basic Exerciser

It ran OK and didn't report errors on any of the tests.

We loaded and ran MAINDEC-08-D3RA TC01 Random Exerciser

It reports P.I NO DECTAPE SKIP

We loaded a different paper tape image of MAINDEC-08-D3RA TC01 Random Exerciser

This one runs OK and keeps the processor very busy.

We booted DMS again, and ran FOCAL.

It runs OK.

Looks like we are ready to try P?S8 in two weeks.

5/12/17

Charles Lasner visited the RICM today.

We wrote  a DECtape image of his P?S8 OS to a physical tape on the PDP-8/I using David Gesswein's dumprest tools.

Since our PDP-8/I only has 4k, David made a special version of his tape writing tool for us.

Charles showed us a very abbreviated version of the TC01 DECtape boot program.

Address    Contents

7615       7604

7616       6766

7617       5217

7754       7577

7755       7577

Load the DECtape, and forward the the tape a few feet.

7615 Load Addr

Set the switches to 0600 and press Start.

After the tape rewinds and stops, press Stop.

Set the switched to 0220 and press Start.

The OS will now boot.

P?S8 really runs on our 4k PDP-8/I!

.DIRECT/S

------

P?S/8 System Directory  DIRECT V10b  Friday 12-Aug-17  Page 1

System: TC08:0

Image Information:

 Name   Block  Size  Load  Length  Out   In   R  S  O  Start

ODT     0163   016   0000    16   GENO  GENI  0  0  0  03000

BATCH   0201   002   7400    01         BAT   0  0  0  07400

BIN     0203   027   0000    13   BIN   BIN   0  0  0  00200

GET     0203   027   0000    13   BIN   BIN   0  0  0  00600

START   0203   027   0000    13   GENO  GENI  0  0  0  00400

DUMP    0232   007   0000    07         DUMP  0  0  0  01400

CHANGE  0241   003   1200    03               1  1  0  01600

FIND    0241   003   1200    03               1  1  0  01200

BSAVE   0244   006   3000    06   BIN         0  0  1  03000

PAL     0252   102   0000    37   BIN   PAL   0  0  0  00200

MAP     0354   012   0000    12         BIN   0  0  0  01200

BLKODT  0366   011   0000    11               0  0  0  02000

SET     0377   013   3000    13               1  1  0  03000

CORE    0412   002   3000    02               0  1  0  03000

DATE    0414   012   3000    12               0  1  0  03000

PRINT   0426   014   0000    14         PAL   1  0  0  00200

FILMAN  0442   024   2600    24               0  1  0  07000

ALLCAT  0466   003   3000    03               0  1  0  03000

CONSOL  0471   040   3000    20         BIN   0  0  0  03000

FOCAL   0531   041   0000    37         FOC   0  0  0  03400

OS8CON  0572   012   0000    12   ASC   ASC   0  0  0  00200

SYSTAT  0604   014   0000    14               0  0  0  00200

DIRECT  0620   023   2600    23               1  1  0  07200

BLKCPY  0643   026   0000    26               0  0  0  00200

RK4MAT  0671   021   0000    21               0  0  0  02200

DT4MAT  0712   014   0000    14               0  0  0  02600

DTCOPY  0726   007   0000    07               0  0  0  00000

<free>  0735   043

Free Slots:    072

Charles demonstrated the console interface, and it is much more modern than OS/8.

This OS has much more capability than DMS, the only other OS (Monitor) that will run on our 4k PDP-8/I.

5/13/17

We fixed the ASR-33 Teletype that came with the PDP-12, and connected it to the PDP-8/I.

We booted Poly BASIC, and loaded a program from the DECtape.

We were able to punch the program onto paper tape and read it back.

It really brought back memories of writing BASIC programs on my 6800 system when I was in college.

5/20/17

We Marked (Formatted) a some DECtapes so we could make copies of the P?S8 operating system.

We made a new P?S8 tape using Dave's dumprest programs.

5/27/17

The P?S8 tape that we made last week booted OK.

We had to adjust the Logical Core so that the tools would only use 4k.

.CORE

PHYSICAL: ONLY 4K

LOGICAL: 32K!

MAXIMUM: ONLY 4K

.CORE ALL

PHYSICAL: ONLY 4K

LOGICAL: ONLY 4K

MAXIMUM: ONLY 4K

.SYSTAT

------

P?S/8 System Status  SYSTAT V10d  Saturday 05-AUG-23

System:          TC08:0 (01)

Version:         8Z

Console:         KL8:0 (01) (Disabled)

CPU Type:        PDP-8/I

Physical Memory: 4K

Maximum Memory:  4K

Logical Memory:  4K

EAE:             Not Installed

Handler Information:

Name    Block  Length  Entry  Block Size

SYS     0123     01     000     00200

NUL     0123     01     034     00200

DTA     0124     01     011     00200

RXA     0125     03     000     00200

RKA     0130     04     000     00200

RKB     0130     04     005     00200

LTA     0134     01     000     00200

DSU     0135     01     075     00200

DSL     0135     01     026     00200

LIN     0136     01     000     00200

LTD     0137     01     000     00400

LID     0140     01     000     00400

FLP     0141     01     000     00200

<FREE>  0142     21

Free Slots:      02

------

.

7/8/17

More time away from the 8/I while I was in Germany again.

We bought new ribbons for the Teletypes from Ribbons Unlimited for $11.95 each.

If you ask for model 33 Teletype ribbon they will add the reversing rivets to a standard ribbon.

They seem to work nicely, and we can actually read the printing now.

We restarted P?S/8 from 7600 and it came right up.

We ran SYSTAT and taped the listing on the front of the 8/I.

While printing a directory listing the system started printing garbage and would not restart P?S/8.

The G221 flip-chips that do the address decoding each work on three bits of the memory address.

We tried reading/writing memory in the blocks 7xxx, x7xx, xx7x, and xxx7.

All of the address blocks worked OK except for xxx7.

After a few minutes of fiddling we found that we could not read/write any memory location ending in 5.

The G221 flip-chips in slots D37 & D38 decode MA09, MA10, and MA11.

The one in D37 is active when MA09 is a zero, and the one in D37 is active when MA09 is a one.

In our case the address ending in a 5 has MA09 set to a one, so we replaced the G221 in slot D38 with a repaired spare.

The core memory works again for all addresses, so we determined (guessed) the right failed flip-chip.

Since the G221 uses a SN7400 and a SN7440 to decode the memory address and drive current through the core.

We have replaced lots of SN7400 and a SN7440 chips in this system, so I will replace both instead of determining which one failed.

We were able to boot P?S/8 and execute the DIRECT/S command and list the directory on the P?S/8 DECtape, so we will declare victory and work on the PDP-12.

7/22/17

P?S/8 restarted at 7600.

Set the date to today. This OS is Y2K!

I fiddled with FOCAL a little.

Everything seems to work OK.

8/5/17

The 8/I would not boot P?S/8 when we tried to restart at 7600.

We reentered the TC01 bootstrap, but it would still not boot.

We wiggled all of the flip-chips, and P?S/8 booted and ran OK.

We demonstrated ancient computer technology so some of our young visitors.

1/5/19

The 8/I would not boot P?S/8 when we restarted at 7600.

We reentered the TC01 bootstrap, but it would still not boot.

We wiggled all of the flip-chips, and there was no change.

It rewinds and goes off the end of the tape, so there is probably a problem in the TC01 DECtape controller..

1/5/19

We tried a different DECtape, but the bad behavior was the same.

We toggled in some simple instruction tests, and they worked fine..

We ran MAINDEC-08-D01C Instruction Test 1 and MAINDEC-08-D02B Instruction Test 2, and both ran OK.

We loaded MAINDEC-08-D3BB TC01 Basic Exerciser, and ran the Basic Motion Routine.

The Clear and Load Status A test works OK, so at least we can talk to the TC01 controller.

The Tape Motion and Timing Pulse Generation test failed.

The US (Up to speed) indicator did not go on, and the Counter indicators stopped with C0 and C2 illuminated.

We should have seen US go on, a the C0-C2 indicators cycle.

Looks like we are not seeing the timing track signal.

Wiggling all of the FlipChips in the TC01 DECtape controller made the indicators look much better.

Well, that didn't last long and it is broken again.

1/26/19

We got the 'scope out and loaded MAINDEC-08-D3BB.

We started the diag at 0210 and the US indicator turned on, the C0-C2 indicators cycled, and the block number was displayed in the AC lights.

We tried several different parts of the diag, and everything worked correctly.

We booted P?S/8, set the date to 1/29/19 and ran the DATE command.

It printed the date and then HAPPY BIRTHDAY CHARLIE!

4/6/19

We tried to boot P?S8 but the DECtape rewinds and goes off the end of the tape, so there is probably a problem in the TC01 DECtape controller again.

Wiggling all of the FlipChips in the TC01 DECtape controller didn't make any improvement this time.

2/29/20

We learned a lot about DECtape controllers fixing the PDP-9, so it is time to fix this one

We loaded MAINDEC-08-DITCA TC01 Basic Exerciser

We ran test @201 Search Find All Blocks

The tape ran off the end while rewinding

The Up to Speed (US) indicator never turned on

I believe that this was the misbehavior that we observed last year

The US flip-flop in slot F29 is never going active

The output of the U+M Integrating One-Shot looks reasonable when running the register tests in the Basic Exerciser

The output of the RATE DY Integrating One-Shot is constantly triggering every 20uS, even with the processor stopped

I don't think that this is reasonable

I swapped the R303 flip-chip from slot E25 into slot E15, and the constant triggering stopped

I replaced a bad 2N3639 transistor Q6 on the R303 in slot E15

The US signal is now working and the tape stops in the end zone

3/1/20

We ran the rest of the tests in MAINDEC-08-DITCA TC01 Basic Exerciser 

Everything looks like it works OK

We loaded the MAINDEC-08-EUFB TC01 DECtape Formatter and formatted a bunch of tapes for the PDP-9

6/21/20

Powered it on just to make sure everything is working OK

Need to bring a printed listing of the P?S/8 TC01 bootstrap next time

3/13/21

We borrowed a G850 SCR driver flipchip from the upper TU55 drive to fix a TU55 in the PDP-9. We need to find a replacement or fix this one.

3/20/21

We replaced the now defective G850 SCR driver flipchip in the upper TU55 drive with one from the TU55 that Victor donated. Works OK now.

6/26/21

We tried to boot P?S/8 from DECtape, but it failed. It looks like there is a problem with the TC01 DECtape controller.

8/4/21

I toggled in a short program to copy the 8/I console switches to the TC01 Status Register A. This should let me move the DECtapes back and forth. Unfortunately the Status Register A contents on the TC01 display panel look like they are XORing or toggling instead of containing the contents of the 8/I AC register. By fiddling with the console switches I can get a DECtape to move forward, but not backward. The TC01 indicator lights show that the drive should be moving backwards.

I suspect that a Negibus strobe signal from the 8/I is misbehaving and causing the wrong data from the AC to be loaded into the TC01 Status Register A.

8/7/21

After thinking about the TC01 DECtape controller behavior, the XORing of the AC into the Status Register A may be correct.

Today we will investigate why we cannot command the DECtapes to move backwards. I think that the DECtape boot program moves the boot DECtape backwards into the End Zone, and then moves forward to read the first block into core memory. Not moving the DECtape backwards would prevent the OS from booting.

The signals in the TC01 for BMR0(0) and BMR0(1) that are used to make the FWD and REV signals for the DECtape drive are different. We need to explore the BMR0 flipflop on the S202 in slot C30 and C31 and the MR0 and MR1 flipflops on the S202 in slots E13 and E14. The MR1 flipflop always reflects the state of the BAC4(1) signal. The MR0 flipflop always toggles and does not correspond to the BAC3(1) signal. 

After looking at a lot of signals with the 'scope I finally realized that bit-3 of the status register is the direction bit, and bit-4 is the go/stop bit. I was programming the register incorrectly so the DECtape drive was not behaving as expected. Oh well.

I tried the TC01 bootstrap again with a P?S/8 DECtape. The tape rewound, but didn't stop at the end zone.

We loaded MAINDEC-08-D3BB-D TC01 Basic Exerciser and tried the Basic Motion Routine. The tape ran off the end of the reel, so it is not detecting the End Zone. Fixing that is the next project.

8/14/21

The serial console was misbehaving this morning. We found an almost broken wire in the Molex connector and repaired it.

We wasted a lot of time trying to get the terminal emulator on my laptop working with the DECtape diagnostic before we remembered that the PDP-8/I doesn't understand lower case letters.

We looked at the data from the Mark Track G882 FlipChip in slot C17. It is not self-oscillating and there is only data on the white-diamond output on pin U. That would really confuse the controller because there would be nothing from the Mark Track in the Window Register.

We substituted the G882 in C17 with the one in C16 and the Mark Track signals looked OK.

Time to repair the G882 that was in C17.

8/21/21

Last week we found that there was not data on pin U of the G882 Manchester reader/writer flipchip in slot C17. This flipchip has positive feedback in the amplifier so should self oscillate when there is no input signal. When there is an input signal the outputs synchronize with tape head data from the TU56 DECtape drive. The one in C17 handles the Mark Track data, so without both outputs working the TC01 DECtape controller could not determine what kind of data it was seeing from the DECtape.

The input/outputs for the reader section of the G882 are differential. The differential data from the DECtape head is less than 1mV and goes into pins D & E and comes out of pins U & V. In our case we see data coming out of pin V. That means that data is going into pin D, through Q7, Q8, Q11, and Q12. Data is going into pin E, but not out of pin U, so the problem is likely with Q6, Q9, Q10, or Q13. Much of the remaining devices like Q5, and lots of diodes and capacitors are shared between the two parts of the differential circuit, so they are likely working OK.

There is some corrosion on the component side of the PCB between the ground plane and through hole pads. We need to clean the corrosion off and try it again.

We found two spare G882 FlipChips in the wrong box in with the M FlipChips. One has already had a transistor replaced in the differential amplifier, the other one looks original. We installed the untouched one in slot C17 and it self-oscillates when the power is turned on.

We ran MAINDEC-08-D3BB TC01 Basic Exerciser, the Search Find All Blocks test. You could see the State indicated on the TC01 panel was mostly in the Data State, so the Mark Track was being decoded. It ran to the end of the tape and turned around, so the End Zone was detected. We ran the Read/Write data test with all eight patterns, and it worked without errors. That means that the TC01 DECtape controller, the TU55 DECtape drive, and the DECtape that we are using for the test are all working OK. We tried the lower drive with the same DECtape and saw a few errors. We will declare it fixed, and see if we can boot P?S/8.

P?S/8 would not boot using the standard OS/8 bootstrap code. There may be a special bootstrap, so I need to investigate.

DMS, the 4k Monitor booted and runs OK.

.PIP

*OPT-L

*IN-S:

FB=1755

NAME  TYPE    BLK

AF

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

.DDT.USER(0) 0022

CDE1.ASCII   0007

STAT.ASCII   0003

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

D801.BINARY  0004

D802.BINARY  0002

D803.BINARY  0001

D01A.BINARY  0004

D02A.BINARY  0003

D03A.BINARY  0001

D04B.BINARY  0003

D05A.BINARY  0003

D07A.BINARY  0004

D111.BINARY  0003

D112.BINARY  0003

D1L1.BINARY  0003

D1L2.BINARY  0001

D2AA.BINARY  0002

D2CA.BINARY  0002

D2BA.BINARY  0003

D1AA.BINARY  0001

D1CA.BINARY  0003

D1EC.BINARY  0003

D1GD.BINARY  0003

D3BB.BINARY  0003

D3BC.BINARY  0003

D3EB.BINARY  0003

D3RA.BINARY  0003

*OPT-L

1/19/22

In preparation for Charles Lasner's birthday we tried to boot his P?s/8 operating system. It read the OS from DECtape, printed the "." prompt, and then halted. We tried both TU55 drives, and two different TC01 bootstrap programs many times, but could not get P?S/8 to boot correctly. Maybe we need to make a new DECtape containing P?S/8?

We booted the 4k DEC monitor, and that seems to run OK. This means that the processor and DECtape subsystem are probably working OK.

2/8/23

We suspect that the lightening storm that damaged the PDP-9 also damaged the PDP-8/I.

We toggled in some diagnostics to see if the processor is working OK.

We can read and write memory. We toggled in a little program with several JMP instructions and they work. The CLA, CLL, CMA, CML, RAR, RAL, RTR, RTL, IAC, and HLT instructions work.

It looks like SZL and CML are not working. SNA, SPA, SMA, ISZ, SZA, HLT are working. Incrementing the AC in a loop works.
It looks like the DECtape boot program works and the DECtape controller does the right things.

The serial console is broken. There is no 20mA of current to close the selector magnet on the Teletype, and the input is always 377. We fixed two broken wires in the serial console cable, and now the input part works OK.

We looked at the TTO CLOCK signal on pin F07P2. It is a nice 220 Hz 3.5V square wave signal. We looked at the output of the LINE flip-flop on pin E02D2 of the M707 Teletype Transmitter board. It is nice 3.5V digital data that matches the ASCII character that was typed on the console. We looked at the output of the inverter on pin E02V2 of the M707 board. The signal matches the timing of the LINE(1) signal, but the fall time of the signal is about 40ms. I think that the fall time should be in the range of us, not ms. The signal LINE(0)\ on pin E02EV2 is open collector through a 120 Ohm resistor with the emitter connected to +5V from a DEC6534B transistor. I think that this should provide the 20mA needed to keep the selector magnet engaged. Since the selector magnet is not engaging, the problem might be on the W076 TTY interface board. We will work on the W076 FlipChip and the TTY interface on Saturday.

2/15/23

We checked the console wiring and found a broken wire that goes to the selector magnet. We repaired the wire and now the console works.

We booted the 4k Disk Monitor from DECtape. Yes the name is confusing, but the contents of the DECtape sectors and the disk sectors is exactly the same so the same 4k Monitor can be used with both devices. We loaded FOCAL 1969 and it ran correctly. Looks like this system is fixed again.

2/18/23

We booted the 4k Disk Monitor from DECtape. We listed one of the Fortran programs on the DECtape. We should enter a "Hello World" program written in Fortran, compile it, and run it.

3/29/23

We booted the 4k Disk Monitor from DECtape and ran FOCAL. It work OK.

6/13/23

We booted the 4k Disk Monitor from DECtape and ran FOCAL. It work OK.

6/17/23

We moved the PDP-8I to the new RICM Lab space. It will be interesting to see how much work it takes to get it running again.

6/28/23

We put a Hubbell 125V 30A Twistlock plug on the 8/I, just like it shipped from the factory. This is not a NEMA 5-30P, it is an older style of plug. The system powered up, and responds correctly to console button presses. We connected the Teletype, and the 20mA connection us working. We mounted a DECtape containing the 4k Monitor, set the address to 7600, presses LOAD ADDRESS, and START. The DECtape spun, and the 4k Monitor prompt printed on the Teletype. We loaded FOCAL, the best hardware test for a PDP-8. We entered a Plotting example from the FOCAL Programming Manual, and it ran OK.

It looks like the PDP-8/I survived the move to the new RICM Lab space.

10/4/23

The PDPi8/I has been working fine for many months. We used it today to test an ASR-33 Teletype and a VT-220 terminal. Both worked OK with the 4k Monitor. After it had been running for about 10 minutes it halted with all of the register lights on the console out. My guess is one of the power supplies has failed.

10/11/23

When we powered on the 8/I today there were a few lights lit on the console. Maybe our guess that the power supply failed was incorrect. We checked the +5V, -15V, and -30V outputs from the main 704 power supply in the 8/I. All of the outputs were within specification.

Examine, Deposit, and Load Address don't load the Switch Register contents into the Program Counter or Memory Address Register.

The CPU isn't getting anything from Core Memory, so it always sees and AND instruction. It will happily Single Step, Single Instruction, and RUN the AND instruction.

10/14/23

We spent some time reading the PDP-8/I Maintenance Manual so we have some idea of where to look for the faults. It looks like the console indicator lights are directly connected to the contents of the registers. That may mean that the registers contain nothing. We will try tracing the information flow from the switch register, through the Register Input Gating Network, the Adder, Register Output Gating Network, and finally to the Registers. There is sure to be a lot of random logic to control the data flow that needs to be tested.

We looked at schematic page 8I-0-27 section B3 to see where the LOAD ADDRESS switch signal came out of the W077 flipchip. The schematic says that the LOAD ADDRESS signal should be on pin B40 K2, but was actually on B40 L2. The schematic has pins K2 & L2 swapped. The L.A. signal goes low when the switch is pressed.

We looked at schematic page 8I-0-2 section C6 to see where the LOAD ADDRESS switch signal goes. This schematic page has the L.A. signal on B40 L2 and connecting to E11 A1. We verified that the L.A. signal was there. The signal goes through a NOR gate on an M113 flipchip and comes out on pin C1. The KEY LA signal is inverted at this time.  We looked at section A4 for the MFTP2 signal on pin F10 D2 that many switches will cause. We didn't see the MFTP2 signal. We looked at section A8. The KEY LA signal gets ORed with the START, EXAMINE, DEPOSIT, and CONTINUE signals by the M117 flipchip in F19 which gets connected to pin E10 S2 on the M700 flipchip in slot EF10. We didn't see the signal. We looked at  pin F19 J2 on the M117 flipchip and the signal was there. We looked again at E10 S2 and the signal was there going high. Must have been an oscilloscope operator error. We looked at pin E10 N2 for the MFTS 0# signal, and it was there going low. We looked at pin E10 T2 for the MFTP 0# signal, and it was not there. MFTP 0 is just an inverted and shaped MFTS 0# signal. We tried an untested NOS M700 flipchip, and there was no change in the behavior.

We ran the M700 on Warrens flipchip tester and can see both the MFTS 0# and the MFTP 0 signals. We also saw the MFTP 1, MFTP 2, MFTS 1, and MFTS 2 signals. Everything on the M700 looks like it is working OK. Maybe a bad connection on E10 backplane connector?

Next Wednesday we will check all of the signals to and from the M700 flipchip. We got a hint from Vince to look at the two destinations of the MFTP 0 signal; the M113 in slot F20 schematic page 8I-0-2 section A4, and the M617 in slot F30 schematic page 8I-0-2 section B5.

10/18/23

See schematic page 8I-0-2 section A8. Pressing LOAD ADDRESS causes the signal on E10S2 to go high, and the MFTS 0 signal on E10N2 to go low. There is 3 ms long 300 mV low-going pulse with a 17 ms repetition rate riding on the MFTS 0 signal when it is high. The same low-going pulse exists on the RESTART# signal on E10R2, on the RUN(0) signal on E10P2, and on E10S2 when it is high when LOAD ADDRESS is pressed. The low-going pulse is within the noise margin range for a high signal so it should not cause any problems. The RESTART# signal stays high when LOAD ADDRESS is pressed. While watching the signal on the 'scope the low-going noise stopped for about 15 seconds, and then changed to a high-going pulse.

We looked at the MFTS0 signal on E10M2 and the MFTP0 signal on E10T2. The MFTS 0 signal on E10M2 looks the same as the input signal to the M700 on pin E10S2. The MFTP 0 signal on pin E10 is always low. We checked the MFTP 1 signal on E10E2 and the MFTP 2 signal on E10D2. Both signals are always low. This makes sense if the MFTP 0 signal is always low.

We pulled the M113 in slot F20 and then the M617 in slot F30. When LOAD ADDRESS was pressed the MFTP 0 signal was always ground. We pulled the M700 from E10, the M113 from F20, and the M617 from F30. We measured the resistance from the MFTP 0 signal to ground, and it was infinite.

In the middle of testing the +5.0V power supply died and all of the front panel lights went out. This is similar to the original failure mode. We measured the +5.0V, -15V, and the +30V power supply output at the faston connectors on the Flexprint cable terminator. The +5.0V was +0.42V, and the -15V and -30V outputs were OK.

The +8.0Vcomes from a center-tapped transformer in the 704 power supply, through 1/2 of a DM2 bridge-rectifier, gets smoothed by a 160,000 uF capacitor, and then goes through a G813 regulator to make +5.0V. I don't think that we have a problem with the over-voltage circuit firing the SCR crowbar because the +5.0V circuit breaker is not tripping.

10/21/23

The +5.0V output is measuring -0.42V. The 8.0V input to the G183 measures 0V. The red output of the DM2 diode bridge measures 0V. The yellow input to the DM2 measures 0.0VAC on both leads. Looks like the diodes for the red output in the DM2 diode bridge died. We replaced the DM2 diode bridge and now the +5.0V power supply is working. We disconnected the power cable that connects the H704 power supply to the PDP-8/I chassis. The 5V measured 4.7V, the -15V measured -15.3V, and the -30V measured -32.2. The +5V should measure 5.0 +/- 5% (4.75V and 5.25V) for proper operation, so maybe the 4.7V output is OK.

We noticed that the ION light is on at power up, and does not go out when the START, STOP, or LOAD ADDRESS switches are pressed. After looking at the schematics we are not convinced that ION gets disabled at power on. We will ignore this for now.

We setup the 'scope to look at the M700 input on E10S2, the MFTS0#, MFTS0, and the MFTP0 signals. The input on pin E10S2 is ground and goes high. The MFTS0# signal on pin E10N2 is high and goes low. The MFTS0 signal on E10M2 is low and goes high. The MFTP0 signal on pin E10T2 is ground and stays at ground. We already tried removing the M113 in slot F20 and the M216 in slot F30 which are the only destinations of the MFTP0 signal that we know of.

We swapped the M700 with a new spare and the MFTP0 signal behavior was the same.

10/28/23

It is possible that something connected to the MFTP0 signal will not let the signal go high. We put a piece of Mylar tape on the gold finger for the M700 pin E10T2 to isolate it from any circuitry in the rest of the processor. We looked at the Input signal on pin E10S2, the MFTS0# signal on E10N2, and the MFTP1 signal on pin E10E2. We can see the input signal transition high and the MFTS0# signal transition low when LOAD ADDRESS is pressed, but the MFTP1 signal stays low. Time for a different method of debugging.

We previously tested this board in the FlipChip tester, and everything looked OK. Now we will look at the signals when the M700 FlipChip is on a W900C dual extender board to get a more realistic test. We looked at the output of the LOAD ADDRESS switch on pin E10S2. As expected this signal transitions from ground to 5V and back to ground many times when the switch is pressed. This is normal behavior for a mechanical switch. The filtering circuitry on pin E10S2 of the M700 FlipChip cleans this up, and about 80 ms later the MFTS0# signal cleanly transitions from 5V to ground. This causes the output of chip E4 on pin 3 to transition from ground to 5V. E4 pin 3 is capacitively connected to the input of E5 on pins 12 & 13. This input signal is pulled to ground by the 220 Ohm resistor R1 and spikes high when the output of E4 transitions high. The output of E4 goes to 2.5V within 10 ns, but then takes an additional 10 us to get to 5V. Maybe the pull-up transistor in E4 is weak? The input to E5 goes to almost 3V within 20 ns. The input needs to be above 2V to be a logic high. The output of E5 on pin 11 starts at 3.5V, goes to ground for 750 ns, goes to 2V, and 1 us later gets to 5V. The output of E5 should start closer to 5V. E4 pin 11 transitions to 3.5V for about 700 ns, and then back to ground. Maybe I missed the MFTP0 signal on the backplane because it is less than 1 us? Maybe there isn't a problem with the M700 and the 80 ms delay from switch to MFTS0# put the rest of the signals off the 'scope screen?

We triggered on MFTS0# going low, and we can see a 750 ns positive going pulse on MFTP0 with no delay. We can see a 100 ns positive going pulse on MFTP1 after a 1.7 us delay. The schematic says that this should be a 2 us delay. We can see a 100 ns positive going pulse on MFTP2 after a 3.5 us delay. The schematic says that this should be a 4 us delay. We see MFTS1(0) go low for about 1.8 us. We see MFTS1(1) go high for about 1.8 us. We can see MFTS2(0) go low for 1.5 us after a 1.7 us delay. We can see MFTS2(1) go high for 1.5 us after a 1.7 us delay. The MFTS0# signal goes low for 250 ms when LOAD ADDRESS is pressed. The MFTS3 signal looks the same as the MFTS0# signal but inverted. All of this looks OK. That explains why replacing the M700 Flipchip didn't make a difference.

Schematic sheet 8I-0-1 shows the logic flow for LOAD ADDRESS. It says that MFT0 puts a zero in MAJOR STATES, then MFT1 does nothing, then MFT2 copies the SWITCH REGISTER to the PROGRAM COUNTER. The 8/I maintenance manual says that MANUAL PRESET# is generated from the MFTP0 pulse. the MANUAL PRESET# signal pulses to ground at the start of the MFTS0# pulse for about 750 ns. Schematic page 8I-0-4 show how SR ENABLE gets generated. We can see this signal go high for 200 ms aft er LOAD ADDRESS is pressed. Schematic page 8I-0-6 shows how PC LOAD gets generated. We can see this signal go high for 100 ns about 3.2 us after LOAD ADDRES is pressed.

We looked at schematic page 8I-0-8 to see the PC register. A PC LOAD pulse coincident with data on the REG BUS should load the PC. We see the PC LOAD pulse on pin E34N2. We looked at REG BUS 00. Changing the positions of the SW REGISTER switches does not change the state of REG BUS 00. That makes sense for the problem that we see. On schematic page 8I-0-9 we can see SW 00 data on pin A40L2. Changing SW 00 changes the data. On pin F34C1 we can see SR ENABLE go high for 175 ms. That should gate the SR 00 data to the ADDER. We looked on pin E34E2 for the ADDER data. It was there, but a zero on the switch was a high on the signal. We looked for the NO SHIFT signal on E34E1 that gates the ADDER data to REG BUS 00. It is always active at 3.2V. That doesn't make sense, and the voltage is a little low. ADDER 01, 02, and 03 data are present and correspond to the SW REGISTER settings.

We looked at schematic page 8I-0-5 for the NO SHIFT signal on pin E31S1 it is always high at 3.2V. Pin E31N2 EAE LEFT# is low, and pin E31M2 SHIFT ENABLE# is is high. We don't have EAE implemented in this machine, so having EAE LEFT# active does not make sense. We should have been looking at pins E31P1 & E31R1 but may have stumbled onto a problem. DOUBLE RIGHT ROTATE on pin E31E1 is inactive. DOUBLE LEFT ROTATE on pin E31J2 is active. RIGHT SHIFT on pin E31L1 is active. LEFT SHIFT on pin E31P2 is active. NO SHIFT on pin E31S1 is active. AND ENABLE on pin E31V2 is is active. With all of those signals active the register gating logic must be really confused. We can test the M617 board with the Flipchip tester, and if it is OK start digging into the input signals to the M617 in slot E31.

11/1/23

We pulled the M617 FlipChip in slot E31 and ran it on the FlipChip tester. It failed and said that output AF2 should be a 1 and was a 2. This is actually an input and is pulled high by the 3V(40) source on the M617. Since this input is shorted low, none of the inputs pulled high by 3V(40) will go high, which would account for the signal conditions we observed. Our new replacement 7400 series parts got lost during the move to the new space so we used a NOS 1970 vintage Motorola DEC7440 chip from the DEC field service tool kit to replace E1 on the M617 FlipChip. The M617 FlipChip passed testing after the chip was replaced.

The 8/I booted the 4k Monitor that was left on core memory. We ran PIP and did a directory listing. That worked OK. We loaded FOCAL 1969. The FOCAL interpreter is one of the best tests of the processor. We compiled and ran a FORTRAN program. Since everything is running, the processor must be OK now. 

The indicator for bit-11 in the TC01 Data Buffer display was not working. The lamp was not installed correctly. It was a little fiddly to get it in the socket, and it works now.

There are some lamps on the front panel that are not working or are intermittent. Those are really painful to fix, so we will ignore them.

11/27/24

Grant repaired the G850 SCR Motor Controller FlipChip for the TU55 DECtape drive #2.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Diagnostic Tests Passed

MAINDEC-08-D01C Instruction Test 1, ran OK on 1/12/19

MAINDEC-08-D02B Instruction Test 2, ran OK on 1/12/19

MAINDEC-08-D04B Random JMP Test, ran OK on 4/22/17

MAINDEC-08-D05B Random JMP-JMS Test, ran OK on 4/22/17

MAINDEC-08-D07B Random ISZ test, ran OK on 4/22/17

MAINDEC-08-D1B1 Memory Address Test Low, ran OK on 4/22/17

MAINDEC-08-D1B2 Memory Address Test High, ran OK on 4/22/17

MAINDEC-08-D1L1 Memory Checkerboard Low, ran OK on 4/22/17

MAINDEC-08-D1L2 Memory Checkerboard High, ran OK on 4/22/17

MAINDEC-08-D3BB TC01 Basic Exerciser, ran OK on 8/21/21

MAINDEC-08-D3RA TC01 Random Exerciser, ran on 4/29/17

MAINDEC-08-DITCA TC01 Basic Exerciser, ran OK on 3/1/20

MAINDEC-8I-D02B Instruction Test 2, ran OK on 4/22/17

To Do:

Run the RIM versions of MAINDEC-8I-D01C, Instruction Test 1, and MAINDEC-8I-D02B, Instruction Test 2. (Done.)

Fix the RUN, PC6, and MB6 lights. (Done)

Swap the Panel lock and Power switches on the front panel. (Done)

Run the TC01 diags and see anything works correctly. (Done)

 Borrow an adjustable DC power supply to reform the capacitors on the 704A power supply. (Done.)

Bring a power modified cord so we can directly connect the 779 power supplies to a Variac. (Done.)

Reform the capacitors in all three power supplies. (Done.)

Disconnect the I/O and data-break cables from the processor. (Not necessary. The external buses are buffered.)

Bring an assortment of cleaning brushes to clean corrosion from the modules. (Done.)

Power up only the 704A power supply and see if anything works. (Done.)

Finish cleaning the modules in the CPU. (Done.)

Connect the AC to the 799 power supplies and see if there is any life in the controller and drives. (Done.)

Crimp a new faston connector the red wire at the top of the CPU cabinet. (Done.)

Find two Oshino OL-1 light bulbs. We could borrow them from the unused locations. (Replaced with CM7370 bulbs)

Test all of the processor Modules in the PDP-8/L system. (Done.)

Create a bootable DECtape containing the 4k monitor. (Done.)

Clean the modules in the TC01 and TU55s. (Needs to be completed.)

Fix the DTF indicator in the TC01.

Write boot and run instructions so others can use the system for demonstrations.

The boards repaired and replaced so far are:

 PDP-8/I Processor

G020 in slot A32 replaced with a spare from the parts 8/L, and replaced with a repaired and tested spare

G221 in slot C38 replaced with a spare from the parts 8/L

G221 in slot D38 7/8/17 replaced with a repaired and tested spare

G221 in slot X replaced with a repaired and tested spare

G228 in slot A37 repaired

G228 in slot B37 repaired. Replaced again.

G228 in slot ? replaced with a spare from the parts 8/L

G826 in slot AB2 replaced with a spare from the parts 8/L

3x M113 repaired.

M113 in slot E15 12/8/14 replaced with a                         repaired and tested spare.

M112 in slot E12 replaced with a repaired and tested spare

M115 in slot E14 replaced with a NOS one

M115 in slot E21 replaced with a spare from the parts 8/L

M115 in slot E25 replaced with a spare from the parts 8/L

M115 in slot F28 replaced with a NOS one

M117 in slot E11 replaced with a repaired and tested spare

M117 in slot F19 replaced with a NOS one

M117 in slot F23 borrowed from the 8/L. Will repair.

M117 in slot F27 replaced with a spare from the parts 8/L 

M160 in slot E30 1/10/15 replaced with a tested spare

M160 in slot E13 repaired

M160 in slot F33 repaired

M160 in slot E26 replaced with a repaired spare

M160 in slot E29 replaced with a repaired and tested spare

M216 in slot B22 Replaced with a repaired spare. 12/6/14 replaced with a repaired and tested spare where all three SN7474 ICs has been replaced.

M216 in slot D22 replaced with a spare from the parts 8/L

M216 in slot E19 replaced with a repaired spare from the parts 8/L

M216 in slot E20 replaced with a spare from the parts 8/L 

M220 in slot EF36 needs repair, temporarily replaced with a NOS one

M220 in slot EF37 replaced an SN7440 E11.

M220 in slot EF38  replaced with a repaired and tested spare.

M220 in slot EF39 12/27/14 replaced the SN7440 E7.

M220 in slot EF40 repaired

M221 in slot C32 replaced with a repaired and tested spare, and repaired again, and repaired again.

M221 in slot C33 replaced with a repaired and tested spare, and repaired again.

M221 in slot C38 replaced with a repaired and tested spare

M310 in slot A22 replaced with a spare from the parts 8/L 

M310 in slot E15 replaced with a spare from the parts 8/L 

M310 in slot F13 repaired

M310 in slot F14 replaced with a spare from the parts 8/L

M506 in slot J15 1/25/15 repaired by replacing Q1, a 2N3009B with one removed from another flip-chip

M617 in slot E31 replaced with a repaired and tested spare, 11/1/23

M617 in slot E32 replaced with a repaired and tested spare

3x M617 modules repaired

8x M651 modules repaired

M700 in slot EF10 replaced with a spare from the parts 8/L. 12/13/14 replaced all the ICs.

M706 in slot EF01 borrowed from the 8/L. Will repair.

M707 in slot EF02 replaced with a repaired and tested spare. Replaced again, and again, and again.

TC01 DECtape Controller

R201 Flip-Flop in slot DTD01 with a spare

S203 Flip-Flop in slot DTD25 2/21/15 replaced a 2N3639 transistor Q3 and a D662 diode

S203 Flip-Flop in slot DTD15 2/29/20 replaced a 2N3639 transistor Q8

TU55 #3

R303 in slot A04 with one borrowed from TU55 #4.

G850 in slot A12 repaired, 11/27/24