Dynamically configured devices simulate multiple controllers with a single DEVICE structure and can have the number of controllers being simulated set by the user. DLI, DZ, DUP, DMC, TDC, VH, DC are all dynamically configured devices.
DLI and TDC are dynamically configured devices which get static bus addresses.
The MicroVAX II boot ROM has code uses one of these instructions with the
data being referenced somewhere in Qbus space. This is not supposed to be
done according to the architecture specifications, but it must have worked on
real hardware. In any case, as a consequence of this reference to I/O space,
these otherwise non-data modifying instructions can have side effects or
reference data which may change even in an instruction looping on itself.
Given that potential, such use isn't an infinite loop which would otherwise
inspire a drop back to scp.
The original implementation coupled the elapsed time measurement
to the 100Hz internal calibration clock. This worked well enough for very
long intervals but not well at all for any intervals less than 50ms. The net
result is that it couldn't usefully be used to produce the 60Hz clock ticks
which Unix 32V used it for. It now leverages the microsecond timing
provided by sim_activate_after(). This problem is reported in #253
This allows pending I/O (console, or otherwise) to complete before dropping
back to the sim> prompt. This better simulates the model where scp is analogous
to the console processor on the older VAX simulators. This better addresses the
incomplete I/O problems discussed in #208
This is necessary to avoid kernel type ahead buffer overruns when a user
pastes a chunk of data into a console session as described in issue #246
Other console input speeds can be set with SET CONSOLE SPEED=nnn
Vector values contained in device information blocks are the true bus relative vector values. CPU specific biased vector values are produced by the respective vector fetching logic and vector values are limited to 9 bits with <1:0> = 0 as specified in both the Unibus and Qbus documents.
Prior logic attempted to load the desired file from the current default directory and if that failed wrote the in memory boot code image to the desired file and then retried the desired load..
A user can still explicitly load a ROM image with a "LOAD -R romfile.bin" command prior to a BOOT attempt if they want to test or otherwise run with a different ROM.
Problem was the console storage output buffer was masked with a WMASK instead of a BMASK (it is only a 8 bit register).
Also, the input interrupt processing cleared the output interrupt state instead of the input interrupt state. This would only be a problem when interrupts are actually used instead of polled I/O.
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 reboot command code was not defined, and even when defined, it didn't get executed before the simulated code executed a HALT instruction. Solved by scheduling immediate execution of reboot command.
VIDEO:
- Make mouse motion activity consistent with SDL relative direction. Add error output when mouse events are discarded due to queue full.
If a client application delivers motion information in a different relative sense, then that application needs to make the adjustments from the SDL standard direction.
- Added SHOW dev VIDEO capability to describe the underlying SDL video capabilities of the current SDL library and host execution environment.
- Force software based rendering under SDL2. Enhanced debug info.
- Added host OS cursor integration support.
- Reorganize libSDL vs libSDL2 version implementation to leverage common logic without replication.
QVSS:
- Coalesced adjacent screen row updates to minimize vid_draw operations
- Report all relative mouse motion in the mouse position register AND mouse motion data.
- Added debugging information for cursor and scan line map updates
- Add option "SET QVSS CAPTURED" to force capture input mode.
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
