On 10 April 2013 13:48, Hittner, David T (IS) <[email protected]> wrote: > To answer your questions: > > 1> Yes, you could detach the command channel from the simulation loop by > putting the command channel in a different thread. The problem then becomes > one of synchronization between the two threads to do the [limited] amount of > things that should be allowed while the simulation loop is still running. You > would also need to put in options to enable/disable command-channel threading > - some people do not want to change the removable media "on the fly", and > some older host systems do not support pthreads. Someone may have already > submitted this code, or it may be in the next version of SIMH (4.0), it would > be best to check with Mark. > That makes a lot of sense, and I did know that you would have to put the core simulator and simulator-command system on separate threads, I was just wondering would that be something that requires massive rewrites to the entire simulator codebase?
> 2> Assuming that the MASSBUS hardware devices actually supported the extended > configuration, you could certainly add the extra components into the > configuration. The question then becomes do any of the operating systems that > ran on the original hardware support the extended configuration? If the > operation systems don't support the extensions, then adding the extra > simulated components is a waste of time. Otherwise, you just have to ask > yourself "Is it worth the effort?" Note that any new components added to a > simulation should be disabled by default for compatibility with older scripts. > Yes, you could have four RH-whatever MASSBUS controllers on a single system, just go look at the PDP-11/70, it can quite easily support four RH70s, or a third party controller in the place of the RH70, as apparently there are some third-party boardsets that can slot into the RH70's slots on the 11/70's backplane. I think, though I am not completely sure, that one of the various UNIX systems supports multiple MASSBUS channels (I want to say it is V7M, which could be built in such a way as to have it's "/" drive on one channel, while using a second MASSBUS disk controller channel for a swap disk, with yet another channel as tape). > 3> Yes. There is an unreleased VAX simulator variant in the wild with 32 > processor support. It would certainly be possible to run additional CPU > simulator loops on other threads - you just have to add synchronization > support for the system shared resources - I/O bus, system bus, memory, etc. > However, in the case of the PDP 11-11/74, you have to ask yourself the > question "Is it worth the effort to add multi-cpu support to more "correctly" > simulate a PDP-11/74?" since the current PDP-11/70 simulation already > outperforms the fastest hardware ever made. :-) Not knowing what the PDP-15 > UNICHANNEL-15 is, I can't comment on it. > You'd also have to worry about the Interprocessor Interrupt and Sanity Timer for the 11/74; and in terms of the question of whether it is worth it, while yes a simulated 11/70 is signficantly more capable then the fastest '11, but how else can one "experiment" with an 11/74? (Yes, yes, we know E-11 exists, *AND* it supports two different methods of multiple processor PDP-11, both the 11/74, and the "let's bridge the memory (FASTBUS) and normal (UNIBUS) buses on one PDP-11/45 and plug it into the UNIBUS of a second 11/45" style machine. But E-11 is expensive, if I wanted to experiment with systems on very large storage (read: RM05).) Also, UNICHANNEL-15 which you can find on BitSavers was a small PDP-11 (11/05 if I remember correctly) "glued" to a PDP-15, letting the PDP-15 make use of RK05 disks and LP11 printers. (I think the UC15 system also offered other peripherals to be accessible to the PDP-15's operating systems, but I only remember the RK05 and LP11.) XVM/DOS and XVM/RSX support the UNICHANNEL devices, going by the XVM/RSX SYSGEN prompts. Thanks for taking the time to answer my mail Mr. Hittner! Cheers, Christian _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
