[Simh] Questions regarding future simulator development

Mark Pizzolato - Info Comm Mark at infocomm.com
Fri Apr 12 13:29:38 EDT 2013


On Friday, April 12, 2013 at 8:40 AM, Michael Mondy wrote:
> 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:
> > > 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.

Everything you mention is correct and part of the plan.  All processing will be done by the main simh thread and will work on all simh simulators and in environments where threading is not available.

Thanks.

- Mark




More information about the Simh mailing list