24 Feb
2022
24 Feb
'22
8:24 p.m.
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
24 Feb
24 Feb
11 p.m.
On Feb 24, 2022, at 8:24 PM, Noel Chiappa via cctalk
<cctalk at classiccmp.org> wrote:
? 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.
Yes, I was thinking of the M7850, but I had forgotten this was just a dual card!
I think I had come to think of it as a CPU option because at some point during the /34
restoration that I did last year I got to the place of ?oh, I needn?t bother trying to
running the parity MAINDECs because I don?t have an M7850?, which felt sort of like ?I
needn?t bother trying to run floating point MAINDECs because I don?t have floating
point...? So alas, nothing exotic for you here, Noel -- just some sloppy thinking on my
part :-)
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.
That is quite interesting, and not what I would have expected!
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 ran into this when I started using one of Jeorg?s ?Unibone? cards with my /34. When the
Unibone is in place and jumped to take grants, those grant chains are open at power up
until the Unibone?s own control software can boot. So after power on my machine (w/
KY11-LB) would be jammed and inoperable from the front panel until the Unibone was
booted.
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.
I think the only difference would be that since the M8264 is timer based, it doesn?t need
the intact end-to-end path required for turnaround. So your bus won?t lock even if you
have a broken grant chain or a poorly behaved or hung device eating grants. I think my
/45 has this built-in (will check later). I would *guess* that the M9302 was just a ?poor
man?s SACK timeout?, and the 8264 was offered later to shore that up to a real timeout for
applications where it mattered?
cheers!
?FritzM.
11:28 p.m.
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/84B52…
/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
25 Feb
25 Feb
7:08 a.m.
That module was specifically called for in the RH11-AB dual-port Unibus-to-MASSBUS
interface as the Unibus B terminator. See RH11-AB_OptionDescr.pdf, Section 4.24 (page
4-32/33), which has a fairly lengthy write-up.
-----Original Message-----
From: cctalk <cctalk-bounces at classiccmp.org> On Behalf Of Mattis Lind via cctalk
Sent: Friday, February 25, 2022 2:29 AM
To: Noel Chiappa <jnc at mercury.lcs.mit.edu>; General Discussion: On-Topic and
Off-Topic Posts <cctalk at classiccmp.org>
Subject: Re: Is The M9312 Boot Module Essential?
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/84B52…
/Mattis
791
days inactive
791
days old
3 comments
4 participants
participants (4)
-
fritzm＠fritzm.org -
jnc＠mercury.lcs.mit.edu -
mattislind＠gmail.com -
pbirkel＠gmail.com