Mupen64Plus

[ari64]

I guess you already know that, but the recently released n64oid (not the same that is on Google Code) uses both code from Ari64's recompiler release 20110128, and Adventus' gles2n64 plugin rev. 22. I was able to find function genjmp from the former and __indexmap_getnew from the latter.

The genjmp() function existed before, but in 20110128 I added the jump table, which is one of the things required to accommodate Android's memory layout. If you can find this table, you can find pointers to most of the rest of the code, even if he stripped the binary.

Of course, he's charging $6 for it and the source is nowhere to be found...

I wonder how difficult it would be to get Google to pull it from the appstore. I suspect stuff like this is partly why Apple and Microsoft have a general "no GPL apps" policy.

 

[javispedro]

The genjmp() function existed before, but in 20110128 I added the jump table, which is one of the things required to accommodate Android's memory layout. If you can find this table, you can find pointers to most of the rest of the code, even if he stripped the binary.

Yes, there's way more -- probably all of the code, and even lots of parts of mupen64plus itself. For example, all of Adventus' assembly is there too. I specifically searched for those two functions because they would be easy to recognize and allowed me to identify the version/release.

He's mostly statically linked the plugins and core into a ~700KiB binary.

 

[b._.o._.b]

I wonder how difficult it would be to get Google to pull it from the appstore. I suspect stuff like this is partly why Apple and Microsoft have a general "no GPL apps" policy.

I just did some research and I can tell you that the Google method looks pretty daunting.
The easiest way is probably contact yongzh and ask for the source, and when he refuses then go to http://www.gnu.org/licenses/gpl-violation.html

Apparently it worked for this example:

http://forums.opensuse.org/english/other-forums/looking-something-other-than-support/388609-best-places-report-gpl-violation.html

Maybe even someone else could do it for you, but I think it should be someone who understands and is able to explain how to see your code was stolen.

 

[bzfrank]

I think I have fixed gles2n64 so OOT (and perhaps more others) now works.
It was a heap corruption caused by an invalid free, however I also found
some other issues that are now fixed.

Changes to make it run are (based on the r22 0.0.4 plugin
as available on http://code.google.com/p/gles2n64/)

1. Texture.h - changed line 34

#define TEXTUREBUFFER_SIZE (128 * 1024)

to

#define TEXTUREBUFFER_SIZE (256 * 1024)

May not be strictly needed, but as long as memory is plenty give
things a bit more space

2. Texture.cpp - changed line 385

u8 noise[64*64*2];

to

u8 noise[64*64*4]; // a bit too large now, but its on the stack anyway

The noise generator code following this line was messing with the stack since
above array was defined a tad to small.

3. Texture.cpp - uncommented line 856

free ( dest );

to

// free ( dest ); // maybe not a good idea to free a static, non-malloced buffer

This was likely the real McCoy, it caused quite some heap corruption over time and
directly lead to the strange behaviour of LOZ:OOT. I suspect it also affected
others too.

Can someone please verify these patches?

 

[notaz]

Can't comment about texture memory, it depends on the games I guess.

2. Texture.cpp - changed line 385

u8 noise[64*64*2];

to

u8 noise[64*64*4]; // a bit too large now, but its on the stack anyway

The noise generator code following this line was messing with the stack since
above array was defined a tad to small.

Don't think so - maximum x and y can reach 63, which means maximum index is 63*64*2+63*2+1 = 8191, while the buffer size is 64*64*2 = 8192, so it should be fine.

3. Texture.cpp - uncommented line 856

free ( dest );

to

// free ( dest ); // maybe not a good idea to free a static, non-malloced buffer

This was likely the real McCoy, it caused quite some heap corruption over time and
directly lead to the strange behaviour of LOZ:OOT. I suspect it also affected
others too.

Great work, have you tried contacting the author with this (through google code perhaps)?

You can post the plugin binary I guess, somebody will then make a .pnd .

 

[Schnatterplatsch]

Whooot??? I love you Please create a binary

 

[Dead1nside]

That's great news bzfrank.

 

[silver]

Changes to make it run are (based on the r22 0.0.4 plugin
as available on http://code.google.com/p/gles2n64/)

Link showing "404 Not Found" for me....?

Great work though...

 

[gruso]

Stray parenthesis caught up in the URL parsing. Fixed.

 

[bzfrank]

Thanks Gruso,

BTW regarding the optimization of the CRC routines (also in this version), I just did some tests on the Pandora by wrapping it in a small test program and doing a CRC32 on a 64 kbyte chunk of memory 65536 times:

pandora:/tmp$ time ./testcrc_mupenoriginal
real 0m45.112s
user 0m44.789s
sys 0m0.219s

pandora:/tmp$ time ./testcrc_fastcrc
real 0m24.017s
user 0m23.844s
sys 0m0.094s

So its almost half the time and twice as fast. Since every time a texture is loaded a CRC is done it can help a bit.

 

[bzfrank]

Just uploaded the PND to the http://dl.openhandhelds.org/ file archive.

If you got the PND from Grusos site, you can dl it again from above location: It fixes the program icon (looks nicer in the menu). Also added some other variations of the gles2n64 plugins with different optimizations, the default one should be good for most everything however.

R1B3F - BZ Fix sounds ok.

 

[gruso]

User chat moved to beta thread: http://www.gp32x.de/board/index.php?/topic/53683-mupen64plus

Let's keep support issues & compatibility talk in that thread, and leave this one for dev talk.

 

[Wally]

Hey Ari, you got a public GIT or Subversion somewhere?

 

[ari64]

Updated dynarec: http://hotfile.com/dl/121021087/9688f9b/mupen64plus-arm-20110615.tar.gz.html

Diffs: http://hotfile.com/dl/121021405/f8158af/patches-20110128-20110615.tar.gz.html


Changes since 20110128:

- Expand cache size for MIPS code (performance)

- Avoid unnecessary saving/restoring of registers (performance)

- Fix some inefficiencies in the liveness analysis (performance)

- Fix problem with 64-bit registers in delay slots (bug)

- Fix problem with hoisting loads out of loops where the loop immediately follows a call/return (bug)

- Fix incorrect clearing of dirty flag when reallocating registers (bug)

- Fix stack alignment on x86 (bug)

- Make compilation of OpenGL parts (on-screen display) optional

 

[Blue Protoman]

Now we need a PND! Anybody care to be so kind?

 

[Schnatterplatsch]

Whoot? Thank you so much Ari, with your work you are making one of the greatest presents the pandora ever got!!! The words in the brackets sound like a wet dream
...by the way, have you gotten a place to donate to in the meantime?


EDIT: Maybe ED can give you some webspace?!? There are some guys with *.gp2x.de domains running around here
EDIT2: Whoever blesses us with a pnd do not forget the latest gfx-plugin: http://www.gp32x.de/board/index.php?/topic/53683-mupen64plus/page__view__findpost__p__950745

 

[quartercast]

PND courtesy of sebt3

Thanks Ari64!

http://repo.openpandora.org/?page=detail&app=mupen64plus

 

[Dead1nside]

Thanks Ari64, and sebt3 for packaging that up so fast.

 

[DaMummy]

ari, i love you, take ownership of mupen on repo and put up a donate link

 

[Wally]

Goldeneye is now VERY playable