Why We're Protecting Your Commodore 64 Ultimate FPGA

Hello Community! Last week, we released our first firmware update for the Commodore 64 Ultimate, and our objective was crystal clear: to unlock 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 dig deeper and put your concerns to rest.

What's Really Happening?

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 stops 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. Instead, they're modifications that run on top of it. We don't consider that to be in the same category, and 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. 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. The author of any such patch bears full responsibility for its behavior on your hardware, and as such, they will need to provide the support.

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

What's happening with this future update isn't about creating walled gardens to keep outside developers away from our systems. 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 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. Problems our team had no hand in creating, nor the ability to diagnose. That isn't sustainable, and it isn't fair to the users who come to us expecting help for other things.

The mechanism we're implementing will prevent non-Commodore FPGA-level firmware builds from being installed on the Commodore 64 Ultimate. We're still considering alternative approaches and evaluating which path best balances user freedom with user protection, and we welcome your input on that.

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. Protecting the firmware is how we make sure every future update lands safely on every unit out there, and we have a lot of updates still to come!

- Marc Bilodeau, Chief Technology Officer