PDP 11/24 - A Step Backwards

[Noel Chiappa]

    > 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