If you are just starting out as an OpenVMS hobbyist, MicroVAX and VAX hardware systems with a Q-bus I/O bus are not the easiest choice, and are accordingly not the most recommended (initial) platform. These Q-bus systems have module- and bus-level configuration requirements (discussed below) that may not be familiar, and these systems also tend to lack easy access to SCSI or other similar storage devices.
As when working on any computer system hardware or other electrically-powered devices, you can potentially cause serious and permanent damage to the hardware or even to yourself. Electricity kills! If you are not trained in and not experienced in hardware maintenance — stop now! There are potentially dangerous voltages within most any computer, and the systems described here are no exception. Always unplug it! Always follow the manufacturer's recommended maintenance procedures! If you don't know what you are doing, don't mess with it!
But as you are still reading here, what follows are some details of the Q-bus.
The Q-bus is the I/O bus used for many MicroVAX and VAX 4000 series systems, and provided both the I/O and memory bus on the KA610 series processor used on the MicroVAX I and VAXstation I series systems.
Within the MicroVAX and VAX processors, the Q-bus implementation is a 22-bit I/O bus, hence various references to the Q22-bus as a synonym. This also used to differentiate the Q-bus implementation within the MicroVAX and VAX series, and within contemporary MicroPDP series (a PDP-11 variant), as an earlier Q-bus implementation was based on an 18-bit bus.
As with many I/O buses, the Q-bus presents itself to the host as a specialized region of the physical address space. This allows device drivers to reference the Q-bus for various operations.
The Q-bus host presentation itself is divided into memory space and into I/O space. As you might expect, the four megabytes of Q-bus memory space basically operates similarly as physical memory, and Q-bus modules and device drivers can cooperate to allow the controller to present host-accessible physical memory within this region. This allows, for instance, the implementation of a series of ring buffers within memory accessible to both the controller and to the host system, allowing the controller and the host to cooperate around data transfers.
Other than the KA610 series processor used in the MicroVAX I and VAXstation I series, no MicroVAX or VAX accesses system physical memory through the Q-bus memory space. Other than the MicroVAX I and VAXstation I, all systems with Q-bus buses use other interconnections for host physical memory, reserving the Q-bus memory space for I/O operations.
Switches and Settings
Q-bus modules are configured through one or more sets of switches, and these configured the I/O space address of the Control and Status Register(s) (CSRs). The host system then locates the Q-bus modules present within the bus using series of address probes within Q-bus I/O space, seeking the presence of one or more CSRs. Based on the response returned from known and specific fixed CSR addresses, and what is found within a range of CSR addresses within a part of Q-bus I/O space known the Floating Vectors, the system bus configuration is determined.
These CSRs use an octal address notation, and are typically set on the module through a switchpack, a set of jumpers, or wire-wrap. The settings and organization and encoding can and do vary by the particular module.
In addition to the CSR selection, many modules will also have an interrupt vector address setting. This is the bus address that the module pokes at when it wants attention; when it has something of potential interest for the host device driver, such as a Direct Memory Access (DMA) completion, or an unsolicited interrupt. Unlike the CSR, it is possible for some modules to have the interrupt vector address soft-loaded by the host device driver. Many modules do, however, require the module to be encoded into a switch-pack, jumpers or, yes, the oldest of Q-bus modules can require use of a wire-wrap tool. The interrupt vector setting is always determined after the CSR address is determined, and the vector settings of each module must be determined based on all modules present.
Fixed and Floating Addresses
Within the fixed CSR space, there are established CSR addresses, and these are reserved for various types of devices. The first Mass Storage Control Protocol (MSCP) disk controller has an established and designated address, for instance. Floating CSR space has a specific detection and configuration sequence that allows the host to infer what devices are present, based on the assigned module configuration precedence, and on the numbers of modules present. The floating space and the configuration sequence was intended to allow better use of the available address space; there simply wasn't enough address space to assign unique addresses or even unique primary (fixed) addresses to each Q-bus module.
The secondary and subsequent modules of a particular type are typically within floating CSR space, and various Q-bus module types can have even the first module configured within floating CSR space. Within fixed CSR space, the CSR(s) assigned to one Q-bus module do not affect those assigned to others, except as the settings apply to any similar secondary modules that might be present. Within floating space, the addition or removal of one module commonly requires CSR settings changes on zero or more other modules that might be present within the Q-bus.
In simplest terms, when you add or remove a module within a Q-bus configuration, you must look at the settings for the module you are adding or removing, and at the CSR settings on the other Q-bus modules present within the system. Even within the fixed CSR addresses, you may need to reconfigure one or more Q-bus modules within the floating address space, as you may have one or more controllers configured as a secondary, and you must reconfigure one of these to the fixed address and configure any others to the appropriate secondary CSR addresses within the floating address space.
To determine the required Control and Status Register (CSR) and (if the device requires hardware settings) interrupt vector settings for a specific Q-bus module, you will need access to a MicroVAX or VAX 4000 series console with a CONFIGURE command, or to an OpenVMS VAX system for the SYSGEN utility CONFIGURE command, or other supporting resources.
Systems with the KA630 processor and its console program, and other of the oldest processors, lack this CONFIGURE command and many other useful commands and mechanisms that can found in the consoles of later VAX processors. CONFIGURE is found on the KA640 series, on most KA650 series systems, and on later series. (Details of the KA610, KA620, KA630, KA640, KA650, KA655 and other Q-bus MicroVAX and VAX processors, and the associated MicroVAX and VAX systems, can be found in the OpenVMS FAQ. The KA620 series was an rtVAX, and was not capable of booting OpenVMS VAX.)
Enter the name of each module into the configuration tool, and you will receive a list of the CSR and vector settings. Don't omit Q-bus modules. To repeat: always enter all Q-bus modules present into the Q-bus into configuration tool. Failure to include all modules can and often will result in an incorrect configuration.
If you have a KA630 or similar MicroVAX or VAX processor and thus you don't have access to a console configuration command and you don't have access to the internet to connect into another availabke OpenVMS VAX system, you can install the tape controller and the disk storage controller at the primary addresses, install no other Q-bus modules, and install the processor and memory. This minimal configuration will typically allow you to get OpenVMS VAX installed, and you can then invoke the SYSGEN utility, shut down, and then use the configuration to install the other Q-bus modules.
The interrupt vector configuration step does not apply to Q-bus modules with soft-loaded interrupt vectors, such as those of the DTC05 (M3135) and DTCN5 (M3136) DECvoice modules. The host device driver loads and configures the setting on these modules.
One particular caution around the interrupt vector setting of a Q-bus module: there is no mechanism that allows the console software or the host operating system software to reliably determine and display the interrupt vector setting. The OpenVMS VAX SYSGEN display and other similar tools display the desired interrupt vector setting, and not the actual setting. The only way to reliably determine the interrupt vector setting is to remove the module and decode the vector. This includes both hardware-set and software-set interrupt vector settings; no direct mechanism for accessing and reading in the interrupt vector settings is particularly feasible.
A DIGITAL Q-bus module is uniquely identified by its so-called “M number”. The M number is the letter M (or more rarely, the letters A, G or H), followed by digits. The code is generally stamped onto the handle or onto the spine of the module, or sometimes in the circuit etch. The M number is generally visible when the module is installed, so do look at the end opposite the Q-bus connectors.
As examples of the typical M number, the M3135 code is assigned to the DTC05 DECvoice voice module, and the M3136 is assigned to the DTCN5 DECvoice T1 module.
Using available listings of DIGITAL Q-bus M numbers (such as the FIELD GUIDE TO Q-BUS AND UNIBUS MODULES; check the web and check the newsgroup archives for vmsnet.pdp-11, alt.sys.pdp11 or comp.sys.dec for this or other references), you can translate the code into the device part number. With the device part number, you can then locate documentation and other resources. In particular, you can use the M number or the device part number to locate the documentation for the configuration settings.
The identification of Q-bus modules from other vendors can be equally interesting, though the particular mechanisms can and will differ.
Once you can identify the Q-bus module, you can then locate the documentation associated with the module or (at a minimum) the encoding used for the CSR and (if applicable) interrupt vector switches or jumpers present on the module.
The Q-bus within a MicroVAX or VAX is physically divided into slots, with each slot having four sets of contact fingers. From the top or left edge of the card (as installed into the enclosure) the four fingers are labeled A, B, C and D, respectively. These fingers are then paired together, and are accordingly commonly referred to as the AB and CD slots. You'll also variously find these fingers referenced as slots 1A, 1B (or 1AB), 1C and 1D (or 1CD).
Various Q-bus modules can be dual-width (two sets of fingers, half the total width of the mounting), or quad-width (four sets of fingers, the full width of the mounting), indicating that the module occupies one-half of or all of the Q-bus mounting slot, respectively.
The total number of Q-bus slots present, and the details of the backplane organization can and to vary. The implementation details will depend on the specific Q-bus enclosure, and not on the MicroVAX or VAX processor installed within the system.
There are two basic families of Q-bus enclosures seen with MicroVAX or VAX processors, the older BA23 and BA123 series enclosures, and the BA213, BA215 and BA400-series enclosures in the S-box family. For the purpose of this discussion, the BA23 and BA123 are the first generation of Q-bus enclosures, and the S-box family is the second generation platform. These two families of enclosures differ in the spacing among the Q-bus slots, and in the I/O bulkhead design.
The BA23 and BA123 family use narrower spacing among the modules, and modules requiring external I/O connections will use one or more separately-mounted I/O modules that screw into matching knock-outs located on the system I/O bulkhead. The numbers of slots and the numbers of I/O knock-outs can and do vary by enclosure.
The S-box enclosure family has wider spacing among the modules, and typically has the I/O connection(s) mounted directly on a metal cover over the slot containing the Q-bus module, either integrated and attached to the module as a spine, or attached to the module by one or more cables. The S-box modules are thus more integrated, typically with internal I/O cabling. (There are exceptions to this relative simplicity, as there are Q-bus modules that are interconnected together within the S-box enclosure, for instance.)
S-box modules that require no I/O connections (or that internally interconnect) will use a blank metal cover over the slot. This blank cover maintains the airflow that provides cooling within the enclosure, and helps reduce the level of electromagnetic interference that might radiate out of the system enclosure.
Within the S-box configuration, all Q-bus modules are configured as quad-width modules. Some dual-width modules do exist for the S-box, but will have a quad-width bulkhead. This obviously requires installation into the AB portion of the slot, as well.
Within the BA23 enclosure, the first three slots are wired with the Q-bus through the AB slots, and what is known as the CD interconnect through the CD slots. Starting with the fourth slot, the Q-bus signals are routed from the AB slot to the CD slot, and from there to the CD slot of slot five, and then into the AB slot of slot five, and into the AB slot of slot six. This serpentine pattern continues throughout the remainder of the slots.
Do not install a Q-bus dual module into 1CD, 2CD, or 3CD of the BA23, nor a quad Q-bus module into slots 1, 2, or 3. You will want to place memory modules in these first three slots. You can and should insert a Q-bus dual module or a Q-bus grant card into 3AB, after the last memory module present.
This organization allows the processor (in slot one) to communicate with the I/O devices over the Q-bus, and allows it a path for communications with memory using the CD interconnect and the private memory interconnect (PMI) or Local Memory Interconnect (LMI). Modules communicating using the CD interconnect must be configured contiguously. The Q-bus processor and memory modules must be configured in adjacent slots.
Within the BA23, there exists room for the processor and two memory modules in the first three slots; there are three Q22/CD slots. Within the BA123 enclosure, the first four slots are wired with the Q-bus through the AB portions of each slot, and the Q-bus serpentine pattern starts at slot five; the BA123 has four Q22/CD slots.
Do not install a Q-bus dual module into 1CD, 2CD, 3CD or 4CD of the BA123, nor a quad Q-bus module into slots 1, 2, 3, or 4. You will want to place memory modules in these first four slots. You can and should insert Q-bus dual modules or Q-bus grant cards into 3AB or 4AB, after the last memory module present.
As with the BA23, this organization allows the processor (in slot one) to communicate with the I/O devices over the Q-bus, and with up to three memory modules using the CD interconnect and private memory interconnect (PMI) or local memory interconnect (LMI).
All slots in the S-box series second-generation enclosures are Q22/CD slots
Processor support for PMI/LMI and the CD interconnect can and does vary. The maximum physical memory configurations are also processor-specific.
The Q22 Bus Slot
Each Q-bus (Q22) slot must either have a Q-bus dual- or quad-width module installed, or must have a Q-bus DMA grant continuity card installed.
Quad-width Q-bus modules intended for the first-generation Q-bus enclosures include a Q-bus DMA grant connection for the CD portion of the slot. Q-bus modules intended for the second-generation S-box enclosure do not include this connection, as the CD portion of each slot is reserved for the CD interconnect.
The CD Interconnect Slot
Communications over the CD interconnect require modules be located in adjacent slots. No grant continuity card is required, available, nor permitted. Dual-width Q-bus modules and Q-bus grant continuity modules and quad-width Q-bus modules with the grant continuity jumper built in (Q-bus modules intended for the BA23 and BA123; for installation into any Q22/Q22 slot) should not be inserted in a Q22/CD slot.
A first-generation quad-width Q-bus module should not be inserted into a Q22/CD slot until and unless the bus grant continuity signal trace inherently present in the CD fingers of a quad module is removed. (This case only technically applies to certain bus configurations and slot installations, but is here considered a general recommendation.) Q-bus modules intended to be installed in the second-generation S-box enclosure always lack this trace, as all slots are Q22/CD slots.
If you are developing Q-bus hardware, there is a very rare device around, the Q-bus slot extender.
At its simplest, the slot extender is quad-sized module with a Q-bus slot on one end and Q-bus fingers on the other, and a set of traces that link the fingers to the slots. When inserted into the backplane, it allows a Q-bus card to be mounted above the plane of the other modules. This slot extender can be very useful if you're building or debugging a Q-bus module, assuming the timing and signaling changes caused by the extender don't preclude its use.
This slot extender is not to be confused with the M9400-series and M9401-series bus extender. The bus extender can allow two Q-bus backplanes to be joined, such as the two connected BA23 boxes configured in the so-called Q5 series MicroVAX configurations.
With a Q-bus MicroVAX or Q-bus VAX system, always assume you will need to (re)configure the bus, and that you will need to (re)configure zero or more other existing Q-bus modules whenever you add or remove a Q-bus module.
The Q-bus CSR settings are interdependent, and the addition or removal or even the reconfiguration of one Q-bus module (such as adding a DSSI disk onto the DSSI bus served by a KFQSA Q-bus to DSSI bus storage controller) can require the (re)configuration of zero or more other Q-bus modules present within the bus.
Always assume reconfiguration, until proven otherwise. And to prove otherwise, remove all the Q-bus modules and verify the settings of each.
DMA Continuity, and Hangs
The DMA grant continuity chain is how the Q-bus arbitrates which of the Q-bus DMA-capable modules has access to and can perform DMA operations. (It is also how the Q-bus prioritizes which controller gets first access to the bus and onto the bus arbiter.) Without a correctly configured DMA grant continuity chain, device hangs and whole-system hangs tend to result.
CSRs, and Hangs
The CSR settings are how the host system recognizes the Q-bus devices present. Incorrectly set CSR settings lead to missing or incorrectly identified devices, and to bus (and system) hangs. For devices with soft-loaded interrupt vector settings, the CSR also determines the interrupt vector settings. Mis-set interrupt vectors can also lead to device hangs.
Device Misidentification, and Hangs
If the host operating system misidentifies or does not detect a Q-bus device, or if the host system or a device or Q-bus diagnostic hangs, do check the CSR and interrupt vector settings on all Q-bus modules present, and do ensure the integrity of the Q-bus DMA grant continuity chain.
If the console device configuration tools (if any) or the host system reports phantom devices — one or more console- or host-reported devices that you do not have installed in the Q-bus — then you almost certainly have one or more misconfigured Q-bus CSR settings.
The Small Systems Storage Interconnect (SCSI) provides single- and multi-host operations, and provides initiator to target access; host to disk or to tape widget. It's a storage-access bus. (There were once what would now seem rather weird devices out on SCSI, but these have largely disappeared on SCSI. There were SCSI-connected terminal controllers, for instance. Remnants of these early devices can be found in the SCSI T10 documents.)
Industry Secret: USB and IDE/ATAPI devices use the SCSI protocols. USB and ATAPI are SCSI-based buses. VAX systems pre-date lack both USB and ATAPI devices, though there are SCSI to IDE adapters around that might work.
DSSI multi-host is initiator to target, and initiator to initator. It's a host-to-storage bus and a host-to-host communications bus. (And clustering on all but KFQSA-connected DSSI host adapters allows host-to-host over the DSSI bus.)
For the early product life of MicroVAX and VAX Q-bus systems, the DIGITAL Storage Systems Interconnection (DSSI) bus was the storage choice typically available from DIGITAL. While the then-current SCSI-1 bus was about the same performance as the DSSI storage bus, DSSI provided dual- and triple-host support, SCS and MSCP capabilities, and a number of other capabilities well beyond SCSI. Accordingly, SCSI connectivity was a comparatively late feature in Q-bus configurations. (Some of the capabilities found in DSSI still do not exist in SCSI. Ever SET HOST into a disk controller to directly adjust its settings?)
Typical Q-bus SCSI storage configurations involve non-DIGITAL Q-bus controllers (usually emulating a Q-bus MSCP controller, and interfacing directly with SCSI disks), the few SCSI devices that can be connected via DIGITAL KZQSA Q-bus to SCSI, or a combination of the DIGITAL KFQSA Q-bus to DSSI controller and an DIGITAL HSD-series DSSI to SCSI adapter.
The KZQSA controller reportedly only occasionally worked with its contemporary SCSI disks, but was not known for widespread compatibility. Original DIGITAL Systems and Options Catalog (SOC) documentation only indicated and only claimed specific SCSI CD-ROM devices and specific SCSI tapes function with the KZQSA. Compatibility with SCSI disks was explicitly not claimed for the KZQSA.
With the retirement of DSSI gear, the KFQSA and the HSD-series controller, or the processor-embedded DSSI adapter (found on later-generation VAX processors) and the HSD-series controller, were the SCSI storage configurations commonly seen on the later-generation MicroVAX and VAX series systems.
Given the vintage of this gear and given the vintage of the contemporary SCSI interfaces, you should not expect to be able to successfully connect an UltraSCSI storage device to a Q-bus.