N64 Emulator In The Work For Pandora


Don't forget about the fact that architectural differences can also assist in emulation. (They can sometimes hurt as well, though.)
 
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.
 
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.
 
Neko said:
Poem58 said:
When I first got my PSP the boards were full of coders saying that you needed roughly 10 times the CPU speed to emulate an older system. (not doing a CPU comparison here just pointing out what was said)
The Pandora CPU arguably is 10x faster than the N64. The clock speed is 6 to 9 times faster (some devs are overclocking) but it's also dual-issue and has a larger cache.

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:
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.

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:
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.

dflemstr said:
He means that Wiz doesn't have some features that a N64 emulator needs. Without hardware-supported floating point operations, for instance, games will run extremely slowly on the Wiz. So, the Wiz will probably be able to run N64 games as well as a PSP in some cases, but it will most probably be even slower on the Wiz compared to on a PSP if a game uses a lot of floating point operations.

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:
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.

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:
Exophase 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.

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:
borgqueenx said:
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?

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:
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.

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:
borgqueenx said:
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?
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.

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:
Exophase 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.
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.
 
Last edited by a moderator:
WizardStan said:
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.

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:
Poem58 said:
Playstation had a main CPU running at 33.8688 MHz

While the N64 had a main cpu running at 93.75 MHz and a co-processor running at 62.5 MHz.

You make a good point, and I agree- these guys ARE geniuses. And I am a coder by occupation. Of course- at the end of the day it doesn't really matter if I believe that an N64 EMU is any more of a paramount acheivement than Playstation 1 which we already have.


In my opinion, though, PS1 is just as paramount an achievement for the Pandora- if purely from an ends vs means perspective. Processing power aside- PS1 games are just as graphically pleasing IMO as N64 games... sometimes more so since the N64 appears to employ gratuitous anti-aliasing where it would be better if it didn't have it at all IMO. Therefore- for me, the end result is that PS1 games are just as, if not more exciting to have available on the Pandora. But of course, having both PS1 and N64 games playable will be a very welcome end result of having such hard working geniuses around here!
 
Last edited by a moderator:
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?
 
Back
Top