About Introduction To BASIC – part 5

Debunking An Introduction To BASIC: Tramiel torture – part 5

This is a response to the author’s fifth post on the Introduction To BASIC series and it’s all starting to take on that rather shrill tone of someone desperately looking for an excuse for their own failure to learn something, doesn’t it dear reader?

In his latest “debunk”, TMR has claimed that he hasn’t even looked at the program listing of the C64 BASIC V2 game “Wasp Shooter”, so this means that he can’t or won’t comment on it. It was the ONLY example of how to write an arcade game in this whole course, even though it was limited to character graphics.

We are discussing a general purpose programming book; it isn’t meant to be all about writing arcade games so it has just one example, but that is more than enough with a little creativity. It really wouldn’t take much time or effort to change the example’s graphics or tweak some specific behaviours to make a new game out of the existing one[1] and more adventurous programmers have a base to start from as well.

I think this is like a language course which only deals with one social situation, then tells you to work out for yourself how to deal with other social situations from that one conversation!

The book is teaching BASIC. In that context, talking about arcade games is just one social situation with others being covered elsewhere in the book.

Before I go any further, I should point out that I started learning Commodore BASIC V2 at about the same time as starting to learn BBC BASIC, so this helped me realise that something was wrong. If I’d lived in the USA, read “The Compute! Gazette”, “The Transactor” and avoided reading about other computers, then I might never have found out there was anything wrong with Commodore BASIC V2 on the C64. I think this is what may have happened to lots of C64 owners in the USA.

And the big question is why would it matter even if this were backed up with some kind of evidence rather than just being an unqualified guess on the author’s part? If your aim is to program the C64 you’ve just purchased, it doesn’t matter at all if you are or aren’t aware of the differences between its BASIC and that of the Atari 8-bit or Apple II in the USA.

But the fact that huge numbers of people managed to learn BASIC either when exposed to other languages or in a vacuum during that process says far more about what BASIC V2 is like to learn than any of the author’s bile-laden rubbish.

Unit 26 has a sprite demo program which is designed to make the reader think that using sprites on the C64 is easy, but reading this program reveals that it contains about 29 POKE commands!

Having to use POKEs wasn’t off-putting to all of those amateur programmers on the C64, it just takes a bit of work to become familiar with them and the author was, essentially, just being lazy.

Of course Atari BASIC also requires POKE commands to use sprites, but it can redefine characters with just a few POKE commands, use POSITION x,y:PRINT to position them and, LOCATE x,y,c to check which characters are where.

Hardware sprites are a very specific feature and using redefined characters and PRINT commands does not replicate what they can do. Bringing up this half-baked “alternative” doesn’t negate the fact that the Atari 8-bit’s BASIC doesn’t have commands for one of its more powerful features, needs POKEs and is actually harder to work with than the C64 in that respect.

Other computers can do similar things with their user defined graphics or UDGs, while I don’t think MSX BASIC or Commodore BASIC V7 require any POKE commands at all to use their sprites!

The MSX and C128 weren’t around in 1982 when the C64 was released or 1983 when Introduction To BASIC – Part 2 was written so it shouldn’t be surprising that they weren’t an influence on either.

Unit 26 is followed by an “Afterword”, congratulating the reader for making it this far and making the unbelievably false, TOTALLY misleading statement “the version of BASIC you’ll find on different machines is generally a little different and usually inferior to Commodore BASIC”!! Of course, no mention is made of which different computers have a BASIC “inferior” to Commodore BASIC

The statement isn’t misleading when the context that the author removed is restored – here’s a bit more of what Introduction To BASIC – Part 2 says:

BASIC is in many respects an excellent language with which to learn programming, but there is one serious drawback which must be mentioned: it is not standardised. This means that the version of BASIC yo’u’li find on different machines is generally a little different and usually inferior to Commodore BASIC. Some BASICs give you a greatly restricted selection of variable names, and many don’t allow you to use arrays of strings. The rules about putting several commands on one line are by no means universal, and the arrangements inside PRINT commands can also vary between machines.

In context the statement is neither “unbelievably false” or “TOTALLY misleading” and the book’s writer is only guilty of some hyperbole and a little over-generalising since he is clearly talking about the core BASIC language rather than those extra commands grafted onto some dialects that the author fixates on. Learning BASIC should be about that core BASIC functionality.

By removing the context in that way the author is misrepresenting what the book says and, essentially, lying to his readers once more.

Finally, in the APPENDIX of all places, there are some programs that actually play music! The tunes are a monophonic version of “In Dublin’s Fair City”, and a three note polyphonic version of a tune called “The Arrival of The Queen of Sheba”, by classical composer Handel.

So that’s three note polyphonic music from BASIC despite the author’s previous claims that it was “impossible”? The author presumably read this book at the time[3] so what he’s written before suddenly become even more questionable than they were already.

The SID synthesiser chip was the main reason I bought the Commodore 64. I tried to adapt this program to play some three channel polyphonic music of my own, but I failed miserably, due to the deliberately confusing music notation and Machine Code. After this, I was stuck programming only monophonic music on my C64!

In other words, the author didn’t look into other options; he failed and just gave up. Again, for someone who has previously claimed to be “artistic and creative” he really doesn’t appear to be either when even slightly outside of his comfort zone. Having to use POKEs, assembly language or even machine code[3] certainly didn’t stop others from producing amazing music on the C64 so we can only place the blame for the author’s abject failure at his own feet.

[1] Of course the author will probably try to say that, because your correspondent has previously “claimed that he hasn’t even looked at the program listing”, he can’t make these assumptions but any fully functioning game can be “re-skinned” with relative ease; your correspondent did it as a child and has seen it done countless times since with both BASIC and machine code games on a number of platforms. All it takes at a simple level is a bit of programming knowledge, some creativity and a bit of persistence.

[2] This is an assumption made from what he’s written, so your correspondent apologises if the author is instead just writing about the book from a present day stance rather than sticking to his topic of programming the C64 in the UK between 1984 and 1985.

[3] There are examples out there where would-be C64 musicians have basically taken the music routine from a game or demo and modified it with just a machine code monitor to play their own music. Creative, artistic people will usually find a way to do something they want rather than merely giving up like the author did.

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