PDP 11/24 - A Step Backwards

[Brent Hilpert]

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.