Debunking operations

Debunking Debunking TMR‘s “Prepare To Operate – Part 2”

TMR of the blog “C64 Crap Debunk” recently had the cheek in https://c64crapdebunk.wordpress.com/2017/12/23/prepare-to-operate-part-2/ to debunk my excellent post examining operating systems in general and what they have to do with the Commodore 64!

The author’s uneducated gibberish about Linux and CP/M or distracted meandering about computers in science fiction are completely irrelevant to the his stated topic of “explaining why the Commodore 64’s BASIC V2 was crap and how some people managed to program the C64”. What exactly do either the Enterprise’s computer or Linux have to do with the C64 dear reader…?

I haven‘t actually written an operating system yet, but I think I may be able write one at some stage in the future.

Let’s pause to remember dear reader that the author has complained incessantly about how the C64’s BASIC forces people to deal with the computer directly but that’s exactly what he’ll have to do in order to program his own operating system – as opposed to using someone else’s code as a base – except without a fixed target platform to worry about; even choosing hardware that doesn’t vary too greatly between iterations such as the Raspberry Pi still gives a range of potential hardware to deal with.

The author has previously talked,  amongst other things, about producing his own version of Microsoft Extended BASIC for the C64 but that hasn’t materialised over four years later so his ability to complete the far more complicated task of writing an entire operating system really does have to be questioned. It’s a positive thing to have dreams of course but they don’t necessarily stand any chance of coming true; your correspondent wanted to be a tap dancer in his youth but had to stop due to balance issues[1].

To do this, I have to look at what other people have done, what operating systems have in common, and how they work.

Just looking superficially at how operating systems work won’t tell the viewer much about actual implementation, what’s happening “under the bonnet” is far more important since that can often shape what’s happening on screen.

I thought I expected computers to be absolutely amazing before getting one. This was based on what I‘d seen in sci fi series, such as Star Trek: The Original Series, Space 1999, Blake‘s Seven, and Doctor Who. Looking back at at episodes and clips from these series made before 1984, they show that none of the computers featured had a GUI, they were mainly voice controlled, could also speak, and either had lots of flashing lights, or panels with lighted switches

One of the problems with basing expectations on science fiction is right there in the term, they’re works of fiction and based on what the writers think may be possible with no guarantee those ideas are based on experience of knowledge of the current state of technology. Some of what was predicted by those programmes became reality over time – as often as not because fans went on to make them happen  – but it’s worth remembering the context because these voice-activated computers were usually found aboard faster-than-light capable starships in the distant future or as part of the control console of a type 40 TT capsule from another world.

The now obsolete Prime computer that Romana installed into the TARDIS in 1980 is at least “terribly interactive” even if we should possibly question the definition of the word “terribly” as used in that context.

 I think that the fictitious computers in these versions of Star Trek probably all contain a ROM or some equivalent RAM storage that can survive a reboot containing routines for graphics, so that creators of operating systems don‘t have to worry about doing this.

We need to pause and note that the author is here discussing his assumptions on the inner workings of fictional computers here dear reader. And,because there’s nothing available in the source material to back that or indeed any other argument, it’s equally valid to presume that the graphics routines were loaded from a DNA-based storage medium which was semi-sentient and relying on modified cow DNA with some extra routines to suppress the occasional dialogue box containing the word “moo”[2].

If he actually wants to understand more about the actual subject of operating systems the author could do a lot worse than looking at G. Pascal Zachary’s book Showstopper which is about the development an actual operating system for real computers, the team of people behind it and how much they sacrificed to get Windows NT written.

[1] He kept falling into the sink.

[2] That isn’t significantly more ridiculous than the author assuming that he knows how the operating system of a fictional computer aboard a starship from the future works, again it’s called science fiction for a reason.

Advertisements

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.

Further operations

Debunking Debunking TMR‘s “Prepare To Operate – Part 1”

I‘ve been pleased to see an increase in the hits on this website, but I don‘t know where they‘re all coming from, except from various countries. As he hasn‘t even seen my stats, I don‘t see how TMR would know either!

The author’s pleasure is based on an increase in traffic, but he then states that he doesn’t know where said traffic is coming from. Your correspondent was merely pointing out that the author doesn’t even know that said hits were down to a real person reading his bile-laden drivel, so that aforementioned pleasure was misplaced.

TMR said he worked in London for a while in the late 1990s. This has nothing to do with what‘s been happening to London since then. The destruction of London has taken place just in the last few years.

And this entire discussion is, as already mentioned, completely and utterly off topic for a blog that the author claims to be about “explaining why the Commodore 64’s BASIC V2 was crap and how some people managed to program the C64” so the author can hardly complain about relevance when he himself is failing so abysmally on that front.

TMR claimed to live in Yorkshire. This is a county which was abolished in 1974! Its territory was redistributed amongst three new counties containing the name Yorkshire, as well as some old and new counties.

Yorkshire is still recognised as a “geographical territory and cultural region”, so claiming to be living in Yorkshire as your correspondent did is still perfectly valid and indeed in common use. It wouldn’t have taken much actual research to realise that, but past experience has taught us not to expect that kind of effort from the author.

Linux is an operating system which has been adapted for lots of different hardware. The way it boots up may be different on different hardware, but once booted, I don‘t think Linux depends on making any calls to a PC BIOS ROM, a Mac ROM, or any other ROM.

The author’s original claim was that he didn’t “think [Linux] depends on any ROM, because it can run on PCs, Macs, and Raspberry Pi computers” but, as your correspondent pointed out, it does rely on a ROM because it wouldn’t be able to boot otherwise. The “but once booted” qualifier in the sentence quoted above wasn’t part of the original statement and changes it significantly, so the author is once more trying to mislead his readers by moving the goalposts.

Linux used to be quite difficult to get into, but has now become fairly user friendly, although some distrtos such as Arch insist on making users type lots of commands to get everything set up. In spite of this, some Arch based distros such as Manjaro, and Antergos have added graphical installers.

Your correspondent’s criticism was based on the huge variety of distributions and the variations they bring to the table making it harder to get into, which in turn has inhibited the spread of Linux on the desktop; that’s a perfectly valid argument because the average user – who won’t have the time or indeed inclination to experiment with multiple flavours of Linux even if there weren’t “lots of commands” to type – doesn’t know or care what an “Arch based distro” is or if they should select GNOME, Cinnamon or KDE as their desktop environment. In that respect, Linux is still difficult to get into and probably always will be.

The author’s post topic was, specifically, the “Commodore 64 and Operating Systems” so we can only hope dear reader that the next instalment will actually talk about operating systems for the C64 since he’s struggling to do so at the moment! There has at least been a passing mention of Berkeley Softworks’ GEOS previously even if the author failed to go into any actual detail (it does fall outside his self-referential 1984/5 window of course, but so does all of the Linux discussion so he’d be almost ridiculously hypocritical of him to complain and doesn’t hold water as an excuse) but what about the other options available during or indeed after the C64’s lifespan?

And we’ll have to see if the author somehow manages to tie any of the operating system discussion into his blog’s stated topic during future posts or if the entire discussion must be written off as irrelevance.