From news.columbia.edu!watsun.cc.columbia.edu!lasner Wed Dec  2 22:54:21 EST 1992
Article: 107 of alt.sys.pdp8
Xref: news.columbia.edu alt.folklore.computers:34615 alt.sys.pdp8:107
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: news.columbia.edu!watsun.cc.columbia.edu!lasner
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: Me and my PDP... (long)
Message-ID: <1992Dec2.140917.3073@news.columbia.edu>
Sender: usenet@news.columbia.edu (The Network News)
Nntp-Posting-Host: watsun.cc.columbia.edu
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
References: <ByM0CI.5EJ@news.chalmers.se>
Date: Wed, 2 Dec 1992 14:09:17 GMT

In article <ByM0CI.5EJ@news.chalmers.se> lape@me.chalmers.se (Lars Persson) writes:
>
>Here the two major bus types. UNIBUS and QBUS. The UNIBUS is a
>replacement of the OMNIBUS (!) from the forerunner the PDP8. The UNIBUS

Wrong:

PDP-8 Positive buss: 1968.  Cables between wire-wrapped assemblies.  The cables
are coax or flat ribbon only if run short.  Buss is always synchronous.

UNIBUS for 11/20 et al. 1969 (in prototypes).  Wide flat ribbon cables between
wire-wrapped assemblies.  Buss is asynchronous to allow longer lengths.

OMNIBUS for PDP-8/e et al. 1970.  Buss is made from the same module blocks as
the other busses but has a printed circuit board to interconnect all fingers
in all slots; there are *no* exceptions, thus no dedicated slots (save the
fact that the CPU stuff has to be at one end and the terminator at the other
end more or less; newer configurations could even redefine which end was the
"front").  Total buss length is 20 slots of module blocks.  Similar to UNIBUS
M920 buss jumpers (for short UNIBUS runs) are the M935 OMNIBUS jumpers which
of course jumper all fingers (M920 do not; typical for UNIBUS it has exception
cases and jumpered fingers, etc.).  Two M935's are used to extend the buss
when it is housed in the PDP-8/e box to a total of 40 slots (38 due to the
overhead of the M935's themselves).  (The smaller PDP-8/f and /m cannot be
extended as such.)  Several years later, the first attempt to expand this
to a second box using BC08H cables.  (BC08H is electrically an M935 only
it looks like a UNIBUS cable, because all of these are made from the same
wide flat stiff ribbon cable; again, BC08H is one-for-one on connection
fingers whereas UNIBUS is not; had DEC rethought the implication of the
few inconsistencies of the UNIBUS here, there would not have been two similar
families of cables.)  Many ECO's later, the attempt is actually viable thus
allowing *reliable* operation of two boxes connected by cables.  OMNIBUS is
synchronous, which is part of the reason for all the problems with extending
it.  Later versions appear (PDP-8/a) with various similar cabling systems
between boxes.  The boxes get smaller (10,12,20 maximum) as the peripherals
get smaller (but likely packaged on hex boards to give a theoretical boost
of "real estate" of 50% if applicable, which often is *not* the case).  The
BC80C cable is created to connect between a hex box and a quad box.  (BTW,
this is the scheme of my own system.)

Still later, the Q-bus appears in various formats.  It is clearly a mechanical
cousin of the OMNIBUS using a printed circuit board on the same blocks.  The
Q-BUS can be defined in two slots, but is often quad (while OMNIBUS is always
quad).

cjl


From news.columbia.edu!sol.ctr.columbia.edu!eff!ssd.intel.com!prp Wed Dec  2 22:54:42 EST 1992
Article: 108 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: news.columbia.edu!sol.ctr.columbia.edu!eff!ssd.intel.com!prp
From: prp@ssd.intel.com (Paul Pierce)
Subject: Re: Federated Consultants?
Message-ID: <BynAqr.2FA@SSD.intel.com>
Sender: usenet@SSD.intel.com
Nntp-Posting-Host: nautilus
Organization: Intel
References:  <1992Nov30.222516.2661@news.uiowa.edu>
Date: Wed, 2 Dec 1992 18:44:51 GMT

In article <1992Nov30.222516.2661@news.uiowa.edu>, jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes:
|> I tried mail and phone contact with Federated Consultants, and failed to
|> make contact (the mail was returned as undeliverable, and the 800 number
|> got me to some men's journal).  Have they gone the way of the dinosaur?

I just got mail from them. It lists a new phone number:

1-800-256-6732

I tried it, it works.
They list Omnibus boards at $75 and up (way up).

|> ESS Limited is still out there, and they list many Omnibus boards at
|> $75 each (I just phoned them).

Whats their contact info?

|> 					Doug Jones
|> 					jones@cs.uiowa.edu

-- 
Paul Pierce			prp@ssd.intel.com
Intel


From news.columbia.edu!sol.ctr.columbia.edu!emory!europa.asd.contel.com!darwin.sura.net!wupost!micro-heart-of-gold.mit.edu!eddie.mit.edu!eplunix!ijs Thu Dec  3 19:00:07 EST 1992
Article: 109 of alt.sys.pdp8
Path: news.columbia.edu!sol.ctr.columbia.edu!emory!europa.asd.contel.com!darwin.sura.net!wupost!micro-heart-of-gold.mit.edu!eddie.mit.edu!eplunix!ijs
From: ijs@eplunix.UUCP (Ishmael J. Stefanov-Wagner)
Newsgroups: alt.sys.pdp8
Subject: PDP8 Manuals available
Message-ID: <1314a@eplunix.UUCP>
Date:  3 Dec 92 14:47:15 GMT
Organization: Eaton-Peabody Lab, Boston, MA
Lines: 25

Available in Boston, Massachusetts - historic DEC PDP-8 manuals!
You pick up...

We have four boxes, approximately 1 cubit x 0.75 cubit x 0.5 cubit,
full of historic DEC manuals, including various versions of the
Small Computer Handbook from the late '60s and early '70s, Introduction
to Programming, Programming Languages, Logic Handbook (detailed descriptions
of the modules which make up PDP8s) etc.  In addition there are some
PDP-11/40 /35 etc paperbacks, plus software and peripherals manuals.
These are an absolute must for the serious Digital Equ. Co. collector,
but due to circumstances are bound for the dumpster unless someone
rescues them before the Solstice!

Possibly also available - DECUS PDP-8 dectapes, TU55 logic.

Inquiries - Tel: 617-573-3748 / Fax: 617-720-4408  or via e-mail.

|\___/|		Ishmael J. Stefanov-Wagner
|/. .\|		Eaton-Peabody Laboratory, Boston, MA
 \=^=/		eplunix!ijs  or  ijs@eddie.mit.edu

"If DEC can get their act together and start shipping them [the Alpha
 machine] in quantity, I think they've got a serious compute box on
 their hands for the first time since the PDP-8."
					--Steve P. Lamont


From news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news Thu Dec  3 19:00:53 EST 1992
Article: 110 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Subject: Re: PDP8 Manuals available
Sender: news@news.uiowa.edu (News)
Message-ID: <1992Dec3.210824.5718@news.uiowa.edu>
Date: Thu, 3 Dec 1992 21:08:24 GMT
References: <1314a@eplunix.UUCP>
Nntp-Posting-Host: pyrite.cs.uiowa.edu
Organization: University of Iowa, Iowa City, IA, USA
Lines: 23

>From article <1314a@eplunix.UUCP>, by ijs@eplunix.UUCP
(Ishmael J. Stefanov-Wagner):
> Available in Boston, Massachusetts - historic DEC PDP-8 manuals!
> You pick up...

I've got a growing collection of documentation, but I need more.

Unfortunately, I can't get up to Boston before the solstace, but I'll
gladly pay postage for some of the more choice manuals!  If someone in
the Boston area can help pick these up and mail them out, I'm looking
for PDP-8/E and F documenation (1973 date on the cover is what I'm
targeting), and I'm looking for peripheral equipment documentation
from 1965 and 1966, specifically, for the DEC A-D converter, model
138E and for the high speed paper-tape reader punch interfaces from that
era (Type 750C Perforated Tape Reader and Control, and Type 75E
Perforated Tape Punch and Control).

If DECtape hardware becomes available, I'd sure like to know, but the
shipping to Iowa might be a bit steep.
                                        Doug Jones
                                        jones@cs.uiowa.edu




From news.columbia.edu!watsun.cc.columbia.edu!lasner Mon Dec  7 22:25:40 EST 1992
Article: 111 of alt.sys.pdp8
Xref: news.columbia.edu alt.folklore.computers:34884 alt.sys.pdp8:111
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: news.columbia.edu!watsun.cc.columbia.edu!lasner
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: The NOVA and the PDP-11  (Was Re: WANTED: PDP-10 or 11)
Message-ID: <1992Dec6.214758.3004@news.columbia.edu>
Sender: usenet@news.columbia.edu (The Network News)
Nntp-Posting-Host: watsun.cc.columbia.edu
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
References: <1992Dec4.212403.10103@news.columbia.edu> <3633339@zl2tnm.gen.nz>
Date: Sun, 6 Dec 1992 21:47:58 GMT

In article <3633339@zl2tnm.gen.nz> don@zl2tnm.gen.nz (Don Stokes) writes:
>
>> >True.  Data General is interesting to DECaholics because of its origins;
>> >earlier DG machines are in some ways what DEC machines might have been.
>> 
>> It is interesting that Tracey Kidder steered away from this issue in the
>> Soul of a New Machine book.  Perhaps we should state our own versions of
>> the tale as we see it.
>
>Well, my version of the tale, gleaned from multiple sources (including
>Kidder) goes something like this:
>
>Edson de Castro worked on the PDP-8.  When the call came for a 16 bit
>machine, de Castro's group started work on what amounted to a 16 bit PDP-8
>(single word, single operand instructions, word oriented addressing etc).

Edson de Castro was Chief Engineer of the original negative logic PDP-8.  He
wanted to work on the newer TTL that had just emerged as the obvious 
direction the industry was going in, and had little interest in the PDP-8/i
project; he wanted something more challenging, such as a 16-bit machine that
was in the "family" of machines such as the -8, but newer hardware.  Apparently
his "group" was as large as several hundred people working on what amounts to
the NOVA as it became known later.  Also, this design was partially serial,
and thus vaguely reminiscent of this notion as carried out in the PDP-8/s,
a losing totally serial version of an -8 that wasn't entirely compatible with
it, and as such, is incapable of running the vast majority of PDP-8 software
no matter how slowly it attempts it, etc.  (It is curious that even years
later there was a NOVA micro that was two-bit serial on the outside.  These
guys are hung up on the trade-off towards non-parallel designs!).

Some quirky aspects of the NOVA are taken straight from the PDP-8, such as
the special disposition of the auto-index registers, etc., so yes, the
short-form of this discussion could be that the design was for a 16-bit
follow-on to the PDP-8 family.

>
>Sometime after de Castro's group got started, another development got under
>way, developing a 16 bit architecture with a multiple word two-operand
>instruction set and half word oriented addressing.  This group also had the
>VP of Engineering's ear and blessing.

As I heard it, it ain't as clean as that:

C. Gordon Bell was technical god at DEC just then.  He could do no wrong
and had KO's ear for any purpose.  Bell was into writing books at that time,
and "Digital Press" was created as the outlet for his work, etc.  Bell had
designed a register-description notation as part of a book he was working
on.  It is a separate matter as to whether this notation is useful for
describing machine architecture, but the relevant point is that *he*
thought so.

Apparently, two young relative newbies in DEC engineering read his work and
used it to toy around with a new machine design (which eventually became the
-11).  Their work is not fully polished, and suffers from some inconsistencies.
(Such as the condition codes aren't exactly the same as a result of an
increment or decrement as opposed to adding or subtracting 1, or that
byte forms of instructions don't quite set the same results as the word forms
of the same instructions.  The point is that a carefully planned work of
architecture design would have located these shortcomings and corrected them.
Much has been published about these issues elsewhere, etc.)

It apparently came down to the fact that the "green light" had been given
for the NOVA project, and sub-design teams formed, etc.  Note that one of
the design goals for this project was to use larger boards to overcome the
limitations of FLIP-CHIP modules which can't have much functionality per
card because of lack of fingers.  Back in the negative logic days, a
one-sided card with 18 fingers was generally adequate because you could only
put so much discrete logic on a module.  But de Castro realized that with the
advent of TTL, merely making the cards double-sided wouldn't be enough.  His
idea has been vindicated since the next few DEC machines all suffer from the
same problem: lots of little cards with mostly empty space on them.  Using
only two or three chips uses up all of the fingers, so you shortchange TTL's
ability to downsize the design and only achieve 2-3 times the shrinking as
compared to discrete negative logic using the same size cards with 36 fingers
total.  By using much larger cards, the chips interconnect, not the modules.
Thus, the larger cards usefully are constructed from a decent number of TTL
packages, and only a buss approach goes off the cards onto a goodly number
of fingers.  This eliminates a lot of wire-wrap and opens the possibility
of making a pc-board buss such as the later OMNIBUS of the PDP-8/e.

>
>It came to a contest between the two architectures to produce what would be
>the PDP-11.  de Castro's group lost, and the PDP-11 became the two-operand
>architecture we know and love.  de Castro resigned immediately to set up
>Data General.  The first computer was the Nova, the architecture of which 
>looked *suspiciously* like that of the 16 bit computer he developed at
>DEC.....  The Nova became the Eclipse and then the 32 bit Eclipse MV series
>in response to the release of the VAX 11/780 by DEC in 1977.  The story is
>taken up in detail from 1977 by Tracy Kidder's book.

Bell's ego was stroked by the hasty work of the two newbies.  He pulled all
the strings he was capable of, including telling KO to pull the plug on the
NOVA project because this was so much better than it wasn't worth persuing
it anymore, even though hundreds of people were committed to it, etc.  As
a result of this politicizing, the -11 design was pushed through hurriedly,
and didn't stop for any analysis of the design for holes, etc., so it was
produced, horns and all, as originally specified, and onto a typical
inefficient design with lots of little cards as the 11/20.  (Admittedly some
of the modules were a little bigger than the typical small M-series module,
but then again this size also exists on certain PDP-8 peripherals as the
"double-height" card in R-series, etc.)  In fact, some of the mechanical
parts of the 11/20 are identical to the 8/l and 8/e, proving that the
details of the project were expediently handled, instead of doing a
complete ground-up design as in the past.

>
>As to whether the pdp11 succeeded soley because the VP liked the guy 
>behind it, we'll never really know.

That depends on the veracity of the story.  Human nature being what it is,
it is likely that some of the way it was retold to me is exaggerated.  What
is true, is that de Castro and 200 or so people quit DEC simultaneously and
quickly formed DG and produced NOVAs from then onward.

>  However, the architecture *is* nice;
>I'd say it has a lot less warts than the PDP-8 or PDP-10, given that it 
>is a 16 bit minicomputer architecture.

Your opinion isn't a given, although I really don't want to open the topic
about the -11 versus the -8 and company.  However, it is sufficient to say
that there are debatable issues about 16 bit machines in general, byte
versus word addressing, and specifics regarding inconsistencies in the -11
design specifically, and whether or not a lot of its popularity stems from
the usefullness of the software as opposed to the underlying architecture.
(There are many people enamoured of RT-11, not the -11 per se.  In fact, they
want RT-32 or RT-64 for their favorite 32 or 64 bit designs, not -11
compatibility at all.)  Moreover, it is clear that DEC imposed the -11 into
some situations where clearly the -8 was more than adequate.  In one infamous
example, DG underbid DEC in selling a large number of systems to Disney because
the NOVA systems were cheaper than DEC's -11-based offerings, and clearly the
-8 could have brought in a more competitive system for the project.  (From
what I understand about the requirement, a modern version of this project
would specify something akin to hundreds of 8051-class 8-bit controller micros,
but they didn't exist back then.)


>  Competition is basically the way
>development is done within DEC -- products fly or die on their merits (or
>by favourably impressing an appropriate VP).  People do resign over these
>decisions; de Castro's case is only remarkable because he went and set up
>a reasonably successful company in quite direct competition with DEC.

True, but not useful; it's one of DEC's long-term major shortcomings that
each project attempts to get funded by backstabbing everything else, and
attempting snow jobs on technically incompetent upper management types.  A
notable example: the VAXmate, which was undeliverable for over two years, yet
caused the cancellation of other viable projects while it stalled and 
eventually burned.

>
>Kidder does avoid the question of de Castro's departure, but he does
>allude to some of the conflicts between DG and other parts of the computer 
>industry, especially DEC.  

It would be interesting to expand on these issues.  Maybe DEC will not
repeat their mistaken patterns of the past.

>
>
>--
>Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
>Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
>Victoria University of Wellington, New Zealand              +64-4-495-5052


cjl


From news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!darwin.sura.net!wupost!waikato.ac.nz!comp.vuw.ac.nz!zl2tnm!toyunix!don Mon Dec  7 22:29:33 EST 1992
Article: 112 of alt.sys.pdp8
Xref: news.columbia.edu alt.folklore.computers:34915 alt.sys.pdp8:112
Path: news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!darwin.sura.net!wupost!waikato.ac.nz!comp.vuw.ac.nz!zl2tnm!toyunix!don
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Subject: Re: The NOVA and the PDP-11  (Was Re: WANTED: PDP-10 or 11)
Message-ID: <3250341@zl2tnm.gen.nz>
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 7 Dec 92 11:02:56 GMT
Sender: news@zl2tnm.gen.nz (GNEWS Version 2.0 news poster.)
References: <1992Dec6.214758.3004@news.columbia.edu>
Distribution: world
Organization: The Wolery
Lines: 149

lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
> Edson de Castro was Chief Engineer of the original negative logic PDP-8.  He
[...]
> C. Gordon Bell was technical god at DEC just then.  He could do no wrong
[...]
> Bell's ego was stroked by the hasty work of the two newbies.  He pulled all
> the strings he was capable of, including telling KO to pull the plug on the
> NOVA project because this was so much better than it wasn't worth persuing

That basically gels with my rather wooly recollection.

> >As to whether the pdp11 succeeded soley because the VP liked the guy 
> >behind it, we'll never really know.
> That depends on the veracity of the story.  Human nature being what it is,
> it is likely that some of the way it was retold to me is exaggerated.  What
> is true, is that de Castro and 200 or so people quit DEC simultaneously and
> quickly formed DG and produced NOVAs from then onward.

One thing DEC always has been pretty good at is keeping its politics 
behind its doors; only when something genuinely visible happens (eg de
Castro's departure, Jupiter's cancellation) does the brown stuff fly
outside.

> Your opinion isn't a given, although I really don't want to open the topic
> about the -11 versus the -8 and company.  However, it is sufficient to say

Well, I do, since I'm a nit more in my depth... 8-)

> that there are debatable issues about 16 bit machines in general, byte
> versus word addressing, and specifics regarding inconsistencies in the -11
> design specifically, and whether or not a lot of its popularity stems from
> the usefullness of the software as opposed to the underlying architecture.

There are a lot of people who would put their hands on their hearts and say
the -11 architecture is the nicest they've used.  I'd be one of them.  
Personally, I feel the pdp11 instruction set has fewer warts on it than the
VAX set in terms of overall consistency (if you ignore the FIS & CIS sets 
which were bags added to the side of the arhitecure later on).  Bell's 
"golden boys" did a surprisingly good job, even if it was a bit rushed.

The pdp11 also marked a noticable change in direction for instruction set
architecures; up to then, all DEC machines had been word oriented and
single word instructions.  This development led on to the VAX architecture,
which took multiple part instructions rather to extremes.  

Basically, DEC had gone for instructions that looked like:

	+--------+--------------------+
	| opcode |      operand       |
	+--------+--------------------+

Now they were splitting the operand from the opcode:

	+-----------------------------+
	|           opcode            |
	+-----------------------------+
	|           operand           |
	+-----------------------------+
	|           operand           |
	+-----------------------------+

They also did away with special registers and other warts on the
architecture required when all the information about an instruction,
*including* literals, was crammed into one word.  Allowing for separate
literals also means that you don't need to do segmentation to get a 
decent address space, which was a problem on all previous machines.

It's interesting to note that many of the techniques used in the word-
oriented machines are re-introduced in today's RISCs.  However, there are
differences:

	- RISCs generally do not use special registers for actions such
	  as auto-increment.
	- RISCs usually have full-sized addressing once addresses are 
	  fetched into registers.  On early DEC computers, the size of the
	  operand literal field was also the limit of the virtual address
	  space.
	- Many RISCs still use byte-oriented addressing.
	- On early DEC machines, the word orientation was to simplify the
	  instruction decode; on RISCs the fixed instruction sizes are to
	  keep the pipeline filling at a constant rate.

Basically, the fact that the architectures "converged" again is largely
co-incidence -- the reasons for doing it that way were very different in
the 1960s to the reasons of the late 80s.  It's hard to say if the movement
of architectures towards multiple word multiple operand instruction sets
throughout the 70s was spearheaded by the pdp11, or whether the pdp11 just
rode the wave of development that culminated in the VAX.

> (There are many people enamoured of RT-11, not the -11 per se.  In fact, they
> want RT-32 or RT-64 for their favorite 32 or 64 bit designs, not -11

There was always a cry for an "RT32" when the VAX came out as the pdp11's
"successor".  DEC almost supplied it in VAXeln, but it had the snag that
development had to be done on a host (usually) VAX/VMS system; you could
develop under VMS and reboot into VAXeln, but this proved unworkable for
most developers, who either splashed out on an extra VAX, or (more often)
stuck with their RSX or RT11 systems where they could both write and test
their systems on the same box.  The VAX never  did "hard" realtime as well
as the pdp11 either, largely because of the  somewhat more baroque
interrupt handling.

> compatibility at all.)  Moreover, it is clear that DEC imposed the -11 into
> some situations where clearly the -8 was more than adequate.  In one infamous

DEC are good at that; as are others.  Let's face it, DEC always pushed 
their latest snaziest boxes -- put yourself in the place of the salesdroid;
would you say:

	"Here it is, it's been around for a while, it'll do the job."
or
	"Here's our latest hot box!"

(Remember, this is a salesdroid!)

I suspect many "DEC blunders" have been just cases of the salesthing not
quite reading the territory and getting it wrong.  

> True, but not useful; it's one of DEC's long-term major shortcomings that
> each project attempts to get funded by backstabbing everything else, and
> attempting snow jobs on technically incompetent upper management types.  A
> notable example: the VAXmate, which was undeliverable for over two years, yet
> caused the cancellation of other viable projects while it stalled and 
> eventually burned.

Whether the technique works or not depends a lot on the personalities; but
I'd challenge you to demostrate any R&D management technique that doesn't
have shortcomings, particularly that one.  A project may get killed, but
often  the deveoplement work is put into practice eventually.  For example,
DEC actually had a RISC architecture going before they decided to go to
MIPS chips; that work was not lost, but found its way into Alpha.

> >Kidder does avoid the question of de Castro's departure, but he does
> >allude to some of the conflicts between DG and other parts of the computer 
> >industry, especially DEC.  
> It would be interesting to expand on these issues.  Maybe DEC will not
> repeat their mistaken patterns of the past.

I haven't followed DG much, but I often got the feeling they were soley 
after DEC's market, sort of like a small yappy dog (the kind you just want
to step on) going for their heels, and largely leaving everyone else alone.

It's a fairly common theme in Kidder that Eagle is soley an attempt to go
after the VAX; the development is reactive rather than proactive.

--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052


From news.columbia.edu!rpi!usc!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!cc.usu.edu!ivie Mon Dec  7 22:29:45 EST 1992
Article: 113 of alt.sys.pdp8
Xref: news.columbia.edu alt.folklore.computers:34929 alt.sys.pdp8:113
Path: news.columbia.edu!rpi!usc!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!cc.usu.edu!ivie
From: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Subject: Re: The NOVA and the PDP-11  (Was Re: WANTED: PDP-10 or 11)
Message-ID: <1992Dec7.102534.61745@cc.usu.edu>
Date: 7 Dec 92 10:25:34 MDT
References: <1992Dec6.214758.3004@news.columbia.edu> <3250341@zl2tnm.gen.nz>
Distribution: world
Organization: Utah State University
Lines: 11

In article <3250341@zl2tnm.gen.nz>, don@zl2tnm.gen.nz (Don Stokes) writes:
>   For example,
> DEC actually had a RISC architecture going before they decided to go to
> MIPS chips; that work was not lost, but found its way into Alpha.

A joke that I heard at a DEC site was that AXP stands for Almost eXactly Prism.
-- 

Roger Ivie                      "My God! That computer is full of Pentium!
ivie@cc.usu.edu                  It's a wonder that you haven't been turned
                                 into mutants!"


From news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!agate!stanford.edu!rock!concert!sas!mozart.unx.sas.com!sch Mon Dec  7 22:31:16 EST 1992
Article: 114 of alt.sys.pdp8
Xref: news.columbia.edu alt.folklore.computers:34936 alt.sys.pdp8:114
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!agate!stanford.edu!rock!concert!sas!mozart.unx.sas.com!sch
From: sch@unx.sas.com (Steve Holzworth)
Subject: Re: The NOVA and the PDP-11 (Was Re: WANTED: PDP-10 or 11)
Sender: news@unx.sas.com (Noter of Newsworthy Events)
Message-ID: <sch.723758215@gargoyle>
Date: Mon, 7 Dec 1992 19:56:55 GMT
References: <1992Dec6.214758.3004@news.columbia.edu> <3250341@zl2tnm.gen.nz>
Nntp-Posting-Host: gargoyle.unx.sas.com
Organization: SAS Institute Inc.
Lines: 56

don@zl2tnm.gen.nz (Don Stokes) writes:

>lasner@watsun.cc.columbia.edu (Charles Lasner) writes:

 stuff deleted

>> >As to whether the pdp11 succeeded soley because the VP liked the guy 
>> >behind it, we'll never really know.
>> That depends on the veracity of the story.  Human nature being what it is,
>> it is likely that some of the way it was retold to me is exaggerated.  What
>> is true, is that de Castro and 200 or so people quit DEC simultaneously and
>> quickly formed DG and produced NOVAs from then onward.

>One thing DEC always has been pretty good at is keeping its politics 
>behind its doors; only when something genuinely visible happens (eg de
>Castro's departure, Jupiter's cancellation) does the brown stuff fly
>outside.

stuff deleted

To further complicate things: I was told once that there used to be yet
a THIRD group within DEC working on the "future PDP" who also lost out,
and spun off into a company called GRI. They made a system called the GRIP.

The only reason I heard this was that I used to work for a company that 
was involved in a triple merger, one component of which was GRI. It was 
mostly in decline, and was eventually shut down by the new parent company
(Fulcrum Computer Group). Fulcrum was eventually sold to Adage, Inc., 
whose main goal was to acquire the Ikonas Graphics Systems component thereof
(Ikonas was a high-end graphics hardware vendor in the late 70s, early 80s;
sort of that era's Silicon Graphics...). 

Anecdote:
Adage was a graphics vendor from the early/mid seventies. They had vector 
graphics with hardware transformations. The machine was also ONE'S COMPLEMENT 
math. Those negative zeros are a pain :-).

>I haven't followed DG much, but I often got the feeling they were soley 
>after DEC's market, sort of like a small yappy dog (the kind you just want
>to step on) going for their heels, and largely leaving everyone else alone.

Several people here used to work at DG in Research Triangle Park. They
actually had lots of innovative hardware in development. Invariably, the
idiots in the front office wouldn't understand the signifigance of the
advance and would shut down the effort before it hit the market.

>--
>Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
>Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
>Victoria University of Wellington, New Zealand              +64-4-495-5052
--
Steve Holzworth
sch@unx.sas.com                         "Do not attribute to poor spelling
x6872                                    That which is actually poor typing..."
SAS Institute - Open Systems R & D                      - me
Cary, N.C.


From news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!dptg!rjf Mon Dec  7 22:32:25 EST 1992
Article: 115 of alt.sys.pdp8
Xref: news.columbia.edu alt.folklore.computers:34946 alt.sys.pdp8:115
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!dptg!rjf
From: rjf@dptg.att.com (51351[efw]-Robert Feddeler(MT4799)T343)
Subject: Re: The NOVA and the PDP-11  (Was Re: WANTED: PDP-10 or 11)
Message-ID: <1992Dec7.222047.3069@dptg.att.com>
Organization: AT&T/NCR, Lincroft, NJ, USA
References: <1992Dec4.212403.10103@news.columbia.edu> <3633339@zl2tnm.gen.nz> <1992Dec6.214758.3004@news.columbia.edu>
Distribution: na
Date: Mon, 7 Dec 1992 22:20:47 GMT
Lines: 32

In article <1992Dec6.214758.3004@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>
>Apparently, two young relative newbies in DEC engineering read his work and
>used it to toy around with a new machine design (which eventually became the
>-11).  Their work is not fully polished, and suffers from some inconsistencies.
>(Such as the condition codes aren't exactly the same as a result of an
>increment or decrement as opposed to adding or subtracting 1, or that
 ^^^^^^^^^^^^^^^^^^^^^^
>byte forms of instructions don't quite set the same results as the word forms
>of the same instructions.  The point is that a carefully planned work of
>architecture design would have located these shortcomings and corrected them.
>Much has been published about these issues elsewhere, etc.)
>

There is actually more thought invested in the 11's instruction set than
meets the eye.  The reason 'inc' and 'dec' don't modify the Carry bit
is to allow for inc's and dec's on loop counters in multi-word arithmetic
routines that need to propogate the C-bit and shouldn't have to waste time
saving and restoring it.  After an add #1, or sub #1, the C- and Z-bits
are always the same.  BNE is equivalent to BCC after an increment or
decrement.

This "feature" caused me a bit of pain at a little after 18:00 hours one
day back in 1975 in the basement of the "mill".  My check for overflow
after an inc on the low order word of the "seconds since midnite" counter
was a BCC that would _always_ branch.

Noto Bne!


bob.			| Heap big trouble in the land of plenty.
Were these more than just my opinions, they would have cost a bit more.


From news.columbia.edu!rpi!usc!enterpoop.mit.edu!eff!world!iecc!johnl Mon Dec 14 04:05:28 EST 1992
Article: 116 of alt.sys.pdp8
Xref: news.columbia.edu alt.folklore.computers:35277 alt.sys.pdp8:116
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: news.columbia.edu!rpi!usc!enterpoop.mit.edu!eff!world!iecc!johnl
From: johnl@iecc.cambridge.ma.us (John R. Levine)
Subject: Re: The NOVA and the PDP-11  (Was Re: WANTED: PDP-10 or 11)
Organization: I.E.C.C.
Date: Sun, 13 Dec 1992 19:09:31 GMT
Message-ID: <1992Dec13.190931.18700@iecc.cambridge.ma.us>
References: <1992Dec4.212403.10103@news.columbia.edu> <1992Dec6.214758.3004@news.columbia.edu>
Lines: 39

lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>It apparently came down to the fact that the "green light" had been given
>for the NOVA project, and sub-design teams formed, etc.  Note that one of
>the design goals for this project was to use larger boards to overcome the
>limitations of FLIP-CHIP modules which can't have much functionality per
>card because of lack of fingers.  ...

Actually, there was a sensible reason that DEC used small cards.  The
PDP-6 (the machine that the PDP-10 was almost as good as) used great big
cards with lots of pins per connector.  Unfortunately, the connectors
didn't work very well.  A standard diagnostic technique when a PDP-6 was
flaking was to open the back and hit all the modules with a rubber mallet.
For that among other reasons the PDP-6 was a marketing failure and they
only built 20 of them.

The later KA10, the first PDP-10, used small Flip-Chip modules the same
size as the ones used in the wildly successful original PDP-8.  (The -10
was mostly B series modules, which were faster than the R and S series
used in the PDP-8.)  It wasn't until the PDP-11/45 that DEC found large
connectors in which they had confidence, and even then, the 11/45's cards
had little latches that you used to force the connectors very firmly into
their sockets.

As far as the Nova ripping off DEC goes, I have a copy of ``How to use the
Nova and the Supernova,'' the programmer's manual for DG's first two
machines, dated 1970.  The design and typography are exactly the same as
in the DEC PDP-10 manual.  It was written by William English, who wrote
the PDP-10 manual.  On page 2-44, when discussing the memory protection
feature, it says ``In particular, do not execute a JSR into a protected
page,'' a piece of advice that also appears almost verbatim in the PDP-10
manual.  But the Nova's JSR saved its return address in a register,
causing no problem when jumping into a read-only segment, while the
PDP-10's JSR stored the return address at the jumped-to location, which
doesn't work in read-only memory.  Oops.  Wrong computer.

-- 
John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 492 3869
johnl@iecc.cambridge.ma.us, {ima|spdcc|world}!iecc!johnl
"Time is Money!  Steal some today!"


From news.columbia.edu!rpi!uwm.edu!ux1.cso.uiuc.edu!news.iastate.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news Mon Dec 14 04:06:27 EST 1992
Article: 117 of alt.sys.pdp8
Xref: news.columbia.edu alt.folklore.computers:35278 alt.sys.pdp8:117
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: news.columbia.edu!rpi!uwm.edu!ux1.cso.uiuc.edu!news.iastate.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Subject: Hammers (Was: The NOVA and the PDP-11)
Sender: news@news.uiowa.edu (News)
Message-ID: <1992Dec13.210542.26834@news.uiowa.edu>
Date: Sun, 13 Dec 1992 21:05:42 GMT
References: <1992Dec13.190931.18700@iecc.cambridge.ma.us>
Nntp-Posting-Host: pyrite.cs.uiowa.edu
Organization: University of Iowa, Iowa City, IA, USA
Lines: 36

>From article <1992Dec13.190931.18700@iecc.cambridge.ma.us>,
by johnl@iecc.cambridge.ma.us (John R. Levine):
> 
> Actually, there was a sensible reason that DEC used small cards.  The
> PDP-6 (the machine that the PDP-10 was almost as good as) used great big
> cards with lots of pins per connector.  Unfortunately, the connectors
> didn't work very well.  A standard diagnostic technique when a PDP-6 was
> flaking was to open the back and hit all the modules with a rubber mallet.

The PDP-11/20 may have been made with small cards, but this didn't fix
the problem.  We had an 11/20 at the University of Illinois, and as it
aged, cards began to get loose, and the common fix was to gently kick
the underside of the machine to reseat the cards.  On failure, you'd
kick it and reboot, and only if that failed was it worth trying anything
more impressive.  Kicking seemed to work about 90% of the time.

The machine was rack-mounted, but there was nothing under the CPU, and
the blank panels had long since been removed from that space by 1973
when this story takes place.

To understand why it worked, you have to know that the PDP-11/20 was
mounted with the wire-wrapped backplane on top and the cards pushed in
from the bottom.  The mounting slides were tiltable, so you could pull
the box out of the rack and tilt it up to face the boards towards you,
or tilt it down to face the backplane towards you.

The boards were retained in their slots by the foam lining on the inside
of the bottom cover of the CPU.  This foam was stiff grey stuff, a type
still commonly used for padding electronics.  The problem is, the stuff
ages, particularly in a warm environment, and as it ages, it looses its
spring and becomes mushy.  The CPU was in a high noise environment
(a card reader and line printer were right there), and I gather that the
vibrarion was enough to work cards loose after the foam lost its spring.

				Doug Jones
				jones@cs.uiowa.edu


From news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!malgudi.oar.net!caen!sol.ctr.columbia.edu!eff!world!dp Mon Dec 14 04:07:55 EST 1992
Article: 118 of alt.sys.pdp8
Xref: news.columbia.edu alt.folklore.computers:35289 alt.sys.pdp8:118
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!malgudi.oar.net!caen!sol.ctr.columbia.edu!eff!world!dp
From: dp@world.std.com (Jeff DelPapa)
Subject: Re: The NOVA and the PDP-11  (Was Re: WANTED: PDP-10 or 11)
Message-ID: <Bz84Gp.2JG@world.std.com>
Organization: The World Public Access UNIX, Brookline, MA
References: <1992Dec4.212403.10103@news.columbia.edu> <1992Dec6.214758.3004@news.columbia.edu> <1992Dec13.190931.18700@iecc.cambridge.ma.us>
Date: Mon, 14 Dec 1992 00:38:48 GMT
Lines: 53

In article <1992Dec13.190931.18700@iecc.cambridge.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes:
>lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>It apparently came down to the fact that the "green light" had been given
>>for the NOVA project, and sub-design teams formed, etc.  Note that one of
>>the design goals for this project was to use larger boards to overcome the
>>limitations of FLIP-CHIP modules which can't have much functionality per
>>card because of lack of fingers.  ...
>
>Actually, there was a sensible reason that DEC used small cards.  The
>PDP-6 (the machine that the PDP-10 was almost as good as) used great big
>cards with lots of pins per connector.  Unfortunately, the connectors
>didn't work very well.  A standard diagnostic technique when a PDP-6 was
>flaking was to open the back and hit all the modules with a rubber mallet.
>For that among other reasons the PDP-6 was a marketing failure and they
>only built 20 of them.

One peice of (likely) apocrapha regarding the nova board size...  It
seems that a number of people at dec had pdp-8's in their basement
built in the same mode as the Cadillac in that old country standard
"one peice at a time".  DG as cost conscious as it ever was,
supposedly designed Nova boards such that they wouldn't fit in
breifcases, printouts, or under the coat (no matter how fat the wearer
of the coat).

the following are supposedly not apocrapha:

DG didn't want cloned memory boards, and had one trace on their memory
board that had an inconspicious break - the sort that someone trying
to copy the board would assume was a bad spot on the copy and fix -
this would connect the +12 supply line to the core stacks sense wire -
powering up such a board would let all of the magic smoke out of the
core stack.

On the nova 1200's, there was a power supply crowbar module. It was
potted, they were assembled by a single technician, and no prints of
the thing were available.  This module was also the source of some of
the timing signals. It was a $500 part from field service. I saw one
that the potting had been carefully removed from - it contained 6
chips. (numbers were removed, possibly by the removal of the potting,
so I cannot give an accurate actual cost estimate)

The novas had power fail restart as a $250 option. It was implemented
(on the 1200 anyway) by two chips (a comparator and a latch I think,
tho it may have been a one-shot and a gate) on one of the CPU cards.
By default the chips were installed on all boards manufactured, and
diked out if not ordered.  The going rate for a bootleg installation
from the field service techs was $50 (the chips cost about $0.45).

<dp>






From news.columbia.edu!watsun.cc.columbia.edu!lasner Mon Dec 14 04:08:32 EST 1992
Article: 119 of alt.sys.pdp8
Xref: news.columbia.edu alt.folklore.computers:35306 alt.sys.pdp8:119
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: news.columbia.edu!watsun.cc.columbia.edu!lasner
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: The NOVA and the PDP-11  (Was Re: WANTED: PDP-10 or 11)
Message-ID: <1992Dec14.090519.6278@news.columbia.edu>
Sender: usenet@news.columbia.edu (The Network News)
Nntp-Posting-Host: watsun.cc.columbia.edu
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
References: <1992Dec4.212403.10103@news.columbia.edu> <1992Dec6.214758.3004@news.columbia.edu> <1992Dec13.190931.18700@iecc.cambridge.ma.us>
Date: Mon, 14 Dec 1992 09:05:19 GMT

In article <1992Dec13.190931.18700@iecc.cambridge.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes:
>lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>It apparently came down to the fact that the "green light" had been given
>>for the NOVA project, and sub-design teams formed, etc.  Note that one of
>>the design goals for this project was to use larger boards to overcome the
>>limitations of FLIP-CHIP modules which can't have much functionality per
>>card because of lack of fingers.  ...
>
>Actually, there was a sensible reason that DEC used small cards.  The
>PDP-6 (the machine that the PDP-10 was almost as good as) used great big
>cards with lots of pins per connector.  Unfortunately, the connectors
>didn't work very well.  A standard diagnostic technique when a PDP-6 was
>flaking was to open the back and hit all the modules with a rubber mallet.
>For that among other reasons the PDP-6 was a marketing failure and they
>only built 20 of them.

Two things:

First of all, those big connectors don't really have more pins, they have
bigger pins, and they're gold-plated, but because they are short, they can
be flakey, especially with a massive card on the other end of the connector,
so it's a matter of bad choice of connector mechanism, not quantity of
connections.  Also, the PDP-6 and KA-10 era doesn't have the problems I'm
talking about, namely when TTL came into vogue.  Now you had too much logic
and not enough local interconnect if the only way to interconnect was at
a module level with only 36 pins total.  So, bigger cards allows for more
pins to interconnect with, and encourages local chip interconnections that
are not brought out to the connector at all.

Second, I heard they made 20 PDP-6's, yet someone else insists 23.

>
>The later KA10, the first PDP-10, used small Flip-Chip modules the same
>size as the ones used in the wildly successful original PDP-8.  (The -10
>was mostly B series modules, which were faster than the R and S series
>used in the PDP-8.)  It wasn't until the PDP-11/45 that DEC found large
>connectors in which they had confidence, and even then, the 11/45's cards
>had little latches that you used to force the connectors very firmly into
>their sockets.

Wrong, the Omnibus predates the 11/45, and uses multiple connectors of the
small variety on a big card.  The hex boards were used in those -11's and
then the 8/a.  I'm not sure if hex boards predate Q-bus, but in any case the
Omnibus is older than both of them, and was being developed at about the
same time as the UNIBUS itself, although not made out of hex boards back then.

[good stuff deleted]

Since they had the "style" of the 36-bits, and the "guts" of the 12-bits,
DG was a "generic" DEC rip-off.  In any case, that's what happens when you
pull the plug of a carefully planned project over a hastily formed weekend.

cjl


From news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!yale!gumby!destroyer!news.itd.umich.edu!sinshan.citi.umich.edu!sarr Mon Dec 14 21:37:35 EST 1992
Article: 120 of alt.sys.pdp8
Xref: news.columbia.edu alt.folklore.computers:35315 alt.sys.pdp8:120
Path: news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!yale!gumby!destroyer!news.itd.umich.edu!sinshan.citi.umich.edu!sarr
From: sarr@sinshan.citi.umich.edu (Sarr J. Blumson)
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Subject: Re: The NOVA and the PDP-11  (Was Re: WANTED: PDP-10 or 11)
Date: 14 Dec 1992 14:24:29 GMT
Organization: University of Michigan, CITI
Lines: 18
Distribution: world
Message-ID: <1gi5etINNoa1@terminator.rs.itd.umich.edu>
References: <1992Dec4.212403.10103@news.columbia.edu> <1992Dec6.214758.3004@news.columbia.edu> <1992Dec13.190931.18700@iecc.cambridge.ma.us>
NNTP-Posting-Host: sinshan.citi.umich.edu

In article <1992Dec13.190931.18700@iecc.cambridge.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes:
>
>Actually, there was a sensible reason that DEC used small cards.  The
>PDP-6 (the machine that the PDP-10 was almost as good as) used great big
>cards with lots of pins per connector.  Unfortunately, the connectors
>didn't work very well.  A standard diagnostic technique when a PDP-6 was
>flaking was to open the back and hit all the modules with a rubber mallet.
>For that among other reasons the PDP-6 was a marketing failure and they
>only built 20 of them.
>
Some of this, of course, was due to DEC's fondness for using vertical
backplanes where the connector was the _only_ mechanical support the
cards had.  I once watched some slighly inebriated movers run a KA-10
up a ramp a little too hard; some of the noards just popped out.  Of
course after we put them back in it worked fine.


(Sarr Blumson)


From news.columbia.edu!rpi!think.com!spool.mu.edu!uunet!munnari.oz.au!uniwa!cujo!cc.curtin.edu.au!zrepachol Wed Dec 16 23:41:14 EST 1992
Article: 121 of alt.sys.pdp8
Xref: news.columbia.edu alt.folklore.computers:35394 alt.sys.pdp8:121
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: news.columbia.edu!rpi!think.com!spool.mu.edu!uunet!munnari.oz.au!uniwa!cujo!cc.curtin.edu.au!zrepachol
From: zrepachol@cc.curtin.edu.au
Subject: Re: The NOVA and the PDP-11  (Was Re: WANTED: PDP-10 or 11)
Message-ID: <1992Dec16.213124.1@cc.curtin.edu.au>
Lines: 15
Sender: news@cujo.curtin.edu.au (News Manager)
Organization: Curtin University of Technology
References: <1992Dec4.212403.10103@news.columbia.edu> <1992Dec6.214758.3004@news.columbia.edu> <1992Dec13.190931.18700@iecc.cambridge.ma.us>
Date: Wed, 16 Dec 1992 12:31:24 GMT

In article <1992Dec13.190931.18700@iecc.cambridge.ma.us>, johnl@iecc.cambridge.ma.us (John R. Levine) writes:
> Actually, there was a sensible reason that DEC used small cards.  The
> PDP-6 (the machine that the PDP-10 was almost as good as) used great big
> cards with lots of pins per connector.  Unfortunately, the connectors
> didn't work very well.  A standard diagnostic technique when a PDP-6 was
> flaking was to open the back and hit all the modules with a rubber mallet.
> For that among other reasons the PDP-6 was a marketing failure and they
> only built 20 of them.
> 

Bzzzt. You are thinking of the CDC6x00 and Cybers. The prob with the 6's cards
was that they where SOLDERED in, some on BOTH sides...

~Paul



From news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!nucsrl!rose.eecs.nwu.edu!holmer Sat Dec 19 04:14:03 EST 1992
Article: 123 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!nucsrl!rose.eecs.nwu.edu!holmer
From: holmer@rose.eecs.nwu.edu (Bruce Holmer)
Subject: Request for benchmark programs
Message-ID: <1992Dec18.171533.28557@eecs.nwu.edu>
Sender: usenet@eecs.nwu.edu (Mr. Usenet)
Organization: EECS Department, Northwestern University
Date: Fri, 18 Dec 1992 17:15:33 GMT
Lines: 19


This might sound strange, but does anyone have PDP-8 assembly
code for some smallish benchmark programs?  I can write these
myself, but I thought I might check to see if they already
exist....

I'm looking for things like the old Byte benchmarks (circa
1981) or the benchmarks used in the first RISC articles (e.g.
Patterson/Sequin, Computer Magazine, Sept. 1982).  Things
like sieve, sort (quicksort, heapsort, etc.), string move,
string search, ackerman, simple puzzle solvers, matrix
operations, software floating point, etc.  I'll be running
these on a simulator, so I'll just initialize the memory, run
the code, and look at the results in memory (that is to say,
I can do with just subroutines for most of the simple stuff).

Thanks,
--Bruce Holmer
holmer@eecs.nwu.edu


From news.columbia.edu!rpi!uwm.edu!caen!destroyer!cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!alberta!tyzuk Sat Dec 19 04:14:23 EST 1992
Article: 124 of alt.sys.pdp8
Xref: news.columbia.edu alt.folklore.computers:35524 alt.sys.pdp8:124
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: news.columbia.edu!rpi!uwm.edu!caen!destroyer!cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!alberta!tyzuk
From: tyzuk@cs.UAlberta.CA (Tyzuk William N)
Subject: Re: The NOVA and the PDP-11 (Was Re: WANTED: PDP-10 or 11)
Message-ID: <tyzuk.724713778@manning>
Sender: news@cs.UAlberta.CA (News Administrator)
Nntp-Posting-Host: manning.cs.ualberta.ca
Organization: University of Alberta, Edmonton, Canada
References: <1992Dec4.212403.10103@news.columbia.edu> <1992Dec6.214758.3004@news.columbia.edu> <1992Dec13.190931.18700@iecc.cambridge.ma.us> <1992Dec16.213124.1@cc.curtin.edu.au>
Date: Fri, 18 Dec 1992 21:22:58 GMT
Lines: 22

zrepachol@cc.curtin.edu.au writes:

>In article <1992Dec13.190931.18700@iecc.cambridge.ma.us>, johnl@iecc.cambridge.ma.us (John R. Levine) writes:
>> Actually, there was a sensible reason that DEC used small cards.  The
>> PDP-6 (the machine that the PDP-10 was almost as good as) used great big
>> cards with lots of pins per connector.  Unfortunately, the connectors
>> didn't work very well.  A standard diagnostic technique when a PDP-6 was
>> flaking was to open the back and hit all the modules with a rubber mallet.
>> For that among other reasons the PDP-6 was a marketing failure and they
>> only built 20 of them.
>> 

>Bzzzt. You are thinking of the CDC6x00 and Cybers. The prob with the 6's cards
>was that they where SOLDERED in, some on BOTH sides...

Lessee now... I think it was a CDC1700 mini that had a 256k word (??)
drum (actually a disk but they called it a drum) which came with a plastic
hammer and maintenance manual which prescribed tapping the cards with
the hammer to cure intermittant faults!  This was an actual recommended and
authorized maintenance procedure!  Sigh.... the good ol' days :-)  NOT.




From news.columbia.edu!rpi!usc!sol.ctr.columbia.edu!cunixb.cc.columbia.edu!slb22 Sat Dec 19 04:14:37 EST 1992
Article: 125 of alt.sys.pdp8
Xref: news.columbia.edu alt.folklore.computers:35527 alt.sys.pdp8:125
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Path: news.columbia.edu!rpi!usc!sol.ctr.columbia.edu!cunixb.cc.columbia.edu!slb22
From: slb22@cunixb.cc.columbia.edu (Seth "the Lesser")
Subject: Re: The NOVA and the PDP-11 (Was Re: WANTED: PDP-10 or 11)
References: <1992Dec13.190931.18700@iecc.cambridge.ma.us> <1992Dec16.213124.1@cc.curtin.edu.au> <tyzuk.724713778@manning>
Sender: nobody@ctr.columbia.edu
Organization: Generic American College Kids (G.A.C.K.)
Date: Fri, 18 Dec 1992 22:35:34 GMT
Message-ID: <1992Dec18.223534.19725@sol.ctr.columbia.edu>
Reply-To: slb22@cunixb.cc.columbia.edu (Seth "the Lesser")
X-Posted-From: cunixb.cc.columbia.edu
NNTP-Posting-Host: sol.ctr.columbia.edu
Lines: 17

tyzuk@cs.UAlberta.CA (Tyzuk William N) writes:
>
>Lessee now... I think it was a CDC1700 mini that had a 256k word (??)
>drum (actually a disk but they called it a drum) which came with a plastic
>hammer and maintenance manual which prescribed tapping the cards with
>the hammer to cure intermittant faults!  This was an actual recommended and
>authorized maintenance procedure!  Sigh.... the good ol' days :-)  NOT.

Good ol' days my bleeding arse.  We have a pack of Sun SPARCstations here at
CTR with cut-rate hard drives that freeze up whenever we power down.  The best
way to unfreeze them (saith my boss, and I've seen him do it with excellent
results) is to tap them with a hammer.  Lightly, of course.

Seth L. Blumberg          \ Warning: This posting has been determined to cause
slb22@columbia.edu (play)   \ cancer in laboratory animals.  Please make sure
sethb@ctr.columbia.edu (work) \ that no white mice are allowed to read it.  
    > No one I know shares my opinions, least of all Columbia University. <


From news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!nucsrl!delta!holmer Sat Dec 19 04:14:52 EST 1992
Article: 126 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!nucsrl!delta!holmer
From: holmer@eecs.nwu.edu (Bruce Holmer)
Subject: Request for instruction cycle counts
Message-ID: <HOLMER.92Dec18174207@rose.eecs.nwu.edu>
Sender: usenet@eecs.nwu.edu (Mr. Usenet)
Organization: EECS Department, Northwestern University, Evanston, Il., USA
Date: Fri, 18 Dec 1992 23:42:07 GMT
Lines: 9


Does someone have a table of instruction cycle
counts for a high-end PDP-8?  I'd need to know
about how many cycles the different addressing
modes require and how to calculate the cycle
count for the OPR instructions.

Thanks,
--Bruce


From news.columbia.edu!watsun.cc.columbia.edu!lasner Sat Dec 19 04:39:47 EST 1992
Article: 127 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: news.columbia.edu!watsun.cc.columbia.edu!lasner
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: Request for instruction cycle counts
Message-ID: <1992Dec19.093750.7276@news.columbia.edu>
Sender: usenet@news.columbia.edu (The Network News)
Nntp-Posting-Host: watsun.cc.columbia.edu
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
References: <HOLMER.92Dec18174207@rose.eecs.nwu.edu>
Date: Sat, 19 Dec 1992 09:37:50 GMT

In article <HOLMER.92Dec18174207@rose.eecs.nwu.edu> holmer@eecs.nwu.edu (Bruce Holmer) writes:
>
>Does someone have a table of instruction cycle
>counts for a high-end PDP-8?  I'd need to know
>about how many cycles the different addressing
>modes require and how to calculate the cycle
>count for the OPR instructions.
>
>Thanks,
>--Bruce


It's interesting timing that you ask for benchmarks as there is another
simulator soon to make the light of day.  This one is for a *real* PDP-8
meaning it supports peripherals including disks.  It's specifically for
80286 and up machines with HD diskette drives.  The author cannot currently
post to usenet but can e-mail, etc.  He wants representative code so that
he can determine the ratio of PDP-8 to simulator performance using a wide
variety of programs, etc.

Not counting the 6120 cycle time, which is somewhat erratic depending on
which instructions specifically we call out, it's best to stick to the 8/e
processor with static memory for timing.  This is the most common configuration
anyway.

All OPR instructions are 1.2 microseconds each regardless of group or outcome
of any test.

All internal IOT instructions are also 1.2 microseconds unless "stretched"
by a peripheral using the NOT LAST TRANSFER line on the OMNIBUS.  If the
cycle is external, and there actually is a KA8E installed, the cycle will
be stretched my an amount determined by the KA8E, and can be adjusted to
many microseconds to accomodate very long (over 50 foot) external positive
and/or negative busses.

All other instructions are two-cycle and thus take 2.6 microsends, or if
indirect are 3.8 microseconds unless auto-indexed in which case make that
4.0 microseconds.

If EAE is present, various group 3 instructions are implemented that take
a varying amount of time such as long shifts which are shift-count dependent
for total execution time, and there are many different timings for each of the
different instructions.  In some cases, instruction timing can also be affected
by auto-indexing operations, such as when the EAE diagnostic places a
MUY instruction into location 00007 so that the operand pointer is in location
00010 thus causing an auto-index as a "feature".

All of these timings assume no memory collisions such as occur when the
MOS memory cards (DRAM) are used, or if DMA is occuring simultaneously.  There
is no pipelining used, although the architecture would easily allow it.  There
is some instruction prefix optimization in the 6120 implementation, thus
instruction times widely vary with respect to the 8/e.  Some are marginally
faster, yet others are quite a bit slower.

By using a short buss, it is possible to "tweak" the CPU timing to get speeds
about 20% better than this accurate nominal speed (crystal-controlled).  
CESI is/was marketing a replacement VLSI processor that was/is quite a bit
faster, etc.

cjl


From news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news Mon Dec 21 06:34:13 EST 1992
Article: 129 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Subject: Re: Request for instruction cycle counts
Sender: news@news.uiowa.edu (News)
Message-ID: <1992Dec20.234924.16714@news.uiowa.edu>
Date: Sun, 20 Dec 1992 23:49:24 GMT
References: <HOLMER.92Dec18174207@rose.eecs.nwu.edu>
Nntp-Posting-Host: pyrite.cs.uiowa.edu
Organization: University of Iowa, Iowa City, IA, USA
Lines: 28

>From article <HOLMER.92Dec18174207@rose.eecs.nwu.edu>, by holmer@eecs.nwu.edu (Bruce Holmer):
> 
> Does someone have a table of instruction cycle
> counts for a high-end PDP-8?  I'd need to know
> about how many cycles the different addressing
> modes require and how to calculate the cycle
> count for the OPR instructions.

There were two different memory cycle times on the PDP-8/E (that was probably
the highest of the high-end PDP-8 machines):  1200ns and 1400ns.

An instruction fetch was one short cycle.
Indirect addressing cost one short cycle, unless it was through an
  autoindex register, in which case you pay for a long cycle.
Operand fetch for AND and TAD cost one long cycle.
Operand fetch/increment/store for ISZ cost one long cycle.
Operand store for DCA and JMS cost one long cycle.
JMP cost nothing other than the instruction fetch and indirect cycles.
IOT to omnibus peripherals cost nothing beyond the instruction fetch cycle.
OPR for non EAE instructions cost nothing beyond the instruction fetch cycle.

These figures are for the standard PDP-8 memory, and must be adjusted if
you want to talk about the various strange things that happened when they
abandoned core, particularly, it should be noted that the ROM technology
of the mid 1970's was a bit on the slow side.

				Doug Jones
				jones@cs.uiowa.edu


From news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!howland.reston.ans.net!paladin.american.edu!darwin.sura.net!spool.mu.edu!olivea!uunet!unislc!thayne Mon Dec 21 18:36:57 EST 1992
Article: 130 of alt.sys.pdp8
Xref: news.columbia.edu alt.folklore.computers:35621 alt.sys.pdp8:130
Path: news.columbia.edu!rpi!zaphod.mps.ohio-state.edu!howland.reston.ans.net!paladin.american.edu!darwin.sura.net!spool.mu.edu!olivea!uunet!unislc!thayne
From: thayne@unislc.uucp (Thayne Forbes)
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Subject: Re: The NOVA and the PDP-11 (Was Re: WANTED: PDP-10 or 11)
Message-ID: <1992Dec20.000558.23826@unislc.uucp>
Date: 20 Dec 92 00:05:58 GMT
References: <1992Dec18.223534.19725@sol.ctr.columbia.edu>
Organization: HomeVax
Lines: 27
X-Newsreader: TIN [version 1.1 PL6]

Seth the Lesser (slb22@cunixb.cc.columbia.edu) wrote:
: tyzuk@cs.UAlberta.CA (Tyzuk William N) writes:
: >
: >Lessee now... I think it was a CDC1700 mini that had a 256k word (??)
: >drum (actually a disk but they called it a drum) which came with a plastic
: >hammer and maintenance manual which prescribed tapping the cards with
: >the hammer to cure intermittant faults!  This was an actual recommended and
: >authorized maintenance procedure!  Sigh.... the good ol' days :-)  NOT.
: 
: Good ol' days my bleeding arse.  We have a pack of Sun SPARCstations here at
: CTR with cut-rate hard drives that freeze up whenever we power down.  The best
: way to unfreeze them (saith my boss, and I've seen him do it with excellent
: results) is to tap them with a hammer.  Lightly, of course.
: 
This time honored maintenance technique was in real danger of becoming a 
lost art a few years ago, but Apple came to our rescue and rejuvinated it
with the introduction of Quantum 40 (and I think Quantum 80) drives, which
regularly refused to spin up after cold boot.  At the time we (Unisys) were
about to use the same drives in a $1 Billion PC contract, and I can tell you
we didn't know whether to snicker about Apple, or sweat bullets because
we couldn't figure out why they worked so well for us.  Turns out to have
been an electrical problem (which some electrically literate Mac user will
have to explain) which we didn't suffer from because of our monster power
supplies.  We did suffer a few very nervous days investigating tho.
-- 
Thayne Forbes
thayne@unislc.slc.unisys.com
