Debunking Sinclair BASIC v C64 BASIC
Commodore 64 BASIC (Commodore BASIC V2) v Sinclair Spectrum BASIC While Commodore 64 BASIC had only 71 keywords (commands, functions, and statements), Sinclair Spectrum BASIC had 86 keywords.
Interestingly, whilst the author admits that he doesn’t “understand all these commands”, he still fails to notice that the list he’s posted doesn’t include some of the more elementary string handling commands like LEFT$, RIGHT$ or MID$ so, whilst the functionality is there in the Spectrum and is merely handled differently, his mostly guess-based “comparison” of the two should’ve noted those missing commands and rang alarm bells… for some reason it didn’t and that’s presumably because noting this wouldn’t have backed up the author’s anti-Commodore agenda.
It was virtually impossible to play more than one note at a time using Commodore 64 BASIC. Even my attempts to modify a program which included a machine code routine to play 3 note polyphonic classical music failed miserably.
This mistake on the author’s part has been thoroughly debunked by the significant number of multi-channel BASIC tunes in the High Voltage SID Collection. It obviously isn’t “virtually impossible” as claimed and the issue isn’t the C64 or even BASIC V2 in this case, it’s down to the author’s limitations as a programmer.
The Commodore 64 just had the PRINT TAB x command, which only allowed the x coordinate to be specified. Positioning a character vertically required the user to create a string of cursor up or down control characters, then use the command LEFT$, MID$, or RIGHT$ to extract some of these to position the character vertically!
Ah, the string handling commands have appeared! Your correspondent was beginning to wonder where they’d got to whilst reading through the Spectrum commands.
As an alternative to this system, the C64 could simply employ it’s hardware sprites which can be manipulated at least as fast as printing characters to the screen, move with pixel precision regardless of what they’re overlapping, don’t require constant erasing before movement, have independent colouring and come with hardware-based sprite-to-sprite and sprite-to-background collision detection.
The author would no doubt have a fit at the mere mention of using POKEs to drive hardware sprites, but that would be highly hypocritical since he’s currently something of an Atari BASIC evangelist and the same is true there.