A fan-made replacement firmware called OM64 is in development for ModRetro’s M64 hardware. Created by developer fulviov from the M64 schematics that ModRetro has published, the project aims to replace the device’s stock firmware with a more customizable operating environment.

That is an interesting milestone for the M64’s community, but it comes with a very large asterisk: OM64 is experimental, is not yet publicly available, and does not currently include a Nintendo 64 core. The developer is working on that core, with a public download planned only after it is ready and the firmware is considered stable enough for broader testing.

In other words, this is not a new way to start playing N64 games on the M64 today. It is an early look at what an independently built firmware stack could bring to the platform once its central feature is complete.

What OM64 is trying to replace

Firmware is the low-level software that lets a piece of hardware start up, present its interface, communicate with connected devices and run its intended functions. On a game-focused FPGA machine such as the M64, firmware is especially consequential because it can shape how users select cores, change video modes, pair controllers and install updates.

OM64 is positioned as a complete alternative to the factory firmware rather than a small add-on. Its development follows ModRetro’s earlier publication of the M64’s schematics, while the official firmware itself has not yet been open-sourced. Schematics are technical diagrams describing the hardware’s electronic design. They can give independent developers a foundation for understanding how a device is put together, but they are not the same thing as having the original software code.

That distinction makes OM64 notable. The project has been built from the published hardware information rather than by waiting for official firmware code to arrive. It also means the software should be treated as its own independent work, with its own development path, feature set and risks.

Features currently listed for OM64

The current build already outlines a more flexible front end than a bare-bones boot menu. Its listed capabilities include:

  • A graphical loader with skins and themes.
  • Separate loader operation: the loader runs as its own core, an approach intended to avoid consuming FPGA resources needed by the active console core.
  • Video-output choices at 720p, 1080p and 4K.
  • Video modes described as Buffered, Low Latency and VRR.
  • Wi-Fi networking, including over-the-air updates.
  • Bluetooth controller support.
  • Game Boy and SNES cores, currently used to test core switching and the broader platform.

Those items describe an ambitious foundation, particularly because a firmware replacement has to handle more than launching one system. A graphical loader is the menu layer users interact with: it is where themes, browsing and settings would live. A core, in this context, is the hardware-logic configuration used to reproduce a particular console platform on the FPGA.

Related coverage includes OM64 Custom Firmware Nears Public Testing for ModRetro’s M64.

The decision to keep the loader in a separate core is therefore more than an interface detail. FPGA resources are finite. Keeping menu functionality separate from the console core is intended to leave the active console implementation with as much of that resource budget as possible. That is a design decision with practical value, although its real-world results will depend on the eventual N64 core and the software’s maturity.

Video settings: what the labels mean

OM64’s proposed video options are broad, but the terms are worth separating because they refer to different things.

720p, 1080p and 4K are output resolutions. They describe the signal being sent to a display, not necessarily the original resolution at which a retro game was designed or rendered. A higher output setting can be useful for matching a modern television or monitor, but it should not be read as a promise that every game is internally rendered in that resolution.

Buffered video generally refers to a mode that uses buffering to help manage the timing of video frames. Low Latency emphasizes reducing delay between an input or rendered frame and what appears on screen. These are competing priorities in many display pipelines: reducing delay can be desirable for responsive play, while buffering can help smooth delivery under certain conditions. The source material does not specify OM64’s exact implementation, so users should avoid assuming performance characteristics until the firmware can be tested publicly.

VRR, or variable refresh rate, is a display feature intended to let a compatible display vary its refresh timing in step with the incoming video signal. The useful takeaway is simply that OM64 intends to offer the mode; compatibility and behavior will depend on the eventual build and the user’s connected display equipment.

Why the Game Boy and SNES cores matter, even without N64

The absence of an N64 core is the most important limitation of OM64 at this stage. Yet the included Game Boy and SNES cores still serve a clear developmental purpose. They are being used to test core switching and the underlying platform, which means they can help exercise the loader, system transitions, controller support and related firmware functions.

Core switching is exactly what it sounds like: moving from one console implementation to another within the system environment. Building that framework before the headline core is complete can help establish how the platform will behave across different uses. It does not turn OM64 into a finished M64 replacement, but it does show that the project is addressing system-level behavior rather than only focusing on one emulation target.

For retro players following FPGA developments, the M64’s eventual N64 core remains the decisive piece. Until it is present and publicly testable, the most accurate description of OM64 is a promising experimental framework rather than a finished Nintendo 64 solution. Readers interested in the wider hardware lineage can also browse our NES action-game coverage.

Connectivity could make the project easier to maintain

Wi-Fi and over-the-air, or OTA, updating are among OM64’s listed features. OTA updates mean software can be delivered through the device’s network connection instead of requiring a separate manual transfer process each time an update arrives. For experimental firmware, that could be particularly useful: frequent revisions are common while bugs are found and features are adjusted.

Bluetooth gamepad support likewise aims at convenience, allowing compatible wireless controllers to connect without a physical cable. However, the presence of a feature on a development list should not be confused with a guarantee of universal controller compatibility or finished behavior. The available information confirms the intended support, not a compatibility matrix or test results.

Experimental means accepting genuine risk

The developer’s own warning deserves to be the headline for anyone considering OM64 when it eventually becomes downloadable: installing it could brick an M64.

“Bricking” is the informal term for leaving a device unable to boot or function normally after a failed or incompatible software change. Firmware has an unusually direct relationship with a device’s startup process, so installation errors and unfinished code can have consequences that a typical app crash does not. OM64 is described as experimental now and likely to remain experimental at its initial release.

There is an important mitigating detail: users can revert to the original M64 firmware if OM64 does not meet their needs. Still, a rollback path should not be mistaken for a reason to ignore the warning. Anyone who ultimately chooses to test early firmware should read the developer’s documentation carefully, understand the recovery process before beginning, and avoid treating an experimental release as a no-risk upgrade.

For most owners, the practical move is patience. Wait for the promised public-testing build, look for clear installation and restoration instructions, and let the initial round of feedback reveal where the rough edges are. The feature list is compelling; the current status is still developmental.

AI-assisted development is openly disclosed

Fulviov has also said that Codex and Claude assisted OM64’s development, characterizing those tools as a way to speed up the work. The developer has been direct that people fundamentally opposed to AI use in software development may not want this particular firmware.

That disclosure does not independently establish the quality, security or stability of the code. Those questions will rest on the software itself, the quality of testing, documentation and future maintenance. But it gives prospective users information they may consider when deciding whether to participate in public testing or follow the project from a distance.

What to watch next

The next meaningful OM64 milestone is not a menu theme or an additional output option. It is the arrival of the Nintendo 64 core, followed by a firmware build stable enough for public testing. The developer expects distribution through an official Ko-Fi page once that threshold is reached, but no public release date has been provided.

For now, OM64 is best understood as an independent effort to show what can happen when published hardware schematics give a community developer room to build. Its interface, output modes, networking and cross-core testing indicate a serious attempt at a full system experience. Its missing N64 core and acknowledged brick risk are equally essential parts of the story. Both can be true: the project is technically intriguing, and it is not ready to be treated like routine consumer software.