Thanks for the lengthy reply. Some responses inline below. > -----Original Message----- > From: Noel Chiappa <j...@mercury.lcs.mit.edu> > Sent: 27 March 2022 21:09 > To: cctalk@classiccmp.org > Cc: j...@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