PDP 11/24 - A Step Backwards

[Noel Chiappa]

    > From: Tony Duell

    > A short in FET Q15 on the bias/interface board in the PSU could do it.
    > The gate of that FET is driven from an LM339 comparator the -ve supply
    > of which is -15V.

Ah; I hadn't even looked at the P/S prints.

(Like I said, I'm really weak on analog: for digital, I have the advantages
that i) although I'm basically/mostly a software person, the MIT CS
department is part of the EE department, and they made sure that all the CS
people had a decent grounding in the fundamentals of digital hardware; and
ii) in my early years, I was involved in a number of actual hardware
projects, including a UNIBUS DMA network interface that tuned into an actual
product. So I'm pretty good with a digital circuit diagram, like these CPU
prints. But analog stuff is still a mostly-closed book to me! :-)

Anyway, I'm happy to let you provide the analysis of the P/S... :-)


    > From: Rob Jarratt

    > [Perhaps] something else on the CPU caused Q15 to fail (if indeed it
    > did).

I'd guess 'unlikely' (if Q15 has failed); UNIBUS ACLO is connected, on the CPU
card, to only a single gate (on K2), and that 383 ohm pull-up (on K3), and the
1K pF cap there (the purpose of which I still don't understand, unless it's
just a smoother). Although I suppose that if that cap failed, shorted, maybe
that could have taken out Q15 somehow.

    > Perhaps I should ... and disconnect ACLO, DCLO and LTC, they are all on
    > the same connector

Now why didn't I think of just un-plugging that whole connector! Duhhhh! My
only concern would be leaving inputs floating...

DCLO, no problem; it has that pull-up on K3. (Ditto for ACLO, if the buffering
input gate isn't dead.) LTC, let's see... It's on K6, upper left corner. I'm
too lazy to work out what leaving that input floating will do, and, if it has
bad consequences, trace out all the places it goes (it should be connected up
to cause an interrupt, somewhere), but there's no point; the KW11 has an
'interrupt enable' that has to be set by software before it can do anything;
so at the moment it's safe to just ignore it for now, and stay with a focus on
getting the main CPU clock running. (LTC is not on the UNIBUS, so there's no
pull-up on the M9302 for it the way there is for ACLO & DCLO.)

So unplug that connector, and see if E70 (on K2, lower right corner) is OK.
(Remember, the pull-up will give it an Ok input with BUS ACLO disconnected.)
If yes, great, go check the main CPU clock.

If not, time to i) see how far the rot has spread (e.g. have other gates in
that package died - not sure what else is in there; not just looking at things
connected to the output - on pin 2), and ii) decide how to repair or
temporarily bypass. (Ditto for anything else that got taken out.) I'd be
tempted to bypass it (since I doubt you stock 8837's - although I do :-) -
ACLO handling isn't needed to get the CPU running. Tie BUF (not BUS!) ACLO to
ground, I'd say, and we can move on to look at MCLK.

    > If that works then I think repair ACLO and see if anything on the CPU
    > is bad or anything else that might cause a short on the ACLO signal of
    > the bus.

Well, your call, but i) working ACLO isn't needed to get the CPU running -
and, in particular, to look for other problems that might be preventing it
from running, and ii) fixing ACLO isn't guaranteed to make the CPU work.

I'd recommend 'keeping the eye on the ball', and focus on the main CPU clock,
getting ODT running, etc. The ACLO issue(s) can be cleaned up at your leisure.

	Noel