[Simh] Simulating the PDP-15/76 Unichannel

[Johnny Billquist]

On 2015-03-16 22:19, Bob Supnik wrote:
> This has been on the wish list for a decade.
>
> The 15/76 Unichannel was a big PDP-15 that used a PDP-11/05 as an IO
> processor to get access to inexpensive Unibus peripherals, particularly
> the RK11-E/RK05, which supported 18b data, the LP11, the CR11, and
> various plotters (not supported in SimH). XVM/DOS and XVM/RSX supported
> the Unichannel, and standard DOS probably did as well.
>
> The 15 and the 11 are crosscoupled through shared memory. Except for
> 4K-12K(W) of local memory, all of Unibus address space is mapped into
> the 15's main memory. DMA transfers from the RK11-E could transfer 18b
> data (using the Unibus parity lines for extra data lines); programmed IO
> transfers from the IO processor transferred 16b data, zeroing out bits
> 0-1 on the 15.
>
> Control is done by a DR15-C parallel interface cross-connected to two
> DR11-C's in the 11. The 15 created task blocks in shared memory and
> transfers an 18b pointer to the 11 via the DR15/11 parallel connection.
> The 11's IO program, called PIREX, executes the directive and sends an
> API interrupt back when done.
>
> Booting is awkward but didn't happen often; both machines had core
> memory that preserved program images.
>
> The method for simulating multiple processors was demonstrated ten years
> ago, but it assumed a from-the-ground-up implementation. Mashing two
> simulator sources together creates serious global variable collisions
> that cannot be resolved without extensive edits to one or the other
> (probably the 11). This is why the HP 2100 Access dual system
> configuration is simulated on two separate simulator instances that
> communicate by TCP/IP. This is not practical for the 11/76 Unichannel,
> because of the shared memory.
>
> Before I venture on a detailed design of a "merged" 15/11 simulator, I
> had one other thought. On today's multi-cores, it's perfectly practical
> to have two simulators running side-by-side, controlled from separate
> terminal windows. However, the two processes would need to share memory.
> Is there some simple way to do this on both Windows and Linux? I'm sure
> there's no portable solution.

One obvious answer is shared memory. Unix sortof supports this, but it's 
a SysV extension that not all have.
And I bet it will not at all port easily to Windows.

(Had you asked about doing this under RSX, it would have been super 
easy, Bob, but I guess that will not help you at all... ;-) )

I suspect mmaping files under Unix might also give you something akin to 
shared memory, but once more, I seriously doubt that will port to Windows.

In short, I am not aware of any portable way of doing this. There are 
definitely non-portable solutions, though.

Maybe create an abstract layer for simh shared memory, which you then 
use. And then you just need to port the shared memory module between 
OSes, and do things in which ever way it should be done on that OS.

	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