When I looked at that ebay listing of "glass memory" it pointed me to another item, https://www.ebay.com/itm/265623663142 -- described as "core rope memory". Obviously it isn't -- it's conventional core RAM. Interestingly enough, it seems to be three-wire memory (no inhibit line that I can see). It looks to be in decent shape. No manufacturer marks, and "GC-6" doesn't ring any bells.
paul
> 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
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
> From: Tony Duell
> A short in FET Q15 on the bias/interface board in the PSU could do it.
> The gate of that FET is driven from an LM339 comparator the -ve supply
> of which is -15V.
Ah; I hadn't even looked at the P/S prints.
(Like I said, I'm really weak on analog: for digital, I have the advantages
that i) although I'm basically/mostly a software person, the MIT CS
department is part of the EE department, and they made sure that all the CS
people had a decent grounding in the fundamentals of digital hardware; and
ii) in my early years, I was involved in a number of actual hardware
projects, including a UNIBUS DMA network interface that tuned into an actual
product. So I'm pretty good with a digital circuit diagram, like these CPU
prints. But analog stuff is still a mostly-closed book to me! :-)
Anyway, I'm happy to let you provide the analysis of the P/S... :-)
> From: Rob Jarratt
> [Perhaps] something else on the CPU caused Q15 to fail (if indeed it
> did).
I'd guess 'unlikely' (if Q15 has failed); UNIBUS ACLO is connected, on the CPU
card, to only a single gate (on K2), and that 383 ohm pull-up (on K3), and the
1K pF cap there (the purpose of which I still don't understand, unless it's
just a smoother). Although I suppose that if that cap failed, shorted, maybe
that could have taken out Q15 somehow.
> Perhaps I should ... and disconnect ACLO, DCLO and LTC, they are all on
> the same connector
Now why didn't I think of just un-plugging that whole connector! Duhhhh! My
only concern would be leaving inputs floating...
DCLO, no problem; it has that pull-up on K3. (Ditto for ACLO, if the buffering
input gate isn't dead.) LTC, let's see... It's on K6, upper left corner. I'm
too lazy to work out what leaving that input floating will do, and, if it has
bad consequences, trace out all the places it goes (it should be connected up
to cause an interrupt, somewhere), but there's no point; the KW11 has an
'interrupt enable' that has to be set by software before it can do anything;
so at the moment it's safe to just ignore it for now, and stay with a focus on
getting the main CPU clock running. (LTC is not on the UNIBUS, so there's no
pull-up on the M9302 for it the way there is for ACLO & DCLO.)
So unplug that connector, and see if E70 (on K2, lower right corner) is OK.
(Remember, the pull-up will give it an Ok input with BUS ACLO disconnected.)
If yes, great, go check the main CPU clock.
If not, time to i) see how far the rot has spread (e.g. have other gates in
that package died - not sure what else is in there; not just looking at things
connected to the output - on pin 2), and ii) decide how to repair or
temporarily bypass. (Ditto for anything else that got taken out.) I'd be
tempted to bypass it (since I doubt you stock 8837's - although I do :-) -
ACLO handling isn't needed to get the CPU running. Tie BUF (not BUS!) ACLO to
ground, I'd say, and we can move on to look at MCLK.
> If that works then I think repair ACLO and see if anything on the CPU
> is bad or anything else that might cause a short on the ACLO signal of
> the bus.
Well, your call, but i) working ACLO isn't needed to get the CPU running -
and, in particular, to look for other problems that might be preventing it
>from running, and ii) fixing ACLO isn't guaranteed to make the CPU work.
I'd recommend 'keeping the eye on the ball', and focus on the main CPU clock,
getting ODT running, etc. The ACLO issue(s) can be cleaned up at your leisure.
Noel
> 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
> 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 just stops the clock temporarily: DCLO asserted resets
> E67/K2_PFAIL, clearing it to register another ACLO / P FAIL.
Could be; that's something else I don't understand completely; that flop's
clear input depends on part on DGP06, which comes out of the E46 decoder on
K1, which is again driven by the microcode. I'll have to look at the TM, and
see if it explains that.
> I thinks he's right to poke around the clock circuitry looking for
> where the clock is being inhibited.
Yup. I was hoping that if we just disconnected the busted ACLO, the clock
would spring to life, and then we could move on to the next step(s), but
maybe looking into that block in detail, e.g. to see if E41 is being reset by
DCLO, would be the best way to go.
Noel
> 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
> 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
