It’s been forever since I updated here, hasn’t it!
Well. This is hard for me to say, but I think it’s time I officially give up on the 11/35 restoration. Wait, hear me out.
I’ve been poking at it over the last month or so, trying to make heads or tails out of what’s going on. And, unfortunately, I can’t. It has been exceedingly frustrating just trying to understand the problems with the startup status pulses, let alone repairing what looks like a completely flakey timing board, and possibly dead ROMs on the microword board.
When I received them, the board set was covered in rust and mouse piss. The IC legs (with the exception of the gold-plated ones, of course) were black, or red and spotted. I’m shocked I was even able to get the power supply back to life. So it’s really no surprise that the logic repair is above my skill level. Would it even be repairable to a DEC engineer? Maybe. I don’t know.
So tonight, I will regretfully put it back into the rack, clear off my workbench, and move on to some other projects. Maybe I’ll come back to this some day, if I ever find a replacement set of KD11-A boards. I do know someone who has a set. But for now, it’s time to move on.
I know I said I was going to take a few days off, but I couldn’t help myself. I spent about two hours looking at signals on the PDP-11/35 today.
I have decided to focus on the POWERUP INIT L signal. This line is normally high, but is supposed to go low for 20ms at system power-on time as soon as the BUS DC LO line goes high. For reference, here’s the complete schematics for both power-off and power-on sequence bus delays.
The chip responsible for POWERUP INIT L is a 74123 in position E26. After my experimentation last weekend I thought it was bad, so I got some replacement parts, pulled the 74123 and replaced it. But much to my chagrin, very little has changed. Here’s a typical startup sequence as it is now.
At least the crazy 50ns glitch is gone, but the output still isn’t going low. Well, not usually, anyway, and that’s what’s even weirder—I actually have seen it go low for ~20ms on several occasions, but only two or three times out of dozens of power-ups!
I’ve spent a lot of time puzzling over this part. Take a look at the schematics around the PWRUP INIT 74123. I’ve called it out here for a better view.
The inputs could not be simpler. Pin 1 is the A input, it’s tied directly to ground. Pin 2 is the B input, and it’s pulled up to +5V through a 1K resistor. Pins 15 and 14 are the RC network used to set the pulse width. Pin 4 is the PWRUP INIT L output, the one that’s supposed to pulse low for 20ms, but doesn’t (usually). And finally, pin 3 is the BUS DC LO input. It goes from LOW to HIGH when the power supply signals that it is ready.
Now, I’ve replaced the 74123, in fact I’ve tried no less than four different 74123 ICs and two 74LS123 ICs. I’ve pulled and carefully checked C45, and verified it’s within 5% of 3.9µF. I’ve checked the resistance across R4 and verified it to be 18KΩ. I’ve checked D2 with the diode test setting of my multimeter, and it’s fine. I watched the BUS DC LO input both with my logic analyzer AND with my oscilloscope, and verified that it goes high when it’s supposed to go high. So to say I am puzzled would be an understatement.
The nearest I can come to a theory right now involves what I’ve observed around that circuit when I apply power. Check this out.
The yellow trace is pin 2, the one that’s pulled +5V through a 1K resistor. (Incidentally, don’t be alarmed by the slow rise time. That’s within specs. According to the maintenance manual, the DC regulator has a maximum +5V output rise time of 30ms under full load, so this rise time of < 3ms is absolutely fine.)
But then check out the CLR input, on pin 3. That little bump is 1.04V! It's higher than the maximum LOW input voltage of 0.8V. Of course it's also lower than the minimum HIGH input voltage, so it should not be triggering anything, but maybe it is? I know the 74123 is considered a real pain in the butt to work with because of how noise sensitive it is, but I've never used them before, I have no practical experience here.
I also wanted to figure out WHY that little bump is making it to pin 3. So here is another waveforms that I found very interesting.
What we’re seeing here is an inverter on a 74H04 at power-on. The yellow trace is the input, and the blue trace is the output. The output is being fed directly into pin 3 of the 74123, and you can see that the little blue hump is there, as expected. Note that the very slow rise time on the input is at initial power-on, so that’s not a logic signal, that’s just the input drifting high as DC starts to flow in from the power supply. But apparently the damn thing actually starts to try to invert the low input signal, thus generating that little output hump.
So to boil it all down, this is my condensed working theory
The inverter (74H04 E24) is (possibly incorrectly?) trying to invert what looks like a LOW input, but it only lasts a few ms before the input is over the 0.8V TTL input threshold and the output goes low again.
The small 1.04V generated by the inverter is just enough to put the one-shot (74123 E26) into an undefined state, so it doesn’t trigger later on when it’s supposed to. But it’s VERY close to the 0.8V TTL threshold, so very occasionally it winds up in a good state, and does trigger when it’s supposed to.
Maybe I’m grasping at straws. But anyway, now my question is what to do about it? Could a marginal 74H04 IC be the cause of the little hump? Is there anything else I should look at around here that I’m just missing or overlooking?
The 8881 was a red herring. As Ian pointed out in the comments, the output is an open collector, so it won’t be high until BUS DC LO pulls it high. In fact that gate is only pulsed on power-off, not power-on. So that chip is probably just fine.
That said, I’m still completely lost. There is definitely something wrong with the power-on sequence, but I can’t for the life of me figure out what it is. I’m going to step back and take a break for a few days and see if inspiration strikes me.
What I really wish I had was a known-good KD11-A to compare against, but that is very unlikely to happen, alas.
It looks like an 8881 is bad on the STATUS module.
Pins 5 and 6 are inputs, and pin 4 is the output of a NAND gate on the 8881. That sure looks like a bad part to me.
I’ve ordered a few spare Signetics N8881’s off of eBay, but… I have to admit, I’m really down and disheartened about the project tonight. I didn’t get more than an hour of debugging in tonight before I found this chip, and now I’ll be high and dry for another week until my chips come in. And what will I find next?
I really think this might be a lost cause. I hate to think about giving up after all the time and money I’ve poured into this so far. There are other projects I’d like to be working on, but I’ve had this PDP-11/35 occupying my entire workbench for a month now and I don’t feel like I’ve actually accomplished very much.
Well, maybe the feeling will pass. I’ll give it one more go. If I continue to find as many dead parts after getting past the 8881, I’ll reconsider whether it’s worth it to continue.
This is what makes a PDP-11/35 or PDP-11/40 tick. It turns out to be 441 ICs. Impressive!
I needed to know what TTL ICs I might need to order replacements for, so I decided to tally up exactly which ones go into making a KD11-A CPU. This information comes straight from the PDP-11/40 Engineering Drawings, which list a summary of ICs used in each module on the first page of the module’s drawings.
It may be useful for someone else, so I figured I’d post it here.
Obviously, I did not finish my project in time for the conclusion of Retrochallenge. Of course I’m a little disappointed, but in retrospect there’s not much that I could have done to make it come together successfully before August 1st.
A few things went wrong: I didn’t get my chassis back from the powder coater until over a week into the month already, and then my power supply died just as I was getting started. But even so, given what I’ve discovered in the CPU so far I doubt that I would have made it by August 1st even without those problems. In fact, I predict this restoration will take several months more at least. I’m fully committed now, I’m not stopping until this thing works, even if I have to replace every single IC.
I’m counting this as a valuable learning experience, and I’ll be back with some crazy new idea for the next Retrochallenge.
A couple of comments here and over on the Vintage Computer Forum prompted me to pull out my copy of Don Lancaster’s “TTL Cookbook” to verify my assumptions. As is so often the case, my assumptions were wrong.
The original TTL family used in the KD11-A, the venerable 7400 series, can drive a maximum load of 16mA per output, and consumes 1.6mA per input. The more modern (and cheap and easy to find) Low-Power Schottky 74LS00 parts on the other hand can drive a maximum load of only 8mA per output.
This doesn’t mean I can’t use 74LS00 parts as replacements, of course. But it does mean that I have to be very careful where I use them. I will have to be absolutely sure that I am driving NO MORE than 5 inputs from any output if I want to use an LS part.
The 74123 that I want to replace, for example, is safe. One of the outputs is driving three inputs, and the other output is driving only one.
The 7404 that I’ve already replaced, however, is no good. I will need to undo that fix immediately. One of the NOR gates is driving ten outputs! That’s the maximum you can drive from TTL to TTL, and twice as many as you can drive from LS TTL to TTL.
So, more delay while I get some original TTL parts. There’s a shop here in town that sells them, but I’ll need to take a couple of hours off work to drive there. The things we do for our hobbies!
Now that the power supply is straightened out (at last!), I’ve been able to start tracing logic and seeing what’s up with the CPU.
First things first: It still doesn’t run. Last week before the power supply died I mentioned that I thought it may have been due to low voltage. That was wishful thinking. Now that the voltage levels are good, the behavior of the CPU is roughly the same. It is time to go spelunking into the lair of the beast.
I wanted to tackle the HALT/ENABLE switch first. If the CPU is halted (switch set into the HALT position) it should be running the console loop, waiting for commands from the console switches, but I have no evidence that it is. I had already verified that the 7410’s on the console were working correctly, so my investigation took me from there to the CPU itself.
Thanks to countless people around the world, a lot of DEC’s documentation lives on in scanned form, including the KD11-A Maintenance Manual and Engineering Drawings. These have proven absolutely essential. It didn’t take me long to trace where the HALT switch feeds into the CPU. It turns out it has several destinations: On the M7235 STATUS module it feeds into a 74H11 AND gate, and on the M7234 TIMING module it feeds into a 7474 flip-flop, a NOR on a 7402, an inverter on a 7404, and a NAND on a 7400.
I took a breadth-first approach to tracing the HALT signal by looking at the inputs and outputs on each of these gates. I was able to watch the signal go from HIGH to LOW and back again as I flipped the switch, so I knew the switch, the cable, and the backplane connections it used were good. Everything looked OK until I go to the 7404 inverter on the TIMING module.
Bingo! My first incontrovertibly bad part! It didn’t take me long to replace the 7404. One very tiny problem down, who knows how many to go.
I hit kind of a dead end on tracing the HALT switch, because most of the other gates have other inputs that weren’t changing. After my little 7404 victory, I decided to start looking more closely at the timing situation. How did I know what was going on at startup? Could I figure out whether I even had a clock? Was any microcode running?
I figured I should start by watching what happens at power-up. There’s a nice little diagram in the maintenance manual, page 3-11, that shows the expected timing of various signals after the CPU is turned on, so I decided to watch these lines on a logic analyzer and see what I got.
I probed the following lines and IC locations on the M7235:
BUS DC LO(DEC8881 E16, 04)
BUS AC LO(DEC380 E15, 10)
PWRUP INIT L(74123 E26, 04)
PWRRESTART H(74123 E25, 13)
JAMUPP(7474 E44, 03)
DELAY POWER DOWN(74123 E34, 12)
Well, I got a mostly correct waveform on my PDP-11/35’s startup:
+5V shows where I turned on the system. About 40ms later, DC LO goes high, then AC LO goes high a few ms after that. They seem to be behaving exactly as they should.
The little spikes there on the JAMUPP line are also correct – in reality those are about 3µs wide, exactly as they should be [EDIT: actually, plus or minus a microsecond – I need to investigate that. microseconds matter!]
DELAY POWER DOWN looks good too. The line is pulled low for about 3ms just as PWRRESTART H and JAMUPP both go low.
But PWRUP INIT L is seriously wrong. What looks like a little spike is a couple of < 1µs blips. That line is SUPPOSED to go low right after BUS DC LO goes low, and stay low for 20ms. That's part of the function of the 74123 IC, it uses an RC network as a timer — in this case an 18K resistor and a 3.9µF capacitor. Different values would be used for different delays.
My first thought was to double-check that noise and see what it looks like on an oscilloscope:
The yellow trace is DC LOW going high, and the blue trace is PWRUP INIT L. As you can see, that really is a very tiny blip. It tries to go low and fails miserably.
I immediately tested the capacitor and resistor in the RC network, but both are totally fine. It’s a tantalum cap anyway, so I wouldn’t really expect it to have gone bad. That pretty much means by process of elimination that the 74123 is bad. No surprise, actually, because the legs are pretty badly spotted with rust.
So that’s where I sit as of tonight. I obviously have startup timing problems, and so far two bad ICs. I’ve ordered a little care package of some 74LSXX, 74ALSXX, and 74FXX parts from Jameco, so they should be here by Wednesday at the latest. Some 74LS123s are among them. I’ll replace E26 and see if the startup waveform improves. There’s also a mystery with PWRRESTART H going high too soon, but I suspect that’s because of the glitch in PWRUP INIT L. We’ll see.
I think this is going to be a pretty slow process. But I’ll make it work yet!
I replaced MPSA05 and MPSA55 transistors that I suspected of being reversed, and bingo, the power supply is working again. I’m still upset with myself that I put them in backward, but in the end no other damage was done. Thank goodness.
Now I have a good, stable 5V supply, and I’ve adjusted the output correctly. That means I can get back to the business of debugging the CPU and seeing why the machine won’t run.