ALPHA1.

What do the letters AXP stand for?

While there are many fanciful "definitions" which have circulated widely, the truth is that AXP is not an abbreviation nor an acronym; the letters do not mean anything. They are just three letters chosen to form a trademark.

When it came time to chose a "marketing name" for the Alpha AXP line, the company was in a quandary. The internal "code name" for the project, Alpha, was widely known and would seem the ideal choice, but it was already in common use by a number of other companies and could not be trademarked. A well-known "name search" firm was hired and was asked to come up with two lists of possible names. The first list was intended to evoke the feeling of "extension to VAX", while the second list was to suggest "not a VAX". Unfortunately, none of the choices offered were any good; for example, "VAX 2000" was found on the first list while the second list contained "MONDO" (later to be used for a kids' soft drink).

Shortly before announcement, a decision was made to name the new line ARA, for Advanced RISC Architecture. However, an employee in Israel quickly pointed out that this name, if pronounced in the "obvious" manner, sounded very much like an Arabic word with decidely unfortunate connotations. Eventually, AXP was selected; the architecture would be referred to as "Alpha AXP" whereas products themselves would use just "AXP".

Use of the AXP term has been phased out in favour of using Alpha. For example, OpenVMS AXP is now called called "OpenVMS Alpha".



ALPHA2.

What are the OpenVMS differences between VAX and Alpha?

Very few. As of OpenVMS V6.1, the VAX and Alpha platforms are very close to "feature parity". Most applications can just be recompiled and run. Some differences to be aware of:

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.



ALPHA3.

Removed: no longer relevant



ALPHA4. Moved to VMS16, and out of the Alpha hardware section



ALPHA5.

Seeking performance information for Alpha (and VAX) systems?

Compaq makes a wide range of performance documents available through its FTP and WWW Internet servers (see DOC2)

The following contain information on current Alpha and VAX products:

    http://www.compaq.com/alphaserver/products.html
    http://www.compaq.com/alphaserver/vax/
The following sites contain information on various retired VAX and Alpha products:
    http://www.compaq.com/alphaserver/archive/index.html
    http://www.compaq.com/alphaserver/performance/perf_tps.html

Also see CPU2000:

    http://www.spec.org/osg/cpu2000/
    http://www.spec.org/osg/cpu2000/results/cpu2000.html



ALPHA6.

Where can I get updated console firmware for Alpha systems?

Firmware updates for Compaq Alpha systems are available from:
       ftp://ftp.digital.com/pub/Digital/Alpha/firmware/index.html
       ftp://ftp.digital.com/pub/Digital/Alpha/firmware/
       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:
       ftp://ftp.digital.com/pub/Digital/Alpha/firmware/interim/

Please send your comments and feedback to :
        alpha_server@service.digital.com

For information on creating bootable floppies containing the firmware, and for related tools, please see the following areas:
  ftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkboot.txt
  ftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkbootarc.txt
  ftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkntboot.txt

                                          [Stephen Hoffman]

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

                                          [Clair Grant]
Also see ALPHA14.



ALPHA7.

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 console command SET CONSOLE SERIAL - after that, it will use the terminal. The DEC 3000 model 300 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)
The AlphaStation and AlphaServer series use the PC DIN serial connector for the "COM1" and "COM2" serial lines, see WIRES1 for details and pinout.



ALPHA8.

Will OpenVMS run on a Multia? AlphaPC 164LX? 164SX?

Yes, there are a set of unsupported images that permit recent OpenVMS Alpha versions to bootstrap on the Multia UDB system. These images and the associated instructions are available at the OpenVMS Freeware website:
  http://www.openvms.compaq.com/freeware/multia/

Instructions are included IN the kits. READ THE INSTRUCTIONS.

Some of the restrictions involved when running OpenVMS on the Multia system include (but may well not be limited to) the following:

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:

  http://home.earthlink.net/~djesys/vms/hobbyist/multia.html
  http://home.earthlink.net/~djesys/vms/hobbyist/mltianot.html
  http://home.earthlink.net/~djesys/vms/hobbyist/support.html
  http://www.netbsd.org/Ports/alpha/multiafaq.html

                                        [Stephen Hoffman]
                                        [David J. Dachtera]
OpenVMS Alpha is not supported on the AlphaPC 164LX and 164SX, though there are folks that have gotten certain of the LX series to load SRM and bootstrap OpenVMS. (The Aspen Durango II variant.) One problem was reported: IDE bootstraps fail; SCSI is required.

Also see ALPHA13.



ALPHA9.

What is the least expensive system that will run OpenVMS?

The cheapest systems presently offered by Compaq that will run OpenVMS are the AlphaServer DS10 server and the AlphaStation XP900 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 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 ALPHA8 for details.

Depending on the OpenVMS version and configuration, the OpenVMS Software Product Description (SPD) is available at:

  http://www.compaq.com/info/spd/
OpenVMS typically uses SPD 25.01.xx and/or SPD 41.87.xx.

When purchasing a system, ensure that the system itself is supported, that the system disk drive is supported or closely compatible, that the CD-ROM drive is supported or is closely compatable and that it also specifically supports 512 byte block transfers, and particularly ensure that video controller is supported. Use of supported Compaq hardware will generally reduce the level of integration effort involved.

A CD-ROM drive is required for OpenVMS Alpha installations.

                                               [Stephen Hoffman]



ALPHA10.

Where can I get more information on Alpha systems?

Compaq operates an AlphaServer information center at:
  http://www.compaq.com/alphaserver/
Alpha Technical information and documentation is available at:
  http://www.support.compaq.com/alpha-tools/documentation/current/chip-docs.html
  ftp://ftp.digital.com/pub/DEC/Alpha/systems/
  http://ftp.digital.com/pub/Digital/info/semiconductor/literature/dsc-library.html

Platform product documentation:
    http://www.compaq.com/info/spd/
    http://www.digital.com/info/lists/key-server_AL.HTM
    http://www.digital.com/info/lists/key-workstation_AL.HTM

Information on Multia hardware is available at:
  http://www.netbsd.org/Ports/alpha/multiafaq.html

                                        [Stephen Hoffman]

Information on current and future Alpha microprocessor designs is also available from AlphaPowered at:
     http://www.alphapowered.com/alpha_tomorrow.html
     http://www.alphapowered.com/timeline.html
     http://www.alphapowered.com/ev7-and-ev8.html

The NetBSD folks maintain some Alpha hardware information at:
  
  http://www.netbsd.org/Ports/alpha/models.html



ALPHA11.

What are the 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

bitMnemonicdescription
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



ALPHA12.

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:


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...

The contents of a core set of environment variables are accessable 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.

                                        [Stephen Hoffman]



ALPHA13.

Will OpenVMS run on a NoName AXPpci33?

Information on bootstrapping OpenVMS (using Multia files) on the (unsupported) NoName AXPpci33 module is available at:
  http://www.jyu.fi/~kujala/vms-in-axppci33.txt
Tips for using the Multia files with the AXPpci33:
                                      [Robert Alan Byer]



ALPHA14.

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 powercycle the box to finish the process.
Also see ALPHA6.



ALPHA15.

Will OpenVMS run on the Alpha XL series?

No. OpenVMS does not support 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.

For the list of boxes officially supported by OpenVMS, please see the OpenVMS Software Product Description (SPD).

       http://www.compaq.com/info/spd/

OpenVMS typically uses SPD 25.01.xx and/or SPD 41.87.xx.

If you are very lucky, sometimes a particular unsupported Alpha box or motherboard will resemble a supported box sufficiently closely and can thus mimic that system and bootstrap. (No such family resemblances exist for the XL.) If you are exceedingly lucky, somebody here in OpenVMS Engineering will have put together a bootstrap kit - such as that for the Multia. (No Miata-like OpenVMS bootstrap kit exists for the XL.)



ALPHA16.

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.

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:

byte/word extension (BWX):
LDBU, LDWU, SEXTB, SEXTW, STB, and STW.
floating-point and square root extension (FIX):
FTOIS, FTOIT, ITOFF, ITOFS, ITOFT, SQRTF, SQRTG, SQRTS, and SQRTT.
count extension (CIX):
CTLZ, CTPOP, and CTTZ.
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.

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.

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.



ALPHA17.

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 ppm, that's less than +/-.000050 seconds of drift per second, less than +/-.000050 days of drift per day, or less than +/-.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).)

The software-maintained system time can drift more, 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 VAX8, TIME6.



ALPHA18.

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.
                                           [Felix Kreisel]



ALPHA19.

What is byte swizzling?

"Swizzling" is the term used to describe the operation needed to do partial word IO on a pre-ev6 system. 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 EV4 and EV5 did not bring bits 0 and 1 off the chip, to do programmed IO 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" (i.e. it's actual position within a longword).

EV56 (though not EV5) had byte/word operations, but OpenVMS did not directly support this for IO. EV6 systems (with the exception of the AlphaServer GS60 and AlphaServer GS140 series, for reasons of platform compatability) all support a flat byte addressable IO space.

If device driver uses CRAM or IOC$WRITE_IO/IOC$READ_IO, then OpenVMS will do the right thing without changing the driver - OpenVMS will swizzle and unswizzle as needed.

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 IO logic to memory. Beware: a few Alpha systems have EV56, but do not support byte/word to I/O space.

If the application is directly doing IO access across a range of Alpha systems (like the graphics servers), then the driver will need to know how to do swizzling for old platforms, and byte access for new platforms.

                                        [Fred Kleinsorge]



ALPHA20.

What commands are available in the Alpha SRM console?

In addition to the normal BOOT commands and such (see ALPHA11 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" 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.



ALPHA21.

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 <F2> to get to the AlphaBIOS setup menu.
  2. Pick the "CMOS Setup..." item.
  3. Press <F6> to get to the "Advanced CMOS Setup" menu.
  4. Change the "Console Selection" to "OpenVMS Console (SRM)".
  5. Press <F10>, <F10>, then <Enter> 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:
    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 Windows NT to write a "harmless" signature to any disk used by OpenVMS, Tru64 UNIX, or Linux, as this will clobber a key part of the disk. (On OpenVMS, you can generally recover from this "harmless" action by using the WRITEBOOT tool.)

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 ALPHA6. For information on OpenVMS license PAKs (for hobbyist use) see VMS9. For information on the Multia, see ALPHA8.

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.



ALPHA22.

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 attempt this, you must ensure that all graphics and I/O controllers in the system are supported by OpenVMS.)



ALPHA23.

OpenVMS and Personal Workstation IDE bootstrap?

OpenVMS will boot and is supported on the 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.

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.)



ALPHA24.

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.

Next Back