SIMH is a simulator for every machine in the collection

One framework, thirty-odd machines

The project is the Computer History Simulation Project, and the scope is visible in the repository root, where each machine has its own directory. There is 3B2, ALTAIR, Altair8800, AltairZ80, B5500, BESM6, CDC1700, GRI, H316, HP2100, HP3000, I1401, I1620, I650, I7000, I7094, Ibm1130, Interdata, LGP, ND100, NOVA, PDP1, PDP10, PDP11, PDP18B, PDP8, PDQ-3, S3, SAGE, SDS, SEL32, SSEM, TX-0, VAX, alpha, imlac and linc. That is a range from a 1960s minicomputer to a machine that predates the minicomputer, and every one of them runs the same way once it is running, because the differences live in the device emulation and the shared framework takes care of the rest. The homepage is trailing-edge.com, and the version at the top of the README is SIMH v4.0.

SCP is the part you learn once

The command environment is called SCP, the simulator framework or command execution environment, and it is the reason SIMH is worth the effort. You type the same commands on a PDP-8 and on an IBM 1130, and the commands that differ between machines are the ones documented per simulator. The change list for the v4.0 work is largely about making that environment behave better. There are descriptive messages for the cases where a NOPARAM status is returned, and the DO command no longer produces excessive context lines when a command produces multiple lines of output. The ZAP command can be aborted with a Control-C, the DO command supports argument manipulation, and there is a global SET AUTOZAP command, or a per drive SET <unit> AUTOZAP, which removes metadata from disk containers at detach time if the container has metadata. A DISKINFO command displays disk container metadata if present and the container size along with detected file system information if a known file system type is present.

The smaller changes are the ones you notice

Some entries in the changelog are about output rather than about features, and they are the ones that shape an hour of use. Support was added to display all SCP visible filenames via relative paths and use those in the SAVEd state, and there is more readable output from SHOW <dev>|<unit> with variable sized DEVICE and UNIT names. Extended register sanity checks include duplicate name detection, and simulators with fixed devices with duplicate register names were fixed. A global command history and tab file name completion, previously done by the GPL readline, is now done by a BSD licensed library available on all platforms, which matters on Windows and is also a licensing simplification. Simulators with video devices that may be enabled no longer disable the screen saver until the video display is presented, with the option to enable or disable the OS screen saver by an environment variable. And support was added to allow optional per device unit tests to exist and to invoke them at simulator startup.

Building it, and the prebuilt Windows route

The building section has three paths, and the first is the one most people should take. Prebuilt Windows simulators are available, and the README notes that simulator binaries for x86 Linux, x86 macOS and Windows for all recent changes are available in the simh/Development-Binaries repository. Building yourself is the second path, and the repository carries the build scripts for the toolchains involved, with build_vstudio.bat and the MinGW variants build_mingw.bat, build_mingw_ether.bat and build_mingw_noasync.bat, plus a Visual Studio Projects/ directory. The makefile is the third path and it is the most opinionated, because the dependency handling is built in, with makefile builds that have potentially useful dependencies not found prompting to install those components before building. macOS Homebrew dependencies can be done directly from within the makefile, while other platforms or package management systems that require root access to install will display the appropriate package management commands and exit. The supported package managers are named, with macOS through Homebrew and MacPorts, Linux across Ubuntu and Debian, RedHat and Fedora and Chimera, and NetBSD, FreeBSD and OpenBSD.

The fork relationship, and who owns which change

The repository is a fork of Open SIMH, and the split is described precisely. All simulator updates on Open SIMH will be present in this repository, and any changes to the master branch code in this repository authored by anyone except the maintainer may be posted as pull requests on the Open SIMH repository. There is then a separate list of the maintainer's changes that are only present in this repository, headed with the visible changes to SCP. The division is a sensible one, since the bulk of the work is per machine, and those changes can flow upstream, while the framework work is specific to this fork. There are also build niceties that only make sense here, such as a global SET AUTOZAP command, a DISKINFO command, the readline replacement, and the SHOW VERSION output that reports the host system type that built the running simulator when it is not the same as the current host system, which is the kind of detail you only need when you are shipping binaries to people.

ROM licensing, and the option to fetch it at run time

One of the more interesting entries is about copyright rather than about emulation. There is support for building simulators without built-in boot or ROM code when building with DONT_USE_INTERNAL_ROM is defined, but to automatically and transparently fetch the needed ROM or other boot code when it is needed. The README gives the reason, that this is possibly useful for systems that do not want to distribute simulators with built-in binary code that may have unknown copyright status. A simulator that downloads its own boot ROM at run time is a different distribution model from one that ships it, and for an institution distributing a wide set of machines, that difference is the difference between shipping a package and shipping a downloader. The related detail is the automatic Cryllic font detection in the BESM6 simulator at runtime rather than build time, which the README says is more relevant for distribution binaries, and the note that a screen saver is not disabled until the video display is presented.

What a simulator is, and where SIMH stops

Two limits are worth naming. The first is that a simulator reproduces the documented behaviour of a machine, which is a different promise from a virtual machine that runs an operating system in the way the original did, and the difference shows in the places where a real machine had behaviour that was never written down. The second is the scope of the individual simulators, since each machine directory is a device emulation with a specific set of peripherals, and a system you care about may need the device you wanted plus several you did not know about. The project does add capabilities that blur the line, with a Simulator Front Panel API, a Remote Console Facility for running a simulator console from elsewhere, DDCMP synchronous host physical device support with framer, a terminal multiplexer, and scriptable interactions with running simulators, so a test harness can drive a machine in a script. The licence is a custom one in a LICENSE.txt file at the root, and the only tags in the repository are from 2014, with v4.0-devel, v3.9-0 and v3.8-2-rc2, so the tree is maintained without a modern release habit, which is why the development binaries repository exists.

Editorial conclusion

SIMH is the right tool if you are working with historic computer systems, whether for preservation, for teaching, or for running the software that was written for them, because the shared SCP environment means that knowledge of one simulator transfers to the next and the machine set is unmatched. It is the wrong tool if you want a modern system emulator, because a simulator here reproduces the documented behaviour of a machine rather than a virtual machine, and the wrong tool if you need a maintained package, because the project ships source and expects you to compile it. Before you build, read the dependency section for your platform, since the makefile will tell you what it wants to install, and check the development binaries repository if you only need a Windows build.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. simh/simh on GitHub