Interesting bug

[Joona I Palaste]

Re: [OT] Commodore 64 BASIC

Old Wolf <oldwolf@inspir e.net.nz> scribbled the following:[color=blue]
> Joona I Palaste <palaste@cc.hel sinki.fi> wrote:[color=green][color=darkred]
>> >> Right on the money, Dan. I started programming on C=64 BASIC V2, which
>> >> is an extremely cut-down version of BASIC by 1980s standards. Back then
>> >> GOTO with a symbolic label rather than a hard-coded line number as the
>> >> destination was like science fiction...[/color]
>>
>> Yes, but what were you going to do about it? C-64 Basic v2 had pretty
>> much the bare minimum of control structures. IF... THEN was only for
>> single lines, not blocks of lines, and there was no ELSE. The only loop
>> available was FOR... NEXT. Every other kind of loop had to be simulated
>> with IF... THEN GOTO. And like I said, GOTOs had to have hard-coded line
>> numbers as destinations. There was GOSUB... RETURN which I think could
>> be used to have "poor man's subroutines", because they behaved
>> otherwise like subroutines but had no concept of local variable scope.[/color][/color]
[color=blue]
> Don't forget the BASIC equivalent of "switch":[/color]
[color=blue]
> 240 GOTO 250*(i=0) + 350*(i=1) + 380*(i=2) + .... + 3530*(i=51)[/color]
[color=blue]
> (this came from an adventure game where there were 50 or so possible
> user actions, each having its own handling "function") .
> Luckily my micro's version of BASIC included the feature of expressions
> evaluating to either 1 or 0 (pretty advanced for those days); the other
> micros had to do something more complicated.
> I'm sure these program listings had to be generated by someone working
> in a real environment with some tool that outputs micro-suitable
> BASIC code, in real life it would take forever to re-number a program
> and the programs were usually perfectly-numbered.[/color]

On a Commodore 64, that GOTO statement will cause an "undef'd
statement" error if the variable i has any value from 0 to 51. This is
because unlike your micro's BASIC, the Commodore 64 BASIC evaluates
true expressions to -1, and thus if i has some value from 0 to 51,
the above GOTO will attempt to jump to a negative line number. It
should read:

240 GOTO -250*(i=0) - 350*(i=1) - 380*(i=2) - ... - 3550*(i=51)

--
/-- Joona Palaste (palaste@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"I wish someone we knew would die so we could leave them flowers."
- A 6-year-old girl, upon seeing flowers in a cemetery

[Dik T. Winter]

Re: Interesting bug

In article <c68d1b$8f0$4@s unnews.cern.ch> Dan.Pop@cern.ch (Dan Pop) writes:[color=blue]
> The main purpose of many BASIC implementations was to make the best use
> of the *limited* resources of 8-bit micros.[/color]

That may have been the purpose of many later BASIC implementations , it
was not the purpose of the original BASIC. At that time the problem was
not limited resources on 8-bit micros, but limited resource on mainframes.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Holger Hasselbach]

Re: [OT] Commodore 64 BASIC v2, again (was: Interesting bug)

Chris Sonnack <Chris@Sonnack. com> wrote:[color=blue]
> Joona I Palaste wrote:
>[color=green]
> > ...Commodore 64...best graphics and sound capabilities on the market[/color]
>
> Used intelligent "peripheral s".
>[color=green]
> > The included BASIC did nothing whatsoever to support anything beyond
> > simple text output. You couldn't even change the background colour,
> > only the text colour.[/color]
>
> Are you sure about that? That doesn't match my memory.
>[color=green]
> > Why didn't the BASIC have in-built graphics and sound support?[/color]
>
> Wasn't there a SOUND() function and wasn't there Sprite support
> at the BASIC level?[/color]

There simply was no space for it in the ROM. The C64 used bank
switching for the memory mapping:

64K RAM
$0000-$7fff 32K
$8000-$9fff 8K - Expansion slot
$a000-$bfff 8K - System ROM (Basic interpreter) - Expansion slot
$c000-$cfff 4K
$d000-$dfff 4K - IO (2xCIA, SID, VIC, 1Kx4 static color RAM)
$e000-$ffff 8K - System ROM (I/O)

The switching was controlled by 3 of the 6 I/O-lines of the 6510 CPU.
The other 3 bits were used for the Datasette tape recorder. 2 of the
CIA's I/O-lines controlled which of the 4 16K-portions of the RAM was
used for text, graphics and sprite data; the VIC-registers controlled
the exact location inside this 16K portion. The space for basic
programs was from $0800-$9fff in the standard configuration (still an
awful lot in comparision to other home computers).

Inside the 16K ROM there was anything: Datasette control, serial I/O
for peripherals, the complete basic interpreter, etc. It was used up
to the last bit. Basic extensions were usually made in three ways: In
hardware by using the expansion slot and losing 8K of RAM; by copying
the basic ROM into the RAM and modifying it; or by modifying one of
the indirect jump pointers heavily used for I/O and interpretation,
repointing it to the own routines.

---snip---------[color=blue]
> What caused this? Why didn't the BASIC have in-built graphics and sound
> support? Many other competing machines did have it. Was Commodore in a
> rush to get the machine released so they did not have the time?[/color]
---snap---------

For a rush the complete thing was too bug-free. The strength of it was
that nearly *any* possibility given by the hardware was used in the
design, completely offering it to the competent programmer - not to
mention the internal "possibilit ies"/bugs of the I/O chips like the
frame sprites which were discovered quite lately. Not including
graphics and sound support into the Basic was IMHO a good idea - it
would have resulted in too much trade-offs.


Holger

[Richard Bos]

Re: Interesting bug

Kenneth Brody <kenbrody@spamc op.net> wrote:
[color=blue]
> Chris Torek wrote:
>[color=green]
> > It is also easy to read what *should* have been written, rather
> > than what was actually written. This is particular true if the
> > debugging is being done by the original programmer.[/color]
>
> Your brain knows what the code is supposed to be doing, and so you
> "see" code that should be behaving. It's not uncommon for someone
> to be debugging their own code for hours, only to call someone else
> over who spots the error in under 30 seconds. (I've been on both
> sides of that scenario.)[/color]

This is not just true in computing, btw. I work for a publisher, and in
that business it is a well-known trope that it is all but impossible to
correct your own newspaper articles.

Richard

[Dan Pop]

Re: Interesting bug

In <408822c2$0$778 5$7a628cd7@news .club-internet.fr> Richard Delorme <abulmo@nospam. fr> writes:
[color=blue]
>Dan Pop a écrit :[color=green]
>> In <40876989$0$778 0$7a628cd7@news .club-internet.fr> Richard Delorme <abulmo@nospam. fr> writes:
>>
>>[color=darkred]
>>>Gotophobia started in the sixties. Dijkstra's paper¹ was published in
>>>1968 and refered to older papers published in 1966. Fortran II and IV
>>>appeared respectively in 1958 and 1962 so their ignorance is forgivable,
>>>whereas C-64 Basic v2 (and many other Basics of this time) appeared when
>>>Dijkstra's paper had irremediably changed minds.[/color]
>>
>>
>> The main purpose of many BASIC implementations was to make the best use
>> of the *limited* resources of 8-bit micros. One of the most popular
>> micros of the early eighties had 8k of ROM and 1k of RAM in its standard
>> configuration. Creative minds managed amazing feats on this
>> configuration.[/color]
>
>The commodore-64 had 20K of ROM and 64K of RAM, so the memory resource
>was not that much limited.[/color]

Maybe, maybe not. The 20K of ROM were probably holding plenty of code
that had nothing to do with the BASIC interpreter itself. There is also
the execution speed issue: GOTO lineno is much faster to implement in an
*interpreter* than scanning for the matching ELSE or reverse scanning to
find the beginning of the loop. Sure, such things can be accelerated,
by giving up the pure interpreter model, but this requires even more
resources.

The PC implementations supporting structured programming features
were typically incremental compilers...

Then, there is the marketing issue. The vast majority of C64's were not
supposed to be programmed in BASIC (or any other language), they were
supposed to be used as game machines. Games implemented in assembly.
Due to that, certain, game-oriented hadware features of the machine were
not even properly supported by the BASIC interpreter. So, the vendor
correctly (from HIS point of view) decided not to invest too much
resources into a sophisticated BASIC implementation where a simple minded
one could serve equally well.

And another argument, which I'm sure was ignored by Commodore, was that
the kids learning programming on such machines (the few seeing in the C64
more than a game machine) were better served by a very simple minded BASIC
along the lines of the original Kemenyi and Kurtz design, than by
something more sophisticated and, therefore, more difficult to grasp by
elementary school kids. I'm sure the really talented kids, who found
the limitations of the builtin BASIC annoying, could find better
alternatives.
[color=blue][color=green]
>> By the time BASIC moved to relatively resource-rich PC's, it also acquired
>> structured programming features (and even dropped the line numbers that
>> were supposed to replace the need for a "sophistica ted" text editor).[/color]
>
>According to Thomas E. Kurtz (co-inventor of BASIC), line number
>suppression and structured programming appeared in their Dartmouth BASIC
>around 1975, in order to avoid "spaghetti code":
>http://www.truebasic.com/downloads/D2001.pdf
>Of course, in 1975, no resource-rich PC was available.[/color]

So, they probably used resource-rich mainframes, so I fail to see your
point.
[color=blue][color=green]
>> Then again, no matter how many minds Dijkstra's paper might have changed,
>> there is plenty of proof that well structured code can be written with
>> gotos and badly structured code without. The tool might help, but it
>> cannot replace the skill of the craftsman.[/color]
>
>Certainly, but it is quite clear to me that Dijkstra's paper changed
>Kurtz & Kemeny minds so that they made their Dartmouth BASIC a fully
>structured language, and that was several years before the release of
>C-64 BASIC v2.[/color]

So what? Are you suggesting that the resources of the C64 were comparable
to those of a mainframe from the mid-seventies?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Joona I Palaste]

[OT] Commodore 64, yet again (was: Interesting bug)

Dan Pop <Dan.Pop@cern.c h> scribbled the following:[color=blue]
> In <408822c2$0$778 5$7a628cd7@news .club-internet.fr> Richard Delorme <abulmo@nospam. fr> writes:[color=green]
>>Dan Pop a écrit :[color=darkred]
>>> In <40876989$0$778 0$7a628cd7@news .club-internet.fr> Richard Delorme <abulmo@nospam. fr> writes:
>>>>Gotophobi a started in the sixties. Dijkstra's paper¹ was published in
>>>>1968 and refered to older papers published in 1966. Fortran II and IV
>>>>appeared respectively in 1958 and 1962 so their ignorance is forgivable,
>>>>whereas C-64 Basic v2 (and many other Basics of this time) appeared when
>>>>Dijkstra' s paper had irremediably changed minds.
>>>
>>> The main purpose of many BASIC implementations was to make the best use
>>> of the *limited* resources of 8-bit micros. One of the most popular
>>> micros of the early eighties had 8k of ROM and 1k of RAM in its standard
>>> configuration. Creative minds managed amazing feats on this
>>> configuration.[/color]
>>
>>The commodore-64 had 20K of ROM and 64K of RAM, so the memory resource
>>was not that much limited.[/color][/color]
[color=blue]
> Maybe, maybe not. The 20K of ROM were probably holding plenty of code
> that had nothing to do with the BASIC interpreter itself. There is also
> the execution speed issue: GOTO lineno is much faster to implement in an
> *interpreter* than scanning for the matching ELSE or reverse scanning to
> find the beginning of the loop. Sure, such things can be accelerated,
> by giving up the pure interpreter model, but this requires even more
> resources.[/color]

A fully interpreted BASIC that scanned the actual source code as the
program progressed caused lots of interesting things. For example,
short line numbers actually performed better than long ones. Also
variables were faster than literal numbers. This was obvious, really,
as scanning a literal number required a decimal-to-binary conversion
but scanning a variable only required a table lookup. Thus several
magazines actually recommended replacing uses of 0 and 1 (which were
the most common numbers) with uses of variables that were assigned
these values and never reassigned.

The Commodore 64 actually used line numbers in a weird fashion. If we
ignore GOTO and GOSUB, line numbers were pretty much irrelevant.
Execution normally proceeded in the order the lines were in memory. If
you edited the memory directly, you could for example put the lines in
reverse order, or even give every line the same number, and the program
still ran like it originally did. (If it didn't use GOTO and GOSUB, of
course.)
[color=blue]
> The PC implementations supporting structured programming features
> were typically incremental compilers...[/color]
[color=blue]
> Then, there is the marketing issue. The vast majority of C64's were not
> supposed to be programmed in BASIC (or any other language), they were
> supposed to be used as game machines. Games implemented in assembly.
> Due to that, certain, game-oriented hadware features of the machine were
> not even properly supported by the BASIC interpreter. So, the vendor
> correctly (from HIS point of view) decided not to invest too much
> resources into a sophisticated BASIC implementation where a simple minded
> one could serve equally well.[/color]
[color=blue]
> And another argument, which I'm sure was ignored by Commodore, was that
> the kids learning programming on such machines (the few seeing in the C64
> more than a game machine) were better served by a very simple minded BASIC
> along the lines of the original Kemenyi and Kurtz design, than by
> something more sophisticated and, therefore, more difficult to grasp by
> elementary school kids. I'm sure the really talented kids, who found
> the limitations of the builtin BASIC annoying, could find better
> alternatives.[/color]

Well, now we don't have that problem. Kids these days won't know a
programming language from a hole in the ground. What they want their
computer to do is access the latest "hip" chat sites and play the
latest action-packed shoot-'em-ups. Nothing that would actually require
creative thinking - heck, thinking at all.

--
/-- Joona Palaste (palaste@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"I said 'play as you've never played before', not 'play as IF you've never
played before'!"
- Andy Capp

[Dan Pop]

Re: [OT] Commodore 64 BASIC v2, again (was: Interesting bug)

In <c6993h$j9a$1@o ravannahka.hels inki.fi> Joona I Palaste <palaste@cc.hel sinki.fi> writes:
[color=blue]
>What caused this? Why didn't the BASIC have in-built graphics and sound
>support? Many other competing machines did have it. Was Commodore in a
>rush to get the machine released so they did not have the time?[/color]

Most likely, Commodore didn't see BASIC programming as relevant to the
marketing of a machine, which was, obviously, hardware optimised to
be used as a game console. However, since it was sold as a home computer
(another marketing trick: parents objecting to buying a game console
could be convinced to buy a home computer ;-) it had to have a BASIC
interpreter.

Compare to the ZX-Spectrum, that was poorly equipped as a game console,
but whose BASIC supported all the hardware features of the machine,
including the high resolution graphics and the sound generator (an I/O
port bit directly turning on and off the membrane of a loudspeaker).
It came with a very nice BASIC manual documenting everything (including
low level hardware and software implementation details) and a cassette
with demo BASIC programs (making minimal use of machine code to improve
the program's user interface). It's obvious that Clive Sinclair seriously
considered the educational usage of the machine, apart from its
recreational one (the machine also came with a very short user guide,
explaining how to connect it to the TV and tape cassette recorder and how
to load "programs" from tape).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Dan Pop]

Re: Interesting bug

In <HwLLLC.Fsq@cwi .nl> "Dik T. Winter" <Dik.Winter@cwi .nl> writes:
[color=blue]
>In article <c68d1b$8f0$4@s unnews.cern.ch> Dan.Pop@cern.ch (Dan Pop) writes:[color=green]
> > The main purpose of many BASIC implementations was to make the best use
> > of the *limited* resources of 8-bit micros.[/color]
>
>That may have been the purpose of many later BASIC implementations ,[/color]

BASIC became really popular about 15 years after its original release.
Apparently, Bill Gates is responsible for that to a significant degree.
[color=blue]
>it
>was not the purpose of the original BASIC. At that time the problem was
>not limited resources on 8-bit micros, but limited resource on mainframes.[/color]

Or even machines lesser than mainframes, that could be used to serve
several terminals used for interactive BASIC programming. FOCAL was
an even more primitive-looking language, used for interactive programming
on the resource starved PDP-8 (4096 12-bit words).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Dik T. Winter]

Re: [OT] Commodore 64, yet again (was: Interesting bug)

In article <c6bmn1$t2m$2@o ravannahka.hels inki.fi> Joona I Palaste <palaste@cc.hel sinki.fi> writes:[color=blue]
> Dan Pop <Dan.Pop@cern.c h> scribbled the following:[/color]
....[color=blue][color=green][color=darkred]
> >>The commodore-64 had 20K of ROM and 64K of RAM, so the memory resource
> >>was not that much limited.[/color][/color]
>[color=green]
> > Maybe, maybe not. The 20K of ROM were probably holding plenty of code
> > that had nothing to do with the BASIC interpreter itself. There is also
> > the execution speed issue: GOTO lineno is much faster to implement in an
> > *interpreter* than scanning for the matching ELSE or reverse scanning to
> > find the beginning of the loop. Sure, such things can be accelerated,
> > by giving up the pure interpreter model, but this requires even more
> > resources.[/color]
>
> A fully interpreted BASIC that scanned the actual source code as the
> program progressed caused lots of interesting things.[/color]

There is actually such a beast in the obfuscated c contest archives. It
is a C program of (I think) less than 2000 bytes.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Dik T. Winter]

Re: Interesting bug

In article <c6bpgp$28k$17@ sunnews.cern.ch > Dan.Pop@cern.ch (Dan Pop) writes:[color=blue]
> In <HwLLLC.Fsq@cwi .nl> "Dik T. Winter" <Dik.Winter@cwi .nl> writes:[/color]
....[color=blue][color=green]
> >it
> >was not the purpose of the original BASIC. At that time the problem was
> >not limited resources on 8-bit micros, but limited resource on mainframes.[/color]
>
> Or even machines lesser than mainframes, that could be used to serve
> several terminals used for interactive BASIC programming. FOCAL was
> an even more primitive-looking language, used for interactive programming
> on the resource starved PDP-8 (4096 12-bit words).[/color]

Mainframes also were pretty resource starved. The first mainframe I used
had 32768 27-bit words, of which only one half could be used for code.
And that was the major mainframe serving two universities and the research
centre I worked at (and am still working at). Later this was changed to
a mainframe with 32768 60-bit words that could easily handle close to 100
interactive users, all doing Fortran, Algol 60, Algol 68 and Pascal
compilations and running editors and programs. But of course, your user
space was limited to 16384 words. And, eh, *no* virtual memory.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Allin Cottrell]

Re: [OT] Commodore 64, yet again

Joona I Palaste wrote:
[color=blue][color=green]
>>And another argument, which I'm sure was ignored by Commodore, was that
>>the kids learning programming on such machines (the few seeing in the C64
>>more than a game machine) were better served by a very simple minded BASIC
>>along the lines of the original Kemenyi and Kurtz design, than by
>>something more sophisticated.. .[/color]
>
> Well, now we don't have that problem. Kids these days won't know a
> programming language from a hole in the ground. What they want their
> computer to do is access the latest "hip" chat sites and play the
> latest action-packed shoot-'em-ups. Nothing that would actually require
> creative thinking - heck, thinking at all.[/color]

As a teacher of undergraduates, I'm sorry to say that I can confirm
that. In the DOS days, I had a scattering of students who really
knew about computers. In the XP days, I have none.

Allin Cottrell

[Richard Delorme]

Re: Interesting bug

Dan Pop a écrit :[color=blue]
> In <408822c2$0$778 5$7a628cd7@news .club-internet.fr> Richard Delorme <abulmo@nospam. fr> writes:
>[color=green]
>>The commodore-64 had 20K of ROM and 64K of RAM, so the memory resource
>>was not that much limited.[/color]
>
> Maybe, maybe not. The 20K of ROM were probably holding plenty of code
> that had nothing to do with the BASIC interpreter itself. There is also
> the execution speed issue: GOTO lineno is much faster to implement in an
> *interpreter* than scanning for the matching ELSE or reverse scanning to
> find the beginning of the loop. Sure, such things can be accelerated,
> by giving up the pure interpreter model, but this requires even more
> resources.[/color]

I don't think that technical considerations were really important.

[color=blue]
> The PC implementations supporting structured programming features
> were typically incremental compilers...
>
> Then, there is the marketing issue. The vast majority of C64's were not
> supposed to be programmed in BASIC (or any other language), they were
> supposed to be used as game machines. Games implemented in assembly.
> Due to that, certain, game-oriented hadware features of the machine were
> not even properly supported by the BASIC interpreter. So, the vendor
> correctly (from HIS point of view) decided not to invest too much
> resources into a sophisticated BASIC implementation where a simple minded
> one could serve equally well.[/color]

That's the main point. The lake of competition, the availability of a
simple and inexpensive BASIC made by Microsoft for their platforms, and
other marketing issues can well explain the choices made by Commodore.
So, whatever if standardized specifications for a better BASIC existed
and the machine was powerful enough to handle them, they did not bother
implementing it.
[color=blue]
> I'm sure the really talented kids, who found
> the limitations of the builtin BASIC annoying, could find better
> alternatives.[/color]

Yes, here is an impressively long list of available languages for
commodore-64:

http://www.npsnet.com/danf/cbm/languages.html

The availability of structured languages (BASIC included) also shows
that the commodore resources were relatively sufficient to handle them.
[color=blue][color=green]
>>According to Thomas E. Kurtz (co-inventor of BASIC), line number
>>suppression and structured programming appeared in their Dartmouth BASIC
>>around 1975, in order to avoid "spaghetti code":
>>http://www.truebasic.com/downloads/D2001.pdf
>>Of course, in 1975, no resource-rich PC was available.[/color]
>
> So, they probably used resource-rich mainframes, so I fail to see your
> point.[/color]

A GE-635 (1966-1975) followed by an Honeywell 66/40 (in 1976). Their
resources were quite comparable to a commodore-64, and were shared among
many users (up to 200).
[color=blue][color=green][color=darkred]
>>>Then again, no matter how many minds Dijkstra's paper might have changed,
>>>there is plenty of proof that well structured code can be written with
>>>gotos and badly structured code without. The tool might help, but it
>>>cannot replace the skill of the craftsman.[/color]
>>
>>Certainly, but it is quite clear to me that Dijkstra's paper changed
>>Kurtz & Kemeny minds so that they made their Dartmouth BASIC a fully
>>structured language, and that was several years before the release of
>>C-64 BASIC v2.[/color]
>
> So what? Are you suggesting that the resources of the C64 were comparable
> to those of a mainframe from the mid-seventies?[/color]

Probably, but that's not the problem. I just want to show that BASIC
could have been a well-structured language on the family and personal
computer of the early 1980s.
I think Kurtz and Kemeny shared a similar opinion when they decided in
1983 to create a company to make "available to everyone a high-quality
BASIC", as demonstrated in this Kurtz' interview:

(from http://www.truebasic.com/downloads/D2006.pdf)
Q: How did Dartmouth BASIC become True BASIC?
A: Teaching at Dartmouth, John Kemeny and I were shielded from some of
the worst implementations of BASIC. For example, we stopped using line
numbers in 1975, just as personal computers were being invented.
Dartmouth BASIC had continued to evolve into a more and more
sophisticated language that was a joy to use. However, in 1983, three
Dartmouth alums challenged us to look at the versions of BASIC that were
out there, all different on the different computers. We were appalled at
how terrible these crude `street' versions were, and what high school
and college students and teachers had to contend with. We knew that
writing papers or delivering talks would have little effect so we
accepted the challenge of forming an independent commercial software
publishing company and making available to everyone a high-quality
BASIC, one that reflected our years of teaching experience.

--
Richard

[Rob Thorpe]

Re: [OT] Commodore 64 BASIC v2, again (was: Interesting bug)

Dan.Pop@cern.ch (Dan Pop) wrote in message news:<c6booe$28 k$16@sunnews.ce rn.ch>...[color=blue]
> In <c6993h$j9a$1@o ravannahka.hels inki.fi> Joona I Palaste <palaste@cc.hel sinki.fi> writes:
>[color=green]
> >What caused this? Why didn't the BASIC have in-built graphics and sound
> >support? Many other competing machines did have it. Was Commodore in a
> >rush to get the machine released so they did not have the time?[/color]
>
> Most likely, Commodore didn't see BASIC programming as relevant to the
> marketing of a machine, which was, obviously, hardware optimised to
> be used as a game console. However, since it was sold as a home computer
> (another marketing trick: parents objecting to buying a game console
> could be convinced to buy a home computer ;-) it had to have a BASIC
> interpreter.
>
> Compare to the ZX-Spectrum, that was poorly equipped as a game console,
> but whose BASIC supported all the hardware features of the machine,
> including the high resolution graphics and the sound generator (an I/O
> port bit directly turning on and off the membrane of a loudspeaker).
> It came with a very nice BASIC manual documenting everything (including
> low level hardware and software implementation details) and a cassette
> with demo BASIC programs (making minimal use of machine code to improve
> the program's user interface). It's obvious that Clive Sinclair seriously
> considered the educational usage of the machine, apart from its
> recreational one (the machine also came with a very short user guide,
> explaining how to connect it to the TV and tape cassette recorder and how
> to load "programs" from tape).
>
> Dan[/color]


I grew up with an Amstrad 464, a 64K Z80 based thing no-one really
remembers.

Like the Commodore 64 it was more for games, but the BASIC interpreter
was still good, although slow. It also supported some things that
were rather like threads, strangely enough. The BASIC manual was a
work of genius, especially the graphical programs.

[Randy Howard]

Re: Interesting bug

In article <c68d1b$8f0$4@s unnews.cern.ch> , Dan.Pop@cern.ch says...[color=blue]
> Then again, no matter how many minds Dijkstra's paper might have changed,
> there is plenty of proof that well structured code can be written with
> gotos and badly structured code without. The tool might help, but it
> cannot replace the skill of the craftsman.[/color]

I think that if his paper had said something like "harmful for newbies" in
the title, it might have been far more appropriate overall.

--
Randy Howard
2reply remove FOOBAR

[Randy Howard]

Re: [OT] Commodore 64, yet again

In article <c6cg4v$26h4$1@ f1n1.spenet.wfu .edu>, cottrell@wfu.ed u says...[color=blue]
> As a teacher of undergraduates, I'm sorry to say that I can confirm
> that. In the DOS days, I had a scattering of students who really
> knew about computers. In the XP days, I have none.[/color]

Hmm, I have a 10-year old child currently learning to program in C
on an XP system. We'll be working on cross-platform portability to
Linux and Mac systems (the latter primarily for byte-order discussions)
shortly.

--
Randy Howard
2reply remove FOOBAR