The UC15 is an 11/05 with part of its address space mapped into PDP15
memory, and a small amount private. It allows bidirectional writes.
There is also a control link, basically two parallel interfaces tied
together.
The key difference with the Rubin 10-11 is that the PDP15 does not
access PDP11 IO space. While it's possible that it worked, the Unibus
interface only supported DATI and DATO. Without DATOB (and DATIP), some
IO devices simply wouldn't function correctly. IO was done via Task
Control Blocks, and the transmission was sychronized on the control
interface (effectively, properly interlocked).
In the UC15, the PDP11 is unaware of changes made in shared memory by
the PDP15; it is only aware (via polling) of changes on the control
link. Memory sharing only applies to "real" memory. IO space is
invisible to the PDP15.
Aside from this issue, the PDP15/UC15 devotes a process (core) to each
CPU. That's fine for two; it's rather problematic for nine (KA10 + 8
PDP11s). The shared memory interface must be within the same physical
machine; it won't work across a network link.
I finally published the paper on the UC15 design; find it here -
http://simh.trailing-edge.com/docs/TheDesignoftheSimulatedPDP1576.pdf
/Bob
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
