Super Mario Galaxy on a Game Boy Advance is the kind of sentence that sounds like it should end with “in your dreams.” Instead, Tobias Friedly, also known for Game of Tobi projects, is building a playable handheld reinterpretation that starts with a player’s own copy of the USA version of Super Mario Galaxy.

This is not presented as a ready-made game image containing Nintendo’s material. It is a project that users build locally. The process takes a legally obtained .iso disc image, verifies and unpacks the necessary original data, then constructs the required models, animation, textures, audio, music and text during the build. The result is intended to run on the Game Boy Advance, a machine from well before the Wii era that naturally cannot match the original game’s visual fidelity or hardware capabilities.

That limitation is not a footnote; it is the whole reason the project is fascinating. A blockier version of Galaxy running on the GBA is not trying to convince anyone that the two systems are peers. It is an engineering exercise in translating the feel and content of a 3D Wii adventure to radically different hardware, while keeping the original game data on the owner’s side of the process.

A rebuild, not a conventional port

“Port” is convenient shorthand, but it can imply that an existing game simply moves intact from one system to another. That is not what the available details describe here. Friedly’s approach relies on a GBA engine by Joshua Barettos and a recent decompilation effort for Super Mario Galaxy, then uses a player-provided game dump to rebuild compatible assets and game data for the handheld target.

A decompilation project is an effort to translate a compiled game program back into human-readable source code or an equivalent understandable codebase. Retail games are normally distributed in machine code: instructions meant for a console’s processor, not for people to conveniently study or modify. A decompilation makes the game’s logic more accessible for research and rebuilding work. It does not make the original hardware suddenly more capable, and it does not eliminate the substantial task of making that logic function on another platform.

Likewise, an engine is the foundational technical framework that handles the pieces a game needs to run: rendering graphics, receiving input, managing sounds, loading data and coordinating gameplay systems. In this case, the GBA engine is the bridge that lets the project target Nintendo’s older handheld rather than the Wii hardware for which Galaxy was designed.

The practical effect is a version that has to make hard compromises. The project is visibly less detailed than the Wii original, with more angular, simplified visuals. That is expected. The significant claim is not that it reproduces the original presentation at parity, but that it provides a playable Super Mario Galaxy experience on Game Boy Advance hardware at all.

Why the build process matters

Friedly’s project is designed around users supplying their own legally acquired Super Mario Galaxy USA disc image. The build instructions specify that the file should be placed in the project folder and named baserom_us.iso. On Windows, where Explorer may hide extensions, users need to take particular care not to accidentally create baserom_us.iso.iso.

Related coverage includes Super Mario Galaxy Is Being Rebuilt for Game Boy Advance.

During a first build, the tools download a disc utility called nodtool, unpack the user’s disc image, check that needed files match the original game, and construct the assets for the GBA project. That verification step is meaningful: it indicates that the builder expects a particular original version and is checking the supplied files rather than treating any similarly named image as interchangeable.

For players, this means the project is less plug-and-play than a normal fan patch or homebrew download. It requires a compatible disc dump, a development environment and some comfort with a terminal. The payoff is that the project does not need to bundle a prebuilt copy of the original game’s data.

That distinction is also useful beyond the legal framing. A local build is transparent about what is being transformed and where it comes from. The user provides the base material, while the project provides the code and conversion process that make a GBA-oriented version possible.

What users need to prepare

The supplied instructions cover macOS, Windows through Windows Subsystem for Linux (WSL), and Ubuntu or Debian Linux. In all cases, prospective builders need their own USA Super Mario Galaxy disc image and the project files. They will also need development tools, including devkitPro, a development toolchain commonly used for Nintendo handheld and console homebrew work.

On macOS, the documented route begins with Terminal and Apple’s developer tools, followed by devkitPro’s package installer. On Windows, the setup uses WSL and Ubuntu rather than a purely native Windows workflow. The project folder and the game image are copied into the Ubuntu environment, with a note that building from the Windows C: drive can work but may be slower.

On Ubuntu or Debian, the process follows broadly the same tool setup as the Windows/WSL route, but in a regular Linux terminal. Once the disc image has the correct name and is in the correct folder, the builder runs the project’s build command. The initial run can take several minutes because it needs to obtain nodtool, extract the disc contents, validate the required files and generate the converted assets.

A sensible checklist before starting

  • Use a legally acquired USA copy of Super Mario Galaxy as the required .iso input.
  • Confirm the filename is exactly baserom_us.iso.
  • Install the applicable developer tools and devkitPro environment for the operating system.
  • On Windows, use the WSL/Ubuntu workflow specified by the project rather than assuming a standard Windows command prompt setup will work.
  • Allow extra time for the first build, which performs downloading, unpacking, verification and asset construction.

The instructions are technical, but the project’s open approach makes them easier to inspect rather than treating the build as a black box. The engine code and the game-side code are available for examination. That matters for hobbyist developers who want to understand the mechanics of a large-scale conversion, not merely see the finished novelty running in a video.

Open code does not erase the hardware gap

There is a temptation to describe projects like this as though they have somehow “beaten” the original platform. The reality is more interesting. A rebuild is a negotiation with limits. The GBA version has to express the game within a far lower-performance environment, which explains the visibly reduced geometric detail compared with the Wii release.

That does not make it a lesser technical achievement. It defines the achievement. Building a game for weaker hardware requires deciding what can remain recognisable, what needs to be recreated differently and what must be simplified. Models, animation, textures, sound, music and text all have to be processed into forms the target implementation can handle.

For a player, the immediate attraction is obvious: the prospect of a Galaxy-style adventure on a portable machine. For developers and preservation-minded tinkerers, the more durable attraction may be the method. The code is available to review, the build consumes an owner’s original game data, and the system requirements are spelled out across major desktop environments.

It also sits comfortably alongside a growing interest in alternative software environments for portable gaming hardware. For a contemporary example of that broader scene, Retroid’s expanded Linux support for several handhelds shows why transparent tools and flexible platforms continue to attract enthusiasts. Friedly’s GBA project is a much more specific undertaking, but it is powered by the same enthusiasm for seeing familiar game ideas work in unexpected technical places.

The important caveats

Potential builders should set expectations carefully. This is not described as a replacement for the Wii game, and its visual presentation should not be judged against the original as if both were designed for identical specifications. The source material explicitly acknowledges the huge power difference between the platforms. Its GBA adaptation is therefore a demonstration of adaptation and resourcefulness, not an attempt to duplicate the Wii experience without compromise.

It also requires the USA version of the game image specified by the project. That version requirement is not arbitrary housekeeping. Since the builder checks extracted files against expected original data, a different regional release or improperly prepared image may not meet the project’s requirements.

Finally, a user should distinguish between the project code and the original game content. The publicly inspectable code makes the technical work visible, while the build instructions place responsibility for the game image with the user. Anyone interested should follow the project documentation closely and ensure that their copy and dump are legitimate.

Why this particular experiment stands out

There are plenty of retro-hardware curiosities that last only as a headline: a familiar logo booting, a menu appearing, a brief scene cut together for a showcase. This effort is more compelling because the stated goal is a playable version, supported by a build system that reconstructs the needed components from a player’s own copy.

It is also unusually clear about its foundations. Friedly credits the GBA engine work by Joshua Barettos and the recent Super Mario Galaxy decompilation that helped enable the project. That kind of acknowledgement helps explain that ambitious fan work is often cumulative: one developer’s engine, another community’s code research, and a creator willing to do the conversion work can combine into something no single piece would produce alone.

So, no, the Game Boy Advance has not secretly transformed into a Wii. But a carefully built, openly inspectable adaptation can still bring a remarkably unlikely game concept to a much older handheld. In a medium where “impossible demake” is often used loosely, the build-first approach gives this Super Mario Galaxy project a concrete technical identity—and a practical path for appropriately equipped owners to explore it themselves.