DEC PDP-12 Restoration

05/09/2015

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

Today's mission is to:

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

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

• Clean the processor cabinet (done)

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

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

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

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

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

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

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

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

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

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

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

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

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

• All of the LEFT and RIGHT SWITCHES work OK.

• The INST FIELD switches have no effect.

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

05/16/2015

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

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

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

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

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

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

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

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

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

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

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

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

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

05/16/2015

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

05/22/2015

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

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

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

05/23/2015

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

PDP-8 Works: IAC, RAL, RTL, CLL, CLA, LINC

PDP-8 Broken: CMA, CML, RAR, RTR, OSR

LINC Works: COM, ATR, RTA, RSW, LSW, PDP

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

05/25/2015

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

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

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

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

05/30/2015

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

06/06/2015

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

Loaded and ran:

MAINDEC-08-D04B-D Random JMP Test

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

MAINDEC-08-D07B-D Random ISZ test

MAINDEC-12-D0GA-A_Tape_Quickie

MAINDEC-8I-D02B-pb Instruction Test 2

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

07

F 1543 T 4660

O 2330 F 7747 R 7710 NS

F 1543 T 4660

O 2330 F 7750 R 7711 NS

F 1543 T 4660

O 2330 F 7751 R 7712 NS

F 1543 T 4660

O 2330 F 7752 R 7713 NS

F 1543 T 4660

O 2330 F 7753 R 7714 NS

F 1543 T 4660

O 2330 F 7754 R 7715 NS

F 1543 T 4660

O 2330 F 7755 R 7716 NS

F 1543 T 4660

O 2330 F 7756 R 7717 NS

F 1543 T 4660

O 2330 F 7757 R 7720 NS

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

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

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

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

A4053 C4052

A4173 C4073

A7400 C1275

A7401 C3273

A7402 C1276

A7403 C3303

A7404 C1273

A7405 C3673

A7406 C2273

A7407 C2303

A7410 C5204

A7411 C1275

A7412 C3273

A7413 C1276

A7414 C3303

A7415 C1673

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

06/11/2015

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

06/13/2015

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

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

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

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

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

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

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

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

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

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

06/18/2015

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

06/20/2015

Core stack serial numbers:

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

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

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

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

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

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

06/21/2015

A little explanation of tuning the core...

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

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

We successfully loaded and ran 10 passes of:

MAINDEC-08-D1B1 Memory Address test.

MAINDEC-08-D1B2 Memory Address test.

MAINDEC-08-D07B-D Random ISZ test.

We ran these diags without errors

MAINDEC-12-D0GA-A_Tape_Quickie

MAINDEC-12-D8AB Relay Register Test

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

06/27/2015

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MAINDEC-12-D1DA Memory Checkerboard, runs OK.

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

07/3/2015

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

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

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

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

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

We need documentation to figure this one out.

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

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

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

Probably a bad paper tape image.

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

07/4/2015

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

07/11/2015

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

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

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

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

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

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

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

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

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

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

That runs fine.

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

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

07/12/2015

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

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

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

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

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

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

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

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

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

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

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

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

07/18/2015

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

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

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

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

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

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

We ran MAINDEC-12-D3AE-PB PDP-12 TAPE CONTROL TEST, PART 1 OF 2.

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

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

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

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

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

We ran MAINDEC-12-D3FB-D_Tape_Data_Test.

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

07/23/2015

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

07/25/2015

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

07/27/2015

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

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

07/28/2015

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

08/01/2015

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

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

@4044 should be 2000 is 2000

@4045 should be 7777 is 7677

@4046 should be 0400 is 0400

@4047 should be 7770 is 7370

@4050 should be 7770 is 7770

@4051 should be 1024 is 1024

@4052 should be 0005 is 0005

@4053 should be 0010 is 0010

@4054 should be 4000 is 4000

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

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

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

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

LS=0702 RS=0000

DO, START 20

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

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

Ran OK.

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

Ran OK.

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

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

08/07/2015

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

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

This process was much easier than expected.

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

08/08/2015

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

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

08/09/2015

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

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

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

08/10/2015

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

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

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

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

08/10/2015

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

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

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

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

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

08/21/2015

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

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

08/28/2015 & 08/29/2015

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

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

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

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

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

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

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

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

Next Friday we will check all of these adjustments.

09/4/2015

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

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

We adjusted LTD TTOK from 47 to 48 us.

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

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

We adjusted the Mark Clock from 7.7 to 7.5 us.

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

09/14/2015

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

We ran MAINDEC-12-D3DB Tape Data Exerciser.

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

We ran MAINDEC-12-D3FB Tape Data Test.

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

09/25/2015 & 09/26/2015

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

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

10/02/2015

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

In the TU55:

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

• Pin A05M stays at -3.5V.

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

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

In the TU55:

• Pin A05V stays at -3.5V.

• Pin A05M stays at -3.5V.

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

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

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

LIST

NONE EDUCOMP BASIC V2.0

10 PRINT "HELLO WORLD"

20 END

READY

RUN

NONE EDUCOMP BASIC V2.0

HELLO WORLD

READY

^C

.DIR LTA0: /B/E

ABSLDR.SV 0070 5 20-SEP-74

CCL .SV 0075 17 02-NOV-74

FOTP .SV 0116 8 22-OCT-74

PIP .SV 0126 11 02-NOV-74

DIRECT.SV 0141 7 02-NOV-74

RESORC.SV 0150 10 20-SEP-74

BOOT .SV 0162 5 20-SEP-74

BUILD .SV 0167 33 02-NOV-74

HANGMN.SV 0230 8 25-OCT-74

SNOOPY.SV 0240 15 25-OCT-74

MOON .SV 0257 14 25-OCT-74

HANGMN.BN 0275 5 25-OCT-74

PING .SV 0302 8 25-OCT-74

HANGMN.WD 0312 2 25-OCT-74

CHESOV.PA 0314 17 25-OCT-74

CHESS .SV 0335 22 25-OCT-74

CHESS .BN 0363 21 25-OCT-74

CHESS8.SV 0410 17 25-OCT-74

DIALPS.SV 0431 21 25-OCT-74

CUBIC .SV 0456 8 25-OCT-74

KALEID.SV 0466 2 25-OCT-74

EDIT .SV 0470 10 18-JAN-74

MARK12.SV 0502 7

SOS .BN 0511 2 10-DEC-74

SOSDEF.PA 0513 2 10-DEC-74

BLINK .PA 0515 1 26-NOV-74

BLINK .BN 0516 1 26-NOV-74

EPIC .SV 0517 14 02-NOV-74

BASIC .SV 0535 73 02-NOV-74

TECO .SV 0646 12 02-NOV-74

PAL8 .SV 0662 16 02-NOV-74

EDU200.SV 0702 31 02-NOV-74

CREF .SV 0741 13 02-NOV-74

DESCR .TM 0756 2 02-NOV-74

TC12F .SV 0760 11 26-NOV-74

SSINST.WU 0773 6 10-DEC-74

SOS .PA 1001 14 10-DEC-74

MAGSPY.SV 1017 27 19-MAY-72

TEMP .TM 1052 73 07-NOV-71

FENWEL.FT 1163 2

<EMPTY> 1165 8

BTEMP .FT 1175 1 31-MAR-75

<EMPTY> 1176 3

ATEMP .FT 1201 1 31-MAR-75

<EMPTY> 1202 12

BETA .FT 1216 2 01-APR-75

<EMPTY> 1220 6

FENWAL.FT 1226 3 01-APR-75

<EMPTY> 1231 5

LINES .FT 1236 3 02-APR-75

TEMP .FT 1241 1 02-APR-75

<EMPTY> 1242 63

97 FREE BLOCKS

.RESOURC /E

46 FILES IN 584 BLOCKS USING 2 SEGMENTS

97 FREE BLOCKS (6 EMPTIES)

# NAME TYPE MODE SIZ BLK KIND U V ENT USER

01 SYS LINC RWF 737 SYS 0 A 07

02 DSK LINC RWF 737 16 1 A 11

03 LTA0 LINC RWF 737 16 0 A 10

04 LTA1 LINC RWF 737 16 1 A 11

05 LTA2 LINC RWF 737 16 2 A 12

06 LTA3 LINC RWF 737 16 3 A 13

07 TTY TTY RW 17+ KL8E C 176

10 TV VR12 W 20+ A 13

11 PTP 41 W 21 00

12 PTR 42 R 21 115

FREE DEVICE SLOTS: 05, FREE BLOCK SLOTS: 04

OS/8 V3

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

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

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

10/03/2015

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

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

10/09/2015

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

10/10/2015

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

10/12/2015

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

10/16/2015

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

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

10/23/2015

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

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

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

TEST PARAMETERS: 0

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

SR=6000

ERR FAT FAST EAC GOOD PASS

425 404 404 4 0 204 0

445 404 404 4 4 204 0

ERR FAT FAST EAC GOOD PASS

1440 1260 1401 4 4 204 0

1440 1260 1401 4 4 204 0

1440 1260 1401 4 4 204 0

1440 1260 1401 4 4 204 0

1440 1260 1401 4 4 204 0

1440 1260 1401 4 4 204 0

1440 1260 1401 4 4 204 0

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

11/12/2015

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

12/4/2015

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

12/11/2015

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

12/12/2015

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

We ran:

• MAINDEC-8I-D01C Instruction Test 1

  • Runs OK.

• MAINDEC-8I-D02B Instruction Test 2

  • Runs OK.

• MAINDEC-12-D0AB CP Test 2

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

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

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

  • We replaced the M168 with a NOS tested spare.

  • Runs OK.

• MAINDEC-12-D0CB CP Test 3

  • Halted @5242 with an unexpected interrupt.

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

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

  • Runs OK.

• Warren's Memory Tuning and Diagnostic program

  • • Field 0 and 1 both tested OK.

12/18/2015

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

MAINDEC-801-3A runs OK now.

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

We ran MAINDEC-12-D8CC-D_KW12A_Clock_Test.

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

12/19/2015

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

We reran MAINDEC-12-D8CC-D_KW12A_Clock_Test.

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

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

12/21/2015

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

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

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

12/22/2015

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

12/26/2015

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

12/28/2015

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

12/30/2015

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

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

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

We ran some more diags from paper tape.

MAINDEC-12-D0CB CP Test 3

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

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

1/2/2016

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

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

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

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

MAINDEC-08-D1EC Extended Memory Checkerboard

MAINDEC-08-D1GD Extended Memory Control, runs OK

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

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

MAINDEC-8I-DOAA INSTRUCTION TEST PART 3A, runs OK

MAINDEC-8I-DOBA EXT ARITH TST PART 3B, runs OK

MAINDEC-12-D1BA JMP Self, runs OK

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

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

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

1/9/2016

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

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

1/16/2016

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

1/23/2016

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

2/13/2016

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

2/20/2016

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

2/20/2016

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

3/12/2016

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

We started cleaning the RK05 Disk drive. The foam that seals the blower, and the foam that seals the air supply duct needs to be replaced. Self adhesive 1/4" and 1/2" weather strip from Home Depot will probably work fine. The 4.8V NiCad battery pack that will retract the heads if the power fails needs to be replaced. It looks like lots of R/C toys use the same battery pack, so it will be easy to get replacements.

3/19/2016

We found two sources for the emergency retract battery packs for the RK05 disk drive. I ordered a 4EP700AAH battery pack from Batteries America. We replaced the seal between the blower and the card cage, and for the disk pack with weatherstripping from Home Depot.

We ran MAINDEC-08-DHRKA-B RK8E Diskless Control Test on the RK05 controller.

It failed test 79 where it tried to do a data-break from memory location 7777. Repeated tries of test 79 all failed the same.

DATA BREAK ERROR

PC:3553 GD:0000 CM:4000 AD:7777 DT:0031

CR:007740 ST:2200 DB:0000 CM:4000 DA:0000

Tests 77 and 78 do a data-breaks from location 0000, and those worked OK. Tests 79 and 80 failed (address 7777), test 81 passed (address 0000), test 82 failed (address 7777). Maybe we one of the address bits use by the data-break is not being driven. We should be able to devise our own tests that try setting each address bit until we find the one that fails. We also noticed that relay K2 that activates the blower and voice coil in the RK05 drive started chattering after the drive was powered on for about 10 minutes. This may be due to lack of cooling because the seal between the blower and card cage is missing, or some other electronics problem.

3/26/2016

We continued debugging the RK8F data-break problem revealed when running MAINDEC-08-DHRKA-B RK8E Diskless Control Test. Last week's failure showed that we could data-break successfully to address 0000 but not to 7777. We suspected a problem in the 74161 or 8881 chips that make up the CA register and Omnibus drivers. From the prints we found that the IOT decoding is done on the M7104 board and the CA is on the M7105. We pulled the M7106 so we could get to the ICs on the M7105. We could see the data on the input pins of the 74161 chips, but no output. The LD signal that comes from the 6RK4 signal (IOT 6744) was active but the CLK signal was always high. After a consult with Warren we started chasing the CLK signal to the source. The IOT 6744 is ANDed with the IDLE signal and TP3. The IDLE signal was at 2V, so probably a bad 7474 flip-flop. Ah, the IDLE signal comes from the M7106 that we removed. We grounded the signal and could see the Omnibus MA signals go active. Unfortunately the upper four bits of the CA also come from the M7106 that we removed. We put the M7106 back in, put the diag in a scope loop, and looked at the Omnibus on the bottom of the wire-wrap backplane in the DW8E. All 12 bits of the CA were active, so the RK8F is probably OK. One thing that we noticed on the RK8F is that the MA signals on the 8881 chips are not gated like they are on an RK8E. Since there is only an RK8F in the Omnibus in the DW8E this works OK. We looked at the MA signals on the Posibus cables and found that one was inactive. The M7102 boards that drive the Omnibus MA signals onto the Posibus cables were previously tested in Warren's flip-chip tester, and one was repaired. We put the M7102 in slot AB20 on an extender and then all of the Posibus MA signals went active. The DHRKA diag also passed, so everything in the RK8F and DW8E is now working. We cleaned the gold contacts on all of the DW8E boards with a white eraser and 91% alcohol, reassembled the DW8E chassis, and the DHRKA diag still worked OK. We bought a new NiCd battery pack and weather strip for the RK05, so cleaning the drive, replacing the battery pack and weather strip will be next week's project.

There seems to be a power supply problem in the RK05 because the relay K2 that activates the blower and voice coil in the RK05 drive chatters after the drive is powered on for about 10 minutes. We need to debug the power supply problem too.

4/2/2016

More work on the RK05 disk drive today. This is an older design drive that has a rectangular HEPA filter without the outlet duct. We replaced the dried out foam seals for the blower motor and the cartridge air duct.

The all of the power supply voltages were low. We adjusted the +5 to +5.15, the -15 to -15.75, but could not adjust the +15 to +15.75. After the drive was powered on for a bout 5 minutes the K2 relay started chattering. The +15 supply voltage was changing from about +14 to +16V. Our guess is that the DC OK signal is going inactive and turning off the K2 relay, the the voltage is OK and the K2 relay turns back on. Our next project will be to debug and repair the +15V power supply.

4/16/2016

We had a Board of Directors meeting today, so not much time to debug the RK05. We had a box of RK05 parts in the warehouse, including a complete H743 power supply. Since the +15V power supply activates the relays, and the K1 Safety Relay was chattering, we started there. We removed the "8 to 20V" regulator that was used for +15V from the spare power supply, and connected it to a 30V lab supply and a 1A load. The regulator worked OK and we adjusted the output to 15.15V. We replaced the +15V regulator in the RK05 drive with the tested spare. The drive powered up OK, but the K1 relay started chattering after a few minutes. This time the -15V supply was low, so maybe I didn't take such good notes last week. We put the original +15 regulator back in the RK05, and did the same procedure with the -15V regulator. The drive again powered up OK, but the K1 relay started chattering after a few minutes. The -15V was low, so there is a problem on one of the interface boards, the Motor Relay board, or the Power Amplifier board. I also noticed that the voice coil was oscillating when S1 was in the down position. This should have deactivated the Power Amplifier output. It is possible that a problem with Q2 or Q4 on the Power Amplifier is causing excess current on the -15V regulator. The emergency retract batteries leaked and caused some oxidation on the heat sink for Q3 and Q4. Maybe this has damaged some of the Power Amplifier components. Next week I can unplug P7 on the power harness and see if the -15V regulator works OK.

4/23/2016

More work on the RK05 disk drive today. We disconnected the wire harness from the P7 connector on the servo power amp and powered up the drive. The +/- 15V stayed within spec, and the K1 relay did not chatter. Looks like we have a problem with the servo power amp. We turned set switch SW1 on the servo power amp to the down position. Instead of deactivating the head servo the heads oscillated. We replaced the servo power amp with a spare, and now it behaves reasonably. With the drive powered up, and a finger on the cartridge seated microswitch, we set RUN/LOAD switch to the RUN position, and the spindle did not turn on. We checked the HOME L signal at pin B06F1. It was low with the carriage retracted and high with the carriage out a little. We looked at the INTERLOCK L signal on pin A06R1. It was always high. One of the DEC documents warns that the wiring for the DOOR LOCKED and CARTRIDGE SEATED switches can be a problem. We disconnected the harness from connector J2 on the control panel. The resistance between pins 1 & 4 should be low with the door locked and the cartridge in place, but it was always high. The resistance across the harness and door locked microswitch was low with the door closed and locked. This is as expected. The resistance across the harness and cartridge present microswitch was high with the cartridge in place or not. This is not as expected. We removed the microswitch and confirmed that it was defective. Since we did not have a spare we shot some contact cleaner into the switch and operated it many times. That restored it to operation and now the INTERLOCK L signal worked as expected. We cleaned dust off the disk surface and tried to spin up the drive.

The spindle motor would not turn on. Grounding pin A04N1 on the M7701 Control and Interlock module caused the motor to turn on, so we knew that was OK. The HOME L, LOAD SW, RUN SW, and INTERLOCK L signals to the M7701 all looked OK. We put the M7701 on an extender an looked at pins 9, 10, & 11 of E12. Pins 9 & 10 were high, but pin 11 was low. Pin A04D1 was low indicating a DC LOW L state. Pins 1 & 2 of E2 were high and 3 was low, so the 75451 was probably shorted. Fortunately at this point I remembered that the RK05 was cabled to the RK8F controller, and the PDP-12 was not powered on. Powering on the PDP-12 caused the DC LOW L signal to go high and the spindle motor turned on. We manually loaded the heads, and didn't hear any bad noises. We set SW1 on the servo power amp to the up position, the heads went to track 0, and the RDY and ON CYL lights went on. Just to push our luck we entered the instructions 6743 and 5031 at locations 30 & 31, and started the processor. This should have read the boot block from sector 0, head 0, track 0, disk 0 into memory location 0 in field 0. The boot block overlays the JMP instruction at location 31, and loads the operating system. It didn't boot from the disk, so something in the hardware is still broken, or there is no boot block on the device. Oh well, time to run the rest of the RK8E controller diags, this time with the disk drive connected.

5/21/2016

The boot program for LAPS-DIAL and OS/8 is the same, but LAPS-dial goes at 20/21 and OS/8 goes at 30/31. Neither will boot the system. I found some example programs in the 8/e maintenance manuals to do a drive Recalibrate, and a drive Seek. The Recalibrate works OK, but the seek causes the head to slowly move beyond cylinder 203 and recalibrate. I tried several difference cylinder addresses, 31 and lower do not seek, 32 and higher seek beyond cylinder 203 and recalibrate. The RK05 maintenance manual has jumper settings to make the drive seek 2/4/64/100/105/202 cylinders. I installed the jumpers for a 2 cylinder seek and the head goes beyond cylinder 203 and recalibrates. These jumpers work OK on my RK05 at home. So, it looks like we have a problem with the M7702 Cylinder Address and Difference board in the RK05 drive. I will take the digital logic boards home and test them in my drive.

5/28/2016

After talking to "experts" we checked all of the signals from the position transducer in the RK05 disk drive. On the M7702, the INNER LIMIT signal on 02AU1 and the OUTER LIMIT signal on 02AK1 both work OK. On the G938, the CHASSIS SIN POSITION signal on 05AN1, and the CHASSIS -COS POSITION signal on 05AU1 are both present and about 150mV PtoP. The SIN POSITION signal on 05AM1, and the inverted SIN POSITION signal on 05AL1 are both present and about 10V PtoP and are centered about ground. The -COS POSITION signal on 05AS1 and the inverted -COS POSITION signal on 05AR1 are both present and about 10V PtoP and are centered about ground. The sum of the SIN POSITION and -COS POSITION signals feed into pin 2 of the comparator E4 and there is a corresponding square wave on E4 pin 6.

The upper channel is pin 2 on the LM301A comparator E4 on the G938 module, the lower channel is pin 6. On the G938, the sum of the SIN POSITION and inverted -COS POSITION signals feed into pin 2 of the comparator E3 and there is no output on E3 pin 6. So it looks like the LM301 comparator E3 is defective. We will replace the chip this week, and the SN7004 chip that it feeds.

6/4/2016

On the G938 in the RK05 disk we replaced the LM301 comparator E3 the SN7004 inverter E1. The sum of the SIN POSITION and -COS POSITION signals feed into pin 2 of the comparator E4 and there is a corresponding square wave on TP6. The sum of the SIN POSITION and inverted -COS POSITION signals feed into pin 2 of the comparator E3 and there is a corresponding square wave on TP7. So, it looks like replacing the two chips fixed the problem that we found last week.

The COUNT PULSE FWD H signal on pin AA1, the COUNT PULSE REV H signal on AC1, the OUTER LIMIT H signal on AD1, and the INNER LIMIT H signal on AB1 all work OK. We adjusted the SIN, -COS, CHASSIS LIMIT, and VELOCITY gain and offset. For a quick test, we put jumpers on the drive signals to make it seek between two cylinders. You can see in the video that it actually works!

We tried to boot the PDP-12 from the disk using the OS/8 and LAPS-DIAL boot procedures, but the processor halted. It looks like the boot block just contains the pattern 2525-5252. Maybe the disk pack was never configured to boot, or someone ran diagnostics on the pack and wiped the contents. We ran the seek part of the MAINDEC-08-DHRKB-D-D RK8E Drive Control Test. It didn't work and we had the drive covers on so we could not see what it was doing.

We reran two passes of MAINDEC-08-DHRKA-B RK8E Diskless Control Test to make sure that the RK8-F controller was OK.

It ran OK, so back to the disk tests. I wrote some simple tests for the RK8-F and RK05. It will recalibrate and seek to a desired cylinder, so the controller is talking to the disk. Next week we will make an backup image of the RK05 disk pack using the dumprest program, and then put a bootable image of OS/8 on the pack.

6/11/2016

We ran MAINDEC-08-DHRKB-G-D RK8E Drive Control Test using one of Mike's disk packs.

It failed with:

DISK DATA ERROR

PC:3571 GD:4156 ST:4001 CM:0001 DA:4156 CA:7177 AD:7200 DT:4155

We reformatted the pack with MAINDEC-08-DHRKD-D-D RK8E-RK8L Disk Formatter Program.

We reran MAINDEC-08-DHRKB-G-D RK8E Drive Control Test.

This time we saw:

RK8E DRIVE CONTROL TEST PASS COMPLETE

We tried using the dumprest programs to make an image of the RK05 pack that came with the PDP-12, but it died complaining about an unexpected interrupt. I will make an image of the existing pack, and then make a bootable OS/8 pack using my 8/e. Hopefully this will boot on the PDP-12. We would also like to make a bootable OS/8 diskette that will run in just the 8k of core on this system.

6/15/16

Using dumprest, I made an image of the RK05 disk pack from the PDP-12 using my PDP-8/e. Unfortunately there was nothing on the pack other than a 5252-2525 pattern. This pattern was probably left from running the disk diagnostics. Using os8diskserver, I made a bootable OS/8 RK05 disk pack for the PDP-12 on my PDP-8/e. I limited the core memory usage to 8k to match the amount of core in the PDP-12. The 8k configuration still runs OK my my 8/e, so hopefully it will boot and run on the PDP-12 next Saturday. We should copy the PDP-12 diagnostics onto this pack. There are a few PDP-8 RK05 disk packs in the warehouse. We should make images of them, and then try to make a bootable LAPS-DIAL disk pack for the PDP-12.

6/20/16

I found an RK05 alignment pack in the warehouse. It needs to be cleaned, but should let us check the alignment of the heads on the PDP-12 and on the PDP-8/e.

6/25/16

SerialDisk is not working properly on the second serial port. The OS/8 handler was modified by another enthusiast so it would run on other then a PDP-8/e, but it looks like it still needs debugging. It is also possible that there is a configuration problem with the second serial port on the PDP-12, so we need to test that too. OS/8 booted from the RK05 disk pack that I made in my PDP-8/e! OS/8 says that I didn't put the CCL.SV file on the pack, so running it is a little more difficult than normal. I did get DIRECT to run and CCL.SV is on the pack. Well, running OS/8 was fun for a while, and then the servo in the RK05 disk died. It behaved like there was no power to the servo amplifier. After being shut off while we got lunch, it worked again. OS/8 was a little flakey and would periodically print SYS ERR and halt. With switch S1 on the Servo Power Amp on or off I can easily move the heads. The voltage at pin BU2 of the G938 Head Position Servo Preamp is always about 15mV so the power amp is not being told to move the heads. The COUNT PULSE FWD H and COUNT PULSE REV H signals look OK so the SIN and COS signals from the position indicator are working. The ON CYL light is always on, even if I move the heads. Our current guess is that there is a problem with the M7702 PACK CYL ADDR AND DIFF module and the CURRENT ADDRESS REGISTER always contains zero. It looked like it was getting read errors, so maybe the alignment on my RK05 is different than this drive.

I formatted the pack on the PDP-12 drive and then ran the RK8-E Controller Test, MAINDEC-08-DHRKB-G.

RK8E DRIVE CONTROL TEST

TEST (Y=YES OR N=NO):

DISK0?y DISK1?n DISK2?n DISK3?n

RK8E DRIVE CONTROL TEST

TEST (Y=YES OR N=NO):

DISK0?Y DISK1?N DISK2?N DISK3?N

STATUS REGISTER ERROR

PC:0257 GD:4000 ST:2400 CM:0200

During the week I will reconstruct the OS/8 pack using my PDP-8/e, but using the pack formatted on the PDP-12.

7/2/16

Last week we formatted the RK05 disk pack on the PDP-12 in case there was any alignment differences with the drive on the PDP-8/e. Using my PDP-8/e I put OS/8 on the PDP-12 disk pack, and configured it for running on the PDP-12. The PDP-12 disk decided to work this morning. I will run it until the drive dies again, and then debug the drive. OS/8 booted OK, but CCL is not working. Commands like DIR and COPY don't work, but DIRECT and PIP work OK. It periodically hangs with the processor running, but nothing displayed in the AC and MB lights. Maybe a data-break problem? The serial disk handler is working OK, but a little slow over a 9600 baud serial connection.

I was able to PIP a text file to the TV, the VR14 display!

.DIR

SYSTEM ERR

.COPY

SYSTEM ERR

.RUN SYS BUILD

$PR

KL8E: *TTY

PT8E: PTP *PTR

RK8E: *SYS *RKA0 *RKB0

SDIS: *SDA0 *SDB0 *SDA1 *SDB1 SDA2 SDB2 SDA3 SDB3

RX01: *RXA0 *RXA1

LNC : *LTA0 *LTA1 LTA2 LTA3 LTA4 LTA5 LTA6 LTA7

BAT : BAT

VR12: *TV

DSK=RK8E:SYS

CORE= 1

.RUN SDA0:RESORC.SV

*/E

103 FILES IN 1428 BLOCKS USING 3 SEGMENTS

1764 FREE BLOCKS (3 EMPTIES)

# NAME TYPE MODE SIZ BLK KIND U V ENT USER

01 SYS RK8E RWF 3248 SYS 0 C 07

02 DSK RK8E RWF 3248 SYS 0 C 07

03 TTY TTY RW 16+ KL8E E 176

04 PTR PTR R 17 PT8E A 112

05 RKA0 RK8E RWF 3248 SYS 0 C 07

06 RKB0 RK8E RWF 3248 SYS 1 C 21

07 T4 64 RWF 20 E 53

10 TDA0 64 RWF 20 E 52

11 T5 64 RWF 20 E 51

12 TDA1 64 RWF 20 E 50

13 RXA0 RX8E RWF 494 21 E 30

14 RXA1 RX8E RWF 494 21 E 34

15 LTA0 LINC RWF 737 22 0 A 10

16 LTA1 LINC RWF 737 22 1 A 11

17 TV VR12 W 23+ A 13

FREE DEVICE SLOTS: NONE, FREE BLOCK SLOTS: 02

OS/8 V3Q

*

After running OK for several hours the RK05 disk drive finally died again. Now we can debug it and fix it permanently. After a lot of signal tracing it looks like the problem was a loose connection on TB2-5 where the POWER AMP DR signal goes from the harness on the M983 module to the harness on the H743 power supply. CCL is working now, so maybe we were getting seek errors on the disk before we fixed the loose wire. The serial disks are no longer working, Maybe the baud rate generator is getting out of specification after running for a while?

It looks like we have an intermittent data-break problem. Running the RESORC.SV program will cause the processor to hang with the "B" (data-break) light on and none of the MB or AC lights on.

Just to make sure that the processor is still OK I reran:

• MAINDEC-8I-D01C Instruction Test 1

• MAINDEC-8I-D02B Instruction Test 2

During the week I will make bootable OS/8 floppy disks and give them a try next week. Next week I will rerun the MAINDEC-08-DHRKA-B RK8E Diskless Control Test to make sure that data-break from the RK8-E disk controller ow working OK.

7/3/16

I booted the OS/8 pack from the PDP-12 on my PDP-8/e. The RESORC program had the same bad behavior. I replaced the program with one from a serial disk image, and now the program works OK. I will look for good demonstration programs for the PDP-12 and put them in the disk pack.

7/9/16

I booted OS/8 from the RK05 disk pack. It works much better after reconstruction.

.RESOURC/E

138 FILES IN 2390 BLOCKS USING 4 SEGMENTS

802 FREE BLOCKS

# NAME TYPE MODE SIZ BLK KIND U V ENT USER

01 SYS RK8E RWF 3248 SYS 0 C 07

02 DSK RK8E RWF 3248 SYS 0 C 07

03 TTY TTY RW 16+ KL8E E 176

04 PTR PTR R 17 PT8E A 112

05 RKA0 RK8E RWF 3248 SYS 0 C 07

06 RKB0 RK8E RWF 3248 SYS 1 C 21

07 T4 64 RWF 20 E 53

10 TDA0 64 RWF 20 E 52

11 T5 64 RWF 20 E 51

12 TDA1 64 RWF 20 E 50

13 RXA0 RX8E RWF 494 21 E 30

14 RXA1 RX8E RWF 494 21 E 34

15 LTA0 LINC RWF 737 22 0 A 10

16 LTA1 LINC RWF 737 22 1 A 11

17 TV VR12 W 23+ A 13

FREE DEVICE SLOTS: NONE, FREE BLOCK SLOTS: 02

OS/8 V3Q

I made a bootable OS/8 diskette configured for the PDP-12, and it works OK.

Well, that didn't last long. It looks like we have some more problems to debug when running from the RK05 disk.

.DIR RXA0:

SYSTEM ERR

.RESORC/E

SYSTEM ERR

It does boot and run OS/8 from the floppy disk drive.

.R BOOT/RX

.DIR

CCL .SV 18 BUILD .SV 33 RESEQ .BA 6 MUSIC4.MU 14

PIP .SV 11 FOCL69.SV 17 TRIAL .BI 2 MUSIC1.MU 11

BOOT .SV 5 BASIC .AF 4 BOOT .PA 21 MUSIC6.MU 13

RESORC.SV 10 BASIC .SF 4 MUSIC .SV 9 JCOOK2.MU 8

DIRECT.SV 7 BASIC .FF 4 MUSIC5.MU 4 FIFTH3.MU 37

TECO .SV 22 BASIC .UF 4 USA .MU 3 JCOOK1.MU 7

BASIC .SV 9 BCOMP .SV 17 BABYEL.MU 11 FIFTH1.MU 43

TRIAL .BA 1 BLOAD .SV 8 MUSIC2.MU 14 MINUET.MU 17

SCALE .MU 1 BRTS .SV 15 MUSIC3.MU 14 YANKEE.MU 3

11 FREE BLOCKS

I ran the MUSIC program, but could not detect any music with an AM radio near the front of the system. I will try it again with the radio at the back of the cabinet.

After running for about 4 hours the RK05 drive servo died again. I manually unloaded the heads,removed the pack, wiggled the same wire on TB2-5, and the drive is working again. Next week I will remove the faston connectors and treat them with corrosion inhibitor.

We ran the Kaleidoscope program from a paper tape image so we could show it to some visitors.

Trying to list a directory of an OS/8 LINCtape yields the same shoeshine tape behavior that we have seen before. At least the LINCtape handler in OS/8 is working, even if the LINCtape drive/controller is not.

We discussed how to get the SKYLARK and KALIED programs to load and run from diskette. These are mixed PDP-8 and LINC programs, so it will take some experimentation to get it working.

7/17/16

During the week I modified the OS/8 BOOT program to support Kyle's serialdisk. It works on my PDP-8/e, but I need to try it on the PDP-12. Charles made an OS/8 version of KALEID that we need to try on the PDP-12. The RX01 floppies are working OK. I used it to transfer an modified version of the BOOT program to the RK05 disk. This version includes BOOT /SD to boot from the serial disk. OS/8 BASIC runs OK from the RK05 disk. FOCAL-69 and FOCAL-71 does not run from disk. I tried several FOCAL-69 paper tapes, and they all end up running in instruction field 2 with the MA and PC counting. This may indicate that there are still hardware problems to fix. The DP12-B second serial port won't reliably talk to the serialdisk server after the system has been running for a few hours. I am looking at the wiring of the serial cable, and found a broken wire, probably the RTS. The signal on the brown wire goes high when the PDP-12 is turned on, so hopefully this is the CTS or READER RUN signal. The plan is to monitor the serial signals when the system is cold and warm to see if the baud rate changes.

DB-9 Pin Function Color W076x Pin

2 Receive Green J

3 Transmit Red H

5 Ground White VV

8 CTS Brown V

Shield Silver B

RS-232 Yellow E-M This signal puts the W076 in RS-232 mode.

N/C Black DD

The READER RUN signal is translated to CTS on the serial cable and is working correctly. The bits look like they are 100us for both transmit and receive, about right for 9600 baud. The bits from my laptop are +/- 5V. The bits from the PDP-12 are +/- 7V. The baud rate and the serial transmit/receive signals look OK. I reduced the FIFOs on the Expresscard serial port to 1 character, but there was no improvement. I swapped the built in serial port for the Expresscard serial port, but there was no improvement. Lowering the baud rate to 4800 did not help either. I need to connect my laptop to my PDP-8/e and verify that the serialdisk server really works OK. This is the output from the serial disk server when doing a DIR SDA0:, then DIR SDA1:, then DIR SDB0:, then DIR SDB1:. It looks like the serialdisk server is getting the wrong request information from the PDP-12. This could be a problem in the OS/8 serialdisk handler, the serial hardware, or the serialdisk server on my laptop. I swapped the M706 and M707 boards for the first and second serial ports in the PDP-12, and the serial signals look OK on a 'scope. I think that we can eliminate the PDP-12 hardware from the possible problems. The OS/8 serialdisk handler is not fully debugged on non-PDP-8/e systems, so that could be the problem. During the week I will try using my laptop as the serialdisk server with my PDP-8/e just to make sure that it works OK.

C:\pdp8\software\SerialDisk\>newserver -1 ../disks/os8v3q_160405.rk05 -2 ../disks/os8v3q_sources1.rk05 -3 ../disks/os8v3q_sources2.rk05

PDP-8 Disk Server for OS/8, v1.2

Using first disk ../disks/os8v3q_160405.rk05 with read enabled and write enabled

Using second disk ../disks/os8v3q_sources1.rk05 with read enabled and write enabled

Using third disk ../disks/os8v3q_sources2.rk05 with read enabled and write enabled

Using serial port /dev/ttyS0 at 9600 with 2 stop bits

Request to read 32 pages from side 0 on first disk

Buffer address 00000, starting block 00000

Warning: client asking to overwrite OS/8 resident page!

Failed to initialize, sending NACK

Request to read 24 pages from side 0 on second disk

Buffer address 60020, starting block 03400

Successfully completed read

Request to read 12 pages from side 1 on first disk

Buffer address 03600, starting block 00001

Successfully completed read

Request to read 24 pages from side 1 on second disk

Buffer address 60020, starting block 03400

Successfully completed read

Warren will visit next weekend, so we will have an opportunity to work on the LINCtapes again.

7/21/16

I tried using my laptop as the serialdisk server with my PDP-8/e, and it works just fine at 38,400 baud. So, either there is still a hardware problem in the PDP-12, or there is a software problem in the serialdisk handler when run on the PDP-12. I can enable the debugging messages in the serialdisk server, and maybe put some halts in the non-system serialdisk handler to debug the problem.

7/23/16

Warren is back for the weekend, so we will do a three day debugging marathon. We connected a terminal emulator to the second serial port, entered a port echo program, and send a stream of characters to the PDP-12. About 99% of the time the characters were echoed back correctly, but sometimes three characters in a row were bit shifted. We swapped the M706 & M707 boards that make the receiver and transmitter of the second serial port with the boards from the first serial port. The misbehavior was the same, so the problem is in the baud rate generator or in the W076x RS-232 board. We will investigate this later.

Back to the TC12 controller problems. We looked at the signals from the G882 module that converts the low level differential signal from the DECtape heads to negative logic levels. We used maintenance mode instructions to move the tape and keep the TC12 idle. On pin U2 of the G882 in slot F09 we could periodically see short data pulses from data track 3. The data pulses should always be more than 16uS. We pulled the W032 module that is on the end of the TU56 data cable from slot EF06. Warren made a test harness to plug onto the W032 and directly connect the differential head data signals to the pins of the G882 slots. We still saw short pulses from data track 3.

We pulled the G882 module from slot F09. Warren made a test harness to plug onto the G882 and directly connect the differential head data signals and the negative logic signals to the backplane. We still saw short pulses from data track 3. We looked at the V2 output of the G882 from slot F09, and saw non-monotonic signals. The non-monotonic signals are likely below the threshold of the W603 board that converts the negative logic signals to TTL signals. This shows that the wiring in the backplane is likely OK, and we have problems elsewhere. This also eliminated the write data from the possible causes of the problem, because the signals were not connected.

7/24/16

We verified that we have a problem either in the home-made baud rate generator or the RS-232 converter board for the second serial port. We know a lot of parts in the TC12 that are not part of the problem. We will do some more investigation tomorrow, especially in the TU56 tape drive.

7/25/16

Our third day of the PDP-12 marathon debugging session. The D0(0) coil in the left tape head is open, so both heads in this TU56 have failed with open coils. We now need three TU56 heads to put everything we have back together. We found a bad or very out of adjustment M302 in the TU56 that was causing braking and turnaround problems with the right drive. We swapped it with a M302 from another TU56 and it is behaving much better. We were actually able to boot OS/8 from the RK05 and write files onto the TU56. This is major progress. OS/8 and LAPS would not boot from tape, but tried very hard. Hopefully it will take just some adjustments to get the drive working correctly now. Next weekend I will run through the TU56 adjustments, including what is mentioned in the Tech Notes.

7/30/16

We got delayed by some new donations. There is always time to look at Unibus core memory boards an about one hundred RT-11 and RSX-11M diskettes. An interesting observation: The serialdisk works find when I booted and ran from the floppy. It fails when running from the RK05 hard disk. Charles Lasner wrote an adapter program that lets us load LINC programs from OS/8. We combined PSTART.BN with KALEID.BN to make KALEID.SV and can now run the LINC KALEIDOSCOPE program from OS/8. This is a real convenience for demonstrating the system. The LINCtapes are working better, so I spent some time copying games from a LINCtape to the RK05 disk.

8/6/16

The RK05 disk drive is not working today, so that will be our debugging project for the day. It periodically pushes the heads out to track 0, but immediately retracts them. It was the same problem with a bad connection at TB2-5 where the POWER AMP DR signal goes from the harness on the M983 module to the harness on the H743 power supply. I removed the faston connectors and squeezed them a little, soaked everything with DEOXIT, wiggled them a lot of times, and it works again.

This is what the input voltage to the servo amplifier looks like when it is doing a seek. The negative voltage pushes the heads out towards the hub. When it gets within 32 cylinders of the target cylinder it starts moving one track at a time. When it gets to the target track it uses a little voltage to hold the head in position. I copied some games and other programs from an RK05 image to an RX01 diskette, and tried them on the PDP-12. SPCWAR runs and has lots of options for command input from the console terminal, but I don't know how to play it. LIFE halts the processor.

MOON displays a space ship and the surface of the moon on the VR14 monitor. Knob 1 controls the fuel burn rate, knob 4 controls the attitude of the rocket. It goes BOOM if you land too hard.

TANK displays two tanks and some obstacles on the VT14 display. The tanks make little sparkles when they blow up, but then reappear.

Right 2 up Tank 1 drive backwards

Right 2 down Tank 1 drive forwards

Right 3 up Tank 2 normal

Right 3 down Tank 1 steer left

Right 4 up Tank 2 normal

Right 4 down Tank 1 steer right

Right 5 up Tank 1 fire cannon

Right 8 up Tank 2 drive backwards

Right 8 down Tank 2 drive forwards

Right 9 up Tank 2 normal

Right 9 down Tank 2 steer right

Right 10 up Tank 2 normal position

Right 10 down Tank 2 steer left

Right 11 up Tank 2 fire cannon

The SCROLL editor displays a prompt on the VR14 display. I need to read the manual to see how this works. DIAL16 runs and displays a "*". It is supposed to read DIAL LINCtapes and convert the source code files to a format that can be used with OS/8.

Charles Lasner modified the serial disk handlers and put them on an RK05 image. Unfortunately the serial disk is misbehaving, so I will have to put the files on a floppy disk.

8/13/16

It is 81F and 83% humidity outside, and very comfortable in our lab space. ;-) I put Charles Lasner's updated serialdisk handlers on a floppy disk so I can install them on the PDP-12 today. I also remembered to bring some of Charles LINCtapes so I can see if the PDP-12 will read them. The serialdisk is still showing problems, so there is likely a hardware problem. We need to write loopback diagnostics that send characters to the PDP-12, have them sent back, and check to see that all of the bits are the same.

I tried to read some of Charles' LINCtapes.

DEC-12-OSYSA-A-U0, OS/12 System LINCtape No. 1

.DIR LTA0:

FAL2 .PA 57 SWPARM.PA 25 TECPRT.TE 1 NIP .SV 28

CLOCK .PA 39 TLK .PA 22 MC .TE 1 GEN .TE 6

RK8E .PA 16 LISTEN.PA 14 ME .TE 1 IFT .TE 3

CCB .PA 14 RX01NS.PA 20 STRIP .TE 1 LOAD13.BI 1

NIPARM.PA 17 RX01SY.PA 27 MAKGEN.TE 1 COMP .PL 3

DUMMY .PA 3 NULL8A.PA 3 MF .TE 1 PQS .TX 2

PWRF .PA 14 TALKN .PA 4 MAZDP5.PA 29 FORM .TX 1

MAZFAK.PA 1 SWAP .PA 20 LPT .PA 10 COMP .TE 11

OS8COM.PA 1 LISTN .PA 3 WARNEW.SV 52 FORM .TE 3

MCR .PA 61 MIR .PA 16 OS8SUP.PA 84 QL1 .PL 4

PARAM .PA 25 EDIT .TE 3 STAT .PA 44 PQS .TE 4

XRP1 .PA 26 PRT .TE 1

7 FREE BLOCKS

This tape looks like it has DECnet for the PDP-8.

We were able to boot DIAL from a LINCtape.

8/20/16

I checked the motor speed clock in the TU56 tape drive. I adjusted the clock from 41kHz to 40kHz which will slow the drive down a little. I also adjusted the braking time from 80 ms to 100 ms which improved the turnaround behavior. I tried reading some of Charles' LINCtapes and some that came with the PDP-12. If I put my thumb on the feed (right) reel the tape would seek correctly for a long time. Otherwise it would stop every few seconds, shoeshine, and then seek again. I speculated that putting my thumb on the tape reel was slowing down the drive. I adjusted the motor clock all the way down to 36kHz, but didn't see an improvement. I put the motor clock back to 40kHz. I tried pressing on the tape near the head while it was seeking, but could not find a position that improved the seek behavior.

8/27/16

Warren suggested that I measure the timing track frequency when I have my thumb on the reel to see just how much I slow down the drive. I can then adjust the motor clock to create the same timing track frequency. If I can get the LINCtape to behave reliably at the slower speed, I can then try controller adjustments and slowly increase the motor clock frequency. We may find that the factory adjustments don't work for this system. Charles Lasner modified the Moon Lander source so it will go back to OS/8 with a ^C. We assembled it from his source with PAL12, and it works OK.

9/3/16

I am running through the TC12 LINCtape controller Maintenance procedure in the DEC-12-HPMPA-A-D_PDP-12_PM_Procedures_Feb73.pdf document.

Adjust the Mark Clock.

Measure the output of the M401 module on pin D21 D2. It should be exactly 7.5 us. Increased from 7.468 to 7.52 us. The trimpot on the M401 is extremely sensitive, so it is difficult to adjust the timing accurately.

LTD TTOK Delay

Measure the output of the M307 module on pin C28 E2. It should measure 48 +/-4us. The procedure is misleading. We really need to trigger on pin E2 going high and measure the time before that K2 went low. Increased from 45us to 48us. There were lots of signals on C28 K2 even when the LINCtape controller was idle.

LTD XTLK Delay

Measure the output of the M307 module on pin C28 F2. It should measure 7 +/-1us, but the hand written notes say to adjust it to 9us. The procedure is misleading. We really need to trigger on pin U1 or S1 going high and measure the time before that F2 went low. Increased from 5.5us to 9us. There were lots of signals on C28 F2 even when the LINCtape controller was idle.

LTD ACIP Delay

Measure the output of the M307 module on pin C30 E2. It should measure 180 +/-20us. The procedure is misleading. We really need to trigger on pin K2 or J2 going high and measure the time before that F2 went low. Increased from 150us to 180us. There were lots of signals on C30 F2 even when the LINCtape controller was idle.

OS/8 booted from the RK05 and ran fine so we could demonstrate MOON and TANK to some visitors.

The LINCtape doesn't behave much better after the adjustments.

A directory from the OS/8 LINCtape:

.DIR LTA0:

ABSLDR.SV 5 PING .SV 8 SOSDEF.PA 2 SSINST.WU 6

CCL .SV 17 HANGMN.WD 2 BLINK .PA 1 SOS .PA 14

FOTP .SV 8 CHESOV.PA 17 BLINK .BN 1 MAGSPY.SV 27

PIP .SV 11 CHESS .SV 22 EPIC .SV 14 TEMP .TM 73

DIRECT.SV 7 CHESS .BN 21 BASIC .SV 73 FENWEL.FT 2

RESORC.SV 10 CHESS8.SV 17 TECO .SV 12 BTEMP .FT 1

BOOT .SV 5 DIALPS.SV 21 PAL8 .SV 16 ATEMP .FT 1

BUILD .SV 33 CUBIC .SV 8 EDU200.SV 31 BETA .FT 2

HANGMN.SV 8 KALEID.SV 2 CREF .SV 13 FENWAL.FT 3

SNOOPY.SV 15 EDIT .SV 10 DESCR .TM 2 LINES .FT 3

MOON .SV 14 MARK12.SV 7 TC12F .SV 11 TEMP .FT 1

HANGMN.BN 5 SOS .BN 2

97 FREE BLOCKS

9/10/16

Lots of visitors today, so the PDP-12 got a real workout running hangman, kaleidoscope, tank, and moon lander. We downloaded a copy of Spacewar from: http://www.chdickman.com/pdp8/VC8/ We assembled it on the PDP-12 using PAL12. It runs, you see a small flicker on the VR14, and then nothing. It is in 8-Mode, and the interrupts are enabled.

I halted the processor and it is at 5503.

I single-stepped it through a loop at 5501, 5502, 5503.

/NOW TO DISPLAY IT

05464 1045 WARDIS, TAD DBUFP

05465 7041 CIA

05466 1375 TAD (DISBUF

05467 6002 IOF /NO INTS IN LINC MODE

05470 3273 DCA WARDX /FOR DISPLAY ROUTINE

05471 1362 TAD (DISBUF-1

05472 4473 DISPLAY

05473 0000 WARDX, 0

4507 D1=DSUN

4506 D2=DSTARS

05474 4507 DSUN /DISPLAY THE UNIVERSE OR SUN

05475 6001 ION

05476 2307 ISZ STOVER /DELAY FOR AUTO RESTART

05477 7410 SKP

05500 5761' JMP SPCWAR /START OVER

IFNZRO FCLOCK+KW12+AX08+DK8EA+DK8EP <

05501 1306 TAD WAIT

05502 7650 SNA CLA

05503 5301 JMP .-2

05504 3306 DCA WAIT>

05505 5202 JMP WAR

00001 *1

00001 5777' JMP INTRPT

00177 6002

/COME HERE FROM INTERRUPT

06000 0000 SAVAC, 0

06001 0000 SAVLK, 0

06002 3200 INTRPT, DCA SAVAC /SAVE ACCUMULATOR

06003 7010 RAR

06004 3201 DCA SAVLK /AND LINK

06005 6031 KSF /KEYBOARD?

06006 5212 JMP .+4

06007 6036 KRB /READ THE CHAR

06010 3220 DCA ICHAR /STORE

06011 5640 JMP I OPTIONS

06012 6041 TSF /TELEPRINTER

06013 5222 JMP CLKINT /NO CHECK CLOCK

06014 6042 TCF /CLEAR THAT FLAG

06015 3217 DCA TELSW /SET NOT IN PROGRESS SWITCH

06016 5640 JMP I OPTIONS

06017 0000 TELSW, 0

06020 0000 ICHAR, 0

06021 0000 DELAY1, 0

CLKINT,

06022 6131 CLSK /SKIP IF CLOCK

06023 5227 JMP INTEXT /QUIT (UNDEFINED INT?)

06024 6135 CLSA /CLEAR THE FLAGS

06025 7240 STA /AND SET WAITING

06026 3777' DCA WAIT

06027 6402 INTEXT, 6402 /LINK

06030 6412 6412

IFNZRO T30G <6161;NOP>

06031 7300 CLA CLL

06032 1201 TAD SAVLK /GET LINK

06033 7104 RAL CLL

06034 1200 TAD SAVAC /AND AC.

06035 6244 RMF /RESTORE FIELDS

06036 6001 ION /AND RESTOR INTERRUPTS

06037 5400 JMP I 0 /RETURN TO PROGRAM

I put a NOP instruction at 05503 and now the game runs. The action is way too fast to be able to control the space ships. The code that I disabled was probably slowing it down to a reasonable speed. It is interesting that the PDP-12 is running too fast...

Spacewar was originally written for the DEC PDP-1 in the early 60s. Over the years it has been improved, modified, and adapted to run on many other computers, including our PDP-12. This version of Spacewar is quite a bit different from the original PDP-1 version, and also different from the SKYLARK program that RCS/RI runs on their PDP-12 (that is me on the right). In the image above you can see one of the space ships on the left shooting rockets near the sun in the center. The gravitational field of the sun changes the path of the rockets. An adept player can use the gravitational field of the sun to slingshot his ship or hit the competitor's ship on the opposite side of the sun.

Next week we will run the KW12 and KW12A diagnostics to make sure that the Programmable Real Time Clock is working correctly. It is also possible that ECO #55 that was applied to the KW12A in this system has changed the clock's behavior so that it is incompatible with this version of Spacewar. If so, we will modify the source code so that it will work correctly with our system.

9/17/16

We ran the MAINDEC-12-D8CD KW12A Clock Test to make sure that the KW12A clock is working OK.

With error halt disabled we found these faults:

TST34 O'FLO FAILED TO SET O'FLO FLOP

TST41 O'FLO FLAG WON'T CLEAR

TST42 CLOCK INTR WON'T CLEAR

TST55 RATE 400KC FAILS

TST56 RATE 100KC FAILS

TST57 RATE 10KC FAILS

TST58 RATE 1KC FAILS

TST58 RATE 100CPS FAILS

TST60 CHAN 1 INPUT LOCKED OUT

TST72 CHAN 1 INPUT LINE FREQ FAILED

TST86 FAST SAM NOT CLEARED

TST87 CHAN 1 WON'T TRANS CNT TO BUF

TST90 CHAN 1 WON'T TRANS CNT TO BUF

So it looks like the KW12A clock is broken. We replaced the M216 flip-chip in slot F19, This module contains the Overflow flip-flop. This was a previously repaired module where we only replaced one of the three SN7474 ICs. Next time we will replace all three SN7474 ICs because we see so many failures of this part. Once the KW12A was fixed, Star Wars worked just fine, and at a much more reasonable playing speed We looked through the Space War code and found a menu of options that can be entered on the console. Turning on the Star Field, and displaying Ships instead of UFOs makes the display look like the older versions of this game.

9/24/16

During the week we looked at the source code for Space War with the intent on fixing the problem with listing the game options. I got the problem with the mangled listing fixed, and didn't break the game.

OPTIONS ARE DESIGNATED BY FIRST CHARACTER

THE NUMBER IN PARENS ARE "NORMAL" VALUES

NUMBERS ARE OCTAL

AVAILABLE OPTIONS ARE:

A ANGULAR MOMENTUM

B BOUNCE ON

C CURVED SPACE

F FIELD OF STARS

G RESET GRAVITY CONSTANT(1000)

N NON-ANGULAR MOMENTUM

M MAX NUMBER MISSLES:

P PHLAT SPACE

R RETRO-THRUST (4):

S DISPLAY SHIPS

T THRUST CONSTANT (2):

U DISPLAY UFO'S

V VELOCITY INITIAL OF MISSLES(2000):

W WRAP-AROUND ON

Z POLARIS ONLY

I sent a copy of the program source and binary to the LCM so they can try it on their PDP-12.

10/8/16

We took a week off the restoration effort to demonstrate 120 year old steam engines at the at the NEWSM Steam-Up.

The only parts of this system that do not work correctly are the LINCtapes, and the second serial port. The LINCtapes have been a persistent, very challenging problem, so we will save that for last. Earlier we used a terminal emulator to send a stream of ASCII characters to the serial port, and had the PDP-12 send them back. Most of the time it worked OK, but there were often errors in the received characters. Today we will write a Windows program to send data to the serial port and verify the data that is sent back by the PDP-12. The Windows program writes bytes from 0..255, the PDP-12 sends the character back, and the received character is compared to the sent character. The program has been running for several minutes without an error. I forced an error by clearing the the AC in the PDP-12, and the Windows program detected the error. I added a random number generator and send a series of random characters to the serial port. Of course it works fine. So now it is back to testing the SerialDisk handler in OS/8 to see what is misbehaving. If I try to list the directory on a serial disk it consistently asks for the wrong blocks to be transferred into non-existent memory. I will do some research during the week and develop a debugging plan.

C:\FAQ\DEC\pdp8\software\os8\SerialDisk\server>os8disk -1 ../disks/pdp8-12.rk05

-2 ../disks/diagpack2.rk05

PDP-8 Disk Server for OS/8, v1.0

Using system disk ../disks/pdp8-12.rk05 with read enabled and write enabled

Using second disk ../disks/diagpack2.rk05 with read enabled and write enabled

Using serial port /dev/ttyS1 at 9600 with 2 stop bits

Request to read 32 pages to side 0 on system disk

Buffer address 23400, starting block 07666

Warning: client asking to write past disk boundary!

Failed to initialize, sending NACK

11/5/16

My day job took me to Germany for a few weeks, but now I am back and ready to debug the serialdisk issues. I wrestled with Cygwin for a few hours and eventually got it to recompile the serial disk server. I reassembled SDSKNS.PA, the serial disk non-system handler. Entering "DIR SDA0:" at the OS/8 prompt..

Resulted in these messages from the serialdisk server...

Client sent signal A

Function: 0020

Buffer: 3400

Block: 7666

Request to read 32 pages from side 0 on first disk

Buffer address 23400, starting block 07666

Warning: client asking to write past disk boundary!

Sending 6221

Sending 0000

Failed to initialize, sending NACK

Sending 2002

The PDP-12 halted at 10173. The core location 10173 contains 7522, a type 2 operate instruction with too many bits on. This doesn't look reasonable. Next week I will put a HALT instruction in the serialdisk handler and see what it is trying to send to the serialdisk server.

11/10/16

From the tests last week we can see that the Buffer Address is in non-existent core, and the Block Address is off the end of the disk. This handler works fine on my PDP-8/e, but not on the PDP-12. The instruction set in the PDP-8/e is a little different from the PDP-12, but the handler should work OK on the PDP-12. I added a HLT instruction to the serialdisk non-system handler, just before it sends the first character to the server. This will let me see the parameters that were sent to the handler by OS/8, and see what the handler sends to the server.

I created a bootable floppy disk with the modified handler for testing. Entering "DIR SDA0:" caused the PDP-12 to halt at 6676 in instruction field 0 with the data field set to 1, at the HLT instruction that I added. The serialdisk handler was loaded at 6400 in field 0. It looks like I can single-step the processor and everything works OK. At full speed the handler gets the wrong data from OS/8. With some more debugging I can see that the pointer to the OS/8 data block is stored at 06761 in the serialdisk handler. When the handler is working correctly the pointer is 2210 in field 1. When it is not working correctly the pointer is 2360 in field 1. When the pointer is wrong the handler does the wrong thing. If I change the OS/8 data block pointer from 2360 to 2210 the serial disk handler works OK

11/12/16

I have more debugging ideas from the Kyle, the serialdisk author, and other OS/8 experts. They asked: OS/8 SYSTEM VERSION 3Q I moved the HLT instruction to the entry point of the serialdisk handler. This lets me see the pointer to the OS/8 disk request block before the handler manipulates it. The experts also reminded me that the PDP-12 has processor hardware for debugging that will let me halt the processor when it accesses or executes a core address. Because of this debugging hardware I really don't need the HLT instruction in the serialdisk handler. I did need the HLT instruction to find out where the handler was getting loaded, but don't need it now. It looks like I can do a "DIR SDA0:" to list the directory of the first serialdisk, then change the contents of 6761 from 2360 60 2210, and it works OK. I can then repeat the command many times and the OS/8 data block pointer at 6761 is always the correct 2210. If I do a "DIR SDB0:" to list the directory of the second serialdisk, it fails because the OS/8 data block pointer at 6761 is always the wrong 2360. After doing a "DIR SDB0:, then doing a "DIR SDA0:" has the OS/8 data block pointer at 6761 the wrong 2360. I added another HLT earlier in the program so I could see the calling address in OS/8 for the handler. When I do a "DIR SDA0:" the calling address is 2210. When I do a "DIR SDB0:" the calling address is 2361. I don't think that the 2361 calling address is correct, so the problem is in OS/8.

11/19/16

Lots of visitors today, so lots of time spent running Space War and Lunar Lander. Spacewar gives the PDP-12 a good workout, even better than the DEC diagnostics. We need to make button boxes for playing Spacewar so we don't wear out the switches on the front panel. Charles Lasner found the problem in Kyle Owen's OS/8 slave serialdisk handler. The original serialdisk handler was written for the PDP-8/e. The IOT instruction decoding for the serial port hardware in the PDP-12 works differently than that in the PDP-8/e. This caused the contents of the AC register to be incorrect after a serial IOT instruction was excuted, and caused the handler to fail. Charles sent us an updated version of the slave serialdisk handler, and it works perfectly.

12/3/16

We started debugging the updated OS/8 system serialdisk handler. We used BUILD to install the updated system handler onto an RK05 disk image, and then tried to boot from the disk image. Unfortunately it failed to boot OS/8 from the serialdisk, so we have more debugging to do. When we get this debugged it will be possible to run OS/8 on a Classic PDP-8, PDP-8/I, PDP-8/L, or PDP-12 with two serial ports and no disks or DECtapes.

12/9/16

The serialdisk system handler worked fine on my PDP-8/e, and I was able to boot from the serialdisk with my 8/e. I tried the same image on the PDP-12, and it almost works... It failed to boot from the serialdisk, but a restart at 7605 finished the boot.

PDP-8 Disk Server for OS/8, v1.2.1

Using first disk ../disks/Mike_PDP-12.rk05 with read enabled and write enabled

Using second disk ../disks/SCRATCH.rk05 with read enabled and write enabled

Using serial port /dev/ttyS1 at 9600 with 2 stop bits

Client sent signal A

Disk: 1

Side: 0

Function: 1000

Buffer: 0000

Block: 0007

Pages: 0010

CDF: 6201

Field: 0000

Request to read 8 pages from side 0 on first disk

Buffer address 00000, starting block 00007

Sending 6201

Sending 6000

Sending 4000

Sending 0000

Sent done acknowledgment

Successfully completed read

A DIR command sends the command to SDD0: instead of SDA0:

Client sent signal D

Received special device code 1

Disk: 2

Side: 1

Function: 3071

Buffer: 4171

Block: 5370

Pages: 0030

CDF: 6271

Field: 0007

Request to read 24 pages from side 1 on second disk

Buffer address 74171, starting block 05370

Sending 6271

Sending 2000

Sending 4000

Serial write failure

: Permission denied

C:\FAQ\DEC\pdp8\software\os8\SerialDisk\server>pause

Press any key to continue . . .

I will do some more debugging tomorrow.

12/10/16

I sent Charles Lasner the debugging information and the RK05 disk image that I was using. He quickly pointed out that the revision of the OS/8 system handler was not the latest. I updated the system handler on the serialdisk image, but still have problems. I will update the serialdisk image on my PDP-8/e and try it again.

We had lots of visitors today. I did well playing Spacewar and tank, but it was embarrassing watching a 10 year old land the rocket on the moon on his first try.

12/17/16

Alex and I are making a LTSPICE model of the G882 Manchester Reader Writer module. This is the module that takes the data from the TU56 LINCtape read/write head, amplifies it, and turns it into a digital signal. The module is a very clever design and will take a lot of experiments to fully understand. Next week we will disconnect the writer part of the G882 module in slot F09 to see if that is causing the noise on data track 3. If not, then we will look at noise being coupled into the output of the G882 module, and power and ground noise. If we can fix this noise problem, the LINCtapes will probably work OK.

I built an OS/8 RK05 disk image using SerialDisk on my PDP-8/e and use the image to boot the PDP-12. It booted OK, and worked fine. I used BUILD to rewrite the OS and bootloader on the RK05 disk image using SerialDisk on the PDP-12. It didn't complete the process and would not boot from the RK05 image. I replaced the RK05 image with the one built on my PDP-8/e and the PDP-12 again worked OK. So, it looks like running BUILD on the PDP-12 using the SerialDisk system handler does not work quite right yet. Charles Lasner has a copy of the original and damaged RK05 images and is helping with the debugging.

12/19/16

Alex and I worked on the LTSPICE model of the G882 model and discussed how to approach debugging the LINCtape drives. We reviewed the logic analyzer data from the TC12 that Warren captured.

12/20/16

Alex finished most of the LTSPICE model of the G882 Manchester Reader Writer module. It turns out that the last stage is a peak-detector, not a level-detector. (It says that in some of the manuals but I didn't notice.) We will post a theory of operation document and the LTSPICE model of the G882 when it is complete. We discussed the debugging plan. Previously we swapped the TU56 and I/O cable for a (known good) TU55 and I/O cable and it made no difference.

So, it is unlikely that the data track 3 noise problem is on the input signal. The likely suspects are noise on any of the 6 voltages, noise on ground, and noise coupled into the output signal. We can disconnect R5 and R15 on the G882 module to isolate the Writer circuitry from the Reader circuitry. We can pull the W603 module in slot F16 to isolate the peak-detector from the tape controller, and then look at the amplified head data. We can also pull the R107 inverter and the W512 level shifter to isolate the tape controller from the write circuit.

TC12/TU56 Debugging information:

• • The head coil resistance is 2-3 Ohms, the bad head had one coil at 400 Ohms.

  • The voltage from the head during a read is 10-12mV

  • The data rate is 33.3us per slice on the tape

  • The turnaround time for the tape drive is 200ms

  • The data pulses should always be longer than 15us (minus some tolerance)

  • The G882 input impedance is 400 Ohms

  • The G882 output is 180ma at 15V

We ran these MAINDECs to make sure that the controller was OK.

• • MAINDEC-12-D0GA Tape Quickie

  • MAINDEC-12-D3AE Tape Control Test Part 1 of 2, Tests tape control logic and inter register transfers

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

We ran MARK12 and successfully formatted a 896 (1600) block tape. (That has not worked in a long time.)

We ran MAINDEC-12-D3DB Tape Data Exerciser starting at 0201. It ran for 45 minutes without an error, so we decided that the drive and controller were working OK with a tape that we formatted. We tried doing a Read Block with some of the LINCtapes that came with the system. They all failed to work correctly. Doing a Read Block with the LINCtape that we just formatted works fine. Head skew?

We booted OS/8 from the RK05 disk, ZEROed the LINCtape that we formatted today, and tried to write some files on it. It failed with a kernel error. Looks like we have some OS/8 software issues to deal with.

12/21/16

We ran MAINDECs to make sure that the controller was OK.

• • MAINDEC-12-D3FB Tape Data Test

It ran OK for a long time, and then hung doing a Move Toward Block. We shut they system off for lunch, and tried again when we came back. When the system was cold it exhibited the shoeshine behavior when reading a specific block.

We ran MAINDECs to make sure that the controller was OK.

• • MAINDEC-12-D7CD System Exerciser, ran for a while and displayed "ERROR"

M-12-D7CD

PASS TIME PC GOOD BAD FIELD

0630 0362 3072 2072 0

This is a LINCtape error.

It looks like it was doing a seek to a block above 512 and hung.

We ran MAINDECs to make sure that the controller was OK.

• • MAINDEC-12-DAEXA-A-PB_System_Exerciser_(replaces_D7CD)

This is the newer system exerciser.

The switch settings were 0110 7701.

These settings disable the KW12A because we didn't a special cable needed for the test.

This one also moved the tape about half way through and then the tape stopped.

M-12-DAEXA-A

PASS TIME PC GOOD BAD FIELD

0362 0362 3723 2342 0

12/22/16

It looks like I managed to damage the contents of the first partition on the RK05 disk drive. I booted the system from the RX01 diskette and reconstructed the partition using a serialdisk RK05 image. Fortunately I had saved a copy of BUILD tailored for the PDP-12, so getting the system to boot from the RK05 was easy.

I bought a paper tape of the DECUS program ORGAN-AA. It runs, and lets you type letters and numbers on the console terminal to make sounds on the speaker. There is another version, ORGAN-BB, that will let you play a file containing the music.

We studied the behavior of the G882 Manchester Reader/Writer with the LTSPICE simulator some more. The Center Tap connection from the head to the G882 is not needed when reading tapes. The gain in the three stage amplifier in the G882 is so high that it will easily work with a read signal that is 10% of the normal voltage. This lets the LINCtapes work with a very large dropout on one track. The Center Tap connection is needed to write on the tapes because the write current goes from ground, through the head, and through the G882 to -15V. The tape head signals that we need to see measure the skew are pins A-D and A-C of the head cable. We connected the 'scope to TU56 slot 12 pins AD2-AH2 and AD2-AJ2 to look at those head signals. We used the PDP-8 maintenance instructions to move the tape, and tried to look for the signal from the head on the TU56 backplane. We couldn't see see the 10mV head signal inside of the 25mV of noise on the signals. The 25mV of noise is at a very high frequency compared to the tape data. Next time we will disconnect the head cable from the relay board and see if there is less noise.

12/24/16

Back to discussing how the G882 module works, and what the read head signals should look like. We soldered some short wires onto a relay board so we could connect the 'scope probes to the head signals. With the head signals floating and connected to my 'scope with isolated inputs there is lots of high frequency noise on the 'scope. Grounding the Skew Check signal to the cabinet significantly reduced the noise. We also had to turn of the flourscent lights to reduce the noise on the 'scope. On the LINCtape that we formatted we could see a few uS of skew. We tried several other LINCtapes and saw up 10uS of skew. We will use one of the tapes written by DEC for a standard and fiddle with the head position to see if we can reduce the skew.

It looks like there is a about 5uS of skew on the TU56 head that we replaced, so we will need to adjust it to less than 1uS. There are also a lot pulses of RF noise mixed with the head signal that makes it difficult for the 'scope to trigger on the head signal. We tried turning off PCs, WiFi routers, fluorescent lights but there was no improvement. We also tried lots of combinations of grounding the shield and 'scope probe grounds, but did not see much improvement.

12/26/16

I found my foil strips for marking BOT and EOT on 9-track tapes sitting on top of one of the TU45 tape drives at home. These very thin aluminum foil strips are use to adjust the head skew in TU55 and TU56 tape heads. We found a sticker in the TU56 that said that the factory head skew was 0.5uS for both heads. We will use a loose TU56 dead that has open MARK coils to see if we can find and minimize the RF noise. We will go through the head skew adjustment procedure to minimize the head skew. This may not be possible because the head signal will only be about 1mV when the tape is oxide side up. We may need to make the head signal amplifier that is described in the DEC TU55/TU56 manuals. We will use a modern Op-Amp instead of the one in the ancient DEC manuals.

For use in the Lab space we may need to add a low-pass filter to the amplifier so we only amplify the head signals and eliminate the RF noise. We tried following the procedure in the DEC Field Service Tech Manual for minimizing the head skew. When we flipped the tape over so the oxide side was up, the tape head signal level was so low we could not see it. We will try using a pair of G888 modules borrowed from a TC11 controller as amplifiers, and see if we can see the tape head signal.

12/28/16

I tried the same tape head signal measurement on the TU56 on my PDP-8/e. There was also a lot of digital noise on the head signal. I tried an ancient analog Tektronix 'scope, but it was too slow to capture the head signals.

I brought the G888 modules from my TC08 to the lab so we can use them to amplify the head signals. We made a test setup to feed a 30kHz 5mV signal into the G888 and looked at the output of the first Op-Amp and the 7400 gate. We saw a gain of 100x in the first Op-Amp on pin H, and typically saw a 50% duty cycle square wave on pins U & V. We adjusted the trimpot R7 to make the square wave on pins U & V as close to 50% as we could. One of the G888 modules needed about 5 turns on on R7 to make a 50% duty cycle.

We wired in one Op-Amp on two G888 modules and now we have enough gain and filtering to get good 'scope images with the tape oxide-side up. The head signal input is about 5mV when performing the skew adjustment with the oxide layer down. The square wave output is stable with an input signal as low as 1mV, which is what we will see when the tape is turned over. We also noticed significant filtering of the high speed noise in the lab environment by the Op-Amp. It looks like we have about 5uS of tape head skew. The DEC standard setup (and these drives when they shipped from DEC) was about 0.5uS of skew. We also ran a LINCtape written on another system and saw a similar amount of skew. Looks like we learn how to shim a head next. We have some timing track jitter that is from mechanical issues. We need to move the tape hubs out about 0.010" to fix that.

12/31/16

We added a wire to the G888 modules in the test setup so we can connect the 'scope to the output of the second MC1709 Op-Amp on the G888 modules. This will supply additional amplification and filtering of the head signals.

We used the track 1 signal to feed both G888 modules and didn't see any skew between them. The DEC G500 module in the skew checker has a trimpot to adjust the offset on the second Op-Amp to minimize the skew between the channels. You can see from this 'scope image that the skew between the G888 modules is minimal.

Track 1 is towards the transport, and track 10 is towards the outside. We disassembled the TU56 tape transport guides and gave everything a thorough cleaning. Using a tape written by DEC we see about 9uS of skew on the timing tracks with track 10 lagging track 1. This means that when facing the tape drive the near side of the tape head is to the right of where it should be. We added one layer of foil to the rear right side of the head to shim the outside of the head to the left and reduce the track 10 skew. The adjustment is very sensitive to the tightness of the head mounting screws. Tightening one head mounting screw about 1/8 of a turn and loosening the other screw would change the skew by about 5uS. We were able to reduce the timing track skew to about 2uS by fiddling with the shim and tightening and loosening the tape head mounting screws. After reducing the head skew it will not boot from the LAPS-DIAL or OS/8 LINCtapes and exhibits the same behavior where it can't find a block on the tape. It will not format a tape on the right drive now, so either we didn't improve the head alignment or something else is still broken. We also measured the coil resistance on the left transport and found two coils with high resistance, so we will need to replace tape head too.

The next blog.