SpaghettiKart: a native Mario Kart 64 port that needs your own ROM

What SpaghettiKart actually is, and who it is for

SpaghettiKart is a source port of Mario Kart 64 maintained by HarbourMasters, the group behind the Ship of Harkinian project. It is written in C and built on libultraship, the same rendering and resource layer used by their other ports, which is why the repository carries a libultraship submodule and a powered-by badge in the README.

The audience is narrow and the README is honest about it. The project does not include any copyrighted assets. You are required to provide a supported copy of the game, and the only supported version is the US ROM. That single constraint filters out most casual users before they reach the download link. If you own a PAL or Japanese cartridge, or a ROM from an unknown source, this port is not aimed at you.

What you get in return is a native binary rather than an emulator wrapper. The release history shows a 1.0.0 tag dated 2026-02-25, following 0.9.9.1 and 0.9.9 in November 2025, so the project has crossed out of its early alpha numbering. The last push to the repository was on 2026-09-16.

How the ROM becomes mk64.o2r

The mechanism is an asset extraction step, not a patch. Spaghettify reads your ROM, pulls the game's data out of it, and writes an archive in the project's own .o2r format. The README calls this generating the O2R from the ROM, and the resulting file is named mk64.o2r.

That archive is what the runtime loads. Custom assets follow the same path: the README states that custom assets are packed in .o2r or stored .zip files, and that you place them in the mods folder. There is one compatibility boundary worth noting, printed as a standalone warning in the README: .otr archives are not supported in SpaghettiKart. Anyone arriving from another libultraship-based port with a collection of .otr files will find they do not load here.

The Switch workflow exposes the split between extraction and playback most clearly. You run one of the PC releases to generate mk64.o2r, then copy the file to the SD card. The console build does not do the extraction itself.

Installing SpaghettiKart on Windows, Linux or Switch

There is no package manager step. The README points to the Releases page, and after that everything happens inside the extracted folder.

Before anything else, verify the dump. The README gives a single accepted hash for the US ROM and suggests checking it with the SHA-1 File Checksum Online tool at romhacking.net/hash.

SHA-1: 579C48E211AE952530FFC8738709F078D5DD215E

If that matches, confirm the file is in .z64 format. Dumps in .n64 format must be converted first; the README links to the swapper tool at hack64.net/tools/swapper.php.

On Windows, extract every file from the zip into a folder of your choosing and run Spaghettify.exe, then select your US ROM. On Linux the equivalent binary is spaghetti.appimage, and the README notes two prerequisites: the zenity or kdialog package must be installed, and you may have to chmod +x the appimage from a terminal.

chmod +x spaghetti.appimage
./spaghetti.appimage

After the extraction completes, the README's Play step is simply to launch Spaghettify.exe again. On Switch, generate mk64.o2r on a PC first, then copy it to the SD card.

Once running, the default keyboard mapping puts A on Shift, B on Ctrl, L on Q, R on Space, Z on Z, Start on Enter, the analogue stick on the arrow keys, C buttons on TGFH, and the D-pad on Num 8 2 4 6. F11 toggles fullscreen, Tab toggles alternate assets, Ctrl+R resets, and Esc opens Settings.

Graphics backends and the crash workaround

SpaghettiKart supports three rendering APIs: DirectX11 on Windows, OpenGL on all platforms, and Metal on macOS. The README states that the default is DirectX 11 with id 2 on Windows and Metal with id 4 on macOS, and that you switch between them in the Settings menu of the menubar, which requires a restart.

The interesting part is the fallback path. If the game crashes, the README offers a manual edit instead of the menu. You open spaghettify.cfg.json, find the line beginning with "Backend":{, and change the id value to 3 with the Name set to OpenGL.

"Backend": {
  "id": 3,
  "Name": "OpenGL"
}

That is a reasonable escape hatch, but it also tells you something about the project's maturity: when the graphics layer misbehaves, the documented recovery is to hand-edit a config file rather than to fall back automatically. The README does not describe any automatic backend detection or retry, and it does not document a rollback if the edited config makes things worse.

Mods, texture packs and the .otr boundary

Modding is a folder convention. Custom assets go in the mods folder, either as packed .o2r files or as stored .zip files. The README points to an official gamebanana page for the game, and to the project's documentation site for anyone who wants to create and pack their own .o2r files.

The .otr restriction is the practical trap. Several ports in this family use .otr as their archive extension, so a user who has been collecting assets across projects will reasonably assume they carry over. They do not. The README states the incompatibility in bold, which suggests it has come up often enough to warrant the emphasis.

What the README does not cover is asset precedence. If two mods touch the same texture, or if a .zip and an .o2r both provide the same file, the documentation is silent on which one wins. For a single texture pack that is fine. For a stack of overlapping mods it is guesswork, and the Tab key that toggles alternate assets is not explained beyond its one-line table entry.

Where SpaghettiKart stops: online, mobile and other platforms

The README documents no online multiplayer. Nothing in the Quick Start, Configuration or Modding sections mentions netplay, and the only multiplayer-adjacent detail is the split-screen control mapping for a local SDL gamepad. Treat the port as a local-play build until the project says otherwise.

Platform coverage is desktop plus Switch. The nightly links cover Windows 64-bit and 32-bit, Linux 64-bit and 32-bit, macOS arm64 and Intel, and Switch. There is no Android, iOS or Vita build in that list, and the README does not discuss those targets. The repository does contain a Dockerfile, but it is a build environment for compiling the project, not a runtime container for playing it.

The nightly builds carry their own warning. The README describes them as for playtesting only and says you will likely encounter bugs and possibly crashes. That is the correct framing for continuous integration output, but it means anyone chasing a recent feature should expect to trade stability for it.

SpaghettiKart compared with the recomp route

The obvious alternative for playing Mario Kart 64 natively is a static recompilation project, which translates the original console binary into C and compiles it. SpaghettiKart takes the other path: it is a hand-written port built on libultraship, with its own asset archive format and its own mods folder.

The difference shows up in what you can change. A recompilation tends to preserve the original code's structure, so modifications are made against translated original functions. SpaghettiKart owns its source tree, which is why it can offer a Settings menu with selectable graphics backends, a mods folder with .o2r archives, and a documented asset extraction step that produces a separate data file. The cost is that the port has to reimplement behaviour rather than inherit it.

The ROM requirement is similar either way. Both approaches need you to supply the game data, and neither ships copyrighted assets. If your goal is the most faithful reproduction of the original binary, a recompilation is the closer match. If your goal is a build with a mod pipeline and swappable renderers, SpaghettiKart is the one that exposes those as first-class features.

Licence, maintenance and what a fork costs you

The repository does not state a licence in the available documentation. The GitHub metadata lists the licence as unknown, and the README contains no licence section. That is a real gap if you plan to redistribute a build, bundle it in a package, or ship it on a storefront. The README's only related statement is that the project does not condone piracy, which addresses ROM distribution rather than the port's own code.

Maintenance looks current rather than dormant. The last push was on 2026-09-16, and the releases run from 0.9.9 in November 2025 through 1.0.0 in February 2026. Nightly builds are published for six desktop targets plus Switch, which implies a working CI pipeline rather than occasional manual uploads.

The upgrade cost is tied to the asset archive. Because mk64.o2r is generated from your ROM rather than downloaded, a new release may require regenerating it with the matching Spaghettify binary. The README does not state whether archives are forward-compatible across versions, so keeping the original ROM dump and re-running extraction after an upgrade is the safe habit. Mods in the mods folder are separate files and are not described as versioned against the engine.

Editorial conclusion

Adopt SpaghettiKart if you already own a US Mario Kart 64 cartridge, can dump it to .z64, and want a native desktop or Switch build with a mods folder and three selectable graphics backends. Skip it if your only copy is a PAL or Japanese ROM, if you expect online multiplayer, or if you want a mobile build: the README documents none of those. Verify first that your dump matches SHA-1 579C48E211AE952530FFC8738709F078D5DD215E and that it is in .z64 format, because those two checks decide whether Spaghettify can produce an mk64.o2r at all.

Frequently asked questions

Official sources

1. HarbourMasters/SpaghettiKart on GitHub
2. Issues
3. Project website
4. README
5. Releases