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