On Kernal Switchers

The Kernal is the low-level “operating system” of the Commodore 64. The functions it provides are the basis for higher level routines in Basic and most other software running on Commodore’s 8-bit machines. In case of the C64 it comes in the form of an 8k ROM chip or as part of a 16k ROM chip in later versions. So the good news is, the Kernal is immune to corruption though any kind of malware. The bad news is, there is no easy way of updating or replacing it although Commodore’s original Kernal leaves a lot of room for improvement.

Kernal ROM from a C64.


Replacing the Kernal means replacing the ROM chip — desoldering the original IC first in many cases and installing a socket. When going through all those troubles, it makes sense to install a new ROM that is bigger than 8k so it can hold several Kernal images at once. This of course then requires some kind of switch that allows selecting the desired Kernal before powering up the computer. Back in the old days, this was usually a mechanical flip or rotary switch that would be installed by drilling a hole into the case of the Commodore.

ROM adapter for up to 8 Kernals. The actual switch is not attached yet.

Nowadays, further perforating the cases of the valuable collectables is often frowned upon. So, different kinds of “switchless” Kernal Switchers have emerged. A very simple one, the “Switchless JiffyDOS” developed by Pasi Lassila uses a single D-type flip-flop connected to the reset line and the Restore key to switch between two different Kernals. Just power on the C64 to get the default Kernal, hold down the Restore key while doing so to get the other one.

The “Switchless Multi Kernal” created by Bwack develops this idea further by using a PIC microcontroller instead of the simple flip-flop, implementing a state machine. When the Restore key is held down while the C64 is running, the switcher enters Kernal selection mode. Subsequent short presses on the Restore key will then toggle through the different Kernals and trigger a reset after a short pause. In this setup, the red power LED of the Commodore is replaced with an RGB LED connected to the controller that will light it in a different color for each Kernal. Bwack has documented the development of his switcher in a series of videos:

The “SuperKernal” project then takes this idea to the extreme: It is built around the STM32F405 MCU clocked at 168Mhz and it does no longer require an EPROM to hold the Kernal images or any extra wiring of signals from the motherboard. Instead, it reads the address bus of the C64 and drives the data bus directly which means it is a drop-in replacement for the original Kernal ROM. This is a very impressive feat that also enables a variety of awesome features. Just to name a few:

  • 36 memory banks to be filled with with Kernal ROM images or PRG files
  • integrated user interface
  • direct upload of files, no need to open the C64 or to replace the EPROM
  • CBM80 cartridge emulation
  • optional WiFi support

All of this comes at a price, though. The first batch of the SuperKernal was priced at €49 and it quickly sold out. At the time of writing, there is no way to buy a new SuperKernal that I’m aware of. Unfortunately, in case of the SuperKernal neither the hardware nor the software are open source so there is no way to build your own.

In the Meantime…

There seemed to be a large gap between the Switchless Multi Kernal and the SuperKernal in complexity, features and price. So, I started some research of my own to see if I could come up with a new kind of switcher to fill that gap. The idea was to use the dirt-cheap STM32F103 MCU to build a Kernal switcher that would still need an external memory chip but that would not require any extra wiring.

STM32F103 dev board wired to the Kernal.

As expected, sniffing the address bus in real time and reacting to certain events turned out to be challenging even for the 32-bit MCU at 72Mhz. I think that detecting the reset procedure and reading data from the Commodore through the address bus would be doable, though.

Detecting the /CS signal on the Kernal.

But it would be very hard to properly drive the data bus in order to transfer data in the opposite direction. This might be a show-stopper for my original project goals.

And now…

Version 0.2 of the magicFlash64. MCU and Flash IC still missing.

So it was that I had not even come very far when Zschunky presented the “magicFlash64” in February 2019. This device is much larger than the SuperKernal and it requires the extra wiring of signals. Apart from that it offers all that I could wish for in a Kernal switcher:

  • a total of 64 8k slots for ROM images or PRGs
  • an integrated user interface
  • upload of images directly from the C64
  • open source
  • cheap and easy to build

The magicFlash64 installed on 250407 test board.

The MF64 is built around a ATmega MCU clocked at 20Mhz and an AM29F040 flash RAM. It is currently in beta testing phase and I was lucky enough to acquire one of the kits. By holding down the Restore key until the power LED of the C64 starts blinking, the user menu is activated.

The menu allows Kernal ROMs to be activated temporarily and PRGs to be loaded and run. Support for regular 8k cartridges is planned. The flash content of the MF64 is programmed and edited using a separate programmer tool. This tool can also be started from the menu, of course.

User menu of the magicFlash64.

There are a few issues that Zschunky is and has been working to resolve. The most serious problem that I encountered so far is the firmware on the ATmega getting corrupted from time to time. I hope that this will be dealt with in the next beta release.

But for the most part, the MF64 is already quite stable and working nicely. It is amazing work and a great contribution to the vintage computer community! The layout of the PCB will probably change in the final version so that it’ll fit better on the C64 short boards and there is a SMD version in the making. Zschunky plans to finalize his design by summer of 2019, if all goes well.


3 thoughts on “On Kernal Switchers

  1. I really love that you are thinkering with the stm32 and investigating reaction time. I am looking into this to on a videopac project. What compiler do you use? I think it might be possible to reduce the interrupt time or perhaps just poll for change and drop interrupts. Not sure yet. Thanks for linking to my video.

  2. Pingback: The NeoRAM Remix | hackup.net

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.