Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’ve been doing some reading about the people building an emulator for the Wii and it seems that given that it is nothing more then a beefed up GameCube, or the Nintendo64, so what makes build emulators for these systems so hard?
On a slight bit of a side note the hardware for these systems is surprisingly low:
Wii:
729MHz PPC CPU
88MB Memory
243MHz GPU
N64:
93.75MHz CPU (64-bit)
4MB Memory
The CPU architecture for game consoles is often somewhat exotic compared with your average desktop machine. Emulation means to perform in software everything that the original hardware did. That is, while the original console may have had dedicated graphics, audio, etc. chips as well as a CPU with a different instruction set, the emulator must perform all the functions of these parallel resources at speed.
Unless the console’s GPU is old, it almost certainly must be emulated on the GPU of the host machine, as modern graphics cards, even cheap ones, have many times the throughput (for graphics workloads) of even the most expensive multicore CPUs. Compounding this difficulty is the fact that communication between CPU, GPU, any other onboard DSPs, and memory was probably highly optimized on the console to take advantage of the specifics of the hardware configuration, and therefore these resources must be rate-matched as well.
Compounding all these difficulties, usually little is known about the specifics of the console’s hardware, as this is kept very much under wraps by design. Reverse engineering is getting less and less feasible for hobbyists to do.
To put things into perspective, an architectural simulator (a program which can run, for example, a PowerPC program on an x86 machine and collect all sorts of statistics about it) might run between 1000x and 100000x slower than real-time. An RTL simulation (a simulation of all the gates and flip-flops that make up a chip) of a modern CPU can usually only run between 10Hz and a few hundred Hz. Even very optimized emulation is likely to be between 10 and 100 times slower than native code, thus limiting what can be emulated convincingly today (particularly given the real-time interactivity implied by a game console emulator).