Why The ULC Audio Codec Is A Perfect Fit For The N64

Although the Nintendo 64 could deliver solid 3D graphics with assets loaded at a blistering speed from the game cartridge, audio-wise it was a bit more hampered. The main challenge here was that streaming PCM audio data from a roomy CD as on the PlayStation wasn’t an option, and using compressed audio samples was impaired by Nintendo’s refusal to open up more than the CPU for third-party codecs, leading to most N64 games using so-called ‘sound fonts’ that use sample-based tracks.

Once the N64’s RSP vector processor became available for use by developers it became possible to use MP3s without clobbering the CPU, but this was still an imperfect solution. In a recent article by [Dominic Szablewski] it is thus argued that the Ultra Low Complexity (ULC) codec might be a match made in haven for the N64 hardware.

This still uses the same modified discrete cosine transform (MDCT) as many lossy audio codecs including MP3 do, but the ULC code is designed to be extremely light-weight for decoding. [Dominic] first came across it in the form of an old Game Boy Advance demo that played a 70 kbps file with no issues on the 16 MHz ARM CPU.

Naturally the ULC codec’s creator [Aikku93] didn’t employ any unusual black magic to achieve this feat, mostly just foregoing some of the heavier elements of e.g. MP3 like splitting the signal into bands, and using a light-weight syntax to store transformed coefficients.

Here [Dominic]’s goal was to port the ULC code to work with the N64’s RSP so as to offload as  much of the decoding as possible. This required becoming extremely intimate with MIPS assembly, with [Dominic] eventually giving up and asking an LLM coding chatbot to translate bits of ULC C code to [Max Bebök]’s RSP language (RSPL) syntax instead.

The good news here is thus that the open source N64 SDK libDragon now has ULC support, just in case you want more than simple tracker-based music for your homebrew N64 game and do not feel like clobbering the RSP and CPU at the same time with something like MP3 or Ogg Vorbis.

Making Xibalba 64, A New N64 Release In 2026

[Dominic Szablewski] created something that we don’t see every day: a no-kidding new physical Nintendo 64 game for sale, complete with cartridge, manual, and box art. He wrote about what it was like to make Xibalba 64, a 3D FPS game built using his own game engine. It even supports two-player couch co-op and four-player deathmatch.

The N64 was a groundbreaking console that brought analog controls and fully 3D game worlds to mainstream console gaming. Architecture-wise it has its share of quirks, including a tiny (4 kB!) amount of texture memory to go around all that fancy 3D content.

Xibalba was originally a demo game for [Dominic]’s MIT-licensed game engine, high_impact. Turning it into a full-fledged title for the N64 meant revisiting all sorts of things from level and gameplay design to sound and music. [Dominic] talks about it all, including the fact that his engine is technically for 2D content but he makes it work for the 3D game by ensuring levels have no elevation. Since levels are flat, the engine never has to deal with a dimension beyond its understanding. Xibalba 64 even maintains a stable 60 frames per second, dipping somewhat only in four-player split-screen.

The N64 still gets a lot of action from dedicated enthusiasts, and there’s no need to start from scratch if you find yourself with a retro gaming itch and a desire to push a vintage console in directions it never knew. For example, we’ve seen an open world game engine for the N64, complete with long drawing distances that didn’t seem possible on the hardware.

How Resident Evil 2 For The N64 Kept Its FMV Cutscenes

Originally released for the Sony PlayStation in 1998, Resident Evil 2 came on two CDs and used 1.2 GB in total. Of this, full-motion video (FMV) cutscenes took up most of the space, as was rather common for PlayStation games. This posed a bit of a challenge when ported to the Nintendo 64 with its paltry 64 MB of cartridge-based storage. Somehow the developers managed to do the impossible and retain the FMVs, as detailed in a recent video by [LorD of Nerds]. Toggle the English subtitles if German isn’t among your installed natural language parsers.

Instead of dropping the FMVs and replacing them with static screens, a technological improvement was picked. Because of the N64’s rather beefy hardware, it was possible to apply video compression that massively reduced the storage requirements, but this required repurposing the hardware for tasks it was never designed for.

The people behind this feat were developers at Angel Studios, who had 12 months to make it work. Ultimately they achieved a compression ratio of 165:1, with software decoding handling the decompressing and the Reality Signal Processor (RSP) that’s normally part of the graphics pipeline used for both audio tasks and things like upscaling.

Continue reading “How Resident Evil 2 For The N64 Kept Its FMV Cutscenes” →

The Latest Advancements In Portable N64 Modding

[Chris Downing] has been in the mod scene a long time, and his 5th GeN64 Portable is his most modern portable Nintendo 64 yet. The new build has an improved form factor, makes smart use of 3D printing and CNC cutting, efficiently uses PCBs to reduce wiring, and incorporates a battery level indicator. That last feature is a real quality of life improvement, nicely complementing the ability to charge over USB-C.

What’s interesting about builds like this is that it’s all about the execution. The basic parts required to mod a classic games console into a portable unit are pretty well understood, and off-the-shelf modules like button assemblies exist to make the job far easier than it was back in the day when all had to be done from scratch. We’ve admired [Chris Downing]’s previous builds, and what differentiates one mod from another really comes down to layout and execution, and that’s where the 5th GeN64 Portable shines. Continue reading “The Latest Advancements In Portable N64 Modding” →

Java Is Now On The Nintendo 64!

Whether it’s your favorite programming language, or your favorite beverage, there’s no denying Java is everywhere. Now, it’s even on the Nintendo 64, thanks to the valiant efforts of [Mike Kohn]. Even better, he’s coded a demo to show off its capabilities!

The project took plenty of work. [Mike] went all the way down to the assembly level to get Java code running on the N64. The project builds on the work that he did previously to get Java running on the PlayStation 2. Notably, both the Sony and Nintendo consoles do have some similarities — both are based on MIPS CPUs.

The demo itself is a work of art. It features the typical “3 billion devices run Java” screen, followed by some truly chunky bass and wailing guitar sounds. It’s followed by all the dancing shapes, sinusoidal text, and bright colors you could shake a stick at.

For those interested in the nitty gritty, [Mike] delves deep into the details of what it took to get everything running. That includes both using the code in an emulator, as well as how to get it going on real Nintendo hardware, something we’ve looked at before.

Continue reading “Java Is Now On The Nintendo 64!” →

What Do You Get When A Raspberry Pi Pico Flashes A Nintendo 64

The joke was when the Nintendo 64 first hit the streets around a quarter century ago, that the 64 in the name referred not to the technology on board, but to the excessive cost of the cartridges. Whatever the truth in that, it’s something now completely laid to rest by [Konrad Beckmann] with his Nintendo 64 flash cart powered by a Raspberry Pi Pico (Nitter Link).

The schematic is surprisingly simple, in that the Pico does everything required to both interface to the N64 and to an SD card to hold the software. The clever work is done by the RP2040 firmware, which can be found along with the hardware details in the “develop” branch of the project’s GitHub repository. And while the earliest version was a Raspberry Pi Pico with a host of jumper wires, the more polished version focuses on a custom PCB and bare RP2040 chip.

Perhaps the N64 hasn’t received the attention it should have over the years, overshadowed as it was by its competitors such as the original PlayStation, but it’s projects like this one which remind us that there’s still life in Nintendo’s ’90s flagship. Speaking of which, if you were on Team Sony back in the day but still want to put your Pi Pico to use, check out this DIY PlayStation Memory Card we covered recently.

Realtime Shadows On N64 Hardware

Although the Nintendo 64 console has in the minds of many been relegated to the era of ‘firmly obsolete graphics’, since its graphic processor’s (GPU’s) lineage traces directly to the best which SGI had to offer in the 1990s, it too supports a range of modern features, including dynamic shadows. In a simple demo, [lambertjamesd] demonstrates how this feature is used.

As can be seen in the demonstration video (linked after the break), this demo features a single dynamic light, which casts a shadow below the central object in the scene, with a monkey object floating around that casts its own shadow (rendered into an auxiliary frame buffer). This auxiliary buffer is then blended into the main buffer, as explained by [ItzWarty] over at /r/programming on Reddit.

This effectively means that the main scene uses a shadow volume, which was used extensively with Doom 3. The primary reasons for why the N64 didn’t use shadow volumes all over the place was due to the limitations this places on the shadow caster (objects) in the scene, such as the need to be convex, and overlap is likely to lead to artifacts and glitches.

Doom 3 would fix this with the use of a stencil buffer that would further refine the basic dynamic lighting support on the N64, which ultimately would lead to the fancy video game graphics we have today. And which no doubt will look properly obsolete in another decade again, as usual.

Continue reading “Realtime Shadows On N64 Hardware” →