So the author is apparently having a go at learning assembly language on his C128 as well as graciously “educating” his readers at the same time; this is of course wonderful because, as we know dear reader, complete novices in any subject always make the best teachers! Hopefully he won’t blame the C128 later when it becomes obvious that trying to write a more substantial program in a monitor is akin to writing a novel on toilet paper, it’s not impossible but certainly couldn’t be described as sensible either.
I feel I should point out first of all that, unlike TMR has recently claimed, when I bought a Commodore 64 in 1984 it wasn’t well known that it had crap, “Neanderthal”, or standard PET BASIC with no commands for colour, graphics, or sound.
In the author’s fantasy world this might actually be true, but in our reality the C64 was already over a year and a half old when the author purchased one and what he considers to be the issues with its BASIC (since not everybody agrees) were very well documented by that point; the problem is that the author went into his purchase blindly and nobody apart from the author is to blame for that; it’s like buying a Renault and then complaining afterwards that it doesn’t have the same engine as a Ford.
Below is a listing of my Assembly Language program which prints “I WAS HERE!” and scrolls horizontally
It scrolls vertically and is essentially the “classic” 10 PRINT “SOMETHING” / 20 GOTO 10 that would be typed into display computers in shops. Your correspondent will avoid offering criticism of the program because there isn’t much point, but we will pause for just a moment to note that it jumps around like Skippy on a busy day, so perhaps the author should’ve taken his own advice and used a flowchart…?
It seems this program doesn’t run on a C64, or would need to be relocated to run. I could only get it to LOAD when using the C128 in C64 mode.
There’s nothing to stop the program working as it stands, simply resetting the C128 into C64 mode (hold down the Commodore key and hit reset) after entering the program and typing SYS6144 will execute it.
Luckily, in this case, we’re using the standard Commodore MONITOR for the C128, but which dates back to the PET. This is fine when it comes to an old fashioned MONITOR with an Assembler, because you can access any part of the computer with it, but obviously not fine when it comes to an old version of BASIC.
This is, of course, a double standard on the part of the author and hideously hypocritical of him. The author doesn’t get to define what is or isn’t acceptable since, along with a lack of experience, he has repeatedly demonstrated that his “knowledge” simply isn’t up to that particular task; for example, it can’t “access any part of the computer” as he’s claiming, which can easily be demonstrated by trying to assemble a JMP $18000 to location $18000 for example.
It’s somewhat amusing to see the author trying to use the C128’s monitor as a metaphorical stick to “beat” the C64 with despite most of his previous favourites not having one.
Unfortunately, according to more than one book about this, the Commodore 64 is so badly designed that at least two different authors suggest storing your data in the cassette buffer, which obviously disables people from saving their program or other data to cassette! I hear it also affects the disk drive!
The author may want to get his hearing checked dear reader, because disk drives don’t use the cassette buffer and there are many programs out there loading their own code into that space. And whilst it obviously isn’t possible to save a machine code routine out to cassette if it’s stored in the cassette buffer, writing something to that space doesn’t magically disable saving or loading either; the most common use of this space are machine code routines or sprite definitions for use with BASIC programs and these usually write the relevant data into that memory and can therefore rebuild it as needed after the cassette buffer has been used.
Claiming that the C64 is “badly designed” just because a couple of authors liked that space for stashing code fragments is a bogus “argument”; as the author himself points out, $c000 to $cfff is readily available and offers 4K of space.
Lots of people or even most people couldn’t afford the expensive disk drives when these books came out, so it’s hard to believe that it was so difficult to find any free RAM to store short programs like this or sprite data.
It’s only “difficult to find” if your knowledge of the machine is as limited as the author’s and a C64 BASIC programmer with a little experience will soon find other spaces. As for if “lots of people or even most people” could afford a disk drive, in the UK the cassette was king but for the rest of the world the C64 was primarily a disk-based machine; even if we limit things to just the UK that’s still a moot point however, because whilst the majority of users didn’t have a disk drive, most of those people weren’t planning on programming the C64 anyway, just like the majority of Spectrum, Amstrad CPC or Atari 8-bit owners had no plans.
Unfortunately the program as listed above takes over the C128, disabling the RUN STOP key.
It doesn’t disable Run/Stop, so holding it down and hitting Restore will work as they’re intended when machine code is running.