Added Buffered Console Capabilities
A key capability needed to support simulators running with background
execution is the ability to have a Telnet connected console which isn’t
continuously connected. This feature is called a Buffered Telnet console.
Absolutely nothing changes for someone not interested in using the feature.
However, if someone is interested in the feature, the following SCP
commands are available:
sim> SET CONSOLE TELNET=port ! Unchanged
sim> SET CONSOLE TELNET=BUFFERED{=buffersize} ! buffersize defaults to 32K
sim> SET CONSOLE TELNET=UNBUFFERED ! restores normal behavior
sim> SET CONSOLE TELNET=NOBUFFERED ! synonym for UNBUFFERED
sim> SET CONSOLE TELNET=LOG=logdestination ! enables logging of Telnet session traffic (potentially separate from destination specified by SET CONSOLE LOG=conlogdest)
sim> SET CONSOLE TELNET=NOLOG ! turns off specific logging of Telnet session
sim> SET CONSOLE TELNET=LOG=conlogdest ! turns on logging all console traffic (unless the telnet session logging is also specified).
The logdestinations for any of the logging/debugging commands can
now be:
LOG, DEBUG, STDOUT, STDERR or any file specification (caps are not
required, but these names are reserved to indicate the current
destination of the specified file handles (sim_log, sim_deb,
stdout, stderr).
When a Console Telnet session is Buffered, a simulator will start
(via BOOT CPU or whatever is appropriate for a particular simulator)
without needing to have an active telnet connection. When a Telnet
connection comes along for the telnet port, the contents of the saved
buffer (which wraps on overflow) are presented on the telnet session
as output before session traffic. This allows the connecting telnet
client to see what happened before he connected since the likely
reason he might be connecting to the console of a background
simulator is to troubleshoot unusual behavior.
The current structure has the optional ability to log the Telnet
session separately from the simulator output (i.e. ini file command
execution) is potentially useful when you need to review what the
simulator may have output which may be difficult to find in and
amongst the possibly verbose Operating system console output.
If someone doesn’t use “SET CONSOLE TELNET=LOG=logdestination”,
then the original strategy of logging all output to the target
specified by “SET CONSOLE LOG=logdestination” is preserved. Looking
at the isolated console output might be more interesting if/when
control flow scp commands are ever implemented (ON,GOTO, RETURN, etc.)
6 files changed