Operating systems and boot driver code presume that each Massbus
device will always be at a specific fixed address and use a specific fixed vector.
The prior implementation assigned the first active Massbus device to RHA
and followed in order for subsequent devices. This could leave devices at
addresses and vectors that software or boot drivers wouldn't expect.
The problem which was originally reported in #301 should now be properly
solved. As a consequence of the need to have fixed addresses and vectors,
some combinations of devices can not coexist in a system without causing
conflicts with each other. TM and TU have conflicting interrupts. TM and
TS have conflicting addresses and interrupts.
remove()'s behavior was extended to perform either a unlink() and if
that failed, a rmdir(). This is not consistent with the native commands
del or rm since they only remove a file but not a directory.
BAD144 info was written correctly if the user answered Y when the disk
image was created, but would not work if SET RPn BADBLOCK was
entered later.
Auto sizing would be potentially wrong if a disk had been created
without writing the BAD144 data. Now, if the disk contains a file system
that information along with the physical container's size is used to
properly auto size the disk.
This allows a device simulator to specifically name the units that it uses
for different purposes. This info is visible in the output of SHOW QUEUE
and debug output.
Once specified or dynamically determined (as previously occurred with
each call to sim_uname()), that name is saved for fast delivery on subsequent
calls. This will remove some overhead when running with debugging on.
Make REM-CON units dynamically allocated and use symbolic names for the
respective different roles they play. This will make interpreting the existing
code easier and ease future extensions.
The original model started with two array variables each with one element
for each potential concurrent remote console. As functionality was added
the number of arrays grew to an unreasonable number. This change
merely gets rid of the separate arrays of per connection info and uses a
single array of REMOTE struct which contains all the per connection info.
This will make future functional extensions much cleaner.
Adds:
1) Simulator side execution of register update activities at an interval
specified in usecs. Rates in excess of 1000Hz should be achievable
for locally connected frontpanel applications.
2) New API for simulators to describe the register state available in
the simulator. If all of a the state which is potentially interesting
to front panel applications is always present in the variables
described by simh REG structures, then frontpanel API access to
that data can be more efficiently provided.
