1
0
mirror of https://github.com/simh/simh.git synced 2026-01-11 23:52:58 +00:00
Mark Pizzolato 661be5d1eb Qbus MicroVAXen: Fix Qbus Address reference passed in by some OS boot code
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.
2024-09-02 18:20:35 -10:00
..
2015-02-13 06:18:24 -08:00
2022-10-26 12:59:49 +02:00
2023-11-12 12:58:55 -10:00