If a telnet session sends options just prior to closing a session, the response
traffic might get dropped which isn't a problem, but we need to make sure
that we stop referencing the now invalid line structure after that happens.
- Don't count stalls as drops since they can be retried
- Count stalls, which probably are rare on network connections but can
happen more frequently on serial port connections.
Avoid Windows specific serial I/O behaviors which might not always have
hardware state reported to user level code. The TMXR layer code already
paces mux output so that reasonable behavior is observed.
- 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).
- Add support to query remaining usecs on pending events.
- Generalized the sim_interval adjustment in sim_idle to allow more than
a single decrement.
- More overhead reduction when idling.
- Carry usec values as double through out to fully support long wall clock
delays.
Clock devices which call sim_register_clock_unit or sim_register_clock_unit_tmr
are best behaved if they use sim_activate_after to schedule their tick events.
Asynchronous clocks are now built for all simulators which are built with
SIM_ASYNCH_IO defined. The default behavior has asynchronous clocks
disabled since this is still experimental, but it can be enabled with
SET TIMER ASYNC.
Catchup clock ticks are now available, but since they're experimental,
they aren't enabled by default. Catchup ticks are only available if the
simulators clock device calls sim_rtcn_tick_ack to acknowledge processing
of clock ticks. The VAX simulators have been modified to leverage this.
Catchup clock ticks can be enabled with SET TIMER CATCHUP
Additionally, an idle threshold is provided which can be used to
influence when clock calibration may be suppressed. The default is not
to suppress calibration activities.
The various timer behaviors are visible with the SHOW TIMER command.
The state of the operating timer facilities is visible with: SHOW CLOCK
Timer events which are queued are visible with the SHOW QUEUE command.
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.