[Simh] Simulating the PDP-15/76 Unichannel

[Bob Supnik]

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.


/Bob
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [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: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Mark Pizzolato - Info Comm]

On Monday, March 16, 2015 at 2:19 PM, Bob Supnik wrote:
> 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.

Almost all (if not all) current simh host platforms have a paradigm for sharing 
memory between processes.  It would be relatively simple to come up with a 
generic simh API  to create or connect to a shared memory region.  The harder 
part would be to provide synchronized access and update primitives referencing 
such a shared memory region which provided one (or potentially more) different 
expected semantics which reflect the behaviors of the hardware being 
simulated...

- Mark
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Clem cole]

Unix at least three shared memory API's the old Columbus Unix shmem(which came 
out in the ATT stream - a lot of Unix have it but it's messy), the tenex mmap 
scheme (BSD's - which is cleaner and fewer side effects IMO) and eventually 
posix defined one that is suppose to be better still (but I don't know of a 
major ISV that uses it).  


The good news is that  I can't think of a modern Unix that does not support at 
least one of them.  Windows supports the first two in SFU in fact (which has a 
new name which I forget) and probably has the posix one also. There is supposed 
to be something like the old VMS shared memory API in Win32 but I've never 
messed with it - while I have used SFU. 

There is another SHMEM API which Cray defined in the mid 80's for PGAS style 
programming and has little in common with the old AT&T scheme other than name.  
It has a different syntax and semantics.  This lives today as the OpenSHMEM 
project and as mostly syntax complainant although semantically there are still 
some rough edges. In fact the OpenSHMEM folks just released a new version of 
the spec which is being ratified this week. I fear that is only Linux and the 
high end HPC systems support it but it probably had the richest interface and 
would be both performant and functional.  

We can talk off list if you want some of the nitty gritty of the differences.  
I suspect the answer is to define an API that works well for simh and then we 
can figure out how to implement it for each target OS.  Some OS will be able to 
have a choice of more than one so then it becomes a performance / operational 
choice. 

Sent from my iPhone

> On Mar 16, 2015, at 5: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.
> 
> 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.
> 
> /Bob
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Clem cole]

Yup. That's why I said look at OpenSHMEM. That's all in there since PGAS 
requires it. 

Sent from my iPhone

> On Mar 16, 2015, at 5:31 PM, Mark Pizzolato - Info Comm  
> wrote:
> 
>> On Monday, March 16, 2015 at 2:19 PM, Bob Supnik wrote:
>> 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.
> 
> Almost all (if not all) current simh host platforms have a paradigm for 
> sharing memory between processes.  It would be relatively simple to come up 
> with a generic simh API  to create or connect to a shared memory region.  The 
> harder part would be to provide synchronized access and update primitives 
> referencing such a shared memory region which provided one (or potentially 
> more) different expected semantics which reflect the behaviors of the 
> hardware being simulated...
> 
> - Mark
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[E. Groenenberg]

> 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.
>
> /Bob
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

Bob,

Any current & reasonably seasoned Unix or derivative has shmat() & shmdt()
(or equivalent) calls for attaching & detaching a segment of a given size.

Also MS$ has this
(https://msdn.microsoft.com/en-us/library/windows/desktop/ms686958%28v=vs.85%29.aspx)
so a common API for SIMH would be fairly easy.

Linux   : shmat() / shmdt()
SunOs   : shmat() / shmdt()
BSD : mmap()  / munmap()
FreeBSD : shm_open() / shm_unlink()
NetBSD  : shm_open() / shm_unlink()

With this feature, it would probably also easy to realize a PDP-11/74
with 4 instances of SIMH.

Regards,

Ed
-- 
Dit is een HTML vrije email / This is an HTML free email.
Zeg NEE tegen de 'slimme' meter.

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Sergey Oboguev]

> From: E. Groenenberg 
>
> Any current & reasonably seasoned Unix or derivative has shmat() & shmdt()
> (or equivalent) calls for attaching & detaching a segment of a given size.
>
> Also MS$ has this
> [...]
> so a common API for SIMH would be fairly easy.
>
>[ ...]
>
> With this feature, it would probably also easy to realize a PDP-11/74
> with 4 instances of SIMH.

Mapping shared memory segment into the address spaces of multiple SIMH
instances is the straightforward part.

More intricate parts are:

1) Mapping guest memory-consistency model to host memory-consistency model.

Does legacy software expect to observe updates to the shared memory executed
by simulated VCPU1 (or virtual IO processor) to become observable by VCPU2
in the same order they were executed by VCPU1? If yes, this would not work
(without special handling by the simulator) on modern machines with weaker
memory-consistency model.

What is the cache coherency protocol of the simulated system and how does it
map to the host system?

Does simulated system have any system events (such as inter-processor
interrupts or IO completion) that affect cache synchronization between VCPUs
or VCPUs/VIOPs, and if yes, how this is to be mapped to the simulator?

Ultimately it all depends on exact actual synchronization patterns utilized
by legacy software.

2) Mapping memory atomicity.

Does host machine provide the same memory access atomicity and separability
as the simulated machine? For instance, if a simulated machine provides a way
to update a byte at address A without interfering with concurrent updates to
bytes at A-1 and A+1 by other VCPUs, then this would take a special effort
to be implemented on a host machine that has let us say a 4-byte word as
the minimum separable unit. Ditto for atomic and separable 2-byte word
accesses (atomicity would mean that concurrent writes to the word do not
result in resultant bytes values coming from different writes,
separability would mean that concurrent writes to neighbor words do not
interfere with each other).

3) Does a simulated system have any synchronization facilities such as
interlocked instructions or machine-specific registers that affect cache
coherency?

4) Mapping execution model.

What happens if a host system thread simulating the execution of VCPU1 (or
virtual IO processor) gets preempted, while VCPU2 is waiting for a response
from VCPU1? Does the simulated system (specifically, its legacy software)
rely on finite timeouts?
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[E. Groenenberg]

>> From: E. Groenenberg 
>>
>> Any current & reasonably seasoned Unix or derivative has shmat() &
>> shmdt()
>> (or equivalent) calls for attaching & detaching a segment of a given
>> size.
>>
>> Also MS$ has this
>> [...]
>> so a common API for SIMH would be fairly easy.
>>
>>[ ...]
>>
>> With this feature, it would probably also easy to realize a PDP-11/74
>> with 4 instances of SIMH.
>
> Mapping shared memory segment into the address spaces of multiple SIMH
> instances is the straightforward part.
>
> More intricate parts are:
>
> 1) Mapping guest memory-consistency model to host memory-consistency
> model.
>
> Does legacy software expect to observe updates to the shared memory
> executed
> by simulated VCPU1 (or virtual IO processor) to become observable by VCPU2
> in the same order they were executed by VCPU1? If yes, this would not work
> (without special handling by the simulator) on modern machines with weaker
> memory-consistency model.
>
> What is the cache coherency protocol of the simulated system and how does
> it
> map to the host system?
>
> Does simulated system have any system events (such as inter-processor
> interrupts or IO completion) that affect cache synchronization between
> VCPUs
> or VCPUs/VIOPs, and if yes, how this is to be mapped to the simulator?
>
> Ultimately it all depends on exact actual synchronization patterns
> utilized
> by legacy software.
>
> 2) Mapping memory atomicity.
>
> Does host machine provide the same memory access atomicity and
> separability
> as the simulated machine? For instance, if a simulated machine provides a
> way
> to update a byte at address A without interfering with concurrent updates
> to
> bytes at A-1 and A+1 by other VCPUs, then this would take a special effort
> to be implemented on a host machine that has let us say a 4-byte word as
> the minimum separable unit. Ditto for atomic and separable 2-byte word
> accesses (atomicity would mean that concurrent writes to the word do not
> result in resultant bytes values coming from different writes,
> separability would mean that concurrent writes to neighbor words do not
> interfere with each other).
>
> 3) Does a simulated system have any synchronization facilities such as
> interlocked instructions or machine-specific registers that affect cache
> coherency?
>
> 4) Mapping execution model.
>
> What happens if a host system thread simulating the execution of VCPU1 (or
> virtual IO processor) gets preempted, while VCPU2 is waiting for a
> response
> from VCPU1? Does the simulated system (specifically, its legacy software)
> rely on finite timeouts?
>

Sure, there are indeed other concerns.

Concerning the mapping, this depends on how SIMH looks at host memory
from a simulated system. If the memory is directly mapped, i.e.
1Mb of simulated system memory maps directly to 1Mb of host OS memory,
it would be easier. If not, it indeed makes it more complex.

Some form of messaging or synchronization would indeed be required,
this could be done f.e. using msg calls (or equivalents), or
use a dedicated small area in the shared memory segment for locking,
using atomic locking instruction (i.e. xchgb instruction for x86 based
processors or ldstub on sparc based processors)

Ed


-- 
Dit is een HTML vrije email / This is an HTML free email.
Zeg NEE tegen de 'slimme' meter.

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Clem Cole]

On Tue, Mar 17, 2015 at 5:25 AM, E. Groenenberg  wrote:

> Some form of messaging or synchronization would indeed be required,
> this could be done f.e. using msg calls (or equivalents), or
> use a dedicated small area in the shared memory segment for locking,
> using atomic locking instruction (i.e. xchgb instruction for x86 based
> processors or ldstub on sparc based processors)
>

​Ed,

Exactly - its more than just the shared address space, you need messaging,
sequencing, sync etc. - this is why I was suggesting that instead of
reinventing an API for simh, using one  that has already been worked and
agree upon by the HPC community.  Since HPC is all about performance, I
would have a solid belief that not only will the primitives work, but they
will offer some of the highest efficiency for the code.

At the risk of sounds like a fan-boy for OpenSHMEM, it seems to me to be
the best of the PGAS family (particularly since it's a library not a new
language like Chapel or UPC).   I would be surprised if it did not have all
of the things that Bob desired/needs built-in.  In fact, one of the recent
additions to OpenSHMEM is the new "counting puts" API which is a
distributed (and scalable) locking and synchronization scheme similar to
the old eventcount scheme of Reed & Kanodia for UP systems [
http://dl.acm.org/citation.cfm?id=359076]. The implementations of these
primitives map well to the instructions level that you point out.

That said, if you stay with strict POSIX API instead, I suspect between
their shared memory and locking/semaphore primitives, you will be pretty
close and i think you should get a solid level of portability.  My two
concerns that that strategy are how many of the OSs have actually
implemented the POSIX primitives, and when they have, how good a job was
done implementing them.   Not that the HPC community is perfect, but they
tend to have an incentive to get the performance aspect right.

Clem
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Johnny Billquist]

On 2015-03-17 08:36, Sergey Oboguev wrote:

From: E. Groenenberg 

Any current & reasonably seasoned Unix or derivative has shmat() & shmdt()
(or equivalent) calls for attaching & detaching a segment of a given size.

Also MS$ has this
[...]
so a common API for SIMH would be fairly easy.

[ ...]

With this feature, it would probably also easy to realize a PDP-11/74
with 4 instances of SIMH.


Mapping shared memory segment into the address spaces of multiple SIMH
instances is the straightforward part.


Actually, it might be less trivial than first thought...

There is a problem in that different emulators might use a different 
layout for memory, that you somehow need to overlap when you come here. 
And that layout can become rather weird, and how do you actually figure 
this out.


Remember, this thread started with the explicit wish to deal with the 
PDP-15 and PDP-11 sharing memory. The PDP-15 uses 18-bit memory, while 
the PDP-11 uses 16-bit memory. Now we need a way to map addresses 
between the two, while the size of each memory word differs.


IN a way, you need to say that address X on the PDP-15 is address Y on 
the PDP-11. Now, address X+1 on the PDP-15 (18 bits), needs to map to 
address Y+2 on the PDP-11 (16 bits, but with 8-bit addressable units).

And in this, what does Y+1 on the PDP-11 map to?


More intricate parts are:

1) Mapping guest memory-consistency model to host memory-consistency model.

Does legacy software expect to observe updates to the shared memory executed
by simulated VCPU1 (or virtual IO processor) to become observable by VCPU2
in the same order they were executed by VCPU1? If yes, this would not work
(without special handling by the simulator) on modern machines with weaker
memory-consistency model.


Correct. And yes, order will be important in most cases.


What is the cache coherency protocol of the simulated system and how does it
map to the host system?

Does simulated system have any system events (such as inter-processor
interrupts or IO completion) that affect cache synchronization between VCPUs
or VCPUs/VIOPs, and if yes, how this is to be mapped to the simulator?

Ultimately it all depends on exact actual synchronization patterns utilized
by legacy software.


I'll just go for the easy case here to start with. You normally do not 
have cache coherency in these old machines. In most cases, you do not 
even have caches.
And in the case systems do have caches, it's mostly write through, not 
write back.
So memory always holds the "correct" data immediately. MP systems had to 
know when there was a potential for cache problems, and work around it 
explicitly.


If we start trying to emulate machines that do have caches, we'll have 
to choose to either implement our own caching layer, in order to emulate 
the cache correctly, or else accept the behavior of the cache of the 
host machine. All modern machines implement cache coherency, so in 
essence you'll get the same effects as if you had no cache. In short, 
things work correct, and you never have broken cache coherency on modern 
machines, and you will not get any issues in normal simulation.


The write order might cause more problems though, if data is updated in 
a different order than you write it, on another CPU. That might require 
that you start playing with memory barriers, which will hurt performance.

But I don't see any way around this, if it becomes a problem.


2) Mapping memory atomicity.

Does host machine provide the same memory access atomicity and separability
as the simulated machine? For instance, if a simulated machine provides a way
to update a byte at address A without interfering with concurrent updates to
bytes at A-1 and A+1 by other VCPUs, then this would take a special effort
to be implemented on a host machine that has let us say a 4-byte word as
the minimum separable unit. Ditto for atomic and separable 2-byte word
accesses (atomicity would mean that concurrent writes to the word do not
result in resultant bytes values coming from different writes,
separability would mean that concurrent writes to neighbor words do not
interfere with each other).


Good point. That needs to be found out on the simulated machines first, 
on how it actually behaves.



3) Does a simulated system have any synchronization facilities such as
interlocked instructions or machine-specific registers that affect cache
coherency?


The cache coherency is not something I would worry too much about here. 
The host machine will essentially give you an environment where you 
never have inconsistent caches at the host level, and therefore not at 
the memory level either.
If the simulated machine have special handling to deal with potential 
cache incoherencies in the original machine design, those will just 
become like NOOPs in the simulated environment, since the cache will 
always be coherent.
(Unless we start emulating the cache layer, at which point we can do 
whatever we want.)



4) Mapping execution model.

Re: [Simh] Simulating the PDP-15/76 Unichannel

[khandy21yo]

Handle the sgatrd memory likre device regosrrrs. Vapyirr rradd and erites yo 
the dhared memoty amf  ley code in simh hamfle the fetails og mappinh betweem 
yhe figgerent gormats.



Sent from Samsung tablet

 Original message 
From Johnny Billquist  
Date: 03/17/2015  9:16 AM  (GMT-07:00) 
To simh@trailing-edge.com 
Subject Re: [Simh] Simulating the PDP-15/76 Unichannel 
 
On 2015-03-17 08:36, Sergey Oboguev wrote:
>> From: E. Groenenberg 
>>
>> Any current & reasonably seasoned Unix or derivative has shmat() & shmdt()
>> (or equivalent) calls for attaching & detaching a segment of a given size.
>>
>> Also MS$ has this
>> [...]
>> so a common API for SIMH would be fairly easy.
>>
>> [ ...]
>>
>> With this feature, it would probably also easy to realize a PDP-11/74
>> with 4 instances of SIMH.
>
> Mapping shared memory segment into the address spaces of multiple SIMH
> instances is the straightforward part.

Actually, it might be less trivial than first thought...

There is a problem in that different emulators might use a different 
layout for memory, that you somehow need to overlap when you come here. 
And that layout can become rather weird, and how do you actually figure 
this out.

Remember, this thread started with the explicit wish to deal with the 
PDP-15 and PDP-11 sharing memory. The PDP-15 uses 18-bit memory, while 
the PDP-11 uses 16-bit memory. Now we need a way to map addresses 
between the two, while the size of each memory word differs.

IN a way, you need to say that address X on the PDP-15 is address Y on 
the PDP-11. Now, address X+1 on the PDP-15 (18 bits), needs to map to 
address Y+2 on the PDP-11 (16 bits, but with 8-bit addressable units).
And in this, what does Y+1 on the PDP-11 map to?

> More intricate parts are:
>
> 1) Mapping guest memory-consistency model to host memory-consistency model.
>
> Does legacy software expect to observe updates to the shared memory executed
> by simulated VCPU1 (or virtual IO processor) to become observable by VCPU2
> in the same order they were executed by VCPU1? If yes, this would not work
> (without special handling by the simulator) on modern machines with weaker
> memory-consistency model.

Correct. And yes, order will be important in most cases.

> What is the cache coherency protocol of the simulated system and how does it
> map to the host system?
>
> Does simulated system have any system events (such as inter-processor
> interrupts or IO completion) that affect cache synchronization between VCPUs
> or VCPUs/VIOPs, and if yes, how this is to be mapped to the simulator?
>
> Ultimately it all depends on exact actual synchronization patterns utilized
> by legacy software.

I'll just go for the easy case here to start with. You normally do not 
have cache coherency in these old machines. In most cases, you do not 
even have caches.
And in the case systems do have caches, it's mostly write through, not 
write back.
So memory always holds the "correct" data immediately. MP systems had to 
know when there was a potential for cache problems, and work around it 
explicitly.

If we start trying to emulate machines that do have caches, we'll have 
to choose to either implement our own caching layer, in order to emulate 
the cache correctly, or else accept the behavior of the cache of the 
host machine. All modern machines implement cache coherency, so in 
essence you'll get the same effects as if you had no cache. In short, 
things work correct, and you never have broken cache coherency on modern 
machines, and you will not get any issues in normal simulation.

The write order might cause more problems though, if data is updated in 
a different order than you write it, on another CPU. That might require 
that you start playing with memory barriers, which will hurt performance.
But I don't see any way around this, if it becomes a problem.

> 2) Mapping memory atomicity.
>
> Does host machine provide the same memory access atomicity and separability
> as the simulated machine? For instance, if a simulated machine provides a way
> to update a byte at address A without interfering with concurrent updates to
> bytes at A-1 and A+1 by other VCPUs, then this would take a special effort
> to be implemented on a host machine that has let us say a 4-byte word as
> the minimum separable unit. Ditto for atomic and separable 2-byte word
> accesses (atomicity would mean that concurrent writes to the word do not
> result in resultant bytes values coming from different writes,
> separability would mean that concurrent writes to neighbor words do not
> interfere with each other).

Good point. That needs to be found out on the simulated machines first, 
on how it actually behaves.

> 3) Does a simulated system have any synchron

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Mark Pizzolato - Info Comm]

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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Tom Morris]

The Unichannel 15 Overview manual in the Bitsavers collection has a pretty
good description of everything for those wondering about the details.

https://archive.org/details/bitsavers_decpdp15Un974_2578882

There's an additional component, the MX15-B memory multiplexer, which
arbitrates memory access (15 wins for simultaneous requests, otherwise,
first come, first serve) and implements byte read/write for the 11.  The
manual also shows the memory layout and how it maps on each system, as well
as a lot of other details of operation.

Tom
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Phil Budne]

Johnny Billquist wrote:
> There is a problem in that different emulators might use a different 
> layout for memory, that you somehow need to overlap when you come here. 
> And that layout can become rather weird, and how do you actually figure 
> this out.

If all simulated memory access is wrapped in C macros, you can hide
most of the ugliness, assuming you don't mind a special build of the
simulators for each multi-processor system.  You might end up with
four or more builds of the PDP-11 simulator: uniprocessor, 11-only
multiprocessor, PDP-15 + PDP-11, PDP-10 + PDP-11.

Since we have CPU cycles to throw away, a "memory server" process
could solve the cache coherency problems...

phil
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Kevin Handy]

Try again (stupid tablets)

Allocate the shared memory inside the emulation like is done with device
registers. Capture the memory locations and handle them spedially. When
that area of shared memory is read or written to, you can use simh code to
access the actual mapped memory, doing any 16/18 bit conversions, etc.

The linked simulators will have to agree on how the mapped memory is laid
out (16/18 bit), but the conversions would be invisible to the emulated
machine. And since they are directly accessing the shared memory, many
problems would disappear.


On Tue, Mar 17, 2015 at 10:49 AM, Phil Budne  wrote:

> Johnny Billquist wrote:
> > There is a problem in that different emulators might use a different
> > layout for memory, that you somehow need to overlap when you come here.
> > And that layout can become rather weird, and how do you actually figure
> > this out.
>
> If all simulated memory access is wrapped in C macros, you can hide
> most of the ugliness, assuming you don't mind a special build of the
> simulators for each multi-processor system.  You might end up with
> four or more builds of the PDP-11 simulator: uniprocessor, 11-only
> multiprocessor, PDP-15 + PDP-11, PDP-10 + PDP-11.
>
> Since we have CPU cycles to throw away, a "memory server" process
> could solve the cache coherency problems...
>
> phil
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Christian Gauger-Cosgrove]

On 17 March 2015 at 12:49, Phil Budne  wrote:
> Johnny Billquist wrote:
>> There is a problem in that different emulators might use a different
>> layout for memory, that you somehow need to overlap when you come here.
>> And that layout can become rather weird, and how do you actually figure
>> this out.
>
> If all simulated memory access is wrapped in C macros, you can hide
> most of the ugliness, assuming you don't mind a special build of the
> simulators for each multi-processor system.  You might end up with
> four or more builds of the PDP-11 simulator: uniprocessor, 11-only
> multiprocessor, PDP-15 + PDP-11, PDP-10 + PDP-11.
>
> Since we have CPU cycles to throw away, a "memory server" process
> could solve the cache coherency problems...
>
What of putting the "memory server" process into the PDP-11 simulator,
and making it generic? That is, you could have the memory sharing
service on the '11 simulator; which you could either configure as a
the UC15, KL10 FE processor, or part of the 11/74. It's a more piece
of software to program, but much more rewarding than compiling four
different simulators, or writing four different new devices.


Also, of note, I brought some of this up back in January 2014:
 Also discussing implementing
the card readers on the '15.


Also, other multiprocessor systems that haven't been discussed that
might be interesting to talk about are the multiprocessor KL10 systems
namely the DECsystem-1088 and DECsystem-1099, the "strange"
PDP-11/45+PDP-11/45 setup involving "fun" with UNIBUS B (not good at
explaining things, E-11 does it as one of its unsupported
configurations), and the dual-processor PDP-15 setup (two PDP-15 CPUs
and optionally an FPP connected to one MX15-B).

And while we're on the topic of interprocessor/interemulator
communications, has anyone thought of perhaps implementing the DX11
with the co-operation of the Hercules team? It might be interesting to
see what strange things could be done having the SIMH PDP-11 as a
"peripheral" to a System/370, or System/390.


-- Christian
-- 
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Paul Hardy 2]

khandy21yo said:

>> Handle the sgatrd memory likre device regosrrrs. Vapyirr rradd and erites yo 
>> the dhared memoty amf  ley code in simh hamfle the fetails og mappinh 
>> betweem yhe figgerent gormats.

 

The human brains ability to parse language is amazing. Without thinking I read 
that as:

“Handle the shared memory like device registers. Copy reads and writes to the 
shared memory, and key code in simh handles the details of mapping between the 
different formats.”

Was that right?

 

To keep this on track, I did use one of these XVM-15 hybrids in the late 1970s. 
A ‘standard’ PDP-15 was the host for my first paid software work when I joined 
Laser-Scan as a programmer in 1975, and I wrote some diagnostics for Sweepnik 
(a nuclear physics image scanner). Laser-Scan soon moved to a PDP11/45 as main 
machine, but continued to ship PDP-15s for a while. The last of these was an 
XVM-15, which arrived from DEC with its chassis rather bent, but still worked 
OK. I ran some commissioning tests on it, then we shipped it off with a 
Sweepnik, I think to the University of Cairo in Egypt.

 

Regards,

 

-- 

Paul  Hardy

Email:   paul at the paulhardy.net domain, web:   
www.paulhardy.net

 

 

 

 

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Kevin Monceaux]

On Tue, Mar 17, 2015 at 07:24:48PM -, Paul Hardy 2 wrote:
 
> The human brains ability to parse language is amazing. Without thinking I
> read that as:

Your brain is a better language parser than mine is.  I didn't very far
attempting to decipher it.  




-- 

Kevin
http://www.RawFedDogs.net
http://www.Lassie.xyz
http://www.WacoAgilityGroup.org
Bruceville, TX

What's the definition of a legacy system? One that works!
Errare humanum est, ignoscere caninum.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [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


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Bob Supnik]

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
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Mark Pizzolato - Info Comm]

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
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Christian Gauger-Cosgrove]

On 17 March 2015 at 21:41, Mark Pizzolato - Info Comm  wrote:
> 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...
>
I mentioned that back on the GitHub discussion (just to plug it again:
). The PDP-11 side of things
does more than just run PIREX and respond to requests. The PDP-11 also
runs the SPOL11 spooler package, and you can run custom MACRO-11
programs on the '11 loaded and started by the '15.

Really the best way is to find some way of making the simulators talk
to each other. Plus, that framework can be expanded towards other
examples. (KL10 and PDP-11/74, being the ones off the top of my head.)


Regards,
Christian
-- 
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Sergey Oboguev]

Unless I misread Mark's message about the RQDX3 analogy, he is suggesting to 
put PDP-15 and PDP-11 in the same SIMH thread and in the same address space. 
When PDP-11 side becomes non-idle, it can signal an event and become eligible 
for execution, in a way similar to RQDX3. The options for co-execution with 
PDP-15 side in this structure are:

1) Execute PDP-11 exclusively until it enters idle state, then resume PDP-15 
execution until PDP-11 becomes non-idle again.(This directly mirrors RQDX3 
analogy).

2) Probably a better option (albeit dissimilar with RQDX3): co-execute PDP-11 
and PDP-15 instruction streams on the same SIMH thread. I.e. execute of chunk 
of N instructions on PDP-15 side, then execute N (or M) instructions on PDP-11 
side, then come back to PDP-15 main loop etc., and repeat this alternating 
execution of per-CPU main loops until one of the sides becomes idle, at which 
point the other side receives 100% share unless it becomes idle too.

One disadvantage of this approach is namespace conflicts.
But perhaps this can be addressed by restructuring SIMH build into 
machine-independent part and machine-specific parts, with machine-specific 
parts going to respective machine-specific DLLs/DSOs, with names local to 
specific CPUs not exported from these DLLs/DSOs and thus not colliding.
A complication might be that while machine-independent part code may be shared, 
but some machine-independent data perhaps might be not (for instance the event 
queue may have the same logical structure for both sides, but either a separate 
instance of this structure is needed for each side, or resets etc. need to be 
handled in a more delicate and involved way taking into account which side is 
resetting -- so the required reorg may be deeper than at the first glance).

The other disadvantage is that it does not leverage host multi-CPU resources.
That's assuming computational performance matters at all.

Yet the other disadvantage is the issues with calibrating VCPU speed.
As the calibration now becomes significantly distorted by the co-executing 
CPU(s) going in and out of idle state in a rapidly varying pattern.

Yet another disadvantage is that by default the consoles of two systems get 
mapped to the same host window, rather than being split, as they probably were 
in real life.

Yet another disadvantage is a complication of the codebase to implement the 
mentioned reorgs or offset for them.

The advantage is that it takes inter-thread synchronization issues out, 
includingmemory coherence issues and timing issues.
But those may be not that great after all.


- Original Message -
From: Christian Gauger-Cosgrove 
To: Mark Pizzolato - Info Comm 
Cc: "simh@trailing-edge.com" 
Sent: Tuesday, March 17, 2015 6:58 PM
Subject: Re: [Simh] Simulating the PDP-15/76 Unichannel

On 17 March 2015 at 21:41, Mark Pizzolato - Info Comm  wrote:
> 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...
>
I mentioned that back on the GitHub discussion (just to plug it again:
<https://github.com/simh/simh/issues/96>). The PDP-11 side of things
does more than just run PIREX and respond to requests. The PDP-11 also
runs the SPOL11 spooler package, and you can run custom MACRO-11
programs on the '11 loaded and started by the '15.

Really the best way is to find some way of making the simulators talk
to each other. Plus, that framework can be expanded towards other
examples. (KL10 and PDP-11/74, being the ones off the top of my head.)


Regards,
Christian
-- 
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.



___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Mark Pizzolato - Info Comm]

On Tuesday, March 17, 2015 at 7:50 PM, Sergey Oboguev wrote:
> Unless I misread Mark's message about the RQDX3 analogy, he is suggesting
> to put PDP-15 and PDP-11 in the same SIMH thread and in the same address
> space. When PDP-11 side becomes non-idle, it can signal an event and
> become eligible for execution, in a way similar to RQDX3. The options for co-
> execution with PDP-15 side in this structure are:

Well, the intention of my suggestion was not to actually execute PIREX code in 
a PDP11 simulator, but to merely have the DR15 device implement the protocol 
(and the resulting behaviors) that the slave PDP11 system executed while 
running PIREX (that is what the RQDX3 simulator does when it implements MSCP).

As Christian points out, the discussion in github issue 
(https://github.com/simh/simh/issues/96) covers this concept as mentioned by 
both Christian and Bob.  I never read the detail of that issue since PDP-15 was 
way beyond/before my time and experience and the discussion seemed to have a 
good flow of its own (by most of the same folks involved in this one now).

> 1) Execute PDP-11 exclusively until it enters idle state, then resume PDP-15
> execution until PDP-11 becomes non-idle again.(This directly mirrors RQDX3
> analogy).
> 
> 2) Probably a better option (albeit dissimilar with RQDX3): co-execute PDP-11
> and PDP-15 instruction streams on the same SIMH thread. I.e. execute of
> chunk of N instructions on PDP-15 side, then execute N (or M) instructions
> on PDP-11 side, then come back to PDP-15 main loop etc., and repeat this
> alternating execution of per-CPU main loops until one of the sides becomes
> idle, at which point the other side receives 100% share unless it becomes idle
> too.

Some aspect of this idea is also explored in that github issue...

- Mark

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Christian Gauger-Cosgrove]

On 17 March 2015 at 23:01, Mark Pizzolato - Info Comm  wrote:
> Well, the intention of my suggestion was not to actually execute PIREX code 
> in a PDP11 simulator, but to merely have the DR15 device implement the 
> protocol (and the resulting behaviors) that the slave PDP11 system executed 
> while running PIREX (that is what the RQDX3 simulator does when it implements 
> MSCP).
>
I'll say it's a good idea in theory, and great for just getting some
semblance of the UC15 subsystem off the ground. But it creates
software compatibility issues at best; and could cause
complacency/stagnation of a "correct" implementation at worst.


> As Christian points out, the discussion in github issue 
> (https://github.com/simh/simh/issues/96) covers this concept as mentioned by 
> both Christian and Bob.  I never read the detail of that issue since PDP-15 
> was way beyond/before my time and experience and the discussion seemed to 
> have a good flow of its own (by most of the same folks involved in this one 
> now).
>
Just for those who don't want to read through the whole, rather long,
discussion on GitHub, I'll summarize a few points regarding different
ways of implementing just the UNICHANNEL-15:

There's three ways, I see, of implementing it:
1. The "Emulated" solution Mark suggested: Emulating the functions of
PIREX, and SPOL11 (we can't forget the spooler).
--> Most "user friendly" of the ways of doing things, as the simulator
would be pretty much the same as before and operate as it did
normally; would probably resemble the current setup of the MASSBUS
disk/tape and MASSBUS controllers on the PDP-11 simulator (device UC
is the DR15 that is the Magical Device of PIREX and SPOL11Ⓡ; devices
RK and LP11 are the RK05s and LP11 lineprinter).
--> Probably going to be absolute hell to program. I mean, worse than
trying to fit a stripped '11 simulator into the '15 simulator; you'll
have to emulate the functions of both PIREX and SPOL11, and track
their states during runtime.
--> Not fully compatible with the software (can't load and run custom
MACRO-11 programs from the PDP-15 end of things).

2. The "Direct" solution that Sergey suggested (and Bob discussed in
the first e-mail): Cramming both emulators into one package.
--> See what Bob said, regarding having to get the code to work.
--> Still relatively user friendly; would probably need to add some
"fun" extra boot routines: A cold start boot that brings up PIREX on
the '11 and then boots the '15, a '15 only warm start, and an '11 only
reload (for when PIREX/SPOL11/your-custom-application crashes it).
--> Making the changes to the pdp11_cpu file to make it work will
probably cause Much Fun™ with the standalone PDP-11 simulator; though
you could also just for the CPU file, and strip it down to just being
an 11/05 in function while making the needed variable name changes.
--> Actually running this configuration will either mean making SIMH
multithreaded (please do, I'd like to see SIMH get the ability to dink
around the "sim>" console as long as one pleases, without stopping the
emulated CPU processing; just as the Hercules emulator does), or
timeslicing/timesharing the execution (like the FPPs on the '8 and '15
work, if I presume correctly).
3. The "Indirect" solution that Johnny brought up (and which I
personally think is the best one).
--> Not as simple for the user to setup; then again the setup probably
wouldn't be more complex than needed for HP2000 ACCESS on the HP21xx
simulator.
--> Greatest benefit to the SIMH project as a whole.
--> Could be "fun" in terms of implementation in a way that keeps the
cross-platform compatibility.


Before, I used to be a proponent of the "Direct" approach, but I've
been swayed to seeing the "Indirect" approach as the better option.

I'm thinking that, to do the Indirect approach in the way that best
allows for future interesting simulator escapades, that the memory
sharing server be implemented on the PDP-11 and be made relatively
generic. That is, it can share memory between another '11 simulator, a
'15 simulator, and a theoretical future KL10 simulator. Meanwhile,
there is a non-generic "UC15" device, that connects to a similar UC15
device on the PDP-15, which operates as the UNICHANNEL configuration
of DR11s and DR15. In the future a "KL10" device, and "IIST" devices
could be implemented, which would be the equivalent of the PDP-11 half
of the KL10 front end interface, and the IIST of the PDP-11/74 (the
IIST would also probably have to be implemented so that one server
setup could connect up to three client IIST devices).

I only foresee major problems with the above plan in both implementing
the shared memory service in a "generic" manner, and the possibility
of users doing insane things. Like hanging a PDP-15 off of a quad-CPU
11/74. (For SCIENCE! that must be done at one point. And equally,
abusing PIREX and RSX-11/M+ to make that setup actually usable...)
Also, the 11/74 and KL10 FE do some other "interesting" things that

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Sergey Oboguev]

> From: Christian Gauger-Cosgrove 
> The "Direct" solution that Sergey suggested ...

To clarify: I certainly did not suggest nor advocate it.

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Christian Gauger-Cosgrove]

On 18 March 2015 at 00:03, Sergey Oboguev  wrote:
> To clarify: I certainly did not suggest nor advocate it.
>
True enough. Bob brought it up way back at the start of the thread.
And he brought up the "Indirect" approach as well. You certainly did
bring create an excellent posting on the pros and cons of the "Direct"
approach. (Far better than I could explain anything...)

Cheers,
Christian
-- 
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Mark Pizzolato - Info Comm]

On Tuesday, March 17, 2015 at 8:52 PM, Christian Gauger-Cosgrove wrote:
> --> Actually running this configuration will either mean making SIMH
> multithreaded (please do, I'd like to see SIMH get the ability to dink around
> the "sim>" console as long as one pleases, without stopping the emulated
> CPU processing; just as the Hercules emulator does), or
> timeslicing/timesharing the execution (like the FPPs on the '8 and '15 work, 
> if
> I presume correctly).

FYI:  The existing simh framework has a remote console capability which can be 
used to "dink around" in "reasonable" ways with a running simulator.  The 
dinking can either be done without stopping instruction execution or execution 
can be stopped while dinking and then resumed with CONT (which will happen 
automatically after a configurable timeout).

The remote console capabilities are implemented without the simulator being 
multi-threaded.  

Meanwhile, some simulators have some functionality which does run in multiple 
threads.  This occurs with VAX and PDP MSCP and TMSCP as well as RP disks 
devices.  These devices perform I/O in a separate thread and when that I/O 
completes device events are queued to the simh event queue and interrupts occur 
in ways similar to how real hardware functioned.  Multi-threaded I/O is only 
used on host platforms which have working pthreads libraries available.  These 
include at least Windows, OS/X, Linux and IA64 VMS.

- Mark
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [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


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Rich Alderson]

At several points in the discussion, the KL-10 has come up as an
example of a system with a PDP-11 front end processor.  Reference
has been made to "shared memory" between the -11 and the PDP-10
engine which is the main reason for the existence of the system.

The PDP-11/40 front end and the PDP-10 engine do not share memory.
Data transfer takes place over a Unibus device (from the -11 side)
which resides in the I/O bay of the -10, called a DTE-20.  This is
a very simple device which ties into the interrupt systems of the
-10 and -11 with a "doorbell"; depending upon who is ringing whose
bell, data moves between the -11's memory and the -10's, but neither
side knows the address(es) in the other processor.

Note that the front end software is special, as well.  Both of the
loader programs, the older KLDCP which is retained by the diagnostic
package and the later RSX-20F[1,2,3], expect to deal with 18-bit
data on disk, not 16.

I'm not saying that a KL-10 emulation would not be interesting, just
pointing out that it has nothing in common with the Unichannel on
the PDP-15/76.

Rich

[1] Developed mostly from RSX-11M, with a few nods to RSX-11D, at
least as far as the doc writers were concerned.
[2] If you boot an RSX-20F floppy on an 11/40 without a DTE-20, you
will immediately receive a message on the console telling you
that the DTE-20 is not found and the system will halt.
[3] NB:  The primary front end must be an 11/40.  There are up to 4
DTE-20s in a KL-10, and the secondary systems can also be 11/34's,
I believe, but I don't think they run RSX-20F, just special loads
like DECnet or HASP/RJE software.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Timothe Litt]

On 18-Mar-15 20:34, Rich Alderson wrote:
> At several points in the discussion, the KL-10 has come up as an
> example of a system with a PDP-11 front end processor.  Reference
> has been made to "shared memory" between the -11 and the PDP-10
> engine which is the main reason for the existence of the system.
>
> The PDP-11/40 front end and the PDP-10 engine do not share memory.
> Data transfer takes place over a Unibus device (from the -11 side)
> which resides in the I/O bay of the -10, called a DTE-20.  This is
> a very simple device which ties into the interrupt systems of the
> -10 and -11 with a "doorbell"; depending upon who is ringing whose
> bell, data moves between the -11's memory and the -10's, but neither
> side knows the address(es) in the other processor.
>
> Note that the front end software is special, as well.  Both of the
> loader programs, the older KLDCP which is retained by the diagnostic
> package and the later RSX-20F[1,2,3], expect to deal with 18-bit
> data on disk, not 16.
>
> I'm not saying that a KL-10 emulation would not be interesting, just
> pointing out that it has nothing in common with the Unichannel on
> the PDP-15/76.
>
> Rich
This is more or less correct, except that the DTE20 is not a 'simple'
device.
I had to learn more about it than I ever wanted to, and the lessons were
sufficiently painful that I remember (most of) them a few decades later.

The -11 can read and write -10 memory.  The primary DTE can access
anything, but the queued protocol used when the OS is running uses
'protected' reads and writes that are limited to a 10-defined window. 
However, even in that mode, other communication happens via fixed
locations in the EPT and low memory. Including console I/O when eddt
or the bootstraps are running.  The primary DTE also can access the
diagnostic bus, SBus & microcode.  (Actually, any of them can, but software
complains if more than one is privileged - it's a toggle switch on the panel
of each DTE.)  This includes microcode loading, and on the fly error
recovery.  The KL10 microcode handles some DTE20 functions.

The other DTEs are restricted to the queued protocol, and can be either
11/40s or 11/34s.  DECnet or ANF-10.

The -10 has an electronic finger and can reboot any of the -11s - even
the primary.
The -10 and -11 have mutual keep-alive counters and reboot each-other.
The -11 does hardware initialization, power-fail restart and other obscure,
barely documented stuff.

The -10 has no access to -11 memory, though the electronic finger triggers a
boot ROM, and includes a few bits specifying where it starts.  The DEC ROMs
all had an entry point for dumping -11 memory as well as loading it.  But
this is a software function.

There is a tech manual that has unpublished errata.  There's a copy at
http://www.36bit.org/dec/manual/ek-dte20-ud-003.pdf

> [1] Developed mostly from RSX-11M, with a few nods to RSX-11D, at
> least as far as the doc writers were concerned.
-11M, but -11D device drivers and a heavy dependence on event flags.
No memory mapping; it was a stripped-down environment.
1 RP04/6 disk dual ported; the 11 driver had to deal with 18-bit (576 byte)
formatted sectors.
The queued protocol provided access to unibus peripherals, including
async lines, card reader, LPT and (my secret contribution, a
battery-backed-up
TOY).  This wasn't pure pass-thru; the 11 did a lot of the low-level
control and
presented abstracted devices.
> [2] If you boot an RSX-20F floppy on an 11/40 without a DTE-20, you
> will immediately receive a message on the console telling you
> that the DTE-20 is not found and the system will halt.
> [3] NB:  The primary front end must be an 11/40.  There are up to 4
> DTE-20s in a KL-10, and the secondary systems can also be 11/34's,
Yes,  but which one is 'primary' is controlled by the toggle switch that
I mentioned.
The test is for one that doesn't have the 'restricted mode' bit.
> I believe, but I don't think they run RSX-20F, just special loads
> like DECnet or HASP/RJE software.
ANF-10, DECnet, and IBM E/T (HASP/RJE and other IBM OSs.  The DN20
wasn't the
only adapter for IBM E/T.)

This is a fairly high-level description.  The details are quite involved.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Johnny Billquist]

On 2015-03-19 04:21, Timothe Litt wrote:

On 18-Mar-15 20:34, Rich Alderson wrote:

[1] Developed mostly from RSX-11M, with a few nods to RSX-11D, at
 least as far as the doc writers were concerned.

-11M, but -11D device drivers and a heavy dependence on event flags.
No memory mapping; it was a stripped-down environment.
1 RP04/6 disk dual ported; the 11 driver had to deal with 18-bit (576 byte)
formatted sectors.
The queued protocol provided access to unibus peripherals, including
async lines, card reader, LPT and (my secret contribution, a
battery-backed-up
TOY).  This wasn't pure pass-thru; the 11 did a lot of the low-level
control and
presented abstracted devices.


This is getting rather far off-topic, but anyway...
Do you have any source for the claim about -11M with -11D device 
drivers? As far as I know, one of the major differences between -11M and 
-11D is just the device drivers, as the whole I/O subsystem was 
redesigned in -11M, for a smaller memory footprint and better efficiency.
-11D could not run without an MMU, while -11M can. Thus it sounds 
strange that you'd have -11M with -11D device drivers. I would suspect 
that would be impossible, and in addition the -11D device drivers would 
require more resources than their -11M counterparts, which would be 
rather opposite of what was required of the 11/40 FE, which is rather 
limited on resources.


My recollection of RSX-20F is that it very much feels like an unmapped 
-11M system. Some changes because of the special requirements, but 
nothing major.


Johnny


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Johnny Billquist]

On 2015-03-19 14:13, Johnny Billquist wrote:

On 2015-03-19 04:21, Timothe Litt wrote:

On 18-Mar-15 20:34, Rich Alderson wrote:

[1] Developed mostly from RSX-11M, with a few nods to RSX-11D, at
 least as far as the doc writers were concerned.

-11M, but -11D device drivers and a heavy dependence on event flags.
No memory mapping; it was a stripped-down environment.
1 RP04/6 disk dual ported; the 11 driver had to deal with 18-bit (576
byte)
formatted sectors.
The queued protocol provided access to unibus peripherals, including
async lines, card reader, LPT and (my secret contribution, a
battery-backed-up
TOY).  This wasn't pure pass-thru; the 11 did a lot of the low-level
control and
presented abstracted devices.


This is getting rather far off-topic, but anyway...
Do you have any source for the claim about -11M with -11D device
drivers? As far as I know, one of the major differences between -11M and
-11D is just the device drivers, as the whole I/O subsystem was
redesigned in -11M, for a smaller memory footprint and better efficiency.
-11D could not run without an MMU, while -11M can. Thus it sounds
strange that you'd have -11M with -11D device drivers. I would suspect
that would be impossible, and in addition the -11D device drivers would
require more resources than their -11M counterparts, which would be
rather opposite of what was required of the 11/40 FE, which is rather
limited on resources.

My recollection of RSX-20F is that it very much feels like an unmapped
-11M system. Some changes because of the special requirements, but
nothing major.


Just re-read the RSX-20F manual (I had almost forgotten I had read it 
before).
In that manual, it is described in pretty good detail that they 
essentially just have an unmapped RSX-11M system. They added a device 
driver for the DTE-20, and a service task connected to that, and then 
just customized the whole thing.


The manual also mentions once or twice that RSX-20F also inherited 
something from RSX-11D, but there is nothing in the manual explaining 
what actually was inherited from -11D, so I'm not sure if I should take 
that verbatim, or just a relationship note, since -11M itself was 
designed based upon -11D.


Johnny

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Timothe Litt]

On 19-Mar-15 10:13, Johnny Billquist wrote:
>
> Just re-read the RSX-20F manual (I had almost forgotten I had read it
> before).
> In that manual, it is described in pretty good detail that they
> essentially just have an unmapped RSX-11M system. They added a device
> driver for the DTE-20, and a service task connected to that, and then
> just customized the whole thing.
>
> The manual also mentions once or twice that RSX-20F also inherited
> something from RSX-11D, but there is nothing in the manual explaining
> what actually was inherited from -11D, so I'm not sure if I should
> take that verbatim, or just a relationship note, since -11M itself was
> designed based upon -11D.
>
> Johnny
>
Don't believe everything that you read.  It most definitely was NOT a
sysgened/ slightly customized version of 11M 2 or 3.something.  The
manual put the best possible spin on a one-off design.

I just finished describing the history/internals. 

BTW, the DN20 DECnet comm code in the 11/34 was built on pretty standard
11s - by the same folks.  They did learn from the 20F experience.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating the PDP-15/76 Unichannel

[Phil Budne]

> [3] NB:  The primary front end must be an 11/40.  There are up to 4
> DTE-20s in a KL-10, and the secondary systems can also be 11/34's,
> I believe, but I don't think they run RSX-20F, just special loads
> like DECnet or HASP/RJE software.

On a TOPS-10 system front ends include ANF-10 nodes (ie; DN87S) for
terminals: serial lines (other than the console and KLINK) weren't put
on the Console Front End of a 1090, and would be undesirable in an SMP
(1099) configuration.  Tho ISTR TOPS-10 might have supported
additional terminals on the CFE on a 1091 (a blue 2060)?

There was also the DL10 which I think *WAS* a memory mapper (for up to
four 11's) used on KA and KI systems (someone is working on SIMH mods
for these), and my list of PDP-10 peripherals:
http://www.ultimate.com/phil/pdp10/10periphs
includes one non 11/40 or 11/34 system:
DC75sync (PDP-11/15 & DS11's via DL10) DN8x code base! (cf DAS85?)

And one where I have no spec for the '11:
DAS78   IBM bisync support (up to 16 360, 370, and/or 2780's) (PDP-11 via DL10)

FWIW, the chk11 in the ANF sources recognizes the following:
KD11-D (11/04)
KD11-B (11/05 or 11/10)
KA11 (11/20) or KC11 (11/15)
KD11-E (11/34)
KD11-A (11/35 or 11/40)
KB11-A (11/45)

And for completeness, I also have these other PDP-10 devices:

DA1012/18-bit (PDP-8/9) computer interface
DA28C   PDP-8/11/12/15 interprocessor channel (for upto 16 processors)
DA28A   PDP-8/12 interface on DA28C
DA28F   PDP-11 interface on DA28C
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh