PDP-15 I/O Device Expansion

[cmgauger]

I've recently begun screwing around with the PDP-15 simulator and the available operating systems again, and I've been thinking about how to go about implementing some of the peripherals the PDP-15 is missing.

First, let's go over the "missing" peripherals for the PDP-15:

1. CR15 or CR03B card reader
2. VT15 graphics display
3. VW01 writing tablet
4. UNICHANNEL-15 + associated peripherals

I personally have don't have a use for or, find I'm very interested in, the VT15 or VW01, so I'm going to ignore those (however, I do welcome individuals who are interested in them to contribute ideas).

So let's address the CR15 and CR03B readers first since they would probably be the simpler of the missing peripherals to implement.

I cannot find documentation on the CR15 reader and control, so I don't know how different it is in comparison to the CR03B; neither have I found documentation on the CR03B reader and control specifically, however, extrapolating on information present in the PDP-9 User Handbook, the CR03B reader control is probably of the same functionality as the control of the CR01B and CR02B, the difference between the three models of CR0xB reader being speed of operation (CR01B at 100 cards per minute, CR02B at 200 cards per minute, and I'm going to assume the CR03B was 300 cards per minute).

From the information in the PDP-9 handbook -- a description of the IOT instructions responsible for card reader control, and the general operation of the reader control and readers themselves, would it be possible to reconstruct the CR0xB reader of the PDP-9 and PDP-15?

As I mentioned earlier I am unsure of how the CR15 card reader and control match up with that of the CR0xB reader and control.

Now, I'm going to address the elephant in the room, namely the UNICHANNEL-15 option and its associated peripherals. I have asked on the mailing list with regards to SIMH and multiple processor systems before, including the UC15. While I'm not nearly competent enough to actually implement a device or anything approching multiple processor support, I have been thinking of ways to go about getting the PDP-15 it's quite popular UC15 attachment.

The UC15 at it's most basic and stripped down form, is a PDP-11/05, with 4KW or 8KW of local/private memory, and the remaining 24KW or 28KW of memory shared with the PDP-15. The PDP-11 is also equipped with two DR11C interfaces, and the PDP-15 with a DR15 interface. The PDP-11 runs a standalone software system known as PIREX loaded from paper tape by the PDP-15; through the DRxx devices the two computer systems may interrupt each other as well as present information and commands. (Data is transferred via the shared memory.) Depending on peripheral configuration, and operating system configuration, the PDP-11 might also be running the SPOL11 spooler program, and small MAC11 (the name of the PDP-11 assembler which is available in XVM/DOS and XVM/RSX) assembler programs written on the PDP-15.

The PDP-11 peripherals which were supported by the PDP-15 software are:

1. RK15 RK05 system
2. LP11 lineprinter
3. LS11 lineprinter
4. LV11 printer-plotter
5. CR11 card reader
6. XY11 plotter control

Of these, the LP11 and CR11 are already implemented in the SIMH PDP-11, and the RK15 is based upon the RK11, but more on that in a minute. I'm not entirely sure, but I do recall the LS11 lineprinter is unnecessary to implement due to being "the same" as the LP11 from a software perspective. The LV11 is an interesting device, however I do not see great use being made of it. Similarly so with the XY11, I see no great use being made of it, although a plotter "engine" if implemented would allow for implementing plotters in the '8 and other 18-bit systems. (Plotter "engine" as in something with could understand the movement commands and pen-up/pen-down commands and turn that into some sort of graphics file.)

The RK15 makes use of the RK11-E controller, which works much like the standard RK11 controller, except it provides the facilities for 18-bit DMA. Disk format is 12 sector packs with 256 18-bit words per sector.

Because of the complexity of the UC15 system, I have conceived of three possibilities for implementing its functionality in SIMH:

1. The Direct Approach -- Implementing multiprocessor support within SIMH, which will probably require a hefty rewrite of the simulator core, to allow the PDP-15 simulator to incorporate a stripped down PDP-11 processor and peripheral set. This approach would be the most friendly for the end users of the software; however this method would probably require the most work in the nitty gritty parts of SIMH, but would probably result in a great benefit for other simulators (by which I mean the VAX and PDP-11 simulators; if SIMH could simulate a KL10, then also for a theoretical KL10 simulator too).
2. The Indirect Approach -- Implementing within both the PDP-15 and PDP-11 simulators an interface to allow two separate simulator programs to interface. The PDP-11 would need a new CPU model option "UC-15", which would:
   a. Disable all unsupported devices, while enabling the PDP-15 connection parts.
   b. Enable 18-bit DMA on the part of the RK11.
   c. "Start" the processor, and put the entire thing under the control of the PDP-15.
   This would also probably require some large amount of work to implement. And while I personally think it would be easier to implement than native multiprocessor support within SIMH itself, it doesn't come with as many benefits.
3. PIREX/SPOL11 Emulation -- Eschewing implementing any from of intersimulator/interprocessor communication at all. Instead a new device driver is written which simulates the function of PIREX and the SPOL11 spooler; peripherals would have to be controlled through a la the RHA/RHB devices for the RP and TU controllers of the PDP-11. This method however doesn't allow for the running of PDP-11 software developed on the PDP-15. (Plus one would need to deal with the states of the PIREX and SPOL11 software.)

In conclusion and as a summary, at a minimum the CR0xB card readers for the PDP-9 and PDP-15 would be "relatively" easy to implement, however the CR15 card reader is lacking in information needed to implement it. Further the UNICHANNEL-15 option -- specifically the RK15 disk system -- would be an excellent thing to have added to the PDP-15, however the only options that I personally can see of implementing it are non-trivial.

Comments are welcome.

[mgthompson]

On Tue, Jan 14, 2014 at 1:16 PM, Christian Gauger-Cosgrove <
notifications@github.com> wrote:

I've recently begun screwing around with the PDP-15 simulator and the
available operating systems again, and I've been thinking about how to go
about implementing some of the peripherals the PDP-15 is missing.

First, let's go over the "missing" peripherals for the PDP-15:

1. CR15 or CR03B card reader
2. VT15 graphics display
3. VW01 writing tablet
4. UNICHANNEL-15 + associated peripherals

I personally have don't have a use for or, find I'm very interested in,
the VT15 or VW01, so I'm going to ignore those (however, I do welcome
individuals who are interested in them to contribute ideas).

So let's address the CR15 and CR03B readers first since they would
probably be the simpler of the missing peripherals to implement.

I cannot find documentation on the CR15 reader and control, so I don't
know how different it is in comparison to the CR03B; neither have I found
documentation on the CR03B reader and control specifically, however,
extrapolating on information present in the PDP-9 User Handbook, the CR03B
reader control is probably of the same functionality as the control of the
CR01B and CR02B, the difference between the three models of CR0xB reader
being speed of operation (CR01B at 100 cards per minute, CR02B at 200 cards
per minute, and I'm going to assume the CR03B was 300 cards per minute).

From the information in the PDP-9 handbook -- a description of the IOT
instructions responsible for card reader control, and the general operation
of the reader control and readers themselves, would it be possible to
reconstruct the CR0xB reader of the PDP-9 and PDP-15?

As I mentioned earlier I am unsure of how the CR15 card reader and control
match up with that of the CR0xB reader and control.

Now, I'm going to address the elephant in the room, namely the
UNICHANNEL-15 option and its associated peripherals. I have asked on the
mailing list with regards to SIMH and multiple processor systems before,
including the UC15. While I'm not nearly competent enough to actually
implement a device or anything approching multiple processor support, I
have been thinking of ways to go about getting the PDP-15 it's quite
popular UC15 attachment.

The UC15 at it's most basic and stripped down form, is a PDP-11/05, with
4KW or 8KW of local/private memory, and the remaining 24KW or 28KW of
memory shared with the PDP-15. The PDP-11 is also equipped with two DR11C
interfaces, and the PDP-15 with a DR15 interface. The PDP-11 runs a
standalone software system known as PIREX loaded from paper tape by the
PDP-15; through the DRxx devices the two computer systems may interrupt
each other as well as present information and commands. (Data is
transferred via the shared memory.) Depending on peripheral configuration,
and operating system configuration, the PDP-11 might also be running the
SPOL11 spooler program, and small MAC11 (the name of the PDP-11 assembler
which is available in XVM/DOS and XVM/RSX) assembler programs written on
the PDP-15.

The PDP-11 peripherals which were supported by the PDP-15 software are:

1. RK15 RK05 system
2. LP11 lineprinter
3. LS11 lineprinter
4. LV11 printer-plotter
5. CR11 card reader
6. XY11 plotter control

Of these, the LP11 and CR11 are already implemented in the SIMH PDP-11,
and the RK15 is based upon the RK11, but more on that in a minute. I'm not
entirely sure, but I do recall the LS11 lineprinter is unnecessary to
implement due to being "the same" as the LP11 from a software perspective.
The LV11 is an interesting device, however I do not see great use being
made of it. Similarly so with the XY11, I see no great use being made of
it, although a plotter "engine" if implemented would allow for implementing
plotters in the '8 and other 18-bit systems. (Plotter "engine" as in
something with could understand the movement commands and pen-up/pen-down
commands and turn that into some sort of graphics file.)

The RK15 makes use of the RK11-E controller, which works much like the
standard RK11 controller, except it provides the facilities for 18-bit DMA.
Disk format is 12 sector packs with 256 18-bit words per sector.

Because of the complexity of the UC15 system, I have conceived of three
possibilities for implementing its functionality in SIMH:

1. The Direct Approach -- Implementing multiprocessor support within SIMH,
   which will probably require a hefty rewrite of the simulator core, to allow
   the PDP-15 simulator to incorporate a stripped down PDP-11 processor and
   peripheral set. This approach would be the most friendly for the end users
   of the software; however this method would probably require the most work
   in the nitty gritty parts of SIMH, but would probably result in a great
   benefit for other simulators (by which I mean the VAX and PDP-11
   simulators; if SIMH could simulate a KL10, then also for a theoretical KL10
   simulator too).
2. The Indirect Approach -- Implementing within both the PDP-15 and PDP-11
   simulators an interface to allow two separate simulator programs to
   interface. The PDP-11 would need a new CPU model option "UC-15", which
   would:
   a. Disable all unsupported devices, while enabling the PDP-15 connection
   parts.
   b. Enable 18-bit DMA on the part of the RK11.
   c. "Start" the processor, and put the entire thing under the control of
   the PDP-15.
   This would also probably require some large amount of work to implement.
   And while I personally think it would be easier to implement than native
   multiprocessor support within SIMH itself, it doesn't come with as many
   benefits.
3. PIREX/SPOL11 Emulation -- Eschewing implementing any from of
   intersimulator/interprocessor communication at all. Instead a new device
   driver is written which simulates the function of PIREX and the SPOL11
   spooler; peripherals would have to be controlled through a la the RHA/RHB
   devices for the RP and TU controllers of the PDP-11. This method however
   doesn't allow for the running of PDP-11 software developed on the PDP-15.
   (Plus one would need to deal with the states of the PIREX and SPOL11
   software.)

In conclusion and as a summary, at a minimum the CR0xB card readers for
the PDP-9 and PDP-15 would be "relatively" easy to implement, however the
CR15 card reader is lacking in information needed to implement it. Further
the UNICHANNEL-15 option -- specifically the RK15 disk system -- would be
an excellent thing to have added to the PDP-15, however the only options
that I personally can see of implementing it are non-trivial.

Comments are welcome.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/96
.

The PDF documents MAINDEC-15-DAUCA-B-D_Unichannel-15_Diagnostic_Jan74.pdf,
and MAINDEC-15-DAUCC-A-D_Unichannel15_Exerciser_Module_Jul73.pdf include
some source code that might give you some insight to the Unichannel device.

I am restoring a TC59 connected to a PDP-9. I disassembled some of the
PDP-9 Maindecs to see what the diagnostics really did, and found quite a
few undocumented IOT instructions. The TC59 schematics clearly show how the
undocumented IOTs are implemented once you know that they are there and
what to look for. You may find that the PDP-15 controllers also have
undocumented IOTs too.

The PDF XVM_SystemUpgrades.pdf, shows how to how to add the Unichannel to a
PDP-15. That might be interesting reading for you.

Mike Ross in New Zealand has a PDP-15, and might have additional

information or documentation.

Michael Thompson

[ArcaneTourist]

On Tue, Jan 14, 2014 at 10:53:44AM -0800, Michael Thompson wrote:

On Tue, Jan 14, 2014 at 1:16 PM, Christian Gauger-Cosgrove <
notifications@github.com> wrote:

I've recently begun screwing around with the PDP-15 simulator and the
available operating systems again, and I've been thinking about how to go
about implementing some of the peripherals the PDP-15 is missing.

First, let's go over the "missing" peripherals for the PDP-15:

1. CR15 or CR03B card reader
2. VT15 graphics display
3. VW01 writing tablet
4. UNICHANNEL-15 + associated peripherals

I personally have don't have a use for or, find I'm very interested in,
the VT15 or VW01, so I'm going to ignore those (however, I do welcome
individuals who are interested in them to contribute ideas).

So let's address the CR15 and CR03B readers first since they would
probably be the simpler of the missing peripherals to implement.

I cannot find documentation on the CR15 reader and control, so I don't
know how different it is in comparison to the CR03B; neither have I found
documentation on the CR03B reader and control specifically, however,
extrapolating on information present in the PDP-9 User Handbook, the CR03B
reader control is probably of the same functionality as the control of the
CR01B and CR02B, the difference between the three models of CR0xB reader
being speed of operation (CR01B at 100 cards per minute, CR02B at 200 cards
per minute, and I'm going to assume the CR03B was 300 cards per minute).

From the information in the PDP-9 handbook -- a description of the IOT
instructions responsible for card reader control, and the general operation
of the reader control and readers themselves, would it be possible to
reconstruct the CR0xB reader of the PDP-9 and PDP-15?

As I mentioned earlier I am unsure of how the CR15 card reader and control
match up with that of the CR0xB reader and control.

Now, I'm going to address the elephant in the room, namely the
UNICHANNEL-15 option and its associated peripherals. I have asked on the
mailing list with regards to SIMH and multiple processor systems before,
including the UC15. While I'm not nearly competent enough to actually
implement a device or anything approching multiple processor support, I
have been thinking of ways to go about getting the PDP-15 it's quite
popular UC15 attachment.

The UC15 at it's most basic and stripped down form, is a PDP-11/05, with
4KW or 8KW of local/private memory, and the remaining 24KW or 28KW of
memory shared with the PDP-15. The PDP-11 is also equipped with two DR11C
interfaces, and the PDP-15 with a DR15 interface. The PDP-11 runs a
standalone software system known as PIREX loaded from paper tape by the
PDP-15; through the DRxx devices the two computer systems may interrupt
each other as well as present information and commands. (Data is
transferred via the shared memory.) Depending on peripheral configuration,
and operating system configuration, the PDP-11 might also be running the
SPOL11 spooler program, and small MAC11 (the name of the PDP-11 assembler
which is available in XVM/DOS and XVM/RSX) assembler programs written on
the PDP-15.

The PDP-11 peripherals which were supported by the PDP-15 software are:

1. RK15 RK05 system
2. LP11 lineprinter
3. LS11 lineprinter
4. LV11 printer-plotter
5. CR11 card reader
6. XY11 plotter control

Of these, the LP11 and CR11 are already implemented in the SIMH PDP-11,
and the RK15 is based upon the RK11, but more on that in a minute. I'm not
entirely sure, but I do recall the LS11 lineprinter is unnecessary to
implement due to being "the same" as the LP11 from a software perspective.
The LV11 is an interesting device, however I do not see great use being
made of it. Similarly so with the XY11, I see no great use being made of
it, although a plotter "engine" if implemented would allow for implementing
plotters in the '8 and other 18-bit systems. (Plotter "engine" as in
something with could understand the movement commands and pen-up/pen-down
commands and turn that into some sort of graphics file.)

The RK15 makes use of the RK11-E controller, which works much like the
standard RK11 controller, except it provides the facilities for 18-bit DMA.
Disk format is 12 sector packs with 256 18-bit words per sector.

Because of the complexity of the UC15 system, I have conceived of three
possibilities for implementing its functionality in SIMH:

1. The Direct Approach -- Implementing multiprocessor support within SIMH,
   which will probably require a hefty rewrite of the simulator core, to allow
   the PDP-15 simulator to incorporate a stripped down PDP-11 processor and
   peripheral set. This approach would be the most friendly for the end users
   of the software; however this method would probably require the most work
   in the nitty gritty parts of SIMH, but would probably result in a great
   benefit for other simulators (by which I mean the VAX and PDP-11
   simulators; if SIMH could simulate a KL10, then also for a theoretical KL10
   simulator too).
2. The Indirect Approach -- Implementing within both the PDP-15 and PDP-11
   simulators an interface to allow two separate simulator programs to
   interface. The PDP-11 would need a new CPU model option "UC-15", which
   would:
   a. Disable all unsupported devices, while enabling the PDP-15 connection
   parts.
   b. Enable 18-bit DMA on the part of the RK11.
   c. "Start" the processor, and put the entire thing under the control of
   the PDP-15.
   This would also probably require some large amount of work to implement.
   And while I personally think it would be easier to implement than native
   multiprocessor support within SIMH itself, it doesn't come with as many
   benefits.
3. PIREX/SPOL11 Emulation -- Eschewing implementing any from of
   intersimulator/interprocessor communication at all. Instead a new device
   driver is written which simulates the function of PIREX and the SPOL11
   spooler; peripherals would have to be controlled through a la the RHA/RHB
   devices for the RP and TU controllers of the PDP-11. This method however
   doesn't allow for the running of PDP-11 software developed on the PDP-15.
   (Plus one would need to deal with the states of the PIREX and SPOL11
   software.)

In conclusion and as a summary, at a minimum the CR0xB card readers for
the PDP-9 and PDP-15 would be "relatively" easy to implement, however the
CR15 card reader is lacking in information needed to implement it. Further
the UNICHANNEL-15 option -- specifically the RK15 disk system -- would be
an excellent thing to have added to the PDP-15, however the only options
that I personally can see of implementing it are non-trivial.

Comments are welcome.

???
Reply to this email directly or view it on GitHubhttps://github.com//issues/96
.

The PDF documents MAINDEC-15-DAUCA-B-D_Unichannel-15_Diagnostic_Jan74.pdf,
and MAINDEC-15-DAUCC-A-D_Unichannel15_Exerciser_Module_Jul73.pdf include
some source code that might give you some insight to the Unichannel device.

I am restoring a TC59 connected to a PDP-9. I disassembled some of the
PDP-9 Maindecs to see what the diagnostics really did, and found quite a
few undocumented IOT instructions. The TC59 schematics clearly show how the
undocumented IOTs are implemented once you know that they are there and
what to look for. You may find that the PDP-15 controllers also have
undocumented IOTs too.

The PDF XVM_SystemUpgrades.pdf, shows how to how to add the Unichannel to a
PDP-15. That might be interesting reading for you.

Mike Ross in New Zealand has a PDP-15, and might have additional

information or documentation.

Michael Thompson

As far as simulating the UNICHANNEL-15 and associated peripherals,
you could do what I did for a similar situation for an emulator
I'm writing. I suspect you've already thought of this, but I'm
not sure.... As hinted in the SIMH docs, one approach to simulating
a system with multiple CPUs or active devices is to have your
sim_instr() simply alternate between doing work on behalf of two
different CPUs (or devices). Of course, most of the existing emulators
are coded with global variables for the CPU registers which would make
it difficult to support multiple CPUs -- you need a copy of every
variable for each of the CPUs or devices. One ugly approach would be
to take a copy of the pdp11 code and duplicate it and rename all the
variables and functions. Horribly ugly, but it might be the quickest
hack for a test approach.

For my purposes, I was starting from scratch and the "IOM"
I/O multiplexor was rather different from the CPU, so I just had
completely separate SIMH devices, variables, etc. As it turns out, I
don't need to run the IOM from my sim_instr(); all the activity for
the IOM is handled as queued events. The IOM queues activities
for other devices. The other devices queue the IOM when they have
info to report to the IOM. The IOM also sometimes queues events for
itself either to simulate delays or to allow the CPU to run "in parallel".

Thus, even though the IOM is semi-programmable, it acts to SIMH more
as a device that just happens to interact a lot with other devices.

Michael

mailing list with regards to SIMH and multiple processor systems before,

[mgthompson]

On Wed, Jan 15, 2014 at 7:37 PM, Mike Mondy notifications@github.comwrote:

On Tue, Jan 14, 2014 at 10:53:44AM -0800, Michael Thompson wrote:

On Tue, Jan 14, 2014 at 1:16 PM, Christian Gauger-Cosgrove <
notifications@github.com> wrote:

I've recently begun screwing around with the PDP-15 simulator and the
available operating systems again, and I've been thinking about how to
go
about implementing some of the peripherals the PDP-15 is missing.

First, let's go over the "missing" peripherals for the PDP-15:

1. CR15 or CR03B card reader
2. VT15 graphics display
3. VW01 writing tablet
4. UNICHANNEL-15 + associated peripherals

I personally have don't have a use for or, find I'm very interested in,
the VT15 or VW01, so I'm going to ignore those (however, I do welcome
individuals who are interested in them to contribute ideas).

So let's address the CR15 and CR03B readers first since they would
probably be the simpler of the missing peripherals to implement.

I cannot find documentation on the CR15 reader and control, so I don't
know how different it is in comparison to the CR03B; neither have I
found
documentation on the CR03B reader and control specifically, however,
extrapolating on information present in the PDP-9 User Handbook, the
CR03B
reader control is probably of the same functionality as the control of
the
CR01B and CR02B, the difference between the three models of CR0xB
reader
being speed of operation (CR01B at 100 cards per minute, CR02B at 200
cards
per minute, and I'm going to assume the CR03B was 300 cards per
minute).

From the information in the PDP-9 handbook -- a description of the IOT
instructions responsible for card reader control, and the general
operation
of the reader control and readers themselves, would it be possible to
reconstruct the CR0xB reader of the PDP-9 and PDP-15?

As I mentioned earlier I am unsure of how the CR15 card reader and
control
match up with that of the CR0xB reader and control.

Now, I'm going to address the elephant in the room, namely the
UNICHANNEL-15 option and its associated peripherals. I have asked on
the
mailing list with regards to SIMH and multiple processor systems
before,
including the UC15. While I'm not nearly competent enough to actually
implement a device or anything approching multiple processor support, I
have been thinking of ways to go about getting the PDP-15 it's quite
popular UC15 attachment.

The UC15 at it's most basic and stripped down form, is a PDP-11/05,
with
4KW or 8KW of local/private memory, and the remaining 24KW or 28KW of
memory shared with the PDP-15. The PDP-11 is also equipped with two
DR11C
interfaces, and the PDP-15 with a DR15 interface. The PDP-11 runs a
standalone software system known as PIREX loaded from paper tape by the
PDP-15; through the DRxx devices the two computer systems may interrupt
each other as well as present information and commands. (Data is
transferred via the shared memory.) Depending on peripheral
configuration,
and operating system configuration, the PDP-11 might also be running
the
SPOL11 spooler program, and small MAC11 (the name of the PDP-11
assembler
which is available in XVM/DOS and XVM/RSX) assembler programs written
on
the PDP-15.

The PDP-11 peripherals which were supported by the PDP-15 software are:

1. RK15 RK05 system
2. LP11 lineprinter
3. LS11 lineprinter
4. LV11 printer-plotter
5. CR11 card reader
6. XY11 plotter control

Of these, the LP11 and CR11 are already implemented in the SIMH PDP-11,
and the RK15 is based upon the RK11, but more on that in a minute. I'm
not
entirely sure, but I do recall the LS11 lineprinter is unnecessary to
implement due to being "the same" as the LP11 from a software
perspective.
The LV11 is an interesting device, however I do not see great use being
made of it. Similarly so with the XY11, I see no great use being made
of
it, although a plotter "engine" if implemented would allow for
implementing
plotters in the '8 and other 18-bit systems. (Plotter "engine" as in
something with could understand the movement commands and
pen-up/pen-down
commands and turn that into some sort of graphics file.)

The RK15 makes use of the RK11-E controller, which works much like the
standard RK11 controller, except it provides the facilities for 18-bit
DMA.
Disk format is 12 sector packs with 256 18-bit words per sector.

Because of the complexity of the UC15 system, I have conceived of three
possibilities for implementing its functionality in SIMH:

1. The Direct Approach -- Implementing multiprocessor support within
   SIMH,
   which will probably require a hefty rewrite of the simulator core, to
   allow
   the PDP-15 simulator to incorporate a stripped down PDP-11 processor
   and
   peripheral set. This approach would be the most friendly for the end
   users
   of the software; however this method would probably require the most
   work
   in the nitty gritty parts of SIMH, but would probably result in a great
   benefit for other simulators (by which I mean the VAX and PDP-11
   simulators; if SIMH could simulate a KL10, then also for a theoretical
   KL10
   simulator too).
2. The Indirect Approach -- Implementing within both the PDP-15 and
   PDP-11
   simulators an interface to allow two separate simulator programs to
   interface. The PDP-11 would need a new CPU model option "UC-15", which
   would:
   a. Disable all unsupported devices, while enabling the PDP-15
   connection
   parts.
   b. Enable 18-bit DMA on the part of the RK11.
   c. "Start" the processor, and put the entire thing under the control of
   the PDP-15.
   This would also probably require some large amount of work to
   implement.
   And while I personally think it would be easier to implement than
   native
   multiprocessor support within SIMH itself, it doesn't come with as many
   benefits.
3. PIREX/SPOL11 Emulation -- Eschewing implementing any from of
   intersimulator/interprocessor communication at all. Instead a new
   device
   driver is written which simulates the function of PIREX and the SPOL11
   spooler; peripherals would have to be controlled through a la the
   RHA/RHB
   devices for the RP and TU controllers of the PDP-11. This method
   however
   doesn't allow for the running of PDP-11 software developed on the
   PDP-15.
   (Plus one would need to deal with the states of the PIREX and SPOL11
   software.)

In conclusion and as a summary, at a minimum the CR0xB card readers for
the PDP-9 and PDP-15 would be "relatively" easy to implement, however
the
CR15 card reader is lacking in information needed to implement it.
Further
the UNICHANNEL-15 option -- specifically the RK15 disk system -- would
be
an excellent thing to have added to the PDP-15, however the only
options
that I personally can see of implementing it are non-trivial.

Comments are welcome.

???
Reply to this email directly or view it on GitHub<
https://github.com/simh/simh/issues/96>

.

The PDF documents
MAINDEC-15-DAUCA-B-D_Unichannel-15_Diagnostic_Jan74.pdf,
and MAINDEC-15-DAUCC-A-D_Unichannel15_Exerciser_Module_Jul73.pdf include
some source code that might give you some insight to the Unichannel
device.

I am restoring a TC59 connected to a PDP-9. I disassembled some of the
PDP-9 Maindecs to see what the diagnostics really did, and found quite a
few undocumented IOT instructions. The TC59 schematics clearly show how
the
undocumented IOTs are implemented once you know that they are there and
what to look for. You may find that the PDP-15 controllers also have
undocumented IOTs too.

The PDF XVM_SystemUpgrades.pdf, shows how to how to add the Unichannel
to a
PDP-15. That might be interesting reading for you.

Mike Ross in New Zealand has a PDP-15, and might have additional

information or documentation.

Michael Thompson

As far as simulating the UNICHANNEL-15 and associated peripherals,
you could do what I did for a similar situation for an emulator
I'm writing. I suspect you've already thought of this, but I'm
not sure.... As hinted in the SIMH docs, one approach to simulating
a system with multiple CPUs or active devices is to have your
sim_instr() simply alternate between doing work on behalf of two
different CPUs (or devices). Of course, most of the existing emulators
are coded with global variables for the CPU registers which would make
it difficult to support multiple CPUs -- you need a copy of every
variable for each of the CPUs or devices. One ugly approach would be
to take a copy of the pdp11 code and duplicate it and rename all the
variables and functions. Horribly ugly, but it might be the quickest
hack for a test approach.

For my purposes, I was starting from scratch and the "IOM"
I/O multiplexor was rather different from the CPU, so I just had
completely separate SIMH devices, variables, etc. As it turns out, I
don't need to run the IOM from my sim_instr(); all the activity for
the IOM is handled as queued events. The IOM queues activities
for other devices. The other devices queue the IOM when they have
info to report to the IOM. The IOM also sometimes queues events for
itself either to simulate delays or to allow the CPU to run "in parallel".

Thus, even though the IOM is semi-programmable, it acts to SIMH more
as a device that just happens to interact a lot with other devices.

Michael

mailing list with regards to SIMH and multiple processor systems
before,

�

Reply to this email directly or view it on GitHubhttps://github.com//issues/96#issuecomment-32431546
.

I still like the idea of two seperate instances if SIMH that send messages
through a shared UC-15 device.
The same model could be used with many of the processor interfaces that DEC
sold.

Michael Thompson

[R-Voorhorst]

For implementation of a processor instance within a Simh processor emulation one might take a look at the floating point Fpp8/12 processor code in the Pdp-8 set; though that is in fact a coprocessor without I/O, some principles are the same as with an Unichannel like shared memory and different processing streams. The Fpp implementation is quite recently and silently added by Bob Supnik and probably no one has used it yet. Furthermore unichannel devices might also be implemented in a way like HSC/HSJ storage devices (disk/tape) on the Vax series where the storage controller itself has been made transparent. Ymmv ...

Best regards

[cmgauger]

On 14 January 2014 13:53, Michael Thompson notifications@github.com wrote:

The PDF documents MAINDEC-15-DAUCA-B-D_Unichannel-15_Diagnostic_Jan74.pdf,
and MAINDEC-15-DAUCC-A-D_Unichannel15_Exerciser_Module_Jul73.pdf include
some source code that might give you some insight to the Unichannel device.

I am restoring a TC59 connected to a PDP-9. I disassembled some of the
PDP-9 Maindecs to see what the diagnostics really did, and found quite a
few undocumented IOT instructions. The TC59 schematics clearly show how the
undocumented IOTs are implemented once you know that they are there and
what to look for. You may find that the PDP-15 controllers also have
undocumented IOTs too.

The PDF XVM_SystemUpgrades.pdf, shows how to how to add the Unichannel to a
PDP-15. That might be interesting reading for you.

Mike Ross in New Zealand has a PDP-15, and might have additional

information or documentation.

Michael Thompson
Yes, reading over the XVM_SystemUpgrades file was mildly informative;
however, it more or less glosses over the technical aspects of the
UNICHANNEL-15, when compared to the UNICHANNEL-15 overview document
(Unichannel15_Overview_1974.pdf) or the UNICHANNEL-15 System Software
Manual (DEC-15-XUCMA-A-D_UC15sysSw.pdf). The UNICHANNEL-15 System
Reference Manual (DEC-15-XSRMA-A-D_UC15refMan.pdf) does not detail the
technical aspects of the UNICHANNEL-15 interface and the PIREX monitor
software as much as the overview and software manuals.

On 15 January 2014 19:37, Mike Mondy notifications@github.com wrote:

As far as simulating the UNICHANNEL-15 and associated peripherals,
you could do what I did for a similar situation for an emulator
I'm writing. I suspect you've already thought of this, but I'm
not sure.... As hinted in the SIMH docs, one approach to simulating
a system with multiple CPUs or active devices is to have your
sim_instr() simply alternate between doing work on behalf of two
different CPUs (or devices). Of course, most of the existing emulators
are coded with global variables for the CPU registers which would make
it difficult to support multiple CPUs -- you need a copy of every
variable for each of the CPUs or devices. One ugly approach would be
to take a copy of the pdp11 code and duplicate it and rename all the
variables and functions. Horribly ugly, but it might be the quickest
hack for a test approach.

For my purposes, I was starting from scratch and the "IOM"
I/O multiplexor was rather different from the CPU, so I just had
completely separate SIMH devices, variables, etc. As it turns out, I
don't need to run the IOM from my sim_instr(); all the activity for
the IOM is handled as queued events. The IOM queues activities
for other devices. The other devices queue the IOM when they have
info to report to the IOM. The IOM also sometimes queues events for
itself either to simulate delays or to allow the CPU to run "in parallel".

Thus, even though the IOM is semi-programmable, it acts to SIMH more
as a device that just happens to interact a lot with other devices.

Michael
As I explained to Mr. Voorhorst later on in this e-mail, that solution
would possibly work, for some usage cases of the UNICHANNEL-15. But
because the PDP-11 half of the UNICHANNEL is essentially independent
of the PDP-15 half, an approach that allows it to remain such is the
one that is required (annoyingly); though transparent emulation of
PIREX would allow the use of the RK05, CR11, et cetera; but would make
it impossible to use the spooler and MACRO-11 facilities in XVM/DOS
and XVM/RSX.

On 15 January 2014 21:57, Michael Thompson notifications@github.com wrote:

I still like the idea of two seperate instances if SIMH that send messages
through a shared UC-15 device.
The same model could be used with many of the processor interfaces that DEC
sold.

Michael Thompson
I would support the idea of SIMH doing this as separate instances of
SIMH. As some of the ideas could be extended towards the PDP-11/74
(namely the shared memory), while other ideas would allow the
recreation of some of the oddball interfaces like the DBxx series of
interprocessor communications buffers (like the DB88 which will let
two PDP-8s talk over their I/O buses; or the DB97, DB98 and DB99 which
would let a PDP-9/-15 communicate with a PDP-7, PDP-8 or another
PDP-9/-15 over the I/O bus).

There is already some progress towards the latter part, in that the
PDP-11 simulator now has some DDCMP devices which allow two SIMH
instances to connect directly to one another over a simulated DDCMP
connection. That idea could be expanded to allow for the interface of
two interprocessor interrupt buffers, or the bodged together
equivalent of those that appear on between the PDP-11 and PDP-15 in
the UNICHANNEL-15.

Sharing memory is a bit more of an interesting field; in the
UNICHANNEL-15 configuration the connection is simplified, the PDP-15
being the "master" of the memory. However, in a PDP-11/74 system,
you'd need to deal with configuring one of the up to four simulators,
as the memory master, with the other three sharing the memory of the
first (said master system would also need to be the home of the IIST).
But that is somewhat outside the scope of the UNICHANNEL-15.

A bit further off-topic from the PDP-15; using "split-simulation" of
the PDP-11/74 would also necessitate some further modifications for
the PDP-11 simulator, to deal with both shared peripherals (MASSBUS
disk and tape living on the MASSBUS of two different CPUs for
redundancy), and the shared UNIBUS. (Each 11/74 CPU could have some
"private" UNIBUS peripherals, but eventually they would share
peripherals for the sake of redundancy; since it would not be good if
you put all your user data drives on one CPU, and it suddenly dropped
out of the system because of an error.)

On 16 January 2014 04:20, R-Voorhorst notifications@github.com wrote:

For implementation of a processor instance within a Simh processor emulation
one might take a look at the floating point Fpp8/12 processor code in the
Pdp-8 set; though that is in fact a coprocessor without I/O, some principles
are the same as with an Unichannel like shared memory and different
processing streams. The Fpp implementation is quite recently and silently
added by Bob Supnik and probably no one has used it yet. Furthermore
unichannel devices might also be implemented in a way like HSC/HSJ storage
devices (disk/tape) on the Vax series where the storage controller itself
has been made transparent. Ymmv ...

Best regards
The only problem with the comparing the UNICHANNEL-15 to the
FPP-12/FPP-12A/FPP-8A is that the associated PDP-11 system is
essentially independent of the PDP-15 system it is connected to. If
the PDP-15 halts the PDP-11 would still be running and PIREX still
patiently waiting for the PDP-15 to ask it to do things while there
might possibly be a MACRO-11 program written by a user on the '15
doing its thing in the PDP-11 too.

Going by the XVM System Upgrades document, DEC's PDP-15/XVM Marketing
people were specifically advertising that custom UNICHANNEL-15 PDP-11s
could be supplied the example they used being an 11/40 with full 256KB
of RAM, running RT-11 or RSX-11/M (and some custom software to emulate
PIREX, to let the PDP-15 still use the RK05 and PDP-11 peripherals).

So, while having the PDP-11 and PIREX system made transparent to let
the PDP-15 use the RK05, LP11, CR11, et cetera could work; software
might break horribly, e.g. if the PDP-15 tried to load up SPOL11 into
the non-existent PDP-11 and then turned on its spooler.

Based on a bit of the variability of the UNICHANNEL-15 system, the
"best" solution probably would be a split-simulator solution, as
opposed to transparent emulation, direct SMP, or slaved processing.
Plus, a split-simulator approach could be later expanded upon for more
well known SMP systems, like the PDP-11/74 (as I outlined above).

Another potential benefit this could have would be trying something
silly like implementing the DX11 UNIBUS-to-IBM-bus&tag interface;
which would require some co-operation with the Hercules developers,
but could make an interesting project. But that is way, way outside
the scope of this discussion.

Now that I've finished my responses, let's talk some nitty gritty
things about the UNICHANNEL-15, as gleaned from manuals (Software
System Manual, Reference Manual, UNICHANNEL-15 Overview, and XVM
System Upgrades manuals, and the UC15 Engineering Drawings to be
precise).

HARDWARE <<

Firstly, the UC15's PDP-11 in a standard configuration was a
PDP-11/05; it had a local memory of 4, 8, or 12 kiloWORDS (8, 16, 24
KB), and shared 24, 20, or 16 KW (48, 40, or 32 KB) of PDP-15 memory.
Being a PDP-11, programs can only access that 64KB of memory (56KB of
RAM + memory map), however as UNIBUS is 18-bit it can access almost
all of the PDP-15's up to 128 KW of 18-bit memory. Interface to the
PDP-15 other than the shared memory, was through two DR11-C
interfaces.

The PDP-15 end of the UC15 consisted of a DR15-C interface, which was
connected to the DR11-C interfaces, and the actual memory shared
between the two systems. The interface to the memory was through
either an MX15-B memory multiplexer (on a straight PDP-15 system), or
through the XM15 XVM (on the XVM equipped PDP-15/XVM-15 systems).

From the software reference manual; based on the PDP-11's local
memory, the UNIBUS can access the PDP-11's private memory, and all of
the PDP-15's memory save for the last 4, 8, or 12 KW of address space.
The PDP-11's local memory starts at its own location 0, and extends up
to its own addresses 017777, 037777, or 057777; addresses 020000,
040000, or 060000 to 157777 are mapped to the PDP-15's memory starting
at location zero. So a PDP-11 with 8KB of local memory would have
locations 020000 through 157777 shared to the PDP-15's memory
locations 000000 through 037777; et cetera. I may have done the
address math wrong, but an excellent diagram can be found in the
Software System Manual, page 1-4.

A description of the PDP-11 and PDP-15 registers and IOTs
(respectively) can be found in the UNICHANNEL-15 Overview manual,
pages 13 through 17. Further this information can also be found in the
engineering drawings sheets 16 through 22. From the information, the
data which the PDP-11 can output is addresses for the four levels of
hardware API interrupt; which set the corresponding API flag in the
DR15-C, and cause an API interrupt on the PDP-15 (if no higher level
interrupt is in progress, and API/PI interrupts haven't been disabled
either locally on the DR15-C or globally on the PDP-15 itself). The
PDP-15 itself can send information to the PDP-11 on the address of the
Task Control Block Pointer which can be read by the two DR11-C input
registers, as well as clear API flags when API interrupts have
completed. The PDP-11 can be interrupted by the clearing of all API
flags, as well as when a new TCBP address has been sent to the
PDP-11's DR11-Cs.

SOFTWARE <<
I am not touching a description of the PIREX monitor, or PDP-15 OS
device handlers with a fifty foot pole. My MACRO-11 is crap, nevermind
my understanding of MACRO-15. In this case, I will highly recommend
going over the Software System Manual, as it has a very detailed
description of the software which I'm not going to repeat.

Although, I will mention some of the interesting parts to the whole
UNICHANNEL-15 software experience.

Namely, starting the PDP-11 of the UNICHANNEL-15 system is done
through the PDP-15; the PDP-11 doesn't have a console teletype, or its
own high-speed reader/punch, so it shares paper tape I/O with the
PDP-15. From the software manual, loading an absolute binary into the
PDP-11 is a three step process:

1. On the PDP-15, at location 17700 load the ABSL11 tape with the
   hardware read-in switch. Simulator equivalent command:
   LOAD absl11.rim 17700 [on the PDP-15]
2. On the PDP-11, start the processor from address 060000, 100000, or
   120000 (4KW, 8KW, and 12KW systems respectively). Simulator equivalent
   command:
   RUN 60000 [on the PDP-11, with 8KB of RAM, modify with correct address
   for other sizes]
3. Put the PDP-11 absolute binary tape into the PDP-15 reader and
   press the continue switch. Simulator equivalent command:
   ATTACH PTR .abs [on the PDP-15]
   RUN [on the PDP-15]

One could always skip the ABSL11 loading step if you just load the
.abs binary tapes from the PDP-11 simulator; but one would also need
to remember to start the PDP-11 simulator. (At which point one won't
know if the load was correct until any UNICHANNEL-15 activities, like
trying to boot off an RK05 happen, or don't happen.)

The most often use of these ABSL11 load processes was to either load
PIREX, or to load MAINDEC diagnostics.

Once the PDP-11 is running PIREX further loading of software onto the
'11 is done via the PDP-15 operating system of choice, and PIREX. If
the PDP-15 needs to halt and restart, PIREX on the '11 can be left
alone. (Though if the simulators disconnect that would probably result
in PIREX crashing, hard.) Though, if one follows the words of DEC's
PDP-15/XVM Marketing group, if you felt sufficiently perverse, you
could replace the "small" PDP-11/05 with a PDP-11/40, with MMU and
more RAM_, and then have RSX-11M or RT-11 run a program in one area of
memory that acts like PIREX and SPOL11; of course you would need have
some amount of custom software for that, as DEC never did release
RSX-11 or RT-11 software to actually *DO_ that.

Thank you for your replies, and I welcome any more comments.

Regards,
Christian

*: That makes me have to ask, how in the hell does a PDP-11 with an
MMU deal with DMA? One of the "features" of the PDP-11/05 UC15 system,
is that while the PDP-11's program memory is fixed at 64KB (local plus
shared memory, plus the 8KB of memory map), the UNIBUS DMA devices,
specifically the RK11-E have the 18-bit UNIBUS DMA that let's them
Access at a minimum the first 116KW of the PDP-15's memory. (The
remainder being inaccessible.)

If you installed a PDP-11/40, wouldn't that render that particular
feature of the UC15 completely inoperative? Because wouldn't the
PDP-11/40 now have it's 8, 16, or 24 KB of local memory, and 224, 232,
and 240 KB of memory shared with the PDP-15? (Which would lead to all
kinds of "fun" with software, as the PDP-15 wants to use its memory,
while the PDP-11 is trying to run RSX-11 in all that "high" memory.)

My question of how DMA works is... say you did install an 11/40 into a
PDP-15 in the place of an 11/05, and you expanded the PDP-11's memory
to its top of 248KB (minus the KB of memory you want shared with
the PDP-15 on the first page); in UNIBUS DMA beyond the first 56KB,
would data be written to the PDP-11's memory, or to the PDP-15's
memory? Because only bad things could happen if the PDP-15 told the
PDP-11 "have the RK05 dump me some data to " and
the PDP-11 does, only to place it into its own high memory, then
interrupts the PDP-15 to say its finished; resulting in two systems
now getting garbage data.

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

[mgthompson]

On Fri, Jan 17, 2014 at 11:49 AM, Christian Gauger-Cosgrove <
notifications@github.com> wrote:

On 14 January 2014 13:53, Michael Thompson notifications@github.com
wrote:

The PDF documents
MAINDEC-15-DAUCA-B-D_Unichannel-15_Diagnostic_Jan74.pdf,
and MAINDEC-15-DAUCC-A-D_Unichannel15_Exerciser_Module_Jul73.pdf include
some source code that might give you some insight to the Unichannel
device.

I am restoring a TC59 connected to a PDP-9. I disassembled some of the
PDP-9 Maindecs to see what the diagnostics really did, and found quite a
few undocumented IOT instructions. The TC59 schematics clearly show how
the
undocumented IOTs are implemented once you know that they are there and
what to look for. You may find that the PDP-15 controllers also have
undocumented IOTs too.

The PDF XVM_SystemUpgrades.pdf, shows how to how to add the Unichannel
to a
PDP-15. That might be interesting reading for you.

Mike Ross in New Zealand has a PDP-15, and might have additional

information or documentation.

Michael Thompson
Yes, reading over the XVM_SystemUpgrades file was mildly informative;
however, it more or less glosses over the technical aspects of the
UNICHANNEL-15, when compared to the UNICHANNEL-15 overview document
(Unichannel15_Overview_1974.pdf) or the UNICHANNEL-15 System Software
Manual (DEC-15-XUCMA-A-D_UC15sysSw.pdf). The UNICHANNEL-15 System
Reference Manual (DEC-15-XSRMA-A-D_UC15refMan.pdf) does not detail the
technical aspects of the UNICHANNEL-15 interface and the PIREX monitor
software as much as the overview and software manuals.

Since some of the technical documentation for the PDP-9 is "thin" we
resorted to writing a PDP-9/PDP-15 disassembler for the HRI formatted
diagnostic paper tapes. The disassembler quickly found undocumented IOT
instructions for the TC59 tape controller. After digging through the
schematics we found that with these uncodumented IOTs you could force a
data-break, and read/write the data and command buffers.

Maybe you could decompile PIREX and parts of XVM/DOS to see how they
interact with the Unichannel?

On 15 January 2014 19:37, Mike Mondy notifications@github.com wrote:

As far as simulating the UNICHANNEL-15 and associated peripherals,
you could do what I did for a similar situation for an emulator
I'm writing. I suspect you've already thought of this, but I'm
not sure.... As hinted in the SIMH docs, one approach to simulating
a system with multiple CPUs or active devices is to have your
sim_instr() simply alternate between doing work on behalf of two
different CPUs (or devices). Of course, most of the existing emulators
are coded with global variables for the CPU registers which would make
it difficult to support multiple CPUs -- you need a copy of every
variable for each of the CPUs or devices. One ugly approach would be
to take a copy of the pdp11 code and duplicate it and rename all the
variables and functions. Horribly ugly, but it might be the quickest
hack for a test approach.

For my purposes, I was starting from scratch and the "IOM"
I/O multiplexor was rather different from the CPU, so I just had
completely separate SIMH devices, variables, etc. As it turns out, I
don't need to run the IOM from my sim_instr(); all the activity for
the IOM is handled as queued events. The IOM queues activities
for other devices. The other devices queue the IOM when they have
info to report to the IOM. The IOM also sometimes queues events for
itself either to simulate delays or to allow the CPU to run "in
parallel".

Thus, even though the IOM is semi-programmable, it acts to SIMH more
as a device that just happens to interact a lot with other devices.

Michael
As I explained to Mr. Voorhorst later on in this e-mail, that solution
would possibly work, for some usage cases of the UNICHANNEL-15. But
because the PDP-11 half of the UNICHANNEL is essentially independent
of the PDP-15 half, an approach that allows it to remain such is the
one that is required (annoyingly); though transparent emulation of
PIREX would allow the use of the RK05, CR11, et cetera; but would make
it impossible to use the spooler and MACRO-11 facilities in XVM/DOS
and XVM/RSX.

On 15 January 2014 21:57, Michael Thompson notifications@github.com
wrote:

I still like the idea of two seperate instances if SIMH that send
messages
through a shared UC-15 device.
The same model could be used with many of the processor interfaces that
DEC
sold.

Michael Thompson
I would support the idea of SIMH doing this as separate instances of
SIMH. As some of the ideas could be extended towards the PDP-11/74
(namely the shared memory), while other ideas would allow the
recreation of some of the oddball interfaces like the DBxx series of
interprocessor communications buffers (like the DB88 which will let
two PDP-8s talk over their I/O buses; or the DB97, DB98 and DB99 which
would let a PDP-9/-15 communicate with a PDP-7, PDP-8 or another
PDP-9/-15 over the I/O bus).

You could add the PCL-11 to this list.

There is already some progress towards the latter part, in that the
PDP-11 simulator now has some DDCMP devices which allow two SIMH
instances to connect directly to one another over a simulated DDCMP
connection. That idea could be expanded to allow for the interface of
two interprocessor interrupt buffers, or the bodged together
equivalent of those that appear on between the PDP-11 and PDP-15 in
the UNICHANNEL-15.

Sharing memory is a bit more of an interesting field; in the
UNICHANNEL-15 configuration the connection is simplified, the PDP-15
being the "master" of the memory. However, in a PDP-11/74 system,
you'd need to deal with configuring one of the up to four simulators,
as the memory master, with the other three sharing the memory of the
first (said master system would also need to be the home of the IIST).
But that is somewhat outside the scope of the UNICHANNEL-15.

A bit further off-topic from the PDP-15; using "split-simulation" of
the PDP-11/74 would also necessitate some further modifications for
the PDP-11 simulator, to deal with both shared peripherals (MASSBUS
disk and tape living on the MASSBUS of two different CPUs for
redundancy), and the shared UNIBUS. (Each 11/74 CPU could have some
"private" UNIBUS peripherals, but eventually they would share
peripherals for the sake of redundancy; since it would not be good if
you put all your user data drives on one CPU, and it suddenly dropped
out of the system because of an error.)

On 16 January 2014 04:20, R-Voorhorst notifications@github.com wrote:

For implementation of a processor instance within a Simh processor
emulation
one might take a look at the floating point Fpp8/12 processor code in the
Pdp-8 set; though that is in fact a coprocessor without I/O, some
principles
are the same as with an Unichannel like shared memory and different
processing streams. The Fpp implementation is quite recently and silently
added by Bob Supnik and probably no one has used it yet. Furthermore
unichannel devices might also be implemented in a way like HSC/HSJ
storage
devices (disk/tape) on the Vax series where the storage controller itself
has been made transparent. Ymmv ...

Best regards
The only problem with the comparing the UNICHANNEL-15 to the
FPP-12/FPP-12A/FPP-8A is that the associated PDP-11 system is
essentially independent of the PDP-15 system it is connected to. If
the PDP-15 halts the PDP-11 would still be running and PIREX still
patiently waiting for the PDP-15 to ask it to do things while there
might possibly be a MACRO-11 program written by a user on the '15
doing its thing in the PDP-11 too.

I believe that the KL-10/PDP-11 interface has a way for the KL-10 and the
PDP-11 to tell if their counterpart has crashed. Maybe PIREX and XVM/DOS
send keep-alive messages back and fourth to check the health of their
counterpart.

Going by the XVM System Upgrades document, DEC's PDP-15/XVM Marketing
people were specifically advertising that custom UNICHANNEL-15 PDP-11s
could be supplied the example they used being an 11/40 with full 256KB
of RAM, running RT-11 or RSX-11/M (and some custom software to emulate
PIREX, to let the PDP-15 still use the RK05 and PDP-11 peripherals).

So, while having the PDP-11 and PIREX system made transparent to let
the PDP-15 use the RK05, LP11, CR11, et cetera could work; software
might break horribly, e.g. if the PDP-15 tried to load up SPOL11 into
the non-existent PDP-11 and then turned on its spooler.

Based on a bit of the variability of the UNICHANNEL-15 system, the
"best" solution probably would be a split-simulator solution, as
opposed to transparent emulation, direct SMP, or slaved processing.
Plus, a split-simulator approach could be later expanded upon for more
well known SMP systems, like the PDP-11/74 (as I outlined above).

Another potential benefit this could have would be trying something
silly like implementing the DX11 UNIBUS-to-IBM-bus&tag interface;
which would require some co-operation with the Hercules developers,
but could make an interesting project. But that is way, way outside
the scope of this discussion.

Now that I've finished my responses, let's talk some nitty gritty
things about the UNICHANNEL-15, as gleaned from manuals (Software
System Manual, Reference Manual, UNICHANNEL-15 Overview, and XVM
System Upgrades manuals, and the UC15 Engineering Drawings to be
precise).

HARDWARE <<

Firstly, the UC15's PDP-11 in a standard configuration was a
PDP-11/05; it had a local memory of 4, 8, or 12 kiloWORDS (8, 16, 24
KB), and shared 24, 20, or 16 KW (48, 40, or 32 KB) of PDP-15 memory.
Being a PDP-11, programs can only access that 64KB of memory (56KB of
RAM + memory map), however as UNIBUS is 18-bit it can access almost
all of the PDP-15's up to 128 KW of 18-bit memory. Interface to the
PDP-15 other than the shared memory, was through two DR11-C
interfaces.

The PDP-15 end of the UC15 consisted of a DR15-C interface, which was
connected to the DR11-C interfaces, and the actual memory shared
between the two systems. The interface to the memory was through
either an MX15-B memory multiplexer (on a straight PDP-15 system), or
through the XM15 XVM (on the XVM equipped PDP-15/XVM-15 systems).

From the software reference manual; based on the PDP-11's local
memory, the UNIBUS can access the PDP-11's private memory, and all of
the PDP-15's memory save for the last 4, 8, or 12 KW of address space.
The PDP-11's local memory starts at its own location 0, and extends up
to its own addresses 017777, 037777, or 057777; addresses 020000,
040000, or 060000 to 157777 are mapped to the PDP-15's memory starting
at location zero. So a PDP-11 with 8KB of local memory would have
locations 020000 through 157777 shared to the PDP-15's memory
locations 000000 through 037777; et cetera. I may have done the
address math wrong, but an excellent diagram can be found in the
Software System Manual, page 1-4.

A description of the PDP-11 and PDP-15 registers and IOTs
(respectively) can be found in the UNICHANNEL-15 Overview manual,
pages 13 through 17. Further this information can also be found in the
engineering drawings sheets 16 through 22. From the information, the
data which the PDP-11 can output is addresses for the four levels of
hardware API interrupt; which set the corresponding API flag in the
DR15-C, and cause an API interrupt on the PDP-15 (if no higher level
interrupt is in progress, and API/PI interrupts haven't been disabled
either locally on the DR15-C or globally on the PDP-15 itself). The
PDP-15 itself can send information to the PDP-11 on the address of the
Task Control Block Pointer which can be read by the two DR11-C input
registers, as well as clear API flags when API interrupts have
completed. The PDP-11 can be interrupted by the clearing of all API
flags, as well as when a new TCBP address has been sent to the
PDP-11's DR11-Cs.

SOFTWARE <<
I am not touching a description of the PIREX monitor, or PDP-15 OS
device handlers with a fifty foot pole. My MACRO-11 is crap, nevermind
my understanding of MACRO-15. In this case, I will highly recommend
going over the Software System Manual, as it has a very detailed
description of the software which I'm not going to repeat.

Although, I will mention some of the interesting parts to the whole
UNICHANNEL-15 software experience.

Namely, starting the PDP-11 of the UNICHANNEL-15 system is done
through the PDP-15; the PDP-11 doesn't have a console teletype, or its
own high-speed reader/punch, so it shares paper tape I/O with the
PDP-15. From the software manual, loading an absolute binary into the
PDP-11 is a three step process:

1. On the PDP-15, at location 17700 load the ABSL11 tape with the
   hardware read-in switch. Simulator equivalent command:
   LOAD absl11.rim 17700 [on the PDP-15]
2. On the PDP-11, start the processor from address 060000, 100000, or
   120000 (4KW, 8KW, and 12KW systems respectively). Simulator equivalent
   command:
   RUN 60000 [on the PDP-11, with 8KB of RAM, modify with correct address
   for other sizes]
3. Put the PDP-11 absolute binary tape into the PDP-15 reader and
   press the continue switch. Simulator equivalent command:
   ATTACH PTR .abs [on the PDP-15]
   RUN [on the PDP-15]

One could always skip the ABSL11 loading step if you just load the
.abs binary tapes from the PDP-11 simulator; but one would also need
to remember to start the PDP-11 simulator. (At which point one won't
know if the load was correct until any UNICHANNEL-15 activities, like
trying to boot off an RK05 happen, or don't happen.)

The most often use of these ABSL11 load processes was to either load
PIREX, or to load MAINDEC diagnostics.

Once the PDP-11 is running PIREX further loading of software onto the
'11 is done via the PDP-15 operating system of choice, and PIREX. If
the PDP-15 needs to halt and restart, PIREX on the '11 can be left
alone. (Though if the simulators disconnect that would probably result
in PIREX crashing, hard.) Though, if one follows the words of DEC's
PDP-15/XVM Marketing group, if you felt sufficiently perverse, you
could replace the "small" PDP-11/05 with a PDP-11/40, with MMU and
more RAM_, and then have RSX-11M or RT-11 run a program in one area of
memory that acts like PIREX and SPOL11; of course you would need have
some amount of custom software for that, as DEC never did release
RSX-11 or RT-11 software to actually *DO_ that.

Thank you for your replies, and I welcome any more comments.

Regards,
Christian

*: That makes me have to ask, how in the hell does a PDP-11 with an
MMU deal with DMA? One of the "features" of the PDP-11/05 UC15 system,
is that while the PDP-11's program memory is fixed at 64KB (local plus
shared memory, plus the 8KB of memory map), the UNIBUS DMA devices,
specifically the RK11-E have the 18-bit UNIBUS DMA that let's them
Access at a minimum the first 116KW of the PDP-15's memory. (The
remainder being inaccessible.)

If you installed a PDP-11/40, wouldn't that render that particular
feature of the UC15 completely inoperative? Because wouldn't the
PDP-11/40 now have it's 8, 16, or 24 KB of local memory, and 224, 232,
and 240 KB of memory shared with the PDP-15? (Which would lead to all
kinds of "fun" with software, as the PDP-15 wants to use its memory,
while the PDP-11 is trying to run RSX-11 in all that "high" memory.)

My question of how DMA works is... say you did install an 11/40 into a
PDP-15 in the place of an 11/05, and you expanded the PDP-11's memory
to its top of 248KB (minus the KB of memory you want shared with
the PDP-15 on the first page); in UNIBUS DMA beyond the first 56KB,
would data be written to the PDP-11's memory, or to the PDP-15's
memory? Because only bad things could happen if the PDP-15 told the
PDP-11 "have the RK05 dump me some data to " and
the PDP-11 does, only to place it into its own high memory, then
interrupts the PDP-15 to say its finished; resulting in two systems
now getting garbage data.

Many systems have DMA address space that is smaller than the memory address
space. They just reserve a memory buffer in low memory for DMA. After a DMA
they just copy the buffer to wherever it is needed in memory. Not as
efficient as using DMA to the actual location, but it works with the
hardware limitation.

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

�
Reply to this email directly or view it on GitHubhttps://github.com//issues/96#issuecomment-32622454
.

Michael Thompson

[ghost]

First, documentation for the CR15 is readily available. For a summary of the 18b card readers, see this paper: http://simh.trailing-edge.com/docs/card_readers_18b.pdf.

Second, several approaches have already been tried for implementing multiprocessors.

1. Loosely coupled. Used for the HP Access system, two separate simulators are run with network communications between them. Not suitable for Unichannel because of the shared memory.
2. Fully symmetric. Used for the SiCortex MIPS simulator, available in the beta section of the original SimH web site.
3. Second processor as I/O device. The second processor is run every cycle, either by an explicit call out of the dispatch loop, or by scheduling an IO event for every cycle.

The principal issues will be the global name space conflicts between the PDP-15 and the PDP-11, the device name space conflicts (e.g., paper tape devices), the need to merge the IO structures to use a single global event mechanism, and the need to have two completely separate interrupt mechanisms in one simulator. I would recommend not trying to use the current PDP-11 CPU, which is overly general, but to start from that source and strip down until you have exactly a PDP-11/05 and no more.

[ghost]

I have finished an implementation of the UC15 using two separate processes - one a PDP15, one a PDP11 with an 18bit RK11 variant. Now I need to debug it and also document the rather complex operational procedures.

Thanks to Mark P for providing the underlying shared memory libraries.

[ghost]

This issue can be closed.