All options which are currently and previously described in the comments
as allowing {option-name}=1 to enable, are now enabled if {option-name}
is defined to be anything at all,
- This exercises macOS first which is more likely to have build issues than
Linux or Windows.
- Fix the format of the date used in filenames and commit messages
- Only include the platform simulator binaries in the created tarball
B. Scott Michel's run of clang memory sanitizer potentially identified
that when a substring doesn't match the returned array offsets would
be -1.
This commit handles that potential and sets the respective substring as
an empty string.
The first ROM included will be defined with names:
BOOT_CODE_SIZE
BOOT_CODE_CHECKSUM
BOOT_CODE_FILENAME
BOOT_CODE_FILEPATH
BOOT_CODE_ARRAY
and BOOT_CODE_URL
That first ROM will also have names:
BOOT_CODE_SIZE_1
BOOT_CODE_CHECKSUM_1
BOOT_CODE_FILENAME_1
BOOT_CODE_FILEPATH_1
BOOT_CODE_ARRAY_1
and BOOT_CODE_URL_1
Subsequent included ROM's will have names
BOOT_CODE_SIZE_n
BOOT_CODE_CHECKSUM_n
BOOT_CODE_FILENAME_n
BOOT_CODE_FILEPATH_n
BOOT_CODE_ARRAY_n
and BOOT_CODE_URL_n
where n is 2 thru the max number of supported ROM includes.
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.
