Cxbx-Reloaded-legacy: an Xbox emulator for Windows and Wine, not native Linux

What Cxbx-Reloaded-legacy emulates, and what it deliberately does not

This is an emulator for Microsoft Xbox games, with Chihiro described in the README as a future target rather than a current one. The scope is narrower than "an Xbox emulator" suggests: the project is a Windows application first. The README lists Windows 7+ x64 or x86-64 Linux with Wine as the supported configurations, states that 32-bit is not supported, that MacOS with Wine is known not to work, and that BSD-based systems are untested. The Linux/macOS section of the compiling instructions is a single line: "Currently not supported." That is the whole answer for anyone arriving from a Linux gaming setup.

The audience is therefore people with a Windows x64 machine and an interest in original Xbox software, plus a smaller group willing to run it under Wine on Linux and accept the instability the README warns about. It is not aimed at users who want a drop-in, fully abstracted emulator with guaranteed per-title behaviour. The project maintains a compatibility list on its website rather than claiming blanket support, and compatibility reports require permission requested through Discord, which tells you the project treats per-game status as community-curated data rather than a promise.

High-level kernel emulation with an LLE graphics path from XQEMU

The architecture visible in the README is a hybrid. Most of the emulator is the project's own work, described as "Kernel, HLE, etc", meaning the Xbox kernel and many system services are emulated at a high level: the emulator intercepts calls and reimplements their behaviour on the host instead of emulating the original hardware instruction by instruction. That is why the hardware requirements are stated in terms of Direct3D 9.0c, Pixel Shader Model 2.x and Vertex Shader Model 3.0 rather than in terms of CPU throughput for a full machine emulation.

The exception is graphics and networking. The README credits XQEMU for "the NV2A LLE and NVNet implementation", so the NV2A GPU and the network chip are emulated at a low level, cycle-adjacent to the original hardware, while the rest of the system leans on HLE. The practical consequence is that the graphics path is the part most likely to be sensitive to host GPU capabilities and driver behaviour, and it is also the part the project does not own outright. Symbol detection across different Xbox Development Kit builds is handled by a separate project, XbSymbolDatabase, and kernel accuracy is checked against the Xbox Kernel Test Suite. Those two dependencies explain how the emulator copes with retail titles built against different XDK versions: it detects symbols in the loaded executable and maps them to its own implementations.

Installing Cxbx-Reloaded-legacy on Windows x64

There are no stable builds. The README states this plainly and points to the download page on the project's website and to the GitHub CI build history for pre-release binaries. Before running anything, install the 32-bit (x86) Visual C++ 2022 Redistributable, since the emulator is a 32-bit process even on a 64-bit OS.

Npcap is required for network emulation, and the README instructs you to enable winpcap compatibility mode during installation. If you want to pass through original Xbox controllers or a Steel Battalion controller, a WinUSB compliant driver is needed; that step is marked optional.

# Download a pre-release build from the project's download page:
# https://cxbx-reloaded.co.uk/download
# Or pick a build from the GitHub Actions CI history.
#
# Prerequisite: install the 32-bit (x86) Visual C++ 2022 Redistributable
# https://aka.ms/vs/17/release/vc_redist.x86.exe
#
# For network emulation, install Npcap with winpcap compatibility mode enabled:
# https://nmap.org/npcap/#download

A first real use is loading a title and checking it against the compatibility list rather than assuming it will run. The project's compatibility site is where per-game status lives, and the README directs bug reports about specific software there, reserving the GitHub issue tracker for emulation problems that are not specific to one title. That split matters in practice: if a game fails, the compatibility site is the place to look before filing anything, and the issue template requirements are strict enough that the README notes non-conforming tickets are auto-closed.

Running it under Wine on Linux, and the version trap

Linux support exists only through Wine, and the README treats it as fragile. It recommends the latest stable Wine release, then says that if it does not work, roll back to Wine 7.0, described as the last known working version. It also links a known issue that prevents saving in some games on Wine 6.8 and later. That is an unusual amount of version-specific caution for a compatibility layer, and it tells you the Wine path is maintained reactively.

The setup uses Winetricks to install two things: vcrun2019, which the README notes requires the latest winetricks script, and d3dcompiler_47, which it warns may be subject to change. Winpcap, unlike on Windows, is built in and needs no separate installation.

# On x86-64 Linux, use the latest stable Wine.
# If it fails, roll back to Wine 7.0, the last known working version.
winetricks vcrun2019
winetricks d3dcompiler_47

The honest reading is that Wine is a fallback, not a supported platform. The README says Wine is "relatively unstable" and might break compatibility at any time without warning. If your only machine runs Linux, you are accepting that a Wine update can take the emulator down and that your remedy is to downgrade Wine rather than wait for a patch.

Where Cxbx-Reloaded-legacy is the wrong tool

The clearest failure mode is platform. If you need macOS, the README says Wine on MacOS is known not to work and BSD systems are untested. If you need a native Linux build, the compiling section answers with "Currently not supported." No amount of configuration changes that.

The second limitation is release discipline. The README states that Cxbx-Reloaded "doesn't currently have stable builds", and the releases visible in the repository are CI tags with hashed names, which is consistent with that. Anyone who needs a version they can pin for a long period, or who needs to know that an upgrade will not change behaviour, is in the wrong place. The project also notes that Debug builds are significantly slower and are only for developers, so the natural instinct to build from source in Debug mode produces a worse experience, not a better one.

The third is the graphics requirement. Direct3D 9.0c with Pixel Shader Model 2.x and Vertex Shader Model 3.0 is old, but it is a hard floor, and the LLE NV2A path is the part of the emulator most exposed to host GPU differences. A machine that meets the letter of the requirement can still produce graphics bugs, which is exactly why the README asks for screenshots when reporting graphical problems.

Finally, contribution has a boundary the README makes explicit: pull requests containing code derived from XQEMU will not be approved until an agreement is reached to make work mutually beneficial, including updates to existing XQEMU-derived code. If your plan is to improve the NV2A or NVNet paths by porting from XQEMU, that plan is blocked by policy, not by technical difficulty.

Cxbx-Reloaded-legacy against xemu

The comparison people actually make is with xemu, and the architectural difference is the point. Cxbx-Reloaded-legacy is predominantly HLE: it reimplements Xbox kernel and system behaviour on the host and uses XQEMU-derived LLE only for the NV2A GPU and NVNet. A low-level emulator in the xemu lineage takes the opposite emphasis, emulating more of the original machine and relying less on reimplementing individual software behaviours.

The trade-off follows from that. HLE can be faster and can sidestep hardware details, but it depends on correctly identifying what a title is doing, which is why this project leans on XbSymbolDatabase to detect symbols across XDK builds and on the Xbox Kernel Test Suite to validate kernel behaviour against real hardware. LLE avoids some of that per-title detective work but pays for it in host requirements and in the amount of hardware behaviour that has to be modelled faithfully.

There is also a licensing and governance difference worth noting: Cxbx-Reloaded-legacy is GPL-2.0, and its relationship with XQEMU is governed by an explicit agreement requirement rather than by the licence alone. The README's position is that the project should not become a hostile fork. If you are choosing between them, the compatibility list is the deciding artefact, not the architecture diagram.

Licence, maintenance and the cost of tracking CI builds

The repository is licensed GPL-2.0, with the licence file at COPYING. For anyone embedding or redistributing the emulator, GPL-2.0 is a copyleft licence and the obligations attach to distribution; this is a description of what the repository states, not legal advice, and the COPYING file is the authoritative text.

The maintenance picture from the repository metadata: the repository is not archived, and the last push was on 2026-05-22. The most recent releases listed are CI builds from April 2026, tagged with commit hashes rather than version numbers. The upgrade cost is therefore not "read the changelog and bump a version". It is "pick a CI build, test your titles, and keep the previous build around". Because the README says stable builds do not exist, there is no supported downgrade target other than an older CI artefact you saved yourself. The README does not document a rollback procedure.

On the Wine side the upgrade cost is sharper: the README names Wine 7.0 as the last known working version and links an open issue affecting saves in some games from Wine 6.8 onward. Upgrading Wine is the risky direction, and the documented remedy is to move backwards. For a user on Linux, that means pinning Wine and treating any distribution upgrade that pulls in a newer Wine as a change to test rather than a routine update.

Editorial conclusion

Adopt it if you run Windows x64, have a Direct3D 9.0c GPU with Pixel Shader Model 2.x and Vertex Shader Model 3.0, and are comfortable with pre-release CI builds whose behaviour can change between tags. Do not adopt it if you need native Linux or macOS support, since the README states Linux and macOS builds are not supported and macOS with Wine is known not to work, or if you require stable releases, because the README says stable builds do not currently exist. Before committing, check the compatibility list at cxbx-reloaded.co.uk/compatibility for the specific titles you care about, confirm your GPU meets the shader requirements, and if you plan to run under Wine start from the latest stable release and fall back to Wine 7.0 if it fails.

Frequently asked questions

Official sources

1. Cxbx-Reloaded/Cxbx-Reloaded-legacy on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases