The Zune HD was supposed to carry your music. Seventeen years later, someone has persuaded it to carry Mario around a 3D world instead.
A fan project by programmer rsheldiii brings Super Mario 64 to Microsoft’s 2009 media player, complete with touch controls, sound and saved progress. Tom’s Hardware highlighted the port on 11 October, sending a wonderfully unlikely piece of old hardware back into the conversation.
The interesting bit goes well beyond the joke of a Nintendo game on a Microsoft music player. Getting it working meant finding ways around a very particular collection of old software tools, graphics limitations and a screen that thinks it is facing the other way.
It is a native port, rather than an emulator
The project builds on sm64ex, a PC-port codebase, and uses OpenZDK to run native code on the Zune HD. Instead of asking an emulator to reproduce a Nintendo 64 around the game, the port adapts the game to the handheld’s own environment.
That distinction explains why the developer spent so much time dealing directly with its compiler and graphics driver. The music player is doing the work locally; this is not a video of Mario being streamed from another machine.
There are some firm boundaries. The repository does not include Nintendo’s game assets or a finished game to download. The build requires the user’s own US-version ROM, and the project’s licence separates its own files from game material and other components.
It is a hobbyist port, with none of the documentation suggesting an official Nintendo or Microsoft release.
That little player had surprisingly capable hardware
In its original 2009 teardown, iFixit found a 3.3-inch OLED display and NVIDIA Tegra hardware inside the Zune HD. That helps explain why a developer might look at the device and see more than a forgotten playlist machine.
The porting notes describe an ARMv6 processor with hardware floating-point support, Windows CE 6 and an OpenGL ES 2 graphics driver. The screen offers 480 by 272 pixels for this landscape game, but the underlying display is wired as a portrait panel.
Consequently, the software has to rotate positions, viewports and clipping regions. Even deciding which way up to draw the world becomes part of the job.
Small screens also change how a familiar game feels. The project supplies touchscreen controls, with adjustable visibility and opacity. There is no physical Nintendo 64 controller attached to the front of the player, so the interface needs to fit around the action already occupying that compact display.
A modern compiler was not automatically better
One of the stranger details sits in the launcher. According to the developer’s notes, a version built with Visual Studio 2008 works, while compiling the same source with a current C# compiler caused it to close immediately on the device.
The working launcher is therefore retained. For this project, replacing an old tool with a newer one could break the exact behaviour needed to start the application.
The game code brought another mismatch: modern C features meeting Microsoft’s older ARM compiler. The port uses compatibility work and a set of fourteen patches, with the first group addressing compiler requirements and the later group reducing processing and drawing work.
This is the less glamorous side of a delightful demo. Before anybody can enjoy an unexpected jump across a game level, the developer has to make very different generations of software agree on basic instructions.
Graphics needed preparation before the game started
The Zune’s graphics driver cannot compile the shader language that this port would otherwise use at runtime. Shaders are small programs involved in producing the image, so that missing capability is a substantial obstacle.
The project instead prepares the required shaders during the build, using NVIDIA tools, then loads the resulting binaries on the device. It also handles blending through the shader rather than relying on a graphics function that does not work as expected on this hardware.
Other optimisations reduce repeated effort. The documented changes include keeping drawing work together when the same texture remains in use and combining skybox tiles so fewer separate drawing calls are required.
These are targeted adjustments for this particular device, rather than evidence that every old media player could run the same game after a quick install.
Smooth music and smooth animation are separate problems
The port gives sound synthesis its own higher-priority thread. The developer explains that a slow visual frame should slow the game rather than interrupt its music in the same way.
Sound data is also read through at startup after initial loading caused delays in the first notes. Those details matter in a game whose atmosphere depends on audio staying coherent while the scene becomes busier.
For input, the touchscreen is sampled separately, with extra handling intended to preserve brief taps between game updates. A tiny touch should not simply disappear because it arrived at an inconvenient moment.
The documentation describes game logic running at thirty ticks a second and settings for skipping rendered frames. That does not establish a locked thirty frames per second across the entire game. The README’s performance claim comes from the project, rather than an independent benchmark of every level.
This remains a project for people who enjoy tinkering
The documented setup uses Linux, Docker, build tools and USB deployment. It supports Zune HD firmware 4.5; compatibility with earlier firmware has not been established. The porting observations also come from testing one device.
Those details make it a different proposition from downloading a new game onto a current handheld. Even transferring the package has quirks, including a changed USB address when the player reconnects and Wi-Fi being unavailable while it is connected over USB.
Still, the appeal is easy to understand. An obsolete music player has become a small working demonstration of patient engineering: keeping the useful hardware, understanding its oddities and reshaping the software around them. The surprise is Mario appearing on the screen. The achievement is everything that had to happen before he could move.
Sources & further reading
Prepared with AI assistance from linked reporting. The cover is an AI-generated editorial illustration. Spotted something we should correct?