How do phone/console emulators work?
In: Technology
The emulator itself is basically a middleman between the (phone/console code) and the (cartridge, disc, or app code). The emulator is just translating code intended for one device – the phone or console – and making it able to be executed on your PC.
One tricky thing is actually building the emulator, since you need to reverse-engineer whatever the phone/console hardware is doing, and do it using code that your PC can actually execute.
Another tricky thing is getting the apps/games – with phone emulators, if everything is going properly, you can still connect to whatever storefront (ie: google play) and download. But with consoles, it implies being able to access the cartridge/disc/etc. and dump all of it’s contents into a ROM file (which will then be opened/used by the emulator to run the game).
The last real tricky thing is just the nature of emulation – it’s like having a translator between you and your best friend speaking different languages. Everything you say has to go through the translator first, which slows everything down.
Consoles are just like computers – they have storage (like a hard drive), memory (RAM), a processor (CPU) and some other parts. An emulator is a program which creates a virtual version of the console’s hardware, including the console processor’s instruction set (the language of the processor). Because the emulated processor can “speak the language” of the original console’s processor, it can run the console’s operating system (equivalent to Windows/iOS/Android etc).
When you combine the virtual hardware and the operating system, the resulting emulator can run the games that were coded for the original console.
As for phone emulators – if you mean smartphones in particular, I think they use something called a virtual machine, which is slightly different – it doesn’t exactly emulate the hardware but it does run the mobile operating system.
Aight full blown ELI5 here.
The main part of a computer is the processor, which does what you want it to do. For that, you enter code and receive output.
Think of it like a labyrinth with something hidden in it and you send a rat to retrieve it. The rat is code; when he emerges with what’s inside, that’s output.
Different processors are like completely different labyrinths, but each rat knows just a particular one. They get lost in any other one and will never find what you need.
So you have a rat that knows only one labyrinth, say the N64. If you want it to function in an Intel Labyrinth, you need to have a look at the N64 labyrinth. Then you try to move the walls in the Intel labyrinth as much as possible, to resemble the N64 one, and where it’s not possible, you make a N64 map with notes on it so the rat will find a way in Intel as well.
At first your emulated labyrinth and map suck and the rat keeps banging into walls and not getting anywhere, so you keep improving it and eventually the rat can usually find its way in the Intel labyrinth as well.
Of course the rat has to deal with reading the map, notes, and the new environment, which make it much slower to go through the labyrinth. That’s why emulation is slow even with the best map.
Also depending on where the treasure exactly is, your map may still not be accurate enough so sometimes the rat gets lost anyway; emulation may be inaccurate.
Latest Answers