On 8/18/2016 4:39 PM, Noel Chiappa wrote: The microvax has the following boards installed: CPU - KA630 Memory - Clearpoint (8MB) Memory - DEC MS630 (2MB) DHV11 TQK50 Viking SCSI controller DEC - RQDX2 (CSR set for 2nd position) There are 2 grant continuity boards installed also. When I boot VMS 5.5 - Welcome to VAX/VMS V5.5 Username: SYSTEM Password: Welcome to VAX/VMS version V5.5 Last interactive login on Wednesday, 17-AUG-2016 17:40  $ show dev Device Device Error Volume Free Trans Mnt Name Status Count Label Blocks Count Cnt DUA0: Online 0 DUA1: Mounted 0 VAXVMSV055 1954647 126 1 DUB0: Online 0 DUB1: Online 0 Device Device Error Name Status Count FTA0: Offline 0 OPA0: Online 0 Device Device Error Name Status Count PTA0: Online 1 PUA0: Online 1 PUB0: Online 1 WSA0: Offline 0 When I boot VMS 7.2 - Welcome to OpenVMS (TM) VAX Operating System, Version V7.2 Username: system Password: Welcome to OpenVMS (TM) VAX Operating System, Version V7.2 Last interactive login on Wednesday, 17-AUG-2016 17:45 $    show dev Device Device Error Volume Free Trans Mnt Name Status Count Label Blocks Count Cnt MV2$DUA0: Mounted 0 OVMSVAXSYS 1858635 138 1 MV2$DUA1: Online 0 MV2$DUB0: Online 0 MV2$DUB1: Online 0 Device Device Error Name Status Count FTA0: Offline 0 OPA0: Online 0 Device Device Error Name Status Count MPA0: Offline 0 PTA0: Online 1 PUA0: Online 1 PUB0: Online 1 I swear that when I first installed VMS the DHV11 ports showed up in the show dev list on the MicroVax II. The TQK50 controller (I have 2) were put into a MicroVax 4000 and that Vax saw each board, so I don't think the boards are bad.

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