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
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
