- 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.
Reworked all priority adjustment code to leverage a new
sim_os_set_thread_priority API which is coded to use pthreads or OS
priority adjustment APIs as necessary.
These changes facilitate more robust parameter type checking and helps
to identify unexpected coding errors.
Most simulators can now also be compiled with a C++ compiler without
warnings.
Additionally, these changes have also been configured to facilitate easier
backporting of simulator and device simulation modules to run under the
simh v3.9+ SCP framework.
Many simulators run instructions one or more orders of magnitude faster
than the original systems did. Limiting simulated serial port input speeds
to legacy bits per second values presents the arriving data much slower
than the original systems ever saw it. Given the processing capacity of the
simulated systems and the fact that the software and device interfaces
only know how to deal with the legacy speed values there is a need to
provide a way to allow input to arrive faster. This problem is solved by
providing a speed factor as a part of a speed specification. For example
a speed can be specified as "speed*factor" or "9600*10".
Each of the speeds greater than 9600bps deliver a character in less than
1ms. Computing inter-character delays in microseconds therefore can't
be precise enough to be well behaved. Measuring the inter-character
delays in instructions (scalled by the calibrated clock) gets us the needed
precision.
A SET CONSOLE SPEED=nnn, where legal values for nnn are common serial
port rates. The speed value will attempt to limit the input data rates to a
simulator to approximately the specified bits per second.
This approach removes the burden from any simulator code to perform instruction execution postlude before calling sim_process_event and prelude activites when sim_process_event returns.
Remote Console commands are now executed from the same simulator context as if entered from the initial sim> prompt.
