On Fri, Apr 12, 2013 at 06:28:30AM -0700, Mark Pizzolato - Info Comm wrote: > 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
As noted in my prior e-mail, I think there's an easy way to do this that makes sure existing simulators are unaffected by the changes and yet supports any SimH command. By causing sim_interval to drop to zero, the simulator will return control to the SimH main() loop. At that point, it's safe to perform any action that had been fed in via an external process. If that approach isn't taken, even things like EXAMINE won't work correctly if the simulator uses more effecient private variables that are marshaled to/from the variables known to SIMH. -- Mike Mondy _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
