>it seems like a lot of work to address the theoretical flexibility you're
>asking for. :-)
It's worth pointing out that there's a use case for simh where somebody uses
the simulator to install software on, and build a disk image for, a real
machine. Once all the software is installed and configured on the simulation,
you can transfer the disk image file to a real disk drive and plug it into a
real machine. Boot it up and away you go...
There are lots of advantages to doing this - simh is way faster than a real
machine when it comes to configuring, compiling and linking operating systems.
It's way easier to copy of a simh disk image file to create a backup or check
point. If your software distros are already in the form of tap files or
diskette images online, then it's way easier to connect them to simh then to
write them to real media. And so on...
In this use case it's advantageous to be able to reproduce the exact target
hardware configuration in simh. This is especially true for most PDP-11 OSes,
which require that CSRs and vectors be defined when the system is generated and
don't autoconfigure for hardware changes (or at least they don't autoconfigure
There are obviously a lot of hardware combinations and the amount of effort
that should be put into simulating all of them is debatable, but if there are
simple fixes that can be made which would expand the range of configurations
that can be simulated correctly then that's probably worthwhile.
Simh mailing list