  MicroVAX 3500 Q-bus and bootstrap questions? 
 The Question is:
 
I've got a uVAX 3500 here with me that just plain and simply refuses to
work. It detects it's disk and floppy controller but neither of the disks or
tape on the chains. When I try to netboot it I never see any network traffic
coming from it.
So question is; can someone think of a quick solution for this or can I get
technical manuals for the uVAX 3500 from somewhere?
I got this system for free and I'm only an out-of-work hacker so I can't pay
the money to have anyone from Digital officially lay their hands on it.
 
Thanks.
 
 The Answer is:
 
  The Wizard does not know of particularly many MicroVAX 3500 systems that
  have a floppy drive installed.  Without specific details of the system
  itself and the specifics of the Q-bus configuration, and without specific
  details of the bootstrap failure being seen here, it is impossible to
  answer this question.
 
  Information on properly determining and setting CSR and interrupt vector
  values on Q-bus modules, as well as the serpentine nature of the Q-bus
  (which you don't have to worry about in the BA213 box typically used on
  the MicroVAX 3500) have been posted to comp.os.vms, and these discussions
  are available via the http://www.dejanews.com and INFO-VAX archives.
 
  The Wizard would first recommend reading about the Q-bus configuration
  from information in the newsgroup archives and that is referenced at
  various MicroVAX sites referenced by the OpenVMS FAQ, and then posting
  the above-requested information to comp.os.vms, and requesting assistance
  from the denizens of the newsgroup with correcting the configuration.
 
  Some of the related discussions include topics (407), (1866), (3232),
  and (5219).
 
	--
 
  Here are a few of the various discussions on this topic retrieved from
  the comp.os.vms archives...  Various email addresses have been altered
  to avoid automated email spam, the information is otherwise unmodified:
 
 
In article &lt;r-larkin-ya023680002506981400110001@news.cso.uiuc.edu&gt;, r-larkin*uiuc.edu (Ronald P. Larkin) writes:
:   I have looked around at netnews and on the web and failed to find a
:listing of the recommended order of Q-bus modules.  Hardware manuals for
:individual devices are kind of coy on the topic--they usually say the
:closer to the CPU the higher the bus priority, but don't recommend where
:to put the device relative to other kinds of devices.  I've seen such
:lists printed in DECUS or someplace, but don't remember where.
 
  Devices that are less sensitive to bus delays go further from the
  bus master (usually the processor) module, while devices that are
  more sensitive must be placed correspondingly closer.
 
  Smarter and "newer" Q-bus controllers tend to be less susceptible
  to delays accessing the bus, while dumber and "older" devices tend
  to be more sensitive.
 
  Device such as streaming tapes (and their controllers), for instance,
  tend to have radically lower transfer rates if they cannot receive
  information from the host fast enough.  Non-streaming tapes can be
  further from the bus master, as they can tend to be more slow-moving,
  and more oblivious to bus latency...  Disk controllers tend to be
  fairly tolerant of latency.  (If the disk device driver and host
  software is smart enough, it can even resubmit the requests -- this
  capability is part of the support associated with mount verification
  and with error recovery.  Tapes, unlike disks, tend to have the tape
  position as an important and assumed part of their basic operations,
  unlike the block-addressable disks.)
 
  The exact order of modules is something of a black art.  With typical
  "recent" Q-bus controllers on typical MicroVAX Q-bus systems, the order
  is traditionally network, serial and point-to-point communications,
  disks, and tapes, respectively.  Though occasionally you will find a
  Q-bus widget that starts having problems with bus latencies, indicating
  a need to reorder the modules in the Q-bus.
 
:  Also, what does VMS &gt;AUTOCONFIGURE actually do?
 
  AUTOCONFIGURE probes the Q-bus CSR space looking for the CSRs of
  device controllers.  Depending on which CSR addresses return valid,
  a particular device type is assumed and configured.  Gaps in the
  address space indicate the next sort of controller should be checked
  for.  See the appendix associated with the SYSGEN documentation for
  additional details.
 
  The CSR is the address that the device driver communicates with the
  device.  CSRs are often read-write, but can have restrictions on which
  hardware instructions are used to access the contents of the CSR.
 
  The interrupt vector is the address that the device uses to communicate
  with the device driver.  Interrupts usually occur in response to something
  that has happened out on the device, such as an I/O completion, or an
  error.  Interrupts often cause the driver to "wake up" and look at the
  contents of the CSR.
 
:                                                  My SYSGEN manual does
:not give the procedure for using &gt;CONFIGURE and then &gt;AUTOCONFIGURE to
:set up a set of controllers.
 
  CONFIGURE tells you the CSRs that AUTOCONFIGURE will be looking for,
  and it allocates the available interrupt vectors for those devices
  in the floating vectors.
 
  You enter the CONFIGURE subsystem, then you specify the secret name of
  each and every Q-bus device present.  Omit none.  When you are done,
  CONFIGURE will provide you with a list of CSR and interrupt vector
  settings.  You then use the device controller manuals to encode the
  CSR and (when necessary) interrupt vector settings into each module.
 
  There are interrupt vectors at fixed locations -- these vectors are
  always assigned to specific devices, and there exists a pool of interrupt
  vectors assigned to any device, the floating vectors.  Sometimes the first
  controller of a given type will have a fixed interrupt vector, and any
  additional matching (or similar) controllers will use vectors allocated
  from the floating vectors.
 
  Some modules have soft-loaded interrupt vectors -- the device driver
  loads the interrupt vector -- and others have switchpacks that set
  the interrupt vector.  Do not, under any circumstance, trust what
  any SYSGEN display tells you about the current interrupt vector
  settings of any Q-bus modules.  On any non-soft-loaded device, you
  must pull the module and check.
 
  The other thing to be aware of when working with the Q-bus are the
  differences in the slots -- Q22/CD vs Q22/Q22 -- and the serpentine
  pattern (and you can search with the word serpentine to find previous
  discussions) used in a particular enclosure.  The BA23 has one pattern,
  the BA123 has another, and the BA2xx and BA4xx enclosures.  Which box
  effects which slots need DMA grant cards, and which slots you can
  insert dual-width Q-bus modules into.  (Most any Q22/Q22 slot can accept
  a quad-width DMA module, but you'll want to be aware of the implications
  of using a Q22/CD slots.)
 
  And I won't even get into a discussion of the available slots and the AC
  and DC loads...
 
:  I've also looked at a bunch of the Hoffman postings and at my VMS 5.5
:docs.  My system hardware manuals are older than most of my peripheral
:devices.
 
  Am I really the only one that is answering Q-bus questions around
  here?  And why do I suddenly get that "older than dirt" feeling? :-)
 
 -------------------------- pure personal opinion ---------------------------
 Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman@xdelta.ZZenet.dec.com
  note to those folks not contributing spam -- there is no ZZ in my address
 
  ++
 
 Followups set to vmsnet.sysmgt.
 
In article &lt;35183633.70A3A0EE@dial.pipex.com&gt;, Gary Gale &lt;gary.g*dial.pipex.com&gt; writes:
:Apologies in advance for the cross-posting - if this enrages anyone
:please bear with me...
 
:I'm trying to hook a uVAX 3500 onto our LAN - fairly straightforward
:most of the time but it appears that the board isn't getting any power.
:From a physical level, I've checked the connections and everything
:_looks_ fine. From a firmware level, I get no self-test problems when
:booting.
 
:I've got an Applied Telesis CentreCOM 210T transceiver to convert from
:thick-wire down to 10 Base T but at no time do I even get a power
:indication, likewise on the hub I'm getting no signal at all.
 
:So - no apparent problems, no diagnostics but no network either. Anyone
:out there care to point me in the direction of an on-line resource I
:could peruse or have any suggestions?
 
  Uh, which Ethernet board?  Which operating system?  Which system
  enclosure (BA23, BA123, or the BA2xx more typical of the MicroVAX
  3500 series)?  Which slot have you plugged the Ethernet board into?
  Do the board and the bulkhead match?
 
  One common older DIGITAL Ethernet board is not IEEE 802.3, and is
  not supported on recent OpenVMS versions: the DEQNA.  (I would not
  expect to see a DEQNA in an S-box BA2xx series enclosure, but I
  digress.)
 
  Typical DIGITAL Q-bus Ethernet controllers have only a few different
  CSR addresses, sometimes as simple as a primary and a secondary CSR
  address setting.  One can usually see pretty quickly from the MicroVAX
  3500 console if the console "sees" the controller correctly, which means
  that the controller is at the correct CSR address.
 
  If you are not seeing power on the transceiver, then I would expect
  there is a wiring fault, or there is a controller fault.  Even the
  older Ethernet boards are only missing "heartbeat" -- they should
  power the transceiver if they are functioning.  If the Ethernet
  board is plugged into a Q-bus slot, then it has power.  (Beware
  plugging any Q22/Q22 quad controller, and any Q22 dual controller,
  into a "CD" slot.  Q22/CD quad controllers and Q22 dual controllers
  are commonly used in the BA2xx series enclosure.)
 
  You are heading into the art of configuring a Q-bus -- there have
  been several previous discussions.  Visit www.dejanews.com and look
  through the archives for "hoffman serpentine quad dual" and/or a few
  other keywords or incantations -- I've posted details before.
 
 -------------------------- pure personal opinion ---------------------------
 Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman*xdelta.ZZenet.dec.com
  note to those folks not contributing spam -- there is no ZZ in my address
 
  ++
 
In article &lt;MSGID_1=3A163=2F506.0_33f7f17a@fidonet.org&gt;, Doug_Murray*rdbbs.jammys.net (Doug Murray) writes:
: I have a few questions about the MicroVAX II system.
:1. Does anyone have the list of &gt;&gt;&gt; commands?   I know I can Examine and
:Deposit to/from registers, but dont have a clue as to what other commands are
:available at that level.
 
  E, D, B, H, U, and I -- Examine, Deposit, Boot, Halt, Unjam, and Init
  -- are all the commands you will likely ever need.
 
:I have a MicroVAX II system with a DHQ11 controller, but it seems that my
:system does not see any of these ports or controller. the card is located in
:the bottom part of Slot 4.
:I have been told that some of these slots cannot
:be used for certain interfaces.
 
  This depends on the specific enclosure.  In the BA23, the first three
  slots are for the CPU and memory -- the so-called Q22-CD slots -- while
  in the BA123, the first four slots are Q22-CD slots.  In the BA2xx and
  BA4xx, all slots are Q22-CD.  Starting in slot 4 of the BA23 and in
  slot 5 of the BA123, the Q22-bus becomes serpentine -- going from the
  upper slot to the lower slot, then to the lower slot of the next higher
  slot, then to the upper slot, then to the upper slot of the next higher
  slot.   (Got all that?  It's easier to draw it out on paper.)  The BA2xx
  and BA4xx do not have a serpentine pattern.
 
  What does this mean?  It means you have to insert dual Q22 cards in the
  appropriate slot, and that you may or may not need a bus grant card when
  a dual and a quad Q22 module are adjacent.  You can place a dual-width
  card in the upper-portion of a Q22-CD slot.  You cannot place a dual-width
  card in the lower-portion of a Q22-CD slot.  And you can place CPU and
  memory cards only in a Q22-CD slot, not in a Q22-Q22 slot.
 
  A full-width module is called a `quad' -- four sets of contact `fingers',
  while a half-width module is called a `dual' -- two sets of `fingers'.
 
:Would anyone know where this card should be
:located?  I attempted to AUTOCONFIGURE the system but still the ports or
:controller do not show up.
 
  This usually means one or more CSRs are mis-set.  Use the SYSGEN
  CONFIGURE command -- specify *all* Q22-bus cards present in the
  system -- to determine the correct settings for the CSR(s) and
  interrupt vector(s) for each module(s) in the system. Then check
  *all* modules -- adding or removing a module can cause a series
  of cascading CSR and/or interrupt vector changes throughout the
  entire Q22-bus.
 
:Additionally, if someone has technical documentation on the MicroVAX II
:system, I would gladly workout some arrangement to get a copy.  Its not
:obvious on how to set the CSR's and Vectors.
 
  The CSR and vector documentation is included with the documentation
  for each module.  It is not in the MicroVAX KA630 CPU documentation.
  The CPU technical documentation is the EK-KA630-UG KA630 CPU module
  user's guide.
 
  -------------------------- pure personal opinion ---------------------------
   Hoff (Stephen) Hoffman   OpenVMS Engineering   h*ffman*xdelta.enet.dec.c*m
     headers and addresses munged to avoid automated spammers: junk-e-mail
 
  ++
 
In article &lt;40qmoi$l1q@explorer.csc.com&gt;, rmsmith*csc.com (Robert Smith)
writes:
 
:I may be suffering from Oldtimers (keep forgetting whether I
:read something on this or not disease) but can some kind person
:please explain to me the meaning of  Q-22 C/D?
 
:I think it means Q bus, 22 bit addressing, and C/D slots are wired
:for DMA (or NPR in the days of the unibus).
 
:For example - the microvax backplanes are listed as Q22 with the first N
:slots C/D.  On a BA123 box I believe this is the first four slots.
 
  BA23: 3, BA123: 4, BA2xx &amp; BA4xx: all.
 
:Now I think this means that the cpu goes in one, the mem in the next two,
:and I don't think I really know what goes in slot 4....
 
:Is the BA23 backplane the same?
 
:thanks in advance for any help in getting this thru my thick skull!
 
  The Q22 is commonly used as an I/O bus, and the CD interconnect has
  various uses but is most commonly used as part of a CPU-to-memory
  interconnection.  As any owner of the MicroVAX I may directly or
  indirectly realize, the Q22 bus does have memory space in addition
  to I/O space, but the memory space is limited to a 4MB address space.
  The CD interconnect (with the over-the-top ribbon cables) allows
  access to rather more memory -- it's part of the memory subsystem
  on some MicroVAX and VAX 4000 processors.
 
  The DMA circuitry is part of the Q22 bus, and the CD interconnect is
  quite seperate from the Q22 DMA request and grant processing.
 
  One can place a dual-width Q22 card in a Q22/CD slot, but one cannot
  place a quad-width Q22 card into a Q22/CD.  (One can sometimes get
  around this -- don't try this one at home folks, this is a professional
  hardware hacker's trick and it can trash the board if not done right
  and it can void service contracts and warrantees -- by cutting the Q22
  DMA etch that would otherwise have been installed in the CD slot.)
 
  If no card is installed in an intermediate Q22 slot, one must insert
  a Q22 DMA grant card -- `holes' in the Q22 bus are bad news and can
  cause bus hangs and other errant behaviour -- into the Q22 slot.  And
  the mistaken insertion of a Q22 grant card into a CD slot has the
  potential to cause problems.  There is no CD grant card.  (Much to
  the relief of ASCAP.  :-)
 
  In the BA23, the first three slots are Q22/CD, and subsequent slots
  are serpentine Q22.
 
  BA2xx, BA4xx series:
 
          6      5      4      3      2      1
        &lt;-Q22  &lt;-Q22  &lt;-Q22  &lt;-Q22  &lt;-Q22  &lt;-Q22
 
        &lt;-CD   &lt;-CD   &lt;-CD   &lt;-CD   &lt;-CD   &lt;-CD
 
   BA23 series:
 
          6      5      4      3      2      1
          Q22  &lt;-Q22    Q22  &lt;-Q22  &lt;-Q22  &lt;-Q22
           |      A     |
           V      |     V
        &lt;-Q22    Q22  &lt;-Q22    CD   &lt;-CD   &lt;-CD
 
 
   BA23 series:
 
          6      5      4      3      2      1
        &lt;-Q22   Q22  &lt;-Q22  &lt;-Q22  &lt;-Q22  &lt;-Q22
           A     |
           |     V
          Q22  &lt;-Q22   CD   &lt;-CD   &lt;-CD   &lt;-CD
 
 
  ------------------------------ Opinionative -------------------------------
   Stephen Hoffman      OpenVMS Engineering      h*ffman@xdelta.enet.dec.com
  ---------------------------------------------------------------------------
 
 
  ++
 
In article &lt;61617n$oij$1@java.imsa.edu&gt;, Beverly Thurber &lt;tsunami*imsa.edu&gt; writes:
:i've recently picked up a microvax ii.  it's a rackmount system that
:has some sort of hard drive (5 1/4" full height) and a tape drive.
:i plugged it in with a null-modem cable going to my laptop and turned it
:on, but nothing came up on my laptop's screen.  the led on the back of
:the vax is flashing, alternating between 9 and f.  any suggestions on
:how to make it work?
 
  The DB9 pinout on the MicroVAX II predates the PC DB9 pinout, and
  is based on an older standard -- the folks that designed the PC
  invented a new pinout, which has become the new standard.  For
  adapter and pinout details, as well as a wealth of other answers
  and URLs, please see ftp://ftp.digital.com/pub/Digital/dec-faq/vms,
  this is the OpenVMS Frequently Asked Questions (FAQ).
 
  Without knowing the Q-bus hardware configuration, it's hard to say
  exactly what is wrong here -- the self-test has obviously failed.
 
  The Q-bus design uses a "cascading" assignment of addresses -- the
  control and status register (CSR) and interrupt vector settings --
  and this means that the system is sensitive to the settings of each
  of the modules present in the Q-bus.  This comes into play when
  Q-bus modules are added or removed.  Also of interest is the
  Q-bus backplane wiring -- in enclosures from the MicroVAX II
  vintage, the Q-bus wiring is "serpentine":
 
  BA23:
        Q &lt;- Q    Q &lt;- Q &lt;- Q &lt;- Q
        |    ^    |
        V    |    V
    &lt;-  Q    Q &lt;- Q   CD &lt;-CD &lt;-CD
 
  BA123:
        Q &lt;- Q    Q &lt;- Q &lt;- Q &lt;- Q &lt;- Q
        |    ^    |
        V    |    V
    &lt;-  Q    Q &lt;- Q   CD &lt;-CD &lt;-CD &lt;-CD
 
 
  The MicroVAX II Q-bus is normally wired right to left or top-to-bottom,
  with the CPU in the topmost or rightmost slot, and the memory module(s)
  in immediately adjacent slots.  The KA630 MicroVAX II supports up to
  two 8 MB memory modules, and a total of 16 MB of memory.  The typical
  disks were the RD53 and the 159 MB RD54.  The typical tape drive is
  the TK50 DLT drive.
 
  A dual Q-bus card (two sets of connector fingers -- half the width
  of the MicroVAX II Q-bus enclosure) must reside in a Q-bus slot.  A
  quad-width module -- the full width of the MicroVAX II Q-bus enclosure
  -- can reside in a Q-Q or a Q-CD module.  Q-bus dual modules can not
  be placed in a CD slot.  In general, the CPU and memory modules should
  be plugged into a CD slot.  (Do not plug a Q-bus module into a CD slot.
  Q-bus enclosures after the BA123 and BA23 use entirely Q-CD slots, and
  the modules for these enclosures are intended to be used in Q-CD slots.)
 
  The Q-bus cards generally have a code number -- the letter M and then
  (usually) four digits -- stamped or etched on them somewhere, usually
  on the module's spine.  The KA630 MicroVAX II CPU module is the "M7606",
  for instance.  If you tell us which modules are present and in which
  slots, and which slots are empty, and if you can tell us which MicroVAX
  II enclosure -- the "space heater" BA23 or the "coffee table" BA123 --
  we can start to help you.
 
  The FAQ has URL pointers to websites with more MicroVAX information.
 
  -------------------------- pure personal opinion ---------------------------
   Hoff (Stephen) Hoffman   OpenVMS Engineering   h*ffman@xdelta.enet.dec.c*m
     headers and addresses munged to avoid automated spammers: junk-e-mail
 
  ++
 
 
In article &lt;3tvhl6$11f@sloth.swcp.com&gt;, phdewi*swcp.com (Phillip Williams)
writes:
:Hello
:On one of my uVAXIIs when ever I try to set a term ie
:set term txa0:/device=vt200/speed=9600/nomodem/perm
:it comes back with error setting txa0: device timed out
:I have switched out the dhv11 but no luck.
:any thoughts.
:phillip
 
  NOTE: I would recommend all hardware service be refered to a qualified
  service technician -- one can cause physical, electro-static or other
  damage or destruction to the hardware and surroundings, and one can
  potentially damage or destroy one's self if not trained and familiar
  with working inside the enclosure.  Dangerous voltages and electro-
  static-sensitive components are present inside the enclosure.
 
        --
 
  My guess is that the CSR and vector settings are incorrect on one or
  more modules residing in the Q-bus.  You will have to use SYSGEN
  CONFIG command to determine what the correct settings are, and then
  you must remove each module and check (and reset if necessary) the
  switchpacks that encode the CSR and (when it is not softloaded) the
  interrupt vector.  DO NOT ASSUME THAT ANY SYSGEN COMMANDS CAN DISPLAY
  THE ACTUAL INTERRUPT VECTOR SETTINGS -- THEY DO NOT.  The only reliable
  way to determine that the CSRs and the interrupt vectors are set
  correctly is to decode the settings off the Q-bus modules.
 
  When one swaps modules into or out of a Q-bus, one *must* re-evaluate
  the CSR and interrupt vector settings of *all* modules residing in the
  Q-bus.  (Unlike many more modern busses, the Q-bus requires manually
  configured settings, and the insertion or removal of an I/O module can
  and often does have a cascading serioes of settings changes on the
  remaining modules in the Q-bus.  And folks new to working in the Q-bus
  often neglect to specify _all_ modules present in the Q-bus; this will
  usually lead to a non-functional or mis-functional system.  DO NOT
  FOCUS ON ONE Q-BUS MODULE -- EVALUATE ALL SETTINGS ON ALL MODULES.)
 
  In addition to the CSR and interrupt vector, one also needs to take
  the serpentine path of the Q22 portion of the Q-bus within various
  enclosures (the pattern varies depending on the particular Q-bus
  backplane used), and one must account for the slots in the Q-bus
  backplane that have the CD (memory) interconnect in addition to the
  Q22 interconnect.  (The Q22/CD slot pattern also varies depending
  on the particular Q-bus backplane used.)  EMPTY Q-22 SLOTS WILL
  CAUSE PROBLEMS WITH SUBSEQUENT Q-22 MODULES.  INSERTION OF Q-22
  MODULES INTO CD SLOTS CAN INTRODUCE OTHER, INTERESTING, PROBLEMS.
 
  Alternatively, the DHV11 could be dead.
 
  Again. refer service to a qualified technician...
 
  ------------------------------ Opinionative -------------------------------
   Stephen Hoffman      OpenVMS Engineering      h*ffman@xdelta.enet.dec.com
  ---------------------------------------------------------------------------
 
In article &lt;0095000015704357000002L072*@MHS&gt;, JOHN MALMBERG &lt;LNUSSAT.JMALMBER*eds.com&gt; writes:
:Hoff writes:
 
:&gt;  It is possible to use a Q22/Q22 board in a Q22/CD slot, but I generally
:&gt;  prefer to sever the DMA grant etch -- this will prevent any sort of odd
:&gt;  positioning-dependent problems relative to any CD-cogniscent modules in
:&gt;  the enclosure.  (Most folks don't deal with CD-cogniscent modules.)  When
:&gt;  moving a Q22/CD board to a Q22/Q22 slot, one must check for, and add in
:&gt;  if necessary, the DMA grant etch.
 
:Useful information to know for keeping the home World Box System with it's
:Q22/Q22 running with what ever I can scrounge :-)
 
  Be aware of the differences in the serpentine pattern in the BA23,
  BA123, and BA2xx/BA4xx series.  (If you search the archives of the
  group for "Q-bus" and "serpentine", you'll likely find a few of the
  previous answers I've posted on this particular subtopic.)
 
:Good Q-Bus information can be hard to find now for some of us.
 
  Most early technical manuals for Q-bus systems have an appendix on the
  Q-bus, giving the wiring, timing, etc.  This information was available
  seperately, as well.  (The VAXstation II owner's manual is one of the
  manuals that has a Q-bus appendix.)
 
  Also visit INFO-VAX and www.dejanews.com -- I've answered a number of
  Q-bus questions over the years, and the archives are searchable.
 
:Since the CXA16/CXB16/CXY08 only seem to be supported for the BA213, BA215, and
:BA440 backplanes, all of which are only Q22/CD slots, I would assume that they
:are Q22/CD boards, not a Q22/Q22 boards, but nothing in my copy of the
:documentation to confirm or deny my assumption.
 
  You will have a better chance with boards that have a detachable bulkhead.
  If the S-box bulkhead (BA2xx/BA4xx) is attached to the module, the module
  will not fit in the BA23 nor BA123.  Also note that S-box modules are
  allowed to use slightly more clearance due to the larger seperation in
  the S-box -- modules were closer together in the BA23 and BA123.  If you
  are swapping modules, check the clearance carefully before "jamming" a
  module into one of the backplanes with narrower seperations...)
 
  The DHV- and DZV-series controllers were rather more common in the older
  BA23/BA123 enclosures.
 
  And the KA630, KA650, and KA655 all use the same BA23/BA123 bulkhead,
  and the same BA2xx bulkhead -- the modules can be used in either the
  BA23/BA123 or the BA2xx series enclosures.  (The KA640 doesn't fit in
  the BA23/BA123 due to mechanical and RFI limits, and it uses a bulkhead
  that differs from the KA630, KA650, and KA655.)
 
  Radio Frequency Interference (RFI) requirements can (and do) limit which
  Q-bus modules can be used in particular enclosures.
 
:In looking this up, I have also found that several but not all of the quad
:height boards have switch packs for exactly the purpose that you mentioned.
 
  In addition to switchpacks, some Q22/Q22 boards will have a zero-ohm
  resistor, rather than etch.  This makes cutting the grant easier...
 
:I would still caution such modifications to only be made by experienced
:persons who assume all risk.
 
  Ayup, one of the two ends of a soldering iron can be quite hot.  :-)
 
  And if you are not trained and experienced in working inside a system
  enclosure with static-senstive components and with the potential (no
  pun intended) for contact with dangerous power levels, don't do it.
  If the documented maintenance procedures are not followed, damage or
  death to human and/or to hardware could result.
 
 -------------------------- pure personal opinion ---------------------------
 Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman@xdelta.ZZenet.dec.com
  note to those folks not contributing spam -- there is no ZZ in my address
 
 
 
