As shown in the VAX Overview and Classification, there are three general classes of VAXen: the Big 4, BI/XMI VAXen, and MicroVAXen, and three general classes of VAX buses and peripherals: UNIBUS and MASSBUS on the Big 4, BI and XMI on BI/XMI VAXen, and Q-bus and non-Q-bus devices on MicroVAXen.
Since 4.3BSD was developed on the Big 4, all of its VAX hardware support code centers around these two buses. The BI-to-UNIBUS adapter and MicroVAX Q-bus are sufficiently close to the UNIBUS adapters on the Big 4 to be fully supported by the existing code as well. The areas that need to be worked on thus are BI and XMI peripherals and MicroVAX on-board devices.
BI and XMI peripherals include communication controllers, network interfaces, MSCP ports, and CI and DSSI cluster interfaces. For the last two, see MSCP and Cluster Interfaces. Communication controllers exist only on BI and are the simplest BI peripherals. Ethernet network interfaces exist both on BI and on XMI. There is only one Ethernet board for XMI, the DEMNA, and its programming interface is not based on GVP (see below). There are several different BI boards featuring Ethernet ports, but they are all different versions of the DEBNx platform. Some of these versions have an Ethernet port with a programming interface identical to that of DEMNA, others have an Ethernet port with a programming interface based on BVP, a form of GVP (see below).
All of these devices are supported by Ultrix V4.2, for which the IFCTF has the full sources. All of this support will eventually be integrated into 4.3BSD-Quasijarus, but some hardware documentation and test hardware will be needed.
The real gap is in the area of support for devices on MicroVAX CPU boards that are connected directly to the CPU without any intervening bus. None of them are currently supported, and supporting them would take some work. In most cases developing this support requires the technical manual for the CPU on which the devices in question are found. The MicroVAX on-board devices can be generally classified as BabyVAX serial ports, Ethernet interfaces, and mass storage devices. Supporting the first will be an integral part of supporting the BabyVAX CPUs themselves, while the other two deserve more consideration.
The first Ethernet interface to be put on MicroVAX CPU boards was AMD LANCE. The information currently available to the Quasijarus Consortium suggests that there are two or more significantly different ways LANCE can be attached to a MicroVAX CPU. It will be necessary to examine the similarities and differences between LANCE Ethernet interfaces on different CPUs in order to decide on how to approach their support.
AMD LANCE was later replaced by DEC SGEC, Second Generation Ethernet Chip, a special DEC IC that connects directly to the CDAL bus on CPU boards without any intervening glue logic. SGEC's programming interface is documented in KA660 and KA670 technical manuals.
Generally there are three kinds of mass storage devices found on MicroVAX CPU boards: MFM disk controllers, SCSI interfaces, and DSSI interfaces.
The only MFM controller ever used on MicroVAXen is SMC HDC9224 on KA410 BabyVAX. It is the same chip that the RQDX3 MSCP-to-MFM controller is based on, and MFM disks are interchangeable between RQDX3 and KA410. Since RQDX3 is an MSCP controller, this has certain implications for the RQDX3/KA410 disk format and the design of the MFM driver. See MSCP and Cluster Interfaces.
Over the time there have been three different SCSI interfaces used on MicroVAX CPUs: NCR 5380, NCR 53C94, and DEC SII. Some thought will have to be given to the design of the SCSI support subsystem. See SCSI.
The SII is particularly interesting because it can act both as a SCSI controller and a DSSI controller. Fred van Kempen says that selection of SCSI or DSSI mode is done in software.
For DSSI purposes the SII was later replaced with SHAC (Single Host Adapter Chip), a special DEC IC that connects directly to the CDAL bus on CPU boards without any intervening glue logic. The main difficulty with supporting SHAC and SII in DSSI mode is not the MicroVAX-specific part, but the general code framework for handling MSCP and cluster interfaces. See MSCP and Cluster Interfaces.
As shown in the VAX Overview and Classification, for performance reasons newer VAX implementations have peripherals attached directly to the VAX main bus and acting as nexi. Given all the VAX magic a nexus has to do, designing a peripheral nexus is no easy task. GVP is one of DEC's efforts to simplify it. GVP is a mechanism allowing peripheral nexi of arbitrary functional purpose to perform their nexus magic in a uniform way and concentrate on their useful functions. GVP is rather general and does not prescribe a fixed device register format. There is also a variant called BVP (BI VAX Port) which defines four standard longword registers.
All CI and DSSI cluster interfaces except SII use GVP. One version of the BI Ethernet port uses BVP. There is also a version of MSCP defined that uses BVP, called BVP Storage System Port (BVP SSP). It is used by BI TK50 and TK70 ports. See MSCP and Cluster Interfaces.
The use of GVP is optional. GVP makes it easier to design a peripheral nexus, but one can design a peripheral nexus without GVP just as well. BI and XMI MSCP ports that are adaptations of UQSSP (see MSCP and Cluster Interfaces) do not use GVP, nor does DEMNA or its BI equivalent, but they are all still fully compliant peripheral nexi.
GVP is completely based on VAX virtual addresses, meaning that a peripheral nexus implementing GVP must implement the full VAX memory management, as described in the VAX Architecture Reference Manual. GVP is also heavily based on the self-relative queue instructions (INSQHI, INSQTI, REMQHI, and REMQTI), which operate on special interlocked queues designed for interprocessor communication in a multiprocessor system (see the VAX Architecture Reference Manual for more information). In fact, these instructions were specifically added to the VAX architecture for use in GVP.
It is noted above that MicroVAX Q-bus is sufficiently close to UNIBUS on big VAXen to share the same code. This is only true for KA630 and higher. KA610 aka KD32 (MicroVAX I) uses Q22-bus as its VAX main bus. Although it would be possible in theory to support it the same way other non-scatter-gather-DMA devices are supported, i.e., by allocating fixed physical memory buffers at boot time and bcopying data between these buffers and user memory, this would take a lot of work, swell the code significantly, and in the end support only a tiny portion of all Q-bus devices. The Quasijarus Consortium will not do this. BSD UNIX will never run on MicroVAX I. This is a policy.
@(#)buses.html 1.1 03/12/18