TOPS-20 began in 1969 as the TENEX operating system of Bolt, Beranek and Newman (BBN) and shipped as a product by DEC starting in 1976.[2] TOPS-20 is almost entirely unrelated to the similarly named TOPS-10, but it was shipped with the PA1050 TOPS-10 Monitor Calls emulation facility which allowed most, but not all, TOPS-10 executables to run unchanged. As a matter of policy, DEC did not update PA1050 to support later TOPS-10 additions except where required by DEC software.

Contents

In the 1960s, BBN was involved in a number of LISP-based artificial intelligence projects for DARPA, many of which had very large (for the era) memory requirements. One solution to this problem was to add paging software to the LISP language, allowing it to write out unused portions of memory to disk for later recall if needed. One such system had been developed for the PDP-1 at MIT by Daniel Murphy before he joined BBN. Early DEC machines were based on an 18-bit word, allowing addresses to encode for a 262-kword memory. The machines were based on expensive core memory and included nowhere near the required amount. The pager used the most significant bits of the address to index a table of blocks on a magnetic drum that acted as the pager's backing store, and the software would fetch the pages if needed and then re-write the address to point to the proper area of RAM.

In 1964 DEC announced the PDP-6. DEC was still heavily involved with MIT's AI Lab, and many feature requests from the LISP hackers were moved into this machine. 36-bit computing was especially useful for LISP programming because with an 18-bit address space, a word of storage on these systems contained two addresses, a perfect match for the common LISP CAR and CDR operations. BBN became interested in buying one for their AI work when they became available, but wanted DEC to add a hardware version of Murphy's pager directly into the system. With such an addition, every program on the system would have paging support invisibly, making it much easier to do any sort of programming on the machine. DEC was initially interested, but soon (1966) announced they were in fact dropping the PDP-6 and concentrating solely on their smaller 18-bit and new 16-bit lines. The PDP-6 was expensive and complex, and had not sold well for these reasons.

It was not long until it became clear that DEC was once again entering the 36-bit business with what would become the PDP-10. BBN started talks with DEC to get a paging subsystem in the new machine, then known by its CPU name, the KA-10. DEC was not terribly interested. However, one development of these talks was support for a second virtual memory segment, allowing part of the user address space to be mapped to a separate (potentially read-only) region of physical memory. Additionally, DEC was firm on keeping the cost of the machine as low as possible, such as supporting bare-bones systems with a minimum of 16K words of core, and omitting the fast semiconductor register option (substituting core), at the cost of a considerable performance decrease.

BBN nevertheless went ahead with its purchase of several PDP-10s, and decided to build their own hardware pager. During this period a debate began on what operating system to run on the new machines. Strong arguments were made for the continued use of TOPS-10, in order to keep their existing software running with minimum effort. This would require a re-write of TOPS to support the paging system, and this seemed like a major problem. At the same time, TOPS did not support a number of features the developers wanted. In the end they decided to make a new system, but include an emulation library that would allow it to run existing TOPS-10 software with minor effort.

The developer team—amongst them Daniel Murphy and Daniel G. Bobrow—chose the name TENEX (TEN-EXtended) for the new system. It included a full virtual memory system—that is, not only could programs access a full 262kwords of memory, every program could do so at the same time. The pager system would handle mapping as it would always, copying data to and from the backing store as needed. The only change needed was for the pager to be able to hold several sets of mappings between RAM and store, one for each program using the system. The pager also held access time information in order to tune performance. The resulting pager was fairly complex, filling a full-height 19" rackmount chassis.

One notable feature of TENEX was its user-oriented command line interpreter. Unlike typical systems of the era, TENEX deliberately used long command names and even included non-significant noise words to further expand the commands for clarity. For instance, Unix uses ls to print a list of files in a directory, whereas TENEX used DIRECTORY (OF FILES). "DIRECTORY" was the command word, "(OF FILES)" was noise added to make the purpose of the command clearer. To relieve users of the need to type these long commands, TENEX used a command completion system that understood unambiguously abbreviated command words, and expanded partial command words into complete words or phrases. For instance, the user could type DIR and the escape key, at which point TENEX would replace DIR with the full command. The completion feature also worked with file names, which took some effort on the part of the interpreter, and the system allowed for long file names with human-readable descriptions. TENEX also included a command recognition help system: typing a question mark (?), printed out a list of possible matching commands and then return the user to the command line with the question mark removed. The command line completion and help live on in current CLIs like tcsh.

TENEX became fairly popular in the small PDP-10 market, and the external pager hardware developed into a small business of its own. In early 1970 DEC started work on an upgrade to the PDP-10 processor, the KI-10. BBN once again attempted to get DEC to support a complex pager with indirect page tables, but instead DEC decided on a much simpler single-level page mapping system. This compromise impacted system sales; by this point TENEX was the most popular customer-written PDP-10 operating systems, but it would not run on the new, faster KI-10s.

To correct this problem, the DEC PDP-10 sales manager purchased the rights to TENEX from BBN and set up a project to port it to the new machine. At around this time Murphy moved from BBN to DEC as well, helping on the porting project. Most of the work centered on emulating the BBN pager hardware in a combination of software and the KI-10's simpler hardware. The speed of the KI-10 compared to the PDP-6 made this possible. Additionally the porting effort required a number of new device drivers to support the newer backing store devices being used.

Just as the new TENEX was shipping, DEC started work on the KL-10, intended to be a low-cost version of the KI-10. While this was going on, Stanford University AI programmers, many of them MIT alumni, were working on their own project to build a PDP-10 that was ten times faster than the original KA-10. The project evolved into the Foonly line of computers. DEC visited them and many of their ideas were then folded into the KL-10 project. The same year IBM also announced their own machine with virtual memory, making it a standard requirement for any computer. In the end the KL integrated a number of major changes to the system, but did not end up being any lower in cost. From the start, the new DECSYSTEM-20 would run a version of TENEX as its default operating system.

Functional upgrades for the KL-10 processor architecture were limited. The most significant new feature (called extended addressing) was modified pager microcode running on a Model B hardware revision to enlarge the user virtual address space. Some effective address calculations by instructions located beyond the original 18-bit address space were performed to 30 significant bits, although only a 23-bit virtual address space was supported. Program code located in the original 18-bit address space had unchanged semantics, for backward compatibility.

The first in-house code name for the operating system was VIROS (VIRtual memory Operating System); when customers started asking questions, the name was changed to SNARK so that DEC could truthfully deny that there was any project called VIROS. When the name SNARK became known, the name was briefly reversed to become KRANS; this was quickly abandoned when someone objected that "krans" meant "funeral wreath" in Swedish (though it simply means "wreath"; this part of the story may be apocryphal).

Ultimately DEC picked TOPS-20 as the name of the operating system, and it was as TOPS-20 that it was marketed. The hacker community, mindful of its origins, quickly dubbed it TWENEX (a portmanteau of "twenty TENEX"), even though by this point very little of the original TENEX code remained (analogously to the differences between AT&T V7 Unix and BSD). DEC people cringed when they heard "TWENEX", but the term caught on nevertheless (the written abbreviation "20x" was also used).

TWENEX was successful and very popular; in fact, there was a period in the early 1980s when it commanded as fervent a culture of partisans as Unix or ITS—but DEC's decision to scrap all the internal rivals to the VAX architecture and its VMS OS killed the DEC-20 and put an end to TWENEX's brief period of popularity. DEC attempted to convince TOPS-20 users to convert to VMS, but instead, by the late 1980s, most of the TOPS-20 users had migrated to Unix. A loyal group of TOPS-20 enthusiasts kept working on various projects to preserve and extend TOPS-20, notably Mark Crispin and the Panda TOPS-20 distribution.

Some of what came with TOPS-20 was merely an emulation of the TOPS-10 Operating System's calls. These were known as UUO's, standing for UUO Unimplemented User Operation,[4] and were needed both for compilers, which were not 20-specific, to run, as well as user-programs written in these languages. The package that was mapped into a user's address space was named PA1050: PA as in PAT as in compatibility; 10 as in DEC or PDP 10; 50 as in a PDP 10 Model 50, 10/50, 1050. Sometimes PA1050 was referred to as PAT.

JSYS stands for Jump to SYStem.[8] Operands were at times memory addresses. "TOPS-20 allows you to use 18-bit or 30-bit addresses. Some monitor calls require one kind, some the other; some calls accept either kind. Some monitor calls use only 18 bits to hold an address. These calls interpret 18-bit addresses as locations in the current section."[1]

Internally, files were first identified, using a GTJFN (Get Job File Number) JSYS, and then that JFN number was used to open (OPENF) and manipulate the file's contents.