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