Re: [Simh] EXT : Questions regarding future simulator development
On Wed, 10 Apr 2013, Armistead, Jason wrote: On Wednesday, 10 April 2013 2:32 PM, Dell Setzer wrote: On Wed, 10 Apr 2013, Hittner, David T (IS) wrote: To answer your questions: 1> Yes, you could detach the command channel from the simulation loop 1> 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. There is another approach that could be used to do e.g. attaching/detaching devices, etc. without interacting with the simh> command prompt, and without running the SIMH command handler in a different thread. One could have, for example, a "magic" I/O or memory location that causes the simulation code to call various SIMH functions directly. So, for example, writing a certain value to a certain memory location could cause the SIMH attach function to be called, perhaps with parameters (e.g. disk image file pathname) pointed to by certain simulated registers. Success/failure status could be returned via a read to the same location. A utility could then be developed to run under the simulated OS that collects the parameters and tickles the magic location. I have actually implemented this in a SIMH simulator I wrote for the MC6809 to run the TSC Flex operating system. A magic memory location allows attaching/detaching disk images, attaching/detaching files to simulated async ports, etc. And a little utility that runs under the simulated OS allows this to all be done from within the simulated environment. The attach or detach appears to the simulated machine to occur between one simulated instruction and the next. This approach works like a charm in the simple-minded Flex environment, but it may or may not be problematic on more complex simulated hardware... ...dell One problem with any attempt to attach/detach devices on the fly is that you have to do it at a time when the OS running inside of SIMH expects the change to occur. On VMS, when you DISMOUNT a volume, the operating system finishes any I/O to the volume in a clean manner. There's no chance you're going to corrupt the file system. Once the dismount is complete, then it's safe to attach another virtual disk image (representing the new removable media) from the SIMH prompt and for the simulated VMS system to MOUNT the new volume. Yes, certainly the OS has to be conditioned for the change, and the appropriate OS commands have to be issued at the appropriate points in the process. But that's no different from how we do things now from the SIMH prompt. Or, for that matter, how an operator would do it with real hardware. Including the possibility of a screwup :) As you say, Flex is a "simple-minded" system, and this is a workable implementation for your needs. I would expect that your solution rapidly gets more limited (and dangerous) once background asynchronous I/O and multiple executing tasks/processes are involved. Again, it's really no different from doing it from the SIMH prompt. As long as the OS or whatever is conditioned to accept the change, it makes no difference whether it's done between one simulated instruction and the next, or done from the SIMH prompt (where, in fact, it's done between one simulated instruction and the next). Yes, the (simulated) instruction that triggers the change will appear to take a long time to execute, but that's probably less disruptive than halting the simulation entirely to drop to the SIMH prompt. Nevertheless, why not share your implementation (including the 6809 core) so it can be added to with the SIMH code repository ? At the moment I don't see that listed as one of the simulators for the current version of SIMH. Well, I really built it as a software platform specificly to run old Flex software, not as a simulation of any particular historic hardware (like SWTPC). Most of the "devices" are implemented via magic memory locations rather than simulation of actual hardware, and some simple drivers let Flex talk to them. And I used a lot of non-portable Windows-specific code, too. So, it would have to be cleaned up quite a bit, and even then I'm not sure there'd be a lot of interest, since it doesn't simulate historic hardware. Regards, ...dell Cheers Jason ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/ma
Re: [Simh] EXT : Questions regarding future simulator development
-Original Message- From: simh-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On Behalf Of Timothe Litt Sent: Wednesday, April 10, 2013 8:13 PM To: simh@trailing-edge.com Subject: Re: [Simh] EXT : Questions regarding future simulator development >I was going to mention the security issues with using telnet for anything - >but I've caused enough trouble. So was I, but Bob Supnik has already explained why we don't provide SSH connections in the code base (export restrictions, two competing SSH standards, etc..). The official SIMH solution to the security issue is "tunnel your telnet" - maybe we can revisit this later. Dave ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] EXT : Questions regarding future simulator development
On 10-Apr-13 18:38, Jordi Guillaumes i Pons wrote: Jordi Guillaumes i Pons Barcelona - Catalunya - Europa El 11/04/2013, a les 0:25, Timothe Litt va escriure: As for simh; I suggest another escape character, which gives a restricted command prompt, but leaves the simulation running Oh no please. When running the simh console inside a screen session accessed via an ssh connection running in a whatever terminal emulation started on a whoknows system the probability of having your escape character being masked/used/nullified by one of the layers is probably near to 1. Specially if your keyboard is not the US variant. I can't escape into klh10 without a lot of keyboard black magic... for example. I vote for a separated telnet port for the "hardware console" connection. It's not that bad. Certainly not probability 1. We already have to deal with ^P for the VAX rom code & the simulator escape (^E). Set running-escape if the chosen default is a problem. Or, overload ^E - if the simulation is running, you get the restricted command line with the simulation running. To stop the simulation, you then type 'stop' to the restricted command line, which gets you the current (full) simh command line . I actually like this better, except for the finger retraining that's required for users. There's no need to require (and secure) another telenet port for this. Networking is optional in simh. And what I suggested fits reasonably easily into the basic simh model. I was going to mention the security issues with using telnet for anything - but I've caused enough trouble. This communication may not represent my employer's views, if any, on the matters discussed. smime.p7s Description: S/MIME Cryptographic Signature ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] EXT : Questions regarding future simulator development
Jordi Guillaumes i Pons Barcelona - Catalunya - Europa El 11/04/2013, a les 0:25, Timothe Litt va escriure: > As for simh; I suggest another escape character, which gives a restricted > command prompt, but leaves the simulation running Oh no please. When running the simh console inside a screen session accessed via an ssh connection running in a whatever terminal emulation started on a whoknows system the probability of having your escape character being masked/used/nullified by one of the layers is probably near to 1. Specially if your keyboard is not the US variant. I can't escape into klh10 without a lot of keyboard black magic... for example. I vote for a separated telnet port for the "hardware console" connection. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] EXT : Questions regarding future simulator development
Jordi Guillaumes i Pons Barcelona - Catalunya - Europa El 10/04/2013, a les 23:18, "Armistead, Jason" va escriure: > One problem with any attempt to attach/detach devices on the fly is that you > have to do it at a time when the OS running inside of SIMH expects the change > to occur Well, I'd say that would introduce a bit of nasty realism into simh... In real iron nothing (apart of common sense) prevents you from powering off the RA82 drive which holds the system disk ;) ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] EXT : Questions regarding future simulator development
Actually, one merely needs to implement what the real hardware did. The simulator is not responsible for filesystem consistency; the OS is. And the real OS and hardware deal with this. (Or don't, but simh isn't a nanny; it is intended to preserve the experience of running the real machines.) Massbus: Detach: clear medium-online & volume valid, set unit attention. The OS will put the disk into mount verification (VMS's name; other OSs use different language). Attach: set medium-online. (The OS will do a pack-ack, setting VV; if the unit is in MV, the OS will make sure the media hasn't changed. If not in MV, it's ready for a mount.) MSCP has the same functions; different names. Other devices have register bits that respond to operator interventions. Just actuate them. As for simh; I suggest another escape character, which gives a restricted command prompt, but leaves the simulation running. (The console is quiescent with respect to the OS at this prompt, but IO is handled by SIMH.) This prompt gives the device buttons; e.g. on/off-line, unload, rewind + attach/detach. Either one command/prompt, or a 'continue' to get back to the OS. This can be done without host utilities or separate threads. And it can be partitioned so there's common code, a hook for the console tty device and hooks in the devices that support dynamic attach/detach. Devices to consider: disks (hard, floppy) tapes (mag,dec, paper) LPT [VFU tape] card reader, punch In the real world, operators did the darnedest things. The hardware followed along. The software coped. Or didn't. But that's the experience to be preserved This communication may not represent my employer's views, if any, on the matters discussed. This communication may not represent my employer's views, if any, on the matters discussed. On 10-Apr-13 17:26, Mark Pizzolato - Info Comm wrote: On Wednesday, April 10, 2013 at 2:18 PM, Jason Armistead wrote: On Wednesday, 10 April 2013 2:32 PM, Dell Setzer wrote: On Wed, 10 Apr 2013, Hittner, David T (IS) wrote: To answer your questions: 1> Yes, you could detach the command channel from the simulation 1> 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. There is another approach that could be used to do e.g. attaching/detaching devices, etc. without interacting with the simh> command prompt, and without running the SIMH command handler in a different thread. One could have, for example, a "magic" I/O or memory location that causes the simulation code to call various SIMH functions directly. So, for example, writing a certain value to a certain memory location could cause the SIMH attach function to be called, perhaps with parameters (e.g. disk image file pathname) pointed to by certain simulated registers. Success/failure status could be returned via a read to the same location. A utility could then be developed to run under the simulated OS that collects the parameters and tickles the magic location. I have actually implemented this in a SIMH simulator I wrote for the MC6809 to run the TSC Flex operating system. A magic memory location allows attaching/detaching disk images, attaching/detaching files to simulated async ports, etc. And a little utility that runs under the simulated OS allows this to all be done from within the simulated environment. The attach or detach appears to the simulated machine to occur between one simulated instruction and the next. This approach works like a charm in the simple-minded Flex environment, but it may or may not be problematic on more complex simulated hardware... ...dell One problem with any attempt to attach/detach devices on the fly is that you have to do it at a time when the OS running inside of SIMH expects the change to occur. On VMS, when you DISMOUNT a volume, the operating system finishes any I/O to the volume in a clean manner. There's no chance you're going to corrupt the file system. Once the dismount is complete, then it's safe to attach another virtual disk image (representing the new removable media) from the SIMH prompt and for the simulated VMS system to MOUNT the new volume. It doesn't actually have to be this complicated as long as the external interface only allows attaching of devices which are already detached. The current simh disk code (at least for RP, and RQ devices and tapes) detaches the device when processing an DISMOUNT/UNLOAD operation. When in this state, the simulated OS
Re: [Simh] EXT : Questions regarding future simulator development
On 2013-04-10 20:55, Larry Baker wrote: On 10 Apr 2013, at 11:22 AM, mailto:simh-requ...@trailing-edge.com>> mailto:simh-requ...@trailing-edge.com>> wrote: 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. RXS-11M-Plus did a very nice job of supporting multiple MASSBUS controllers. Not only that, it supported mixed-MASSBUS configurations -- tapes and disks on the same controller. And, multi-path MASSBUS configurations to dual-port disk drives. Our PDP-11/70 had several MASSBUS disk drives all dual-ported to two MASSBUS controllers. RSX-11M-Plus issued seeks separate from data transfers. Whichever controller was available could be used to issue any command to any drive it could reach. As I recall, the PDP-11/74 could have even more than 4 MASSBUS controllers, because each processor had its own MASSBUS/UNIBUS. Some rather powerful disk configurations could be configured. RSX-11M-Plus had all the code to make it work. (The developers used a PDP-11/74 system.) M+ supports up to 4 CPUs, 12 Unibuses, and 16 Massbuses. The 4 CPUs are a limitation of the IIST, unless I remember wrong. The 16 Massbuses are a logical extension from the four CPUs, since in the 11/74 was more or less a modified 11/70, and each 11/70 can have four RH70 controllers. The 12 Unibuses are a design limitation in RSX, as you have one additional field in many data structures, called the Unibus run mask (or URM). That is a 16-bit value, and thus you have one bet per Unibus. Each CPU have one implied Unibus, leaving space for 12 additional Unibuses in the URM. In reality, this worked by having Unibus switches (DT07), between segments of the Unibus. And segments could be moved from one CPU to another. So, the buses could be reconfigured on the fly of a running system. But all buses had to end up at one CPU or another sooner or later. And no, you could not simultaneously have one Unibus connected to multiple CPUs. But in case of CPU failures, you could switch the bus over to another CPU. (Yes, 11/74 machines are really fun, but simh probably needs some larger reworking before you could do something like an 11/74.) Johnny ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] EXT : Questions regarding future simulator development
On Wednesday, April 10, 2013 at 2:18 PM, Jason Armistead wrote: > On Wednesday, 10 April 2013 2:32 PM, Dell Setzer wrote: > > > > > On Wed, 10 Apr 2013, Hittner, David T (IS) wrote: > > > > > To answer your questions: > > > > > > 1> Yes, you could detach the command channel from the simulation > > > 1> 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. > > > > > > > There is another approach that could be used to do e.g. > > attaching/detaching devices, etc. without interacting with the simh> > > command prompt, and without running the SIMH command handler in a > > different thread. One could have, for example, a "magic" I/O or memory > > location that causes the simulation code to call various SIMH > > functions directly. So, for example, writing a certain value to a > > certain memory location could cause the SIMH attach function to be > > called, perhaps with parameters (e.g. disk image file pathname) > > pointed to by certain simulated registers. Success/failure status > > could be returned via a read to the same location. A utility could then be > developed to run under the simulated OS that collects the parameters and > tickles the magic location. > > > > I have actually implemented this in a SIMH simulator I wrote for the > > MC6809 to run the TSC Flex operating system. A magic memory location > > allows attaching/detaching disk images, attaching/detaching files to > > simulated async ports, etc. And a little utility that runs under the > > simulated OS allows this to all be done from within the simulated > > environment. The attach or detach appears to the simulated machine to > > occur between one simulated instruction and the next. This approach > > works like a charm in the simple-minded Flex environment, but it may or > may not be problematic on more complex simulated hardware... > > > > ...dell > > > One problem with any attempt to attach/detach devices on the fly is that you > have to do it at a time when the OS running inside of SIMH expects the > change to occur. On VMS, when you DISMOUNT a volume, the operating > system finishes any I/O to the volume in a clean manner. There's no chance > you're going to corrupt the file system. Once the dismount is complete, then > it's safe to attach another virtual disk image (representing the new > removable media) from the SIMH prompt and for the simulated VMS system > to MOUNT the new volume. It doesn't actually have to be this complicated as long as the external interface only allows attaching of devices which are already detached. The current simh disk code (at least for RP, and RQ devices and tapes) detaches the device when processing an DISMOUNT/UNLOAD operation. When in this state, the simulated OS can no longer be doing any I/O to the devices in question. - Mark Pizzolato ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] EXT : Questions regarding future simulator development
On Wednesday, April 10, 2013 at 10:49 AM, David T Hittner 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. The synchronization issues you raise certainly are necessary, but they could readily be done the 'simh' way by having a device (not necessarily one the simulated operating system knows about) which provides the necessary interfaces to the current simulator environment. It could have a separate thread which manages the interface and schedules itself (queue a simh event) to poll the interface managed by the interface thread a couple of times a second, and depending on what the interface needed done, could attach/detach devices, etc. as desired. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] EXT : Questions regarding future simulator development
On Wednesday, 10 April 2013 2:32 PM, Dell Setzer wrote: > > On Wed, 10 Apr 2013, Hittner, David T (IS) wrote: > > > To answer your questions: > > > > 1> Yes, you could detach the command channel from the simulation loop > > 1> 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. > > > > There is another approach that could be used to do e.g. > attaching/detaching devices, etc. without interacting with the simh> command > prompt, and without running the SIMH command handler in a different thread. > One > could have, for example, a "magic" I/O or memory location that causes the > simulation > code to call various SIMH functions directly. So, for example, writing a > certain value > to a certain memory location could cause the SIMH attach function to be > called, > perhaps with parameters (e.g. disk image file pathname) pointed to by certain > simulated registers. Success/failure status could be returned via a read to > the same > location. A utility could then be developed to run under the simulated OS > that collects > the parameters and tickles the magic location. > > I have actually implemented this in a SIMH simulator I wrote for the > MC6809 to run the TSC Flex operating system. A magic memory location allows > attaching/detaching disk images, attaching/detaching files to simulated async > ports, > etc. And a little utility that runs under the simulated OS allows this to all > be done from > within the simulated environment. The attach or detach appears to the > simulated > machine to occur between one simulated instruction and the next. This approach > works like a charm in the simple-minded Flex environment, but it may or may > not be > problematic on more complex simulated hardware... > > ...dell One problem with any attempt to attach/detach devices on the fly is that you have to do it at a time when the OS running inside of SIMH expects the change to occur. On VMS, when you DISMOUNT a volume, the operating system finishes any I/O to the volume in a clean manner. There's no chance you're going to corrupt the file system. Once the dismount is complete, then it's safe to attach another virtual disk image (representing the new removable media) from the SIMH prompt and for the simulated VMS system to MOUNT the new volume. As you say, Flex is a "simple-minded" system, and this is a workable implementation for your needs. I would expect that your solution rapidly gets more limited (and dangerous) once background asynchronous I/O and multiple executing tasks/processes are involved. Nevertheless, why not share your implementation (including the 6809 core) so it can be added to with the SIMH code repository ? At the moment I don't see that listed as one of the simulators for the current version of SIMH. Cheers Jason ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] EXT : Questions regarding future simulator development
On 10 Apr 2013, at 11:22 AM, wrote: > 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. RXS-11M-Plus did a very nice job of supporting multiple MASSBUS controllers. Not only that, it supported mixed-MASSBUS configurations -- tapes and disks on the same controller. And, multi-path MASSBUS configurations to dual-port disk drives. Our PDP-11/70 had several MASSBUS disk drives all dual-ported to two MASSBUS controllers. RSX-11M-Plus issued seeks separate from data transfers. Whichever controller was available could be used to issue any command to any drive it could reach. As I recall, the PDP-11/74 could have even more than 4 MASSBUS controllers, because each processor had its own MASSBUS/UNIBUS. Some rather powerful disk configurations could be configured. RSX-11M-Plus had all the code to make it work. (The developers used a PDP-11/74 system.) Larry Baker US Geological Survey 650-329-5608 ba...@usgs.gov ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] EXT : Questions regarding future simulator development
On Wed, 10 Apr 2013, Hittner, David T (IS) 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. There is another approach that could be used to do e.g. attaching/detaching devices, etc. without interacting with the simh> command prompt, and without running the SIMH command handler in a different thread. One could have, for example, a "magic" I/O or memory location that causes the simulation code to call various SIMH functions directly. So, for example, writing a certain value to a certain memory location could cause the SIMH attach function to be called, perhaps with parameters (e.g. disk image file pathname) pointed to by certain simulated registers. Success/failure status could be returned via a read to the same location. A utility could then be developed to run under the simulated OS that collects the parameters and tickles the magic location. I have actually implemented this in a SIMH simulator I wrote for the MC6809 to run the TSC Flex operating system. A magic memory location allows attaching/detaching disk images, attaching/detaching files to simulated async ports, etc. And a little utility that runs under the simulated OS allows this to all be done from within the simulated environment. The attach or detach appears to the simulated machine to occur between one simulated instruction and the next. This approach works like a charm in the simple-minded Flex environment, but it may or may not be problematic on more complex simulated hardware... ...dell ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] EXT : Questions regarding future simulator development
On 10 April 2013 13:48, Hittner, David T (IS) 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 Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] EXT : Questions regarding future simulator development
> There is an unreleased VAX simulator variant in the wild with 32 processor >support. It had been released about 8 months ago. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] EXT : Questions regarding future simulator development
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. 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. 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. David Hittner -Original Message- From: simh-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On Behalf Of Christian Gauger-Cosgrove Sent: Wednesday, April 10, 2013 12:28 PM To: simh@trailing-edge.com Subject: EXT :[Simh] Questions regarding future simulator development Hello, I have a few quick questions about what could be added to SIMH. Not that I could add the features, my skills at C are not quite excellent, so in general, I wouldn't really be able to add anything to the project... or it would be better to say, I wouldn't be able to add anything remotely competently. Any way on to the questions! How difficult, and better to ask, how possible would it be to add the following to SIMH at some point in the future? 1. Some way of interacting with devices while the simulator is still running. What I mean would be some way of breaking to the "sim>" prompt without halting the simulated CPU. So one could do things like swap disk packs, floppy diskettes and magnetic tapes without halting the system. Kind of like the way the Hercules emulator let's you affect the system on the fly. 2. Additional MASSBUS controllers and disks. What I mean is, since the actual PDP-11/70 could have four RH70 MASSBUS controllers installed in it, would it be possible to have another set of RP disks and TU tape drives added to SIMH? Also, would it be possible to have the RS03 and RS04 fixed head disks added to the RP device list? I ask only of the RS03 and RS04 because while they are not strictly necessary any more (being they were small logically, but rather quick, swap disks), it would be nice to have to be able to (re)create more "authentic" systems. 3. Would it be at all possible for SIMH to become capable of supporting a multiprocessor system? E.g. the PDP-15's UNICHANNEL-15 option, or the PDP-11/74. Thank you to any who answer this e-mail. I'd try my own hand at making some of the modifications to the SIMH codebase, but as I said, my skills at present are far too low to be of any real use. Cheers, Christian ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
