[Simh] EXT : Questions regarding future simulator development

[Dell Setzer]

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