[Simh] TMXR/UC15 documentation?

[Lars Brinkhoff]

Hello,

The ITS restoration team is getting ready to hook up eight (simulated)
Unibuses to a (SIMH) PDP-10. The MIT AI KA10 machine really did this,
and we want some of the applications that used these capabilities.

We'd like some guidance on the best way to do this in the SIMH
framework. Since UC15 is essentially the same idea, I suppose we should
probably do the same thing. Is there any documentation on this? So far
I only know these four letters: TMXR.

Thanks!

[Mark Pizzolato]

The ITS restoration team is getting ready to hook up eight (simulated) Unibuses
to a (SIMH) PDP-10. The MIT AI KA10 machine really did this, and we want
some of the applications that used these capabilities.
We'd like some guidance on the best way to do this in the SIMH framework.
Since UC15 is essentially the same idea, I suppose we should probably do the
same thing. Is there any documentation on this? So far I only know these four
letters: TMXR.

TMXR has nothing to do with UC15. The UC15 has a shared memory segment
between two independent simh simulators (a PDP11 and a PDP15).

TMXR is the simh library which is used by terminal mux devices to provide telnet
connections to simulated serial ports.
It is also used by several point-to-point network devices (DMC11, DUP11) to
connect independent simh instances via simulated WAN connections using
TCP or UDP for data delivery.

What devices are going to be connected to all of these Unibus(s)?

- Mark

[Lars Brinkhoff]

Post by Mark Pizzolato

Post by Lars Brinkhoff
The ITS restoration team is getting ready to hook up eight
(simulated) Unibuses to a (SIMH) PDP-10. The MIT AI KA10 machine
really did this, and we want some of the applications that used these
capabilities.

TMXR is the simh library which is used by terminal mux devices to
provide telnet connections to simulated serial ports. It is also used
by several point-to-point network devices (DMC11, DUP11) to connect
independent simh instances via simulated WAN connections using TCP or
UDP for data delivery.

Sorry for the confusion, I must have misunderstood when I read about
those network devices. Though I suppose what I want could be considered
a form of point-to-point communication.

Post by Mark Pizzolato
What devices are going to be connected to all of these Unibus(s)?

It's mostly used to allow direct access to PDP-11 main memory.

Maybe a longer explanation is in order.

The MIT AI PDP-10 had a special device attached called the Rubin 10-11
interface. It allowed connecting up to eight PDP-11s. The interface
mapped the PDP-11 memories into the PDP-10 address space. As far as I
know (there's not much in the way of documentation), there was only
shared memory, no interrupts or any other features. The PDP-10 always
initiates accesses. The 11s could not access PDP-10 memory.

[Mark Pizzolato]

Post by Mark Pizzolato

Post by Lars Brinkhoff
The ITS restoration team is getting ready to hook up eight
(simulated) Unibuses to a (SIMH) PDP-10. The MIT AI KA10 machine
really did this, and we want some of the applications that used these
capabilities.

TMXR is the simh library which is used by terminal mux devices to
provide telnet connections to simulated serial ports. It is also used
by several point-to-point network devices (DMC11, DUP11) to connect
independent simh instances via simulated WAN connections using TCP or
UDP for data delivery.

Sorry for the confusion, I must have misunderstood when I read about those
network devices. Though I suppose what I want could be considered a form of
point-to-point communication.

Post by Mark Pizzolato
What devices are going to be connected to all of these Unibus(s)?

It's mostly used to allow direct access to PDP-11 main memory.

Mostly??? What else besides memory access? Is the access from the PDP10
side done by programmed I/O (i.e. referencing addresses in the Unibus
address space), or by some DMA engine which allowed transfers from the
PDP10's memory to the PDP11's and back?

Maybe a longer explanation is in order.
The MIT AI PDP-10 had a special device attached called the Rubin 10-11
interface. It allowed connecting up to eight PDP-11s. The interface mapped
the PDP-11 memories into the PDP-10 address space. As far as I know (there's
not much in the way of documentation), there was only shared memory, no
interrupts or any other features. The PDP-10 always initiates accesses. The 11s
could not access PDP-10 memory.

Given this explanation, it would seem that you're merely looking for a shared
memory model, and not really a point-to-point WAN situation.

What PDP11 model(s) were involved? Was there a PDP11 memory map involved?

You've got the software which ran on the PDP11's?

What devices existed on the PDP11's?

The UC15 simulator is a particular PDP11 simulator which has a specific model
PDP11 and a limited set of devices.

Given that what you've got is one way with only the PDP11's memory being
accessed and no interrupts it would seem that a KA10 with a set of PDP10
Unibus(s), with each connected directly to a different PDP11 system, you
could model this pretty easily.

- Mark

[Lars Brinkhoff]

Post by Mark Pizzolato

Post by Lars Brinkhoff
It's mostly used to allow direct access to PDP-11 main memory.

Mostly??? What else besides memory access?

First, we don't know everything yet. It's not exactly documented. I
expect details to reveal themselves as we progress.

I believe it could also be used to access memory mapped I/O registers.

Post by Mark Pizzolato
Is the access from the PDP10 side done by programmed I/O
(i.e. referencing addresses in the Unibus address space), or by some
DMA engine which allowed transfers from the PDP10's memory to the
PDP11's and back?

No DMA. Just instructions doing regular memory accesses.

Post by Mark Pizzolato
Given this explanation, it would seem that you're merely looking for a
shared memory model, and not really a point-to-point WAN situation.

Yes, it's shared memory.

Post by Mark Pizzolato
What PDP11 model(s) were involved? Was there a PDP11 memory map involved?

I 11/10, 11/20, 11/40, 11/45. The device accesses physical memory
addresses, so if a PDP-11 has an MMU that's not visible.

The Rubin 10-11 has a memory mapping mechanism that translates PDP-10
addresses to a 3-bit Unibus number, an 18-bit Unibus base address, and a
10-bit address limit. The latter can be used to set the size of the
mapping from a full ITS page (1024 36-bit words), down to a single
PDP-11 word. There are 256 mappings, one for each ITS page in a 256K
range.

Post by Mark Pizzolato
You've got the software which ran on the PDP11's?

For most of them.

Post by Mark Pizzolato
What devices existed on the PDP11's?

I'll be happy to go into details!

Unibus number 0: PDP-11/10 with 12K memory, around 20 32K frame buffers
for bitmapped displays, video switch, audio switch, and keyboards. And
the elevator button. This 11 is our top priority.

Unibus number 1: PDP-11/20 with 28K, attached to a XGP laser printer.

Unibus number 2: GT40 with 8K attached to the CONS Lisp machine.

Unibus number 3: CHEOPS, hardware assist for a chess program.

Unibus number 4: PDP-11/45 with 32K, custom hardware with eight vector
displays. Used by the MIT Logo group.

Unibus number 5: PDP-11/45 with 32K, and roboics equipment.

Unibus number 6: PDP-11/40 with 28K, and equipment for computer vision
research.

Unibus number 7: Unknown PDP-11 model with 8K and a Chaosnet interface.

The memory sizes are what ITS maps in. It could actually be more.

Post by Mark Pizzolato
Given that what you've got is one way with only the PDP11's memory
being accessed and no interrupts it would seem that a KA10 with a set
of PDP10 Unibus(s), with each connected directly to a different PDP11
system, you could model this pretty easily.

Right, it's not a complicated device. I have the PDP-10 side
implemented, and ITS seems happy with it. It creates mapping as needed,
and tries to read and write memory locations. For now writes are
ignored and reads return zero (except the mappings).

So, uness there's any support code in SIMH for something like this,
we'll invent our own bus interfaces.

[Lars Brinkhoff]

Post by Lars Brinkhoff
Unibus number 7: Unknown PDP-11 model with 8K and a Chaosnet interface.

Correction: 11/10, and two Chaosnet interfaces.

[Lars Brinkhoff]

Post by Mark Pizzolato
Given that what you've got is one way with only the PDP11's memory
being accessed and no interrupts it would seem that a KA10 with a set
of PDP10 Unibus(s), with each connected directly to a different PDP11
system, you could model this pretty easily.

I will probably hook into the PDP-11 simulator. The PDP-11 should
accept memory read and write requests from the PDP-10. Any guidance on
how to do this?

Even though TMXR is point-to-point communication, it seems to me it
might serve for sending messages to encode such requests, and return
data for read references.

[Paul Koning]

Post by Lars Brinkhoff

Post by Mark Pizzolato
Given that what you've got is one way with only the PDP11's memory
being accessed and no interrupts it would seem that a KA10 with a set
of PDP10 Unibus(s), with each connected directly to a different PDP11
system, you could model this pretty easily.

I will probably hook into the PDP-11 simulator. The PDP-11 should
accept memory read and write requests from the PDP-10. Any guidance on
how to do this?

You could look at Bob's PDP-15 work, but that was built for a system of coooperating processors with tight timing. If you don't have tight timing (lockstep execution) requirements, you could use a different scheme. For example, moving the memory to a shared memory region, and running the several simulators as separate processes that access that shared region. Whether that's doable depends mostly on the software -- does it have interlocking operations, or does it expect to post a request to memory and have it acted on within N cycles on the sending machine? If the latter, then you need to ensure near lock step execution of the simulators, and "just put them in separate processes" would not be good enough.

By way of analogy, the dual CPU mode of the CDC 6000 mainframes (somewhat surprisingly) doesn't require close synchronization and works perfectly well with the two CPUs running in separate threads. On the other hand, the 10 or 20 PPUs must all run in the same thread, time-sliced on a simulated cycle basis, because they do have tight timing without sufficient explicit synchronization.

paul

[Timothe Litt]

Post by Lars Brinkhoff
It's mostly used to allow direct access to PDP-11 main memory.
Maybe a longer explanation is in order.
The MIT AI PDP-10 had a special device attached called the Rubin 10-11
interface. It allowed connecting up to eight PDP-11s. The interface
mapped the PDP-11 memories into the PDP-10 address space. As far as I
know (there's not much in the way of documentation), there was only
shared memory, no interrupts or any other features. The PDP-10 always
initiates accesses. The 11s could not access PDP-10 memory.

The DEC version of this is the DL10 - at least for the KA/KI.  Also
supported on the
KLs with external memory/IO buses.  This provides a Unibus to PDP-10 memory
window.  IIRC, up to 4 Unibuses/DL10.  Either side could write -10
memory.  The
DL10 connects to the IO bus (for configuration, interrupt status/enables,
etc, and the electronic finger (which triggers the boot rom - which is
how the 10 gets
control for load/dump.  And the memory bus for the memory references -
which to
the Unibus, look like memory.  We used this for ANF-10 network front
ends; some
environments also connected -15s to the Unibus.

You should think about what you describe as a subset of the DL10, which
someone will
eventually want to add to the KA/KI emulations.

For the KL10, the DTE20 uses a somewhat different architecture - I don't
have time to
describe it now.

I think the manuals for both are on Bitsavers - but I have a meeting to
get to...

It's pretty clear that SimH needs a model/portable library for shared
memory...

[Al Kossow]

The DEC version of this is the DL10 - at least for the KA/KI.  Also supported on the
KLs with external memory/IO buses.  This provides a Unibus to PDP-10 memory
window.  IIRC, up to 4 Unibuses/DL10.  Either side could write -10 memory.  The
DL10 connects to the IO bus (for configuration, interrupt status/enables,
etc, and the electronic finger (which triggers the boot rom - which is how the 10 gets
control for load/dump.  And the memory bus for the memory references - which to
the Unibus, look like memory.  We used this for ANF-10 network front ends; some
environments also connected -15s to the Unibus.

The Air Force Avionics Lab in Dayton had one on their KI which connected to a bunch of GT-40s
that was part of an F-16 simulator, ca. 1979.

[Lars Brinkhoff]

The DEC version of this is the DL10 - at least for the KA/KI. Also
supported on the KLs with external memory/IO buses.

I wasn't going to mention it, but I now have an excuse to say the MIT MC
KL10 had two PDP-11 attached, one through DL10 and the other through
DTE20.

But then, we don't have a suitable KL10 emulator so it's a moot point.

You should think about what you describe as a subset of the DL10

Right. I did, in another forum.

[Johnny Billquist]

This post might be inappropriate. Click to display it.

[Lars Brinkhoff]

This post might be inappropriate. Click to display it.

[Angelo Papenhoff]

Post by Johnny Billquist
Really? The KA10 itself predates the Unibus. I guess it's possible they
added the ability to hook up Unibuses later in the life of the machine,
but the KI would have been around at that point as well, so a bit
surprising that they'd do anything with the KA at that point.

Lars and Rich already commented, but I wanted to add that I was told by
Richard Greenblatt (who has never seen a KI he said) that they simply
found the KI to be disappointing. Not enough of an improvement over the
KA to justify replacing the KAs, still no real paging in particular.

Angelo

[Johnny Billquist]

Post by Angelo Papenhoff

Post by Johnny Billquist
Really? The KA10 itself predates the Unibus. I guess it's possible they
added the ability to hook up Unibuses later in the life of the machine,
but the KI would have been around at that point as well, so a bit
surprising that they'd do anything with the KA at that point.

Lars and Rich already commented, but I wanted to add that I was told by
Richard Greenblatt (who has never seen a KI he said) that they simply
found the KI to be disappointing. Not enough of an improvement over the
KA to justify replacing the KAs, still no real paging in particular.

Yep, with the information from Rich and Lars I now understand better
what this was.

As for the pager in the KI, it's a well known story. I still the KI
looks nicer, though. :-)

Johnny