[HECnet] TOPS-10 KS10 Ethernet Monitor

[John Wilson]

From: Johnny Billquist <bqt at softjar.se>

>I seem to remember having read that they were parity for each byte, but 
>looking at a Unibus spec now (from 1979), it seems PB is actually 
>indicating a parity error, while PA is reserved for future use.

OK I had PA and PB reversed, but, exactly.  I don't know if that means
PA/PB had a slightly different meaning in the early days when the parity
controller was outboard of the core stacks (in that case I'd think you
couldn't mix old and new hardware, which doesn't seem to be a problem),
or else they changed the spec before the hardware hit the streets and
everything is fine (which sounds more like it).

>And the 
>slave are expected to generate these signals, and the master is expected 
>to check them, so I guess the DEUNA/DELUA should generate/check them, if 
>it is a proper Unibus citizen. Which could make life in a KS interesting...

Well, my point is that if it's true that PB is now asserted only on an error
(vs. both being asserted or not depending on the parity of that byte),
then if it *never* gets asserted, everything's fine.  Accesses to CSR space
certainly don't check parity so it seems that nothing bad happens if you
don't assert these pins.  And I'm thinking the DEUNA/DELUA would stop with
a parity error if it found PB asserted when reading memory with DMA, which
is a good reason to make sure the data structures and buffers you give it
never have the 17th/18th bits set, but otherwise, no sweat.  You're giving up
parity checking but the KS10 MMC/MMAs already do ECC and I don't think they
need Unibus masters to be in charge of noticing flaky RAM.

John Wilson
D Bit