=;The OpenVMS Frequently Asked Questions (FAQ)D

The OpenVMS Frequently Asked Questions (FAQ)



 r \ ^  
PreviousContentsIndex

p

14.6 Where can I get more information on Alpha systems?



1HP operates an AlphaServer information center at:



>Alpha Technical information and documentation is available at:



CSoftware Product Description (SPD) information, including platform support documentation:



/Information on Multia hardware is available at:



8Information on DEC 3000 series hardware is available at:



The NetBSD5 folks maintain useful Alpha hardware information at:

{

14.7 Describe Alpha instruction emulation and instruction subsets?



EThe Alpha architecture is upward- and downward-compatible, and newer Hinstructions are emulated on older platforms, for those cases where the =compiler is explicitly requested to generate the newer Alpha instructions.

DIn particular, OpenVMS Alpha V7.1 and later include the instruction Bemulation capabilities necessary for the execution of newer Alpha Dinstructions on older Alpha microprocessors. (Instruction emulation Gcapabilities are available for user-mode application code, and are not ?available to device drivers or other similar kernel-mode code.)

DAlpha instructions are available in groups (or subsets). Obviously, Athere is the base instruction set that is available on all Alpha Amicroprocessors. Then, the following are the current instruction Dextension groups (or subsets) that are available on some of various recent Alpha microprocessors:



FThe typical instruction subset that provides the biggest win---and of Fcourse, your mileage may vary---is typically the instruction set that ?is provided by the EV56 and later; specifically, the byte-word =instruction subset. To select this subset, use the following:

 

"
)/ARCHITECTURE=EV56/OPTIMIZE=TUNE=GENERIC 




CThe /ARCHITECTURE controls the maximum instruction subset that the Hcompiler will generally use, while the /OPTIMIZE=TUNE controls both the Hinstruction-level scheduling and also the instructions generated inside Floops---any code resulting from /OPTIMIZE=TUNE that is specific to an Hinstruction subset will be generated only inside loops and will also be G"protected" by an AMASK-based test that permits the executionE of the proper code for the particular current Alpha microprocessor.

GTypically /OPTIMIZE=TUNE=GENERIC is the appropriate choice for tuning, Band the /ARCHITECTURE selects the minimum target architecture for *general use throughout the generated code.

Fgenerated for later architectures and instruction subsets will run on Dolder Alpha systems due to the emulation, but if /ARCHITECTURE is a Gsignificant benefit, then the emulation might be a performance penalty.

DPlease see the OpenVMS Ask The Wizard area for the source code of a F(non-privileged) tool that looks at the instruction subsets available Eon the particular Alpha microprocessor that the tool is run on. This Ftool demonstrates the use of the Alpha AMASK and IMPLVER instructions.

Please see Section 10.22 and Section 14.9 for additional details and related considerations.g

14.8 So how do I open up the DEC 3000 chassis?



EAfter removing those two little screws, tilt the back end of the top ,shell upwards---then you can remove the lid.U

14.9 What is byte swizzling?



H"Swizzling" is the term used to describe the operation needed Dto do partial longword (i.e. byte or word) accesses to I/O space on Gthose systems that don't support it directly. It involved shifting the Coffset into an address space by 5 (or 7 for one older system), and CORing this into the base address. It then required the size of the -operation to be ORed into the low order bits.

EThat is, because the EV4 and EV5 CPUs did not bring bits 0 and 1 off Gthe chip, to do programmed I/O for bytes/words, the information on the Hsize/offset of the transfer was encoded into the address data. The data Ditself then had to be shifted into the correct "byte lane"?; into the required offset position within a longword transfer;

EThe EV56 microprocessor supports byte/word instruction references in Gmemory space, however only specific EV56 systems can support byte/word Baccesses into I/O space; device drivers may or may not be able to Gutilize to byte/word instructions to access device registers. Further, Deven on an EV56 system with hardware support for byte/word accesses Ginto I/O space, the relevant OpenVMS routines typically do not support byte/word access into I/O space.

GSystems based on the EV6 microprocessor (with the salient exception of Bthe AlphaServer GS60 and AlphaServer GS140 series, for reasons of Cplatform compatability) support a flat, byte addressable I/O space.

9If a device driver uses CRAM or IOC$WRITE_IO/IOC$READ_IO,Gthen OpenVMS will correctly process the swizzling requirements without Erequiring changes the driver; OpenVMS will transparently swizzle and Hunswizzle the I/O space references, if needed for the particular target Gplatform. (Access and use of these routines may or may not be feasible Awithin the requirements for a particular device driver, with the Hdecision typically based on the target performance requirements and the Hexpected frequency of device references and thus the expected frequency -of calls to these or other similar routines.)

HTo use byte/word operations on MEMORY, you need to tell the compiler to >use the EV56 or EV6 architecture (/ARCHITECTURE=EV56). Memory Hoperations did not swizzle, but the compiler would do long/quad access, Dand extract/insert bytes as needed. Using /ARCHITECTURE=EV56 allows 9smaller, more efficient byte/word access logic to memory.

EIf the application is directly referencing I/O space access across a Arange of Alpha systems such as is done with the X Windows device Gdrivers, then the driver will need to know how to do swizzling for old Eplatforms, and byte access for new platforms. Device drivers for new Fgraphics controllers can specifically target and specifically require Gplatforms based on EV6 and later Alpha microprocessors because of this requirement, for instance.

Please see Section 10.22 and Section 14.7 for additional details and related considerations.p

14.10 What is the layout of the VAX floating point format?



CThe VAX floating point format is derived from one of the PDP-11 FP Hformats, which helps explain its strange layout. There are four formats Hdefined: F 32-bit single-precision, D and G 64-bit double-precision and EH 128-bit quadruple precision. For all formats, the lowest addressed F16-bit "word" contains the sign and exponent (and for other Ethan H, some of the most significant fraction bits). Each successive Ghigher-addressed word contains the next 16 lesser-significant fraction Bbits. Bit 15 of the first word is the sign, 1 for negative, 0 for Gpositive. Zero is represented by a biased exponent value of zero and a Dsign of zero; the fraction bits are ignored (but on Alpha, non-zero Cfraction bits in a zero value cause an error.) A value with biased Aexponent zero and sign bit 1 is a "reserved operand" - Ftouching it causes an error - fraction bits are ignored. There are no 1minus zero, infinity, denormalized or NaN values.

HFor all formats, the fraction is normalized and the radix point assumed Gto be to the left of the MSB, hence the following range: 0.5 less than Aor equal to f and less than 1.0. The MSB, always being 1, is not Gstored. The binary exponent is stored with a bias varying with type in 'bits 14:n of the lowest-addressed word.

 

"
<  FP      Exponent    Exponent    Mantissa (Fraction) bits, 9  Type      Bits        Bias        including hidden bit =  ========================================================== -   F         8           128              24 -   D         8           128              56 -   G        11          1024              53 -   H        15         16384             113 




EThe layout for D is identical to that for F except for 32 additional fraction bits.

CExample: +1.5 in F float is hex 000040C0 (fraction of .11[base 2], biased exponent of 129)i

14.11 Where can I find more info about VAX systems?

s

14.12 Where can I find information on NetBSD for VAX systems?



.Gunnar Helliesen maintains a NetBSD VAX FAQ at

|

14.13 What system disk size limit on the MicroVAX and VAXstation 3100?



CSystem disks larger than 1.073 gigabytes (GB)---1fffff hexidecimal Hblocks -- are not supported on any member of the VAXstation 3100 series Fand on certain older members of the MicroVAX 3100 series, and are not Hreliable on these affected systems. (See below to identify the affected Fsystems---the more recent members of the MicroVAX 3100 series systems are NOT affected.)

FVarious of the SCSI commands used by the boot drivers imbedded in the console@PROM on all members of the VAXstation 3100 series use "Group 0" Gcommands, which allow a 21 bit block number field, which allows access Fto the first 1fffff hexidecimal blocks of a disk. Any disk references Epast 1fffff will wrap---this wrapping behaviour can be of particular Ginterest when writing a system crashdump file, as this can potentially Flead to system disk corruptions should any part of the crashdump file be located beyond 1.073 GB.

CMore recent systems and console PROMs use "Group 1" SCSI commands, (which allow a 32 bit block number field.

EThere was a similar limitation among the oldest of the MicroVAX 3100 Hseries, but a console boot PROM was phased into production and was made Havailable for field retrofits---this PROM upgrade allows the use of the D"Group 1" SCSI commands, and thus larger system disks. There was no 4similar PROM upgrade for the VAXstation 3100 series.

(Systems that are affected by this limit:



Also see



9Also see Section 9.5.d

14.14 What are the VAX processor (CPU) codes?



 

"
   CPU:    Platform:    -----   --------- *   KA41-A : MicroVAX 3100 Model 10 and 20 +   KA41-B : VAXserver 3100 Model 10 and 20    KA41-C : InfoServer ,   KA41-D : MicroVAX 3100 Model 10e and 20e -   KA41-E : VAXserver 3100 Model 10e and 20e ,   KA42-A : VAXstation 3100 Model 30 and 40 ,   KA42-B : VAXstation 3100 Model 38 and 48 %   KA43-A : VAXstation 3100 Model 76 *   KA45   : MicroVAX 3100 Model 30 and 40 %   KA46   : VAXstation 4000 Model 60 #   KA47   : MicroVAX 3100 Model 80     KA48   : VAXstation 4000 VLC )   KA49-A : VAXstation 4000 Model 90/90A %   KA49-B : VAXstation 4000 Model 95 %   KA49-C : VAXstation 4000 Model 96 #   KA50   : MicroVAX 3100 Model 90 #   KA51   : MicroVAX 3100 Model 95    KA52   : VAX 4000 Model 100    KA53   : VAX 4000 Model 105    KA54   : VAX 4000 Model 106 #   KA55   : MicroVAX 3100 Model 85 #   KA56   : MicroVAX 3100 Model 96    KA57   : VAX 4000 Model 108 #   KA58   : MicroVAX 3100 Model 88 #   KA59   : MicroVAX 3100 Model 98    KA85   : VAX 8500    KA86   : VAX 8600    KA88   : VAX 8800 '   KA600  : VAX 4000-50 (aka VAXbrick) 0   KA610  : MicroVAX I, VAXstation I (aka KD32)    KA620  : rtVAX (VAXeln)    KA62A  : VAX 6000-200    KA62B  : VAX 6000-300 '   KA630  : MicroVAX II, VAXstation II )   KA640  : MicroVAX 3300, MicroVAX 3400 H   KA650  : VAXstation 3200, MicroVAX 3500, MicroVAX 3600, MicroVAX III    KA64A  : VAX 6000-400 8   KA655  : MicroVAX 3800, MicroVAX 3900, MicroVAX III+    KA65A  : VAX 6000-500 (   KA660  : VAX 4000-200, VAX 4 upgrade    KA66A  : VAX 6000-600    KA670  : VAX 4000-300    KA675  : VAX 4000-400    KA680  : VAX 4000-500    KA681  : VAX 4000-500A    KA690  : VAX 4000-600    KA691  : VAX 4000-605A    KA692  : VAX 4000-700A    KA693  : VAX 4000-605A    KA694  : VAX 4000-705A    KA730  : VAX-11/730    KA750  : VAX-11/750 #   KA780  : VAX-11/780, VAX-11/782    KA785  : VAX-11/785    KA7AA  : VAX 7000-600    KA7AB  : VAX 7000-700    KA7AC  : VAX 7000-800    KA800  : VAXrta    KA820  : VAX 8200, VAX 8300    KA825  : VAX 8250, VAX 8350    KA865  : VAX 8650 




FFor console commands associated with certain MicroVAX 3100 series and @VAX 4000 model 10x series motherboard personality settings, see 4Section 14.32.w

14.15 Where can I get software and hardware support information?



<Please contact the HP Customer Support Center. Services and Ginformation, manuals, guides, downloads, and various other information %is available via the support link at:



:Various hardware and system documentation is available at:



CTSM (Terminal Server Manager), DEChub, DECserver, etc. information:



FThe owner and maintainer of current DECserver and related hardware is &DIGITAL Network Products Group (DNPG):

z

14.16 Where can I get hardware self-maintenance support assistance?



FThe HP Parts Directory and the HP Parts Reference Guide (arguably the Dmost direct descendents of the HP Assisted Services program, of the CCompaq Assisted Services program, and of the now-ancient DECmailer Dprogram) are available to customers that wish to maintain their own Hsystem(s) (self-maintenance), but that wish some level of assistance in Hacquiring specific parts, hardware diagnostics and hardware manuals for Gthe system(s), and that wish to have access to spares and module-level 5repairs for customer-performed hardware module swaps:



FThe HP Parts Reference Guide replaces the CAS-Catalog and DAS-Catalog %parts catalogs and related resources.

DDetails of the available self-maintenance programs and services can Avary by geography and by the particular services channel(s), and ;current program specifics are available via the above URLs.}

14.17 Why does my system halt when I power-cycle the console terminal?



AVarious VAX and Alpha consoles are designed to process the BREAK &signal, treating it as a HALT request.

>A BREAK is a deliberately-generated serial line framing error.

EWhen a serial line device such as a terminal powers up (or sometimes Bwhen powering down) it can generate framing errors. These framing 0errors are indistingushable from a BREAK signal.

BWhen a BREAK is received on a serial line console for various VAX Hsystems---including most VAXstation, MicroVAX, and VAX 4000 series---it Bis typically interpreted as a HALT. Alpha systems will also often 9process a BREAK in a similar fashion, halting the system.

?There is no uniform or generally-available way to disable this ?behaviour on every VAX or Alpha system. On some systems, BREAK Dprocessing can be disabled in favor of [CTRL/P], or [CTRL/P] is the only way to halt the processor.

GThe most common way to avoid these halts is to disable the serial line Dconsole or to simply not power-cycle the console terminal. There is Ecertain important system state information that is displayed only on Athe console, OpenVMS expects to always have access to the system console.

9Also see Section 5.6.t

14.18 Can I reuse old keyboards, mice and monitors with a PC?



COlder HP keyboards (those with the DIGITAL logo and the RJ modular Cjacks), older HP mice (those with the DIGITAL logo and with the RJ Dmodular jacks, or with a DIN connector with pins in a configuration Eother than the PC-standard DIN connector pin orientation), and older Avideo monitors (with RGB synch-on-green video signaling) all use signaling@formats and/or communications protocols that differ from the PC Gstandards, and are not (easily) interchangable nor (easily) compatible Cwith typical PC peripheral device controllers. The LK201 and LK401 Ekeyboards, the VSXXX series mice, the VR260 and VR290 monitors, etc.,Aare incompatible with most PC systems and with most KVM switches.

ENewer HP (and Compaq) keyboards (those with with PC-style DIN plugs, Dand the HP, Compaq or DIGITAL logo), newer HP mice (with PC-pin DIN Eplugs, and the HP, Compaq or DIGITAL logo), and newer video monitors 7(multi-synch, usually with a VGA or SVGA connection, orFlater) are often interchangeable with "industry standard" PC systems, Band can often be used with most PC peripheral device controllers. CLK461, LK463, LK46W, LK471, PC7XS-CA, VRC16, VRC21, TFT-series LCD Dflat-panel displays, etc., are typically reasonably compatible with Hmost PC systems, and will usually perform as expected within the limits of the hardware.>(For details of CRT and LCD display compatibility, please see 3Section 14.19.)

HRule of thumb: if the peripheral device component was sold for use with Ethe DEC 2000 (DECpc 150 AXP), an AlphaServer series, an AlphaStation Gseries, or a more recent Alpha system, it will probably work with a PC Aperipheral controller or with a PC-compatible KVM switch. If the Dperipheral device component was sold for use with an VT420 or older Gterminal, most VAX, most VAXstation, and most Alpha systems with names Fin the format DEC [four-digit-number], it probably won't work on a PC #system or with a PC-compatible KVM.

FNote that the above is a general guideline, and should not be read to Hindicate that any particular peripheral device will or will not work in Eany particular configuration, save for those specific configurations &the device is explicitly supported in.

GSoftware Integrators sells a video adapter card called Gemini P1 which Hwill drive many of the older HP (DIGITAL-logo) fixed-frequency monitors on a PC system:



GThe DIGITAL (classic 2-5-2-style) part number 29-32549-01 converts the Foutput from the RGB cable (3 BNC, synch-on-green) that comes with the VAXstation 3100 and VAXstationC 4000 series to a female SVGA D connector. You may be able to find @ third-party converters or adapters (3 BNCs with synch-on-green : signaling to 5 BNCs with VGA/SVGA, or to 15-pin VGA/SVGA.

HThis adapter will allow PC multisync monitors with the needed frequency Dspecifications to be used with the VAXstation series synch-on-green Fvideo connection. It may well also work with a VAXstation 2000 series Csystems, but specifics and performance of that combination are not "immediately known at this writing.

?The protocol definition for the old DIGITAL keyboard and mouse @interfaces is buried at the back of the QDSS section in the old CVAXstation II manual, specifically, in the back of the VCB02 Video BSubsystem Technical Manual (EK-104AA-TM). The keyboard wiring and Hprotocol is in appendix B, and occupies circa 44 pages. The mouse is in appendix C, circa 12 pages.

;Also see Section 14.19.




 r Y \ ^  
PreviousNextContentsIndex