This is more than a novelty. The project shows what it takes to get modern-ish game code running on a device that Microsoft only ever meant to run managed XNA games. It also comes with real setup caveats, covered below.
What the project is (and isn't)
The repository describes itself as a port of sm64ex to the Zune HD. In the developer's words, it "plays (mostly) at full speed with sound, touch controls and saves." That is the author's own characterization. Tom's Hardware notes that no official frame-rate figure exists and that some lag appears when the Zune can't keep up.
It is not an N64 emulator. It is a native build of the community decompilation-based PC port. Three points matter:
- The repository contains no game assets and no ROM, and it offers no prebuilt game. You need a legally dumped Super Mario 64 ROM with an exact checksum.
- The README specifies the USA version, with SHA-1 checksum 9bef1128717f958171a4afac3ed78ee2bb4e86ce, and the build checks it. Other ROM versions are not listed as supported.
- The project asks people not to request a ROM or a built game.
What you need
The README's requirements are specific:
- A Zune HD and its USB cable. Only firmware 4.5 has been tested so far.
- An x86-64 Linux computer with Docker and Git, 6 GB of free disk space, and an internet connection for the first build.
- The README says building and deploying use Docker, and no bare-metal workflow is currently provided.
Windows readers should note that nothing in the instructions covers building on Windows. Tom's Hardware makes the same point about Docker on Linux. A Windows PC could in principle host a Linux environment, but the project doesn't document that, so treat it as untested.
Build and deploy steps
The README gives four commands:
git clone [GitHub - rsheldiii/sm64-zune: Super Mario 64 (sm64ex) for the Zune HD, built from your own ROM · GitHub](https://github.com/rsheldiii/sm64-zune)cd sm64-zune./sm64zune build path/to/your-rom.z64./sm64zune deploy
The first run takes five to ten minutes. It creates a build container image and asks before it downloads the compilers and other files. Deployment is a separate container that installs the finished package over USB. Close any app running on the Zune first.
Troubleshooting from the README
- Deploy says "not installed": close whatever is running on the Zune and unplug it. Plug it back in, wait for the "connected" screen, then run deploy again. Details are in the deploy log. Docker must be able to pass a USB device to a container, and the README says the usual rootful Docker can.
- The game closes as soon as it starts: the copy was most likely cut short, so deploy again.
- The game stops with a message: the message names the build and two addresses. A bundled Python 3 tool turns those into function names, and the author asks for an issue report with them.
- Getting a log: the Zune can't hand over files over USB, so a logging build sends its log over Wi-Fi when you exit the game. Unplug the Zune because its Wi-Fi is off while on USB. A crash can't upload its own log. A later successful run sends it.
Playing it
The touchscreen overlay replaces the N64 pad. Tom's Hardware says it offers a stand-in analog stick plus A, B, Z, R, four C buttons and Start. Build-time settings include:
- Button style: hidden, outline or filled. Filled is the default.
- Opacity: 10 to 100 percent, with 80 as the default.
- Frame skip: never, sustained or always. The default is sustained. "Never" slows the game down like the N64 would, while the other settings skip some drawing when the Zune falls behind.
- Logging and profiling: off by default.
To quit, hold three fingers on the screen for two seconds. According to Tom's Hardware, the game renders at 480x272 in landscape and runs game logic at 30 ticks per second. Audio runs on its own higher-priority thread, so a slow frame rate shouldn't hit it. Those figures come from Tom's Hardware's reading of the project, not from independent testing here.
How the port works
This is the part that will interest Windows developers and retro tinkerers.
- Native code via OpenZDK. The README says the game runs as native code through OpenZDK, while third-party games normally go through Microsoft's XNA. The Zune only starts XNA programs, so the package includes a small OpenZDK XNA launcher that starts the native game.
- A legacy compiler. The Zune-specific layer and the game sources are compiled with Microsoft's 2008 ARM compiler under Wine, inside the Docker image.
- Precompiled shaders. The README says the Zune's graphics driver can't compile shaders, so they are compiled ahead of time with NVIDIA's Tegra tools. Tom's Hardware adds that the renderer is an OpenGL ES 2 design derived from Fast3D with prebuilt shader variants. It says blending is baked into the fragment shaders because the GPU lacks fixed-function blending. I couldn't confirm those finer details in the README overview, so treat them as Tom's Hardware's description.
- Downloads. The build fetches about 24 MB of Visual C++ 2008 ARM compiler files from Microsoft's Visual Studio 2008 trial ISO. It also fetches 6 MB of OpenZDK 4.5 headers and libraries, 36 MB of NVIDIA tools from the Tegra 250 Windows CE 6 platform pack, and 0.4 MB of Khronos headers. Each download is verified against a SHA-256 value in the project's fetch tool.
Tom's Hardware says the port applies 14 patches to a pinned sm64ex version.
Risk, licensing and legal context
The README says the firmware isn't modified. It also says OpenZDK was never supported by Microsoft and that you use the port at your own risk. The project is not affiliated with Microsoft or Nintendo.
The project's own code is MIT-licensed. The Fast3D-derived renderer's license forbids distributing a built game that contains assets you have no right to distribute. That explains why the repo ships no binaries and, as of the capture, no releases.
The wider landscape is also relevant. Tom's Hardware recalls that Nintendo's lawyers moved against sites hosting compiled copies of the 2020 PC port. Build-it-yourself projects like this one try to stay clear of that by keeping the copyrighted material out of the repository.
Background on the Zune HD
Tom's Hardware reports that the Zune HD launched in 2009 at between $219.99 and $289.99, depending on capacity, with an Nvidia Tegra APX 2600 chip. It describes the OS as Windows CE-based, and says Microsoft stopped production in 2011.
The report credits an exploit with leading to OpenZDK and homebrew. It also speculates that AI tooling may be driving more ports, since the first commit credits Claude. That is an inference from a commit message. It doesn't tell us how much of the code an AI wrote.
Takeaways
- Fun, not mainstream. The device is 17 years old and only firmware 4.5 is reported tested.
- Build, don't download. The path is Linux plus Docker plus your own USB-connected Zune and your own ROM dump.
- Performance is unquantified. "Mostly full speed" is the author's phrase, with no benchmark behind it.
- The engineering is the story. A 2008 ARM compiler under Wine, precompiled Tegra shaders and an unofficial SDK are what make this work. A Zune that once mostly played music now runs a 3D platformer, at the cost of a lot of workarounds.
If you still have a Zune HD in a drawer, this is a decent excuse to charge it. Just be ready to dump your own cartridge.