Utilitaire de conversion ISO PS1 > PBP
Caractéristiques
Utilitaire de conversion ISO PS1 > PBP
Commenter
NioX5199 Wrote:C'est quoi ce bor... ! C'est magnifique ! mais je pige pas... pkoi on arrive a faire un emulateur N64 , un peu lent certe, mais pas plus que la GBA ! et l'emulateur GBA est trop trop lent !
1) The N64 CPU is much closer to the PSP CPU than the GBA CPU is. This means that the N64 is an excellent candidate for efficient dynamic recompilation. The GBA's CPU (ARM) is also a solid candidate for recompilation on just about any platform, including MIPS (what PSP uses). What I mean by that is that using dynarec for ARM would improve the performance several times over using interpretation (the traditional approach most emulators use, including almost all GBA ones) because ARM has complicated instructions that are computationally expensive to parse, a step removed in recompilation. However, since PSP has a MIPS CPU like N64 it means that instructions can be recompiled very efficiently, often a single instruction to a single instruction (on average I'd imagine it's something like 2 or 3 instructions for every 1, depending on how tight the memory accesses and branching blocks are and how frequent they're used in the source code). N64 has a 90MHz CPU so you'd need about 180 to 270MHz to emulate that at full speed, but chances are no real N64 games actually utilize the CPU fully and idle loop detection eliminates the requirements a lot (especially on dynarec cores) so the PSP's 333MHz MIPS based CPU should be more than enough. But some of you might be saying "Exophase, PSP has a 32bit CPU and N64 has a 64bit CPU, how can they be similar?" This is true, however, the MIPS has a rather scaleable backwards compatible design, so not only does the N64's CPU more or less support a bulk of the instructions that the PSP's does directly, meaning that it has 32bit operations for every 64bit ones, but most games only use these 32bit operations. Ironically the system with "64" in its name almost never uses the 64bit capabilities of its CPU, proving yet again that bit rating in consoles has been little more than a marketing tool that more or less died out with that system anyway.
Here's a less technical analogy to help explain why PSP can emulate N64's CPU when existing GBA emulators kinda suck: say you have two paragraphs. One is in English and uses words at a college level, the other is in Korean but uses words at a 5th grade level. You give them to an American middle school student and give the student a Korean/American dictionary and a normal American dictionary and ask him/her to explain what the paragraphs are saying, timing him/her. Even though the paragraph at a 12th grade level contains much more advanced concepts the student will be able to figure it out much more quickly because he/she already understands most of the words. For the Korean paragraph at a 5th grade level he/she will have to translate each word to English before understanding it. Even if this were an entire Korean book the student would have to learn Korean before hand (the compile time overhead of dynamic recompilation) and would have to use several English words to express some Korean concepts (the runtime overhead), this things wouldn't be as present in understanding a more advanced English book. This analogy isn't 100% fitting but it's close enough to explain my point.
2) N64 can be HLE'd very well, meaning that if you have a system that's sufficiently more powerful than the N64 itself you can emulate everything but the CPU very efficiently for many games because you're emulating it at a library call level. GBA games either can't be HLE'd very well beyond the BIOS calls or it usually isn't (to the best of my knowledge). So this puts most of the emulator's focus on the CPU, and as I said that's a speciality for PSP.