Microvax II hardware not recognized

[Paul Koning]

> On Aug 18, 2016, at 4:39 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
>> From: Paul Koning
> 
>> A lot of Unibus/Qbus devices have "floating CSRs" which means they
>> don't have fixed address assignments. Instead, the correct address is
>> based on a set of rules, which puts devices in an ordered list and
>> assigns addresses in sequence. .. If you get the address wrong, the
>> system will see the device as the wrong type
> 
> What about if you have a series of devices (A, B, C, D, E), assigned addresses
> in the correct order, and then you remove C from the system; will the software
> stop probing for more devices when it gets to C (ie. D and E, although still
> plugged in, will not be seen)?

They will probably be seen, but they will be mistaken to be a different device.

Here's how the floating CSR machinery works:  

There's a list of "floating CSR" devices in the documentation.  For example, you can find it in Appendix D of the 1981 Peripherals Handbook.  It lists device types and their CSR base address modulus.  For example, the first few entries are (modulus in octal):

DJ11  10
DH11  20
DQ11  10
DU11  10
DUP11 10
LK11  10
DMC11 10

Floating addresses start at 760010.  The address assignment works as follows:

1. Start at the start address (760010).
2. For each device type in the floating address list:
   a. Round the current address up to a multiple of the modulus
   b. For each device you actually have:
      i. Set the CSR base address of the next unit to the current address
      ii. Advance the current address by the modulus
   c. Advance the current address by the modulus of the NEXT device type (i.e., leaving a "hole" to mark no more units of that type.)

So suppose you have one DJ11, one DH11, and one DU11, but no others, the addresses would be:

DJ11: 760010  (hole at 760020 to mark no more)
DH11: 760040  (hole at 760060)
(hole at 760070 to mark no DQ11)
DU11: 760100

Suppose you then remove the DJ11 but leave the other controllers with their existing addresses.  What will happen is that autoconfig software will misidentify the DH11 as a DU11, and the DU11 as an DMC11.  The reasoning goes like this:

(hole at 760010 to mark no DJ11)
(hole at 760020 to mark no DH11)
(hole at 760030 to mark no DQ11)
DU11: 760040  (hole at 760050 to mark no more)
(hole at 760060 to mark no DUP11)
(hole at 760070 to mark no LK11)
DMC11: 760100

The correct procedure for removing the DJ11 is to remove it and also change the other floating CSR controller addresses to:

(hole at 760010 to mark no DJ11)
DH11: 760020  (hole at 760040)
(hole at 760050 to mark no DQ11)
DU11: 760060

There are utilities that do this calculation for you; for example, in the "simtools" repository (SIMH tools) there's "config11" which does all this very nicely.

---

The handbook also describes floating vectors.  Those are somewhat similar with one key difference: there are no "holes to mark no more units", instead the vectors are assigned in order to those devices that actually exist.  That makes sense given that the vector address space is so much smaller.

The way RSTS treats all this: starting with V6B, the RSTS initialization code (INIT) walks through the floating CSR address space looking for addresses that respond (no NXM bus timeout).  It uses the floating CSR order rules to identify what the device at that address is.  (In other words, it relies on correct address assignment).

RSTS does *not* use floating CSR rules.  Instead, once it has identified all the I/O devices (floating as well as fixed) that it supports, it "pokes" them to make them interrupt.  It sets all the possible vectors with an interrupt catcher, so it learns what vector is actually used.  In other words, RSTS requires correct use of the floating CSR rules, but does not care about the floating vector rules, or for that matter the fixed vector assignments.  All that matters is that the vector assignments are unique.  There's one exception: since there isn't any way to make a card reader (CD11 or CR11) interrupt without attempting to read a card, those controllers are not poked, and for that one case RSTS requires the vector to be the standard one.

	paul