[Simh] Questions regarding future simulator development

Mark Pizzolato - Info Comm Mark at infocomm.com
Fri Apr 12 09:28:30 EDT 2013


On Thursday, April 11, 2013 at 9:45 AM, Timothe Litt wrote:
> On 11-Apr-13 09:59, Bob Supnik wrote:
> > 3. The problem with "console while simulating" is that SimH (at least when I
> was developing it) is single -threaded. That said, there is a way to handle this
> within the existing framework:
> >
> > - Insist that the console always runs via a Telnet window.
> > - Let the keyboard sampling "device" look for more than ^E; in fact, let it
> accumulate type-ins into a command buffer. Note that all editing (echo,
> delete, etc) would have to be explicitly emulated, because the keyboard
> window, at that point, is in raw mode.
> > - When ENTER is recognized, see if the command verb is part of a small
> acceptable set of commands that are safe to run while the simulator is
> executing. As Tim Litt points out, ATTACH and DETACH should work, because
> this is no different, from the simulator's point of view, than ^E,
> attach/detach, CONTINUE. EXAMINE is probably safe. Not much else is.
> >
> > While it all sounds good in theory, I expect a whole bunch of things are
> going to break. Most notably, lots of SimH device service routines assume
> that if a device is attached at the start of the routine, it will be throughout
> and don't implement comprehensive error recovery further down.
> Yes, this is what I had in mind.  Single-threaded actually helps.
> 
> I don't see why the Telnet window is required to make this work. Running
> from a terminal window should work the same way.  Probably can be done
> with some slight of hand in sim_console (sim_poll_kbd/sim_os_poll_kbd);
> but I haven't really looked at the code in a long time.

I agree.

[...]

> I hope someone has the enthusiasm and time to give it a whirl.

I've got a plan which will work without any extra threads and not require special synchronization and minor modification to the existing code.

It seems most reasonable that someone who wants to use this facility to '"act as an operator" to change tapes, disks, etc, might not need to be physically in front of the system simh is running on.

This facility will provide an alternate Operator Interface accessible via telnet.  This is separate and apart from any considerations of where the console session may currently be connected via (i.e. TELNET, or to a serial port local to the host computer or still running in the context which started the simulator).

Matt's desire to connect a guest serial port will work just fine with this approach as well since the current TMXR layer supports direct connecting particular lines on a MUX to an arbitrary TCP host:port.

The commands which will work via this interface will be restricted to ATTACH, DETACH, and SHOW, and EXAMINE. (For now).  A BlinkenLights interface could pretty much be built on top of this.  

- Mark





More information about the Simh mailing list