• Please review our updated Terms and Rules here

PDP-9 at the RICM

m_thompson said:
Could you current limit the input drivers, and then measure the resulting voltage to make sure that the signal actually went to -3V?
Click to expand...
Seems like that should work. Haven't looked to see if any cards have intentionally higher input current. Other thought was lower value series resistor and differential mux to directly measure the current.
 
I have made this so far. A prototype of a levelshifter, to 3.3V logical levels. Two channels of I/O. Tolerant to +/-15V in case of faulty modules. Releays are for galvanic isolation. Three holes in top is ground and connections to the pins of the tested board for clipping on oscilloscope probes. Works to about 1 MHz.
IMG_0731.JPG
 
Sure, I realized that there are no pull up/down resistor to measure the current thru. This is also not the version that matches the board. I'll do more changes...
 

Attachments

  • Level-converter.pdf
    31.1 KB · Views: 7
I spend more time debugging the PDP-9 today. It would not run the Instruction Test #2 Maindec. It looks like the IOF instruction sometimes does not work. I toggled in a little loop to do an ION, IOF, check that interrupts are off, if so then loop, otherwise halt. It would do maybe a hundred loops and then IOF would not turn interrupts off. I chased that issue through the I/O controller and I think that I found the problem. Then the machine really died. The EXAMINE and DEPOSIT keys don't do anything, and I don't think that the I/O RESET pulses are getting to the I/O bus. I was really getting close...
 
I found the offending signal coming from the I/O processor that was stopping the console switches from working. I started digging in the I/O processor for why the signal looked so peculiar, and now the processor is broken again, but in a different way. I wonder if all of the power on/power off cycles that I have been doing to swap and check flipchips is damaging weak components?
 
After several days of debugging I found the problem with the processor. One of the voltage margin switches for the processor chassis was not fully in the normal position so there was no +10VDC to the Jam Flipflops in the Control Memory circuit. All I had to do was cycle the switch a few times and the processor is back to normal. It wasn't so bright for DEC to mount these switches on the fan trays...

Now back to fixing the I/O problem. When the processor executes an IOT instruction it sends the device address, data, and IOT pulses to the I/O controller and then waits for a signal that indicates that the I/O completed. The flipflop that buffers the IOP 4 was switching at 3 MHz without any input. The output was going to the processor and trying to restart the Control Memory much faster than it was capable and really making for strange behavior. If I disconnect the IO RESTART signal at the processor, the processor will execute any instruction except IOT. Without the IO RESTART signal the Control Memory hangs if it executed an IOT instruction. I replaced the S203 that implements the IOP 4 flipflop with a spare R203 and that issue was fixed. I will repair the S203 next time. The Pulse Amplifier that makes the IO RESTART signal is still generating pulses when it should be quiet. I will debug that next.
 
I found a bad R111 NAND gate that was causing problems with the Grey code counter in the I/O controller. The IO RESTART signal still doesn't work correctly so the processor's control memory is still broken and the console doesn't work. I keep disconnecting the IO RESTART signal from the processor to verify that everything else works OK, and it does. I will eventually find all of the broken bits and get this system to boot again.
 
I spent today chasing missing DLY and CLK DLY'D signals to a B301 Delay Flipchip and don't have a spare for it. I have it on an extender and can see the IO CLK (B) signal at the input and output of T2. From there is goes through D14 and disappears. I may LT Spice simulate the board to better understand it.
 
I pulled the B301 from the PDP-9 and plugged it into a backplane connector block with an R401 clock generator set to the same 1 MHz that it would see in the PDP-9 I/O controller. It is a lot easier to probe with the 'scope on the bench than on an extender in the I/O chassis. I still have not determined what is broken, and don't really know what the signals going through the transformers should look like.

At the same time I am working on the LT Spice simulation of the B301. I read about simulating the transformers, and it said that I could use the inductance of the coils instead of the number of turns in the coil. We had two spare T-2057 transformers so I used an LCR meter to measure the inductance of the coils. I compared the measurements out-of-circuit to the in-circuit readings of the transformer on the B301 and they were nearly identical. So now I can simulate the transformers on the B301. I need to get better models for the DEC specific transistors and diodes. Then maybe I can understand how the B301 works and can fix it.

Jörg Hoppe in Germany has a B301 listed for sale in his Flip-Chip Shop, but he doesn't reply to a message sent through his WWW site. Maybe I can find his email address.
 
FLIR Image of the B301 Delay Line.JPG
We resorted to using an infrared camera to look for hot components on the B301 flipchip. Two pairs of current limiting resistors are hot, which means that the corresponding transistors are always on. We bought some 2N3605 transistors on eBay because Q3 looks bad.

It will be interesting to see if the replacement B301 gets here before I get this one fixed.
 
The replacement B301 arrived and it works in the benchtop fixture. I adjusted the the delay to 500 ns, and installed it in the PDP-9. Both output signals are present when the I/O controller is running, but the delay time is miles off and the trimpot on the B301 has no effect on the delay. It looks like there is a wiring or backplane connector problem that I have to fix.
 
The CPU us almost back to working. The problem with B301 was yet another blown fuse. Without the +10VDC supply Q3 on the B301 could not adjust the delay time and the delay was just a few nanoseconds.

Everything in the CPU seems to be working except for the IOF instruction that turns off interrupts. This is where I started many weeks ago. Kind of happy to be back here.

One of the TU55 DECtape drives has a hub motor always on. This should be easy to track down and fix.
 
We found another S202 FlipFlop flipchip that was bad. We swapped it for a spare that I bought from Jörg and now we can turn interrupts on and off.
We ran the whole set of processor diags, and everything ran OK.

The TU55 needs a G850 SCR Motor Driver board. Now we have four bad ones and no spares. Time to fix a few.

We tried to boot ADSS from DECtape, and got a TIM timing error on the TC02 DECtape controller. I think that this is where we started two months ago. I suspect that a Data-Break didn't happen within 33 us, so there was a TIM error. That should be pretty easy to verify.
 
I keep going back and forth between the TC02 DECtape controller and the processor trying to find what is wrong with data-break. I spent the day chasing very complicated microcode circuitry and learning how the processor implements data-break. I can see the processor fetch the Word Count address from the TC02 and then fetch the Word Count from core memory. It looks like the processor never gets to the Current Address cycle and just continuously repeats the Word Count cycle. This is going to be really challenging to debug.

The TC59 Magnetic Tape controller has a feature that lets you load the data buffer and then force a data-break. The TC59 diags do this with all possible bit combinations to test all the capabilities of data-break. I might connect the I/O bus to the TC59 and run this part of the diags to determine if the data-break problem is in the processor or the TC02.
 
We don't have any PDP-9 I/O cables. These are a block of 4x flipchips so you only need 2x BC09 I/O cables. The BC09 cables are nearly identical to the BC10 I/O cables for the KA10. The LCM has lots of those, but isn't willing to part with any.

For now we are using 8x PDP-8 I/O cables. This works OK, but is a little more complicated to wire. We don't have a second set of 8x PDP-8 I/O cables to connect from the TC02 DECtape controller to the TC59 Magnetic Tape controller. I will probably try using a set of Vincent's ribbon cable FlipChips to see if those will work OK.

We also need 3x cables that connect to the indicator lamps on the TC02. These are direct finger to ribbon cable on one end and finger to ribbon cable through a diode on the other end. I will work out with Vincent what we can use, and if we need to reproduce one of the FlipChips.

On Saturday we disconnected the TC02 and connected the TC59. The TC59 has a feature where you can read/write the Data Register and then force a Data-Break. One of the diagnostics tests the Data-Break feature so we could use this to determine if the Data-Break problem is in the TC02 or the processor. The first test verifies that all possible combinations of the Command Register can be read/written, and that worked OK. The second test verifies that all possible combinations of the Data Register can be read/written. That one failed. We haven't used the TC59 for a few years, so that is not surprising.

We toggled in some little programs to fiddle with the Data Register, and were surprised at the behavior. The TC59 has both inputs on the Data Register flipflops wired to the I/O bus, so a 1 on the I/O bus compliments the data in the Data Register. This seems pretty complicated, so I wanted to look at the code in the diagnostic. Unfortunately the printed manual and listing for the diagnostic are an early version, and the only image of the diagnostic that we actually have is a later one that works for both the PDP-9 and the PDP-15. I am working on a paper tape disassembler to get a source listing from the paper tape image. Then I can see if I can pull comments from the earlier listing to make a working new listing.

In the middle of testing with the TC59 the I/O got flakey. The processor will run Instruction Test 1, but fails on Instruction Test 2 where it is testing the line clock. It looks like we need to fix some more things in the I/O section of the processor.
 
We toggled in a little program that sets the clock tick counter to -131,071 decimal, starts the clock, and halts when the clock flag goes on. This should run for 36 hours before the flag goes on, but runs for just a few milliseconds. We usually see between 3 and 20 clock ticks before the flag goes on. The clock uses part of a data-break cycle to increment the clock counter, and when it goes to zero generates an overflow signal that turns on the clock flag. This fault is likely related to the same data-break problems that we have with the 1/2" magnetic tape controller, and the DECtape controller. There is very little information in the maintenance manual about how the clock works, so this should be fun to reverse engineer and debug.
 
After lots of studying the Maintenance Manual and the schematics, and tracing signals between the I/O controller and the Processor, we think that we found the problem with the Real Time Clock. The counter address for the RTC is 000007. This gets generated by the I/O controller when the Data-Break request from the RTC is granted. The address is transferred to the buffered I/O bus, then to the O bus in the processor, and then to the MB register. From there it should go to the Memory controller. The signals that gate the address from the O bus to the MB look like they are being activated too often, but we have not resolved that issue yet. We did see the bit 17 of the address get into the MB, but bits 15 & 16 did not get into the MB. That would make the data-break increment the instruction at address 1 instead of 7. Address 1 is the first instruction executed after an interrupt, so that would cause lots of interesting problems. Eventually the clock counter goes to zero and turns on the clock flag, so eventually address 7 makes it to the MB.

I think we finally have a smoking gun that would cause problems with the RTC and DECtape. Saturday we will try to find what is broken.
 
You must log in or register to reply here.
Back
Top