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.

History of Pascal on small machines http://pascal.hansotten.com/ and on VAXen http://pascal.hansotten.com/vaxvms-pascal/

VAX Pascal manual from Feb 1987 https://bitsavers.org/pdf/dec/vax/lang/pascal/AI-H485E-TE_VAX_PASCAL_User_Manual_Feb87.pdf

VAX-11 Programming Card, part number AV-D827B-TE from 1983. This 58 page booklet described the VAX instruction set. The VAX is the classic example of a CISC machine. For example, it has an op code for generating the CRC of a data block http://web.archive.org/web/20021008050711/http://www.rtfm.net/vax/vax-crc.html http://rtfm.net/vax/vax-crc.html . The instruction set has over 256 op codes. It uses almost all of the single bytes and a few double bytes and has almost 64 different addressing modes.

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

Here is the table of contents:
8 Forward Jeffrey C. Kalb
12 The MicroVAX 78032 Chip, A 32-Bit Microprocessor Daniel W. Dobberpuhl, Robert M. Supnik, Richard T. Witek
23 The MicroVAX 78132 Floating Point Chip William R. Bidermann, Amnon Fisher, Burton M. Leary, Robert J. Simcoe, William R. Wheeler
37 Debugging the MicroVAX II CPU Board Barry A. Maskas
48 The Evolution of the Custom CAD Suite Used on the MicroVAX II System Anthony F. Hutchings
56 The Making of a MicroVAX Workstation Rich Spitz, Peter George, Stephen Zalewski
66 The RQDX3 Design Project Nicholas A. Warchol, Stephen F. Shirron
76 The Evolution of Instruction Emulation for the MicroVAX Systems Kathleen D. Morse, Lawrence J. Kenah
86 The TK50 Cartridge Tape Drive Steven E. Boone, Guenter E. Schneider
99 Porting ULTRIX Software to the MicroVAX System Raymond J. Lanza

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.

Hunter Goatley's VMS freeware http://www.goatley.com/hunter hosted by Process Software http://www.process.com

Seven Sages Vax Archive http://vax.sevensages.org

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.

Side view.

Back view.

Close-up of the ports on the back.

Teleray Model 20 DDG Operators Manual, Edition 1.2, Publication Number KA069887-1 from 1984, by Teleray The MultiProtocol Terminal Company, a division of Research, Inc. This manual describes the terminal setup and the escape codes.

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.

For more on Falco and other old terminals, see http://www.cs.utk.edu/~shuford/terminal/various.html

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

https://groups.google.com/g/comp.os.vms/c/IMWn2Fg46VA
Why Is Wednesday November 17, 1858 The Base Time For VAX/VMS?
November 17, 1858 is the base of the Modified Julian Day system.
The original Julian Day (JD) is used by astronomers and expressed in days since noon January 1, 4713 B.C. This measure of time was introduced by Joseph Scaliger in the 16th century. It is named in honor of his father, Julius Caesar Scaliger (note that this Julian Day is different from the Julian calendar named for the Roman Emperor Julius Caesar!).
Why 4713 BC? Scaliger traced three time cycles and found that they were all in the first year of their cyle in 4713 B.C. The three cycles are 15, 19, and 28 years long. By multiplying these three numbers (15 * 19 * 28 = 7980), he was able to represent any date from 4713 B.C. through 3267 A.D. The starting year was before any historical event known to him. In fact, the Jewish calendar marks the start of the world as 3761 B.C. Today his numbering scheme is still used by astronomers to avoid the difficulties of converting the months of different calendars in use during different eras.
So why 1858? The Julian Day 2,400,000 just happens to be November 17, 1858. The Modified Julian Day uses the following formula:
MJD = JD - 2,400,000.5
The .5 changed when the day starts. Astronomers had considered it more convenient to have their day start at noon so that nighttime observation times fall in the middle. But they changed to conform to the commercial day.
The Modified Julian Day was adopted by the Smithsonian Astrophysical Observatory (SAO) in 1957 for satellite tracking. SAO started tracking satellites with an 8K (non-virtual) 36-bit IBM 704 computer in 1957, when Sputnik was launched. The Julian day was 2,435,839 on January 1, 1957. This is 11,225,377 in octal notation, which was too big to fit into an 18-bit field (half of its standard 36-bit word). And, with only 8K of memory, no one wanted to waste the 14 bits left over by keeping the Julian Day in its own 36-bit word. However, they also needed to track hours and minutes, for which 18 bits gave enough accuracy. So, they decided to keep the number of days in the left 18 bits and the hours and minutes in the right 18 bits of a word.
Eighteen bits would allow the Modified Julian Day (the SAO day) to grow as large as 262,143 ((2 ** 18) - 1). From Nov. 17, 1858, this allowed for seven centuries. Using only 17 bits, the date could possibly grow only as large as 131,071, but this still covers 3 centuries, as well as leaving the possibility of representing negative time. The year 1858 preceded the oldest star catalog in use at SAO, which also avoided having to use negative time in any of the satellite tracking calculations.
This base time of Nov. 17, 1858 has since been used by TOPS-10, TOPS-20, and VAX/VMS. Given this base date, the 100 nanosecond granularity implemented within VAX/VMS, and the 63-bit absolute time representation (the sign bit must be clear), VMS should have no trouble with time until:
31-JUL-31086 02:48:05.47
At this time, all clocks and time-keeping operations within VMS will suddenly stop, as system time values go negative.
Note that all time display and manipulation routines within VMS allow for only 4 digits within the 'YEAR' field. We expect this to be corrected in a future release of VAX/VMS sometime prior to 31-DEC-9999.

DEC Answers Leap Year Complaint https://www-users.cs.york.ac.uk/susan/joke/decly.htm