[Simh] EXT : Questions regarding future simulator development

[Mark Pizzolato - Info Comm]

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