From: CSBVAX::MRGATE!RELAY-INFO-VAX@CRVAX.SRI.COM@SMTP 2-SEP-1988 18:48 To: ARISIA::EVERHART Subj: WARNING -- VAX 3xxx family Qbus differences Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Fri, 2 SEP 88 14:40:36 PDT Received: from CUNYVM.CUNY.EDU by KL.SRI.COM with TCP; Fri, 2 Sep 88 14:17:07 PDT Received: from phast.phys.washington.edu by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 8545; Fri, 02 Sep 88 17:06:48 EDT Date: Fri, 2 Sep 88 14:05 PDT From: SEYMOUR%phast.phys.washington.edu@CUNYVM.CUNY.EDU Subject: WARNING -- VAX 3xxx family Qbus differences To: info-vax@kl.sri.com X-VMS-To: IN%"info-vax@kl.sri.com" Well, my first VAXstation 3200 just arrived -- with a cover letter: (any emphasis is DEC's, not mine. The ellipses (...) are mine.) (i've moved the "tech notes" to inside the body){are my contractions} [things in brackets are rewordings for brevity] "uVax"=microVax ============================================================ Attn: Non-Digital Device Users microvax II. ... impact system functioning IF AND ONLY IF you intend to use non-Digital peripherals, Q-bus devices or device drivers. Microvax 3xxx Tech Note 1: Multiple successive writes to the Q-bus Map Registers can lock out Q-bus DMA transfers in a way which can cause device DMA Timeouts. Device driver software can avoid this condition by using the Q-bus Map Register calls provided by Digital's operating systems or by performing either an I/O Space access or a memory write between successive Q-bus Map Register writes. --------------------------------- The second difference impacts Q-bus devices which can drop their interrupt requests before they are serviced. It also impacts any device driver which can cause a device to drop its interrupt request before the request is serviced. If you have a non-Digital device or driver, insure it complies with Tech Note 2. Non-compliance could result in undetected data corruption. Tech Note 2: When a uVax 3xxx responds to an interrupt while executing a POLY instruction, it aborts that instruction, reads the interrupt vector (via Qbus interrupt acknowledge cycle) and passes control to the interrupt service routine. On exiting from the service routine (via an REI instruction), it restarts the POLY instruction. If there is no response to the interrupt acknowledge cycle on the Qbus, then the POLY instruction will be skipped (i.e. never executed). [This no-response condition] is called a passive release. The uVax 3xxx will produce incorrect data if a passive release coincides with execution of a POLY instruction ... Impact on devices: The uVax 3xxx does not support any Q-bus device which can, independent of being cleared by its software driver, drop its interrupt request without responding to the ensuing interrupt acknowledge cycle. Such behavior, known as a transparent hardware initiated passive release {THIPR}, is not allowed by the Qbus Specification. However, past processors have tolerated this type of operation more gracefully. THIPRs are a common operation for many UNIBUS devices. Therefore, such devices should not be connected to this system via a Qbus to UNIBUS adapter. Impact on drivers: [a device driver clearing an interrupt enable bit might trigger a software initiated passive release, so don't clear an Interrupt Enable bit unless] 1. The device driver clears the interrupt enable condition only when that device has no interrupts pending. 2. A device driver instruction that clears a device's interrupt enable condition must be followed by at least one device register read access before the driver returns control to program code which could execute a POLY instruction. ------------------ The third difference impacts the small number of Qbus devices which can perform Qbus DMA DATIO cycles. The occurrence of DMA DATIO cycles on the uVax 3xxx could result in data corruption. Therefore such operation is not supported. The Digital-supplied DRv1W has a mode of operation which can generate DMA DATIO cycles if instructed to do so by the non-Digital hardware to which it is attached. This mode is not supported on the uVax 3xxx. Normal DRv1W input and output transfer operation is fully supported. If you are using 3rd party peripherals, you need to contact the supplier to receive certification that their devices and device driver software meet the specification of this system, as outlined above, and in the Tech notes. Installation and operation of a device is not sufficient, in that violation of the 2nd and 3rd items above can produce infrequent undetected data corruption. For customers with devices which are non-compliant and which cannot be made compliant, future Field Change Orders (FCO's) will remove these specification differences. For customers needing additional information, please contact the US Area Customer Support Center (1-800-DEC-8000) or your local field service representative. Your Digital-supplied hardware and software compply with these specs. ================================================================ (end of DEC letter)(the leter did NOT have a DEC document number) So, Info-VAXers, DAARC-siders and Info-CAMACers, does a BiRa MBD-11 perform THIPR's? Does its RDH/WDR cycle appear as a DATIO? It looks like it's about to be scope-the-bus week! Do any 3rd party OEMs on this net know if their devices will or will not work on the current 3xxx family? (Truth now generates better customer relations than boards shipped back later!) I've got MDB's Qbus-to-UNIBUS converter, Aviv Qbus tape and disk controllers, UNIBUS Datasystems Corp. LP-11 card, and will probably be adding weird things for the rest of the systems' lives. Send to me and i'll summarize to the net, or post to the net directly. Or both. -- dick seymour seymour@uwaphast.bitnet 206-543-4298