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
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
