Emulation
- Thread starter FIBERLINE
- Start date
Toasty
Sony battery
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.
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.
Last edited:
Falcon4ever
Plugin coder / Betatester
double posting is annoying..., just edit the post next time (both of you)
Toasty: good explaination
Toasty: good explaination
Toasty
Sony battery
Yeah, this was originally two threads and it apparently got merged. I've condensed my previous posts into one.
Last edited:
BlueFalcon7
New member
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.
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.
- Thread Starter
- #7
Is it possible to find the steps using a random number generator?
- Thread Starter
- #9
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
Sony battery
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.
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).
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).
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.
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.