Subject: Happy PDP-5 day

From: [email-masked]
Date: 11 Aug 93 10:04:31 MDT

According to a magazine that I once encountered in the bowels of the university
library, the PDP-5 was unveiled August 11, 1963 at WESCON. 

Here's to 30 years of small computers!

Roger Ivie
[email-masked]

PS: For you MS-DOS guys, here's the lineage of MS-DOS as near as I can 
figure it. Please feel free to correct me if I'm wrong:

                   LINC
                 /      \
              PDP-4    PDP-5
                |        |
        Unix  PDP-7    PDP-8 OS/8
                 \      /
           Unix   PDP-11  RT-11
                 /     \
                |     8080 CP/M
                |       |
                |     8086 MS-DOS 1.x
                 \     /
                   8086 MS-DOS 2.x and up

---

From: [email-masked] (Dan Pop )
Date: Wed, 11 Aug 1993 20:19:07 GMT

>                   8086 MS-DOS 2.x and up

I'll leave to the PDP-8 experts to comment about the connections between OS/8
and RT-11 and I'll comment about the next step, RT-11 -> CP/M. The only 
connections that I can see between RT-11SJ and CP/M is that they were both
single job, and they had a DIR command and a PIP utility. CP/M was by far
more primitive than RT-11, in every respect, so it cannot be considered as an
evolution from the latter. The underlying hardware was also more primitive.
Even MS-DOS 6.0 can be considered as an involution from RT-11, both at the
level of the user interface and at the level of system programming.

Dan
-- 
Dan Pop 
Tel:   +41.22.767.2335
Email: [email-masked]
Mail:  CERN - PPE, Bat. 21 1-023, CH-1211 Geneve 23, Switzerland
--
Dan Pop 
Tel:   +41.22.767.2335
Email: [email-masked]
Mail:  CERN - PPE, Bat. 21 1-023, CH-1211 Geneve 23, Switzerland

---

From: [email-masked] (Paul Tomblin)
Date: Wed, 11 Aug 1993 21:56:09 GMT

>evolution from the latter. The underlying hardware was also more primitive.

There is no law of computing, or even of biology, that states that all 
evolution has to go from less complex to more complex.  One only has to look 
at mammals that went back to the sea, like whales and seals.

Paul "I'm not a biologist, I just play one on the net" Tomblin
-- 
Paul Tomblin - formerly {pt{omblin},news}@{geovision.}gvc.com
"Ok dear, Want me to call the bike shop and see if they'll sponsor your
mid-life crisis?"  "Yeah.  Ask 'em if they'll upgrade my shifters, too"
 - Calvin's mom and dad

---

From: [email-masked]
Date: 12 Aug 93 09:10:41 MDT

> level of the user interface and at the level of system programming.

Gary Kildall is often quoted as saying the CP/M came out of RT-11, which is why
I drew it that way. Personally, I consider CP/M to be closer to OS/8, but I
didn't use any really early versions of RT-11.

Roger "The first DEC machine I used was a VAX. Then I used a PDP-8." Ivie
[email-masked]

---

From: [email-masked] (Charles Lasner)
Date: 12 Aug 1993 17:51:16 GMT

>Roger "The first DEC machine I used was a VAX. Then I used a PDP-8." Ivie

Which is probably a unique event in the annals of DEC.  It takes an observant
individual to appreciate the distinction, etc.

A side issue:

How many people are there that actually appreciate a machine's architecture?

I suspect that many self-proclaimed -11 lovers got that way merely because
they liked the software for what it could do for them, not the underlying
hardware that was being used to implement it, etc.

A case in point could be RT-11.  It is likely that a system mimicking RT-11
could have been done on the PDP-8.  It would have required DEC to insist that
the machine have 32K to accomplish this, instead of the relatively spartan
attitude of just requiring 8K to run OS/8 (or 4K to run P?S/8!), but DEC never
required any users to go for 32K until the DECmate I.  (The VT78 is a fixed
memory size of 16K; all older machines could be had in various sizes, although
most 8/a memories tended to be either 16K or 32K.)

So, if DEC had written "RT-8" and it's functionality was consistent with what
most people get out of RT-11 over the years (this is doable), would there
still be such an -11 following?

Today, it's far too easy to lump together "unix boxen" as an extension of this
notion.  IMO most people *never* appreciate a computer's architecture under it
all.

cjl

---

From: [email-masked] (Dan Pop)
Date: Thu, 12 Aug 1993 20:24:50 GMT

>hardware that was being used to implement it, etc.
Well, those people programming in assembly (MACRO-11) definitely loved the
the machine architecture, especially the addressing modes and the symmetry of
the registers. They were not available on others mini's of the time.

>the machine have 32K to accomplish this, instead of the relatively spartan

Why? RT-11 could run on a 8K machine. It's true that the word had 4 extra bits,
but this could hardly justify 32K on a PDP-8.

>still be such an -11 following?
It's not clear if by "-11" you refer to PDP-11 or RT-11. The answer is yes,
anyway (IMHO). PDP-11 was not designed primarily to run RT-11. And RT-11 was
only one of the OS's designed for PDP-11, namely the one oriented towards
the small configurations used in laboratory automation, amongst other many
applications. They had the advantage that the software development could be
done on bigger machines /45, /70, /34, /44 and the laboratory or factory
machines could be equipped with just enough memory to run the application
software (at the beginning, when memory and mass storage peripherals were
expensive) or RT-11 and the application software (later).

Dan

---

From: [email-masked] (Charles Lasner)
Date: 12 Aug 1993 23:07:18 GMT

>the registers. They were not available on others mini's of the time.

Personally, I hate(d) it.  But that's not the point.  I would think that the
people who programmed in macro-11 were a minority, and I am asking if there
was a significent percentage of customers with only a software utility's-eye
view of a machine.

>but this could hardly justify 32K on a PDP-8.

Well, perhaps 12K on an -8.  The point is that you want about 8K for the
user program on the -8, same as in OS/8.  I figured that for a whole field
to be available to the user, the system would steal about 4K for itself.  But
the point is that DEC only demanded 12K for problematic peripherals, and 8K
otherwise since this is the OS/8 minimum, etc.

>expensive) or RT-11 and the application software (later).

I meant that if there was an RT-8 that did what the -11 did, it could have
predated RT-11, but they just weren't interested at the time.  Picture a
world without RT-11, but with RT-8.  I suspect that for a goodly segment of
the DEC-buying public, it woudn't have made a difference.
 
cjl

---

From: [email-masked] (Johnny Billquist)
Date: 13 Aug 93 10:05:16 GMT

>individual to appreciate the distinction, etc.

:-) Well, I went from pdp-11 to VAX to pdp-8 and pdp-10. :-)

>How many people are there that actually appreciate a machine's architecture?

Probably less that one would wish, and more than you suspect, Charles.
I think you underestimate the appreciation some people have for the
pdp-11 architecture.

>hardware that was being used to implement it, etc.

No no no. The -11 has some really wonderful stuff.
For one thing I *really* love that the PC is a general register.
No special instructions for immediate mode, register->memory,
memory->register, memory->memory or register->register. It is
all the same instructions.
I never have understood how anyone can like a processor which don't
do it that way. (Such as the MC68xxx, which do *everything *wrong*).
But the pdp8, pdp10 et al. does things a completely different way,
which is beautiful in another way totally, but also extremely
enjoyable.
Who can resist an architecture where JUMP means do not jump. :-)

>still be such an -11 following?

Yes. In my opinion, DEC did do that. Have you ever used RTS8?
OS/8 is a background job in RTS8. Seems to me like something very much
moving towards RT-11, but I haven't used RT-11 much myself.
The problem is, as usual, the memory limit of the pdp-8, it was probably
the big killer of the architecture. The 8/a had the KT-8, but few
were sold, it seems.

>notion.  IMO most people *never* appreciate a computer's architecture under it

That is very true, especially for unix-jocks.

	Johnny
--
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: [email-masked]       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

---

From: [email-masked] (Johnny Billquist)
Date: 13 Aug 93 10:19:50 GMT

>was a significent percentage of customers with only a software utility's-eye

No, I think that a big majority programmed in assembler for the first years
on the pdp-11. Especially if you used RT-11, since most high-level
languages don't fit too good into realtime applications.
Even to this say, I'd say that pretty many people program in assembler
if they use a pdp-11, with the exception of those running unix.

Especially those with RT-11 in mind, I think often were customers
who wrote their own software, in assembler, and didn't bother much
about anything else in the machine.

The fact is that *very* many people really do like the pdp-11 architecture,
and while I know you won't appreciate this point, many other preocessor
manufacturers obviously thought it was good enough to copy, to get
customers. (Think about the MC68xxx, or NS16xxx)
(Hell, even the 6502 was inspired by the pdp-11 from what I've heard).

>the DEC-buying public, it woudn't have made a difference.

I'm not sure I agree. DEC would probably have sold more pdp8 for a while,
and less pdp11, that much I agree upon. But the end would very probably
have been the same anyway. The potential of the pdp8 was already being
stretched, while the pdp-11 was starting at the low end, and there
the pdp8 could be given an edge, but as usual, all development goes
towards larger and more advanced. You can not get a pdp8 in the
same size as the bigger pdp11, so in the end, the pdp8 would be
the looser anyway. When prices of hardware drop, more people would
be able to afford a bigger pdp11 instead, and have access to all
the software on it, which could not be gotten to run on a pdp8,
and be able to develop software on a fast machine, and then use a
small, dedicated pdp11 on different tasks.

One of the big problems with the pdp8, when you start building
bigger systems, is the interrupt structure, which is very lame.
It works very nice for small system, but not very good when
it comes to large ones. And remember also, that in the early
seventies, disks and tapes were bulky stuff, which required
a lot of hardware to interface, which the pdp8 hadn't any space for
either. Today, the pdp8 actually got better odds than in the
early seventies. Imagine massbus on a pdp8?

Also, Omnibus puts a limit on how much stuff you can throw into
a pdp8, and the architecture limits you to 64 device adresses,
each one able of pretty little. A normal terminal needs two
devices. Sure, you could stretch it all some more, but it
can get pretty expensive to put the limits all the time.
The early pdp11 peripherials wasn't made by stretching things.
Terminal controllers were made on whole backplanes, while using
several adresses in the I/O page. But backplane size was not
a big issue on the pdp11, and the I/O page was 8K.

Makes it much cheaper to do peripherials for the pdp11 in the long run.

And don't flame me for liking the pdp11, Charles. I think you
know my general opinions on several DEC machines...
--
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: [email-masked]       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

---

From: [email-masked] (Charles Lasner)
Date: 13 Aug 1993 16:59:43 GMT

>I think you underestimate the appreciation some people have for the

I think you are looking too closely for an answer to the question.  See your
own response about unix-jocks below.  Maybe in your "sphere" some people
like the -11, but I am speaking more globally.  I think the bulk of people
who purchased -11's did so merely for what the applications did for them
indirectly, not for the underlying machine.  And said applications were not
something that came about from some claimed miraculous features unique to
the -11.  In any case, the main point is that when this abstractionis taken to
extremes, the unix-jock phenomena is the end result.

>all the same instructions.

Regardless, I still want the global answer.  However, I will freely concede
that a lot of *current* -11 people agree with you completely.  My question
really has little to do with -11's per se.

>Who can resist an architecture where JUMP means do not jump. :-)

To answer that, I would say "JRST about anyone" :-).

>the big killer of the architecture. The 8/a had the KT-8, but few

Most of what became the software for the PDP-8 was a notion in Richard Lary's
head years before he came to work from DEC, and was still in the group I am
a proud member of back then at Brooklyn Polytech.  Back then, RTS8 (formerly
SRT8) was known as "TOY".  We were running it in 4K from MS-8 and it handled
our extra PT08 TTY: interface, etc.

RTS8 ain't RT-11 or even like it.  What the -8 wants to have to be on a par
with an RT-11 is a system where you can dynamically load executables that
are on the file structure initially, and come in and make system calls to
the system resident interrupt handler/system routines, etc.  This is not
what RTS8 does, rather it's more like the original rigid definition of the
early RSX-11 with fixed tasks, etc.  Someone was even writing a task builder
for it to help out, etc.

But further, RTS8 doesn't rely on the PDP-8 timeshare trap either.  Most of
the other systems that do, are too busy emulating 4K machines and/or OS/8.
There really isn't an RT-11-type system out there for the -8 that got anywhere
completely.  What would be required is a radical departure from OS/8, which
perhaps included file system compatibility, but whose executable files are
totally incompatibile with OS/8.  Since OS/8 would still own the rights to
boot the device, the RT-8 would then be constrained to live within OS/8's
provinces further reducing the amount of available memory, etc.

I would recommend dumping all of the OS/8 conventions, since they are too
marginal for the purpose, and it wouldn't serve any purpose towards such a
project.  After all, an OS/8 conversion task could be written for it after
the fact.

I am open to suggestion for improvements to the P?S/8 "third" file structure
which could be the home to such a system.  Unlike OS/8, P?S/8 only requires
128 words resident in 07600-07777 to get started, and could be totally kicked
out of memory once the RT-8 got up.  (There are three file structures: one
oriented towards users who prefer something like the original BASIC from
eons ago, which is distinct from the second which is optimized for system
program descriptions.  Both of these are viable in 4K!  The third structure
is under development and will be used to entertain the notion of programs
that can't run in 4K, as long as a basic set of copy/rename/delete utilities
can access it in 4K, and said utilities themselves can reside in the second
directory for the purposes of calling them up.  Alternatively, it could be
required that the second directory contain a shell program that needs more
than 4K to run at all, and it would access the third directory completely,
and some alternate 4K-only means could minimally exist to at least examine
the third directory, etc.  In any case, this third directory is the one
where all of the new "action" goes.  Tentative features include file protection
bits, tree-structured directory segments, time as well as date stamps, file
lengths in words/bytes as opposed to blocks like OS/8, execution restrictions
meaning memory availability, block number boundary restriction capabilities, 
etc.  Please contact me if anything conceptual ought to be considered, etc.)

In any case, an RT-8 system ought to use traps to get at system services.
This really hasn't been done outside of TSS8.

>That is very true, especially for unix-jocks.

All too true.  Sort of interesting to here something that sounds like:
Eunuchs and jocks in the same sentence :-).

cjl

---

From: [email-masked] (Charles Lasner)
Date: 13 Aug 1993 17:40:29 GMT

>if they use a pdp-11, with the exception of those running unix.

First of all, reading the end first, this ain't a flame :-).

We are at cross-purposes here.  I am attempting to illustrate that there is
a class of user that is architecture ignorant, but either uses programs that
others write, or alternatively programmed only in Fortran or whatever where
the actual machine didn't matter.  Some people make an argument that no
matter how good the potential of a machine is, the lack of good software will
kill it.  I am making an inverse argument which is that if the software looks
good to a user, they may never understand whether the underlying machine was
good or bad, and whether the software was well written or was actually just
a pile that happened to look good at the command level.

>about anything else in the machine.

No doubt it applied to some, as it did with the -8 as well.  But in my
experience, I found customers who were ignorant of what was in their
respective systems of both types.

>(Hell, even the 6502 was inspired by the pdp-11 from what I've heard).

I don't want to get into the religious war over architecture, but remember
that there is one for a whole bunch of features that there are those who
lambast the -11 for.  Some topics to be named, but please do not dwell on
them: byte addressing, inconsistent condition codes, not fully symmetrical
modes and operations, largely wasted addressing modes that have little
statistical usage, etc.  Please let's pursue this (if at all!) separately,
but I didn't invent any of the references; most are the subject of some
master's theses and journal articles, and there is nothing new here, etc.

>and less pdp11, that much I agree upon.

But that's the only point I raise, that this would have been fine for the
purposes the customers sought, etc.  IMO every machine should have an RT-11
kind of a system, and for a while there was a clamor for an RT-32 for the VAX.

> But the end would very probably
>towards larger and more advanced.

No, this is simply not true.  DEC had a mindset that a PDP-8 was a 4K machine
and it was a major step to get them to admit to needing 8K because for the
original LINC-8 and -8 it was quite a bit of extra hardware.  But from the
8/i onward it wasn't so big a deal.  It was next to impossible to get DEC to
spring for software that would have required 12K-16K and wanted 32K, which 
at the time was considered astronomical.  The -11 came into a world where they
realized that those 4K 11-20's were worthless, and they better get some memory
into them in order to do anything useful with them.  Thus, the -11 benefitted
from the ability to support a project based on more memory being in the
average customer's machine before hand.

> You can not get a pdp8 in the

No, at the time the -11 was a 32K machine.  The bigger machines came later.
RT-11 runs on these "smaller" -11's.  One-user machines don't really need
the MMU stuff.  If the -8 was considered a 32K machine instead of a 4K one,
things could have been different.  In any case the seeds of the relevant
software predate any of these decisions.

>it comes to large ones.

That's simply not true.  When the fancier peripherals started to come in,
they supported vectored interrupts.  The PDP-12 has API and is an older
design.  In fact, API was planned for the Omnibus and then dropped!  But
in any case, I have worked with the KL8A and SLZ8 which are one-device-vectored
interrupt handling, and also the TELCON 32-channel multiplexors.  Others
have worked with the DC02 family of terminal multiplexors which come in sizes
from 4 TTY's to 32 TTY's with one interrupt.  I think you are assuming that
the problem would be that if you had N terminals, you need N pollings to 
handle the interrupts.  In real systems, N never gets to even 4.  However,
since there is no actual API hardware other than on the -12, you have to have
a little overhead to fake it if necessary.  I once wrote a series of real-time
programs that did this, and the overhead wasn't really that much; mostly it
was needing a real-time dedicated stack and auto-index register devoted to
it, but it really wasn't more than a few instructions more than some mythical
API hardware.  There are more sources of overhead than merely the count of
instruction fetches in an interrupt handler.  However, I have heard of people
who had to count their -11 instructions in interrupt handlers because the
machines were too slow to keep up with the data!

> And remember also, that in the early

I don't understand this at all:  I assume you are referring to the Omnibus
being a physical real-estate problem if you are building the whole peripheral
into the buss-box.  But the -11's UNIBUS was more like the older positive
buss where there is a separate backplane which can be as big as you need.  To
that way of thinking, the LSI/2 cards of the smallest Q-bus machines are more
limited than the -8.  In any case, I have had SCSI on my -8/a for years, so
I still don't understand the problem.  Regardless, all of us can perhaps take
advantage of the fact that much peripheral hardware is a lot smaller!

>can get pretty expensive to put the limits all the time.

See above.  Each device address *can* be lame, but doesn't have to be.  You
really don't just replicate the console interface to add another TTY:!

>a big issue on the pdp11, and the I/O page was 8K.

And later they found that it was too big so lowered it to 4K.  I don't
understand the reference to stretching things since the normal -8 way isn't
stretched.  If neither machine stretches things, then fine.

>Makes it much cheaper to do peripherials for the pdp11 in the long run.

No way.  The -11 stuff was always more expensive.  The problem is usually
the -8 version got the short end of the hardware engineering stick.  As to
ultimate price, I think there is no significant price in a properly engineered
solution, just that sometimes that became an unachievable goal.

>know my general opinions on several DEC machines...

As you know, I already know that.  No flames per se intended.  However, not
everyone agrees with either me or you.  My biggest problem with the -11 is
"political" in that where DEC could have done better with -8's, they clumsily
chose to use -11's, sometimes with negative consequences, such as the Disney
contract they lost to DG for about $70M, etc.

cjl

---

From: [email-masked] (Howard S Shubs)
Date: Sat, 14 Aug 1993 06:42:45 GMT

>I think the bulk of people
>indirectly, not for the underlying machine.

That's true of any computer.  Machines are purchased for a reason.  OTOH,
people who -get them for free- might like them for themselves.
-- 
Howard S Shubs    [email-masked]          For to win 100 victories in 100
The Denim Adept   [email-masked]   battles is not the acme of skill.

---

From: [email-masked] (Charles Lasner)
Date: 14 Aug 1993 22:08:18 GMT

>people who -get them for free- might like them for themselves.

That's the point I was making.  I think JB is speaking for people in our group
or similar, whereas I was referring to original purchasers/the people the
marketroids are trying to reach.  To that point, I am saying that it's
unfortunate that DEC never tried to exploit the power of a PDP-8 with more than
about 8K for the purposes of what RT-11 did/does well, since clearly such a
system can be done for the -8, but unfortunately never was.  (And apparently
they repeated the mistake with the VAX as well, since there was an expected
following of what was to be called RT-32, etc.)

cjl

---

From: [email-masked] (Johnny Billquist)
Date: 15 Aug 93 00:35:55 GMT

>extremes, the unix-jock phenomena is the end result.

The places that bought pdp11's for UNIX was a clear minority!
Most places bought pdp11 for process control, second after that was
probably education, and many of those used RSTS/E. Admittedly, most
people using RSTS/E never used macro-11, but for all other systems, and
type of customers, macro-11 was the language of choice.

>early RSX-11 with fixed tasks, etc.  Someone was even writing a task builder

True, RTS8 is maybe more like RSX is some ways, but the concept of
foreground/background seems to me very familiar with the way RT-11
works.
And you use OS/8 in RTS8...

>provinces further reducing the amount of available memory, etc.

Hmmm, I assume that you mean the trapping of IOT's when you're talking
about timeshare trap, right?
RTS8 do use that. Atleast in verion 3, which I have.
It has to do things that way to keep OS/8 as a process.

>project.  After all, an OS/8 conversion task could be written for it after

I could agree with that.

>This really hasn't been done outside of TSS8.

Ummm, I could disagree with you. I have used MULTOS some,
and it uses IOT's to get different system services, and
it emulates several pdp8, each running OS/8. So each user
has his own copy of OS/8, but there are some previously
unused IOT's which can be used to get additional features.

>Eunuchs and jocks in the same sentence :-).

:-)

---

From: [email-masked] (Johnny Billquist)
Date: 15 Aug 93 01:08:03 GMT

>people who -get them for free- might like them for themselves.

Yes, but buying machines for a purpose isn't neccesarily the same thing
as buying a machine for the applications. Sometimes you buy machines
for doing stuff for which there are no prepackaged applications.
You still buy the computer for a purpose, but the architecture becomes
the deciding point.
--
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: [email-masked]       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

---

From: [email-masked] (Johnny Billquist)
Date: 15 Aug 93 01:17:09 GMT

>following of what was to be called RT-32, etc.)

No, you are missing my point.
In the beginning of the seventies, the typical DEC customer was something
completely different than today. At that time, it was technical people
who sold and bought DEC stuff. Marketdroids hadn't been exported from
IBM yet. (Especially not to DEC).
The original purchasers of DEC equipment in the beginning of the pdp11
was people who wrote assembly language on it.
You are trying to put them into todays suites. That was not the case.
And I still stand by my claim that the pdp8 couldn't grow nicely that
much more than it did. The pdp11 could, at that time.

As for RT-32, yes, many people wanted other stuff on the VAX, than
was eventually came out. TOPS-32 is another story, as is RSX-32, and
*no*, VMS is not the same as RSX-11M(-PLUS).
VMS feels more like RSTS/E from the outside. I understand it got
more in common with IAS...

	Johnny

---

From: [email-masked] (Johnny Billquist)
Date: 15 Aug 93 01:34:14 GMT

>First of all, reading the end first, this ain't a flame :-).

Nope, this is getting to be an interesting discussion...

>a pile that happened to look good at the command level.

While I fulle agree that there exist some people why are totally ignorant,
I think that the number is constantly rising, and I believe it was much
lower at the time the pdp-11 were introduced...

>respective systems of both types.

If you are talking about nowadays, I would suspect that was the case even
without you saying so. But did you really find that to be the case in say
1971?

>master's theses and journal articles, and there is nothing new here, etc.

Well, I have to agree the the branch instruction isn't very logical
in the way how the opcodes look. (Just semi-logical, which is far less
than the pdp8 or pdp-10.)
Byte-addressing isn't a problem in any way, possible that you are not
allowed to address words at odd bytes could be considered illogical.
The basic pdp-11 *is* fully symmetrical in addressing modes and
operations. The EIS is not, unfortunately, and the reason is that
they didn't have enough opcodes left.
(They solved that in the VAX, which has been flamed even more because
of it...)
Nowadays, CISC is pretty unpopular, no surprise the pdp11 gets some
fire because of that.

But okay, there are a few ugly-looking things in the pdp11, but not that
many, really. And in my opinion, the only that bothers me is the
limits on the EIS instructions.

>kind of a system, and for a while there was a clamor for an RT-32 for the VAX.

The point I wanted to make that in the long run it might have been for
the worse. We are talking about a short term gain for a long term
lossage, in my mind.
Sooner or later, the pdp8 would be on the loosing side, and the longer
you put it off, it might turn for the worse.
Mostly for DEC, since they needed to get money rolling on the pdp11
to get more development going, to get prices down, and stay competitive.
Otherwise they would soon have to quit the arena.
You have to try to keep the upper hand on your competitors, as well as
trying to keep your customers satisfied.
And those two goals are pretty hard to meet at the same time.

>average customer's machine before hand.

Yes, but once more extending the address size of the pdp8 would mean much
trouble and headache. And it would have needed to be done to get things
working for a longer period.
Preferrably, you would have wanted to drop the KM8, and go for a real MMU
more like the one in the pdp11. But that would have made it incompatible with
all existing software. Double trouble.

>software predate any of these decisions.

I think the 8 was thought of as a 32K machine. The problem was that that
was the *upper* limit of the pdp8, while it was the basic design of the pdp11.
The pdp11 addressed 32Kword without any additions, while the pdp8 had
to use the KM8, which is just about an MMU for the pdp8. When you added
an MMU to the pdp11, you got *much* more.

>interrupt handling, and also the TELCON 32-channel multiplexors.

Don't know anything about the API, but I do know how the KL8A works, and
you have to poll it. There is a special IOT which makes it jump if it
was requestion an interrupt, but you don't get it to jump according
to the programmed vector without that IOT, so you still have that
problem.
Then you have the problems of nested interrupts. The pdp8 isn't designed
to handle that. You don't even have different priorities of interrupts
in hardware. You can just poll peripherials in whatever order you want
to, and that is your priorities. Noone can interrupt an interrupt, unless
the interrupt service do some serious work to allow it.
Much headache can come from that...
(Do we need to go further into it?)

>  Others
>handle the interrupts.  In real systems, N never gets to even 4.

Not so, I'm saying that you will need *at least* N polling for N devices,
and probably a few more.

>  However,

Yes, some pdp11 are really slow. But some also are pretty fast.
And I also can tell you that if you would connect those same peripherials
to a pdp8, it wouldn't be able to keep up with the speed either.
But you just never hooked up stuff with those speeds to pdp8's anyway.

>advantage of the fact that much peripheral hardware is a lot smaller!

SCSI didn't exist when the decision to move for the pdp11 was made!
(Which I was trying to point out to you...)
And yes, the Omnibus cannot be of any size you want to. And all lines
are already defined, so you cannot build the things in the same free way
you can in the Unibus. You just have Unibus in and out for an RH11, the rest
is special stuff, and 6 slots wide even so. And HEX flip-chips at that.
A massbus controller on Omnibus would probably be around 15 cards.
(I have a TU-10 controller, and that one is 4 cards, and that device
is pretty simple compared to a massbus)

>really don't just replicate the console interface to add another TTY:!

Agree on that one. With terminal multiplexors, you could stuff in
many TTYs without using many I/O addresses. But how many I/O adresses
do you think you would need for a Massbus device?
Probably around 30 or so.
(Or you would have to make it even bigger, and harder to use...)

>stretched.  If neither machine stretches things, then fine.

The pdp8 would have been stretched if you wanted to expand it
much further from where it was.

>solution, just that sometimes that became an unachievable goal.

The pdp11 peripherials were more expensive, and also much more advanced
than there pdp8 counterparts, so a straight comparision of $$$ isn't
that informative.
To once more go back to the massbus, a massbus controller for the pdp8
would have been significantly more expensive than the pdp11 version.

And if you didn't go with massbus, you really had no big disks to
use on a pdp8 until the SDI comes along, from DEC. 3rd party would have
been SMD, which isn't that much smaller or easier.
SCSI has only become an option since the Macintosh came. Pretty new
compared to the pdp8 or pdp11.

>contract they lost to DG for about $70M, etc.

DEC hasn't always been able to come out on top of their competitors,
but obviously the have managed better than DG in the long run.
--
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: [email-masked]       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

---

From: [email-masked] (Howard S Shubs)
Date: Sun, 15 Aug 1993 06:44:56 GMT

>You still buy the computer for a purpose, but the architecture becomes

Then the deciding point becomes price and availability.  Look at the
80n86 series.  Certainly it's not popular due to its architecture.
-- 
Howard S Shubs    [email-masked]          For to win 100 victories in 100
The Denim Adept   [email-masked]   battles is not the acme of skill.

---

From: [email-masked] (Charles Lasner)
Date: 16 Aug 1993 05:07:10 GMT

>The places that bought pdp11's for UNIX was a clear minority!

No, I mean the notion of unix=unix=unix, not -11-based unix per se.

>type of customers, macro-11 was the language of choice.

I think we need someone from DEC to confirm any of this, since I can't fathom
your order at all.

>And you use OS/8 in RTS8...

Not really; you can configure a background task, that's all.  The bulk of
the system is totally non-configurable in the RTS8 sense, sort of like early
RSX.

>about timeshare trap, right?

Yes, the trapping of the switch register function so it can be faked, the
trapping of HLT so it doesn't ever halt, and the trapping of IOT's so they
can be used as executive requests for any and all system services.  The idea
is that if you do it this way, the code is modular, and could be "upgraded"
to a more comprehensive system should it get redesigned.

>It has to do things that way to keep OS/8 as a process.

No, the point is that *only* the OS/8 background task uses it.  And then, only
to fake the non-interrupt environment of OS/8.

>unused IOT's which can be used to get additional features.

Yes, but the main thrust is to simulate the inefficiency of stand-alone
non-interrupt I/O, which is fine if you are not concerned with real-time
or buffering when it's really done, and a grossly inefficient thing to
simulate.  Whether other system services are present or not, most of the
usage is to slavishly fake how OS/8 bumbles along as if there are no actual
interrupts and support multiples of only that.  Clearly there is only rare
usage of trapped I/O that allows good overlap, etc.

Perhaps this is an industry secret we uncovered!

cjl

---

From: [email-masked] (Charles Lasner)
Date: 16 Aug 1993 05:14:56 GMT

>IBM yet. (Especially not to DEC).

I suggest your locale was isolated from the mainstream.  I was already
seeing what you refer to go away as early as 1972.  By 1975 there wasn't
much of a following for many DEC machines from a techical standpoint in
many areas.  And of course by 1980 it was non-existent.

>was people who wrote assembly language on it.

Yes, at the *very* beginning, since there wasn't yet anything else.  But later
that changed radically.

>You are trying to put them into todays suites. That was not the case.

No, today it's just worse, not different.

>much more than it did. The pdp11 could, at that time.

Irrelevant.  My point is that a 32K -8/e with an "RT-8" system on it would
be powerful enough to be the system of choice of a goodly number of people
who used RT-11 in the "superficial" way we have been discussing.  If such a
system existed, it could be 512K by 1985 using the CESI memory, and certainly
would have been 128K with the KT8A.

>*no*, VMS is not the same as RSX-11M(-PLUS).

Sorry, VMS 1.0 *IS* RSX.

>more in common with IAS...

Can't say about later stuff, but the roots are what they are.

cjl

---

From: [email-masked] (Charles Lasner)
Date: 16 Aug 1993 06:21:50 GMT

>lower at the time the pdp-11 were introduced...

Agreed it was *lower*, but not all that low.  Also, the -11/20 was introduced
in 1970, so we are still talking about a few years down the road.  And I
would submit that your locale (from DEC marketroid's point of view) is a 
sales "backwater" not where they were attempting to manipulate the average
customer's perceptions.  (Also, a lot of customers were "corporate", etc.)
So, perhaps your local collection of users represented a different "mindset"
from the one that DEC was "shooting" for, and got, primarly in the USA, and
especially in NYC, home of many large corporate DEC accounts, etc.

>without you saying so. But did you really find that to be the case in say

Nowadays this argument doesn't exist for the -11 and the -8.  They are both
dead as far as business is concerned.  Had DEC's current attitude existed
a few years ago, the -8 and -11 would be handled as "ghosts" instead of only
the -11 currently.  But any case, I am saying that around 1972 it was already
showing true that way :-(.  The years just upped the numbers even more.

In fact, I was consulting for a few people who had the demented notion that
the pre-packaged software consisting of OS/8 release software, combined with
the crappy paper-tape software was sufficient to get their job done totally!

(Note: DEC had been hired on as a consultant to certain endeavors, and produced
programs for a specific application for specific customers.  Then, they would
market the same programs, often not even modified, to the general audience as
alleged viable solutions for the newer customers' problems.  This was largely
wishful thinking, and the overall quality of these applications was poor.  Some
were even totally incompatible with disk systems because they were to 
specifically "intimate" with paper-tape conventions, and were written for
machines with 4K or possible 8K where the only peripherals beyond those for
the application was the high-speed reader.  In these situations, the BIN and
RIM loaders could be counted on as being present, not the resident of a
disk-based O/S, etc.)

They had to rebudget to hire on me and people like me, etc.  There was a
whole early "network" of us who met at DECUS conventions who were hired on
essentially "after the fact" because the software was essentially worthless
for applications they counted on, etc.  The earliest I can relate to this
is actually 1970, just about when the -11 was announced, but on the -8 at
the time.

>than the pdp8 or pdp-10.)

And the loop counters were so kludgic that they added an asymmetrical one
just to get reasonable performance.

>allowed to address words at odd bytes could be considered illogical.

Byte-addressing disease has always been harmful.  The presumption of a
fixed byte size is truly idiotic.  Only the -10 solves this elegantly, and
with no compromise of the address space.  In the case of the -11, it's cut
in half for no good reason.

>they didn't have enough opcodes left.

I suggest you read some scholarly ACM articles that point out why this is
untrue.  Take a look at the INC and DEC operations and then compare to
adding and subtracting #1 for a trivial example.

>Nowadays, CISC is pretty unpopular, no surprise the pdp11 gets some

To my mind, not enough.  The VAX is treated is if it's the only three-headed
monster, but the head count may be different here, but still not normal.

>limits on the EIS instructions.

Whether it bothers you or not, the "horns" are still there.  Maybe you never
were "burned" by some of them; others weren't so fortunate, and they wrote
articles about the experiences, etc.

>you put it off, it might turn for the worse.

How can more software availability be bad for DEC?  The amount of people who
were hired to write RT-11, COS-310, OS/8, etc. was a real tiny group at the
beginning.  They could have afforded $100K more at the time.

>Otherwise they would soon have to quit the arena.

Essentially, they threw in a lot of money into the -11 money pit.  They
had made a desparate committment to it, often counterproductive in that to
succeed, it had to backstab other architecture's resources, machines that
for some of the applications were more suitable.

>And those two goals are pretty hard to meet at the same time.

Wrong.  At the time, DEC "could do no wrong".  That attitude hurt them quite
a few years later, and deeply so.  (Some would say rightfully so!)  Competition
was internally generated, not an industry problem.  I referred to the Disney
contract where $70M was lost to DG because a problem that later could, and
eventually was done by a micro, was presented on an -11, not an -8.  They
spent research money on the wrong machine, and predictably lost the contract
because it was way overpriced.  DG's bid wasn't cheap, but an -8-based one
could have beat DG, even with DEC's internal overhead, etc.

>working for a longer period.

No, the KT8A was planned and built anyway.  There was to be a Fortran compiler
written that would generate MACREL code that would load into it so that a
system akin to the VAX stand-alone system (forget its name) could be built
on the -8.  The compiler was canned, but MACREL was finished for no pay by
Stan Rabinowitz.

>all existing software. Double trouble.

No need to.  The KT8A or CESI system is fine for an RT-8.  Not quite as
elegant in some spots, but not blecherous either.

>>>small, dedicated pdp11 on different tasks.

There's no way that at any point in engineering history, an -8 costs more
to make than a corresponding -11.  The LSI-8 was produced by Richard Lary,
and was dropped by management for non-technical reasons, etc.

>an MMU to the pdp11, you got *much* more.

At the beginning, the -11 was a 32K machine, and the -8 was thought to aspire
to 32K, but never get there.  IT was a 4K machine and making it 8K took some
mindset alteration of management.  Note that PS/8 was released for 8K -8's
at the same time as they were making 4K 11/20's with a TTY: and nothing else.

>to the programmed vector without that IOT, so you still have that

Yes, semi-polling.  But the SLZ8 is an 8-channel version of a KL8A, so it
cuts the polling overhead in half.  The TELCON cards I used needed only a
single IOT set to tell you which channel you needed to deal with.  Similarly,
the DC02 hardware does the same up to 32 channels as well.  Various real-time
systems on the PDP-12 needed to do that correctly and did so.  I think you'll
find that only some much later -11's could keep up with an API-capable -12
with a 32 channel DC02.

>(Do we need to go further into it?)

Yes, as I said, API does all that, and is a standard feature of the -12
(KF-12B).  It was planned, then later dropped, from the Omnibus.

In any case, I have written real code with an interrupt stack, and you are
overblowing the seriousness of the problem.

>Not so, I'm saying that you will need *at least* N polling for N devices,

Yes, but the point is that on a real system, N is quite small.  The actual
difference isn't that great on practical applications, some of which I have
already written, etc.

>But you just never hooked up stuff with those speeds to pdp8's anyway.

That's patently false!  The transfer speed of most of the peripherals on the
-8 is comparable to that on the -11.  Some of the -11's were so slow, they
couldn't keep up with the family spec, such as why the RX02 got designed with
DMA because LSI's couldn't keep up with an RX01!

>SCSI didn't exist when the decision to move for the pdp11 was made!

SCSI was being used on *my* PDP-8 in 1981.

>is pretty simple compared to a massbus)

Not quite true.  The Omnibus "grew" a fifth foot to gain more signals in the
8/a.  A sixth foot could've been added on easily if required.  Physical size
is irrelevant, since you can package things -11 style if need be off of 
cables that plugged into Omnibus first-card controllers.  Most of the logic of
a TU-10 and TM8E system is in the drive, not the Omnibus.  Later peripherals
got smaller, not larger.  There really isn't much call for peripherals that
aggregate more logic real estate than something as gross as the FPP-8/A on
two hex Omnibus cards.

>(Or you would have to make it even bigger, and harder to use...)

Probably about 1 set.  There exists a 256 channel I/O card for the -8 with
one set of IOT's.  That's what multiplexors are for, etc.  You are assuming
a trivial interface where one IOT does one thing only, not a multi-functional
device.

>much further from where it was.

I still don't understand what you mean by stretching.  The memory concept
can be extended to 2^24 words, and the IOT's to 2^18 operations.  Where's
the stretch other than being imaginative beyond the simple interfaces used
for the console I/O which was never the model for anything else?

>than there pdp8 counterparts, so a straight comparision of $$$ isn't

Other than Massbus adaptors, which wasn't the main thrust, I don't know
what you're talking about.  Generally, the -8 version of a peripheral they
both had was cheaper, and paid a price of having to have klduged software
to get around avoidable problems, etc.  The RK8E was a lot cheaper than
the multitudes of RK11's, etc.  (Not to be confused with what they wanted
to *charge* for either!)

>been SMD, which isn't that much smaller or easier.

I was already using a 10-Meg disk on the -8 years before either.  Had anyone
wanted to interface the slightly larger packs, the basic interface would be
virtually the same.  The disks simply cost more, beyond most people's budgets,
so they never bothered.  Interface costs weren't the driving force though.

>compared to the pdp8 or pdp11.

Wrong, see above.  1981 predates the Mac.

BTW, the MAC version of SCSI is not really SCSI, and it uses no data state
purpose.  Essentially, it uses a program-transfer kind of interface to
shovel bytes down a lame digital I/O interface.  The PDP-8 and any other
sane design uses the command/data state of the SCSI buss to initiate a DMA
operation at the appropriate time so that the I/O speed is reasonable.
I have been in contact with a few SCSI peripheral manufacturers who admitted
that they "bent" a few rules so that their disks would actually be MAC
compatible, as opposed to merely being compatible with the spec on paper.  But
from the beginning, the -8 version of the interface, the CESI MDC8 card, was
always playing by the rules.  My first SCSI controller was an SMS ripoff of
the Shugart actual disk interface card.  Back then they didn't know anything
about common command sets or anything, so they replicated just about everything
except some hack commands that allowed the controller to copy between devices
without intervention from the host.  The reason was that the host could do
a device-host, host-device copy faster, and if you had no other disks, what
would you do on the host anyway? :-).

>but obviously the have managed better than DG in the long run.

I'm not so sure about that!

In any case, there were many situations where, without benefit of hindsight,
DEC lost out as predicted.  Also, remember, that had DEC done things right,
there never would've been a DG at all, just a moderately larger DEC.  Perhaps
today they would be faring better that way, etc.

cjl

---

From: [email-masked] (Robert Harper)
Date: Mon, 16 Aug 1993 14:00:36 GMT

Rather than enter into a tired old -8 vs -11 debate, let me just remark that
the core DEC Alpha architecture is _remarkably_ like the -8.  Most -11'isms
have been dropped entirely: back to fixed instruction length, skip
instructions, "operate" instructions, and so forth.  Some backward
compatibility support is provided (mainly for VMS), but in the main the new
architecture harkens back to the old, an implicit recognition of the failure
of the -11/VAX lineage.

-- 

Robert Harper

---

From: [email-masked]
Date: 16 Aug 93 09:15:44 MDT

> on the -8.  The compiler was canned, but MACREL was finished for no pay by

VAXeln.

On the subject of interrupt schemes, have you seen how Alpha does interrupts?
Processor jumps to a fixed location with mapping disabled and software gets to
sort it out. The PDP-8 interrupt scheme ain't dead yet...

Roger Ivie
[email-masked]

---

From: [email-masked] (Charles Lasner)
Date: 16 Aug 1993 18:12:56 GMT

>sort it out. The PDP-8 interrupt scheme ain't dead yet...

JB was trying to point out that the -11-style interrupt can be superior, and
I countered with the existence of the KF-12B API hardware, and the tentative
Omnibus version that was canned, etc.  Sometimes, depending on the CPU
instruction set, the extra complexity of the hardware can be counter-productive
thus a simpler structure allows software to tailor the interrupt service to
what's required, whereas a complicated one could actually be more overhead.

I once wrote -8 code where the interrupt priority was not according to the
norms.  In essence, the priority is to not lose any interrupts, as opposed
to the notion that any of them had priority over another unconditionally.
To accomplish this merely required an interrupt stack and reorganizing the
traditional interrupt structure so that essentially every foreground operation
was operating "in the background" meaning the source of interrupt had already
been dismissed, but the code is still grinding out the consequences in a way
equivalent (in priority) to background processing.  When it's actually
completed that code, it is officially dismissed and true background processing
is restored, but during that portion of the code, interrupts from other
sources are allowed.  This minimizes interrupt latency, but does not get
described by conventional API means, etc.

I guess the Alpha people wanted to allow software to tailor its own structure
in a like manner.

Incidentally, the 6121 support chips for the 6120 support vectored interrupts
where you issue one IOT and you wind up in the appropriate interrupt handler
without polling.  To do what I had to do on the -8 were this the hardware
present, I seriously think the latency would have been longer and the
code more complicated, not less so.  The KF12B API most definitely would
have been worse.  (I opted not to use it.)

cjl

---

From: [email-masked] (Jens Stark)
Date: Mon, 16 Aug 1993 10:10:11 GMT

>                   8086 MS-DOS 2.x and up

Hmm - there must be some missing link.

The first time I booted MS-DOS, I looked for PIP. DOS claimed not to know
what PIP was supposed to be. A program loader without PIP ? I could not
imagine that DOS could be successful at all.

Jens

---

From: [email-masked] (Johnny Billquist)
Date: 17 Aug 93 00:01:36 GMT

>80n86 series.  Certainly it's not popular due to its architecture.

No, in that specific case it *is* a question of the applications available.
But just because it is so in that case, does not mean that it is so in
every case, just as the opposite doesn't apply all the time.
However, there is always a purpose.
Did it enter your mind that different types of customers have different
purposes?
(Sorry if I'm sounding a bit irritated, but I think the above
comment was a little too much a reaction from the backbone, with
no thinking involved)
--
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: [email-masked]       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

---

From: [email-masked] (Johnny Billquist)
Date: 17 Aug 93 00:06:49 GMT

>many areas.  And of course by 1980 it was non-existent.

Well, can't say I got that much firsthand experience from it as you have,
so I won't try to argue on that one.
But also, your view is more extreme than mine.

>Yes, at the *very* beginning, since there wasn't yet anything else.  But later

Yes, we are mostly arguing about what is meant by "later".
When we are talking RT11 and RSX, MACRO-11 is still the language of choice
for many things to do.

>No, today it's just worse, not different.

I think we also agree on that one. However, at the time I'm tlaking about,
my view is that the problem was small enough to not be a problem at the
time. It has grown immensly since then.

>would have been 128K with the KT8A.

By 1985, The pdp-11 had already become to small, and we were talking
big VAXen with several megs of memory. 512K is nothing compared to that,
and still much less than the 4Mbyte of the pdp11, which was realized already
in 1975.
And it is not irrelevant in the long run, only in the short run, and
I think I have said it enough times, that in she short view, DEC could
have pushed more for the pdp8, at the expense of the pdp11, instead of the
other way around, but they probably would have lost on it in the longer run.
And by loosing I mean that overall sales would have mounted to less.

>Sorry, VMS 1.0 *IS* RSX.

No. It is not. Perhaps IAS, but definitely not RSX-11M.
Apart from the obious difference that they had a new file structure, there
are some stuff in VMS, that is clearly not in RSX-11M, but which is
in IAS, wuch as priorities in I/O requests. Much stuff differ, and
some stuff works different ways, and always have. They do have the same
ancestor, though, since RSX-11M also comes from IAS in a way.
--
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: [email-masked]       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

---

From: [email-masked] (James R Ebright)
Date: 17 Aug 1993 05:43:38 GMT

>No. It is not. Perhaps IAS, but definitely not RSX-11M.

Oh, come on.  VMS V1.0 was so much like 11-M I used 11-M handbooks.
It wasn't at all like RSTS (V6C was current when the VAX-11/780 was
introduced and it didn't look a bit like VMS).

>ancestor, though, since RSX-11M also comes from IAS in a way.

BTW, IAS is RSX-11D with a few diferences... 11M was a lot different
from 11D but IAS was not.

-- 
 Information farming at...     For addr&phone: finger             A/~~\A
 THE Ohio State University  [email-masked]   ((0  0))____
      Jim Ebright             e-mail: [email-masked]                 \  /      \
                          Support Privacy: Support Encryption      (--)\

---

From: [email-masked] (Geoff Mccaughan)
Date: 17 Aug 93 21:57:10 +1200

>> [...]

>But also, your view is more extreme than mine.

Cjl's view is more extreme than *everyone's*

--
Geoff, Sysop Equinox (equinox.gen.nz)  +64 (3) 3854406 [6 Lines]
   "If you have to run heating in winter, you don't own enough computers."
       Vote SPQR       Ski Nix Olympica       Freedom for Axolotls

---

From: [email-masked] (Martin Minow)
Date: Tue, 17 Aug 1993 15:02:05 GMT

If I may be so bold as to interrupt...

RT11 was done by many of the same people who had worked on OS/8. It
used some of the OS/8 ideas, but wasn't very similar inside. Its
primary goals were to provide a usable operating system with very
small memory/processor requirements. RT11 V1 ran comfortably in
4 K-words, as I recall, and could compile large Fortran programs
in an 8 K-word machine. It was a wonderful advance from the other
PDP-11 operating system of that era, DOS (of which the less said
the better).

CP/M used many design ideas from RT11, but these would have been
apparent to anyone who read the manuals.

At the introduction of Vax/VMS, the PDP-11 family supported a number
of semi-compatible operating systems:

-- RT11 for low-end single-user machines.
-- RSTS/E for timesharing (educational and commercial)
-- RSX-11M and RSX-11D for real-time process control
-- IAS (a high-end RSX-11D)
-- Mumps (a task-specific database system)
-- various task-specific executives (RSX-11A, for example).

Eventually, RSX-11M absorbed RSX-11D and all of the systems presented
a common command language (each with minor quirks). Also, RSTS/E could
run most non-real-time programs developed for RT11 and RSX-11M.

A rough o.s. lineage for the PDP-11 would be as follows:

pre-1972:  Paper-tape (IOX)
           DOS-11
           RSTS-11
post-1972 (introduction of the 11/45)
           RT-11
           DOS-11 -> DOS-Batch (dead end)
           RSTS-11 V4 -> RSTS/E
           RSX11D -> IAS
           RSX11A -> RSX-11M
           Mumps
post-1978 (introduction of Vax)
           RSX-11M -> VMS
           RSX11D, IAS merged with RSX-11M
 
Martin Minow
[email-masked]

---

From: [email-masked] ()
Date: 17 Aug 1993 16:08:07 GMT

Martin Minow writes

!A rough o.s. lineage for the PDP-11 would be as follows:
!
!pre-1972:  Paper-tape (IOX)
!           DOS-11
!           RSTS-11
!post-1972 (introduction of the 11/45)
!           RT-11
!           DOS-11 -> DOS-Batch (dead end)
!           RSTS-11 V4 -> RSTS/E
!           RSX11D -> IAS
!           RSX11A -> RSX-11M
!           Mumps
!post-1978 (introduction of Vax)
!           RSX-11M -> VMS
!           RSX11D, IAS merged with RSX-11M
! 

What about UNIX!? :-)

I actually am curious about DOS-11.  The only hear about it in obscure
places in RSTS/E manuals.   Did the file format carry over from DOS to
RSTS tapes?  Disk files?

Andy

---

From: [email-masked] (Charles Lasner)
Date: 17 Aug 1993 18:28:11 GMT

>Cjl's view is more extreme than *everyone's*

Well, remember who I am:

I am the author of the only O/S that wasn't an official DEC system for the -8.
The fact that it was offered to them and turned down has little to do with it.
(Note: the reason was that since it *could* be made to run in only 4K that
it "might lower memory sales" :-(.)

I am part of a group that predates the PDP-11.  I was using TOPS-10 before
there was a PDP-11.  I was using TOPS-10 sometimes to develop PDP-8 software
on PAL-10 using TECO as far back as 1968.  This group largely consists of
the people who became the core portion of the PDP-8 software development
group, and partially the -11 equivalent.

Most of the members of this group believe the -11 was a lame machine, which
repeated some of IBM's mainframe mistakes (byte addressing) and was influenced
by the later ACM articles, and also a few master's theses, which quantified
what members of the group were aware of from experience.

Additionally, posts with my signature on them sometimes represents the
opinions of others without usenet access.  Usenet access is sometimes not
as available as one might think, etc.  So, if it seems intense, it ought to
be!  Divide the intensity by N, where N=2,3,4 or so, and see if then it
is more reasonable :-).  (BTW, if you think *i'm* intense, you should here
some of the others who are just not net.people!)

cjl

---

From: [email-masked] (Martin Minow)
Date: Tue, 17 Aug 1993 21:41:45 GMT

In article <[email-masked]>, [email-masked] () wrote
> What about UNIX!? :-)
Sorry, I was thinking about "developed at Dec" operating systems.

> places in RSTS/E manuals.   Did the file format carry over from DOS to

DOS-11 (later Dos-Batch) was used to deliver RSTS/E to customers in the
V4/V5 timeframe. RSTS/E was compiled on-site to configure it for the
customer's particular hardware. After the disk image was built, DOS-11
was never seen again. Somewhere around the, umm, V6A of B timeframe,
RSTS/E became able to build itself without a separate support operating
system.

The tape format (extended to comply with the ANSI tape minimum record
length) carried over to RSTS and other PDP-11 O.S. The disk format,
fortunately, did not.

On a memory-limited mini, one of the most difficult problems for the O.S.
designer lies in organizing the on-disk file system. At the time Dos-11
was being developed, RF disks amd DECtapes had 512 Kbytes, with 2.5 and
5 Mbyte RK-series in the future. RT-11 ignored the problem: you created
a file at its maximum size and truncated it to the actual size when the
file was closed. Then, you periodically defragmented the disk to regain
contiguous space. RSTS and RSX allocated disk areas in chunks (RSTS
clusters) and used a pointer records (MFD/UFD) to locate the pieces
of a disk file (Unix uses a similar arrangement). (I'm using the RSTS
terminology as I never got as familar with the Files-11 disk format
internals.)

DOS-11 could either allocate a fixed-size contiguous disk area (fast
and efficient), or a sequential stream area. The latter stored data
in 510 bytes in a sector, and used the other two bytes to point to
the next sector. The disadvantage here is that, to delete a file,
you had to read the entire file one sector at a time. This made Fortran
compilations extremely slow.

Martin Minow
[email-masked]
ps: apologies to the alt.sys.pdp8 people -- my newsreader apparently
doesn't let me redirect the followup.

---

From: [email-masked] (Johnny Billquist)
Date: 18 Aug 93 10:16:38 GMT

>introduced and it didn't look a bit like VMS).

Well, you could use 11-M handbooks for IAS and survive too.
That don't make them the same.
--
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: [email-masked]       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

---

From: [email-masked] (Charles Lasner)
Date: 18 Aug 1993 13:30:07 GMT

>That don't make them the same.

You are using guesswork; I am using fact.  VMS 1.0 was a quick and dirty hack
on RSX.  I used it on an in-house machine.  It never really was a product
sold.  This was at the dawn of the VAX era.  Other than the I/O which was
native mode code, literally all of that early version was RSX as various
people loved/hated it.

Over the years, all of the code was removed/revamped.  They barely made it
through by the time VAXen came out without the -11 emulator present.  In fact,
TECO was deleted because there was no budget to convert it over.  (It got
done anyway, but later.)  The -11 emulator was incomplete, but did all you
needed other than the I/O module, etc.

VMS 1.0 looked little like what it eventually turned into.  Don't use any
more recent usage experience as a guide towards how it happened.  I was there
at the beginning.

cjl

---

From: [email-masked] (James R Ebright)
Date: 18 Aug 1993 13:40:32 GMT

>That don't make them the same.

True... but, for example, the Fortran compiler was actually RSX-11M's
running under the PDP-11 emulation mode.  The emulation mode was where
they got their 'layered products' -- a term not in use at that time --
and they were all RSX-11M products.

There was a good reason for this.  Dave Cutler, the architect/developer
of RSX-11M was one of the five people(!) who wrote VAX/VMS 1.0

Dave is now honchoing NT for Microsoft... Good career move as nothing is
doing at DEC anymore :(  except for Supnik's group.

---

From: [email-masked] (Johnny Billquist)
Date: 18 Aug 93 14:57:47 GMT

>native mode code, literally all of that early version was RSX as various

But the I/O is one of the things that really differs between RSX-11M and VMS!
RSX don't care about priorities on I/O requests, IAS does, and so do VMS!
--
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: [email-masked]       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

---

From: [email-masked] (Johnny Billquist)
Date: 18 Aug 93 15:01:08 GMT

>and they were all RSX-11M products.

The same compiler is also used in IAS.
The reason it's called RSX-11M's is because that had the largest
installed base of customers.
RSX-11M products and IAS products are very often the same.
Not that many differs. The same programs can run, but the OS
in the bottom differs.
However, I'll concede as much as that VMS is a hybrid.

>of RSX-11M was one of the five people(!) who wrote VAX/VMS 1.0

I know.

>doing at DEC anymore :(  except for Supnik's group.

Don't kow if I agree with it being a good move. I think that anything
that MS gets involved in, eventually will be a joke, no matter who the
individuals involved are.

As for what DEC's doing now, don't ask me.

---

From: [email-masked] (Mike Yankus)
Date: Wed, 18 Aug 1993 15:56:01 GMT

>           RSX11D, IAS merged with RSX-11M

IAS is a direct descendant of RSX-11D.  IAS release 3.0 merged RSX-11D and
IAS 2.0 into a single product.  (I am a previous user of RSX-11D, going back
to release 4, and currently use IAS 3.5.)  I think you will find that RSX-11M
was built directly from RSX-11D.  As I vaguely recall, the original RSX-11M
was advertised as "a proper subset of RSX-11D."  After RSX-11M became more
widely used than IAS or RSX-11D, due to lower license cost, DEC was adding
new features to RSX-11M/RSX-11M+ faster than to IAS.  Memory management
directives come to mind.  Thus the appearance that there was some "merging."

Currently, IAS and RSX share the same source code for the file system and many
utilities.  In this respect, they are more alike than different (PIP is PIP!).
>From a user perspective, the big difference is support of DCL.  RSX-11D never
had it.  The earlier IAS releases had nothing but.  Current IAS (since 3.0)
supports either DCL or MCR command language interpreters (CLIs).

-- 
Mike Yankus	             UUCP:     uunet!sparky!yankus
PRC Inc.                     INTERNET: [email-masked]
1410 Wall St.                Phone:    (402) 291-8300 
Bellevue, NE. 68005-3687     FAX:      (402) 291-4362

---

From: [email-masked] (Charles Lasner)
Date: 18 Aug 1993 19:19:10 GMT

>RSX don't care about priorities on I/O requests, IAS does, and so do VMS!

No, not on *that* VMS!  This is V 1.0 we're talking about!  All you know
about VMS was to come later as a 100% rewrite, and in some cases, even
more than that as it was changed several times!  I mean the literal input
and output disk and terminal operations level and no more are native VAX
code at that early point.

cjl

---

From: [email-masked] (Jens Stark)
Date: Wed, 18 Aug 1993 13:32:33 GMT

>           RSX11D, IAS merged with RSX-11M

What about the PDP-15 ? I remember that I used a mag tape ( oops. dectape )
based operating system once, which even swapped to tape. 
Can anybody confirm that and give more info on that thing ?

Greetings,  
   Jens

---

From: [email-masked]
Date: Tue, 17 Aug 93 21:18:06 EDT

>and still much less than the 4Mbyte of the pdp11, which was realized already

PDP-11s really went to 4 meg? The VAX-11/780 topped at 2 meg, no?

------------------------ uunet!quack!gilly!dave ------------------------
================= Dave Fischer - Nature's Perfect Food =================
----------------------- [email-masked] ------------------------

---

From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879)
Date: Thu, 19 Aug 1993 13:52:40 GMT

>From article <[email-masked]>,
> Can anybody confirm that and give more info on that thing ?

The PDP-15 was not related to the PDP-11, except in the sense that both
used a UNIBUS to handle peripheral interfacing.  Specifically, the PDP-11
was a 16 bit machine, and the PDP-15 was an 18 bit machine (ever wonder
why the UNIBUS allowed for 18 bits -- it wasn't just to support the memory
management unit on the 11/45!).

Thep PDP-15 was upward compatable from the PDP-9, which was upward
compatable from the PDP-7, which was upward compatable from the PDP-4,
which hit the market in 1962.  The PDP-1 was also an 18 bit machine, but
I don't think it was compatable with this series.

In any case, the PDP-7 and PDP-9 both supported DECtape, and DECtape based
operating systems were originally developed on those machines, and they
moved naturally to the PDP-15.  I don't know the particulars of the PDP-15
operating system, but I suspect that, like other contemporaneous systems
on computers sold for real-time process control, it allowed a single
interactive user in the background while it ran real-time process control
tasks in the foreground.

The PDP-15 was the last of a pround lineage of 18 bit computers made by
DEC, and that lineage included some machines used in very important
real-time control applications.  Among these, at least one PDP-4 seems to
have lasted for years running the computer controlled wire-wrap machines
that were used to wire the backplanes for the original PDP-8 and other
late second generation machines built by DEC.

					Doug Jones
					[email-masked]

---

From: [email-masked] (Stephen C. Woods)
Date: 19 Aug 93 16:10:38 GMT

#!pre-1972:  Paper-tape (IOX)
#!           DOS-11
#!           RSTS-11
#!post-1972 (introduction of the 11/45)
#!           RT-11
#!           DOS-11 -> DOS-Batch (dead end)
#!           RSTS-11 V4 -> RSTS/E
#!           RSX11D -> IAS
#!           RSX11A -> RSX-11M
#!           Mumps
#!post-1978 (introduction of Vax)
#!           RSX-11M -> VMS
#!           RSX11D, IAS merged with RSX-11M

Causing much grief and discontent among IAS programmers.  RSX-11M had the
most Baroque tty driver it has ever been my misfortunate to have to deal
with.

>places in RSTS/E manuals.   Did the file format carry over from DOS to

Interestingly enough, Dec PDP-11 diagnostics ran/run on DOS-11 (a fate
worse that death, I assure you).

-- 
-----
Stephen C. Woods; UCLA SEASNET; 2567 BH;LA CA 90024; (310)-825-8614
UUCP: ...{ibmsupt,ncar!cepu}!ollie}!scw  Internet:[email-masked]

---

From: [email-masked] (Charles Lasner)
Date: 19 Aug 1993 20:59:36 GMT

>management unit on the 11/45!).

Yes, certain -15 memory options used UNIBUS memory.  There never was any
peripheral handling for the UNIBUS with one notable exception: the UNICHANNEL.

This was an actual PDP-11/05 with a fudged UNIBUS device that was 18 bits wide
in the -11.  There is a small mod to the RK11-D that makes it an RK11-E which
is 18-bits transfer and the data is slightly "crowded" compared to the normal
data rate on the RK05 pack.  It can't use regular 16-bit RK05 packs due to
the different recording rate, but you can freely reformat the disk packs and
then use them.  I know someone who runs RT-11 on this machine with no problems.
The data is available to the -15 as 18-bit data, and the -11 CPU only sees
16-bits of that in its shared window memory.  The -11 is normally the slave,
and runs a dedicated serving program called PYREX.  The -15 makes I/O requests
by poking into the shared memory into the bits the -11 can see changes in,
and it then acts on them, accomplishing some I/O operation and then reporting
it back by also poking into the same memory, etc.  Thus, the -11 can cause
DMA to happen into memory it can't (completely) access.

This system also supports more conventional UNIBUS peripherals for the benefit
of the -15 such as an RX01/02 or even a DZ-11.  Thus, it is also a front-end
for the -15 if need be.  (For something like multi-user MUMPS or a third-party
version thereof, etc., or even RSX-15, which predates RSX-11, and possibly
unix.)  All of the memory has to be 18-bits on the 18-bit UNIBUS, similar
to and compatible with the UNIBUS memory which might be attached to the -15
itself, etc.

>interactive user in the background while it ran real-time process control

Like the PDP-8, the -15 has the PDP-9 negative buss, and its own positive
buss, so it has the TC02 and TC15 DECtape controllers (instead of TC01 and
TC08 respectively).  The guts of both are remarkably similar to their
respective -8 counterparts, and are programmed as similarly, etc.

The ADSS system is quite awful, and is in part *why* unix got written, since
it about the most abominable thing ever run on DECtape.  Knowledgeable users
don't call it "ADSS" since it's proper abbreviation should come from its
name: Advanced Software System - ASS, which is an appropriate name.  Some
marketroid saw this and added the unwarranted "D" in there to avoid that
problem :-).

This system gets extended to a disk version and is then known as DOS-15.
The -15 version can be made to run as a PDP-9 subset or a PDP-15 to change
the addressing mode to either have double-size pages (9) or index register
activity (15).

Most -15 systems were physically quite large, more like -10 systems.  This
was the lowest DEC machine where an entire machine room was considered
acceptable, even though the machine could be only a 32K 18-bit cousin of
the PDP-8, with mostly software much inferior to its 12-bit cousin.

There exists a PDP-8 simulator that boots actual PDP-8 bootable DECtapes
on a PDP-15 directly.  Speed is about 10% of actual PDP-8, but the DECtape
I/O is full-speed due to emulation as opposed to inst-x-inst simulation for
the tape I/O.  The simulator can run OS/8 and P?S/8 configured specifically
for TC01/08 DECtape.  It also supports the -15's console terminal as the
device 03/04 console completely, as well as the reader/punch as a PDP-8
PC04/05 reader/punch completely.

At a certain installation I knew, the users admitted that the PDP-8 simulator
running PDP-8 software was the most effective use of the machine they had
ever seen :-).

We also used it to get line-printer listings.  (Most -15's had magtapes and
large line-printers, etc.)

cjl

---

From: [email-masked] (Don Stokes)
Date: 20 Aug 93 08:32:26 GMT

> PDP-11s really went to 4 meg? The VAX-11/780 topped at 2 meg, no?

Yes pdp11s went to (nearly) 4MB in the 11/70, /23, /24, /73, /83, /84, /53,
/93 and /94 models (in roughly chronological order).

22 bits worth of addressability is an architectural limit, based on the
layout of the page address registers.  Putting more memory on a pdp11 would
require either re-writing the OS routines associated with memory management
or doing nasty hacks that left the OS thinking it had only 4MB available.

The VAX 11/780 could go to (I think) 16MB, maybe more -- I can't remember
how big the physical address paths were and what reason for the limit was
(ie could third party boards take it up).  It was certainly somewhat more
than 2MB...

Mind you, the /780 came out with memory sizes of 512k or less.  OTOH, I
was trying to track down a problem in my VSII while rebuilding the machine
in two BA23s, and to attempt to isolate the problem, put a KA630 (processor
board) into the slot where the bus extender would (and now does) go, and
attempted to boot.  The KA630 has 1MB of memory onboard -- VMS V5.3 took
one look at the size of its available memory and refused to go any
further.

Last time I ran VMS in 1MB it was under V4.1 on a uVAX I.  I did have VMS
V5.1-1 going in 3MB on a uVAX I with a 30MB disk.

They don't write OS code like they used to...

--
Don Stokes, CSC Network Manager, Victoria University of Wellington, New Zealand
Ph+64 4 495-5052  Fax+64 4 471-5386  Work:[email-masked]  Home:[email-masked]

---

From: [email-masked] (Dan Pop)
Date: Fri, 20 Aug 1993 14:58:01 GMT

>/93 and /94 models (in roughly chronological order).
I don't see the /44 in this list. Why?

Dan

---

From: [email-masked]
Date: 20 Aug 93 15:38:16 MDT

> management unit on the 11/45!).

Yes, but where did they get the data lines? Did they take over the parity
signals?

Roger Ivie
[email-masked]

---

From: [email-masked] (Johnny Billquist)
Date: 21 Aug 93 13:27:42 GMT

>PDP-11s really went to 4 meg? The VAX-11/780 topped at 2 meg, no?

Yes. The pdp-11/70 was (I think) the first 22-bit address pdp-11, and
it came in 1975. At that time, to get all 4 megs, you needed an
additional memory cabinet, and a total of 8 MK-11 boxes. Later, when
the 256Kbyte memory cards came for the MJ-11 memory box, one memory
box for the 11/70 could hold all 4 megs.

Where did you get the idea that the 11/780 only went to 2 megs???

---

From: [email-masked]
Date: Sat, 21 Aug 93 16:06:48 EDT

>(ie could third party boards take it up).  It was certainly somewhat more

Oh. I was looking at the original "VAX Architecture Handbook" that announced
the VAX-11/780, and it specified a 2 meg limit. Was this fixed with higher
capacity RAM chips, or what?

>Mind you, the /780 came out with memory sizes of 512k or less.  OTOH, I

Tha handbook says the minimum config was 128K. Now THAT would have benn
painfull! Did any 128K VAXen actually ship?

----------------------- [email-masked] ------------------------

---

From: [email-masked] (John Whitmore)
Date: 23 Aug 1993 10:17:50 GMT

>>The VAX 11/780 could go to (I think) 16MB, maybe more --

	There was an upgrade (hardware rewiring and new memory controller
board) at one point; the before-upgrade limit may have been 2 Mbytes.

>painfull! Did any 128K VAXen actually ship?

	Yes.  I have some of their memory boards here; the 
date is Nov 1977, and the boards are 11" by 16" and hold
144 memory chips each.  The chips are MK4027 type.

	That's a whopping 64k bytes (with parity) per board.
The old MK4027 is a 4kbit dynamic RAM.

	John Whitmore

---

From: [email-masked] (Paul Repacholi)
Date: 24 Aug 93 07:42:26 +0900

> In <[email-masked]> [email-masked] (Charles Lasner) writes:
...
> RSX don't care about priorities on I/O requests, IAS does, and so do VMS!

check the code. M uses the task priority for io, and ignores what you
put in the QIO. D and IAS use the QIO value iff <>0, else task.

Hey Charles, do you know the Zigglet story?

~Paul

---

From: [email-masked]
Date: Mon, 23 Aug 93 09:06:24 EDT

>Where did you get the idea that the 11/780 only went to 2 megs???

	"MOS memory may be added in increments of 128K byte units to a
	maximum of 1 million bytes per controller. Two memory controllers
	may be connected to a VAX-11/780 system, for a total of 2 million
	bytes of physical memory. (The minimum memory requirement is
	128K bytes.)"

		- _VAX11/780_Architecture_Handbook_, digital, 1977.

So, how did they get past that?

----------------------- [email-masked] ------------------------

---

From: [email-masked] (Johnny Billquist)
Date: 25 Aug 93 00:39:37 GMT

>So, how did they get past that?

Typical DEC vaporware. Just because DEC didn't make bigger memory cards
than 128Kbytes, they said the maximum memory on the machine was 2 megs.
But many more address lines exist, so just by using larger memory cards,
you get more memory into the machine.
--
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: [email-masked]       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

---

From: [email-masked] (Johnny Billquist)
Date: 25 Aug 93 00:41:36 GMT

>put in the QIO. D and IAS use the QIO value iff <>0, else task.

*Sigh*. Final comment from my side.
Yes, M uses the task priority, ie. it *don't* care about priorities in
I/O reuqests.
D and IAS do, as do VMS. (Or is my memory wrong on this?)
--
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: [email-masked]       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

---

From: [email-masked] (Thomas Bellman)
Date: 26 Aug 93 11:48:01 GMT

> you get more memory into the machine.

Now that's a new variant of vaporware.  Most computer manufacturers
promise *more* than they can deliver, but DEC obviously promised
*less* than they delivered.  Pity that so few companies do this...

--
Thomas Bellman,  Lysator Computer Club,  Linkoping University,  Sweden
Email: [email-masked]   Phone (home): +46 - 13 177780

---

From: [email-masked]
Date: 27 Aug 93 12:50:44 +0930

> used some of the OS/8 ideas, but wasn't very similar inside. Its

One difference that seemed significant to me at the time I used these things, 
was that OS/8 turned interrupt of, RT11 of course had it on.

Regards,

John Bennett                                   [email-masked]

---

From: [email-masked] (Paul Repacholi)
Date: 28 Aug 93 23:46:56 +0900

...
> painfull! Did any 128K VAXen actually ship?

The SPD for v1.? or v2.? ( can't remember now, _very_ early ) gives
a *MAXIMUM* of 256KW. ie, 8k more than a 34...

It also said 398 users!

~Paul

---

From: [email-masked] (William Chesters)
Date: Sat, 28 Aug 93 16:37:02 GMT

In article <[email-masked]>, [email-masked]
(Paul Repacholi) writes:
# The SPD for v1.? or v2.? ( can't remember now, _very_ early ) gives
# a *MAXIMUM* of 256KW. ie, 8k more than a 34...

I've seen the jokes about space heaters, but this is ridiculous.

-- 
William "now *that* might stop us running out of hot water" Chesters
`/usr/games/fortune`

---

From: [email-masked] (Ethan Dicks)
Date: 28 Aug 93 23:13:19 EDT

Paul Repacholi ([email-masked]) wrote:
: In article <[email-masked]>, [email-masked] writes:
: > [email-masked] (Don Stokes) writes:
: ...
: > 
: >>Mind you, the /780 came out with memory sizes of 512k or less.  OTOH, I
: > 
: > Tha handbook says the minimum config was 128K. Now THAT would have benn
: > painfull! Did any 128K VAXen actually ship?

I worked for a company that bought a VAX-11/750 (S/N BT000254) that shipped
with 512K (on two cards).  That machine was in active service until about
two weeks ago.  Mind you, it was upgraded to 8Mb a few years ago.

: The SPD for v1.? or v2.? ( can't remember now, _very_ early ) gives
: a *MAXIMUM* of 256KW. ie, 8k more than a 34...

The SPD for v1.0 had a restriction of that nature.  I can't easily reference
my copy of it because my VAX/VMS v1.0 manuals are packed in storage.  They
make for humorous reading when viewed with hindsight.

Also, The 11/34 had to share memory space with an I/O page.  The VAX 
architecture allowed for a full power-of-two RAM space with I/O space residing
entirely outside the area available for RAM.  To access I/O, you had to be in
kernel mode or have a kernel mode process map the I/O page into the 4Gb virtual
space of your process.  Since very few processes actually had to hammer I/O
registers directly (unlike PDP-11 programs), this does not normally represent
a problem.

-ethan