Emulation

[FIBERLINE]

Why is emulating a gamecube so hard and time consuming?

[FIBERLINE]

So is it the CPU that the emulator seems to hog?

[Toasty]

Yes. Or more accurately, the CPU is the main bottleneck preventing it from running at full speed.

As with just about any emulator, the host platform has a different instruction set than the emulated platform. (They speak different languages.) For every instruction in the original code (from the game), the host CPU (in your PC) must execute many instructions to translate it to its own instruction set and then execute it.

Let's say a Gamecube game has these instructions for the CPU:
1. Read a number from memory
2. Add 12 to that number
3. Write the result back to memory

A Gamecube (which reads Gamecube-ese) does the following:
1. Read a number from memory
2. Add 12 to that number
3. Write the result back to memory

A PC (which does not know Gamecube-ese and must use an emulator) does the following:
1. Read a piece of code from the game
2. Look up the meaning of that piece of code
3. Figure out what the PC-ese equivalent of that code is
4. Execute the PC-ese code (read a number from memory)
5. Read a piece of code from the game
6. Look up the meaning of that piece of code
7. Figure out what the PC-ese equivalent of that code is
8. Execute the PC-ese code (add 12 to that number)
9. Read a piece of code from the game
10. Look up the meaning of that piece of code
11. Figure out what the PC-ese equivalent of that code is
12. Execute the PC-ese code (write the result back to memory)

That's a very simplified explanation, but as you can see, it's no surprise that the host platform usually needs to be at least an order of magnitude faster than the emulated platform to achieve decent speeds.

[Falcon4ever]

double posting is annoying..., just edit the post next time (both of you)

Toasty: good explaination

[Toasty]

double posting is annoying..., just edit the post next time (both of you)

Toasty: good explaination
Yeah, this was originally two threads and it apparently got merged. I've condensed my previous posts into one.

[BlueFalcon7]

I was wondering, does the actual GC do software rendering? Because, I know that we can now do direct 3d of a lot of new stuff which was not available in 2001. I also know that ATI is not known for hardware rendering, but are really good with writing code for software rendering (which is good for game systems)

I know that the video plugin takes care of that sort of stuff, but if it is software rendered, couldn't there be some sort of dynamic recompiler specifically to commands that are direct 3d, so instead of requiring the CPU to do extra software rendering, it runs the code through the dynarec and sends it straight to the GPU.

...or is that what they already do? Just asking.

[FIBERLINE]

Yes. Or more accurately, the CPU is the main bottleneck preventing it from running at full speed.

As with just about any emulator, the host platform has a different instruction set than the emulated platform. (They speak different languages.) For every instruction in the original code (from the game), the host CPU (in your PC) must execute many instructions to translate it to its own instruction set and then execute it.

Let's say a Gamecube game has these instructions for the CPU:
1. Read a number from memory
2. Add 12 to that number
3. Write the result back to memory

A Gamecube (which reads Gamecube-ese) does the following:
1. Read a number from memory
2. Add 12 to that number
3. Write the result back to memory

A PC (which does not know Gamecube-ese and must use an emulator) does the following:
1. Read a piece of code from the game
2. Look up the meaning of that piece of code
3. Figure out what the PC-ese equivalent of that code is
4. Execute the PC-ese code (read a number from memory)
5. Read a piece of code from the game
6. Look up the meaning of that piece of code
7. Figure out what the PC-ese equivalent of that code is
8. Execute the PC-ese code (add 12 to that number)
9. Read a piece of code from the game
10. Look up the meaning of that piece of code
11. Figure out what the PC-ese equivalent of that code is
12. Execute the PC-ese code (write the result back to memory)

That's a very simplified explanation, but as you can see, it's no surprise that the host platform usually needs to be at least an order of magnitude faster than the emulated platform to achieve decent speeds.

Is it possible to find the steps using a random number generator?

[Toasty]

Huh? :huh: Elaborate.

[FIBERLINE]

What I mean is: in your directions it says add 12 ext... well if the cpu code is dealing with numbers (possibly like an encryption) a random number generator might speed things up. Maybe what I mean is random code generator? I was just wondering if you could program a computer to do random exploits until the code for the gamecube cpu is cracked.

[Toasty]

The Gamecube game isn't encrypted. A program is a list of instructions. PCs don't natively read Gamecube instructions, so they have to be translated to PC instructions that a PC can execute. If you have a list of French instructions it wouldn't be plausible to just keep randomly changing letters in the hopes that you'd end up with an English translation. There are two ways to execute the French instructions:

1. Have a native speaker perform them. (Run the code on a CPU that executes Gamecube instructions natively, such as a Gamecube or Wii.)
2. Have someone who doesn't speak French translate the instructions into his language and then perform them. (An emulator on a PC translates Gamecube instructions to their PC equivalents and executes them.) Obviously, this method is much more time-consuming, but allows code to run on platforms that don't natively understand it.

[Doomulation]

Something else to ponder is that in a Gamecube, there is hardware beside the CPU that does work. In the PC, there is no such hardware (or they're different), so the PC's CPU has to do their work as well and make the game believe it runs on a real system.
There's also other overhead, like timing, OS calls, DirectX calls (I would believe since the consoles are fixed hardware, they don't really need a high-level API such as DX).

[FIBERLINE]

Is it possible to send a command to a PC and see what the reaction is such as a blue screen. Then send random commands to the gamecube until you get the same result thus possibly getting a correlation between the two?

[Doomulation]

Read instruction.
Interpret instruction.
Execute instruction.
This is the way a CPU works, on a much lower level. And this is also an interpreter - a way of emulating things.
Don't try to compare emulation with encryption or any other such silly thing, because it isn't how it works nor can work.

There's also dynamic recompiler. It translates instructions into x86 instructions instead of trying to interpret them - this is faster, but harder. It still only works with CPU emulation.