[Simh] EXT : Questions regarding future simulator development

[Timothe Litt]

Actually,  one merely needs to implement what the real hardware did.  
The simulator is not responsible for filesystem consistency; the OS is.  
And the real OS and hardware deal with this.  (Or don't, but simh isn't 
a nanny; it is intended to preserve the experience of running the real 
machines.)

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, punch

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130410/3ac57ecf/attachment-0002.bin>