The original SET CONSOLE SPEED=nnn was added to a allow direct wired
terminal connected to a host system serial port to be a simulator's console.
The current change generalizes all console I/O such that speed is a reliable
option for direct console connections as well as serial and telnet connections.
The simple recipe to get well behaved console output speed is:
1) call tmxr_set_console_units() in the reset routine of the console DEVICE.
2) In the code path that engages console output do something similar
to this as appropriate for the system being simulated:
void txdb_wr (int32 data)
{
tto_unit.buf = data & 0377;
tto_csr = tto_csr & ~CSR_DONE;
CLR_INT (TTO);
sim_activate (&tto_unit, tto_unit.wait);
}
3) In the output unit's service routine the console output unit's service
routine do something similar to this as appropriate for the system
being simulated:
t_stat tto_svc (UNIT *uptr)
{
int32 c;
c = sim_tt_outcvt (tto_unit.buf, TT_GET_MODE (uptr->flags));
if (c >= 0) {
t_stat r;
if ((r = sim_putchar_s (c)) != SCPE_OK) { /* output; error? */
sim_activate (uptr, uptr->wait); /* retry */
return ((r == SCPE_STALL)? SCPE_OK: r); /* !stall? report */
}
}
tto_csr = tto_csr | CSR_DONE;
if (tto_csr & CSR_IE)
SET_INT (TTO);
}
The almost all of the current simh simulators already are implemented
with logic like the above example. These will work just fine with the
newly regulated console speed.
The system default of no extra backlog has generally worked well for
simulated mux devices for a long time since reasonable arrival of
new tcp connections is usually expected to have gaps of minutes.
If, for some reason, connection arrivals in a particular case can
happen multiple times per second, a backlog might be useful.
- Add common system includes used in may places which are allowed
and thus added directly in sim_defs.h.
- Separate completely private system data structures and system APIs
for use only by SCP library routines into sim_scp_private.h.
Asynchronous MUX functionality was added long ago and never completely
tested and thus never completed and never actually used.
All of what it was supposed to achieve was independently achieved when
bit rate speed functionality was added.
This adds support for the "framer" device, which is a USB-connected
device built around a Raspberry Pico that connects to a synchronous
line, either RS-232 or DEC "integral modem" coax connection. It
implements the framing portion of DDCMP: clock recovery for the
integral modem case, byte sync, and DDCMP frame handling including
CRC. The actual DDCMP protocol state machine, with its handling of
sequencing, timeout and retransmit, etc. is left to the host
software. All the design files for the framer may be found at
https://github.com/pkoning2/ddcmp .
This commit adds code to drive the framer from the TMXR library,
allowing it to be used either from simulated DMC-11 or simulated
DUP-11 devices. Both have been tested, using RSTS/E, RSX-11/M+, and
TOPS-20.
Fixed the one-digit limit on eth<n> device names, the limit is now 2.
This is all around the tmxr_set_get_modem_bits() API.
This change is non operational, but this clarification would avoid the
mistake made when someone uses or thinks about changing that
API in the future.
The prior change disabled returning DTR and RTS which the documented
interface was quite specific about actively returning.
The only user of this API which actually cared about DTR and RTS was
the in the pdp11_dmc module.
As reported in #951
As reported in #865
When instruction execution is stopped, forced mux output rate limiting
can't leverage instruction execution rate to time inter-character delays.
A direct sleep is used but that has a minimal granularity measured in
milliseconds. The prior default for a non speed controlled line was 10ms
sleep between character output. This has been changed to 1ms which
is reasonable for most situations. Meanwhile, since the remote console
facility uses TMXR, and it has the reasonable ability to generate output
when instructions are not being executed, this is better but not perfect.
Outbound connections are rare and most may have wanted explicit blocking
behavior, so no one noticed the missing non-blocking case.
Any place which did do outbound connects have explicitly added
SIM_SOCK_OPT_BLOCKING so that the prior behavior is preserved.
The SIM_SOCK_OPT_BLOCKING flag is no honored as it was originally
intended to be.
