• Please review our updated Terms and Rules here

PDP-9 at the RICM

We tried to control the TU55s through the controller. If we command the drive to move, it moves about 1mm, stops, and shows an END error. It thinks that it went into the end zone so it stopped the tape.

After several hours of debugging we found that the G882 modules are oscillating when the tape is stopped. This is normal. The G882 module for the Mark track sends the decoded "data" to the Window Register, and after about 150ms the TP1 pulses show up. This starts clocking the "data" into the Window Register and eventually the code for the End Zone shows up in the Window Register. This is just random data and the TP1 pulses shouldn't be present.

It looks like the signals from the Write Mark Track switch are not pulled down enough, so in the active state the signal is at -1.8V. It needs to be below -2.0V to be active, and this eventually lets the TP1 pulses into the Window Register before the Up To Speed signal goes active.

Maybe I can get some time today to debug this, and compare the signals to the ones on the TC01 on the PDP-8/I.
 
We replaced a defective S107 inverter FlipFlop. The control signals to the TU55 DECtape look better, but we are still getting the END error and the tape only moves about 1mm.

Mattis punched the PDP-9 DECtape diagnostics and formatter for us.

The PDP-9 has something like a RIM loader in microcode (HRI). The paper tapes have a bin (HRI) loader at the beginning, and the rest of the tape is in BIN format. With a little work we might be able to make a bin loader for the console port, strip off the HRI loader from the beginning of the paper tape images, and load the diags at 110 baud through the console. Getting the real paper tapes from Mattis will be a lot easier.

I formatted a DECtape in PDP-9 format on my PDP-8/e. It was a little confusing because the word size in the formatter questions is in 12-bit words and the tape specification for the PDP-9 has 18-bit words. I think that I had it right with 384 decimal words to make 600 octal 12-bit words or 400 octal 18-bit words per block. The DECtape block size is the same on the PDP-9 and the PDP-10, but the PDP-10 uses it as 200 octal 36-bit words.
 
Too many visitors yesterday to get much done on the TC02. We are still getting the END error after we send a MOVE command to the TC02 and the tape only moves about 1mm. This part of the TC02 is very complicated because there are lots of error conditions that cause the tape motion to stop. We will eventually find the problem and move on to the next issue.
 
Today, after lots of false leads, we found that the signal from the processor that tells the TU55 DECtape drives to stop moving when the processor halts is always in the halt mode. No wonder the DECtape drives won't move the tape. Most likely a bad transistor in the S107 inverter flip-flop, so it should be a simple fix.
 
Yay, We replace a transistor on an inverter FlipChip an now the DECtapes move when we send a MOVE command to the TC02 DECtape controller. The indicator lights on the TC02 display panel flicker when the tape is moving, so it looks like it sees data from the DECtape.

Time to run the MAINDEC diagnostics that Mattis punched for use so we can see how much of the controller is working.
 
m_thompson said:
Time to run the MAINDEC diagnostics that Mattis punched for use so we can see how much of the controller is working.
Click to expand...

I hope the tapes got punched allright. Those mechanical thing can be a bit finicky some times. Hard to verify the tape by the eye. Reading them in might help out. But if there is an error was it in the punching or in the reading?
 
We loaded the paper tape for MAINDEC-9A D3BB-PB TC02 Basic Exerciser that Mattis Lind punched and sent us. We ran test #0, Basic Motion. This test puts the tape in Forward Motion and watches for the End Mark on the Mark Track, then reverses the motion of the tape. You can see from the indicator lights that the TC02 controller behavior is not correct, so more debugging is needed.

Video here:

We also tried test #11, Instruction test. This immediately halted at 03762, so the controller is generating an interrupt when it should not. I will try to fix that today.

Thanks again to Mattis and Anders for helping with this project.
 
Yesterday we ran MAINDEC-9A D3BB-PB TC02 Basic Exerciser test #0. This moves the DECtape forward until the TC02 controller finds the End Zone, then moves the tape backwards until the End Zone, and reverses the direction again. It only uses the Timing Track and the Mark Track for this, so only a little of the controller needs to work for this test to run. This test lets you 'scope just about all of the TC02 logic to see what is working while the tape is moving.

While the tape was moving we noticed that the pattern of lights for the Longitudinal Parity Buffer and the Read-Write buffer looked a little unusual, so we looked at the data coming from the G882 Manchester Reader-Writers. Everything looked OK except for the D0+ signal that was noisy and had a 500mV bias. We measured the resistance of the coils in the TU55 tape head, and found that the D0+ signal was open. The TU55 manual says that only DEC can change tape heads, but we ignored that and installed a head from a TU55 drive that was recently donated. Now we can see reasonable data on all 5x tape channels. We ran test #1, Search Scope Loop, and saw block numbers incrementing in the AC display on the console.

Just as we were basking in the glory of a mostly functional TC02, and about to make a video of the pretty light pattern, the processor halted. After a little experimenting we found that the core memory would only read zeros. Oh well, maybe we can fix that today and get back to the TC02.
 
The memory is working again. The B310 delay line that takes CLK and makes POST CLK\ had a non-monotonic output so the pulse amplifier that takes POST CLK\ and makes POST CLK was double triggering and making a mess of the core memory subsystem. We replaced the B310 with spare and are back to debugging the TC02 DECtape controller.
 
We had a very successful day working on the DEC PDP-9 and TC02 DECtape controller.

Alex found and replaced a bad diode on the B310 delay line FlipChip that prevented the core memory from working a few weeks ago. This diode worked fine in the forward direction, but instead of preventing current flow in the reverse direction, it acted like a resistor. This caused the output signal to have two pulses instead of one, and really confused the core memory controller. A few weeks ago we replaced the B310 broken delay line with a spare. We put the original repaired B310 back in the PDP-9 because we were concerned that we had tuned the adjustable delays in the core memory with the original B310, and the replacement B310 might have had slightly different delays.

On the TC02 DECtape controller, we found that data bit 1 from the DECtape drive was not getting latched into the Read-Write Buffer flip-flop. The S603 Pulse Amplifier that transfers this data from the Manchester Reader-Writer flipchip into the Read-Write Buffer flip-flop was dead. Mike Lill found a bad DEC D-664 diode on the Pulse Amplifier, and Emilio replaced it with a 1N4149 diode. Data bit 1 is now getting latched into the Read-Write Buffer Flip-Flop. I am getting more help fixing the PDP-9, so the repair work is going faster!

This failed diode had the same part number and the same failure mode as the diode on the B310 module. We are speculating that the cause was a partial breakdown of the PN junction in the diode. There are thousands of these diodes in the PDP-9, so hopefully we won't have lots of these diodes fail.

Next we found another bit in the Read-Write Buffer that would not latch data. We replaced the R201 flipchip with an untested spare and got lucky, it worked. Mike Lill found a bad transistor on the broken R201 flipchip, so we will replace it and add it to our spares.

The Read-Write Buffer and Data Buffer in the DECtape controller are really complicated. The data from/to the tape read/write head is 3 bits, and the word size in the PDP-9 is 18 bits. The Read-Write Buffer is 6 bits, so it shifts 3 bits of tape data from one side of the Read-Write Buffer to the other and then latches 3 bits of new data from the tape head. Then the Data Buffer shifts 6 bits of data from the middle of the 18-bit Data Buffer to the front of the Data Buffer, then shifts 6 bits from the end of the Data Buffer to the middle of the Data Buffer, and then latched 6 bits of data from the Read-Write Buffer into the Data Buffer. Once 18 bits of data have been assembled in the Data Buffer it is transferred to core memory using Data-Break.

We ran the TC02 Basic Exerciser test #1, Search Scope Loop. We can see the DECtape block numbers in the AC on the PDP-9 console display count up and down as the tape moves from end to end. This is really good progress.

We ran the TC02 Basic Exerciser test #4, Search Find All Blocks. The printout said that there was no interrupt when it found the end of the tape. The S202 dual flip-flop flipchip that holds the Interrupt Enable bit in Status Register B would latch the data for 200ns and then turn back off. We don't have a spare S202 so we swapped an S202 from another part of the TC02 controller. Now the interrupt enable bit stays on, so that means that the problem is in the S202 flipchip.

Mike Lill checked all of the diodes and transistors on the S202 with a DVM, but all looked OK. Next week we will make a test fixture for the S202 flipchip and do some active testing to determine what is broken, and then repair it.
 
Good to hear that you're making progress and even better that you're putting a team together. Are they other RICM members or are you recruiting some young folks like Dawson in Duluth?
 
Jack,

The PDP-9 helpers are two existing volunteers, and one new young volunteer. Dawson should move here in a few weeks, so can hopefully volunteer him to help keep the PDP-12 and the PDP-8/I running. With some more help we could get one of the PDP-8/S systems and the PDP-8/L out of the warehouse and into lab space.
 
Sure wish I lived up that way to be able to help. I'd be glad to work on an 8i. Too bad I don't.
 
You must log in or register to reply here.
Back
Top