PDP 11/24 - A Step Backwards

[Noel Chiappa]

    > From: Rob Jarratt

    > today I went back to it to check things a bit more carefully. All the
    > power outputs of the PSU appear nominal.
    > ...
    > Presumably, whatever the part is, it is stopping the CPU working,
    > because previously the CPU did appear to show some activity, although
    > of course it could still be a failure on the CPU. I am not sure what
    > other outputs the CPU might depend on. There is the LTC signal for the
    > line time clock, but I don't know if its absence would stop the CPU
    > working. I have not been able to test the LTC signal as yet.
    > Can anyone suggest what else the CPU might need? Or is it LTC?

I'm going to start with some meta-comments, and then add some practical
suggestions for how to proceed.

Reading this, I'm guessing that you're a software person, right? Not that
there's anything wrong with that (_I_'m basically a sofware engineer), but if
one is going to collect and run (which inevitably means maintain/repair - it
was ever thus, including BITD) vintage computers, you need to have mildly
decent hardware skills. Yes, to some degree, one can lay this off on others
(as has been done here with the power supply - something I'd do myself, as my
analog skills are not very good), but I think developing some decent digital
hardware understanding would really help.

For instance, take your question about the LTC. To some degree, a complete,
entirely accurate answer is dependent on the details of the software
(bootstrap and/or OS). However, knowing how the LTC works, what the low-level
details are of what the CPU hardware does with it, etc would tell you whether
it is a cost-effective (in terms of overall 'getting the hardware working'
project) thing to spend time on looking at, to begin with.

(Parenthetical observation: I reckon that debugging _any_ issue, hardware
_or_ software, is a process of 'what's the _cheapest_ [easiest, quickest,
etc] test I can do that will produce the _maximal_ reduction in the area that
the bug could be in. Rinse, repeat, until you've tracked the problem to its
lair.)

(You may discover, once you get the machine mostly working, that the LTC
_specifically_ isn't working - at which point you can dive into it in detail.
But until then, I'd ignore it. It's a relatively small aount of stuff, and the
chance of a problem in there is small. And even if it's broken, the likely
effects are small. There are better things to look at - below. Having a clear
understanding of the machine's major functional units, and how they interact,
would have made that clear.)

So, in addition that that overview of the major functional units, you
definitely need to know how the QBUS works (read the QBUS chapter in the
"Microcomputer Products Handbook" or the "Microcomputer Processors"
books). (Yes, I know, the -11/24 is a UNIBUS machine, but the two busses
differ only in extremely minor details; if you fully understand one, you can
learn the other in half an hour. And the -11/24's CPU is a KDF11 CPU, and uses
the microcode ODT 'front panel' of the QBUS CPUs.)


Having said that, and starting with the "All the power outputs of the PSU
appear nominal" (which rules out a large area), this is the process I'd
follow to reduce the area the problem is in as quickly as possible. (And
maybe I should transform this into a 'fault analysis of QBUS (and some
UNIBUS) PDP-11 systems' on the CHWiki.)

You need to see if the CPU is _basically working. Two stages to that: i) is
the ODT 'front panel' (in microcode) working, ii) is the CPU basically
functional - i.e. can it fetch and execute instructions. Answers to those
will greatly reduce the area in which the problem (if there's _only_ one - a
possibility one must keep in mind).

The first will tell you that i) the CPU is basically functional, executing
micro-instructions, etc; ii) that the bus is basically functioning (for
master-slave cycles; DMA and interrupts will remain to be checked out); iii)
that the console port is working. (Yes, on the KDF11-U, the console is on an
internal bus, and so in theory a machine could have the ODT 'front panel'
working, _and_ still have a problem with the bus, but depending on the exact
details of said problem, maybe not.)

So, hook up a console, set the machine to 'halt', and power on. Is console ODT
working? If so, congrats, you win, go to stage ii) below.

If not, you have a reduced area in which you have to investigate - and you'll
need a 'scope of some kind to make any progress. (If you don't have one,
you're SOL. Get one.). In order i) is the CPU's internal clock (and thus,
probably the microcode) running? (At this point you will need to consult the
"PDP-11/24 System Technical Manual", EK-11024-TM.) If so, is it trying to
talk to the console's registers? (See Section 4.6 of the TM, "Internal
Address Decode".) If so, is the UART working properly? (4.7 of the TM,
"Serial Line Units".)

If so, console ODT is running, you're now at stage ii): you can see if the
CPU will run. Deposit a 0777 ('BR .') in a likely location (I usually use
0100 or 01000); read it back to make sure the write succeeded. (If not,
likely either the UNIBUS or the main memory has a problem.) Start the
machine; the 'Run' light should come on - if you're lucky!

Depending on which bin you wound up in, further assistance s available. :-)

	  Noel