Vorporeal
Yes, no, I, this is.
Don't forget about the fact that architectural differences can also assist in emulation. (They can sometimes hurt as well, though.)
N64 Emulator In The Work For Pandora
- Thread starter renejr902
- Start date
renejr902
Active Member
i forgot diddy kong racing in my top 5
Consequence_9
have you realized that rock stars always seem to l
WHY has no one mentioned Gauntlet 64!? 4-Player ONLINE co-op*!?
*[eventually w/kalliera]
*[eventually w/kalliera]
Vorporeal
Yes, no, I, this is.
Mmm, good call. I loved playing Gauntlet Legends in the arcade, and also had a lot of fun playing through Gauntlet: Dark Legacy with some friends on the Gamecube. Online-multiplayer for Gauntlet would be awesome.
MrBlais
Member
All I want is Ocarina of Time. I already have Final Fantasy VII on my PSP. If I can get OoT on my Pandora, I will die happy 
gaterooze
Coltrane Sundia
renejr902 said:
That was fantastic. Goddamn it got hard later on!
Last edited by a moderator:
elwing
Rabbit Addict
- Joined
- Feb 23, 2009
- Messages
- 3,118
the 64 also old a version of my favorite multiplayer game...
bomberman...
sure the 64 version is quite bad compared to the great atomic bomberman or the quite good bomberman generation, but that version feature some unique, strange and good thing in multiplayer... and the arena are great, I do specially love the grass one where bomb are almost hidden into the grass... it is not as good as the other bomberman mantionned, but the different (and fun) gameplay makes it an interesting multiplayer game.
ho, and like all other bomberman ignore the single player mode, it's pretty bad.
bomberman...
sure the 64 version is quite bad compared to the great atomic bomberman or the quite good bomberman generation, but that version feature some unique, strange and good thing in multiplayer... and the arena are great, I do specially love the grass one where bomb are almost hidden into the grass... it is not as good as the other bomberman mantionned, but the different (and fun) gameplay makes it an interesting multiplayer game.
ho, and like all other bomberman ignore the single player mode, it's pretty bad.
Poem58
Active Member
Neko said:
You must have missed where I said I was NOT doing a CPU comparison (though you quoted it) But if you must then by that Logic you would have to overclock the main CPU to 940Mhz and still need another 640mhz for the coprocessor. Which last time I checked NO Pandora should ever be overclockable to 1.5Ghz. However I didn't (for sake of simplicity) take into account the architectural differences or relative abilities of the Omap3 to explain. Simply put it's easier to emulate a PSX than an N64 on Pandora by specs alone. The poster I was replying to was saying that it shouldn't be any more of a big deal to emulate N64 over PSX, yet the N64 is clearly faster and I assume more complex.
After all I hear that the Sega Saturn is so complex despite not having a super fast processor that it cannot be emulated yet so the speed argument is not valid for all situations I suppose.
The point is these coders do a spectacular job of squeezing every bit from the hardware. It's not just that 10x the CPU can magically make an emu easy to make.
What's dual-issue and what do you mean by that? Keep in mind I have no technical experience or coding experience so explain simply please.
Also side note, I remembered reading an article around the time N64 came out where they were comparing the 64's CPU to I think a Pentium 4 ( I wish I could remember in what magazine). They said something crazy like the equivalent of 9 Pentium 4's (might have been 3's?) in power. Anyone remember reading this? How amazingly off were they, cause it didn't seem to be "so powerful" I wouldn't even think you could realistically compare those two CPU's, after all the N64 was RISC not x86.
Edit: I see there are Saturn emulators after all, I thought there were not, I guess it just took awhile and I was no longer looking for one when they happened. I'll have to look to see if they really work (never had a Saturn) I'm guessing though that what I remembered from the past about it being to complicated still makes a Pandora Saturn emulator unlikely to impossible. Feel free to correct me. It's how I learn.
Last edited by a moderator:
Poem58 said:
Well, I don't really want to get into a CPU comparison either, but dual-issue means the processor can do up to two instructions at a time. The CPU in the N64 can only do one at a time.
My point was that the 10x faster claim wasn't totally off-base, and the Pandora CPU is around 10x faster. This doesn't mean that an emu is easy to make, just possible to make.
Last edited by a moderator:
Exophase
Nothing good will ever come of Exophase.
Although the N64's CPU is capable of up to 90 million instructions per second, Mupen64plus is only emulating 1/5th of that. In any real world r4300i code some cycles would be lost due to internal stalls because of branches, load-use interlocks, and a few multi-cycle instructions. But if it had enough cache to map out the entire RAM space (or direct access to zero wait-state memory that was sufficiently large) then it would probably typically execute a large percentage of this, probably over 60 million instructions per second.
Unfortunately it doesn't have such cache or fast RAM and access to the main RAM which is loaded into cache has a ton of overhead for anything less than significantly large bursts (much larger than a cache line). The CPU's access to the RDRAM is further slowed down by being routed through the RCP, which I suppose gives it priority (rightfully so) but also adds fixed latency. Since the CPU has direct mapped cache there will be a lot of misses just by shifting access between different regions. Data cache will often be negated just by loading from two pointers in the same routine, even the stack pointer runs this risk. Highly aligned data structures would make the situation even worse.
The situation is so bad that Mupen64plus doesn't even bother emulating more than 1/5th the maximum possible number of instructions, or 18 million a second. I'm not really convinced that this is enough for all games, but any hypothetical that aren't can probably cope with it and will simply suffer from additional in-game slowdown. Which is usually a lot better than the emulator slowing down beyond frameskipping. which takes the audio and input responsiveness with it.
Fact is, 18 million is all that Mupen64plus is going to emulate, so we can take that number as a hard limit.
Cortex-A8, on the other hand, has been cited by ARM as executing an average of 0.9 instructions per cycle across several industry standard applications. This is not a maximum like our N64 number, just an average. I don't know the cache configuration they used, but I doubt it was something particularly extravagant. Scaled to clock speed this gives us 540 million instructions per second at 600MHz, or 30 times higher than what Mupen64plus's N64 can do.
Now, how much a recompiler's output falls under the "average" curve is another story - my guess is not that favorably, because they tend to generate a lot of instruction bloat and extra branches which hurts icache and BTB performance.
I've said this about 1000 times, but it's really silly when people say "you need N times the power of what you're emulating to emulate it", where N is some fixed number. For one thing, none of these people are even making remotely educated quantifications as to how powerful something is and instead just compare the clock speed of the main CPU on both, when CPU can be a very small portion of the overall system capability and when the CPUs are generally not comparable on clock basis. And it's silly because emulation overhead has a lot to do with how different the platform is and not just how much "weaker" it is. And then it depends on how accurate the emulation needs to be and what your exact goals are.
What I said was that IF N64 games perform a lot of floating point calculations then Wiz wouldn't cut it. What Ari64 has shown is that (at least for the popular games he tested) they don't. In fact, his Cortex-A8 code is using soft floats to begin with. I do find this a little surprising because StrmnNrmn gained noticeable performance improvements by adding register caching to floats, but this might have been very context limited. Ari64 cited 2-3.5% of CPU time, so 0.36 to 0.63 million per second, which is relatively manageable, and would perform better with custom recompiled code than with the libc calls that Mupen64plus is using.
Yes, the Wiz wouldn't compare highly well to the Pandora for running N64. But with floats out of the equation it looks at least worth trying. Converting down the ARMv6 instructions to ARMv5 equivalent chains would probably not hurt performance tremendously because unless I missed something the recompiler isn't relying on them for high performance in common code like for memory accesses or branches. Even though the 3D is only OpenGL ES 1.1 it is still as good as what several of the earlier N64 emulators were capable of doing, which was more than enough for emulating plenty of games satisfactorily. The Wiz's 3D vector coprocessor could also possibly be used to accelerate N64 T&L.
Mupen64plus is capable of giving results in at least something at 50% CPU usage for a 600MHz Cortex-A8. Wiz is probably usually less than half as fast per cycle, but can usually overclock to 800-850MHz. You might not get anything close to fullspeed across the board but all I ever said was PSP-level, which is certainly not that either.
Given that people have ported N64 emulators to GP2X where it was beyond ridiculous to expect a speed anyone would be happy with I would be surprised to see someone not eventually try to port this to Wiz. Even if that does mean a bit more work in the 3D department.
N64 was released in 1996, before the Pentium 2 was even out ;p Much less Pentium 3 or 4.. A common Pentium 1 of the day was probably much more powerful than the N64's CPU. But couldn't touch the vector capabilities of the RSP.
Unfortunately it doesn't have such cache or fast RAM and access to the main RAM which is loaded into cache has a ton of overhead for anything less than significantly large bursts (much larger than a cache line). The CPU's access to the RDRAM is further slowed down by being routed through the RCP, which I suppose gives it priority (rightfully so) but also adds fixed latency. Since the CPU has direct mapped cache there will be a lot of misses just by shifting access between different regions. Data cache will often be negated just by loading from two pointers in the same routine, even the stack pointer runs this risk. Highly aligned data structures would make the situation even worse.
The situation is so bad that Mupen64plus doesn't even bother emulating more than 1/5th the maximum possible number of instructions, or 18 million a second. I'm not really convinced that this is enough for all games, but any hypothetical that aren't can probably cope with it and will simply suffer from additional in-game slowdown. Which is usually a lot better than the emulator slowing down beyond frameskipping. which takes the audio and input responsiveness with it.
Fact is, 18 million is all that Mupen64plus is going to emulate, so we can take that number as a hard limit.
Cortex-A8, on the other hand, has been cited by ARM as executing an average of 0.9 instructions per cycle across several industry standard applications. This is not a maximum like our N64 number, just an average. I don't know the cache configuration they used, but I doubt it was something particularly extravagant. Scaled to clock speed this gives us 540 million instructions per second at 600MHz, or 30 times higher than what Mupen64plus's N64 can do.
Now, how much a recompiler's output falls under the "average" curve is another story - my guess is not that favorably, because they tend to generate a lot of instruction bloat and extra branches which hurts icache and BTB performance.
I've said this about 1000 times, but it's really silly when people say "you need N times the power of what you're emulating to emulate it", where N is some fixed number. For one thing, none of these people are even making remotely educated quantifications as to how powerful something is and instead just compare the clock speed of the main CPU on both, when CPU can be a very small portion of the overall system capability and when the CPUs are generally not comparable on clock basis. And it's silly because emulation overhead has a lot to do with how different the platform is and not just how much "weaker" it is. And then it depends on how accurate the emulation needs to be and what your exact goals are.
dflemstr said:
What I said was that IF N64 games perform a lot of floating point calculations then Wiz wouldn't cut it. What Ari64 has shown is that (at least for the popular games he tested) they don't. In fact, his Cortex-A8 code is using soft floats to begin with. I do find this a little surprising because StrmnNrmn gained noticeable performance improvements by adding register caching to floats, but this might have been very context limited. Ari64 cited 2-3.5% of CPU time, so 0.36 to 0.63 million per second, which is relatively manageable, and would perform better with custom recompiled code than with the libc calls that Mupen64plus is using.
Yes, the Wiz wouldn't compare highly well to the Pandora for running N64. But with floats out of the equation it looks at least worth trying. Converting down the ARMv6 instructions to ARMv5 equivalent chains would probably not hurt performance tremendously because unless I missed something the recompiler isn't relying on them for high performance in common code like for memory accesses or branches. Even though the 3D is only OpenGL ES 1.1 it is still as good as what several of the earlier N64 emulators were capable of doing, which was more than enough for emulating plenty of games satisfactorily. The Wiz's 3D vector coprocessor could also possibly be used to accelerate N64 T&L.
Mupen64plus is capable of giving results in at least something at 50% CPU usage for a 600MHz Cortex-A8. Wiz is probably usually less than half as fast per cycle, but can usually overclock to 800-850MHz. You might not get anything close to fullspeed across the board but all I ever said was PSP-level, which is certainly not that either.
Given that people have ported N64 emulators to GP2X where it was beyond ridiculous to expect a speed anyone would be happy with I would be surprised to see someone not eventually try to port this to Wiz. Even if that does mean a bit more work in the 3D department.
Poem58 said:
N64 was released in 1996, before the Pentium 2 was even out ;p Much less Pentium 3 or 4.. A common Pentium 1 of the day was probably much more powerful than the N64's CPU. But couldn't touch the vector capabilities of the RSP.
Last edited by a moderator:
borgqueenx
Well-Known Member
mmmm, so you are saying the pandora can emulate N64, but wont reach full speed if we use mupen64, but comes close? I dont know much about technical talk, but is this correct?
Gren
Very Active Member
Exophase said:
Interesting. How does the RSP compare to PC accelerators of the day? I had a Matrox Mystique 4MB in late '96 and then a 3Dfx Voodoo 1 in early '97.
Last edited by a moderator:
Exophase
Nothing good will ever come of Exophase.
borgqueenx said:
I never said anything like that, where did you get such an idea? Ari64 very much knows what he's doing, his port of Mupen64plus is not going to be handicapped.
Gren said:
RSP is a vector CPU, not a 3D accelerator. The 3D accelerator in the N64 is the RDP. It had a good number of features for its time, especially compared to consoles that came before it, but a pathetically small amount of texture RAM crippled it. I also heard turning on Z-buffering took away a lot of the fillrate - it might have not been cached well enough to cope with the RDRAM performing a read-modify-write cycle on one location and a write to another one. Actually, I bet its alpha blending fillrate wasn't that good either.
I don't know anything about the Matrox Mystique, but I'm sure the Voodoo 1 was better.
Last edited by a moderator:
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
Basically, the N64 doesn't execute nearly as many instructions as the CPU is theoretically capable of. Comparing clock speeds in this case makes even less sense than usual.borgqueenx said:
edit: additionally meaning that an emulator doesn't need to execute an instruction every emulated clock tick, only (about) 1/5th of them in this case.
Last edited by a moderator:
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
Because you said Mupen only emulates 1/5th of the maximum possible instructions. To someone that doesn't fully understand systems design, that's the same as "Mupen only runs at 1/5th maximum speed". Took me a second try to understand what was going on, but I only have a basic understanding of emulation.Exophase said:
Last edited by a moderator:
Exophase
Nothing good will ever come of Exophase.
WizardStan said:
Hm, okay.
If it really does become a problem I'm sure Ari64 will make options to circumvent it. I know PJ64 has this option for allowing games like Perfect Dark to run more smoothly. They probably run better than they do on a real N64, in this case. Most games are frame limited to 20 or 30fps, though (and don't usually dip below that).
Ari64 definitely knows what he's doing when it comes to doing a fast recompiler, so you can all count on him for the best results you'll get.
Last edited by a moderator:
TheRain
Member
Poem58 said:
Last edited by a moderator:
Patrick R Ludvigsen
Member
- Joined
- May 6, 2008
- Messages
- 243
wow, and I'm still learning basic C++...
This is very awesome and these guys are indeed coding geniuses
This is very awesome and these guys are indeed coding geniuses
greendots
Its finally here!
- Joined
- Mar 11, 2008
- Messages
- 610
Why does Mupen64plus and the other N64 emulators require so many graphics plug-ins? Theres about 4 or 5 that I know of- each with their own options that impact compatibility and speed. Why has there not been a single 'beat all, end all' graphics plug-in? Would it be possible to have one for the pandora?
