The VAX architecture design imposes certain very stringent requirements on the design of VAX buses and peripherals. Namely, the main bus(es) of a VAX, i.e., the bus(es) coming out of the CPU (or to which CPUs are attached in a system designed for SMP) must be special VAX bus(es). In order to be usable as a VAX main bus, a bus must completely match the VAX architecture specification in its addressing model, interrupt model, and all other aspects.
The only devices that can be attached directly to VAX main buses and
appear in the VAX native 32-bit address space are the so-called
"nexi" (singular "nexus").
A nexus is different from an "ordinary" device in that it does things
that are above and beyond what one can reasonably expect from an
"ordinary" device, things to ensure that it meets all requirements of
the VAX way of doing things
and the specific VAX implementation it is
attached to.
Among other things, a nexus must perform paged memory mapping that parallels
the virtual-to-physical address translation performed by the VAX CPU on every
memory reference.
All nexi can be divided into two general categories: bus adapters and peripherals. Originally all nexi were bus adapters attaching "ordinary" buses to the VAX main bus, and all peripherals were attached to these "ordinary" buses. This way all peripherals could be designed as ordinary devices and not have to worry about the nexus magic. As the performance demands increased, it became attractive to attach peripherals directly to the VAX main bus. In order to maintain the VAX architecture design, these peripherals were designed as nexi.
In both cases each actual peripheral has a nexus standing in front of it. This requirement of the VAX architecture design is called the two-layer bus structure. A VAX must comply with this requirement in order to be called a VAX. VAXen that do not comply with this requirement will hereafter be called poor man's VAXen. DEC originally defined the term MicroVAX to refer to such a VAX, and indeed many MicroVAXen are poor man's VAXen, but the Quasijarus Consortium discourages such use of this term, since many other MicroVAXen actually do comply with the two-layer bus structure requirement. See below.
With no exceptions, all VAXen ever made can be grouped into four major classes: the Big 4, BI/XMI VAXen, the VAX/Alpha hybrid, and MicroVAXen. This grouping is based on technical similarities and differences, not on any DEC marketing ideology.
This is the original VAX-11 series, i.e., VAX-11/780 (Star), VAX-11/750 (Comet), VAX-11/730 (Nebula), and last but not least, Venus, which should have been named VAX-11/790, but was unfortunately given the inappropriate and confusing name VAX 8600.
All Big 4 VAXen are architectured around a central SBI or SBI-like bus (SBI and its clones are specifically designed as VAX main buses) with UNIBUS, MASSBUS, and CI adapters hanging off of it. All of these adapters are nexi. The Big 4 VAXen have not been designed for symmetric multiprocessing.
BI/XMI VAXen are all VAXen that are architectured around one or more VAXBI or XMI buses. These buses appear in the VAX native 32-bit address space and qualify as VAX main buses. In fact, they have been specifically designed as VAX main buses. This means that BI and XMI nodes (devices attached to BI and XMI buses) are nexi. These nexi can be either UNIBUS adapters or actual peripherals. All BI/XMI VAXen are designed with symmetric multiprocessing in mind, although all of them can be configured with only one CPU if desired.
All 8000 series VAXen except the misnamed 8600 are BI VAXen, having one or more BI buses. The VAX 6000 platform is architectured around one XMI bus, with CPUs, memory modules, VAXBI adapters, and peripheral XMI devices attached to it. VAX 9000 can have up to 4 XMI buses. The Quasijarus Consortium presently doesn't have any more information on VAX 9000.
One of DEC's most horrifying developments is the DEC 7000/10000 platform and the VAX 7000/10000 system based on it. The main bus of the DEC 7000/10000 platform is called LSB. LSB is decidedly not a VAX bus, instead, it is an Alpha bus. Despite LSB being an Alpha bus not suited for VAX use, DEC has built a VAX CPU module (KA7AA) and an XMI adapter for it. XMI is a VAX bus, thus a VAX 7000/10000 system with one or more KA7AA CPUs and one or more XMI adapters looks to an unsuspecting innocent user as a normal BI/XMI VAX. However, it is definitely not one. Although both the CPUs and the I/O devices are VAX, they have a decidedly non-VAX bus (LSB) standing between them.
The consequences of this design are devastating. Being an Alpha bus and not a VAX bus, LSB lacks the addressing model or semantics of a VAX bus, making it impossible to attach a VAX bus to LSB with a bus adapter that allows the VAX bus to be addressable from LSB. The LSB-to-XMI adapter does not allow LSB CPUs to address the XMI bus. No XMI device is directly addressable by an LSB CPU, whether Alpha or VAX. This fact alone makes it impossible to adapt the normal VAX 6000/9000 XMI code in a normal VAX OS to DEC 7000/10000. DEC 7000/10000 XMI would most probably have to be supported by totally different code, with only a small fraction of all XMI devices supported.
The VAX incompatibility of DEC 7000/10000 XMI is not the only problem. The console, the SMP model, and all system registers are completely alien too. This makes it impossible to run a normal VAX OS on VAX 7000/10000 at all. 4.3BSD-Quasijarus will never run on VAX 7000/10000. The only kind of OS one can practically hope to run on VAX 7000/10000 is an OS that supports both VAX and Alpha, supports DEC 7000/10000 with Alpha CPUs, and has a very peculiar internal design that allows some Alpha constructs and code to be used by the VAX version. VMS is one such OS. Unfortunately, it is very unlikely that any version of UNIX will ever run on VAX 7000/10000.
For what it's worth, DEC 7000/10000 is designed with symmetric multiprocessing in mind, but can be configured with only one CPU if desired.
For the Quasijarus Consortium's official definition of a MicroVAX, see Quasijarus Consortium Official VAX Terminology. Basically, all VAXen smaller than an 8200 or a 6000 are MicroVAXen. All machines that DEC named MicroVAXen or VAXstations are MicroVAXen in the Quasijarus Consortium definition, but some machines that DEC named VAXen (namely, all 4000s) are also MicroVAXen in the Quasijarus Consortium definition.
According to the information currently available to the Quasijarus Consortium, there are four subclasses of MicroVAXen: Q22-bus MicroVAXen, DSSI MicroVAXen, BabyVAXen, and Firefox.
KA610 aka KD32 was the first Q22-bus MicroVAX made. It is also the worst VAX ever made. This is because it violates the two-layer bus structure requirement (see above). KA610 aka KD32 is the only Q22-bus MicroVAX on which there is no bus adapter or any other kind of nexus standing between the CPU and the Q22-bus devices. KA610 aka KD32 uses the Q22-bus as its VAX main bus and Q22-bus memory as main memory. Among other horrible things, this means that the main memory is limited to 4 MB and that no scatter-gather DMA is possible.
KA630 and all higher Q22-bus MicroVAXen are much better. They implement the VAX architecture requirement of a two-layer bus structure as follows. Architecturally they have a CPU-native main bus, but it is confined within the CPU board. This bus has a Q22-bus adapter attached to it, which provides the Q22-bus, the only bus to leave the CPU board. This adapter is a nexus. On some Q22-bus MicroVAXen the Q22-bus adapter is the only device attached to the internal main bus. Other Q22-bus MicroVAXen also have on-board Ethernet and DSSI interfaces attached to it. On KA660 and higher these interfaces are nexi. On KA640 they are ordinary devices, making KA640 a poor man's VAX in this area. They can only do DMA to their own fixed static RAM buffers.
Q22-bus MicroVAXen have not been designed for symmetric multiprocessing.
Once upon a time DEC has built a series called VAXft, which used a combination of special hardware and VMS software to achieve fault tolerance. According to the information currently available to the Quasijarus Consortium, the building blocks of this series were hacked MicroVAXen. Among other hacks, they took the design of newer Q22-bus MicroVAXen (those with on-board DSSI and Ethernet interfaces) and removed the Q22-bus adapter, leaving only DSSI and Ethernet.
Too little is known about these hacked MicroVAXen to classify them as uniprocessor or multiprocessor.
KA410, KA42/41, and KA43 BabyVAXen are strictly poor man's VAXen. They only have an internal bus confined within the system board and no expansion buses of any kind. The devices on the internal bus include serial ports, an SMC HDC9224 MFM controller, an NCR 5380 SCSI interface, and a LANCE Ethernet interface. The mass storage controllers can only do DMA to a fixed static RAM buffer, and the Ethernet interface can do DMA to main memory, but not scatter-gather.
According to the information currently available to the Quasijarus Consortium, KA44 through KA49 are very similar to the above three. They also have LANCE Ethernet, but the SCSI interface uses NCR 53C94. It is not currently known how is the 53C94 attached to the internal bus and what are its DMA capabilities, if any.
KA52 is the only BabyVAX resembling a real VAX. It has a Q22-bus interface similar to that of Q22-bus MicroVAXen and DEC shipped KA52 systems with a DSSI daughterboard using the same SHAC chip used on newer Q22-bus MicroVAXen. It is not currently known whether this daughterboard is also usable on KA50 or not.
BabyVAXen have not been designed for symmetric multiprocessing.
The information available so far to the Quasijarus Consortium suggests that Firefox is architectured around a proprietary bus called the M-bus, and that the devices one can have attached to the M-bus are similar to those found on BabyVAXen. There is also a Q22-bus adapter available for it, and it is reportedly compatible with that used on W22-bus MicroVAXen.
Firefox is a multiprocessor system with either 2 or 4 CPUs. There are two CPUs per board, making a uniprocessor configuration impossible.
For the definitions of the terms used, see Quasijarus Consortium Official VAX Terminology.
@(#)overview.html 1.1 03/12/18
Michael Sokolov
[email protected]