Commodore 64 Kernalpalooza

When you power up your Commodore computer, there’s a complex dance of things happening to ensure the system is ready to go. Then, the base components needed to present an interface and accept inputs from you are loaded up, before the system finally presents that screen we all know and love.

Back in the day before the internet, eBay, Amazon and Ali Express, getting the components and software necessary to hack and modify the Commodore was a challenge. It was the sort of thing you picked up while interacting with fellow hardcore Commodore geeks, or maybe you knew a guy who knew a gal who had a hand in developing for the platform. It was nearly a thing of magic when somebody came out with a modified kernel that addressed the shortcomings of the 1541 floppy drive, one which came on a pair of custom-burned chips and a toggle switch (so you could flip back to the stock kernel for those programs that couldn’t load under JiffyDOS for whatever reason).

Nowadays, it’s a simple matter to learn a little about the inner workings of the computer, and source your own bits to not only replace the kernal, but modify it to make it your own, too! And not just the kernal, either. The character and BASIC ROMs can also be changed in interesting ways, some more deeply than others, depending on how familiar and comfortable you are with the code that comprises these things.

Dump the existing ROM to a simple 8k bin file (or more likely just download a dump, open it up in a hex editor, make some edits in the appropriate spots, snatch up a compatible EEPROM and programmer, and burn baby burn!

It’s extremely approachable these days, and once you grasp the concept, you’ll probably be looking to personalize a copy for yourself. A lot of people already have, and put them up online to share.

Now, there is a limit to what you can pull off. Like I said, the whole “operating system” is a measly 8k of code: just enough to get all the hardware working as intended, and making the advertised features available. The thing is, 8k is all the system is willing to look at, so for the really big customizations, something has to go to make room for them. That’s why many fastloader variants just chuck the datasette routines out the window, though of course there are other variants that focus on expanding the tape controls and do away with floppy-related stuff, too. How’d you like to just be able to type “LOAD” and the system assumes you’re entering LOAD”*”,8,1 instead? No more of that “PRESS PLAY ON TAPE” nonsense! 🙂

Okay, so now that you’re drooling, how does it work? Well first, of course, you’re going to need your replacement chip. The stock kernal ROM in the Commodore is not re-writable (it’s a PROM; but you need an EPROM or EEPROM). The difference between the two is that one is erased with a high intensity light, usually a UV lamp, before it can be written to again. The other can be wiped electrically (Electrically Erasable Programmable Read-Only Memory) by the programmer device. EEPROMs are far more common and convenient, but if you’re already knee-deep in the world of legacy micro-electronics, you may have an old-school EPROM laying around already. Each variant comes in different sizes, from 8k up to 512k, and availability can be challenging for the smaller ones.

Oh, and there are three variants of EEPROMS too. These are DIP: the classic oblong chip with metal legs sticking out of it, PLCC: a smaller, square package with its legs wrapped around the edges around each side, and SMD: with teensy tiny little legs designed to sit flat against pads on the circuit board.

All of the available E/EEPROMs will require some kind of adapter, either because they have more than the 24 pins of the stock Commodore sockets, or of course because they’re a completely different form factor. Thankfully, there are projects out there for each of them; it’ll be up to you which one suits your expectations best.

The one you want will depend very much on how you expect to use it. If you want to swap ROMs quick and easy and often, you will probably want a solution that doesn’t require you to open the chassis and flip switches or jumpers around.

For that, there are two options:

1. A SMD-based option that uses a couple of additional internal connections to let you switch the ROM simply by holding down RESTORE on the keyboard. You can get one of these little chunks of magic as a DIY project or pre-built too! The downside to this solution is that you can’t easily change the EEPROM contents without building a converter board or de-soldering the SMD from the assembly so it can be written on the programmer, and you’re limited to 4 slots.
2. A ROM switcher that uses an additional controller (usually Arduino) to give you an on-screen menu or even a separate physical control to handle the switching.

There is a PLCC solution that will let you switch the ROM with a little dial switch or jumpers built onto the board, and popping the chip out of the assembly and snapping it into an adapter that comes with the programmer. Getting replacement PLCC EEPROMS is a bit of a challenge and can be expensive. I mean, you can get them fairly cheap by the handful on Ali Express or eBay, but what you’re getting will be of dubious quality, and in some cases, outright re-badged fakes that aren’t even what they claim on the label.

DIP chips are more accessible, cheap, easier to handle, and usually use DIP switches, jumpers or physical switches soldered to the board to change the ROM to be loaded.

The PLCC project offers a simpler rotary surface-mount switch for selecting up to 8 kernals(!!) The downside? There are relatively few sources for a pre-built unit, they are all outside of the US (so shipping is slower and more expensive), and the project is not open-source, so it’s not easy to make your own. Ami64 has them, as does MyRetroStore. Ami64 will ship to the US, MyRetroStore will not. These were apparently made by a creator who goes by cece-mods, but now sells as CeceTechTools (Etsy) and again, still does not ship to the US. There is no main store that I could find, other than the resellers. Should I take one of mine apart and adapt it to use a SMD or DIP chip instead?

Of course, there are also some interesting cartridge-based options that make the whole affair almost plug-and-play with custom on-screen menus and everything. These are really cool, but also really expensive too, if you’re only wanting to swap the kernal. However, those devices have such a broad range of functionality that the asking price for them is actually quite fair.

Me. I’m going with the PLCC option because I bought one a while back, before I realized I’d hop between kernals more frequently. Initially, I had thought to drop in JiffyDOS and use that with my Pi1541, but again, some programs just don’t like it, and then when I discovered the TeensyROM, suddenly I didn’t even need to bother with speeding up disk load times at all. Now, I’m just looking for a cheap means to customize my kernal and leave it, taking advantage of the ability to modify the kernal, BASIC and character ROMs so I can do something truly unique with my Commodore 64, and yet still be able to fall back to the stock state whenever I need to.

What You Need

If you decided on one of the SMD “RESTORE key” mods, the installation and use process is usually quite simple, and they have solid instructions that arrive with them, as well. TheRetroChannel does a fantastic job describing (and selling!) these. You can get more info on those directly on his YouTube channel as well.

Hardware

Software

If you know what you’re doing with the hex code, then go nuts! Dream up a modification and make it happen cap’n! For the rest of us, here’s a walkthrough on some of the useful things you can change to suit your tastes and needs.

What to Change

If you have a good understanding of what you’re looking at, you can introduce or modify your own takes on actual kernal functionality, but honestly most of the really good and useful stuff has been done already. The point is that with these hardware components, you can easily run with an existing project, modify it a bit to make it your own, and drop that thing in place like it was always there. If you opt for one of the multi-ROM options, you can easily switch out for something different without having to swap the physical chips.

Also, you aren’t limited to swapping the kernal, either. You can also change the character set as well. Yep, you can change the font itself! Hey, shut up this was almost unheard of back in the day! Finally, you can also use modified versions of BASIC. Now that one can be a little fraught if you’re going to be running existing apps, but really cool if you have an idea for a program of your own that could take advantage of the modded and enhanced command set that an alternate BASIC version can provide.

The Fine Points

Now, you’ll need to remain aware of these binary file sizes, depending on your goal. If it’s about the kernals, those are 8kb each, and the switches on the projects above will be geared toward switching between focusing on 8kb windows of the total burned code. The problem with this is that if you want to use the concept for swapping character sets, those are only 4kb. There’s an easy way around the confusion that creates though. It will become clear what I mean in a moment

When you’re assembling your ROMs for burning, you want to do your edits to them (if any) first. Then you will make one big chunk of each of them to be burned to the chip as a single bundle.

In Windows, this is done with a simple command in the command prompt:

copy /b “kernal1.rom” + “kernal2.rom” + “kernal3.bin” + “kernal4.bin” assembled.bin

See how that works? You’re copying each of the ROMs (or BINs; they’re interchangeable for the most part, depending on where you got your sources), in order in binary mode (that /b switch), and outputting a single file called “assembled.bin”. The code for the kernal is exactly 8kb, so when it’s all done, you’ll have one big file where the end of the first kernal butts right up against the beginning of the next, but that switch on the board exposes one 8kb window of that code at a time, so as long as each kernal begins and ends in a predictable place in the final bundle, it will totally just work.

BUT, character sets are half of the size of a kernal, so if your switch exposes 8kb at a time, what do? The answer is deceptively simple: double up the ducks in the row! The command would look like:

copy /b “charset1.bin” + “charset1.bin” + “charset2,bin” + “charset2.bin” + “charset3.bin” + “charset3.bin” assembled..bin

You see, our ROM switcher projects only switch in 8kb increments. When it goes to load the character set, the Commodore is only going to take a 4kb mouthful of the code. It doesn’t matter if the same character set is repeated immediately afterward; it’ll be completely ignored. That second 4kb chunk could be filled with lorem ipsum; it simply doesn’t matter, because the only reason we need that second 4kb chunk is to ensure the next character set chunk starts where it’s expected to. So if each character set is repeated twice per switch “window”, the end result will turn out to be one character set accessed per switch (or jumper) position.

The way the Commodore’s architecture works relies on things being arranged in deference to the hardware’s expectations. There are no “files” with a beginning and end on those chips like text files on a thumb drive; the code is just one long string, but as long as all the expected elements are there in the order expected, it will just work in the end.

So that’s how you can make your Commodore 64 do things it never could have done out of the box!

One last point: if you’re making multiple variation ROM bundles, maybe make sure the first item in each bundle is the original, untouched version? That way you can roll back to stock configuration easily if you need to.

Burning It Down

So now you’ve got your modded ROMs assembled and ready to go, now it’s time to get them burned on the chips.

For my 8-in-1 board, because the rotary switch only exposes 8kb windows at a time, and because of the way the board re-routes a couple of the chip legs to conform to the Commodore’s expectations, we cannot actually reprogram the PLCC while it’s mounted on that board, so it needs to come off the C64 mainboard, first.

---

We will need to extract the chip, using the funky extractor tool that came with the programmer. You’ll see little notches in the corner of the chip’s socket where you can insert the extractor prongs. Those prongs are hooked, and are meant to hook underneath the PLCC chip itself, while squeezing the extractor arms will cause the body of it to push against the PLCC socket, creating a levering force to help the extraction. Shuffle the prongs down into those slots, then squeeze the extractor just a little bit to start putting upward pressure on the chip. Don’t squeeze like you’re trying to break a walnut; things can go pear-shaped fast if you use too much force. Instead, just put a little pressure on it, then wiggle it like you would a pair of tweezers to gently shuffle the PLCC chip out of its socket.

---

Now that the chip is out, pay close attention to its markings. Orientation matters, and you’ll want to make sure it’s installed on the programming adapter in the right orientation. Look for the notch on the chip that indicates the top edge. Orient this to align with the special indicator notch on the PLCC socket, which should be at top left. Line the chip up over the socket, and with it sitting on top of the contacts, push it home gently. It may take a little nudging, but it will go in if you ensure it’s lined up properly first.

---

Once it’s in the socket, we can now mount the whole adapter into the programmer device, ensuring it’s sitting in the topmost slots, before locking it in place.

---

Now, connect the programmer to your computer via the USB A-B (printer-type) cable, then launch the programming application. I use XGPro, which you can get from a handy Github archive, rather than flailing about the manufacturer’s (sketchy) native language site.

In XGPro, you’ll first need to select the programmer device you’re working with

Then, you will need to select the proper chip so it knows what it should be looking for when it comes time to actually communicate with your EEPROM. Click in the box under “Select IC”, near the top of the screen, and select “WINBOND” under the Manufacturers panel (yeah I know it reads “Manufactory”, it’s still obvious what they intended), then locate and select “W27C512 @PLCC32”.

Naturally, if you have a different variant, then be sure to choose the correct one. More often than not, it makes a big difference with these things.

---

Now, click the little green-outlined button called “READ”, and in the window that pops up, click the Read button near the bottom. You should see confirmation of successful communication and reading of your chip!

---

So, at this point, you now have a full “dump” of the current contents of your chip. If this chip is new to you, maybe export this and save it for later, just in case? It’s not like it’s that big. 😀 Click on Back in the Read window, then you can go to to SAVE, give the file a name and a place to store it.

---

Now, click on LOAD, and navigate to where your assembled kernal bundle is stored.

If you spent enough time rummaging around the hex editor previously, you might recognize the opening bytes of your first kernal variant.

---

Now, click on the PROG. button in the top menu bar, and then click the Program button in the Chip Program dialog that just opened.

Wait a few moments and watch the progress bar as those bytes get laid down on the chip all smooth and organized-like. When it’s done, the program will emit a high-pitched chirp/beep. I don’t know why they insist on deafening their users like that, but do beware it’s a thing with this program.

When it’s all done, you can close the program and disconnect the programming device from your computer.

---

Now reverse the chip movement process, to mount it back on the switcher board you pulled it from originally.

Drop it back in the Commodore’s mainboard and select one of the alternate kernal slots.

Plug it all back in and fire it up. SWEET!

Small admission here: the kernal alteration I made only affects the first line of text, and the background/border/text colors. Replacing “READY.” with “RDY />” is done by modifying the BASIC ROM, and the apparent font change was done using an alternate character ROM. In my longboard C64, that’s essentially swapping out three dedicated chips for changeable ROMs.

Now What?

Well, have some fun with it! You can now build and swap out code to make the system entirely your own.

However, you are NOT relegated to opening the case every time you want to make a change. There is a way to do this without all the unplugging of cords and loosening of screws every time, and without resorting to buying a Final Cartridge III!