[Simh] EXT : Questions regarding future simulator development

[Dell Setzer]

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 at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>