RE: PDP 11/24 - A Step Backwards
> From: "Rob Jarratt" > I did plug the connector back in, so that DCLO and > LTC are connected, I just removed the ACLO pin. Ah, OK, good. Pulling the pins from those Mate-n-Loc shells without the right tool is tricky; glad you did it, because as Brent Hilpert pointed out, having a working DCLO is important, to reset everything to a known state on power-on. > I didn't look for replacements last night. Is there a modern > equivalent? Not that I know of. Even if you found something with the same pin-out, supposedly DEC selected ones that were 'good enough'. I've never had an issue with NOS ones that I bought from vendors, though. > I may have found a source of NOS. Great; get several, they're a useful chip to have around; the QBUS uses them, as well as the UNIBUS. If the same place has DS8640's (the receiver), save on shipping (and ordering delays) and get a couple of those too. I say that because depending on what else you had plugged into the UNIBUS post ACLO failure, the -15V may have damaged them too. The M9312 (not sure if you had one of those, but the -11/24 manual says it's common in them) uses ACLO (via a DS8640). The KY24 seems not to (as far as I can tell from a quick look - negative results from a quick print scan aren't 100.00% reliable, whereas positive ones are), oddly enough. In EUB memory (not sure which you have), the MS11-L and MS11M MS11-P don't seem to, whereas the MS11-P _drives_ ACLO (through an 8881) - probably to prevent CPU startup until the ECC is cleared). Etc, etc. > I always marvel at how neatly those wires are done, I wish I knew how > to do such a neat job. The same way the old joke says one gets to Carnegie Hall, I expect! :-) (I wonder what the UK equivalent of the Carnegie is - the Royal Albert, probably?) Noel
RE: PDP 11/24 - A Step Backwards
> The 'unused' gate in E52 is the one that the added wires from the ACLO > ECO went to; I wonder if it was damaged by the -15V, somehow? So, I checked, and the wire that goes from the plated-through hole next to the etch cut on E70p1 winds up at E52p4 (the bus line on that transceiver), thereby connecting the latter directly to UNIBUS ACLO (on pin BF1). So that's almost certainly what caused other gate(s) in E52 to fail. I think I have managed to trace where all the other two wires to that 'new' gate in E52 went to/from, to see exactly what the ECO is. Given that E52 is a transceiver, it was likely substituted for E70 so that the KDF11-U could also _drive_ BUS ACLO. I discovered that E52p5 (the new transceiver's input) is connected to E73p13 (an DS8640 quad NOR used as a bus reciver); that's in the upper left corner of K2. It's BUS PB L NOR BUS PA H - i.e. a parity error has been detected in memory - so it apparently then power-fails the system! The incoming BUF ACLO (E52p6) goes to a PTH next to E70p8. On the bottom, there's a trace from that PTH that goes to E66p13 - which is the inverter shown on K2 which converts BUF ACLO H to POWER OK H. So that probably the answer to my plaint about E70p1 being left floating: perhaps theres an etch cut somewhere that disconnected E66p13 from E70p2, so the former can now be driven by E52p6. I can't see one, but there's a trace from that latter PTH that dives under E70, and I can't see it well, but it looks like it goes to E70p2. It would be interesting to know what they did about the E70p2 -> E66p13 connection. Noel
Re: PDP 11/24 - A Step Backwards
On 4/2/2022 5:12 PM, Rob Jarratt via cctalk wrote: Using tack soldered wires, I have traced back and I *think* I have found something. There could be a fault in E52 (sheet K6, p157 of the PDF). While K6 BUS DCLO L is +5V, I am measuring K6 BUF DCLO H at an average 1.64V with 50us spikes at 2.08V. According to a NatSemi datasheet for the DS8641 (http://pdf.datasheetcatalog.com/datasheet/nationalsemiconductor/DS005806.PD F) the logical 0 output should be 0.4V max and the logical 1 output should be 2.4V min. I also measured K6 BUF DCLO L to be always low, suggesting it thinks the K6 BUF DCLO H is a logical 1. This seems to suggest that E52 may be faulty. Trace here: https://rjarratt.files.wordpress.com/2022/04/e52-dclo-signal.jpg. Regards Rob Also, consider having a look at whatever E52 is driving - something may be pulling at it's output - a bad chip, a short somewhere in what it drives, etc. That looks to be E53 pin 13, and wherever else that signal might go. And also look at K5 BUS DCLO L, pin 15 of E52, just in case. JRJ
RE: PDP 11/24 - A Step Backwards
> -Original Message-
> From: cctalk On Behalf Of Noel Chiappa via
> cctalk
> Sent: 03 April 2022 03:41
> To: cctalk@classiccmp.org
> Cc: j...@mercury.lcs.mit.edu
> Subject: RE: PDP 11/24 - A Step Backwards
>
> > It was quite a struggle to separate those nylon connectors, is there
a
> > trick to it?
>
> You mean the Mate-n-lok's? Not really; just make sure the catch is
released.
>
> What did you do about DCLO? (Oh, I think I see the answer, below looks
> like you're relying on the pullup on K3...)
>
> > When I powered on, the CPU LEDs did not light up.
>
> Two of them ('0' and '1') are just bits in a special register, and thus
only do
> anything when the bootstrap code fondles them. When you get ODT
> running, you can amuse yourself turning them off and on manually! :-)
>
> > I did notice that the CLK LED flickered on briefly when I powered it
> > off.
>
> Interesting. Not sure exactly what we can deduce from that; but
interesting.
>
> > I put a scope probe on TP1 (p152 of the PDF), there was no activity,
> > the pin remained high.
>
> Yes; the signal there (MCLK H) is more or less the same one that drives
the
> 'CLK' LED (MCLK L); so no big surprise there. Still, that reduces the
problem
> space to a small part of K1.
>
> > The problem now is that I expect I will need to probe various pins
to
> > find out what is going on. But I don't have a Unibus extender and I
am
> > reluctant to remove the backplane. From what I can tell in the
> > Technical Manual you can't install the CPU in other slots
>
> Basically right; the backplane and CPU are designed to have it go in slot
1.
> It _might_ work in other MUD slots, with some loss of functionality (e.g.
> slot 2 doesn't have grant lines; MUD slots won't have the 'UNIBUS Map
board
> pesent' line - pin FE1, on K11, UB TO MA VIA UBMAP) but I wouldn't want to
> chance it, there might be a clash.
>
> > I am forced to tack solder probe wires to the chips, which works but
is
> > time consuming. Any other ways?
>
> Sorry, I don't have any experience to suggest any; too well supplied with
> extender cards, so I've never had to resort to alternatives!
>
>
> > I *think* I have found something. There could be a fault in E52
(sheet
> > K6, p157 of the PDF). While K6 BUS DCLO L is +5V, I am measuring K6
BUF
> > DCLO H at an average 1.64V
>
> Yeah, that's wrong. E52 is bad, and will have to be replaced.
>
> (From the +5V on BUS DCLO, I guess you're relying on the pullup? DCLO on
> the UNIBUS, with the resistor network on the M9302, should be about 3.5V -
> but now I'm confused, even with the P/S connector unplugged, it should
still
> be 3.5V or so. Oh well, it's late, the brain is powering down... :-)
Sorry if I wasn't clear, I did plug the connector back in, so that DCLO and
LTC are connected, I just removed the ACLO pin.
>
> The 'unused' gate in E52 is the one that the added wires from the ACLO ECO
> went to; I wonder if it was damaged by the -15V, somehow?
Oh, I forgot about that! That would seem highly likely.
>
> > logical 0 output should be 0.4V max
>
> Which is what you should be seeing.
>
> > I also measured K6 BUF DCLO L to be always low, suggesting it thinks
> > the K6 BUF DCLO H is a logical 1.
>
> Yup; and that definitely explains why the clock isn't running - BUF DCLO L
is
> clearing E41 on K1.
>
> Anyway, you'll have to replace E52 (which will be a bit of a pain, with
the 3
> ECO eires tacked to it). The DS8641 is an old chip, no longer in
production, so
> the usual suppliers may not have it, but there are some on eBait.
I didn't look for replacements last night. Is there a modern equivalent? My
initial searches show there isn't but I may have found a source of NOS.
Worried about replacing it with the ECO wires as you say, I always marvel at
how neatly those wires are done, I wish I knew how to do such a neat job.
Thanks
Rob
>
> Noel
RE: PDP 11/24 - A Step Backwards
> It was quite a struggle to separate those nylon connectors, is there a
> trick to it?
You mean the Mate-n-lok's? Not really; just make sure the catch is released.
What did you do about DCLO? (Oh, I think I see the answer, below looks
like you're relying on the pullup on K3...)
> When I powered on, the CPU LEDs did not light up.
Two of them ('0' and '1') are just bits in a special register, and thus only
do anything when the bootstrap code fondles them. When you get ODT running,
you can amuse yourself turning them off and on manually! :-)
> I did notice that the CLK LED flickered on briefly when I powered it
> off.
Interesting. Not sure exactly what we can deduce from that; but interesting.
> I put a scope probe on TP1 (p152 of the PDF), there was no activity,
> the pin remained high.
Yes; the signal there (MCLK H) is more or less the same one that drives the
'CLK' LED (MCLK L); so no big surprise there. Still, that reduces the problem
space to a small part of K1.
> The problem now is that I expect I will need to probe various pins to
> find out what is going on. But I don't have a Unibus extender and I am
> reluctant to remove the backplane. From what I can tell in the
> Technical Manual you can't install the CPU in other slots
Basically right; the backplane and CPU are designed to have it go in slot 1.
It _might_ work in other MUD slots, with some loss of functionality (e.g.
slot 2 doesn't have grant lines; MUD slots won't have the 'UNIBUS Map board
pesent' line - pin FE1, on K11, UB TO MA VIA UBMAP) but I wouldn't want to
chance it, there might be a clash.
> I am forced to tack solder probe wires to the chips, which works but is
> time consuming. Any other ways?
Sorry, I don't have any experience to suggest any; too well supplied with
extender cards, so I've never had to resort to alternatives!
> I *think* I have found something. There could be a fault in E52 (sheet
> K6, p157 of the PDF). While K6 BUS DCLO L is +5V, I am measuring K6 BUF
> DCLO H at an average 1.64V
Yeah, that's wrong. E52 is bad, and will have to be replaced.
(From the +5V on BUS DCLO, I guess you're relying on the pullup? DCLO on the
UNIBUS, with the resistor network on the M9302, should be about 3.5V - but now
I'm confused, even with the P/S connector unplugged, it should still be 3.5V
or so. Oh well, it's late, the brain is powering down... :-)
The 'unused' gate in E52 is the one that the added wires from the ACLO ECO went
to;
I wonder if it was damaged by the -15V, somehow?
> logical 0 output should be 0.4V max
Which is what you should be seeing.
> I also measured K6 BUF DCLO L to be always low, suggesting it thinks
> the K6 BUF DCLO H is a logical 1.
Yup; and that definitely explains why the clock isn't running - BUF DCLO L is
clearing E41 on K1.
Anyway, you'll have to replace E52 (which will be a bit of a pain, with the 3
ECO eires tacked to it). The DS8641 is an old chip, no longer in production, so
the usual suppliers may not have it, but there are some on eBait.
Noel
RE: PDP 11/24 - A Step Backwards
> -Original Message- > From: cctalk On Behalf Of Rob Jarratt via > cctalk > Sent: 02 April 2022 11:58 > To: 'Noel Chiappa' ; 'General Discussion: On-Topic > and Off-Topic Posts' > Subject: RE: PDP 11/24 - A Step Backwards > > > > > Disconnect the bad ACLO, power it on, and see if the CLK LED comes on. > > if not, then we'll have to work out why not. > > This is my plan for later today. OK, so I disconnected ACLO only. It was quite a struggle to separate those nylon connectors, is there a trick to it? In doing so I spotted two backplane wire wrap pins touching and a couple of others that were quite close too, so I separated them and inspected all the backplane pins. I didn't see any other ones touching. When I powered on, the CPU LEDs did not light up. Some random characters appeared on the console, but probably just a bit of noise maybe? However, I did notice that the CLK LED flickered on briefly when I powered it off. I put a scope probe on TP1 (p152 of the PDF), there was no activity, the pin remained high. The problem now is that I expect I will need to probe various pins to find out what is going on. But I don't have a Unibus extender and I am reluctant to remove the backplane. From what I can tell in the Technical Manual you can't install the CPU in other slots to make room for attaching probes either. I am forced to tack solder probe wires to the chips, which works but is time consuming. Any other ways? Using tack soldered wires, I have traced back and I *think* I have found something. There could be a fault in E52 (sheet K6, p157 of the PDF). While K6 BUS DCLO L is +5V, I am measuring K6 BUF DCLO H at an average 1.64V with 50us spikes at 2.08V. According to a NatSemi datasheet for the DS8641 (http://pdf.datasheetcatalog.com/datasheet/nationalsemiconductor/DS005806.PD F) the logical 0 output should be 0.4V max and the logical 1 output should be 2.4V min. I also measured K6 BUF DCLO L to be always low, suggesting it thinks the K6 BUF DCLO H is a logical 1. This seems to suggest that E52 may be faulty. Trace here: https://rjarratt.files.wordpress.com/2022/04/e52-dclo-signal.jpg. Regards Rob > > > > > Noel
RE: PDP 11/24 - A Step Backwards
Finally found time to get to this one... > From: Rob Jarratt > However, there is a puzzle. On the CPU I found that the track from the > pull up resistor to E70 has been cut. I don't know about the "pull up resistor" part, but I have several KDF11-U's, and _all_ of them have the trace on the bottom of the card connected to pin 1 of E70 cut, in the exact same place (about 1/8" from the pin). This suggests that it's not a local mod (as you suggest below), but an 'official' DEC ECO. > This would suggest that E70 pin 2 is floating, which I think means that > K2 BUF ACLO H is also floating The input (pin 1) will be floating, but not the output (pin 2); TTL doesn't work that way, I think. I may have this wrong, but I think open TTL inputs float high, so BUF ACLO should be low. I looked, and I don't see any other traces (e.g. on the top side) going to pin 1. So I'm a bit puzzled that DEC allowed that input to float, as open inputs can lead to erratic operaton; they're usually tied high, or to ground. > K2 BUS ACLO L however has been patched to E52 pin 4, which is the > output of a gate on sheet K6. Can't say I understand why. Me neither; that's an unused (on the prints) driver in the DS8641 (center bottom of the page) - although that gate seems to have been fully wired up (wires to pins 4, 5 and 6) as part of the ECO. There is an ECO list on pg. 167 of the -11/24 prints (2 pages after K14), but I don't see an E52 in it anywhere. The puzzle here, if E70p1 is cut, and the output is low, is why the CPU clock isn't running. The -15V on BUS ACLO shouldn't have taken out any other semiconductors; it's not attached to anything else. (It will have run C6, on the lower right of the card, the wrong way, but i) I think that's a non-polarized item - and 100V rated, per the prints, and ii) I don't think that goes anywhere else, even if it's not.) So what's stopping the clock from running, then? Noel
Re: PDP 11/24 - A Step Backwards
On 4/2/2022 5:49 AM, Noel Chiappa via cctalk wrote: > does [disabling the MCLK counter via DCLO, asserted by the two > E126 monostable chain from ACLO] happen just on power-down, or on > power-up too? I'd need to understand how that two monostable chain > works in both cases, which I currently don't. (I only understand > monostables when pulses trigger them, not edges, which is a big part of > why I don't completely understand it.) So this was bugging me, so I hauled out my TI TTL databook and looked up the LS123. And, if that 'LS123 wasn't made by TI, it could be considered suspect until it has been checked out with a 'scope. I remember, from somewhere back in the day, that not all '123s were created equal, and that TI's were demonstrably better than the others in terms of stability and trustworthiness. I also recall *vaguely* one experience where replacing a '123 made by someone else with a TI one fixed the issue. JRJ
RE: PDP 11/24 - A Step Backwards
> -Original Message- > From: Brent Hilpert > Sent: 31 March 2022 22:48 > To: r...@jarratt.me.uk; General Discussion: On-Topic and Off-Topic Posts > > Subject: Re: PDP 11/24 - A Step Backwards > > On 2022-Mar-31, at 2:14 PM, Rob Jarratt wrote: > >> Those three comparators in the H777 are looking at a time-delay ramp > > > > Is that a typo? This is the H7140 not the H777. > > Groan. > > When this thread came up I went looking for the 11/24 schematic. I found > the document I linked earlier for the 11/24 and found 'the' +5 power supply. > So apparently I've been looking at the wrong +5V supply (H777) because the > rest of you are indeed looking at a different +5 supply (H7140), both of which > are in that same 11/24 pdf document. > > And indeed, the ACLO control is Q15 in the H7140. > > I really wish when people are asking for assistance or talking about a > schematic or circuit they would include a link/reference to exactly what they > are looking at (a) so the reader doesn't have to go scratching around to find it > and (b) to avoid effort-wasting screw-ups like this. Sorry about the wasted time. I think I did say at one point that it was the H7140, but that will be way down the thread somewhere. I will use PDF page numbers in future. > > So yes, you can ignore a lot of the details I described, though some of the > principals I mentioned are still valid.
Re: PDP 11/24 - A Step Backwards
> and there is some circuitry driving the clear input on the second > 123. Never mind this section. I mis-read the print; the clear input is connected to an _input_ of the flop below (which is also tied high). Noel
RE: PDP 11/24 - A Step Backwards
> > Disconnect the bad ACLO, power it on, and see if the CLK LED comes on. if > not, then we'll have to work out why not. This is my plan for later today. > > Noel
Re: PDP 11/24 - A Step Backwards
> does [disabling the MCLK counter via DCLO, asserted by the two > E126 monostable chain from ACLO] happen just on power-down, or on > power-up too? I'd need to understand how that two monostable chain > works in both cases, which I currently don't. (I only understand > monostables when pulses trigger them, not edges, which is a big part of > why I don't completely understand it.) So this was bugging me, so I hauled out my TI TTL databook and looked up the LS123. According to that, the 123 is triggered by the rising edge on the B (non-inverted) input, when the A (inverted) input is low (which it will be here; it's tied to ground). (Also by the falling edge on A when B is high, which we can ignore.) So I think that chain is probably triggered only on power-down, which will produce a rising edge on P FAIL. (Power-up will produce only a falling edge on P FAIL, once power is up and good.) (Note that the second monostable is triggered, also on B, by the -Q output of the first; i.e. by the 'falling' edge of the first's pulse. But see also at the bottom, below.) So that should happen (if I have correctly understood this, which is not certain, I'm just a software person :-) is that some time after P FAIL goes high - a delay set by the first 123 - the second 123 produces a pulse (of a width set by its RC pair) - which via E52 produces an assertion pulse on DCLO. WTF? (Not that we care in this machine's case, since i) it only happens on power-down, and ii) it's just a pulse, so it's affect on MCLK will be very transient; it can't cause it to stay off. My curiousity has been piqued, is all. :-) The TM does not, after a _thorough_ search (although there are a few mentions of power u/down, but not this), explin why, alas. (The TM for some _other_ -11 CPU, one which contains a similar circuit might, but I'm not _that_ curious! :-) My _guess_ is that the intent is to reset all devices to a good idle state, _before_ power actually goes out. (Don't ask me why it just doesn't use INIT, though!) The potential fly in the ointment of complete understanding is that a 123 can _also_ produce a pulse on a rising edge at the clear input - and there is some circuitry driving the clear input on the second 123. (The clear input on the _first_ 123 seems to be left hanging in space - odd!) It seems to be set off by the mysterious DGP03 signal, generated by the microcode - but the GP table on pg. 4-21 of the TM doesn't contain an entry for '3'? Unless it has a typo - there are two '5' entries. In which case it could be 'Toggle the HALT flip-flop (K6)' (which I don't see on K6, unless it's E78) but yah, pulsing DCLO will probably clear it, wherever it is! This machine is making my head hurt. Disconnect the bad ACLO, power it on, and see if the CLK LED comes on. if not, then we'll have to work out why not. Noel
Re: PDP 11/24 - A Step Backwards
> From: Brent Hilpert >> ACLO is only used to trigger a 'power-failing' interrupt; CPU >> operation is otherwise un-affected by ACLO (so the CPU can get ready). >> DEC P/S's carefully sequence ACLO and DCLO such that on power-down, >> ACLO is asserted first (to allow the CPU to get ready); on power-up, >> DCLO is de-asserted first (the later de-assertion of ACLO is the >> signal for the CPU to start running). > a) "ACLO is only used to trigger a 'power-failing' interrupt" > b) "ACLO is the signal for the CPU to start running" > Only a, or a & b? Sorry, I tried to write only 10 words, when I should have just bitten the bullet and written 40. There are two different circumstances: i) AC power coming on, and ii) AC power going off. (Sorry if you already know this next, but I'm not skipping anything any more: DEC paid careful attention to both, as the PDP-11's were always intended to be able to deal well with un-attended operation over an un-expected power outage. So they had to shut down in an orderly way on ii), and start up in an orderly way on i). Having the operator press a 'reset' button after power-on was not an option! Of course, the software had to be written to handle it all, and not all of it did so; e.g. UNIX V6 didn't deal well with either, whereas RSTS-11 would go through an outage and automagically pick up exactly where it was when power went down.) So when I said "ACLO is only used to trigger a 'power-failing' interrupt", the un-stated circumstance was 'when AC power goes off'. The bit about "de-assertion of ACLO [on power-up] is the signal for the CPU to start running" is something I hadn't known, but just picked up (it's not anything I ever had to pay attention to before) from reading the "Initialization" section in the "pdp11 bus handbook" - which is not (alas) online. (Maybe I should scan, OCR and port that section; it's fairly short.) (There _is_ a "pdp-11 UNIBUS Design Description" document online: http://www.bitsavers.org/pdf/dec/unibus/UnibusSpec1979.pdf but alas it doesn't have anything like the detail given in the "pdp11 bus handbook". 2.5 there, "Initialization Section", has some text about ACLO, DCLO and INIT (which is generated by the CPU, not the P/S), but not much.) Here's what the "pdp11 bus handbook" says (pg. 54): "When [the processor] senses the negation of ACLO, [which happens after the negation of DCLO, which itself happens "5 useconds after DC power is within specifications" - i.e. plenty of time for all logic to reset itself to a known state, after good power is available to it all] the processor starts its power-up sequence." How that happens in the -11/24 I'm not sure; the -11/24 TM doesn't cover it, and the Fonz, which we don't have documentation on, will be involved. > Now these things may well not be a problem here; I'm just looking for > potential failure points because we're looking for an unknown fault by > isolating things, and it's best done without introducing new potential > problems, or at least being aware of the potential. Makes sense. > ACLO exercises influence over DCLO and hence the CPU clock via those > those monostables (we both) mentioned earlier. Right, I had forgotten about those - it was late, and my brain was shutting down as I was tired. > ACLO -edge: > ==> inverted (E70.2/K2) to +edge > ==> triggers FF (E67/K2_PFAIL) to latch high > ==> triggers MonoFF (E126/K6_AC_TIM) > ==> triggers MonoFF (E126.10-5/K6) > ==> asserting K6_BUF_DCLO_L for some period It's not clear to me what the _point_ of that all is; I had previously guessed that "there's a delay between the PFAIL H input .. and _the CPU_'s assertion of DCLO - i.e. if the P/S goes bonkers and indicates ACLO, and doesn't promptly (after a suitable short delay to allow for power-fail action) follow it with DCLO, as it is _supposed_ to, the CPU will indicate DCLO on its own - and do it on the bus so everbody else will freeze too." That might still be correct - I think that perhaps that path through the monostables only operates on power-down (but maybe I'n wrong there, I don't really understand completely how that all works) - on power-up, PFAIL H is going to be a falling edge - so will the two E126 monostables just ignore that? Alas, the -11/24 TM doesn't cover this, as far as I could find. AC TIM winds up being used on K1, on the monostable at top right, which I think generates a bus INIT pulse, when called for by the microcode (MIB14). No idea why they need AC TIM to clear that monostable. > ==> which disables MCLK counter (E41/K1) Right, but does that happen just on power-down, or on power-up too? I'd need to understand how that two monostable chain works in both cases, which I currently don't. (I only understand monostables when pulses trigger them, not edges, which is a big part of why I don't completely understand it.) > It may be that it
Re: PDP 11/24 - A Step Backwards
On 2022-Mar-31, at 7:44 PM, Noel Chiappa wrote:
>> From: Brent Hilpert
>> DCLO & ACLO behave as power-on-reset signals to the system.
>
> Minor nit: actually, I think it's DCLO which performs that function in a lot
> of places; see e.g. the latches on pg. K2 (pg. 153 of the PDF) and K7. (INIT,
> usually in buffered form, is used more widely for this function, but I doubly
> digress in that observation.)
>
> As I explained, ACLO is only used to trigger a 'power-failing' interrupt; CPU
> operation is otherwise un-affected by ACLO (so the CPU can get ready). DEC
> P/S's
> carefully sequence ACLO and DCLO such that on power-down, ACLO is asserted
> first (to allow the CPU to get ready); on power-up, DCLO is de-asserted first
> (the later de-assertion of ACLO is the signal for the CPU to start running).
a) "ACLO is only used to trigger a 'power-failing' interrupt"
b) "ACLO is the signal for the CPU to start running"
Only a, or a & b?
You know more about the overall/macro system function of these signals than I
do, for current purposes I'm just looking at the electrical
behaviour/requirements for the signals and the particulars of this environment.
My point is that ACLO (and DCLO) are to remain in the same state as they are
when power is off, until the power supplies are ready. Or at least the power
supply design suggests (and enacts) such by intention.
- Suppose ACLO were allowed to waffle high during power-up but then asserted
low before CPU enable. That could trigger PF logic unless the PF logic has been
designed to deal with it. Things could be designed to allow ACLO to waffle high
as long as it's stable low (asserted) by the time DCLO goes high (deasserted) -
maybe they are - but one would want to know that.
- If bus-ACLO is left open to float high with power up, you have a slow edge
feeding into FF (E67/K2_PFAIL) and thence to monostables (E126/K6). There are
rise-time requirements for FF clock-edges, they can be unpredictable with slow
edges (that's what Schmitt triggers are for). There's a gate there (E70) that
may provide enough gain to adequately take care of the slow edge, I don't know
what the specs on those bus receivers are.
Now these things may well not be a problem here; I'm just looking for potential
failure points because we're looking for an unknown fault by isolating things,
and it's best done without introducing new potential problems, or at least
being aware of the potential.
> However, you make a good point with:
>
>> If they are allowed to just float up as the power supply comes up you
>> have no guarantees as to the end result ('end' meaning the state of
>> things after the power supply has come up)
>
> DEC specs state that DC power has to be up and stable 5 usec before DCLO can
> be de-asserted ("pdp bus handbook", pg 53). This is precisly so that
> everything is in a known state when operation commences.
>
> So I guess I'll go back to my original suggestion: disconnect the ACLO from
> the P/S (with its bogus -15V), leaving DCLO, so that it can properly set
> everything to a known state on power-on, and then you can see see if E70 has
> been fried, or is still working.
>
>
>> Manually connecting/disconnecting bus-ACLO to GND after power-up will
>> ... disable the clock.
>
> I can't see anything in the clock circuitry on pg. K1 (pg. 152 of the PDF),
> where all the clocks are generated, that looks at ACLO, or its inverted form
> POWER OK, or its latched form, PFAIL (both generated in the bottom RH corner
> of K2)? Did I miss something? All I can see is DCLO.
ACLO exercises influence over DCLO and hence the CPU clock via those those
monostables (we both) mentioned earlier.
ACLO -edge:
==> inverted (E70.2/K2) to +edge
==> triggers FF (E67/K2_PFAIL) to latch high
==> triggers MonoFF (E126/K6_AC_TIM)
==> triggers MonoFF (E126.10-5/K6)
==> asserting K6_BUF_DCLO_L for some period
==> which disables MCLK counter (E41/K1)
I haven't analysed things further in full to say what happens after that,
whether the clock is stopped for good or just temporarily, just that there is a
path of influence from ACLO (-edge) in there. It may be that it just stops the
clock temporarily: DCLO asserted resets E67/K2_PFAIL, clearing it to register
another ACLO / P FAIL.
> I'm too burned out right now to check for uses of ACLO/POWER-OK/PFAIL, to see
> definitively what it does do; tomorrow.
Given Rob's message about alterations on the CPU board regarding ACLO -
although it's not clear what those alterations are - I thinks he's right to
poke around the clock circuitry looking for where the clock is being inhibited.
Re: PDP 11/24 - A Step Backwards
On Fri, Apr 1, 2022 at 12:13 AM Noel Chiappa via cctalk wrote: > > I really wish when people are asking for assistance or talking about a > > schematic or circuit they would include a link/reference to exactly > > what they are looking at > > But everone probably _was_ looking at the same document - just different Actually I wasn't. I was working from the 11/44 printset (I recognised the power supply as being the same number) -- on paper. And I am not going to start counting pages. However I did say 'bias/interface board' which I am pretty sure is not a part of the H777 PSU. -tony
RE: PDP 11/24 - A Step Backwards
> From: Brent Hilpert
> DCLO & ACLO behave as power-on-reset signals to the system.
Minor nit: actually, I think it's DCLO which performs that function in a lot
of places; see e.g. the latches on pg. K2 (pg. 153 of the PDF) and K7. (INIT,
usually in buffered form, is used more widely for this function, but I doubly
digress in that observation.)
As I explained, ACLO is only used to trigger a 'power-failing' interrupt; CPU
operation is otherwise un-affected by ACLO (so the CPU can get ready). DEC P/S's
carefully sequence ACLO and DCLO such that on power-down, ACLO is asserted
first (to allow the CPU to get ready); on power-up, DCLO is de-asserted first
(the later de-assertion of ACLO is the signal for the CPU to start running).
However, you make a good point with:
> If they are allowed to just float up as the power supply comes up you
> have no guarantees as to the end result ('end' meaning the state of
> things after the power supply has come up)
DEC specs state that DC power has to be up and stable 5 usec before DCLO can
be de-asserted ("pdp bus handbook", pg 53). This is precisly so that
everything is in a known state when operation commences.
So I guess I'll go back to my original suggestion: disconnect the ACLO from
the P/S (with its bogus -15V), leaving DCLO, so that it can properly set
everything to a known state on power-on, and then you can see see if E70 has
been fried, or is still working.
> Manually connecting/disconnecting bus-ACLO to GND after power-up will
> ... disable the clock.
I can't see anything in the clock circuitry on pg. K1 (pg. 152 of the PDF),
where all the clocks are generated, that looks at ACLO, or its inverted form
POWER OK, or its latched form, PFAIL (both generated in the bottom RH corner
of K2)? Did I miss something? All I can see is DCLO.
I'm too burned out right now to check for uses of ACLO/POWER-OK/PFAIL, to see
definitively what it does do; tomorrow.
Noel
Re: PDP 11/24 - A Step Backwards
On 2022-Mar-31, at 4:12 PM, Noel Chiappa wrote: >> From: Brent Hilpert > >> So apparently I've been looking at the wrong +5V supply (H777) because >> the rest of you are indeed looking at a different +5 supply (H7140), >> both of which are in that same 11/24 pdf document > > That's because the H777 is the P/S for the BA11-L 5-1/4" box, and the H7140 > is the P/S for the BA11-A 10-1/2" box - both of which are, quite reasonably, > covered in the -11/24 print set. > >> I really wish when people are asking for assistance or talking about a >> schematic or circuit they would include a link/reference to exactly >> what they are looking at > > But everone probably _was_ looking at the same document - just different > pages! Alas, DEC doesn't number _all_ the pages with a 'unique within the > print set' identifier. > Still, one could say 'page xx of the PDF'. Which is what I do in these sorts of discussions, at least if it has not been specified previously, and especially when dealing with larger docs. E.g. from my previous messages in this thread: ref: pdfPg.152,etc of http://www.bitsavers.org/pdf/dec/pdp11/1124/MP01018_1124schem_Aug80.pdf pdfPg.30 of http://www.bitsavers.org/pdf/dec/pdp11/1124/MP01018_1124schem_Aug80.pdf (The latter being the page for the H777 I was mistakenly looking at.) Makes it easier for a recipient, everyone following, and yourself if you have to go back to it in the course of subsequent discussion.
RE: PDP 11/24 - A Step Backwards
> From: Brent Hilpert > So apparently I've been looking at the wrong +5V supply (H777) because > the rest of you are indeed looking at a different +5 supply (H7140), > both of which are in that same 11/24 pdf document That's because the H777 is the P/S for the BA11-L 5-1/4" box, and the H7140 is the P/S for the BA11-A 10-1/2" box - both of which are, quite reasonably, covered in the -11/24 print set. > I really wish when people are asking for assistance or talking about a > schematic or circuit they would include a link/reference to exactly > what they are looking at But everone probably _was_ looking at the same document - just different pages! Alas, DEC doesn't number _all_ the pages with a 'unique within the print set' identifier. Still, one could say 'page xx of the PDF'. Noel
Re: PDP 11/24 - A Step Backwards
On 2022-Mar-31, at 2:14 PM, Rob Jarratt wrote: >> Those three comparators in the H777 are looking at a time-delay ramp > > Is that a typo? This is the H7140 not the H777. Groan. When this thread came up I went looking for the 11/24 schematic. I found the document I linked earlier for the 11/24 and found 'the' +5 power supply. So apparently I've been looking at the wrong +5V supply (H777) because the rest of you are indeed looking at a different +5 supply (H7140), both of which are in that same 11/24 pdf document. And indeed, the ACLO control is Q15 in the H7140. I really wish when people are asking for assistance or talking about a schematic or circuit they would include a link/reference to exactly what they are looking at (a) so the reader doesn't have to go scratching around to find it and (b) to avoid effort-wasting screw-ups like this. So yes, you can ignore a lot of the details I described, though some of the principals I mentioned are still valid.
RE: PDP 11/24 - A Step Backwards
I made some interesting discoveries this evening. See below.
> -Original Message-
> From: cctalk On Behalf Of Brent Hilpert
via
> cctalk
> Sent: 31 March 2022 21:03
> To: General Discussion: On-Topic and Off-Topic Posts
>
> Subject: Re: PDP 11/24 - A Step Backwards
>
> On 2022-Mar-31, at 12:36 AM, Noel Chiappa via cctalk wrote:
> >> 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.
>
> Note: It's Q14 that controls ACLO, not Q15, Q15 is involved in the +5
startup.
> Unless there are two versions of the schematic and I'm looking at a
different
> one than everyone else.
>
> pdfPg.30 of
> http://www.bitsavers.org/pdf/dec/pdp11/1124/MP01018_1124schem_Aug8
> 0.pdf
>
Thanks for pointing that out, I had not noticed the other line going down to
Q13 and Q14.
>
> >> 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!
> > Du! 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.
>
> Removing DCLO and ACLO from the PS to the bus may allow the CPU/clock to
> work. Or it may not.
Well I can tell you it didn't, disconnecting those connectors left the CPU
still not doing anything. However, there is a puzzle. On the CPU I found
that the track from the pull up resistor to E70 has been cut. This would
suggest that E70 pin 2 is floating, which I think means that K2 BUF ACLO H
is also floating (I haven't put a probe on it as yet). But as the cut is
deliberate, there must be a reason. The CPU did work for a while when I
first got the machine. K2 BUS ACLO L however has been patched to E52 pin 4,
which is the output of a gate on sheet K6. Can't say I understand why.
However, for whatever reason it would seem that perhaps the ACLO signal from
the PSU has always been considered bad?
>
> DCLO & ACLO behave as power-on-reset signals to the system. If they are
> allowed to just float up as the power supply comes up you have no
> guarantees as to the end result ('end' meaning the state of things after
the
> power supply has come up), without doing an analysis of the pertinent
logic
> under their control.
>
> JFETs are being used as the ACLO/DCLO control devices for a reason. In
> co
Re: PDP 11/24 - A Step Backwards
On 2022-Mar-31, at 12:36 AM, Noel Chiappa via cctalk wrote:
>> 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.
Note: It's Q14 that controls ACLO, not Q15, Q15 is involved in the +5 startup.
Unless there are two versions of the schematic and I'm looking at a different
one than everyone else.
pdfPg.30 of
http://www.bitsavers.org/pdf/dec/pdp11/1124/MP01018_1124schem_Aug80.pdf
>> 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! Du! 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.
Removing DCLO and ACLO from the PS to the bus may allow the CPU/clock to work.
Or it may not.
DCLO & ACLO behave as power-on-reset signals to the system. If they are allowed
to just float up as the power supply comes up you have no guarantees as to the
end result ('end' meaning the state of things after the power supply has come
up), without doing an analysis of the pertinent logic under their control.
JFETs are being used as the ACLO/DCLO control devices for a reason. In contrast
to bipolars, the normal/no-gate-voltage state of a JFET is Source-Drain
conducting, thus the initial state at power-up of ACLO-L & DCLO-L will be
0V/low-impedance-to-GND. The point is to maintain that state until the power
supply levels are good so the logic can be forced into a known state.
Those three comparators in the H777 are looking at a time-delay ramp generated
by C14 and the constant-current circuit of Q11.
What is supposed to happen:
- everything is initially 0V: V+5, ACLO, DCLO.
- power is switched on. Internal voltage levels begin to rise.
- after some delay, E4 trips first to start the +5 supply.
- after some more delay, E5 trips, de-asserting DCLO (DCLO = High,+V).
- after some more delay, E6 trips, de-asserting ACLO (ACLO = High,+V).
The delays are presumably of some order of mS.
-15V is the expected level from the E6 comparator output if AC is good. A
Gate-Drain short in Q14 would be allowing that out to the bus. JFETs can be
flaky, a failed JFET wouldn't be a big surprise.
So E6.6 = Q14.G = -15V is expected after power-up but an additional concern
would be that a G-D short allowed excessive current from the bus through the E6
comparator output and damaged E6, or if left on too long burned out pull-up
resistors on the CPU or bus terminator. However the LM301 is supposed to have
current limiting so those things may not have been damaged.
The scope could be used to observe what is going on with the +5, DCLO, ACLO
sequencing at power up (with bus pull-ups, but without CPU).
Removing only the ACLO PS-to-bus connection would allow DCLO to still
RE: PDP 11/24 - A Step Backwards
> 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! Du! 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
RE: PDP 11/24 - A Step Backwards
> -Original Message- > From: cctalk On Behalf Of Tony Duell via > cctalk > Sent: 31 March 2022 04:26 > To: Noel Chiappa ; General Discussion: On-Topic > and Off-Topic Posts > Subject: Re: PDP 11/24 - A Step Backwards > > On Thu, Mar 31, 2022 at 3:52 AM Noel Chiappa via cctalk > wrote: > > > If the machine then runs, it's up to you as to whether you get the P/S > > repaired so that ACLO work properly - your call. (I wonder how the > > -15V got to ACLO - I suspect a solder bridge from the prior repair - > > but knowing the answer is not important to getting the machine > > running.) > > 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. > Yes I found that on the schematic and surmise that this is what has failed. > Of course _why_ Q15 failed, if it has, is another matter. Yes, a bit concerning, and as Noel says maybe this has damaged something else, or that something else on the CPU caused Q15 to fail (if indeed it did). Perhaps I should follow Noel Chiappa's suggestion and disconnect ACLO, DCLO and LTC, they are all on the same connector and see how far it gets. 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. > > -tony
Re: PDP 11/24 - A Step Backwards
On Thu, Mar 31, 2022 at 3:52 AM Noel Chiappa via cctalk wrote: > If the machine then runs, it's up to you as to whether you get the P/S > repaired so that ACLO work properly - your call. (I wonder how the -15V got > to ACLO - I suspect a solder bridge from the prior repair - but knowing the > answer is not important to getting the machine running.) 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. Of course _why_ Q15 failed, if it has, is another matter. -tony
Re: PDP 11/24 - A Step Backwards
> From: Rob Jarratt > I found these two signals and ACLO is low (-15V) 'Good news, bad news'... Bad is that something is seriously wrong there; 'allowed' values are 0v (asserted) and +3V (un-asserted). I'm worried that the -15V will have taken out some of the semiconductors that are 'listening' to ACLO (like E70, page K2 of the CPU prints, lower right corner) - and possibly some of the things that are connected to _them_. Good news is that i) this would definitely cause a problem, so we're closing in, and ii) even better, the machine doesn't actuallly _need_ the ACLO (or DCLO) signal from the P/S to function properly. Just disconect them (which may be a bit tricky; IIRC you've got a BA11-A - but you can pull the pin in the connector shell of the power harness from the backplane, details of that here: https://gunkies.org/wiki/DEC_power_distribution_connectors or, worst case, just cut the yellow wire to pin 4 of the 6-pin connector). At that point the pullups on ACLO (on the M9302 and the CPU - page K3 of the CPU prints - that's odd, there's a pullup to +5V there, but a cap to ground; the M9302 does indeed have the pull-up/down resistor pair on both ACLO and DCLO) should pull ACLO high and the clock should now run (CLK LED on) - unless the -15V killed something. If the machine then runs, it's up to you as to whether you get the P/S repaired so that ACLO work properly - your call. (I wonder how the -15V got to ACLO - I suspect a solder bridge from the prior repair - but knowing the answer is not important to getting the machine running.) > DCLO is high and the DC ON light is illuminated Good. > the CPU doesn't do anything presumably because ACLO is asserted. Yes. As long as the CLK LED is off, the machine will definitely be totally dead. If you can get it on, ODT should run (modulo issues yet to be sorted about the minimal functional machine - I'll post on that in a moment). Noel
RE: PDP 11/24 - A Step Backwards
I found these two signals and ACLO is low (-15V) so I guess this must be the problem and whatever blew inside the PSU is probably the reason this signal is low. DCLO is high and the DC ON light is illuminated, but the CPU doesn't do anything presumably because ACLO is asserted. Regards Rob > -Original Message- > From: Tony Duell > Sent: 27 March 2022 10:15 > To: r...@jarratt.me.uk; Rob Jarratt ; General > Discussion: On-Topic and Off-Topic Posts > Subject: Re: PDP 11/24 - A Step Backwards > > On Sat, Mar 26, 2022 at 9:20 PM Rob Jarratt via cctalk > wrote: > > > Can anyone suggest what else the CPU might need? Or is it LTC? > > > > I would check the ACLO and DCLO signals. These are both high (pulled up by > the bus terminator) for normal running, a PSU can pull them low if it detects > loss of mains or whatever. Normally that will halt the CPU > > -tony
RE: PDP 11/24 - A Step Backwards
You were right, it is switching noise. As you said, I was zoomed in too far, I hadn't paid proper attention! The actual ripple is about 50mV peak to peak. https://rjarratt.files.wordpress.com/2022/03/pin-1-5v-averaged-ripple.jpg Regards Rob > -Original Message- > From: cctalk On Behalf Of Matt Burke via > cctalk > Sent: 29 March 2022 01:31 > To: cctalk@classiccmp.org > Subject: Re: PDP 11/24 - A Step Backwards > > On 28/03/2022 23:22, Rob Jarratt via cctalk wrote: > > Its 600mV, but it is more of a spike than a ripple. Here is a trace: > > https://rjarratt.files.wordpress.com/2022/03/pin-1-5v-ripple.jpg > > > > I think that's just switching noise. You appear to be zoomed in on the point > where the main switching transistor is turning back on. Here is a trace from > an H7100 power supply (connected to a 70A dummy load) for > comparison: > > http://www.9track.net/posts/h7100_trace.png > > If you turn on averaging mode on the oscilloscope (acquire menu) then that > should filter our some of the noise and you will be able to see the actual > ripple a bit better. It should be noted though that a differential probe is > required for accurate ripple and noise measurements. > > Regards, > > Matt
RE: PDP 11/24 - A Step Backwards
> From: Brent Hilpert
> But the LED and CPU clock are not driven directly by that RC oscillator
> - there's a bunch of logic in-between the oscillator and the LED / CPU
> clock.
Oh, sure; it was late (for me; the dog woke me up at AM today :-), and it had
taken me a while to get even that far (find the freakin' thing), so I just
wanted to pass the ball forward and crash!
I saw the "STOP OSC H" signal feeding into the production of "PRE OSC L", but
couldn't fully work out all the things that fed into that - and it now looks
like that's not an important thing anyway, "MCLK H" is the one to look at.
> [RC clock] => K1 OSC H/L
> --> [4-bit counter w parallel load] => K1 MCLK H/L
> --> LED
It seems to me that the LED, being driven directly by MCLK L, should be
flashing at the basic clock rate (i.e. dim to the eye) - so if it's totally
off, MCLK L must not be running. So that's thing absolutely numero uno to
investigate.
> --> [driver] => K1 CHIP CLK H (fonz CPU clock)
Yeah; the Fonz also gets "MCLK L" on pin 19, though - not sure what that's
for. Eh, not important at the moment.
> The 4-bit counter looks to be generating some additional phases
Yeah, section 4.2 "Timimg" of the -11/24 TM talks about all the various
clocks in some detail.
> but it's also controlled by a bunch of other signals. One of those
> signals is K6 BUF DCLO L which can hold the counter in reset, i.e.
> disable the Master/CPU clock (and LED). K6 BUF DCLO L is derived
> on-board from K2 P FAIL H
Huh? BUF DCLO L is just BUS DCLO L, run through that DS8641 bus transceiver.
But yes, because DCLO can stop the clock, checking ACLO and DCLO is priority
numero uno in the debugging process, now. (Contrary to my previous fear, the
CPU might be OK, and it might just be a power supply issue.)
> which is derived from K2 BUS ACLO L
I haven't bothered to check to see where BUF ACLO L (generated on K2) goes,
but I assume it's used in power-fail trapping stuff. (ISTR that PDP-11 PS's
sequence ACLO before DCLO, to allow power-fail trapping, before the machine is
frozen as DC power actually goes low.) Likewise, not important at the moment.
> which is input from BF1-in-funky-hex-box which I presume is a bus
> connector pin.
Yes; the ID ("BF2") is an indicator to that.
> Even if ACLO is good, there's a whack of logic on the CPU board -
> including two monostables - just to get from ACLO to DCLO
The import of those two monostables isn't completely clear to me. However,
notice that the output is fed through the DS8641 bus transceiver to _drive_
BUS DCLO; my _guess_ is that there's a delay between the PFAIL H input (which
comes from BUS ACLO L) and _the CPU_'s assertion of DCLO - i.e. if the P/S
goes bonkers and indicates ACLO, and doesn't promptly (after a suitable short
delay to allow for power-fail action) follow it with DCLO, as it is
_supposed_ to, the CPU will indicate DCLO on its own - and do it on the bus
so everbody else will freeze too.
Anyway, I think we've got as far as we can until ACLO and DCLO are checked.
I'm upgrading the CHWiki KDF11-U page to cover the stuff that's not in the
CPU chapter of the -11/24 TM, like the meaning of those on-board LED's, etc.
Noel
Re: PDP 11/24 - A Step Backwards
On 3/29/2022 2:28 AM, Joshua Rice wrote: Just to chip in my 5 pennies worth. At least in the QBUS world, the only chipset that wouldn't ODT without memory is the original LSI-11 (and the T11 i believe, but that's moot because they came with RAM onboard). You should still get ODT on F11 and J11 chipsets even without RAM. I totally agree and this threw me for a bit of a loop when I was testing my 11/24. I can do a quick check next week, but from what I can remember I was baffled at no ODT until memory was in. Maybe it was the 7273's but I went through 4 cpu boards trying it. Memory in and it all worked. And I have 3 spare 11/24 cpus all in working order for sale if anyone needs one :-) I'll double check later. CZ
Re: PDP 11/24 - A Step Backwards
-- Original Message -- From: "Chris Zach via cctalk" To: r...@jarratt.me.uk; "'General Discussion: On-Topic and Off-Topic Posts'" Sent: Tuesday, 29 Mar, 2022 At 00:11 Subject: Re: PDP 11/24 - A Step Backwards I have been reluctant to put everything back in, in case the PSU fries something. And the ripple I noticed is... For the record, right now I have only the M7133, M7134 and G7273 installed. Ok, I do recall that my 11/24 wasn't doing any ODT without some form of memory. When I configured a (broken-ish) MS11-PL in it did at least come up and allow me to load memory addresses and the like. But no memory, no deal. I'd say figure out your PSU first, then memory, then stuff. C Just to chip in my 5 pennies worth. At least in the QBUS world, the only chipset that wouldn't ODT without memory is the original LSI-11 (and the T11 i believe, but that's moot because they came with RAM onboard). You should still get ODT on F11 and J11 chipsets even without RAM. Since the 11/24 uses the same chipset as the 11/23, i assume that this would still apply. Not sure of the intricacies of UNIBUS, having had no experience, but i assume that if the bus was terminated or continuity cards inserted correctly, the CPU board should ODT without memory. It's likely that the lack of ODT is due to issues with other boards, the backplane (an often missed source of issues), or the bus termination/continuity. I'd start with the basic stuff first. Whilst you're waiting on your PSU to be serviced in warranty, check the backplane and cabling for foreign objects, damage, and corrosion. Shorts and intermittent connections are inherently difficult to troubleshoot assembled, but can be trivial to identify when the machine is torn down. Then i'd reinstall the PSU and fans etc, then work on bringing up the machine, starting with the CPU and memory, then other devices. One notable thing, is i believe most PDP-11 PSUs, regardless of bus type, won't function correctly without a load on them. It might be hard to troubleshoot without a load on it. If you're short of grant continuity cards, they're extremely simple, and i'm sure with some googling, gerber files can be found for them. It should be trivial to make some from copper plated PCB stock and some patience if time is pressing. Good luck in your endeavors! Josh Rice
Re: PDP 11/24 - A Step Backwards
On 2022-Mar-28, at 4:07 PM, Noel Chiappa via cctalk wrote: >> 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. > > Looking at the KDF11-U prints, I finally found that LED (it's pretty low > level - I was worried that it might be a bit in a register, and driven by > software, but it's not, it's actually driven directly by the the CPU's > internal clock signal; it's on page K1 of the prints, 'Clock, State Decode', > in the very upper left corner). (The source of the CPU's internal clock is > just an RC circuit, in the lower middle of that page, and the trim pot that's > part of it - along the upper edge of the board - can be adjusted to set the > clock speed 'properly', per the note at the back of the prints on the page > which lists the configuration switches. The 2MHz crystal along the upper edge > drives the baud rate generator.) But the LED and CPU clock are not driven directly by that RC oscillator - there's a bunch of logic in-between the oscillator and the LED / CPU clock. [RC clock] => K1 OSC H/L --> [4-bit counter w parallel load] => K1 MCLK H/L --> LED --> [driver] => K1 CHIP CLK H (fonz CPU clock) The 4-bit counter looks to be generating some additional phases, but it's also controlled by a bunch of other signals. One of those signals is K6 BUF DCLO L which can hold the counter in reset, i.e. disable the Master/CPU clock (and LED). K6 BUF DCLO L is derived on-board from K2 P FAIL H, which is derived from K2 BUS ACLO L which is input from BF1-in-funky-hex-box which I presume is a bus connector pin. Tony mentioned checking ACLO. Even if ACLO is good, there's a whack of logic on the CPU board - including two monostables - just to get from ACLO to DCLO to enable the CPU clock, as well as those other signals controlling the phase counter. ref: pdfPg.152,etc of http://www.bitsavers.org/pdf/dec/pdp11/1124/MP01018_1124schem_Aug80.pdf
Re: PDP 11/24 - A Step Backwards
On 3/28/22 21:55, Jon Elson wrote: On 3/28/22 17:22, Rob Jarratt via cctalk wrote: Its 600mV, but it is more of a spike than a ripple. That's probably not real. It looks like noise pickup from the probe ground lead. Try disconnecting the probe tip and see if you still get similar signals. I have seen similar noise lots of times when measuring things with switching power supplies. The high frequency content is pretty unlikely to be actually there on the power rails, with a bunch of decoupling caps all over the boards. Jon
Re: PDP 11/24 - A Step Backwards
On 28/03/2022 23:22, Rob Jarratt via cctalk wrote: > Its 600mV, but it is more of a spike than a ripple. Here is a trace: > https://rjarratt.files.wordpress.com/2022/03/pin-1-5v-ripple.jpg > I think that's just switching noise. You appear to be zoomed in on the point where the main switching transistor is turning back on. Here is a trace from an H7100 power supply (connected to a 70A dummy load) for comparison: http://www.9track.net/posts/h7100_trace.png If you turn on averaging mode on the oscilloscope (acquire menu) then that should filter our some of the noise and you will be able to see the actual ripple a bit better. It should be noted though that a differential probe is required for accurate ripple and noise measurements. Regards, Matt
Re: PDP 11/24 - A Step Backwards
I have been reluctant to put everything back in, in case the PSU fries something. And the ripple I noticed is... For the record, right now I have only the M7133, M7134 and G7273 installed. Ok, I do recall that my 11/24 wasn't doing any ODT without some form of memory. When I configured a (broken-ish) MS11-PL in it did at least come up and allow me to load memory addresses and the like. But no memory, no deal. I'd say figure out your PSU first, then memory, then stuff. C
RE: PDP 11/24 - A Step Backwards
> From: "Rob Jarratt" > Thanks for the lengthy reply. Glad to help - or try to. > 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. There doesn't seem to be as lot on the F-11 set. I looked in the DEC semiconductor handbook, and it's not there - although perhaps it had been dropped by the one I looked at (which was mostly uVAX stuff) as obsolete? If you look in the KDF11-A and KDF11-U Tech Manuals, there is a chapter on the F-11 chip set, as used in those cards, and that's better than nothing - it talks a fair amount about the low level details of how the various chips operate and interact, etc. > 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. Looking at the KDF11-U prints, I finally found that LED (it's pretty low level - I was worried that it might be a bit in a register, and driven by software, but it's not, it's actually driven directly by the the CPU's internal clock signal; it's on page K1 of the prints, 'Clock, State Decode', in the very upper left corner). (The source of the CPU's internal clock is just an RC circuit, in the lower middle of that page, and the trim pot that's part of it - along the upper edge of the board - can be adjusted to set the clock speed 'properly', per the note at the back of the prints on the page which lists the configuration switches. The 2MHz crystal along the upper edge drives the baud rate generator.) > Having hopefully eliminated all the power voltages it left me wondering > if there was a fault on the CPU or in the PSU. If ODT isn't running, the problem is almost certainly in one of those two areas. > Having had activity on those LEDs recently it seems most likely that it > will be the PSU, particularly as *something* in there blew up. I'm not so sure. Those boards mostly just want +5V; looking a bit more, the CPU chips do seem to use +12V. The RS232 drivers will use +/-12V. I'm afraid that if i) it used to show activity, but no longer does so, and ii) the main voltages (+5V, +12V) look good, something on the CPU card has failed. But it will take a bit of digging to i) verify that, and ii) identify the fault. > 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 have yet to trace how the LTC signal is used in the KDF11-U, but on the KDF11-A, it not being there is a total NOP. (In fact, in the BA11-N/S type mounting boxes, there's a 'Clock Enable' switch on the front panel which turns the LTC signal off - and the machine runs fine with it off - except for the TOD clock not ticking.) That clock signal - totally different from the main CPU clock - is only used as an input to what is in effect a peripheral. > I had a console attached. There is nothing on the console. When I first > got the machine I did get output on the console. Not a good sign, alas. If you have a scope of some kind, and want to keep poking, I'd recommend that you start by seeing if the clock is running, and move forward from there. The KDF11-U prints are online, as is the KDF11-U Tech Manual. Skim the chapter on the CPU (4, I think), and then grovel around in the prints for a bit. Don't try to totally understand it all, just skim through it, so you know roughly where most things are. Noel
RE: PDP 11/24 - A Step Backwards
Its 600mV, but it is more of a spike than a ripple. Here is a trace: https://rjarratt.files.wordpress.com/2022/03/pin-1-5v-ripple.jpg Regards Rob > -Original Message- > From: Wayne S > Sent: 28 March 2022 23:15 > To: r...@jarratt.me.uk; Rob Jarratt ; General > Discussion: On-Topic and Off-Topic Posts > Cc: Chris Zach > Subject: Re: PDP 11/24 - A Step Backwards > > How bad is the ripple? > Anyone on the list know what’s acceptable? > > > Sent from my iPhone > > > On Mar 28, 2022, at 14:46, Rob Jarratt via cctalk > wrote: > > > > > > > >> -Original Message- > >> From: cctalk On Behalf Of Chris Zach > >> via cctalk > >> Sent: 28 March 2022 20:57 > >> To: cctalk@classiccmp.org > >> Subject: Re: PDP 11/24 - A Step Backwards > >> > >>> 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. > >> > >> I'm on a nice long train trip right now but I recently got my 11/24 > >> running again. One thing that baffled me was it would not do anything > >> on the serial port. No ODT, no nothing. > >> > >> Turns out you really need to make sure the slots are filled properly. > >> The CPU top, then the memory map, then for the next 4 boards one has > >> to be either a properly configured MS11-PL (the 128kw board) or the > >> memory boards specific to that type of 11/24. Or you have to put > >> G7273's in the CD slots. > >> > > > > I have been reluctant to put everything back in, in case the PSU fries > something. And the ripple I noticed is certainly something that bothers me. > Previously I had a burning smell from the memory board. I have since > replaced all the electrolytics on the memory board, but I have not tried > putting it back in the machine since. Just checking my notes, it seems I have > had *intermittent* lack of activity on the CPU LEDs before, so it may be > worth trying to put everything back in, although the ripple makes me > hesitant to do so. For the record, right now I have only the M7133, M7134 > and G7273 installed. > > > > > >> Next you need proper devices or G7273's in the next two slots and a > >> proper terminator in the left sockets of the last slots and a G7273 in the > center slots. > >> Only then will ODT work. > >> > >> Another oddity is that the 5.25 inch box has +5 and +12 I think and > >> the > >> 10.5 has +5 and +15. There are different memory boards that work in > >> one and not the other, or both depending on jumper settings that have > >> to be right. Unibus drives me bonkers sometimes with the number of > >> different voltages requires (+5, +12, +15, +20, -15, etc) It > >> doesn't help that the +15 and +12 are on the same pins. > >> > >> Plus it's possible someone screwed with some switches, make sure they > >> are set properly (ie: default is a good start). > >> > >> If you're still stuck next week drop me a line and I'll fire up my > >> 11/24 and see if I can replicate your failure. > >> > >>> > >>>> > >>>> 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 hav
RE: PDP 11/24 - A Step Backwards
> -Original Message- > From: cctalk On Behalf Of Chris Zach via > cctalk > Sent: 28 March 2022 20:57 > To: cctalk@classiccmp.org > Subject: Re: PDP 11/24 - A Step Backwards > > > 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. > > I'm on a nice long train trip right now but I recently got my 11/24 running > again. One thing that baffled me was it would not do anything on the serial > port. No ODT, no nothing. > > Turns out you really need to make sure the slots are filled properly. > The CPU top, then the memory map, then for the next 4 boards one has to > be either a properly configured MS11-PL (the 128kw board) or the memory > boards specific to that type of 11/24. Or you have to put G7273's in the CD > slots. > I have been reluctant to put everything back in, in case the PSU fries something. And the ripple I noticed is certainly something that bothers me. Previously I had a burning smell from the memory board. I have since replaced all the electrolytics on the memory board, but I have not tried putting it back in the machine since. Just checking my notes, it seems I have had *intermittent* lack of activity on the CPU LEDs before, so it may be worth trying to put everything back in, although the ripple makes me hesitant to do so. For the record, right now I have only the M7133, M7134 and G7273 installed. > Next you need proper devices or G7273's in the next two slots and a proper > terminator in the left sockets of the last slots and a G7273 in the center > slots. > Only then will ODT work. > > Another oddity is that the 5.25 inch box has +5 and +12 I think and the > 10.5 has +5 and +15. There are different memory boards that work in one > and not the other, or both depending on jumper settings that have to be > right. Unibus drives me bonkers sometimes with the number of different > voltages requires (+5, +12, +15, +20, -15, etc) It doesn't help that the > +15 > and +12 are on the same pins. > > Plus it's possible someone screwed with some switches, make sure they are > set properly (ie: default is a good start). > > If you're still stuck next week drop me a line and I'll fire up my 11/24 and > see > if I can replicate your failure. > > > > >> > >> 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? (Se
Re: PDP 11/24 - A Step Backwards
On 2022-03-28 15:49, Jonathan Chapman via cctalk wrote: What surprises me (a little) is that there is a commercial outfit willing to work on something so old. It's essentially what we do. I doubt there's a directory of all the small shops that work on legacy equipment, but consider that some of this stuff runs CNC machines that are still in use. Depending on the industry and product, including Nuclear power stations! it's *way* cheaper to keep an old machine that's run not-full-time operational than to retool and recertify. Thanks, Jonathan
Re: PDP 11/24 - A Step Backwards
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.
I'm on a nice long train trip right now but I recently got my 11/24
running again. One thing that baffled me was it would not do anything on
the serial port. No ODT, no nothing.
Turns out you really need to make sure the slots are filled properly.
The CPU top, then the memory map, then for the next 4 boards one has to
be either a properly configured MS11-PL (the 128kw board) or the memory
boards specific to that type of 11/24. Or you have to put G7273's in the
CD slots.
Next you need proper devices or G7273's in the next two slots and a
proper terminator in the left sockets of the last slots and a G7273 in
the center slots. Only then will ODT work.
Another oddity is that the 5.25 inch box has +5 and +12 I think and the
10.5 has +5 and +15. There are different memory boards that work in one
and not the other, or both depending on jumper settings that have to be
right. Unibus drives me bonkers sometimes with the number of different
voltages requires (+5, +12, +15, +20, -15, etc) It doesn't help that
the +15 and +12 are on the same pins.
Plus it's possible someone screwed with some switches, make sure they
are set properly (ie: default is a good start).
If you're still stuck next week drop me a line and I'll fire up my 11/24
and see if I can replicate your failure.
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
RE: PDP 11/24 - A Step Backwards
> -Original Message- > From: cctalk On Behalf Of Antonio Carlini > via cctalk > Sent: 28 March 2022 07:50 > To: cctalk@classiccmp.org > Subject: Re: PDP 11/24 - A Step Backwards > > On 28/03/2022 04:57, Tony Duell via cctalk wrote: > > > > Very little of the stuff I've bought new has had such seals (with some > > things, like my audio equipment, you are _expected_ to remove the > > covers, the user manuals tell you how. They also include the full > > schematics). Ditto test gear (if there is a seal it voids the > > calibration only), computer stuff, etc. > > > > I don't think DEC ever put such seals on their machines when new. > > Certainly not on things like power supplies,] > > > > -tony > > The RZ28 I have right here has the usual "Warranty Void If Broken" seal on > the side. > > In this case the PSU was recently sent off for repair: I'm not surprised it > came > back with a similar sticker. > > They're not trying to stop you looking inside, they're trying not to have to > fix > it again for free after you've fiddled. > > What surprises me (a little) is that there is a commercial outfit willing to > work > on something so old. Me too, but they do! > > > Antonio > > > -- > Antonio Carlini > anto...@acarlini.com
RE: PDP 11/24 - A Step Backwards
> -Original Message- > From: cctalk On Behalf Of Chris Zach via > cctalk > Sent: 27 March 2022 19:48 > To: cctalk@classiccmp.org > Subject: Re: PDP 11/24 - A Step Backwards > > Bigger question is who repaired the power supply "under warranty"? A company called Radwell International. Based near me. They succeeded in getting the PSU to work, which I have been unable to do as it is just beyond me. > > On 3/27/2022 2:38 PM, Bill Gunshannon via cctalk wrote: > > On 3/27/22 05:17, Tony Duell via cctalk wrote: > >> On Sat, Mar 26, 2022 at 11:12 PM Rob Jarratt via cctalk > >> wrote: > >> > >>> Unfortunately, or fortunately, depending on how you look at it, the > >>> PSU repair is under warranty, which means I can't do it myself > >>> without invalidating the warranty, so I will have to send it back. I > >>> don't know if the ripple is caused by the blown part, but I suppose > >>> it is likely. I may be able to inspect it without breaking the seals. > >> > >> That sort of thing would make me very suspicious as to what they've > >> done inside the PSU that they don't want you to see. > >> > > > > Pretty much every electronic device I have ever bought had seals on it > > and a notice that breaking the seals voided the warranty. Even stuff > > with easily replaceable (or upgradeable) components. Nothing unusual > > here. > > > > bill > > > >
Re: PDP 11/24 - A Step Backwards
> What surprises me (a little) is that there is a commercial outfit > willing to work on something so old. It's essentially what we do. I doubt there's a directory of all the small shops that work on legacy equipment, but consider that some of this stuff runs CNC machines that are still in use. Depending on the industry and product, it's *way* cheaper to keep an old machine that's run not-full-time operational than to retool and recertify. Thanks, Jonathan
RE: PDP 11/24 - A Step Backwards
Thanks for the lengthy reply. Some responses inline below. > -Original Message- > From: Noel Chiappa > 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
Re: PDP 11/24 - A Step Backwards
On 28/03/2022 04:57, Tony Duell via cctalk wrote: Very little of the stuff I've bought new has had such seals (with some things, like my audio equipment, you are _expected_ to remove the covers, the user manuals tell you how. They also include the full schematics). Ditto test gear (if there is a seal it voids the calibration only), computer stuff, etc. I don't think DEC ever put such seals on their machines when new. Certainly not on things like power supplies,] -tony The RZ28 I have right here has the usual "Warranty Void If Broken" seal on the side. In this case the PSU was recently sent off for repair: I'm not surprised it came back with a similar sticker. They're not trying to stop you looking inside, they're trying not to have to fix it again for free after you've fiddled. What surprises me (a little) is that there is a commercial outfit willing to work on something so old. Antonio -- Antonio Carlini anto...@acarlini.com
Re: PDP 11/24 - A Step Backwards
On Sun, Mar 27, 2022 at 7:49 PM Bill Gunshannon via cctalk wrote: > > On 3/27/22 05:17, Tony Duell via cctalk wrote: > > On Sat, Mar 26, 2022 at 11:12 PM Rob Jarratt via cctalk > > wrote: > > > >> Unfortunately, or fortunately, depending on how you look at it, the PSU > >> repair is under warranty, which means I can't do it myself without > >> invalidating the warranty, so I will have to send it back. I don't know if > >> the ripple is caused by the blown part, but I suppose it is likely. I may > >> be able to inspect it without breaking the seals. > > > > That sort of thing would make me very suspicious as to what they've > > done inside the PSU that they don't want you to see. > > > > Pretty much every electronic device I have ever bought had seals on > it and a notice that breaking the seals voided the warranty. Even > stuff with easily replaceable (or upgradeable) components. Nothing > unusual here. Very little of the stuff I've bought new has had such seals (with some things, like my audio equipment, you are _expected_ to remove the covers, the user manuals tell you how. They also include the full schematics). Ditto test gear (if there is a seal it voids the calibration only), computer stuff, etc. I don't think DEC ever put such seals on their machines when new. Certainly not on things like power supplies,] -tony
Re: PDP 11/24 - A Step Backwards
On 3/27/2022 11:49 AM, Bill Gunshannon via cctalk wrote: On 3/27/22 14:48, Chris Zach via cctalk wrote: Bigger question is who repaired the power supply "under warranty"? My guess would be whoever fixed it this last time and warranted it. bill I have an Alpha DS-20 retired Feb 2021 that was under service contract thru 3/2021. The PDP 11s are probably actively supported by those who are supporting customers with active systems. Article said use of software and probably hardware thru the rest of the decade. DS-20 was replaced by High Availability configuration Dell servers, Alpha on Intel emulation. No change to OS or software in the migration. Same goes for PDP 11, and possibly this was retired in such a move with remaining warranty. (didn't see where OP got the system. thanks Jim
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? 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
Re: PDP 11/24 - A Step Backwards
On 3/27/22 14:48, Chris Zach via cctalk wrote: Bigger question is who repaired the power supply "under warranty"? My guess would be whoever fixed it this last time and warranted it. bill
Re: PDP 11/24 - A Step Backwards
Bigger question is who repaired the power supply "under warranty"? On 3/27/2022 2:38 PM, Bill Gunshannon via cctalk wrote: On 3/27/22 05:17, Tony Duell via cctalk wrote: On Sat, Mar 26, 2022 at 11:12 PM Rob Jarratt via cctalk wrote: Unfortunately, or fortunately, depending on how you look at it, the PSU repair is under warranty, which means I can't do it myself without invalidating the warranty, so I will have to send it back. I don't know if the ripple is caused by the blown part, but I suppose it is likely. I may be able to inspect it without breaking the seals. That sort of thing would make me very suspicious as to what they've done inside the PSU that they don't want you to see. Pretty much every electronic device I have ever bought had seals on it and a notice that breaking the seals voided the warranty. Even stuff with easily replaceable (or upgradeable) components. Nothing unusual here. bill
Re: PDP 11/24 - A Step Backwards
On 3/27/22 05:17, Tony Duell via cctalk wrote: On Sat, Mar 26, 2022 at 11:12 PM Rob Jarratt via cctalk wrote: Unfortunately, or fortunately, depending on how you look at it, the PSU repair is under warranty, which means I can't do it myself without invalidating the warranty, so I will have to send it back. I don't know if the ripple is caused by the blown part, but I suppose it is likely. I may be able to inspect it without breaking the seals. That sort of thing would make me very suspicious as to what they've done inside the PSU that they don't want you to see. Pretty much every electronic device I have ever bought had seals on it and a notice that breaking the seals voided the warranty. Even stuff with easily replaceable (or upgradeable) components. Nothing unusual here. bill
Re: PDP 11/24 - A Step Backwards
On Sat, Mar 26, 2022 at 11:12 PM Rob Jarratt via cctalk wrote: > Unfortunately, or fortunately, depending on how you look at it, the PSU > repair is under warranty, which means I can't do it myself without > invalidating the warranty, so I will have to send it back. I don't know if > the ripple is caused by the blown part, but I suppose it is likely. I may be > able to inspect it without breaking the seals. That sort of thing would make me very suspicious as to what they've done inside the PSU that they don't want you to see. -tony
Re: PDP 11/24 - A Step Backwards
On Sat, Mar 26, 2022 at 9:20 PM Rob Jarratt via cctalk wrote: > Can anyone suggest what else the CPU might need? Or is it LTC? > I would check the ACLO and DCLO signals. These are both high (pulled up by the bus terminator) for normal running, a PSU can pull them low if it detects loss of mains or whatever. Normally that will halt the CPU -tony
RE: PDP 11/24 - A Step Backwards
> -Original Message- > From: cctalk On Behalf Of Toby Thain via > cctalk > Sent: 26 March 2022 22:07 > To: cctalk@classiccmp.org > Subject: Re: PDP 11/24 - A Step Backwards > > On 2022-03-26 5:20 p.m., Rob Jarratt via cctalk wrote: > > I had the H7140 PSU in my PDP 11/24 repaired a little while ago and I > > posted about it here: > > https://robs-old-computers.com/2022/02/10/pdp-11-24-progress/ > > > > I have since had the PSU fixed again and it came back a couple of weeks ago. > > When I installed it and applied power to the input, I heard a > > reassuring relay click. > > > > So I powered it on. The fans turned, but there was a crackle and I > > smelt something burning. I couldn't locate the smell, there were no > > lights on the CPU board, but the fans continued to turn. > > > > I had to leave it a few days and today I went back to it to check > > things a bit more carefully. All the power outputs of the PSU appear > > nominal. > > However, the ripple seems quite high, with an amplitude of 600mV on > > the +5V > > output: https://rjarratt.files.wordpress.com/2022/03/pin-1-5v-ripple.jpg. > > > > The DC ON light comes on, but the M7133 CPU LEDs show no activity > > whatsoever. > > > > There is no apparent damage to the CPU or to the M7134 that was also > > installed. So, I guess the component that blew up must be inside the PSU. > > Presumably, whatever the part is, it is stopping the CPU working, > > because > > I think the next step would be to inspect the PSU and see if the ripple can be > eliminated, perhaps by replacing whatever blew up :) > Unfortunately, or fortunately, depending on how you look at it, the PSU repair is under warranty, which means I can't do it myself without invalidating the warranty, so I will have to send it back. I don't know if the ripple is caused by the blown part, but I suppose it is likely. I may be able to inspect it without breaking the seals. > --T > > > 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? > > > > > > > > Regards > > > > > > > > Rob > >
Re: PDP 11/24 - A Step Backwards
On 2022-03-26 5:20 p.m., Rob Jarratt via cctalk wrote: I had the H7140 PSU in my PDP 11/24 repaired a little while ago and I posted about it here: https://robs-old-computers.com/2022/02/10/pdp-11-24-progress/ I have since had the PSU fixed again and it came back a couple of weeks ago. When I installed it and applied power to the input, I heard a reassuring relay click. So I powered it on. The fans turned, but there was a crackle and I smelt something burning. I couldn't locate the smell, there were no lights on the CPU board, but the fans continued to turn. I had to leave it a few days and today I went back to it to check things a bit more carefully. All the power outputs of the PSU appear nominal. However, the ripple seems quite high, with an amplitude of 600mV on the +5V output: https://rjarratt.files.wordpress.com/2022/03/pin-1-5v-ripple.jpg. The DC ON light comes on, but the M7133 CPU LEDs show no activity whatsoever. There is no apparent damage to the CPU or to the M7134 that was also installed. So, I guess the component that blew up must be inside the PSU. Presumably, whatever the part is, it is stopping the CPU working, because I think the next step would be to inspect the PSU and see if the ripple can be eliminated, perhaps by replacing whatever blew up :) --T 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? Regards Rob
PDP 11/24 - A Step Backwards
I had the H7140 PSU in my PDP 11/24 repaired a little while ago and I posted about it here: https://robs-old-computers.com/2022/02/10/pdp-11-24-progress/ I have since had the PSU fixed again and it came back a couple of weeks ago. When I installed it and applied power to the input, I heard a reassuring relay click. So I powered it on. The fans turned, but there was a crackle and I smelt something burning. I couldn't locate the smell, there were no lights on the CPU board, but the fans continued to turn. I had to leave it a few days and today I went back to it to check things a bit more carefully. All the power outputs of the PSU appear nominal. However, the ripple seems quite high, with an amplitude of 600mV on the +5V output: https://rjarratt.files.wordpress.com/2022/03/pin-1-5v-ripple.jpg. The DC ON light comes on, but the M7133 CPU LEDs show no activity whatsoever. There is no apparent damage to the CPU or to the M7134 that was also installed. So, I guess the component that blew up must be inside the PSU. 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? Regards Rob
