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.
Also, if acting on ENTER is done at 'next instruction' time, there should be less breakage. DEPOSIT should work about as well as console switches on real hardware. (Useful for deposit 30 -1 (crash TOPS-10/20), VAX SIRR for quorum/XDELTA, etc). But there probably will be some breakage where timed device events don't check for 'still attached' and need to set some error bits. It's not obvious why (given that command execution is synchronous) these wouldn't be bugs in the current code. Certainly more likely to be exercised.
The hook looks something like this: There are 4 states for keyboard input (char ready):(0) "not simulating": cooked, current command table. "BOOT,CONTINUE,START" S-> "simulating" (1) "simulating" raw: look for ^E (print prompt S-> "^E received") - other chars to console device
(2) "^E received": buffer input to ENTER; ENTER S-> "Enter pending"
(3) "ENTER pending": wait for instruction boundary; execute
restricted comand table;
STOP S-> "not simulating"; other cmd S-> "simulating"
It might be good to check for ^E as the first character in (2), so ^E^E
can send ^E to the simulated console.
I hope someone has the enthusiasm and time to give it a whirl. This communication may not represent my employer's views, if any, on the matters discussed.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
