So a normal game played on a PC is going to be an executable file that was made specifically for PC, and is set up to run in that environment.
N64 games on the other hand are designed specifically with the N64’s hardware in mind and is not designed to run in any other environment.
To get around this hardware mismatch, some very skilled people write code that simulates the hardware of the N64, and run it on a PC. Once they’ve got a simulated N64 running on a PC, they simply feed the original ROM data from an N64 cartridge into this simulated N64 and it just works.
If they didn’t get the simulation(really it’s an *emulation*) quite right then you can get unusual behaviors and errors.
The more advanced the hardware you’re trying to emulate, the more likely you’re going to get little details off and cause more of these errors. The N64 is very simple compared to a PS5, so it takes less power to emulate the hardware through code, and the lower complexity means there’s less things for you to screw up and get errors.
So, summarized: Emulation is when you simulate the hardware of the console, and the more complex the console, the more computing power it takes and the harder it is to get everything right.
So older hardware like an original N64 console is way way slower than modern hardware. Improvements in technology have allowed us to fit many many times more processing power into the same size box, and so today’s computers are powerful enough that they can effectively run a simulation that does everything that would go on inside a real N64 system, but with code instead of hardware.
Basically an emulator pretends that it is the console it is trying to emulate. It knows all the specifications for the console, how much memory it has, what its instruction set is, what it does to boot up, and it uses those rules to act out what would happen inside the console in real life, like a child playing with dolls.
When you run an emulator, your computer is doing a lot more work to run the emulator than the original console would be doing since the emulator had to use software to do things that would just be done with hardware in the real console, but it usually doesn’t matter because old consoles are so slow and new computers are so fast.
This technique would not work so well for newer consoles because, for one, the inner workings of new consoles are much more closely guarded for security and intellectual property protection reasons, so creating an emulator would be very difficult, and secondly, because new consoles are very fast. They are already pushing the limits of what’s possible to compute in real time with current technology, so trying to run that in an emulator would just be painfully slow.
In older consoles, cartridges contained ROMs (read only memory) which stored all the game code and art assets. The game code is stored as a series of CPU instructions, like “take this value and store it in this location in RAM”, or “send this data to the GPU and tell it to do this”.
When you power on the console, it runs a special sequence of steps to basically look for a cartridge connection, confirm its valid and for the right region, and if it finds one it will look in a specific location in the ROM to figure out what it is supposed to do first, then begin executing it.
What an emulator does, is essentially copies this process: it reads the ROM file, finds the first instruction and begins doing what it is being told to.
The catch is that the instructions the ROM contains assume a specific machine, such as a NES, N64, Genesis etc. When it gives an instruction like “move this block of memory to this location in memory on the VDU” your PC thinks “what the heck is a ‘VDU’?” When the ROM says “wait for vertical blank”, your PC thinks “what is a vertical blank”. This means it cannot actually run any of the instructions it’s being given.
This is where “high-level emulation” (HLE) and “low-level emulation” (LLE) come in. HLE can be described as directly translating instructions. When the ROM says “move memory to VDU and wait for vertical blank”, the emulator translates this to “draw this triangle on screen and wait for the next frame” for your PC to execute.
HLE works quite well, but its not very accurate. For those who just want to play a bit of Mario 64 it generally works OK, but there are a lot of quirks specific to the original hardware which means the way your PC reproduces those instructions isn’t exactly 100% identical. Sometimes the differences are tiny, such as Mario’s shadow is a little darker in the emulator than the original, and sometimes it can be severe (game crashes).
This is where LLE comes in. The emulator doesn’t just interpret instructions for your PC, it actually simulates the original machine. It gets really psychotically anal about everything, down to “it takes 2 nanoseconds for the memory to transfer to the VDU, so we will simulate that delay exactly. Then the TV’s electron beam takes 1 ns to finish a scan line, so we will simulate that”. This is MUCH more accurate and can produce 100% faithful recreations, but at the cost of being MUCH more demanding on hardware. That’s why a SNES emulator can require a 3ghz machine.
Hope this helps!
An emulator is what’s called a virtual machine. It uses software (code) to replicate the hardware (circuits/chips) of another computer.
We can do it with older consoles/computers because they are very simple. In order for it to run properly, you need to be able to simulate the whole machine at once, which means your current hardware needs to be either extremely similar or far faster than what you’re trying to emulate.
The original Wii had a GameCube emulator because the hardware was extremely similar, basically all the Wii needed to do what cut off access to half of its memory, and it’s essentially the same. For something like a computer running an N64 emulator, the N64 was simple enough that the computer can simulate every piece of hardware without issue.
Modern consoles are much more complex, so they take a lot more work to emulate and much higher end PCs to emulate.
Latest Answers