N64 Emulator In The Work For Pandora

[Exophase]

Exophase are you programming or giving advice on the port?

Edit: Just wondering, i am trying to gauge progress. Wish there was a main repo for the project.

I don't have anything to do with the development of the N64 emulator, I'm just commenting.

 

[supermario0x40]

Ari64: Here's what I replaced the UXTH line (and its corresponding outupt_w32 line) in emit_andimm() with:

assem_debug("mov %s,%s asl #16",regname[rt],regname[rs]);
assem_debug("mov %s,%s lsr #16",regname[rt],regname[rs]);
output_w32(0xe1a00000|rd_rn_rm(rt,0,rs));
output_w32(0xe1a00000|rd_rn_rm(rt,0,rs));

I got that by trial and error - I don't know very much ARM assembly to be honest.
I was attempting to learn so I could write my own dynarec (that is, before you released yours), but it would have taken me 4 years instead of 4 months

 

[ari64]

Ari64: Here's what I replaced the UXTH line (and its corresponding outupt_w32 line) in emit_andimm() with:

assem_debug("mov %s,%s asl #16",regname[rt],regname[rs]);
assem_debug("mov %s,%s lsr #16",regname[rt],regname[rs]);
output_w32(0xe1a00000|rd_rn_rm(rt,0,rs));
output_w32(0xe1a00000|rd_rn_rm(rt,0,rs));

I got that by trial and error - I don't know very much ARM assembly to be honest.
I was attempting to learn so I could write my own dynarec (that is, before you released yours), but it would have taken me 4 years instead of 4 months

That is clearly incorrect, it's just the same mov instruction repeated twice with no shift. Mario 64 might not crash immediately since it doesn't have a lot of instructions that would use this.

Try this:

    assem_debug("bic %s,%s,#FF000000\n",regname[rt],regname[rs]);
    output_w32(0xe3c00000|rd_rn_rm(rt,rs,0)|0x4FF);
    assem_debug("bic %s,%s,#00FF0000\n",regname[rt],regname[rt]);
    output_w32(0xe3c00000|rd_rn_rm(rt,rt,0)|0x8FF);

 

[supermario0x40]

Thanks Ari64! This is why I ended up not writing my own... I know even less than I thought! I'm compiling it as we speak. I have a better camera now, so I'll be making another video soon. And maybe a Mario Kart 64 demo too! Come to think of it, MK64 did crash before - I wonder why...

edit: removed smileys

 

[ari64]

Thanks Ari64! This is why I ended up not writing my own... I know even less than I thought! I'm compiling it as we speak. I have a better camera now, so I'll be making another video soon. And maybe a Mario Kart 64 demo too! Come to think of it, MK64 did crash before - I wonder why...

Mario Kart should work (it works for me).

Shifts would've worked, if you had included the shifts in the instruction encoding. However, shifts can take an extra cpu cycle on many ARM processors so I tend to avoid them if possible.

 

[borgqueenx]

Thanks Ari64! This is why I ended up not writing my own... I know even less than I thought! I'm compiling it as we speak. I have a better camera now, so I'll be making another video soon. And maybe a Mario Kart 64 demo too! Come to think of it, MK64 did crash before - I wonder why...

edit: removed smileys

cant wait for it

 

[supermario0x40]

cant wait for it

Here it is. http://www.youtube.com/watch?v=ZggGMLBr2Oo

edit: Mario Kart had a white screen with glN64 (the rest worked), so I just did a better Mario 64 video.

 

[WizardStan]

IT LIVES!
How does the XScale processor compare to the OMAP3, do you know? I couldn't find much to compare against, other than it doesn't look like the ipaq has floating point or a dedicated GPU, whereas the Pandora has NEON and the SGX.

 

[Vorporeal]

It's also using a software renderer, so the video should run MUCH faster on the Pandora, as Adventus has ported glN64 to OGLES, so we'll have the SGX processing graphics, taking the load off of the Cortex.

 

[Exophase]

Shifts would've worked, if you had included the shifts in the instruction encoding. However, shifts can take an extra cpu cycle on many ARM processors so I tend to avoid them if possible.

Only if you're shifting by a register. They may take an extra pipeline stage on Cortex-A8, but I don't think it causes any additional dependency problems.

 

[ari64]

Shifts would've worked, if you had included the shifts in the instruction encoding. However, shifts can take an extra cpu cycle on many ARM processors so I tend to avoid them if possible.

Only if you're shifting by a register. They may take an extra pipeline stage on Cortex-A8, but I don't think it causes any additional dependency problems.

Yes, it takes an extra pipeline stage. The proposed code was this (as an alternative to uxth)

lsl r0,r0,#16
lsr r0,r0,#16

I don't think the A8 has dependency problem with this, but on some cpus there can be a one-cycle stall because the shift executes one pipeline stage before the rest of the instruction.

 

[Exophase]

Shifts would've worked, if you had included the shifts in the instruction encoding. However, shifts can take an extra cpu cycle on many ARM processors so I tend to avoid them if possible.

Only if you're shifting by a register. They may take an extra pipeline stage on Cortex-A8, but I don't think it causes any additional dependency problems.

Yes, it takes an extra pipeline stage. The proposed code was this (as an alternative to uxth)

lsl r0,r0,#16
 lsr r0,r0,#16

I don't think the A8 has dependency problem with this, but on some cpus there can be a one-cycle stall because the shift executes one pipeline stage before the rest of the instruction.

Which CPUs? Anything ARM9 or earlier definitely won't have such a problem. It appears that XScale has this problem, so ARM11 might too. But it wouldn't surprise me if it was just XScale.

 

[ari64]

Which CPUs? Anything ARM9 or earlier definitely won't have such a problem. It appears that XScale has this problem, so ARM11 might too. But it wouldn't surprise me if it was just XScale.

Gilberto Tanzola is using XScale, so guess why I recommended BIC.

Either one would be okay on ARM9 (Wiz).

 

[Exophase]

I don't think we should all have to pay for Intel's design compromises in XScale ;D It's a good choice for his XScale specific application, but you made it sound like you were avoiding those shifts in general. Of course, if you can schedule something in the interlock slot then you're as good as doing it that way no matter the platform.

Back then it seems like Intel was making a lot of crippling decisions on their archs and expected compilers/programmers to stop doing things the way they had been (never mind legacy code).. we all know how well that turned out for XScale.

 

[ari64]

I don't think we should all have to pay for Intel's design compromises in XScale ;D It's a good choice for his XScale specific application, but you made it sound like you were avoiding those shifts in general. Of course, if you can schedule something in the interlock slot then you're as good as doing it that way no matter the platform.

Back then it seems like Intel was making a lot of crippling decisions on their archs and expected compilers/programmers to stop doing things the way they had been (never mind legacy code).. we all know how well that turned out for XScale.

There's nothing wrong with using 2 bic instructions, it's just as fast on ARM9.

I am careful with shifts in general as they are problematic on the A8. While a shift will not stall another shift, an arithmetic operation will stall a subsequent shift on the A8. Fortunately ARMv6 has sign/zero extension instructions, so shifts aren't needed for that. Another thing is that, unlike MIPS, when doing register specified shifts ARM considers up to 8 bits significant. So I have to mask the upper bits before doing the shift, which requires another instruction and stalls the shift. Luckily SLLV/SRLV/SRAV are relatively uncommon instructions so it's not a huge performance problem.

 

[Exophase]

Yeah, that sucks. At least it's a lot easier to emulate MIPS shifts with ARM than ARM shifts with MIPS, though.

 

[ari64]

Yeah, that sucks. At least it's a lot easier to emulate MIPS shifts with ARM than ARM shifts with MIPS, though.

Not too bad if you can use conditional moves. That's how I did the 64-bit shifts. Probably would be hard on MIPS III though.

 

[Exophase]

Yeah, that sucks. At least it's a lot easier to emulate MIPS shifts with ARM than ARM shifts with MIPS, though.

Not too bad if you can use conditional moves. That's how I did the 64-bit shifts. Probably would be hard on MIPS III though.

Yes, I use conditional moves, but it's still worse than just having to mask the shift amount.

 

[calc84maniac]

*gravedig*

So let me make sure I got this straight - what's happening now is that Pickle is trying to get the OGLes video plugin to compile correctly?

 

[God Ginrai]

*gravedig*

So let me make sure I got this straight - what's happening now is that Pickle is trying to get the OGLes video plugin to compile correctly?

This isn't really old enough to call it a gravedig. It's more like a Bump. And yes, I believe that is the current state of things. I keep watching the dev thread for more info, but it's pretty much gone quiet there, much to my disappointment. :\

-God Ginrai