Is The M9312 Boot Module Essential?

[Mattis Lind]

What about the M9300 board? Do you have an idea what the purpose is of that
card? It look a bit like a M9302 but with more logic on it and a few
jumpers and a LED. It also have a delay line and a monostable flip-flop.

Here is a photo of a (dusty) M9300:
http://forum.datormuseum.se/data/B21AEA95-02C2-402B-BC97-06790BAEDC88/84B52290-D267-46C8-8B65-1A3EFEF7916B.jpg

/Mattis

fredag 25 februari 2022 skrev Noel Chiappa via cctalk <cctalk at classiccmp.org
>:

> 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
>