It was common practice for most advanced C64 software to avoid most kernal routines, replacing disk i/o with custom fast loaders, screen output with custom rendering, and system interrupts with their own. This was almost always true for games, and sometimes true for applications, for example, the C64 didn't have a UART, and high modem baudrates sometimes lead to bit errors, so some fast terminal programs wrote their own.
This article is amazing though, because it revealed stuff I never knew, even after years of C64 coding. For example, I didn't know about the VECTOR calls to save/restore the vector table. I almost always started out my code doing this myself, e.g. SEI/LDA $0314/STA SAVED_IRQ/.../CLI.
I remember writing a BBS in assembly language for the C64 and using $FFD2, but I had to hook the kernel to implement multiple window support, so that when the SYSOP was doing stuff, he had an overlay window and output could be directed at different screens. The design of the kernal gave you just enough flexibility to do what was needed.
20 years later, and I still feel like I had more joy developing on the C64 than any modern system. The tools were primitive, the kernal was primitive, the constraints were great, but everything was much more predictable. You knew exactly how long something took, you knew what resources you had to work with, and it was possible for a single person to completely understand the whole system down to even the hardware layer.
And man oh man, the Action Replay cartridge. Immediate feedback from changes, and global freezing of a system and inspection of all system state including WRITE ONLY registers.
Back in those days I wrote my own assembler for the C64 (and later the C128). Probably my single greatest moment of joy as a programmer was when it successfully assembled its own source code.
I think the software designers of the Commodore 8-bit personal computers deserve more recognition than they have. The hardware independent jump table is something not often seen in the 70's with severely constrained memory machines.
Of course, IBM had the 360 and CP/M had a similar idea at its core but, still, this is pretty sophisticated for those early years.
Yeah Commodore seemed to have some smart people on staff.
Sadly what sunk it was once again boardroom meddling.
the ousting of Tramiel after an argument between him and Gould, followed by Gould appointing a long line of more or less, most often less (one glorious exception was the guy in charge when the Amiga 500 was introduced), competent CEOs.
Neat, as a VIC-20 owner back in the day I wasn't really aware of this.
I remember my parents getting me into a week long computer camp when I was 8 or 9 (below the minimum age and required a special interview) and all the computers they had in the lab were PETs -- and how excited I was to be able to record the BASIC programs I worked on and bring them home to run on my brand new VIC-20.
That said, Commodore was not nearly as good at Apple and Atari at keeping backward compatibility on their 65xx 8-bits, and they did something weird with the Plus/4 type machines, which bizarrely had almost no compatibility at all. You could easily run software from the late 70s on a mid/late 80s Apple IIgs, or on an Atari XE.
Yeah, Commodore's business model seemed to be designing incompatible 6502 computers and throwing them against the wall to see which ones stuck. There was like a dozen of them, and only 2 or 3 really mattered. When they were riding high on the Commodore 64, they released the incompatible Plus/4 to great hype, and the market reaction was WTF, these guys are totally clueless.
Commodore mainly sold on price, which was great for people who wanted an accessible computer. But growing up, I knew a lot of people with zero interest in computers who had a Commodore stuffed in their closet. There was a thing "Computers are the future, so you're a bad parent if you don't buy one for your child." And the Commodore was the cheapest thing at K-Mart....
So in these discussions, people always say Commodore had bad management, but that was also the public perception at the time. They seemed shady. Meanwhile, Apple was expensive, but they were seen as really solid company. And not to mention IBM.
Commodore frequently made (bad) decisions based on cutting parts cost. Plus/4 was just plain cheaper to build than the C64, and they thought they could charge the same price for it...so, it looked great on paper to the bean counters. They just fundamentally misunderstood the market and the success of the C64 within that market and repeated that misunderstanding over and over again.
C64 was successful not just because it was cheap, but because it provided a lot of value. It was a powerful computer for the price. The Plus/4 couldn't provide C64 compatibility without including the C64 chipset, and those were the features that made C64 expensive (comparatively) to build. The Commodore 16 was an even bigger joke; at that point, nobody was shipping such an underpowered machine.
Similarly, they put a lot of resources into things like the CDTV, which was a five-year-old computer in a home stereo style chassis. At that point, cheap VGA and high-quality sound cards were already available. It was anemic, but because it was old tech, it was cheap to make. Just more cashing in on their previous successes by making lower value versions of good products.
The C64 wasn't seen as the "cheap" product, IMHO, it was seen as a good value. Where Commodore screwed up later was failing to deliver good value, while keeping the cheap price. The 64 was a revolution. And, the Amiga was, too, but on a different set of metrics (cheap and good value were not really Amiga characteristics, in a world with cheap PC compatibles with VGA and 16-bit sound flooding the market...the Amiga 500 was probably the last great value product Commodore ever shipped, and that's reflected in the relative success of the product).
>the Amiga 500 was probably the last great value product Commodore ever shipped
Agreed, the Amiga 1200 was too little too late, I remember when I first tried programming on the PC coming from Amiga, segmented memory and 16 colors, I thought no way am I ever gonna use this!
Next time I gave it a try there were dos extenders giving you a flat memory model as well as vga 256 color mode-x where each byte corresponded to a pixel on screen, which performed so much faster than the Amiga's blitter with bitplanes that it was suddenly very clear that it was all over for Commodore.
You probably mean mode 13h - 320x200x256 colour. Mode X is actually similar in some ways to the Amiga's bitplanes because it uses a planar memory arrangement. This is actually quite useful for fast drawing of pixels because in Mode X for example you can draw four pixels at once with one write.
> Mode X is actually similar in some ways to the Amiga's bitplanes because it uses a planar memory arrangement.
Mode X does not separate bitplanes. With Mode X, you don't need to write to 8 memory addresses to completely change a single pixel. (In the worst case, you needed one slow "out" and one fast "mov" instruction, if you wanted completely random access. However, no one ever did this, because you could simply draw every 4th pixel once for each bank, requiring just 3 (or 4) bank switches per frame.)
Mode X is nothing like Amiga bitplanes.
Also in Mode X each byte does correspond to a pixel on screen, it's just banked in 4 banks.
Mode X it interleaves framebuffer pixels into four banks. Top-left pixel at coordinates 0, 0 is in bank 0, next right is in bank 1, etc. until pixel at coordinates 4, 0 is again in bank 0.
You could also write same pixel to all banks at once (or in any combination).
On Amiga, bitplanes worked very differently. They were basically layered "2-color" bitmaps, one bit corresponds always to one pixel. 1 to 6 bitplanes (or 1-8 for AGA) could be combined to form 2^1 to 2^8 colors. So for example for 256-color display, you actually had to set eight bitplane pointers.
This type of bitplane arrangement made setting a single pixel very slow. You had to rotate desired color value bits and mask & set corresponding pixel in 8 different memory addresses...
Right. I don't mean to dismiss the "value" of the C64. But it was more like Commodore accidentally released something good, and then sold at or below cost to run their lower-end competitors out of business. Commodore 64 obviously had a enthusiastic user base, but the users recognized the "value" more than Commodore did. Commodore's business model was selling a lot of cheap computers to people who wouldn't actually use them, so the Plus/4 was just as good as far as Commodore was concerned. And yes the Commodore 64 was seen as cheap -- you could walk into Target etc and get a computer for $250!
On the techie side of the internet now, a lot of people have a positive perception of Commodore because they got one when they were 13 or whatever and got into it. We don't hear from all the people who couldn't find a use for it or never bought the disk drive (another $250) and ended-up shoving it into their closet. At the time, Commodore was not considered a reliable well-run company. There's a reason the schools bought Apples.
The Commodore 128 effectively had a Commodore 64 built-in to support a sort-of "backward compatibility". Apple did this too, with the IIGS, which could boot into what was effectively IIe mode.
> That said, Commodore was not nearly as good at Apple and Atari at keeping backward compatibility on their 65xx 8-bits, and they did something weird with the Plus/4 type machines, which bizarrely had almost no compatibility at all. You could easily run software from the late 70s on a mid/late 80s Apple IIgs, or on an Atari XE.
It's interesting to compare the approaches of the Apple IIgs and Apple III in this respect. The Apple III had backward compatibility, but it was deliberately limited to a no-frills Apple II compatibility mode, supposedly because Apple didn't want developers to continue targeting new software to Apple II. Apple IIgs, whose "native" architecture diverges much more from the original Apple II, had better backward compatibility (thanks in large part to the 65C816's emulation mode and the Mega II chip).
Calling the commodore's firmware a kernel is a bit of a stretch in my opinion because it did not schedule anything. The 6502 had no MMU and therefore no virtual memory or running of more than one app.
One clever idea I learned when I was a kid tinkering with C64 was how the ROM resided at the same memory address as RAM. By toggling a bit, you can switch between the two. Applications back in the day would toggle this bit really fast to give the capability of having an assembly language program running in the background while your basic program interacted with it.
I learned this and it stuck with me over the years. C-Net BBS by a company called Perspective Software, if I recall correctly, did just this.
"KERNAL is Commodore's name for the ROM-resident
operating system core in its 8-bit home computers;
from the original PET of 1977, followed by the
extended but strongly related versions used in its
successors: the VIC-20, Commodore 64, Plus/4, C16,
and C128."
> "The way the article reads seems to imply a kernel OS."
I don't think so. Here are some instances of the word KERNAL in the article:
* ... jump table at the end of the KERNAL ROM ...
* ... The system ROM (“KERNAL”) was now 4 KB
* ... making the KERNAL and the editor merely
a device driver package.
* ... jump table in the KERNAL ROM for interfacing
with it
* ... these are the KERNAL calls used by BASIC ...
* The following eight KERNAL routines ...
* ... it calls out to these KERNAL functions ...
* ... these KERNAL calls have to parse the BASIC
arguments ...
* These 6 KERNAL calls are actually BASIC command
extensions, ...
I had never heard of the commodore KERNAL before and I had no problem following it. In addition, the term kernel has many uses in computing besides OS kernel.
This article is amazing though, because it revealed stuff I never knew, even after years of C64 coding. For example, I didn't know about the VECTOR calls to save/restore the vector table. I almost always started out my code doing this myself, e.g. SEI/LDA $0314/STA SAVED_IRQ/.../CLI.
I remember writing a BBS in assembly language for the C64 and using $FFD2, but I had to hook the kernel to implement multiple window support, so that when the SYSOP was doing stuff, he had an overlay window and output could be directed at different screens. The design of the kernal gave you just enough flexibility to do what was needed.
20 years later, and I still feel like I had more joy developing on the C64 than any modern system. The tools were primitive, the kernal was primitive, the constraints were great, but everything was much more predictable. You knew exactly how long something took, you knew what resources you had to work with, and it was possible for a single person to completely understand the whole system down to even the hardware layer.
And man oh man, the Action Replay cartridge. Immediate feedback from changes, and global freezing of a system and inspection of all system state including WRITE ONLY registers.