Martin's VAXstation 2000 (node DEEPV2)

(updated 31-May-2003)

Collection of documentation I found elsewhere. Credit is given at the end of the page.


  1. Formatting a hard disk
  2. Formatting a floppy disk
  3. Ports on a VAXstation 2000
  4. Using SCSI disks
  5. Installing VMS
  6. References

Formatting a hard disk

The disks used in the main box of a VAXstation 2000 are MFM Disks, like those used in early IBM PCs. These disks have to be prepared, or "formatted" for use in a VAXstation. Formatting with a PC is not good enough, as the VAXstation hardware needs a special format on the disk. Disks formatted on a VAXstation 2000 can also be used in a MicroVAX II.

The hardware knows certain type of disks, which have been used in standard MicroVAX and VAXstation configurations, and these disks have DEC names:

My VS2000 came with a Micropolis RD54, which is a full height 5 1/4 hard disk, occupying two of today's 5 1/4 PC drive bays. I also successfully formatted a ST-255 (RD31) that came with a old PC. If you have such a disk regardless which source, you can easily format it with the VS2000 ROM formatter program, It will recognize the drive and automatically set all drive parameters correctly.

Formatting non standard drives is difficult, because you have to specify all parameters by hand. [1] gives a list of parameters.

The formatting itself is done by calling the procedure TEST 70 from the "chevron" prompt:

    >>> TEST 70
    VSfmt_QUE_unitno (0-2) ? 0    [Enter drive number, 0 and 1 for disks, 2 for floppy]

    VSfmt_STS_Siz .......... xxxx [any RDxx or ???? is reported here]

If xxxx is showing one of the above disk codes, then the following part will be skipped. If it is showing ????, then the drive parameters need to be entered by hand. Parameters are from the VS2000 technical manual.

	VSfmt_STS_EntUIB              [Formatter wants drive details]

    xbnsiz :=54         [enter the number of transfer blocks]
    dbnsiz :=48         [enter the number of diagnostic blocks]
    lbnsiz :=83236      [enter the number of logical blocks]
    rbnsiz :=200        [enter the number of replacement blocks]
    surpun :=6          [enter the number of surfaces per unit]
    cylpun :=820        [enter the number of cylinders per unit]
    wrtprc :=820        [enter the write precompensation cylinder]
    rctsiz :=4          [enter the size of the revectoring control table (RCT)]
    rctnbr :=8          [enter the number of copies of the RCT]
    secitl :=1          [enter the sector interleave]
    stsskw :=2          [enter the surface to surface skew]
    ctcskw :=9          [enter the cylinder to cylinder skew]
    mediai :=627327008  [enter the MSCP media ID]

*	Note this number is not dependant on disk geometry, but is the 
*	magic number for VMS to report on the type of disk.

At this point, the formatter exits the query mode. The following dialog is the same for standard disks and custom disks:

    VSfmt_QUE_SerNbr (0-999999999)  [enter the serial number for the drive 
                                     or enter a unique number for each unit]
    VSfmt_QUE_RUsure (DUAx 1/0) ?   [where x equals the unit number]
                                    [enter 1 for YES, 0 for NO]
    VSfmt_STS_RdMbb.............OK  [manufacturer's bad block located]
    VSfmt_STS_FMTing............OK  [disk formatted OK]
    VSfmt_STS_ChkPss............OK  [check pass completed OK]
    VSfmt_STS_BBRvec := x           [number of bad blocks revectored]
    VSfmt_RES_Succ                  [disk is successfully formatted]

At this point, the disk has been succesfully formatted, and the console command prompt is displayed.

Explanation of drive specifics:

number of transfer blocks. All DEC's disks seem to use 54, regardless of the disk capacity.
number of diagnostic blocks. DEC seems to select this so that the DBNs and XBNs total up to 1 cylinder. Therefore:
total number of user data blocks, not counting DBNs and XBNs. I believe that
the numbers I have for DEC disks are close to this, but not exact. There must be some ambiguity about what gets counted.
replacement block count (for bad block revectoring). About 0.1% to 1% of the disk capacity is reasonable, depending on the media quality. DEC seems to always use 0.2%. This is frequently rounded to an exact number of cylinders, but I'm not sure that's necessary. WARNING - if you allocate fewer RBNs than your disk has bad sectors, the VS2000 formatter seems to hang in the media analysis phase!
surfaces (aka heads) per drive. Note that the RQDX? will ALWAYS assume 17 sectors per track, 512 bytes per sector! The RQDX controllers can handle a maximum of 16 heads.
cylinders per drive. Total number of cylinders on the drive. I believe, but I'm not sure, that this does NOT include the cylinders used for DBNs, RBNs and XBNs. Note that the RQDX family controllers can handle a maximum of 2048 cylinders (but I don't think there were ever any MFM drives made with even close to that number!).
cylinder to start write precompensation. If your drive doesn't need write precomp (almost none do), then enter a value larger than the last cylinder.
size of the Replacement (i.e. Bad Block Replacement) and Caching Table. From the structure of the RCT, I believe this can be calculated as
RCTSIZ = (44 + 4*RBNSIZ) / 512
but unfortunately this doesn't give the values DEC uses for their drives! You could also just use the RCTSIZ from the closest sized DEC disk.
number of copies of the RCT. I'm not sure of the significance of this, but DEC disks always use 8.
sector to sector interleave. The RQDX is fast enough to support 1 (i.e. no interleaving). Anything larger will reduce thruput. SECITL is a function of the disk rotational speed, and is the same for all MFM drives regardless of capacity.
delay for switching heads. I don't know how to calculate this or even what units it's expressed in! All drives seem to use 2.
- delay for track-to-track seek. I don't know how to calculate this or even what units it's expressed in! All DEC drives use 8.
media identification code. This is a 32 bit value which the ROM wants you to enter in DECIMAL, not hex! Standard values are:
RD32 - 627327008
RD33 - 627327010
RD53 - 627327029
RD54 - 627327030

The last section explains how the media id is calculated if you are interested. If you use a non-DEC media id, be aware of two things: (1) the ROM disk diagnostic won't work, and (2) the VMS MSCP cluster server won't serve the disk.

The media id is a longword (32 bit) value composed of five 5-bit alphabetic characters and one 7-bit binary value. The five characters start from bit 31 (the MSB) of the longword and are encoded as 0=null, 1='A', 2='B', etc. Only letters (and a null) can be represented.

The first two characters represent the media type (e.g. "DU") and the next three are the name of the media currently mounted (e.g. "RD").

The 7-bit binary value is the numeric part of the media name (e.g. 32, 53, 54, etc).

For example, for an RD54 we have

D U R D  54

Write this down as a 32 bit hex value and we have 0x25644036 or 627327030 (decimal).

Here are the parameter values for some DEC disks, and those that I've successfully used for a Seagate ST-4097 (an 80Mb drive).

 RD54 RD53 ST4097
XBNSIZ 54 54 54
DBNSIZ 201 82 99
LBNSIZ 311256 138672 156060
RBNSIZ 609 280 306
SURPUN 15 8 9
CYLPUN 1221 1020 1021
WRTPRC 1221 1020 1024
RCTSIZ 7 5 5
RCTNBR 8 8 8
SECITL 1 1 1
STSSKW 2 2 2
CTCSKW 8 8 8
MEDIAI 627327030 627327029 627327029

Floppy disk

A floppy disk drive can be installed in the main box. The floppy drive connector looks like a standard PC 5 1/4 inch drive connector. Using it with a PC 5 1/4 drive failed, though. The ROM formatter can format RX33 floppy disks:

    >>>> TEST 70
    VSfmt_QUE_unitno (0-2) ? 2      [enter the drive number of the floppy drive]
    ( 1=RX33 ) ? 1                  [enter a 1 if RX33 diskette media]
    VSfmt_QUE_RUsure (DUA2 1/0) ? 1 [enter a 1 for yes, 0 for no]
                                    [DUA0 is the first hard disk, DUA1 the second, and DUA2 is the floppy drive]
    VSfmt_STS_FMTing .....OK        [diskette formatted OK]
    VSfmt_STS_CkRXfmt ....OK        [RX33 format checked OK]
    VSfmt_RES_Succ                  [diskette is formatted successfully]


Brian Schenkenberger says that the 9-pin connector is the console port, and that plugging in a BCC08 cable and a terminal will get me access to the console. Ehud Gavron, Chad Maloney, and Roger Ivie expand this explanation, stating that not only is the 9-pin printer port a serial port, but that there are also two more serial ports embedded in the video console connector, for a total of three serial ports: TTA0, TTA1, and TTA2. If a video console is attached, the two embedded ports are connected to the keyboard and the mouse. I'm assuming that TTA0 and TTA1 are the two embedded connectors (which explains why I haven't gotten my terminal to show anything yet under NetBSD...I'm trying to spawn a getty to tty00, not tty02).

Mr. Maloney and Mr. Gavron go on to say that the 25-pin connector is used to connect a BA40 expansion box. The BA40 has connectors for a TK50 drive and for the old-style "3 rows of pins" SCSI disk connectors for RD54/RD53/RD52 hard disk drives (this style of connector is also common on old Sun workstations, in my experience). Without the expansion unit, I will be unable to connect other SCSI devices to this machine.

Gregg Economou mentions a switch that activates the serial console on the printer port. He also says that the 25-pin communications port is only useful for hooking up a TKZ50 and isn't a 100% SCSI.

Using SCSI disks

Wolfgang Moeller describes a 50-pin on-board SCSI connector. However, the VS2000 does not know how to boot from SCSI disks, only from the TK50 (and variants) tape drive, certain models of which are hard-wired to ID 1 (and can be booted via the BOOT MUA0 command). Mr. Moeller says it may be possible to cross-boot VMS from a small internal disk to an external SCSI disk. He's written an experimental generic SCSI driver for VMS version 5.5-2 called 'PK2KDRVR', available from

From the README:

PK2K_0013-BIN.ZIP Binaries for VMS V5.5-2, plus the README (slight update from the 0012 version).
PK2K_0013-BIN.README (ASCII!) Usage notes for the V5.5-2 version. Applies equally well to the following kits, with the respective VMS version substituted for "V5.5-2".
PK2K_0013-061BIN.ZIP Binaries for oVMS V6.1
PK2K_0013-062BIN.ZIP Binaries for oVMS V6.2
PK2K_0013-071BIN.ZIP Binaries for oVMS V7.1
PK2K_0013-072BIN.ZIP Binaries for oVMS V7.2 (NEW!)
PK2K-BOOT_0013.ZIP "Secondary VMB" SYSBOOT images for booting into a SCSI disk, to be loaded via DUAn: or ESA0:
KA410W_V23_ROM-0013.PATCH (ASCII!) PATCH command file for improving upon the "KA410-B V2.3" ROM, allowing it to boot from SCSI disks, instead of "MUA0". The bootstrap code within is identical to the one in PK2K-BOOT_0013.ZIP .

PK2KDRVR is a driver for the Vs2000/uVAX2000 SCSI port (traditionally known as the "tape controller port").

>>> EXPERIMENTAL software, NO WARRANTIES at all! <<<

Apart from one `feature' and one restriction mentioned next, it _ought_ to behave just like the Vs3100 SCSI driver (PKNDRIVER).

SCSI host id determination

The SCSI host adapter _by_default_ used the SCSI id 0 (not 6 or 7, as customary with other SCSI adapters), meaning you can't use a device on the bus with this id. This setting can be checked from the ">>> T 50" display, which under "TPC" shows a longword for each of the SCSI ids 0..7 - the host id is indicated by a longword of FFFFFF03. Analogous to the ">>> SET SCSI[A]" commands found with other VAXen, the setting can be changed permanently (saved in NVRAM), in a somewhat non-intuitive way:

Host ID Enter at the >>> prompt ...
7 D/U/P 200B00BC 1C
6 D/U/P 200B00BC 18
5 D/U/P 200B00BC 14
4 D/U/P 200B00BC 10
3 D/U/P 200B00BC 0C
2 D/U/P 200B00BC 08
1 D/U/P 200B00BC 04
0 D/U/P 200B00BC 00

Note: The `field sevice utility' ">>> T 73" (or better, ">>> T 20000073"), aka. "tpmker", does not correctly cope with a non-zero host id. This is a ROM bug. T 73 likely has little use to anyone these days.

Known restriction

PK2KDRVR won't do data transfers of 16kB or more.

This has the effect of limiting the block size that can be used with SCSI tapes, and also will break any program that _attempts_ to read 16kB or more. The only VMS program that does so (which I'm aware of) is DUMP - see below for a patch.


This is *EXPERIMENTAL* SOFTWARE that theoretically *could* not only crash your system, but *could* cause CORRUPTION on all media connected to the computer on which it's installed. (In fact, PK2KDRVR has plenty of code that *attempts* to crash the system if a chance for corruption gets noticed. I haven't observed any problem, let alone a crash, with PK2K on VMS V5.5-2, since the release of V1.2 in late August 1997, in spite of trying pretty hard :-) Fact is, the Vs2000/uVAX2000 hardware has never been "qualified" by anyone to work correctly with SCSI devices.

>>> NO WARRANTIES at all! <<<

Installation & use

*** This is for VMS V5.5-2 only ***

The "binary kit" contains PK2KDRVR.EXE (not spelled PK2KDRIVER for quite "technical" reasons) plus 5 patch command files.




to create 2KSYSGEN.EXE in the current directory.

Make sure that no MUA0 shows up, and that TVDRIVER (the Vs2000/uVAX2000 magtape driver) is _not_ loaded.



to load PK2KDRVR (ought to show up as device PKA0) and autoconfigure the SCSI devices, just like on a Vs3100.

If you're confident enough in the driver that you want the machine to auto-configure the SCSI at boot time, create two more programs (which _may_ only be required if the machine is a cluster member),

and copy

Each of these programs supposedly behaves just like the VMS "original", when executed on a VAX other than a Vs2000 or uVAX2000.

For completeness' sake, there are two more patch command files that create PK2K-aware versions of STASYSGEN.EXE and STANDCONF.EXE . Both of these are only used by stand-alone BACKUP - in order to build a PK2K-aware kit, place the patched programs into SYS$SYSTEM under the original name, and modify SYS$UPDATE:STABACKIT-TABLE.DAT by replacing "TVDRIVER.EXE" with "PK2KDRVR.EXE". You may also wish to change STABACKIT.COM such that it accepts generic SCSI tape (devtype 28) and on that occasion make it refer to a differently named *-TABLE.DAT - I did find a non-DEC DAT drive from which a Vs2000 did boot, with the tape configured as MKA100 (">>> B MUA0" expects the tape to have a SCSI id of 1).

Lastly, there's 2KDUMP.COM which will create 2KDUMP.EXE via $ PATCH @2KDUMP.COM

Use the result instead of the original SYS$SYSTEM:DUMP.EXE in order to DUMP blocks from a SCSI tape drive, e.g. via

		$ DUMP MKAu00:

or similar. Contrary to standard DUMP, 2KDUMP will - independent of hardware - read at most 16k-1 bytes per tape block (no big deal :-).

Using the secondary bootstrap to boot into a SCSI disk

Changes over V0.10 (22-feb-1999):

The secondary bootstrap image comes in 2 versions:

- 2KVMB.EXE (linked /SYSTEM=0/HEADER) for loading via ethernet: Copy this image on some MOP server, then

$ MCR NCP SET NODE {Vs2000} HARD ADDR {xx-xx-xx-xx-xx-xx} -
  LOAD FILE {dev}:[{dir}]2KVMB.EXE 

Boot the {Vs2000} via

    >>> B/{flags} ESA0

with {flags} being those that you'd like to use with "B DKAn00" if that command existed. Once 2KVMB runs, it prompts for "Boot device:" - reply with "DKAn" (it understands only 4 characters) to mean the SCSI disk known as "DKAn00:" to VMS. 2KVMB will then boot from the SCSI disk so named, expecting to find SYS$LOADABLE_IMAGES:PK2KDRVR.EXE there (plus the rest of VMS :-).

- 2KVMB-SYSBOOT.EXE (linked /SYSTEM=0/NOHEADER) for loading from a disk bootable via ROM ('DUA0','DUA1' = "RD" type MFM disk, 'DUA2' = RX33-compatible floppy disk).

Make this image (contiguously, as it already is) available as DUA{x}:[SYS{k}.SYSEXE]SYSBOOT.EXE in order to be able to boot into DKAn00:[SYS{k}], {k} being the system root 'number'. (CAREFUL - don't use a system root that exists on DUA{x}!)

    >>> B/{flags} DUA{x}

will then load this image, which will prompt for "Boot device:" as above, and boot into DKAn00: if you reply "DKAn" as above. The boot {flags} specified apply to both the 'primary' and the 'secondary' boot. They would be e.g. {k}0000001 (i.e. 8 hex digits) for an 'interactive' boot into [SYS{k}].


The 'source code' is mostly the product of DISM32 (old DECUS tool, available these days from archives like etc)- I didn't understand (or even read) most of 2KVMB.MAR, but added a few comments nonetheless. 2KBTDRIVER.MAR is the only thing that you can hold me responsible for, but it's also largely based on TVBTDRIVER from the "KA410-B V2.3 ROM".

Installing VMS

Personally I have installed VMS 5.5-1 from a TK50 tape via the second box containing the TK(Z)50 drive, which is connected to the main box by a "SCSI type" cable. I also installed VMS 6.1 and VMS 7.2 on SCSI-Disks using the SCSI-drivers mentioned above.

General notes about installing VMS: The VMS system software is distributed in BACKUP savesets. These are usually named something like VMS055.x where x are letters starting from A. In general, DEC VMS distributions come in files like XXXYYY.Z where XXX is the code for the product, YYY is the version number and Z is a letter from A-Z. In the VMS install savesets, the .A saveset is the upgrade saveset, and the .B saveset is for a fresh install. If the VAX supports booting from an install medium (like TK50 tape or CDROM) then these media are usually bootable from the VAX boot prompt. For a standalone VS2000 you need a device to boot the install media from. I have a second box with a TK50 drive and thats where I installed VMS 5.5 from. To boot from the tape, you would enter B MUA0 from the boot prompt.

VAXstations can be booted over Ethernet. I ran a complete Netbsd vax system only via Ethernet with remote MOP boot and the filesystem mounted from a Pentium I machine running Linux 2.2.19. To remote boot, use

>>> B ESA0
from the ROM "chevron" prompt.

I have rebuilt the inside of my VS2000. It now contains a TEAC 5 1/4" HD floppy drive (standard PC drive), which is called RX33 in DEC terms. The other drive in it is a small SCSI drive large enough to hold VMS 5.5-2 just in case it is needed. The machine can still boot independently by loading a patched, SCSI enabled secondary bootstrap from the floppy drive and then booting into the SCSI drive. Now that I have a VAXstation 4000 VLC, it can boot VMS as a cluster member off the VLC. The machine is a bit faster and makes less noise now.

A Hobbyist License can be obtained and there is a CD-ROM from Montagar Software Concepts available containing VMS 7.3. To get a hobbyist licens membership in a DECUS chapter is required, but DECUS membership is free, at least in DECUS Germany (see DECUS Germany), DECUS US is now called ENCOMPASS


  1. Formatting harddisks by Bob Armstrong with additions from Kees Stravers and contributions by Terry Kennedy, Lennart Boerjeson
  3. VMS device support manuals
  4. SCSI disk driver by Wolfgang J. Möller, Göttingen, F.R.Germany,