Debunking Commodore 64 warnings
Recently, as part of my extensive research, I’ve been searching online archives, as well as eBay, to find some magazines with reviews of the Commodore 64 which gave potential computer buyers, who were deciding which computer to buy, some warning about the Commodore 64, unlike the review I read in “The A-Z of Personal Computers”, which listed full reviews of lots of computers in a single volume, but no other magazine seemed to do this. I’ll be dealing with that magazine in a separate post. I think I’ve found THREE magazines which gave people some warning about the shortcomings of the Commodore 64.
This “extensive research” (which is basically just cherry picking things from thirty year old magazines whilst ignoring others and without really understanding them properly or even confirming that what was printed is actually the case) indirectly demonstrates something; since the majority of magazines (or more accurately the majority of the small sample the author looked at) apparently don’t have a “warning” we can assume that the people behind these publications didn’t feel a warning was necessary.
Apart from this, The Transactor also had a news item later on, saying that less than a year after being released, the Commodore 64 was already being fitted with a THIRD version of its Kernal ROM to fix bugs in the first two versions! Of course, some early software wouldn’t work with the new ROMs. Furthermore, the monitor port was about to be changed from 5 pins to 8 pins! So much for the “Commodore 64” being the World’s best selling “single model” of computer produced from 1982 to 1994!! As it was already incompatible with earlier production versions, Commodore may as well have upgraded its BASIC ROM as well!!!!
Again we see that the author really doesn’t understand computers enough to see why this is garbage. The later models of C64 weren’t “already incompatible” because modifying the Kernel makes absolutely no difference to any program written to use it correctly. The jump table remains a constant between revisions so $FFD2 will always accept the same input and produce the same output even if the routine called has moved from one end of the ROM space to the other. Any compatibility issues will be with software that calls Kernel routines directly in exactly the way that all of the C64’s first and third party documentation tell programmers not to. If the author were actually anywhere near right about it being “already incompatible” he’d be able to find more than mere anecdotal evidence of one program not working out of the hundreds of thousands of programs for the C64.
Altering BASIC is a completely different proposition of course because the levels of incompatibility that are introduced even by small changes tend to prove more tangible and indeed frustrating for programmers; had the author instead purchased one of the machines where the BASIC interpreter was for one reason or another modified during its lifespan he would no doubt be grumbling incessantly about how even the small programs he wrote failed to work on a friend’s computer or at the local computer club.
 Your correspondent is aware of another change which affects a handful of programs but the issue once more arises from programmers not sticking to the guidelines and despite his “extensive research” the author has utterly failed to find this problem to whine pointlessly about it.