N64 Emulator In The Work For Pandora

[ari64]

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.

It's 2-3.5% of the instructions, which is probably more than this percentage of the CPU time since these instructions take several cycles. Investigating how much time is actually spent on this is one of the things on my to-do list.

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.

Floats aren't the only issue. It was slower without the movt/movw instructions. Also, compiling without the pld (preload) instructions (which the ARM926EJ ignores) has a measurable negative effect.

It's just barely fast enough to run on the Pandora, so I'm not even going to consider the Wiz right now. I figure someone will probably try it sooner or later.

 

[Exophase]

It's 2-3.5% of the instructions, which is probably more than this percentage of the CPU time since these instructions take several cycles. Investigating how much time is actually spent on this is one of the things on my to-do list.

I meant instructions, which should have been clear by the counts per second listings I gave.

Floats aren't the only issue. It was slower without the movt/movw instructions.

These only gained 3% for you, and you didn't compare against compiled constants which would not have the negative effect on dcache/DTLB. The end result might be something inbetween.. which is kind of splitting hairs.

Also, compiling without the pld (preload) instructions (which the ARM926EJ ignores) has a measurable negative effect.

How bad is it? Since the Wiz doesn't have L2 cache at all I would just roll that into the general performance disadvantage I gave it (less than half the same speed per clock).

It's just barely fast enough to run on the Pandora, so I'm not even going to consider the Wiz right now. I figure someone will probably try it sooner or later.

I never expected you personally to try - I probably wouldn't either (actually, do you even have a Wiz..?)

But there is certainly an interest in levels of not-quite fullspeed N64 emulation on handhelds, if Daedalus's popularity is any indication. So "fast enough" varies with person.

Nonetheless, aren't you being a little pessimistic? Or are there not really popular games taking 50% of Cortex-A8 CPU time at 600MHz, like you've been saying? I think you may be overestimating the CPU demands a highly optimized video plugin will have. But this is all kind of meaningless until games really are running at full capacity (and with sound, I guess) on the Pandora.

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!

You're thinking of texture filtering, not anti-aliasing. Anti-aliasing is almost never a bad thing. Texture filtering is also usually a good thing if you're not often spanning much more than one texture pixel per screen pixel. Perhaps you prefer the PS1's textures more because they were higher resolution, since PS1 didn't have the same texture memory limitations that N64 did. You're probably right though, games of this era wouldn't always benefit from bilinear filtering on textures.

 

[Poem58]

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!

Sorry, your original post sounded more like they were technically the same in difficulty to emulate. Which is why I responded what I did.
However, I will concede that the Playstation has more games and probably even a larger audience and of course it is great to have both. I had the N64 but not a Playstation, I will now get to play some PSX games I otherwise never was able to and someone who never had the N64 will get the same chance. Good times for all!

 

[TheRain]

You're thinking of texture filtering, not anti-aliasing. Anti-aliasing is almost never a bad thing. Texture filtering is also usually a good thing if you're not often spanning much more than one texture pixel per screen pixel. Perhaps you prefer the PS1's textures more because they were higher resolution, since PS1 didn't have the same texture memory limitations that N64 did. You're probably right though, games of this era wouldn't always benefit from bilinear filtering on textures.

Ah yes you're right. anti-aliasing is for edges right? Yes it is the extremely blurred textures I'm talking about. I'd rather see pixels than obviously blurred images My opinion is- and this is from my remembering of the time period and the state of hardware 3-d graphics acceleration at the time of the n64- people were excited about extremely blurred textures because it represented something new in graphics technology- Hardware 3-d graphics operations like texture filtering and anti-aliasing were a *new thing* then.

 

[gruso]

I was one of those N64 fans who argued for the "proper" 3D capabilities of the N64 over the blocky mess of the PSX. Sure James Bond was blurry, but Lara Croft and her stupid world looked like they were made from Lego. I only learned the term "fanboy" a few years later.

 

[PokeParadox]

I was one of those N64 fans who argued for the "proper" 3D capabilities of the N64 over the blocky mess of the PSX. Sure James Bond was blurry, but Lara Croft and her stupid world looked like they were made from Lego. I only learned the term "fanboy" a few years later.

Yeah... I preferred a "proper" 3D accelerator in the console as opposed to... what the PS1 did. There were some great games on both systems, but when games were done properly on the N64 they looked a lot better than a lot of games on the PS1. There were many gems you just didn't get on PS1. I still Wave Race today.

 

[Dunny]

I was one of those N64 fans who argued for the "proper" 3D capabilities of the N64 over the blocky mess of the PSX. Sure James Bond was blurry, but Lara Croft and her stupid world looked like they were made from Lego. I only learned the term "fanboy" a few years later.

Tbh, you couldn't be more right. At least the N64 had decent perspective correction - the PS1 just looked distorted over short distances. That always bugged me, as the textures ended up zig-zagging up and down across the polygon. Wonder if it's possible to correct that in emulation? EPSXE certainly doesn't in R-Type Delta

D.

 

[kin]

I was one of those N64 fans who argued for the "proper" 3D capabilities of the N64 over the blocky mess of the PSX. Sure James Bond was blurry, but Lara Croft and her stupid world looked like they were made from Lego. I only learned the term "fanboy" a few years later.

Yeah... I preferred a "proper" 3D accelerator in the console as opposed to... what the PS1 did. There were some great games on both systems, but when games were done properly on the N64 they looked a lot better than a lot of games on the PS1. There were many gems you just didn't get on PS1. I still Wave Race today.

I luv waverace too... I haven't seen many games around that can beat those nice waves, control and playability.

 

[Exophase]

It's not surprising that PS1 lacked perspective correct texturing. Most early 3D accelerators and software renderers did. It's a pretty expensive operation.

You can't generally apply perspective correction to PS1 games because the vertex and texture coordinates are submitted without depth information. You'd have to have some kind of HLE that makes the emulator aware of what depth coordinates coming out of the GTE correspond to what inputs to the display list on the GPU (and hope that nothing modifies the former). I don't know how well it'd work, but at least it possibly wouldn't look worse than nothing if you got it wrong.

N64's RDP did have a lot of features, probably because it came from the world leader in professional 3D graphics. Only it was basically a professional solution stripped down to fit a commercial design and was thus heavily incapacitated. Perspective incorrect textures suck, but a lot of N64 games hardly used textures at all.

One area in which PS1 games shined over N64 one was 2D. The texture memory setup on N64 must have really hurt tile/sprite based 2D games too. You'd have to constantly upload tiles into 2KB (can't use the whole 4KB or else you wouldn't be able to render and upload at the same time).. probably less if you want to keep common palettes loaded.

 

[PokeParadox]

Yes, I saw a lot of people saying that the N64 was a stripped down SGI workstation. Rare actually had Banjo-Kazooie running in "Hi-Res" on an SGI workstation in one interview I saw.

 

[levi]

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.

Edit: Wrong end of stick on my part

 

[cb88]

acutally the reason it only runs 1/5 speed is because that is all that is needed for most games... they don't use the full cpu power

 

[Exophase]

The recompiler may work with 'only' 1/5th of the instructions possible but it must still emulate the rest. It could be faster than 1/5th speed if those are the most worthwhile instructions - but I think they're arguing about which instructions to tackle next.

The heck are you talking about..?

 

[ari64]

Also, compiling without the pld (preload) instructions (which the ARM926EJ ignores) has a measurable negative effect.

How bad is it? Since the Wiz doesn't have L2 cache at all I would just roll that into the general performance disadvantage I gave it (less than half the same speed per clock).

I recall it making a few percent difference when I first did it. But I just tested it again and it seems to make very little difference with null video rendering. I guess it only makes a difference when you knock a lot of stuff out of the L2 cache. Well, this is another little mystery to investigate.

(actually, do you even have a Wiz..?)

No

Nonetheless, aren't you being a little pessimistic? Or are there not really popular games taking 50% of Cortex-A8 CPU time at 600MHz, like you've been saying? I think you may be overestimating the CPU demands a highly optimized video plugin will have. But this is all kind of meaningless until games really are running at full capacity (and with sound, I guess) on the Pandora.

At 600Mhz, Zelda OoT is about 60% for r4300 emulation, and about 80% overall without video. I'd like to test it with that highly optimized video plugin.

Mario 64 is often under 60% for the dynarec, although I can confirm what Pickle said about the mario face hitting 80%+. I wonder what it's doing there.

 

[Exophase]

Mario 64 is often under 60% for the dynarec, although I can confirm what Pickle said about the mario face hitting 80%+. I wonder what it's doing there.

I THINK I heard floating point spike before, from StrmnNrmn. But this area has always been slower in emulators.

There's no audio right now right? What could be taking up so many cycles outside of recompiled code??

 

[ari64]

There's no audio right now right? What could be taking up so many cycles outside of recompiled code??

That was with audio.

 

[ari64]

acutally the reason it only runs 1/5 speed is because that is all that is needed for most games... they don't use the full cpu power

Nothing on N64 uses the full cpu power, because the memory is too slow.

 

[ari64]

Mario 64 is often under 60% for the dynarec, although I can confirm what Pickle said about the mario face hitting 80%+. I wonder what it's doing there.

I THINK I heard floating point spike before, from StrmnNrmn. But this area has always been slower in emulators.

hmm.. It is around 5-6% FPU instructions (about 1 million per second)

 

[MDave]

acutally the reason it only runs 1/5 speed is because that is all that is needed for most games... they don't use the full cpu power

Nothing on N64 uses the full cpu power, because the memory is too slow.

I wonder what sort if games we would of seen if the hardware flaws (correct me if I'm wrong?) didn't exist What a waste of a good CPU.

 

[Exophase]

There's no audio right now right? What could be taking up so many cycles outside of recompiled code??

That was with audio.

I wonder if the audio plugin used can be optimized further any either. At any rate, people (not me) are often willing to play without audio if it means the difference between fullspeed and not very full speed.