Based on my research, it seems that Commodore BASIC V2 on the C64 is such a load of crap that it’s probably easier to learn 6502 Assembly Language! Of course, the problem with that may be trying to think like a computer, as well as yet again trying to remember lots of numbers representing memory locations. At least these are in hexadecimal, though, which may make it easier.
So the author feels that remembering a four digit alphanumeric value might magically be easier than remembering a five digit numeric one… but hasn’t managed to do either himself so we can safely ignore his uninformed opinion dear reader.
Based on things I’ve heard about programming in 6502 Assembly Language on Atari 8 bit computers, people usually use a file with a long list of EQU equate directives, to replace the numbers with meaningful official Atari names for the various routines. I haven’t seen this approach on the C64 yet, so I don’t know if it’s used at all.
Some people on both the Atari 8-bit and C64 use variations on this technique, but there are probably just as many who don’t. And your correspondent would argue that the list of register names on the Atari 8-bit aren’t as “meaningful” as the author claims, labels like ATACHR or PRIOR mean nothing if you haven’t previously learnt what the register behind it does (and PRIOR as a name still doesn’t entirely make sense afterwards).
Of course, the Atari range of computers could be programmed in Atari BASIC, although users required POKEs and PEEKs to use the Player Missile Graphics or sprites.
And, hypocritically, this is somehow still not a problem for the author despite being no different to how it’s done on the C64.
I think that a lot of the problems with the Commodore 64 are due to misdirection, meaning a similar technique to that used by magicians so that people don’t notice how their tricks work. I was told by the BBC with their big computer literacy campaign on TV as well as books, access to BBC Micro computers, etc that all computers used the language BASIC and that you had to learn that language.
The BBC computer literacy project specifically focused on BBC BASIC and no other 8-bit was directly compatible with it, so the author opens himself to even more ridicule by trying to single out the C64. And who, exactly, is responsible for the claimed “misdirection” exactly?
In spite of this, I recently heard that Apple ][ programs were often or even mostly written in Applesoft BASIC.
Your correspondent has previously done some digging around Apple II disk images to understand the process behind making an auto-booting program for the machine and, whilst some of the boot loaders are BASIC at least on the pirated versions available to download, the majority of those games were machine code. That might be wrong of course, but unless the author can produce verifiable statistics…
The RGBi signal was output by a new additional video chip in the C128 called the VDC, although the Commodore 128 also included the VIC-II chip. Unfortunately, Commodore BASIC V7 had no commands to support the VDC chip, then Walrusoft brought out an improved BASIC called BASIC 8 to make use of the VDC!
Of course it wasn’t possible to save a BASIC 8 program out and give it to a friend with a C128 who didn’t have the BASIC 8 package… this has previously been a massive issue for the author when talking about the C64, so your correspondent is “surprised” that he failed to mention it in relation to the C128 – anyone would think he has some bias!
Commodore also brought out a mouse for the C128, which looked identical to the original Amiga mouse widely called a “tank mouse”.
The 1351 mouse was also compatible with the C64 so isn’t specific to the C128.
The 128K RAM used a technique called “bank switching”, also used by Amstrad and some others, where because only a total of 64K RAM could be seen by the 8 bit 8502 CPU at any one time, the 128 was divided into banks of RAM which were only seen when they needed to be. I’ve read that there were only 2 banks of 64K, but several different memory configurations. The maximum RAM on the C128 could have been 512K or even 1Mb!
The Commodore-produced C64 RAM expansions don’t use bank switching and can deal with a maximum of 16Mb; this wasn’t an option in the 1980s when that kind of RAM was hideously expensive of course, but your correspondent has two machines expanded to that level that he takes to retro gaming events.
I think it would have been a great idea if the Commodore 128 had come out some time before 1985 or even in 1982 instead of the Commodore 64. It seems to be a case of missing the boat. It ended up being overshadowed not only by the Amiga, but also by the Commodore 64 not being discontinued, which should have happened in or before 1985. Unfortunately, the C128 ceased production in 1989, although the Commodore 64 continued until 1994, when Commodore went bust.
It might seem a “great idea” but the C128 simply wouldn’t have been financially viable as a commercial product in 1982; in fact the price tag was more reasonable by 1985 but still put it out of reach for the majority of home users, especially in the UK where cost was an important factor. The C64 kept selling because it’s a popular computer, despite what the author claims.
I’ve finally come to the conclusion that various Commodore 64 magazines, as well as Commodore themselves should have given people the clear message that Commodore BASIC V2 is only suitable for writing text based programs, like a pocket calculator only with text labels, or text only adventure games.
And yet there are games in BASIC for the C64 which have graphics, some of which are compiled and could pass for machine code; the author needs to remember that just because he isn’t aware of something it doesn’t logically follow that they don’t exist.
The differences between those computers summed up are whereabouts in RAM to place your Assembly Language/Machine Code programs, the ASCII/ATASCII/PETSCII codes for specific alphanumeric characters, where is the screen memory located, and if you use any ROM based routines, then the addresses of these routines will be different on different computers, so you have to look them up and replace them.
This is a worryingly naïve way of looking at 6502 machine code and no, it really isn’t anywhere near as simple as the author is trying to imply.
I recently had a fantasy of reading an ad about it while sitting near my Dad in the living room, shouting out the details in amazement, seeing my chance to be free of Commodore BASIC V2 and into the Spectrum marketplace, then having meetings with Spectrum owners to retype my Sinclair Spectrum BASIC listings into their computers, because I seriously doubt that these programs saved by a C64 compatible data recorder would have been compatible with the Spectrum.
Your correspondent isn’t sure that admitting to having these kinds of adolescent fantasies will do anything positive for the author’s reputation, in fact it could easily be seen as rather worrying.
The irony is that in the author’s fantasy the Spectrum Simulator couldn’t save or load files in a form compatible with a real Spectrum whilst in reality it could do exactly that; BASIC programs or even SCREEN$ files could be exchanged between the two machines and a teenage version of your correspondent occasionally did so to convert a friend’s Spectrum-drawn graphics (created with the OCP Art Studio before the author starts dribbling about Spectrum BASIC again) to the C64.
Unfortunately, this program shows the limitations of the Commodore VIC-II chip. In hires mode GRAPHIC 1 (320×200) it soon starts to suffer from attributes or artefacts where the lines in each 8×8 pixel square change to the same colour, the same as on the Sinclair Spectrum.
This is one of those trade offs that happens in 8-bit computer design; at the same resolution the Amstrad CPC or BBC Micro only get four colours for the entire display where the Spectrum has fifteen and the C64 gets sixteen. That’s why it can do things like this if the artist uses a graphics tool:
So far, I haven’t seen any display from the higher resolution VDC chip, because I haven’t yet bought the right kind of monitor lead.
The VDC has only two colours per 8×8 pixel attribute cell, but they’re half the width of the C64 ones and it’s worth remembering, however, that all of the other machines with a comparable mode (the Amstrad CPC or BBC Micro for example) only have two colours where the C128 VDC has sixteen.
$FFE1 is a ROM routine I think is called STOPIN, which allows the user to break out of the program just by pressing the RUN STOP key (like ESC on other computers), instead of pressing RUN STOP and RESTORE, which resets the computer, including colours and variables, although your program would still be intact in RAM. TMR didn’t seem to understand this!
The lack of understanding is purely the authors; calling $FFE1 doesn’t “re enable” the Run/Stop key as the author claimed previously, it merely checks the key and the author’s code is then exiting on a positive response. In real world programs (as opposed to the tiny fragments the author is offering up) just exiting to BASIC without resetting the registers like that is pretty much useless because they do things like turn on the hardware sprites, change where the character set or screen pointers are looking and so on.
As an aside, your correspondent mentioned that he previously hand assembled and can still write a similar program to the author’s without needing a monitor:
This is, of course, a completely useless “trick” and doesn’t make your correspondent any more fun at parties.
 Its hard to talk about the Apple II’s software history with any real degree of certainty because, if the figures in some of the contemporary magazines weren’t hyperbole, there were a significant number of programs released that haven’t been archived; one publication claimed over 16,000 programs, which is several times what can be found online.