TJ-2, a very early word-processor-like program for the PDP-1
Daniel P. B. Smith
I have posted a reproduction of the documentation for a VERY early
word-processor-like program, which ran on a PDP-1 with 4K words (9K bytes)
of RAM in 1963. I think the program was written by Pete Samson, although
no names appear in the documentation. For your nostalgic pleasure:
http://world.std.com/~dpbsmith/tj2.html
Comments welcome.
--
Daniel P. B. Smith
dpbs...@world.std.com
ds...@cameonet.cameo.com.tw
Daniel P. B. Smith (dpbs...@world.std.com) wrote --
> I have posted a reproduction of the documentation for a VERY early
> word-processor-like program, which ran on a PDP-1 with 4K words (9K bytes)
> of RAM in 1963. I think the program was written by Pete Samson, although
> no names appear in the documentation. For your nostalgic pleasure:
>
> http://world.std.com/~dpbsmith/tj2.html
>
> Comments welcome.
Thank you, thank you, thank you. That is fascinating.
I'd like to comment on one of your notes:
TJ-2 does not resemble modern word processors with "on-screen
formatting" or "WYSIWYG editing." It somewhat resembles earlier word
processors like RUNOFF, TROFF or WordStar in which the editor and
formatter are separate....
WordStar has had on-screen formatting since very early days -- probably
since it first appeared in '78 or '79. To my knowledge, it has always
been as WYSIWYG as you'd want to get on a character-cell display (one
*can* go too far in that direction). In '81 or so all you needed for
editing and printing was WS.COM, a dynamic code overlay, and a message
overlay (there were also dynamic mail-merge and spelling overlays). It
was an integrated editor and formatter, and it did letter-quality
printing in proportionally spaced fonts on "incremental" printers (in
those days, this generally meant daisywheels).
I've heard others compare WordStar to nroff, troff, et al, and I can't
for the life of me figure out where this notion comes from.
BTW, WordStar version 7.0 came out in '92 and is still sold. The
WordStar Users' Group is 16 or 17 years old and still going strong, and
there is a *very* active Bitnet-style mailing list.
A diamond is forever.
Dan Strychalski
ds...@cameonet.cameo.com.tw
Bob Manners
> I have posted a reproduction of the documentation for a VERY early
> word-processor-like program, which ran on a PDP-1 with 4K words (9K bytes)
> of RAM in 1963. I think the program was written by Pete Samson, although
> no names appear in the documentation.
4Kwords == 9Kb. I take it that the PDP-1 had an 18 bit word length then?
--
------------------------------------------------------------------------------
Bob Manners 24 Temple Street, Oxford, OX4 1JS, Tel/FAX: 01865 245819
My REAL address is: r...@swift.eng.ox.ac.uk
------------------------------------------------------------------------------
Stephen Westin
> > I have posted a reproduction of the documentation for a VERY early
> > word-processor-like program, which ran on a PDP-1 with 4K words (9K bytes)
> > of RAM in 1963. I think the program was written by Pete Samson, although
> > no names appear in the documentation.
>
> 4Kwords == 9Kb. I take it that the PDP-1 had an 18 bit word length then?
You betcha. My impression of the PDP genealogy:
PDP 1,4,7,9,15: 18-bit machines
PDP 5,8,12: 12-bit
PDP 6,10,20: 36-bit
PDP 11: 16-bit
PDP 2: Never built
PDP 3: Designed, never built by DEC, but rumor has it a customer
bought DEC modules and assembled one. Don't know word length.
PDP 13: Never existed
PDP 14: Industrial automation controllers. Don't know word length
PDP 16: Not a machine, but a system of register-transfer modules
(memory, ALU, etc) from which a customer could build various
computer-like devices. I used them in a class at Michigan; I
believe DEC donated lots of 'em after they died in the market.
They came out just in time to be obsoleted by the increasing
level of integrated circuits of the time.
-Stephen H. Westin
swe...@ford.com
The information and opinions in this message are mine, not Ford's.
--
-Stephen H. Westin
swe...@ford.com
The information and opinions in this message are mine, not Ford's.
Douglas W. Jones,201H MLH,3193350740,3193382879
From article <RJM.97Ja...@europa.ox.ac.uk>,
by r...@europa.ox.ac.uk (Bob Manners):
> 4Kwords == 9Kb. I take it that the PDP-1 had an 18 bit word length then?
Exactly. The PDP-1, PDP-4, PDP-7, PDP-9 and PDP-15 were related in that
regard. The later 18 bit machines were not compatable with the PDP-1,
though.
DEC Press has come out with a wonderful book, Digital At Work, that includes
photos and overviews of the specs for most of the PDP machines, as well as
predecessors like the MIT TX0.
You can find a short table of these attributes in the first part of the
alt.sys.pdp8 FAQ.
Doug Jones
jo...@cs.uiowa.edu
A.R. Duell
jo...@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes:
>DEC Press has come out with a wonderful book, Digital At Work, that includes
>photos and overviews of the specs for most of the PDP machines, as well as
>predecessors like the MIT TX0.
Yes, that book is rather fun but there are a number of errors in it that
may be confusing at first. I seem to recall that one of the pictures of a
'PDP11 System' is actually a VAX 11/730 (or maybe the other way round),
etc. My favourite error is the fact that a very nice picture of a PDP8 of
some flavour has been printed left-right reversed, or at least, I think it
has (unless there was an ASR-33 like teletype with the punch on the right,
and a single DECtape drive that filled the _right_ hand half of the rack
panel).
None-the-less, there's a lot of good stuff in it, and it's certainly worth
buying if you are interested in the old DEC machines.
> Doug Jones
--
-tony
ar...@eng.cam.ac.uk
The gates in my computer are AND,OR and NOT, not Bill
Douglas W. Jones,201H MLH,3193350740,3193382879
From article <5ct39s$j...@lyra.csx.cam.ac.uk>,
by ar...@eng.cam.ac.uk (A.R. Duell):
>>DEC Press has come out with a wonderful book, Digital At Work, ...
>
> Yes, that book is rather fun but there are a number of errors in it that
> may be confusing at first. I seem to recall that one of the pictures of a
> 'PDP11 System' is actually a VAX 11/730 (or maybe the other way round),
> etc. My favourite error is the fact that a very nice picture of a PDP8 of
> some flavour has been printed left-right reversed, ...
I hadn't noticed that one! Page 50, lower left. Not only is the tape
reader-punch on the ASR 33 on the wrong side, and the TU 55 drives with
their tape reels on the wrong side, but you can clearly read the unit
number on the upper drive -- a backwards 4.
I get the feeling that layout professionals really like people to face
to the right in profile views, and that that photo is as likely to have
been left-right reversed when it was originally run as an advertising
photo back in the 1970's as it is to have been reversed in for the book.
I've seen other left-right reversals in DEC ads from that era.
Doug Jones
jo...@cs.uiowa.edu
Johnny Billquist
>In article <RJM.97Ja...@europa.ox.ac.uk> r...@europa.ox.ac.uk (Bob Manners) writes:
>
>> > I have posted a reproduction of the documentation for a VERY early
>> > word-processor-like program, which ran on a PDP-1 with 4K words (9K bytes)
>> > of RAM in 1963. I think the program was written by Pete Samson, although
>> > no names appear in the documentation.
>>
>> 4Kwords == 9Kb. I take it that the PDP-1 had an 18 bit word length then?
>
>You betcha. My impression of the PDP genealogy:
>
>PDP 1,4,7,9,15: 18-bit machines
>PDP 5,8,12: 12-bit
>PDP 6,10,20: 36-bit
*Sigh* There never was any such beast as the PDP-20.
>PDP 11: 16-bit
>PDP 2: Never built
True, but it was reserved for a 24-bitter according to MRC.
>PDP 3: Designed, never built by DEC, but rumor has it a customer
> bought DEC modules and assembled one. Don't know word length.
36-bits. One was built in 1960, according to MRC.
>PDP 13: Never existed
>PDP 14: Industrial automation controllers. Don't know word length
12-bit, but with a 1-bit accumulator.
>PDP 16: Not a machine, but a system of register-transfer modules
> (memory, ALU, etc) from which a customer could build various
> computer-like devices. I used them in a class at Michigan; I
> believe DEC donated lots of 'em after they died in the market.
> They came out just in time to be obsoleted by the increasing
> level of integrated circuits of the time.
And it was a 16-bitter according to MRC.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@update.uu.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Roger Ivie (a known boogerhead)
In article <5csjas$4...@reader.seed.net.tw>, ds...@cameonet.cameo.com.tw wrote:
>I've heard others compare WordStar to nroff, troff, et al, and I can't
>for the life of me figure out where this notion comes from.
From the dot commands, near as I can figure.
Roger "using WordStar for 16 years and loving it" Ivie
iv...@cc.usu.edu
Stephen Westin
> In <SWESTIN.97...@dsg145.nad.ford.com> swe...@dsg145.nad.ford.com (Stephen Westin ) wri
<snip>
> >PDP 6,10,20: 36-bit
>
> *Sigh* There never was any such beast as the PDP-20.
OK, DECsystem-20. Or DECSYSTEM-20. Or decSystem20. Or whatever silly
combination of capitalization and punctuation the marketing people
came up with.
<snip>
> >PDP 16: Not a machine, but a system of register-transfer modules
> > (memory, ALU, etc) from which a customer could build various
> > computer-like devices. I used them in a class at Michigan; I
> > believe DEC donated lots of 'em after they died in the market.
> > They came out just in time to be obsoleted by the increasing
> > level of integrated circuits of the time.
> And it was a 16-bitter according to MRC.
I seem to recall that the ALU came in 4-bit chunks, so you could roll
your own. It was about two decades ago, so I might well be wrong. I
tried to implement an IBM-360 instruction set with the stuff, but
don't remember if I had a 32-bit ALU or not. Pretty sure I built
32-bit registers.
Chris Ward
> >PDP 5,8,12: 12-bit
Along with the knowledge that the Data General Nova was decended from the
PDP-8
(Edson DeCastro worked on both) two other machines that I worked with were
very similar to
the PDP-8. They were both made by Nicolet instrument Corp, the 1080 and
the 1180. I do not
remember much about the 1080 except that I think it was 18 bits (it ran
FFT's for an NMR) but I did
program the 1180 which was a 20 bit machine. Mounted in a Nicolet 1099 (I
think) FFT-IR machine
I think it may have been designed around the resoultion of the digitizers
that they had available.
I was able to program it like a PDP-8 (it had the same kind of Page zero
addressing for
indirect references and stuff, and was a single AC machine, and it may have
had relative addressing)
and it had a disk operating system called Dexter-2. It might have been an
OEM machine, but I do
not remember anything that would indicate a different origination of the
beast.
Anyone else see one of these?
John Everett
In article <01bc0fe8$97d6d740$0b4284a9@wardch>, c...@mail.idt.com says...
>
>Along with the knowledge that the Data General Nova was decended from the
>PDP-8
>(Edson DeCastro worked on both)
Ain't revisionist history wonderful! Actually the Nova was descended (as
opposed to decended) from the PDP-X (or X-project) at DEC. This was DEC's
first attempt at a 16 bit machine, rejected by the operations committee.
Eventually a new design emerged as the PDP-11.
--
jeve...@wwa.com (John V. Everett) http://www.wwa.com/~jeverett
Will Rose
ds...@cameonet.cameo.com.tw wrote:
[...]
: WordStar has had on-screen formatting since very early days -- probably
: since it first appeared in '78 or '79. To my knowledge, it has always
: been as WYSIWYG as you'd want to get on a character-cell display (one
: *can* go too far in that direction). In '81 or so all you needed for
: editing and printing was WS.COM, a dynamic code overlay, and a message
: overlay (there were also dynamic mail-merge and spelling overlays). It
: was an integrated editor and formatter, and it did letter-quality
: printing in proportionally spaced fonts on "incremental" printers (in
: those days, this generally meant daisywheels).
Not sure you needed the MSG overlay - if it didn't exist (to save space)
I seem to recall WS gave a standard "urk" message of some sort. 'Course,
you had then to work out what the message might have been.
ds...@cameonet.cameo.com.tw
Will Rose (c...@cts.com) wrote --
>ds...@cameonet.cameo.com.tw wrote:
>[...]
>: WordStar has had on-screen formatting since very early days -- probably
>: since it first appeared in '78 or '79. To my knowledge, it has always
>: been as WYSIWYG as you'd want to get on a character-cell display (one
>: *can* go too far in that direction). In '81 or so all you needed for
>: editing and printing was WS.COM, a dynamic code overlay, and a message
>: overlay.... [snipped by DS]
>
> Not sure you needed the MSG overlay - if it didn't exist (to save space)
> I seem to recall WS gave a standard "urk" message of some sort. 'Course,
> you had then to work out what the message might have been.
Yup, in 3.x at least, you could do without the message overlay
in a pinch. And working on an Apple II with one 128K disk drive,
you could get yourself into a pinch pretty easily. I have vague
memories of zapping WSMSGS.OVR once or twice... *very* vague....
Dan Strychalski -+=%#@#%=+- ds...@cameonet.cameo.com.tw
Chris Ward
> >Along with the knowledge that the Data General Nova was decended from
the
> >PDP-8
> >(Edson DeCastro worked on both)
>
> Ain't revisionist history wonderful! Actually the Nova was descended (as
> opposed to decended) from the PDP-X (or X-project) at DEC. This was DEC's
> first attempt at a 16 bit machine, rejected by the operations committee.
> Eventually a new design emerged as the PDP-11.
>
Does not mean that the PDP-X machine could not have been a machine
in the middle. I am not trying to revise history, but instead find out
what
it was. From my readings and listenings Mr. DeCastro was heavily involved
in the PDP-5/8 world and as I recall the project being cancelled did result
in his
leaving DEC and founding Data General. And there were even rumors of a
court
decision over DEC claiming ownership of the design, and (for instance the
bit
arrangement in the instruction decoding) where the Supreme Court said that
making these rearrangements were sufficent in this case to create a new and
novel machine, but that in future cases it would not be, because the
technique
had become general knowledge.
Chris Ward
shen...@escape.widomaker.com
ds...@cameonet.cameo.com.tw writes:
> TJ-2 does not resemble modern word processors with "on-screen
> formatting" or "WYSIWYG editing." It somewhat resembles earlier word
> processors like RUNOFF, TROFF or WordStar in which the editor and
> formatter are separate....
>WordStar has had on-screen formatting since very early days -- probably
>since it first appeared in '78 or '79. To my knowledge, it has always
No, it didn't. It was at best able to format given a document width
and show things like page breaks. It was never anywhere near WYSIWYG.
That is what the poster meant by on screen formatting. The display
of Wordstar was more to show you where you were in a document and some
basic characteristics, not what you would see on paper. Even my worst
ever printer looked better than that.
>I've heard others compare WordStar to nroff, troff, et al, and I can't
>for the life of me figure out where this notion comes from.
Then you must never have used the dot notation of Wordstar. Most of its
power was in the dot commands. nroff uses dot notation for its formatting
command set as well, and that is why Wordstar is considered similar.
The 8-bit Atari program TextPro was a lot like that as was the IBM PC
program PC-Write.
>BTW, WordStar version 7.0 came out in '92 and is still sold. The
>WordStar Users' Group is 16 or 17 years old and still going strong, and
>there is a *very* active Bitnet-style mailing list.
--
csh - shen...@widomaker.com - http://www.widomaker.com - Linux 2.0.25
----------------------------------------------------------------------
"The Heisenberg Uncertainly Principle has completely defeated the
Einsteinian Physisist" -- Huh? What? Who said that?
ds...@cameonet.cameo.com.tw
shen...@escape.widomaker.com wrote --
> ds...@cameonet.cameo.com.tw writes:
>
>> WordStar has had on-screen formatting since very early days -- probably
>> since it first appeared in '78 or '79. To my knowledge, it has always
>
> No, it didn't. It was at best able to format given a document width
> and show things like page breaks. It was never anywhere near WYSIWYG.
> That is what the poster meant by on screen formatting. The display
> of Wordstar was more to show you where you were in a document and some
> basic characteristics, not what you would see on paper. Even my worst
> ever printer looked better than that.
I was careful to write "on-screen formatting" and not "WYSIWYG", because
there is now a big difference. Before the Mac came out, however, what the
WordStar editing screen provided was called WYSIWYG, and it is still
called on-screen formatting. Margins, indents, outdents, page breaks,
exactly what text will print on each line -- all the formatting that
*can* be shown on a character-cell display is shown. Dot commands and
non-printing control codes can be displayed or hidden with two
keystrokes. There's a big difference between that and what you get using,
say, vi and nroff or troff. I call it on-screen formatting.
>> I've heard others compare WordStar to nroff, troff, et al, and I can't
>> for the life of me figure out where this notion comes from.
>
> Then you must never have used the dot notation of Wordstar. Most of its
> power was in the dot commands. nroff uses dot notation for its formatting
> command set as well, and that is why Wordstar is considered similar.
> The 8-bit Atari program TextPro was a lot like that as was the IBM PC
> program PC-Write.
I used dot commands to good effect for many years*, and I know that nroff
uses similar commands. I don't see how that makes WordStar the same kind
of program as nroff.
Dan Strychalski ds...@cameonet.cameo.com.tw
*Actually I changed the "dot" command flag character to 29h [)].
ds...@cameonet.cameo.com.tw
I wrote --
> I've heard others compare WordStar to nroff, troff, et al, and I can't
> for the life of me figure out where this notion comes from.
...and Liam Quin (l...@sq.com) replied (privately, but with cc's to the
newsgroups, so there's no telling if my [expletive deleted] news server
will ever carry them) --
> You always used to be able to put things like
> .PP
> in a Wordstar file (or just type them in) to start a new paragraph, etc.
Things *like* .pp, yes (.pp is not a WS dot command), but not to start a
new paragraph. Paragraphs are delimited by 0Dh 0Ah (cr+lf). Within a
paragraph, WS uses 8Dh 0Ah, that is, it sets the high bit on the
carriage-return code and treats the sequence as a soft line break.
> These commands are similar to nroff commands.
> You don't need to use them, and for all I know they aren't even documented
> any more... They were there in the CP/M versions of Wordstar at least.
You do need them for many things. They are documented: the 1992 DOS WS 7
manual's command index lists about 70 of them. In WS 7, you can type and
edit them manually or let the program enter them automatically in
response to your input in Macintosh-like dialog boxes. WS for W-----s
doesn't use them at all, though.
Dan Strychalski ds...@cameonet.cameo.com.tw
JMFBAH
You've been talking about a program called nroff. Since I was the first
group leader of the RUNOFF group at DEC, would you mind enlightening me?
We had a NRUNOF (sp?) for a while when the commands were being modified so
that semi-colons could be a terminator character of a formatting command
and the commands were shortened to 1-2 characters.
/BAH
Rick Hawkins
In article <shendrix.854927050@escape>, <shen...@escape.widomaker.com> wrote:
>ds...@cameonet.cameo.com.tw writes:
>No, it didn't. It was at best able to format given a document width
>and show things like page breaks. It was never anywhere near WYSIWYG.
but it beat the daylights out of word perfect :)
>>I've heard others compare WordStar to nroff, troff, et al, and I can't
>>for the life of me figure out where this notion comes from.
>Then you must never have used the dot notation of Wordstar. Most of its
>power was in the dot commands. nroff uses dot notation for its formatting
>command set as well, and that is why Wordstar is considered similar.
But you had to be careful in WS. .. was the comment command. It's been
a while, but in 82 as an undergraduate, a pair of ellipses (for omitted
text) deleted two lines from one of my English papers: after
reformating, both landed on the first lines . . .
I finally seem to have broken myself fo word star commands. Or at
least, I've remapped all of the ones i still use to word commands :)
>>BTW, WordStar version 7.0 came out in '92 and is still sold. The
>>WordStar Users' Group is 16 or 17 years old and still going strong, and
>>there is a *very* active Bitnet-style mailing list.
>"The Heisenberg Uncertainly Principle has completely defeated the
>Einsteinian Physisist" -- Huh? What? Who said that?
But it only exactly beats the not quite certan Einsteinian :)
--
R E HAWKINS
rhaw...@iastate.edu
These opinions will not be those of ISU until they pay my retainer.
Joe Morris
ds...@cameonet.cameo.com.tw writes:
>Daniel P. B. Smith (dpbs...@world.std.com) wrote --
>> I have posted a reproduction of the documentation for a VERY early
>> word-processor-like program, which ran on a PDP-1 with 4K words (9K bytes)
>> of RAM in 1963. I think the program was written by Pete Samson, although
>> no names appear in the documentation.
My recollection agrees with yours; similarly, my copy of the documentation
(Memo PDP-9-1, dated 9 May 1963) also has no signature block (mildly curious,
since many of the memos of that period have both an author's name and
an approval (often by J. B. Davis) on the last page.
> TJ-2 does not resemble modern word processors with "on-screen
> formatting" or "WYSIWYG editing." It somewhat resembles earlier word
> processors like RUNOFF, TROFF or WordStar in which the editor and
> formatter are separate....
It did, however, use the CRT to display words that required hyphenation.
The user pointed to the places where a word could be hyphenated, then
hit the "save" or "don't save" spot to control whether the hyphenation
information was to be added to the in-core directory.
The words that requried operator intervention were displayed long before
the output paper tape punch reached their location; with a reasonably
prompt reaction to their appearance the paper tape output would be
generated at full punch speed.
Joe Morris / MITRE
Max ben-Aaron
High their:
In the late 60's & early 70's I worked for a company (Medidata, later
Searle Medidata) which started life as a not-for-profit spin-off from
Lincoln Lab. (as I have heard), called American Science Institute. The
chief engineer, Ed Rawson was a friend of Dec's Olsen and he managed to
get hold of the modules used for the prototype PDP-2 which never
reached the market. ASI used them to build their own machine
(designed, I believe, by Chuck Corderman) which they called "Casino"
and was sometimes jocularly referred to as a PDP-2 1/2. Casino was
noteworthy for having, very early in trhe game, graphics capabilities.
It also had some special terminals which had labels that cannot be
repeated on this (family) newsgroup.
Mb-A
=================================================================
In <SWESTIN.97...@dsg145.nad.ford.com>
swe...@dsg145.nad.ford.com (Stephen Westin ) writes:
>
>In article <RJM.97Ja...@europa.ox.ac.uk> r...@europa.ox.ac.uk
(Bob Manners) writes:
>
>> > I have posted a reproduction of the documentation for a VERY
early
>> > word-processor-like program, which ran on a PDP-1 with 4K words
(9K bytes)
>> > of RAM in 1963. I think the program was written by Pete Samson,
although
>> > no names appear in the documentation.
>>
>> 4Kwords == 9Kb. I take it that the PDP-1 had an 18 bit word length
then?
>
>You betcha. My impression of the PDP genealogy:
>
>PDP 1,4,7,9,15: 18-bit machines
>PDP 5,8,12: 12-bit
>PDP 6,10,20: 36-bit
>PDP 11: 16-bit
>PDP 2: Never built
>PDP 3: Designed, never built by DEC, but rumor has it a
customer
> bought DEC modules and assembled one. Don't know word
length.
>PDP 13: Never existed
>PDP 14: Industrial automation controllers. Don't know word
length
>PDP 16: Not a machine, but a system of register-transfer
modules
> (memory, ALU, etc) from which a customer could build
various
> computer-like devices. I used them in a class at
Michigan; I
> believe DEC donated lots of 'em after they died in the
market.
> They came out just in time to be obsoleted by the
increasing
> level of integrated circuits of the time.
>
Max ben-Aaron
In <5ctbdp$cjd$1...@Zeke.Update.UU.SE> b...@Zeke.Update.UU.SE (Johnny
Billquist) writes:
>
>In <SWESTIN.97...@dsg145.nad.ford.com>
swe...@dsg145.nad.ford.com (Stephen Westin ) writes:
>
>>In article <RJM.97Ja...@europa.ox.ac.uk> r...@europa.ox.ac.uk
(Bob Manners) writes:
>>
>>> > I have posted a reproduction of the documentation for a VERY
early
>>> > word-processor-like program, which ran on a PDP-1 with 4K words
(9K bytes)
>>> > of RAM in 1963. I think the program was written by Pete
Samson, although
>>> > no names appear in the documentation.
>>>
>>> 4Kwords == 9Kb. I take it that the PDP-1 had an 18 bit word length
then?
>>
>>You betcha. My impression of the PDP genealogy:
>>
>>PDP 1,4,7,9,15: 18-bit machines
>>PDP 5,8,12: 12-bit
>>PDP 6,10,20: 36-bit
>
>
>>PDP 2: Never built
>
>
customer
>> bought DEC modules and assembled one. Don't know word
length.
>
>
>>PDP 14: Industrial automation controllers. Don't know word
length
>
>
modules
>> (memory, ALU, etc) from which a customer could build
various
>> computer-like devices. I used them in a class at
Michigan; I
>> believe DEC donated lots of 'em after they died in
the market.
>> They came out just in time to be obsoleted by the
increasing
>> level of integrated circuits of the time.
>
>
>--
>Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
>email: b...@update.uu.se || Reading murder books
>pdp is alive! || tryin' to stay hip" - B. Idol
High their:
Was the PDP-14 "LINC", a commercial version of a control computer built
at MIT'S Lincoln Lab?
Mb-A.
Stephen Westin
In article <5d5qms$b...@sjx-ixn7.ix.netcom.com> xen...@ix.netcom.com (Max ben-Aaron) writes:
<snip>
> High their:
>
> Was the PDP-14 "LINC", a commercial version of a control computer built
> at MIT'S Lincoln Lab?
Nope. The LINC-8 was a PDP-8 (I?) sharing a box (and, I think, memory)
with a LINC. It was a commercial product from DEC, and worked because
both the '8 and the LINC were 12-bit machines. The LINC had a bunch of
analog I/O and was useful for monitoring and controlling lab
experiments. The PDP-12 was the next generation of the LINC-8, and the
LINCtape evolved into DECtape.
I seem to recall that Cooley Lab at the University of Michigan wrote a
simple operating system for the LINC-8 which went on to become OS/8.
Douglas W. Jones,201H MLH,3193350740,3193382879
> Was the PDP-14 "LINC", a commercial version of a control computer built
> at MIT'S Lincoln Lab?
The first LINC was built in 1962 at Lincoln Labs using DEC logic modules.
By the end of 1963, an additional 20 or so machines had been built by
their end-users. At first, users simply purchased parts from DEC, but
then DEC began to sell the parts as a kit -- was this the first computer
sold in kit form? -- and as I understand it, DEC even allowed some
customers to assemble and test the machine at Maynard and then haul it
home ready to run.
In late 1964, DEC began to manufacutre and sell ready-to-run LINC
systems, made to order. All this happened before the 1965 introduction
of the PDP-8 and well before the 1966 introduction of the LINC-8 (a machine
that could run both the PDP-8 and LINC instruction sets. Eventually,
DEC built and sold 21 LINC systems, while customers built 29. In
addition, DEC sold 142 LINC-8 systems, and something like 3500 PDP-12
systems were sold to follow up on that success. Others also came out
with LINC clones, for example, the Spear MicroLINC.
Doug Jones
jo...@cs.uiowa.edu
David M. Razler
swe...@dsg145.nad.ford.com (Stephen Westin ) wrote:
| In article <5d5qms$b...@sjx-ixn7.ix.netcom.com> xen...@ix.netcom.com (Max ben-Aaron) writes:
|
| <snip>
|
| > High their:
| >
| > Was the PDP-14 "LINC", a commercial version of a control computer built
| > at MIT'S Lincoln Lab?
|
| Nope. The LINC-8 was a PDP-8 (I?) sharing a box (and, I think, memory)
| with a LINC.
PDP-8. the PDP-8/I-LINC machine was the PDP-12
| It was a commercial product from DEC, and worked because
| both the '8 and the LINC were 12-bit machines. The LINC had a bunch of
| analog I/O and was useful for monitoring and controlling lab
| experiments. The PDP-12 was the next generation of the LINC-8, and the
| LINCtape evolved into DECtape.
|
The PDP-14 was a semi-custom machine controller.
David M. Razler
david....@worldnet.att.net
Mark H. Wood
> In article <19970203141...@ladder01.news.aol.com>,
> JMFBAH <jmf...@aol.com> wrote:
>>You've been talking about a program called nroff. Since I was the first
>>group leader of the RUNOFF group at DEC, would you mind enlightening me?
Hey, kudos to you and all the RUNOFF group. I used it on various systems to
write a modest pile of documentation and at least one term paper, and I credit
that experience with my ability to make decent looking documents without having
to corral and direct a hundred thousand fancy WYSIWYG gizmos. When I see what
the next generation is composing, without the benefit of that experience, I
don't know whether to laugh or cry.
--
Mark H. Wood, Lead Systems Programmer +1 317 274 0749 [@disclaimer@]
MW...@INDYVAX.IUPUI.EDU Finger for more information.
I am endeavoring to construct a mnemonic circuit using stone knives and
bearskins. -- Spock
Eric Werme
jmf...@aol.com (JMFBAH) writes:
>You've been talking about a program called nroff. Since I was the first
>group leader of the RUNOFF group at DEC, would you mind enlightening me?
nroff is an old time Unix program that replaced roff, and older and, as far
as I know, lost program. (And probably no loss.) troff is a nroff
variant designed to talk to the Graphic Systems phototypesetter, but
various paths exist to talk to PostScript an other current printing
systems.
Nroff files generally include macro libraries, typcically for man pages
or one of two for documents.
Random nroff sample:
.IP "\fBgateway\fP \fIhost\fP
True if the packet used \fIhost\fP as a gateway. I.e., the ethernet
source or destination address was \fIhost\fP but neither the IP source
nor the IP destination was \fIhost\fP. \fIHost\fP must be a name and
must be found in both /etc/hosts and /etc/ethers. (An equivalent
expression is
.in +.5i
.nf
\fBether host \fIehost \fBand not host \fIhost\fR
.fi
.in -.5i
which can be used with either names or numbers for \fIhost / ehost\fP.)
.IP "\fBdst net \fInet\fR"
True if the IP destination address of the packet has a network
number of \fInet\fP, which may be either an address or a name.
Upper case commands are usually macros:
.IP - Indent Paragraph
.in - Indent (inches, points, etc)
.nf - no fill
.fi - fill
Embedded commands can change fonts - \fB bold, \fI italics. I forget
what \fR and \fP are, but you get the idea.
I assume PDP-10 RUNOFF and nroff have a common ancestor, but have never
been curious to look into it. The macro language in nroff has variables and
string processing functions that let the clever author do some
remarkable things.
--
<> Eric (Ric) Werme <> This space under reconstruction <>
<> <we...@zk3.dec.com> <> <>
Doug Humphrey
Does anyone remember the Imlacs? Fortran language only
as far as I know, but I only goofed on them a little bit.
Pretty early devices...
Not dec machines, I know, but the dec-heads are the people
who I trust to understand the old machines ;-)
Doug
(PDP10s forever!)
Barry Shein
There was R which ran under ITS and used similar dot commands as I
remember, and I thought R started life on CTSS. Can't say that with
any authority, just vague memories. The point being that there was
some relationship between "R" and "RUNOFF", the letter R wasn't
coincidental.
--
-Barry Shein
Software Tool & Die | b...@world.std.com | http://www.std.com
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
Bob Manners
> Hey, kudos to you and all the RUNOFF group. I used it on various systems to
> write a modest pile of documentation and at least one term paper, and I credit
> that experience with my ability to make decent looking documents without having
> to corral and direct a hundred thousand fancy WYSIWYG gizmos. When I see what
> the next generation is composing, without the benefit of that experience, I
> don't know whether to laugh or cry.
Don't lump all the 'next generation' together. I used TeX/LaTeX for
everything except UNIX man pages, for which I use groff.
Bob
--
------------------------------------------------------------------------------
Bob Manners 24 Temple Street, Oxford, OX4 1JS, Tel/FAX: 01865 245819
My REAL address is: r...@swift.eng.ox.ac.uk
------------------------------------------------------------------------------
JMFBAH
mw...@indyvax.iupui.edu (Mark H. Wood) wrote:
>> In article <19970203141...@ladder01.news.aol.com>,
<> JMFBAH <jmf...@aol.com> wrote:
>>You've been talking about a program called nroff. Since I was the first
>>group leader of the RUNOFF group at DEC, would you mind enlightening me?
>Hey, kudos to you and all the RUNOFF group.
<snip>
Thank you. Maybe it's time to document more of the ways we used to work
when Digital was DEC.
As the programming staffs grew, the work load at Tape Prep grew. The jobs
would come in, be assessed for length of time the job would take, and get
put into a priority list. It got so complex that nobody (writers,
reproducers, nor programmers) were getting their jobs done on time. So
Tape Prep was reorganized into three groups: 1) the RUNOFF group which
would handle all work that needed to be done in RUNOFF, 2) the
quick-turnaround group which took in jobs that could be done in less than
an hour or so, and 3) all the rest of the jobs.
At that time, all documentation that was published and shipped by DEC was
done on typewriters by a group of (about) 20 women. None of that stuff
was on-line. A few exceptions were the -10 functional specs and (I think)
the processor manual. After getting broken in, I decided that everything
should start to be done on-line. I began a campaign to convince writers to
type their stuff on-line; there were some who preferred to write on paper
but not many. It took some convincing that a complete retyping of a
chapter wasn't needed just because they added one text line; this was the
case when the documents were done by typewriters.
The RUNOFF group gradually transformed itself into a real typesetting
group (long after I left). RUNOFF was not very good at manipulating text
for publishing but it was very useful. For instance, double columns that
were automatically left/right justified and space-filled were impossible
to do, but we managed [smiling emoticon here]. I believe that the only
job I ever turned down was submitted by a one of the five V.P.s (for the
life of me I can't remember the name). My boss was insistent that I do
the job for fear that the VP would get unhappy. I pointed out that he
would be even more unhappy when we produced a sloppy job that took 20
hours/month to do. What he really wanted was a VISICALC piece of
software. This was in 1972; there was no such thing. I turned down the
job, explaining to him that it was more efficient for someone with good
secretarial skills to do the job since the software didn't exist.
I was always sorry that all those women (of the typing pool) were
eventually put out of a job but I was not sorry to finally get that
documentation into bits. Interestingly enough, the person who made a
transition to typing on-line from the pool was a woman who was considered
to be backward; but she could type 120 w.p.m. When she was being trained
to work on a computer, the decision was being made that she wouldn't be
able to learn RUNOFF. The plan was that she would WYSIWYG the
documentation into a file, and someone, like me, would insert RUNOFF
commands to do the formatting. That was unacceptable and I insisted that
she be taught RUNOFF commands, monitor-level commands and everything in
between. She learned and she just loved it.
/BAH
John Everett
In article <1997Feb4.1...@indyvax.iupui.edu>, mw...@indyvax.iupui.edu
says...
>
>> In article <19970203141...@ladder01.news.aol.com>,
>> JMFBAH <jmf...@aol.com> wrote:
>>>You've been talking about a program called nroff. Since I was the first
>>>group leader of the RUNOFF group at DEC, would you mind enlightening me?
>
>Hey, kudos to you and all the RUNOFF group.
I think you perhaps misunderstand, Barb (JMFBAH) was not responsible for the
creation of RUNOFF, but for its DEC-wide adoption as a documentation
standard.
The story of RUNOFF's creation is another piece of DEC folklore. Some person
(who's name is lost to history) had created a "text-processing" program that
ran on the PDP-10. He wanted to sell it to DEC. He came to Maynard one Friday
and demonstrated it to a group of us -10 types. He was careful to remove the
program from System 2 before he departed, but left behind some documentation.
On Monday, Bob Clements showed us how he had spent his weekend. He had
written a program that basically conformed to the guy's documentation. Bob
called his weekend project RUNOFF.
tli
Doug Humphrey <do...@ss1.digex.net> wrote:
Does anyone remember the Imlacs? Fortran language only
as far as I know, but I only goofed on them a little bit.
Pretty early devices...
1982.
Tony
--
Good Happens -- just a whole lot less frequently
Tom Van Vleck
Peter da Silva wrote:
>Early in the history of UNIX, back before Version 7 and the great UNIX
>explosion, there was a fairly simple text processor used for formatting
>the manual pages. It was inspired by "RUNOFF" and called "ROFF" (when you
>work on ASR33 teletypes, you like making command names short!).
Jerry Saltzer wrote the RUNOFF command for CTSS on the MIT 7094.
I remember using it for documentation in 1965, so it was a public
command by then. Saltzer acknowledged inspiration from TJ-2 and
expensive typewriter.
I believe the R formatter of ITS came after RUNOFF.
Doug McIlroy, Rudd Canaday, and Dennis Ritchie
wrote a version of runoff for 645 Multics in BCPL, so that the Multics
group could use its own system for documentation. Both of these
runoffs took input lines beginning with dot as command lines.
Bob Morris and Dennis Ritchie moved the BCPL runoff to BTL's
GE-635 and called it roff. McIlroy then wrote a roff from scratch
in BCPL, expanding and improving on runoff; Ken Thompson and Dennis
Ritchie then wrote a machine-language version of roff for their new
system, UNIX, about 1970, to justify the purchase of the PDP-11.
DEC's RUNOFF command might have been inspired by CTSS's, since
the DEC engineers who went to MIT in the 60s would have seen it.
Or it might have been an independent invention, with a coincidence
in names.
Paul Wexelblat
Yeah, We had an Imlac <something or other> at BBN in the Early 70's. I
don't remember much about it excepth that its assembly language was
virtually identical to a DEC system (maybe even the PDP-1) but it had
another processor in it that ran some graphics stuff (a "display list).
It was sitting back near the MTIMP (The Mag Tape IMP - yes, back then
there was a serious attempt to do realtime mag tape transfers over the
ARPAnet; this was before TCP/IP, though :-> )
...wex
Jay R. Ashworth
ds...@cameonet.cameo.com.tw wrote:
: I've heard others compare WordStar to nroff, troff, et al, and I can't
: for the life of me figure out where this notion comes from.
The dot command formatting engine?
Cheers,
-- jr '.PP' a
--
Jay R. Ashworth j...@scfn.thpl.lib.fl.us
Member of the Technical Staff Unsolicited Commercial Emailers Sued
The Suncoast Freenet Pedantry: It's not just a job, it's an adventure.
Tampa Bay, Florida +1 813 790 7592
Tom Knight
> I believe the R formatter of ITS came after RUNOFF.
R was well after runoff -- done in the Dynamic Modelling Group (home
of Zork) and well after the more popular TJ-6 formatter used for ITS
documentation.
Alan Frisbie
In article <5d8rb7$6...@ss1.digex.net>,
do...@ss1.digex.net (Doug Humphrey) writes:
> Does anyone remember the Imlacs?
Remember them? I have an Imlac PDS-1 here in my office,
along with the manuals and print sets. The last time I
turned it on, it still worked.
-- Alan E. Frisbie Fri...@Flying-Disk.Com
-- Flying Disk Systems, Inc.
-- 4759 Round Top Drive (213) 256-2575 (voice)
-- Los Angeles, CA 90065 (213) 258-3585 (FAX)
John Everett
In article <thvv-06029...@thvv.vip.best.com>, th...@best.com says...
>
>DEC's RUNOFF command might have been inspired by CTSS's, since
>the DEC engineers who went to MIT in the 60s would have seen it.
>Or it might have been an independent invention, with a coincidence
>in names.
The following is from Bob Clements, the author of DEC's PDP-10 RUNOFF. The
reason I'm posting (as opposed to Bob) is self-explanatory:
"Hi, John,
I haven't been posting lately due to getting ticked off at the resulting
junk email. Haven't had time to fix the environment to hide my address
properly. Feel free to post this if you omit the cleartext form
of my email address.
In article <5daa2f$lfc$1...@kirin.wwa.com> you write:
>The story of RUNOFF's creation is another piece of DEC folklore. Some person
>(who's name is lost to history) had created a "text-processing" program that
>ran on the PDP-10.
[...]
>On Monday, Bob Clements showed us how he had spent his weekend. He had
>written a program that basically conformed to the guy's documentation. Bob
>called his weekend project RUNOFF.
Well, this isn't how I remember it, and it gives me too much credit.
I don't remember anyone coming to offer such a program to DEC, but it
might have happened.
The actual origin of RUNOFF on the -10 was indeed me, but I didn't
write it from scratch or from specs. I did a fairly direct translation
of the source code for SDS-940 RUNOFF, which was written at UCB.
I had to redo the I/O and system call stuff, of course, but the
text formating logic was all straight out of the Berkley code.
If you can find a copy of the source code of RUNOFF, you'll see big
sections with registers named A, B and X (I think that's right), which
were the main registers of the 940. It didn't have general registers
like the DEC machines. That code was just plain copied.
Today, I suppose you'd get in trouble for that. In those days, it
wasn't that big a deal. Mea culpa."
Paul Wexelblat
Jay R. Ashworth wrote:
>
> ds...@cameonet.cameo.com.tw wrote:
> : I've heard others compare WordStar to nroff, troff, et al, and I can't
> : for the life of me figure out where this notion comes from.
>
> The dot command formatting engine?
<snip>
I could guess, but I expect that it's not common knowledge that WortStar
_was_
written by a PDP-1 programmer. Wordsatr (as orifginally written for the
Imasi (I think))
predates RUNOFF (predicessor to nroff).
I don't know TJ-2, but I did write a text justification program for the
PDP-1 that was
implemented in Logo. (I also wrote some of Logo, that was written for
the PDP-1 in Assembler
- Midas (predicessor to MACRO) but that's a different story.
Please address specific follows-up to alt.folklore.computers as I dont
subscribe to all the
crossposted groups mentioned.
...wex
Douglas W. Jones,201H MLH,3193350740,3193382879
From article <32FD3B...@concentric.net>,
by Paul Wexelblat <w...@concentric.net>:
>
> I could guess, but I expect that it's not common knowledge that WortStar
> _was_ written by a PDP-1 programmer. Wordsatr (as orifginally written for the
> Imasi (I think)) predates RUNOFF (predicessor to nroff).
????? RUNOFF (on MULTICS) dates from the late 1960's. That begat RUNOFF
on the Bell Labs GCOS system (I have the manuals for it that I got when
I worked at Bell in 1973), and that begat NROFF and TROFF in around 1973.
(The CAT Phototypesetter was still a hot new toy at Murray Hill when I
was there).
Nothing developed for the IMSAI predates any of this!!!!
A far more interesting lineage is the one that links TJ-2 to HTML. Anyone
want to lay it out in full? (Hint: HTML grew in the context of SGML,
which originally grew in the context of a type formatter on the IBM-360
family, which was based on ideas developed at IBM Cambridge Labs, which
had a connection with work done on CTSS at MIT -- the common ancestor
from which RUNOFF grew, by the way -- which was, no doubt, inspired by
TJ-2.)
Doug Jones
jo...@cs.uiowa.edu
JMFBAH
jeve...@wwa.DEFEAT.UCE.BOTS.com (John Everett) wrote a memory correction:
<snip>
<I think you perhaps misunderstand, Barb (JMFBAH) was not responsible for
the
<creation of RUNOFF, but for its DEC-wide adoption as a documentation
<standard.
<snip documentation about the real author of RUNOFF>
Yup. I did misunderstand this person. I also did a great big blunder
when I wrote that Pete Conklin wrote RUNOFF; I did not remember that Bob
wrote it. Please forward my humblest apologies to Bob Clements [emoticon
here wincing from the application of 2 lashes of a wet noodle].
Now, I'm befuddled about what Pete did write that helped me put bread on
my table. FACTPR maybe?
/BAH
Alan Bowler
In article <5cvtfc$22j$3...@kirin.wwa.com> jeve...@wwa.DEFEAT.UCE.BOTS.com (John Everett) writes:
>In article <01bc0fe8$97d6d740$0b4284a9@wardch>, c...@mail.idt.com says...
>>
>>Along with the knowledge that the Data General Nova was decended from the
>>PDP-8
>>(Edson DeCastro worked on both)
>
>Ain't revisionist history wonderful! Actually the Nova was descended (as
>opposed to decended) from the PDP-X (or X-project) at DEC. This was DEC's
>first attempt at a 16 bit machine, rejected by the operations committee.
>Eventually a new design emerged as the PDP-11.
It is not all that revisionist. While the Nova was a 16 bit system,
it had a very pdp-8 flavour to it. The fact that internal to DEC
there was a (rejected) intermediate design between the PDP-8 and the Nova
doesn't much change the fact that it is a "spiritual" decendant of the
PDP-8.
Mike Albaugh
John Everett (jeve...@wwa.DEFEAT.UCE.BOTS.com) wrote:
: The following is from Bob Clements, the author of DEC's PDP-10 RUNOFF.
: The actual origin of RUNOFF on the -10 was indeed me, but I didn't
: write it from scratch or from specs. I did a fairly direct translation
: of the source code for SDS-940 RUNOFF, which was written at UCB.
Hmmm, I thought it looked familiar, but the "Runoff"-like
thingy on the [SX]DS-9[34]0 :-) was, AFAIK, called "Autosecretary".
I may even have a manual buried in those boxes of books in the attic.
I never actually had an account on the '940, being an undergrad
at the time, but I _did_ pull cable for its terminals and once even
repair one of the boards in the terminal interface. For you young'uns,
this was a rack of DEC "System Modules" (Preceded Flip Chips, and
were also used on the PDP-6 we had) where each line interface (what
we'd call a UART today) used two or three cards. I know the tranmitter
and receiver were separate, I just don't recall whether there was
also a separate "control" card. Perhaps I can stir some memories
out there. These little wonders were so well designed that the
later UARTs from Western Digital and General Instruments pretty
much copied them verbatim (Perhaps they were designed to DEC spec),
and I always get a little peeved when I run into a serial interface
that is _less_ well designed but done later (8530, 8250, Rockwell VIA...)
Anyway, the odd thing I remember about Autosecretary was
that it output a tape that had to be flipped over and fed to a
Flexowriter. Apparently Friden and Teletype had differing ideas
about where the sprocket holes should go :-)
: If you can find a copy of the source code of RUNOFF, you'll see big
: sections with registers named A, B and X (I think that's right),
Matches my recollection, although as I said before I did not get
_that_ close to the machine. Amazing what a machine with 16K of
24-bit words per process (about 64 or 128K total) could do. OTOH,
the limited per-process space made "fork" the tool of choice
for task decomposition, and I'm still living with _that_ headache
today on my company-issue Unix machine, _years_ after per-process
address space made single-address-space tasks possible...
(I also blame them for making "delete" the default "interrupt"
key. Made using the paper-tape reader a real thrill :-)
: Today, I suppose you'd get in trouble for that. In those days, it
: wasn't that big a deal. Mea culpa."
As I recall, Project Genie (the 930->940 conversion and
software development) was ARPA-funded, and the source code was
freely distributable.
Mike
| alb...@agames.com, speaking only for myself
John Bayko
In article <E5EGE...@thinkage.on.ca>,
Here's what the Great Microprocessors List has to say about the
various descendants of the PDP-8 - the complete descriptions are
available in the list from my home page,or the CPU Info Center at:
http://infopad.eecs.berkeley.edu/CIC/
Great Microprocessors of the Past and Present (V 9.2.2)
[...]
Section One: Before the Great Dark Cloud.
[...]
Part V: The 6809, extending the 680x (1977)
Like the 6502, the 6809 was based on the Motorola 6800 (1974), which
was initially based on the design of the big endian DEC PDP-8, though
the 6809 expanded the design significantly. [...]
Section Two: Forgotten/Innovative Designs before the Great Dark Cloud
[...]
Part VI: Intersil 6100, old design in a new package
The IMS 6100 was a single chip design of the PDP-8 minicomputer
(1965) from DEC (low cost successor to the PDP-5 (1963)).
The old PDP-8 design was very strange, and if it hadn't been
so popular, an awkward CPU like the 6100 would have never had a reason
to exist.
[...]
Part VII: NOVA, another popular adaptation
Like the PDP-8, the Data General Nova was also copied, not just in
one, but two implementations - the Data General MN601 (MicroNova),
and Fairchild 9440. However, the NOVA was a more mature design (by PDP-8
designer Edson DeCastro, who came to Data General from DEC).
[...]
Another CPU, the PACE, was based on the NOVA design, but featured
16 bit addressing, more addressing modes, and a 10 level stack (like
the 8008).
The 32 bit ECLIPSE (pre 1983) was Data General's successor to the 16
bit Nova. [...]
Part VIII: Signetics 2650, enhanced accumulator based (1978?)
Superficially similar to the PDP-8 (and IMS 6100), the Signetics
2650 was based around a set of 8 bit registers with R0 used as an
accumulator, [...]
--
John Bayko (Tau).
ba...@cs.uregina.ca
http://www.cs.uregina.ca/~bayko
Ross Alexander
I've edited heavily since my comment is a brief one.
ba...@borealis.cs.uregina.ca (John Bayko) writes:
> Here's what the Great Microprocessors List has to say about the
>various descendants of the PDP-8 - the complete descriptions are
[...]
> Like the 6502, the 6809 was based on the Motorola 6800 (1974), which
>was initially based on the design of the big endian DEC PDP-8, though
>the 6809 expanded the design significantly. [...]
It's not at all clear to me what the line of descent between a machine
(6800) with
two accumulators (mostly orthogonal)
PC relative displacement branches
condition codes
8-bit organization
hardware stack
index register
vectored interrupts (admittedly primitive)
and a earlier machine (pdp8) with
one accumulator and a totally non-orthogonal quotient register
page relative branches
no condition codes
12 bit organization
no stack
no index register (I don't count mem locs 0010 .. 0017 as index registers)
flat interrupts
might be beyond that fact that they're both small 2s complement von
Neumann machines. I've hacked on both and they have totally different
`feels'.
In short, the 6800 doesn't seem to share a lineage with the pdp8.
The intersil 6100, definitely.
regards,
Ross
--
Ross Alexander, ve6pdq -- (403) 675 6311 -- r...@cs.athabascau.ca
Douglas W. Jones,201H MLH,3193350740,3193382879
ba...@borealis.cs.uregina.ca (John Bayko) writes:
> Here's what the Great Microprocessors List has to say about the
>various descendants of the PDP-8 - the complete descriptions are
> Like the 6502, the 6809 was based on the Motorola 6800 (1974), which
>was initially based on the design of the big endian DEC PDP-8, though
>the 6809 expanded the design significantly. [...]
No! As near as I can tell, the 6800 had nothing to do with the PDP-8.
Single accumulator machines were the rule, not the exception, from 1946
when Berks, Goldstein and Von Neumann first proposed the fetch-execute
cycle as we know it, and the late 1950's. In the 1960's, virtually all
of the significant minicomputers were single-accumulator machines, and
strong shawows of that world-view held on in the first generation of
microprocessors. The only major micrpocessor today with strong vestiges
of this worldview is, of course, the Intel family of 80x86 machines.
Anyway, someone needs to get their hands on the documentation for
Motorola's first 8-bit processor, the MDP-1000, released in 1968. It
wasn't a microprocessor, it was a minicomputer, made with TTL, I think,
but I'll lay odds that the 6800 architecture draws on the experience of
the MDP-1000 far more than it draws on the PDP-8.
Also, John Bayko's list completely missed the HP 21XX series of
minicomputers. Both the HP 21XX and DG NOVA series can be described
as 16 bit versions of the PDP-8, but in widening the word, the two
teams came to different conclusions about what to do with the extra
bits (HP used 2 accumulators, DG used 4, and so on). DG was a DEC
spinoff, while HP (or rather, an HP subsidiary) was a major OEM customer
of DEC PDP-8 hardware in the mid 1960's -- so major that, according to
an interview published by CHAC, HP seriously considered buying DEC
before they decided to make their own machines.
Doug Jones
jo...@cs.uiowa.edu
John Bayko
In article <5dt21u$f...@aurora.cs.athabascau.ca>,
Ross Alexander <r...@cs.athabascau.ca> wrote:
>> Like the 6502, the 6809 was based on the Motorola 6800 (1974), which
>>was initially based on the design of the big endian DEC PDP-8, though
>>the 6809 expanded the design significantly. [...]
>
>(6800) with
>
> two accumulators (mostly orthogonal)
> PC relative displacement branches
> condition codes
> 8-bit organization
> hardware stack
> index register
> vectored interrupts (admittedly primitive)
>
>and a earlier machine (pdp8) with
>
> one accumulator and a totally non-orthogonal quotient register
> page relative branches
> no condition codes
> 12 bit organization
> no stack
> no index register (I don't count mem locs 0010 .. 0017 as index registers)
> flat interrupts
>
>might be beyond that fact that they're both small 2s complement von
>Neumann machines. I've hacked on both and they have totally different
>`feels'.
>
>In short, the 6800 doesn't seem to share a lineage with the pdp8.
>The intersil 6100, definitely.
Pretty indirect, but the basic idea was followed, at least
initially - the 6800 was the only accumulator-based microprocessor at
the time, compared to the register-based 8080. I think the differences
can be mostly attributed to learning from past mistakes.
I read in the same article that Motorola intended the 6809 to be
more like the PDP-11, while other designers wanted to continue
refining the 6800, and this is part of what eventually caused one
group to split off and form MOS Technologies to design the 650x. On
the other hand, apart from adding interesting addressing modes, I don't
know exactly how the 6809 was very PDP-11-ish...
Maybe 'inspired' would be a better description of the 6800's
relation to the PDP-8.
Bob Manners
>the 6800 was the only accumulator-based microprocessor at
>the time, compared to the register-based 8080.
Pardon my ignorance here, but how would one define 'accumulator-based'
and 'register-based'?
As far as I'm aware of the (relatively recent) use of the word
'accumulator', it seems to refer to a register in a processor which is
sufficiently non-orthogonal that maths operations may not be done in
the other registers.
Does that make any sense?
Carl R. Friend
Bob Manners wrote in article Nr. <RJM.97Fe...@europa.ox.ac.uk>:
>
> Pardon my ignorance here, but how would one define 'accumulator-based'
> and 'register-based'?
>
> As far as I'm aware of the (relatively recent) use of the word
> 'accumulator', it seems to refer to a register in a processor which is
> sufficiently non-orthogonal that maths operations may not be done in
> the other registers.
If I'm remembering things correctly here (feel free to correct me!
Dr. Jones?), the original "accumulators" were essentially "self-adders"
which both held a value, and, when a new item was submitted to them,
they added the submitted datum to their current contents, thereby
"accumulating" incoming data. The term is (in a computer sense) a
very old one.
In "modern" machines, the terms "accumulator" and "register" are
often used interchangably, although "accumulator" seems to be falling
out of favour.
Note that the term "register" didn't always denote a processor-
internal scratchpad; in the LINC machine designed in the early '60s,
the term "register" was used to refer to what we'd now call a memory
location. Hence, in the LINC, you had 1024 "registers" in both the data
and instruction fields, and a single 12-bit "accumulator" (which was,
in fact, a simple 12-bit latch with input gating that could engage an
adder.
The PDP-8 follows the same analogy; the main "register" is called an
"accumulator", possibly for no other reason than that's what the
designers were familiar with. The PDP-10 architecture sported sixteen
"ACs", which were also known as "Fast Memory" (in the KA, FM was an
option - without it the 16 ACs dwelt in the first 16 words of core).
--
______________________________________________________________________
| | |
| Carl Richard Friend (UNIX Sysadmin) | West Boylston |
| Minicomputer Collector / Enthusiast | Massachusetts, USA |
| mailto:carl....@stoneweb.com | |
| http://www.ultranet.com/~engelbrt/carl/museum | ICBM: N42:22 W71:47 |
|________________________________________________|_____________________|
gag...@clark.net
In article <5djhge$s...@flood.weeg.uiowa.edu>,
Douglas W. Jones,201H MLH,3193350740,3193382879 <jo...@pyrite.cs.uiowa.edu> wrote:
>From article <32FD3B...@concentric.net>,
>by Paul Wexelblat <w...@concentric.net>:
>
>(The CAT Phototypesetter was still a hot new toy at Murray Hill when I
>was there).
>
group at DEC (Tim Stein and myself, and others) wrote a driver for
the CAT pretty early after its introduction. It was a neat little
typesetting machine, and we were glad to get one because it was
the first 'real' typesetting machine we had in house. I recall the
date as 1973-74 or so, but could be wrong. Others who worked on
Typeset-10 included Dan Bricklin. Typeset-10 was roughly modeled
after Typeset-8, which was a wildly popular newspaper production
system. The -10 version (in MACRO-10) had a number of innovative
features, including a neat hyphenation algorithm that used a cute
hashing algorithm derived from the -10's ability to do infinite
level indirection and clever bit operations. It ran circles around
anything else that we knew of.
The Typeset-10 language was, in fact, modeled after the way that
MIDAS (the -10 assembler at MIT) handled macros. You could
do integer arithmetic in it, using the algorithms from
Peter Sampson's wonderful STRING language, which allowed for
infinite precision. Also, if you wanted,
you could ouput the results directly was word strings in english,
or as roman numerals.
Originally, Typset-10 had been planned to use RUNOFF syntax, but
it was clear that such a syntax was too cumbersome. Some vestiges
remained, which was unfortunate or we would have invented TEX.
>
>A far more interesting lineage is the one that links TJ-2 to HTML. Anyone
>want to lay it out in full? (Hint: HTML grew in the context of SGML,
>which originally grew in the context of a type formatter on the IBM-360
>family, which was based on ideas developed at IBM Cambridge Labs, which
>had a connection with work done on CTSS at MIT -- the common ancestor
>from which RUNOFF grew, by the way -- which was, no doubt, inspired by
>TJ-2.)
I recall using RUNOFF or something very like it on the 7094
CTSS system at MIT, which would have been in the mid/late sixties,
and of course MIT-AI later had a much more powerful
version for both the PDP-6 and later for the PDP-10. So I'd put
the evolutionary chain as CTSS --> MULTICS/MIT-AI and lots of
branches after that. None of which is to speak of Electric Typewriter,
and the many other efforts that were going on at the same time,
including a truly bizzare text processor in use on the Phoenix
machine at MITRE, which Joe Morris probably remembers much better
than I do.
Robert Houk - SMCC Bos Desktop Hardware
>(The CAT Phototypesetter was still a hot new toy at Murray Hill when I
>was there).
I'm probably wrong on the 'who was first' here, but the Typeset-10
group at DEC (Tim Stein and myself, and others) wrote a driver for
the CAT pretty early after its introduction. It was a neat little
typesetting machine, and we were glad to get one because it was
the first 'real' typesetting machine we had in house. I recall the
date as 1973-74 or so, but could be wrong. Others who worked on
Probably pretty accurate, as the CAT (wasn't it "CATT" or "C/A/T/T",
or something like that?) was "well established" (and later nicknamed
by me as the "grind grind stink stink" machine) by the end of 1975
when I got there and inherited ITPS-10 (aka Typeset-10 in drag).
Typeset-10 included Dan Bricklin. Typeset-10 was roughly modeled
after Typeset-8, which was a wildly popular newspaper production
system. The -10 version (in MACRO-10) had a number of innovative
features, including a neat hyphenation algorithm that used a cute
hashing algorithm derived from the -10's ability to do infinite
level indirection and clever bit operations. It ran circles around
anything else that we knew of.
As I very vaguely recall, I timed it at around 2000 lines/second on
a KI-10, which I thought was pretty amazing, all things considered.
Originally, Typset-10 had been planned to use RUNOFF syntax, but
it was clear that such a syntax was too cumbersome. Some vestiges
remained, which was unfortunate or we would have invented TEX.
I wrote a RUNOFF macro for it, and managed to hornswoggle a friend
into completing Conklin's (?) abortive RUNOFF/TYPESET interface, so
we could take standard RUNOFF input and "typeset it". People were
pretty amazed to see hyphenated RUNOFF output come out on the line-
printers, let-alone proportionally-spaced stuff on the Diablo!
(Don't think we ever quite mastered footnotes, though...)
Ah, the good ole days . . . I *still* don't like WYSIWSYG formatters
like Word et al (although they do make tables a *lot* easier)
-RDH
jmfb...@ma.ultranet.com
In article <c3b914ojsrp.fsf@urq>,
'ey Bob!
I remember using that software to create great galleys. I also remember
using your terminal, GT-40?maybe?. I seem to remember that it sounded
like a small airplane. I would type in RUNOFF format, run the .RNO file
through some kind of pre-formatter and then (somehow) get it printed on
the machine that was on MRO-1. It produced great copy; a great leap
forward from the Diablo.
By the way, this is my first test of entering an item using this ISP.
(AOL became a swear when it started to tell me to get off the system!).
/BAH
Brian Harvey
People in this thread have been comparing RUNOFF and friends with TeX.
You might be interested to know that the PDP-10 was the host for an early
TeX precursor, the professional typesetting system that I worked on (along
with Lowell Hawkinson and some others) at Composition Technology
circa 1970, I believe the first program that handled high-quality
typesetting of mathematical formulas from user input in math terms
rather than exact positional terms.
Mark H. Wood
Yup -- the "shadow ACs" area was underneath them, and the Monitor could use it
somehow (but it's been too long for me).
The IBM 360/44 used core for all kinds of stuff that you might not expect,
including registers. Again real registers were an extra-cost option I believe.
(It's also been many moons since I worked on one of these.) But you couldn't
load inner loops into the registers and jump to them like TECO reputedly did on
the PDP-10.
--
Mark H. Wood, Lead Systems Programmer +1 317 274 0749 [@disclaimer@]
MW...@INDYVAX.IUPUI.EDU Finger for more information.
I am endeavoring to construct a mnemonic circuit using stone knives and
bearskins. -- Spock
Chris Zach
> The IBM 360/44 used core for all kinds of stuff that you might not expect,
> including registers. Again real registers were an extra-cost option I
believe.
> (It's also been many moons since I worked on one of these.) But you
couldn't
> load inner loops into the registers and jump to them like TECO reputedly
did on
> the PDP-10.
Of course, the untimate hell was the PDP-8/S. With a 1 bit accumulator (ok, a
flip flop) I think it sequenced the instructions and data through the flip
flop one bit at a time. A true serial computer....
CZ
--
Time to take time
For Spring will turn to Fall
In just no time at all...
Smith and O'Halloran
In article <1997Feb20.1...@indyvax.iupui.edu>,
Mark H. Wood <mw...@indyvax.iupui.edu> wrote:
>> The PDP-10 architecture sported sixteen
>> "ACs", which were also known as "Fast Memory" (in the KA, FM was an
>> option - without it the 16 ACs dwelt in the first 16 words of core).
>
>Yup -- the "shadow ACs" area was underneath them, and the Monitor could use it
>somehow (but it's been too long for me).
Not quite. Whether the AC references went to Fast Memory or to absolute
core locations 00-17 on the KA-10 depends on the setting of the "FM ENB"
switch on the console front panel.
Normally, FM ENB was left ON, enabling Fast Memory. But if you had
previously installed the 16-word bootstrap program into core while
FM ENB was OFF, the program would still be there inspite of intervening
power failures.
The true magic of the PDP-10 instruction set was in the RIM-10B loader.
The program is 14 instructions long and uses 2 accumlators for data.
It reads in 36-bit words from an 8-bit paper tape reader, deposits the
data in memory, and verifies the checksums of the program it is loading.
-Joe
--
INWAP.COM is Joe and Sally Smith, John and Chris O'Halloran and our cats
See http://www.inwap.com/ for "ReBoot", PDP-10, and Clan MacLeod.
John Everett
In article <5ej2j4$3...@student.computer.org>, c...@alembic.crystel.com says...
>
>> The IBM 360/44 used core for all kinds of stuff that you might not expect,
>> including registers. Again real registers were an extra-cost option I
>believe.
>> (It's also been many moons since I worked on one of these.) But you
>couldn't
>> load inner loops into the registers and jump to them like TECO reputedly
>did on
>> the PDP-10.
>
>Of course, the untimate hell was the PDP-8/S. With a 1 bit accumulator (ok,
a
>flip flop) I think it sequenced the instructions and data through the flip
>flop one bit at a time. A true serial computer....
And performance to match. As a charter member of the PDP-8 programming group
(when the "group" was Roger Pyle and me) I had to test everything I wrote for
PDP-8/S compatibility. Some of the most boring hours I've ever spent.
Smith and O'Halloran
In article <5ekohr$b...@shell3.ba.best.com>,
Smith and O'Halloran <in...@shell3.ba.best.com> wrote:
>The true magic of the PDP-10 instruction set was in the RIM-10B loader.
>The program is 14 instructions long and uses 2 accumlators for data.
>It reads in 36-bit words from an 8-bit paper tape reader, deposits the
>data in memory, and verifies the checksums of the program it is loading.
Someone asked me to post the RIM10B loader. Here it is, with an analysis.
Somewhere I read the story of how it was created; a really bright hacker
was tricked into creating it when his colleagues kept saying that it
couldn't be done. Anyone have the details?
-Joe
lynx -dump http://www.inwap.com/pdp10/rim10b.html
RIM10B LOADER
RIM10B ; Causes RIM10B loader to be punched
00/ 777762,,0 XWD -16,0
01/ 710600,,60 ST: CONO PTR,60
02/ 541400,,4 ST1: HRRI A,RD+1
03/ 710740,,10 RD: CONSO PTR,10
04/ 254000,,3 JRST .-1
05/ 710470,,7 DATAI PTR,@TBL1-RD+1(A)
06/ 256010,,7 XCT TBL1-RD+1(A)
07/ 256010,,12 XCT TBL2-RD+1(A)
10/ 364400,,0 A: SOJA A, ; Magic occurs here ****
11/ 312740,,16 TBL1: CAME CKSM,ADR
12/ 270756,,1 ADD CKSM,1(ADR)
13/ 331740,,16 SKIPL CKSM,ADR
14/ 254200,,1 TBL2: JRST 4,ST
15/ 253700,,3 AOBJN ADR,RD
16/ 254000,,2 ADR: JRST ST1
17/ CKSM=ADR+1
Here is an example of a two-word program as output by RIM10B
17/ 777776,,777 LOC 1000 ; Set starting address
20/ 201740,,3777 START: MOVEI 17,4000-1
21/ 505740,,777600 HLRI 17,-200
22/ 707677,,4576 ; Sum of previous 3 words
23/ 254000,,1000 END START
ANALYSIS
RIM
When the Read-In Mode (RIM) switch is pressed on the console of
a KA or KI, it sends a reset pulse down the I/O bus, sets the
PC flags to zero, and executes "DATAI D,0" (where D is the
device code selected by a set of 7 switches, the paper tape
reader is device 104). The DATAI reads in an IOWD, which has
the negative word count in the left half and starting address
minus one in the right half. The CPU then repeatedly executes
"BLKI D,0" until the left half of location 0 reaches zero.
("BLKI D,X" increments both halves of location X, reads in a
word from device D, and stores it the address that the right
half of location X now points to.)
00/ XWD -16,0
Transfer 16 octal (14 decimal) words, starting at location 1.
01/ST: CONO PTR,60
Start paper tape reader in binary mode
02/ST1: HRRI A,RD+1
Reset finite-state machine to looking for IOWD
State RD+1 = Looking for IOWD or JRST
03/RD: CONSO PTR,10
Read paper tape reader status, skip if "DONE" bit is set
04/ JRST .-1
Not set, keep looping until the bit does get set
05/ DATAI PTR,@TBL1-RD+1(A)
Index register A has RD+1, indexing TBL1-RD+1+RD+1 is TBL1+2,
which is the SKIPL CKSM,ADR instruction, therefore the
effective address is ADR. Store the IOWD in ADR.
06/ XCT TBL1-RD+1(A)
Same effective address, "SKIPL CKSM,ADR" loads the IOWD into
accumulator CKSM, and skips next instruction because its
negative.
07/ XCT TBL2-RD+1(A)
Not executed first time around. At the end of the tape, a JRST
instruction will be read in instead of an IOWD. (JRST is opcode
254, which is postitive). TBL2-RD+1+RD+1 is TBL2+2, which is
ADR. The JRST instruction which was just read in is executed,
and that causes the PC to jump to the beginning of the program.
10/A: SOJA A,RD+1
Set the PC to RD+1, subtract one from index register A (so it
now has RD in the right half, then jump to the original address
(RD+1).
04/ JRST .-1
Not set, keep looping until the bit does get set
State RD+0 = Reading in data words
03/RD: CONSO PTR,10
Read paper tape reader status, skip if "DONE" bit is set
04/ JRST .-1
Not set, keep looping until the bit does get set
05/ DATAI PTR,@TBL1-RD+1(A)
Index register A has RD+0, indexing TBL1-RD+1+RD+0 is TBL1+1,
which is the ADD CKSM,1(ADR) instruction, therefore the
effective address is one greater than what ADR points to. Store
the data in memory.
06/ XCT TBL1-RD+1(A)
Same effective address, "ADD CKSM,1(ADR)" adds the word read in
to the additive checksum in accumulator CKSM.
07/ XCT TBL2-RD+1(A)
The address is TBL2-RD+1+RD+0 which is TBL2+1. That location
has "AOBJN ADR,RD". Add one to both halves of accumulator ADR.
If the result is still negative, loop back to RD (location 3).
If non-negative, continue on at location 10.
10/A: SOJA A,RD+0
Set the PC to RD+0, subtract one from index register A (so it
now has RD-1 in the right half, then jump to the original
address (RD+0).
State RD-1 = Reading in checksum
03/RD: CONSO PTR,10
Read paper tape reader status, skip if "DONE" bit is set
04/ JRST .-1
Not set, keep looping until the bit does get set
05/ DATAI PTR,@TBL1-RD+1(A)
Index register A has RD-1, indexing TBL1-RD+1+RD-1 is TBL1+0,
which is the CAME CKSM,ADR instruction, therefore the effective
address is ADR. Store the expected checksum in ADR.
06/ XCT TBL1-RD+1(A)
Same effective address, "CAME CKSM,ADR" compares the calculated
checksum in accumulator CKSM with the expected checksum stored
in memory location ADR. Skip the next instruction if they're
equal.
07/ XCT TBL2-RD+1(A)
The address is TBL2-RD+1+RD-1 which is TBL2+0. That location
has "JRST 4,ST" which is a HALT instruction. If the previous
compare instruction failed, set the program counter to ST and
halt the CPU. This allows the operator to back up the paper
tape reader and try again. If the CAME succeeded, this HALT is
not executed.
10/A: SOJA A,RD+1
Set the PC to RD+1, subtract one from index register A (so it
now has RD-2 in the right half, then jump to the original
address (RD+1). This jumps to location ST1, which resets the
finite-state machine.
Dispatch table for finite-state machine
11/TBL1: CAME CKSM,ADR
In state RD-1, read expected checksum into ADR, then compare
calculated checksum with expected checksum.
12/ ADD CKSM,1(ADR)
In state RD+0, store data word into memory, then add data word
into running checksum.
13/ SKIPL CKSM,ADR
In state RD+1, store IOWD or JRST in ADR, then load that word
into accumulator CKSM and skip if the word is negative.
14/TBL2: JRST 4,ST
If the checksum comparison fails, halt the CPU, with ST in the
PC.
15/ AOBJN ADR,RD
In state RD+0, increment the IOWD and jump to RD if more to go.
16/ADR: JRST ST1
This is the last word of the RIM10B loader. When the hardware
read-in process is completed, this instruction is executed to
start the program.
17/CKSM=ADR+1
The additive checksum is calculated using this accumulator.
STORING BOOTSTRAP IN CORE MEMORY
The FM ENB switch enables Fast Memory, causing references to the
accumulators (locations 00 through 17) to go to RAM instead of core
memory. When FM ENB is off, the above bootstrap can be toggled into
locations 01 through 16. (Locations 00 and 17 need not be
initialized.)
[End of http://www.inwap.com/pdp10/rim10b.html]
jmfb...@ma.ultranet.com
In article <5enk2j$c...@shell3.ba.best.com>,
Aaaahhh!!! JRSTs, HRLIs, CAMEs. Isn't it wonderful to speak a familiar language
for a change?
/BAH
Carl R. Friend
Smith and O'Halloran wrote in
article Nr. <5enk2j$c...@shell3.ba.best.com>:
>
> [RIM loader code saved and snipped]
>
> STORING BOOTSTRAP IN CORE MEMORY
>
> The FM ENB switch enables Fast Memory, causing references to the
> accumulators (locations 00 through 17) to go to RAM instead of core
> memory. When FM ENB is off, the above bootstrap can be toggled into
> locations 01 through 16. (Locations 00 and 17 need not be
> initialized.)
>
In any event, this technique would only work on the KA-10. Later
-10s used semiconductors exclusively, so there wasn't any way to save/
load anything to the lowest of low core.
As an interesting sidelight, the KI-10 had four sets of AC (or FM,
if you will) selectable by the operating system or by front panel
switches (IIRC, in the same little panel that had the margining con-
trols and ReadIn Device switches). Whether DEC ever made use of the
added ACs, I'm not sure, but doing so would certainly have helped
during context switches.
Tom Moser
In article <33157086...@swec.com>, "Carl R. Friend" <carl....@swec.com> writes:
> Smith and O'Halloran wrote in
> article Nr. <5enk2j$c...@shell3.ba.best.com>:
> >
> > [RIM loader code saved and snipped]
> >
> >
> > The FM ENB switch enables Fast Memory, causing references to the
> > accumulators (locations 00 through 17) to go to RAM instead of core
> > memory. When FM ENB is off, the above bootstrap can be toggled into
> > locations 01 through 16. (Locations 00 and 17 need not be
> > initialized.)
> >
>
> In any event, this technique would only work on the KA-10. Later
> -10s used semiconductors exclusively, so there wasn't any way to save/
> load anything to the lowest of low core.
>
I don't think this is true. I will be very embarrased if I am wrong but
I believe that on the KL you could just PMAP another page to page 0 and
then any writes to location 0-17 in that page would go to the shadow ACs.
Maybe someonw with a KL running TOPS-20 can try this - I haven't written
code for a PDP-10 for 12 years so you might need to tweak this but you
will get the idea.
HRLZI T1,.FHSLF /* These 2 lines might be to
MOVE T2, [.FHSLF,,5000] /* the wrong ACs (source vs dest)
MOVX T3, PM%RD+PM%WR
PMAP% /* map page 0 to page 5
Now any references to 5000-5017 will end up in the shadow ACs but will NOT
appear in the ACs and refs to 5020-5777 will be visible in page 0.
So in DDT do
5000/ 1234
0/ should show [.fhslf,,0] and not 1234
5020/ 1234
20/ should show 1234
> As an interesting sidelight, the KI-10 had four sets of AC (or FM,
> if you will) selectable by the operating system or by front panel
> switches (IIRC, in the same little panel that had the margining con-
> trols and ReadIn Device switches). Whether DEC ever made use of the
> added ACs, I'm not sure, but doing so would certainly have helped
> during context switches.
>
> --
Again Tops-20 made extensive use of a bunch of the AC blocks. For
instance I think APRSRV had it's own AC set.
-Tom
Mark & Suzanne
Carl R. Friend wrote:
>
> Smith and O'Halloran wrote in
> article Nr. <5enk2j$c...@shell3.ba.best.com>:
> >
> > [RIM loader code saved and snipped]
> >
stuff deleted
..
>
> In any event, this technique would only work on the KA-10. Later
> -10s used semiconductors exclusively, so there wasn't any way to save/
> load anything to the lowest of low core.
Later 10's still had core memories. Unless my memory is a little
fuzzy KL10's eg 2040 with MB20 core memory. However the readin stuff
went with the older systems that had real front pannels directly
controlling the PDP-10 CPU. KL and it's ilk had front end processors
PDP11/40 then later 8080 on the DECSYSTEM-2020.
>
> As an interesting sidelight, the KI-10 had four sets of AC (or FM,
> if you will) selectable by the operating system or by front panel
> switches (IIRC, in the same little panel that had the margining con-
> trols and ReadIn Device switches). Whether DEC ever made use of the
> added ACs, I'm not sure, but doing so would certainly have helped
> during context switches.
The monitr certainly did use the registers for special purposes
esp so that the monitr could work with out having to save user registers
Cheers
Mark :)
Pat Farrell
Mark & Suzanne <g...@s054.aone.net.au> wrote:
> Later 10's still had core memories. Unless my memory is a little
>fuzzy KL10's eg 2040 with MB20 core memory.
I know that AMS' first KL20 had core memory 256MW from when it was
installed ~9/77 until we sold it, still running in ~93. We had added
MOS memory until it had ~1.5MW, along with upgrades to at least a 2060
along the way. (we had six KLs, and most were 2065s, but I lose track
of which ones got the bigger cache, etc.)
Pat
Carl R. Friend
Mark & Suzanne wrote in article Nr. <331708...@s054.aone.net.au>:
>
> Carl R. Friend wrote:
> >
> > In any event, this technique would only work on the KA-10. Later
> > -10s used semiconductors exclusively, so there wasn't any way to save/
> > load anything to the lowest of low core.
>
> went with the older systems that had real front pannels directly
> controlling the PDP-10 CPU. KL and it's ilk had front end processors
> PDP11/40 then later 8080 on the DECSYSTEM-2020.
>
Oh, nuts. It looks like I'd better go back to studying the English
language. I didn't mean to imply that core memories went out with the
KI-10, just that the "FM" option became standard equipment and couldn't
be turned off yielding core-resident ACs.
I worked with plenty of core boxes on KIs and KLs in the early '80s.
I also remember my sense of awe when confronted with an ARM-10LS semi-
conductor memory box with ECC.
Doug Humphrey
> Oh, nuts. It looks like I'd better go back to studying the English
>language. I didn't mean to imply that core memories went out with the
>KI-10, just that the "FM" option became standard equipment and couldn't
>be turned off yielding core-resident ACs.
Yep - in the KA, the FM was able to turn on/off mainly because
there were KA machines out there which didn't have the FM option
(though, not too many of them) because back then this was damned
expensive stuff. In my first KA, the only Integrated Circuits in
the whole thing were the relocate and protect registers and the
Fast Memory units. B199 and B250 modules? That is from memory,
(no pun intended) so it might be wrong...
On KI and KL and KS, there was no "option" for this kind of thing,
thus no nifty switch, and no nifty hack of leaving the bootstrap
in the core and running with FMs. Also, no speed control knobs,
right? KA had them, KL did not, I don't *think* that the KI had
them, but I never *ran* or *owned* a KI, just used one briefly.
> I worked with plenty of core boxes on KIs and KLs in the early '80s.
>I also remember my sense of awe when confronted with an ARM-10LS semi-
>conductor memory box with ECC.
Damned expensive machines, they were...
Doug
Carl R. Friend
Doug Humphrey wrote in article Nr. <5ffgdt$n...@ss1.digex.net>:
>
> On KI and KL and KS, there was no "option" for this kind of thing [FM],
> thus no nifty switch, and no nifty hack of leaving the bootstrap
> in the core and running with FMs. Also, no speed control knobs,
> right? KA had them, KL did not, I don't *think* that the KI had
> them, but I never *ran* or *owned* a KI, just used one briefly.
The KI had speed control knobs, two of them to be exact: "coarse"
and "fine". They were used in conjunction with the "repeat" key on the
main panel, mostly for hardware troubleshooting and program debugging.
--
Doug Humphrey
Carl R. Friend <carl....@swec.com> wrote:
>
> The KI had speed control knobs, two of them to be exact: "coarse"
>and "fine". They were used in conjunction with the "repeat" key on the
>main panel, mostly for hardware troubleshooting and program debugging.
>
Great! They were a blast on the KA - of course, since nobody was
running "production" on my KA (it was in my apartment) then you could
adjust the speed control so that the lights were more "readable" and
teach people what they looked like when the machine was doing certain
things. Of course, it was kind of expensive for just visual effects,
but the electricity was included in the rent, so it didn't matter so
much ;-)
By the by, does anyone here know who I should contact at Compuserve
to talk about all of the 10's that they are discarding? I would like
to get a set (or two) of the efficient power supplies that cut the
power consumption on the KL based machines that they were running.
I understand that it cut usage by something like 70%.
Thanks,
Doug
Carl R. Friend
Doug Humphrey wrote:
>
> By the by, does anyone here know who I should contact at Compuserve
> to talk about all of the 10's that they are discarding? I would like
> to get a set (or two) of the efficient power supplies that cut the
> power consumption on the KL based machines that they were running.
> I understand that it cut usage by something like 70%.
It sounds like they went over to using switching supplies rather
than the analogue series-pass supplies the DEC supplied. On that
topic: Does anybody know _why_ DEC put those KL supplies sideways and
depended on forced-air cooling rather than placing them vertically
and using fan-assisted convection?
Of course, if anybody knows where I can score a KI-10 it goes
without saying that I'd be eternally grateful.
jmfb...@ma.ultranet.com
In article <331B7CDC...@swec.com>,
>>
>> By the by, does anyone here know who I should contact at Compuserve
>> to talk about all of the 10's that they are discarding? I would like
>> to get a set (or two) of the efficient power supplies that cut the
>> power consumption on the KL based machines that they were running.
>> I understand that it cut usage by something like 70%.
>
> It sounds like they went over to using switching supplies rather
>than the analogue series-pass supplies the DEC supplied. On that
>topic: Does anybody know _why_ DEC put those KL supplies sideways and
>depended on forced-air cooling rather than placing them vertically
>and using fan-assisted convection?
>
I don't know the design reason, but my conclusions for the design was 1) to
torment us (supported by the pain caused by taking the console lights away)
or 2) an expensive temperature gauge to tell one that the room was too hot.
[a tongue-in-cheek emoticon here]
/BAH
Aron K. Insinga
Related story (from memory, so caveat emptor): They were built in areas
of plants (ML, MR) which didn't have a raised floor with air
conditioning blown underneath, so they took clean air from above and
blew it down through the machine. If you did have such a raised floor,
there was an ECO to reverse the fans to suck cold air up through the
cabinets from underneath the floor. This also required turning the
backplane for some option upside down in its cabinet to prevent the hot
components that were carefully placed on one edge of the board from
heating up the rest of the board.
- Aron Insinga
Richard M. Alderson III
In article <5fft1m$p...@ss1.digex.net> do...@ss1.digex.net (Doug Humphrey)
writes:
>By the by, does anyone here know who I should contact at Compuserve to talk
>about all of the 10's that they are discarding?
They discarded all the DEC equipment quite some time ago, I believe, retiring
it in favour of Systems Concepts boxen. There's only one guy in the entire
company these days who knows anything at all about 36-bit computing; I imagine
he's nervous...
--
Rich Alderson You know the sort of thing that you can find in any dictionary
of a strange language, and which so excites the amateur philo-
logists, itching to derive one tongue from another that they
know better: a word that is nearly the same in form and meaning
as the corresponding word in English, or Latin, or Hebrew, or
what not.
--J. R. R. Tolkien,
alde...@netcom.com _The Notion Club Papers_
Bjorn Hell Larsen
In <ALDERSON.9...@netcom6.netcom.com>, alde...@netcom6.netcom.com
(Richard M. Alderson III) wrote:
> In article <5fft1m$p...@ss1.digex.net> do...@ss1.digex.net (Doug Humphrey)
> writes:
>
> >By the by, does anyone here know who I should contact at Compuserve to talk
> >about all of the 10's that they are discarding?
>
> They discarded all the DEC equipment quite some time ago, I believe, retiring
> it in favour of Systems Concepts boxen. There's only one guy in the entire
> company these days who knows anything at all about 36-bit computing; I imagine
> he's nervous...
Are you saying that the entire Compuserve infrastructure runs on SC boxes, and
they only have one guy there who knows how they work?
Bjorn
--
Bjorn Hell Larsen
http://home.sn.no/home/blarsen/
Carl R. Friend
Aron K. Insinga wrote in article Nr. <331C4B...@infomation.com>:
>
> Related story (from memory, so caveat emptor): They were built in areas
> of plants (ML, MR) which didn't have a raised floor with air
> conditioning blown underneath, so they took clean air from above and
> blew it down through the machine.
"Top-down" airflow was very common in DEC machines, the argument
being that some of these systems will be used in dirty environments
like factory floors. I know that the PDP-12 I just got through
resurrecting features top-down cooling, as did a couple of the -10s
that I worked on early on in my career (they got converted to bottom-
up cooling).
> If you did have such a raised floor, there was an ECO to reverse the
> fans to suck cold air up through the cabinets from underneath the floor.
> This also required turning the backplane for some option upside down
> in its cabinet to prevent the hot components that were carefully
> placed on one edge of the board from heating up the rest of the board.
The DK-10, maybe? Although I don't recall any of them getting too
warm...
Pat Farrell
bla...@nac.no (Bjorn Hell Larsen) wrote:
>> There's only one guy in the entire company these days who knows anything at all about 36-bit computing;
>they only have one guy there who knows how they work?
Dunno what the current state is, but about five years ago, Dave
Eastburn was still a VP of marketing at CI$. I worked with him on
the System 1022 Users group board in the mid-80s. He at least knew
what a KL was.
When I got my CI$ account, I pinged him. He said then that they had
mostly SC replacements, but were moving (had moved?) to lots of 486s
with a homegrown OS to handle the forums. I assume those are now
Pentiums.
Last time I looked, he was still on the masthead of their inhouse
advertising mag. But I haven't used CI$ in too long to remember.
Pat
Stephen Westin
In article <331E24F3...@swec.com> "Carl R. Friend" <carl....@swec.com> writes:
<snip>
> "Top-down" airflow was very common in DEC machines, the argument
> being that some of these systems will be used in dirty environments
> like factory floors. I know that the PDP-12 I just got through
> resurrecting features top-down cooling, as did a couple of the -10s
> that I worked on early on in my career (they got converted to bottom-
> up cooling).
<snip>
I've used a number of DEC machines with top-down cooling. I've also
used the Evans & Sutherland PS390, which originally had bottom-up
cooling. Within a few months, the filter on the bottom had clogged,
causing it to overheat. The workaround was to rip the filter out until
the field engineer could come out and flip the fans for top-down flow
so it would ingest less dust.
--
-Stephen H. Westin
swe...@ford.com
The information and opinions in this message are mine, not Ford's.
Smith and O'Halloran
I asked about the details of the genesis of the RIM10B loader.
Here's a responce from one of the authors.
-Joe
From: Bob Clements
To: in...@best.com
Subject: Re: RIM10B bootstrap loader for the PDP-10
Newsgroups: alt.folklore.computers,alt.sys.pdp10
In-Reply-To: <5enk2j$c...@shell3.ba.best.com>
References: <5ctbdp$cjd$1...@Zeke.Update.UU.SE> <33052C5D...@swec.com> <1997Feb20.1...@indyvax.iupui.edu> <5ekohr$b...@shell3.ba.best.com>
Hi, Joe,
As I said in a previous article about RUNOFF, I'm avoiding USENET postings
until I get a little spare time to fake my address to avoid email spam.
Feel free to post this if you omit my email address except in the
form I put on the last line.
>>The true magic of the PDP-10 instruction set was in the RIM-10B loader.
>>The program is 14 instructions long and uses 2 accumlators for data.
>>It reads in 36-bit words from an 8-bit paper tape reader, deposits the
>>data in memory, and verifies the checksums of the program it is loading.
Add "and can be restarted on a block boundary in case of a checksum
error", which was another requirement of the task.
>Somewhere I read the story of how it was created; a really bright hacker
>was tricked into creating it when his colleagues kept saying that it
>couldn't be done. Anyone have the details?
> -Joe
No trickery. Just the challenge of doing it.
I think I posted this some years ago. If anyone has an old copy they
can compare my current fading memory to the old version. Here's how I
remember it now.
This loader was written in an all-out brainstorming effort. It happened
at DEC, Maynard, building 5 rather than at TMRC or Project MAC where
other such fests happened.
Somehow the challenge came up of writing a paper tape loader that
would not require the use of any fixed memory locations. The idea was
that any program might be loaded in pieces, and you wouldn't want to
clobber any previous part with storage/code used by the loader. Also,
to take dumps of a dead program, we didn't want to clobber any core.
This should fit entirely in the ACs.
A few previous attempts had been done, but they all took somewhat more
than sixteen words. Finally, a bunch of serious bit bummers decided
to work on it and get it solved.
My memory may be wrong, but I think the group that worked on it
included Alan Kotok, Tom Eggers, Dave Gross and myself, and a couple
more whom I'm not so sure of. Maybe Peter Hurley? Maybe Tom Hastings?
Anyway, we came up with a LOT of ways of doing it in fifteen
instructions plus the two registers to hold the checksum and the
AOBJN pointer. Seventeen words in all. We considered using
location 40 for the 17th word, but that didn't feel fair.
Then, out of the blue, Dave Gross came in with this wonderful hack,
using two indexed XCT instructions, which was totally unlike anything
else we had tried. It used thirteen instructions plus the registers,
so it could fit in the ACs WITH the count word needed by the RIM
hardware! Register zero was actually a spare. Most other attempts
had used it for the checksum.
There was great rejoicing, and the quiet, reserved Dave Gross actually
looked quite pleased with himself.
Bob Clements, K1BC (w) +1 617 USE K1BC
Smith and O'Halloran
In article <5ffgdt$n...@ss1.digex.net>,
Doug Humphrey <do...@ss1.digex.net> wrote:
>Yep - in the KA, the FM was able to turn on/off mainly because
>there were KA machines out there which didn't have the FM option
>(though, not too many of them) because back then this was damned
>expensive stuff.
At the going-away party for Stanford's PDP-10s, someone had an old
catalog of 36-bit systems. It listed the 1010, 1020, 1030 and 1040
models. I asked about the KA's without FM and byte hardware, and he said
that although DEC had such items in the catalog, none were ever sold.
All customers opted for Fast Memory and byte-manipulation/floating-point
hardware.
I would like to know if there are any counterexamples; sites that admit
to purchasing a KA without FM and FP. (I do not believe there are any.)
I would also like to know there are any of these ancient catalogs still
around. I want to get them scanned and posted to my website.
-Joe
Joe Morris
swe...@dsg145.nad.ford.com (Stephen Westin ) writes:
> "Carl R. Friend" <carl....@swec.com> writes:
>> "Top-down" airflow was very common in DEC machines, the argument
>> being that some of these systems will be used in dirty environments
>> like factory floors. I know that the PDP-12 I just got through
>> resurrecting features top-down cooling, as did a couple of the -10s
>> that I worked on early on in my career (they got converted to bottom-
>> up cooling).
>I've used a number of DEC machines with top-down cooling. I've also
>used the Evans & Sutherland PS390, which originally had bottom-up
>cooling. Within a few months, the filter on the bottom had clogged,
>causing it to overheat. The workaround was to rip the filter out until
>the field engineer could come out and flip the fans for top-down flow
>so it would ingest less dust.
OTOH, at a PPOE we had a brand-new KL10 that ate circuit cards at
an alarming rate (all at DEC's expense) until the airflow was turned
around to use the air coming up from the raised flooring. DEC had
been made aware that (like most computer rooms of the time) we used
underfloor cooling exclusively, but still insisted on delivering
and installing the machine with top-down airflow.
DEC had some wonderful design concepts in the KL10, coupled with
hideous physical implementations. My biggest squawk about the
machine (I wasn't responsible for the KL10, but was involved
with the electrical power for the computer center) was that that
the machine was dumping ~15A of current down the ground wire, and
the DEC CE could not understand why I was upset. (The KL10 used
3-phase AC power; there was significant current in the *neutral*
line because the loads were badly unbalanced, but that's at
least within Code specs. Current in the *ground* wire isn't supposed
to be present.)
Joe Morris
Richard M. Alderson III
In article <3320d7e1...@news.sn.no> bla...@nac.no (Bjorn Hell Larsen)
writes:
>Are you saying that the entire Compuserve infrastructure runs on SC boxes, and
>they only have one guy there who knows how they work?
No, the CompuServe infrastructure is migrating to Windows NT servers, with no
further work being done on the SC boxes, and so their management made the
decision to let all those expensive 36-bit-familiar folks go.
Or perhaps that's "Yes, the ..."
Douglas W. Jones,201H MLH,3193350740,3193382879
In article <331E24F3...@swec.com> "Carl R. Friend"
<carl....@swec.com> writes:
> "Top-down" airflow was very common in DEC machines, the argument
> being that some of these systems will be used in dirty environments
> like factory floors. I know that the PDP-12 I just got through
> resurrecting features top-down cooling, as did a couple of the -10s
> that I worked on early on in my career (they got converted to bottom-
> up cooling).
Quote from DEC's Small Computer Handbook, 1973, page 8-11:
... in general, air enters standard cabinets through the top filter
and exits at the bottom ...
This applies to the standard DEC H960 "basic cabinet", a 6 foot 19" (EIA
standard mounting rails) relay rack with side skins, rear door and
fan/filter assembly built into the top. This cabinet was used for all
kinds of DEC computer systems of that era, from the 12 bit PDP-8 on up
into the 16-bit PDP-11, 18-bit PDP-15, and into the 36 bit world (although
I think the PDP-10 CPU used a custom wide cabinet, with rows of H960
cabinets for peripheral interfaces).
The earlier CAB-1 through CAB-8 series of DEC cabinets used prior to 1968
were built with a fan in the bottom. I don't know which way the air flowed
in these cabinets, but the original PDP-8, 1966, had bottom up flow with
the fans in the power supply assembly halfway up the cabinet and just
below the CPU.
Doug Jones
jo...@cs.uiowa.edu
Jimpy
I worked in manufactiring on the PDP-10. I can't remember if any machines
went to customer sites without the FM option on the KA10, but I do
remember that a few machines were shipped without the floating point
option.
Jimpy
Allen J. Baum
In article <5fng6c$i...@top.mitre.org>, jcmo...@mwunix.mitre.org (Joe
Morris) wrote:
> OTOH, at a PPOE we had a brand-new KL10 that ate circuit cards at
> an alarming rate (all at DEC's expense)
At HP they installed a KL10, and started testing it.
My manager put his hand on the cabinet & nearly burned himself.
He told the CE who said "Oh, it's ECL, it gets hot."
That was before they found out the fans weren't connected.
And either was the overtemp sensor.
We got new boards, too.
--
***********************************************
* Allen J. Baum ab...@pa.dec.com *
* Digital Semiconductor *
* 181 Lytton Ave. *
* Palo Alto, CA 94306 *
***********************************************
Robert Billing
In article <abaum-07039...@terrapin.pa.dec.com>
ab...@pa.dec.com "Allen J. Baum" writes:
> That was before they found out the fans weren't connected.
> And either was the overtemp sensor.
> We got new boards, too.
In the early days of the PDP11 they used to ship in the UK with the
110V fans wired in series pairs for 240V power. I remember one chap
parking a screwdriver through one fan, then powering up. The stalled
fan dropped almost no volts, while its mate made a most remarkable
noise.
--
I am Robert Billing, Christian, inventor, traveller, cook and animal
lover, I live near 0:46W 51:22N. "...you're the only thing in this
whole world that's pure & good & right, & wherever you are & wherever
you go there's always...some light." http://www.tnglwood.demon.co.uk/
Eric Smith
In article <3320C3...@s054.aone.net.au> Mark & Suzanne <g...@s054.aone.net.au> writes:
> I thought you could margin the clock on KL10 processors?
> or is this only possible in diagnostic modes? I thought I had been
> told once that people would margin the clock speed up and leave
> it there.
I don't have a KL10 maintenance manual (unfortunately), but from the prints
it looks like the clock margin is just the choice between two fixed
frequency crystals, rather than a variable adjustment knob like the earlier
machines had.
Cheers,
Eric
--
-----------------------------------------------------------------------------
Don't blame me, I voted Libertarian. http://www.lp.org/ (800) 682-1776
-----------------------------------------------------------------------------
jmfb...@ma.ultranet.com
In article <qhybbwu...@houhah.brouhaha.com>,
er...@brouhaha.com (Eric Smith) wrote:
>In article <3320C3...@s054.aone.net.au> Mark & Suzanne
<g...@s054.aone.net.au> writes:
>> I thought you could margin the clock on KL10 processors?
>> or is this only possible in diagnostic modes? I thought I had been
>> told once that people would margin the clock speed up and leave
>> it there.
>
>I don't have a KL10 maintenance manual (unfortunately), but from the
prints
>it looks like the clock margin is just the choice between two fixed
>frequency crystals, rather than a variable adjustment knob like the
earlier
>machines had.
>
Maintenance Handbook--apparently it was Dave Rockwell's). However, I need
an interpreter...I don't seem to understand a thing. I haven't been able
to find the word "clock" but then I've just done a cursory scan.
/BAH
Mark & Suzanne
jmfb...@ma.ultranet.com wrote:
> >
> I have Volume I of the KL10 Maintenacne Guide (I also have a KL10
> Maintenance Handbook--apparently it was Dave Rockwell's). However, I need
> an interpreter...I don't seem to understand a thing. I haven't been able
> to find the word "clock" but then I've just done a cursory scan.
page 16 headed DIAMON COMMANDS (Cont)
half way down the page "Y = CLOCK MARGINS". There maybe other ways
of turning this one, don't know.
Cheers
Mark :)
Aron K. Insinga
> In article <3320C3...@s054.aone.net.au> Mark & Suzanne <g...@s054.aone.net.au> writes:
> > I thought you could margin the clock on KL10 processors?
> > or is this only possible in diagnostic modes? I thought I had been
> > told once that people would margin the clock speed up and leave
> > it there.
I recall some zig-zag traces on KL10 PC boards that had jumpers soldered
across them in manufacturing, but that was probably to adjust the local
clock skew, not the global clock speed.
- Aron Insinga
Alan Greig
jmfb...@ma.ultranet.com wrote:
>
> In article <qhybbwu...@houhah.brouhaha.com>,
> >it looks like the clock margin is just the choice between two fixed
> >frequency crystals, rather than a variable adjustment knob like the
> earlier
> >machines had.
> >
> Maintenance Handbook--apparently it was Dave Rockwell's). However, I need
> an interpreter...I don't seem to understand a thing. I haven't been able
> to find the word "clock" but then I've just done a cursory scan.
From memory...
SET CLOCK MARGIN was the command and I think there was a SET MARGINS ALL
as well. I haven't typed either command since about 1981 so I could
be complete wrong!
--
Alan Greig Tel: (01382) 308802
University of Abertay Dundee Email: A.G...@tay.ac.uk
** Never underestimate the power of human stupidity **
jmfb...@ma.ultranet.com
In article <3327E90E...@tay.ac.uk>,
Alan Greig <A.G...@tay.ac.uk> wrote:
>jmfb...@ma.ultranet.com wrote:
>>
>> In article <qhybbwu...@houhah.brouhaha.com>,
>> >it looks like the clock margin is just the choice between two fixed
>> >frequency crystals, rather than a variable adjustment knob like the
>> earlier
>> >machines had.
>> >
>> I have Volume I of the KL10 Maintenacne Guide (I also have a KL10
>> Maintenance Handbook--apparently it was Dave Rockwell's). However, I
need
>> an interpreter...I don't seem to understand a thing. I haven't been
able
>> to find the word "clock" but then I've just done a cursory scan.
>
>From memory...
>
>SET CLOCK MARGIN was the command and I think there was a SET MARGINS ALL
>as well. I haven't typed either command since about 1981 so I could
>be complete wrong!
>
the heading "clock operations". One can set the clock source (options are
normal clock, speed margin clock, and external clock); the one can select
the clock rate (options are normal, divide by 2, divide by 4, and divide by
8). Whatever the hell that means.
Looking at this documentation has prodded guilt pangs. I never really
spent time ...hmmm..how did John put it?...oh, yea...standardizing stuff in
the diagnostics group. This stuff is almost unreadable w.r.t. print
quality. Ah, well...
/BAH
Henry W. Miller
Eric Smith wrote:
>
> In article <3320C3...@s054.aone.net.au> Mark & Suzanne <g...@s054.aone.net.au> writes:
> > I thought you could margin the clock on KL10 processors?
> > or is this only possible in diagnostic modes? I thought I had been
> > told once that people would margin the clock speed up and leave
> > it there.
>
> frequency crystals, rather than a variable adjustment knob like the earlier
> machines had.
>
> Eric
> --
> -----------------------------------------------------------------------------
> Don't blame me, I voted Libertarian. http://www.lp.org/ (800) 682-1776
> -----------------------------------------------------------------------------
I'm pretty sure that you could adjust the clock speed on the KL - I
remember helping Field Service do this once.
-HWM
John C Green Jr
jmfb...@ma.ultranet.com wrote:
>In article <5enk2j$c...@shell3.ba.best.com>,
> in...@shell3.ba.best.com (Smith and O'Halloran) wrote:
>>In article <5ekohr$b...@shell3.ba.best.com>,
>>Smith and O'Halloran <in...@shell3.ba.best.com> wrote:
>>>[RIM10B loader was magic]
>>
>>[listing with annotation]
>[A pleasure to read]
By the time the 1971 edition of "PDP-10 Reference Handbook"
was published there had been so many questions asked by
people using it as an example of good programming technique
that this comment was added in the margin:
This loader is written for min-
imum size and is quite com-
ples. Do not approach it as a
simple programming example.
- - -
Internet Marketing and Business Development
Website Development and Project Management
21483 Old Mine Rd (408)353-1870
Los Gatos CA 95030 JCG...@ix.netcom.com
Henry W. Miller
John C Green Jr wrote:
>
> jmfb...@ma.ultranet.com wrote:
>
> >In article <5enk2j$c...@shell3.ba.best.com>,
> > in...@shell3.ba.best.com (Smith and O'Halloran) wrote:
> >>In article <5ekohr$b...@shell3.ba.best.com>,
> >>Smith and O'Halloran <in...@shell3.ba.best.com> wrote:
> >>>[RIM10B loader was magic]
> >>
> >>[listing with annotation]
>
> >[A pleasure to read]
>
> By the time the 1971 edition of "PDP-10 Reference Handbook"
> was published there had been so many questions asked by
> people using it as an example of good programming technique
> that this comment was added in the margin:
> This loader is written for min-
> imum size and is quite com-
> ples. Do not approach it as a
> simple programming example.
John,
I was also particularly fond of the "Effective Address Calculation"
disclaimer that was often used in the hardware manuals. I wonder if the
person who wrote that had a background in law?
> - - -
> Internet Marketing and Business Development
> Website Development and Project Management
> 21483 Old Mine Rd (408)353-1870
> Los Gatos CA 95030 JCG...@ix.netcom.com
-HWM
Henry W. Miller
Mark H. Wood wrote:
>
> > In article <19970203141...@ladder01.news.aol.com>,
> > JMFBAH <jmf...@aol.com> wrote:
> >>You've been talking about a program called nroff. Since I was the first
> >>group leader of the RUNOFF group at DEC, would you mind enlightening me?
>
> Hey, kudos to you and all the RUNOFF group. I used it on various systems to
> write a modest pile of documentation and at least one term paper, and I credit
> that experience with my ability to make decent looking documents without having
> to corral and direct a hundred thousand fancy WYSIWYG gizmos. When I see what
> the next generation is composing, without the benefit of that experience, I
> don't know whether to laugh or cry.
> --
Mark,
When I see these youngsters who have never seen a punched card, or had
to fish a star wheel out of a chad box, well, that's not too bad. But
not being able to write nice tight compact code like we used to have to
do, well, that's a shame. Faster processors and cheap memory hide a
multitude of programming sins.
I bring up this story because it reenforces the point above. About 8-9
years ago, I was working on a programming project for a real-time
process controller. One of my co-workers was a bright young
scientist-programmer, fresh out of school. His idea of "reusable code"
was to grab a section of code out of the program, plop a copy somewhere
else in the code tree and change a couple of variables! I had to spend
about 30% of my time cleaning up after him. One afternoon, I had to
perform a major optimization of the code to get a lousy few KB so the
system could load. He had gotten spoiled in running with the relatively
large address space of a DEC-20 (See, I told you it was marginally
related) and could not make the transition to a smaller machine very
easily. At that time, a "Big" PC was a 25 Mhz 386 with 16M of memory.
Damned kids...
> Mark H. Wood, Lead Systems Programmer +1 317 274 0749 [@disclaimer@]
> MW...@INDYVAX.IUPUI.EDU Finger for more information.
> I am endeavoring to construct a mnemonic circuit using stone knives and
> bearskins. -- Spock
-HWM
jmfb...@ma.ultranet.com
In article <3337B1...@sacto.mp.usbr.gov>,
young thing fresh out of college. He was hired to maintain a couple of
CUSPs. About a year later, he let it be known that he deserved a raise and
a promotion such that he would be equivalent to JMF. When he finally left,
I took over some of his responsibilities. I received an SPR on a CUSP that
complained of a feature not being available anymore. I investigated the
problem, and, much to my horror, found that it was intentionally done by
this upstart. Since the CUSP in question was a very important piece in
the successful running of operations, I looked at the other edits he did.
They all had to be deleted, the old SPRs reopened, and the real bugs got
fixed. This person had no idea about the philosophy of timesharing.
And then there is the story about the developer who decided that the
double<CTRL>C intercept feature in UMOUNT was useless. He had never heard
of the philosophy "If it ain't broke, don't fix it" repeatedly taught by
JMF and TW.
/BAH - subtract twenty for e-mail
Henry W. Miller
I'm almost afraid to ask what he did with it...
> /BAH - subtract twenty for e-mail
-HWM
Henry W. Miller
Max ben-Aaron wrote:
>
> High their:
>
> In the late 60's & early 70's I worked for a company (Medidata, later
> Searle Medidata) which started life as a not-for-profit spin-off from
> Lincoln Lab. (as I have heard), called American Science Institute. The
> chief engineer, Ed Rawson was a friend of Dec's Olsen and he managed to
> get hold of the modules used for the prototype PDP-2 which never
> reached the market. ASI used them to build their own machine
> (designed, I believe, by Chuck Corderman) which they called "Casino"
> and was sometimes jocularly referred to as a PDP-2 1/2. Casino was
> noteworthy for having, very early in trhe game, graphics capabilities.
> It also had some special terminals which had labels that cannot be
> repeated on this (family) newsgroup.
>
> Mb-A
>
> =================================================================
Is there any publically available documentation about the PDP-2? I've
heard a little about it over the years, but no real details.
-HWM
Henry W. Miller
JMFBAH wrote:
>
> mw...@indyvax.iupui.edu (Mark H. Wood) wrote:
>
> >> In article <19970203141...@ladder01.news.aol.com>,
> <> JMFBAH <jmf...@aol.com> wrote:
> >>You've been talking about a program called nroff. Since I was the first
> >>group leader of the RUNOFF group at DEC, would you mind enlightening me?
>
> >Hey, kudos to you and all the RUNOFF group.
> Thank you. Maybe it's time to document more of the ways we used to work
> when Digital was DEC.
>
> As the programming staffs grew, the work load at Tape Prep grew. The jobs
> would come in, be assessed for length of time the job would take, and get
> put into a priority list. It got so complex that nobody (writers,
> reproducers, nor programmers) were getting their jobs done on time. So
> Tape Prep was reorganized into three groups: 1) the RUNOFF group which
> would handle all work that needed to be done in RUNOFF, 2) the
> quick-turnaround group which took in jobs that could be done in less than
> an hour or so, and 3) all the rest of the jobs.
>
> At that time, all documentation that was published and shipped by DEC was
> done on typewriters by a group of (about) 20 women. None of that stuff
> was on-line. A few exceptions were the -10 functional specs and (I think)
> the processor manual. After getting broken in, I decided that everything
> should start to be done on-line. I began a campaign to convince writers to
> type their stuff on-line; there were some who preferred to write on paper
> but not many. It took some convincing that a complete retyping of a
> chapter wasn't needed just because they added one text line; this was the
> case when the documents were done by typewriters.
>
I'm sure that we all have our favorite RUNOFF story. Mine was as
follows: I had to do an in-depth analysis of a customer's performance
problems. (Hey, what did they expect - they were running a KA-10) In
fact, I got "imported" to Colorado to do it. Much of it was data
collection
via WATCH. I was able to distill it down using some utilities that Reed
Powell had written. The problem was how to get it into a readable form
for the customer.
Solution: I modified the output routines to output the data with
RUNOFF commands interspersed. Then I ran the data through RUNOFF and
came out with page after pretty page of statistics. When printed on
a Diablo daisy wheel printer with the carbon ribbon, it really looked
sharp. This was (I'm pretty sure) before the time of laser printers,
but the Diablo output was very nice. (Until a sales being put his
leaking
pastrami sandwich on top of the stack of output. How I got revenge
is a story for another time...)
I still use RUNOFF to this day, to help create VMS documentation.
Truly a great piece of software. (If that's not enough, people watch
with
awe when I use TECO...)
> The RUNOFF group gradually transformed itself into a real typesetting
> group (long after I left). RUNOFF was not very good at manipulating text
> for publishing but it was very useful. For instance, double columns that
> were automatically left/right justified and space-filled were impossible
> to do, but we managed [smiling emoticon here]. I believe that the only
> job I ever turned down was submitted by a one of the five V.P.s (for the
> life of me I can't remember the name). My boss was insistent that I do
> the job for fear that the VP would get unhappy. I pointed out that he
> would be even more unhappy when we produced a sloppy job that took 20
> hours/month to do. What he really wanted was a VISICALC piece of
> software. This was in 1972; there was no such thing. I turned down the
> job, explaining to him that it was more efficient for someone with good
> secretarial skills to do the job since the software didn't exist.
>
See how rich you could have been if you had written that package?
> I was always sorry that all those women (of the typing pool) were
> eventually put out of a job but I was not sorry to finally get that
> documentation into bits. Interestingly enough, the person who made a
> transition to typing on-line from the pool was a woman who was considered
> to be backward; but she could type 120 w.p.m. When she was being trained
> to work on a computer, the decision was being made that she wouldn't be
> able to learn RUNOFF. The plan was that she would WYSIWYG the
> documentation into a file, and someone, like me, would insert RUNOFF
> commands to do the formatting. That was unacceptable and I insisted that
> she be taught RUNOFF commands, monitor-level commands and everything in
> between. She learned and she just loved it.
>
Gee, a secretary savant?
> /BAH
-HWM
jmfb...@ma.ultranet.com
In article <3338DF...@sacto.mp.usbr.gov>,
The way I worked was I would take a terminal, mount a pack, type ONE
<ctrl>C, do a bunch of type-ahead, go out to the machine room, mount the
pack, find another terminal, start another process. Before I get
implmentation suggestions, these tasks were not repetitive, just part of
doing the many varied tasks that I associate with being a den mother
[smiling emoticon here].
What this developer did was take out the pause that UMOUNT did. If you
typed
MOUNT BLKX<CR>
^C
DIR FOO<CR>
UMOUNT would trap the <CTRL>C until the pack was mounted. The edit done
was to immediately go to monitor mode whenever any <CTRL>C was typed. So I
couldn't type ahead, run into the machine room to mount the pack and have
my tasks (as TW would say) "start without me".