[Simh] Simulating the PDP-15/76 Unichannel

[Bob Supnik]

The difference is that the RQDX3 firmware was in PROM and was not 
modifiable. PIREX executed in core and was expected to be modified. In 
fact, if the 15/76 had a non-standard IO configuration, PIREX had to be 
modified as part of the system generation process.  Still, something to 
be considered.

On 3/17/2015 9:41 PM, Mark Pizzolato - Info Comm wrote:
> I was just going to ask questions which you answered below.
>
> As long as you've got things running in separate processes, there are no name collisions since they are separate simulator instances.  You'll certainly need a memory reference paradigm which is more complicated than merely referencing the array M since there will be two blocks of memory (non-shared and shared).  Other simulators already have separate address ranges which map to different things (VAX RAM, ROM, Qbus memory, etc...).
>
> Given the High Level synchronization operations (through the DR15/DR11) it won't be hard to assure memory coherency.  Since your development platform is Windows, we can come up with a simple API to create a shared memory window and we'll worry about porting to other platforms later.
>
> OR YOU CAN STEP BACK and look at the problem differently:
>
>  From the model you have describe it seems that the PDP-11 side is merely a slave to the activities on the PDP-15 side.
>
> Wasn't the RQDX3's processor a member of the PDP11 family?  We don't try to execute the RQDX3 firmware, but we merely have a device simulator that communicates across the bus just as the RQDX3 did.  Would an approach make sense that implemented the PIREX behaviors in a DR15 simulation (possibly, internally talking to the various UNIBUS device simulations)?
>
> Just a wild idea...
>
> - Mark
>
> On Tuesday, March 17, 2015 at 1:33 PM, Bob Supnik wrote:
>> Memory semantics on the 15/76 were very simple. Neither machine had
>> cache; neither machine had overlapped instruction execution; and neither
>> system had locking capabilities. Therefore, the only ordering constraint is
>> this:
>>
>> - all memory writes in common memory must be visible (committed) before
>> either system issues an IO instruction to the DR15 or DR11 (which pokes the
>> other system).
>>
>> That's because the ordering is based on the following software model:
>>
>> PDP15:
>> - set up Task Control Block, set up buffers, pointers, etc.
>> - write TCB address to the PDP11 via the DR15.
>>
>> At the point the TCB address is written, everything written to common
>> memory must be visible to the PDP11.
>>
>> PDP11:
>>
>> - process TCB, do IO (either DMA or programmed IO)
>> - post an IO completion interrupt back to the PDP15 via the DR11.
>>
>> At the point the interrupt is posted, everything written to common (or
>> PDP15 non-common) memory must be visible to the PDP15.
>>
>> For a "mashed up" implementation, I don't think the memory container size
>> difference is insurmountable. The PDP11 already abstracts memory access to
>> routines like Read/Write or Map_Read/Write. These can be conditionally
>> compiled as needed. The RK11 likewise would require relatively little work,
>> mostly in abstracting the data type used for rkxb, the transfer buffer.
>>
>> As I said, the real problem is the global name space conflict. I didn't write the
>> code with the expectation of mashups, so every simulator has a global M for
>> memory, a global PC for the program counter. Because of code cloning,
>> there tend to be lots of subroutines with the same names in every simulator.
>> It's not insurmountable, because very little of the
>> PDP11 is needed, but it's tedious and painstaking, and I don't want to end up
>> having to retest the PDP-11 from scratch. That's why I ended up with five
>> separate DECtape implementations rather than give skeletons and a
>> common device library - it was easier at the time to clone and modify than to
>> conditionalize.
>>
>> /Bob