"Since all of you steal your software..."
Jim Stewart
probably in the late 70's. As I recall, he accused computer hobbyists
of stealing his Basic interpreter and he threatened to stop writing
software for personal computer market. Does anyone have the full text
of the letter?
Joe Thompson
<jste...@jkmicro.com> wrote:
It's available on several web sites. An Alta Vista search should turn up
plenty.
If only he'd made good on his threat... -- Joe
--
Joe Thompson | http://kensey.home.mindspring.com/
$spam$@orion-com.com | O- He-Who-Grinds-the-Unworthy
Charlottesville, VA | "I'd like to take this time to formally
thank you for bringing back a lot of bad memories." -- ADB on ASR
Taki Kogoma
<$spam$-21129800...@user-37ka4oj.dialup.mindspring.com> to
alt.folklore.computers:
>In article <367F1C8E...@jkmicro.com>, Jim Stewart
><jste...@jkmicro.com> wrote:
>> A letter from Bill Gates was published in the old SCCS magazine,
>> probably in the late 70's. As I recall, he accused computer hobbyists
>> of stealing his Basic interpreter and he threatened to stop writing
>> software for personal computer market. Does anyone have the full text
>> of the letter?
>
>It's available on several web sites. An Alta Vista search should turn up
>plenty.
>
>If only he'd made good on his threat... -- Joe
What was the last program Gates actually sat down and ground out the
code for?
--
Capt. Gym Z. Quirk | "I'll get a life when someone
(Known to some as Taki Kogoma) | demonstrates that it would be
quirk @ swcp.com | superior to what I have now."
Veteran of the '91 sf-lovers re-org. | -- Gym Quirk
Eric Fischer
> What was the last program Gates actually sat down and ground out the
> code for?
In his interview in Susan Lammers's 1986 book _Programmers at Work_ he
says it was the ROM for the TRS-80 Model 100 laptop computer, cowritten
with Jey Suzuki.
eric
Eric Fischer
> A letter from Bill Gates was published in the old SCCS magazine,
> probably in the late 70's. As I recall, he accused computer hobbyists
> of stealing his Basic interpreter and he threatened to stop writing
> software for personal computer market. Does anyone have the full text
> of the letter?
An HTMLized copy of it was posted here a few months ago by
dles...@odyssee.net. Here it is again, minus the HTML tags:
| February 3, 1976
|
| An Open Letter to Hobbyists
|
| To me, the most critical thing in the hobby market right now is the
| lack of good software courses, books and software itself. Without good
| software and an owner who understands programming, a hobby computer is
| wasted. Will quality software be written for the hobby market?
|
| Almost a year ago, Paul Allen and myself, expecting the hobby market to
| expand, hired Monte Davidoff and developed Altair BASIC. Though the
| initial work took only two months, the three of us have spent most of
| the last year documenting, improving and adding features to BASIC. Now
| we have 4K, 8K, EXTENDED, ROM and DISK BASIC. The value of the computer
| time we have used exceeds $40,000.
|
| The feedback we have gotten from the hundreds of people who say they
| are using BASIC has all been positive. Two surprising things are
| apparent, however. 1) Most of these "users" never bought BASIC (less
| than 10% of all Altair owners have bought BASIC), and 2) The amount of
| royalties we have received from sales to hobbyists makes the time spent
| of Altair BASIC worth less than $2 an hour.
|
| Why is this? As the majority of hobbyists must be aware, most of you
| steal your software. Hardware must be paid for, but software is
| something to share. Who cares if the people who worked on it get paid?
|
| Is this fair? One thing you don't do by steeling software is get back
| at MITS for some problem you may have had. MITS doesn't make money
| selling software. The royalty paid to us, the manual, the tape and the
| overhead make it a break-even operation. One thing you do is prevent
| good software from being written. Who can afford to do professional
| work for nothing? What hobbyist can put 3-man years into programming,
| finding all bugs, documenting his product and distribute for free? The
| fact is, no one besides us has invested a lot of money in hobby
| software. We have written 6800 BASIC, and are writing 8080 APL and 6800
| APL, but there is very little incentive to make this software available
| to hobbyists. Most directly, the thing you do is theft.
|
| What about the guy who re-sell Altair BASIC, aren't they making money
| on hobby software? Yes, but those who have been reported to us may lose
| in the end. They are the ones who give hobbyists a bad name, and should
| be kicked out of any club meeting they show up at.
|
| I would appreciate letters from any one who wants to pay up, or has a
| suggestion or comment. Just write me at 1180 Alvarado SE, #114,
| Albuquerque, New Mexico, 87108. Nothing would please me more than being
| able to hire ten programmers and deluge the hobby market with good
| software.
|
| Bill Gates
| General Partner, Micro-soft
eric
Charles Richmond
From Charles Simonyi and the URAL II to Bob Frankston/Dan Bricklen and
VisiCalc, and onward, it was extremely interesting...and I believe it is still
in print. In the back there were some photocopies of some of the original
notes and papers of the programmers.
Anyway, as I remember the interview with Mr. Gates, he said that the last
program he worked on was the BASIC for the TRS-80 Color Computer. Maybe Eric
can double-check this--I have since given my well-worn copy of the Lammers'
book to a good friend.
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
William Hamblen
: Anyway, as I remember the interview with Mr. Gates, he said that the last
: program he worked on was the BASIC for the TRS-80 Color Computer.
And said BASIC has a well known bug in the floating point arithmetic, too.
Nick S Bensema
Eric Fischer <er...@fudge.uchicago.edu> wrote:
>In article <75lttd$p...@boofura.swcp.com>, Taki Kogoma <qu...@swcp.com> wrote:
>
>> What was the last program Gates actually sat down and ground out the
>> code for?
>
>In his interview in Susan Lammers's 1986 book _Programmers at Work_ he
>says it was the ROM for the TRS-80 Model 100 laptop computer, cowritten
>with Jey Suzuki.
Here's a fun exercise... ask those who have owned the Model 100 what
was really great about that old machine, and then tell them that Bill
Gates wrote the ROM in it.
I only have a vague idea what the machine is like; an LCD display
and most of the useful software one would need in the 80's was right
there in ROM, no waiting, no loading. There was at least a BASIC
interpreter, a word processor, and a terminal program. That's
pretty much all I've heard, and I've only seen one in person.
I'd really like to get my hands on one of those machines... they
seem like they'd be neat to lug around and take notes on, but I
have a feeling the going rate for a working model 100 is probably
more than that for a 386 laptop, which I could have just as much
fun with.
--
Nick Bensema <ni...@primenet.com> 98-KUPD Red Card #710563 UIN: 2135445
~~~~ ~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
</BLINK>
John Birch
Fischer) wrote:
>Jim Stewart <jste...@jkmicro.com> wrote:
>
>> A letter from Bill Gates was published in the old SCCS magazine,
>> probably in the late 70's. As I recall, he accused computer hobbyists
>> of stealing his Basic interpreter and he threatened to stop writing
>> software for personal computer market. Does anyone have the full text
>> of the letter?
>
Letter kindly reposted by Eric Fischer;
It's the first time I've read this, it's a fascinating insight into
the mindset of the man who started Microsoft. He really does want to
live the 'American dream' (and I guess he is!)
<SNIP>
>|
>| To me, the most critical thing in the hobby market right now is the
>| lack of good software courses, books and software itself. Without good
>| software and an owner who understands programming, a hobby computer is
>| wasted. Will quality software be written for the hobby market?
<The visionary didn't predict the free software movement then!>
<snip>
>| Who can afford to do professional
>| work for nothing? What hobbyist can put 3-man years into programming,
>| finding all bugs, documenting his product and distribute for free?
<Anybody who charges for support can - the software itself has no
intrinsic value - its the mind power that went into developing it and
the ongoing understanding of the software residing in the developers
head that is of value.
As many commercial organisations are all too well aware - the moment a
lead developer leaves them, they discover that they are unable to
continue developing the existing software they 'own'. For some
inexplicable <grin> reason, new brooms sweep clean, consequently there
is a period when the old software is frozen, pending the release of a
new version developed by whomever the company has persuaded to babysit
the old product. The very bottom line is; nobody likes maintaining
somebody elses code, but it's a point of honour to fix your own bugs
when somebody points them out to you!>
<SNIP>
>|
>| What about the guy who re-sell Altair BASIC, aren't they making money
>| on hobby software? Yes, but those who have been reported to us may lose
>| in the end. They are the ones who give hobbyists a bad name, and should
>| be kicked out of any club meeting they show up at.
>|
<About the only thing I do agree with in this letter - piracy should
be banned>
>| I would appreciate letters from any one who wants to pay up, or has a
>| suggestion or comment. Just write me at 1180 Alvarado SE, #114,
>| Albuquerque, New Mexico, 87108. Nothing would please me more than being
>| able to hire ten programmers and deluge the hobby market with good
>| software.
<And charge them for it !!!!>
<SNIP>
I've only just really started looking at the free software movement -
having been tickled by the recent press coverage into action. But it
seems to me that there are massive spin-off benefits to being open in
any approach to software development.
As I see it;
You focus on supporting the users rather than devloping a more
marketable product,
You focus on improving and developing the product in line with the
users requirements rather than what the marketing department perceives
as what is required,
You focus on providing good support in terms of documentation, user
guides, hints and tips, tutorials, custom components, etc (Since these
are what you charge for!).
Basically it would seem to me that you are in a positive cycle rather
than a negative one! I.e. Rather than trying to convince customers
that your product is good, you show them (for free) that it is not bad
(and worth investing in learning about!).
regards John B.
Eric Fischer
> I read the Lammers' book [Programmers at Work] *several* times, and I
> really enjoyed it each time!!! From Charles Simonyi and the URAL II
> to Bob Frankston/Dan Bricklen and VisiCalc, and onward, it was
> extremely interesting...and I believe it is still in print.
I'm not sure if it's still in actual print, but you can get it on a CD
in HTML format, according to an ad in the latest issue of Unix Review.
It's $25 from Dr. Dobb's Journal,
and includes other interviews with programmers that weren't in the
original book, including the "Halcyon Days" video game interviews,
which I also highly recommend.
> Anyway, as I remember the interview with Mr. Gates, he said that the
> last program he worked on was the BASIC for the TRS-80 Color
> Computer. Maybe Eric can double-check this--I have since given my
> well-worn copy of the Lammers' book to a good friend.
I don't have my copy here with me to verify, but I'm sure it was the
Model 100 because I posted a quote from the book in this newsgroup,
back in June of 1996:
"I still help design algorithms and basic approaches, and
sometimes I look at code. But since I worked on the IBM
PC BASIC and the Model 100, I haven't had a chance to
actually create a program myself." (p. 72)
There must have been a reference to the Color Computer too, though,
because I remember there being an obvious typo where the book referred
to a 6800 instead of a 6809. I'll check for the details when I get
home tonight.
eric
Carl R. Friend
Nick S Bensema wrote in message <75ngp8$d2s$1...@nnrp02.primenet.com>...
>
>Here's a fun exercise... ask those who have owned the Model 100 what
>was really great about that old machine, and then tell them that Bill
>Gates wrote the ROM in it.
Usually you don't need to tell them. When the machine first comes
up it "proudly" displays the Microsoft copyright message. Even with-
out that message you can tell it's Mickeysoft Inside -- if you really
push the machine hard it runs slower and slower as the garbage collect
logic gets whacked. Eventually you have to push the reset button on
the back beacuse it can take several seconds to recognise a keystroke.
>I only have a vague idea what the machine is like; an LCD display
>and most of the useful software one would need in the 80's was right
>there in ROM, no waiting, no loading. There was at least a BASIC
>interpreter, a word processor, and a terminal program. That's
>pretty much all I've heard, and I've only seen one in person.
That pretty much sums it up. I still use mine as my "road box"
which travels with me. The 300 bps modem is enough for Email and
is faster than the screen can scroll anyway. Hooked up that way to
a UNIX box I can even surf the Web using Lynx. The nicest part? No
moving parts!
--
______________________________________________________________________
| | |
| Carl Richard Friend (UNIX Sysadmin) | West Boylston |
| Minicomputer Collector / Enthusiast | Massachusetts, USA |
| mailto:carl....@stoneweb.com | |
| http://www.ultranet.com/~engelbrt/carl/museum/ | ICBM: N42:21 W71:46 |
|________________________________________________|_____________________|
Alexandre Pechtchanski
>On Mon, 21 Dec 1998 17:24:15 GMT, er...@fudge.uchicago.edu (Eric
>Fischer) wrote:
>
>Letter [from Bill Gates to hobbyists] kindly reposted by Eric Fischer;
>
>It's the first time I've read this, it's a fascinating insight into
>the mindset of the man who started Microsoft. He really does want to
>live the 'American dream' (and I guess he is!)
[ snip ]
>... it's a point of honour to fix your own bugs
>when somebody points them out to you!>
Unless your name is Bill Gates or you work for Microsoft. Then you either
proclaim "It is not a bug, it is a feature!" (even if it breaks everything
_hard_, like infamous "EMM386 stopped your computer to save your work") or agree
that it _is_ a bug, but declare that you are not going to do anything about it
(FPW on fast computers and many others).
[ When replying, remove *'s from address ]
Alexandre Pechtchanski, Systems Manager, RUH, NY
fs...@mindless.com
> Charles Richmond <rich...@plano.net> wrote:
>
> > I read the Lammers' book [Programmers at Work] *several* times, and I
> > really enjoyed it each time!!! From Charles Simonyi and the URAL II
> > to Bob Frankston/Dan Bricklen and VisiCalc, and onward, it was
> > extremely interesting...and I believe it is still in print.
>
> I'm not sure if it's still in actual print, but you can get it on a CD
> in HTML format, according to an ad in the latest issue of Unix Review.
> It's $25 from Dr. Dobb's Journal,
>
> http://www.ddj.com/cdrom/
After checking around last night, I can verify that both the original
1986 and the revised 1989 versions are both out-of-print. Thanks for
the CD-ROM URL, Eric!
--
Mark C. Langston
Ph'nglui mglw'nafh Cthulhu R'lyeh wagn'nagl fhtagn.
Cthulhu for President in 2000: Why choose the lesser evil?
Nick S Bensema
Carl R. Friend <carl....@stoneweb.com> wrote:
>
>Nick S Bensema wrote in message <75ngp8$d2s$1...@nnrp02.primenet.com>...
>>
>>Here's a fun exercise... ask those who have owned the Model 100 what
>>was really great about that old machine, and then tell them that Bill
>>Gates wrote the ROM in it.
>
> Usually you don't need to tell them. When the machine first comes
>up it "proudly" displays the Microsoft copyright message. Even with-
>out that message you can tell it's Mickeysoft Inside -- if you really
>push the machine hard it runs slower and slower as the garbage collect
>logic gets whacked. Eventually you have to push the reset button on
>the back beacuse it can take several seconds to recognise a keystroke.
Yipes.... that's so Timex-Sinclairesque. But I'm not surprised at
the Microsoft copyright message; just about every personal computer
on the face of the Earth after a certain date has a Microsoft
copyright message somewhere in the manuals or the ROM itself; even
the Commodore 128 bears Microsoft's name right in the 128-mode boot
screen. I think Microsoft's claim on most early computers is a
covert collaboration in the BASIC interpreter. AmigaBASIC was
probably MS's; it was QBASIC-like enough. I'm also tempted to say
that C64's and Apple's was too, but I'm not ready to take that
kind of leap, especially since I found out there's no such thing
as a 6-gig Jaz drive. What the hell was I thinking?
deke.sp...@generous.net
>What was the last program Gates actually sat down and ground out the
>code for?
worldDomination.bas
------------------------
Let love find you! http://generous.net
A list for flirting generousSing...@onelist.com
Over The Hill Gang generousSingle...@onelist.com
College and younger generousTee...@onelist.com
Lots of Personal Ads generousProfi...@onelist.com
If it's not 'just the way you are', it's not love....
Peter Seebach
Nick S Bensema <ni...@primenet.com> wrote:
>covert collaboration in the BASIC interpreter. AmigaBASIC was
>probably MS's; it was QBASIC-like enough.
It certainly was. Despite clear and unambiguous statements from Apple,
Motorola, and Commodore, AmigaBASIC only works if the top byte of every
pointer is irrelevant. (True on the 68000.)
-s
--
Copyright 1998, All rights reserved. Peter Seebach / se...@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Send me money - get cool programs and hardware! No commuting, please.
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
Eric Fischer
> AmigaBASIC was probably MS's; it was QBASIC-like enough.
Yes, it was a Microsoft BASIC, and in typical Microsoft fashion it used
the top bits of pointers for other data and broke when those bits
started to correspond to real address space.
> I'm also tempted to say that C64's and Apple's was too, but I'm not
> ready to take that kind of leap
The C64 BASIC was from Microsoft. The original Apple Integer BASIC
wasn't -- it was written by Steve Wozniak -- but Applesoft (floating
point) BASIC was another Microsoft product. The standard BASIC for
the Atari 400 and 800 wasn't from Microsoft, but a Microsoft version
was available as an option. Texas Instruments, though, somehow managed
to avoid having any Microsoft BASIC available for its TI-99/4A.
eric
Brendan Hahn
>probably MS's; it was QBASIC-like enough. I'm also tempted to say
>that C64's and Apple's was too, but I'm not ready to take that
Applesoft BASIC was by MS, at least partly, but the original Integer BASIC
wasn't. Can't remember for the C64.
bh...@transoft.mangle.net <-- unmangle to reply
D. Peschel
Nick S Bensema <ni...@primenet.com> wrote:
> I think Microsoft's claim on most early computers is a
>covert collaboration in the BASIC interpreter.
For a long time, BASIC was a big part of their business. There was a thread
here a while ago about MS' use of a PDP-10 (and some really evil assembler
macros) to compile their versions of BASIC.
> AmigaBASIC was
>probably MS's; it was QBASIC-like enough. I'm also tempted to say
>that C64's and Apple's was too,
AmigaBASIC: yes, and MS disobeyed Commodore's admonition not to turn a
24-bit address into a 24-bit address plus 8 bits of data (because addresses
would eventually become 32 bits). When addresses DID become 32 bits, most
people didn't lament the demise of AmigaBASIC.
C-64: I almost sure it wasn't. Commodore had been writing their BASICs for
some time.
Apple: There were two dialects. Integer BASIC (written and hand-assembled
by Steve Wozniak) is fast and simple, has some nice features, and has only
one minor bug I know of. (There's a *** TOO MANY PARENS ERR message, but
using too many parentheses gives you another error, so the correct one never
shows up. This can be fixed by changing one byte.) AppleSoft (written and
copyrighted by MS, patched by Apple to handle lower-case) is slow and
complicated, has floating-point and strings but lacks some of the
convenience of Integer BASIC, and has many bugs and anomalies.
-- Derek
Ron Hunsinger
dpes...@u.washington.edu (D. Peschel) wrote:
> AppleSoft (written and
> copyrighted by MS, patched by Apple to handle lower-case) is slow and
> complicated, has floating-point and strings but lacks some of the
> convenience of Integer BASIC, and has many bugs and anomalies.
One of my favorites is the following:
100 FOR X = 1 TO 10000
110 IF 1/X <> 1/X THEN PRINT X
120 NEXT X
It's hard to imagine how 1/X could ever NOT be equal to itself, yet this
program will print out a distressingly large number of values of X for
which it isn't.
I came across this one from the inside out. I was disassembling the ROM,
and while reading the code to evaluate expressions I found some that made
me splutter "But... but... if they do it that way, then...". I wrote the
above test program, and sure enough they did.
-Ron Hunsinger
Joe Thompson
hns...@sirius.com (Ron Hunsinger) wrote:
> One of my favorites is the following:
>
> 100 FOR X = 1 TO 10000
> 110 IF 1/X <> 1/X THEN PRINT X
> 120 NEXT X
>
> It's hard to imagine how 1/X could ever NOT be equal to itself, yet this
> program will print out a distressingly large number of values of X for
> which it isn't.
>
> I came across this one from the inside out. I was disassembling the ROM,
> and while reading the code to evaluate expressions I found some that made
> me splutter "But... but... if they do it that way, then...". I wrote the
> above test program, and sure enough they did.
What did they do, something like "If 1/A x B != 1, then return true"? For
a <> operation to ever fail, you'd have to to either give it an invalid
value in the first place, or it would have to treat its arguments
differently, or be really *obviously* broken. -- Joe
Charlie Gibbs
(Nick S Bensema) writes:
> I think Microsoft's claim on most early computers is a
>covert collaboration in the BASIC interpreter. AmigaBASIC was
>probably MS's; it was QBASIC-like enough.
Indeed, AmigaBASIC was the one piece of M$ software that
was inflicted upon the Amiga. I eventually stopped using it
simply because it was so obnoxious. Then along came the 68020
accelerators, and AmigaBASIC promptly died - because Microsoft,
in their usual fashion, had ignored the widely-publicized
programming guidelines and produced something that was not
portable from the 68000 to higher processors. Commodore
replaced AmigaBASIC with ARexx in version 2.0 of AmigaOS,
and since then the Amiga has been a Microsoft-free zone.
--
cgi...@sky.bus.com (Charlie Gibbs)
Remove the first period after the "at" sign to reply.
Joe Thompson
Seebach) wrote:
> (1/x) != (1/x)
>
> happens as
> put 1 and x in FP registers
> do operation to higher precision intermediate representation
> store result, truncating
> do operation to higher precision intermediate representation
> pull stored result and compare
>
> Not always, but enough to make it useless.
You'd think it would be a standard to ensure that if two equal expressions
are compared, they are found equal. i.e., in your case, the untruncated
result should not be compared to the truncated one. And really the
truncated one should not be stored at a lower precision in the first place
I'd think. -- Joe
William Hamblen
: <The visionary didn't predict the free software movement then!>
The free software movement already existed at the time. Software flowed
across the ARPANET. User groups like DECUS flourished and where imitated
by hobbyists. Dr Dobbs Journal of Computer Calisthenics and Orthodontia
(Running Light Without Over Byte) started as a way to distribute free Tiny
BASIC. Hobbyist magazines were full of type-in-yourself listings.
Peter Seebach
Joe Thompson <$spam$@orion-com.com> wrote:
>What did they do, something like "If 1/A x B != 1, then return true"? For
>a <> operation to ever fail, you'd have to to either give it an invalid
>value in the first place, or it would have to treat its arguments
>differently, or be really *obviously* broken. -- Joe
Well, on modern hardware, it's a common problem for C programs;
(1/x) != (1/x)
happens as
put 1 and x in FP registers
do operation to higher precision intermediate representation
store result, truncating
do operation to higher precision intermediate representation
pull stored result and compare
Not always, but enough to make it useless.
-s
Richard Lamb
somewhere, but can't find an assembler that won't choke on it...
Anybody got a source that WILL assemble?
Wanted for 8088 progect....
Richard Lamb
Gene Wirchenko
>In article <hnsngr-ya0231800...@news.sirius.com>,
>hns...@sirius.com (Ron Hunsinger) wrote:
>
>> One of my favorites is the following:
>>
>> 100 FOR X = 1 TO 10000
>> 110 IF 1/X <> 1/X THEN PRINT X
>> 120 NEXT X
>>
>> It's hard to imagine how 1/X could ever NOT be equal to itself, yet this
>> program will print out a distressingly large number of values of X for
>> which it isn't.
Comparing floating point values for exact equality or exact
inequality is poor programming practice. See Peter Seebach's post as
well.
[snip]
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Peter Seebach
Joe Thompson <$spam$@orion-com.com> wrote:
>In article <muWf2.629$fM1....@ptah.visi.com>, se...@plethora.net (Peter
>Seebach) wrote:
>>
>> happens as
>> put 1 and x in FP registers
>> do operation to higher precision intermediate representation
>> store result, truncating
>> do operation to higher precision intermediate representation
>> pull stored result and compare
>>
>> Not always, but enough to make it useless.
>You'd think it would be a standard to ensure that if two equal expressions
>are compared, they are found equal.
Yes, but so many people don't want that if it slows their code down...
>i.e., in your case, the untruncated
>result should not be compared to the truncated one. And really the
>truncated one should not be stored at a lower precision in the first place
>I'd think. -- Joe
The problem isn't the lower precision, because that's the "real" precision.
The problem is that some FPU's are *FASTER* with more bits, because that's
the "most natural" format; so, compilers like to do everything in a more
exact intermediate form.
There's various workarounds, and you can almost always get what you want,
but it's occasionally surprising.
The moral of the story? No one who doesn't believe that the IEEE spec
makes sense should be comparing floats for equality.
Charles Richmond
>
>
> [snip...] [snip...] [snip...]
>
> I'd really like to get my hands on one of those machines... they
> seem like they'd be neat to lug around and take notes on, but I
> have a feeling the going rate for a working model 100 is probably
> more than that for a 386 laptop, which I could have just as much
> fun with.
>
surprised at what price you can have one for your very own. I believe it can
be had for less that $100 US. I do *not* know what the going rate is for 386
laptops, though . . .
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> the Microsoft copyright message; just about every personal computer
> on the face of the Earth after a certain date has a Microsoft
> copyright message somewhere in the manuals or the ROM itself; even
> the Commodore 128 bears Microsoft's name right in the 128-mode boot
> screen.
>
family that bought out Atari and came out the the Atari ST line of 68000
computers. Consequently, M-suck did *not* produce a single piece of software
for the Atari ST...no BASIC, no word processor, no spreadsheet, no nothing!!!
Gee, how fortunate for the Atari ST users!!!
>
> I think Microsoft's claim on most early computers is a
> covert collaboration in the BASIC interpreter. AmigaBASIC was
> as a 6-gig Jaz drive. What the hell was I thinking?
>
out, it will be able to read the original 1-gig Jaz disks also. ;-)
J. Benz
Gene Wirchenko wrote:
> $spam$@orion-com.com (Joe Thompson) wrote:
>
> >In article <hnsngr-ya0231800...@news.sirius.com>,
> >hns...@sirius.com (Ron Hunsinger) wrote:
> >
> >> One of my favorites is the following:
> >>
> >> 100 FOR X = 1 TO 10000
> >> 110 IF 1/X <> 1/X THEN PRINT X
> >> 120 NEXT X
> >>
> >> It's hard to imagine how 1/X could ever NOT be equal to itself, yet this
> >> program will print out a distressingly large number of values of X for
> >> which it isn't.
>
> Comparing floating point values for exact equality or exact
> inequality is poor programming practice. See Peter Seebach's post as
> well.
I've seen that post, and I'm familiar with the reasons why you don't compare FP
for equality - but I am also amazed that this particular instance does not
compare equally. Floating point error *should* be deterministic even when it
gives you the wrong answer - in other words, the *same* error should be made
twice here, resulting in equally wrong values. One would not expect the
machine to insert some random factor into a simple divide, or to evaluate these
two 1/X's through different code paths. It might be instructive if Mr.
Hunsinger could post what the two values of 1/X actually evaluate to when
they're NOT equal. Poor programming practice or not, it's still pretty
amazing.
J. Benz
Peter Seebach wrote:
> In article <$spam$-22129821...@user-37ka4jk.dialup.mindspring.com>,
> Joe Thompson <$spam$@orion-com.com> wrote:
> >In article <muWf2.629$fM1....@ptah.visi.com>, se...@plethora.net (Peter
> >Seebach) wrote:
> >> (1/x) != (1/x)
> >>
> >>
Ohh, *that* post from Peter Seebach....
TheCentralSc...@pobox.com
>
>One of my favorites is the following:
>
> 100 FOR X = 1 TO 10000
> 110 IF 1/X <> 1/X THEN PRINT X
> 120 NEXT X
My favorite when visiting a radio shack store was:
10 for x=1 to 32000
20 poke x,0
30 next x
jumping jack crash!
Gene Wirchenko
You left out that you selectively snipped bits of the post and
thus almost totally misstated Peter's view. Not nice.
Gene Wirchenko
>Gene Wirchenko wrote:
>
>> $spam$@orion-com.com (Joe Thompson) wrote:
>>
>> >In article <hnsngr-ya0231800...@news.sirius.com>,
>> >hns...@sirius.com (Ron Hunsinger) wrote:
>> >
>> >> One of my favorites is the following:
>> >>
>> >> 100 FOR X = 1 TO 10000
>> >> 110 IF 1/X <> 1/X THEN PRINT X
>> >> 120 NEXT X
>> >>
>> >> It's hard to imagine how 1/X could ever NOT be equal to itself, yet this
>> >> program will print out a distressingly large number of values of X for
>> >> which it isn't.
>>
>> Comparing floating point values for exact equality or exact
>> inequality is poor programming practice. See Peter Seebach's post as
>> well.
>
>I've seen that post, and I'm familiar with the reasons why you don't compare FP
>for equality - but I am also amazed that this particular instance does not
>compare equally. Floating point error *should* be deterministic even when it
>gives you the wrong answer - in other words, the *same* error should be made
>twice here, resulting in equally wrong values. One would not expect the
"*should*"? Why? If you want code optimized for speed and you
are not using the precision fully, the compare being off by a bit is
fine.
Peter Seebach has already posted why it can happen the way it
does.
>machine to insert some random factor into a simple divide, or to evaluate these
>two 1/X's through different code paths. It might be instructive if Mr.
>Hunsinger could post what the two values of 1/X actually evaluate to when
>they're NOT equal. Poor programming practice or not, it's still pretty
>amazing.
Comparing for exact equality is a well-known gotcha of floating
point. You've got to learn the rules before you play.
Sam Yorko
>
> Yes, I guess there is *no* 6-gig Jaz drive . . . yet!!! But when it does come
> out, it will be able to read the original 1-gig Jaz disks also. ;-)
>
Ralph Wade Phillips
D. Peschel wrote in message <75p27m$10u0$1...@nntp1.u.washington.edu>...
(stuff about other Microsoft BASICs deleted)
>
>C-64: I almost sure it wasn't. Commodore had been writing their BASICs
for
>some time.
>
Erm - No, Microsoft was writting BASIC for the Commodore since LONG
before the C64. Matter of fact, the original PETBasic was Microsoft 4K
BASIC, with Commodore specific extensions (think AppleSOFT for a better
known version of suchlike.)
>Apple: There were two dialects. Integer BASIC (written and hand-assembled
>by Steve Wozniak) is fast and simple, has some nice features, and has only
>one minor bug I know of. (There's a *** TOO MANY PARENS ERR message, but
>using too many parentheses gives you another error, so the correct one
never
>shows up. This can be fixed by changing one byte.) AppleSoft (written and
>copyrighted by MS, patched by Apple to handle lower-case) is slow and
>complicated, has floating-point and strings but lacks some of the
>convenience of Integer BASIC, and has many bugs and anomalies.
Apple didn't patch BASIC to handle lower case - they patched their
keyboard routine! BASIC, for some wonky reason, even on the earliest
Apple ][+ machines, would properly handle mixed case commands (by parsing
them to upper case before tokenizing, I think), but the stock Apple ][+
keyboard handler wouldn't.
RwP
D. Peschel
Ralph Wade Phillips <ral...@techie.com> wrote:
>>C-64: I almost sure it wasn't. Commodore had been writing their BASICs
>for
>>some time.
> Erm - No, Microsoft was writting BASIC for the Commodore since LONG
>before the C64. Matter of fact, the original PETBasic was Microsoft 4K
>BASIC, with Commodore specific extensions (think AppleSOFT for a better
>known version of suchlike.)
Well, I stand corrected. I thought Commodore displayed their version
numbers conspicuously, though? And Commodore FAQ's talk about the
differences between BASIC 2.0, 4.0, 7.0, etc. Did Commodore hire Microsoft
and then call it Commodore's work?
> Apple didn't patch BASIC to handle lower case - they patched their
>keyboard routine! BASIC, for some wonky reason, even on the earliest
>Apple ][+ machines, would properly handle mixed case commands (by parsing
>them to upper case before tokenizing, I think), but the stock Apple ][+
>keyboard handler wouldn't.
So how come DOS refused to handle lower-case commands even after the key-
board routine had been patched?
-- Derek
Eric Fischer
> Apple didn't patch BASIC to handle lower case - they patched their
> keyboard routine! BASIC, for some wonky reason, even on the earliest
> Apple ][+ machines, would properly handle mixed case commands (by parsing
> them to upper case before tokenizing, I think), but the stock Apple ][+
> keyboard handler wouldn't.
Maybe the BASIC in the II plus could handle lowercase, but the
(pre-Enhanced) IIe couldn't. The 80 Column Card firmware had
a nice trick, though, where you could get it to automatically
convert everything you typed to uppercase except for things in
quotes, which stayed lowercase. I think the sequence to trigger
this was ESC-E, but my memory may be developing errors, since
the last time I did any substantial programming on an unenhanced
IIe was around 1988.
eric
David Wragg
> [letter by Bill Gates]
> | February 3, 1976
> |
> | An Open Letter to Hobbyists
> |
> | [snip]
> | We have written 6800 BASIC, and are writing 8080 APL and 6800
> | APL, but there is very little incentive to make this software available
> | to hobbyists. Most directly, the thing you do is theft.
> | [snip]
I have never heard of an MS APL. Did they ever get around to releasing
it, or was it just hyperbole on Bill's part?
(And if they did release it, could someone mail me a copy ;-)
Dave Wragg
John Bean
Peschel) wrote:
>Well, I stand corrected. I thought Commodore displayed their version
>numbers conspicuously, though? And Commodore FAQ's talk about the
>differences between BASIC 2.0, 4.0, 7.0, etc. Did Commodore hire Microsoft
>and then call it Commodore's work?
Hence the "Microsoft Joke" in the PET's ROM...
WAIT 6502,100 was the normal invocation IIRC (its been a long
time!)
--
Regards
John Bean
Ron Hunsinger
$spam$@orion-com.com (Joe Thompson) wrote:
> In article <muWf2.629$fM1....@ptah.visi.com>, se...@plethora.net (Peter
> Seebach) wrote:
>
> > (1/x) != (1/x)
> >
> > happens as
> > put 1 and x in FP registers
> > do operation to higher precision intermediate representation
> > store result, truncating
> > do operation to higher precision intermediate representation
> > pull stored result and compare
> >
> > Not always, but enough to make it useless.
That's exactly what they did. The Applesoft interpreter simulates a
floating point accumulator (the 6502 doesn't have a real one) that has a
little bit more precision than their standard floating point format.
Since the accumulator can hold only one value at a time, intermediate
values have to be pushed onto a stack. They round to the shorter "standard"
precision before pushing. All binary operations work on two operands, the
left operand being popped from the stack, and the right operand being
already in tha accumulator.
So the sequence is almost exactly as you said (the principal difference
being that there's only one (pseudo)register):
put 1 into the accumulator (expanding it to 1.0)
push it onto the stack
put X into the accumulator
divide [TOS divided by AC -> AC], producing a high-precision quotient
push the result onto the stack (rounding)
put 1 into the accumulator (expanding it to 1.0)
push it onto the stack
put X into the accumulator
divide [TOS divided by AC -> AC], producing a high-precision quotient
compare [TOS vs AC] for inequality, putting boolean result in AC
The problem is that, when you get to the compare, the two operands have
different precisions.
> You'd think it would be a standard to ensure that if two equal expressions
> are compared, they are found equal. i.e., in your case, the untruncated
> result should not be compared to the truncated one. And really the
> truncated one should not be stored at a lower precision in the first place
> I'd think. -- Joe
You're right that two identical expressions should always compare equal.
Because of rounding, it's dangerous to expect normal algebraic rules, such
as the associative and distributive laws, to apply to computer arithmetic.
That's the reason that it's usually not a good idea to compare floating
point values for equality.
But that doesn't apply here. However floating point is implemented, it
should be completely deterministic. The same expression evaluated twice
should produce the same value both times. And a value should compare equal
to itself (except when it's explicitly defined not to, as with NaNs in IEEE
arithmetic).
The error, in this case, was that both operands of the compare should have
been rounded to the same precision before doing the compare. (The extra
information in the accumulator wasn't so much a longer mantissa as a guard
digit, intended to provide proper rounding, and protect against loss of
precision in a renormalization operation if the lead digit of the mantissa
cancelled in a subtraction. Being a guard digit, it shouldn't have been
retained between operations. It's there to enable proper rounding - it
should have been used for rounding, not comparing.)
It's a common mistake in floating point subroutines. Implementors often
fall prey to the temptation to retain extra precision as long as possible,
in the false belief that this makes the arithmetic more accurate (and in
some cases faster). Actually, what it does is make the arithmetic less
predictable. As a defense, progrommers are required to add extra code to
compensate, so that programs using the supposedly faster arithmetic wind up
actually being slower.
But the floating point routines in AppleSoft were written by Randy
Wiggington, who was still in high school at the time. He didn't have the
background to warn him off from this pitfall. He's in good company - lots
of others have made this mistake - but it's still a mistake.
-Ron Hunsinger
Ron Hunsinger
> Comparing floating point values for exact equality or exact
> inequality is poor programming practice. See Peter Seebach's post as
> well.
There's nothing wrong with comparing floating point values.
The only error is expecting common arithmetic equivalancies to apply to
floating point arithmetic. In particular, the associative law does not
hold, the distributive law does not hold, the reciprocal of a reciprocal is
not always the original number, the square root of a square is not always
the absolute value.
Most of these laws almost hold. The discrepancy is always there, but
usually isn't noticed until you get to a compare. And at that point, the
compare winds up getting blamed, when actually the error is elsewhere.
For example, the loop:
for (double x = 0.0; x != 1.0; x += 0.1) { /* ... */ )
is liable to be infinite. The mistake isn't in the compare x != 0.0, as so
many writers will claim. The mistake is assuming that 10*(1/10) == 1, as it
would be is multiplication were associative.
-Ron Hunsinger
William Hamblen
: I have never heard of an MS APL. Did they ever get around to releasing
: it, or was it just hyperbole on Bill's part?
I don't remember ever seeing it myself. How much APL can you shoehorn
into (at most) 64K?
Gene Wirchenko
>In article <36804d31...@news.vip.net>, ge...@vip.net wrote:
>
>> Comparing floating point values for exact equality or exact
>> inequality is poor programming practice. See Peter Seebach's post as
>> well.
>
>There's nothing wrong with comparing floating point values.
Provided you aren't comparing for exact equality.
>The only error is expecting common arithmetic equivalancies to apply to
>floating point arithmetic. In particular, the associative law does not
>hold, the distributive law does not hold, the reciprocal of a reciprocal is
>not always the original number, the square root of a square is not always
>the absolute value.
>
>Most of these laws almost hold. The discrepancy is always there, but
>usually isn't noticed until you get to a compare. And at that point, the
>compare winds up getting blamed, when actually the error is elsewhere.
>
>For example, the loop:
>
> for (double x = 0.0; x != 1.0; x += 0.1) { /* ... */ )
>
>is liable to be infinite. The mistake isn't in the compare x != 0.0, as so
>many writers will claim. The mistake is assuming that 10*(1/10) == 1, as it
>would be is multiplication were associative.
I would say it is. The mistaken assumption is being made BOTH in
the addition and the compare. I suggest that the compare include a
delta, say
abs(x-1.0)<0.01
I grant that this is ugly, but if you were doing it much you could (in
C) code a macro to pretty it up and invoke like
fcomp(x,1.0,.01)
My C isn't that good. Would that macro be
#define fcomp(f1,f2,delta) abs((f1)-(f2))<(delta)
Thierry Schembri
>Well, that is *mostly* accurate...Microsoft got hacked off at the Tramiel
>family that bought out Atari and came out the the Atari ST line of 68000
>computers. Consequently, M-suck did *not* produce a single piece of
software
>for the Atari ST...no BASIC, no word processor, no spreadsheet, no
nothing!!!
>Gee, how fortunate for the Atari ST users!!!
Actually, it's not exact, Microsoft worked for a while on an Atari ST
version of the WORD word processing. It was a limited version known under
the name 'Write'. I don't know if it was marketed or not.
Jeff Epler
>is liable to be infinite. The mistake isn't in the compare x != 0.0, as so
>many writers will claim. The mistake is assuming that 10*(1/10) == 1, as it
>would be is multiplication were associative.
Heck, you're assuming that
(1/10)+(1/10)+(1/10)+(1/10)+(1/10)+(1/10)+(1/10)+(1/10)+(1/10)+(1/10)
== 10*(1/10)
== 1
all of which are questionable.
Jeff
Paul Guertin
wrote:
[Bugs in Applesoft]
>
> One of my favorites is the following:
>
> 100 FOR X = 1 TO 10000
> 110 IF 1/X <> 1/X THEN PRINT X
> 120 NEXT X
>
> It's hard to imagine how 1/X could ever NOT be equal to itself, yet this
> program will print out a distressingly large number of values of X for
> which it isn't.
Indeed.
]LIST
100 FOR X = 1 TO 10000
110 IF 1 / X < > 1 / X THEN PRINT
X
120 NEXT X
]RUN
603
683
1206
1366
2049
2412
2732
3091
4055
4097
4098
4765
4824
5464
6147
6182
7361
8110
8194
8196
9273
9530
9648
]
For the audience: can you guess from that list what the bug is
without looking at the Applesoft code?
One of my favorite Applesoft quirks is the way PRINT allows
floating-point numbers to have more than one decimal point.
This allows one to do arithmetic on software revision numbers.
]PRINT 6.2.2 * 5.1
6.21.02
Paul Guertin
p...@sff.net
Jeffrey S. Dutky
The real questionable part is the assumption that float(1) divided
by float(10) is equal to 0.1, which is only true in the right repre-
sentation. If we are dealing with binary floating point numbers then
1/10 actaully equals something like .9999997, depending on the width
of the mantissa. In this circumstance, no matter how you formulate
the sum, the rules of arithmetic won't hold.
This is the same problem you have with the sum 1/3+1/3+1/3 when you
do it by hand and require that all decimals be terminating and only
have N digits in their representation.
The problem is not that the rules of arithmetic don't apply, but
that they only apply selectively! For certain values of M and N,
the sum from 1 to M of (1/N) == M*(1/N) == 1 exactly, for others
it doesn't.
- Jeff Dutky
John Savard
>In article <75lttd$p...@boofura.swcp.com>, Taki Kogoma <qu...@swcp.com> wrote:
>> What was the last program Gates actually sat down and ground out the
>> code for?
>In his interview in Susan Lammers's 1986 book _Programmers at Work_ he
>says it was the ROM for the TRS-80 Model 100 laptop computer, cowritten
>with Jey Suzuki.
a) Hey, I own one of those! (I bought it for $15 at a thrift shop, not
long ago, and thought I got a really good deal...)
b) One of these days, somebody will get the idea of making a $29.95
pocket organizer that is as useful as that was...
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
John Savard
>I have never heard of an MS APL. Did they ever get around to releasing
>it, or was it just hyperbole on Bill's part?
No, they never did. There are other APL products for the IBM PC,
although I don't know offhand if there ever was an 8080 APL. There
might well have been one of a sort that ran under CP/M.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
Eric Smith
> But the floating point routines in AppleSoft were written by Randy
> Wiggington, who was still in high school at the time. He didn't have the
> background to warn him off from this pitfall. He's in good company - lots
> of others have made this mistake - but it's still a mistake.
Ron,
Are you sure that Randy wrote the FP routines in AppleSoft? My disassembly
looks almost identical to the ones in the source code for Microsoft BASIC
for the Commodore PET and Ohio Scientific.
I don't doubt that Randy wrote *some* floating point routines. Weren't
there some in the Integer BASIC ROMs (but unused by Integer BASIC)?
Eric
Mark Statzer
TheCentralSc...@pobox.com wrote:
>
> On Tue, 22 Dec 1998 15:16:02 -0800, Ron Hunsinger <hns...@sirius.com> wrote:
> >
> >One of my favorites is the following:
> >
> > 100 FOR X = 1 TO 10000
> > 110 IF 1/X <> 1/X THEN PRINT X
> > 120 NEXT X
> ...
>
> My favorite when visiting a radio shack store was:
>
> 10 for x=1 to 32000
> 20 poke x,0
> 30 next x
>
> jumping jack crash!
The *best* one was;
10 PRINT CHR$(RND(255));:GOTO 10
...ran continuous gibberish all over the screen. Kicked in & out of 40
column, too...
Statz
Luis Fernandes
Re: floating point, you might want to have a look at:
http://www.cs.berkeley.edu/~darcy/Research/index.html
Mr. Darcy visited Ryerson and gave the talk titled "Evolving Java's
Floating Point Support: The Good, the Bad, and the Ugly".
lis...@zetnet.co.uk
On 1998-12-23 rich...@plano.net said:
:Nick S Bensema wrote:
:> [snip...] [snip...] [snip...]
:> I'd really like to get my hands on one of those machines... they
:> seem like they'd be neat to lug around and take notes on, but I
:> have a feeling the going rate for a working model 100 is probably
:> more than that for a 386 laptop, which I could have just as much
:> fun with.
:Check on ebay and on <comp.sys.tandy> for Model 100's for sale.
:You might be surprised at what price you can have one for your very
:own. I believe it can be had for less that $100 US. I do *not*
:know what the going rate is for 386 laptops, though . . .
Less than $100 sounds about right to me. :>
--
Communa (lis...@zetnet.co.uk) -- you know soft spoken changes nothing
lis...@zetnet.co.uk
On 1998-12-22 hns...@sirius.com(RonHunsinger) said:
:One of my favorites is the following:
:100 FOR X = 1 TO 10000
:110 IF 1/X <> 1/X THEN PRINT X
:120 NEXT X
:It's hard to imagine how 1/X could ever NOT be equal to itself, yet
:this program will print out a distressingly large number of values
:of X for which it isn't.
:I came across this one from the inside out. I was disassembling the
:ROM, and while reading the code to evaluate expressions I found
:some that made me splutter "But... but... if they do it that way,
:then...". I wrote the above test program, and sure enough they did.
Tee hee. This is one of the reasons I don't like floats.
QL SuperBASIC had a rather nifty function, though, that would get around
a fair number of these problems. It had an "approximately equal"
comparison operator, which would return TRUE if two floats differed by
only one digit's worth of precision or two strings differed only in
case.
Kin Hoong CHUNG
: In article <75oe9l$b6$1...@eiffel.swec.com>,
: Carl R. Friend <carl....@stoneweb.com> wrote:
:>
:>Nick S Bensema wrote in message <75ngp8$d2s$1...@nnrp02.primenet.com>...
:>>
:>>Here's a fun exercise... ask those who have owned the Model 100 what
:>>was really great about that old machine, and then tell them that Bill
:>>Gates wrote the ROM in it.
:>
:> Usually you don't need to tell them. When the machine first comes
:>up it "proudly" displays the Microsoft copyright message. Even with-
:>out that message you can tell it's Mickeysoft Inside -- if you really
:>push the machine hard it runs slower and slower as the garbage collect
:>logic gets whacked. Eventually you have to push the reset button on
:>the back beacuse it can take several seconds to recognise a keystroke.
: Yipes.... that's so Timex-Sinclairesque. But I'm not surprised at
Well, it has something that _few_ modern laptops have---a nice full-travel
(if I recall correctly) keyboard.
Merry Christmas,
Kin Hoong
Paul Guertin
> QL SuperBASIC had a rather nifty function, though, that would get around
> a fair number of these problems. It had an "approximately equal"
> comparison operator
Iverson's J programming language (a modern, ASCIIfied version of APL)
does all equality comparisons this way, I believe. The tolerance is
user-specifiable.
Paul Guertin
p...@sff.net
Paul Guertin
<rich...@plano.net> wrote:
> Check on ebay and on <comp.sys.tandy> for Model 100's for sale. You might be
> surprised at what price you can have one for your very own. I believe it can
> be had for less that $100 US.
Data point: I saw a Model 100 with a $50 price tag at last year's
Trenton Computer Fair.
Paul Guertin
p...@sff.net
Michael Black
I have a copy of "Write" for the Atari ST, so it did become a commercial
product. I bought it at a clearance at a store getting out of the Atari
business, for something like fifteen dollars. I don't have the manual
handy to see what it says. The box clearly marks it as coming from Atari,
but it is called "Microsoft Write".
Michael
Tim Shoppa
> What bugged me about Apple BASIC was that NONE of the versions used the
> up-arrow key for anything.
Hmph. I'm looking at my Apple ][+ right now, and can't find the
up-arrow key. Care to point me to it?
> Commodore and Atari machines, including, I believe, the PET, used
> a screen editor that let you move the cursor around and type
> anywhere, and just parsed whatever line the cursor was on when you
> hit RETURN. Even the Sinclair computers had something similar to
> that, even if it was slow and unresponsive. I've only heard legends
> about BBC BASIC, which many allege to be the greatest BASIC
> interpreter of all time. But the Apple's BASIC didn't have anything
> of the kind. As far as I knew, if you wanted to edit a line, you
> had to re-type the entire line with the changes you wanted.
The Apple ]['s editing scheme is actually far more versatile -
you hit ESC, use the I-J-K-M keys to position the cursor
over the start of the stuff you want, and then right-arrow over
it. Using this method anything on the screen can be easily
included in the input line. This is well-documented in the _Apple ][
Reference Manual_ that shipped with your ][ or ][+, Chapter 2, p. 34,
"Escape Codes".
Tim.
Nick S Bensema
Eric Fischer <er...@fudge.uchicago.edu> wrote:
>
>The C64 BASIC was from Microsoft. The original Apple Integer BASIC
>wasn't -- it was written by Steve Wozniak -- but Applesoft (floating
>point) BASIC was another Microsoft product. The standard BASIC for
>the Atari 400 and 800 wasn't from Microsoft, but a Microsoft version
>was available as an option.
I had that version, pretty much because it looked like it would be more
fun to play with, and because there was this one book with a type-in
program that used it. And it even used VARPTR and related functions
to allocate font memory, and it seemed really convoluted at the time
compared with finding the topmost 1K of memory and POKEing at it.
>Texas Instruments, though, somehow managed
>to avoid having any Microsoft BASIC available for its TI-99/4A.
If that history-of-the-TI page is accurate, they managed that by
making it impossible for anyone but TI to develop for the machine
until five years after it came out.
It still gets me how the TI couldn't even compete with the Vic-20.
--
Nick Bensema <ni...@primenet.com> 98-KUPD Red Card #710563 UIN: 2135445
~~~~ ~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
</BLINK>
Nick S Bensema
D. Peschel <dpes...@u.washington.edu> wrote:
>
>Apple: There were two dialects. Integer BASIC (written and hand-assembled
>by Steve Wozniak) is fast and simple, has some nice features, and has only
>one minor bug I know of. (There's a *** TOO MANY PARENS ERR message, but
>using too many parentheses gives you another error, so the correct one never
>shows up. This can be fixed by changing one byte.) AppleSoft (written and
>copyrighted by MS, patched by Apple to handle lower-case) is slow and
>complicated, has floating-point and strings but lacks some of the
>convenience of Integer BASIC, and has many bugs and anomalies.
What bugged me about Apple BASIC was that NONE of the versions used the
up-arrow key for anything.
Commodore and Atari machines, including, I believe, the PET, used
a screen editor that let you move the cursor around and type
anywhere, and just parsed whatever line the cursor was on when you
hit RETURN. Even the Sinclair computers had something similar to
that, even if it was slow and unresponsive. I've only heard legends
about BBC BASIC, which many allege to be the greatest BASIC
interpreter of all time. But the Apple's BASIC didn't have anything
of the kind. As far as I knew, if you wanted to edit a line, you
had to re-type the entire line with the changes you wanted.
--
D. Peschel
In article <761cva$n1c$4...@nnrp02.primenet.com>,
Nick S Bensema <ni...@primenet.com> wrote:
>In article <75p27m$10u0$1...@nntp1.u.washington.edu>,
>D. Peschel <dpes...@u.washington.edu> wrote:
>>Apple: There were two dialects. Integer BASIC (written and hand-assembled
>What bugged me about Apple BASIC was that NONE of the versions used the
>up-arrow key for anything.
Up-arrow key? What up-arrow key? There was none until the //e and //c
(unless someone added a home-built keyboard.)
The Apple ][ keyboard can send most of the 32 control characters, most of the
64 upper-case-and-punctuation ASCII characters, and none of the 32 lower-case
ASCII characters. (The exceptions involve [ \ _ and their associated control
characters, except that Escape is available.)
It has a left-arrow key which is the same as Ctrl-H (backspace) and a right-
arrow key which is the same as Ctrl-U (? - I haven't seen that little quirk
on any other computer). There are no up- or down-arrow keys. There is a ^
key but i hope that's not what you meant.
On the //e and //c, the down-arrow key sends a Ctrl-J (linefeed). That
moves the cursor down but is not very useful. The up-arrow key sends a
Ctrl-K (vertical tab - some other machines work the same way) but, as you
say, is ignored.
Maybe Apple could have put something in, but by then the bonds of backward-
compatibility were pretty strong!
>Commodore and Atari machines, including, I believe, the PET, used
>a screen editor that let you move the cursor around and type
>anywhere, and just parsed whatever line the cursor was on when you
>hit RETURN. Even the Sinclair computers had something similar to
>that, even if it was slow and unresponsive. I've only heard legends
>about BBC BASIC, which many allege to be the greatest BASIC
>interpreter of all time. But the Apple's BASIC didn't have anything
>of the kind. As far as I knew, if you wanted to edit a line, you
>had to re-type the entire line with the changes you wanted.
That's not true. The editing mechanism is clunky but it is there.
The fundamental keyboard input routine works with a line (up to about 255
characters) and allows you to move left or right within a line, add
characters to the end, and overtype characters in the middle. There's no
insertion. When you hit Return, characters to the right of the cursor are
erased and ignored.
Add to this the sequences Esc-A, Esc-B, Esc-C, and Esc-D (which move the
cursor up, down, left, or right, not necessarily in that order) and you can
use a two-step process: 1) move the cursor around the screen with the escape
sequences, 2) add characters to the input buffer by typing them or using the
right arrow to copy them. By the way, I think those sequences move the
cursor when they are output as well as when you type them in.
A further refinement (in the Autostart ROM that came with later ]['s) lets
you use Esc-I, J, K, M (a diamond pattern) to move the cursor. You don't
need to press Esc every time you move the cursor one character, either!
There were a few other frills (Esc-Ctrl-P clears the screen). Later
machines added more frills.
In a sense, the ][ originally borrowed its design from contemporary
terminals. The design was rather weak (even compared to those terminals)
but that's the way it goes. I think the single-line input model put great
constraints on further changes.
You're right about the "screen editor" approach on the Commodore and Atari.
On the Apple, the screen is a record of past input lines. On the Commodore
and Atari, the entire screen is made up of input lines. I don't know much
about the Commodore. On the Atari, a line is up to 120 characters. You can
move left/right/up/down within a line, use tab stops, delete characters,
insert a signle space to put a character in, delete and insert lines, and do
a few other things.
The BBC is the ultimate refinement of the Apple approach. The BBC keeps
track of a current input line, and I don't think you can use arbitary lines
as input lines. On the Apple, the escape sequences and arrows do two things
which are somewhat blurred: move the cursor around to old characters, and
put new characters into the input and manipulate the input. On the BBC, the
two jobs are clearly separated. It's kind of a neat mechanism, actually.
By default, you're only dealing with the current input line (regardless of
what's on the screen). You can erase characters from the end and that's
about all. (I think there's a Delete key which the Apple doesn't have/use.)
When you move the cursor with one of the arrow keys, it splits into TWO
cursors. You move one around the screen with the arrow keys, and hit a
special key (called COPY) to copy characters down to the input. Meanwhile,
the other one is tracking the input.
I'm not entirely sure what commands affect which cursor (if any) but it's a
very clever idea. Seeing the cursor split is very impressive. I think I
still like the screen-editor mentality better, however.
-- Derek
Paul Guertin
wrote:
> What bugged me about Apple BASIC was that NONE of the versions used the
> up-arrow key for anything.
Not really. Starting with the Apple IIe (the first Apple II with up-
and down-arrow keys), all four arrow keys could be used instead of
IJKM to move the cursor in escape mode.
Basically, when you typed ESC, you could move the cursor anywhere on
the screen (well, in the current text window, if you're a purist)
without BASIC "realizing" it. Then you typed ESC again and could use
the right-arrow key to trace over characters.
For example, if you just typed
]10 PRUNT "HELLO"
]_
(with the cursor where the underscore is), you could correct that
line by typing
ESC, up-arrow, up-arrow, ESC, right-arrow 5 times, I,
right-arrow 10 times, return.
BASIC would think that you just typed '10 PRINT "HELLO"'.
You could delete characters by going back into ESC mode before
tracing over them. Insertion was more difficult if there were
no spaces you could use: you had to use the line above (or below),
like this:
]10HCOLR=3:HPLOT0,0TO279,191 : REM SHOULD BE HCOLOR
]_
ESC, up-arrow, up-arrow, ESC, right-arrow 6 times, ESC, up-arrow,
ESC, O, ESC, down-arrow, left-arrow, ESC, right-arrow until EOL,
return.
(Real hackers would use one of the ABCD codes instead of the
last up-arrow to save one keypress, but I don't remember which
one was "up".)
You can imagine the flashbacks I had when I learned vi.
I agree that line editing in Applesoft was a pain. That's why
most people used Neil Konzen's PLE (Program Line Editor,
subsequently expanded and sold by Beagle Bros. under the name
GPLE (Global ~)), which was a combination line editor and macro
package.
With PLE loaded, you could edit any line by typing ^E followed by
the line number. It had character insertion and deletion and was
very comfortable to use. Also, you could map often-used strings to
ESC combinations, so that you could type ESC 1 instead of
"CATALOG,D1^M", and so on.
My favorite BASIC programming environment was GPLE, Double-Take
(LIST with two-way scrolling, variable cross-reference, hex/dec
conversion, and a dozen other enhancements) and Pronto DOS (a
patch to DOS 3.3 that made it nearly 3 times as fast).
> Commodore and Atari machines, including, I believe, the PET, used
> a screen editor that let you move the cursor around and type
> anywhere, and just parsed whatever line the cursor was on when you
> hit RETURN.
I thought that behavior was really strange, when I first saw it on a
Commodore 64, since it went against the "command line" model I
was used to.
Paul Guertin
p...@sff.net
Dave Daniels
wrote:
> The *best* one was;
>
> 10 PRINT CHR$(RND(255));:GOTO 10
>
> ...ran continuous gibberish all over the screen. Kicked in & out of 40
> column, too...
At least with GUIs we can be childish in more sophisticated ways.
A trick I have come across with RISCOS is to grab part of the
screen containing one or more filer windows as a sprite and then
to use that sprite as the backdrop ('wallpaper' in Windows
terminology). The trick is to then watch people clicking on files
in what *they think* are real filer windows...
Dave
--
ANTISPAM: Please note that the email address above is false. My
correct address is:
dave_daniels<at>argonet<dot>co<dot>uk
Please replace the <at> and <dot>s with @ and . respectively when
replying - Thanks!
Dave Daniels
> that, even if it was slow and unresponsive. I've only heard legends
With regards to BBC Basic, on Acorn machines it has cursor editing
facilities that are provided by the operating system (MOS on the
BBC Micro, RISCOS on the Archimedes/A5000/Risc PC ranges). These
work along broadly the same lines as you describe in that you can
drive the cursor around the screen and copy characters from
anywhere. The difference is that they are copied to the input
buffer rather than the line on the screen being used as the input.
The Amstrad CPC range has the sort of editing/input capabilities
you describe.
> about BBC BASIC, which many allege to be the greatest BASIC
> interpreter of all time.
BBC Basic is certainly an extremely powerful dialect of Basic. I
think that the Sinclair QL people would argue that QL Superbasic
is better, but IMHO Sophie Wilson of Acorn wrote something a bit
special when she developed BBC Basic.
What can I say quickly about it? Well, Acorn developed an extended
Basic which includes such features as procedures, multi-line
functions, block IF statements, CASE statements, WHILE and REPEAT
loops and so forth. I suspect that other additions were inspired
by BCPL, in that it has indirection operators and a simple but
effective way to dynamically allocate memory. With a bit of care,
you can build and manipulate any dynamic data structure you like.
The snag is, it is like doing it at assembler level. One of the
other selling points is that it has a built in assembler which is
integrated with the interpreter so you can mix Basic and assembler
in the same program with ease. The assembler source is assembled
at run time (the assembler is very, very fast) and it can use the
facilities of the Basic interpreter as an extremely powerful macro
processor. In the ARM versions, just about the full facilities of
the OS are directly available to Basic programs. It also seems to
be a rule that BBC Basic interpreters are extremely fast. The 6502
version stood head and shoulders above just about every other
Basic interpreter running on an 8-bit processor. The ARM versions
have carried on that tradition.
Putting together the speed, direct access to the OS, the
assembler, the indirection operators, dynamic memory allocation
and the other, more common extensions and IMHO you have an
extremely potent programming language. It is nowadays largely
overlooked as everybody uses C and Java, plus, of course, who
programs in Basic beyond the age of twelve? IMHO, it is still a
great language, and ideal when you want to do something quickly
rather than crank up the heavy machinery and do it in C.
I guess that if BBC Basic had been designed by an American
company that people would have been singing its praises as the
greatest version of Basic of all time for years but it is
British, so...
Gene Wirchenko
[snip]
>If that history-of-the-TI page is accurate, they managed that by
>making it impossible for anyone but TI to develop for the machine
>until five years after it came out.
>
>It still gets me how the TI couldn't even compete with the Vic-20.
I think the first paragraph is much of the explanation for the
second.
I remember the Radio Shack TRS-80 Model I. Lots of non-RS
hardware and software came out for it. It helped RS; it didn't hinder
it.
Visicalc, the forerunner of Lotus 1-2-3, was in its time a killer
app (the first killer app for micros IIRC) that helped sell an awful
lot of Apples to businesspeople just by itself.
There are probably other examples as well.
Matt Ackeret
Nick S Bensema <ni...@primenet.com> wrote:
>What bugged me about Apple BASIC was that NONE of the versions used the
>up-arrow key for anything.
That's not BASIC's fault, that's the command interpreter's fault.
Plus, on a //e (or is it enhanced //e?) or better, you can use the arrow
keys in escape mode to move the cursor around... (as well as IJKM.. dang,
one of the few things Woz did wrong. IJKL is so much easier to use repeatedly
than IJKM, even if IJKM is a tiny bit more 'physically intuitive'). I just
quit ProTERM for a minute on this GS and verified that escape works in
BASIC.SYSTEM the way I expected.
>of the kind. As far as I knew, if you wanted to edit a line, you
>had to re-type the entire line with the changes you wanted.
Nope. Use escape mode to move the cursor around, and move the cursor over
previously-typed things in non-escape mode to copy characters, and
move to another area of the screen to type new characters to insert.
It's not as good as something like GPLE (Global Program Line Editor, by
Beagle Bros), but you don't have to type the whole line.
BTW, Byteworks just released a freeware version of GS BASIC.
--
mat...@area.com
Don Stokes
>With regards to BBC Basic, on Acorn machines it has cursor editing
>facilities that are provided by the operating system (MOS on the
>BBC Micro, RISCOS on the Archimedes/A5000/Risc PC ranges). These
>work along broadly the same lines as you describe in that you can
>drive the cursor around the screen and copy characters from
>anywhere. The difference is that they are copied to the input
>buffer rather than the line on the screen being used as the input.
>The Amstrad CPC range has the sort of editing/input capabilities
>you describe.
But all of these were clunky bolt-ons to the old replace-line-by
line-number scheme dating back to the original Dartmouth BASIC. The
Commodore style screen editing was closer to a real screen editor
than the Apple/BBC styles of copying screen contents into a separate
buffer, and had the distinct advantage that you could move directly to
the bit you wanted to change, change it and hit Return, as opposed to
the Beeb/Apple approach where you had to copy the entire line. It did
get a wee bit tiresome.
What really annoyed me about the Apple was that the ROM routine to do
single-key input (implemented by GET in Applesoft BASIC) would insist on
doing the screen edit thing, and on some (not all) versions of the //e
ROM, this included treating the up-arrow key as ESC-I (some of the other
posts in this thread more than adequately describe Apple ][ style
editing). So you went to get a single keystroke, the user hit the
up-arrow and the cursor went its merry way up the screen. Not good if
you're trying to write a screen based data entry program that uses the
arrows to move between fields.
So I found myself writing my own input routine in machine code
(assembler? we don't need no steekin assembler), first to just read
keystrokes with the editing being done in BASIC, but when that was
easily outrun by the 80 wpm typist using the thing, I put the whole
field input routine into machine code (doing a search for the string
variable "A$" and using that as the buffer address and field length).
And of course, this being the Apple and having a rather idiosyncratic
approach to what was or wasn't in hardware, the routine even had to
flash the cursor, including switching in and out of the two 80-column
card pages (which, bizzarely, mapped every second column, so to write
a row of text you'd switch in the first page, write the first character
to the first address, switch in the second page, write the second
character to the same address as the first, switch back the first page
and write the third character to the second address, switch in the
second page, write the fourth into the same (second) address, and
so-on).
The thing did have an ASCII keyboard register, whereas most other
contemporary micros just mapped the keyboard lines directly to memory or
an I/O port, leaving the software to sort out how to get ASCII input. Of
course that meant you couldn't use the keyboard for pushbutton style
control. The Beeb had MOS routines to give you either ASCII input or
check for specific key states, so was much more flexible. One couldn't
help noticing that mostly you didn't care about how the Beeb's hardware
was laid out, but the with the Apple you found yourself getting intimate
with the hardware registers the moment you started to something
non-trivial.
For assembly programming on the Beeb I wrote a little memory resident
screen editor that when involked would fiddle the OS vectors so that
output would be redirected to the editor, and force a LIST command into
the input. It would trap the output, remove the line numbers and
sqirrel the rest away in high memory to be edited, then when you exited
it would diddle things so that input came from the edit buffer, after an
AUTO command. That way one could edit assembly programs without having
to worry about line numbers. The program always had a BASIC FOR loop
around it to give two-pass assembly.
>BBC Basic is certainly an extremely powerful dialect of Basic. I
...
>What can I say quickly about it? Well, Acorn developed an extended
>Basic which includes such features as procedures, multi-line
>functions, block IF statements, CASE statements, WHILE and REPEAT
>loops and so forth. I suspect that other additions were inspired
Much of that is later add-ons. The original BBC BASIC had multiline
functions and procedures, and REPEAT ... UNTIL, but that was it for
control statements. IF statements were old-fashioned one-liners (they
did have ELSE, which the MS variants didn't have, but still restricted
to how many statements separated by ':'s you could bunch up on a line.
I occasionally used the screen editor mentioned above to write simple
BASIC programs (without line numbers), but without line numbers or
multiline IFs you hit brick walls pretty quickly.
Of course the built-in assembler was a godsend on an 8-bit micro, and
the indirection ops were a lot more useful than the MS style PEEK & POKE.
There were other little niceties like '&' to denote a hex constantant.
And there was a decent interface into the OS, so you didn't have to use
anything like the appalling crocks used by the Apple, eg:
PRINT CHR$(4); "OPEN FILENAME"
(Ghod, the OS interfaces in the Apple sucked, when they existed at all,
that is!)
And as you note, the BBC BASIC was fast. The 2 MHz 6502 made the beast
marginally faster than anything else in its class, but compared to MS
BASIC based machines, BASIC programs on the Beeb easily outran the same
programs running on anything else.
--
Don Stokes, Networking Consultant http://www.daedalus.co.nz +64 25 739 724
D. Peschel
Don Stokes <d...@news.daedalus.co.nz> wrote:
>Much of that is later add-ons. The original BBC BASIC had multiline
>functions and procedures, and REPEAT ... UNTIL, but that was it for
>control statements. IF statements were old-fashioned one-liners (they
>did have ELSE, which the MS variants didn't have, but still restricted
>to how many statements separated by ':'s you could bunch up on a line.
What machines are we talking about here? As far as I know, the evolution
went something like this:
Atom +--> Electron
|
+-------> Proton (= BBC Micro), models A and B --> model B+ --> Master
Then we get into the 16-bit machines which I'm not going to deal with.
So which machines have the simpler version of BASIC?
>Of course the built-in assembler was a godsend on an 8-bit micro, and
>the indirection ops were a lot more useful than the MS style PEEK & POKE.
>There were other little niceties like '&' to denote a hex constantant.
>And there was a decent interface into the OS, so you didn't have to use
>anything like the appalling crocks used by the Apple, eg:
>
> PRINT CHR$(4); "OPEN FILENAME"
>
>(Ghod, the OS interfaces in the Apple sucked, when they existed at all,
>that is!)
The OS interface is very lovely (from a user's point of view -- from a
programmer's point of view, although it seems straightforward to me, it also
seems to have a LOT of vectors and entry points). How do you define new *
commands? I've always assumed it's possible (with such a well-designed
system it MUST be possible!) Can you define new BASIC commands too?
I think the problem with the Apple is that it started out as a simple
machine, 1-2 generations before the Atari/Commodore/BBC/CPC. The
convenience features it has are convenient in the mindset of the 70's -- in
the mindset of the 80's they are essential. And the Apple's features don't
fit together very well (Wozniak admitted that he added the grahpics and
sound because they were cool and easy to add). When piling something on top
of a small foundation, you get bad results. This became true especially
with the //c and //e.
The BBC hit the same sort of scalability "wall" with the Master series, as
far as I can tell from reading the manual. They planned farther ahead but
the memory architecture and backward compatibility still got messy.
I do have a soft spot for the Apple (since I grew up with it) and I think
the disk system is ingenious and there are some timeless programs for it
(which is even more remarkable considering the quirks of the hardware).
-- Derek
Don Stokes
D. Peschel <dpes...@u.washington.edu> wrote:
>In article <763v85$7js$1...@news.wlg.netlink.net.nz>,
>Don Stokes <d...@news.daedalus.co.nz> wrote:
>
>>functions and procedures, and REPEAT ... UNTIL, but that was it for
>>control statements. IF statements were old-fashioned one-liners (they
>>did have ELSE, which the MS variants didn't have, but still restricted
>>to how many statements separated by ':'s you could bunch up on a line.
>
>went something like this:
>
>Atom +--> Electron
> |
> +-------> Proton (= BBC Micro), models A and B --> model B+ --> Master
More like:
Atom ... BBC A -- BBC B -- BBC MASTER
|
+-- Electron
I'm not sure where the Proton fits in, probably off the Atom. But the
Electron was post-BBC, basically an attempt at a cut-down Beeb. It had a
lot less hardware under the bonnet, and what was there took advantage of
ULA/PLA technology to stuff a lot of what was there into a single chip.
>So which machines have the simpler version of BASIC?
At least as recently as the BBC B and Electron (circa 1984). I'm not
sure about the Master, but the Archimedes versions have many many
improvements over the BBC B / Eectron version.
>>[Apple OS -- it sucked]
>The OS interface is very lovely (from a user's point of view -- from a
>programmer's point of view, although it seems straightforward to me, it also
>seems to have a LOT of vectors and entry points).
OK, I'm thinking of DOS 3.3, which was *the* DOS for the Apple for all the
time I used them. ProDOS just wasn't widespread until the GS came out as
far as I could make out.
I don't remember many entry points, although there were a couple of
routines in DOS for fooling with blocks & load/saving files that I never
really got into. Mostly though, the Apple had two I/O streams, one in,
one out, that you could diddle with the PR# and IN# statements. If you
went PR#1 to get at the device in slot 1 (eg a printer) you blew away
DOS (on #6), except that DOS was smart enough to notice that you'd
*typed* PR#1 (but was lost if you actually put PR#1 into your program --
instead you'd put in PRINT CHR$(4);"PR#1" and DOS would do the
redirection for you). Oh, and if you typed "PR#6" it rebooted...
DOS just lived in your input and output streams. If it saw a Ctrl/D it
assumed the rest of the output line was a DOS command. Now that I think
of it, the sequence to read a line from a file named by F$ into A$ was:
PRINT CHR$(4); "READ "; F$
INPUT A$
PRINT CHR$(4); "CLOSE"
or something like that. There was no concept of file handles, so if you
wanted to read or write a different file you had to close the previous one
first. Writing real applications was a *pain*.
> How do you define new *
>commands? I've always assumed it's possible (with such a well-designed
>system it MUST be possible!) Can you define new BASIC commands too?
On the Beeb, the philosophy was completely different. You never called
DFS (Disk Filing System) or ADFS (Advanced DFS, hierarchical dirs etc)
directly, you called the OS. The OS would talk to whichever filesystem
was currently installed, and only one could be active at a time. The
MOS never had any concept of I/O redirection (which contrasts the Apple
where it *only* had redirection), or device naming, so there was one
filesystem, up to two serial ports, one cassette port, one printer port
and so-on, with different interfaces, albeit in many cases controlled
through the same entry points but with different function codes.
You could (and I did) define new * commands by hooking the OSCLI vector.
OSCLI was the entry point to interpret a * command -- you gave it the
address of the command in the X & Y registers (CR terminated, I think),
and it interpreted it. But the OS called its routines via some vectors
so you could hook these and fiddle.
The main OS routines were OSBYTE and OSWORD. OSBYTE used the accumulator
as a function code, and X & Y as parameters. OSWORD has X & Y as a 16 bit
address of a function-specific control block. There were separate file
I/O call as well.
BASIC was completely separate -- it called the OS functions, but not the
other way around (apart from the "*BASIC" OSCLI command). (Incidentally,
"*command" was the accepted way for a CLI to recognise that a command
should be passed to OSCLI to be interpreted instead of being interpreted
locally. OSCLI ignored leading '*'s.)
>I think the problem with the Apple is that it started out as a simple
>machine, 1-2 generations before the Atari/Commodore/BBC/CPC. The
>convenience features it has are convenient in the mindset of the 70's -- in
>the mindset of the 80's they are essential. And the Apple's features don't
>fit together very well (Wozniak admitted that he added the grahpics and
>sound because they were cool and easy to add). When piling something on top
>of a small foundation, you get bad results. This became true especially
>with the //c and //e.
I'd have to agree with this. A small micro back in those days was just
a CPU and memory and a few peripherals grafted onto the system bus in
the cheapest way possible, and that philosophy showed. Even the Beeb's
MOS had a fairly fixed idea about what it was likely to be faced with,
although it did manage to make the split between the OS and BASIC that
wasn't in evidence on other boxes.
>The BBC hit the same sort of scalability "wall" with the Master series, as
>far as I can tell from reading the manual. They planned farther ahead but
>the memory architecture and backward compatibility still got messy.
The Beeb's biggest weakness was that its ROMs were just too darned big.
The MOS took 16 K all by itself, and BASIC (or whatever other language
or ROM based application was loaded) took another 16 K. That left you
with 32 K of RAM, and the OS and friends wanted a chunk of that (and
ADFS was particularly hungry). The coprocessor (3 MHz 6502 with its own
memory) somehow managed to get you 48k, but it was hugely expensive.
The Beeb was a bitty-box. A *nice* bitty-box, but still a bitty-box. It
was also a lot more recent than the Apple.
>I do have a soft spot for the Apple (since I grew up with it) and I think
>the disk system is ingenious and there are some timeless programs for it
>(which is even more remarkable considering the quirks of the hardware).
Personally, I came to hate the I/O system. When I was doing Real
Applications for it, I'd already been using the Beeb (well, an Electron
mainly, but Beebs as well) and knew what a file handle was. I hated the
way when I kicked the (Nestar) network in the guts I lost the 80 column
card (but got it back after I finished making Nestar fiddle things into
a sufficiently DOS 3.3-like configuration so I could just use DOS
commands to deal with). The Beeb had real networking, the Apple was
very, very hacked together. But even standalone it was not pretty. I
never, ever liked the fact DOS commands were sent in-band, and after
many years dealling with real computers and real OSes I like it even
less.
I was also rather less than impressed with the skimping on hardware that
went into the Apple. For eg, there's no interrupts. The ROM has stuff
to revector the interrupts, but there aren't any. No time, no input,
nothing. So a real OS (defined as one that at least has async I/O and
pre-emption) on basic Apple hardware could never be written. It would
never get a real typeahead buffer. And this is all ten-cent stuff, not
huge $$$ added to the cost to implement this stuff. Even in 1976.
Paul Guertin
> Plus, on a //e (or is it enhanced //e?) or better, you can use the arrow
> keys in escape mode to move the cursor around...
It was on the original //e.
> (as well as IJKM.. dang,
> one of the few things Woz did wrong. IJKL is so much easier to use repeatedly
> than IJKM, even if IJKM is a tiny bit more 'physically intuitive').
I agree. So just use the ol'EPROM burner to correct that little
mistake. Apple even gave out the source to the Monitor, so it was
easy to know which two bytes to patch.
One thing I've always wanted to do (but never did, for lack of
time) was to get the code for another microcomputer (preferably
65xx-based) BASIC, make the necessary patches, and load it on
the language card (*). Imagine the shock of my C64 friends when
they would see my Apple II emulate their computer!
(*) The "language card" was a card containing an extra 16k of
bank-switchable RAM. When you booted the System Master disk,
an image of the Integer ROMs was loaded into it, and you could
switch between Applesoft and Integer with the "INT" and "FP"
DOS commands.
Paul Guertin
p...@sff.net
Paul Guertin
<a__fake_...@127.0.0.1> wrote:
> IMHO Sophie Wilson of Acorn wrote something a bit
> special when she developed BBC Basic.
>
> [...] procedures, multi-line functions, block IF statements, CASE
> statements, WHILE and REPEAT [...] indirection operators [...]
> dynamically allocate memory [...] built in assembler [...]
> extremely fast.
Want want want!
Is the source code for that BASIC available anywhere? Even though
Apple and Commodore never published the source for their BASIC,
there were books like "Mapping the Commodore" and "What's Where in
the Apple" that contained very detailed explanations that were
as good as a real disassembly.
An Apple II assembler, Roger Wagner's Merlin, came with a
program that would disassemble the ROM BASIC in your computer,
massage it to add meaningful labels and comments, and print the
result. Presto, BASIC source code.
Does something like this exist for BBC BASIC? I'd love to get
my hands on it and compare it with other 6502 BASICs I know.
If it's really good, it could end up replacing Applesoft in
my Apple II...
I never saw a BBC computer. Were they even sold in Canada? But I
knew of their BASIC because I had a book called "Spacegames"
with about two dozen cheezy Basic programs in several dialects
(TRS-80, Apple II, PET, ZX81...). The BBC version was unlike all
the others, and it was obvious even to me that its BASIC was much
more powerful than all the others.
Paul Guertin
p...@sff.net
Charles Richmond
>
> [snip..] [snip...] [snip...]
>
> I agree. So just use the ol'EPROM burner to correct that little
> mistake. Apple even gave out the source to the Monitor, so it was
> easy to know which two bytes to patch.
>
> One thing I've always wanted to do (but never did, for lack of
> time) was to get the code for another microcomputer (preferably
> 65xx-based) BASIC, make the necessary patches, and load it on
> the language card (*). Imagine the shock of my C64 friends when
> they would see my Apple II emulate their computer!
>
to implement things like sprites and sound and such. Just transferring the
BASIC code to the Apple would *not* be enough to turn it into a C64. With the
Apple ][, things like graphics and music are much more the responsibility of
the programmer and whatever tricks s/he can dream up.
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
tur...@my-dejanews.com
> One thing I've always wanted to do (but never did, for lack of
> time) was to get the code for another microcomputer (preferably
> 65xx-based) BASIC, make the necessary patches, and load it on
> the language card (*). Imagine the shock of my C64 friends when
> they would see my Apple II emulate their computer!
No, you wouldn't want to do that! BASIC 2.0 is a pile of utter crap.
Mind you, I think Integer Basic is even worse. I suppose it's quite
feasible though as the C64 Kernel (BIOS) is separate from the BASIC
and has a rather nice call interface. All you'd need was RAM in the
appropriate places. What impressed me was some friends of mine
porting the BASIC interpreter from the BBC Micro Model B to the C64.
I only played with it a bit but it seemed fairly solid and they were
cross assembling code on both "platforms" if I remember correctly...
-t.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Gene Wirchenko
[snip]
>Much of that is later add-ons. The original BBC BASIC had multiline
>functions and procedures, and REPEAT ... UNTIL, but that was it for
>control statements. IF statements were old-fashioned one-liners (they
>did have ELSE, which the MS variants didn't have, but still restricted
>to how many statements separated by ':'s you could bunch up on a line.
Which version of MS BASIC? I used MBASIC 4 and 5 which were the
mainstream BASIC and they most definitely did have else clauses.
[snip]
Victor Eijkhout
> AppleSoft (written and
> copyrighted by MS, patched by Apple to handle lower-case)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
*Prffftt* !!
--
Victor Eijkhout
"Too many textbooks and discussions leave children free to make
up their minds about things." [Fundie Mel Gabler]
Ariel Scolnicov
> In article <7642ju$106e$1...@nntp1.u.washington.edu>,
> D. Peschel <dpes...@u.washington.edu> wrote:
> [...]
> >[...]
> >So which machines have the simpler version of BASIC?
>
> At least as recently as the BBC B and Electron (circa 1984). I'm not
> sure about the Master, but the Archimedes versions have many many
> improvements over the BBC B / Eectron version.
I only ever *saw* a Master, not actually used one. It had WHILE loops
(for the first time in BBC BASIC). I think the official reason was
that the Master was documented as using a 65c02 (unlike the model B,
which was supposed to use a 6502, but many were built with a 65c02, or
you could bring your own). The additional unconditional branch
instruction saved enough bytes in the ROM to make space for the WHILE
command.
The above is dimly-remembered hearsay from an unreliable source...
I don't remember what other BASIC improvements the Master added.
> [...]
--
Ariel Scolnicov /---------------\ "GCAAGAATTGAACTGTAG"
Compugen Ltd. |Join the Dark | Tel: +972-2-6795059 (Jerusalem)
72 Pinhas Rosen St. |Side! Just Say:| Tel: +972-3-7658520 (Main office)
Tel-Aviv | "Yes, but..."| +972-3-7658521
ISRAEL \---------------/ ari...@compugen.co.il
Dave Daniels
<ari...@compugen.co.il> wrote:
> I only ever *saw* a Master, not actually used one. It had WHILE loops
> (for the first time in BBC BASIC). I think the official reason was
I have just checked and the version of BBC Basic (Basic 4) on the
Master does not have a WHILE loop. ISTR that the WHILE loop was a
rumour from the earliest days of Basic 1, but AFAIK it first
appeared in Basic 5 on the Archimedes in 1987. (Okay, then,
someone tell me it was on the ARM Second processor...)
> The above is dimly-remembered hearsay from an unreliable source...
I think that your source was wrong.
> I don't remember what other BASIC improvements the Master added.
There were not many. It was recoded using the extra 65c02 opcodes
to make it faster and Acorn added an 'ON <expression> PROC<whatever>'
statement that worked along similar lines to 'ON <expression> GOTO'.
The graphics were extended, but that was because they were provided
by the OS and the improvements were in there. There was a full-screen
editor built in to the machine which made life easier, although the
maximum size Basic program it could handle was limited. That was
about it really.
Tom Seddon
>> Actually, it's not exact, Microsoft worked for a while on an Atari ST
>> version of the WORD word processing. It was a limited version known under
>> the name 'Write'. I don't know if it was marketed or not.
>>
>I have a copy of "Write" for the Atari ST, so it did become a commercial
>product. I bought it at a clearance at a store getting out of the Atari
>business, for something like fifteen dollars. I don't have the manual
>handy to see what it says. The box clearly marks it as coming from Atari,
>but it is called "Microsoft Write".
Microsoft Write was bundled with some STFMs (of the 1040 variety) around
Xmas 1988. It was a nasty piece of software. It required an add-on to
the ST's OS (GDOS) to allow you to use fonts, required two disk drives
because the bitmap fonts took up so much disk space, and ran damn slowly
because it was so poorly written. It also crashed every 5 seconds too;
however, this could be fixed (to a small extent) by saving your
documents on the program disk.
In its defence though, with 4MB of RAM and a hard disk (and no GDOS) it
was... usable. Just.
I have a suspicion that Microsoft wrote the original ST BASIC. That is,
the one that came on the original 'Welcome' type disk, before Atari saw
sense and bundled a cut-down version of Power BASIC (I think?) with
their computers. However, all my Atari stuff is in the attic so I cannot
confirm this.
Folklore content: the Atari ST's operating system was developed on Apple
Lisas.
--Tom
Tom Seddon
>Atom +--> Electron
> |
> +-------> Proton (= BBC Micro), models A and B --> model B+ --> Master
More like:
Atom +--> BBC Micro +--> model B+ --> Master
|
+--> Electron
The Electron owes more to the Beeb than the Atom, the OS is virtually
identical from a programming point of view and the BASIC is very similar
as well. (The OS/BASIC even includes calls for stuff that the Electron
doesn't have, e.g., ADC, multiple sound channels, teletext mode, to keep
compatibility with BBC software.)
>
>Then we get into the 16-bit machines which I'm not going to deal with.
>
>So which machines have the simpler version of BASIC?
I am not sure about the Atom. Its BASIC was possibly simpler than the
BBC's. All I do know is that programs written in it look very, very
peculiar -- at least compared to any BASIC I have seen before or since.
It did have an assembler though.
There were three versions for the BBC class of computers, BASIC I, BASIC
II and BASIC IV. You can tell which version of BASIC you have by
pressing BREAK and typing REPORT (don't forget to press return :-). (C)
1981 Acorn indicates BASIC 1, and (C) 1982 Acorn indicates BASIC 2. This
also works for BASIC 4. (Unfortunately BASIC 5 (Archimedes) was written
in 1986.)
On with the history.
The original version of BASIC was BASIC I. This was supplanted by BASIC
II. BASIC II had the following improvements:
* INSTR(x,y) no longer caused a full-scale crash if LEN(x)<LEN(y);
* The floating-point arithmetic was as accurate as the ZX81's, which was
an improvement;
* It had new assembly directives for assembling bytes, words,
doublewords and strings directly (this was possibly with the old BASIC
but annoyingly tricky);
* It had a new statement, OSCLI, which sent a BASIC string to the
operating system, so operating system commands could be constructed
easily. (This was possible with the old BASIC but annoyingly tricky.);
* The assembler supported assembling code for a given address at another
address in memory (E.g., assembling code destined for the ROM area into
RAM). Once again, possible with the old BASIC but annoyingly tricky...
and also long-winded.
* Finally it had a new keyword OPENUP, which opened a file for both
input and output. This was possible on the old BASIC as well, but the
statement was called OPENIN for some unfathomable reason. (OPENOUT did
as you would expect.) The BASIC II's OPENIN performed as per its name.
(It also had the following anti-improvement. Try this on a real BASIC
II-equipped BBC:
*fx200,3 [press BREAK]
O. [you will get a "Bad Program" message]
AUTO [You will get line 10. Press RETURN. You must press BREAK to
recover.])
BASIC III never was, I don't think. There was also a version of BASIC
for the 6502 second processor, this was mainly the same as BASIC II but
was reassembled to live at a different address because the second
processor had more memory. Oh, and it also recognised "COLOR" (which
was, of course, corrected to "COLOUR" when the program was LISTed :-) as
a valid keyword, as a sop to the American market. Despite the fact the
6502 second processor had a different 6502 model (I forget the number,
but it was the one with BBR/BBS instructions), the assembler was
unchanged.
BASIC IV was for the Master. Extra features were, so far as I can
remember:
* 65c12 opcodes in the assembler (PLX,PLY,STZ,BRA,etc)
* 65c12 opcodes used in the ROM itself (slightly faster);
* LIST IF command, to list lines containing a particular set of letters;
* ON...PROC (as ON GOSUB, but "structured" I presume);
* The EDIT command. This interfaced with the Master's built-in EDIT ROM
(or vice-versa) and caused the editor to pop up complete with
detokenized BASIC program in memory. (I'm not sure about the exact
details of this and am possibly wrong.)
(the Master may have had a 65c02. In contrast to the 6502 second
processor, it had the 6502 model that did *not* have BBR/BBS, but *did*
have most of the other new opcodes.)
>The OS interface is very lovely (from a user's point of view -- from a
>programmer's point of view, although it seems straightforward to me, it also
>seems to have a LOT of vectors and entry points). How do you define new *
>commands? I've always assumed it's possible (with such a well-designed
>system it MUST be possible!) Can you define new BASIC commands too?
You can write yourself a ROM, which will get called via its service
entry point when an unrecognised * command is entered. You may also
intercept USERV (&200,&201) which is called when a *CODE or a *LINE
command is executed. On entry to the routine, A=0 if *CODE was typed --
X+Y are the two parameters. A=1 if *LINE was typed -- X+Y point to the
rest of the command line. A between &e0 and &ff indicates that an OSWORD
call in that range was called, registers as per usual osword entry.
OR you could intercept the command-line interpreter (&208,&209) but this
is most probably more hassle than it is worth.
The Advanced User Guide for the BBC Micro has more details on the above.
Adding new BASIC commands is possible, I believe you intercept the BRK
vector, trap "Mistake" or "Syntax error" messages, decide which command
caused said error (by examining the BASIC workspace in zero page) and
interpret it yourself. I suspect this would be tricky to program though.
--Tom
Ben Harris
Tom Seddon <t...@sunholme.demon.co.uk> wrote:
>D. Peschel <dpes...@u.washington.edu> wrote this on Sun, 27 Dec 1998:
>
>I am not sure about the Atom. Its BASIC was possibly simpler than the
>BBC's.
According to my BBC BASIC User Guide, it used Atom BASIC, which was
integer-only. I haven't got a working Atom here to try it on, though I
might have a System version of it on floppy somewhere. The System also had
a version of BBC BASIC (called "Acorn New BASIC"). I don't know if the
Atom ever got it.
>BASIC III never was, I don't think.
According to the BBC BASIC User Guide, it was supplied on the B+, and just
provided COLOR and a couple of bug fixes.
>There was also a version of BASIC
>for the 6502 second processor,
known, I believe, as HIBASIC.
>BASIC IV was for the Master. Extra features were, so far as I can
>remember:
>
>* 65c12 opcodes in the assembler (PLX,PLY,STZ,BRA,etc)
>* 65c12 opcodes used in the ROM itself (slightly faster);
>* LIST IF command, to list lines containing a particular set of letters;
>* ON...PROC (as ON GOSUB, but "structured" I presume);
>* The EDIT command. This interfaced with the Master's built-in EDIT ROM
>(or vice-versa) and caused the editor to pop up complete with
>detokenized BASIC program in memory. (I'm not sure about the exact
>details of this and am possibly wrong.)
Also TIME$, "|" in VDU statements, EXT# and more bug fixes.
--
Ben Harris
Computer Officer, Corpus Christi College, Cambridge.
Nathan Sidwell
> Adding new BASIC commands is possible, I believe you intercept the BRK
> vector, trap "Mistake" or "Syntax error" messages, decide which command
> caused said error (by examining the BASIC workspace in zero page) and
> interpret it yourself. I suspect this would be tricky to program though.
I did something like this to assemble ROMs from a chained series of
programs. You needed more than 20K of source to produce a 16K rom, so I
would split up the source into <SRC>01, <src>02 ... files, each chaining
the next. The trick was how to keep all the assembly labels (normal
variables), which would be lost by a normal CHAIN command. As it
couldn't hold all the labels simultaneously, I effectively produced a
virtual memory system for variables, which intecepted the BRK vector,
looked to see if it was caused by an 'undefined var' error, and then
scanned a file to see if it knew what it was. Just before chaining the
next source file, all the variable values were merged into the file.
So I ended up with a two pass assembler which dealt with multiple source
files.
nathan
--
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
You can up the bandwidth, but you can't up the speed of light
nat...@acm.org http://www.cs.bris.ac.uk/~nathan/ nat...@cs.bris.ac.uk
Dr. Peter Kittel
>On Tue, 22 Dec 1998 15:16:02 -0800, hns...@sirius.com (Ron Hunsinger)
>wrote:
>
>[Bugs in Applesoft]
>>
>> One of my favorites is the following:
>>
>> 100 FOR X = 1 TO 10000
>> 110 IF 1/X <> 1/X THEN PRINT X
>> 120 NEXT X
>>
>> It's hard to imagine how 1/X could ever NOT be equal to itself, yet this
>> program will print out a distressingly large number of values of X for
>> which it isn't.
>
>Indeed.
Strange, this does not happen in AmigaBASIC (V2.0).
>One of my favorite Applesoft quirks is the way PRINT allows
>floating-point numbers to have more than one decimal point.
>This allows one to do arithmetic on software revision numbers.
>
>]PRINT 6.2.2 * 5.1
>6.21.02
Funny, I also tried it in AmigaBASIC, and it does it differently.
Also no error message, but "6.2 1.02" as result. It obviously
handles the first number with two decimal points as two, "6.2" and
".2".
--
Best Regards, Dr. Peter Kittel // E-Mail:
Private Site in Frankfurt, Germany \X/ peterk @ combo.ganesha.com
Deutsches Wort mit 4-mal "tz"? Atzventzkrantzkertze! (Uli Stein)
Dr. Peter Kittel
>
>What bugged me about Apple BASIC was that NONE of the versions used the
>up-arrow key for anything.
>
>a screen editor that let you move the cursor around and type
>anywhere, and just parsed whatever line the cursor was on when you
>hit RETURN.
Yes, and that was the part written by Commodore and not Microsoft,
AFAIK. This screen editor was one of the reason why I fell in love
with the PET, while neither Tandy nor Apple stood any chance in
comparison.
Don Stokes
>Adding new BASIC commands is possible, I believe you intercept the BRK
>vector, trap "Mistake" or "Syntax error" messages, decide which command
>caused said error (by examining the BASIC workspace in zero page) and
>interpret it yourself. I suspect this would be tricky to program though.
Would that work? Errors (from dim memory) were reported using BRK, ie:
brk \ 6502 breakpoint instruction ($00)
EQUB errorcode \ Byte errorcode
EQUS "errormessage" \ String error message
brk \ Terminating NUL.
So you could handle the BRK instruction OK, but you were left with the
problem of where to return to. The error handler didn't return, so the
code following the terminating nul could be anything. I suppose if you
disassembled the BASIC ROM around the offending address you could jiggle
the stack back the way it oughta be and jump back into the code that
would normally be executed after a successful keyword lookup, but it
wouldn't exactly be portable across different versions of BASIC.
Richard Plinston
>
> >There was also a version of BASIC
> >for the 6502 second processor,
>
> known, I believe, as HIBASIC.
The Master supplied on disk a version called Basic 128 which
could use all the sideways RAM as workspace.
Therewas a BBC Basic for the Z80 co-procesor, for the
Sinclair ZX88 and its derivitive the Amstrad something or other
and various versions for the IBM-PC (I have a couple somewhere).
Warren Young
>Charles Richmond <rich...@plano.net> wrote:
>I don't have my copy here with me to verify, but I'm sure it was the
>Model 100 because I posted a quote from the book in this newsgroup,
>back in June of 1996:
>
> "I still help design algorithms and basic approaches, and
> sometimes I look at code. But since I worked on the IBM
> PC BASIC and the Model 100, I haven't had a chance to
> actually create a program myself." (p. 72)
I just verified this in the DDJ version of the book -- the quote is
correct.
>There must have been a reference to the Color Computer too, though,
>because I remember there being an obvious typo where the book referred
>to a 6800 instead of a 6809. I'll check for the details when I get
>home tonight.
The relevant quote is:
"In the first four years of the company, there was no
Microsoft program that I wasn't involved in actually writing
and designing. In all those initial products, whether it was
BASIC, FORTRAN, BASIC 6800, or BASIC 6502, not a line of code
went out that I didn't look over. But now we have about 160
programmers, so I mostly do reviews of products and
algorithms."
Ain't cut-and-paste great?
= Warren -- http://www.cyberport.com/~tangent/
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m
=
= Dawn: The time when men of reason go to bed.
Gaven Miller
I haven't seen the original 1985-release ST Basic in a while, so cannot
check the program credits, but the "new ST Basic" dated 1987 (which
surfaced in mid 1988) was by the British company "Metacomco plc"
ST Basic "died" in 1991-ish, to be replaced by "First Basic" (a cut down
version of Power Basic - which, in its own recursive way, was a cut down
version of Hisoft Basic)
> Folklore content: the Atari ST's operating system was developed on Apple
> Lisas.
Is there a cite for this? I thought GEM was written on Intel PCs, and
recompiled for the ST.
--
All email sent to my inca address will fail, however I can now be
contacted via an intermediary : gem at tos pl net. I would like to
apologise to the genuine respondents that this may inconvenience.
Joe Thompson
Veken) wrote:
> It would strike me as very odd that the same calculation (1/x)
> would give two different results when executed twice.
We just went over this in another newsgroup. It's not that the
calculation was being done differently, it's that in most BASICs what
happens is: the first 1/x is pushed onto the stack, which stores it at a
lower FP precision (10 places instead of 13, say) and then when that
version is compared with the "fresher" (and untruncated) 1/x you get an
"inequality". -- Joe
--
Joe Thompson | http://kensey.home.mindspring.com/
$spam$@orion-com.com | O- He-Who-Grinds-the-Unworthy
"While preceding your entrance with a grenade is a good tactic in
Quake, it can lead to problems if attempted at work." -- C Hacking
Joe Thompson
> It also reminded me of a fact I had almost forgotten: that some
> numbers can easily be represented with a limited number of
> decimals in base 10, but not in base 2: i.e., the number 8000 was
> in both lists.
In general, after reducing a fraction to 1/x, the fraction is a
terminating decimal only if x contains factors which are all factors of
the base you're using. In base 10, that means 2 and 5. Obviously for
prime bases, it only works for numbers which are powers of the base (e.g.
in base 2, 1/x is a terminating decimal only for x that are powers of 2).
Converting fractions between bases is simple if they're powers of each
other, but otherwise the math, though simple, is tedious. -- Joe
Tom Seddon
>Tom Seddon (t...@sunholme.demon.co.uk) wrote:
>> Folklore content: the Atari ST's operating system was developed on Apple
>> Lisas.
>
>Is there a cite for this? I thought GEM was written on Intel PCs, and
>recompiled for the ST.
I dug out the article I got that piece of trivia from -- amazingly, it
was where I remembered it was!
According to the article, you are right, but, hey, no worries, because
I'm right as well ;-)
ANTIC PUBLISHING LTD, COPYRIGHT 1986. REPRINTED BY PERMISSION.
"When work starting on moving GEM to the ST, there were two big
problems. First, no STs actually existed. Second, there was no operating
system on the 68000 with which GEM and the Desktop could run. Unix was
too large, and CP/M-68K lacked a number of capabilities, such as
hierarchical files, which were needed to support GEM.
"Work on porting the graphics parts of GEM to the 68000 had to start
immediately to meet schedules. Therefore, CP/M-68K running on Apple
Lisa's [sic] was used to get this part of the project off the ground.
Naturally, the Alcyon C compiler and other tools which were native to
this environment were used.
"In parallel, an effort was begun to write a new operating system for
the 68000, which would ultimately become the ST's file system. It was
designed to be a close clone of PC-DOS, since it would perform the same
functions for GEM in the new environment. At this point, the term TOS
was introduced. TOS really meant 'the operating system, whatever it may
be, that will run on the ST', since not even the specifications, let
alone the code, were complete at that time.
"...As 'TOS' became more solid, the developer's tools were ported to the
new environment one by one, and the GEM programming moved with them.
CP/M-68K was completely abandoned, though the old manuals for C and the
tools lived on and are still found in the Atari developer's kit.
"All of this work had been done on Lisas or Compupro systems fitted with
68000 boards. At this point, workable ST prototypes became available. An
implementation of 'TOS' for the target machine was begun, even before
the basic operating system was fully completed.
"The other intent for the new operating system was to be a base for GEM
on other 68000 systems as well as the ST. Because of this, Digital
Research named it GEMDOS when it was finally complete, thus providing
the final bit of nomenclature. 'TOS' as now found in the ST is in fact a
particularly implementation of generic GEMDOS, including the ST-specific
BIOS."
(Tim Oren, professional GEM issue #15, Antic Magazine)
--Tom