[Simh] Simulating the PDP-15/76 Unichannel

[Bob Supnik]

No. All Unibus IO is initiated by PIREX, the 11 IO executive. It is 
transferred, byte-by-byte or word-by-word, to/from buffers in the common 
shared memory. So, for example, to print to the LP11:

1) PDP-15 sets up a properly formatted 8b byte-packed buffer in common 
memory.
2) PDP-15 sets up a task control block (TCB) to print the buffer. The 
TCB is also in common memory.
3) PDP-15 pokes the PDP-11 via the DR15-C, passing in the address of the 
TCB.
4) PDP-11 invokes the LP11 "task" in PIREX, which pulls data from the 
buffer and sends it to the printer.
5) At completion, the PDP-11 posts an API interrupt back to the PDP-15 
via one of the two DR11-C's.

/Bob

On 3/17/2015 11:42 AM, Mark Pizzolato - Info Comm wrote:
> On Monday, March 16, 2015 at 2:19 PM, 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.
> Clearly the DR15/11 paradigm passing through PIREX is necessary for DMA devices, but how is programmed I/O handled.
>
> With the whole Unibus space addressable from the 15 side, is there code on the 15 which actually does programmed I/O directly to the Unibus devices?  If programmed I/O is done directly by the 15, then this whole problem is very different than one which relates to shared memory access.
>
> - Mark