[rescue] Finding antique machines

John Francini francini at mac.com
Fri Apr 20 06:25:04 CDT 2007


>Tue, 17 Apr 2007 @ 22:18 -0700, Sheldon T. Hall said:
>
>>  And those things could handle a _lot_ of activity without breaking a sweat,
>>  too.  Remember when CompuServe was handling three million members with a
>>  bunch of hopped-up TOPS-10 machines?
>
>I thought they ran the pre-cursor to Twenex (TOPS-20)?

Nope.


>The story as I remember it is they bought PDP-10s, added paging and
>other functions that DEC refuse to add, and rewrote TOPS.

CompuServe's weird (to me) version of TOPS-10 branched off the 'real' 
OS somewhere around the 5.07 or 6.01 release, mid-1970s.

>Time passes, and DEC basically starts from the timeshare system and
>creates the Decsystem-20 and TOPS-20.

Nope, nope, nope.

Here's the deal.

The TOPS-10 Monitor (the old term for what we call an "OS") dates 
straight back to the original code written for the PDP-6 (DEC's first 
36-bit product) in 1963.   The first model of the PDP-10, the KA-10, 
which debuted in 1968, didn't have virtual memory or paging.  These 
were new and (commercially) untested concepts, though they were 
already operational on Multics at MIT.

Instead, the KA-10 had protection and relocation registers, which 
allowed a user program to be split into a 'low segment' which the 
program could write to, and a 'high segment', which was 
write-protected.  The high segment code could be shareable amongst 
users. So, if your job (a process in modern parlance) were running, 
say, a COBOL program, the COBOL run-time environment (libraries and 
such) would live in the high segment, and your program and data would 
live in the low segment.  Segments were multiples of 1Kword (36-bit 
words) in size, and were internally contiguous.  The Monitor could 
swap out an entire low segment to the swap area (a pre-allocated 
contiguous spot on disk, or, earlier, drum storage). The high segment 
stayed in core if there were other users who needed it; if not, the 
high segment would get swapped out as well if necessary.

Computer scientists at Bolt, Berenek, and Newman (BBN), in Cambridge, 
tried to get DEC to add the newfangled paging features to Monitor, 
but to no avail.  So they did the next best thing:  they bought a 
PDP-10 and then designed a box to add paging logic to the KA-10 CPU. 
They then proceeded to write a new OS from the ground up for it.  The 
result was TENEX, or TEN EXecutive.  This was the direct predecessor 
to TOPS-20.  Dan Murphy, one of the original programmers on the TENEX 
project, was hired by DEC in 1972 to port TENEX to the 
then-under-development KL-10 processor, which *would* support proper 
paging via microcode.  The eventual result of that port was TOPS-20. 
The user community dubbed it "TWENEX", as an homage to its history.

Meanwhile, the original Monitor was dubbed "TOPS-10", and the system 
as a whole was christened "DECsystem-10" when the second processor in 
the family, the KI-10, came out in 1972.  It was twice as fast as the 
KA-10, used 512-word pages instead of the 1Kword-multiple memory 
segments of the KA, would allow individual pages to be set 
write-protected or write-enabled, and could support non-contiguous 
job memory spaces.  However, TOPS-10 still didn't support it.

The KL-10 Model A, which came out in 1974, was Digital's first 
microcoded processor. It was twice as fast as the KI-10 it replaced. 
It supported KI-10 style paging, which was just fine for TOPS-10.  It 
also supported external memory channels, which allowed it to be a 
'drop-in' replacement for the KI-10.

The KL-10 Model B, which came out in 1976, was the processor on which 
TOPS-20 debuted. The Model B supported internal MOS memory, and its 
microcode also supported "real" (TENEX-style) paging, so it natural 
that it was also the first computer that supported TOPS-20.  The 
system was dubbed the DECSYSTEM-20.

Later on, Digital came out with the DECsystem-1091, a re-packaging of 
the KL-10 Model B in the same cabinetry as the DECSYSTEM-20 (and with 
the same internal memory), but with blue top panels in place of the 
orange used on the -20.  After that point, the only difference 
between a DECsystem-10 and a DECSYSTEM 20 were:

o The microcode loaded at boot time by the front-end PDP-11/40
o The OS loaded from disk
o The on-disk format of the filesystems
o A can of paint

Inside DEC, we had a collection of KL-10 computers available for 
stand-alone developer use.  These were usually orange-paneled.  All 
we needed to do to switch from TOPS-20 to TOPS-10 (or vice versa) was:

1. Shut down any OS running on the box.
2. Remove the previous user's system disk pack.
3. Install your own system disk pack.
4. Hit the "boot" button.

This would boot the PDP-11/40's console front-end software (a highly 
modified version of RSX-11 called RSX-20F), which would then proceed 
to load the CPU microcode and then boot the OS.


A single-box, cost-reduced (and 4x slower) model, the DECSYSTEM-2020 
(also known as the KS-10), was released in 1978.  It used a PDP-11 
UNIBUS for its peripherals, and also supported both TOPS-10 and 
TOPS-20.



TOPS-10 and TOPS-20 were very different beasts.  TOPS-10 was always 
the faster OS, while TOPS-20 was always the more feature-ful OS. Both 
had their adherents, and both were in active development right to the 
very end of the product's life in 1990.

There were plans for a 'unification' OS, dubbed TOPS-36, to take the 
best parts of both Monitors and combine them into one system, but 
that never really got beyond the investigational stage.


>
>Before the two systems could be merged into one product again, DEC
>dropped the whole 36-bit line in favor of VAX.

Partial credit here. (see above).

Indeed, the whole 36-bit line was indeed dropped because of the "one 
architecture, one OS, one product" mantra.  (We in TOPS dubbed that 
"One chicken, egg, one basket".)

>For a lot of people, that was a black day.

Now THERE you're right on.

One longtime TOPS-20 user, Mark Crispin, to this day uses the 
signature line "TOPS-20: a great improvement on its successors" in 
his e-mails.  And many of us still feel that way to this day.

John Francini
Ex-TOPS-10 developer
-- 
John Francini, francini at mac.com

"The journey is more important than the destination -- that's part of life.
If you only live for getting to the end, you're almost always disappointed."
                               -- Donald Knuth



More information about the rescue mailing list