Is The M9312 Boot Module Essential?

First, a minor correction: 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). ??? 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? 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