I have just obtained a pdp-6/10 program that I very much want to try.
Specifically, the ancient MacHack VI chess program.
More specifically, the two versions available on these pages. (Tape images
are available, of course.)
http://pdp-10.trailing-edge.com/decuslib10-01/index.html
http://pdp-10.trailing-edge.com/decuslib20-02/index.html
(Does anybody know of any other tapes etc. with chess programs for the PDP
systems? I'd like to hear about it. I already know about CheckMo-II.)
I know nothing about the PDP and I need some help.
First and foremost, I want to get the program up and running under a
simulator.
What Windows based emulator should I choose?
What operating system goes on the PDP-10?
How do I load it?
(Better yet... are there any prebuilt disk images ready to use under the
emulator?)
Then, how do I get the chess program off the tape image?
Then how do I run the program itself?
I'm not wanting to become an expert in the PDP. Just simple instructions so
I can play with the program. (Mostly to make sure it works, and partly
because that way I can say I've done it.)
If anybody can give me explicit instructions, that'd help.
Or, better yet, would anybody would be kind enough to make up a pre-made
disk image for both versions of the chess program, so that way anybody could
run the program easily? (If not, then instructions will do.)
But again, I'm not familiar with the PDP, its OS, etc. or the PDP emulators
available.
I have used emulators before... VMWare and Qemu, for example. Plus a few
for old 8 bit micros. But not for the PDP.
Finally, does anybody know of any PC based assemblers and disassemblers for
the PDP-6/10?
I'd like to try and disassemble that sucker back into something vaguely
readable. (Yes, I know that's a big task. I've done that before for
programs on my old 8-bit micro.)
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
I doubt there are any.
> I'd like to try and disassemble that sucker back into something vaguely
> readable. (Yes, I know that's a big task. I've done that before for
> programs on my old 8-bit micro.)
The original source code is likely to still be around somewhere. I
used to have the source for CHAOS, which was a close relative.
Note that PC based emulators are so much faster than real pdp-10's
that playing vs MacHack VI would be quite a bit different than in the
old days.
> I have just obtained a pdp-6/10 program that I very much want to try.
> Specifically, the ancient MacHack VI chess program.
> I know nothing about the PDP and I need some help.
>
> First and foremost, I want to get the program up and running under a
> simulator.
>
> What Windows based emulator should I choose?
I use KLH's.
I have run this under Windows, just to see if it works.
But I really run it under Linux.
> What operating system goes on the PDP-10?
These particular programs were on ITS.
> How do I load it?
> Then, how do I get the chess program off the tape image?
> Then how do I run the program itself?
>
> I'm not wanting to become an expert in the PDP. Just simple instructions so
> I can play with the program. (Mostly to make sure it works, and partly
> because that way I can say I've done it.)
In the old days, you had to become something of an expert to use a
computer system like this. These computers were not designed to be
easy to use, by today's standards. By wanting to run these old systems,
you are trying to return to the nostalgia of the old days.
> Finally, does anybody know of any PC based assemblers
> and disassemblers for the PDP-6/10?
> I'd like to try and disassemble that sucker back into something
> vaguely readable. (Yes, I know that's a big task.
> I've done that before for programs on my old 8-bit micro.)
I don't know what you mean.
A PDP-6/10 is nothing remotely like any 8-bit microcomputer
or any 32/64-bit PC descendants that people use today.
If you load the program into DDT (the debugger) under ITS,
it will disassemble the machine instruction codes for you.
Okay.
>> What operating system goes on the PDP-10?
>
> These particular programs were on ITS.
Okay. I didn't know that.
> In the old days, you had to become something of an expert to use a
> computer system like this. These computers were not designed to be
Yeah, I know!
> easy to use, by today's standards. By wanting to run these old systems,
> you are trying to return to the nostalgia of the old days.
I'm not wanting to run the system.
I'm wanting to run the program.
I don't really have any nostalgia for the system itself, but for that
particular program.
>> Finally, does anybody know of any PC based assemblers
>> and disassemblers for the PDP-6/10?
>
>> I'd like to try and disassemble that sucker back into something
>> vaguely readable. (Yes, I know that's a big task.
>> I've done that before for programs on my old 8-bit micro.)
>
> I don't know what you mean.
> A PDP-6/10 is nothing remotely like any 8-bit microcomputer
I was meaning that I have experience doing that back in the days of when I
was using an 8 bit micro. And that yes, I know it's a pain in the ass.
But that if I had reasonable tools, I might give it a try anyway.
> or any 32/64-bit PC descendants that people use today.
>
> If you load the program into DDT (the debugger) under ITS,
> it will disassemble the machine instruction codes for you.
I don't know DDT.
But I suspect that for a program this large, I need more than a simple
debugger.
I was hoping... Oh well.
>> I'd like to try and disassemble that sucker back into something vaguely
>> readable. (Yes, I know that's a big task. I've done that before for
>> programs on my old 8-bit micro.)
>
> The original source code is likely to still be around somewhere. I
I don't think so...
> used to have the source for CHAOS, which was a close relative.
Really???!!! I don't suppose you still have it, do you?
I've been trying to collect old chess programs for years, but most have just
disappeared.
> Note that PC based emulators are so much faster than real pdp-10's
> that playing vs MacHack VI would be quite a bit different than in the
> old days.
I know. That's fine. That's not really the point.
The point is, the program was found and I would get a chance to play it.
The computer chess community had thought the program was lost forever, so
actually finding it was exciting.
Some are probably still around. Tech II is probably still around too.
> The computer chess community had thought the program was lost forever, so
> actually finding it was exciting.
Has anyone asked Greenblatt?
They might be... but if so, you've got to find the right people to ask who
knows where they are at.
The authors of most of the old programs have disappeared. When you think
about it, it's been 30 years, and many of them are 60+ years old and have
simply retired and disappeared.
Just tracking them down can be a heck of a challenge.
Then when you do, it turns out that they no longer have a copy. The old
systems have long since been retired and the only copy they still had might
be a printout which disappeared years ago.
I've contacted a few of the authors of the old programs (not all, I couldn't
find most), and so far, nobody has kept a copy of their old 30 year old
programs.
The best they can say is they might still have an executable some where, or
that they gave some people a copy and that they might still have a copy
after all these years...
Tony Marsland supposedly had a decent collection of programs, but the last
few messages to him didn't get a reply.
Robert Hyatt used to have a collection, including MacHack VI source, CoKo IV
source, Chess 4.9 source and others. But they've gotten thrown out over the
years. He says he doesn't even have a copy of his old Blitz or early Cray
Blitz anymore. People just weren't making any effort to keep them. Even
the authors often didn't.
>> The computer chess community had thought the program was lost forever, so
>> actually finding it was exciting.
>
> Has anyone asked Greenblatt?
I don't know where he is.
I've never encountered any current reference to him. Although I do have to
admit that I haven't done any hunting for authors in over a year.
I've gotten the impression that he no longer is alive, but nobody has come
out and said that.
As I said though... I haven't done any hunting for anybody in about two
years. Finding a copy of MacHack 6 was simply pure chance.
Path of least resistance is likely to run the TOPS-20 "port" via an
account at twenex.org. They seem to have it installed, even (it's
called "chess"), although I only discovered this after copying over
the .EXE from the DECUS tape. Oops. :P
Anyway, it seems to do stuff:
@chess
_bd
WR WN WB WK WQ WB WN WR
WP WP WP WP WP WP WP WP
-- ** -- ** -- ** -- **
** -- ** -- ** -- ** --
-- ** -- ** -- ** -- **
** -- ** -- ** -- ** --
BP BP BP BP BP BP BP BP
BR BN BB BK BQ BB BN BR
_
?PA1050: Illegal instruction 6,,2 at user 0
(I pressed ^C there...something's not quite right.) Entering "ps" causes
moves to be made, though, so I imagine it's working.
--
David Evans
Faculty of Computer Science dfe...@bbcr.uwaterloo.ca
Dalhousie University, Halifax, Canada http://bbcr.uwaterloo.ca/~dfevans/
Thanks for telling me! Saves quite a bit of effort.
> ?PA1050: Illegal instruction 6,,2 at user 0
>
> (I pressed ^C there...something's not quite right.) Entering "ps" causes
> moves to be made, though, so I imagine it's working.
Hmmm... Well.. . Not like I can fix it...
Thanks for the help.
I have this running on my simh. Since the simulators we are running are much
faster than the old KL10's we can set the search depth way up!
So you'd grab decuslib10-01.tap.bz2 and bunzip2 it to make a .tap file. Then
you'd use the console commands to connect that .tap file to your tape drive.
In simh:
sim> at tu0 decuslib10-01.tap
sim> continue
.R BACKUP
/TAPE MTA
/INTERCHANGE
/FILES
/REWIND
/RESTORE *.*=MTA0:CHESS.*
! CHESS HOW
CHESS SAV
"Done
/EXIT
.RUN CHESS.SAV
_pb
_p-k4
_B P/K2-K4
....
Now with respect to the disassembly of machack, you can play with DDT and do
a reasonable job. The problem (if I recall correctly) was that machack's
binary code did a LOT of indirect addressing. This created a huge problem
for disassembly.
Yes it would be nice to get source code for these gems. The people that do
have them may wait too long to let go.
Later
Mark Hittinger
bu...@pu.net
He's still around, I'm pretty sure. I last saw him a few years ago.
Someone on this newsgroup probably has his email address.
Well, if it blows up on ^C when running on an emulation layer for an
OS other than the one it was written for, I think it's doing OK,
personally. :) FWIW, it seemed to survive ^C while it was computing
moves.
I'll ask him tomorrow.
Oh wow!!! Yes, please do!
I guess I am really going to have to start getting serious about collecting
these chess programs.
I've asked around before but never made much progress.
Bob Hyatt said he used to have CoKo IV, MacHack VI and a few others, but no
longer does. Other authors have made similar comments about their
collections and their own programs.
Tony Marsland had a collection and we discussed it, but he was busy and
suggested I contact him after the academic year was over. I tried several
times then but never got any further response.
Most of the authors I could never track down. Maybe now with Google & Yahoo
doing more pages than ever I might actually be able to find a few of the
authors. Tech, Chaos, Awit, CoKo, MyChess, and whatever else...
It's really incredible....
MacHack VI is... well, one of the most important chess programs in computer
history. I know there are better programs today. That's not the point.
The point is that it's so historically significant.
Yeah, MacHack VI was a hack. (That's where the 'hack' part came from. A
chess 'hack' in project 'Mac'.) But it was an important hack.
In the computer chess world, we thought we had lost MacHack VI years ago.
That it was lost forever.
I was absolutely amazed when I discovered it in the PDP archives.
But yet here you pdp people are actually using it and are quite familiar
with it! It's no big deal to you.
Incredible!
Makes me wonder if the IBM-704 fans still have Arthur Samuel's Checkers
program!
Thanks to everybody.... You people have been lots of help and friendly
too....
I assume you mean 'cont'
When I do that, the simulator hangs.
Shouldn't I have some sort of disk image or OS image first?
I think you said ITS, right?
It looks like there are some instructions linked to from the Simh home page.
Those directions don't match what Simh seems to expect.
I guess there isn't any pre-done image?
I appologize if I'm just not understanding.... I've never used a PDP and am
totally unfamiliar with it.
> First and foremost, I want to get the program up and running under a
> simulator.
> What Windows based emulator should I choose?
> What operating system goes on the PDP-10?
> How do I load it?
The following webpage should help you with some of your initial questions.
http://www.aracnet.com/~healyzh/pdp10emu.html
Zane
> So you'd grab decuslib10-01.tap.bz2 and bunzip2 it to make a .tap file.
> Then
> you'd use the console commands to connect that .tap file to your tape
> drive.
Okay.
I follwed the instructions at:
http://www.cosmic.com/u/mirian/its/itsbuild.html
Things seem to work.
> In simh:
>
> sim> at tu0 decuslib10-01.tap
> sim> continue
Before I start its? Or does it matter?
> .R BACKUP
> /TAPE MTA
Those are the point where things go wrong.
First, is that a dot r?
Second, when I do "/tape" right after entering the / it asks "job?"
So I'm not doing something right.
> /INTERCHANGE
> /FILES
> /REWIND
> /RESTORE *.*=MTA0:CHESS.*
> ! CHESS HOW
> CHESS SAV
>
> "Done
>
> /EXIT
>
> .RUN CHESS.SAV
>
> _pb
> _p-k4
> _B P/K2-K4
>
> ....
>
> Now with respect to the disassembly of machack, you can play with DDT and
> do
> a reasonable job. The problem (if I recall correctly) was that machack's
> binary code did a LOT of indirect addressing. This created a huge problem
> for disassembly.
>
> Yes it would be nice to get source code for these gems. The people that
> do
> have them may wait too long to let go.
>
> Later
>
> Mark Hittinger
> bu...@pu.net
Those looks like TOPS-10 commands.
While the original program may have been written for ITS, I believe
that the DECUS libraries only contain the "port" to TOPS-10 (that also
rund under the compatibility package on TOPS-20). So you'll want one
of those OSes to use these versions.
Or, as I said, just work with it on twenex.org, unless you need your
own system.
>
> Those looks like TOPS-10 commands.
>
> While the original program may have been written for ITS, I believe
> that the DECUS libraries only contain the "port" to TOPS-10 (that also
> rund under the compatibility package on TOPS-20). So you'll want one
> of those OSes to use these versions.
Okay. I guess I'll try that, then.
How compatable are ITS and TOPS-10?
When you say 'port', is it just a matter of running it, or what? Did they
have to change the program in someway, or what?
After all, you tried the one that was already set up and it didn't work
right. It caused an illegal instruction, so something doesn't seem right.
> Or, as I said, just work with it on twenex.org, unless you need your
> own system.
I went over there and started to, but I would like to get it working on my
system.
That way I can do it whenever I want. If I want to later give a copy to
somebody, it'll already be setup for them to play with, and so on.
I can't say for sure, as I've used neitgher ITS nor TOPS-10. However,
I believe that for a program that makes very mild demands of the operating
system, a port is fairly straightforward. It likely involved only minimal
changes.
>After all, you tried the one that was already set up and it didn't work
>right. It caused an illegal instruction, so something doesn't seem right.
>
Well, it seemed OK until I pressed ^C while it was waiting for input,
so it "mostly" works. It certainly seemed to do something reasonable
when I asked it to play itself, and in that situation ^C worked fine.
My guess is that something I/O-related has been fouled in the journey
from ITS to TOPS-10 to the PA1050 compatibility package used to run
TOPS-10 stuff on TOPS-20. I suspect that the main logic of the program
works fine.
[ I wrote the first bit... ]
>> Or, as I said, just work with it on twenex.org, unless you need your
>> own system.
>
>I went over there and started to, but I would like to get it working on my
>system.
>
>That way I can do it whenever I want. If I want to later give a copy to
>somebody, it'll already be setup for them to play with, and so on.
>
OK. If you plan to do that, you'll need to learn at least basic admin
skills of the OS you elect to use. It may be best to grab the "TWONKY"
system for KLH10 from here
http://klh10.trailing-edge.com/
but as we're talking TOPS-10 at this point I should really keep quiet as
I have no clue in regards to that. (And only a minimal clue wrt.
TOPS-20, to be honest!)
>> > I've gotten the impression that he no longer is alive, but nobody has
>> > come
>> > out and said that.
>>
>> He's still around, I'm pretty sure. I last saw him a few years ago.
>> Someone on this newsgroup probably has his email address.
>
> I'll ask him tomorrow.
Just wondering if you've asked him, and what he said...
I don't really expect him to still have it... Not after all these years.
(But I am hopeful...[grin])
> "Christopher C. Stacy" <cst...@news.dtpq.com> wrote in message
> news:ur7ccf...@news.dtpq.com...
>
> >> > I've gotten the impression that he no longer is alive, but nobody has
> >> > come
> >> > out and said that.
> >>
> >> He's still around, I'm pretty sure. I last saw him a few years ago.
> >> Someone on this newsgroup probably has his email address.
> >
> > I'll ask him tomorrow.
>
>
> Just wondering if you've asked him, and what he said...
>
> I don't really expect him to still have it... Not after all these years.
> (But I am hopeful...[grin])
He said it's "burried deep" in a pile somewhere, but that
he thinks he has a copy. I suggested that various people
come looking for it from time to time, and that we should
put it online somewhere. I think this will happen, but
it's not anybody's high priority.
Oh, and he also said, "No, not dead..."
Oh wow oh wow oh wow!
> come looking for it from time to time, and that we should
> put it online somewhere. I think this will happen, but
If he needs my real email address, let me know.
Since his copy is undoubtably a printout, I hope he has access to a scanner
and a good OCR program..
I've done OCRing before and was never really happy with it. It works and I
can do it, but it's a bit of an effort...
> it's not anybody's high priority.
Probably not.
I realize that most people don't care. And that most computer chess people
would find it only mildly interesting.
But it's exciting to me.
> Oh, and he also said, "No, not dead..."
[grin]
I had not actually heard anybody say that he was, but I sure had gotten that
impression.
More likely a 7-track ITS backup tape
I know of one person in the world capable of reliably recovering the
data, if 'blatt can ever find it. It's probably buried with all the
other stuff that I hear is buried in his garage.
Chris, any chance this would have made it onto the GFR tapes?
Hope it's still readable....
NASA has discovered the hardway that a lot of their tapes from the 60s and
70s are unreadable.
I've been in touch with a couple of people, and one or two of them is pertty
sure they too have a few old chess programs. Not quite as much of a classic
as MacHack VI, but old enough to be interesting.
Chess 3.x, Chess 4.x, AWIT, Blitz (ancestor to CrayBlitz), TinkerBelle
(ancestor to Belle), and so on.
I've posted a couple of messages in Computer Chess about collecting some
programs
Here's the URL, but it requires membership to read.
http://www.talkchess.com/forums/1/message.html?447344
I guess I should repost it in comp.rec.games.chess, except it seems to be
abandoned by most real computer chess people.
if needed I can be contacted at (reverse the words)
Net . cebridge -at- Carey
***
I have gotten in contact with a guy who does have a collection of old
programs. Unfortunately, he's going to be out of town for serveral weeks, so
we'll have to pick up the conversation then.
He did however say that he *may* (only *may*, no guarantee!) have:
1) Blitz from 1981 or so.
2) Awit
3) Tinkerbelle & parabelle
4) MacHack VI (executable only. No source.)
5) Chess 3.0
plus a few others.
But, we are going to have to contact the authors to get their permission to
distribute these things.
(Christopher in the pdp-10 newsgroup talked to Mr. Greenblatt and was told
that he does think he still has the source for MacHack VI!! If so, that's a
heck of a find!!)
Old programs that I currently have:
1) Sargon
2) Byte magazine Chess 0.5
3) MacHack VI executable
4) 'Chess' from Unix from 79. (Written by Ken Thompson??)
5) CheckMo-II from 1974. For pdp.
6) a few unnamed chess programs for the PDP 6, 8, and 11.
7) A few mychess executables.
8) Microchess 1
9) Sinclear zx-80 (famous only for its size.)
Not really a major collection. (I also have a few commercial ones, such as
Sargon 2, Atari 2600 chess, and a few others. But those aren't really
suitable for distribution.)
So, if you know the location of any of the chess program authors from the
late 60's, 1970s, or early 80's, let me know.
If you know the author personally, please ask them yourself about the
possibility of collection and distributing their old programs. Questions
such as that are accepted much better from somebody they know than from a
stranger.
Programs that would be nice to still find:
Tech (1 & 2)
Kaissa (not bloody likely!)
T.Belle aka TinkerBelle
Blitz & CrayBlitz
Chess 3.x & 4.x
NuChess (aka Chess 5.x)
WITA / AWIT
Chaos
Pawnking
MyChess (source, we have plenty of executables)
CoKo IV
Belle (circuit diagram and program.)
And I'm sure there are many more that aren't coming to me right off the top
of my head. It's nice if the programs are historically famous, or
significant, but actually any chess program from the 60's or mid 70's is
historically significant simply due to the age. From the mid 70s to the mid
80's, possibly, but by that time there were lots of programs.
People to look for:
David Kittenger
James Gillogy.
Robert Hyatt... (Easy to find...)
David Slate
Larry Atkin
Ken Thompson
Dennis Cooper
Ed Kozdrowicki
And I'm sure there are others who's name I can't think of right off hand. If
you know them (either personally or just know where they are at), then ask
them....
Remember, questions like these are accepted much better from people they
know than from a stranger. And be polite!
You might also want to assure them that we have no intention of making fun
of their programming skills or anything like that. Many of these programs
were done as a hobby in whatever spare time they could find. The programs
were written only for their own use, so the quality of the code or comments
may not be the best quality.
I think all of us have early programs we are embarrased by, so why should
they be any different. The only real difference is that they were 'there'
back then, they used much more primative systems, and they were sucessful
and most of us weren't.
It's possible the computer musemu might be interested in this stuff, but we
need to collect it first.
So, if you can think of any programs that we should try to find, let me
know.
If you can think of anybody we should contact, let me know.
If you know where any of the authors are at, let me know.
If you know the authors personally, feel free to ask them.
If you have a collection... Let me know.
I may not be the best person to be 'in charge', but since there is nobody
else even making an effort, I guess it's up to me until somebody better
qualified stands up.
***
and
***
I should also add that we might be willing to accept:
1) Any articles of significance.
2) physical chess computers, if you are willing to donate them. (Fat
chance! But, if the project gains some momentum and becomes successful, then
perhaps you might consider it.)
For the articles, either the originals, or a good clean scanned electronic
copy of the original article.
Articles of interest may include... Oh, the paper by Arthur Samuel in 1959.
And his followup article. The article by the Spraklens. Byte Chess 0.5's
article. The chapter about Chess 4.5, since that influenced so many
programs. And whatever else. Too many to think of right off hand.
More physical items might include actual computer chess books or copies of
the JICCA that you might want to donate. (However, again, due to their
physical nature, we wouldn't be able to post these on the web. *IF*, and
that is *IF*, we get enough physical stuff to have a physical archive, and
we are actually sucessful in our archiving attempt, then perhaps you might
want to consider it.)
(Even at this early stage, we'll still accept physical stuff. Whether it's
phyiscal copies of chess programs, old chess computers, manuals, books, etc.
I was just meaning that you might feel more comfortable waiting to see if
our archiving attempt is sucessful before donating anything physical. After
all, it's entirely possible this effort will fizzle out, just like past
attempts by other people.)
***
First and foremost, there is more than one OS for the PDP-10, just as there are
several different families of PDPs, so asking "what OS runs on the PDP?" is not
going to get a simple answer.
On the PDP-10, the three operating systems which can be run on the two main
emulators (SimH and KLH10) are Tops-10, Tops-20, and ITS. These three OSes
share no code among themselves; in point of fact, until the last releases of
the DEC operating systems (Tops-10 and Tops-20), the systems did not even share
microcode--and ITS never used the same microcode as Tops-10 or Tops-20 on the
hardware that the emulators mimic.
Next, the DECUS tapes contain an executable for Tops-10. This is apparently a
port of the ITS program, which in this case means different system calls for
everything--almost a re-write rather than a simple port.
I have a disassembler for Tops-10 and Tops-20 executables that runs on Tops-20,
written in Pascal. If you want to have a look at it, go to PDPplanet.org and
follow the links to request an account on our Toad-1, then send me e-mail and
I'll make it available to you. We already have the DECUS library on-line on
the Toad-1, so you don't have to worry about getting the program there. I'll
make the source available if you want to try porting a 36-bit disassembler to
an 8-bit machine.
--
Rich Alderson | /"\ ASCII ribbon |
ne...@alderson.users.panix.com | \ / campaign against |
"You get what anybody gets. You get a lifetime." | x HTML mail and |
--Death, of the Endless | / \ postings |
> First and foremost, there is more than one OS for the PDP-10, just as
> there are
> several different families of PDPs, so asking "what OS runs on the PDP?"
> is not
> going to get a simple answer.
I think I originally asked about the OS for that program, rather than how
many OS's ran on the PDP-6.
But yeah, it is a bit confusing when you aren't familiar with the PDP.
> Next, the DECUS tapes contain an executable for Tops-10. This is
> apparently a
> port of the ITS program, which in this case means different system calls
> for
> everything--almost a re-write rather than a simple port.
I was originally told ITS, so that's what I spent so much effort on...
I haven't really tried Tops-10 because I've been preocupied with other
stuff. (Well, I did spend a few minutes, but nothing sucessful. Less than
an hour, some of which was reading manuals.)
Realistically, I should go ahead and work on it again. Get everything set
up so that when we do set up the archive, we can give a disk image ready to
be downloaded by the user and explicit instructions on how to actually run
it.
> I have a disassembler for Tops-10 and Tops-20 executables that runs on
> Tops-20,
> written in Pascal. If you want to have a look at it, go to PDPplanet.org
> and
Considering I haven't gotten machack VI to even run yet, I'm definetly not
ready for doing any kind of work actually under on the pdp.
I'd be much more comfortable using a PC based tool to disassemble and
reassemble (to make sure my disassembly is right.)
However, I've done complete disassemblies before. Back in my old 8-bit
days. Beyond just a simple disassembly, but the full thing to recreate
reasonable source code.
It's not fun. Not in the slightest.
I think I'd much rather give Mr. Greenblatt a chance to find and recover the
original source!
Don't hold your breath.
There is some code-sharing between Tops10 and Tops20. Tops20 has
a "tops10-user-mode-support" package called PA1050. This is needed
to run some of the utilities to build Tops20 itself. (how do you
describe PA1050 without invoking the "emulator" word?)
The monitor ("Kernel" for the kiddies born after 1965) of Tops20
is developed in complete separation from Tops10; and in fact
came from outside DEC.
>Next, the DECUS tapes contain an executable for Tops-10. This is apparently a
>port of the ITS program, which in this case means different system calls for
>everything--almost a re-write rather than a simple port.
>
>I have a disassembler for Tops-10 and Tops-20 executables that runs on Tops-20,
>written in Pascal. If you want to have a look at it, go to PDPplanet.org and
>follow the links to request an account on our Toad-1, then send me e-mail and
>I'll make it available to you. We already have the DECUS library on-line on
>the Toad-1, so you don't have to worry about getting the program there. I'll
>make the source available if you want to try porting a 36-bit disassembler to
>an 8-bit machine.
I think I'll follow those links myself!
-- mrr
That's encouraging... [grimace]
Seriously though... I've done full reverse disassemblies before. (Actually,
some of it was for the 6809 cpu, and I've been told that the 'flavor' of the
instructions are similar to what the PDP's had. Don't know if that's true,
though.) Recreating constants, comments, etc. It's not fun. And doing it
on a system that I'm not familiar with would be worse.
It's easy to do a simple disassembly. But to figure out what the constants
are, add some comments and so on... That's a heck of a lot of effort.
I would rather wait for Greenblatt.
MAYBE if we are successful in collecting a few of the classics back from the
70's, he might feel a bit of urge to help. Or maybe a few chess programmers
from the 70's might ask him to help. I know two people from computer chess
in the 70's that might be willing to contact him, once we start making some
progress.
But as I said, since I do know that it's possible the source still exists
and might still be readable, I'd much rather wait a bit on him than trying
to do a full disassembly myself.
It may turn out to not be readable... And the odds get worse every month
that goes by. As I said, NASA has discovered the hard way that a lot of
their old tapes from the 60's and 70's are not readable or partially
damaged. And that's in a controlled storage environment. Many are fine,
but quite a few aren't.
Stuck at the bottom of a pile in a musty, damp garage...[shudder] The only
way conditions would be worse was if it was paper tape and was stored in a
damp basement. Or a tape / disk stored next to a tv.
> Seriously though... I've done full reverse disassemblies before. (Actually,
> some of it was for the 6809 cpu, and I've been told that the 'flavor' of the
> instructions are similar to what the PDP's had. Don't know if that's true,
> though.) Recreating constants, comments, etc. It's not fun. And doing it
> on a system that I'm not familiar with would be worse.
OK, that's what I was trying to warn you about in my previous follow-up. There
is no such thing as "the PDP" in the sense you mean here.
The 6809 instruction set is vaguely similar to the PDP-11 family's instruction
set, so you might not feel too uncomfortable with the latter: 16-bit words in
8-bit bytes, small number of instructions, etc. etc. It bears no resemblance
to the PDP-10 at all.
The PDP-10 (and the PDP-6 before it), on the other hand, is a 36-bit word-
oriented architecture in which entities smaller than the word ("bytes") are
defined within a word-long data structure called a byte pointer. (These may be
anywhere from 1 to 36 bits in length.) There are several hundred instructions
defined in the architecture, with a 9-bit opcode length, 4-bit accumulator and
index fields, an indirect bit, and an 18-bit address/immediate field. Just
representing the data accurately will be a challenge for any PC-based tool.
Any just for completeness' sake, there were 12-bit (PDP-5/PDP-8/PDP-12) and
18-bit (PDP-1/PDP-4/PDP-7/PDP-9/PDP-15) families of "PDPs" as well, none of
which was particularly similar to the 6809, either.
Finally, I'm not convinced that the original MACHACK VI was even an ITS program
--RG could very easily have written it to the bare metal on the PDP-6. (Chris,
do you know for sure that it ran under ITS?)
> OK, that's what I was trying to warn you about in my previous follow-up.
> There
> is no such thing as "the PDP" in the sense you mean here.
I know, I know.
It's just a lot easier to use over generalizations for this simple level of
discussion.
> The 6809 instruction set is vaguely similar to the PDP-11 family's
> instruction
> set, so you might not feel too uncomfortable with the latter: 16-bit
> words in
Yeah. Not identical etc, of course. Just the 'flavor'.
Realistically it doesn't make too much difference because I don't really
want to do that kind of stuff if I don't have to.
> 8-bit bytes, small number of instructions, etc. etc. It bears no
> resemblance
> to the PDP-10 at all.
Well, the program was originally written for the PDP6/11 and then ported to
PDP10.
As
> The PDP-10 (and the PDP-6 before it), on the other hand, is a 36-bit word-
> oriented architecture in which entities smaller than the word ("bytes")
> are
> defined within a word-long data structure called a byte pointer. (These
> may be
> anywhere from 1 to 36 bits in length.) There are several hundred
> instructions
> defined in the architecture, with a 9-bit opcode length, 4-bit accumulator
> and
> index fields, an indirect bit, and an 18-bit address/immediate field.
> Just
> representing the data accurately will be a challenge for any PC-based
> tool.
Probably.
But at this point, it's not really that big of an issue for me. Since I'm
not actually starting to disassemble anything, it doesn't matter too much.
> Finally, I'm not convinced that the original MACHACK VI was even an ITS
> program
> --RG could very easily have written it to the bare metal on the PDP-6.
> (Chris,
> do you know for sure that it ran under ITS?)
I really don't know.
Most of my reliable stuff just says it was written in MIDAS for the pdp6 and
that it later ran on the PDP11 and PDP 10.
Later stuff could easily be asumptions as to what OS (if any) it ran on, or
a later version that had been ported.
Not much telling what the original version did, or what particular version
was on that pdp site, or what particular version Mr. Greenblatt has.
If you have to do a disassembly ITS of Tops20 would be about
as favourable environments as you can get. Fire up DDT and
see if you have a symbol table.
I have myself written programs "to the bare metal" on Tops20.
Some ITS or Tops20 programs never had source code.
-- mrr
...although they can lead you to what I suspect to be very incorrect
conclusions. For example:
>Well, the program was originally written for the PDP6/11 and then ported to
>PDP10.
>
I don't believe this. The PDP-6 and PDP-11 have very little in
common in terms of architecture, while the PDP-10 is basically a
beefed-up PDP-6. I suppose two versions---one for the PDP-11 and one
for the PDP-6---could have been written in parallel and then the PDP-11
one put out to pasture, but that seems a unlikely.
Anyway, this is exactly one occasion where being very particular
about which PDP you're discussing matters. Given that the term "PDP"
was invented as a pseudo-synonym for "computer", it is not too
surprising that they are very different. You may also find that
the various PDP camps are somewhat territorial, especially when one
starts talking about the "PDP-11/780". :P
> >On the PDP-10, the three operating systems which can be run on the two main
> >emulators (SimH and KLH10) are Tops-10, Tops-20, and ITS. These three OSes
> >share no code among themselves; in point of fact, until the last releases of
> >the DEC operating systems (Tops-10 and Tops-20), the systems did not even share
> >microcode--and ITS never used the same microcode as Tops-10 or Tops-20 on the
> >hardware that the emulators mimic.
>
> There is some code-sharing between Tops10 and Tops20. Tops20 has
> a "tops10-user-mode-support" package called PA1050. This is needed
> to run some of the utilities to build Tops20 itself. (how do you
> describe PA1050 without invoking the "emulator" word?)
PA1050 is a syscall emulation layer, working in much the same way
the linux emulation layer in FreeBSD does. In fact it is possible
to do it the other way around, I remember conjuring up something
called PA2020 for the sole purpouse of running a Tops-20 program
(called zork.exe) on Tops-10 a long time ago...
As for code-sharing, the DECnet code is common between the topses,
modulo a bunch of conditionals.
> -- mrr
--Johnny
I don't think the PDP-11 had anything to do with it "originally".
> and then ported to PDP10.
PDP-6 programs generally don't need to be "ported" to the PDP-10; the PDP-10
architecture is a superset of the PDP-6 architecture excepting only a few
very minor differences.
It could well have been "ported" to the PDP-11 at some point, though such
a por" would more likely be a rewrite, as the PDP-11 is completely
different than the PDP-10 in almost every respect.
As Rich Alderson has pointed out, the 6809 instruction set does have the
same general flavor of the PDP-11 instruction set. But both have a
completely dissimilar flavor to any other PDP models, especially the
PDP-6 and PDP-10.
[shrug]
I wasn't there.
I can only say what I've read about it.
> Anyway, this is exactly one occasion where being very particular
> about which PDP you're discussing matters. Given that the term "PDP"
Actually, no, it does NOT matter.
Really... Are you about to do a full disassembly of it?
I'm not. At least not right now. Not as long as there is even a chance of
the original source being retrieved.
So at this point, even though I'm wrong, it's "good enough".
I do realize that you people in here care a lot more about the various PDP
systems than I do. The only reason I'm here is because of the program.
> was invented as a pseudo-synonym for "computer", it is not too
I wouldn't go that far....
> surprising that they are very different. You may also find that
> the various PDP camps are somewhat territorial, especially when one
> starts talking about the "PDP-11/780". :P
Hey, I used a PDP-11/785... does that count...[grin]
Not "originally". No.
Originally it was strictly PDP-6.
But it did have quite a life and ran on several pdp architectures, as well
as the CHEOPS hardware.
>> and then ported to PDP10.
>
> PDP-6 programs generally don't need to be "ported" to the PDP-10; the
> PDP-10
"Ported" was probably the wrong word.
> It could well have been "ported" to the PDP-11 at some point, though such
> a por" would more likely be a rewrite, as the PDP-11 is completely
> different than the PDP-10 in almost every respect.
From what I gather, that was done a few times.
MacHack VI wasn't simply one program that sprang into existance. It evolved
quite a bit until he put it away for good.
That's why I've said that I didn't know which particular versions those
decus tapes had. Other than for the pdp-10, of course.
No, of course not. But I maintain that it matters for other reasons.
>I do realize that you people in here care a lot more about the various PDP
>systems than I do. The only reason I'm here is because of the program.
>
The PDP-10 and PDP-11 were not only different in architecture, they
were substantially different in scale. The PDP-10 was a "big" machine,
often used with lots of disk attached, a fair amount of memory (256KW
was not uncommon, I believe, and 4MW was around at the end). They were
expensive, and institutions usually didn't have many of them.
The PDP-11, on the other hand, was a "little" machine. It was
designed to be small and affordable, the sort of thing that a workgroup
might have or that you might give to your grad students to work the lab
with once the PDP-8 ran out of steam. The address space was 64KB and,
while up to 4MB of memory could be installed in the larger machines,
that was not universally done and not every model of PDP-11 could support
it. Furthermore, 4MB is approximately less than a quarter of a PDP-10's
4MW.
So, the question arises, what approaches might have been used when
writing a chess program for these two environments? Are the same
algorithms applicable to each case? Were interesting secondary storage
schemes used? Were downright compromises made to make the program run
on small machines? Were the lessons learned while adapting the system
to scarce resources then applied to the "big iron" version to make it
even better? Did addressing these issues advance the state of the art
of computer chess?
I have no idea what the answers are, of course, and I'm not saying
that you should either. However, they seem like the sorts of questions
that a computer chess historian might ask, and the questions might not
present themselves without an awareness of the difference between a
PDP-10 and a PDP-11. However, all of this is, as you say, entirely
irrelevant to building a collection of programmes.
I'm not trying to be an ass here; trying to put some context behind
what you're investigating may even allow you to spark more interest in
original authors and yield programme copies that you're looking for.
> Morten Reistad <firs...@lastname.pr1v.n0> writes:
>> There is some code-sharing between Tops10 and Tops20. Tops20 has
>> a "tops10-user-mode-support" package called PA1050. This is needed
>> to run some of the utilities to build Tops20 itself. (how do you
>> describe PA1050 without invoking the "emulator" word?)
> PA1050 is a syscall emulation layer, working in much the same way
> the linux emulation layer in FreeBSD does. In fact it is possible
> to do it the other way around, I remember conjuring up something
> called PA2020 for the sole purpouse of running a Tops-20 program
> (called zork.exe) on Tops-10 a long time ago...
Wow! I dind't know that had ever gotten into the wild. It was written by
Stu Grossman when he was at Stevens so that he could run ZORK on Tops-10.
Stu, of course, wrote the KX10 emulator that inspired Ken Harrenstein to
write KLH10.
> As for code-sharing, the DECnet code is common between the topses,
> modulo a bunch of conditionals.
Well, the GALAXY code is similarly common. When I wrote earlier in the
thread that the OSes did not share code, I meant at the executable level,
not source disguised by clever macro writers.
> "Rich Alderson" <ne...@alderson.users.panix.com> wrote in message
> news:mddslwi...@panix5.panix.com...
>> "Visitor" <No...@example.com> writes:
>> OK, that's what I was trying to warn you about in my previous follow-up.
>> There is no such thing as "the PDP" in the sense you mean here.
> I know, I know.
> It's just a lot easier to use over generalizations for this simple level of
> discussion.
No, it's not. It frequently obscures the very points you want to make.
>> The 6809 instruction set is vaguely similar to the PDP-11 family's
>> instruction set, so you might not feel too uncomfortable with the latter:
>> 16-bit words in
> Yeah. Not identical etc, of course. Just the 'flavor'.
> Realistically it doesn't make too much difference because I don't really
> want to do that kind of stuff if I don't have to.
>> 8-bit bytes, small number of instructions, etc. etc. It bears no
>> resemblance to the PDP-10 at all.
> Well, the program was originally written for the PDP6/11 and then ported to
> PDP10.
There is no such thing as the PDP6/11. The PDP-6 came out in 1964, the -10
in 1967, and the -11 in 1969. Chronology is against you.
> As
>> The PDP-10 (and the PDP-6 before it), on the other hand, is a 36-bit word-
>> oriented architecture in which entities smaller than the word ("bytes") are
>> defined within a word-long data structure called a byte pointer. (These may
>> be anywhere from 1 to 36 bits in length.) There are several hundred
>> instructions defined in the architecture, with a 9-bit opcode length, 4-bit
>> accumulator and index fields, an indirect bit, and an 18-bit
>> address/immediate field. Just representing the data accurately will be a
>> challenge for any PC-based tool.
> Probably.
> But at this point, it's not really that big of an issue for me. Since I'm
> not actually starting to disassemble anything, it doesn't matter too much.
>> Finally, I'm not convinced that the original MACHACK VI was even an ITS
>> program--RG could very easily have written it to the bare metal on the
>> PDP-6. (Chris, do you know for sure that it ran under ITS?)
> I really don't know.
Uh, sorry, I didn't realize that your name is also Chris--I was addressing
Chris Stacy, an ITS hacker and confrere of Greenblatt.
> Most of my reliable stuff just says it was written in MIDAS for the pdp6 and
> that it later ran on the PDP11 and PDP 10.
MIDAS is the MIT-created assembler language. It makes no assumption about the
environment in which a program will run, assuming that the programmer will
include whatever is needed.
> Later stuff could easily be asumptions as to what OS (if any) it ran on, or
> a later version that had been ported.
> Not much telling what the original version did, or what particular version
> was on that pdp site, or what particular version Mr. Greenblatt has.
The stuff on the DECUS tapes for Tops-10 and Tops-20 is OS-specific (where
the PA1050 compatibility package allows many but not all Tops-10 programs to
run on Tops-20). DECUS did not publish ITS programs, to the best of my
knowledge, nor bare-metal programs.
> In article <mddslwi...@panix5.panix.com>,
> Rich Alderson <ne...@alderson.users.panix.com> wrote:
>> Finally, I'm not convinced that the original MACHACK VI was even an ITS
>> program--RG could very easily have written it to the bare metal on the
>> PDP-6. (Chris, do you know for sure that it ran under ITS?)
> If you have to do a disassembly ITS of Tops20 would be about
> as favourable environments as you can get. Fire up DDT and
> see if you have a symbol table.
> I have myself written programs "to the bare metal" on Tops20.
Perhaps I should make clear what I mean by "bare metal" in this context: The
PDP-6 and the original PDP-10 had *hardware* facilities for talking to the
console terminal, and I/O instructions for using those facilities. Thus, RG's
chess program did not *of necessity* need to have any OS on the system in order
to be loaded and run (though it may have done).
> Some ITS or Tops20 programs never had source code.
Yeah, a lot of little file hacks I've done over the years have been like that,
but that's not "bare metal." The KLAD diagnostics are bare metal.
> "David Evans" <dfe...@bcr10.uwaterloo.ca> wrote in message
> news:dfl36r$5o2$1...@rumours.uwaterloo.ca...
>> Anyway, this is exactly one occasion where being very particular
>> about which PDP you're discussing matters. Given that the term "PDP"
[snip]
>> was invented as a pseudo-synonym for "computer", it is not too
> I wouldn't go that far....
You should. It's the official story from Digital Equipment Corporation of the
invention of the name "Programmed Data Processor" for their first computer
product, to get around GAO acquisition rules for computers.
I didn't say that PDP didn't stand for "Programmed Data Processor", etc.
I said I wouldn't go so far as to as to say that 'PDP' was a synonym for
"computer". That's way too broad.
The way you phrased it made it sound like it was a general synonym. It
wasn't. It was just something DEC happened to do. That's much more limited
in scope. Darn near insignificant, actually.
You may have been meaning it in that limited fashion, but that's not the way
it got read.
> There is no such thing as the PDP6/11. The PDP-6 came out in 1964,
> the -10
> in 1967, and the -11 in 1969. Chronology is against you.
sigh.
I think you are being a bit anal, here.
I didn't say there was a specific machine called the pdp 6/11. Try mentally
changing the / to &.... I'm sure it's a great mental stretch, but try
hard.... I'm sure you can do it.
Nor did I say that Mr. Greenblatt jut happend to do everyting in
chronological order you prefer. Other than doing it on the PDP-6 first.
Or that he immediately switched systems the instant it came out.
Or...
You are really trying to pick nits here,
> Uh, sorry, I didn't realize that your name is also Chris--I was addressing
> Chris Stacy, an ITS hacker and confrere of Greenblatt.
Well, it was in a message to me, so that gave me just as much right to
comment as him.
And since is a *public* newsgroup, anybody would have had the right to
comment.
>> Most of my reliable stuff just says it was written in MIDAS for the pdp6
>> and
>> that it later ran on the PDP11 and PDP 10.
>
> MIDAS is the MIT-created assembler language. It makes no assumption about
> the
> environment in which a program will run, assuming that the programmer will
> include whatever is needed.
Nor did I say that it did, etc.
I was simply stating what information I had.
Did you actually hear me start jumping to all sorts of conclusions and say
that the color of the machine was pink with polka dots with a scratch
towards the upper left?
No.
>> Later stuff could easily be asumptions as to what OS (if any) it ran on,
>> or
>> a later version that had been ported.
> The stuff on the DECUS tapes for Tops-10 and Tops-20 is OS-specific (where
> the PA1050 compatibility package allows many but not all Tops-10 programs
> to
> run on Tops-20). DECUS did not publish ITS programs, to the best of my
> knowledge, nor bare-metal programs.
But that still doesn't say which version of the program it was....
It just says what OS was being used.
It does not say if it was his first version, or his second one. Or whether
it was just a quick recompile, or what ever. Or whether event xyz happened
before abc or what.
As my statement above says... A lot of statements have been made over the
years about Machack VI. Some of which may or may not actually be true.
Some of the chonology may be off. Some of it may be assumption. Some of it
may not even be right... just mistakes in oral history that gets taken as
fact.
So you can't really say much about those on the decus tapes except that they
are there. You don't know what version they are (early? Buggy? Later
advanced and better tuned? Etc.) You don't know what came before that or
after that.
> "Rich Alderson" <ne...@alderson.users.panix.com> wrote in message
> news:mddfysh...@panix5.panix.com...
> > "Visitor" <No...@example.com> writes:
> >
> >>> Anyway, this is exactly one occasion where being very particular
> >>> about which PDP you're discussing matters. Given that the term "PDP"
> >
> > [snip]
> >
> >>> was invented as a pseudo-synonym for "computer", it is not too
> >
> >> I wouldn't go that far....
> >
> > You should. It's the official story from Digital Equipment Corporation of
> > the
> > invention of the name "Programmed Data Processor" for their first computer
> > product, to get around GAO acquisition rules for computers.
>
> I didn't say that PDP didn't stand for "Programmed Data Processor", etc.
>
> I said I wouldn't go so far as to as to say that 'PDP' was a synonym for
> "computer". That's way too broad.
>
> The way you phrased it made it sound like it was a general synonym. It
> wasn't. It was just something DEC happened to do. That's much more limited
> in scope. Darn near insignificant, actually.
>
> You may have been meaning it in that limited fashion, but that's not the way
> it got read.
He was very nicely trying to educate you to the fact that
your usage of "the PDP" was inappropriate -- you were under
the misapprehension that the term referred to a particular
comptuer architecture.
You seem to boast about how you could disassemble the binary
program yourself and translate it to another architecture,
and you seemed to think that it would be something like
an 8080 or 68000.
Since you're in the habit of lecturing people about these
computers and insisting that they should do all kinds of work
for you, I think you should just go with your original plan
and figure it all out yourself.
I know I'm not helping.
Hmmmm...Which ITS programs are you thinking of?
> "Rich Alderson" <ne...@alderson.users.panix.com> wrote in message
> news:mddmzmp...@panix5.panix.com...
>
> > There is no such thing as the PDP6/11. The PDP-6 came out in 1964,
> > the -10
> > in 1967, and the -11 in 1969. Chronology is against you.
>
> sigh.
>
> I think you are being a bit anal, here.
>
> I didn't say there was a specific machine called the pdp 6/11. Try mentally
> changing the / to &.... I'm sure it's a great mental stretch, but try
> hard.... I'm sure you can do it.
Too big a stretch for me. The "PDP6/11" notation indicates to me that
somebody thinks the PDP-6 and the PDP-11 are in some meaningful way
very much alike.
They aren't.
--
David Dyer-Bennet, <mailto:dd...@dd-b.net>, <http://www.dd-b.net/dd-b/>
RKBA: <http://noguns-nomoney.com/> <http://www.dd-b.net/carry/>
Pics: <http://dd-b.lighthunters.net/> <http://www.dd-b.net/dd-b/SnapshotAlbum/>
Dragaera/Steven Brust: <http://dragaera.info/>
In that case, I appologize.
It's just that as I've said several times in here, I don't have any interest
in the PDP. Any PDP. Whether it's the PDP 3 or the "PDP"-11/780....
My sole interest was the program. The only reason I came to this newsgroup
was of what's stated in the subject line.... (Although that changed when
the discussion got over to Greenblatt still being alive and maybe having the
original source.)
And apparently, I've ruffled a few feathers with those of you who do care
considerably more about the PDP than the program.
I appologize.
> You seem to boast about how you could disassemble the binary
> program yourself and translate it to another architecture,
I've never claimed to actually know PDP assembly code. Any version of PDP.
In fact, I've admitted a few times that I've never used a PDP of any sort
and didn't really care much about it.
All I've said is:
1) I was originally asking about a disassembler and assembler on the PC.
(If there had been one available, I was going to download the manuals and
start learning the assembly language. I've never said or suggested that I
already knew any PDP assembly or that I was an expert in it, etc. If I had
already known PDP assembly (any sort), then the odds would have been good
that I would have already known how to run MacHack VI and I wouldn't have
needed instructions on the OS.)
2) That I have done that type of complex disassembly and source re-creation
before (in my 8 bit micro days) and although I can do it, it's a heck of a
lot of work and I don't like it and I'd really rather not try if there is
any chance of ever getting the original source.
3) that I had heard that 6809 assembly language had a "flavor" similar to
what some of the PDP's used. I didn't say it was identical or even similar.
I definetly used the phrase "similar flavor".
And at no time have I ever said, suggested, implied or insinuated, that I
could (or would) convert it to another architecture. Converting it has
never even been brought up before. I have no idea where you got that
impression. (Unless you got confused when I mentioned that I had done
source re-creation back in my old 8 bit days, and you assumed I was going to
port it to that. Which I certainly never said or suggested. Or in the
discussions about the systems that Greenblatt has run the program on. But
he isn't me.)
If I was going to convert it, to be honest, I'd do it in C, so it could be
portable to all processors. I certainly wouldn't waste my time rewriting it
in another assembly and tying it to yet another architecture.
> and you seemed to think that it would be something like
> an 8080 or 68000.
I've never mentioned the 8080 or the 68000. Don't know why you'd mention
those.
The only thing I've ever said is that I've done that type of complete
disasembly and source re-creation before on my old 8 bit micro and that I
had heard that 6809 style of assembly had a similar "flavor" to what some
PDP's used.
(And since I have used the 6809 before, that would have been somewhat of a
starting point on learning the assembly language that MacHack VI had been
written in. I could have related to it a bit.)
> Since you're in the habit of lecturing people about these
> computers and insisting that they should do all kinds of work
> for you, I think you should just go with your original plan
What kind of work???
Could you please quote the message where I said they should do such & such
for me?
I haven't said any such thing. Not once.
I don't even know what kind of "all kinds of work" you could possibly be
talking about.
The closest I've said to anything like that would have been asking about a
disassembler & assembler that ran on the PC, so I could do my work there,
instead of inside an OS that I wasn't familiar with.
Frankly, it sounds like some people in here have read a lot more into my
messages than I actually wrote.
> Too big a stretch for me. The "PDP6/11" notation indicates to me that
> somebody thinks the PDP-6 and the PDP-11 are in some meaningful way
> very much alike.
They were written down side by side though....
Fine.
I lied.
MacHack VI never ran on a PDP system at all.
I've just been pulling your leg and playing a massive practical joke on
everybody.
MacHack VI was strictly for the DataGeneral systems. (Yes yes, I know...
those didn't come along until 69-70 or so....)
Mr. Greenblatt has been helping me and lying to everybody all these years
about what systems his program really ran on. He just slapped a pdp logo
onto the system and figured nobody would notice the difference in hardware.
Accepted.
>It's just that as I've said several times in here, I don't have any interest
>in the PDP. Any PDP. Whether it's the PDP 3 or the "PDP"-11/780....
>
>My sole interest was the program. The only reason I came to this newsgroup
>was of what's stated in the subject line.... (Although that changed when
>the discussion got over to Greenblatt still being alive and maybe having the
>original source.)
>
>And apparently, I've ruffled a few feathers with those of you who do care
>considerably more about the PDP than the program.
>
>I appologize.
Accepted.
Consider yourself educated.
>> You seem to boast about how you could disassemble the binary
>> program yourself and translate it to another architecture,
>
>I've never claimed to actually know PDP assembly code. Any version of PDP.
>In fact, I've admitted a few times that I've never used a PDP of any sort
>and didn't really care much about it.
>
>All I've said is:
>
>1) I was originally asking about a disassembler and assembler on the PC.
>(If there had been one available, I was going to download the manuals and
>start learning the assembly language. I've never said or suggested that I
>already knew any PDP assembly or that I was an expert in it, etc. If I had
>already known PDP assembly (any sort), then the odds would have been good
>that I would have already known how to run MacHack VI and I wouldn't have
>needed instructions on the OS.)
There are no cross-development tools that are hosted and develop for
the PDP10. The PC was simply too lame hardware-wise while the PDP10 was
actively developed.
[although rumors will have it the PC OS was developed on the PDP10]
The solution is to fire up an emulator on the PC, there are at least three
of them, and run the original environment.
>2) That I have done that type of complex disassembly and source re-creation
>before (in my 8 bit micro days) and although I can do it, it's a heck of a
>lot of work and I don't like it and I'd really rather not try if there is
>any chance of ever getting the original source.
Besides Multics, ITS and Tops20 are the original homes of excellent interactive
debugging tools. The assembly debugger, DDT, remains the standard I still
hold all other debuggers to.
The PDP10 assembly language and instruction set is also extremely regular
and powerful.
I therefore stand by my assertion that a "source reconstruction" project
will be a lot easier on ITS or Tops20 than on almost any other platform.
Actually, for around three years of my life I used DDT as my pocket
calculator, and constantly wrote 5-20 instruction programs for such work
that would normally be done (then) on a HP/TI programmable calculator or
(now) in a spreadsheet. I even saved some of them as real programs.
I know some people who did larger programs this way. In other words, there
was no source code. I am trying to break this notion to you as softly
as I can. There may never have been source code.
I still miss DDT.
>3) that I had heard that 6809 assembly language had a "flavor" similar to
>what some of the PDP's used. I didn't say it was identical or even similar.
>I definetly used the phrase "similar flavor".
Not really.
The PDP10 has regular instructions that are always 36 bits, one word,
long. There are 16 registers, 15 of them are fully general purpose,
and can be used as two 18-bit halfwords, a byte pointer, a pointer,
an integer, a single precision float, half of a double precision float,
a bit map, or an index register.
>And at no time have I ever said, suggested, implied or insinuated, that I
>could (or would) convert it to another architecture. Converting it has
>never even been brought up before. I have no idea where you got that
>impression. (Unless you got confused when I mentioned that I had done
>source re-creation back in my old 8 bit days, and you assumed I was going to
>port it to that. Which I certainly never said or suggested. Or in the
>discussions about the systems that Greenblatt has run the program on. But
>he isn't me.)
>
>If I was going to convert it, to be honest, I'd do it in C, so it could be
>portable to all processors. I certainly wouldn't waste my time rewriting it
>in another assembly and tying it to yet another architecture.
The main challenge is probably the 36 to 32 bit word size transition.
>> and you seemed to think that it would be something like
>> an 8080 or 68000.
>
>I've never mentioned the 8080 or the 68000. Don't know why you'd mention
>those.
>
>The only thing I've ever said is that I've done that type of complete
>disasembly and source re-creation before on my old 8 bit micro and that I
>had heard that 6809 style of assembly had a similar "flavor" to what some
>PDP's used.
>
>(And since I have used the 6809 before, that would have been somewhat of a
>starting point on learning the assembly language that MacHack VI had been
>written in. I could have related to it a bit.)
>
>
>> Since you're in the habit of lecturing people about these
>> computers and insisting that they should do all kinds of work
>> for you, I think you should just go with your original plan
>
>What kind of work???
>
>Could you please quote the message where I said they should do such & such
>for me?
>
>I haven't said any such thing. Not once.
>
>I don't even know what kind of "all kinds of work" you could possibly be
>talking about.
>
>The closest I've said to anything like that would have been asking about a
>disassembler & assembler that ran on the PC, so I could do my work there,
>instead of inside an OS that I wasn't familiar with.
Such things do not exist, but they are not really needed. Good emulators
for the PDP10 hardware exist on the PC. Look for KLH10, SIMH or possibly TS10.
>Frankly, it sounds like some people in here have read a lot more into my
>messages than I actually wrote.
This is one of the few remaining places on usenet where polite and accurate
discussions are still seen as the norm.
If you want a lighter version, try alt.folklore.computers; but be warned that
it is the home of thread drift.
-- mrr
Sigh! Child, you do not treat PDP-10 bit gods in this manner.
They will give you the shirt off their backs w.r.t. information
but they do not deal with dipshits at all.
>
>Nor did I say that Mr. Greenblatt jut happend to do everyting in
>chronological order you prefer. Other than doing it on the PDP-6 first.
>
>Or that he immediately switched systems the instant it came out.
>
>Or...
>
>You are really trying to pick nits here,
That is, or rather, was our job. Being nitpicking is why those
systems were so good.
<snip>
>As my statement above says... A lot of statements have been made over the
>years about Machack VI. Some of which may or may not actually be true.
>Some of the chonology may be off. Some of it may be assumption. Some of it
>may not even be right... just mistakes in oral history that gets taken as
>fact.
>
>So you can't really say much about those on the decus tapes except that they
>are there. You don't know what version they are (early? Buggy? Later
>advanced and better tuned? Etc.) You don't know what came before that or
>after that.
If the code was a hack, the usual version assignments may not apply.
For the rest of you, it was possible to do PDP-11 and -8 code
on TOPS-10 with the use of the assemblers MACY11, MACX11, and
PAL8. It sounds like there is some confusion on the part of the
OP that may be answered by this. We did development of the
minis on the -10 but only to the point of creating a binary
and/or executable. It had to be copied to a DECtape or
papertape and then brought to a mini to load and execute.
I don't know if this helps at all. A lot of code
was also toggled in by hand. I'll leave it to the
hardware guys to explain that one :-).
/BAH
<snip>
>As for code-sharing, the DECnet code is common between the topses,
>modulo a bunch of conditionals.
Nope.
/BAH
Would you explain what you mean by this? (side by side)
>
>Fine.
>
>I lied.
Oh, quit it. You could have saved face and just said typo.
The reason PDP-10ers are bit gods is because it didn't
take 100 whacks of a virtual baseball bat to admit they
goofed. It usually only took one.
You are confused. People here have been trying to help
eliminate that confusion. You have a wish to get some
old code and get it to run. IT IS IMPORTANT THAT YOU
UNDERSTAND WHAT YOU CAN AND CANNOT DO. That is why
people are correcting your mistakes. Because, if
these mistakes are not corrected, you will never achieve
your goal. People of the Greenblat flavor will not expend
any time to satisfy anybody who cannot learn the basic
ABCs of computing. They do not have the time to waste.
Please take note. Everything you thought was a nitpick, was
not. It is necessary knowledge to do the kind of work you
said you wanted to do. We don't waste time picking useless
nits.
Well, we don't unless there is a turf war. ;-)
/BAH
> "Rich Alderson" <ne...@alderson.users.panix.com> wrote in message
> news:mddmzmp...@panix5.panix.com...
>
>> There is no such thing as the PDP6/11. The PDP-6 came out in 1964,
>> the -10
>> in 1967, and the -11 in 1969. Chronology is against you.
>
> sigh.
> I think you are being a bit anal, here.
>
> I didn't say there was a specific machine called the pdp 6/11. Try
> mentally changing the / to &.... I'm sure it's a great mental stretch, but
> try hard.... I'm sure you can do it.
No, don't think so.
10/20 folks hated the 11s and their devil spawn, the Vax.
Wouldn't have been so bad, except that the 11/vax folks forgot
to learn any of the hard earned stuff about big systems.
6, 10 and 20 are magic numbers. Don't mess them in with
unclean numbers.
--
Pat
Fine. It was a typo.
Except it wasn't. That was what was written down in the stuff I happened to
have handy about MacHack VI.
But alright. If it makes you happy, then it was a typo.
> You are confused. People here have been trying to help
You also missed the not so minor fact the much of the 'confusion' is in an
area I have repeatedly said I didn't care about and that is not relevant to
the program.
I don't care about the PDP itself.
I don't even care if Mr. Greenblatt painted his pink and stuck a bra on his.
That's not relelvant to the program. (True, it'd be an interesting
historical story, but not really relevant to the program.)
> eliminate that confusion. You have a wish to get some
> old code and get it to run. IT IS IMPORTANT THAT YOU
> UNDERSTAND WHAT YOU CAN AND CANNOT DO. That is why
In the begining, I was told to run it under ITS.
I accepted that as being correct.
So, I hunted down all the stuff, got the recommended pdp-10 emulator, and
spent a couple days trying to get it to run.
Needless to say, it failed because 1) the program wasn't for ITS, 2) the
instructions I was given wasn't for ITS.
As for getting TOPS-10 installed and MacHack VI installed under it, I
haven't been successful there either. I've been busy with other things and
haven't had the time to spend on it like I did with the ITS stuff I was
told. The quick check I did didn't turn up any quick installation
instructions like for ITS.
I did play with one image that said it was already set up, but that didn't
work out.
I haven't asked about more instructions in here about getting the program to
run. I haven't been coming back in here and asking more and more questions
about how to get the program to run, etc. I figured that when I do get the
extra time to spend on it, I'd just download the manuals and try to figure
it out myself.
The majority of stuff in here (esp. lately) has not been at all relevant to
the program or to my getting the program to run.
Lately, it's all been in areas that I repeatedly said I didn't care and that
weren't relevant. pdp hardware stuff.
> people are correcting your mistakes. Because, if
> these mistakes are not corrected, you will never achieve
Actually, you are mistaken.
It doesn't matter in the slightest whether Greenblatt did the pdp-10 or
pdp-11 version after the original pdp6.
That was part of the latest stuff from pdp fanatics.
He worked on his program for more than 10 years, off and on. Things did not
necessarily happen in pdp chronological order.
And some stuff I have on MacHack VI is contradictory (dates wrong, etc.)
And I have no idea which specific version was on those decus tapes. Other
than it's for the PDP-10, of course.
> your goal. People of the Greenblat flavor will not expend
> any time to satisfy anybody who cannot learn the basic
> ABCs of computing. They do not have the time to waste.
>
> Please take note. Everything you thought was a nitpick, was
> not. It is necessary knowledge to do the kind of work you
> said you wanted to do. We don't waste time picking useless
> nits.
*IF* you care about the PDP hardware and its history and so on.
Then no. It probably isn't a nitpick.
But if you are only interested in the program, then most of those other
comments are totally worthless and irrelevant.
Most of that stuff just does not matter to the history of the program or to
whether it would be possible to get, archive, and publish the source for
MacHack VI.
The reality is many of you are trying to do a history of the PDP etc. that
simply isn't relevant.
What is relevant are things like:
1) get a pdp-10 emulator.
2) get such and such support tape images.
3) follow the xyz commands to get the OS installed.
4) follow the abc commands to get MacHack VI installed.
5) enter the comand 123 to actually run MacHack VI.
or.
1) I've been in touch with Mr. Greenblatt and he says he's willing to hunt
for the source. It'll only be a matter of weeks before we get the tape read
and the source avialble!
The vast majority of stuff that's been said in here aren't even vaguely
relevant to any of those things.
I know that many people like the PDP. Any pdp. That's not uncommon. Most
people from the 50's, 60's or 70's have strong feelings about the first
computer they used. Or one they used the most. Sometimes those feelings
are highly negative. Other times they are very fond memories.
But I'm not one of the pdp fans. I have never used a PDP. I don't have the
urge now to use a pdp. If you were to offer to give me a fully working
pdp-6/8/10/11/11-780, etc. etc., I wouldn't care.
The closest I care about the pdp itself is in following a sequence of steps
to get the MacHack VI program running. The pdp emulator is just an end to
the means, not the goal itself. The important part is the program.
> There are no cross-development tools that are hosted and develop for
> the PDP10. The PC was simply too lame hardware-wise while the PDP10 was
> actively developed.
I figured these days, somebody might have written pc based tools.
That's not uncommon for emulators these days.
That way developers can still use their syntax coloring editors, and run
modern language compilers (ie: ansi C, C++, etc.), and so on. And still
make regular backups of their development stuff by burning it to cd. And
son on.
With many emulators, you don't have to stay locked into using only stuff
that was available on the original system and doing everything within the
emualtor.
You only do that if you are... well.... well, somewhat fanatical about being
"true" to the original system, or have no easy way to transfer stuff between
the emulator and host.
Most people who use emulators of old systems aren't like that. They welcome
pc based tools and modern compilers, and readily transfer stuff between the
host & emulator.
They prefer to have fun with the emulator, rather than being 'pure' to it.
>>2) That I have done that type of complex disassembly and source
>>re-creation
>>before (in my 8 bit micro days) and although I can do it, it's a heck of a
>>lot of work and I don't like it and I'd really rather not try if there is
>>any chance of ever getting the original source.
>
> Besides Multics, ITS and Tops20 are the original homes of excellent
> interactive
> debugging tools. The assembly debugger, DDT, remains the standard I still
> hold all other debuggers to.
As I've said before, I don't know the OS, so I don't know DDT.
But a full blown disassembler (like what's needed to do a source recreation)
tends to be more than just a debugger with an assembler and disassembler
thrown in.
> I therefore stand by my assertion that a "source reconstruction" project
> will be a lot easier on ITS or Tops20 than on almost any other platform.
Maybe.
But it sure would be inconvenient from my user's perspective.
> I know some people who did larger programs this way. In other words, there
> was no source code. I am trying to break this notion to you as softly
> as I can. There may never have been source code.
Highly unlikely for a program that was developed and tweaked for more than
10 years. And ported to at least one other OS. And ported to his dedicated
CHEOPs hardware.
Plus, several people (elsewhere) have explicitly said they *did* once have a
copy of the MacHack VI source, but have long since lost or thrown it away.
I may not know much about PDP hardware, but I definetly do know a few things
about MacHack VI.
>>3) that I had heard that 6809 assembly language had a "flavor" similar to
>>what some of the PDP's used. I didn't say it was identical or even
>>similar.
>>I definetly used the phrase "similar flavor".
>
> Not really.
Alright. You say it doesn't.
[shrug] It's not really all that relevent. It was just something I
mentioned once because I thought it might help me grasp the PDP assembly
language that Greenblatt used for MacHack VI.
It's not really relevant one way or the other. Except for the fact that I
did indeed say it in passing.
>>If I was going to convert it, to be honest, I'd do it in C, so it could be
>>portable to all processors. I certainly wouldn't waste my time rewriting
>>it
>>in another assembly and tying it to yet another architecture.
>
> The main challenge is probably the 36 to 32 bit word size transition.
Maybe.
It would really depend on how he used those bits.
Even today, most programs don't even use the full 32 bits in current
systems. A lot of what they do is really limited to 20-25 bits and the rest
gets unused. Other people use the full amount and go ahead and use the full
64.
[shrug] No way to know without a thorough analysis or looking at his
source.
Even if I already has Greenblatt's source, converting it to C is not being
planned. Sure, it'd be nice. But it's not planned.
>>The closest I've said to anything like that would have been asking about a
>>disassembler & assembler that ran on the PC, so I could do my work there,
>>instead of inside an OS that I wasn't familiar with.
>
> Such things do not exist, but they are not really needed. Good emulators
> for the PDP10 hardware exist on the PC. Look for KLH10, SIMH or possibly
> TS10.
As I mentioned up above, a lot of people that use emulators actually prefer
to do some of their work outside of the emulator.
Not everybody is a purist that insist on doing everything from within the
emulator just as if that system was the real thing and there was no other
system to use.
That's why I thought there might be outside tools.
>>Frankly, it sounds like some people in here have read a lot more into my
>>messages than I actually wrote.
>
> This is one of the few remaining places on usenet where polite and
> accurate
> discussions are still seen as the norm.
I would say that a lot of the people that have been speaking up are not the
most polite.
Fanatical would be more accurate. Insisting on discussing things that
aren't relevant to the discussion or situation.
> If you want a lighter version, try alt.folklore.computers; but be warned
> that
> it is the home of thread drift.
I think most people here have done pretty well with thread drift....
The current discussions aren't at all relevant and just barely related to my
original posts.
You seem to forget that almost all development on the PDP10 ceased approx
1986. Most of the development and tool building took place in the period
1966-1981.
May I remind you that these were times when real men were hippies, real machines
took the better part of an apartment in floorspace, and the power budget was
on the order of 10 villas. Personal machines were called "terminals", or
"card punchs"; or "desk calculator".
When we youngsters saw the PET 2001 in the shop, we instantly thought that
we could build a modem for it and connect it to the PDP10. The "build" in
front of modem was intentional. I ended up doing just that for a PET, but
for a different project that ended up as one of the first multiuser BBS'es.
The PDP10 systems each had it's flavour. ITS was the hacker's turf, sort of
great grandparent to Linux. Tops10 was the transaction mill, and Tops20 was
the academic/development home. They each have development tool ranging from
merely good to excellent.
Noone has seen any point in merging these with *n*x or Windows. To bring the
point home, the way these systems are connected to the world they get a
separate etherenet adapter, and the emulation translates the ethernet I/O
inside the emulation to ethernet I/O on the external NIC. Thus, Tops20 runs
completely alone. The *n*x system is scantly doing more than microcode did
on real HW.
>With many emulators, you don't have to stay locked into using only stuff
>that was available on the original system and doing everything within the
>emualtor.
>
>You only do that if you are... well.... well, somewhat fanatical about being
>"true" to the original system, or have no easy way to transfer stuff between
>the emulator and host.
This is a problem; we have to ftp files in and out. The upside is that ftp
has support for the challenges in word size and endianness readily built in.
>
>Most people who use emulators of old systems aren't like that. They welcome
>pc based tools and modern compilers, and readily transfer stuff between the
>host & emulator.
>
>They prefer to have fun with the emulator, rather than being 'pure' to it.
The PDP10 people haven't really taken on a "pure" approach. Tops20 is now
being maintained and is developed to handle modern stuff like mime, large
disk spaces and modern compilers and runtime systems.
Emulators now run Tops20 at ~25 times the fastest DEC machine, and ~5 times
the fastest third party offering; so they are pretty adequate in running the
assembly-optimized code these systems contain.
The mindset is more geared towards actually making Tops20 or ITS a live
environment again. We want to run the systems EXACTLY because they contain
the software they do. After all, they were the homes of emacs, ddt, teco,
simula and lots of other classic software.
>>>2) That I have done that type of complex disassembly and source
>>>re-creation
>>>before (in my 8 bit micro days) and although I can do it, it's a heck of a
>>>lot of work and I don't like it and I'd really rather not try if there is
>>>any chance of ever getting the original source.
>>
>> Besides Multics, ITS and Tops20 are the original homes of excellent
>> interactive
>> debugging tools. The assembly debugger, DDT, remains the standard I still
>> hold all other debuggers to.
>
>As I've said before, I don't know the OS, so I don't know DDT.
>
>But a full blown disassembler (like what's needed to do a source recreation)
>tends to be more than just a debugger with an assembler and disassembler
>thrown in.
>
>
>> I therefore stand by my assertion that a "source reconstruction" project
>> will be a lot easier on ITS or Tops20 than on almost any other platform.
>
>Maybe.
>
>But it sure would be inconvenient from my user's perspective.
The odds that such a system has no source is low, <1%, but it is non-zero.
The odds that it is written in PDP10 assembly is pretty high, > 75%. These
programs were not famous for having lots of comments; so of the binary has
the symbol table intact a source recreation sans comments is actually not
such a horrendous affair.
>> I know some people who did larger programs this way. In other words, there
>> was no source code. I am trying to break this notion to you as softly
>> as I can. There may never have been source code.
>
>Highly unlikely for a program that was developed and tweaked for more than
>10 years. And ported to at least one other OS. And ported to his dedicated
>CHEOPs hardware.
>
>Plus, several people (elsewhere) have explicitly said they *did* once have a
>copy of the MacHack VI source, but have long since lost or thrown it away.
Do you know what it was written in ?
Do you have the binary available for inspection; a quick DDT session on
it will reveal a lot of these things.
>>>The closest I've said to anything like that would have been asking about a
>>>disassembler & assembler that ran on the PC, so I could do my work there,
>>>instead of inside an OS that I wasn't familiar with.
>>
>> Such things do not exist, but they are not really needed. Good emulators
>> for the PDP10 hardware exist on the PC. Look for KLH10, SIMH or possibly
>> TS10.
>
>As I mentioned up above, a lot of people that use emulators actually prefer
>to do some of their work outside of the emulator.
>
>Not everybody is a purist that insist on doing everything from within the
>emulator just as if that system was the real thing and there was no other
>system to use.
>
>That's why I thought there might be outside tools.
For the PDP10 : None. We who knew and loved the PDP10s are just very
happy that emulators are now available, so we can build from the PDP10s
own toolchest. That is more than enough for now.
As I said earlier, a 'PA386' gateway package to the outside OS may be an
idea, but it would need expert knowledge from the *n*x and Tops20/ITS sides.
I doubt it is possible for Tops10 without making the PA386 replace Tops10.
>>>Frankly, it sounds like some people in here have read a lot more into my
>>>messages than I actually wrote.
>>
>> This is one of the few remaining places on usenet where polite and
>> accurate
>> discussions are still seen as the norm.
>
>I would say that a lot of the people that have been speaking up are not the
>most polite.
>
>Fanatical would be more accurate. Insisting on discussing things that
>aren't relevant to the discussion or situation.
>
>
>> If you want a lighter version, try alt.folklore.computers; but be warned
>> that
>> it is the home of thread drift.
>
>I think most people here have done pretty well with thread drift....
>
>The current discussions aren't at all relevant and just barely related to my
>original posts.
You are bringing in an old debate about how to restore old software, and
Machack is just one of a large number of programs. When you ask for help,
expect that the helpers may want to use the general solution that help us
all instead of just this one case; important as it may be.
As I said, if you have got the binary and whatever info surrounding it I
can volunteer to fire up an emulator and have a look; getting some real
data on what we really have before us.
-- mrr
I consider myself a Tops20 hacker of old, and I can never say I
had any animosity against the PDP11 or the PDP8; which where the
only other PDP's I met. The PDP11 made a nice front end and the PDP8
made a very nice terminal possible.
The PDP11/74 was also the most usable unix system for a long time.
It is all about the VAX. Too much about that system was and is wrong,
from ISA design to I/O to OS issues to politics.
>6, 10 and 20 are magic numbers. Don't mess them in with
>unclean numbers.
If I were to do a minimalistic systems design today and a good
pdp8 chip was available I would give it serious consideration.
-- mrr
Not at all. They were wonderful for our ANF-10 front ends.
> ..and their devil spawn, the Vax.
>Wouldn't have been so bad, except that the 11/vax folks forgot
>to learn any of the hard earned stuff about big systems.
>
>6, 10 and 20 are magic numbers. Don't mess them in with
>unclean numbers.
One cannot substitute them.
/BAH
This reminds me that I set up a cross-development system that compiled
files from C to MACRO-10 in Linux, and then transparently FTP'ed files
to be assembled in TOPS-20. The resulting REL files were FTP'ed back
to Linux, and maybe I had them cached at the 20 side for the LINK
pass. Finally the EXE's could be run inside the emulator, and a
pass/fail would be returned.
This was somewhat fragile, and probably not much like the tools
"Visitor" are used to, but it was good enough to run large portions of
GCC's test suite.
I never had the impression that anyone hated the 11's. The Vax is a
different story.
Sigh! Try to leave your self-centered ego at the fucking door.
It could have been a typo on the docs you remember. It could
also be a slashed zero. Greenblat may not have slashed his
zeroes but we at DEC sure as hell did. It could also
have been a program that ran on the -10 using the -11 as a
front end. This means that there are two programs, not
one.
>
>
>> You are confused. People here have been trying to help
>
>You also missed the not so minor fact the much of the 'confusion' is in an
>area I have repeatedly said I didn't care about and that is not relevant to
>the program.
And people who do know about this stuff are trying to teach you
the stuff you're going to need before you start to work on your
project.
>
>I don't care about the PDP itself.
>
>I don't even care if Mr. Greenblatt painted his pink and stuck a bra on his.
>That's not relelvant to the program. (True, it'd be an interesting
>historical story, but not really relevant to the program.)
It may be relevant if those aspects are needed to look at the
code. For all you know, the code is toggled in...or was.
>
>
>> eliminate that confusion. You have a wish to get some
>> old code and get it to run. IT IS IMPORTANT THAT YOU
>> UNDERSTAND WHAT YOU CAN AND CANNOT DO. That is why
>
>In the begining, I was told to run it under ITS.
>
>I accepted that as being correct.
>
>So, I hunted down all the stuff, got the recommended pdp-10 emulator, and
>spent a couple days trying to get it to run.
>
>Needless to say, it failed because 1) the program wasn't for ITS, 2) the
>instructions I was given wasn't for ITS.
>
>As for getting TOPS-10 installed and MacHack VI installed under it, I
>haven't been successful there either. I've been busy with other things and
>haven't had the time to spend on it like I did with the ITS stuff I was
>told. The quick check I did didn't turn up any quick installation
>instructions like for ITS.
>
>I did play with one image that said it was already set up, but that didn't
>work out.
>
>I haven't asked about more instructions in here about getting the program to
>run. I haven't been coming back in here and asking more and more questions
>about how to get the program to run, etc. I figured that when I do get the
>extra time to spend on it, I'd just download the manuals and try to figure
>it out myself.
>
>The majority of stuff in here (esp. lately) has not been at all relevant to
>the program or to my getting the program to run.
Fine, if that is what you think.
>
>
>Lately, it's all been in areas that I repeatedly said I didn't care and that
>weren't relevant. pdp hardware stuff.
The PDP hardware stuff is what you're going to need to know if
you intend to take raw machine language (we'll assume there
aren't sources) and translate them to PC flavored code.
>> people are correcting your mistakes. Because, if
>> these mistakes are not corrected, you will never achieve
>
>Actually, you are mistaken.
>
>It doesn't matter in the slightest whether Greenblatt did the pdp-10 or
>pdp-11 version after the original pdp6.
We think it may.
>
>That was part of the latest stuff from pdp fanatics.
>
>He worked on his program for more than 10 years, off and on. Things did not
>necessarily happen in pdp chronological order.
And people have been trying to tell you that your idea of
chronological order is wrong, which it is. PDP was merely
a trademark of all our computers. The number following it
gave a hint at the architecture which were all different.
The PDP-6 was a subset of the PDP-10.
>
>And some stuff I have on MacHack VI is contradictory (dates wrong, etc.)
So? It just means that the dates were not updated in the comments.
The only dates that really matter are the dates the files were
written to a particular disk area. This info is probably not
helpful now.
>
>And I have no idea which specific version was on those decus tapes. Other
>than it's for the PDP-10, of course.
And there was more than one flavor of PDP-10. If this code did
specific KA instructions, there is a chance it will not execute
under the emulated TOPS-10 system. I don't know if it
would work under an ITS system.
>
>
>> your goal. People of the Greenblat flavor will not expend
>> any time to satisfy anybody who cannot learn the basic
>> ABCs of computing. They do not have the time to waste.
>>
>> Please take note. Everything you thought was a nitpick, was
>> not. It is necessary knowledge to do the kind of work you
>> said you wanted to do. We don't waste time picking useless
>> nits.
>
>*IF* you care about the PDP hardware and its history and so on.
Honey, you want to read code that was written waybackwhen
so the hardware and the history is important.
>
>Then no. It probably isn't a nitpick.
>
>But if you are only interested in the program, then most of those other
>comments are totally worthless and irrelevant.
We know better.
>
>Most of that stuff just does not matter to the history of the program or to
>whether it would be possible to get, archive, and publish the source for
>MacHack VI.
>
>
>The reality is many of you are trying to do a history of the PDP etc. that
>simply isn't relevant.
>
>What is relevant are things like:
>
>1) get a pdp-10 emulator.
>2) get such and such support tape images.
>3) follow the xyz commands to get the OS installed.
>4) follow the abc commands to get MacHack VI installed.
>5) enter the comand 123 to actually run MacHack VI.
>
>or.
>
>1) I've been in touch with Mr. Greenblatt and he says he's willing to hunt
>for the source. It'll only be a matter of weeks before we get the tape read
>and the source avialble!
>
>
>The vast majority of stuff that's been said in here aren't even vaguely
>relevant to any of those things.
How do you know this?
>
>
>I know that many people like the PDP. Any pdp. That's not uncommon. Most
>people from the 50's, 60's or 70's have strong feelings about the first
>computer they used. Or one they used the most. Sometimes those feelings
>are highly negative. Other times they are very fond memories.
>
>But I'm not one of the pdp fans. I have never used a PDP. I don't have the
>urge now to use a pdp. If you were to offer to give me a fully working
>pdp-6/8/10/11/11-780, etc. etc., I wouldn't care.
>
>The closest I care about the pdp itself is in following a sequence of steps
>to get the MacHack VI program running. The pdp emulator is just an end to
>the means, not the goal itself. The important part is the program.
The only code that gets executed is the machine language. You
do understand this? Perhaps not. The younger generation
has never seen machine language because C hides it.
/BAH
The VAX was OK. It was the arrogance of the _few_ people who thought
it could be a mainframe that was abhorrent. There were only
a few but they were the main players and nobody told them "NO!".
A subset of these people wanted to destroy the PDP-10 and
everything that had to do with the -10. Why they wished to
do this is a subject for a psychoanalyst.
/BAH
> Pat Farrell <pfar...@nospam.com> wrote:
>>10/20 folks hated the 11s
>
> Not at all. They were wonderful for our ANF-10 front ends.
Not so good while running the evil 2780/3780/Hasp stuff.
Pretty good as terminal traffic concentrators.
Just not used as computers.
--
Pat
That's because the protocol was poorly designed. It
might even have worked well if the specs weren't a moving
target.
>Pretty good as terminal traffic concentrators.
>
>Just not used as computers.
A lot of our customers used them as computers. They were
not wrong. My favorite PDP-11 OS was IAS.
/BAH
> Pat Farrell <pfar...@nospam.com> wrote:
>>No, don't think so.
>>10/20 folks hated the 11s and their devil spawn, the Vax.
>>Wouldn't have been so bad, except that the 11/vax folks forgot
>>to learn any of the hard earned stuff about big systems.
>
> I consider myself a Tops20 hacker of old, and I can never say I
> had any animosity against the PDP11 or the PDP8; which where the
> only other PDP's I met. The PDP11 made a nice front end and the PDP8
> made a very nice terminal possible.
Yes, by RSX11M as a timesharing operating system
was evil. And it lead directly to promoting certian people who
will not be named. Who then twisted RSX into VMS
and later OS/2.5 and Windows NT.
I suppose it is like blaming the 8088 for all the stupidity
of Windows 2.11. Not quite right, but close enough
> The PDP11/74 was also the most usable unix system for a long time.
Hmm, did it run RSX? oh now, you said Unix....
> It is all about the VAX. Too much about that system was and is wrong,
> from ISA design to I/O to OS issues to politics.
Word. Except it made a lot of money for DEC, and that
made its incorrect positions acceptable politics
--
Pat
Specs? You want IBM to write solid specs so DEC can steal their
business? The protocols worked prefectly on all of our
IBM mainframes with IBM operating systems surrounded
by highly paid IBM Systems Programmer types.
I don't know which marketing genius decided it was a good
idea to make that terrible piece of stuff, but
Dec sold it to us, and our marketing geniuses sold it
to our customers and I had to support the damn pos.
Hmm, pos, does that mean Professional Operating System,
yet another demon spawn of RSX?
No, I beg to disagree.
The VAX was not OK. It was not just VMS.
The 32 bit extensions were the pinnacle of complexity, as the
rest of the world was moving towards a simpler solution for hardware;
a movement that ended in RISC within a decade. DG, Prime and Motorola
struggeled with the same complexity, but they did drive towards
simplifying it with various degrees of success. And that complexity
cost blood in terms of resources; they could have been used for a
faster box. This changed an elegant, but somewhat weird ISA on the
PDP11 into a monstrosity.
Among the tings that suffered on the VAX was IO and reasonable size
memory of all sizes and shapes, not just DRAM, but all the register files
and caches as well.
VMS didn't help at all. It was also a monstrosity of complexity.
I was there, in the trenches, when DEC lost the race again and again
to the Prime, ND, HP, Wang and DG machines. All of these had their
window of opportunity because the VAX was such an abomination.
Finally with the 8600 there was a sort-of-acceptable performance
vehicle, all too late and too little. The animosity from VAXen
go both ways. VAXen conspire to hurt me.
-- mrr
> You seem to forget that almost all development on the PDP10 ceased approx
> 1986. Most of the development and tool building took place in the period
> 1966-1981.
I didn't forget.
Those are the sorts of things that hobbiests do for fun.
Not necessarily years ago when the pdp was new, etc. But these days.
[shrug] That's just what most people do for emulated systems.
>>You only do that if you are... well.... well, somewhat fanatical about
>>being
>>"true" to the original system, or have no easy way to transfer stuff
>>between
>>the emulator and host.
>
> This is a problem; we have to ftp files in and out. The upside is that ftp
> has support for the challenges in word size and endianness readily built
> in.
Most (many) emulators provide easy way to transfer data to/from the host.
Either a seperate command that can read / write the disk image, or a full
blown way to make the disk image appear as an actual virtual disk in the
host. (Whether it be as a floppy, hard drive, cd, or some other type of
removable storage device.) Or even shared space on the host drive that the
emulator sees as a seperate device of some sort.
That may be the reason that so many people like doing development work
outside of the emulator. They get the full benefits of a more modern system
(syntax highlighting editors, source code control systems, modern languages,
cd backup, etc.), and it's trivial to transfer the work to the host when
they get done.
Usually, an easy way to transfer files is one of the early priorities of an
emulator.
> The mindset is more geared towards actually making Tops20 or ITS a live
> environment again. We want to run the systems EXACTLY because they contain
> the software they do. After all, they were the homes of emacs, ddt, teco,
> simula and lots of other classic software.
That's not the way most people treat emulated systems these days.
They tend to prefer to have more fun than to be 'pure' about making an
emulated system behave like it originally did. With all the isolation etc.
that goes along.
Most people who use emulators of old systems have actually used the old
systems, along with all the quirks and the so on. Wo when they use the
emulator, they prefer a few modern conveniences to make it less awkward.
Apparently the pdp folks are different, though.
>>Plus, several people (elsewhere) have explicitly said they *did* once have
>>a
>>copy of the MacHack VI source, but have long since lost or thrown it away.
>
> Do you know what it was written in ?
Only that it was originally MIDAS for the PDP6.
There is little readily available reliable information about MacHack VI
after the initial development.
He presented a paper or two on it, but that's about it. Most of the stuff
about it was done as 'word of mouth'.
Most people who've heard of the program don't even realize that he kept
working on it (off and on) for close to 10 years. They just tend to think
that the initial program was all that existed.
So although it was originally MIDAS, there's no telling what the later
versions were. Maybe he never did do a complete rewrite. Maybe he did.
[shrug] Practically nothing is documented of the later years.
>>Even if I already has Greenblatt's source, converting it to C is not being
>>planned. Sure, it'd be nice. But it's not planned.
>
> Do you have the binary available for inspection; a quick DDT session on
> it will reveal a lot of these things.
I have the two binaries from the decus tape. That's all.
But again, I don't know DDT to be able to really use it.
I doubt that a quick look would reveal much, though. You'd have to know a
lot about the program and its structure and data structures to even know
where to look.
It's entirely possible that some areas use the full bits and that other
areas might not need it.
Or that some areas do use the full bits but do so only because it was
convenient. That it could have been done with fewer too. (Just like on
modern systems, where people may pack several characters into a 32 bit word.
They are individual bytes, but they are being treated as a 32 bit word
because it's convenient.)
A chess program is a very complicated program and looking at it raw can be
very difficult. That's one of the reasons I am very reluctant to try to
reverse engineer it if I don't have to.
> As I said, if you have got the binary and whatever info surrounding it I
> can volunteer to fire up an emulator and have a look; getting some real
> data on what we really have before us.
The binaries are readily available on the decus tape.
I don't remember which one right off hand... Look for the file 'chess.how'.
That's the help file. It'll be on two seperate tapes.
The sizes are different, so I don't know how they are different.
> It may be relevant if those aspects are needed to look at the
> code. For all you know, the code is toggled in...or was.
No, it wasn't. The source was distributed to several people.
>>The majority of stuff in here (esp. lately) has not been at all relevant
>>to
>>the program or to my getting the program to run.
>
> Fine, if that is what you think.
Glad we got that settled.
> The PDP hardware stuff is what you're going to need to know if
> you intend to take raw machine language (we'll assume there
> aren't sources) and translate them to PC flavored code.
I have no intention of translating it to PC flavored code.
I've never suggested I was even considering it.
Sure, converting it to C would be fun, but not really necessary. Simply
running MacHack VI under an emulator will give you a good taste of what the
program was like. (True, it'd be faster than it origianlly was, but not
many people would mind.)
I certainly wouldn't try to convert it to some other system using assembly.
That would kind of violate the whole point in getting the source for MacHack
VI.
>>And some stuff I have on MacHack VI is contradictory (dates wrong, etc.)
>
> So? It just means that the dates were not updated in the comments.
I'm not talking about comments in a program, etc.
I'm talking about people writing down events in MacHack VI's history.
Some of the dates are wrong about what he did and when he did it.
MacHack VI wasn't widely documented, actually. Most of what we read about
it today was pieced together years later. And some of that is wrong.
> And there was more than one flavor of PDP-10. If this code did
> specific KA instructions, there is a chance it will not execute
> under the emulated TOPS-10 system. I don't know if it
> would work under an ITS system.
I have no idea.
As I've been trying to point out, the MacHack VI project itself wasn't
documented well. Mr. Greenblatt was just hacking out some code. It wasn't
something that was going to be historical, so it wasn't documented. And
even the later years weren't really documented.
We don't know what did or did not actually happen. A few papers and a few
dates is all we know for sure. The rest is just people writing down things
they had heard and believed to be true.
I don't think anybody is sure why it was called "MacHack VI" Were there 5
other versions before this one? Was that the sixth project in project
"MAC"? Etc. I've heard ideas, but nothing that I'm reasonably sure of.
All that we do know for certainty is that it was written in MIDAS on a PDP-6
, it played some tournaments, its endgame was weak, later versions were
better, and it played David Levy in 1978 on specialized chess hardware
called CHEOPS. And he published at least one paper. And that he gave
copies of the source to at least a few people.
People agree on that. It's all the other stuff (along with some dates,
etc.) that people disagree.
>>*IF* you care about the PDP hardware and its history and so on.
>
> Honey, you want to read code that was written waybackwhen
> so the hardware and the history is important.
The only relevant thing would be to know specifically the programs on the
decus tape were for the pdp-10. And probably for TOPS-10.
Most of the other stuff isn't really relevant to that specific situation.
And none of it is relevant if Mr. Greenblatt does still have the source and
can be persuaded to release it.
>>The vast majority of stuff that's been said in here aren't even vaguely
>>relevant to any of those things.
>
> How do you know this?
Because several people have already pointed out that MacHack VI from the
decus tapes DO work (at least mostly) on the emulators.
So at this point, it's just a matter of me figuring out how to install and
run TOPS-10 and then install MacHack VI from the decus tapes.
>>The closest I care about the pdp itself is in following a sequence of
>>steps
>>to get the MacHack VI program running. The pdp emulator is just an end to
>>the means, not the goal itself. The important part is the program.
>
> The only code that gets executed is the machine language. You
> do understand this? Perhaps not. The younger generation
> has never seen machine language because C hides it.
pffft.
Of course I know that. Don't be an ^%#@.
Just because I never used the pdp doesn't mean I'm ignorant about computers.
You'd think that in the 25 years I've used computers, I might have learned
at least a few things.
I've learned several assembly languages. (In fact, I've pointed that out
before, in reference to my having heard that the 6809 supposedly had a
similar flavor to what some of the PDP's had.) (Although it's also worth
saying that I no longer do assembly coding and definetly dislike the x86
assembly.)
And the first compilers I used, I was a bit disapointed because it didn't
generate as good assembly as what I could do. True, it was faster to write
a program in a high level language, but the programs were larger and slower.
>Most (many) emulators provide easy way to transfer data to/from the host.
>
>Either a seperate command that can read / write the disk image, or a full
>blown way to make the disk image appear as an actual virtual disk in the
>host. (Whether it be as a floppy, hard drive, cd, or some other type of
>removable storage device.) Or even shared space on the host drive that the
>emulator sees as a seperate device of some sort.
>
>
>That may be the reason that so many people like doing development work
>outside of the emulator. They get the full benefits of a more modern system
>(syntax highlighting editors, source code control systems, modern languages,
>cd backup, etc.), and it's trivial to transfer the work to the host when
>they get done.
>
>Usually, an easy way to transfer files is one of the early priorities of an
>emulator.
Well, FTP is available, and it can be scripted on both sides. I would
classify that as "easy".
>> The mindset is more geared towards actually making Tops20 or ITS a live
>> environment again. We want to run the systems EXACTLY because they contain
>> the software they do. After all, they were the homes of emacs, ddt, teco,
>> simula and lots of other classic software.
>
>That's not the way most people treat emulated systems these days.
>
>They tend to prefer to have more fun than to be 'pure' about making an
>emulated system behave like it originally did. With all the isolation etc.
>that goes along.
>
>Most people who use emulators of old systems have actually used the old
>systems, along with all the quirks and the so on. Wo when they use the
>emulator, they prefer a few modern conveniences to make it less awkward.
>
>Apparently the pdp folks are different, though.
Perhaps. If I were to do this I would use emacs anyway. OK, it has a lot
more functionality and has syntax highlighting etc. but that is mostly
visual sugar.
And I would say "make" to a $ instead of "comp" to an @.
I would not embark on the chess side of it at all, but a little look
in a debugger can tell you a lot.
It can tell you how it was linked, if there is a symbol table,
you get a lot of clues to the environment (ITS/Tops20/Tops10) and
some info about which version.
>> As I said, if you have got the binary and whatever info surrounding it I
>> can volunteer to fire up an emulator and have a look; getting some real
>> data on what we really have before us.
>
>The binaries are readily available on the decus tape.
>
>I don't remember which one right off hand... Look for the file 'chess.how'.
>That's the help file. It'll be on two seperate tapes.
>
>The sizes are different, so I don't know how they are different.
OK, I'll have to fire up Tops20 and login again. First time in 22 years
I did that with a real task to do!
-- mrr
For all that, let's not lose sight of the fact that the VAX was
extremely successful. For several years there, the 780 was *the*
standard unit of measure for all benchmarks comparing the relative
performance of different processors.
And it's also easy to forget that the VAX *was* the pinnacle of CISC
development, following the PDP-10 tradition of inventing ever more
complex instructions. (Did anyone ever *use* those KL-10 string
instructions?) It's only with hindsight that it's easy to see that the
pinnacle was a dead end.
No, I'm afraid we really can't rationalize it away: no matter how bad
the VAX or VMS may have actually been, the reason we hate the VAX is
because it blew our beloved PDP-10 line out of the water in a battle
none of us will really accept was fair.
-don provan
OK.
>
>The VAX was not OK. It was not just VMS.
The VAX project was supposed to be an answer to the
equivalent of the BIS instruction set that was done with
the KL. That one didn't work well so they tried to
design a CPU that had byte addressing as a given rather
than doing an add-on. I never understood the need for
it but others were more aware of the market place than
I ever was. Remember that the VAX was started in 1975 or 76;
I don't recall the year they would have _started_ writing
specs. The CPU architect for the KL went to doing the VAX design.
>
>The 32 bit extensions were the pinnacle of complexity, as the
>rest of the world was moving towards a simpler solution for hardware;
>a movement that ended in RISC within a decade. DG, Prime and Motorola
>struggeled with the same complexity, but they did drive towards
>simplifying it with various degrees of success. And that complexity
>cost blood in terms of resources; they could have been used for a
>faster box. This changed an elegant, but somewhat weird ISA on the
>PDP11 into a monstrosity.
>
>Among the tings that suffered on the VAX was IO and reasonable size
>memory of all sizes and shapes, not just DRAM, but all the register files
>and caches as well.
>
>VMS didn't help at all. It was also a monstrosity of complexity.
We covered why in another thread recently.
>
>I was there, in the trenches, when DEC lost the race again and again
>to the Prime, ND, HP, Wang and DG machines. All of these had their
>window of opportunity because the VAX was such an abomination.
>
>Finally with the 8600 there was a sort-of-acceptable performance
>vehicle, all too late and too little. The animosity from VAXen
>go both ways. VAXen conspire to hurt me.
Our customers used VAXen for what you would call routers and
let their -10s do the real usermode grunt work. That was
a wonderful machine for that networking. IIRC, this was
around 1983; whenever DECUS was in Atlanta and the year
of the World's Fair in Tennessee.
/BAH
From the point of view of user thruput, it was never a
success.
> ..For several years there, the 780 was *the*
>standard unit of measure for all benchmarks comparing the relative
>performance of different processors.
That's a new one.
>
>And it's also easy to forget that the VAX *was* the pinnacle of CISC
>development, following the PDP-10 tradition of inventing ever more
>complex instructions.
No, this had to do with bytes and manipulating bytes.
> ..(Did anyone ever *use* those KL-10 string
>instructions?) It's only with hindsight that it's easy to see that the
>pinnacle was a dead end.
How do you figure? Everything I see these days is in terms
of bytes.
>
>No, I'm afraid we really can't rationalize it away: no matter how bad
>the VAX or VMS may have actually been, the reason we hate the VAX is
>because it blew our beloved PDP-10 line out of the water in a battle
>none of us will really accept was fair.
JMF and I were stockholders of DEC. It was in our interests to
get the biz to succeed. This means that the company would
be successful only if it made a profit. JMF and TW worked
hard to help make VMS/VAX work well.
/BAH
>>>Even if I already has Greenblatt's source, converting it to C is not being
>>>planned. Sure, it'd be nice. But it's not planned.
>>
>> Do you have the binary available for inspection; a quick DDT session on
>> it will reveal a lot of these things.
>
>I have the two binaries from the decus tape. That's all.
>
>But again, I don't know DDT to be able to really use it.
>
>I doubt that a quick look would reveal much, though. You'd have to know a
>lot about the program and its structure and data structures to even know
>where to look.
This is where you are completely wrong. PDP-10 programmers can
tell you a lot just by looking at the files. I can tell you
a lot about binary data files because I spent long hours looking
and editing them with FILDDT (a variant of DDT that allowed one
to look and modify a disk file rather than memory).
People who have spent long hours looking at code can tell a
lot about any executable, relocatable and other bit
arrangements. They can even figure out how to patch one
to get it to work a little bit.
>
>It's entirely possible that some areas use the full bits and that other
>areas might not need it.
>
>Or that some areas do use the full bits but do so only because it was
>convenient. That it could have been done with fewer too. (Just like on
>modern systems, where people may pack several characters into a 32 bit word.
>They are individual bytes, but they are being treated as a 32 bit word
>because it's convenient.)
But with DDT you can choose how any bit strings get displayed. You
can define the byte size and step through the program to see
if there's anything that makes sense. You can have DDT
display the bits as if it were code to see if it makes any
sense. Just about anybody who has typed R DDT can identify
where the monitor calls are and what the user code intended.
>
>A chess program is a very complicated program and looking at it raw can be
>very difficult.
It can't be as difficult as monitor or comm code.
> .. That's one of the reasons I am very reluctant to try to
>reverse engineer it if I don't have to.
>
>
>> As I said, if you have got the binary and whatever info surrounding it I
>> can volunteer to fire up an emulator and have a look; getting some real
>> data on what we really have before us.
>
>The binaries are readily available on the decus tape.
>
>I don't remember which one right off hand... Look for the file 'chess.how'.
>That's the help file. It'll be on two seperate tapes.
>
>The sizes are different, so I don't know how they are different.
R FILDDT
CHESS.EXE
0$7T/
And then just hit <LF> until you get a ?<CTRL>G
Caveat: Something tells me that my fingers have
mucked it up. This is highly likely because all
the keys are the wrong place on my keyboard.
/BAH
At time, I remember thinking that anything to do with networks
was a moving target. But this was a personal thought no a
professional assessment. In those days, it sure seemed
like nobody could agree on anything other than a zero bit
was zero and a set bit was one; even that wasn't true because
of hex.
> ..The protocols worked prefectly on all of our
>IBM mainframes with IBM operating systems surrounded
>by highly paid IBM Systems Programmer types.
But the user thruput sucked. That's why sites liked to have
their users think they were yakking at an IBM but the real
work was getting done on a backend which was called a PDP-10.
After the real work was done, the bits that user expected was
shipped back to the IBM side as if it had never left.
>
>I don't know which marketing genius decided it was a good
>idea to make that terrible piece of stuff, but
>Dec sold it to us, and our marketing geniuses sold it
>to our customers and I had to support the damn pos.
POS? You are not talking about the decade I'm thinking of.
>
>Hmm, pos, does that mean Professional Operating System,
>yet another demon spawn of RSX?
I have no idea. When I see that, I get a flag that says
PDP-12 for some very strange reason that I cannot fathom.
/BAH
<snip--there's no point>
>> And there was more than one flavor of PDP-10. If this code did
>> specific KA instructions, there is a chance it will not execute
>> under the emulated TOPS-10 system. I don't know if it
>> would work under an ITS system.
>
>I have no idea.
>
>As I've been trying to point out, the MacHack VI project itself wasn't
>documented well. Mr. Greenblatt was just hacking out some code. It wasn't
>something that was going to be historical, so it wasn't documented. And
>even the later years weren't really documented.
>
>We don't know what did or did not actually happen. A few papers and a few
>dates is all we know for sure. The rest is just people writing down things
>they had heard and believed to be true.
And we are trying to tell you that you can tell a lot by looking
at the EXE file with DDT.
>
>I don't think anybody is sure why it was called "MacHack VI" Were there 5
>other versions before this one? Was that the sixth project in project
>"MAC"? Etc. I've heard ideas, but nothing that I'm reasonably sure of.
Roman numerals are never used to indicate version numbers;
those were always in octal. VI is six which may have been a
room number, a building, his sixth girlfriend or the number
of the CPU architecture. I couldn't give an educated guess
unless I knew how Greenblat thought and worked. We can guess
at this, too, by looking at his code. JMF was very good at
this task.
<snip>
>>>*IF* you care about the PDP hardware and its history and so on.
>>
>> Honey, you want to read code that was written waybackwhen
>> so the hardware and the history is important.
>
>The only relevant thing would be to know specifically the programs on the
>decus tape were for the pdp-10. And probably for TOPS-10.
>
>Most of the other stuff isn't really relevant to that specific situation.
>
>And none of it is relevant if Mr. Greenblatt does still have the source and
>can be persuaded to release it.
You are wrong here, too. Having a source never implies that
you can build an executable that will run. And this is a
law of computing life.
>
>
>
>>>The vast majority of stuff that's been said in here aren't even vaguely
>>>relevant to any of those things.
>>
>> How do you know this?
>
>Because several people have already pointed out that MacHack VI from the
>decus tapes DO work (at least mostly) on the emulators.
>
>So at this point, it's just a matter of me figuring out how to install and
>run TOPS-10 and then install MacHack VI from the decus tapes.
You should listen to Rich's suggestion about using somebody else's
PDP-10 site. You don't have the patience to do any -10 installation
nor will you be able to set up a system to run the game.
>
>
>>>The closest I care about the pdp itself is in following a sequence of
>>>steps
>>>to get the MacHack VI program running. The pdp emulator is just an end to
>>>the means, not the goal itself. The important part is the program.
>>
>> The only code that gets executed is the machine language. You
>> do understand this? Perhaps not. The younger generation
>> has never seen machine language because C hides it.
>
>pffft.
>
>Of course I know that. Don't be an ^%#@.
It isn't wise to piss off the den mother.
>
>Just because I never used the pdp doesn't mean I'm ignorant about computers.
>You'd think that in the 25 years I've used computers, I might have learned
>at least a few things.
One thing you have failed to learn is how to learn from experts.
I can almost go as far as stating that you can't identify an
expert.
>
>I've learned several assembly languages. (In fact, I've pointed that out
>before, in reference to my having heard that the 6809 supposedly had a
>similar flavor to what some of the PDP's had.) (Although it's also worth
>saying that I no longer do assembly coding and definetly dislike the x86
>assembly.)
There is huge difference between learning one and living with one.
The people who have been going out of their way to try to help
you are people who have lived, breathed and shat assembly language.
And they have done this with the very machine you need to use
to play the game.
>
>And the first compilers I used, I was a bit disapointed because it didn't
>generate as good assembly as what I could do. True, it was faster to write
>a program in a high level language, but the programs were larger and slower.
>
Then you fix the compiler or the OTS. We have experience in doing
that, too.
/BAH
...
>>Usually, an easy way to transfer files is one of the early priorities of an
>>emulator.
>
>Well, FTP is available, and it can be scripted on both sides. I would
>classify that as "easy".
>
I'd classify it as a big pain.
The problem is, writing something like NFS for most PDP-10 operating
systems is not really trivial. Most current operating systems assume
that a file is a string of 8-bit bytes and PDP-10 files just don't look
like that. The FTP protocol contains gyrations to deal with this issue
and I suppose one could incorporate them into an NFS server but
nobody's done it and that's why the PDP-10 community tends to use
native tools for most things. Look at the fun there's been targeting
gcc, binutils, the relevant libraries.
Anyway, my point is that the apparent lack of "progress" isn't out
of old-time crustiness on the part of the PDP-10 crowd but is more
a combination of the complexity of the task at hand and the lack of
impetus to put in the considerable effort required.
FWIW, I am truly *not* a PDP-10 expert. I am about the same age as
the KL-10 and first used TOPS-20 in, er, 2004. (I think I actually
touched the KL-10 that Mike Ross now owns but at the time the only DEC
stuff I had used was the PDP-11 and its spawn.) What I've found is
that while the community and the technology is a bit "weird" to
somebody of my era, it's usually that way for a good reason.
--
David Evans
Faculty of Computer Science dfe...@bbcr.uwaterloo.ca
Dalhousie University, Halifax, Canada http://bbcr.uwaterloo.ca/~dfevans/
> In article Pat Farrell <pfar...@nospam.com> wrote:
>>Specs? You want IBM to write solid specs so DEC can steal their
>>business?
>
> At time, I remember thinking that anything to do with networks
> was a moving target. But this was a personal thought no a
> professional assessment. In those days, it sure seemed
> like nobody could agree on anything other than a zero bit
> was zero and a set bit was one; even that wasn't true because
> of hex.
Which led us to the joys of ASN.1 in the 90s.
Interoperable networking was always a moving target,
at least until after DEC's sponsorship of ISO/OSI died.
>> ..The protocols worked prefectly on all of our
>>IBM mainframes with IBM operating systems surrounded
>>by highly paid IBM Systems Programmer types.
>
> But the user thruput sucked. That's why sites liked to have
> their users think they were yakking at an IBM but the real
> work was getting done on a backend which was called a PDP-10.
> After the real work was done, the bits that user expected was
> shipped back to the IBM side as if it had never left.
Users? You think the IBM folks cared about users? They didn't
even think about them.
None of the places that I worked at thought that way.
Most of the time, there was no way for the people who worked
on IBM gear to talk to folks working on KA/KI/KL. They didn't
share a common language.
>>I don't know which marketing genius decided it was a good
>>idea to make that terrible piece of stuff, but
>>Dec sold it to us, and our marketing geniuses sold it
>>to our customers and I had to support the damn pos.
>
> POS? You are not talking about the decade I'm thinking of.
No, the whole 2780/3780/hasp on a 11 connected to a KL
was a piece of stuff long before the marketoids at Dec
invented the second meaning of POS. I only dealt with it
on Tops20, dunno if equivalents existed for Tops-10.
>>Hmm, pos, does that mean Professional Operating System,
>>yet another demon spawn of RSX?
>
> I have no idea. When I see that, I get a flag that says
> PDP-12 for some very strange reason that I cannot fathom.
My tongue was firmly in cheek. POS on the Pro350 and Pro380
was clearly demon spawn of RSX.
--
Pat
>> ..For several years there, the 780 was *the*
>>standard unit of measure for all benchmarks comparing the relative
>>performance of different processors.
>
> That's a new one.
Not at all. The press talked about VUP (Vax Unit of Performance)
instead of MIPS (mythincal Indicator of Processor Speed)
and all the other vendors talked about it.
>>And it's also easy to forget that the VAX *was* the pinnacle of CISC
>>development, following the PDP-10 tradition of inventing ever more
>>complex instructions.
>
> No, this had to do with bytes and manipulating bytes.
I'm not following this one. The Vax took the worst of
the PDP-11 byte oriented, variable instruction length
wacko autoincrement design and multiplied it by
some huge number.
With the exception of the ILDB/IDPB and related instructions,
the 6/10/20 world was straight forward load and store.
>> ..(Did anyone ever *use* those KL-10 string
>>instructions?) It's only with hindsight that it's easy to see that the
>>pinnacle was a dead end.
Yes, we used them all the time.
They were put in for Cobol, and nearly all of the processing
on all six of our KLs was Cobol talking to System 1022.
Where the Cobol compiler didn't use them, I built
macro-20 functions that did.
>>No, I'm afraid we really can't rationalize it away: no matter how bad
>>the VAX or VMS may have actually been, the reason we hate the VAX is
>>because it blew our beloved PDP-10 line out of the water in a battle
>>none of us will really accept was fair.
>
> JMF and I were stockholders of DEC. It was in our interests to
> get the biz to succeed.
Your personal interest aside, I agree with the earlier comment.
The Vaxen killed the KLs without replacing them. For Dec,
it probably was a decent business decision. For me, it
killed a product that I loved and understood and that enabled
me to earn a very good living. When I was a freshman
engineering student, the old professor talked about how
steam locomotive designer was the hot business in 1920, but dead
by 1940, and we were warned not to get into the next steam locomotive
design rut. Warning ignored here. I loved the 10s and 20s, and hated
the Vaxen.
I think I could have handled the hardware, but the OS ignored
nearly everything that the LCG folks spent decades learning.
Which was shameful enough, but then they were rewarded
into putting the same mistakes into the Windows descendants that
we are cursed with using today.
Bitter, not me.
--
Pat
>>Well, FTP is available, and it can be scripted on both sides. I would
>>classify that as "easy".
>
> I'd classify it as a big pain.
You are correct. it is a pain.
>
> The problem is, writing something like NFS for most PDP-10 operating
> systems is not really trivial. Most current operating systems assume
> that a file is a string of 8-bit bytes and PDP-10 files just don't look
> like that.
Yes, they make that assumption. Very naive and wrong but
so widespread that it can't be changed.
Way back when, assuming 8-bit bytes was just wrong.
Now that memory and bandwidth and cycles are free,
it is not so terrible. But it seems to wasteful
to someone who was trained to care about each bit.
> FWIW, I am truly *not* a PDP-10 expert. I am about the same age as
> the KL-10 and first used TOPS-20 in, er, 2004. (I think I actually
> touched the KL-10 that Mike Ross now owns but at the time the only DEC
> stuff I had used was the PDP-11 and its spawn.) What I've found is
> that while the community and the technology is a bit "weird" to
> somebody of my era, it's usually that way for a good reason.
Right. Just like the problems I had explaining the Year 2000 problems
to folks in undergraduate CS programs in the late 90s. They
always asked, why not just put in two more bytes. The answer
was that when 200 MB disks cost $30 grand, two bytes wasted
on each record was a mortal sin. Times change, definitions of sins
change. In 1970 or so, wasting two bytes per record on a huge
100,000 record file was unthinkable.
--
Pat
I logged onto XKLeTen.PaulAllen.com, an XKL Toad-1 system running Tops-20 which
has the DECUS libraries on-line, and took a look at what was there, using the
PHOTO screen logging tool available under Tops-20:
*******************************************************************************
[PHOTO: Recording initiated Fri 9-Sep-2005 11:02AM]
!cd [decus.lib10.0156]
!v
PS:<DECUS.LIB10.0156>
110.INF.1;P525252 1 25(7) 29-Apr-1975 09:29:00 ALDERSON
CHESS.HOW.1;P525252 2 640(36) 13-Apr-1970 16:00:00 ALDERSON
.SAV.1;P525252 20 10151(36) 8-Jun-1970 17:00:00 ALDERSON
Total of 23 pages in 3 files
!tyPE (FILE) 110.INF.1
THIS IS DECUS #110
!head chess.how
THE GREENBLATT CHESS PROGRAM (MACHACK) RUNS UNDER CONTROL
OF THE DEC TIME-SHARING MONITOR FOR THE PDP-6/10.
THIS COPY COMES TO YOU FROM TYMSHARE, INTERGALACTIC COMPUTER
OPERATIONS, CALIFORNIA, USA RPG.
THE FOLLOWING COMMANDS ARE RELEVANT:
PB PLAY BLACK - INSTRUCTS MACHACK TO PLAY ON BEHALF
OF BLACK
!get chess.sav
!iNFORMATION (ABOUT) meMORY-USAGE
27. pages, Entry vector loc 140 len 254000
Section 0 R, W, E, Private
0-13 Private R, W, E
15-33 Private R, W, E
!reset
!cd [decus.lib20.0030]
!v
PS:<DECUS.LIB20.0030>
CHESS.EXE.1;P525252 28 14336(36) 22-Aug-1980 17:40:32 DECUS
.HOW.1;P525252 2 640(36) 13-Apr-1970 16:00:00 DECUS
Total of 30 pages in 2 files
!head chess.how
THE GREENBLATT CHESS PROGRAM (MACHACK) RUNS UNDER CONTROL
OF THE DEC TIME-SHARING MONITOR FOR THE PDP-6/10.
THIS COPY COMES TO YOU FROM TYMSHARE, INTERGALACTIC COMPUTER
OPERATIONS, CALIFORNIA, USA RPG.
THE FOLLOWING COMMANDS ARE RELEVANT:
PB PLAY BLACK - INSTRUCTS MACHACK TO PLAY ON BEHALF
OF BLACK
!get chess.exe
!i mem
27. pages, Entry vector loc 140 len 254000
Section 0 R, W, E, Private
0-13 CHESS.EXE.1 1-14 R, CW, E
15-33 CHESS.EXE.1 15-33 R, CW, E
!pop
[PHOTO: Recording terminated Fri 9-Sep-2005 11:04AM]
*******************************************************************************
Things to note:
1. The DECUS program numbers are usually given in octal, so library 156 is also
#110.
2. The Tops-10 entry is a .SAV file, while the Tops-20 entry is an .EXE file.
This reflects different internal layouts for the executable file itself
(zero compression, for example), but nothing about the memory image which
the file represents.
3. Loading the two versions into memory, they are apparently identical in
memory usage, making it more likely that they are the same program packaged
differently.
4. The file CHESS.HOW is identical between the two versions, stating that this
is a version from TYMSHARE. "THE DEC TIME-SHARING MONITOR FOR THE PDP-6/10"
is an early version of what later became known as Tops-10, so it's a port,
because Project MAC did not run this monitor, preferring the homegrown ITS.
5. RPG is, I believe, Dick Gruen, who was also at the Stanford AI Lab at one
time. It wouldn't surprise me at all that RG would give him a copy to bash
on.
6. The timestamp on the Tops-10 version shows that it is older than the Tops-20
operating system by about 5 years--and the DECUS people were scrupulous in
keeping timestamps for historical accuracy.
I can easily make disassemblies of the two available, should you wish to see
for yourself that the code is the same, and that only Tops-10 monitor calls
(i. e., system calls) are used.
I'll even make a bootable Tops-10 disk image for SimH available to you, if you
have someplace I can send 70MB (the approximate size of a bzip2'd RP06 disk
image).
--
Rich Alderson | /"\ ASCII ribbon |
ne...@alderson.users.panix.com | \ / campaign against |
"You get what anybody gets. You get a lifetime." | x HTML mail and |
--Death, of the Endless | / \ postings |
>>I doubt that a quick look would reveal much, though. You'd have to know a
>>lot about the program and its structure and data structures to even know
>>where to look.
>
> This is where you are completely wrong. PDP-10 programmers can
> tell you a lot just by looking at the files. I can tell you
Not just PDP-10 programmers. A lot of experienced programmers can.
But, you've missed the point.
You are confusing the implementation with the algorithms.
"How" he did something instead of "why".
I'm very familiar with chess programming. I've been doing it off and on
(mostly off), for 15 years.
Some stuff I do on a 32 bit processor is basically the same as what I was
doing before, except I'm using the extra bits.
So although the implementation has changed, most of the basic algorithms
haven't.
Looking at the pdp disassembly would only give you the details of the
implementation. Not the why. And it's the 'why' that would be relevant to
portability.
Let's take an example of bitboards. http://en.wikipedia.org/wiki/Bitboard
if you aren't familiar with the term. (I don't think MacHack VI used
bitboards, but that's not the point.)
Arthur Samuel used 'bitboards' way back in the mid 50's. For his famous
checker's program, he used the IBM 704's 36 bit word length to hold his
checker board.
The way he did it used all 36 bits. His program required all 36 bits.
However, just a slight change and a very miniscule amount of extra work is
all that's required for a standard 8x8 checkers board to work just as well
on a 32 bit system.
But looking at just the disassembly of his program, it'd be very difficult
to realize that.
Those (and more) are the kinds of things I'm talking about.
Implementation vs. algorithmic necessity.
Trying to seperate the two from just a rough disassembly is going to be very
difficult. You'd need much more along the lines of a full commented
recreation to see what he was doing and why.
But since it's not going to be ported, this is moot.
>>A chess program is a very complicated program and looking at it raw can be
>>very difficult.
>
> It can't be as difficult as monitor or comm code.
Actually, it can be. (Of course, whether it is or not depends entirely on
the examples of each that you pick.)
Then throw in the various other parts, such as the evaluator and the
plausible move generator. Those can have lots of interactions and chess
specific information. Deciphering those could be a challenge.
>
> 2. The Tops-10 entry is a .SAV file, while the Tops-20 entry is an .EXE
> file.
> This reflects different internal layouts for the executable file itself
> (zero compression, for example), but nothing about the memory image
> which
> the file represents.
I figured there would be differences. But I had no way to know anything
beyond that.
> 3. Loading the two versions into memory, they are apparently identical in
> memory usage, making it more likely that they are the same program
> packaged
> differently.
Yeah, that is likely.
That's good to know. It means one less possible hassle.
> 4. The file CHESS.HOW is identical between the two versions, stating that
> this
> is a version from TYMSHARE. "THE DEC TIME-SHARING MONITOR FOR THE
> PDP-6/10"
> is an early version of what later became known as Tops-10, so it's a
> port,
> because Project MAC did not run this monitor, preferring the homegrown
> ITS.
Yeah.
I wonder if the port was done by Greenblatt himself or someone else...
He did used to give away copies of the source to various people.
> 5. RPG is, I believe, Dick Gruen, who was also at the Stanford AI Lab at
> one
> time. It wouldn't surprise me at all that RG would give him a copy to
> bash
> on.
Very possible.
Some of the classic programs were distributed fairly freely back then.
It really makes it all the more amazing that the sources haven't survived.
> 6. The timestamp on the Tops-10 version shows that it is older than the
> Tops-20
> operating system by about 5 years--and the DECUS people were scrupulous
> in
> keeping timestamps for historical accuracy.
Interesting tidbit...
It's possible that was during the period that Greenblatt wasn't working on
his program much. So there may not have been a newer (stronger) one to use.
Or maybe they ported it themselves from the same source, figuring it was
"good enough."
> I can easily make disassemblies of the two available, should you wish to
> see
> for yourself that the code is the same, and that only Tops-10 monitor
> calls
> (i. e., system calls) are used.
Sure, I'd like to see that.
I can't say it'll help me any, but that'd still be somewhat interesting to
look at.
Let me know how big the compressed sources are. If they are too big, I may
have to go over to someplace and sign up for a free email address.
(My ISP limits things to only a couple meg. Pretty stingy with their email.
And that's when it works right... They also like playing with spam filters.
Agressively so.)
> I'll even make a bootable Tops-10 disk image for SimH available to you, if
> you
> have someplace I can send 70MB (the approximate size of a bzip2'd RP06
> disk
> image).
That would be nice, but I have no way to receive anything that large...
70 meg??!
Wow.... That could really put a crimp into my desire to have a downloadable
disk image for people to use!!!
I wasn't expecting it to be more than a couple megs.
I had no idea that TOPS-10 was as bloated as what Windows 98 was...!
Heck, I've got Win95 disk images that are smaller than that.
And my old DOS & Win3 images are smaller still. Even with a few apps
installed.
Wow. I gotta admit, that size really surprised me.
Don't have to do NFS.
You just have to:
1) have a seperate host based program that can read / write PDP-10 disks
(for various OS's). This can let you work with the actual disk & tape
images. Browse, delete, add, modify, edit, repair, etc. However far you
want to go.
or
2) Have the emulator use a shared local directory and make that appear as a
ftp site (or such) to the guest. With the emulator pretending to be the
remote ftp site itself. Several other options.
There are even other options. Many of which are host independant. Some of
which are host dependant.
If you want to get fancy, then you can go further. But you don't have to.
>>We don't know what did or did not actually happen. A few papers and a few
>>dates is all we know for sure. The rest is just people writing down
>>things
>>they had heard and believed to be true.
>
> And we are trying to tell you that you can tell a lot by looking
> at the EXE file with DDT.
Some.
But not enough.
No matter how much you might learn from that particular copy (which probably
wont be as much as you expect), that's not going to say much, if anything,
about any other version. (Short of doing a full disassembly and actually
studying it, of course.)
Is the version that's on the DECUS tapes an early buggy version? [shrug]
No way to know.
There are lots of things it just can't tell you.
>>I don't think anybody is sure why it was called "MacHack VI" Were there 5
>>other versions before this one? Was that the sixth project in project
>>"MAC"? Etc. I've heard ideas, but nothing that I'm reasonably sure of.
>
> Roman numerals are never used to indicate version numbers;
> those were always in octal. VI is six which may have been a
Could be personal preference.
It could also be that somebody else named the program.
> room number, a building, his sixth girlfriend or the number
> of the CPU architecture. I couldn't give an educated guess
> unless I knew how Greenblat thought and worked. We can guess
There is a very distinct possibility that Mr. Greenblatt was not the person
that actually named the program.
So that complicates things even more.
There's a lot we don't know about MacHack VI.
>>And none of it is relevant if Mr. Greenblatt does still have the source
>>and
>>can be persuaded to release it.
>
> You are wrong here, too. Having a source never implies that
> you can build an executable that will run. And this is a
> law of computing life.
I don't think anybody has any real plans to rebuild an executable.
Sure, it'd be nice. As would a C version.
But at this point, it's mostly about preserving the source for it, and
reading it and admiring it, etc.
It's a very distinct possibility that he has the last surviving copy of the
source, and it's suffering bit-rot in his garage.
>>So at this point, it's just a matter of me figuring out how to install and
>>run TOPS-10 and then install MacHack VI from the decus tapes.
>
> You should listen to Rich's suggestion about using somebody else's
> PDP-10 site. You don't have the patience to do any -10 installation
> nor will you be able to set up a system to run the game.
If we manage to get enough chess programs to really set up an archive site,
having a downloadable version of MacHack VI that people can actually
download and play is a much better choice than having them go to some other
site and play it online.
True, some people may prefer to do it online. I think a lot of people
wouldn't though.
(For the record, it'd also be nice to have a few other classic chess
programs in a downloadable emualtor form. Chess 4.9 and CrayBlitz, for
example. But that's probably not going to happen. Not the least of which
is that I don't think there is a Cray emulator available to run CrayBlitz
on...)
No, you don't.
>You just have to:
>
>1) have a seperate host based program that can read / write PDP-10 disks
>(for various OS's). This can let you work with the actual disk & tape
>images. Browse, delete, add, modify, edit, repair, etc. However far you
>want to go.
>
It's unclear what this would get you beyond what's provided already
using FTP. You wouldn't have to fire up an emulated machine in order
to work with the contents of your disks, but I don't think that poeple
need to do this very often.
>2) Have the emulator use a shared local directory and make that appear as a
>ftp site (or such) to the guest. With the emulator pretending to be the
>remote ftp site itself. Several other options.
>
That could be done, but again, given that you can ftp in and out
already, this doesn't really get you more functionality than exists
right now.
I'm not shooting down your goal of great host/PDP-10 integration--I
think it would be great. But going beyond FTP, which I think needs
to be done for a scheme like this to be an improvement on the status
quo, is a bunch of work. Not to mention that file transfer is a
very small part of comprehensive "external support".
>>>And none of it is relevant if Mr. Greenblatt does still have the source
>>>and
>>>can be persuaded to release it.
>>
>> You are wrong here, too. Having a source never implies that
>> you can build an executable that will run. And this is a
>> law of computing life.
>
> I don't think anybody has any real plans to rebuild an executable.
Guess I should clarify that.
Yes, the subject says 'assembler'.
That was because at the time I was thinking about doing a full source
recreation. And that requires an assembler to verify your work.
Do a full disassembly. Reassemble to verify it's correct.
Improve the disassembly. Reassemble to verify it's correct.
Add descriptive labels. Reassemble to verify it's correct.
Etc. etc.
So yes, if I was going to do a full source recreation, an assembler would be
needed.
But if we can get the source from Mr. Greenblatt, then the assembler
wouldn't be needed.
> "Rich Alderson" <ne...@alderson.users.panix.com> wrote in message
> news:mdd4q8u...@panix5.panix.com...
>> I'll even make a bootable Tops-10 disk image for SimH available to you, if
>> you have someplace I can send 70MB (the approximate size of a bzip2'd RP06
>> disk image).
> That would be nice, but I have no way to receive anything that large...
> 70 meg??!
That's compressed with bzip2, the current best cross-platform bit-packer I
know. The uncompressed image is 315MB.
> Wow.... That could really put a crimp into my desire to have a downloadable
> disk image for people to use!!!
> I wasn't expecting it to be more than a couple megs.
> I had no idea that TOPS-10 was as bloated as what Windows 98 was...!
> Heck, I've got Win95 disk images that are smaller than that.
> And my old DOS & Win3 images are smaller still. Even with a few apps
> installed.
> Wow. I gotta admit, that size really surprised me.
The RP06 disk pack held 175MB (though 18-bit formatting instead of "standard" =
IBM-compatible formatting made it a little smaller); the SimH emulator does not
do anything to shrink things, and represents 36-bit words in 64-bit integers,
so you get a BIG file. KLH10 will let you use other models (like 9 8-bit bytes
per 2 36-bit words), but is happiest with the same kind of 36-in-64 that SimH
uses.
I'll get back to you on the size of the disassemblies; the chess program is
apparently too complex for the simpleminded way I handled labeling branch
targets.
There is a SIMH TOPS-10 7.03 image available at pdp10.kilonet.org and it's
23 megs or so.
aak
> VMS didn't help at all. It was also a monstrosity of complexity.
> I was there, in the trenches, when DEC lost the race again and again
> to the Prime, ND, HP, Wang and DG machines. All of these had their
> window of opportunity because the VAX was such an abomination.
Interesting to note that while VMS is still here, Prime, Wang and DG are
long gone.
--
Huw Davies | e-mail: Huw.D...@kerberos.davies.net.au
Melbourne | "If soccer was meant to be played in the
Australia | air, the sky would be painted green"
And survived despite three successive CEOs to get rid of it.
This should also tell you something. You VMS people have
an opportunity; please don't fuck it up like the 10/20 people
did.
/BAH
I'm sure they did talk about it. Yakking doesn't imply
real comparisons. I never saw the word VUP; that must
have been after comparisons to main frames stopped.
>
>>>And it's also easy to forget that the VAX *was* the pinnacle of CISC
>>>development, following the PDP-10 tradition of inventing ever more
>>>complex instructions.
>>
>> No, this had to do with bytes and manipulating bytes.
>
>I'm not following this one.
Byte addressing was desired and thought to be the
way to deal with data processing computing. String
manipulation was getting more and more common among
DEC customers. IBM did string-flavored computing
extremely well. DEC was playing catchup in this
area at the time.
> .. The Vax took the worst of
>the PDP-11 byte oriented, variable instruction length
>wacko autoincrement design and multiplied it by
>some huge number.
The VAX architects did not start with an -11. Do not
confuse the hardware development with the software
chosen to start as the base.
>
>With the exception of the ILDB/IDPB and related instructions,
>the 6/10/20 world was straight forward load and store.
Yes. And it sucked. That's why DEC worked on created
hardware that could do string manipulation.
>
>
>>> ..(Did anyone ever *use* those KL-10 string
>>>instructions?) It's only with hindsight that it's easy to see that the
>>>pinnacle was a dead end.
>
>Yes, we used them all the time.
Then you should have understood why DEC thought that this
should be at the hardware level and not at machine nor
microcode level.
>They were put in for Cobol, and nearly all of the processing
>on all six of our KLs was Cobol talking to System 1022.
>Where the Cobol compiler didn't use them, I built
>macro-20 functions that did.
Yes, well. Language development group had its problems.
>
>>>No, I'm afraid we really can't rationalize it away: no matter how bad
>>>the VAX or VMS may have actually been, the reason we hate the VAX is
>>>because it blew our beloved PDP-10 line out of the water in a battle
>>>none of us will really accept was fair.
>>
>> JMF and I were stockholders of DEC. It was in our interests to
>> get the biz to succeed.
>
>Your personal interest aside, I agree with the earlier comment.
>The Vaxen killed the KLs without replacing them.
No, VAXen did not kill the KLs. The KLs were scheduled to become
obsolete in the early 80s. The KLs were too big, too power hungry
and too expensive and were scheduled to become unsupported in
a couple of years.
> ..For Dec,
>it probably was a decent business decision. For me, it
>killed a product that I loved and understood and that enabled
>me to earn a very good living. When I was a freshman
>engineering student, the old professor talked about how
>steam locomotive designer was the hot business in 1920, but dead
>by 1940, and we were warned not to get into the next steam locomotive
>design rut.
And I was told to expect to have my job change every five years.
Read that? FIVE. That is the computing biz.
> ..Warning ignored here. I loved the 10s and 20s, and hated
>the Vaxen.
That's because you knew what a timesharing system was supposed
to do. It took an underground infiltration of PDP-10ers into
VMS land to get VMS to the point that it could do some
decent timesharing. Getting rid of three people helped
tremendously in this.
>
>I think I could have handled the hardware, but the OS ignored
>nearly everything that the LCG folks spent decades learning.
Exactly. It went further than that. The chief VMS architect
wrote code to prevent any, and I mean any, PDP-10 computing
innovations to be implemented in VMS. Fortunately, for
VMS, he cracked his head wide open and lost the ability to
think. This guy did this despite Bell telling to do the
opposite.
>Which was shameful enough, but then they were rewarded
>into putting the same mistakes into the Windows descendants that
>we are cursed with using today.
That happened because of a second software architect who kept
undermining the VMS development. There was a reason he
was removed physically and organizationally. Why do you
think NT cannot deal with thousands of users? The chief
architect never thought that thousands should be allowed
on a system at once, let alone give these users the
impression that they could access all the resources.
>
>Bitter, not me.
Believe it or not, I understand. You would not still be
bitter if you had been handed a well-designed transition
from the PDP-10 platform to the VAX. If we had handed you
an emulator that gave you the false impression that
you were working under a -20 or a -10, you would have
eventually transformed your working habits to the VAX.
Going from the PDP-10 to the VAX would have been like,
make that should have been like, going from a stickshift
to an automatic transmission in your car.
/BAH
/BAH
> In article <XOgUe.13352$Zp.9918@lakeread04>,
> Pat Farrell <pfar...@nospam.com> wrote:
>>Not at all. The press talked about VUP (Vax Unit of Performance)
>>instead of MIPS (mythincal Indicator of Processor Speed)
>>and all the other vendors talked about it.
>
> I'm sure they did talk about it. Yakking doesn't imply
> real comparisons. I never saw the word VUP; that must
> have been after comparisons to main frames stopped.
Well, that may be more of a comment on your exposure to
non-DEC thinking. It was all over the press in the
early 80s.
I'm not sure that DEC ever made "mainframes"
They made big fast iron, but it never was
considered a real competitor to the 3090s, etc.
And we had both, and the guy in the office
next to me was the Direcctor of IBM
Systems Programming, just as I was the
Director of Dec Systems Programming.
If the CI and other stuff had come on early,
and been successful, and maybe if the next thing
after the Jupitor had been a success, then you
could have talked about a Dec mainframe the
same way IBM did. I didn't care.
The KLs did what our business needed
except they were too damn slow and too
damn expenive in lots of metrics.
>>> No, this had to do with bytes and manipulating bytes.
>>
>>I'm not following this one.
>
> Byte addressing was desired and thought to be the
> way to deal with data processing computing. String
> manipulation was getting more and more common among
> DEC customers. IBM did string-flavored computing
> extremely well. DEC was playing catchup in this
> area at the time.
OK, yes, doing BCD artitimetic in hardware, and having
all the byte mangling instructions made medocre IBM systems
way better for boring Cobol than my six 20s. But,
even so, I could get a business application written
and delivered for a fraction of the cost of doing it
with the other iron.
Of course, Total Cost of Ownership wasn't a buzzword back then.
> The VAX architects did not start with an -11. Do not
> confuse the hardware development with the software
> chosen to start as the base.
Sure could have fooled me. The instructions were the same,
had the same lame autoincrement register pointers and
wildly varying instruction lengths, formats, etc.
> Yes. And it sucked. That's why DEC worked on created
> hardware that could do string manipulation.
They did? I never saw any. I guess the KIs had hardware, but
the KL microcode was only hardware to LCG. It was software
to the rest of the world.
> Then you should have understood why DEC thought that this
> should be at the hardware level and not at machine nor
> microcode level.
I don't know. Never saw any indication of that in many
trips to Marlboro. Lots of NDAs, etc.
>>They were put in for Cobol, and nearly all of the processing
>>on all six of our KLs was Cobol talking to System 1022.
> Yes, well. Language development group had its problems.
Just a few, eh?
> No, VAXen did not kill the KLs. The KLs were scheduled to become
> obsolete in the early 80s. The KLs were too big, too power hungry
> and too expensive and were scheduled to become unsupported in
> a couple of years.
That is correct. the KLs were new pretty new in April, 1976
when First Data burned down. Everett and Swithers and others ported
our local TOPS-10 to the KL in the fishbowl on the first floor of
the Marlboro factory (MR01?). and I was drafted to operate it
because all the real operators were cleaning up in Waltham.
But by your five year rule, the KLs should have been replaced by
something faster, cooler, less power sucking, etc. by 1981,
and again in 1986.
So while I mispoke in saying that the Vaxen killed the KLs,
what I should have said is that the evil Vaxen killed the
replacements for the KL, and that killed the LCG lines.
After years of working on Tops-20, I really didn't care much
about the TOPS-10 OS, it was famous mostly because it was
more efficient of hardware, the 20 was a lot more
efficient of programmers. TCO and all that.
>> ..Warning ignored here. I loved the 10s and 20s, and hated
>>the Vaxen.
>
> That's because you knew what a timesharing system was supposed
> to do.
It isn't clear to me, even in hindsight, that timesharing would
have stayed important anyway. Cheaper boxes made it hard
to justify paying my company $100,000 per month for timesharing,
even when it delivered a lot of real value to the customers.
Some of it was just terminology. Now, all the buzzwords have n-tiered
systems with smart terminals (browsers) talking to applications on
webservers. We actually had most of this using Pro-350s talking
to KLs in 1981 or 82. Just way ahead of the game.
> It took an underground infiltration of PDP-10ers into
> VMS land to get VMS to the point that it could do some
> decent timesharing. Getting rid of three people helped
> tremendously in this.
Sadly too little too late.
>>I think I could have handled the hardware, but the OS ignored
>>nearly everything that the LCG folks spent decades learning.
>
> Exactly. It went further than that. The chief VMS architect
> wrote code to prevent any, and I mean any, PDP-10 computing
> innovations to be implemented in VMS.
So much for LCG's much pushed "integration"
We all knew it was a scam.
>>Which was shameful enough, but then they were rewarded
>>into putting the same mistakes into the Windows descendants that
>>we are cursed with using today.
>
> That happened because of a second software architect who kept
> undermining the VMS development. There was a reason he
> was removed physically and organizationally. Why do you
> think NT cannot deal with thousands of users? The chief
> architect never thought that thousands should be allowed
> on a system at once, let alone give these users the
> impression that they could access all the resources.
Oh, I know for sure about David.
What a blockhead. In the book "Showstopper" about
the development of NT, there is a long section
on trying to reduce the memory requirements of NT.
Seems David didn't understand about swappable sections
or the OS. I know it was in Tops-20, and probably in
parts of TOPS-10 and even Tenex.
Those who refuse to learn from history are doomed
to repeat it.
>>Bitter, not me.
>
> Believe it or not, I understand. You would not still be
> bitter if you had been handed a well-designed transition
> from the PDP-10 platform to the VAX. If we had handed you
> an emulator that gave you the false impression that
> you were working under a -20 or a -10, you would have
> eventually transformed your working habits to the VAX.
I did, it is called LAMP. Linix, Apache, MySql and Perl/php
It is essentially exactly what we were doing in 1980 on
KLs.
> Going from the PDP-10 to the VAX would have been
And it would have made DEC a lot more money.
Maybe they would have bought Compaq and HP.
Oh well
--
Pat
> In article <XOgUe.13352$Zp.9918@lakeread04>,
> Pat Farrell <pfar...@nospam.com> wrote:
>> .. The Vax took the worst of the PDP-11 byte oriented, variable instruction
>> length wacko autoincrement design and multiplied it by some huge number.
> The VAX architects did not start with an -11. Do not confuse the hardware
> development with the software chosen to start as the base.
Barb, the VAX was introduced as the "_V_irtual _A_ddressing e_X_tension of the
PDP-11" in Digital's own marketing literature. And the first OS for the VAX
was RSX-11. Not a *port* of RSX-11, just RSX-11.
This was not just a press thing -- the VAX-11/780 was the formal
unit of performance. From Hennessey & Patterson, _Computer
Architecture, A Quantitative Approach_, 2nd Ed., 1995, p. 27,
speaking of measuring performance by timing benchmark software:
"This is the approach used by the SPEC benchmarks, where a base
time on a VAX-11/780 is used for reference."
For years and years past when the VAX-11/780 was in common use,
it remained the "1" on performance scales. A Google search for
"SPECmark VAX" turns up lots of material, e.g.:
http://www.computeruser.com/resources/dictionary/definition.html?lookup=5590
"Definition for: VAX Unit of Performance:
VUP: A unit of measurement of computer performance.
One VUP is equivalent to the performance of Digital Equipment
Corporation’s VAX 11/780. It is also equivalent to one SPECmark."
So if you heard performance quoted in SPECmarks, that was VUPs.
It wasn't just the SPEC suite that used it -- it was common to use
the VAX-11/780's performance as "1" for all sorts of metrics besides
runtime.
>>With the exception of the ILDB/IDPB and related instructions,
>>the 6/10/20 world was straight forward load and store.
>
>
> Yes. And it sucked.
Ow. Beg to differ. I can't go into detail, being under extreme
deadline pressure just now, but there were *many* features of the
-10 instruction set architecture that put it way past others of the
time, and most since. (If we *do* want to go into this further,
we should split off into a separate thread.) It captured many of
the best RISC features, but still had a rich set of operations.
Just a few items (I have a fairly thorough list somewhere -- I know
I'm leaving out a lot):
-- Highly orthogonal instruction format and opcode values.
Instruction decode is simple, and many CPU hardware
functions can be driven straight off the raw instruction
bits.
-- Fixed length instructions.
Just as in the RISC justification, this simplifies prefetch.
The extended instructions seem at first glance to break this,
but really don't -- they can be handled as data. Likewise
the implicit loop instructions (e.g. BLT) don't need a lot of
fixup in the fetch stage -- they generate their own next
instructions, so fetch can stall.
-- Very large address range within the offset field.
My first year in college, I worked on a compiler project
written in XASM, an alternate assembler for the IBM 360,
and later did a lot of BAL programming. Remember "USING"?
Had to use up a register for every 8 bits worth of address
range, and that was in *bytes*, just to store a base address
for labels and jumps. And heaven help you if you neglected
to actually fill the register with the address you promised
to the assembler!
When I later started programming in MACRO-10, it was like
the light dawned. It was never necessary to chunk up single
routines or even single program modules into little pieces
just because of a tiny branch offset. Programs that were too
big overall for one section always had natural subdivisions
that made sense to be put in separate sections, just for
organizational purposes.
-- User stacks and stack manipulation instructions.
AMEN. This made user program context switches trivial. E.g.
LPTSPL had a context for each printer. As each printer blocked,
all it had to do to go on to the next was pick up the pointer
to the next active printer context, BLT in its registers, and
POPJ to where that printer had left off. And stacks could be
used for all sorts of other purposes, e.g. parsing, implementing
pushdown automata -- could have as many as one wanted, didn't
have to "share" with program execution.
>>The Vaxen killed the KLs without replacing them.
>
> No, VAXen did not kill the KLs.
Killed Jupiter, though, and hence further development of the -10
architecture. Or at least, that's what us customers heard -- that
competition between the LCG and VAX groups couldn't be resolved
amicably, and the VAX group won. (I started working at DEC only
long after, in 1992, so saw none of that from the inside.)
I'm not going to diss the VAX nor VMS. I like both, and used
both for many years. I just wish the -10 architecture could
have lived on as well, and/or that it had had more influence on
the Alpha.
> Why do you
> think NT cannot deal with thousands of users? The chief
> architect never thought that thousands should be allowed
> on a system at once.
There was also a business decision in there. When NT engineers
came to talk to the University of Washington DECUS group, before
NT was really a product, I asked why it wasn't going to support
full timesharing and multiple users. The reply was, and I quote,
"That doesn't fit our model of client-server computing." That is,
NT was intended as the back end server, and regular Windows
machines would be the user front ends.
This is actually not a bad model -- run the GUI on a separate box,
and since that box has spare capacity, also run local apps. This
is also the justification for the smart terminal / thin client,
except those typically didn't run much beyond the GUI. (It's
also pretty much what I'm doing right now, sitting at a Linux
box with no local user files other than scratch space.) And this
model allowed Microsoft to sell a lot more "seats" -- separate
Windows installations. Rather than develop a new thin client,
they could just use what they already had, and it could still be
used standalone. NT was not, at the time, really going to be an
application server, either -- it was going to provide file and
network services.
The fault lay in not realizing that the full user and process
isolation provided by timesharing was also a benefit for a server,
and even for multiple applications run by one user, run on their
own client machine. This was not a Microsoft-specific issue --
Apple didn't have process isolation. And most big-iron mainframes
were batch-oriented, so it wasn't there either. (IBM's VM provided
fierce isolation, but at the expense of making it very difficult
to communicate between users.) (Scheduling is a separate issue.
NT had a timesharing scheduler -- one of many different flavors
of timesharing scheduler, but still timesharing. I'm guessing
that I may get some grumbling in reply...)
These days, IMO, we need not only the sort of isolation provided
by traditional timesharing, but also the protection against
untrusted code provided by virtual machines, sandboxing, "safe"
languages, restricted task-specific languages, and suchlike.
-- Pat
<sheesh> Talk about guaranteed fudge factors.
>
>For years and years past when the VAX-11/780 was in common use,
>it remained the "1" on performance scales. A Google search for
>"SPECmark VAX" turns up lots of material, e.g.:
>
>http://www.computeruser.com/resources/dictionary/definition.html?lookup=5590
>
>"Definition for: VAX Unit of Performance:
>VUP: A unit of measurement of computer performance.
>One VUP is equivalent to the performance of Digital Equipment
>Corporation’s VAX 11/780. It is also equivalent to one SPECmark."
>
>So if you heard performance quoted in SPECmarks, that was VUPs.
Perhaps this is where ignoring user thruput in the field got
started.
>
>It wasn't just the SPEC suite that used it -- it was common to use
>the VAX-11/780's performance as "1" for all sorts of metrics besides
>runtime.
If I were a DEC competitor I'd use it as a base, too.
>
>>>With the exception of the ILDB/IDPB and related instructions,
>>>the 6/10/20 world was straight forward load and store.
>>
>>
>> Yes. And it sucked.
>
>Ow. Beg to differ. I can't go into detail, being under extreme
>deadline pressure just now, but there were *many* features of the
>-10 instruction set architecture that put it way past others of the
>time, and most since.
Sigh! Sorry. By "it" I meant byte manipulation sucked on the
-10. It came out of engineering-flavored thinking, not
COBOL-flavored thinking. Trying to addon a COBOL adroitness
onto the hardware whose computing services was based on
providing science and engineering didn't work well (where
"work well" = user thruput).
Look, whenever anybody does a design, there are basic assumptions
made. Most of the time, these assumptions are due to the
background experience of the designers and never specified.
If your assumptions are science and/or engineering based, then
there is no way you are going to include the DBMS-flavored
processing. DBMS-flavored thinking was not a DEC folklore.
Absolutely nobody knew how to think that way.
> .. (If we *do* want to go into this further,
Sigh! No.
> .. though, and hence further development of the -10
>architecture. Or at least, that's what us customers heard
Yes, well.
> ..-- that
>competition between the LCG and VAX groups couldn't be resolved
>amicably, and the VAX group won.
There was no competition. What happened was that Bell made
a corporate speech. And spoke about his thought experiments.
This is the classic case when he made a mess and we couldn't
clean it up for him. He started talking about the future,
such as 90s and 2000s. Within this context, he said, "..there
should be one operating system..."; he meant that there should
be one, and only one, software project for each new piece of
hardware and not n project where n=all the OS user interfaces
we had at the time.
Nobody in non-LCG land heard the context of this sentence.
Instead, they took it as a direct order to cancel all
projects, work, meetings, funding, marketing, support, planning,
manufacturing, shipping of anything that had a whiff of LCG.
It was done within a week. LCG didn't get a scent of this
event until our meetings were cancelled, cross charging came
back as void, etc.
That was the week that DEC died. Not when Jupiter was cancelled.
> .. (I started working at DEC only
>long after, in 1992, so saw none of that from the inside.)
>
>I'm not going to diss the VAX nor VMS. I like both, and used
>both for many years. I just wish the -10 architecture could
>have lived on as well, and/or that it had had more influence on
>the Alpha.
The Alpha did have -10 influence. It had Pete Conklin. JMF
did [what I call] the CPU driver. I don't know who the
hardware architect was. I would assume that there was
some flavor of Kotok influence.
<snip--I'll leave this for others>
/BAH
Sigh! We never made data-processing gear. Now,
if you want to define a mainframe as something
that can do dedicated record processing a mile a minute,
that's your choice. IBM knew how to deal with
disk farms. DEC never did. Think of one file around
1980 or so that took up a hundred or more RP06s. _ONE_
file. You don't boot a timesharing monitor for that.
Any TTY interrupt would detract from managing that monster
file.
>They made big fast iron, but it never was
>considered a real competitor to the 3090s, etc.
>And we had both, and the guy in the office
>next to me was the Direcctor of IBM
>Systems Programming, just as I was the
>Director of Dec Systems Programming.
>
>If the CI and other stuff had come on early,
>and been successful, and maybe if the next thing
>after the Jupitor had been a success, then you
>could have talked about a Dec mainframe the
>same way IBM did.
No. None of those ifs would have helped us be
the same as IBM. IBM had a data processing folklore.
DEC did not.
> .I didn't care.
>The KLs did what our business needed
>except they were too damn slow and too
>damn expenive in lots of metrics.
The slowness was due to your OS choice.
>
>
>>>> No, this had to do with bytes and manipulating bytes.
>>>
>>>I'm not following this one.
>>
>> Byte addressing was desired and thought to be the
>> way to deal with data processing computing. String
>> manipulation was getting more and more common among
>> DEC customers. IBM did string-flavored computing
>> extremely well. DEC was playing catchup in this
>> area at the time.
>
>OK, yes, doing BCD artitimetic in hardware, and having
>all the byte mangling instructions made medocre IBM systems
>way better for boring Cobol than my six 20s. But,
>even so, I could get a business application written
>and delivered for a fraction of the cost of doing it
>with the other iron.
Bingo! Timesharing-based OSes allowed a higher user thruput
than any system designed for data processing. A shop
would have their developments on the PDP-10 mainframe
which would be used on the IBM mainframe that had to run
non-user jobs. IOW, the IBM was not to be used for
user interactive activities.
>
>Of course, Total Cost of Ownership wasn't a buzzword back then.
>
>
>
>> The VAX architects did not start with an -11. Do not
>> confuse the hardware development with the software
>> chosen to start as the base.
>
>Sure could have fooled me. The instructions were the same,
>had the same lame autoincrement register pointers and
>wildly varying instruction lengths, formats, etc.
My first and last exposture to VAX instruction set was
at Jud Leonard's seminar. I recall no resemblance of
the two instruction sets. There was about as much
similarity as with the -10's. E.g., moves started with
an M.
>
>
>> Yes. And it sucked. That's why DEC worked on created
>> hardware that could do string manipulation.
>
>They did? I never saw any. I guess the KIs had hardware, but
>the KL microcode was only hardware to LCG.
I'm sure you would know that. [emoticon drooling sarcasm]
Are you really trying to tell me
how we thought? The production and managing of the microcode
was in the hardware group, but I can assure you that we knew
the difference between something you can kick and something
you had to load^Wmassage into core.
> .. It was software
>to the rest of the world.
They were also wrong since the world could not patch it,
debug it, modify it, and fixing it required midnight
sacrifices ;-).
>
>
>> Then you should have understood why DEC thought that this
>> should be at the hardware level and not at machine nor
>> microcode level.
>
>I don't know. Never saw any indication of that in many
>trips to Marlboro. Lots of NDAs, etc.
Perhaps you had to work there to see it. It certainly was
true that we bitched about hardware's management styles
and decisions about the microcode. Getting a bug fix
and shipped took longer to schedule and deliver than
a major monitor release. But that certainly didn't
imply that we thought microcode was real hardware.
>>>They were put in for Cobol, and nearly all of the processing
>>>on all six of our KLs was Cobol talking to System 1022.
>> Yes, well. Language development group had its problems.
>
>Just a few, eh?
Methinks you are speaking to yourself.
>
>> No, VAXen did not kill the KLs. The KLs were scheduled to become
>> obsolete in the early 80s. The KLs were too big, too power hungry
>> and too expensive and were scheduled to become unsupported in
>> a couple of years.
>
>That is correct. the KLs were new pretty new in April, 1976
>when First Data burned down. Everett and Swithers and others ported
>our local TOPS-10 to the KL in the fishbowl on the first floor of
>the Marlboro factory (MR01?).
Yup. I can still smell that. John reeked of smoke that Monday?
morning when I walked in.
> .. and I was drafted to operate it
>because all the real operators were cleaning up in Waltham.
>
>But by your five year rule,
What five year rule?
> .. the KLs should have been replaced by
>something faster, cooler, less power sucking, etc. by 1981,
That was the plan which got delayed and delayed and delayed.
>and again in 1986.
Now count the processors that did get shipped.
>
>So while I mispoke in saying that the Vaxen killed the KLs,
>what I should have said is that the evil Vaxen killed the
>replacements for the KL, and that killed the LCG lines.
No, LCG stupidity killed the PDP-10 line. Corporate had
no interest in manufacturing 10s anymore after the Jupiter
debacle. The steering committee nixed the PDP-10 design
submitted that reworked the KL onto a desktop footprint
in our last desparate attempt to fix the Jupiter mess.
>
>After years of working on Tops-20, I really didn't care much
>about the TOPS-10 OS, it was famous mostly because it was
>more efficient of hardware,
No, it was more efficient w.r.t. user thruput.
> .. the 20 was a lot more
>efficient of programmers.
Programmer interface as a user. Not processing.
> .TCO and all that.
>
>>> ..Warning ignored here. I loved the 10s and 20s, and hated
>>>the Vaxen.
>>
>> That's because you knew what a timesharing system was supposed
>> to do.
>
>It isn't clear to me, even in hindsight, that timesharing would
>have stayed important anyway.
Oh, dear.
> .Cheaper boxes made it hard
>to justify paying my company $100,000 per month for timesharing,
>even when it delivered a lot of real value to the customers.
>
>Some of it was just terminology. Now, all the buzzwords have n-tiered
>systems with smart terminals (browsers) talking to applications on
>webservers. We actually had most of this using Pro-350s talking
>to KLs in 1981 or 82. Just way ahead of the game.
Yep, TTYs.
>
>
>
>> It took an underground infiltration of PDP-10ers into
>> VMS land to get VMS to the point that it could do some
>> decent timesharing. Getting rid of three people helped
>> tremendously in this.
>
>Sadly too little too late.
What are you talking about? VMS is getting shipped. IF the
OS sucked so badly, nobody would have used it. VMS is
a good helpmate to users.
>
>>>I think I could have handled the hardware, but the OS ignored
>>>nearly everything that the LCG folks spent decades learning.
>>
>> Exactly. It went further than that. The chief VMS architect
>> wrote code to prevent any, and I mean any, PDP-10 computing
>> innovations to be implemented in VMS.
>
>So much for LCG's much pushed "integration"
>We all knew it was a scam.
Oh, fuck that very much. This wasn't LCG. This was marketing
trying to put a bandaid on the fact that there were no plans
about moving customers from the -10 to the VAX at the
design stage. Bell had absolutely no concept of what it
was like to be a user. Neither did Cutler. Both of these
men were used to being "right" 100% of the time. Cutler
was a brilliant bit coder. He had abolutely no capability
of empathizing from the user's point of view, let alone
two user's sharing the same resources. Bell had, and still
does, have a very narrow idea about computing services; there
were none. It was all electricity which had to obey a few
basic ohm laws. Anything else didn't matter and was to be
avoided because they were annoying.
>
>>>Which was shameful enough, but then they were rewarded
>>>into putting the same mistakes into the Windows descendants that
>>>we are cursed with using today.
>>
>> That happened because of a second software architect who kept
>> undermining the VMS development. There was a reason he
>> was removed physically and organizationally. Why do you
>> think NT cannot deal with thousands of users? The chief
>> architect never thought that thousands should be allowed
>> on a system at once, let alone give these users the
>> impression that they could access all the resources.
>
>Oh, I know for sure about David.
>What a blockhead. In the book "Showstopper" about
>the development of NT, there is a long section
>on trying to reduce the memory requirements of NT.
>Seems David didn't understand about swappable sections
>or the OS.
He shouldn't have. He was a small computer thinker.
One process only. That is why 11M is a single task
monitor. Device drivers are waste of core. EVent
driven OSes were a waste of CPU...setting around doing
nothing until some annoying peripheral caused an interrupt.
Note that this is not wrong if applied to systems that
had one thing to do. I think you people call this embedded
processors. Cutler would have brilliant at it as long
as nobody made him a manager.
>I know it was in Tops-20, and probably in
>parts of TOPS-10 and even Tenex.
>
>Those who refuse to learn from history are doomed
>to repeat it.
Yup. VMS is in the -10/20 state around 1985.
<snip>
/BAH