N64

[Destructo2000]

As in the description, I'm not going to ask why we don't have N64 emulation, I already know the answer to that. I am curious though, as I haven't been able to find this on the internet anywhere. What would be the absolute lowest system requirements for an N64 emulator? I know the PSP is at 33 mhz, but then again, it doesn't have a high compatibility rate. Also, I know project64 needs 600 mhz. Anyways, I was just wondering what would be needed to get one to run at a reasonable speed, say 20-30 fps. Oh yeah, what kind of graphics capabilities would be needed?

 

[rokdcasbah]

medium to high? h34r:

it really depends on a lot of things...for one thing psp mips chip != x86 chip. so even using mhz as a rough guide is pretty useless. i'm going to say it's more the quality of the software than anything. most emulators, even ones that look accurate, aren't accurate down to every line of code ("emulate"...who decides what the criteria is for that?). the second big problem is that different hardware is just different. i guess you're going to want floating point, and some kind of way to execute similar instructions in parallel. like mmx, or a second chip for 3d acceleration (again...what's getting accelerated specifically? it's hard to quantify these things when there's so many variations.

or we could just oversimplify things and argue to pass the time

 

[RockOut]

Well, the GP2X has two 200mhz processors overclockable to 250mhz. That is an effective 500 mhz or maybe a bit less because the second core is limited. Should be enough raw power for the n64 even though the n64 is complicated...

 

[Nr.56]

Well, the GP2X has two 200mhz processors overclockable to 250mhz. That is an effective 500 mhz or maybe a bit less because the second core is limited. Should be enough raw power for the n64 even though the n64 is complicated...

maybe effective 500Mhz arm power , you can´t compare an arm with x86-processor or a mips! there are a lot of differences between the architectures. belive in the developers, i think they know what they talk about :lol:

 

[slaanesh]

There's an N64 emulator (Daedalus) for the PSP. It's not fullspeed, but it is impressive considering it's running @ 333Mhz with graphic acceleration. If Daedalus could some how use the 2nd processor on the PSP I'd say you'd be looking at some funky N64 handheld love.

Like the PS1 emulator for the PSP, I'd imagine if a large company with the right financing (ie. Sony or Nintendo) wanted to write an N64 emulator, something with the power of a PSP would be able to handle it.

But then Sony isn't going to write an N64 emulator for their PSP and Nintendo isn't going to write an N64 emulator for Sony's PSP...

 

[Nr.56]

There's an N64 emulator (Daedalus) for the PSP. It's not fullspeed, but it is impressive considering it's running @ 333Mhz with graphic acceleration. If Daedalus could some how use the 2nd processor on the PSP I'd say you'd be looking at some funky N64 handheld love.

Like the PS1 emulator for the PSP, I'd imagine if a large company with the right financing (ie. Sony or Nintendo) wanted to write an N64 emulator, something with the power of a PSP would be able to handle it.

But then Sony isn't going to write an N64 emulator for their PSP and Nintendo isn't going to write an N64 emulator for Sony's PSP...

well, release nr.12 is in the pipeline! daedalus is a great emulator :rolleyes: but mips is not arm, it seems to me that daedalus on gp2x will (unfortunately) never be possible.

 

[Exophase]

Well, the GP2X has two 200mhz processors overclockable to 250mhz. That is an effective 500 mhz or maybe a bit less because the second core is limited. Should be enough raw power for the n64 even though the n64 is complicated...

This logic doesn't work at all for emulators where it's often difficult to impossible to really parallelize it. For instance you can't really use two CPUs to emulate a single CPU more efficiently, unless the code written for it is quite high level and inherently multithreaded and you can high level emulate the OS, and even then it would be very tricky. This would only work well if the threads were well balanced. In N64's case, none of these things apply.

It works a little better for splitting say, CPU and video emulation, but you only get high benefits out of this if the cost of emulating both is about equal. Unfortunately both things can be data set heavy, so not very good for putting on the 940T which only has 4KB of data cache. notaz found an excellent use for the 940T in emulating Sega Genesis's FM synthesizer - this is a rare case of a component in an emulator that has a lot of computational power over a small data set (the input is several PSGs, which only need tiny lookup tables), and the output is probably relatively negligable due to write buffering. In most cases you will not get benefits like this in emulation.

Now about the whole CPU comparison thing... yes, again... it's very easy for people to say "___ is not ___" and they do it a lot, although not without really expanding on it in a meaningful way >_> In terms of integer performance MIPS and ARM aren't that far off - MIPS on MIPS does help a bit, but not a lot. The main thing here is that you need an FPU to emulate FPU without sacrificing an unbearable amount of speed and GP2X just doesn't have one. That's the nail in the coffin right there. VFPU and of course 3D accceleration help the PSP tremendously too.

But clock for clock any x86 post Pentium will smoke either CPU in average amount of work done per clock cycle. Although x86 isn't as well equipped for efficient dynarec of RISC platforms.

 

[Nr.56]

thanks for your explanation.
in case of native code: how efficient works the magic eyes chipset in comparison to other typical gameenvironments? are psx or n64-class games possible (native coded)?

 

[sam fisher]

thanks for your explanation.
in case of native code: how efficient works the magic eyes chipset in comparison to other typical gameenvironments? are psx or n64-class games possible (native coded)?

See payback. I'd call that around PSX or N64 class. BTW, i'm pretty sure i made payback work faster using the proper working MMU hack instead of the different one that comes with it

 

[messiah]

imho lowest requirements to emulate n64 was Pentium (non mmx) 133mhz with 32mb ram and 3dfx 4mb with ultra-HLE emu. SM64 was playable without problems. and it was long time ago, probably 1998

 

[fusion_power]

Why everyone always want a N64 Emulator on GP2X? We don't even have a Full Speed GBA Emu, so how should a N&4 Emu work? I have never seen Bilinear Filtering in Software for example and N64 uses bilinear Filtering. GP2X has no 3D Hardware so how should this be done? I think it wohld make more sense to concentrate on possible emulators and the optimization of them. It's enough work and when we have all the possible Emulators on GP2X maybe we could start to think about the impossible ones :lol:

 

[PokeParadox]

There was actually a demo released on GP2X that did do software bi-linear filtering. I really don't see N64 as a feasible project. Maybe someone will eventually port it for geek-points... but I doubt it would be useful...

 

[Alex.]

BTW, i'm pretty sure i made payback work faster using the proper working MMU hack instead of the different one that comes with it

Seriously? So the mmu.o from Picodrive would improve performance in Payback?

I wonder if the DRM would kick off if I overwrote it :unsure:

 

[Retroid]

imho lowest requirements to emulate n64 was Pentium (non mmx) 133mhz with 32mb ram and 3dfx 4mb with ultra-HLE emu. SM64 was playable without problems. and it was long time ago, probably 1998

At the time the UltraHLE authors were suggesting a 300MHz CPU with 64megs of RAM. Mario64 was just about full speed but Zelda did chug a little.

There was another emu, was it called Corn? That didn't get far but it did an amazing job of getting Mario almost playable without GPU help.

 

[notaz]

Unfortunately both things can be data set heavy, so not very good for putting on the 940T which only has 4KB of data cache. notaz found an excellent use for the 940T in emulating Sega Genesis's FM synthesizer - this is a rare case of a component in an emulator that has a lot of computational power over a small data set (the input is several PSGs, which only need tiny lookup tables), and the output is probably relatively negligable due to write buffering. In most cases you will not get benefits like this in emulation.

Well that YM2612 FM chip is quite a heavy beast to emulate, calculating every sample involves ~2-4 lookups in a table of ~200K of size, and up to 5 channels can be used, so lookups multiply by that. Earlier versions of the code were using 2 smaller tables instead of that ~200K one, and they were slower. I wouldn't diminish ARM940 that much. Overclocking RAM helps a lot there, it should be able to do many things even with it's small cache. I think the main problem is paralellizing our emulators, not the crippled ARM940 core.

 

[rokdcasbah]

doesn't the mips chip in n64 do floating point? i would guess that would be sort of important. yet another reason why mhz don't mean much unless you're comparing exactly the same cpu core.

 

[Squidge]

and the same features. Eg. If you took two MIPS processors - one with 64KB of icache/dcache @ 200mhz, and another @ 300mhz but with no icache/dcache, which one would be faster?

 

[Exophase]

Unfortunately both things can be data set heavy, so not very good for putting on the 940T which only has 4KB of data cache. notaz found an excellent use for the 940T in emulating Sega Genesis's FM synthesizer - this is a rare case of a component in an emulator that has a lot of computational power over a small data set (the input is several PSGs, which only need tiny lookup tables), and the output is probably relatively negligable due to write buffering. In most cases you will not get benefits like this in emulation.

Well that YM2612 FM chip is quite a heavy beast to emulate, calculating every sample involves ~2-4 lookups in a table of ~200K of size, and up to 5 channels can be used, so lookups multiply by that. Earlier versions of the code were using 2 smaller tables instead of that ~200K one, and they were slower. I wouldn't diminish ARM940 that much. Overclocking RAM helps a lot there, it should be able to do many things even with it's small cache. I think the main problem is paralellizing our emulators, not the crippled ARM940 core.


I stand by what I said anyway You might have a 200K table, but you probably stay within local regions.

 

[notaz]

I stand by what I said anyway You might have a 200K table, but you probably stay within local regions.

Might be, haven't done any analysis on this.

 

[Exophase]

I stand by what I said anyway You might have a 200K table, but you probably stay within local regions.

Might be, haven't done any analysis on this.


You'd be a little hard pressed to.. I wish ARM920T had performance counters.