VAX 11/.750 Boot ROM code makes non-longword memory references to MassBus and Unibus register space. Minor changes were necessary to allow this behavior which was architecturally undefined behavior, but had real code which depended on it.
Added a BOOTDEV option to the CPU to reflect the 4 position boot device selection switch on real VAX 11/750 hardware.
The UBA750 initial state started with the UBA map registers validly mapping the first 256KB of RAM to Unibus space.
Added simulated PCS/WCS memory which boot code on some operating systems (Ultrix and other BSD derived systems) automatically loaded on the VAX 11/750. PCS/WCS was also automatically loaded by the newer versions of the BOOT ROMs.
The native VMB.EXE program historically supported a Boot Block oriented
boot if Bit 3 of the parameter register (R5) was set when VMB was invoked.
This Boot Block boot operation reads sector 0 into memory and starts
execution at offset 2 of the data block in memory.
When portitions of VMB were migrated into ROM to support the earliest
MicroVAX system (MicroVAX I) and all subsequent ROM based VMB versions
the concept of Boot Block booting was extended in these ROM VMB
implementations. The change in boot block booting functionality included
several features:
1) If a normal boot attempt to a device failed (due to VMB not being
able to locate a secondary bootstrap program), a boot block boot is
automatically attempted. If the Bit 3 of R5 was set, then the
initial search for a secondary boot block was avoided and a boot
block boot was immediately attempted.
2) When performing a boot block boot, the sector 0 contents are examined
and if these contents conform to the pattern defined for ROM based
(PRA0) booting, the ROM format Offset, Size, and Starting address
information is used directly by VMB to load a program into memory
and control is transferred to that program. If the contents of
sector 0 do not fit the pattern required for ROM based booting, then
the code in sector 0 is executed directly starting at offset 2,
the same as was originally done with the non ROM based VMB versions.
Note that this extended behavior allows sector 0 to contain very little
information and quite possibly no actual boot code.
Developers of alternate operating systems for VAX computers noticed the ROM
based boot block behavior and changed their installation media AND the disk
structures to only provide the minimal boot information required on the
systems with VMB installed in ROM.
Since, when this active development of these alternate operating systems for
VAX computers was happening, the vast majority of development and new system
deployments were to hardware which had ROM base VMB, no one noticed that
older systems which booted with the non ROM based VMB could no longer boot
from new install media or disks formatted with these operating systems.
This patch addeds the ROM based VMB boot block boot functionality to the
original dynamically loaded VMB.EXE used by the older systems to boot.
The patch overwrites some VMB code which exists to support NVAX(1302) and
Neon-V(1701) systems. If simh simulators for these systems are ever built
an alternate location must be found to accomodate this extended logic
- Avoid assignments of void * values. Cast all memory allocation return values to appropriate types.
- Add output to sim_log where missing in various places.
- Fixed issue with lost file positions after a restore for devices which leverage the UNIT_SEQ flag.
- Added support to allow proper building of ROM dependent modules if the ROM image file is missing but the desired ROM image include file exists and has the correct/expected contents.
- Added support to help new ROMs to be added to the set of ROMs which are translated/tested.
- Added command Usage to program which is displayed if invoked with /? or /help Usage displays the current set of ROM images which are known.
This can happen if the file was transferred or unpacked incorrectly and in the process tried to convert line endings rather than passing the file's contents unmodified.
This allows a single simulator executable to be a completely useful component (for those simulators which dynamically load ROM or other boot code).
Meanwhile, we continues to allow the explicit use of a user's preferred ROM or other boot code as well.
A build option is provided in the makefile to not build with the included ROM functionality if desired.
