On 17 March 2015 at 23:01, Mark Pizzolato - Info Comm <[email protected]> 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. _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
