Problem reported in https://github.com/open-simh/simh/issues/409
There are key differences between the MicroVAX I and MicroVAX II.
Specifically, the MicroVAX I is a machine with direct Qbus memory and
no QBA (Qbus Adapter) which is part of all later MicroVAXen and
corresponds to the UBA (Unibus Adapter) on systems with Unibuxes.
Among possibly other things, these Adapters primarily provide the
translation between the CPU's system memory and addresses on the
respective bus (Qbus or Unibus). These Adapters provide a set of
mapping registers which map the respective bus addresses to desired
locations in CPU memory which allows for "Scatter/Gather" memory
transfers. The MicroVAX I, having its memory directly on the Qbus,
has no CPU specific way to implement "Scatter/Gather" for I/O device
for memory transfers very much needed in systems with virtual memory.
On this system, the Scatter/Gather functionality is provided directly
within the MSCP controller which is simulated by the pdp11_rq.c
module.
On Qbus MicroVAXen with Qbus Adapters, the boot rom initializes all
the Qbus mapping registers such that Qbus addresses map directly to
CPU RAM addresses. This simplifies boot code which don't turn on
Virtual Memory (and thus the need for Scatter/Gather) until later stages
of the operating system boot. The Ultrix boot we're dealing with plays
games with the mapping registers somewhat early in the boot, and
requests a transfer of 0x2000 bytes (words maybe) to an address of
0x010000c8. Note that this would be the address from the point of
view of the controller on the Qbus. This value is actually beyond the
end of the 22bit Qbus address space (0x003fffff). The controller
therefore previously returned a non-existent memory error.
It would seem that instructions performing this I/O request are ones
which were loaded by an earlier read and thus the bug really should
be there, but since this code actually worked on real hardware,
accomodating that behavior belongs in the simulator. Meanwhile,
when this transfer has happened, the QBA Mapping registers have
been changed from their initial values that mapped 1-1 Qbus addresses
to RAM. The proper approach is therefore merely to ignore any bits
in the transfer address beyond the 22bits of the Qbus address space.
Interesting that all other operating systems (or boot code) never
presented a buffer address beyond the maximum 22bit Qbus address.
- Display Media-ID and Geometry info for all SHOW <unit> output when attached
- Use real drive Geometry info for all disk types
- Fix RA80 cylinders copied from RM80
- Fix RZ23 cylinders to reflect disk size
- Return correct cylinder info on MSCP error path
Historically, if a configuration file explicitly set either a DEVICE's
ADDRESS or VECTOR, autoconfiguration was immediately disabled.
This change defers disabling autoconfigure until an explicitly setting
of a DEVICE address or VECTOR actually changes what had been previously
configured by autoconfigure.
These are added based on simple drive geometry and size information
without any parameters for bad block management (not used in simulation
anyway).
Additionally, RF drives connected to Qbus systems via a KFQSA. When
connected this way, EACH drive on the DSSI bus appeared to the attached
Qbus system as a separate MSCP controller to the operating system. This
change does not model that connectivity.
Additional UNITs from 4 up to 254 are replicated from Unit 0.
If the UNIT->uname has already been populated, we could leak memory if
it isn't released before copying from the template UNIT.
At this time:
- The ZAP command exists to remove meta data from containers that
have it. Container files processed by the ZAP command will generally
be restored to the size it was before the addition of the meta data
and the file time stamps will be unchanged.
- Newly created containers get meta data.
- At attach time, containers that don't have meta data, but have
recognized file systems that fit within the drive it is being
attached to get meta data added without changing the file timestamps.
- Containers that don't have meta data and don't have a recognized
file system that is <= the drive size are attached without comment
and without adding meta data as long as the drive is NOT set to
autosize (controllers that support multiple drive types all default to
autosize, which can explicitly be disabled on a drive by drive basis).
- Containers that don't have meta data which are > the drive size can
only be attached read only.
- Containers with meta data can not be attached to a different
controller at all if the container size is smaller than the drive on the
other controller.
- Containers that have meta data can be freely be attached to the
controller that they were attached to when they got the meta data.
If a file system is detected, it will be reported. Otherwise if no
recognized file system is found, the attach will be silent. File
system detection reporting can be suppressed with -Q on the attach
command.
- Containers with meta data can only be attached read only to a different
controller if the container is larger than the drive it is being
attached to.
In the future:
- In general, containers with meta data (or recognized file systems)
will be attachable to MSCP and SCSI controllers, as long as reasonable
sector sizes and file system not requiring interleaving have been found.
- Containers without meta data will only be attachable if autosize
is disabled and the container is <= the size of the drive.
- Explicitly setting a drive type on a unit will implicitly disable
autosizing. If a user wants to set the default drive for a unit
and still allow autosizing they must explicitly set the unit to
autosize after setting the drive type.
Relevant to: #1065, #1059, #1094, #1100, #1118, #1117
Historically this functionality was reimplemented within each
DEVICE simulator often with slightly different implementations
and inconsistencies. Solving this globally within SCP required
changes in many places, but should henceforth be reasonably
managed.
As discussed in #1034
- Make all PDP11, VAX RP and RQ devices autosizing behave similarly
- Generalize the attach help to be specific to the device/system being
attached
- Remove the sim_disk_pdp10_* calls which weren't correct or needed
since sim_disk_attach_ex provides sector size which is used correctly
Array REGister definitions have been made consistent by passing the
name of the array object. This allows proper sizing assessment
to occur in the register validation logic.
Some previously described array REGister initializers were not really
arrays. Some were structures and others were merely pointers to
someplace in memory that it was desirable to view as a scalar array.
Structures or other blob data should now use SAVEDATA. Virtual
arrays intended to be interpret some part of memory as scalar data
now use VBRDATA initializers.
Array REGister definitions have been made consistent by passing the
address of the whole array object. This allows proper sizing assessment
to occur in the register validation logic.
- Extra queue and timer units on RQB, RQC, and RQD are now properly
initialized.
- PDP11 unit numbers are numbered:
device RQ 0-3
device RQB 4-7
device RQC 8-11
device RQD 12-15
Some devices have dedicated units that perform various independent
functions (often timing) that are independent of the primary device unit
which is ATTACHed. This services to help interpret debug information
that may be produced.
These changes facilitate more robust parameter type checking and helps
to identify unexpected coding errors.
Most simulators can now also be compiled with a C++ compiler without
warnings.
Additionally, these changes have also been configured to facilitate easier
backporting of simulator and device simulation modules to run under the
simh v3.9+ SCP framework.
The RSX-11M+ boot driver expects a slower response from the simulated
UDA50 controller. This response is only in during the MSCP initialization
sequence, so normal protocol interactions for read and write I/O are
unchanged. Updated value determined by John Forcast. Fixes#216.
