Why We're Protective Of Your Commodore 64 Ultimate FPGA
- Marc Bilodeau
- Apr 15
- 4 min read
Updated: 5 days ago

This article has been updated to clarify Commodore's position
Hello Community! Last week, we released our first firmware update for the Commodore 64 Ultimate, and our objective was crystal clear: to UN-lock more of what's possible on the C64U without compromising what our users love about it.
We've added USB mouse support, improved the BASIC editor, added music-detect mode for the Starlight and Founders Editions, and more! If you haven't read all the changes, you can find them here.
That said, we also mentioned an upcoming change that has raised concerns among some members of the Commodore community about preventing firmware not released by Commodore from being loaded onto the hardware.
So, let’s clarify this plainly: we are not going to lock the FPGA or stop the community from experimenting with machines they own.
What's Really Happening? - No FPGA Lock
The Commodore 64 Ultimate is not a static product. There will be new hardware revisions, new components, and new capabilities! This is foundational to our roadmap and, frankly, core to the Commodore 64 Ultimate's value proposition. But it also means that firmware built for a different board may not behave safely on ours. In other words, if deployed, it could lead to hardware returns and replacements due to actions entirely out of our control. This would have significant financial implications for Commodore, a brand that we know holds a special place in your heart.
Firmware authored by a third party, even a talented and well-intended one, simply cannot account for hardware changes that only we know, control, and plan for well in advance. The reverse is also true. Our firmware updates, optimized for the Commodore 64 Ultimate's evolving platform, could introduce incompatibilities with third-party products that haven't been updated to match. This isn't hypothetical. We've seen it already in recent community posts, after users performed updates with the wrong firmware and found their machines in a non-functioning state. Then they contacted Commodore. It's an engineering reality we need to get ahead of now, not after more units stop working.
What About Patches Like SPIFFY?
First, we applaud SPIFFY's efforts and would love to have a conversation with them. It's also the kind of ingenuity we want to foster and promote from developers. We're amazed by all the wonderful software and hardware being created by the community today, and look forward to seeing what's next, just like you.
However, we want to be clear about an important distinction. There is a meaningful difference between a temporary software patch and full replacement firmware that operates the system. Patches like SPIFFY are not permanent changes to the firmware. SPIFFY can be effectively uninstalled by re-flashing our firmware on top of it. But full replacement firmware designed for other systems, can break that flashing option itself - meaning you cannot then re-flash our firmware back on top. This is what makes SPIFFY non-permanent. We don't consider SPIFFY to be in the same category, and to be clear, this policy is not aimed at that kind of community-driven ingenuity.
That said, we want to be straightforward and transparent on our stance. Whilst we can and do allow you to use them, as you rightly should, we just cannot officially support patches we did not create or actively maintain - much like Apple would not repair an iPhone bricked during jailbreaking. If a third-party patch causes an issue with your Commodore 64 Ultimate, that will fall outside the scope of what our support or warranty teams can help with. Support for any such patch must come from its author or the community, not Commodore.
What About The Ultimate64 Firmware?
The FPGA board at the heart of the Commodore 64 Ultimate was designed by Gideon Zweijtzer, who first developed and sold his own version, the Ultimate64, and which is used by countless enthusiasts worldwide (I personally have one). Gideon is an important member of the Commodore team, serving as a systems architect and overseeing the ongoing development of the Commodore 64 Ultimate (including the update we just released).
This is not about creating a walled garden, locking the FPGA, or stopping the community from experimenting with their own machines. It's simply and primarily about two products that share a common origin but are forking down different paths.
Our hardware roadmap for the Commodore 64 Ultimate includes board revisions and component changes that Gideon's Ultimate64 firmware has no reason to address, since it's built for his product, not ours. As those two paths diverge, firmware designed for one is increasingly likely to cause costly problems on the other. The policy we mentioned in the recent changelog simply exists to get ahead of that divergence in these two products, before it costs someone else their system.
What To Expect Moving Forward
We hope this explains why we've taken the reasonable stance we did, and simply cannot provide support for firmware we did not build. We've already received support requests from users who loaded third-party firmware onto their Commodore 64 Ultimate and encountered issues. That isn't sustainable, and it isn't fair to the users who come to us expecting help for other things.
Having considered alternative approaches and evaluated which path best balances user freedom with user protection, we are not planning to block non-Commodore FPGA-level firmware from being installed on the Commodore 64 Ultimate. Instead, we will present a clear disclaimer that community-installed firmware, patches, or other modifications are used at the owner’s own risk, and Commodore cannot provide free support, free warranty service, or free replacement for units bricked or damaged as a result. We hope you'll agree that's a fair balance.
We know this might feel restrictive from a certain perspective, especially in a community built on tinkering. We get it. That spirit is why we're here, too. #WeAreCommodore. But our job is to make sure the hardware in front of you keeps working as it evolves, and we want to do that responsibly.
We built the Commodore 64 Ultimate for the same reason you bought one, because Commodore deserves more than nostalgia. It deserves active development. Providing clear guidance around unsupported firmware is how we make sure users understand the risks while remaining free to experiment, and we still have a lot of updates to come!
- Marc Bilodeau, Chief Technology Officer




Comments