PDP 11/24 - A Step Backwards

[Rob Jarratt]

Thanks for the lengthy reply. Some responses inline below.

> -----Original Message-----
> From: Noel Chiappa <jnc at mercury.lcs.mit.edu>
> Sent: 27 March 2022 21:09
> To: cctalk at classiccmp.org
> Cc: jnc at mercury.lcs.mit.edu
> Subject: RE: PDP 11/24 - A Step Backwards
> 
>     > 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? 

Yes, that is correct.

> 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.)
> 

I think I have been avoiding learning about the buses, but I think you are
right I will do some reading on them. I have a PDP11 Architecture Handbook
which talks about the Unibus, so I can read that. As an aside I have also
been trying to find a fault on a Pro 350 which uses the same CPU chipset. I
have a pinout but no datasheet. I tried asking here on cctalk a while ago,
but there doesn't seem to be a whole lot of documentation to help me
understand how the CPU chips actually work. So I do try to understand the
hardware when I can.

> 
> 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).

I don't think the CPU is working at all. The reason being that there is
absolutely no LED activity. Including an LED that is supposed to indicate a
clock. Having hopefully eliminated all the power voltages it left me
wondering if there was a fault on the CPU or in the PSU. Having had activity
on those LEDs recently it seems most likely that it will be the PSU,
particularly as *something* in there blew up. The only signal that I can
identify that seems likely to have this kind of effect is LTC, but I don't
know enough about LTC to know if its absence could cause the CPU board not
to work at all, although I see above that you think it unlikely. I suppose
the fault could be something I can't see on the CPU board, particularly as
there do seem to be some quite large spikes, otherwise I am not sure if
there is anything else from the PSU that could prevent the CPU getting
going.

> 
> 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.

I had a console attached. There is nothing on the console. When I first got
the machine I did get output on the console. But that was before the PSU
first failed on me, which is quite a few years ago now.

> 
> 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