Debunking C64 magazine exposé!
Actually there’s nothing to debunk really because it’s mostly just opinion and paraphrasing a small part of Input issue 3. I doubt there’s a single C64 programmer who has ever denied the fact that the C64’s BASIC is lacking in commands for graphics or sound, but the majority of us just got on with finding ways to handle those things ourselves, usually by learning machine code. Other BASICs lack functionality too but aren’t singled out in the same way by the author; there are no commands present in Atari BASIC to use it’s hardware sprites or build display lists for example so they’re all done with POKE commands but, despite the author being aware of this omission, it somehow doesn’t end up on the receiving end of his ire.
If the only exposure the average beginner has to programming is the C64’s BASIC, the important POKEs rapidly become second nature anyway and setting the border to black on the C64 with POKE 53280,0 isn’t significantly more arcane than something like BORDER 0 on the Spectrum for example, in both cases the meaning of the command and the terminology “border” need to be explained along with talking about what the zero actually means.
And when (or perhaps more accurately if since it didn’t always happen for one reason or another) the time comes to transition to machine code it’s far easier to translate POKE commands than bespoke ones, POKE 53280,0 on the C64 becomes LDA #0 / STA 53280 (note the same numbers are present in both commands) whilst BORDER 0 on the Spectrum changes into LD A,0 / OUT (254),A (in this case only the zero survives) and the Atari 8-bit’s SETCOLOR 2,14,2 translates as LDA #228 / STA 710 or STA 53272 if writing directly to the register (and none of the original numbers are present in either case) .
This isn’t a major leap of course, but at the point it needs to be made the programmer is already having to get their head around assembly language and this is a distraction that BASIC V2 users simply didn’t have.