>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 
very well).

  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

Reply via email to