This problem was a latent bug introduced when summarized array register
output was added back in 2013 or 2018.
This fixes the problem reported in https://github.com/open-simh/simh/issues/499
Accept devices mapped at IOPAGEBASE -- text buffer/character generator
memory on video board starts at 160000.
Clear invalid PSW bits in trap handler -- system acceptance test writes
PSW 113705 to vector 34 (TRAP instruction).
- Improve debug output.
- Add support for Alpha display processor.
Details figured out by Zachary Harper @sparky-z from reading the
listing "FREEWAY CROSSING PROGRAM".
I talked to Van Snyder and he told me about this "fix" he wanted
introduced in SimH i1401. The fix was needed to get a program running.
The program not working was likely due to a transcription error, not
the emulator. That "fix" thus introduced a bug, this change fixes it..
The bug: Currently SimH i1401 doesn't deposit a group mark in core
memory after reading a tape mark. It only deposits the tape mark.
This is wrong. The tape mark should be followed by a group mark.
Input of the WRU character reliably causes return from the running
simulator.
- DBGINT works with gdb as a debugger with the default being the next
character after the WRU value. ^F when WRU is default ^E.
- lldb does not support DBGINT signaling. Only Control-C causes
break back to lldb.
Currently, a bug in lldb exists that causes console character input of the
CR character (^M) to actually be received as LF (^J). A bug report has
been submitted to the llvm project describing the problem.
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.
Base vmnet support covers bridged network interfaces and locally
accessible TAP network connections. These reflect the vmnet bridged
and host behaviors which are leveraged under the covers, but configured
using the original sim_ether commands. The resulting bridged case
behaves like the Windows network connections do (with direct access
to and from the local LAN as well as the host system) using the natural
interface name. NAT behaviors are specifically supported using the
original SLiRP code since the vmnet support depends on simulators
primarily getting IPv4 addressing via DHCP, but essentially no simh
simulators actually had OS network code which used DHCP and all
merely used static network address setup. The vmnet (shared/NAT)
support can't be configured to operate with the same DHCP and static
IP addresses provided by the original SLiRP implementation and to
avoid the need to specifically change hard coded simulator IPv4
addresses before things could work.
- Detect which network interfaces are WiFi (when possible) and thus
not useful candidates for bridging.
- Cleanly report when running as root is needed.
- Avoid allowing network connections to interfaces which aren't
actually connected to a network.
- Add support to explicitly set TAP network host side network
interface's IPv4 address and netmask. This optional support is
provided specifically for the Apple vmnet case, but not for other
platforms using TAP network connections due to the various ways
that must be handled with external commands.
- Add host system's IPv4 address, netmask, media type and connection
state to interface descriptions visible via SHOW ETHERNET.
Some system environments may have a significant number of potential
network interfaces, most of which aren't interesting to connect
simulators to. Knowing which interfaces are actually in useful
states helps users select the correct device.
The vmnet aspect of this functionality was originally inspired by
Calvin Buckley's pull request to the open-simh repository. That
solution wouldn't actually operate well certainly for NAT cases due
to the forced DHCP to non-configurable address blocks and the lack
of any way to support static addresses TCP or UDP port mapping.
Only the string instructions document the registers used by the
register-form instructions. Also document the BCD register-form
instructions. Although, the operands have already been loaded into the
special-purpose instructions before the op switch, I think this
documentation is useful.
These instructions are referred to as L2Dr and L3Dr in the PDP-11/24
System Technical Manual (https://www.vt100.net/manx/details/1,23) and
their opcode strings call them L2DR and L3DR. These comments seem to be
a simple typo.
- windows-build now supports the latest Visual Studio 2022 17.14.3
Fix: #1216#1216 reports problem with 17.14.2, but MS had already released 17.14.3
as of 5/28/2025, so that version is what is now supported.
This whole array VS2022 problems comes from the fact that Release
builds of certain static libraries are rejected at link time as
incompatible with those libraries produced by any prior Visual Studio
version. This problem has existed for a very long time (going back to
at least VS2017). The earlier strategy implemented with simh builds
was to not support the latest Visual Studio tool set until it stopped
changing. That was sort of OK when Visual Studio versions changed
every 2 years, but since VS2022 was dragging on with frequent changes
support for intermediate versions was added some 3 years back.
