Is The M9312 Boot Module Essential?

Noel Chiappa jnc at mercury.lcs.mit.edu
Thu Feb 24 22:24:56 CST 2022


First, a minor correction:

    > the M8264 Sack Timeout module ... there's next to nothing in print
    > about them

There is also some coverage in EK-KD11E-TM-001, at: Section 4.7.2.4 "M8264
NO-SACK Timeout Module" (pg. 4-41, pg. 87 of the PDF), which I found while
looking for parity stuff (below).


    > From: Fritz Mueller

    > The KD11-E is pretty bare boned... Parity handling was also a quad "add on".

??? The KD11-E/EA doesn't do much with parity (below), so at first I thought
that maybe you were thinking of the M7850 Parity Controller (which is
actually a memory option, not KD11-E/EA specific; more below), but that's a
dual card.

The KD11-E/EA does not (like most PDP-11's) calculate parity; PDP-11 memory
units do all the work, and signal 'parity error detected' to the CPU over the
UNIBUS (using the PB line); the CPU will trap when it sees that (if enabled;
the KD11-E and -EA can disable recognition of parity errors, with jumpers).

See Section 4.7.2.7, "Parity Errors", in EK-KD11E-TM-001 (at pg. 4-45, pg. 91
of the PDF); the circuit diagram is on page K2-1 of the KD11-E/EA FMPS.

The M7850 has to be in the same backplane as the memory, but that can be a
different backplane from the one holding the CPU. So it can be 15' away, at
the other end of a UNIBUS cable.

Anyway, can you say more about the parity add-on?


    >> So if i) a device requests a grant, and then drops the request at
    >> _just_ the right time ... and ii) there's a break in that grant line
    >> ... before it gets to the M9302, which can turn it around as a SACK ,
    >> then ... the KD11-E CPU will hang!

    > I believe a broken grant chain with an M9302 in place on the far side
    > results in the grant being pulled up at the M9302, and then continuous
    > assertion of SACK, hanging the processor straight out the gate.

Oh, right you are! (I'm glad _your_ brain is runed on - unlike mine! :-)

I happen to have an -11/04 (the -11/34's sibling) on the bench in my work
room, with one of Guy's very useful UA11's plugged into it. (BTW, the UA11:

  http://www.shiresoft.com/products/ua11/Unibus%20Analyzer.html

is fantastically useful as a UNIBUS debugging tool. Everyone working on
UNIBUS machines should have one.) So I thought I'd go try an experiment.


It turned out to be a bit more complicated than I thought, but you're
basically right: a break in the grant lines (e.g. missing grant continuity
card) causes the downstream card to 'see' 'phantom' incoming grants (open TTL
inputs float high), and signal a grant on from there; and if there's an M9302
at the end of the bus, it will see that and jam SACK on.

The complication was that when I powered the machine on, it turned out that
something was asserting SACK when the machine was halted; if I put it into a
'BR .' loop, that goes away. I looked, and the KD11-D doesn't even _have_ a
SACK driver! So I tried un-plugging the KY11-LB, and the 'SACK on halt' went
away. (That machine has core, and I set the power-on vector to halt the
machine.)

Looking at the KY11-LB manual, it does in fact assert SACK (after it has sent
the KD11 a 'halt request, and receives a 'halt acknowledge'), to recognize
the CPU's acknowledgement of the halt request. (I have yet to check and see if
the KY11-LB asserts SACK if the CPU halts on its own accord - probably 'yes',
but that's a project for tomorrow.)


The thing that's puzzling me is that the M8264 seems to exactly replicate the
functionality of the M9302, with an 'unused' bus grant being turned into a
SACK. So I don't understand the point of the M8264. Whether the cause of the
grant is a rare timing window of a bus request being cancelled, or a broken
grant line; with an M9302 in the system, a SACK will result. 

The only difference between the two is that because of the way grant lines
are wired, the M8264 will not respond to a broken grant line 'downstream' of
the M8264.

The M8264 does add this capability to a system using an M930 terminator - but
just switching to an M902 would be simpler. And the M9302 pre-dates the
M8264, as we can see from EK-11034-OP-PRE2. So I'm really quite confused as
to what the point of the M8264 was.

   Noel


More information about the cctech mailing list