Using The SNES Super FX Chip To Run Super Mario 64

Although the Nintendo 64 was the first to bring real 3D graphics to the table in 1996, the Super Nintendo had an ace up its sleeve in the form of the Super FX chip. One major advantage of using cartridge-based games is that you have the option to add wild features such as a 3D graphics chip to your SNES, something that got used to make games like Star Fox, and as [Tobi] demonstrates in a recent video, can also totally run Super Mario 64 if you squint a lot.

While there’s a rumor that Nintendo was looking to release a ‘Super Mario FX’ game for the SNES, there’s no evidence for such a project. Fortunately these days we got hobbyists prepared to give it a shake to see what a determined group of SNES game developers could have accomplished back then.

The pleasant surprise here is that although a new engine was needed, the SM64 assets could be used with this ‘SMFX’ game and it runs fairly well. There is still room for performance improvement, and the 2 MB memory limit is a problem that may require some culling of parts of levels.

Frames are painted back to front since there’s no advanced Z-culling or similar features, but it shows just how capable the Super FX chip is. [Tobi] has said that he’ll look at releasing the project in some form once he’s happy with how it works and runs, which is definitely something that we’ll look forward to.

Continue reading “Using The SNES Super FX Chip To Run Super Mario 64“ →

Nintendo DS Port Of Super Mario 64 Released With Multiplayer Support

For some time now [Tobi Friedly] has been tinkering away at porting the original Super Mario 64 from the Nintendo 64 to just about any device imaginable. One of these being the Nintendo DS, with the code and build instructions now up on GitHub, along with the demonstration video below that shows off the added multiplayer functionality.

We previously covered this project and the challenges involved. The main problem that kept him from just taking the existing Nintendo DSi port by [Hydr8gon] and running it on the original DS is that the latter doesn’t have enough RAM to load the entire game ROM into memory. The integration of NitroFS for asset streaming took some time, along with addressing sound support and overall stability. Meanwhile it appears that multiplayer support was also added along the way.

This multiplayer involves two DS systems, each running its own copy of the game. This can be nice for co-op playing of the game, as well as just for goofing around in a 120 star fully finished game with a buddy.

Continue reading “Nintendo DS Port Of Super Mario 64 Released With Multiplayer Support” →

Porting Super Mario 64 To The Original Nintendo DS

Considering that the Nintendo DS already has its own remake of Super Mario 64, one might be tempted to think that porting the original Nintendo 64 version would be a snap. Why you’d want to do this is left as an exercise to the reader, but whether due to nostalgia or out of sheer spite, the question of how easy this would be remains. Correspondingly, [Tobi] figured that he’d give it a shake, with interesting results.

Of note is that someone else already ported SM64 to the DSi, which is a later version of the DS with more processing power, more RAM and other changes. The reason why the 16 MB of RAM of the DSi is required, is because it needs to load the entire game into RAM, rather than do on-demand reads from the cartridge. This is why the N64 made do with just 4 MB of RAM, which is as much RAM as the NDS has. Ergo it can be made to work.

The key here is NitroFS, which allows you to implement a similar kind of segmented loading as the N64 uses. Using this the [Hydr8gon] DSi port could be taken as the basis and crammed into NitroFS, enabling the game to mostly run smoothly on the original DS.

There are still some ongoing issues before the project will be released, mostly related to sound support and general stability. If you have a flash cartridge for the DS this means that soon you too should be able to play the original SM64 on real hardware as though it’s a quaint portable N64.

Continue reading “Porting Super Mario 64 To The Original Nintendo DS” →

Running DOOM And Super Mario 64 Inside A PDF File

Although generally described as a document format, PDFs have ballooned from a Postscript-lite format into a mutant featuring XML and JavaScript support, basically turning what once was a fairly simple format into an interactive page. Naturally, this has to be used for good, and that is why we have the Doom PDF project, as well as [Game of Tobi] using that project as the inspiration for a Super Mario 64 port based on the decompiled source code.

The nice thing about the Super Mario 64 version is that it’s stand-alone, running from a 23.5 MB PDF, unlike the Doom PDF which runs the game in DOSBox. The compromise is that Super Mario 64 PDF runs at just a few FPS, with the output in glorious ASCII.

What enables this feat is to open the PDF in a viewer that supports JavaScript, with the PDF.js that comes with most browsers generally allowing for integrated JS in the PDF to be executed. Unfortunately [Game of Tobi] hasn’t released source code for this project, but we hope that this is forthcoming.

While one can argue about the practicality of this whole demonstration from a gaming perspective, it definitely shows that PDF as a format has gotten way out of hand now that it’s even overrun with hellspawn and Italian plumbers.

Continue reading “Running DOOM And Super Mario 64 Inside A PDF File” →

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

Why Super Mario 64 Wastes So Much Memory

The Nintendo 64 was an amazing video game console, and alongside consoles like the Sony PlayStation, helped herald in the era of 3D games. That said, it was new hardware, with new development tools, and thus creating those early N64 games was a daunting task. In an in-depth review of Super Mario 64’s code, [Kaze Emanuar] goes over the curious and wasteful memory usage, mostly due to unused memory map sections, unoptimized math look-up tables, and greedy asset loading.

The game as delivered in the Japanese and North-American markets also seems to have been a debug build, with unneeded code everywhere. That said, within the context of the three-year development cycle, it’s not bad at all — with twenty months spent by seven programmers on actual development for a system whose hardware and tooling were still being finalized, with few examples available of how to do aspects like level management, a virtual camera, etc. Over the years [Kaze] has probably spent more time combing over SM64‘s code than the original developers, as evidenced by his other videos.

As noted in the video, later N64 games like Legend of Zelda: Ocarina of Time are massively more optimized and streamlined, as lessons were learned and tooling improved. For the SM64 developers, however, they had a gargantuan 4 MB of fast RDRAM to work with, so optimization and memory management likely got kicked down to the bottom on the priority list. Considering the absolute smash hit that SM64 became, it seems that these priorities were indeed correct.

Continue reading “Why Super Mario 64 Wastes So Much Memory” →

Optimized Super Mario 64 Offers Exciting Possibilities

When working on any software project, the developers have to balance releasing on time with optimizations. As long as you are hitting your desired time constraints, why not just ship it earlier? It’s no secret that Super Mario 64, a hotly anticipated launch title for the Nintendo 64 console in 1996, had a lot of optimizations left on the table in order to get it out the door on time. In that spirit, [Kaze Emanuar] has been plumbing the depths of the code, refactoring and tweaking until he had a version with serious performance gains.

Why would anyone spend time improving the code for an old game that only runs on hardware released over two decades ago? There exists a healthy modding community for the game, and many of the newer levels that people are creating are more ambitious than what the original game could handle. But with the performance improvements that [Kaze] has been working on, your budget for larger and more complex levels suddenly becomes much more significant. In addition, it’s rumored that a multi-player mode was originally planned for the game, but Nintendo had to scrap the feature when it was found that the frame rate while rendering two cameras wasn’t up to snuff. With these optimizations, the game can now handle two players easily.

Luigi has been waiting 26 years for his chance to shine.

[Kaze] has a multi-step plan for improving the performance involving RAM alignment, compiler optimizations, rendering improvements, physics optimizations, and generally reducing “jankiness.” To be fair to the developers at Nintendo, back then they were working with brand new hardware and pushing the boundaries of what home consoles were capable of. Modeling software, toolchains, compilers, and other supporting infrastructure have vastly improved over the last 20+ years. Along the way, we’ve picked up many tricks around rendering that just weren’t as common back then.

The central theme of [Kaze]’s work is optimizing Rambus usage. As the RCP and the CPU have to share it, the goal is to have as little contention as possible. This means laying out items to improve cachability and asking the compiler to generate smaller code rather than faster code (no loop unrolling here). In addition, certain data structures can be put into particular regions of memory that are write-only or read-only to improve resource contention. Logic bugs are fixed and rendering techniques were improved. The initial results are quite impressive, and while he isn’t done, we’re very much looking forward to playing with the final product.

With the Nintendo 64 on its way to becoming a mainline-supported Linux platform, the old console is certainly seeing a lot of love these days.

Continue reading “Optimized Super Mario 64 Offers Exciting Possibilities” →