First, a minor correction:
the M8264 Sack Timeout module ... there's next to
nothing in print
There is also some coverage in EK-KD11E-TM-001, at: Section 184.108.40.206 "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
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 220.127.116.11, "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:
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
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
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 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.