Customizing The C64 Kernal

Fun fact: Commodore’s core software is known as the kernal, which would, from the outside, seem to be intentionally incorrect, perhaps to set up some kind of copyright claim? In actuality, the misspelling came about after one of the engineers made a typo, and CBM simply ran with it, naming it kernal even in the general documentation. Whether somebody thought it was accidentally creative, or they just decided to let it go after the error had already made its way through a bulk of the printed materials, while the truth may be lost to time, the fact remains that it’s just another one of those myriad quirks that we Commodore aficionados have adopted readily as well.

The kernal is in charge of operating the various aspects of the computer – it is similar to the operating system of a modern computer, but it’s entirely on a chip, on the motherboard. It primarily handles the task of interacting with the user: receiving commands, acting on them as directed, and providing feedback.

And, similar to today’s OSes, alterations and mods are possible, despite the kernal living on a chip where it would seem to be nearly set in stone, on a non-writable chip, Nevertheless, Commodore’s kernal can be modified to change its appearance and behavior, though while it used to be difficult to manage unless you were a skilled hardware and software geek, it’s darned near child’s play to do it today.

Back in the C64’s heyday, there were commercial kernal replacements available -usually sold via advertisements in scene publications like Compute! or Compute’s Gazette- like JiffyDOS, which replaces the datasette routines with enhanced floppy drive transfer speeds, as well as a simplified command set. Originally, the altered kernal came on replacement switchable ROM chips. JiffyDOS still exists today, and licenses for the firmware –and of course pre-loaded switchable ROM chips– can be obtained online.

Though the C64 is well and truly legacy hardware at this point, ROM switchers have continued to be designed and refined, and now it’s possible to swap kernals with the flip of a switch, turn of a dial, or even tap of the Restore key! The primary interface no longer need be static, and can be customized relatively simply, while still maintaining the ability to fall back to the original experience and command set. A C64 so modified is still fully capable of being returned to original user experience whenever needed.

Now today, with technology being more accessible, understanding the kernal code becomes almost trivial, and simple things such as boot up color or welcome text can be changed, as well as core routines.

Where to start

To begin altering the kernal, you’ll need an example of the kernal as a file to start with. While we can get a copy of the kernal right from the original chip with just a little work, it’s a lot less hassle to just go download an example readily available on the internet. Also, in the event the current stock kernal ROM chip has failed, this process can provide a handy repair and replacement, while opening the door for alternatives on-the-fly.

The stock Commodore kernal is available online on zimmer.net. The most common kernal ROM is 901227-03. It was the final revision of the kernal before the Commodore 64 ended production. The most recent revision –251104-04– was meant for the Commodore SX-64, which was a slightly different animal. Almost fully compatible with the C64, but different enough that running its kernal on a C64 introduces some oddities that just get in the way of using the system as expected.

Note that some Commodore ROMs may technically still be copyrighted. CBM doesn’t exist in quite the same form that it used to, but the assets are still wholly owned, lurking in the shadows under the stewardship of a company called Cloanto (https://cloanto.com/products/). The developers of the MEGA65 -a modern take on an unreleased model- wrote a detailed post on this topic here, and another post about the issue is discussed thoroughly here as well.

Edit the file

Alteration is performed on the ROM’s binary file directly, so a hex editor is required, such as HxD. HxD opens the binary file and displays it in both hexadecimal and decoded ASCII. This is helpful to see what code may represent visible text, but also allows direct access to every individual byte of the source code in general. The code is displayed by the address spaces in which it resides. It looks like gibberish for most of the file, but if you know what to look for, lots of things can be easily located and changed to suit your preferences.

HxD is one of many hex editors available online

What to edit

Now, editing the code directly can be a little fraught and can result in the computer not working as expected, or at all. However, for the most part, any failed attempts to mod the kernal can be rolled back easily. It is possible to cause real damage if you change the wrong things, but you’d honestly need to know what you were looking at in the first place to do so. The order of everything is important so not changing the dimension of a field is important. Here’s the thing: the kernal is packed with every feature the developers could cram into the original chip’s storage space, and exists as a loooooong continuous blob of hex code, so being able to access specific routines and functions in the kernal requires knowing exactly which address space they start and end at. What this means for us is that the best way to perform a successful initial customization of the kernal is to end with the same number of characters as you started with. You can replace the word “FREE” with “FART” if you wanted to be immature (but hilarious!), but “FARTY” is right out. You could use a shorter word too, as long as you include space characters to pad it out.

There are guides to help with alterations, such as this one for modding JiffyDOS or this one about ROM patches.

Here are a few kernal changes that can be done easily and safely. Bear in mind we’ll only be looking at cosmetic changes; nothing that changes functionality of the system such as what a more in-depth product like JiffyDOS does.

Changing startup Text

The text of the Commodore boot screen will appear in the stock ROM as plain text, and is easy to find in HxD – it can then be changed and saved. Try searching (CTRL-F) for the string “BASIC BYTES FREE”, which is in all official versions of the kernal, around offset $0461.

The first line of the screen should use offsets $0475 to $0497 (which includes the preceding empty spaces, but not the ones following the text)

Location of the welcome message in the stock kernal

The texts “BASIC BYTES FREE” and “64K RAM SYSTEM” (plus their spacing) are also alterable.

In fact, the whole section from the spaces to the 64K RAM SYSTEM (with spaces) are a whole single string (where 20 represents spaces and #0D represents returns) and can be altered as a block – add or remove lines, change text, etc. After this string, the number of bytes available will be printed by the kernal, then the string BASIC BYTES FREE (which starts by a space) which can be changed too.

The whole welcome message is a single string inside the kernal – 20 are spaces, $0D are carriage returns/newlines.

There are other interesting strings that could be altered as long as their length is respected, such as SEARCHING FOR or ERROR.

You can experiment most effectively by copying out the string as shown selected above, paste it into Notepad, then experiment with your chosen modifications until you’ve achieved an exact string length match.

Changing startup screen colors

One of the most popular kernal changes is the startup color scheme. Want to make the Commodore look like old DOS prompt? You could set the text to be green over black background, instead of light blue on dark blue. Prefer the border to be black too? Maybe something a little more eclectic? This is just data within the kernal; as long as the right values in the right place make sense to the rest of the routines at-large, you can make changes that have predictable results this way.

In the stock kernal, there is a unique string which should be around offset $CD9- “0E0601020304” – the 0E (offset $0CD9) is the border color (light blue) and 06 (offset $0CDA) the background color (blue) – these can be changed to any of the accepted stock Commodore colors as follows:

Location of the border and background color in the stock kernal

Changing text color

The text color can also be changed – looking for this unique string “8C02A90E” which would be around offset $0532- the 0E (offset $0535) is for text color (light blue) and can be altered.

Location of the TEXT color in the stock kernal

Beware! if the text and background colors are the same, text will be unreadable. Black on black? No thanks, Mr. Douglas Adam.

Changing READY. prompt

The READY text is not part of the kernal, but the BASIC ROM – that is why the Commodore 64 can boot up with an almost OK screen but no READY message when the BASIC chip fails. But kernal or BASIC, both can be altered…

We can view this message is in the BASIC binary by searching READY and the prompt is located at offset $0378.

Location of the READY. prompt in the BASIC ROM

The prompt message can be changed like other texts. It is just an output set of characters and the kernal doesn’t really care what the text is, as long as the length is the same, including the punctuation in “READY.” – these 6 characters can be changed to any other string.

Result of changing the READY. prompt

In theory other BASIC response messages can also be changed without altering the functionality. However, beware that changing actual tokens in the BASIC ROM, such as “PRINT” or “GOTO” will definitely cause some collateral damage, so don’t mess around too much with those.

Advanced features?

Something interesting would be to remove the de facto loading location of the LOAD action commanded by shift-RUN/STOP, which is the tape drive (device=1) on the stock kernal.

LOAD from disk using a different kernal

The SX64 kernal ROM which was made for the portable luggable version of the Commodore 64 –the SX-64, Commodore Executive 64, or Commodore VIP-64 depending on where it was sold. Its high price point and low actual portability kept it from seeing anything like the success of the C64.

While the computer was a “portable” version of the Commodore 64, the datassette port and all its loading routines were removed. Much of the kernal was similar to the full C64, and the file can be used in a standard C64 if a datasette isn’t going to be used.

The binary kernal ROM file 251104-04 is available on zimmer.net

It is possible to revert the text and color scheme of the SX-64 kernal back to the usual C64 one but keep the load-on-floppy (or pi1541) with the shift-RUN/STOP key combo.

That being said, there is an issue with the SX64 (or most any kernals) implementation of the shift-RUN/STOP routine – it pushes the command as
LOAD”:*”,8
Which loads the very first program on the disk device 8, traditionally the first floppy drive. However, it does not ensure the memory location where it is loaded to. A much better command would add a ,1 parameter for those programs where specific memory address is needed. Fear not – this can be altered in the kernal file. Even if the new load command is technically too long for the space it has available in the kernal binary.

There are basic command abbreviations that uses PETSCII to make commands shorter. They are usually 2 characters, turning LOAD’s 4 char count to only 2, leaving 2 characters for the extra ,1.

PETSCII is literally using the lower-case character map of the ASCII table – when editing the binary file, one could simply write the ASCII lower-case and that would become the corresponding letter’s PETSCII in the Commodore world.

Therefore, locating the LOAD command in the SX64 kernal binary and changing it with
Lo”:*”,8,1
would in theory push the correct (shortened) command to the BASIC interpreter. This is found at offsets $10D8 to $10E1

Location of the LOAD call in the SX64 kernal

When implemented, hitting shift-RUN/STOP results in the following

Load shortcut with ,8,1 arguments

What if you want to use both the floppy drive and tape drive?

One of the main issues with using JiffyDOS or SX64 as a base kernal to implement a change in the LOAD routine, is that the datasette routines are butchered to make room for new content. Remember, the code storage space is really cramped for these systems. While this may be advisable on machines without a cassette port, it does block some nice modern features such as Tapuino, the arduino tape emulator.

Being that LOAD and RUN are both read as a single string by the kernal, one could sacrifice the auto-RETURN and the RUN in favor of having an auto-fill load string – there’s just enough space for that without going into much trouble altering the inner routines of the kernal. On the base kernal file, the complete load sequence is located around at offset $0CE7

Complete load sequence for Shift-RUN/STOP on stock kernal

Changing it to
Lo”*”,8,1
would in effect remove the #0D (Enter) and the RUN + #0D (auto run) – this would still give an interesting auto-fill command for loading programs.

Altered load sequence with stock kernal, removes auto-Enter and auto-run

At this point, it is up to the user to hit [ENTER].

While less automation, still more useful than the plain LOAD for cases using floppy drive, without removing the actual datasette routines.

auto-fill with shift-RUN/STOP (no Enter)

To load on tape, simply type LOAD [ENTER]

Testing

To actually put these alterations to use, we need to burn the images to a physical chip to use in the computer. Burning ROM chips is its own fun process, but sometimes it is nice to test ahead of the whole pull-the-chip-to-reburn process. That’s where we can turn to VICE – the Versatile Commodore Emulator – which uses the exact same binary files as burnt on the ROM chips. From the VICE folder, the /C64/kernal file is the kernal ROM, and can be used for a quicker iteration time. This kernal file is literally the stock C64 binary kernal ROM, so you can replace VICE’s instance with your own customized one, and boot it up for instant testing.

See the end result by running VICE with the altered kernal and BASIC ROMs.

Running custom kernal and BASIC in the VICE emulator

Installation

Beside being used in emulation, altered roms can be installed on the actual hardware – see Chip Flipping: Changing the ROMs for details on how to do a physical swap!

ISSUES WITH DIAG

Something to keep in mind is that the C64 Diagnostic Cart with full harness is likely to declare a bad PLA or bad CIA because of the different ROMs. Anyone who RTFM about what the diagnostic is actually doing when testing CIAs and PLA will understand that the stock ROM checksums are used for those tests. If you’re running different ROMs from stock, then the checksums will be different, so… I guess just expect weirdness with self-test programs if you’re not running all the stock things when you test.

C64 diagnostic REV586220++ – bad PLA declared because of custom Character ROM – Note that the custom kernal is declared as Unknown.

For full diagnostic to report correctly, it is best to have the stock set of ROMs installed when running the tests. That is why ROM switchers may become handy.

Conclusion

The sky is the limit. Or imagination. But the end result can look quite good.

Simulated DOS on commodore 64, made with altered kernal/basic

Other cool mods

-One cool Kernal alteration available on CSDB is an autoboot – loads the first program available on disk. Useful for BBSes. Trashes the datasette routines (like most added functions)

-On the other end of the spectrum, there is this TurboTape kernal on CSDB that removes RS232 in favor of TurboTape datasette speeder, and head alignment.

Now what?

Well, you’ve made your changes and proven they work as intended in an emulator, but what about dropping these changes on the real thing?

That’s up next, where we start swapping out the stock Commodore ROM chips for our own custom-made ones!