Opposites attract

Debunking The Opposite to the Commodore 64

That’s right the author’s back and it’s not a repeat… well okay, it is a repeat because the same old “arguments” have come out once again but we weren’t expecting anything else from him, were we dear reader? Certainly we didn’t expect paragraphs. So, apparently he’s been away for several months getting 8-bit computers to draw circles in BASIC, which says far more about the author’s “abilities” than your correspondent can without laughing…

The whole point of this blog is computer literacy versus computer illiteracy. A prime example of computer illiteracy is Commodore 64 BASIC V2, which, because that computer was released in 1982, was designed to put people off learning to program, leave it to the “experts” and just play games and use other software instead.

Computer literacy is defined at Dictionary.com as “familiarity with computers and how they work, especially a nontechnical understanding of microcomputers and of the role computers play in modern society” (your correspondent’s emphasis) so discussing BASIC, hardware specifications, resolutions, colour depth or anything else along those lines is outside the declared topic of his blog, invalidating pretty much anything left that wasn’t already invalidated by the author’s lack of knowledge (there are further definitions, none of which are about programming).

So let’s look at the C64 in a computer literacy context; the C64 has, according to the Guinness Book of World Records, sold more units than any other 8-bit home computer so it would be absolutely impossible to claim that the C64 wasn’t a huge, positive impact on computer literacy; millions of people got their first taste of microcomputing from the machine, be that playing games (which is more on topic when discussing computer literacy than BASIC), word processing, composing music, building spreadsheets, getting online in some form or managing a database.

But wandering back over to the off topic (at least for the author’s blog) it’s telling that a machine the author feels was “designed to put people off learning to program” has a truly massive archive of software, much of which was developed by the kind of amateur programmer the author spectacularly failed to become. The games library alone is tens of thousands of titles and the demo scene, which originated on the Apple 2 and C64 years before some of the other machines saw their first release, has produced countless demos, utilities and games over the decades and is still going strong.

I was very surprised to read on the blog http://www.c64crapdebunk.wordpress.com criticism of various computers just because they used hardware which was a few years old, 5 years old, or even older. I don’t think I’ve ever objected on this blog to the age of hardware components.

The C64’s BASIC is a ROM chip, a hardware component in the same way the processor or VIC-II are. But to restore context, the point being made in that previous post that the author missed is that, if the C64’s BASIC being old is an issue for the author, then having a video processor that’s even older still should be an issue for the author too, unless some pathetic double standard is in play on his side of things. Your correspondent doesn’t believe it makes the slightest difference how old either the components in the MSX series or the C64’s BASIC are and feels obliged to point out that he didn’t use the word “obsolete” in his post either, that is just a deliberate misinterpretation by the author.

Another post which was totally irrelevant was a graphics screen of a tortoise or a turtle done on a Commodore 64! I assume this was done using a graphics editor, not actually programmed by calculating which one of 16 colours to make each pixel on the screen. I assume it was in the low resolution 160×200 display mode, so that’s 32,000 pixels to POKE!

As before, the author has “forgotten” to quote the context; the tortoise picture is from a post filed as meta discussion that was discussing more generally how difficult the C64 is or more accurately isn’t program; the picture was offered up as part of the output from the previous weekend’s Datastorm scene party. How the picture was created is of course completely irrelevant in that context.

It was also cute, which is good.

In a similar vein, the C64 saw over twenty new releases at the Nordlicht party in Germany last weekend so here’s a picture from that event as well; don’t forget dear reader that the people making the demos, games, pictures and music released at these events are all doing so on a computer the author feels was “designed to put people off learning to program” – it doesn’t seem to be frightening them off, does it?

“Night Walk” by Veto of Arsenic and Oxyron

I was also conned by a certain magazine which was a buyers’ guide to computers available at the time. It may be best not to mention its name. I hope the Editor has suffered a painful death since then for all the stress she caused me.

Ignoring the rest of the self-obsessed rubbish the author wrote around this, your correspondent just wants to pause in total seriousness for a moment to point out how abhorrent he feels the comment in the second sentence to be – the author should be completely bloody ashamed of himself.

At least the Atari ST was disk based, and ST BASIC wasn’t on ROM, only loaded from disk. GFA BASIC on disk could use a runtime module, enabling the programs to run on any Atari ST without the need for the owner to have a copy of the BASIC in question, unlike a cassette based Commodore 64.

Your correspondent has recently been informed that there is at least one compiler which accepts Simon’s BASIC programs (and if the menu on said compiler is correct, it handles other dialects too) to produce an output file which will run on any C64 without the cartridge present; the compiler itself needs to run from disk of course because nobody sensible would expect otherwise, but the final compiled program will happily work from cassette.

There was even a section describing how to use something called the 64MON cartridge, which was a Machine Code Monitor. This was for editing or programming in Machine Code NOT Assembly Language! I have no idea why anyone would want to do this!

The reason that the author has no idea is because he isn’t an assembly language programmer; machine code monitors are used for debugging assembled programs so some assemblers shipped with a built in monitor and several cartridge- and disk-based options exist. Most emulators come with a monitor style debugger of some kind.

Most of the people who bought Sinclair Spectrums and MSX computers had probably never owned a computer before, so why would they care if its hardware had been used in older computers or not?

And the exact same logic applies to the C64’s BASIC; BASIC dialects are all as arcane as each other until they’re learnt regardless of if they have bespoke commands or use POKE and PEEK. Machine-specific commands like SETCOLOR mean absolutely nothing to a novice programmer until they’ve learnt the command itself and which numbers do what.

So to sum up, it’s not the hardware you’ve got, but the attitude behind a certain computer and the programming languages available for it that decides what you can do with it!

This just reads like marketing guff… on any 8-bit computer the hardware dictates what BASIC can or can’t offer and what speed the programs are executed at. The best way to get the most out of an 8-bit is never going to be a high level language because even the best interpreters are still slow and compilers for these machines don’t produce code as optimal as an assembly language programmer can.

This entry was posted in Debunking and tagged , , , , , . Bookmark the permalink.