Restoring a PDP-8/L

[gwiley]

First step was to remove the power supply, disconnect and/or remove the 3 large electrolytic capacitors and reform them.

The reforming jig is very similar to the one used for reforming electrolytics in the PDP-8/M.
PDP-8/M supply reforming with schematic:
https://forum.vcfed.org/index.php?t...-new-old-pdp-8-m-chassis.1238187/post-1256186

Next, test the 5V regulator with it disconnected from the bridge rectifier and input filter cap. I wasn’t able to find requirements for output current of the 5V regulator, so a load test was performed using a Kunkin electronic load. The output current was gradually increased while using my finger to monitor the temperature of the 2N3055 pass transistor.


I was a bit nervous to do the following without having checked any of the modules but with the 5V regulator disconnected from the backplane, I connected a lab supply set to output 5 volts to the backplane through a spare G785 board. The 5V current consumption was measured with probably nothing running. Here’s the photo; it draws about 5.1 A so testing the regulator up to almost 9 A might be sufficient.


Previously I saw Roland’s github repository containing files that describe an additional 5 volt crowbar/OVP for the 8/L. https://github.com/Roland-Huisman/Crowbar_PDP8-L It mentions a situation where the regulator output voltage can spike above 5 volts while the voltage is ramping up. I was curious about this so I performed a Vin vs. Vout test to observe the problem. As expected, mine does the same thing.


Additionally, the 8/L’s crowbar/OVP uses the same voltage reference as the regulator, so that could fail and cause the output voltage to be too high and not trip the crowbar. So, I built and tested 2 copies of Roland’s crowbar OVP and performed a test to determine the trip point:


I might set the threshold a tiny bit higher so it’s not prone to trip when the 5V supply ramps up. Notice in the chart above that my supply goes to 6.043 volts before in snaps back to 5 volts.
Here are the test results of the 8/L’s native crowbar/OVP:


None of the other supply voltage outputs have been tested yet because the 8/L power supply has not yet been plugged into a 120 VAC wall socket. It’s probably about time for this to happen but with the supply connected to loads first, not connected to the backplane.

Made some progress on the Stearns Flip Chip tester so it was time to start testing some of the simple M-series modules in the 8/L. This is pretty much all of the modules toward the front panel that are in front of the G-series modules. I’m quite fortunate to have a tester based on an existing tester design and have access to a nice library of tests which makes this process *much* easier. When a module is good it gets a yellow dot sticker. When a module tested bad it was replaced with one of the spares (which were also tested in the tester) and that module would get a yellow dot sticker with a small circle in the middle. In a couple of cases the original module was repaired on the spot so it got a yellow sticker with a dot or an R. Here’s a photo of the card cage with stickers on the modules. 11 modules tested bad so far, 2 were repaired and 9 were swapped from the spares kit. Before each module was tested it got a good cleaning which was actually the most time-consuming part of the process.
The M700 in slots C2+D2 is missing in the photo because it was in the tester when the photo was taken. There are still more modules to test and I expect to find more bad parts.


Here’s a tally of what was bad (so far):


(The first row indicates that there were two bad SN7400’s on one M113 module.)
In addition to the above, there was an M113 with a bad via/feed-through that was fixed by resoldering it. An M310 delay line module had a bad Q1 PNP transistor. I replaced it with a 2N3906 because this transistor seems to be nothing special in this circuit. The M310 worked properly after replacing Q1. I have parts on order to repair the rest of the above modules. Some have arrived already.

(I used to have a big pile of SN7400 chips but gave them away a few years ago thinking: “when am I ever going to use these?”. Ha! If I had only known I’d have a renewed interest in the PDP-8. I’ll have to share my story about the PDP-8 sometime and building a morph between a PDP-8 and Nova.)

Spent a little time with the M700 Manual Timing Generator. E3, a 7400, is almost certainly bad. I can swap that tomorrow. For now, I’m using the M700 from the spares kit so I’ll be able to run the updated M700 tests and be able to evaluate the pulse filter circuit and the pulse chain generator that generates MFTP0, MFTP1 and MFTP2.

Given that so many bad modules have been found so far, I’d really prefer to test as many as possible in the tester before powering up the whole unit to see what works and what doesn’t. I’m kind of surprised to see so many bad chips because Omnibus modules that I’ve purchased from various sources have rarely had bad chips. The date codes of chips in the 8/L are a bit older though. Maybe IC passivation, and just chip manufacturing process and quality control improved a lot over the few years between the 8/L and 8/E,F,M. Looking through the forum I see that others have had similar experiences with many bad components in their 8/L.

I hope to have more to share soon…

 

[m_thompson]

I think that you will find a lot more broken SN7474 chips before it is fully functional...

 

[gwiley]

I think that you will find a lot more broken SN7474 chips before it is fully functional...

So far, I've run all of the M-series modules through the tester and I seem to have mostly bad logic gates. I do have a total of three bad SN7474 on the M216 modules. In the back half of the machine it seemed like about one third of the SN7400 chips were bad, and some SN7402's on the M623 modules.

I'm lucky to have a sizeable spare kit, and luckily they've all tested good, so the repair mode has been to just swap in good modules for bad. There's a growing pile of bad modules to repair later.

 

[m_thompson]

Don't be surprised if the machine runs OK for a few hours and then breaks again. It took many test/run/repair cycles before the PDP-8/I and PDP-12 at the RICM got to be reliable. We run these machines about once per week. Once the flakey parts are replaced it should be reliable for quite a while.

We had the PDP-8/L running nicely and when I finished my FPGA I/O interface experiments we put it in the warehouse. Two years later we tried to run it, and it is horribly broken.

 

[gwiley]

Seems like long ago I read something about carbon composition resistors changing value over time. The 8/L is a first-hand example of this. The terminator boards, M002 and M906, were tested in two phases. First the resistances were measured with a DVM and second the modules were plugged into the tester (to power the board but with no test program loaded) and measured the termination voltages.

The M002 has a bunch of series and parallel combinations of the resistors so the expected measured resistance value needs to be computed.

Most resistors are about 5% to 6% higher than their intended value.

The frequency of the RC-controlled clock on the M452 Variable Clock was only about 1.5% low, which is probably fine. I did adjust it up a little though, so it's right on.

 

[m_thompson]

The M002 termination board has both pull-up and pull-down resistors, and if both resistances go up the same amount, then the resulting termination voltage will be the same. The terminator will supply a little less current, but should work OK. The M906 is just pull-ups and diode clamps. That should work fine with slightly higher resistance in the pull-ups. On the M452 I imagine that C5 has lost some capacitance so you needed to adjust R3 to compensate for C5.

 

[gwiley]

Don't be surprised if the machine runs OK for a few hours and then breaks again. It took many test/run/repair cycles before the PDP-8/I and PDP-12 at the RICM got to be reliable. We run these machines about once per week. Once the flakey parts are replaced it should be reliable for quite a while.

We had the PDP-8/L running nicely and when I finished my FPGA I/O interface experiments we put it in the warehouse. Two years later we tried to run it, and it is horribly broken.

Thanks for this, good to know. I'll be sure to keep the spare boards and tester in working condition.

Curious about the FPGA I/O interface experiments. Were these for the 8/L? I've been thinking it would be fun to add memory expansion and disk I/O, but it feels like I'm a long way from doing that right now.

 

[m_thompson]

Curious about the FPGA I/O interface experiments. Were these for the 8/L? I've been thinking it would be fun to add memory expansion and disk I/O, but it feels like I'm a long way from doing that right now.

I made a programmed I/O device emulator from a MicroSemi SmartFusion SOM and some level shifters. The FPGA didn't have enough available pins to implement data-break. The ARM Cortex M3 in the FPGA ran Linux and emulated a paper tape reader and held the paper tape images in files. The FPGA did the address decoding, skip logic, and data buffering. The SOM that I used is pretty old now, so using something like a DE10-Nano would make more sense.

Making a Posibus Periperal Emulator

Contact mike@ricomputermuseum.org for details. Introduction: Many of the PDP-8 systems that are rescued are missing the peripherals, or the peripherals require extensive restoration. I am attempting to use an Emcraft Linux SmartFusion Evaluation Kit to make a Posibus Peripheral Emulatortm. I

www.ricomputermuseum.org

I did something similar with a newer SOM for Omnibus.

Making an Omnibus Peripheral Emulator

Contact mike@ricomputermuseum.org for details. Introduction: These early PDP-8 systems have pretty front panels that include switches and lights. Many of the PDP-8 systems that are rescued are missing the peripherals, because the processor looks interesting and the peripherals do not. In many

www.ricomputermuseum.org

It would be cool to make an Omnibone based on the BeagleBone Black.

 

[djg]

We had the PDP-8/L running nicely and when I finished my FPGA I/O interface experiments we put it in the warehouse. Two years later we tried to run it, and it is horribly broken.

I must be the one lucky person with 8/L. I got one from get it out of the basement we need to sell the house. It has the standard humid basement and mouse residue corrosion. Took it apart and cleaned it. Saw one G board with a burned trace so replaced that board. Reformed and check supply and nothing needed replacing. Powered on machine and it worked. No repairs needed. Still worked last time I turned it on. Haven't tried the expansion box. Still haven't found any documentation for BM08. No idea how long since it was last used before I got it but didn't look that recent.

 

[djg]

It would be cool to make an Omnibone based on the BeagleBone Black.

It depends on being able to extend bus cycles until the BeagleBone is ready. Can you do that with Omnibus? It's been too long since i made my board but i though the timing was mostly fixed.

 

[m_thompson]

It depends on being able to extend bus cycles until the BeagleBone is ready. Can you do that with Omnibus? It's been too long since i made my board but i though the timing was mostly fixed.

With the SmartFusion based peripheral emulator the Cortex M3 was running about 1000 times faster than the than the 8/E so it had no problem keeping up with the bus. I actually had to slow the emulator down so I could test the skip logic.

 

[gwiley]

Don't be surprised if the machine runs OK for a few hours and then breaks again. It took many test/run/repair cycles before the PDP-8/I and PDP-12 at the RICM got to be reliable. We run these machines about once per week. Once the flakey parts are replaced it should be reliable for quite a while.

The "scorecard" so far:

These are mostly Signetics 7400 with date codes from 6934 to 6938. Most of the bad ICs overall are Signetics, and some Sprague.
The TO-5 transistor was from a G221. It was the rusting-lead problem, described here: https://www.pdp-9.net/pdp-8-l
This is scary. I wonder how many more are nearly rusted through, ready to break.
This proves m_thompson's point: "Don't be surprised if the machine runs OK for a few hours and then breaks again."

Also found two bad 7402 ICs on a pair of M623's.
The M706 and M707 Teletype Receiver and Transmitter are both bad. I just swapped them with good boards from the spares and haven't yet attempted to debug them.
Also have some bad and-or-invert gates or bad expanders on M160's. Modules were swapped, not yet repaired.

The Stearns-variant tester has been immensely helpful to find the bad modules and isolate the bad parts. I developed some scope loop vector files to test and debug the M700 Manual Timing Generator, M452 Variable Clock, and a test procedure for the G624 Resistor board. I actually found a super leaky electrolytic on a G624 that seems to be cured by a reforming process. I can upload these new vector files and companion test documents to github soon.

 

[gwiley]

Debugging the M700 Manual Timing Generator. There were four bad SN7400 ICs on the original M700 in the 8/L. Due to the large number of bad SN7400’s in the system I had to order some, which came rather quickly from Jameco and there was an additional larger order from the AliExpress JOYHOT Store. The M700 requires more than just simple digital functionality, so the analog characteristics of the SN7400 are important.

The Manual Timing Function implemented in the M700 is described in Volume 1 of the 8/L maintenance manual, Figure 4-10 on page 4-18
http://bitsavers.org/pdf/dec/pdp8/pdp8l/DEC-8L-HR1B-D_8LmaintVol1.pdf
This circuit generates timing pulse sequences when front panel switches are actuated.

There should be 2 μsec from MFTP0 to MFTP1, and another 2 μsec from MFTP1 to MFTP2. My good board from the spares kit functions exactly this way. It’s a rev-E and has mylar 0.01 μF caps in the timing chain. However, the original board from the 8/L, a rev-D, with four 7400’s replaced, had only 1 usec from MFTP0 to MFTP1 and has standard 0.01 μF disc caps in the timing chain. The 220 ohm resistors on the bad rev-D measured only about 5% higher (should make it slower, not faster) and the ceramic 0.01 caps were only slightly low. To be safe, I replaced all 220 ohm parts with 1% metal film resistors and 0.01 μF caps with 0.01 μF PET film capacitors. However, after upgrading the timing components there was still only 1 μsec from MFTP0 to MFTP1. Looking carefully at E5-9 and 10 it was clear that the E4-E5 pair of gates was returning to the non-triggered state when E5-9&10 dropped to 2 V. It should be 1.4 V, the standard TTL gate threshold. Remember, this is the rev-D board from the 8/L.

E5 was one of the ICs replaced with one from Jameco. Looking at the same circuit on the rev-E board from the spares kit, the E4-E5 gates return to the resting state when E5-9&10 decayed to 1.4 V, which is as expected. It didn’t make sense that a TTL gate would have a threshold other than two diode drops! I replaced E5 with a National DM7400N from my box of ancient parts, so I’m pretty sure it’s a real 7400. The circuit now trips at 1.4 V!
I should have taken photos of the waveform before swapping E5, but the effect can be observed at the E6 & E7 pair of gates that sets the delay from MFTP1 to MFTP2. The photo below of the rev-E board from the spares kit shows proper behavior at E7-13. The pulse ends when the voltage falls to 1.4V and a 2 μsec delay from MFTP0 to MFTP1.


Compare that to the improper behavior of the original 8/L board that has both E6 and E7 repaired and swapped with a Jameco SN7400N. The pulse ends when the voltage falls to 2V. The time is not as extremely incorrect as it could be because E6 is also a Jameco part, which has an output high voltage of 5 volts, which helps to extend the delay a little.


So, what’s up with the SN7400N from Jameco? First of all, the shape of Texas doesn’t look right:

A real TI SN7400N date code 7628 consumes 13mA at 5V with inputs floating. The Jameco part initially draws 13 mA and within seconds drops to zero. A real TI SN7400N has inputs that float at 1.4V. Jameco part measured zero volts with a scope probe on the floating input. Prop delay of a National DM7400N (soldered to the M700) measured 10ns L-H and H-L. Jameco part measured 10ns L-H and 7ns H-L. Jameco part logic high output is 5 volts, not 3.5 to 4 volts as with a typical TTL gate. The logic threshold is about 2V instead of 1.4V as noted above. I’m pretty sure this is actually a CMOS part marked as an SN7400N and clearly not manufactured by TI.

The SN7400N parts from the AliExpress JOYHOT Store are different but also have issues. I didn’t verify all of the parameters. The TI logo looks wrong but in a different way.

With inputs floating the part consumes zero current. Floating inputs sit at 1.34 volts and the output is zero with floating inputs. This seems good. The logic switching threshold measured using a variable lab supply is around 0.95 volts! Clearly noise margin is an issue here. The logic high output is 4.6 volts so it's not likely a TTL totem-pole output. I didn’t check the prop delay. This is also clearly a counterfeit part.

So, to repair an M700 module that needs more than just digital functionality of the NAND gates; real SN7400 TTL parts should be used.

This is a good lesson regarding SN74xx part sourcing. I probably won’t be ordering any more of them from China. Digikey and Mouser are more expensive, but probably for a good reason.

 

[DDS]

Your experience with those 7400 gates reminds me of my experience with my Heathkit H14 printer. The thing had no crystal for the timing oscillator. Instead, it had a 7400 IC with the outputs chained to the inputs in a ring configuration so that the propagation delays created a clock of sorts. The parts listing in the manual said it was a "selected" part. Mine must have not been selected all that carefully because at times the printer wouldn't do its "power up" dance with the print head advancing to the right then banging back to the left twice in succession. Instead it would just sit there until I grounded one of the pins on that 7400. Then it would get happy, do its little wake up dance, and all was right in H14 printer world.

 

[m_thompson]

I bought some 7475 parts from a broker. These should have Vcc on pin 5 and ground on pin 12. Whatever was in the package didn't like power on those pins because it cause a dead short Vcc to ground.

 

[gwiley]

I bought some 7475 parts from a broker. These should have Vcc on pin 5 and ground on pin 12. Whatever was in the package didn't like power on those pins because it cause a dead short Vcc to ground.

Wow, that could be pretty exciting if your power supply is robust. I wonder if they were actually 74175 or something like that.

 

[m_thompson]

Wow, that could be pretty exciting if your power supply is robust. I wonder if they were actually 74175 or something like that.

The 7475 was on a programmer's console in a PDP-8/a. Fortunately it just tripped the +5VDC breaker in the power supply.

 

[Teletech]

This business of counterfeit parts is really getting tiresome!
I'm fortunate enough to have what might be a lifetime supply of vintage parts, but for those buying new stuff it must be harrowing.
I'd be testing every chip I think.

 

[gwiley]

So, what’s up with the SN7400N from Jameco?

I contacted Jameco this morning and explained this issue, sent them the photo of the chip and plot of Vout vs. Vin, and they promptly apologized and sent me a refund before noon the same day. Pretty nice.

Here's the Vout vs. Vin plot of four parts.

The two good parts are:
1. The black curve, a TI SN7400N that I acquired sometime in the late 70's
2. The orange curve, a National Semiconductor DM7440N date code 025P that I purchased from Jameco in August. Markings on the part appear to be legitimate. I'm pretty certain this is a real 7440N manufactured by National.

The red curve is the 7400N from Jameco, mentioned above. This part actually functions fine on Flip Chip modules that are purely digital in nature. The Stearns Flip Chip tester is happy with it, as we would expect, because it's a digital test. Based on the measured prop delay, power consumption, VOH level and shape of the Vout vs. Vin, I suspect this device is likely a 74AHC00 inside. I have 9 of these soldered onto boards that I've repaired. They might be okay but will review each one carefully. I'll probably replace all of them on the M700 Manual Timing Generator because the threshold voltage and VOH need to be like a TTL part for the M700 to function properly. Didn't discover the part issue until I replaced four 7400's on the one M700 module.

The purple curve is an SN7400N that I purchased from the AliExpress JOYHOT Store in August. I reached out to JOYHOT and they said they'll check with their supplier. I worry about the 0.9V threshold if the inputs go to the Flip Chip edge connector because there's very little noise margin for signals coming from other boards. Fortunately, I have none of these soldered to any of my Flip Chip modules.

There's a small order of TI SN7400N coming from DigiKey sometime this week which are definitely needed since the JOYHOT parts aren't usable. It's only qty=10; figured it's best to start small to confirm they're good first, then order more later.

 

[thunter0512]

... I suspect this device is likely a 74AHC00 inside. I have 9 of these soldered onto boards that I've repaired.

This is another reason to use sockets. It is easy to identify/remember what you have changed and if parts are fake, faulty or out-of-spec then it is easy to swap them.