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.
When a new connection arrives it will be bound to the first line found
which has DTR enabled (considering the line order rules). If none is
available, then all currently unconnected lines will have the RING signal
enabled. If no such lines exist, the incoming connection is rejected with
"All connections busy". If a currently disconnected line (with RING
enabled) raises DTR within 3 seconds, then that line gets the pending
connection and all other lines with RING enabled have RING disabled.
If 3 seconds pass without DTR coming up on any line with RING enabled
coming on, all lines with RING enabled will have RING disabled and the
incoming connection will be rejected with "No answer on any connection"
Full modem lines depend on the simulated OS to fully configure the line
parameters (speed, parity, etc.), so setting line speed during a normal
attach violates that behavior. However, when a RESTORE operation is
being performed, we are obliged to restore the OS set line parameters
which we know were already set by the simulated OS.
To promote clarity of experience, a user on a telnet connected line (which
supports modem control signaling) will receive a "Disconnected from
{simulator name}" message when a session is explicitly terminated by the
simulated system. This allows the user to differentiate that case from the
simulator merely being powered off or otherwise crashing. This behavior
mirrors the "Connected to the {simulator name}" message that is presented
when the connection is established.
A multiplexer may have a combination of speed limited behaviors on
different lines, and there may be lines which are idle and lines which
are actively receiving input. Some of the problems described in #252
are fixed by this.
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.
Data arriving on simulated serial ports can arrive faster than the OS running
on the simulated system can deliber it to user mode programs. This happens
when chunks of data are delivered to the mux from a network connection.
This can be due to a file transfer program (kermit) running on the other end
of a network connection and the packet size being delivered exceeds the
simulated OS's type ahead buffer size OR from users who paste arbitrary
blocks of data into a telnet or console session.
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.
- Accept input comments
- Allow leading and trailing spaces in remote console input commands
- Force prompt to be "sim> " or "SIM> " when in a master mode console session. "SIM> " used during single command mode.
- Enhance performance of single command mode input processing by processing all available input characters before actually flushing output buffers
TMXR API extension to add tmxr_input_pending_ln that reports the existence of additional input data
TMXR also now conforms to revised sim_sock API changes
Ideas based on Dave Bryan's console halt efforts.
sim> SEND {<mux>:line} {DELAY=n,}"string"
Where <mux> is the name of the device pointed to by the TMXR structure. If <mux>:line isn't specified, then the console device is implicitly being referenced.
Delay is optional and once set persists for subsequent SEND operations to the same device. Delay defaults to 1000. The DELAY value is a minimum number of instructions which must execute before the next character in the provided string will be injected to the console port. The DELAY value has effect between the characters delivered as well. "string" requires quotes and within the quoted string, common C escape character syntax is available (\r\r\t, etc.).
Each device (console, and each line in each mux) has a separate value for DELAY.
An arbitrary number of 'expect' conditions can be defined. The command syntax is:
sim> EXPECT {<mux>:line} {[cnt]} "matchstring" {actioncommand {; actioncommand ...}}
Where <mux> is the name of the device pointed to by the TMXR structure. If <mux>:line isn't specified, then the console device is implicitly being referenced.
"matchstring" requires quotes and within the quoted string, common C escape character syntax is available (\r\r\t, etc.). The quotes used can be single or double quotes, but the closing quote must match the opening quote. The match string might be extended to allow the use of perl style regular expressions in the "matchstring" when a -R switch is specified on the command line.
sim> EXPECT "Enter Color: " SEND "Red\r"; g
A specific 'expect' condition can be removed with:
sim> NOEXPECT {<mux>:line} "matchstring"
All 'expect' conditions can be removed with:
sim> NOEXPECT {<mux>:line}
'expect' conditions can be examined with:
sim> SHOW EXPECT {<mux>:line}
Expect rules are one-shots (i.e. they disappear once a match has occurred) unless they are explicitly described as persistent with the -P switch.
The -C switch is available when defining expect rules. The effect of a rule defined with the -C flag is that when an expect match occurs for that rule, ALL rules are cleared for that device (console or <mux>:line).
