Notes and thoughts on my journey into the Nintendo 64 modding scene

— Alan Barzilay

Nintendo

64

Index

System architecture

This section is mostly based on the best analysis of the N64

System architecture

So, computers (and consequently game consoles) in general have a few important components:

  • CPU
  • GPU
  • RAM
  • Storage
  • Peripherals

System architecture

The mapping presented in the last slide isn´t very precise but I think is a good first aproximation about how things work, later we will see that the "GPU" does quite a few things besides processing graphics and how all those chips deal with our peripherals.

Also, here is a nice visualization about how everything is connected

Ok, let's take a better look at those chips form earlier

CPU:

NEC VR4300

I wont try to go into details of what a CPU is or how they work, anything I write is going to be worse than other readily available explanations online. Actually, I wont really explain how any computer component works, this is about the nintendo64 and its peculiarities so I will try to focus on whats special about its CPU or else I will never finish this

This may come as a shock to you, but the Nintendo 64 CPU has a 64-bits architecture.

64-bits architecture

MIPS III instruction set

93.75 MHz

24 KB L1 cache

32-bit data bus to the RCP

5-stage pipeline

Jokes aside, I find this interesting since the Game Cube uses a 32-bit architecture and the x86_64 architecture would start to get traction almost a decade after the N64's launch. Not sure what led them to this decision but I find it neat.

Anyway, this CPU actually has a second 32-bits mode besides its native 64 bits one, this secondary mode has fewer features and is compatible with MIPS II. I'm not sure what advantage this mode would bring, sounds like a handicapped mode with fewer features.

 

Last thing of note about the N64 CPU is that it has no direct access to the RAM, having to go through the RCP chip (the "GPU")

Abridged Emulation History

So... I tried to think of a better way to talk about this, but I can't find another way to describe the n64 emulation other than utter chaos. And I'm not alone, there are quite a few people confused and/or complaining online. (add mais links?)

 

If you have previous experience with emulating other consoles you may be surprised at the fragmentation of efforts and the unreliability of n64 emulation.

The gold standard (if you can even call that) for N64 emulation has changed a lot along the years, I will try to abridge what happened since the N64 launch and cite most relevant event (such as leaks and new plugins/libraries).

 

I may get the order and detail of some things wrong, but, like, come on, can you blame me?

Jokes aside, I have a lot of respect for everyone in the emulation community for bringing us this far, there is some really impressive stuff being done and at the end of the day all problems are the fault of Nintendo whatever the fuck the RCP is doing over there.

<3 to the devs

1.

UltraHLE & the Oman files

Abridged Emulation History

UltraHLE:

First successful N64 emulator, merely 3 years after the N64 release.

Smart use of High Level Emulation, i.e. instead of simulating absolutely everything the RCP did down to its transistors (Low Level Emulation) it does some smart mapping of system calls (i feel this is similar to steam's proton but i may be very wrong) to approximate the expected result and thus cut down on the complexity and processing. Aside from being the "first" emulator, it is irrelevant nowadays since it was discontinued a long time a go.

N64 release
September 1996

Oman Files:

Huge leak from SGI (you know, the fucking creators of the cpu and gpu). Apparently it boosted a lot of the earlier efforts but do its fundamentally illegal nature it would contaminate any clean room reverse engineering attempt that came near it.

If you want to get involved with n64 emulation and/or modding you better stay clear of it to avoid legal trouble. Anyway, i have been recommended this run down about what was contained in these Oman files: https://www.retroreversing.com/oman-archive

I haven't looked at them and I probably wouldn't understand any of it even if I did, I swear Nintendo plz don't sue me.

 

 

1.

UltraHLE & the Oman files

Abridged Emulation History

Project64:

Even though it had a closed source period, this emulator was once considered the best of its time and its legacy can still be felt in other emulators to this day (for better or worse).  It defined the first plugin spec, known as Zilmar Spec, that would become the general approach to N64 emulation.

There are lot of criticism online directed to the project lead for some of his decisions and the direction in which the project has been going (such as old bundled plugins and per-game timing fixes instead of focusing on cycle accuracy).

You can still get a pretty good experience depending on the game you want to play and by messing around with parameters, plugins and etc.

Also, if you ignore some insane problems it had in the past, a pretty serious vulnerability has been found on it so it isn't the safest option if you are downloading random ROMs from the internet.

Windows support (and only windows).  

N64 release
September 1996

Mupen64:

Fuck, where do I even begin with this one. Researching this was hella confusing.

It started as Mupen64, then it forked into Mupen64plus when they broke off from the Zilmar plugin spec. It also does not have an official GUI which I find incomprehensible.

For some god forsaken reason, it has an insane amount of forks similarly named which makes everything even more confusing, some of the most important forks are, but not limited to:

  • Mupen64Plus-Next
  • ParaLLEl-N64
  • simple64
  • Mupen64+ Reverser Edition (RE)
  • Wii64
  • Not64

2.

Project64 & Mupen64

Besides the Mupen forks, there is also the whole plugin mess, which brings me to...

1.

UltraHLE & the Oman files

Abridged Emulation History

Plugins:

This is kinda hard to place on a timeline since it is essentially a second timeline happening in parallel with the history of emulators but I think this is where it makes more sense narativelly.
 

So, whats all this plugin deal about? Well, this approach started with proejct64 and it kinda stuck ever since.

The idea is simple, an N64 is made of different parts so lets emulate those as diferent things and plug them together to make an emulator. For this to be possible, the plugins need to be consistent, follow some kind of specification.

The first specification was made by Zilmar, the steward of project64 and was the dominant spec for a good while. However, this spec is ANCIENT and since they were feeling constrained by it the Mupen team created their own spec (insert xkcd joke about specs), breaking compatibility with project 64.

N64 release
September 1996

2.

Project64 & Mupen64

3.

Plugin Hell

Historically, the majority of N64 emulators all shared the same plugin spec (...), and could therefore all use the same plugins, meaning you could take a plugin DLL file, use it on one emulator, then take that DLL and use it on another, and it would also work there. Of these, the big three emulators were Project64, 1964 and Mupen64. Each had advantages and disadvantages, and some games worked well in one only to not work in another, even when using the same plugin configuration. This necessitated having all of these emulators and sometimes even older or modified versions of them, along with a great many plugins, to be able to play most of the N64 library with the least amount of issues possible - though admittedly a good amount of games (particularly the most popular ones) were playable with just the best few of them.

To illustrate the point, here is a site that, as late as 2012, was dedicated to documenting the exact emulator, plugin and settings combination necessary to get each and every game to at least a playable state, if at all possible. Unsurprisingly, this situation often led to a lot of confusion from users, who often wondered why there were so many plugins, and which ones were the best to use, only to find out it often depended on the game, and even then, some games would refuse to work as intended no matter what was tried. Hence the label "plugin hell" was coined, and stuck as a description of the travails of trying to emulate N64 games well into the 2010's.

https://emulation.gametechwiki.com/index.php/Recommended_N64_plugins#The_Plugin_Specs

Plugins:

So everything was a mess (and kinda still is). Why can't we have a single good plugin for each subsystem and be done with it?

Well, the biggest problem is the RSP which, as previously established, is a fucking hellhole. Its default behavior is already weird and unconventional, but n64 game developers could fuck around with microcode to change its behavior complicating matters further.

There is also the whole issue of HLE Vs LLE, which essentially comes down to a trade -off between fidelity and performance.If you want a good discussion on this topic, go here.

 

With better hardware more readilly available (tks Moore) and more sophisticated graphic libraries like Vulkan,the situation got A LOT better. So much so that if you simply choose the more popular plugins you can pretty much get the best and more robust emulation experience possible at the moment. Also they have been ported to all major plugin specs.

So, which are those modern plugins you ask?

1.

UltraHLE & the Oman files

Abridged Emulation History

N64 release
September 1996

2.

Project64 & Mupen64

3.

Plugin Hell

RDP Plugins:

ParaLLEl-RDP - LLE video plugin, runs on the GPU through the use of the Vulkan shaders "This is currently considered the best video plugin by most measures". Supports hi-res upscalling but due to being an LLE emulator it lacks support for widescreen hacks or high-res textures (but GLideN64 has those!). High system requirements and needs a GPU with Vulkan support. Needs to be used with an LLE RSP plugin.

GLideN64 - A hybrid HLE/LLE plugin, not to be confused with Glide64 plugin by the same author (keeping track of the genealogy of these things makes me want to murder someone). "This is the best HLE plugin by far." Supports: mip-mapping, emulation of low-level triangles, microcode emulation of every game, gamma correction, flat and prim shading, VI emulation,  LLE graphics, hi-res custom texture support, MSAA and AF, a widescreen hack, and even some shaders. It is the only plugin that has implemented HLE support of microcodes for every N64 game.

Use this over ParaLLEl-RDP only if you are unable to run the latter in HD at full speed or if further enhancements such as widescreen hacks and hi-res textures are desired.

4.

Modern Plugins

RSP Plugins:

Not as contentious as the RDP plugins, if you are using ParaLLEl-RDP (which you probably should) your best bet is to stick to ParaLLEl-RSP.

 

Input Plugins:

NRage Input - the best plugin.

 

Audio Plugins:

I'm confused, send help

1.

UltraHLE & the Oman files

Abridged Emulation History

N64 release
September 1996

2.

Project64 & Mupen64

3.

Plugin Hell

Faltando em algum lugar:

-libretro coisas

-audio coisas

-rsp pra hle

- seja la q porra o ares ta fazendo com MAME coisas

- simple 64 e outros dropando plugins

- push recente pra compatibilidade e acuracia real, removendo per game hacks

- 2020 Nintendo data leak (GigaLeak)

4.

Modern Plugins

3.

GLideN64

paraLLEl-RDP

GigaLeak

5.

1.

UltraHLE & the Oman files

2.

Project64 & Mupen64

Abridged Emulation History

Ares & Simple64

4.

Modern Plugins

Refs:

https://emulation.gametechwiki.com/index.php/Nintendo_64_emulators

https://emulation.gametechwiki.com/index.php/Project64

https://emulation.gametechwiki.com/index.php/Mupen64Plus

https://emulation.gametechwiki.com/index.php/Recommended_N64_plugins


https://www.retroreversing.com/

Toninho Gavião Jr.

Rippar meu cartucho original

 

1

????

 

2

Profit

Chorão desce dos seus e me ensina a andar de skate

3

https://www.youtube.com/watch?v=r1wOHyfGT7E&list=PLGGatGxzDJByQkpefzSpvkB7D67x-3yVH&index=2

Vs

Quick disclaimer, I program for a living and have studied a lot of these stuff in university (MSc in Computer Sciences). My career led me to focus in other areas of computer science so I am by no means an expert in hardware emulation or reverse engineering but keep in mind that I know a lot more than the average person about how computers work and probably skipped a few technical details (probably unintentionally).

 

 

 

Btw, I tried to cite all my sources and link the images back to their creators. Lastly, Im new to this scene, let me know if you find any mistakes!

 

Serif

By barzilay

Serif

  • 59