This commit introduces dozens of changes to make the 3B2-700 simulator
fully functional and ready for wider use. In addition to 3B2-700
availability, this commit includes a tremendous amount of refactoring
of the 3B2-400 and common code to make the project structure easier to
maintain and reason about.
One final important change: ROM files are no longer included in the
source code. 3B2 ROM images must be obtained separately and loaded
into the simulator before boot.
Changes:
- The 3b2 target has been aliased to 3b2-400
- The formerly named 3b2-600 project has become 3b2-700
- SCSI QIC tape support has been added to sim_scsi.c
- Header files have been reworked to reduce complexity of includes
- Common code has been consolidated
- Timer code has been unified
When multiple ROM images are included by the same source module,
#define variables with names BOOT_CODE_SIZE_n, BOOT_CODE_FILENAME_n
and BOOT_CODE_ARRAY_n will be defined.
This change lays the groundwork for adding support for Rev 3 3B2 models,
which includes the Model 500, Model 600, and Model 1000.
Rather than use the fixed strings "400" and "1000" in file names, the
strings "rev2" and "rev3" will be used, which allows greater flexibility
to implement various system configurations more easily.
Additionally, this change adds a copy of the Debug Monitor (DEMON) ROM
image for the Rev 2 board, to be used soon in a later checkin.
Refactor in preparation for the addition of a Rev 3 simulator for the
3B2/1000 system.
This change also includes a full cleanup of the rat's-nest of includes
and externs that plagued the 3B2 simulator and made it difficult to
understand and maintain. Headers are now required in the following
order:
compilation unit -> "3b2_defs.h" -> {... dependencies ...}
Finally, HELP has been added to the CPU device.
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.
