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.

Reviving Mystery Nintendo 64 Game Cartridge Found In The Woods

As far as things go that you are likely to find during a relaxing walk in the forest, Nintendo 64 game cartridges probably do not rank high on that list. Yet this is what happened to a friend of [BlueBox Tinkers] a few years back, leaving him dying to see whether the cartridge would still work, as well as what game it is since its labels got obliterated courtesy of its time spent enjoying the outdoors. Fortunately he recently got a chance to see whether he could revive this cartridge.

The insides look pretty much like what you’d expect after presumably months or years of exposure, with the metal shield severely corroded. The PCB does however look pretty decent still, with obvious signs of corrosion on the front-side vias, and a pretty gross-looking back side.

Unfortunately it wasn’t confirmed whether this friend tried to stick this old cartridge into an N64 console, but [BlueBox Tinkers] wasn’t going to take any such chances. First up was an inspection and deep cleaning of the PCB, showing that it had escaped real damage, with the shield having taken the brunt of the corrosion. Cleaning up the shield and the insides of the plastic shell is by far the hardest part, with the pitted metal and rust stuck on the plastic. For a full restoration you’d probably want to for a reproduction shell and shield here.

Ultimately the game turned out to still work, with the mystery game sadly fairly predictable, but with someone’s old save files still intact. Somehow it seems that what Nintendo did to make N64 cartridges dust- and child-resistant also makes it survive in the woods, so if you find one during a forest walk, it’s totally worth it to adopt it and take it home.

Continue reading “Reviving Mystery Nintendo 64 Game Cartridge Found In The Woods” →

Running Windows CE On The Nintendo 64

Although Windows CE doesn’t use the NT kernel, it’s similarly designed to run on a wide variety of system architectures. Since the Nintendo 64 uses a MIPS CPU it should basically just run either kernel. You might assume that the N64’s rather limited specs are a bit of a problem, but fortunately Windows CE is designed to run on a digital potato, and requires only a MB of RAM. Since that just so happens to be what the N64 has under the hood, [Throaty Mumbo] was optimistic about getting Windows CE running on the 1990s game console.

The idea for this project came when [Throaty] was tinkering with an IBM Workpad Z50 laptop that uses almost the same CPU as the N64 and also runs Windows CE. Although said laptop is probably a lot more practical of a platform to run Windows on, this didn’t mean that it wouldn’t be a fun challenge.

Since CE was intended to be customized by companies for their own embedded hardware this means that you can use an official SDK, such as Microsoft Windows CE 2.11 Platform Builder. Making Windows CE 2.11 run on an N64 thus involves creating a board-specific configuration and compile that against said SDK.

If you want to give it a shot yourself, the entire project is available on GitHub which is where you find most of the technical details as well. When using a flash cart such as the EverDrive, you can also put applications on the SD card and run them from within the Windows GUI. You’ll still be limited by the N64 hardware, but otherwise the experience is very smooth as the video below demonstrates.

Continue reading “Running Windows CE On The Nintendo 64” →

Writing An Open-World Engine For The Nintendo 64

Anyone who has ever played Nintendo 64 games is probably familiar with the ways that large worlds in these games got split up, with many loading zones. Another noticeable aspect is that of the limited drawing distance, which is why even a large open area such as in Ocarina of Time‘s Hyrule Field has many features that limit how far you can actually see, such as hills and a big farming homestead in the center. Yet as [James Lambert] demonstrates in a recent video, it’s actually possible to create an open world on the N64, including large drawing distances.

As explained in the video, the drawing distance is something that the developer controls, and thus may want to restrict to hit certain performance goals. In effect he developer sets where the far clipping plane is set, beyond which items are no longer rendered. Of course, there are issues with just ramping up the distance to the far clipping plane, as the N64 only has a 15-bit Z-buffer, after which you get ‘Z fighting’, where render order becomes an issue as it’s no longer clear what is in front of what.

One fix is to push the near clipping plane further away from the player, but this comes with its own share of issues. Ergo [James] fixed it by doing two render passes: first all the far-away objects with Z-buffer disabled, and then all the nearby objects. These far-away objects can be rendered back-to-front with low level-of-detail (LoD), so this is relatively fast and also saves a lot of RAM, as the N64 is scraping by in this department at the best of times.

In the video the full details of this rendering approach, as well as a new fog rendering method, are explained, with the code and such available on GitHub for those who wish to tinker with it themselves. [James] and friends intend to develop a full game using this engine as well, so that’s definitely something to look forward to.

Continue reading “Writing An Open-World Engine For The Nintendo 64” →

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” →

Super Mario 64, Now With Microtransactions

Besides being a fun way to pass time, video gaming is a surprisingly affordable hobby per unit time. A console or budget PC might only cost a few hundred dollars, and modern games like Hollowknight: Silksong can provide 40-60 hours of experience for only around $20 USD. This value proposition wasn’t really there in the 80s, where arcade cabinets like Gauntlet might have cost an inflation-adjusted $8 per hour in quarters. This paradigm shift is great for gamers, but hasn’t been great for arcade owners. [PrintAndPanic] wanted to bring some of that old coin munching vibe into console gaming, and so added a credit system to Super Mario 64.

The project is a fork of a decompilation of Super Mario 64, which converts the original machine code into a human-friendly format so bugs can be fixed and other modern features added. With the code available, essentially anyone can add features into the game that weren’t there already. In this case, [PrintAndPanic] is using a Raspberry Pi connected to a coin slot, so when coins are put into the game like an old arcade machine, the Raspberry Pi can tell the modified version of Super Mario 64 to add credits. These credits allow the player to run and jump, and when the credits run out Mario becomes extremely limited and barely able to outrun even the slowest Bombombs and Goombas.

With some debugging out of the way and the custom game working, [PrintAndPanic] built a custom enclosure for the game and the coin slot to turn it into a more self-contained arcade-style machine. The modified code for this project is available on the project’s GitHub page for those who want to play a tedious version of a favorite video game that costs more money than it should.

There are plenty of other modifications for this classic as well, most of which involve improving the game instead of adding a modern microtransaction-based system.

Continue reading “Super Mario 64, Now With Microtransactions” →

The Nintendo 64DD, an N64 add-on released only in Japan in 1999.

Exploring Nintendo 64DD Code Remnants In Ocarina Of Time

What if you took a Nintendo 64 cartridge-based game and allowed it to also use a large capacity magnetic disc format alongside it? This was the premise of the Nintendo 64DD peripheral, and the topic of a recent video by [Skawo] in which an archaeological code dig is performed to see what traces of the abandoned product may remain.

The 64DD slots into the bottom of the console where the peripheral connector is located, following which the console can read and write the magnetic discs of the 64DD. At 64 MB it matched the cartridge in storage capacity, while also being writable unlike cartridges or CDs. It followed on previous formats like the Famicom Disk System.

For 1998’s Game of the Year title The Legend of Zelda: Ocarina of Time such a 64DD-based expansion was worked on for a while before being cancelled along with the 64DD. With this Zelda game now decompiled, its source code has shown to be still full of 64DD-related code that [Skawo] takes us through in the video.

Continue reading “Exploring Nintendo 64DD Code Remnants In Ocarina Of Time“ →