Page 2 of 9

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Tue Jan 29, 2013 10:16 pm
by marqs
HonkeyKong wrote:I'm using the maemo version. I couldn't find any other ones. If you could point me toward the original version, I would like to play around with getting it running. I was planning on trying to rewrite the ARMv7 ASM in GLES2N64 to work with ARMv6.
I meant the standard version found here. That doesn't include dynarec support for arm though.

From a quick look, there's not much asm in GLES2N64 besides some NEON code, which isn't supported on Pi anyway. I got it compiled by omitting -D__NEON_OPT, but the plugin wasn't recognized by standard mupen64plus. BTW, did you try -march=armv6 -mfloat-abi=hard -mfpu=vfp flags when compiling mupen64plus-arm?

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Wed Jan 30, 2013 12:16 am
by HonkeyKong
marqs wrote:I meant the standard version found here. That doesn't include dynarec support for arm though.

From a quick look, there's not much asm in GLES2N64 besides some NEON code, which isn't supported on Pi anyway. I got it compiled by omitting -D__NEON_OPT, but the plugin wasn't recognized by standard mupen64plus. BTW, did you try -march=armv6 -mfloat-abi=hard -mfpu=vfp flags when compiling mupen64plus-arm?
Yes, I did use those exact compiler flags when building. Thanks for the link, I'll see what I can do with it. :)

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Sat Mar 02, 2013 7:20 am
by SuperTaranta
Curious how its going for HonkeyKong. Any Status?

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Sat Mar 02, 2013 7:42 pm
by HonkeyKong
SuperTaranta wrote:Curious how its going for HonkeyKong. Any Status?
Unfortunately, there hasn't been any new progress on that front. I've been buried in contract work and haven't had the time to touch it for a few weeks. I am, however, interested in whether or not anyone else has had luck getting it to build and run.

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Sat Mar 02, 2013 9:08 pm
by SuperTaranta
HonkeyKong wrote:
SuperTaranta wrote:Curious how its going for HonkeyKong. Any Status?
Unfortunately, there hasn't been any new progress on that front. I've been buried in contract work and haven't had the time to touch it for a few weeks. I am, however, interested in whether or not anyone else has had luck getting it to build and run.
I completely understand, we all have our share of real life, and its not easy. I'm curious too if anyone actually picked this up or if everyone just dropped it.

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Tue Mar 19, 2013 2:33 pm
by felix3008
Hi,
I'm fairly new to porting over things to arm but i will try to port DaedalusX64 (Which ran quite good on my psp (333 mhz!)).

Felix3008

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Sun Apr 28, 2013 1:42 am
by theidealist
Alright, so I'm digging into this too. I would love to turn my little pi into a killer N64 emulator. I miss Ocarina of Time.

Anyway, after a little bit of tinkering with make files and whatnot, I got stuck with the same "uses vfp register arguments" linker error that HonkeyKong reported when he tried to make the maemo port work. I guess there's no real surprise there. It's got something to do with the linkage_arm.s file in the r4300/new_dynarec folder, I'm pretty sure. That file is basically just assembly language -- I'm a C++ guy and may use the asm keyword on occasion but this file and it's usage by the compiler is a mystery to me. But I know I want the assembly language, if at all possible. With as much basic math and floating point stuff the N64 undoubtedly does, I'd prefer the whole thing to be written in assembly if it could be. I changed a bunch of stuff in and around that file but have not yet managed to make it work. I'm guessing that it needs to be ported to use VFP directly if we want it to work on our scrawny armv6's.

So, then I started to try and bring over the more actively maintained mupen64plus-ae (android edition) from https://github.com/paulscode/mupen64plus-ae . While porting to android itself was certainly a major undertaking, the base C code seems to have been significantly refactored from the maemo version, and is now much cleaner. The problem here? Building crashes the compiler.

Code: Select all

../../src/r4300/new_dynarec/assem_arm.c:2005:33: warning: ‘addr’ may be used uninitialized in this function [-Wuninitialized]
../../src/r4300/new_dynarec/new_dynarec.c:4731:11: note: ‘addr’ was declared here
../../src/r4300/new_dynarec/assem_arm.c:1012:33: warning: ‘alt’ may be used uninitialized in this function [-Wuninitialized]
../../src/r4300/new_dynarec/new_dynarec.c:4731:16: note: ‘alt’ was declared here
gcc: internal compiler error: Killed (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.
make: *** [_obj/r4300/new_dynarec/new_dynarec.o] Error 4
make: Leaving directory `/home/pi/rpi/buildroot/rpi-buildroot/output/build/mupen64plus-ae-master/jni/core/projects/unix'
Well that was a dead end too -- now I'm more than a little stuck. I'm beginning to think that I'll need to understand ARM assembly language, the VFP extensions, gcc "multilib" arm nuances and the "softfp" flag. As I'm working on this now and pouring over the linkage_arm.s file, a few helpful links I've found are:

http://infocenter.arm.com/help/topic/co ... index.html [VFP instruction set]
http://wiki.debian.org/ArmHardFloatPort/ [tons of useful stuff relating to ARM, EABI, VFP, NEON, arm version, marketing name, etc. Arm is confusing!]

For benefit of users everywhere, I include the following information on the current version of gcc as provided by raspbian (I can't believe I couldn't find this anywhere online already!):

Code: Select all

$ gcc -march=armv6 -mfloat-abi=hard -mfpu=vfp -Q --help=target -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14+rpi1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.6.3 (Debian 4.6.3-14+rpi1) 
COLLECT_GCC_OPTIONS='-march=armv6' '-mfloat-abi=hard' '-mfpu=vfp' '-Q' '--help=target' '-v'
 /usr/lib/gcc/arm-linux-gnueabihf/4.6/cc1 -v -imultilib . -imultiarch arm-linux-gnueabihf help-dummy -dumpbase help-dummy -march=armv6 -mfloat-abi=hard -mfpu=vfp -auxbase help-dummy -version --help=target -o /tmp/cc5NVdzn.s
The following options are target specific:
  -mabi=                      		
  -mabort-on-noreturn         		[disabled]
  -mandroid                   		[disabled]
  -mapcs                      		[disabled]
  -mapcs-float                		[disabled]
  -mapcs-frame                		[disabled]
  -mapcs-reentrant            		[disabled]
  -mapcs-stack-check          		[disabled]
  -march=                     		armv6
  -marm                       		[enabled]
  -mbig-endian                		[disabled]
  -mbionic                    		[disabled]
  -mcallee-super-interworking 		[disabled]
  -mcaller-super-interworking 		[disabled]
  -mcirrus-fix-invalid-insns  		[disabled]
  -mcpu=                      		
  -mfix-cortex-m3-ldrd        		[enabled]
  -mfloat-abi=                		hard
  -mfp16-format=              		
  -mfp=                       		
  -mfpe                       		[disabled]
  -mfpe=                      		
  -mfpu=                      		vfp
  -mglibc                     		[enabled]
  -mhard-float                		[disabled]
  -mlittle-endian             		[enabled]
  -mlong-calls                		[disabled]
  -mpic-register=             		
  -mpoke-function-name        		[disabled]
  -msched-prolog              		[enabled]
  -msingle-pic-base           		[disabled]
  -msoft-float                		[disabled]
  -mstructure-size-boundary=  		
  -mthumb                     		[disabled]
  -mthumb-interwork           		[enabled]
  -mtp=                       		
  -mtpcs-frame                		[disabled]
  -mtpcs-leaf-frame           		[disabled]
  -mtune=                     		
  -muclibc                    		[disabled]
  -mvectorize-with-neon-quad  		[disabled]
  -mword-relocations          		[disabled]
  -mwords-little-endian       		[disabled]

GNU C (Debian 4.6.3-14+rpi1) version 4.6.3 (arm-linux-gnueabihf)
	compiled by GNU C version 4.6.3, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9
GGC heuristics: --param ggc-min-expand=55 --param ggc-min-heapsize=47969
COLLECT_GCC_OPTIONS='-march=armv6' '-mfloat-abi=hard' '-mfpu=vfp' '-Q' '--help=target' '-v'
 as -march=armv6 -mfloat-abi=hard -mfpu=vfp -meabi=5 -o /tmp/cceVs8dC.o /tmp/cc5NVdzn.s
Let me know if any of you have any great ideas

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Sun Apr 28, 2013 7:54 am
by marqs
theidealist wrote:So, then I started to try and bring over the more actively maintained mupen64plus-ae (android edition) from https://github.com/paulscode/mupen64plus-ae . While porting to android itself was certainly a major undertaking, the base C code seems to have been significantly refactored from the maemo version, and is now much cleaner. The problem here? Building crashes the compiler.
I recall stumbling into similar compiler crash when compiling the official version of the emulator. You could try a newer gcc or linaro compiler - see this.

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Sat May 11, 2013 12:57 am
by theidealist
marqs wrote:
theidealist wrote:So, then I started to try and bring over the more actively maintained mupen64plus-ae (android edition) from https://github.com/paulscode/mupen64plus-ae . ... The problem here? Building crashes the compiler.
I recall stumbling into similar compiler crash when compiling the official version of the emulator. You could try a newer gcc or linaro compiler - see this.
Thanks! I haven't gotten to changing my compiler, but that might be necessary for this all to work.

For now, I wanted to pass along that I got the base mupen64plus code compiling and linking, although the gles2n64 plugin is not working just yet. I basically wanted to report the solution to the annoying linker error with the linkage_arm.s assembly file
/usr/bin/ld: error: mupen64plus uses VFP register arguments, /tmp/ccO2ia9P.o does not
The answer was amazingly simple (it always, is, right?).

I had a friend who is good with ARM stuff spend some time with me on it and he had the observation that the assembly file is not actually using any floating point math, so it *shouldn't* matter if it is using VFP register arguments or not. The VFP register arguments are just to enhance functions that accept and return floating point values, in order to save the enormous overhead that is there in copying things into and out of the VFP co-processor. I don't understand why, but apparently it can take up to 20 cycles just to copy a single precision floating point from a CPU register to/from a VFP register.

Anyway, once we realized that, we figured it was just a matter of fooling the linker into thinking that the assembly file did in fact use VFP register arguments. That's where this mail message came in extrordinarily helpful:

http://gcc.gnu.org/ml/gcc-help/2012-02/msg00082.html

We added ".eabi_attribute 28, 1" to the assembly file near the top with the other .eabi attribute entries, and voila! It linked! And it built! And it runs!

This is all using the hard (fast, in-hardware) floating point, so I am pretty excited that it should be good once I get the gles2n64 stuff worked out.

That's another post... For later...

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Thu May 23, 2013 4:56 pm
by segalion
Hello...

any news about...?

any link where follow the progress...?

Do you know could be possible to play Ocarina at natural framerate? Seems that pcsx_rearmed work at decent for some games (probably is the minimum HW required)..., and I dont know if n64 demand more or less cpu/gpu...

Thanks for this great...

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Thu Jun 13, 2013 7:33 am
by mrpi64
Nice Idea!

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Mon Jul 22, 2013 4:54 pm
by nexusrex
i have retropie image can i install the n64 emulator or no

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Mon Jul 22, 2013 6:25 pm
by KitchUK
No you can't emulate the N64 as far as I know. Would love some Mario 64 though!

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Mon Jul 22, 2013 6:35 pm
by nexusrex
no mupen64plus emulator for retropie image
WHY :evil:

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Mon Jul 22, 2013 7:51 pm
by nexusrex
mupen64plus-n64 emulator for the pi
can i install it and playing roms
i have retropie image
please help me
:|

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Mon Jul 22, 2013 8:02 pm
by portets
It was never finished.

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Tue Jul 23, 2013 12:43 am
by theidealist
Yeah, I am still working on it in my "free time", but I don't have much of that these days.

I was really excited about it working but it turned out there was some strange stuff happening in the dynarec (dynamic recompiler) that all the emulation relies upon. That is some crazy code if I've ever seen it! I tried for a couple of weeks to debug via normal means (mainly the insertion of copious print statements to try and see where it crashed), but didn't have any luck. I really didn't/don't understand how that thing is doing anything sensible for anyone...

I decided instead to go after the paulscode mupen for android project that is running successfully on lots of phones which are also underpowered and ARM based. The struggle right there is that building that project natively on the pi either crashes the onboard compiler or - if you're lucky - actually crashes the whole system, I think due to resource exhaustion (but that is pure speculation). I am currently fighting with a buildroot setup that will allow me to cross compile that project for the pi. We'll see how it goes, but I am not optimistic at this point, merging the two build systems is beyond my current abilities to hack makefiles.

One thing I am optimistic about is that if we can get it running and using the "new" dynarec with a VFP enabled ARM based backend, it will be performant. There's no reason it shouldn't be.

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Tue Jul 23, 2013 8:48 pm
by marqs
I think the general lack of commitment comes from the fact that RPi is underpowered to run many N64 games. While I believe some games like Mario64 could run almost or completely at full speed, various games (e.g. Goldeneye) are never going to work well on Pi - just look at the system requirement notes on PC-based N64 emulators.

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Wed Jul 24, 2013 12:37 am
by teeth_03
I wonder how much extra cycles you could get by having the option of disabling audio. It would be better than nothing.

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Wed Jul 24, 2013 12:46 pm
by abishur
personally, I think that if there were ever to be a version that even remotely came close to working, someone would have to basically make it from the ground up to use the GPU powers for 100% of the processes that can use the GPU and only use the CPU for things that absolutely could not use the GPU. It would be a huge undertaking and even then I'm not sure if it would be enough to get a truly workable solution. :(

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Fri Aug 09, 2013 5:50 am
by HonkeyKong
Well, after a weekend and some change tinkering with it, I've managed to get the libretro version of Mupen64Plus to compile and run, as evidenced by the photo here. So far, I've managed to successfully run Super Mario 64, The Legend of Zelda: Ocarina of Time, and Killer Instinct Gold.

However, right now it only runs at 3-5 FPS, as it's using the interpreter core instead of the dynarec core. At the moment I'm working with the ARM dynarec to see if I can get that working, and hopefully gain a considerable speed boost. If someone could point me toward a port of M64+ that uses the ARM dynarec core, it would help me incorporate that into the build system, and get the ball rolling on a decent N64 emulator for the Raspberry Pi once and for all.

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Fri Aug 09, 2013 6:32 am
by KitchUK
Yes! You sir, are amazing. :)

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Fri Aug 09, 2013 6:54 am
by welshy
Be buoyed by the fact this is the first time anybody has actually got N64 emulation running AT ALL on the RPi! Hopefully (and with further work) you can get it to a acceptably playable/runnable state. Nice Job! I have added a post/link in the Emulation 'Sticky' documenting your progress and asking for assistance in locating the port of M64+ that uses the ARM dynarec core.

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Fri Aug 09, 2013 4:38 pm
by HonkeyKong
Welshy, thanks for the assistance. As of right now, I've run into the same problem as marqs and theidealist, with GCC crashing while trying to compile new_dynarec.c, but I've found that it compiles just fine when using clang to compile instead. Now, I think it's just a matter of tweaking on the Makefile enough to make it link and run correctly without complaining about missing symbols when loading the library. Lots of trial and error here, but it's very promising. :-P

Re: Mupen64Plus - N64 Emulator for the Pi

Posted: Sat Aug 10, 2013 1:05 am
by HonkeyKong
I got the new_dynarec.c issue sorted out. All it took was manually compiling that file and removing the -O3 optimization switch. So, now it compiles and links with the dynarec core, but I haven't figured out where it's looking for the mupen64plus.cfg file to tell it to use that core instead of the cached interpreter, or any of the other settings, like filtering, motion blur, etc. I'm hoping once I get that sorted, we'll have a somewhat usable emulator on our hands. :)