Massbus:Detach: clear medium-online & volume valid, set unit attention. The OS will put the disk into mount verification (VMS's name; other OSs use different language).
Attach: set medium-online. (The OS will do a pack-ack, setting VV; if the unit is in MV, the OS will make sure the media hasn't changed. If not in MV, it's ready for a mount.)
MSCP has the same functions; different names.Other devices have register bits that respond to operator interventions. Just actuate them.
As for simh; I suggest another escape character, which gives a restricted command prompt, but leaves the simulation running. (The console is quiescent with respect to the OS at this prompt, but IO is handled by SIMH.) This prompt gives the device buttons; e.g. on/off-line, unload, rewind + attach/detach. Either one command/prompt, or a 'continue' to get back to the OS.
This can be done without host utilities or separate threads. And it can be partitioned so there's common code, a hook for the console tty device and hooks in the devices that support dynamic attach/detach.
Devices to consider: disks (hard, floppy) tapes (mag,dec, paper) LPT [VFU tape] card reader, punchIn the real world, operators did the darnedest things. The hardware followed along. The software coped. Or didn't. But that's the experience to be preserved....
This communication may not represent my employer's views, if any, on the matters discussed. This communication may not represent my employer's views, if any, on the matters discussed. On 10-Apr-13 17:26, Mark Pizzolato - Info Comm wrote:
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 bedeveloped 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 ormay not be problematic on more complex simulated hardware......dellOne 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 _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
