mirror of
https://github.com/simh/simh.git
synced 2026-01-11 23:52:58 +00:00
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.