DEC VAX History

VAX ARCHITECTURE HANDBOOK Architecture For The 80's, from 1981.
Chapter 1 is entitled VAX: COMPUTERS FOR THE '80s and has a picture
of a VAX-11/750 in front of a VAX-11/780.

The chapter starts by explaining that
The letters VAX suggest the premier feature of VAX
computers - Virtual Address eXtension. In a VAX computer,
bytes of information are located with a 32-bit address.
and continues that
From the programmers's point of the bottom two billion bytes of
virtual address space can be used for programs, and he or she need
never worry about complicated techniques of overlaying or segmenting
to squeeze the program into a smaller address range.
The book has Roman numeral pages
to x, and then takes 506 pages to describe the VAX instruction set.

The VAX ARCHITECTURE HANDBOOK had this picture on the inside front cover.

VAX-11 Architecture Reference Manual, 20 May 1982, Revision 6.1,
part number EK-VAXAR-RM-001. This manual describes the instruction
sets used by the VAX-11/780 and the later VAX-11/750.
It contains both the native VAX instructions and the PDP-11 compatibility
instructions.

The manual is in a courier font and starts:
CHAPTER 1
INTRODUCTION
1-Feb-80 -- Rev 6
1.1 INTRODUCTION
VAX-11 represents a significant extension of the PDP-11 family
architecture. It shares with the PDP-11 byte addressing, similar I/O
and interrupt structures, and identical data formats. Although the
instruction set is not strictly compatible with the PDP-11, it is
related, and can be mastered easily by a PDP-11 programmer. Likewise
the similarity enables straightforward manual conversion of existing
PDP-11 programs to VAX-11. Existing user mode PDP-11 programs which do
not need the extended features of VAX-11 can run unchanged in the PDP-11
compatibility mode provided in VAX-11.
As compared to the PDP-11, VAX-11 offers a greatly extended virtual
address space, additional instructions and data types, and new
addressing modes. Also provided is a sophisticated memory management
and protection mechanism, and hardware assisted process scheduling and
synchronization.
A number of specific goals guided the VAX-11 design:
1. Maximal compatibility with the PDP-11 consistent with a
significant extension of the virtual address space, and a
significant functional enhancement.
2. High bit efficiency. This is achieved by a wide range of data
types and new addressing modes. PDP-11 programs naively
tranlated to VAX-11 should not grow significantly in size;
while programs redesigned to exploit VAX-11 should get smaller
despite the extended virtual address space.
3. A systematic, elegant instruction set with orthogonality of
operators, data types, and addressing modes. This enables the
instruction set to be exploited easily, particularly by high
level language processors.
4. Extensibility. The instruction set is designed so that new
data types and operators can be included efficiently and in a
manned consistent with the currently defined operators and data
types.
5. Range. The architecture should be suitable over the entire
range of PDP-11 computer system implementations currently sold
by Digital Equipment Corporation.

SELF-MAINTENANCE HANDBOOK, part number EK-24818-75/83, from 1983.
This book explained how to do simple remedial and preventative maintenance
and how to estimate how many spare parts to stock.
When you bought DEC hardware, you usually needed to purchase a maintenance
contract. The prices of the contract increased with the age of the system
to try to push you into buying new systems every few years.
We dropped maintenance on our VAXen after the contract cost us more than
the price of buying a new PC each year and running SCO Unix on it,
and the PC that we could have bought would have run faster than any of our VAXen.

VAX-11 PASCAL Language Summary, part number AV-L368A-TE from
the first printing in October, 1982.
In 1984, we ported our programs from Oregon Pascal-2 and DEC's F4P Fortran compiler
under RSX-11M to VAX-11 Pascal and VAX-11 Fortran under VAX/VMS V3.
The VAX Pascal and Fortran compilers were both solid.
VAX Pascal programs often needed to start with the line [inherit ('sys$library:starlet.pen')]
to import the definitions of VMS routines, similar to the C headers under /usr/include
on unix systems.
VAX Pascal supported pre-compilation. .pen files were pre-compiled .pas files.
The linker automatically included the library starlet.olb,
similar to the way that linkers on unix systems include libc.a.
DEC's code name for the VAX-11/780, the first VAX model, was "star",
and DEC's code name for VMS was "starlet".
DEC apparently left the names of those files unchanged when it renamed the
operating system to VMS.
DEC later renamed VMS to OpenVMS. http://www.openvms.org/http://www.openvmshobbyist.org/
When you pronounce OpenVMS, the Open is silent.
VMS survived Compaq's buy-out of DEC and HP's buy-out of Compaq. http://www.openvms.compaq.com/
HP even ported OpenVMS to the Itanium in early 2002.

VAX-11 C Language Summary, part number AA-P788A-TE
from the first printing in March 1983.
DEC added the non-standard storage class specifiers globaldef,
globalref, globalvalue, and readonly
that usually required adding VMS-specific #ifdef's.
Also, VMS text files were variable length records with a two-byte
length, then text, then an optional null to pad the line to an
even number of bytes. This did not work well with C's concept of
streamed files. DEC eventually added a streamlf file type
that worked better with C, but to get any reasonable performance
from C programs, you had to do all of the I/O through RMS calls
instead of the VAX C run times.

VAX DSR Quick Reference Guide for VMS 4.0, part number AV-Z002A-TE,
from 1984. DSR stands for Digital Standard Runoff,
a text formatter similar to roff.

VAX DEC/MMS guide for the VAX MODULE MANAGEMENT SYSTEM,
DEC's version of make, part number EA-27160-84
from 1984.

VAX DEC/Shell guide, part number EA-30307-84 from 1984.
DEC/Shell was a VAX command line interpreter (CLI) that
provided an interface similar to the Unix V7 Bourne shell.

VAX Language-Sensitive Editor VAX C Pocket Guide,
part number AA-EV41A-TE, from the first printing in March 1985,
for VAX/VMS V4.0 or later,
software version VAX Language-Sensitive Editor V1.0.
This editor used an EDT-like keypad, but showed tokens
like [@comment@]... that you could expand.
I edited programs with the standard EDT editor and later
with my hacked version of microEmacs ftp://ftp.newspapersystems.com/pub/binaries/src/,
and a few people used TPU (DEC's Text Processing Utility),
but I think that we never used the LSE.

The Digital Technical Journal, issue number 2 from March, 1986,
with a focus on the MicroVAX II. The cover picture is the input
programmable logic array of the VLSI 78132 FPU used in the MicroVAX II.
(The first issue from Auguest, 1985 covered the VAX 8600.)

The original VAX-11/780 and VAX-11/750 had multi-chip CPU's that
filled an entire circuit board. In the MicroVAX series,
DEC stripped down CPU to make it fit on a single chip.
In order to reduce time to market, the MicroVAX I actually
used several semicustom logic chips. At the same time,
another team started the design of the single-chip MicroVAX II cpu.
MicroVAXen do not support PDP-11 emulation, and they run some
of the more complicated instructions through handlers in software traps
rather than in microcode.
Specifically, the MicroVAX CPU does not implement floating point instructions,
packed decimal instructions, or character string instructions (except MOV3C and
MOV5C, which were preserved to allow efficient ways to copy and fill memory areas).
DEC ran a simulation of instruction usage to see which instruction to keep
in microcode and which to move to software emulation.
Also, DEC wrote MicroVAX versions of their compilers that avoided the
emulated instructions. Supposedly, they missed some of the string instructions
that the COBOL compiler generated, so COBOL programs ran very slowly
on MicroVAXen.

The RQDX3 was a Q-Bus controller for floppy and Winchester
(i.e. hard disk) drives.
The original VAX-11/780 and VAX-11/750 used Unibus backplane,
the same as the larger PDP-11 models like the PDP-11/45 and PDP-11/70.
Unibus cards were large, maybe about two feet by three feet
(60 cm X 90 cm).
Also, the order of the Unibus cards in the backplane was critical.
If you placed the cards in the wrong order, the system might crash
or not even boot at all. If a Unibus system was running OK,
the rule was that you did not touch any of the cards.
The MicroVAXen used a smaller Q-Bus backplane, the same
as the smaller PDP-11 models like the PDP-11/23 and PDP-11/73.
(SCS had a 73 and a few 23's. The node name of our 73 was piglet.)
The Q-Bus cards were about 1 ft X 2 ft (30 cm X 60 cm).

The evil TK50 tape drive used a CompacTape Cartridge that contained
600 feet (about 183 m) of half-inch magnetic tape on a single spool.
A cartridge could hold up to 100 MB.

VAXen ran VMS, VAXELN and Ultrix.
We ran VMS on our VAX-11/750 and MicroVMS on our MicroVAX II systems.
VAXELN was a real-time operating system.
Ultrix-32 was DEC's version of Unix.
It was based on the 4.2 BSD release.
DEC started development on Ultrix-32 in fall 1983 and
released V1.0 in April 1984.

Version 4.4 VAX/VMS Internals and Data Structures,
part number EY-8264E-DP, ISBN 1-55558-008-4, from 1988,
by Lawrence J. Kenah, Ruth E. Goldenberg, and Simon F. Bate.
This nearly 1000-page tome contained more than you would
ever want to know about VMS. For example, section 20.1
starting on page 549 details the 25 phases that the $CREPRC
system service passes through as it creates
a new process. Unlike Unix, where a fork() call takes
only a few milliseconds, on VMS, creating a process could take
over a minute if you had lots of symbols and logical names defined.
Packages for VMS that attempted to provide Unix-like shells would
usually keep a cache of reusable ready-made processes.

The older PDP-11's could use 8" floppy disks.
You had to buy pre-formatted disks from DEC.
This is a DEC 8" floppy disk on the left in comparison
with a CD ROM, a 5 1/4" floppy disk, and a 3 1/2" floppy disk
on the right.

VMS was a fairly solid operating system.
Unlike any version of MS Windows, it was possible to make VMS secure,
and unlike most versions of Unix, VMS came secure "out of the box"
(provided you changed the default DEC field service and system manager
accounts).
VMS used DECnet instead of tcp/ip.
We purchased a tcp/ip package from CMU/Tek.
Our VAXen usually went down only once or twice a year wen
we lost power due to storms. The VAXen needed three phase power
and would have needed a very expensive UPS.
The only other problem we had was running
kermit http://www.columbia.edu/kermit on the console.
The VMS console driver was different from the other serial port drivers.
It was simpler and apparently was not designed for high rates of input.
It could handle normal typing speeds, but if you ran kermit on the console,
connected to another system, and then ran a command that generated a lot
of output, a directory listing for example, VMS would crash very hard.
A support call came during an important demo on April 11, 1986,
and to avoid interfering with the demo, JPM took the call from the back room
with the consoles. He promptly fired up kermit on the console of the VAX
running for the demo, dialed in, connected, did a directory listing,
and crashed the VAX. After we rebooted, we had to do an unplanned demo
of the procedures to recover after a crash. That evening, I added
the RECOVER option for the Layout FIN program.

When we first worked on the SCS-8000 editorial system in the mid 1980's,
we used specially modified vt220 clones by Teleray that cost $1400 each.
The terminal had special horizontal and vertical split-screen scrolling modes.
Customers used to call our system the Teleray system because they
saw only the Teleray terminals. Once the system worked dependably,
we covered up the Teleray label with a silvery SCS nameplate.
You can see the SCS nameplate at the lower right of the screen.

To reduce the number of keystrokes needed to enter special characters,
each key had a shift, a supershift, and a shift-supershift so that
it could generate four characters.

This is the front of a Falco Infinity Hi-Speed terminal.
We mostly used Falco vt220 clones on our VAX and early Unix systems.
We had Falco modify them to accept sixel graphic streams
from ghostscript http://www.ghostscript.com
so we could display postscript graphics.

Falco, left side view.

Falco, right side view.

We think that we put Falco out of business by asking them fix their terminals
so that they emulated vt220's as advertised.
A few companies like Micro Technologies International http://www.mticom.com
still work with old Falcos.

The old serial ports had a connector conspiracy where the port that you
needed to plug into would always be the wrong sex for the cable, and then if you
were lucky enough to have a cable with the correct sex, the flow control pins
(mostly pins 2 and 3) would be reversed. We used to make use of these DEC break-out
boxes to test pin connections before making new cables. Sometimes, we would just
keep using the break-out box semi-permanently until we had a more urgent need for
its services.

The business end of a break-out box.

A box of patch cables for break-out boxes.
The orange box is the same as the green box except that it has
8" orange cables while the green box has 32" green cables.
The label says
digital MODULE ACCESSORY
10 DIGITAL PATCH CORDS
Miniature Stacking Banana Jacks
Part Number 911 -- 8" Orange
DIGITAL EQUIPMENT CORPORATION
MAYNARD, MASSACHUSETTS