
Commodore KERNAL History - ingve
http://www.pagetable.com/?p=926
======
cromwellian
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.

~~~
DaveInTucson
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.

------
rbanffy
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.

~~~
avian
Isn't the whole point of the post that it wasn't a hardware independent jump
table?

~~~
jacobush
Well, most of the post, but some of the later models were designed to be
forward compatible.

------
cmrdporcupine
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.

~~~
flomo
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.

~~~
SwellJoe
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).

~~~
gribbly
>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.

~~~
bananaboy
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.

~~~
vardump
> 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...

~~~
bananaboy
Ah right, I think I was confusing it with EGA, where you have one bitplane for
each colour component.

------
emcrazyone
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.

Cool article!

~~~
nanis
He is not referring to the firmware as "kernel" ... See
[https://en.wikipedia.org/wiki/KERNAL](https://en.wikipedia.org/wiki/KERNAL) :

    
    
        "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."

~~~
emcrazyone
Too bad that's not stated in the article. The way the article reads seems to
imply a kernel OS.

~~~
nanis
> "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, ...

