KL Console Commands
Daniel Seagraves
Anyone have a list of the KL10 Console Commands?
Screen captures would be useful too...
Daniel Seagraves | I'm an International Clandestine Arms Dealer!
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
What is this? See http://www.dcs.ex.ac.uk/~aba/rsa | 36 BITS 4EVER!
wal...@emc.com
In article <Pine.LNX.3.96.980928...@bony.umtec.com>,
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Eric Smith
> Anyone have a list of the KL10 Console Commands?
The KL10 doesn't have any console in the traditional sense of the work.
It has a PDP-11/40 front end processor which is used for microcode load,
bootstrap, diagnostics, etc. Once the system is running, the terminal
attached to the 11 acts as the CTY (console TTY) for the 10.
The 11 runs the RSX-20F operating system, which IIRC is a derivative of
RSX-11D. So in some sense the KL10 console commands are RSX-11
commands.
> Screen captures would be useful too...
If someone was actually still running a KL, and using a PC as the
console terminal (instead of the more commonly used DECwriter or CRT),
you might have a chance of getting screen captures. Then again, if
someone was still running a KL, they probably wouldn't want to reboot
it for that purpose.
jmfb...@aol.com
Eric Smith <eric-no-spam-...@brouhaha.com> wrote:
>Daniel Seagraves <ro...@bony.umtec.com> writes:
>> Anyone have a list of the KL10 Console Commands?
>> Screen captures would be useful too...
>
>If someone was actually still running a KL, and using a PC as the
>console terminal (instead of the more commonly used DECwriter or CRT),
>you might have a chance of getting screen captures. Then again, if
>someone was still running a KL, they probably wouldn't want to reboot
>it for that purpose.
We laboriously reproduced actual "screen captures" in the documentation.
Don't you have a set of Notebooks? Look at any of the MIGs
and at the -20F doc.
One of the things that I did want to accomplish is to get
the sources of all the docs on tape and ship it to the world.
Unfortunately, the best laid plans of men and women..... :-(.
/BAH
Sigh! - Subtract a hundred and four for e-mail.
Daniel Seagraves
> We laboriously reproduced actual "screen captures" in the documentation.
> Don't you have a set of Notebooks? Look at any of the MIGs
> and at the -20F doc.
I wish. All I have is the Processor Refrence Manual from 36bit.org, and
some old KA10-era stuff.
Aron K. Insinga
> The 11 runs the RSX-20F operating system, which IIRC is a derivative of
> RSX-11D.
Or KLDCP (KL Diagnostic Console Program?) when running diagnostics.
- Aron Insinga
Smith and O'Halloran
Go to Volume 14 of the DECsystem-10 Manual Set.
Look at the "TOPS-10/TOPS-20 RXS-20F System Reference Manual" (part number
AA-BS94A-TK). Go to Chapter 4, "PARSER". You will see 14 commands listed
for OPERATOR mode and 22 commands for PROGRAMMER mode.
-Joe
--
INWAP.COM is Joe and Sally Smith, John and Chris O'Halloran and our cats
See http://www.inwap.com/ for PDP-10, "ReBoot", "Shadow Raiders"/"War Planets"
Philip Gagner
>Daniel Seagraves <ro...@bony.umtec.com> writes:
>> Anyone have a list of the KL10 Console Commands?
>
>The KL10 doesn't have any console in the traditional sense of the work.
>It has a PDP-11/40 front end processor which is used for microcode load,
>bootstrap, diagnostics, etc. Once the system is running, the terminal
>attached to the 11 acts as the CTY (console TTY) for the 10.
>
>The 11 runs the RSX-20F operating system, which IIRC is a derivative of
>RSX-11D. So in some sense the KL10 console commands are RSX-11
>commands.
Um, not really. RSX-20F was derived by "Bugsy" and the group from
RSX-11D, as you say, with various drivers and other things from
RSX-11M. People wanted to use RSX-11D because of its real time
features, but the system calls of RSX-11M were much nicer, so we threw
them in. But the command parser (cleverly named PARSER), was written
from scratch and has no relation with RSX-11D or RSX-11M commands.
This is something the RSX-11D group can be proud of.
I know this to be true because Rollo Belanger and I wrote most of the
KL-10 RSX-20F PARSER. It was generally a pretty bad job, in part
because the "language grammar" was a compromise designed by a
committee and kept changing and in part because Field Service had a
lot of input into the console command language, and they had very
fixed ideas about what it should be like, which weren't driven by any
aesthetic sense, and any talk about language "design" or theory was
quickly shot down. Marketing and management wanted to do whatever FS
wanted, so long as the thing could be booted, they really didn't care
what the console command langauge looked like. This, in my view at the
time and in my view now, was an unfortunate mistake.
Anyway, the command language ended up being pretty much a hack. There
were some nice features (the way repeats worked always amused me--you
could nest them and variables would be saved in a way that would alow
recursive functions), but not very many. The PARSER program was not,
in other words, derived in any way from the RSX command parser, and it
really didn't have much in common with it (I vaguely recall that we
copied how the file directory command output looked for PDP-11
devices, and it could parse input in a way that could theoretically
make MACRO-11 happy but it never did). The thing was compiled using a
program MACY11 or MACDLX or some such name, which was a cross-compiler
which ran on the -10, and then loaded onto a floppy or DECTAPE which
booted the RSX20F system and the PARSER was in the joblist when it
booted. The typical RSX-11D command parser simply wouldn't run on
RSX20-F, as far as I know.
>
>> Screen captures would be useful too...
>
jmfb...@aol.com
And wasn't there some funny stuff that had to be done since the -11
side of the file system wasn't 16-bit?
One of the projects that I had on my to-do list was to mechanize
the build procedures for RSX20-F. That never got done. When the
last developer left DEC, all the build information was lost. When
I pointed this out (I wanted Mike to train me to do a build before
he left) to the management, the thinking was that we could always
get Roland to show us just like he did when Mike was hired.
Why is this guy even thinking of trying to simulate the -20F
side of the KL? It was a pain in the ass concept (sorry, Phil,
I'm talking with a TOPS-10 monitor developement hat now :-))
and one of the things the guys would have dearly loved to
trade for lights.
Mark & Suzanne (gcs might work)
>
> And wasn't there some funny stuff that had to be done since the -11
> side of the file system wasn't 16-bit?
You mean it WAS 16bits. The boot RP04/6 was dual ported one to the RH20
in the KL and the other to the RH10 on the PDP-11. The 11 had track 0
formated in 16bit mode and so the drive spoke to the 11 it 16 bit words
and when the PDP-10 final got its brain loaded it spoke to the drive
in 18bit mode for the rest of the disk. You could get the PDP-11 to
serv its 16bit mode filesystem back to the 10 via one of the DTE
protocols.
Cheers
mark :)
jmfb...@aol.com
I don't think I ever understood DTE protocols. I know that the
-11 was 16-bit. But the cables that went to our disks (the dual
ports) were 18-bit...were they not? And retrieving data from
the disk from the -11 side took some munging. I do know that
the -10 side of that dual ported disk would not have been content
with only 16 bits of data on a fetch.
But, then on the other hand, hardware was never my strength; I
left that part of the business to the guys to finger out :-).
Daniel Seagraves
> Why is this guy even thinking of trying to simulate the -20F
> side of the KL?
What? I'm not - I'm just going to (try to) make the console commands the
same. That would be nuts!
(Besides, I have an X-windows book, I'm thinking of once this is
reasonably working making an X console with lights and switches, like that
PDP-8 sim. Should I use the KA or KI panel?)
Alan H. Martin
>The only time the 10 every munged data was when it had to deal with rather
>odd things call 9 track tapes. ...
Not quite. Transmitting data in 8-bit bytes for DECnet was done in software,
because I can recall someone trying to speed things up in some pack/unpack
algorithm.
>... 8bit+parity, it had to convert this. Two forms basically existed ... and
>then some strange packing algorithm that you will find documented on the web
>for stuffing 36 bit words efficently on tape. This was all accomplished by a
>piece of hardware in tape controller which I think was a M8914 board aka bit
>fiddler ...
Huh.
Yep, here it is:
M8914:
TM02 18-BIT FIDDLER,HEX (BFLR 1)
BFLR1 is just a joke, not a real 2-5-4-2 code.
/AHM
--
Alan Howard Martin AMa...@ZKo.DEC.Com
John Wilson
>In article <36136C...@s054.aone.net.au>,
> "Mark & Suzanne (gcs might work)" <SPAMO...@s054.aone.net.au> wrote:
>>The 11 had track 0
>>formated in 16bit mode and so the drive spoke to the 11 it 16 bit words
>>and when the PDP-10 final got its brain loaded it spoke to the drive
>>in 18bit mode for the rest of the disk.
Yuck!!! Why? Just because the 11 drivers depend on 22 sector mode, or is
there some reason I'm missing why you can't access the low 16 bits of each
data word from the 11? I would think it would just drop the high 2 bits of
each word (on the 18-bit "data" half of the Massbus) when reading and let
them float to zero when writing, or at worst it would read/write scrambled
data (if I remember right even the A/B versions of the RH11 had all 18 bits,
I think the M7294 mods in the RH11C are for something else).
>I don't think I ever understood DTE protocols. I know that the
>-11 was 16-bit. But the cables that went to our disks (the dual
>ports) were 18-bit...were they not? And retrieving data from
>the disk from the -11 side took some munging. I do know that
>the -10 side of that dual ported disk would not have been content
>with only 16 bits of data on a fetch.
The cables are indeed 18 bits wide for the data half, 16 for the control
half so everybody should be happy.
John Wilson
D Bit
Mark & Suzanne (gcs might work)
>
> In article <36136C...@s054.aone.net.au>,
> "Mark & Suzanne (gcs might work)" <SPAMO...@s054.aone.net.au> wrote:
> >>
> >
> >> And wasn't there some funny stuff that had to be done since the -11
> >> side of the file system wasn't 16-bit?
> >
> >You mean it WAS 16bits. The boot RP04/6 was dual ported one to the RH20
> >formated in 16bit mode and so the drive spoke to the 11 it 16 bit words
> >and when the PDP-10 final got its brain loaded it spoke to the drive
> >serv its 16bit mode filesystem back to the 10 via one of the DTE
> >protocols.
>
with interupts and IO basically DMA from 11-mem to DTE to 10-mem
or 10-mem to DTE to 11-mem the protocol(s) where schemes (protocols)
developed to drive certian types of communications between
TOPs and the various devices on the PDP-11 most basically the console
then various other serial devices and don't forget the line printer
which had its own protocol.
> -11 was 16-bit. But the cables that went to our disks (the dual
> ports) were 18-bit...were they not? And retrieving data from
> the disk from the -11 side took some munging. I do know that
There was no munging the port to the 11 was clocked to read a 16 bit
word from the serial data stream that came from the disk head
and the 10 port was clocked to read 18 bits into the register
The only time the 10 every munged data was when it had to deal with
rather odd things call 9 track tapes. It had no problem with the older
7 bit drives where it could just stuff sixbit+parity onto the tape
but 8bit+parity, it had to convert this. Two forms basically existed
one which was really wastefull of tape which I think was core dump
format (?) which was used by very simple boot programs and
then some strange packing algorithm that you will find documented on
the web for stuffing 36 bit words efficently on tape. This was all
accomplished by a piece of hardware in tape controller which I think was
a M8914 board aka bit fiddler ...
> the -10 side of that dual ported disk would not have been content
> with only 16 bits of data on a fetch.
It got just what it wanted 18 bit words
>
> But, then on the other hand, hardware was never my strength; I
> left that part of the business to the guys to finger out :-).
If thats a typo I'm not sure, "finger" out that could have all sorts
of conitations (sp?)
Cheers
Mark :)
Philip Gagner
<snip>
>>wanted, so long as the thing could be booted, they really didn't care
>>what the console command langauge looked like. This, in my view at the
>>time and in my view now, was an unfortunate mistake.
>>
<snip>
>>which ran on the -10, and then loaded onto a floppy or DECTAPE which
>>booted the RSX20F system and the PARSER was in the joblist when it
>>booted. The typical RSX-11D command parser simply wouldn't run on
>>RSX20-F, as far as I know.
>
>And wasn't there some funny stuff that had to be done since the -11
>side of the file system wasn't 16-bit?
Oh yes. I tried to repress the memory of this... it was an awful hack.
Well, it was sort of 16-bit, that is, RSX20F could read files stored
on the PDP-10 side, although it never worked well, through a routine
which mapped headers and such, mediated by the DTE-20. 18 bits were
tranmitted, and the 2 high order bits (as I recall) were discarded.
But the basic file system used for floppies (8") and DECTapes was
RSX-11 format, so it was sort of 16 bit too. Data intended for the -10
were packed as PDP-10 halfwords, so you lost even more space, but this
never mattered. And there was a special format for microcode loads,
but I don't think we ever finished implementing this. At least it
wasn't done when I left the project.
>
>One of the projects that I had on my to-do list was to mechanize
>the build procedures for RSX20-F. That never got done. When the
>last developer left DEC, all the build information was lost. When
>I pointed this out (I wanted Mike to train me to do a build before
>he left) to the management, the thinking was that we could always
>get Roland to show us just like he did when Mike was hired.
Build procedure?? I never saw anyting like that, fer sure. Stuff was
complied using MACY11 and written to DECtape, and then loaded and then
dumped onto floppies (for floppy based machines). Nothing automated
about it. Since MACY11 (or MACDLX sometimes) didn't know enough to
write tape or floppy media, I'd think you'd need to machanize it on an
RSX-11D system. Never occurred to us to try...
>
>Why is this guy even thinking of trying to simulate the -20F
>side of the KL? It was a pain in the ass concept (sorry, Phil,
>I'm talking with a TOPS-10 monitor developement hat now :-))
>and one of the things the guys would have dearly loved to
>trade for lights.
>
Oh, no need for apologies. We thought it was an awful hack at the
time, and it proved to be so. Purity of concept certainly got short
shrift. We actually put the lights in, you know. There were RSX20F
commands which would display "lights" on the terminal. I was a big fan
of the KA10 lights, which told you everything you ever wanted to know,
so we put them in in the hope that someday someone would realize that
a display terminal would make a better console than the LA30 (hard
copy dot matrix) printers that FS and marketing wanted. You could even
make a repeat macro that would update the "lights" as the machine ran.
The problem here was that the DTE-20 would suck up interrupts at a
ferocious rate when you did this, so the whole machine would run a
little slower. But we figured that someday someone would want the
feature.
I can't think of ANY reason to simulate the horrible RSX20F interface,
except maybe an exercise in masochism that exceeds all normal bounds
and shouldn't be discussed in polite company. Certainly a front-end
console "simulator" would be necessary, but given the limited number
of things the DTE-20 could do from the -10 side, it would be better to
have a clean interface and ignore the rest. If you're building a
simulator, boot the sucker from simulated ROM and trap all DTE-20
calls with a return of success and throw them away. You won't lose
anything worth keeping.
RSX20F -- Not DEC's finest hour...
Phil Gagner
Mark & Suzanne (gcs might work)
>
> I can't think of ANY reason to simulate the horrible RSX20F interface,
> except maybe an exercise in masochism that exceeds all normal bounds
> and shouldn't be discussed in polite company. Certainly a front-end
> console "simulator" would be necessary, but given the limited number
> of things the DTE-20 could do from the -10 side, it would be better to
> have a clean interface and ignore the rest. If you're building a
> simulator, boot the sucker from simulated ROM and trap all DTE-20
> calls with a return of success and throw them away. You won't lose
> anything worth keeping.
>
Certianly from an interface perspective, its not total necessary to
emulate the FE interface but you have to have something so why not
make it similar and just drop the unecessay stuff. If you ever intend
to boot from standard tape images (eg. install tapes) and run with
and unmodified DEC OS then you have to emulate a largish amount of
FE behaviour certainly null returns won't cut it, and since there
is no direct code call that goes from 11-10 10-11. You have to set
up to emulate the DTE protocols for at least console function. At
no time would you try and emulate PDP-11 instructions to get the
FE behaviour so you don't have to adopt quite the degree of crud that
you see makes up the RSX environment.
Mark :)
jmfb...@aol.com
"Mark & Suzanne (gcs might work)" <SPAMO...@s054.aone.net.au> wrote:
>jmfb...@aol.com wrote:
>>
>> In article <36136C...@s054.aone.net.au>,
>> "Mark & Suzanne (gcs might work)" <SPAMO...@s054.aone.net.au>
wrote:
>> But, then on the other hand, hardware was never my strength; I
>> left that part of the business to the guys to finger out :-).
>
>If thats a typo I'm not sure, "finger" out that could have all sorts
>of conitations (sp?)
The spelling was on purpose. The phrase is a TWism and, yes, it
did have all those connotations :-).
jmfb...@aol.com
>> side of the KL?
>
>same. That would be nuts!
I agree. The only reason to simulate anything on the -20F side
is if the hardware you are running the simulator on is serving
the same function that the -11 was supposed to. You were talking
about not having a lot of time. I'm just wondering why you're
addressing the console commands at all. They were shit. Even
field service hated it.
Maybe somebody can talk about the pie in the sky that -20F was
supposed to make. The only thing worse, IMO, that we produced
was the MCB.
jmfb...@aol.com
gag...@clark.net (Philip Gagner) wrote:
>jmfb...@aol.com wrote:
>
><snip>
>>>wanted, so long as the thing could be booted, they really didn't care
>>>what the console command langauge looked like. This, in my view at the
>>>time and in my view now, was an unfortunate mistake.
>>>
><snip>
>>>which ran on the -10, and then loaded onto a floppy or DECTAPE which
>>>booted the RSX20F system and the PARSER was in the joblist when it
>>>booted. The typical RSX-11D command parser simply wouldn't run on
>>>RSX20-F, as far as I know.
>>
>>And wasn't there some funny stuff that had to be done since the -11
>>side of the file system wasn't 16-bit?
>Oh yes. I tried to repress the memory of this... it was an awful hack.
Sorry :-) but sometimes children need to know the whole truth :-).
>Well, it was sort of 16-bit, that is, RSX20F could read files stored
>on the PDP-10 side, although it never worked well, through a routine
>which mapped headers and such, mediated by the DTE-20. 18 bits were
>tranmitted, and the 2 high order bits (as I recall) were discarded.
>But the basic file system used for floppies (8") and DECTapes was
>RSX-11 format, so it was sort of 16 bit too. Data intended for the -10
>were packed as PDP-10 halfwords, so you lost even more space, but this
>never mattered. And there was a special format for microcode loads,
>but I don't think we ever finished implementing this. At least it
>wasn't done when I left the project.
Well, let's talk about the data that had to be exchanged. At a
system startup, the date and time had to be given to the -10.
The file spec had to be transferred. The TTY had to look like
a -10 terminal. I still don't know how you kept it all separate.
And the -10 had to keep telling the -11 that it was still running
(remember all those KAFs?).
>>
>>One of the projects that I had on my to-do list was to mechanize
>>the build procedures for RSX20-F. That never got done. When the
>>last developer left DEC, all the build information was lost. When
>>I pointed this out (I wanted Mike to train me to do a build before
>>he left) to the management, the thinking was that we could always
>>get Roland to show us just like he did when Mike was hired.
>
>Build procedure?? I never saw anyting like that, fer sure. ...
Yea, I know. There never was one [wry emoticon here].
> ... Stuff was
>complied using MACY11 and written to DECtape, and then loaded and then
>dumped onto floppies (for floppy based machines). Nothing automated
>about it. Since MACY11 (or MACDLX sometimes) didn't know enough to
>write tape or floppy media, I'd think you'd need to machanize it on an
>RSX-11D system. Never occurred to us to try...
That mechanization was one of my rules of shipping software. The
build of -20F had to be done on that PDP11/70. Source control
was a figment of the current developer's imagination with no pointers
to the latest edit. Developers were terribly difficult critters
when it came to source control. That's why we had such elaborate
procedures for the TOPS-10 monitor edits, build, and ships.
See, if we could build a piece of software from the ground up,
then we were guaranteed that the field image sources were still
around. Losing sources was a very, very real danger. We had
customers whose major gazillion dollar applications broke because
of our software updates and couldn't fix anything because the
sources were just gone; the software worked so well bug fixes
were non-existant. We had a lot of those lonely pieces of
software. And -20F was one of the biggest.
Oh, I could tell stories about these critters and their quirks :-).
>>
>>Why is this guy even thinking of trying to simulate the -20F
>>side of the KL? It was a pain in the ass concept (sorry, Phil,
>>I'm talking with a TOPS-10 monitor developement hat now :-))
>>and one of the things the guys would have dearly loved to
>>trade for lights.
>>
>Oh, no need for apologies. We thought it was an awful hack at the
>time, and it proved to be so. Purity of concept certainly got short
>shrift. We actually put the lights in, you know. There were RSX20F
>commands which would display "lights" on the terminal. I was a big fan
>of the KA10 lights, which told you everything you ever wanted to know,
>so we put them in in the hope that someday someone would realize that
>a display terminal would make a better console than the LA30 (hard
>copy dot matrix) printers that FS and marketing wanted. You could even
>make a repeat macro that would update the "lights" as the machine ran.
>The problem here was that the DTE-20 would suck up interrupts at a
>ferocious rate when you did this, so the whole machine would run a
>little slower. But we figured that someday someone would want the
>feature.
I don't think I ever knew about the light simulator. It certainly
was true that a major hassle happened because TW insisted that
the front end terminal be attached to a VT06 when he was debugging.
And when TW threatened strike, people provided the resources he
needed.
>
>I can't think of ANY reason to simulate the horrible RSX20F interface,
>except maybe an exercise in masochism that exceeds all normal bounds
>and shouldn't be discussed in polite company. Certainly a front-end
>console "simulator" would be necessary, but given the limited number
>of things the DTE-20 could do from the -10 side, it would be better to
>have a clean interface and ignore the rest. If you're building a
>simulator, boot the sucker from simulated ROM and trap all DTE-20
>calls with a return of success and throw them away. You won't lose
>anything worth keeping.
Well, now I guess I'm confused. I thought the point of an emulator
was to be able to use this hardware that I have on my desk and have
it run TOPS-10 programs. That way the executables
that we shipped on tape could be run asis on this Intel system.
>
>RSX20F -- Not DEC's finest hour...
Well, cheer up. The MCB was worse :-).
Daniel Seagraves
>
> I agree. The only reason to simulate anything on the -20F side
> is if the hardware you are running the simulator on is serving
> the same function that the -11 was supposed to. You were talking
> about not having a lot of time. I'm just wondering why you're
> addressing the console commands at all. They were shit. Even
> field service hated it.
Didn't know that. Either way, this is low on the priority stack - First
I'm going to make it boot something, then I'll work on the UI and
suchlike. Make it work, then make it pretty.
jmfb...@aol.com
wil...@dbit.com (John Wilson) wrote:
>In article <6uvr49$5tq$1...@strato.ultra.net>, <jmfb...@aol.com> wrote:
>>In article <36136C...@s054.aone.net.au>,
>> "Mark & Suzanne (gcs might work)" <SPAMO...@s054.aone.net.au> wrote:
>>>formated in 16bit mode and so the drive spoke to the 11 it 16 bit words
>>>and when the PDP-10 final got its brain loaded it spoke to the drive
>>>in 18bit mode for the rest of the disk.
>
>there some reason I'm missing why you can't access the low 16 bits of each
>data word from the 11? I would think it would just drop the high 2 bits
of
>each word (on the 18-bit "data" half of the Massbus) when reading and let
>them float to zero when writing, or at worst it would read/write scrambled
>data (if I remember right even the A/B versions of the RH11 had all 18
bits,
>I think the M7294 mods in the RH11C are for something else).
The problem was the insistence of whomever that the two processors
share the same disk. Some damn fool notion of saving money for
the customers, I guess. So from the -10s point of view, the
PDP-11's file system was just a file called ...shit, now I forgot..
foo.SYS or something. That was so TOPS-10 would never write to those
blocks unless some real fool really wanted to mess about (and then
he deserved everything he got :-)).
Part of the mess (or maybe even all of it) of -20F was that both
RSX20F and TOPS-10 had to use the same disk pack.
Philip Gagner
<snip>
>
>Maybe somebody can talk about the pie in the sky that -20F was
>supposed to make. The only thing worse, IMO, that we produced
>was the MCB.
>
>/BAH
I don't think that RSX20F was ever supposed to be pie in the sky. The
KL was a microcode machine, so that running diagnostics was going to
be a problem. If the microcode hardware was flaky, then the machine
would be a useless piece of iron (i.e. diagnostics wouldn't run). So
the logical decision was to have a front end which had feelers into
the hardware (via the DTE-20) and could load data, single clock the
hardware, and thus do diagnostics. It was actually a very logical way
of doing things. You had a simple known reliable machine (PDP-11/40
initially) which could run the complex diagnostics required to get the
complex hardware to a state where it could run its own diagnostics.
Once you've decided to do this lights and switches don't seem that
important, so the cost (which including maintenance is extremely high)
can't be justified.
Nobody in the KL group really cared that much about what the FE ran.
DAS (Digital Advanced Systems) wanted it to run DN8x type software so
that it would be a built-in network controller. Management wanted it
to run vanilla RSX-11 software so that they wouldn't have to spend any
money writing new software. Management won. SInce nobody wanted to put
much money into the beast, there wasn't much memory available. The
DTE-20 was viewed as a "real time" device, so RSX11D seemed like a
good starting point. So hundreds of thousands of dollars were spent
trying to shoehorn RSX11D into working with the DTE and with the
dual-ported disk drives, and more hundreds of thousands of dollars
were spent trying to write diagnostics that wouldn't crash RSX11D. On
top of all this, the -10 group was undergoing the birthing of "clean"
code, so that there were coding standards that people were supposed to
follow, but the -11 group had different standards. Finally, the -11
system programmer types kept changing the system calls (each for good
reasons and each time to make them better) so that the documentation
never matched the actual RSX20F system being used, and old code broke
all the time.
In the middle of this, we were trying to write the PARSER, which got
pretty short shrift. LCG FS (who later came to hate it) had VERY
definite ideas about how they wanted it done (among other things they
wanted it to look more like TOPS-20).
We had this idea in the back of our minds that eventually the whole
blasted thing would be replaced by a network front end anyway, which
of course never happened. So if there was a pie in the sky, that would
have been it. I still think the DN8x software would have worked
better.
Smith and O'Halloran
>The problem was the insistence of whomever that the two processors
>share the same disk. Some damn fool notion of saving money for
>the customers, I guess. So from the -10s point of view, the
>PDP-11's file system was just a file called ...shit, now I forgot..
>foo.SYS or something. That was so TOPS-10 would never write to those
>blocks unless some real fool really wanted to mess about (and then
>he deserved everything he got :-)).
FEFILE.SYS = Front-End Filesystem. There was a separate program
(MAKEFE or MKFE) that created the file in contiguous clusters.
(The original poster who said the first track of the RP06 was formatted
in 16-bit mode is wrong. The PDP-11 was capable of reading the PDP-10's
HOM blocks, locating it's entry, and reading 16-bit data from inside
36-bit by 128 word blocks.)
Smith and O'Halloran
Philip Gagner <gag...@clark.net> wrote:
>and shouldn't be discussed in polite company. Certainly a front-end
>console "simulator" would be necessary, but given the limited number
>of things the DTE-20 could do from the -10 side, it would be better to
>have a clean interface and ignore the rest. If you're building a
>simulator, boot the sucker from simulated ROM and trap all DTE-20
>calls with a return of success and throw them away. You won't lose
>anything worth keeping.
Just about every peripheral that was not a disk, tape or network was on the
console front-end. Lineprinter. Card Reader and Card Punch. Hardwired
TTYs. (Excluding, for the moment, devices connected to a KA-compatible
I/O bus, such as the BA10 lineprinter and Calcomp plotter interface.)
Megan
>a -10 terminal. I still don't know how you kept it all separate.
>And the -10 had to keep telling the -11 that it was still running
>(remember all those KAFs?).
Sure do... if I remember correctly, the -11 kept depositing a count
into (location 30? of) the -10, and the -10 kept decrementing it. If
it ever got to zero, it knew the -11 was dead, and if I remember
correctly would try to boot it. At the same time, the -10 kept
depositing a value in the -11 memory, which it decremented. If that
count got to zero, the -11 knew the -10 was dead and would reboot
it...
I was an operator on one of the KLs at Digital's Parker Street
facility (in 1977), and the KL I worked on had a bad 10<->11
connection, so the -11 regularly lost communication with the -10
(someone had set something so the system ignored the keepalive).
Well, I was using RT-11 back then (before I became a developer
of it) and often would boot RT off one of the DECtapes of the
11/40 'frontend' while the 'backend' kept happily running
TOPS-10...
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
jmfb...@aol.com
gag...@clark.net (Philip Gagner) wrote:
>jmfb...@aol.com wrote:
>
><snip>
>>
>>Maybe somebody can talk about the pie in the sky that -20F was
>>supposed to make. The only thing worse, IMO, that we produced
>>was the MCB.
>>
>>/BAH
>
>I don't think that RSX20F was ever supposed to be pie in the sky. The
>KL was a microcode machine, so that running diagnostics was going to
>be a problem.
Ah, I forgot about that. :-) I think the "pie in the sky" thing
came from a conversation trying to convince TW that the KL was
a good thing. He didn't debug on the thing for a long time. If
he could, he always worked on the KI or the KA.
>If the microcode hardware was flaky, then the machine
>would be a useless piece of iron (i.e. diagnostics wouldn't run). So
>the logical decision was to have a front end which had feelers into
>the hardware (via the DTE-20) and could load data, single clock the
>hardware, and thus do diagnostics. It was actually a very logical way
>of doing things. You had a simple known reliable machine (PDP-11/40
>initially) which could run the complex diagnostics required to get the
>complex hardware to a state where it could run its own diagnostics.
>
>Once you've decided to do this lights and switches don't seem that
>important, so the cost (which including maintenance is extremely high)
>can't be justified.
Nobody asked TW or JMF. I think TW was the most traumatized by
the lights.
>
>Nobody in the KL group really cared that much about what the FE ran.
>DAS (Digital Advanced Systems) wanted it to run DN8x type software so
>that it would be a built-in network controller. Management wanted it
>to run vanilla RSX-11 software so that they wouldn't have to spend any
>money writing new software. Management won. ....
What management? I knew there were nuts by then but I never
did have a good feel for the hardware side of the business.
My impression (whenever I dealt with them) is that they were
still in the Dark Ages when hardware didn't need an OS.
I suppose I'm going russle a few hares here :-).
> ... SInce nobody wanted to put
>much money into the beast, there wasn't much memory available. The
>DTE-20 was viewed as a "real time" device, so RSX11D seemed like a
>good starting point. So hundreds of thousands of dollars were spent
>trying to shoehorn RSX11D into working with the DTE and with the
>dual-ported disk drives, and more hundreds of thousands of dollars
>were spent trying to write diagnostics that wouldn't crash RSX11D. On
>top of all this, the -10 group was undergoing the birthing of "clean"
>code, so that there were coding standards that people were supposed to
>follow, but the -11 group had different standards. Finally, the -11
>system programmer types kept changing the system calls (each for good
>reasons and each time to make them better) so that the documentation
>never matched the actual RSX20F system being used, and old code broke
>all the time.
Shit! How the hell did you ever get any work done with all that
going on? No wonder it was a mess. Our technique was to train
our supervisor to keep that crap away from us. What did you do,
Phil?
>
>In the middle of this, we were trying to write the PARSER, which got
>pretty short shrift. LCG FS (who later came to hate it) had VERY
>definite ideas about how they wanted it done (among other things they
>wanted it to look more like TOPS-20).
Well, we could talk about this aspect if you wish. I never did
quite figure out all the dynamics in this area. I was just starting
to get at it (when I got sick) by tackling the KLAD pack. I started
to get the awful sense that that whole aspect of our business was
run by the techs checking out the machines who hadn't a clue about
how to use the system as a user.
>
>We had this idea in the back of our minds that eventually the whole
>blasted thing would be replaced by a network front end anyway, which
>of course never happened. So if there was a pie in the sky, that would
>have been it. I still think the DN8x software would have worked
>better.
Amen. And if it didn't work, we at least had people who could
fix it. This was an aspect of shipping the software on our
monitor tape. We always had to hire somebody special to any -20F work
and that was very nearly impossible to do even in the late 70s.
jmfb...@aol.com
in...@best.com (Smith and O'Halloran) wrote:
>In article <3615172c...@news.clark.net>,
>Philip Gagner <gag...@clark.net> wrote:
>>and shouldn't be discussed in polite company. Certainly a front-end
>>console "simulator" would be necessary, but given the limited number
>>of things the DTE-20 could do from the -10 side, it would be better to
>>have a clean interface and ignore the rest. If you're building a
>>simulator, boot the sucker from simulated ROM and trap all DTE-20
>>calls with a return of success and throw them away. You won't lose
>>anything worth keeping.
>
>Just about every peripheral that was not a disk, tape or network was on
the
>console front-end. Lineprinter. Card Reader and Card Punch. Hardwired
>TTYs. (Excluding, for the moment, devices connected to a KA-compatible
>I/O bus, such as the BA10 lineprinter and Calcomp plotter interface.)
Maybe on KL10 hardware. But the emulator isn't going run on a KL10 (if
it is, why spend time writing an emulator?). The TTYs, card reader/punch,
and line printers are not going to be hitched to a front end on the
system running the emulator [emoticon here getting a tad testy].
John Everett
>
>Just about every peripheral that was not a disk, tape or network was on the
>console front-end. Lineprinter. Card Reader and Card Punch. Hardwired
>TTYs. (Excluding, for the moment, devices connected to a KA-compatible
>I/O bus, such as the BA10 lineprinter and Calcomp plotter interface.)
Okay, maybe I'm just losing my mind, but I was responsible for ALL of the
TOPS-10 "unit record" device service routines during the period in which the
KL was being introduced. I don't recall ever having to rewrite/modify CDPSRX,
CDRSRX, LPTSER, etc., because of any KL specific changes to their
interfaces/controllers. Seems to me they responded to the same CONOs/CONIs and
DATAOs/DATAIs they did on the KA and KI. Did TOPS-20 do things differently?
--
jeve...@wwa.DEFEAT.UCE.BOTS.com (John Everett) http://www.wwa.com/~jeverett
^^^^^^^^^^^^^^^
Things have gotten so bad I feel the need to disguise my email address.
And I don't like this explanation because I just hate long signatures.
Smith and O'Halloran
>jmfb...@aol.com writes:
>
>>a -10 terminal. I still don't know how you kept it all separate.
>>And the -10 had to keep telling the -11 that it was still running
>>(remember all those KAFs?).
>
>into (location 30? of) the -10, and the -10 kept decrementing it. If
>it ever got to zero, it knew the -11 was dead, and if I remember
>correctly would try to boot it. At the same time, the -10 kept
>depositing a value in the -11 memory, which it decremented. If that
>count got to zero, the -11 knew the -10 was dead and would reboot
>it...
Yes, but it wasn't location 30, the keep-alive counter was a reserved location
in the EPT (Exec Page Table).
At every clock tick interval (60 or 50 times per second at PI level 7), the
-10 would look at location 30. If it was ever set to be nonzero, TOPS-10
would take a crash dump.
So, if the system was limping along but not responding to the CTY,
you could force it do produce a stopcode by using the switches and buttons
(KA and KI) or "DM 30,1" (KS and KL running KLDCP). For a KL with RSX20F,
it was something like "EXAMINE 30", "DEPOSIT 1".
Smith and O'Halloran
John Everett <jeve...@wwa.DEFEAT.UCE.BOTS.com> wrote:
>In article <6v33qo$mr1$1...@shell3.ba.best.com>, in...@best.com says...
>>
>>Just about every peripheral that was not a disk, tape or network was on the
>>console front-end. Lineprinter. Card Reader and Card Punch. Hardwired
>>TTYs. (Excluding, for the moment, devices connected to a KA-compatible
>>I/O bus, such as the BA10 lineprinter and Calcomp plotter interface.)
>
>Okay, maybe I'm just losing my mind, but I was responsible for ALL of the
>TOPS-10 "unit record" device service routines during the period in which the
>KL was being introduced. I don't recall ever having to rewrite/modify CDPSRX,
>CDRSRX, LPTSER, etc., because of any KL specific changes to their
>interfaces/controllers. Seems to me they responded to the same CONOs/CONIs and
>DATAOs/DATAIs they did on the KA and KI. Did TOPS-20 do things differently?
Remember, the KL was introduced in two waves.
The KL-1080 was the same size and shape as a KI and had microcode loaded
from DECtapes via KLDCP. As I understand it, most of those first boxes
came with the I/O-bus interface, so that the BA10 and other KA/KI peripherals
could be attached.
The second wave was the KL-1091. In particular, the ones with MOS memory
instead of core memory. They had microcode loaded from floppy via RSX20F.
Not as many of them had the I/O-bus interface, so they relied on the
Console Front-End for unit record devices. By the time we were running
TOPS-10 7.03 started using extended addressing, the only visible difference
between RSX20F for TOPS-10 and RSX20F for TOPS-20 was one byte in the
"keep alive has failed" message. When the -10 stopped, the -11 would send
out on all the hardwired terminals
%%DECSYSTEM-10 NOT RUNNING
or
%%DECSYSTEM-20 NOT RUNNING
Bill Pechter
>>And the -10 had to keep telling the -11 that it was still running
>>(remember all those KAFs?).
>
>into (location 30? of) the -10, and the -10 kept decrementing it. If
>it ever got to zero, it knew the -11 was dead, and if I remember
>correctly would try to boot it.
>
>I was an operator on one of the KLs at Digital's Parker Street
>facility (in 1977), and the KL I worked on had a bad 10<->11
>connection, so the -11 regularly lost communication with the -10
>(someone had set something so the system ignored the keepalive).
>
The 8600/8650 did the same thing with the T11 and RL02
based front end on the Venus. (Designed by the LCG folks, of course)
Anyway... I used to run adventure on the T11 under rt11 when
I worked on them for fun.
Bill
Megan
>The 8600/8650 did the same thing with the T11 and RL02
>based front end on the Venus. (Designed by the LCG folks, of course)
>Anyway... I used to run adventure on the T11 under rt11 when
>I worked on them for fun.
I remember some late nights over in the Marlboro lab, working on
some of the console code for the 8600... this was early on in
the use of RT for the console, so we were still playing with
using the XL handler... I was working on getting a venus-version
of the XL driver working... I did, and sent mail back to my
then project leader, using a modem connected to the serial
port.
Turns out that code was not used, but the conditionals live on
in the XL driver code (unless they've been removed).
There was a poster somewhere which read
"RT-11 turns venus on."
jmfb...@aol.com
jeve...@wwa.DEFEAT.UCE.BOTS.com (John Everett) wrote:
>In article <6v33qo$mr1$1...@shell3.ba.best.com>, in...@best.com says...
>>
>>Just about every peripheral that was not a disk, tape or network was on
the
>>console front-end. Lineprinter. Card Reader and Card Punch. Hardwired
>>TTYs. (Excluding, for the moment, devices connected to a KA-compatible
>>I/O bus, such as the BA10 lineprinter and Calcomp plotter interface.)
>
>Okay, maybe I'm just losing my mind, but I was responsible for ALL of the
>TOPS-10 "unit record" device service routines during the period in which
the
>KL was being introduced. I don't recall ever having to rewrite/modify
CDPSRX,
>CDRSRX, LPTSER, etc., because of any KL specific changes to their
>interfaces/controllers. Seems to me they responded to the same CONOs/CONIs
and
>DATAOs/DATAIs they did on the KA and KI. Did TOPS-20 do things
differently?
>
TOPS-20 had card readers, card punches, and I don't ever remember
a plotter. Hell, the plotter on the -10 disappeared early on.
Joe is confused.
MadBeing
>I don't think you are losing your mind, John. I also don't think that
>TOPS-20 had card readers, card punches, and I don't ever remember
>a plotter. Hell, the plotter on the -10 disappeared early on.
>Joe is confused.
TOPS20 definitely had card readers directly on the primary front end. At least
SN's 2313 and 2447 did. In fact, I found one of the early quasar glxlib bugs
(the first rev of v4.0 tops20) in the card reader driver.
Dan
Dan Smith
"Old Programmers never die,
They just jrst to a new address"
Smith and O'Halloran
>I don't think you are losing your mind, John. I also don't think that
>TOPS-20 had card readers, card punches, and I don't ever remember
>a plotter. Hell, the plotter on the -10 disappeared early on.
>Joe is confused.
I retract my statement about the plotter, but RSX20F for a 1091 did
support PDP-11 based lineprinter, card reader and card punch controllers.
(By that time, paper-tape readers and punches were long gone.)
jmfb...@aol.com
madb...@aol.com (MadBeing) wrote:
>
>>I don't think you are losing your mind, John. I also don't think that
>>TOPS-20 had card readers, card punches, and I don't ever remember
>>a plotter. Hell, the plotter on the -10 disappeared early on.
>>Joe is confused.
>
>front end. At least SN's 2313 and 2447 did. In fact, I
>found one of the early quasar glxlib bugs
>(the first rev of v4.0 tops20) in the card reader driver.
TOPS-20 had a card reader driver? Not even the -10 had that
(we had moved the card stuff to the Customer Supported Tape).
I didn't spend much time on packaging TOPS-20 so I can't say
what the -20 monitor group (this does not include spoolers)
supported. I also didn't review the TOPS-20 SPDs so I can't
say what configurations were sold.
Smith and O'Halloran
>TOPS-20 had a card reader driver? Not even the -10 had that
>(we had moved the card stuff to the Customer Supported Tape).
>I didn't spend much time on packaging TOPS-20 so I can't say
>what the -20 monitor group (this does not include spoolers)
>supported. I also didn't review the TOPS-20 SPDs so I can't
>say what configurations were sold.
TOPS-10/TOPS-20 RSX-20F System Reference Manual, AA-BS94A-TK, AD-BS94A-T1
(TOPS-10 version 7.03, TOPS-20 release 6.1, RSX20F version 15-15)
Page 10-24: DH11 DATA BASE, status of up to 128 TTY lines.
Page 10-29: CD-11 DRIVER DATA BASE, status bits for CD-11 card reader.
Page 10-30: LP-20 DRIVER DATA BASE, status of line printer.
I need to clear up a misstatement on my previous post: there was no
plotter or card punch connected to our 1091. I was, indeed, confused.
We had upgraded the plotter to a Calcomp unit that had an RS-232 interface.
The card punch was a device that had a keyboard and an RS-232 interface. I had
to modify SPROUT to talk to these devices.
We had two Data Products printers; one connected to the KL's BA-10 (left-over
lineprinter controller from the KA), the other had an A/B switch so that it
could connect to the KL's LP-20 or to the KS's LP-11. The high-speed card
reader was a CD20 connected to the KL's CR-11.
Philip Gagner
>In article <F08Eo...@world.std.com>, Megan <m...@world.std.com> wrote:
>>jmfb...@aol.com writes:
>>
>>>a -10 terminal. I still don't know how you kept it all separate.
>>>And the -10 had to keep telling the -11 that it was still running
>>>(remember all those KAFs?).
>>
>>Sure do... if I remember correctly, the -11 kept depositing a count
>>into (location 30? of) the -10, and the -10 kept decrementing it. If
>>it ever got to zero, it knew the -11 was dead, and if I remember
>>correctly would try to boot it. At the same time, the -10 kept
>>depositing a value in the -11 memory, which it decremented. If that
>>count got to zero, the -11 knew the -10 was dead and would reboot
>>it...
>
>Yes, but it wasn't location 30, the keep-alive counter was a reserved location
>in the EPT (Exec Page Table).
>
>At every clock tick interval (60 or 50 times per second at PI level 7), the
>-10 would look at location 30. If it was ever set to be nonzero, TOPS-10
>would take a crash dump.
>
>So, if the system was limping along but not responding to the CTY,
>you could force it do produce a stopcode by using the switches and buttons
>(KA and KI) or "DM 30,1" (KS and KL running KLDCP). For a KL with RSX20F,
>it was something like "EXAMINE 30", "DEPOSIT 1".
> -Joe
Why "EX 30, DE 1" you might ask... well, on a KA10 console, a deposit
was made by examining the location with the address switches, then
keying in the value to be deposited, then toggling the deposit switch,
so it was a syntax well known to FS. It was also a bad idea, causing
lots of confusion. Why not just "DE <addr> <value>" ? I think that
syntax was allowed (if the code for it wasn't removed), but it
probably had some funny punctuation mark required (backarrow tickles
my memory, but it's probably not that).
Philip Gagner
>In article <3615172c...@news.clark.net>,
>Philip Gagner <gag...@clark.net> wrote:
>>and shouldn't be discussed in polite company. Certainly a front-end
>>console "simulator" would be necessary, but given the limited number
>>of things the DTE-20 could do from the -10 side, it would be better to
>>have a clean interface and ignore the rest. If you're building a
>>simulator, boot the sucker from simulated ROM and trap all DTE-20
>>calls with a return of success and throw them away. You won't lose
>>anything worth keeping.
>
>Just about every peripheral that was not a disk, tape or network was on the
>console front-end. Lineprinter. Card Reader and Card Punch. Hardwired
>TTYs. (Excluding, for the moment, devices connected to a KA-compatible
>I/O bus, such as the BA10 lineprinter and Calcomp plotter interface.)
>
Actually, in the early implementation, only one TTY was allowed. We
wanted to put in support for more, but marketing didn't want us to
because it might keep people from buying terminal controllers. The
support for them was left in RSX, though, and eventually I think there
were versions of it that supported multiple TTY's.
Let's see now, you want to support these various devices through a
front end, but you STILL don't need (1) RSX20F or (2) the PARSER in
particular. If you want hardware completeness, you could check and
whenever the -10 side makes a DTE-20 call, figure out what
pseudo-device it is trying to access and just redirect the function.
There weren't that many DTE functions, actually.
Or declare that FE's on your simulated machine have to be "naked" and
LPTs, card readers, etc. just get supported some other way (like the
BA10, which actually would be far simpler to emulate).
> -Joe
jmfb...@aol.com
And you were talking about TOPS-10 even though you typed TOPS-20.
Typos in this newsgroup can cause great misunderstandings :-).
jmfb...@aol.com
>>>jmfb...@aol.com writes:
>>>
>>>>And the -10 had to keep telling the -11 that it was still running
>>>>(remember all those KAFs?).
>>>
Would you explain why it was a bad idea and who got confused?
Eric Werme - replace nospam with werme
>in...@best.com (Smith and O'Halloran) wrote:
>>So, if the system was limping along but not responding to the CTY,
>>you could force it do produce a stopcode by using the switches and buttons
>>(KA and KI) or "DM 30,1" (KS and KL running KLDCP). For a KL with RSX20F,
>>it was something like "EXAMINE 30", "DEPOSIT 1".
>Why "EX 30, DE 1" you might ask... well, on a KA10 console, a deposit
>was made by examining the location with the address switches, then
>keying in the value to be deposited, then toggling the deposit switch,
>so it was a syntax well known to FS.
Not true, but often done in practice.
Set address switches to 30
Set data switches to 1
Push "Deposit this"
I usually pushed "Examine this" first as a safety check. If the data lights
were non-zero, then I had entered a bad address.
It was also interesting to put CALLI 12(? the code for exiting a program)
and pushing execute while the machine was running. The instruction would
execute and if it were in some user program it would exit.
Ah - on a PDP-11/40 console, you only had one set of switches, and I beleive
you had to push examine to set the address and pull deposit to store data to
that address.
--
<> Eric (Ric) Werme <> The above is unlikely to contain <>
<> ROT-13 addresses: <> official claims or policies of <>
<> <jr...@mx3.qrp.pbz> <> Compaq Computer Corp. <>
<> <jr...@plorecbegny.arg> <> http://www.cyberportal.net/werme <>
John Everett
>
>We had two Data Products printers; one connected to the KL's BA-10 (left-over
>lineprinter controller from the KA), the other had an A/B switch so that it
>could connect to the KL's LP-20 or to the KS's LP-11.
Did your KS really have an LP-11? The reason I ask is because the DEC standard
KS configuration included an LP-20. When I ported TOPS-10 to the KS, I was
by that time an ADP employee working as a "contract worker" at Marlboro. We
(ADP) were planning on buying our KS-10s without an LPT interface and
installing LP-11s ourselves. For this reason I had no interest in modifying
LPTSER to deal with the UBA and LP-20, so Doug Detroy (a DEC employee), did
that part of the job.
We opted for the LP-11 because 1) it was cheaper than the LP-20, and 2) it
didn't seem to us that having a DMA LPT controller on the KS made any sense at
all. Because of the "NUXI problem" one had to muck about with the output
buffering a byte at a time anyway (to properly order the bytes in the buffer),
so while mucking about, why not just output the byte directly to the printer?
Once we (ADP) took delivery of our first KS, we installed an LP-11 and I
modified LPTSER to support it. I don't recall if we ever gave that code (I
think I called it LP1SER) back to DEC.
John Wilson
with werme <> wrote: >Ah - on a PDP-11/40 console, you only had one set of
switches, and I beleive >you had to push examine to set the address and pull
deposit to store data to
Not LOAD ADRS? That would be consistant w/others. But anyway yes it has to
be done in two steps. IIRC the KS10's 8080A console emulator is the same,
you can't give an address in a deposit command (only data) so you need to
load up the address pointer with another command first.
John Wilson
D Bit
jmfb...@aol.com
nos...@zk3.dec.com (Eric Werme - replace nospam with werme) wrote:
>gag...@clark.net (Philip Gagner) writes:
>
>>in...@best.com (Smith and O'Halloran) wrote:
>
>>>So, if the system was limping along but not responding to the CTY,
>>>you could force it do produce a stopcode by using the switches and
buttons
>>>(KA and KI) or "DM 30,1" (KS and KL running KLDCP). For a KL with
RSX20F,
>>>it was something like "EXAMINE 30", "DEPOSIT 1".
>
>>Why "EX 30, DE 1" you might ask... well, on a KA10 console, a deposit
>>was made by examining the location with the address switches, then
>>keying in the value to be deposited, then toggling the deposit switch,
>>so it was a syntax well known to FS.
>
>Not true, but often done in practice.
>
>Set address switches to 30
>Set data switches to 1
>Push "Deposit this"
>
>I usually pushed "Examine this" first as a safety check. If the data
lights
>were non-zero, then I had entered a bad address.
>
>It was also interesting to put CALLI 12(? the code for exiting a program)
>and pushing execute while the machine was running. The instruction would
>execute and if it were in some user program it would exit.
>
beleive
>you had to push examine to set the address and pull deposit to store data
to
Ric, I don't remember _pulling_ anything. Weren't they just
the old -11 toggle switches? Geez.. this stuff is so hazed
in my brain. I'm glad we're talking about real stuff :-).
On the -10s the switches were those rocker thingies. Is there
an official term <g>?
/BAH
jmfb...@aol.com
jeve...@wwa.DEFEAT.UCE.BOTS.com (John Everett) wrote:
<snip>
>Once we (ADP) took delivery of our first KS, we installed an LP-11 and I
>modified LPTSER to support it. I don't recall if we ever gave that code (I
>think I called it LP1SER) back to DEC.
>
This isn't the first time that I wish somebody had preserved the
MCO files (not the ones we shipped on the monitor tape) but the
ones that contained all the MCOs written. There's a hell of a
lot of documentation and information that's been lost because
somebody dumped "old" stuff.
Philip Gagner
>Philip Gagner wrote:
>>
>
<snip>
>
>Certianly from an interface perspective, its not total necessary to
>emulate the FE interface but you have to have something so why not
>make it similar and just drop the unecessay stuff. If you ever intend
>to boot from standard tape images (eg. install tapes) and run with
>and unmodified DEC OS then you have to emulate a largish amount of
>FE behaviour certainly null returns won't cut it, and since there
>is no direct code call that goes from 11-10 10-11.
There is, actually. The -10 could read and write -11 memory, and the
-11 could read and write -10 memory pretty directly. On both TOPS-10
and TOPS20 there were monitor calls which implemented an interface,
but the hardware could do it directly (load registers with memory
contents, set up the control bits and push the doorbell).
> You have to set
>up to emulate the DTE protocols for at least console function. At
>no time would you try and emulate PDP-11 instructions to get the
>FE behaviour so you don't have to adopt quite the degree of crud that
>you see makes up the RSX environment.
No, you don't. First, the tapes you're speaking of would be connected
to the -10, if one implemented tapes at all. It would be nice, I
suppose, to have a fully operational -10 with spinning tapes, from a
museum standpoint, but there's little reason except that to implement
tapes. The FE generally had either an 8" floppy or DECtapes. Why
support these? Presumably you're not going to load "official"
microcode into your emulated KL, so you don't need those features.
Wouldn't it be far easier just to implement only (1) START/HALT; (2)
CLOCK; and (3) Examine/Deposit Register and (4) Examine/Deposit
memory? Why is anything else at all needed?
One might, I suppose, want to implement console TTY, but it would be
easier to emulate a DC-10 and remap the console functions.
Besides, I think that anyone actually building a KL emulated would
want to run ITS rather than either DECSystem-10 or -20 code. But
that's just a personal opinion, based on experience with all three
systems.
Philip Gagner
>In article <6vdd7g$ohs$1...@nntpd.lkg.dec.com>,
> nos...@zk3.dec.com (Eric Werme - replace nospam with werme) wrote:
<snip>
>>
>>Not true, but often done in practice.
>>
>>Set address switches to 30
>>Set data switches to 1
>>Push "Deposit this"
This is correct.
<snip>
>
>Ric, I don't remember _pulling_ anything. Weren't they just
>the old -11 toggle switches? Geez.. this stuff is so hazed
>in my brain. I'm glad we're talking about real stuff :-).
>
>On the -10s the switches were those rocker thingies. Is there
>an official term <g>?
As to switches:
PDP-6 had lovely switches. The best ever. There were large toggle
switches (something like the bat-wing switches on British motor cars
except round and tapered and longer, made of brushed aluminum, I
think) for control functions and then little microswitches for things
like address and data. These had the advantage of staying up or down
after being pushed, so you could run your finger along them and "feel"
the address to make sure it was right, or look at them and see.
Feeling was easier and faster. The console looked like something that
would be built in a laboratory rather than a piece of commercial gear.
The KA-10 had awful switches - rocker switches made of colored
plastic. Probably cheaper, maybe more reliable, but not as aesthetic.
The KI-10 had absolutely lovely switches again- square translucent
switches with lights built into them. When you pushed a switch the
light would (might) come on. Very Star Trek. Looked the way a computer
should. Beam me up, Scottie.
The KL ... well, enuf said.
jmfb...@aol.com
I never met an ITS. Would you mind explaining why you'ld rather see
ITS run? What did you prefer in ITS over the -10 or -20?
Philip Gagner
>In article <6v33qo$mr1$1...@shell3.ba.best.com>, in...@best.com says...
>>
>>Just about every peripheral that was not a disk, tape or network was on the
>>console front-end. Lineprinter. Card Reader and Card Punch. Hardwired
>>TTYs. (Excluding, for the moment, devices connected to a KA-compatible
>>I/O bus, such as the BA10 lineprinter and Calcomp plotter interface.)
>
>Okay, maybe I'm just losing my mind, but I was responsible for ALL of the
>TOPS-10 "unit record" device service routines during the period in which the
>KL was being introduced. I don't recall ever having to rewrite/modify CDPSRX,
>CDRSRX, LPTSER, etc., because of any KL specific changes to their
>interfaces/controllers. Seems to me they responded to the same CONOs/CONIs and
>DATAOs/DATAIs they did on the KA and KI. Did TOPS-20 do things differently?
Well, you're not losing your mind (at least the above message isn't
sufficent evidence of the hypothesis to make a conclusive judgment)
but the answer is still no. That is, the FE-connected devices did not
(and logically could not) respond to CONO, CONI, DATAO, and DATAI.
What happened was that the pseudo-device trapped through the device
dispatch table into the front end driver (what was it called, FESER
doesn't sound right--DTESER?) and the front end driver pushed it onto
the DTE queue, where eventually it got eaten by RSX20F and later a
successful return was pushed back over the FE, resolving the system
call. So LPTSER, etc, did not have to be rewritten or modified any
more for the FE than they had to be for remote (DC72) lineprinters,
etc. Since the networked devices (DC72/DN8x) were introduced before
the -KL, I don't recall any modifications which were required. Lots of
modifications were required to make the FE code work, though.
Philip Gagner
>>
>I never met an ITS. Would you mind explaining why you'ld rather see
>ITS run? What did you prefer in ITS over the -10 or -20?
>/BAH
This is a troll, right? :-o
ITS was a cleaner implementation of an operating system. It could be,
because it didn't have to support hundreds of thousands of different
combinations of devices. As you know, it was developed at MIT AI. It
lacked a lot in the area of security (this wasn't considered a defect,
particularly), but it gave a lot on performance. And it was easier to
maintain, by far.
ITS didn't really have a command set. When you "logged in" (i.e.
tickled the TTY controller or network controller), ITS would start a
job process and load a copy of DDT. That DDT had been modified
somewhat due to the complaints of non-hacker graduate students and
some professors used to systems like MULTICS or CTSS, so that it had
an overlay of "commands". Actually, there was only one "command",
which was colon (:). The next word was dispatched through a table so
that it looked like :LOAD or :DIR did useful things. But in reality,
you were running a much enhanced version of DDT, which know about
sub-processes. This made programming and debugging very much simpler,
and you didn't have to load DDT in the address space of your program
(remember all the times a program would run only with DDT loaded??)
Anyway, ITS was designed early on to know about multiple processors
(sort of--shared memory processors anyway) and remote devices. There
was a real drive towards device independence, much more so than at
DEC. So tape drives looked like disks, and so did pretty much
everything else. This made remote devices a snap, because the system
already encapsulated the hardware for devices and presented a uniform
interface. The job control system calls were easier to use and more
sophisticated. Inter-process communication was a very big item, much
earlier than TOPS-10 had it. In fact, that part of the DECSystem-10
IPCF (InterProcess Communication Facility) which I worked on was
modeled after the way ITS did it.
Finally, the operating system package was much, much smaller than
DECs.
Problems with ITS included random musings which tried to pass for
system documentation, almost completely uncommented system code (like
some sort of recursive sacred scripture, the code was its own
commentary), and lack of support for any device which didn't interest
MIT or Stanford.
Daniel Seagraves
> No, you don't. First, the tapes you're speaking of would be connected
> to the -10, if one implemented tapes at all. It would be nice, I
> suppose, to have a fully operational -10 with spinning tapes, from a
> museum standpoint, but there's little reason except that to implement
> tapes. The FE generally had either an 8" floppy or DECtapes. Why
> support these? Presumably you're not going to load "official"
> microcode into your emulated KL, so you don't need those features.
> Wouldn't it be far easier just to implement only (1) START/HALT; (2)
> CLOCK; and (3) Examine/Deposit Register and (4) Examine/Deposit
> memory? Why is anything else at all needed?
>
That's pretty much what I'm doing - I decided to bag the console bit - I'm
making up my own commands.
> One might, I suppose, want to implement console TTY, but it would be
> easier to emulate a DC-10 and remap the console functions.
What's a DC-10? I have DATAO TTY working...
> Besides, I think that anyone actually building a KL emulated would
> want to run ITS rather than either DECSystem-10 or -20 code. But
> that's just a personal opinion, based on experience with all three
> systems.
I'm not going to limit it to ITS - I'm going to try to emulate enough to
make TOPS-20 work. Speaking of which, does anyone have a diskimage?
Daniel Seagraves | I'm an International Clandestine Arms Dealer!
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
What is this? See http://www.dcs.ex.ac.uk/~aba/rsa | 36 BITS 4EVER!
Chris Hedley
gag...@clark.net (Philip Gagner) writes:
> PDP-6 had lovely switches. The best ever. There were large toggle
Going completely off-topic for a moment, it's a shame that today's
"computers" don't look like the real thing. Star Trek would've never
sanctioned stage-props along the lines of something dull and beige
with few interesting lights and switches on them. The "soft power"
switch of today's PCs is a true atrocity, half the time it doesn't
even turn the bugger off. Still, at least I can still use the
switch on the wall-socket which has a nice tactile feel to it. :)
Chris.
Philip Gagner
<snip>
>> One might, I suppose, want to implement console TTY, but it would be
>> easier to emulate a DC-10 and remap the console functions.
>
>What's a DC-10? I have DATAO TTY working...
>
The DC-10 was the old, ancient, and best of all simple, terminal
controller for PDP-10s. It came out around the same time as the KA-10.
It supported multiple serial terminals. You're probably right that the
I/O instruction was conventionally DATAO TTY, but I vaguely remember
it as conventionally DATAO CON, for DATAO Console. 'course it's all in
the assignments, and was a matter of taste.
>
>I'm not going to limit it to ITS - I'm going to try to emulate enough to
>make TOPS-20 work. Speaking of which, does anyone have a diskimage?
This means you're really going to implement all the page-fault stuff
right? Wow! As I recall, TOPS-20 was a little sensitive to page fault
timings. I'm probably wrong about this, but as I recall ITS ran on the
modified page controller that MIT used--would it ever run on a vanilla
KL? I vaguely remember an effort to make it do that, but I never heard
whether anyone got it working.
Daniel Seagraves
> The DC-10 was the old, ancient, and best of all simple, terminal
> controller for PDP-10s. It came out around the same time as the KA-10.
> It supported multiple serial terminals. You're probably right that the
> I/O instruction was conventionally DATAO TTY, but I vaguely remember
> it as conventionally DATAO CON, for DATAO Console. 'course it's all in
> the assignments, and was a matter of taste.
Hmm... Got any manuals for it?
> This means you're really going to implement all the page-fault stuff
> right? Wow! As I recall, TOPS-20 was a little sensitive to page fault
> timings. I'm probably wrong about this, but as I recall ITS ran on the
> modified page controller that MIT used--would it ever run on a vanilla
> KL? I vaguely remember an effort to make it do that, but I never heard
> whether anyone got it working.
I have the DECsystem 10/20 Processor Refrence Manual from 36bit.org,
and I plan on emulating everything in it that I can. And if I can't, I'll
fake it, or find someone to explain it to me. Thing is, I have to haul
ass and get this done before all the folks with the answers goes to the
big bit-bucket in the sky... I'm at 43% done, and I'm not giving up
anytime soon. (Also, I'm 19, so I've got the rest of my life to hack this
to prefection.)
Daniel Seagraves | I'm an International Clandestine Arms Dealer!
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
What is this? See http://www.dcs.ex.ac.uk/~aba/rsa | 36 BITS 4EVER!
PS: The typo was intentional :)
Chris Ward
Daniel Seagraves wrote in message ...
>On Wed, 7 Oct 1998, Philip Gagner wrote:
>
>> The DC-10 was the old, ancient, and best of all simple, terminal
>> controller for PDP-10s. It came out around the same time as the KA-10.
>> It supported multiple serial terminals. You're probably right that the
>> I/O instruction was conventionally DATAO TTY, but I vaguely remember
>> it as conventionally DATAO CON, for DATAO Console. 'course it's all in
>> the assignments, and was a matter of taste.
The terminal controller for the PDP-10 that I remember was actually a
PDP-8/I (I think) with 32K of 12 bit words, and it was described to me as
the predecessor of the UART, that is, it read each bit and assembled a seven
(or eight or whatever) bit byte by sensing the start bit, the data bits, the
parity, the stop and the rest. It handled 30 or more 10CPS terminals (110
baud, 2 stop bits) and 5 or so 300 bps (High Speed) terminals.
Mike Albaugh
: The terminal controller for the PDP-10 that I remember was actually a
: PDP-8/I (I think) with 32K of 12 bit words, and it was described to me as
: the predecessor of the UART,
Kinda doubtful, IMHO, that last bit. Although I well remember
the 8/I used as a "terminal concentrator" via bit-boffing software,
I also well remember UARTs made out of three "System Modules" (tm)
each, programmed very much like (sane) UARTS of today. I would be
_very_ surprised to hear that a bit-boffing 8/I (made of TTL ?)
preceded these system-modules, the basic building blocks of the
PDP-1, -4, -5, and -6.
: that is, it read each bit and assembled a seven
: (or eight or whatever) bit byte by sensing the start bit, the data bits, the
: parity, the stop and the rest. It handled 30 or more 10CPS terminals (110
: baud, 2 stop bits) and 5 or so 300 bps (High Speed) terminals.
Software UARTS are fun. My first was on a machine with vacuum
tubes and drum main-memory, but that post-dated my use of mechanical
"UARTS" (with both "pulling" and "holding" magnets, for all you other
grey-beards :-)
Apologies for the distinctly thin veneer of -10 content.
Mine was a -6 :-)
Mike
| alb...@agames.com, speaking only for myself
Mark Crispin
> I have the DECsystem 10/20 Processor Refrence Manual from 36bit.org,
> and I plan on emulating everything in it that I can. And if I can't, I'll
> fake it, or find someone to explain it to me. Thing is, I have to haul
> ass and get this done before all the folks with the answers goes to the
> big bit-bucket in the sky... I'm at 43% done, and I'm not giving up
> anytime soon. (Also, I'm 19, so I've got the rest of my life to hack this
> to prefection.)
With all due respect, and with absolutely no intent to discourage you or
dampen your youthful enthusiasm, I must inform you that your "43% done" is
extremely optimistic. You may have implemented 43% of the user mode
machine instructions, but that part of the task is less than 20% of the
overall work necessary to produce an emulator that can run any of the
operating systems.
Or, more accurately, an emulator that can run EDDT (meaning that you have
basic console I/O done) is about 20% of the task.
I/O and the virtual memory system is a *huge* task, and often you are not
going to find the answers from reading the manual; you will have to
analyze EDDT and operating system sources.
It may also be helpful to analyze microcode sources as well; in
particular, you may think that you've implemented floating point
correctly, until you actually try running real software and find that you
have not.
I wish you the best of luck in your project, but having observed the
progress of Stu's incomplete emulator and Ken's completed emulator, I
strongly urge you to prepare yourself for much more work than you
anticipate. I would hate to see you become discouraged when reality
sets in (and it will) and abandon the project.
You're probably about 8% done. Good luck.
-- Mark --
* RCW 19.149 notice: This email address is located in Washington State. *
* Unsolicited commercial email may be billed $500 per message. *
Science does not emerge from voting, party politics, or public debate.
Chris Ward
Mark Crispin wrote in message ...
>With all due respect, and with absolutely no intent to discourage you or
>dampen your youthful enthusiasm, I must inform you that your "43% done" is
>extremely optimistic. You may have implemented 43% of the user mode
>machine instructions, but that part of the task is less than 20% of the
>overall work necessary to produce an emulator that can run any of the
>operating systems.
>
>I wish you the best of luck in your project, but having observed the
>progress of Stu's incomplete emulator and Ken's completed emulator, I
>strongly urge you to prepare yourself for much more work than you
>anticipate. I would hate to see you become discouraged when reality
>sets in (and it will) and abandon the project.
>
>You're probably about 8% done. Good luck.
>
>-- Mark --
with him on the size of the task you have set before you. Have you thought
of implementing a KS-10? It was a later machine, and though it did not have
as much capacity or thoroughput as the KL, there were lots fewer options. I
think it could run TOPS-10 and TOPS20, and if someone could run ITS, that
would cover the audience nicely. The simpler machine, and the less complex
the interface to the hardware the better if you have to emulate it. I think
the KS-10 was microcoded, and emulating the microcode might be a good route
too. The KL was the big boy on the block though, and there will be a lot of
people who would not settle for an emulation of anything less. But as far
as I can tell there is a bigger chance of you getting on a real KS-10 than a
KL-10 in order to compare your results, power and housing costs being what
they are.
Chris Ward
If you were building a machine from scratch, a PDP-10 like machine (in the
fashionable 32 or 64 bits) might be made to work quite well.
Mark Crispin
> I never met an ITS. Would you mind explaining why you'ld rather see
> ITS run? What did you prefer in ITS over the -10 or -20?
ITS and TOPS-20 were both much more advanced operating systems than
TOPS-10.
TOPS-20 had significantly better virtual memory than ITS. Conversely, ITS
had more forward-looking processes (much like UNIX); TOPS-20 processes
were in some ways like threads since they all shared the same job status
(for example, changing the connected directory in one process did so for
all processes).
Like TOPS-10, ITS had a terrible mishmash of system calls in the early
days, but later on the wonderful .CALL UUO (every argument and every
return value followed very specific rules. TOPS-20's system calls started
out with a better design, but it was allowed to get messy (although never
as bad as TOPS-10).
TOPS-20's command decoder was like TOPS-10's, only much better; however by
today's shell standards it was pretty weak. ITS' command decoder was DDT;
it was great for hackers but once again by today's shell standards it was
even weaker than TOPS-10's. There may have been a MIC equivalent in ITS,
but certainly nothing like PCL in TOPS-20. PCL in turn never matched the
Unix shell; TOPS-20 and Unix were often compared as "TOPS-20 is an
incredibly powerful OS hidden behind an incredibly powerless shell; UNIX
is an incredibly powerful shell hiding an incredibly powerless OS."
ITS used a significantly simpler pager than TOPS-20, but it was much
better than the KI pager that all but the final versions of TOPS-10 used.
ITS had good display terminal support (although not as good as WAITS), and
the inspiration for Unix termcap came from ITS. Curiously, ITS never had
built-in support for ANSI terminals. However, this definitely beat out
anything that TOPS-20 (and especially TOPS-10) ever had, which is
charitably characterized as "knowing the right way to draw delete last
character on various terminals".
ITS was a great "hacker's playground", but active development fell by the
wayside in the late 1970s
Philip Gagner
>
>Daniel Seagraves wrote in message ...
>>On Wed, 7 Oct 1998, Philip Gagner wrote:
>>
>>> The DC-10 was the old, ancient, and best of all simple, terminal
>>> controller for PDP-10s. It came out around the same time as the KA-10.
>>> It supported multiple serial terminals. You're probably right that the
>>> I/O instruction was conventionally DATAO TTY, but I vaguely remember
>>> it as conventionally DATAO CON, for DATAO Console. 'course it's all in
>>> the assignments, and was a matter of taste.
>
>The terminal controller for the PDP-10 that I remember was actually a
>PDP-8/I (I think) with 32K of 12 bit words, and it was described to me as
>the predecessor of the UART, that is, it read each bit and assembled a seven
>(or eight or whatever) bit byte by sensing the start bit, the data bits, the
>parity, the stop and the rest. It handled 30 or more 10CPS terminals (110
>baud, 2 stop bits) and 5 or so 300 bps (High Speed) terminals.
>
This was a device variously named, but generally called a DC72. It was
a remote terminal controller (although it could be connected over a
local interface--indeed at least one local controller HAD to be on an
interface. I'm probably wrong, but I think the hardware box that
connected the local FE to the -10 was called a something like a DL10
(or maybe the DL10 was only used for -11 FE's--in which case I don't
recall waht the box was).
The PDP8/I was MUCH later, and it was a general purpose computer (a
PDP-8 in fact) which sat at the end of a network (see above). You
could hook several terminals (I think 8 was pretty much the max) to
it, as well as a remote lineprinter and a remote card reader. Also, it
could handle speeds much higher than 30 CPS.
It was designed by DAS (Digital Advanced Systems) and programmed by
several people, notably Eric Peabody. Eventually it got superceded by
the DNx series of PDP-11 based front ends.
John Wilson
>> modified page controller that MIT used--would it ever run on a vanilla
>> KL? I vaguely remember an effort to make it do that, but I never heard
>> whether anyone got it working.
The modified page controller existed in hardware form only on the KA machines,
for the KL and KS it was done using custom microcode on vanilla hardware.
Which is good news if that's what you have, but since the emulator won't be
running the real microcode it will need to have a special ITS mode to
emulate the behavior of the ITS microcode.
>I have the DECsystem 10/20 Processor Refrence Manual from 36bit.org,
>and I plan on emulating everything in it that I can. And if I can't, I'll
>fake it, or find someone to explain it to me.
FYI the ITS paging stuff isn't in any of the DEC docs, and neither are a
few other goodies (like BLTBU/BLTUB) that may come up later. The ITS
microcode sources will help a lot though. FWIW, I did a quick sketch of
my understanding (from various sources) of ITS paging in
http://www.dbit.com/pub/pdp10/info/paging.its
>I'm at 43% done, and I'm not giving up
Just to chime in with everyone else, don't underestimate the difficulty
of the paging, interrupt, and I/O systems. Just to do KS10 style I/O you
need to do a whole lot of twiddling to bridge between the Unibus and the
KS10 bus (Unibus maps and BRx translation for both UBAs), and emulating the
Unibus devices themselves is no picnic; I'm sure the KL10 I/O system is a
lot harder. Thanks to bad docs, the TU77 is very difficult to get right,
and the RM/RP disks aren't as bad but still non-trivial. But it's still
doable, luckily the 10s don't seem to have had anything like the insane
proliferation of different peripherals that DEC's 16/32-bit machines had, so
you can do just one kind of disk (e.g. RP06) and one kind of tape (e.g. TU77)
and probably satisfy 99% of everybody.
John Wilson
D Bit
Megan
>Ric, I don't remember _pulling_ anything. Weren't they just
>the old -11 toggle switches? Geez.. this stuff is so hazed
>in my brain. I'm glad we're talking about real stuff :-).
The 11/40 (/35, /45, /55, /70) had essentially triangular shaped
switches with a rounded apex sticking out from the panel. It
had a pivot point located in the center of the base of the triangle.
In the down position, it was a zero, lift for a one...
>On the -10s the switches were those rocker thingies. Is there
>an official term <g>?
the KA10 has the same style of toggle switches (rockers) as the
pdp-8/i. The KI10 had square, momentary contact pushbuttons.
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
Eric Smith
> There is, actually. The -10 could read and write -11 memory, and the
> -11 could read and write -10 memory pretty directly.
The DTE20 hardware only provided the -11 with the capability of reading
and writing -10 memory, but not vice versa.
Obviously suitable front end software on the -11 could provide this
functionality to the -10 if it was needed.
Reference: chapter 1 of the DTE20 Unit Description, 3rd edition, available at
http://www.36bit.org/
Eric
John Everett
>
>The terminal controller for the PDP-10 that I remember was actually a
>PDP-8/I (I think) with 32K of 12 bit words, and it was described to me as
>the predecessor of the UART, that is, it read each bit and assembled a seven
>(or eight or whatever) bit byte by sensing the start bit, the data bits, the
>parity, the stop and the rest. It handled 30 or more 10CPS terminals (110
>baud, 2 stop bits) and 5 or so 300 bps (High Speed) terminals.
The bit-banger being described above was called the 680, at least on the
PDP-8. Back before I joined the PDP-10 Monitor Group I co-wrote (with Don
Witcraft) a little OS called TSS-8. I was responsible for (among other things)
the TTY support and had to get intimately familiar with the little beast. I
seem to recall on the 8/I there was a 680I which differed from the 680 in bit
sampling rate. I think the 680 sampled 8 times per bit, while the 680I only
sampled 5 times. But then again that was a long time ago.
Peter da Silva
Mark Crispin <m...@CAC.Washington.EDU> wrote:
>ITS had good display terminal support (although not as good as WAITS), and
>the inspiration for Unix termcap came from ITS. Curiously, ITS never had
>built-in support for ANSI terminals. However, this definitely beat out
>anything that TOPS-20 (and especially TOPS-10) ever had, which is
>charitably characterized as "knowing the right way to draw delete last
>character on various terminals".
Hmmm.
I definitely recall hitting ^U on a TOPS-20 system on a 300 baud terminal
and seeing it use cursor positioning commands to clear the line. This was
really obvious when you were ^U-ing multiple lines of some letter that
you'd created by falling asleep on the terminal until the beeping woke
you up.
Ah, finals week.
The Datamedia 1520 had the UGLIEST bell sound, too.
--
This is The Reverend Peter da Silva's Boring Sig File - there are no references
to Wolves, Kibo, Discordianism, or The Church of the Subgenius in this document
> We must make sure our momentum aligns with our value-added distribution! <
Peter da Silva
Peter da Silva <pe...@taronga.com> wrote:
>I definitely recall hitting ^U on a TOPS-20 system on a 300 baud terminal
>and seeing it use cursor positioning commands to clear the line. This was
>really obvious when you were ^U-ing multiple lines of some letter that
>you'd created by falling asleep on the terminal until the beeping woke
>you up.
Hmmm. Thinking back now, I can't recall ever falling asleep on a TOPS-20
session. It was the overloaded PDP-11 running Version 6 that was sleep
inducing. It *was* the '20 that impressed me by using escape sequences to
implement erase-line, though. Perhaps it was a Berkeley hack?
Mark & Suzanne (gcs might work)
>
> but the answer is still no. That is, the FE-connected devices did not
> (and logically could not) respond to CONO, CONI, DATAO, and DATAI.
Thats my understanding each machine knows only about its interface to
the DTE you need to be setting up control structures and telling
your side of the DTE about them and so passing the data via the DTE to
the 10 or 11 on the otherside its a PDP-10 IO instruction to the DTE
that make its happen causing an interupt to the 11 (doorbell style).
> What happened was that the pseudo-device trapped through the device
> dispatch table into the front end driver (what was it called, FESER
> doesn't sound right--DTESER?) and the front end driver pushed it onto
DTESRV and various upper layers like TTYSRV CDRSRV LINEPR on the 10 side
Cheers
Mark :)
Chris Hedley
Mark Crispin <m...@CAC.Washington.EDU> writes:
> ITS and TOPS-20 were both much more advanced operating systems than
> TOPS-10.
Dunno about anyone else, but I'm taking cover now.
Chris.
Mark Crispin
> >However, this definitely beat out
> >anything that TOPS-20 (and especially TOPS-10) ever had, which is
> >charitably characterized as "knowing the right way to draw delete last
> >character on various terminals".
> I definitely recall hitting ^U on a TOPS-20 system on a 300 baud terminal
> and seeing it use cursor positioning commands to clear the line.
^U (and ^W) are just multiple forms of "delete last character".
TOPS-20 had a limited table of how to do certain things (line starve,
clear to end of screen) but didn't do anything with them other than make
delete (including ^W and ^U) do the right thing.
MIT did real ITS-style display handling (I think that it was Mike McMahon
who did the work, maybe Dan Gerson) but it was never widely adopted.
However, nothing ever matched the wonderful display system that WAITS had.
Alan H. Martin
>"Chris Ward" <c...@idt.net> wrote:
>>The terminal controller for the PDP-10 that I remember was actually a
>>
>This was a device variously named, but generally called a DC72. It was a
>box that connected the local FE to the -10 was called a something like a DL10
>(or maybe the DL10 was only used for -11 FE's--in which case I don't recall
>waht the box was).
>
>The PDP8/I was MUCH later, and it was a general purpose computer (a
>PDP-8 in fact) which sat at the end of a network (see above). You
>could hook several terminals (I think 8 was pretty much the max) to
>it, as well as a remote lineprinter and a remote card reader. Also, it
>could handle speeds much higher than 30 CPS.
Chris is referring to a "680I", (perhaps contained in a DC68, but I'm not
positive). The 680I has been described elsewhere on Usenet as a PDP-8/I with
additional communications hardware. He's specifically referring to the -8
connected to KA#101 at Stevens Institute in Hoboken.
There was certainly no ANF-10 (let alone DECnet-10) used or needed to drive a
680I with attached modems.
The DL10 memory window was used on the PDP-11-based DC76 box (perhaps among
others). KA#109 at BOCES/NCODE (Westbury, NY) used a DC76/DL10 combo.
I didn't know what interfaced a -10 to a DC68, but my 3rd edition -10 SRM says
that it was a DA10 12/18 bit computer interface which sat on both the -10's
and the -8's I/O bus.
/AHM
--
Alan Howard Martin AMa...@ZKo.DEC.Com
Smith and O'Halloran
Alan H. Martin <ama...@denton.zko.dec.com> wrote:
>Chris is referring to a "680I", (perhaps contained in a DC68, but I'm not
>positive). The 680I has been described elsewhere on Usenet as a PDP-8/I with
>additional communications hardware. He's specifically referring to the -8
>connected to KA#101 at Stevens Institute in Hoboken.
>
>others). KA#109 at BOCES/NCODE (Westbury, NY) used a DC76/DL10 combo.
>
>I didn't know what interfaced a -10 to a DC68, but my 3rd edition -10 SRM says
>that it was a DA10 12/18 bit computer interface which sat on both the -10's
>and the -8's I/O bus.
Yep. And the 680I responded to READ-IN_MODE, and could be used to
squirt a bootstrap program into the KA's memory. (This was instead of
relying on the paper-tape reader to load in the bootstrap that knew
how to talk to RP02 disk drives.)
Later on, DCA (Digital Communications Associates of Norcross, Georgia) came
out with another box that lived on the -10's I/O bus and talked to remote
terminal concentrators. We did not have an ANF-10 network at the Colorado
School of Mines, but I hacked in some of the network-related UUOs so that
SYSTAT and such could report which terminal multiplexor the TTY was connected
to.
-Joe
--
INWAP.COM is Joe and Sally Smith, John and Chris O'Halloran and our cats
See http://www.inwap.com/ for PDP-10, "ReBoot", "Shadow Raiders"/"War Planets"
Smith and O'Halloran
John Everett <jeve...@wwa.DEFEAT.UCE.BOTS.com> wrote:
>In article <6vb376$a8n$1...@shell3.ba.best.com>, in...@best.com says...
>>
>>We had two Data Products printers; one connected to the KL's BA-10 (left-over
>>lineprinter controller from the KA), the other had an A/B switch so that it
>>could connect to the KL's LP-20 or to the KS's LP-11.
>
>Did your KS really have an LP-11? The reason I ask is because the DEC
>standard KS configuration included an LP-20.
Yeah, but the LP-20 was too expensive. What we had was a board from
DCA that was an LP-11 clone. They provided the device driver for it;
I'm not sure, but I think it was called LP1SER.
>Once we (ADP) took delivery of our first KS, we installed an LP-11 and I
>modified LPTSER to support it. I don't recall if we ever gave that code (I
>think I called it LP1SER) back to DEC.
I cannot say whether DCA got your code or they re-invented the driver.
It just worked.
John Wilson
Eric Werme - replace nospam with werme <> wrote:
>The KA rocker switches were nicely rounded and had a much better feel
>than most other console switches.
I've been wondering about this, most of the DEC front panels seemed to use
switches that were a bit substantial for my tastes, were they really that
easy to use? The thing I like about my 8/E's front panel is that the flimsy
little bat switches (really slide switches with bats mounted over them) are
very lightweight so it's easy to change the switches quickly by whacking them
with the side of your finger, but the KA10 rockers and most PDP-11 triangles
look like you'd have to go a lot more slowly since it takes a good solid poke
to flip them. Am I wrong?
John Wilson
D Bit
(still fantasizing about having switches made up for a custom console for E11)
Eric Werme - replace nospam with werme
>jmfb...@aol.com writes:
>>Ric, I don't remember _pulling_ anything. Weren't they just
>>the old -11 toggle switches? Geez.. this stuff is so hazed
>>in my brain. I'm glad we're talking about real stuff :-).
>The 11/40 (/35, /45, /55, /70) had essentially triangular shaped
>switches with a rounded apex sticking out from the panel. It
>had a pivot point located in the center of the base of the triangle.
>In the down position, it was a zero, lift for a one...
That wasn't my reference. All the momentary contact switches were
spring loaded triangles that you pushed down and would spring back.
Deposit was the one exception - you had to lift it up and it would
spring down. BAH - I don't think you ever had much need to muck
with bits on the various -11s. Rebooting them was mostly setting the
start address in the switches and pushing load address and start.
>>On the -10s the switches were those rocker thingies. Is there
>>an official term <g>?
>the KA10 has the same style of toggle switches (rockers) as the
>pdp-8/i. The KI10 had square, momentary contact pushbuttons.
The KA rocker switches were nicely rounded and had a much better feel
than most other console switches. I often copied an address from the
data light down to the address switches, then added an offset directly
into the switches (think of a binary abacus) to get to important data
when I couldn't use DDT or EDDT.
--
<> Eric (Ric) Werme <> The above is unlikely to contain <>
<> ROT-13 addresses: <> official claims or policies of <>
<> <jr...@mx3.qrp.pbz> <> Compaq Computer Corp. <>
<> <jr...@plorecbegny.arg> <> http://www.cyberportal.net/werme <>
Philip Gagner
>In article <6vjjvc$4qm$1...@nntpd.lkg.dec.com>,
>Eric Werme - replace nospam with werme <> wrote:
>>The KA rocker switches were nicely rounded and had a much better feel
>>than most other console switches.
>
>I've been wondering about this, most of the DEC front panels seemed to use
>switches that were a bit substantial for my tastes, were they really that
>easy to use? The thing I like about my 8/E's front panel is that the flimsy
>little bat switches (really slide switches with bats mounted over them) are
>very lightweight so it's easy to change the switches quickly by whacking them
>with the side of your finger, but the KA10 rockers and most PDP-11 triangles
>look like you'd have to go a lot more slowly since it takes a good solid poke
>to flip them. Am I wrong?
No. You're not wrong. The KA10 switches were lightweight junk plastic,
but weren't like the PDP-11 switches (they were, as has been pointed
out earlier, like certain PDP-8 switches). The problem with the KA-10
switches was that they were multi-colored flimsy rocker switches. The
PDP-6 sported wonderful positive action microswitches that gave a
satisfying click when you switched them. Coupled with the brushed
aluminum panel, you felt like you were really doing science when you
used the machine. Dr. Who would have been proud to use them.
Most flavors of PDP-11 console switches were, by and large, thin
trapozoidal plastic jobbers (you call them triangles), but at least
they'd stay where you put them. Still, no self-respecting mad
scientist would have had them on the Tardis for a minute.
Several bouts of serious memory deposits with the PDP-6 could give you
finger callouses. The PDP-10 would probably give you finger cramps.
The KI-10 would give you hallucinations because of all the pretty
blinkin-lights. Still, all of these were probably better than the
PDP-11 Kaymart "triangles."
Given my druthers, it would be the PDP-6 or the KI-10. Hard to chose
between them. Love them blinkin-light-switches, but the "click" of the
PDP-1/PDP-6 switches, and the wonderful truncated cone toggle-switches
for control functions had a really nice tactile/auditory experience.
jmfb...@aol.com
gag...@clark.net (Philip Gagner) wrote:
>jmfb...@aol.com wrote:
>>>
>>I never met an ITS. Would you mind explaining why you'ld rather see
>>ITS run? What did you prefer in ITS over the -10 or -20?
>
>This is a troll, right? :-o
Actually, no. I'm really interested and very ignorant.
>
>ITS was a cleaner implementation of an operating system. It could be,
>because it didn't have to support hundreds of thousands of different
>combinations of devices.
Yup. That's was always one of the compromises we had to make. One
of the very first things that JMF and TW did when starting 7.01 was
use that as an opportunity to bundle in sensible stuff and get rid
of the stuff that had been haunting them for years.
> As you know, it was developed at MIT AI. It
>lacked a lot in the area of security (this wasn't considered a defect,
>particularly), but it gave a lot on performance. And it was easier to
>maintain, by far.
>
>ITS didn't really have a command set. When you "logged in" (i.e.
>tickled the TTY controller or network controller), ITS would start a
>job process and load a copy of DDT. That DDT had been modified
>somewhat due to the complaints of non-hacker graduate students and
>some professors used to systems like MULTICS or CTSS, so that it had
>an overlay of "commands". Actually, there was only one "command",
>which was colon (:). The next word was dispatched through a table so
>that it looked like :LOAD or :DIR did useful things. But in reality,
>you were running a much enhanced version of DDT, which know about
>sub-processes. This made programming and debugging very much simpler,
>and you didn't have to load DDT in the address space of your program
>(remember all the times a program would run only with DDT loaded??)
Actually, no. Example, please?
>
>Anyway, ITS was designed early on to know about multiple processors
>(sort of--shared memory processors anyway) and remote devices.
Was it a timesharing system or one these task partition systems that
people have a tendency to call timesharing?
> There
>was a real drive towards device independence, much more so than at
>DEC.
My plan was to get the guys to figure out a way to add a new device
without doing a rebuild. If a rebuild wasn't required, then a reload
wouldn't be either. Jim always said that the whole data structure would
have to be redefined and, if that had to be done, starting from scratch
would be more cost effective. TW just pooh-poohed the idea; he was
the type who never thought about the next thing :-)--he was content
to leave that to us.
> So tape drives looked like disks, and so did pretty much
>everything else. This made remote devices a snap, because the system
>already encapsulated the hardware for devices and presented a uniform
>interface. The job control system calls were easier to use and more
>sophisticated. Inter-process communication was a very big item, much
>earlier than TOPS-10 had it. In fact, that part of the DECSystem-10
>IPCF (InterProcess Communication Facility) which I worked on was
>modeled after the way ITS did it.
That's why Peter was given the project (or so I thought).
>
>Finally, the operating system package was much, much smaller than
>DECs.
>
>Problems with ITS included random musings which tried to pass for
>system documentation, almost completely uncommented system code (like
>some sort of recursive sacred scripture, the code was its own
>commentary), and lack of support for any device which didn't interest
>MIT or Stanford.
>
Yea, that's curse/blessing of being in business rather than education.
What I would have liked to have seen, was the lights when ITS was
running. When Dan was developing TOPS20 on the KI, the light patterns
were almost alien to me. I wouldn't have minded using one either :-).
Thank you for the explanation. :-)
Would something like DECnet or ANF-10 have been difficult to
incorporate into the system?
/BAH
Sigh! - Subtract a hundred and four for e-mail.
jmfb...@aol.com
gag...@clark.net (Philip Gagner) wrote:
>"Chris Ward" <c...@idt.net> wrote:
>
>>
>>Daniel Seagraves wrote in message ...
>>>
>>>> controller for PDP-10s. It came out around the same time as the KA-10.
>>>> It supported multiple serial terminals. You're probably right that the
>>>> I/O instruction was conventionally DATAO TTY, but I vaguely remember
>>>> it as conventionally DATAO CON, for DATAO Console. 'course it's all in
>>>> the assignments, and was a matter of taste.
>>
>>the predecessor of the UART, that is, it read each bit and assembled a
seven
>>(or eight or whatever) bit byte by sensing the start bit, the data bits,
the
>>parity, the stop and the rest. It handled 30 or more 10CPS terminals
(110
>>baud, 2 stop bits) and 5 or so 300 bps (High Speed) terminals.
>>
>local interface--indeed at least one local controller HAD to be on an
>connected the local FE to the -10 was called a something like a DL10
>(or maybe the DL10 was only used for -11 FE's--in which case I don't
>recall waht the box was).
>
>The PDP8/I was MUCH later, and it was a general purpose computer (a
>PDP-8 in fact) which sat at the end of a network (see above). You
>could hook several terminals (I think 8 was pretty much the max) to
>it, as well as a remote lineprinter and a remote card reader. Also, it
>could handle speeds much higher than 30 CPS.
>
>several people, notably Eric Peabody. Eventually it got superceded by
>the DNx series of PDP-11 based front ends.
We're having semantic problems. The PDP-8 that was being used as
a terminal concentrator (that 8/I) was known as a 680I. It came
before the DC72 configuration. My introduction to a PDP-10 was
at a college in 1969-70 and the dialups were handled by a 680I.
jmfb...@aol.com
nos...@zk3.dec.com (Eric Werme - replace nospam with werme) wrote:
>m...@world.std.com (Megan) writes:
>
>>jmfb...@aol.com writes:
>
>
>>>Ric, I don't remember _pulling_ anything. Weren't they just
>>>the old -11 toggle switches? Geez.. this stuff is so hazed
>>>in my brain. I'm glad we're talking about real stuff :-).
>
>>The 11/40 (/35, /45, /55, /70) had essentially triangular shaped
>>switches with a rounded apex sticking out from the panel. It
>>had a pivot point located in the center of the base of the triangle.
>>In the down position, it was a zero, lift for a one...
>
>That wasn't my reference. All the momentary contact switches were
>spring loaded triangles that you pushed down and would spring back.
>Deposit was the one exception - you had to lift it up and it would
>spring down. BAH - I don't think you ever had much need to muck
>with bits on the various -11s. Rebooting them was mostly setting the
>start address in the switches and pushing load address and start.
Chuckle. That just shows how much you know :-). I was flipping
8's and 11's way before your time in a group known then as Tape
Prep. But I never got to work on that PDP-12 and I never met
a PDP-6...nor a 1.
jmfb...@aol.com
John Everett
>
>The PDP-6 sported wonderful positive action microswitches that gave a
>satisfying click when you switched them. Coupled with the brushed
>aluminum panel, you felt like you were really doing science when you
>used the machine. Dr. Who would have been proud to use them.
Switches that were shared with the PDP-4 and PDP-5, along with the blue
cabinets and brushed aluminum front panels.
Mark & Suzanne (gcs might work)
>
> In article <6viopm$9le$1...@teabag.demon.co.uk>,
> cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) wrote:
> >In article
> <Pine.NXT.4.10.981007...@tomobiki-cho.cac.washington.edu>,
> > Mark Crispin <m...@CAC.Washington.EDU> writes:
> >> ITS and TOPS-20 were both much more advanced operating systems than
> >> TOPS-10.
> >
> >Dunno about anyone else, but I'm taking cover now.
>
> Why?
I think they expecting a flame from BAH or others in this group to
tell them why TOPS-10 was really the better OS :) I guess I'd agree
with the TOPS-20 since I have more of a single CPU business approach
to thinks and like what I see as TOPS-20. But again this is unfair
since I gave never logged onto WAITS and ITS and to a lesser degree
TOPS-10 though I have a stronger fealing of who it worked (documentation
wise).
Mark :)
Aron K. Insinga
> In article <361d6c9e...@news.clark.net>, gag...@clark.net says...
> >
> >The PDP-6 sported wonderful positive action microswitches that gave a
> >satisfying click when you switched them. Coupled with the brushed
> >aluminum panel, you felt like you were really doing science when you
> >used the machine. Dr. Who would have been proud to use them.
>
> Switches that were shared with the PDP-4 and PDP-5, along with the blue
> cabinets and brushed aluminum front panels.
Oh, good, a discussion of lights and switches, a subject near and dear to my
heart!
I don't know about the exact switch types, but the watershed in packaging is the
PDP-8.
I believe that all of the earlier machines (1,4,5,6,7) had brushed aluminum
front panels,
and panels at the top of the cabinets, with toggle switches and lights in small
cylinders
with flat, translucent white tops that that stuck through a hole in the aluminum
panel and
plugged into a couple of little contacts on a circuit board under the panel. I
salvaged a
cabinet top panel from a PDP-7 with the I/O-related lights as cheap scrap from
American
Used Computer (or was it American Abused Computer? :-) in Boston near Kenmore
Sq.
long ago. The labels were silkscreened onto the aluminum panel. And of course
they
used System Modules and soldered backplanes and were packaged in relay racks,
since the panels of sockets had to be bolted into the panel before the wires
were added.
The interconnect problems of the PDP-6, the appearance of the Sylvania
wirewrap sockets and Gardner-Denver wirewrap machine, and the prospect
of building many, cheap computers on an assembly line forced changes.
Starting with the PDP-8, DEC machines had slide switches with plastic bats.
The lights and switches were on a large circuit board and shone through or
stuck through or below the silkscreened sheet of plastic with the labels on it.
On the 8, the 2 key switches (one on the right and one on the left, one for
power
and one for panel lock, I think) were *really* there to hold the sheet of
plastic in
place. At least some of this was Ken Olsen's idea. In a lecture he said that
he hung out a Lechmere (a large department store) studying the appliances to
find a cheaper way, to the point where he thought the store staff suspected him
of "casing the joint" for a possible robbery. (That might have been the talk
where
Gordon Bell introduced Ken as a packaging engineer on his staff. :-)
And of course they used Flip Chips and the wirewrapped backplanes.
Also, this is where, for the smaller machines, the package starts moving from
the
rack down to a box that fits into the rack, which let the embedded systems
market
happen. Later they added those white-edged black panels that plug onto the rack
to cover up the box.
Some of the later 11s (45, 70) might have had real toggle switches under the
bats,
but the 11/20 had slide switches like the 8s.
[Hmm, I guess that screening the plastic panel and molding the plastic bats
were what let DEC get into interesting colors for their machines. Reviving
a notable feature of the ancestral TX-0?]
My recollection is that some machines used stiffer plastic in the bats
(8, 11/10, 11/45, 11/70) while others used softer plastic (8/e, 11/20)
but I don't know for sure. Maybe someone with can say what the
plastics were. Earlier machines used flat-handled bats, while later 11s
(45, 70) used triangular bats and the metal bezel(?) around the edge of
the front panel was molded at the bottom to stick out in the same shape
as the switches. I think that was to protect the switches. Little pins
on the sides fit into holes on metal pieces on each side of the "real" switch.
Re: pushing vs. pulling somewhere in this thread: The deposit switch was usually
upside-down so that you had to flip it up above the neutral position instead of
flipping it down, to make it harder to accidently change memory. And it was
spring-loaded so it returned to its normal position.
Several machines (KA10, PDP-8/<I forget which one>, PDP-12, PDP-15 or XVM)
had the rocker switches. I was under the impression that the rocker switches
were
covers over slide switches like the bats, but I don't think I ever saw under one
to be
sure.
The KI10 was a (very nice to look at, anyway) anomoly. I don't know why it used
the push-buttons with lights in them.
There are a few PDP-11 pictures at
<http://www.eecis.udel.edu/~mader/delta/aronpics.html>
but I haven't scanned my 36-bit-family pictures yet. (RealSoonNow...)
- Aron Insinga
Al Kossow
> John Everett wrote:
>
> Some of the later 11s (45, 70) might have had real toggle switches under the
> bats,
> but the 11/20 had slide switches like the 8s.
>
11/20's used the same slide switches and handles as 8E/M
> Several machines (KA10, PDP-8/<I forget which one>, PDP-12, PDP-15 or XVM)
> had the rocker switches. I was under the impression that the rocker switches
> were
> covers over slide switches like the bats, but I don't think I ever saw under one
> to be
> sure.
8I's, 12's and 15's use rocker style slide switches
The 11/05,11/10 were the first 11's to use Alco molded switches which were used
on all subsequent front panels. These were also the same switches (sans plastic
frob) that were used on the Altair and with a frob on IMSAIs.
Mark Crispin
> jmfb...@aol.com wrote:
> > In article <6viopm$9le$1...@teabag.demon.co.uk>,
> > cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) wrote:
> > >In article
> > <Pine.NXT.4.10.981007...@tomobiki-cho.cac.washington.edu>,
> > > Mark Crispin <m...@CAC.Washington.EDU> writes:
> > >> ITS and TOPS-20 were both much more advanced operating systems than
> > >> TOPS-10.
> > >Dunno about anyone else, but I'm taking cover now.
> > Why?
> I think they expecting a flame from BAH or others in this group to
> tell them why TOPS-10 was really the better OS :)
I doubt it. All the PDP-10 OSs were fundamentally good, particularly
compared to that abomination called VMS.
> I guess I'd agree
> with the TOPS-20 since I have more of a single CPU business approach
> to thinks and like what I see as TOPS-20. But again this is unfair
> since I gave never logged onto WAITS and ITS and to a lesser degree
> TOPS-10 though I have a stronger fealing of who it worked (documentation
> wise).
Well, I have extensive programming experience on TOPS-10, TOPS-20, ITS,
Tenex, WAITS, and some of the TOPS-10 variants such as CompuServe and CMU.
Excluding Tenex (which was essentially version 0.xxx of TOPS-20), all of
these systems had unique features that made them special compared to all
the others:
TOPS-10 high performance, SMP, support for lots of CPUs (I don't
think PDP-6 support was flushed until 6 series, and KA
support wasn't flushed until 7 series) and devices.
TOPS-20 a modern OS even by today's standards, albeit hampered by
a weak shell and a programming environment that assumes
that all the world is assembly language. Better virtual
memory than any other PDP-10 OS or most modern OSs.
ITS type-independent dumb terminal support in the kernel,
albeit limited (the kernel supported two types of
Datamedias, but no ANSI terminals). PCLSR (which no
other OS has). MLDEV (user mode device drivers). Great
hacker playground.
WAITS most advanced display support of all, not duplicated even
today. Last shared code with TOPS-10 in 3.54 days, but
was extensively hacked even then. Filesystem and device
drivers were completely different (most reliable
filesystem of any PDP-10 OS, the result of the world's
worst hardware). Lots of funky devices.
Chris Ward
all I know, it may still be there....
John Everett wrote in message <6vl4lp$k3v$1...@hirame.wwa.com>...
Chris Ward
>>PDP-8/I (I think) with 32K of 12 bit words, and it was described to me as
>>the predecessor of the UART, that is, it read each bit and assembled a
seven
>>(or eight or whatever) bit byte by sensing the start bit, the data bits,
the
>>parity, the stop and the rest. It handled 30 or more 10CPS terminals (110
>>baud, 2 stop bits) and 5 or so 300 bps (High Speed) terminals.
>the TTY support and had to get intimately familiar with the little beast. I
>seem to recall on the 8/I there was a 680I which differed from the 680 in
bit
>sampling rate. I think the 680 sampled 8 times per bit, while the 680I only
>sampled 5 times. But then again that was a long time ago.
>
rates involved was related to how a UART worked, and I remember someone, or
a group of programmers at Stevens (possibly including Mr. Crispin, Mr.
Martin and others) explaining sampling to me, and the difference between 5
samples per bit and 8 samples per bit is familiar. It is hard to remember
because there was one big terminal room with 7 model 35's, and 2 model 33's
and people chatted in loud conversations over the noise. Help was not that
far away! They also had big flat tables on either side, good for printouts,
which come to think of it, I would do well to emulate!
Bill Westfield
today.
Was it WAITS that had great display support SOFTWARE, or was it just a
superior display hardare system? Certainly it would have been difficult to
do the things WAITS did with displays without near-DMA speed access to the
screen...
cisco considered building a sorta-datadisk display device as a terminal
server - you know: pack 10 "Hercules" style displays on a multibus card, and
put a bunch of them in a box with an ethernet. You'd've gotten near
ethernet display speeds at a not-horrendous cost per port, and the software
would be where we could've done neat things with it. (obviously, we never
did this. NCD came close to the concept with their X terminals.) There
still isn't an OS (other than waits?) that understands what to do with that
sort of display speed - they just all run a bunch of "ordinary" terminal
windows. (actually, I'm not sure what I'd do with it either.) Not many
applications use it effectively either, dispite 15 years of having the
technology available in the PC arena.)
(I may have to take that back - I think IBM does some reasonable things with
their 3270-style terminals, and at least they have full language support for
displays via CICS...)
BillW
--
(remove spam food from return address)
Barry Shein
It's probably worth pointing out that ITS had a working network file
system in the late 1970's or thereabouts.
I remember when someone decided that I really ought to be running
macsyma on MIT-MC rather than MIT-AI (more memory, and AI was a KA, MC
a KI) so gave me an account on MC and I thought, hmm, what about my
files, but there they were!
Today we wouldn't think twice about this but at the time I was
astounded when I realized what was going on, that the disk was just
transparent across the network.
--
-Barry Shein
Software Tool & Die | b...@world.std.com | http://www.world.com
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
jmfb...@aol.com
<Pine.NXT.4.10.981009...@Tomobiki-Cho.CAC.Washington.EDU>,
Mark Crispin <m...@CAC.Washington.EDU> wrote:
>On Fri, 9 Oct 1998, Mark & Suzanne (gcs might work) wrote:
>> jmfb...@aol.com wrote:
>> > In article <6viopm$9le$1...@teabag.demon.co.uk>,
>> > cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) wrote:
>> > >In article
>> >
<Pine.NXT.4.10.981007...@tomobiki-cho.cac.washington.edu>,
>> > > Mark Crispin <m...@CAC.Washington.EDU> writes:
>> > >> ITS and TOPS-20 were both much more advanced operating systems than
>> > >> TOPS-10.
>> > >Dunno about anyone else, but I'm taking cover now.
>> > Why?
>> I think they expecting a flame from BAH or others in this group to
>> tell them why TOPS-10 was really the better OS :)
>
>I doubt it. All the PDP-10 OSs were fundamentally good, particularly
>compared to that abomination called VMS.
Yea, well, my first impression of VMS was that it was terribly
senile (that left no time for maturity). However, people who
haven't had any other exposure to a timesharing system like VMS
because of its on-line help. I suppose VMS has to have improved
because the PDP-10ers infiltrated the group :-). Now that I've
announced my bias ....
>
>> I guess I'd agree
>> with the TOPS-20 since I have more of a single CPU business approach
>> to thinks and like what I see as TOPS-20. But again this is unfair
>> since I gave never logged onto WAITS and ITS and to a lesser degree
>> TOPS-10 though I have a stronger fealing of who it worked (documentation
>> wise).
>
>Well, I have extensive programming experience on TOPS-10, TOPS-20, ITS,
>Tenex, WAITS, and some of the TOPS-10 variants such as CompuServe and CMU.
>Excluding Tenex (which was essentially version 0.xxx of TOPS-20), all of
>these systems had unique features that made them special compared to all
>the others:
>
>TOPS-10 high performance, SMP, support for lots of CPUs (I don't
> think PDP-6 support was flushed until 6 series, and KA
> support wasn't flushed until 7 series) and devices.
Right. One of the reasons I preferred TOPS-10 was because I could
get my work done (and I usually had 3-4 projects going at once).
I never did a timing but I eventually had the final "make the tapes
for SDC" procedures down to a point that I think I could do a complete
TOPS-10 submission build in eight hours (but only if the monitor
didn't crash). And TOPS-10 was my baby :-).
I would work on the -20 in the early morning hours when TW had
all our -10s stand-alone. But, as soon as somebody else logged
in (those people didn't work nights), I left because the
performance degraded to the point where I was swearing for the
at-sign after exiting from the editor.
>
>TOPS-20 a modern OS even by today's standards, albeit hampered by
> a weak shell and a programming environment that assumes
> that all the world is assembly language. Better virtual
> memory than any other PDP-10 OS or most modern OSs.
I hated the user interface; it required too much typing. On the other
hand, I preferred the UUO (oops, JSYS) interface to TOPS-10's. It was
much, much easier to code a user mode program in assembly language on
the -20 than on the -10...especially I/O.
<snip ITS due to lack of experience>
>WAITS most advanced display support of all, not duplicated even
> today. Last shared code with TOPS-10 in 3.54 days, but
> was extensively hacked even then. Filesystem and device
> drivers were completely different (most reliable
> filesystem of any PDP-10 OS, the result of the world's
> worst hardware). Lots of funky devices.
Would you explain why its filesystem was more reliable? I think I'm
trying to get at the difference in philosophies more than the
details of the implementations.
jmfb...@aol.com
"Mark & Suzanne (gcs might work)" <SPAMO...@s054.aone.net.au> wrote:
>jmfb...@aol.com wrote:
>>
>> In article <6viopm$9le$1...@teabag.demon.co.uk>,
>> cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) wrote:
>> >In article
>>
<Pine.NXT.4.10.981007...@tomobiki-cho.cac.washington.edu>,
>> > Mark Crispin <m...@CAC.Washington.EDU> writes:
>> >> ITS and TOPS-20 were both much more advanced operating systems than
>> >> TOPS-10.
>> >
>> >Dunno about anyone else, but I'm taking cover now.
>>
>> Why?
>
>I think they expecting a flame from BAH or others in this group to
>tell them why TOPS-10 was really the better OS :)
<snip preferences>
Ah! Well, I don't have to fight for funding now so there's no
reason to flame. But I didn't say I wouldn't fight about it :-)))).
David M. Razler
The official designation of the PDP8/I "world's largest UART" was DCA-680,
and, if I remember correctly, it was not exactly 100% a DEC product
(developed, if I remember the nameplate on the LIRICS KA-10 unit properly) by
Digital Communications Associates, hence the designation.
The DCA-680 could handle at least 72 Bell Datapump standard connections (I
believe the standard number was 103) of up to 300 baud, symetric, each. Most
lines ran slower, at 110 baud because of the common use of ASR-33 Teletypes at
the far end.
It also accepted multiple-line connections into early MUX's for transmission
over leased lines with the greatest of ease.
The system had some neat features - especially the ability, by throwing one
bit switch on the constantly-monitored 8/I front panel, to give the 8/I CTY
the ability to link directly to a given terminal.
With 72 high school users frequently trying rather poor attacks on the LIRICS
system, it was a great way to scare some would-be hacker to near-death when
the KA-10 DAEMON indicated someone was attempting to break the system. (click,
input port number, type "the machine is not happy with you")
Ahhh for the good old days...
dmr
David M. Razler
david....@worldnet.att.net
Mark H. Wood
: The terminal controller for the PDP-10 that I remember was actually a
: PDP-8/I (I think) with 32K of 12 bit words, and it was described to me as
Don't forget the PDP11-based DC76. We had two of these on a KL10D(?)
(carried over from a KI system I think, but I wasn't let into the
machine room back then) and I think we then carried 'em over somehow
to a pair of KL10Es. Very nice, but they'd get "funny" after a while
and Field Service would come out and take them to bits, wipe *all* of
the card fingers with solvent, put 'em back together and then they'd
run well again for some months. (Before you ask: we were praised at
least once for the cleanliness of our machine room. Thinking about
what I usually found under the floor when running cables, I'm scared
to ask what a dirty room would've looked like.)
--
--
Mark H. Wood, radical centrist mhw...@ameritech.net
Having seen what's at the edges of the road, I much prefer the dead armadillos.
Mark Crispin
> WAITS most advanced display support of all, not duplicated even
> today.
>
> superior display hardare system? Certainly it would have been difficult to
> do the things WAITS did with displays without near-DMA speed access to the
> screen...
Great display hardware *and* software.
Some things (such as vector or bitmapped graphics) required a III or TV
(DataDisc) display, but most WAITS display applications worked fine on
dumb terminals. Even on dumb terminals we had the line editor, multiple
page printers, and display programs.
It's hard to explain to someone who hasn't seen it, or only saw it on a
casual basis.
Mark Crispin
> Would you explain why its filesystem was more reliable? I think I'm
> trying to get at the difference in philosophies more than the
> details of the implementations.
WAITS' filesystem was incredibly robust, with huge amounts of redundant
information. One of the people who actually worked on the filesystem code
(Ralph Gorin, Jeff Rubin, Brian Harvey, Martin Frost) would have to give
full (and authoritative) details; but I remember that all the retrieval
links had back pointers and I'm pretty sure that data blocks had retrieval
information as well. There was also a read-after-write.
All sorts of things to deal with incredibly flakey disk channels. I think
that when I first got there, they were still using the PDP-6 167 channel.
It was replaced (JBR was writing its driver code) with a Foonly channel, a
wire-wrap behemoth. It wasn't until the final days that WAITS finally got
a real channel (an RH20, using PHYSIO drivers from TOPS-20).
I remember when the Foonly channel started scribbling all sorts of lossage
on the disk. There were something like a dozen different algorithms that
the channel was using to clobber the filesystem; but they were able to
write a program to analyze a disk block, determine which algorithm had
whacked it, and then undo the damage.
I don't recall a full filesystem reload from tape ever happening on WAITS.
jmfb...@aol.com
david....@worldnet.att.net (David M. Razler) wrote:
<snip>
>It also accepted multiple-line connections into early MUX's for
>transmission over leased lines with the greatest of ease.
>
>The system had some neat features - especially the ability,
>by throwing one bit switch on the constantly-monitored 8/I
>front panel, to give the 8/I CTY the ability to link directly
>to a given terminal.
>
>With 72 high school users frequently trying rather poor
>attacks on the LIRICS system, it was a great way to scare
>some would-be hacker to near-death when the KA-10 DAEMON
>indicated someone was attempting to break the system. (click,
>input port number, type "the machine is not happy with you")
>
>Ahhh for the good old days...
Now that's a good one :-))).
Mark H. Wood
here ever use a DN92? I came across the glossy for it one day while
cleaning out old papers bequeathed by a former boss. It was an RJE
station and (I think) could also handle a few terminal lines.
(Before you ask: I don't know what became of that glossy, but I don't
throw away interesting stuff so it may turn up again.)
Mark H. Wood
: In article <6viopm$9le$1...@teabag.demon.co.uk>,
: cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) wrote:
: >In article
: <Pine.NXT.4.10.981007...@tomobiki-cho.cac.washington.edu>,
: > Mark Crispin <m...@CAC.Washington.EDU> writes:
: >> ITS and TOPS-20 were both much more advanced operating systems than
: >> TOPS-10.
: >
: >Dunno about anyone else, but I'm taking cover now.
:
: Why?
Please, everyone, note that MRC said "more advanced", not "better".
They probably were more advanced in various areas, but "better"
depends on what you, personally, want.
As for me, my favorite time was that period when we were migrating
from TOPS-10 to TOPS-20. We had brought in a brace of KL10Es to
replace an older-model KL10. We plugged the disks from the older
system into one box (cleverly named DECA::) and ran TOPS-10 on it,
then plugged some new disks into the other box (DECB::) and began
figuring out TOPS-20. Gradually we moved users from one environment
to the other, until they were all converted. Then we split them
between the two machines again and ran TOPS-20 on both -- one system
for students, one for faculty/staff.
At first I disliked the thought of moving to TOPS-20. It looked like
it did way too much hand-holding. Then I began programming on it and
found it quite nice. I really enjoyed having *both* OSes at my
fingertips. I was sad the day we took down TOPS-10 for the last time,
but they were both good helpful OSes.
}HERESY ON{
Later I had to go through the same process with VMS by the time our VAX
8800 arrived. The 780 seemed like a toy compared to a KL, and then
they kept making VAXen *smaller*. I was present at the unveiling of
the 8600 model in Indianapolis (it probably happened somewhere else
first :-) and, when I saw how familiar the in'ards were, I thought
maybe it wouldn't be so bad. Eventually I developed a style for VMS
programming and grew to love it *too*.
}HERESY OFF{
Now I miss them *all*. The Powers That Be are taking out our VAX 7620
and replacing it with a whole roomful of Microsoft-spawned
abominations that are no match, in stability or control, for any DEC
system we ever owned. Sic transit gloria mundi
Al Kossow
>>here ever use a DN92? I came across the glossy for it one day while
>>cleaning out old papers bequeathed by a former boss. It was an RJE
>>station and (I think) could also handle a few terminal lines.
>>
>>(Before you ask: I don't know what became of that glossy, but I don't
>>throw away interesting stuff so it may turn up again.)
The unit I used in 1980 was an RJE to a dual KI at the Air Force Avionics
Lab in Dayton. It was 8E based, had a line printer, card reader, and
several serial lines. If memory serves me right, you booted it from
the card reader; I don't remember any other periperals on it that you
could boot from.