GitHub Gems

VKRT NES Remaster: C++20 NES Emulator Source Released on GitHub

VKRT NES Remaster has published an independent C++20 NES emulator source distribution on GitHub, pairing hardware-faithful emulation with an optional visual remaster mode.

Illustration of a retro grey NES-style controller beside lines of C++ source code on a dark background
Photo: GitHub

A new public source distribution of VKRT NES Remaster, a native Nintendo Entertainment System emulator written in C++20, has been posted on GitHub. According to the repository page on GitHub, the project was authored by Francisco Triemstra, who works under the VKRT name, and it pairs a standards-based emulation core with an optional visual remaster mode for Windows users. The release is an independent copy of the product and does not include the author's private development history or internal tooling.

What the repository contains

The repository describes itself as an emulator-independent source distribution. It is meant for people who want to read, build and study the code, not as a finished consumer download. GitHub lists the project under the name VKRT NES Remaster, and the page makes clear that the private software environment used to build the original product is not part of the public release.

The published material focuses on what a developer needs to compile and check the software. It includes build instructions, deterministic test gates and provenance notes. Historical internal milestone documents from the original product were deliberately left out, according to the repository text.

An emulation core separate from the visuals

The most important design rule in the project concerns the separation between emulation and presentation. The repository states that the CPU, picture processing unit, audio processing unit, cartridge and mapper logic, controller handling and timing state are the authoritative parts of the system. Display paths are only allowed to read observations of that state. Presentation, in other words, cannot alter the underlying emulation.

This approach matters for anyone who cares about accuracy. Many enhanced or upscaled game displays blur the line between what the console actually computed and what a modern renderer has added. By keeping the two layers apart, the project aims to make it clear which visual changes are cosmetic and which parts of the machine's behaviour are being reproduced.

Original and Remaster modes

The Windows frontend offers two presentation choices. Original, mapped to the F1 key, shows the game as the console would have displayed it. Remaster, mapped to F4, applies what the repository calls semantic observation and bounded presentation methods. The text says these methods do not rely on external commercial artwork. Earlier F2 and F3 rendering experiments are not counted as supported modes.

The application also includes a Home screen, ROM selection, audio settings and input facilities. Keyboard configuration, optional XInput controller navigation and saved settings are covered by automated tests, according to the repository.

A Metroid-specific profile

One optional visual profile is designed for a Metroid game. The profile can be selected when the software recognises a specific ROM fingerprint. The repository is explicit that this distribution contains no Metroid ROM, artwork or soundtrack, so users would need to supply their own legally obtained files.

Build requirements and testing

Building the project requires Python 3, CMake 3.20 or newer, Ninja for the listed commands, and a compiler that supports C++20. Once the build is complete, the Windows executable can be launched from the build folder and opened at its Home screen.

The author reports that the original independent Windows packaging passed 41 of 41 CTest tests. The repository adds an important caveat: that result applies to that packaging, and the exact commit now published should be validated separately with its own recorded results. Passing automated tests is also not presented as proof of real-device audio quality, full playability or broad game compatibility.

  • Required tools: Python 3, CMake 3.20 or newer, Ninja and a C++20 compiler
  • Test and demo tools use synthetic, generated NES inputs rather than commercial games
  • No commercial .nes or .fds ROM files are included

Licensing and attribution

The project is licensed under the Attribution Assurance License, which the repository describes as OSI-approved. The license requires a prominent author credit to appear when a distributed binary that incorporates or depends on the covered code is launched. The required credit names Francisco Triemstra, VKRT, with a link to the author's GitHub profile.

The repository also notes that preserving this attribution does not mean VKRT endorses any downstream product. Contributors may keep credit for their own changes. Anyone redistributing the source must include the signed license notice, and anyone distributing a compiled executable is responsible for implementing and checking the launch-time attribution themselves.

The repository further says that the implementation follows publicly documented hardware concepts and contains first-party code. It also states that the project has no affiliation with Nintendo or other commercial game publishers. It cautions that it has not performed an exhaustive legal or text-similarity audit against every earlier implementation.

Limits and what comes next

The repository is careful not to overstate what the software can do. It makes no claim of universal compatibility, cycle-perfect timing or support for every NES title. A full acceptance test covering real hardware, audio and playability, along with a broad compatibility survey, is described as separate work that has not been implied by the current test results.

For developers and retro enthusiasts, the release is most useful as a readable reference for an emulator built around a strict separation between hardware state and display output. Those who want to run it will need to bring their own legally obtained game files. Anyone planning to distribute a built version should study the attribution requirements before doing so.

The coming months will show whether the project attracts outside testers and contributors who can extend the compatibility picture and validate the exact published commit. For now, the repository offers a clearly documented, openly licensed example of an NES emulator whose remastered visuals are built on top of, rather than in place of, the console's own state.

Source: GitHub

Comments (0)