On 7 May 2010, at 08:25, cctalk-request at classiccmp.org wrote:
>
> Message: 2
> Date: Thu, 06 May 2010 16:06:37 -0700
> From: Al Kossow <aek at bitsavers.org>
> Subject: Re: Servant .953
> To: cctalk at classiccmp.org
> Message-ID: <4BE34B7D.6060902 at bitsavers.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 5/6/10 2:23 PM, Fred Cisin wrote:
>>> Al Kossow wrote:
>>>> I am interviewing Andy Hertzfeld tomorrow, and had hoped to talk about
>>>> Servant, but I can't find a copy of it around anywhere tonight.
>
> A huge thank you to Nigel Williams who forwarded a working copy of .951 five
> minutes before Bill and Andy arrived. We spent an hour talking about MacPaint
> and Quickdraw (Apple has finally given CHM approval to make the sources available)
> then another hour on Alice, Dali Clock, Servant, Hypercard, and Magic Cap.
Could you please clarify, the QuickDraw source is available for what purpose? Could developers modify it any include it in heir commercial 64 bit Intel applications for instance?
Is the source Pascal, Assembler, C or something else?
Roger Holmes,
Director of Microspot who has a Carbon application which compiles with over 10,000 warnings about deprecated QuickDraw calls.
Here's my top 3 weirdest devices I've ever sent email through, just for fun:
1. The AlphaSmart "Dana" which was a strange laptop-like device which ran
PalmOS. The email client was Eudora for PalmOS.
2. Sony eVilla BeIA appliance using some kind of (crappy) built-in mail
application.
3. Sharp Wizard handheld organizer over a serial TTY connected to a 386/SX
with optional math co-processor installed so it could run ... Xenix.
Logged in via simple built-in vt100 terminal app on the wizard at 2400
BPS to the Unix box. Used 'elm' to send the mail.
That Sharp Wizard was a helluva organizer for it's time. The main feature
was that it takes AAA batteries and thus I was actually able to afford to
run the thing in college by getting rechargables. It had a nice keyboard
and the display was readable in the sunlight, too. No backlight, though.
-Swift
> >
> > Hey, this is useful.
> > Thanks for doing it!
>
> Yep!
> Already investigating. IMD gave me some trouble, had to resort to
> dosbox. Source for PED (Programmer's Editor) version G? I've never
> seen source. I have version F as a :PROG file. I'm guessing that Planc
> version C may compile it.. this will stretch my emulator. Haven't yet
> figured out how to handle that PED2.DMK file, so I don't know what it
> contains - executable?
>
>
>
PED2.DMK and DISK8.IMD is the same disk, but different ways of reading it
off the disk. I used both the standard PC-floppy and then also the
catweasel card. I tried the catweasel for some floppies that I had reading
trouble with.
I am really interested in hearing more about your emulator!
/Mattis
OK, so we already had a dump of the M9301-YA ROMs, but were (apparently)
missing the others?
So I fnally got one of my UNIBUS 11's running, and whipped up a small program
to dump the ROM contents, and now have the -YB, -YF and -YH ROMs dumped. I'm
in the process of disassembling them now.
(If anyone needs the contents in binary format, to blow new ROMs, let me know,
and I can probably produce them if you give me the details on the format you
need the data in.)
Does anyone have any of the others - YC, YD, YE and YJ?
If you're not up to dumping them, I can send you my small program (currently
in .LDA format, but I can convert it to a script - it is not very long at all
- for the console emulator in the M9301 series), which will do it - it
produces packed octal output, 8 words/line, so a very small output.
Noel
A friend has a large set of paper tape which seems to be from a DG User
group (not sure about that, but label on box sort of implies that).
The tape pile is fanfold about 10" across in a DG box specially made for
such use.
We hope to have a reader to digitize it soon, but wonder if anyone knows
of such a program? We just have the labels which say that is what the
tape has to go on.
More photos and the like later. I know that more info would be helpful,
but figured I'd ask first.
thanks
Jim
> From: Diane Bruce
> PL/M wasn't bad either.
I forgot about PL/M...
> Telephone companies preferred deterministic behaviour from their code
> and operating systems.
Not just telco's. Many (most?) people doing stand-alone applications want
this, or something close to it.
> There are many warts in C I would remove if I had the power to. ;)
Eh, don't we all.
My favourite peeve: in cloning BCPL, they left out 'valof/resultis'. That
made certain kinds of macros really, really ugly...
> C is a high level PDP-11 assembler to this day. (auto increment and
> decrement)
This myth persists, but it's wrong. B (the typeless predecessor to C) on the
PDP-7 had them, before the PDP-11 existed, as DMR attests:
People often guess that they were created to use the auto-increment and
auto-decrement address modes provided by the DEC PDP-11 on which C and Unix
first became popular. This is historically impossible, since there was no
PDP-11 when B was developed.
The document that's excerted from:
http://www.bell-labs.com/usr/dmr/www/chist.html
might be of interest here, since it contains a section ("Whence Success?")
containing his take on why C was a success (e.g. "it evidently satisfied a
need for a system implementation language efficient enough to displace
assembly language, yet sufficiently abstract and fluent to describe
algorithms and interactions in a wide variety of environments").
Noel
Oh, another factor that led to success for C, I suspect: I/O is not in the
language, it's handled by optional subroutine libraries. This made it very
easy for compilers/etc to produce language for stand-alone systems. Compare
PL/I, which needed a large subroutine library to run on bare hardware.
> From: Paul Koning
> Algol 68 has both pointers and structures.
Yeah, but Algol-68 never did much (although it had a certain amount of
influence). Why, I'm not certain - I suspect the fact that it was fairly
complex had something to do with it, but I expect its biggest problem was
that a number of _very_ respectd people from its committee denounced it
roundly (whether their reasons were good or bad, I can't say).
Tony Hoare's Turing lecture, "The Emperor's Old Clothes", recounts a lot of
that. (That's the source of the famous quote about "there are two ways of
constructing a software design: One way is to make it so simple that there
are obviously no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." He was talking about Algol-68,
there.)
> So does Pascal.
Which didn't have a lot of the capabilities needed to be system language at
_that point in time_ (remember, this is about 'why did C succeed, back then');
it was, after all, originally designed as a pedagogical language.
> And Modula.
That was late 70's - C was already off and running by then.
> The main thing C has that most other languages don't is *unsafe* data
> typing - the ability to subvert the type system at the drop of a cast,
> and the programming tradition to do this a lot.
{Sighs.} You really seem to have it out for C. You'll never be able to
understand why it was so successful if you start out with the mindset that
it's total crap (even if that's not the way you thought you meant that
comment). That _is_ the implication of that "the main thing that C has"
comment - compared to things available _at the time_, like BCPL, etc, it _did_
have significant advantages.
Does it have issues? Sure. But the main reason it was so successful is that
compared to the other alternatives available _at the time_, it was, overall,
a better mouse-trap. (It wasn't just that it went with Unix - as DMR pointed
out, below, it succeeded in a lot of places that Unix didn't.)
> But it was cheap, available, and good enough to do useful work.
There's a lot of truth to that. Dennis Ritchie's HOPL presentation, "Five
Little Languages and How They Grew":
http://www.bell-labs.com/usr/dmr/www/hopl.html
has a section at the end about "how C succeeded in becoming so widely used",
and it's close to that. Some may consider your description a put-down; DMR I
expect would embrace it.
> I think the answer is simpler: Unix was adopted by a number of academic
> groups because it was available on easy terms
That certainly didn't hurt, but I don't think it was the biggest factor, by a
long way.
I think one of the biggest things is that early Unix (I'm thinking V6, V7)
was a system with an incredibly high bang/buck ratio - for the size, one got
a heck of a lot of functionality. This was important not just for _use_, for
for pedagogical reasons - to give students an example of a well-done system.
The fact that the hardware it ran on (PDP-11's) was modestly priced (for the
day) also helped a lot.
> and it was adopted by a very successful company (Sun)
Unix had taken off big-time before Sun even appeared.
Noel
nope it is working
In a message dated 4/27/2016 10:48:48 P.M. Mountain Standard Time,
dkelvey at hotmail.com writes:
Has the list gone down or just dropped me again?
> From: Erik Baigar
> I wanted to have a computer using core memory and so I bought a black
> box from the Tornado aircraft which contained core. This started a 10
> year yourney of analyzing it, decyphering the command set and building
> tools to program it. ... I have a project page on this:
> http://www.baigar.de/TornadoComputerUnit/index.html
I am absolutely, completely, blown away. This has got to be one of the most
amazing projects I have ever come across. I'm utterly awed by the work you
did to reverse engineer this thing.
Everyone should check out this site - especially the detailed time-line
Noel