Commodore KERNAL History
pagetable.com
pagetable.com
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.
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.
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.
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.
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).
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.
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).
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.
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.
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...
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.
Cool article!
"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."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, ...