BizHawk: a multi-system emulator built around TAS tools, not just play

What BizHawk actually solves, and for whom

Most emulators optimise for one console and one goal: play the game. BizHawk optimises for reproducing a play session exactly, frame by frame, and then changing it. The README describes EmuHawk as a multi-system emulator written in C#, and says the recording, playback and debugging tools make it "the first choice for TASers (Tool-Assisted Speedrunners)". That is the whole thesis of the project. Everything else, including full screen and joypad support, is table stakes.

The audience splits in two. The first group is tool-assisted speedrunners and the people who verify their movies: they need deterministic playback, savestates, frame stepping and rewinding, and an input file that can be replayed years later on the same core. The second group is romhackers and reverse engineers who want a memory viewer, a search and edit tool, and a scripting hook into the emulated hardware. Casual players can use it, and the feature list mentions 10 save slots and hotkeys, but they are not the reason the project exists.

Bespoke cores in C#, plus a C++ outlier and waterbox

BizHawk does not wrap libretro cores by default. The README lists A7800Hawk, Atari2600Hawk, C64Hawk, ChannelFHawk, ColecoHawk, GBHawk, IntelliHawk, NesHawk, O2Hawk, PCEHawk, SMSHawk, TI83Hawk, VectrexHawk and ZXHawk as bespoke emulation cores written in C#, with MSXHawk written in C++. That naming convention is the clearest signal of the architecture: each system gets a Hawk core maintained inside this repository rather than pulled from an upstream project.

The repository layout backs this up. The top level contains directories such as psx/, lynx/, quicknes/, libmupen64plus/, wonderswan/ and waterbox/, alongside ExternalCoreProjects/, ExternalProjects/ and LibretroBridge/. Some cores are vendored from elsewhere, and LibretroBridge exists to reach libretro cores that were never reimplemented in C#. waterbox is the sandboxing layer used to run native code from managed code, which is how a C# frontend hosts emulation code that was not written in C#.

The trade-off is maintenance surface. A frontend that owns its cores can guarantee that savestates, memory domains and Lua bindings behave consistently across systems, which is exactly what TAS tooling needs. It also means each core's accuracy and bug list move at its own pace, and a fix in one Hawk core does nothing for another.

Installing on Windows and getting to a first frame

Windows installs from a zip. The README points at the releases page and says to click `BizHawk-<version>-win-x64.zip`, extract it anywhere, and keep each version in its own folder rather than mixing versions. It also warns that moving or renaming the folder is fine as long as all files stay together, and that SmartScreen or third-party antivirus may block the first launch. As of 2.10 the only prerequisite named is the MSVC++ redistributable.

There are no ROMs and no firmware in the archive. You supply the game image and, for disc-based or add-on systems, the BIOS files, through the firmware management feature the README lists. The repository ships no copyrighted content, and the README does not document where to obtain it.

Once EmuHawk.exe runs, the path to a first session is short: load a game image, confirm the core the frontend picked, then open the hotkey configuration to bind a gamepad. The README's feature list includes format, region and integrity detection for game images, so the frontend normally selects a core for you.

Linux packages, Nix and the macOS gap

The README's Unix section says to install the listed package with your package manager, and the badges link to the relevant package pages. Distribution packaging is the supported route on Linux; there is no upstream tarball install documented in the README.

For reproducible builds the README advertises Nix support and the repository carries `default.nix` and `shell.nix` at the top level, so a Nix or NixOS user can build from source through those expressions rather than a distro package.

macOS is the awkward case. The README's jump list labels the macOS entry "macOS (legacy BizHawk)", which is a strong hint that what is documented is the older 1.x line, not the current 2.11.x releases. Anyone searching for a current BizHawk on macOS should read that section carefully before assuming the latest release applies. There is no iOS or Android build documented in the README at all.

Rerecording, Lua and the C#.NET hook

The feature that separates BizHawk from a general emulator is input recording. The README lists input recording, savestates with 10 slots plus infinite named savestates, speed control with frame stepping and rewinding, and memory view, search and edit across all emulated hardware components. Those four together are the loop a TAS author lives in: rewind to a frame, change an input, play forward, compare.

The second hook is programmatic. The README states that core and frontend can be controlled with Lua or C#.NET. Lua is the practical entry point for scripted input, memory watch expressions and automated checks; C#.NET is for tools that need to live inside the solution, and the repository has a dedicated ExternalToolProjects/ directory for that style of extension. The Dist/ and ExternalToolProjects/ entries in the tree are where external tooling is expected to sit.

This is also where BizHawk's weight shows. A scripting host and a memory-domain abstraction per core add overhead and complexity that a player-only emulator does not pay for.

Where BizHawk is the wrong tool

Accuracy and breadth are not the same thing, and BizHawk's supported list has visible edges. The README lists PlayStation (PSX) and Saturn, but nothing from the PS2 generation, and no GameCube or Wii. If your library is mostly sixth-generation consoles, BizHawk is the wrong frontend regardless of how good its tooling is.

The second limit is the platform matrix. Windows and Linux are the documented targets, macOS is labelled legacy, and there is no mobile build. Users searching for BizHawk on Android or iOS will not find one here.

The third is the maintenance model. The repository is not archived and the last push was on 2026-09-20, with 2.11.1 released on 2026-05-01. That is recent activity, but it is concentrated in a project that maintains many cores at once. A bug in one Hawk core can sit while the team works on another system, and there is no upstream core maintainer to escalate to, because the core lives here.

Finally, casual users pay a cost for features they will not use. A frontend with a scripting host, a full input mapper and a memory editor is a larger surface than a single-console emulator, and the README's own advice about keeping versions in separate folders reflects that.

BizHawk against RetroArch's core model

The obvious comparison, and the one people search for, is RetroArch. RetroArch is a frontend over libretro cores: the emulation code comes from many upstream projects, and the frontend stays thin. BizHawk inverts that. Its default cores are written for it, in C#, and the frontend knows about their memory domains, savestate formats and input timing in a way a generic libretro frontend cannot assume.

That difference decides the choice. If you want the widest console coverage and a uniform interface across many upstream cores, RetroArch's model gives you more systems and more frequent core updates from independent teams. If you want deterministic input recording, rewinding and a memory API that behaves the same way across the systems you care about, BizHawk's model is the one built for it. BizHawk does reach libretro cores through LibretroBridge, so the split is not absolute, but the bridge is an escape hatch rather than the main path.

Licence and the cost of upgrading

The repository reports the licence as NOASSERTION, which means GitHub could not classify the LICENSE file automatically. The README's jump list has a License section, so the authoritative answer is in that file rather than in any summary. Read it before you redistribute a build or bundle a core, since emulator projects commonly mix licences across vendored components, and BizHawk's tree includes vendored directories such as libmupen64plus/ and quicknes/ that may carry their own terms. Nothing here is legal advice.

Upgrade cost is low in principle and slightly higher in practice. Releases are versioned (2.10, 2.11, 2.11.1) and the README explicitly says not to mix versions, so an upgrade is a fresh folder plus your configuration and firmware paths. The changelog lives on TASVideos, not in the repository, so release notes are the place to check for core changes before you move a long-running project. The README does not document a rollback procedure, and it does not promise savestate compatibility across versions, so keep the old folder until a movie or savestate has been replayed successfully on the new one.

Editorial conclusion

Adopt BizHawk if you record input, write Lua or C#.NET tooling against emulated memory, or need debugging views that most standalone emulators do not expose. Do not adopt it if you want a single portable binary for phones, or if your target system is not on the supported list. Before committing, check the release page for the current 2.11.x archive, confirm your system appears in the README's supported list, and verify that the firmware your core needs is something you can supply legally, since BizHawk ships none.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. TASEmulators/BizHawk on GitHub