N64 On The Pandora

[dooradley]

ok so i just watched the video put up the other day of the pandora running mario 64, mario kart 64 and starfox. i'm amazed. but i'd like to know more and i can't seem to find any more info/videos anywhere. is there anyone that has more information? is the emu running other games at a decent speed? if it will run goldeneye or zelda at that speed at that resolution i'm running not walking to buy a pandora immediately!

 

[(naw)mcx]

ok so i just watched the video put up the other day of the pandora running mario 64, mario kart 64 and starfox. i'm amazed. but i'd like to know more and i can't seem to find any more info/videos anywhere. is there anyone that has more information? is the emu running other games at a decent speed? if it will run goldeneye or zelda at that speed at that resolution i'm running not walking to buy a pandora immediately!

Yes, go run! Go, run, buy a Pandora, you might make it to Newcastle by dawn!


lol.

 

[x68000]

It's starting to snow up here, so i'd put a decent pair of boots on

 

[dooradley]

you guys must be pretty bored. feel sorry for you. hopefully someone will actually answer my question...

 

[danielliu88888]

*resists the urge to piss around*


it's still being worked on, and there aren't very many more videos.

here's a link to the video vault, please check the pandora information index before asking questions like this again.

 

[kloplop321]

you guys must be pretty bored. feel sorry for you. hopefully someone will actually answer my question...

Check the pandora video vault http://kultpower.de/pandoravideos/ for more I guess.
The speed seems to have no problems on the most-tested games(like Mario) so it shouldn't have too much of an issue on others. I think it should decently run Golden eye with a little further development.

 

[carlgeorge]

It looks like N64 is much better than I ever expected. I knew PS1 would be okay, but the N64 I wasn't expecting to be this good this soon. Craig did mention that F-Zero didn't work properly yet, so there are some bugs still.

 

[gibberish]

i wouldnt imagine the f zero x problem is really much of one.
the game appears to run at full speed with no graphical glitches at all when the demo is left to roll.

i would assume that from a developers point of view that's a lot less of a problem to fix than if the game was running slowly with bad graphical glithces and stuff everywhere.*

*total uneducated guess

 

[x68000]

you guys must be pretty bored. feel sorry for you. hopefully someone will actually answer my question...

It's called Christmas spirit, you should try some :rolleyes:

 

[kingoddball]

Here is a link for technical detail, and the reasons some games won't run (GoldenEye will not run :angry: )

DO NOT POST in there, you may get shot by the mods.

[post='http://www.gp32x.de/board/index.php?/topic/49358-mupen64plus/page__pid__790747__st__495&#entry790747']Mupen64Plus Pandora[/post]

 

[dooradley]

thanks for the info. i guess i'll just have to hope and pray they see this project through.

 

[ari64]

The reason Goldeneye (and Paper Mario) crashes is because it executes code in virtual memory and the dynamic recompiler doesn't check the mapping when it compiles the code so it just bails out. But that's trivial to fix.

There are some bigger issues with the TLB support though. Currently all memory accesses are checked against the range 80000000-80800000 and anything outside this range (including virtual memory) results in a call to the function pointers in readmem/writemem. This is really slow, so any game that does this a lot is going to be unplayable on the Pandora.

So I need to make an inline lookup instead of a function call. The best I could come up with was something like this:

 add r2, fp, r1 lsr #10
 bic r2, r2, #3
 ldr r2, [r2, #offset]
 tst r2, #1
 bne io_handler
 ldr r0, [r1, r2]

which would replace the current

 cmp r1, #0x800000
 bvc io_handler
 ldr r0, [r1]

Of course it would be slower, so I would only have the compiler generate this code if the game is actually using the TLB.

To do this I would need to move the mapping tables into dynarec_local (which is what fp contains a pointer to) and set the low bits for the I/O range and unmapped memory. Also allocate another register in load_alloc and store_alloc so there is a register for this pointer to the mapping tables.

I probably won't have time to finish it until January. Then there's the TLB exception handling to do. Most games don't actually cause pagefaults, so maybe I can get some working without that.

 

[Awakening]

Ari64:
I have no idea what that means and I don't know what the TLB is. Paper Mario is probably the N64 game I want to play the most but since the battles require some button timing it needs to run smoothly. So I wonder if that's one of the games that will run too slow to ever be playable.

 

[ari64]

Ari64:
I have no idea what that means and I don't know what the TLB is. Paper Mario is probably the N64 game I want to play the most but since the battles require some button timing it needs to run smoothly. So I wonder if that's one of the games that will run too slow to ever be playable.

It loads the title screen then crashes, but I have a pretty good idea of what needs to be fixed. I'll look into it some more after the holidays.

 

[ashdjones]

Ari64:
I have no idea what that means and I don't know what the TLB is. Paper Mario is probably the N64 game I want to play the most but since the battles require some button timing it needs to run smoothly. So I wonder if that's one of the games that will run too slow to ever be playable.

It loads the title screen then crashes, but I have a pretty good idea of what needs to be fixed. I'll look into it some more after the holidays.

While we're all here asking, is the Fzero-X glitch serious? Its my favourite racing game ever!

 

[Awakening]

Ari64:
I have no idea what that means and I don't know what the TLB is. Paper Mario is probably the N64 game I want to play the most but since the battles require some button timing it needs to run smoothly. So I wonder if that's one of the games that will run too slow to ever be playable.

It loads the title screen then crashes, but I have a pretty good idea of what needs to be fixed. I'll look into it some more after the holidays.

Sounds great! I'm in no rush myself, so much else to play anyway. I never thought N64 would even run. Thanks for the hard work

 

[HackModford]

Hey Ari64! Do you think the enhanced texture packs will ever be possible?

 

[Exophase]

So I need to make an inline lookup instead of a function call. The best I could come up with was something like this:

   add r2, fp, r1 lsr #10
   bic r2, r2, #3
   ldr r2, [r2, #offset]
   tst r2, #1
   bne io_handler
   ldr r0, [r1, r2]

which would replace the current

   cmp r1, #0x800000
   bvc io_handler
   ldr r0, [r1]

Of course it would be slower, so I would only have the compiler generate this code if the game is actually using the TLB.

I hope we can turn every thread about Mupen64plus into a coding discussion ;D I have a few questions/comments about your implementation:

- Okay, I assume the emulated page table starts after #offset, but how important are the things in that region, such that you'd have fp point there instead of + offset forward? If you generally access things via immediate offsets from that point then it'd just be with negative offsets, but I think it's unlikely that you're doing anything that hits more frequently than memory code. But, this could be a compatibility issue against your normal mode of operation. If the offset isn't required you can load from (fp + ((address >> 12) << 2)), not that I need to tell you that.

- Thanks to several execution stages there's a 2-cycle address generation interlock penalty on Cortex-A8 now. This in addition to lots of other stalls that weren't seen in previous CPUs.. we should really get together and write an ASM optimization guide or something because I think some of these will really get us. But in this case it makes the above code at least 8 cycles total :/ (the only thing I can see pairing is tst/bne, although the first and last instructions could pair with unseen things). So if possible it'd be good to schedule the address generation in advance where you can. ... you probably already knew this too, but just in case.

- There's an alternative for MMU or complex memory space emulation that hlide suggested to me once, and I use in the MIPS version of gpSP.. I'm not sure yet if it would work out better for you or not, but the idea is to check if the entry is the same page as it was last time, and if so, use a direct routine. I think this would probably work better on x86 or a platform with larger immediates than on ARM, because you need to do a pretty large compare and immediate add. For ARM I think it'd be something like this:

 ubfx r2, r1, #12, #20
 movt r0, #offset_low
 movt r3, #last_memory_low
 movw r0, #offset_high
 movw r3, #last_memory_high
 cmp r2, r3
 blne memory_miss
 ldreq r0, [r0, r1]

Of course, this only works well if the memory accesses hit the same pages usually. Otherwise it incurs the costs of self-modifying code to update the offsets, which probably wouldn't be quite as bad if it didn't require going through the kernel. This uses more code space and worse, more registers, but I think it'll usually take less cycles since it pairs much better/has fewer stalls. This is assuming that the ubfx takes one cycle, since the TRM doesn't mention it. It probably has the usual shift interlock.

Oh, and of course this is totally unsuitable if the game actually changes the address space mappings at all.

 

[DaMummy]

The reason Goldeneye (and Paper Mario) crashes is because it executes code in virtual memory and the dynamic recompiler doesn't check the mapping when it compiles the code so it just bails out. But that's trivial to fix.

There are some bigger issues with the TLB support though. Currently all memory accesses are checked against the range 80000000-80800000 and anything outside this range (including virtual memory) results in a call to the function pointers in readmem/writemem. This is really slow, so any game that does this a lot is going to be unplayable on the Pandora.

So I need to make an inline lookup instead of a function call. The best I could come up with was something like this:

 add r2, fp, r1 lsr #10
 bic r2, r2, #3
 ldr r2, [r2, #offset]
 tst r2, #1
 bne io_handler
 ldr r0, [r1, r2]

which would replace the current

 cmp r1, #0x800000
 bvc io_handler
 ldr r0, [r1]

Of course it would be slower, so I would only have the compiler generate this code if the game is actually using the TLB.

To do this I would need to move the mapping tables into dynarec_local (which is what fp contains a pointer to) and set the low bits for the I/O range and unmapped memory. Also allocate another register in load_alloc and store_alloc so there is a register for this pointer to the mapping tables.

I probably won't have time to finish it until January. Then there's the TLB exception handling to do. Most games don't actually cause pagefaults, so maybe I can get some working without that.

i love it when you talk dirty to me Ari64

 

[kingoddball]

I love the nerd talk!
I may have no clue whats being said, but it sure is pretty!