When the console is connected to a serial port or telnet sessions enable
speed setting, the bits being output are now paced a the desired speed.
Multi-line mux I/O is also correctly rate limited on all lines.
This should address the problems described in #545
- Add sim_panel_mem_deposit_instruction API
- Properly shutdown debug activities when more than one panel is active
- Properly unwind socket facilities when more than one panel is active
- More rigorously unwind things when a panel is destroyed while its
simulator is running.
- Give explicit session request traffic priority over potentially pending
repeat command processing.
- EXPECT HALTAFTER=nnn
--> sets "nnn" as the global/default value
- EXPECT "some string"
--> uses the "nnn" global/default value
- EXPECT HALTAFTER=ttt "some string"
--> uses the "ttt" temporary value for this EXPECT only
and:
- SEND AFTER=nnn
--> sets "nnn" as the global/default value
- SEND "some string"
--> uses the "nnn" global/default value
- SEND AFTER=ttt "some string"
--> uses the "ttt" temporary value for this SEND only
(and similarly for the SEND DELAY value).
Make REM-CON units dynamically allocated and use symbolic names for the
respective different roles they play. This will make interpreting the existing
code easier and ease future extensions.
The original model started with two array variables each with one element
for each potential concurrent remote console. As functionality was added
the number of arrays grew to an unreasonable number. This change
merely gets rid of the separate arrays of per connection info and uses a
single array of REMOTE struct which contains all the per connection info.
This will make future functional extensions much cleaner.
Adds:
1) Simulator side execution of register update activities at an interval
specified in usecs. Rates in excess of 1000Hz should be achievable
for locally connected frontpanel applications.
2) New API for simulators to describe the register state available in
the simulator. If all of a the state which is potentially interesting
to front panel applications is always present in the variables
described by simh REG structures, then frontpanel API access to
that data can be more efficiently provided.
The console mode needs to be set to properly interpret and generate ANSI
escape sequences. It is not 100% VT100 compatible, but this is MUCH better
than without any support.
Windows 10 finally supports ANSI escape sequences in console applications.
Simulators may output appropriate sequences and get useful results, however,
timing of the bytes in the output stream to the console device matters.
This change buffers the data in escape sequences for up to 8ms or until another
escape sequence is presented for output. Once the 8ms elapses, then all output
characters are presented to the windows console subsystem together so they
can be properly interpreted.
commit ef6528bf32 added support for automatic WRU detection for simulators
that don't have a console port, but it was never documented and the addition of
that support potentially interfered with SAVE/RESTORE behavior.
The console connection state is now automatically saved and restored.
The output of remote console commands gets truncated at the configured
buffer size. The default has been raised from 1400 to 8192.
Common remote console usage is from the same host as the simulator and
as such localhost TCP traffic is delivered in chunks at least 8192 so no extra
packets will be involved in transporting the potential extra data and no
transmission delays on the send() call.
The minumum size is now 1400 (which was the prior default).
The RUN command implicitly resets all devices which may have unexpected
consequences for a novice user.
The logic now produces a warning about this side effect when more than one
RUN command is executed in the same simulator session.
An explicit RESET command suppresses this warning for a subsequent RUN
command.
A RUN command with the -Q switch also suppresses this warning.
