Prepare to operate – part 2

Debunking The Commodore 64 and Operating Systems – Part 2

Operating systems can be created either using Assembly Language/Machine Code for the CPU the hardware is based around, or by using a language which has a version running on that hardware, or on another system which can be used to produce code compatible for that hardware. How this is actually done can be quite complicated to understand.

This is a rather vague statment dear reader, almost as though the author has no idea what he’s talking about!

Very generally speaking, operating systems are machine code programs that were built either from assembly language source on older, low-powered systems where optimised code is essential or a high level language on hardware with a bit more under the metaphorical bonnet. How that code is assembled or compiled can vary between cases but, in the case of 8-bit systems at least, it’s usually cross developed from another platform with more resources.

The program above uses $FFD2 CHROUT to output characters onto the text screen. These characters are held as data starting at address $1820 on the C128, but this should be $1020 on the C64, due to the different memory map. The program starts at $1800 on the C128, but this should be $1000 on the C64.

There’s absolutely no reason why the program can’t start at $1800 on the C64 as well so the author is merely misleading his readers by trying to make things seem more complicated than they actually are. We’re also going to quote the author saying that his program “uses $FFD2 CHROUT to output characters” here because it will be relevant later, although the program itself isn’t important to the discussion even with that unnecessary trailing BRK command.

CP/M only has 31 functions or calls, but the good excuse for this is that it came out in 1978, instead of 1982.

So dear reader, it’s apparently a “good excuse” for CP/M because it was released in 1978, but the same doesn’t apply for Commodore BASIC which has more functions and arrived during the previous year; that must leave most of the author’s readers wondering why there appears to be a double standard in play unless they’re already used to his hypocrisy.

GEOS is an advanced GUI based OS for the C64, designed to look like the early Apple MacIntosh System Software or Digital Research GEM. It appears mainly as a monochrome system, but can use more than two colours at a time, unlike the early Mac. In spite of this, it never looks anything like as colourful as Atari ST GEM, or Amiga Workbench OS.

Should anybody sensible really be surprised that a program running on an 8-bit system from the early 1980s is less colourful than something similar on mid 1980s 16-bit computers? Still, at least with this second post titled “The Commodore 64 and Operating Systems” the author finally gets to the point where he’s actually discussing a C64 operating system!

It even fixes the C64 design faults by turning off the BASIC and Kernal ROMs, as well as loading a number of equates with meaningful names, similar to the Atari 8 bit computers.

They are also similar to the “meaningful” names for C64 Kernal routines such as CHROUT, as used by the author himself earlier in the same post with a program which “uses $FFD2 CHROUT to output characters”.[1] It’s also worth noting as we have previously that “meaningful” is also a relative term dear reader, they might be so to a programmer who already knows what those registers or functions do but Commodore’s official names like CHROUT are equally meaningful in that context.

I think that anyone out there wanting to create a brand new OS, not based on Linux, UNIX, or even on MS Windows, should get their hands on a Raspberry Pi computer, or a phone with an ARM CPU. This type of CPU is RISC (Reduced Instruction Set Chip), but I was surprised to read recently that it has lots of registers, a bit like the 68000 family, instead of the x86 family, or the 6502 family.

The advice quoted above was brought to you by somebody who has none of the experience or skills required to write an operating system and should be treated accordingly.

While thinking up ideas for your new OS you could be watching lots of sci fi to see the way computers work there, then work out a way of actually doing it.

Computers in science fiction usually have either a graphical interface based on something which already exists or go down what your correspondent has previously seen described as the “whizzy graphics” route which will look pretty on screen but wouldn’t actually work in practical terms. And for goodness sake dear reader, don’t start designing your operating system at the graphical user interface, getting the code which underpins the GUI working and stable should be your first priority – having pretty icons is pointless if the file system you’ve written randomly loses a byte per ten thousand!

That‘s all for now! Look out for another amazing post about the C64 in the near future!

Presumably where the word “amazing” actually translates to “factually inaccurate” and “about the C64” will probably include random, irrelevant dribbling about operating systems on other platforms.

[1] No doubt the author will whine that he was using $FFD2 rather than CHROUT but, since the program was written in a monitor where there aren’t any labels rather than an assembler, it shouldn’t be a surprise that said labels aren’t present.

This entry was posted in Debunking and tagged , , , , . Bookmark the permalink.