On 2015-04-26 22:22, John Wilson wrote:
From: Johnny Billquist <bqt at softjar.se>
I'm curious on exactly how a DEUNA/DELUA
works in a KS-10. Does anyone
know? Does it do 8-bit-byte DMA to the 18-bit memory, leaving the top
two bits alone. Or does it only work if it do word DMA (would be
strange, as the controller itself can send and receive odd byte length
ethernet packets).
This is what the BLTBU and BLTUB instructions are for in the later microcode
(converting between sensible PDP-10 memory and the mishmash you get as a
result of DMA through the UBA to a 16-bit peripheral). Since a DELUA is
not 18-bit-data-aware, it ignores the high two bits of each 18-bit halfword
when doing DMA.
That would be nice...
Is there some
potential problem with regards to a PDP-11, which have two
parity bits for data, which are used for actual data on a KS? (If I
remember right.)
IIRC you're OK as long as you don't set those bits in memory that the DELUA
will read. I feel like the Unibus documentation changed at some point,
between whether PA/PB are actual parity bits (I think that's what the very
early doc said), vs. being parity *error* bits (and I think PB isn't even
really used -- PA asserted means there's been a parity error detected in the
current DATI/DATIP). I could be wrong about all of this.
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. 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...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol