TriCNES: a cycle-accurate NES emulator that exists to play TAS files

The emulator was built to test one very specific theory

TriCNES, or Coin's Contrabulous Cartswapulator, is a Nintendo Entertainment System emulator written by Chris "100th_Coin" Siebert with a focus on test-driven accuracy. The README explains that the emulator was originally made in order to experiment with a theoretical arbitrary code exploit the author created titled "Intercycle Cartridge Swapping", where the NES cartridge is replaced every CPU cycle in order to run custom code. That exploit was later verified to work on real hardware by a YouTube user named Decrazyo. So the project began as a research instrument rather than a player, and that origin explains the whole shape of the tool. The repository was built from the ground up starting from a blank .NET WinForms project, and the file listing shows the conventional parts of a WinForms application, with `Program.cs`, `Emulator.cs`, a `TriCNES.csproj`, `Forms/` and `forms/` directories, and `Properties/`.

It does not do audio, and it only takes TAS input

The Limitations section is short and blunt, and it is the first thing to read. The emulator does not produce audio. It only accepts inputs in the form of a TAS file, which the README notes is fixed in the dev build. And it can only run NTSC cartridges properly. That is a short list, but it removes the emulator from the category of general-purpose NES emulation. There is no gameplay, no controller input, and no sound, so a comparison with something like a general NES emulator frontend is not really meaningful, because the two are solving different problems. This is a verification tool. The audience is a TAS author, a hardware researcher, or anyone who needs a deterministic, cycle-accurate reference machine rather than a game.

Mapper support is a fixed list, and half of it is still in the dev build

The supported mapper chips are enumerated in the README, and the parenthetical annotations are the interesting part. The list covers mapper 0 NROM, mapper 1 MMC1, mapper 2 UxROM, mapper 3 CNROM, mapper 4 MMC3 with MMC6 support in the dev build, mapper 7 AOROM, mapper 9 MMC2 in the dev build, mapper 66 GxROM in the dev build, and mapper 69 Sunsoft FME-7. Famicom Disk System is partially supported in the dev build. So a large fraction of the mapper coverage exists only in the development build rather than the released one. If your ROM uses a mapper outside that list, or uses one of the dev-build-only entries and you are running the release, it will not run properly. The presence of a `mappers/` directory at the repository root suggests each of these is implemented as a separate unit, and the file `6502Documentation.cs` suggests the CPU core carries its own reference notes.

TAS file formats from six different tools, and no sync guarantee

The supported TAS file types list covers a wide range of the TAS ecosystem, and the caveat at the top of the section is the important part. Due to varying emulator accuracy, the emulator is not guaranteed to sync all TAS files. Despite this, it supports loading inputs from several formats. In the dev build there is .3c2, the TriCNES format, and .3c3, the TriCNES TAS Timeline format. Then there is .bk2 from Bizhawk, .tasproj from Bizhawk's TAStudio, .fm2 from FCEUX, .fm3 from FCEUX's TAS Editor, .fmv from Famtasia, and .r08 from Replay Device. Loading a file is not the same as syncing it, and the difference between those two things is the accuracy question, which is exactly what the emulator was built to study.

The .3ct format is a cartridge swap script

Beyond the imported formats, the emulator loads the author's own intercycle-cart-swapping format, .3ct, and its structure is simple enough to read. The first line is an integer indicating how many cartridges are used, called n. The following n lines are local file paths to the ROMs, which sets up an array of cartridges. The remaining lines until the end of the file are in the format "x y" where an integer x is separated from an integer y with a space, and when the TAS is played back, before CPU cycle x the emulator swaps to the cartridge at index y. A worked example:

5
Super Mario Bros. [!].nes
Dash Galaxy in the Alien Asylum (U) [!].nes
Kung Fu (JU) [!].nes
Pipe Dream (U) [!].nes
Super Mario Bros. 3 (U) (V1.1) [!].nes
6 0
7 1
8 2
9 3
10 4

Five cartridges here, and before cycle 6 the emulator swaps to index 0, the first ROM, before cycle 7 to index 1, and so on. The format is a plain text description of a hardware-level timing experiment, which is a neat illustration of why an emulator that is cycle-accurate enough to swap a cartridge every cycle is a prerequisite for the original research.

A WinForms app with an SDL2 dependency

The repository listing gives the shape of the implementation. Beyond the WinForms pieces there is a `SDL2.dll` at the root and a `packages.config`, which is the NuGet dependency format used by older .NET Framework projects, along with `App.config` and an `App.config`-style `Properties/` directory. That combination places the project in the .NET Framework era of WinForms rather than modern .NET, and the `packages.config` approach is worth noting for anyone trying to build it on a current machine. The repository is MIT licensed with the LICENSE file at the root, the releases are v1.0.0 from 2025-03-13 and v1.0.1 from 2025-04-01, and the last push was on 2026-10-12, so the code is being worked on even though the published version is a 1.0 line from 2025.

Editorial conclusion

TriCNES fits a TAS author or a hardware researcher who needs a deterministic NES reference to test a theory against, especially anyone working on cartridge swapping tricks, since the .3ct format was built for exactly that. It is the wrong tool for playing games, since the README states it does not produce audio and only accepts inputs in the form of a TAS file. Before you rely on it for anything, check the mapper list against the ROM you care about, because several of the mappers are only in the dev build, and treat the claim of not guaranteeing sync on all TAS files as a real constraint rather than a footnote.

Frequently asked questions

Official sources

1. 100thCoin/TriCNES on GitHub
2. Issues
3. License: MIT
4. README
5. Releases