Before continuing with this series, I need to remind you all of the following very important and influential facts. I was told by Commodore by their C64 startup screen, their BASIC course I’m writing about here, as well as the BBC computer literacy campaign that the way to learn how to program computers was in BASIC. Machine Code definitely wasn’t a language for beginners and that you were supposed to learn how to do things in BASIC before learning how to do them in Machine Code.
How the C64’s power up screen “told” the author that assembly language wasn’t a language for beginners is very questionable and he should probably seek help if things like that are actually talking to him; whilst assembly language might not have been a good starting point for most beginners, some people did indeed start with it regardless of the author’s evidence-free beliefs.
The author has once more confused learning BASIC generally with learning what he wanted to do with BASIC specifically and these aren’t the same thing at all; the remainder of the post is merely petulant whining so, whilst we’ll meander through and laugh at a few examples of the author’s broken logic or childlike bias, most of it is just the same old pointless bile we’ve come to expect from him which simply isn’t worth the effort of even quoting.
At this stage, lucky Sinclair Spectrum users would have learnt the commands BORDER n and PAPER n:CLS, lucky Atari users would have learnt about SETCOLOR n,n,n while lucky Dragon and Tandy users would have learnt CLSn, and lucky MSX users would have learnt COLOR n,n,n.
The C64’s way of doing things might seem arcane in hindsight especially to the hard of thinking like the author, but we’re talking about computer programming here and, until someone has sat down and actually learnt what SETCOLOR or BORDER are and how they work, these commands will be just as arcane as a POKE.
Unit 7 is about IF…THEN and STOP. Of course, I was keen to get through all this, which I thought would lead to me composing some music, then using it in my own programs.
In other words the author wasn’t paying the book the attention required to actually learn from it. That lays the blame for his failure squarely at his own feet.
Unit 9 starts by showing people how to use the C64 quotes mode with all the tedium of embedding control codes for coloured text into PRINT statements, while Sinclair Spectrum users could just use PEN n, Atari users could use COLOR n, and MSX users could also use COLOR n.
The embedded control codes allow for mid line or indeed mid word colour changes, something the longer and, again, equally arcane to the beginner commands on other platforms needed multiple PRINT commands to achieve, making the C64 approach the more optimal and in some cases easier for the program to read and debug. The author’s claim that “Sinclair Spectrum users could just use PEN n“ is wrong of course, because the Spectrum BASIC command would be INK which also neatly demonstrates how these commands are just as difficult to remember even for those who aren’t a complete novice. Your correspondent thanks the author for weakening his own argument in this way.
Unit 12 tells us more about FOR…NEXT loops, as well as keeping scores of sporting events and working out the prices of buying lots of postage stamps of different values in bulk. By this stage, I think the suspense of when I was going to be able to program any hires graphics or sound was killing me!
Again, the author is not paying proper attention to what the book is teaching and failing to learn because of it.
Of course, music like this has been created on the C64, but I doubt if it was in Commodore BASIC V2, and I don’t know how this was done.
There are quite a few examples of BASIC-driven music on the C64 which the author could look through and, ultimately, it’s just a matter of pushing data through the sound registers. The most common “trick” seems to be using variables for those five digit numbers, a technique the author stoically tries to ignore because it negates another of his “arguments”.
Returning to the subject of making music, you can hear a Depeche Mode compilation created with the C64, but probably not in Commodore BASIC V2, on http://www.youtube.com/watch?v=SoAYge8Jzd4
The author has repeatedly tried to pull the wool over his readers’ eyes with this straw man argument; yes, the music in that video is played by assembly language routines rather than BASIC but most of those tunes are using musical features that aren’t available to any other BASIC as well.
Unit 15 claims to consist of routines which could be useful in games, the very thing most would be Commodore 64 programmers were probably interested in producing to make some money!
To loosely paraphrase Jessie J, it wasn’t about the money for a lot of the amateur programmers on the C64; there were at the very least thousands of programmers who gave away their self-written demonstrations, utilities and games for free by distributing them through local and national computer clubs, via the worldwide postal-based network that existed between users and C64-specific nascent online services Qlink or Compunet.
And we have to note dear reader that, for games development, by the author’s self-imposed 1984-1985 window in the UK, the idea of selling BASIC games commercially was pretty much dead in the water. People had already realised as far back as the Apple II, PET and Atari 8-bit in the 1970s that BASIC wasn’t practical for the majority of game genres so anybody who took to programming with plans to make games were either starting out by learning BASIC with the intention of moving over to assembly language straight away or in the minority who simply skipped BASIC altogether.
 “Routines” plural because over a dozen musicians are credited for the demo 101 – A Tribute To Depeche Mode which means that several different music drivers were employed. We should also note that none of these people started out as commercial developers (some went on to commercial work later) so the author is weakening some of his other “points” by acknowledging this demo and the backroom developers responsible for it.