[Simh] Simulating the PDP-15/76 Unichannel

Tue Mar 17 23:51:41 EDT 2015

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

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

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

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

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

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

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

Just going to bring this off topic for a short moment, to bring up the
DX11 again. Anyone here interested in that device? It makes gives a
UNIBUS PDP-11 the ability to interface to IBM bus and tag, making the
'11 a peripheral of an IBM (or plug compatible) mainframe system. From
playing around a bit with OS/360 on Hercules I think that the DX11
(and a corresponding interface on Hercules) would make a *VERY* cool
project. But that's just my opinion.

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