The system default of no extra backlog has generally worked well for
simulated mux devices for a long time since reasonable arrival of
new tcp connections is usually expected to have gaps of minutes.
If, for some reason, connection arrivals in a particular case can
happen multiple times per second, a backlog might be useful.
Leverage drive type flag DETAUTO which defers meta data addition to
happen at detach time. This allows pre-existing containers to be attached
to larger drives (with more platters) with autosize disabled and then if
autosizing is subsequently enabled before detaching, will thus add correct
meta data when the unit is detached.
Newly created containers will have meta data added at creation time and
updated to reflect data written beyond the original data in the container.
Different versions of VMS on different VAX systems default to different
locations for the secondary bootstrap program SYSBOOT.EXE. Some
have it at [SYSEXE]SYSBOOT.EXE and others have it at
[SYS0.SYSEXE]SYSBOOT.EXE.
Digital sold different MicroVAX I and VAXStation I systems with different
boot ROMs that defaulted to look in one of these locations but not
consistently across systems that were sold.
This change uses the existing KA610 ROM image (that supports both
MicroVAX I and VAXStation I systems) and defaults to look for the
secondary bootstrap in [SYSEXE]SYSBOOT.EXE. If the boot attempt
fails, on the currently connected disk, it retries looking for the
secondary bootstrap in [SYS0.SYSEXE]SYSBOOT.EXE.
This retry process does not work on the VAXStation I. In order to boot
from disks which have SYSBOOT.EXE located in [SYS0.SYSEXE] you can
execute
sim> BOOT /R5=100
and when you are prompted in the video screen with:
Bootfile:
merely enter:
Bootfile:[SYS0.SYSEXE]SYSBOOT.EXE
- Behave well when NOCALIBRATE mode is enabled after some instruction
execution already happened.
- Properly detect the reliable calibrated clock or use the internal one.
Note: To avoid potential breakage of existing PDP11 configurations in
the wild, which may expect RP on RHA, TU on RHB and RS on RHC,
RPB is connected to RHD Massbus adapter.
- More robust recovery when Massbus configuration errors occur
- More complete RH{A,B,C,D} help
Peter Allan analyzed the source code for the VAX780 simulator and
came up with a somewhat simple strategy to replicate the RP device
source code and to add another controller on an additional Massbus.
That initial strategy includes: Copying the pdp11_rp.c source module to
pdp11_rpb.c and making almost all global variables static as well as all
internal functions used in the RP device. All but the "DEVICE rp_dev",
that is, which now becomes "DEVICE rpb_dev" with a name of "RPB".
The change process was relatively simple although somewhat tedious and
wouldn't easily lend itself to manage future changes that might happen to
pdp11_rp.c.
The changes in this commit cleanup pdp11_rp.c so that changing it to
pdp11_rpb.c only need to affect 3 lines of code which will simplify
future maintenance of these modules.
