Discussion:
[Simh] External bus interface
Lars Brinkhoff
2018-01-18 10:12:13 UTC
Permalink
Hello,

I wrote a GitHub issue about this, but maybe it's better to bring it up
for discussion on the mailing list. So I'll copy the text here:

Richard Cornwell's KA10 simulator is getting ready. At MIT, there were
PDP-11s connected to the PDP-10 memory and I/O busses. The 11s acted as
dedicated I/O processors. Some of us are interested in recreating
configurations similar to this. For example, MIT-AI had a PDP-11
connected to control a number of graphical terminals called Knight TVs.
And another PDP-11 for CHAOS networking.

To hook up separate simulator processes this way, I suppose there should
be some kind of bus interface for SIMH. The interface would have to
support memory transfers, interrupt signals, etc.

Would it be feasible to create such a bus interface?

Best regards,
Lars Brinkhoff
Bob Supnik
2018-01-18 12:36:56 UTC
Permalink
Lars,

SimH knows nothing of the internal structure of simulators, so I'm
skeptical of a SimH-level solution. However, a simulator-specific
interface can be built.

As an example, I am finishing up the UC15, which is exactly what you
describe - a PDP11 that is connected to the memory of a PDP15 and
controlled via a cross-connected paralllel link. The PDP11 acts as an IO
processor for the PDP15.

I have not solved all the problems. The solution requires a multi-core
(or other kind of SMP) system, with one core per simulator. It probably
depends on in-order writes and strong cache consistency semantics. And
it definitely depends on tight polling, which causes the cores to run
flat out (unsuitable for mobile devices).

Bob
Message: 4
Date: Thu, 18 Jan 2018 10:12:13 +0000
Subject: [Simh] External bus interface
Content-Type: text/plain
Hello,
I wrote a GitHub issue about this, but maybe it's better to bring it up
Richard Cornwell's KA10 simulator is getting ready. At MIT, there were
PDP-11s connected to the PDP-10 memory and I/O busses. The 11s acted as
dedicated I/O processors. Some of us are interested in recreating
configurations similar to this. For example, MIT-AI had a PDP-11
connected to control a number of graphical terminals called Knight TVs.
And another PDP-11 for CHAOS networking.
To hook up separate simulator processes this way, I suppose there should
be some kind of bus interface for SIMH. The interface would have to
support memory transfers, interrupt signals, etc.
Would it be feasible to create such a bus interface?
Best regards,
Lars Brinkhoff
Lars Brinkhoff
2018-01-18 17:26:33 UTC
Permalink
Hello,

Thanks, that's good to know. It's encouraging that something is
underway.

Are the machines running inside the same process? I was vaguely
thinking about running machines as separate processes, with some
communication mechanism between them. Maybe shared memory, maybe
something else. It wouldn't even have to be SimH in both ends.

But I'll take what I can get!

Best regards,
Lars Brinkhoff
Post by Bob Supnik
SimH knows nothing of the internal structure of simulators, so I'm
skeptical of a SimH-level solution. However, a simulator-specific
interface can be built.
As an example, I am finishing up the UC15, which is exactly what you
describe - a PDP11 that is connected to the memory of a PDP15 and
controlled via a cross-connected paralllel link. The PDP11 acts as an
IO processor for the PDP15.
I have not solved all the problems. The solution requires a multi-core
(or other kind of SMP) system, with one core per simulator. It
probably depends on in-order writes and strong cache consistency
semantics. And it definitely depends on tight polling, which causes
the cores to run flat out (unsuitable for mobile devices).
Mark Pizzolato
2018-01-18 17:34:12 UTC
Permalink
Thanks, that's good to know. It's encouraging that something is underway.
Are the machines running inside the same process? I was vaguely thinking
about running machines as separate processes, with some communication
mechanism between them.
The goal is to leverage the existing simulator code without any heavy lifting
which would be required to have multiple simulators running in the same process.
Maybe shared memory, maybe something else.
What I'm working on is based around shared memory which may or may not
be used directly by the device simulator using it. This allows the same interfaces
to leverage the rest of the hooks into SCP.
It wouldn't even have to be SimH in both ends.
In theory that might be true, but that won't be a primary goal.

- Mark
Post by Bob Supnik
SimH knows nothing of the internal structure of simulators, so I'm
skeptical of a SimH-level solution. However, a simulator-specific
interface can be built.
As an example, I am finishing up the UC15, which is exactly what you
describe - a PDP11 that is connected to the memory of a PDP15 and
controlled via a cross-connected paralllel link. The PDP11 acts as an
IO processor for the PDP15.
I have not solved all the problems. The solution requires a multi-core
(or other kind of SMP) system, with one core per simulator. It
probably depends on in-order writes and strong cache consistency
semantics. And it definitely depends on tight polling, which causes
the cores to run flat out (unsuitable for mobile devices).
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh
Bob Supnik
2018-01-18 18:32:21 UTC
Permalink
Yes, in separate processes. They use shared memory sections to
communicate - one as main memory, one as control state.

/Bob
Post by Lars Brinkhoff
Hello,
Thanks, that's good to know. It's encouraging that something is
underway.
Are the machines running inside the same process? I was vaguely
thinking about running machines as separate processes, with some
communication mechanism between them. Maybe shared memory, maybe
something else. It wouldn't even have to be SimH in both ends.
But I'll take what I can get!
Best regards,
Lars Brinkhoff
Post by Bob Supnik
SimH knows nothing of the internal structure of simulators, so I'm
skeptical of a SimH-level solution. However, a simulator-specific
interface can be built.
As an example, I am finishing up the UC15, which is exactly what you
describe - a PDP11 that is connected to the memory of a PDP15 and
controlled via a cross-connected paralllel link. The PDP11 acts as an
IO processor for the PDP15.
I have not solved all the problems. The solution requires a multi-core
(or other kind of SMP) system, with one core per simulator. It
probably depends on in-order writes and strong cache consistency
semantics. And it definitely depends on tight polling, which causes
the cores to run flat out (unsuitable for mobile devices).
Paul Koning
2018-01-18 14:50:48 UTC
Permalink
Post by Lars Brinkhoff
Hello,
I wrote a GitHub issue about this, but maybe it's better to bring it up
Richard Cornwell's KA10 simulator is getting ready. At MIT, there were
PDP-11s connected to the PDP-10 memory and I/O busses. The 11s acted as
dedicated I/O processors. Some of us are interested in recreating
configurations similar to this. For example, MIT-AI had a PDP-11
connected to control a number of graphical terminals called Knight TVs.
And another PDP-11 for CHAOS networking.
To hook up separate simulator processes this way, I suppose there should
be some kind of bus interface for SIMH. The interface would have to
support memory transfers, interrupt signals, etc.
Would it be feasible to create such a bus interface?
I think this was done already for PDP-15 to PDP-11 hookup, but I don't know any of the details. It seems like something that would be easier with threads rather than processes, but it should be doable either way.

paul
Hittner, David T [US] (MS)
2018-01-18 15:11:29 UTC
Permalink
I suspect that you could create a cross-simulator "bus" using some common I/O carrier between simulators to allow them to communicate the bus state. As Bob states, it would be simulator-specific.

If the simulators are running on the same OS host, a common bus could be simulated using a memory structure (like a Fortran COMMON) to transmit bus state variables. If you are running multiple simulators on different hosts across the network, you could use the network as the common bus by sending specifically-encoded packets using some arbitrary TCP/IP protocol number to transmit the bus state variables to the other side(s).

I've thought a bit about these techniques for intra-simulator connects between multiple threads for multiple CPUs, and for simulating a multi-initiator SCSI bus, Digital CI, or Memory Channel for OpenVMS cluster communications between multiple SIMH simulators.

As a practical example of running a simulated bus over a different transmission medium to achieve the goal, I think that the parallel network I/O interface card simulators on the PDP-11 and PDP-10 simulate parallel transmission by transmitting serialized packets over standard Ethernet rather than over a physical parallel connection.

Dave

-----Original Message-----
From: Simh [mailto:simh-***@trailing-edge.com] On Behalf Of Bob Supnik
Sent: Thursday, January 18, 2018 6:37 AM
To: ***@trailing-edge.com
Subject: EXT :Re: [Simh] External bus interface

Lars,

SimH knows nothing of the internal structure of simulators, so I'm skeptical of a SimH-level solution. However, a simulator-specific interface can be built.

As an example, I am finishing up the UC15, which is exactly what you describe - a PDP11 that is connected to the memory of a PDP15 and controlled via a cross-connected paralllel link. The PDP11 acts as an IO processor for the PDP15.

I have not solved all the problems. The solution requires a multi-core (or other kind of SMP) system, with one core per simulator. It probably depends on in-order writes and strong cache consistency semantics. And it definitely depends on tight polling, which causes the cores to run flat out (unsuitable for mobile devices).

Bob
Message: 4
Date: Thu, 18 Jan 2018 10:12:13 +0000
Subject: [Simh] External bus interface
Content-Type: text/plain
Hello,
I wrote a GitHub issue about this, but maybe it's better to bring it up
Richard Cornwell's KA10 simulator is getting ready. At MIT, there were
PDP-11s connected to the PDP-10 memory and I/O busses. The 11s acted as
dedicated I/O processors. Some of us are interested in recreating
configurations similar to this. For example, MIT-AI had a PDP-11
connected to control a number of graphical terminals called Knight TVs.
And another PDP-11 for CHAOS networking.
To hook up separate simulator processes this way, I suppose there should
be some kind of bus interface for SIMH. The interface would have to
support memory transfers, interrupt signals, etc.
Would it be feasible to create such a bus interface?
Best regards,
Lars Brinkhoff
_______________________________________________
Simh mailing list
***@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
Loading...