Finding and using Software images that were translated using VEST; you can perform a second translation of a VAX image. Please see Section 7.4 and Section 13.14 for related information. Please see the website for the most current details on availability and plans and status of translations for OpenVMS I64 platforms. __________________________________________________________ 13.13 Where can I get Zip, Unzip, self-extracting zip, etc? Many packages are provided in ZIP, GZIP, or BZIP2 format, which requires you to acquire the associated unzip tool to unpack it. You can get ZIP and UNZIP and related and similar tools from the following areas: o http://www.hp.com/go/openvms/freeware/ o ftp://ftp.process.com/vms-freeware/unzip.alpha_exe o ftp://ftp.process.com/vms-freeware/unzip.vax_exe o http://www.decus.de:8080/www/vms/sw/zip.htmlx o http://www.djesys.com/zip.html o http://www.djesys.com/unzip.html or you can request the FILESERV_TOOLS package from the e-mail server. Beware: The [000TOOLS...] pre-built versions of ZIP on the OpenVMS Freeware V4 CD-ROM will erroneously return BILF errors on OpenVMS V7.2 and later. Use the source on the Freeware V4 to rebuild the ZIP image(s), or (better) acquire a far newer Zip kit from a more recent Freeware, or elsewhere. The pre-built version of ZIP on the Freeware V4 kit is older than the included ZIP sources, and comparatively buggy. Directions for creating and using the sfx self- extracting zip file compression mechanism are available in the unzip kit that is available at: o Look in a recent unzip* directory at http://www.hp.com/go/openvms/freeware/ o With the UNZIP542 directory from Freeware V5.0, look for the file UNZIPSFX.TXT. 13-27 Finding and using Software If you want to build the zip images for yourself (eg: for an older OpenVMS version), pull over the entire contents of a recent unzip directory. o http://www.hp.com/go/openvms/freeware/ and invoke LINK.COM. HP OpenVMS Engineering uses a tool known as FTSV for creating self-extracting compressed files using the OpenVMS DCX compression tools, as seen with various OpenVMS ECO (patch) kits. sfx provides better compression than does DCX. The FTSV and its related FTSO package have only limited availability outside HP, and are not standard products. __________________________________________________________ 13.14 Are VAX Hardware Emulators Available? Software-based emulators of the VAX architecture and for specific VAX hardware platforms are available from various sources: o SRI CHARON-VAX http://www.softresint.com/ o Tim Stark's TS10 http://sourceforge.net/projects/ts10/ o Bob Supnik's Trailing Edge http://simh.trailing-edge.com/ VAX emulators that operate on PC systems and/or on OpenVMS Alpha systems are available. For information on an alternative to using a VAX emulator- on the available DECmigrate VAX executable image translator- please see Section 13.12. 13-28 _______________________________________________________ 14 Hardware Information __________________________________________________________ 14.1 What are the OpenVMS differences among VAX, Alpha, and IA-64? In terms of software, very few. As of OpenVMS V6.1, the VAX and Alpha platforms are very close to "feature parity". OpenVMS on IA-64 is expected to have "feature parity" with OpenVMS Alpha, and is based on the same source pool. Most applications can just be recompiled and run. Some differences to be aware of: o The default double-precision floating type on OpenVMS Alpha is VAX G_float, whereas on VAX it is usually D_float. D_float is available on Alpha, but D_float values are converted to G_float for computations and then converted back to D_float when stored. Because the G_float type has three fewer fraction bits than D_float, some applications may get different results. IEEE float types are also available on OpenVMS Alpha. o The preferred floating point format on Alpha and IA-64 is IEEE. o Data alignment is extremely important for best performance on Alpha. This means that data items should be allocated at addresses which are exact multiples of their sizes. Quadword alignment will offer the best performance, especially for character values and those smaller than 32 bits. Compilers will naturally align variables where they can and will issue warnings if they detect unaligned data items. o HP C is the only C compiler HP offers on OpenVMS Alpha, and is a direct descendant of Compaq C and DEC C on OpenVMS Alpha. HP C is compatible with DEC C on OpenVMS VAX, but is somewhat different from the older VAX C compiler most people are familiar 14-1 Hardware Information with. Read up on the /EXTERN_MODEL and /STANDARD qualifiers to avoid the most common problems. In additon to HP C, there are open-source ports such as Gnu C available for OpenVMS. o The page size on Alpha and IA-64 systems is variable, but is at least 8 kilobytes. This can have some effect on applications which use the $CRMPSC system service as well as on the display of available memory pages. The page size is available from $GETSYI(SYI$_PAGE_SIZE). There are also a number of manuals which discuss migration to OpenVMS Alpha available on the documentation CD-ROM media, both in the main documentation and in the archived documentation section. On more recent OpenVMS Alpha versions, OpenVMS Alpha has begun to add features and support not available on OpenVMS VAX. Salient new areas include the following: o 64-bit addressing in OpenVMS Alpha V7.0 and later o Multi-host SCSI support (SCSI TCQ) in V6.2 and later o PCI support (platform-dependent) o OpenVMS Galaxy support in V7.2 and later Please see Section 14.4.5 for Intel Itanium terminology. __________________________________________________________ 14.2 Seeking performance information for Alpha (and VAX) systems? HP makes a wide range of performance documents available through its FTP and WWW Internet servers (see Section 3.2). The following contain information on current Alpha and VAX products: o http://www.compaq.com/alphaserver/servers.html o http://www.compaq.com/alphaserver/vax/index.html 14-2 Hardware Information The following sites contain information on various retired VAX and Alpha products: o http://www.compaq.com/alphaserver/archive/index.html o http://www.compaq.com/alphaserver/performance/perf_ tps.html Also see CPU2000: o http://www.spec.org/osg/cpu2000/ o http://www.spec.org/osg/cpu2000/results/cpu2000.html __________________________________________________________ 14.3 Console Commands, Serial Lines, and Controls? This section contains information on VAX and Alpha consoles, and details related to console commands, serial lines, and configuration settings. _____________________________ 14.3.1 What commands are available in the Alpha SRM console? In addition to the normal BOOT commands and such (see Section 14.3.5.2 for some details) and the normal contents of the console HELP text, operations such as I/O redirection and floppy disk access are possible at the SRM console prompt: 1 Format a FAT floppy, and insert it into the AlphaStation floppy drive. 2 Perform the following at AlphaStation SRM Console : >>> show * > env.dat >>> show conf > conf.dat >>> cat env.dat > fat:env.dat/dva0 >>> cat conf.dat > fat:conf.dat/dva0 3 You may use the SRM "ls" command to display the contents of the floppy. >>> ls fat:env.dat/dva0 >>> ls fat:conf.dat/dva0 4 You can now transfer the FAT-format floppy to another system. 14-3 Hardware Information _____________________________ 14.3.2 What does SRM mean? What is PALcode? The abbreviation SRM is derived from the Alpha System Reference Manual, the specification of the Alpha architecture and the associated firmware. PALcode is a name assigned to a particular set of functions provided by the SRM firmware. PALcode is used to provide low-level functions required by higher-level operating system or application software, functions which may not be directly available in Alpha hardware. PALcode is implemented using available Alpha instructions and using the Alpha processor, though PALcode operates in a mode which simplifies programming. PALcode is also permitted access to processor-specific and otherwise internal features of a particular Alpha microprocessor implementation; microprocessor-specific features which are not easily accessable to operating system or application code. _____________________________ 14.3.3 Alpha COM ports and VAX console serial line information? This section contains information on the Alpha COM communication ports, and related settings, as well as on the VAX console bulkhead and VAX console serial line connection. _____________________________ 14.3.3.1 Which terminal device name is assigned to the COM ports? COM2 is normally TTA0:. COM1 is normally TTB0: if the Alpha workstation is booted with the SRM console environment variable set to graphics, and is OPA0: if the console is set to serial. On the DEC 2000 series (sometimes incorrectly known by the name of the system as sold for Microsoft Windows NT Alpha; as the DECpc 150 AXP series) on older OpenVMS Alpha releases, COM1 through COM4 are known as OPA0: through OPA3:. On all current OpenVMS releases, these ports are serviced by the terminal driver and not by the console OPDRIVER driver. 14-4 Hardware Information Often the easiest way to determine the OpenVMS terminal name assigned to the port is to connect a terminal, log in interactively, and look at the output of SHOW TERMINAL. (Device names can vary by OpenVMS version, as well as by the SRM console environment variable selection.) For serial console hardware and related information, and for pin-outs and related information, please see Section 14.3 and Section 14.27. _____________________________ 14.3.3.2 Which serial port is the console on the MicroVAX 3100? Just to keep life interesting, the MicroVAX 3100 has some "interesting" console ports behaviours based on the setting of the BREAK enable switch. When the console is not enabled to respond to BREAK, MMJ-1 is the console port. MMJ-3 will (confusingly) output the results of the selftest in parallel with MMJ-1. When the console is enabled to respond to BREAK, MMJ-3 becomes the console port, and MMJ-1 will (confusingly) output the results of selftest in parallel with MMJ-3. _____________________________ 14.3.3.3 How can I set up an alternate console on a VAXstation? Most VAXstation series systems and a few Alpha series systems have a switch - most often labeled S3, largely for historical reasons-that enables one of the serial lines as the system console device; as OPA0:. This disables console output to the graphics display. (For a related behaviour, please see Section 11.10.) All VAXstation 3100 series systems provide a S3 slide switch, though the oldest may be missing the cut-out through the enclosure that provides access to the switch. The slide switch is located near the diagnostic LED display. (The slide switch is accessable with the cover removed.) Various members of the DEC 3000 series Alpha systems also have a similarly-labled S3 switch for selection of the alternate console. 14-5 Hardware Information The particular port that becomes the console can vary. The printer MMJ connection is used on all VAXstation 3100 series. On VAXstation II, the console DB9 is used, rather than the graphics display. On most (all?) AlphaStation series systems, typically the COM1 serial port becomes the console. Also see Section 14.3.6, Section 11.10, and Section 14.19. Beware the two different DB9 pin-outs; see Section 14.28 for related details. For information on registering software license product authorization keys (PAKs), please see Section 5.6.2. _____________________________ 14.3.3.4 Please explain the back panel of the MicroVAX II The MicroVAX-series console bulkhead interface was used with the KA630, as well as with the KA650 and KA655 processors. There are three controls on the console bulkhead of these systems: Triangle-in-circle-paddle: halt enable. dot-in-circle: halt () is enabled, and auto-boot is disabled. dot-not-in-circle: halt () is disabled, and auto-boot is enabled. Three-position-rotary: power-up bootstrap behaviour arrow: normal operation. face: language inquiry mode. t-in-circle: infinite self-test loop. Eight-position-rotary: console baud rate selection select the required baud rate; read at power-up. There are several different bulkheads involved, including one for the BA23 and BA123 enclosures, and one for the S-box (BA2xx) series enclosure. The console bulkheads typically used either the MMJ serial line connection, or the MicroVAX DB9 (not the PC DB9 pin- out), please see the descriptions of these in section WIRES1. For available adapters, see Section 14.28. 14-6 Hardware Information Also present on the console bulkhead is a self-test indicator: a single-digit LED display. This matches the final part of the countdown displayed on the console or workstation, and can be used by a service organization to determine the nature of a processor problem. The particular countdown sequence varies by processor type, consult the hardware or owner's manual for the processor, or contact the local hardware service organization for information the self-test sequence for a particular processor module. Note that self-tests 2, 1 and 0 are associated with the transfer of control from the console program to the (booting) operating system. _____________________________ 14.3.4 What are Alpha console environment variables? Alpha systems have a variety of variables with values set up within the SRM system console. These environment variables control the particular behaviour of the console program and the system hardware, the particular console interface presented to the operating system, various default values for the operating system bootstrap, and related control mechanisms-in other words, "the environment variables provide an easily extensible mechanism for managing complex console state." The specific environment variables differ by platform and by firmware version-the baseline set is established by the Alpha Architecture: AUTO_ACTION ("BOOT", "HALT", "RESTART", any other value assumed to be HALT), BOOT_DEV, BOOTDEF_DEV, BOOTED_DEV, BOOT_FILE, BOOTED_FILE, BOOT_OSFLAGS, BOOTED_OSFLAGS, BOOT_RESET ("ON", "OFF"), DUMP_DEV, ENABLE_AUDIT ("ON", "OFF"), LICENSE, CHAR_SET, LANGUAGE, TTY_DEV. OpenVMS Galaxy firmware can add console environment variables beginning with such strings as LP_* and HP_*, and each particular console implementation can (and often does) have various sorts of platform-specific extensions beyond these variables... 14-7 Hardware Information The contents of a core set of environment variables are accessible from OpenVMS using the f$getenv lexical and the sys$getenv system service. (These calls are first documented in V7.2, but have been around for quite a while.) Access to arbitary console environment variables is rather more involved, and not directly available. _____________________________ 14.3.5 What are the boot control flag values? Both VAX and Alpha primary bootstraps support flag values; a mechanism which permits the system manager to perform specific customizations or site-specific debugging of the OpenVMS system bootstrap. While very similar, there are differences among the boot flag implementations for the various architectures. _____________________________ 14.3.5.1 What are the I64 IPB boot flag values? The OpenVMS I64 primary bootstrap flags are processed within the IA-64 primary bootstrap image IPB.EXE; within the SYS$EFI.SYS structures. The primary bootstrap boot flags are largely parallel to those of OpenVMS Alpha (see Section 14.3.5.2, though the console and the console mechanisms used to specify the boot command, the boot flags, and boot command options do differ markedly. When you register an EFI boot alias (please see Section 14.4.5 for Intel Itanium terminology), you will be asked if you want to enter boot options, and what type. To add boot flags to a boot alias, select Unicode as the boot options type, and enter an SRM-like options string, such as the conversational bootstrap selected by the following example: -fl 0,1 14-8 Hardware Information _____________________________ 14.3.5.2 What are the Alpha APB boot flag values? The following flags are passed (via register R5) to the OpenVMS Alpha primary bootstrap image APB.EXE. These flags control the particular behaviour of the bootstrap: BOOT -FL root,flags bit description --- ---------------------------------------------- 0 CONV Conversational bootstrap 1 DEBUG Load SYSTEM_DEBUG.EXE (XDELTA) 2 INIBPT Stop at initial system breakpoints if bit 1 set (EXEC_INIT) 3 DIAG Diagnostic bootstrap (loads diagboot.exe) 4 BOOBPT Stop at bootstrap breakpoints (APB and Sysboot) 5 NOHEADER Secondary bootstrap does not have an image header 6 NOTEST Inhibit memory test 7 SOLICIT Prompt for secondary bootstrap file 8 HALT Halt before transfer to secondary bootstrap 9 SHADOW Boot from shadow set 10 ISL LAD/LAST bootstrap 11 PALCHECK Disable PAL rev check halt 12 DEBUG_BOOT Transfer to intermediate primary bootstrap 13 CRDFAIL Mark CRD pages bad 14 ALIGN_FAULTS Report unaligned data traps in bootstrap 15 REM_DEBUG Allow remote high-level language debugger 16 DBG_INIT Enable verbose boot messages in EXEC_INIT 17 USER_MSGS Enable subset of verbose boot messages (user messages) 18 RSM Boot is controlled by RSM 19 FOREIGN Boot involves a foreign disk If you want to set the boot flags "permanently" use the SET BOOT_FLAGS command, e.g. >>> SET BOOT_OSFLAGS 0,1 14-9 Hardware Information _____________________________ 14.3.5.3 What are the VAX VMB boot flag values? The following flags are passed (via register R5) to the OpenVMS VAX primary bootstrap image VMB.EXE. These flags control the particular behaviour of the bootstrap: The exact syntax is console-specific, recent VAX consoles tend to use the following: >>> BOOT/R5:flags Bit Meaning --- ------- 0 RPB$V_CONV Conversational boot. At various points in the system boot procedure, the bootstrap code solicits parameter and other input from the console terminal. If the DIAG is also on then the diagnostic supervisor should enter "MENU" mode and prompt user for the devices to test. 1 RPB$V_DEBUG Debug. If this flag is set, VMS maps the code for the XDELTA debugger into the system page tables of the running system. 2 RPB$V_INIBPT Initial breakpoint. If RPB$V_DEBUG is set, VMS executes a BPT instruction immediately after enabling mapping. 3 RPB$V_BBLOCK Secondary boot from the boot block. Secondary bootstrap is a single 512-byte block, whose LBN is specified in R4. 4 RPB$V_DIAG Diagnostic boot. Secondary bootstrap is image called [SYSMAINT]DIAGBOOT.EXE. 5 RPB$V_BOOBPT Bootstrap breakpoint. Stops the primary and secondary bootstraps with a breakpoint instruction before testing memory. 14-10 Hardware Information 6 RPB$V_HEADER Image header. Takes the transfer address of the secondary bootstrap image from that file's image header. If RPB$V_HEADER is not set, transfers control to the first byte of the secondary boot file. 7 RPB$V_NOTEST Memory test inhibit. Sets a bit in the PFN bit map for each page of memory present. Does not test the memory. 8 RPB$V_SOLICT File name. VMB prompts for the name of a secondary bootstrap file. 9 RPB$V_HALT Halt before transfer. Executes a HALT instruction before transferring control to the secondary bootstrap. 10 RPB$V_NOPFND No PFN deletion (not implemented; intended to tell VMB not to read a file from the boot device that identifies bad or reserved memory pages, so that VMB does not mark these pages as valid in the PFN bitmap). 11 RPB$V_MPM Specifies that multi-port memory is to be used for the total EXEC memory requirement. No local memory is to be used. This is for tightly-coupled multi-processing. If the DIAG is also on, then the diagnostic supervisor enters "AUTOTEST" mode. 12 RPB$V_USEMPM Specifies that multi-port memory should be used in addition to local memory, as though both were one single pool of pages. 13 RPB$V_MEMTEST Specifies that a more extensive algorithm be used when testing main memory for hardware uncorrectable (RDS) errors. 14-11 Hardware Information 14 RPB$V_FINDMEM Requests use of MA780 memory if MS780 is insufficient for booting. Used for 11/782 installations. <31:28> RPB$V_TOPSYS Specifies the top level directory number for system disks with multiple systems. _____________________________ 14.3.6 How do I boot an AlphaStation without monitor or keyboard? The AlphaStation series will boot without a keyboard attached. To use a serial terminal as the console, issue the SRM console command SET CONSOLE SERIAL followed by the console INIT command. Once this SRM command sequence has been invoked and the CONSOLE environment variable is set to SERIAL, the Alpha system will use the serial terminal. (Set the environment variable to GRAPHICS to select the console display output via the graphics display.) The DEC 3000 series has a jumper on the motherboard for this purpose. Various older Alpha workstations generally will not (automatically) bootstrap without a keyboard connected, due to the self-test failure that arises when the (missing) keyboard test fails. The usual settings for the console serial terminal (or PC terminal emulator acting as a serial console are: 9600 baud, 8 bits, no parity, one stop bit (9600 baud, 8N1). AlphaServer 4100 and derivative series platforms, and AlphaServer GS80, GS160, and GS320 series system consoles are capable of 57600 baud. See the COM2_BAUD console environment variable, and ensure that you have current SRM firmware version loaded. The AlphaStation and AlphaServer series use a PC- compatible DB9 serial connector for the COM1 and COM2 serial lines (and for the OPA0: console line, if that was configured via SRM), please see Section 14.27 for details and pin-out. 14-12 Hardware Information For information on registering software license product authorization keys (PAKs), please see Section 5.6.2. For a related behaviour of DECwindows, please see Section 11.10. For information on the VAXstation alternate console mechanisms, please see Section 14.3.3.3. _____________________________ 14.3.7 Downloading and using SRM console Firmware? This section discusses downloading and using Alpha console firmware, sometimes called PALcode. _____________________________ 14.3.7.1 Where can I get updated console firmware for Alpha systems? Firmware updates for HP Alpha systems are available from: o ftp://ftp.digital.com/pub/Digital/Alpha/firmware/index.html o ftp://ftp.digital.com/pub/Digital/Alpha/firmware/ o ftp://ftp.digital.com/pub/Digital/Alpha/firmware/readme.html The latest and greatest firmware-if updated firmware has been released after the most recent firmware CD was distributed-is located at: o ftp://ftp.digital.com/pub/Digital/Alpha/firmware/interim/ For information on creating Alpha bootable floppies containing the firmware, and for related tools, please see the following areas: o ftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkboot.txt o ftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkbootarc.txt o ftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkntboot.txt The SROM firmware loader expects an ODS-2 formatted floppy, see mkboot. As for which image to use, the ROM image uses a header and the file extension .ROM, and the SROM bootable floppy cannot use the .ROM file. 14-13 Hardware Information To check the firmware loaded on recent OpenVMS Alpha systems, use the command: $ write sys$output f$getsyi("console_version") $ write sys$output f$getsyi("palcode_version") SDA> CLUE CONFIG Also see Section 14.3.7.2. For information on HP Integrity EFI firmware upgrades, please see Section 14.3.10. _____________________________ 14.3.7.2 How do I reload SRM firmware on a half-flash Alpha system? Some of the AlphaStation series systems are "half- flash" boxes, meaning only one set of firmware (SRM or AlphaBIOS) can be loaded in flash at a time. Getting back to the SRM firmware when AlphaBIOS (or ARC) is loaded can be a little interesting... That said, this usually involves shuffling some files, and then getting into the AlphaBIOS firmware update sequence, and then entering "update srm" at the apu-> prompt. To shuffle the files, copy the target SRM firmware file (as200_v7_0.exe is current) to a blank, initialized, FAT-format floppy under the filename A:\FWUPDATE.EXE From the AlphaBIOS Setup screen, select the Upgrade AlphaBIOS option. Once the firmware update utility gets going, enter: Apu-> update srm Answer "y" to the "Are you ready...?" Apu-> quit You've reloaded the flash. Now power-cycle the box to finish the process. Also see Section 14.3.7.1. 14-14 Hardware Information _____________________________ 14.3.7.3 How do I switch between AlphaBIOS/ARC and SRM consoles? The specific steps required vary by system. You must first ensure that the particular Alpha system is supported by OpenVMS (see the SPD), that all core I/O components (graphics, disk controllers, etc) in the system are supported by OpenVMS (see the SPD), and that you have an OpenVMS distribution, that you have the necessary license keys (PAKs), and that you have the necessary SRM firmware loaded. A typical sequence used for switching over from the AlphaBIOS graphics console to the SRM console follows: 1 Press to get to the AlphaBIOS setup menu. 2 Pick the "CMOS Setup..." item. 3 Press to get to the "Advanced CMOS Setup" menu. 4 Change the "Console Selection" to "OpenVMS Console (SRM)". 5 Press , , then to save your changes. 6 Power-cycle the system. Most Alpha systems support loading both the AlphaBIOS/ARC console and the SRM console at the same time, but systems such as the AlphaStation 255 are "half-flash" systems and do not support the presence of both the AlphaBIOS/ARC and SRM console firmware at the same time. If you have a "half-flash" system, you must load the SRM firmware from floppy, from a network download, or from a firmware CD-ROM. Following the normal AlphaBIOS or ARC firmware update sequence to the APU prompt, and then explictly select the target console. In other words, power up the system to the AlphaBIOS or ARC console, use the supplementary options to select the installation of new firmware (typically from CD-ROM), and then rather than using a sequence which updates the current firmware: 14-15 Hardware Information Apu-> update -or- Apu-> update ARC Apu-> verify Apu-> quit Power-cycle the system Use the following sequence to specifically update (and load) SRM from AlphaBIOS/ARC on a "half-flash" system: Apu-> update SRM Apu-> verify Apu-> quit Power-cycle the system Use the following sequence to specifically update (and load) the AlphaBIOS/ARC console from SRM on a "half- flash" system: >>> b -fl 0,A0 ddcu BOOTFILE: firmware_boot_file.exe Apu-> update ARC Apu-> verify Apu-> quit Power-cycle the system Once you have the SRM loaded, you can directly install OpenVMS or Tru64 UNIX on the system. Do not allow Microsoft Windows NT or other operating system(s) to write a "harmless" signature to any disk used by OpenVMS Alpha or OpenVMS VAX, as this will clobber a key part of the disk; this will overwrite the OpenVMS bootblock. (On OpenVMS Alpha and OpenVMS VAX, you can generally recover from this so-called "harmless" action by using the WRITEBOOT.EXE tool. Using OpenVMS I64 and the EFI console, the bootblock structures are expected to be compatible with those of Microsoft Windows and other Integrity operating systems; please see the discussion of the SET BOOTBLOCK command and the SYS$SETBOOT.EXE image in Section 9.7.3, in Section 14.3.9, and in the OpenVMS documentation for related details.) 14-16 Hardware Information If you have a "full-flash" system and want to select the SRM console from the AlphaBIOS or ARC console environment, select the "Switch to OpenVMS or Tru64 UNIX console" item from the "set up the system" submenu. Then power-cycle the system. If you have a "full-flash" system with the SRM console and want to select AlphaBIOS/ARC, use the command: >>> set os_type NT and power-cycle the system. For information on acquiring firmware, see Section 14.3.7.1. For information on OpenVMS license PAKs (for hobbyist use) see Section 2.8.1. For information on the Multia, see Section 14.4.1. Information on enabling and using the failsafe firmware loader for various systems-this tool is available only on some of the various Alpha platforms-is available in the hardware documentation for the system. This tool is used/needed when the firmware has been corrupted, and cannot load new firmware. The full list of AlphaBIOS key sequences-these sequences are needed when using an LK-series keyboard with AlphaBIOS, as AlphaBIOS expects a PC-style keyboard: 14-17 Hardware Information F1 Ctrl/A F2 Ctrl/B F3 Ctrl/C F4 Ctrl/D F5 Ctrl/E F6 Ctrl/F F7 Ctrl/P F8 Ctrl/R F9 Ctrl/T F10 Ctrl/U Insert Ctrl/V Delete Ctrl/W Backspace Ctrl/H Escape Ctrl/[ Return Ctrl/M LineFeed Ctrl/J (Plus) + upselect (some systems) (Minus) - downselect (some systems) TAB down arrow SHIFT+TAB up arrow _____________________________ 14.3.8 Console Management Options Options to collect multiple consoles into a single server are available, with both hardware options and software packages that can provide advanced features and capabilities. Some of the available console management options for OpenVMS: o Heroix: http://www.robomon.com/ o KI Products: http://www.ki.com/products/clim/ o Global Maintech: http://www.globalmt.com/ o TECsys: http://www.tditx.com/ o CA: http://www.cai.com/products/commandit.htm Computer Associates is the owner of what was once known as the VAXcluster Console System (VCS) console management package, and has integrated this capability into the CA management product suite. 14-18 Hardware Information _____________________________ 14.3.9 Why do my EFI Boot Aliases Fail? OpenVMS I64 boot aliases contain signature information referencing the specific volume, meaning that the entries are specific to the disk volume and not the disk device. This also means that certain operations, such as the SET BOOTBLOCK command or the RUN SYS$SETBOOT.EXE operation that can rewrite these volume signatures (signature or GUID values) can render existing boot aliases unusable. If your boot aliases do not function as expected, first try removing and re-adding them; this will resynchronize the boot aliases with the volume contents. If you are using the SET BOOTBLOCK command or the RUN SYS$SETBOOT.EXE operation to rewrite the disk bootblock, you can request that the current signatures (if any) be preserved, and this will typically maintain the validity of your EFI console boot aliases. _____________________________ 14.3.10 Downloading and using EFI Console Firmware? HP Integrity EFI system firmware can be downloaded in the form of a bootable image master, unzipped and then burned onto CD or DVD media (please see Section 9.7 for details of recording optical media on OpenVMS), and the system can then generally be booted off the created media to perform the EFI firmware upgrade. The HP Integrity Server website is accesssable via the following URL, and the available services and support information there has links to the available platform- specific firmware images and upgrade-related materials: o http://www.hp.com/go/servers/ For information on Alpha SRM console firmware upgrades, please see Section 14.3.7. 14-19 Hardware Information __________________________________________________________ 14.4 What platforms will OpenVMS operate on? For the list of boxes that are officially and formally supported by OpenVMS Engineering, please see the OpenVMS Software Product Description (SPD). o http://h18000.www1.hp.com/info/spd/ OpenVMS typically uses SPD 25.01.xx, SPD 41.87.xx, and SPD 82.35.xx. Sometimes a particular and officially unsupported Alpha box or Alpha motherboard will sufficiently resemble a supported box that the platform can effectively mimic and can bootstrap OpenVMS. Alternatively, somebody (usually one or more engineers within the OpenVMS Engineering group) will have put together a bootstrap kit - such as the kit for the Alpha Multia-which permits OpenVMS to bootstrap on the platform. Contrary to the assumptions of some folks, there are platform-level differences even within the VAX and within the Alpha platforms- hardware-level differences that can require moderate to extensive new coding within OpenVMS. Within a platform series, and particularly within Alpha platforms (and those few VAX systems) that support Dynamic System Recognition (DSR), OpenVMS can usually bootstrap. DSR is a mechanism by which OpenVMS can gather platform-specific information, and DSR is the reason why newer Alpha systems can be more easily and more commonly supported on older OpenVMS Alpha releases. DSR is implemented with OpenVMS Alpha code, with SRM console code, and with platform non-volatile memory. OpenVMS users with experience on older OpenVMS VAX releases and VAX hardware will recall that then-new VAX systems either required an OpenVMS VAX upgrade, or that earlier releases would mis-identified then- newer VAX systems-such as the case of the VAX 7000 model 800 being (mis)identified as a VAX 7000 model 600 when bootstrapped on OpenVMS VAX V5.5-2. (This (mis)identification was the outcome of a deliberate engineering effort to permit the VAX 7000 model 800 to bootstrap on V5.5-2; the system manager could configure 14-20 Hardware Information the VAX 7000 model 800 to (mis)identify itself as a model 600, to permit the system to bootstrap on V5.5- 2.) OpenVMS VAX and VAX platforms lack DSR support. OpenVMS I64 (please see Section 14.4.5 for Intel Itanium terminology) supports a platform-level feature similar to the OpenVMS Alpha DSR mechanism, based on the ACPI interface and the byte-code interpreter implemented within OpenVMS, within the EFI console, and particularly within non-volatile memory located on (byte-code interpreter compliant) PCI I/O hardware. ACPI tables provide the information that was formerly retrieved from DSR and from the SRM, and the byte-code interpreter can (theoretically) permit at least limited operations with (compliant) PCI hardware, whether or not OpenVMS has a driver for the particular hardware. The byte code interpreter may or may not permit operations with any particular PCI hardware, and may or may not have sufficient performance for local requirements, and PCI hardware may or may not include the necessary ROM-based drivers in the PCI hardware non-volatile storage. (The intent of this Intel platform-level effort is to move the host software drivers out onto the specific PCI hardware, and to permit the same byte code to operate regardless of the particular host platform.) At least the initial releases of OpenVMS I64 will not have support for the byte code interpreter nor for arbitrary PCI or system hardware, but will have support for ACPI-based system identification and system configuration. _____________________________ 14.4.1 on the Alpha Multia? Yes, there are a set of unsupported images that permit specific OpenVMS Alpha versions to bootstrap on the Multia UDB system. These images and the associated instructions are available at the OpenVMS Freeware website: o http://www.hp.com/go/openvms/freeware/ Look in the Freeware V5.0 /multia/ directory. 14-21 Hardware Information Instructions are included IN the kits. READ THE INSTRUCTIONS. PLEASE! Some of the restrictions involved when running OpenVMS on the Multia system include (but may well not be limited to) the following: o The PCMCIA support was completely removed, because the Intel chip on the Multia was not compatable with the Cirrus chip on the Alphabook. This means, of course, that you will not see and cannot use any PCMCIA cards on a Multia. The Multia uses shared interrupts, and as a result, a special ZLXp-E series graphics device driver-one that does not use interrupts-is needed. This driver is provided in the kit. o The serial lines don't work. o If you have a Multia with a PCI slot, you can't use any PCI card that requires interrupts. o The SRM console on this system is very old and very fragile. (This SRM console was designed only and strictly for diagnostic use, and was not particularly tested or used with OpenVMS.) o If things don't work for you, don't expect to see any OpenVMS updates, nor SRM console updates, nor any support. o Do not expect to see any new versions of OpenVMS on the Multia nor on any other unsupported systems. If such new versions do appear and do work, please consider it as a pleasant surprise. The Multia images are not included on the OpenVMS Freeware V4.0 CD-ROM kit, the kit that was distributed with OpenVMS V7.2. (These images became available after Freeware V4.0 shipped.) Other sources of information for OpenVMS on Multia include: o http://www.djesys.com/vms/hobbyist/multia.html o http://www.djesys.com/vms/hobbyist/mltianot.html 14-22 Hardware Information o http://www.djesys.com/vms/hobbyist/support.html o http://www.netbsd.org/Ports/alpha/multiafaq.html o http://www.brouhaha.com/~eric/computers/udb.html _____________________________ 14.4.2 on AlphaPC 164LX? AlphaPC 164SX? OpenVMS Alpha is not supported on the AlphaPC 164LX and 164SX series, though there are folks that have gotten certain of the LX series to load SRM and bootstrap OpenVMS. (The Aspen Durango II variant, specifically.) One problem has been generally reported: ATA (IDE) bootstraps will fail; SCSI storage and a SCSI CD-ROM device is required. Also see Section 14.4.2.1. _____________________________ 14.4.2.1 on the NoName AXPpci33 system? Information on bootstrapping OpenVMS (using the Multia files described in Section 14.4.1) on the (unsupported) NoName AXPpci33 module is available at: o http://www.jyu.fi/~kujala/vms-in-axppci33.txt Tips for using the Multia files with the AXPpci33: o You have to use the Multia kit and follow the directions in ALPHA8, but do *not* load the Multia SRM firmware into the AXPpci33. Rather, download and use the latest firmware for the AXPpci33 from the HP Alpha firmware website instead. o 64 MB memory is generally necessary. o you cannot use any PCI cards, and if you plan on networking, you need to find an ISA Ethernet card supported by OpenVMS. o When the AXPpci33 board bootstraps, it will dump some stuff like a crash dump, but it will continue and-so far-this hasn't caused any particular hassles. 14-23 Hardware Information o The system shutdown and reboot procedures do not work properly. o The serial console is reported to not work, though the serial ports apparently do work. The status of the parallel port is unknown. o Rumour has it that you have one of the AXPpci33 motherboards with the PS/2 mouse and keyboard connectors and a VGA card (one that will work under DECwindows) and you can run DECwindows on the system. _____________________________ 14.4.3 on the Alpha XL series? No. OpenVMS Engineering does not formally support the Alpha XL series, nor will OpenVMS (informally) bootstrap on the Alpha XL series. OpenVMS can not, will not, and does not bootstrap on the Alpha XL series. The Alpha XL series was targeted for use (only) with the Microsoft Windows NT operating system. The Alpha XL platform does not resemble other supported platforms. _____________________________ 14.4.4 OpenVMS on the Personal Workstation -a and -au series? Though OpenVMS is not supported on the Personal Workstation -a series platforms, OpenVMS might or might not bootstrap on the platform. If you wish to attempt this, you must ensure that all graphics and all I/O controllers in the system are supported by OpenVMS. You must also ensure that you have the most current firmware loaded. Here are some salient differences within the various Personal Workstation series: o The -a series was designed and was tested for Windows NT use. Only. It is not supported for use with OpenVMS. 14-24 Hardware Information o The -au series was designed and tested for Windows, OpenVMS, and Tru64 UNIX compatibility, and is considered a supported system. o There are at two different and distinct variants of the family, and usually refered to by their internal hardware project names. o The Miata MX5. The Miata MX5 variant has no USB ports and no on-board SCSI. The on-board Intel SIO chipset is not supported by OpenVMS, and thus OpenVMS cannot bootstrap ATAPI CD-ROM devices. That said, the Miata MX5 -a series typically came with DEC branded Adaptec 2940UW SCSI controllers, Matrox Millennium graphics cards, no L3 cache module, and an Toshiba IDE CD-Rom. Some came with very high end Powerstorm graphics card if the system was destined to do CAD or movie rendering. Graphics and other I/O can and does vary by package. The Miata MX5 is not supported by OpenVMS. o The Miata GL. The Miata GL variant has USB ports and on-board SCSI and bootstraps using the on- board Cypress IDE chipset and an ATAPI CD-ROM are supported by OpenVMS. The Miata GL -a variant is need not be configured with an add-on SCSI controller, given both the ability to bootstrap from ATAPI CD-ROM and the on-board SCSI. Graphics and other I/O can and does vary by package. Various of the Miata GL systems are supported by OpenVMS. For obvious reasons, most folks will select a Miata GL system, given the choice between the Miata MX5 and the Miata GL. And as for your next question, you cannot necessarily nor easily distinguish the Miata MX5 from the Miata GL based solely on the model number. See Section 14.4.4.2 for related details. 14-25 Hardware Information _____________________________ 14.4.4.1 OpenVMS on the Whitebox Windows-Only series Alpha? Though OpenVMS is not supported on the "Whitebox" series of Alpha platforms, OpenVMS might or might not bootstrap on the platform. These systems were specifically configured, targeted and supported only for use with the Microsoft Windows NT operating system. On some of the "Whitebox" systems, the following sequence of console commands can potentially be used to convert the system over to unsupported use by and for OpenVMS Hobbyist users. (But please note that if you wish to attempt this, you must ensure that all graphics and all I/O controllers in the system are supported by OpenVMS, and you must ensure that you have the most current SRM firmware loaded. (For information on locating and downloading the most current Alpha SRM firmware, please see Section 14.3.7.1.) And you must realize that the resulting Whitebox configuration will be entirely unsupported and may or may not be stable and useful.) set os_type vms cat nvram ! too see what is in this, if anything edit nvram 10 set srm_boot on 20 e init If your nvram has other contents, you will need to change the line numbers (10 and 20) to reflect the contents of your configuration. To obtain documentation on the commands of the console editor, enter the ? command within the editor. The above sequence was reportedly tested on the DIGITAL Server 3300 series, a relative of the AlphaServer 800 series. The DIGITAL Server 3300 is not supported by OpenVMS, though the AlphaServer 800 series is a supported platform. The sequence may or may not work on other platforms, and may or may not work on the DIGITAL Server 3300 platform. Also see Section 5.33. 14-26 Hardware Information _____________________________ 14.4.4.2 OpenVMS and Personal Workstation ATA (IDE) bootstrap? OpenVMS will boot and is supported on specific Personal Workstation -au series platforms, though OpenVMS will require a SCSI CD-ROM if the Intel Saturn I/O (SIO) IDE chip is present in the configuration- only the Cypress IDE controller chip is supported by OpenVMS for IDE bootstraps. (Configurations with the Intel SIO are not generally considered to be supported systems.) If you have an -au series system, you can determine which IDE chip you have using the SRM console command: SHOW CONFIGURATION If you see "Cypress PCI Peripheral Controller", you can bootstrap OpenVMS from IDE storage. If you see "Intel SIO 82378", you will need to use and bootstrap from SCSI. (A procedure to load DQDRIVER on the Intel SIO- once the system has bootstrapped from a SCSI device-is expected to be included as part of the contents of the DQDRIVER directory on Freeware V5.0 and later.) Many of the -a series systems will include the Intel SIO, and thus cannot bootstrap from IDE. See Section 14.4.4 for related details. _____________________________ 14.4.5 On the Intel Itanium IA-64 platform? OpenVMS has been ported to the Intel IA-64 architecture; to HP Integrity systems based on the Intel Itanium Processor Family. The first release of OpenVMS I64 was V8.0, with the first general release of OpenVMS I64 known as V8.2. Yes, there was a V8.1 release, too. Some Intel and HP terminology: Itanium Processor Family is the name of the current implementation; of the current Intel microprocessor family implementing the IA-64 architecture. IA-64 is the name of the Intel architecture implementing the VLIW (Very Long Instruction Word) design known as EPIC (Explicitly Parallel Instruction Computing). 14-27 Hardware Information I64 is the name of a family of HP computer systems that use Intel Itanium processors and that are supported by "HP OpenVMS for Integrity Servers" (and itself more commonly known as "OpenVMS I64"); by one of the HP operating systems that runs on HP Integrity hardware. The Extensible Firmware Interface (EFI) is the name of the console environment for Itanium systems, and the Baseboard Management Console (BMC) and the optional Management Processor (MP) are the most typical hardware interfaces into the system console. _____________________________ 14.4.5.1 Where can I get Intel Itanium information? Intel Itanium Processor Family and IA-64 Architecture, Hardware, Software, and related docoumentation materials are available at: o ftp://download.intel.com/design/IA-64/manuals/ o ftp://download.intel.com/design/IA-64/Downloads/ o ftp://download.intel.com/design/IA- 64/Downloads/archSysSoftware.pdf o ftp://download.intel.com/design/IA- 64/Downloads/24870101.pdf The Intel Extensible Firmware Interface (EFI) console documentation: o http://www.pentium.de/technology/efi/index.htm Please see Section 14.4.5 for Intel Itanium terminology. __________________________________________________________ 14.5 What is the least expensive system that will run OpenVMS? The cheapest systems that are or have been recently offered by HP that will run OpenVMS Alpha are the AlphaServer DS10 server, the AlphaStation XP900 workstation, the AlphaStation VS10 workstation, and the AlphaStation XP1000 workstation. Other companies sell Alpha-powered systems and Alpha motherboards, some of which will run (and can be purchased with) OpenVMS- see the OpenVMS Software Product Description (SPD) for 14-28 Hardware Information details on the supported systems and configurations. There are also many used AlphaStation, AlphaServer, and DEC 3000 models available which are quite suitable. For more experienced OpenVMS system managers, the (unsupported) Multia can bootstrap OpenVMS-see Section 14.4.1 for details. Depending on the OpenVMS version and configuration, the OpenVMS Software Product Description (SPD) is available at: o http://www.hp.com/go/openvms/doc/ When purchasing a system, ensure that the system itself is supported, that the system disk drive is supported or closely compatible, that the optical (CD or DVD) drive is supported or is closely compatable and that (in the case of SCSI devices) it also specifically supports 512-byte block transfers; no equivalent requirement exists for IDE devices. Also particularly ensure that the video controller is supported. Use of supported HP hardware will generally reduce the level of integration effort involved. A CD-ROM, CD-R or DVD drive is required for OpenVMS Alpha installations. CD-ROM drive compatibility information is available at: o http://sites.inka.de/pcde/dec-cdrom-list.txt __________________________________________________________ 14.6 Where can I get more information on Alpha systems? HP operates an AlphaServer information center at: o http://www.hp.com/go/server Alpha Technical information and documentation is available at: o ftp://ftp.compaq.com/pub/products/alphaCPUdocs/ o http://h18000.www1.hp.com/products/software/alpha- tools/ o ftp://ftp.digital.com/pub/DEC/Alpha/systems/ o http://ftp.digital.com/pub/Digital/info/semiconductor/literature/dsc- library.html 14-29 Hardware Information o Alpha Systems Update: http://www.compaq.com/alphaserver/fb_acu.html Software Product Description (SPD) information, including platform support documentation: o http://h18000.www1.hp.com/info/spd/ OpenVMS typically uses SPD 25.01.xx, SPD 41.87.xx, and SPD 82.35.xx. Information on Multia hardware is available at: o http://www.netbsd.org/Ports/alpha/multiafaq.html Information on DEC 3000 series hardware is available at: o http://www.phys.ufl.edu/~prescott/linux/alpha/dec3000- sysinfo.html o http://www.phys.ufl.edu/~prescott/linux/alpha/dec3000- docs.html o http://ftp.netbsd.org/pub/NetBSD/misc/dec- docs/index.html The NetBSD folks maintain useful Alpha hardware information at: o http://www.netbsd.org/Ports/alpha/models.html __________________________________________________________ 14.7 Describe Alpha instruction emulation and instruction subsets? The Alpha architecture is upward- and downward- compatible, and newer instructions are emulated on older platforms, for those cases where the compiler is explicitly requested to generate the newer Alpha instructions. In particular, OpenVMS Alpha V7.1 and later include the instruction emulation capabilities necessary for the execution of newer Alpha instructions on older Alpha microprocessors. (Instruction emulation capabilities are available for user-mode application code, and 14-30 Hardware Information are not available to device drivers or other similar kernel-mode code.) Alpha instructions are available in groups (or subsets). Obviously, there is the base instruction set that is available on all Alpha microprocessors. Then, the following are the current instruction extension groups (or subsets) that are available on some of various recent Alpha microprocessors: o byte/word extension (BWX): LDBU, LDWU, SEXTB, SEXTW, STB, and STW. o floating-point and square root extension (FIX): FTOIS, FTOIT, ITOFF, ITOFS, ITOFT, SQRTF, SQRTG, SQRTS, and SQRTT. o count extension (CIX): CTLZ, CTPOP, and CTTZ. o multi-media extension (MVI): MAXSB8, MAXSW4, MAXUB8, MAXUW4, MINSB8, MINSW4, MINUB8, MINUW4, PERR, PKLB, PKWB, UNPKBL, and UNPKBW. The typical instruction subset that provides the biggest win-and of course, 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 The /ARCHITECTURE controls the maximum instruction subset that the compiler will generally use, while the /OPTIMIZE=TUNE controls both the instruction-level scheduling and also the instructions generated inside loops-any code resulting from /OPTIMIZE=TUNE that is specific to an instruction subset will be generated only inside loops and will also be "protected" by an AMASK-based test that permits the execution of the proper code for the particular current Alpha microprocessor. 14-31 Hardware Information Typically /OPTIMIZE=TUNE=GENERIC is the appropriate choice for tuning, and the /ARCHITECTURE selects the minimum target architecture for general use throughout the generated code. generated for later architectures and instruction subsets will run on older Alpha systems due to the emulation, but if /ARCHITECTURE is a significant benefit, then the emulation might be a performance penalty. Please see the OpenVMS Ask The Wizard area for the source code of a (non-privileged) tool that looks at the instruction subsets available on the particular Alpha microprocessor that the tool is run on. This tool demonstrates the use of the Alpha AMASK and IMPLVER instructions. Please see Section 10.22 and Section 14.10 for additional details and related considerations. __________________________________________________________ 14.8 What is the Accuracy of the Alpha Time of Year (BB_WATCH) Clock? The specification for maximum clock drift in the Alpha hardware clock is 50 parts per million (ppm), that is less than ±0.000050 seconds of drift per second, less than ±0.000050 days of drift per day, or less than ±0.000050 years of drift per year, etc. (eg: An error of one second over a day-long interval is roughly 11ppm, or 1000000/(24*60*60).) Put another way, this is .005%, which is around 130 seconds per month or 26 minutes per year. The software-maintained system time can drift more than this, primarily due to other system activity. Typical causes of drift include extensive high-IPL code (soft memory errors, heavy activity at device IPLs, etc) that are causing the processing of the clock interrupts to be blocked. Also see Section 14.15, Section 4.2. 14-32 Hardware Information __________________________________________________________ 14.9 So how do I open up the DEC 3000 chassis? After removing those two little screws, tilt the back end of the top shell upwards-then you can remove the lid. __________________________________________________________ 14.10 What is byte swizzling? "Swizzling" is the term used to describe the operation needed to do partial longword (i.e. byte or word) accesses to I/O space on those systems that don't support it directly. It involved shifting the offset into an address space by 5 (or 7 for one older system), and ORing this into the base address. It then required the size of the operation to be ORed into the low order bits. That is, because the EV4 and EV5 CPUs did not bring bits 0 and 1 off the chip, to do programmed I/O for bytes/words, the information on the size/offset of the transfer was encoded into the address data. The data itself then had to be shifted into the correct "byte lane" ; into the required offset position within a longword transfer; The EV56 microprocessor supports byte/word instruction references in memory space, however only specific EV56 systems can support byte/word accesses into I/O space; device drivers may or may not be able to utilize to byte/word instructions to access device registers. Further, even on an EV56 system with hardware support for byte/word accesses into I/O space, the relevant OpenVMS routines typically do not support byte/word access into I/O space. Systems based on the EV6 microprocessor (with the salient exception of the AlphaServer GS60 and AlphaServer GS140 series, for reasons of platform compatability) support a flat, byte addressable I/O space. If a device driver uses CRAM or IOC$WRITE_IO/IOC$READ_ IO, then OpenVMS will correctly process the swizzling requirements without requiring changes the driver; OpenVMS will transparently swizzle and unswizzle the 14-33 Hardware Information I/O space references, if needed for the particular target platform. (Access and use of these routines may or may not be feasible within the requirements for a particular device driver, with the decision typically based on the target performance requirements and the expected frequency of device references and thus the expected frequency of calls to these or other similar routines.) To use byte/word operations on MEMORY, you need to tell the compiler to use the EV56 or EV6 architecture (/ARCHITECTURE=EV56). Memory operations did not swizzle, but the compiler would do long/quad access, and extract/insert bytes as needed. Using /ARCHITECTURE=EV56 allows smaller, more efficient byte/word access logic to memory. If the application is directly referencing I/O space access across a range of Alpha systems such as is done with the X Windows device drivers, then the driver will need to know how to do swizzling for old platforms, and byte access for new platforms. Device drivers for new graphics controllers can specifically target and specifically require platforms 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. __________________________________________________________ 14.11 What is the layout of the VAX floating point format? The VAX floating point format is derived from one of the PDP-11 FP formats, which helps explain its strange layout. There are four formats defined: F 32- bit single-precision, D and G 64-bit double-precision and H 128-bit quadruple precision. For all formats, the lowest addressed 16-bit "word" contains the sign and exponent (and for other than H, some of the most significant fraction bits). Each successive higher- addressed word contains the next 16 lesser-significant fraction bits. Bit 15 of the first word is the sign, 1 for negative, 0 for positive. Zero is represented by a biased exponent value of zero and a sign of zero; 14-34 Hardware Information the fraction bits are ignored (but on Alpha, non- zero fraction bits in a zero value cause an error.) A value with biased exponent zero and sign bit 1 is a "reserved operand" - touching it causes an error - fraction bits are ignored. There are no minus zero, infinity, denormalized or NaN values. For all formats, the fraction is normalized and the radix point assumed to be to the left of the MSB, hence the following range: 0.5 less than or equal to f and less than 1.0. The MSB, always being 1, is not stored. 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, Type Bits Bias including hidden bit ========================================================== F 8 128 24 D 8 128 56 G 11 1024 53 H 15 16384 113 The layout for D is identical to that for F except for 32 additional fraction bits. Example: +1.5 in F float is hex 000040C0 (fraction of .11[base 2], biased exponent of 129) __________________________________________________________ 14.12 Where can I find more info about VAX systems? o HP provides limited VAX platform information via links at the AlphaServer website, itself available via: http://www.hp.com/go/server/ o Jim Agnew maintains a MicroVAX/VAXstation FAQ at: http://anacin.nsc.vcu.edu/~jim/mvax/mvax_faq.html o The VAXstation 3100 Owner's Guide: http://www.whiteice.com/~williamwebb/intro/DOC- i.html o A field guide to PDP-11 (and VAX) Q-bus and UNIBUS modules can be found at: http://metalab.unc.edu//pub/academic/computer- science/history/pdp-11/hardware/field-guide.txt 14-35 Hardware Information o Various VAX historical information (also see Section 2.1) can be found at: http://telnet.hu/hamster/vax/e_index.html __________________________________________________________ 14.13 Where can I find information on NetBSD for VAX systems? Gunnar Helliesen maintains a NetBSD VAX FAQ at o http://vaxine.bitcon.no/ __________________________________________________________ 14.14 What system disk size limit on the MicroVAX and VAXstation 3100? System disks larger than 1.073 gigabytes (GB)-1fffff hexidecimal blocks - are not supported on any member of the VAXstation 3100 series and on certain older members of the MicroVAX 3100 series, and are not reliable on these affected systems. (See below to identify the affected systems-the more recent members of the MicroVAX 3100 series systems are NOT affected.) Various 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" commands, which allow a 21 bit block number field, which allows access to the first 1fffff hexidecimal blocks of a disk. Any disk references past 1fffff will wrap-this wrapping behaviour can be of particular interest when writing a system crashdump file, as this can potentially lead to system disk corruptions should any part of the crashdump file be located beyond 1.073 GB. More recent systems and console PROMs use "Group 1" SCSI commands, which allow a 32 bit block number field. There was a similar limitation among the oldest of the MicroVAX 3100 series, but a console boot PROM was phased into production and was made available for field retrofits-this PROM upgrade allows the use of the "Group 1" SCSI commands, and thus larger system disks. There was no similar PROM upgrade for the VAXstation 3100 series. 14-36 Hardware Information Systems that are affected by this limit: o VAXstation 3100 series, all members. No PROM upgrade is available. o MicroVAX 3100 models 10 and 20. No PROM upgrade is available. o MicroVAX 3100 models 10e and 20e. Only systems with console VMB versions prior to V6.4 are affected. A PROM upgrade for these specific systems is (or was once) available. Also see o http://www.whiteice.com/~williamwebb/intro/DOC- i.html Also see Section 9.5. __________________________________________________________ 14.15 What is the Accuracy of VAX the Time of Year (TOY) Clock? The VAX Time-Of-Year (TOY) clock (used to save the time over a reboot or power failure) is specified as having an accuracy of 0.0025%. This is a drift of roughly 65 seconds per month. The VAX Interval Time is used to keep the running time, and this has a specified accuracy of .01%. This is a drift of approximately 8.64 seconds per day. Any high-IPL activity can interfere with the IPL 22 or IPL 24 (this depends on the VAX implementation) clock interrupts-activities such as extensive device driver interrupts or memory errors are known to slow the clock. Also see Section 14.8, Section 4.2. 14-37