Mupen64Plus - N64 Emulator for the Pi

[theidealist]

HonkeyKong,

That is really exciting! I didn't even try the interpreter as I figured it would not even make 1 fps.

And that was especially brilliant to use clang - I don't know why I didn't think of that!

Did you build clang from source with gcc natively?

The best active arm dynarec project I am aware of is paulscode's android app. The problem there is they are using the android make system which is not very helpful if the main things you are trying to figure out is Makefile madness (which is the whole krux of this whole port to rpi, I think). They are at least using more recent pulls of mupen and the project is in pretty active development. They also have overhauled the normal Makefile build process with a system of their own, but I am not sure if that is supposed to work. Anyway the project is on github:

https://github.com/paulscode/mupen64plus-ae

It runs flawlessly with every rom I've tried on my galaxy s4 phone.

Keep up the good work and let us know when it's hacked!

[HonkeyKong]

HonkeyKong,

That is really exciting! I didn't even try the interpreter as I figured it would not even make 1 fps.

And that was especially brilliant to use clang - I don't know why I didn't think of that!

Did you build clang from source with gcc natively?

The best active arm dynarec project I am aware of is paulscode's android app. The problem there is they are using the android make system which is not very helpful if the main things you are trying to figure out is Makefile madness (which is the whole krux of this whole port to rpi, I think). They are at least using more recent pulls of mupen and the project is in pretty active development. They also have overhauled the normal Makefile build process with a system of their own, but I am not sure if that is supposed to work. Anyway the project is on github:

https://github.com/paulscode/mupen64plus-ae

It runs flawlessly with every rom I've tried on my galaxy s4 phone.

Keep up the good work and let us know when it's hacked!

I used the version of clang that was in the Raspbian APT repo, but ended up falling back to GCC. The new_dynarec.c compiles fine with -O2 instead of O3, however, when I run it, I get an Illegal Instruction error as soon as the dynarec core starts up. Below is the output from when I run this:

Code: Select all

pi@raspberrypi ~ $ /home/pi/RetroArch-master/retroarch -L /home/pi/mupen64plus-libretro-master/mupen64plus_libretro.so --config /home/pi/n64/mupen64plus.cfg n64/Super\ Mario\ 64\ \(U\)\ \[\!\].z64
RetroArch: Loading default config.
RetroArch: Looking for config in: "/home/pi/.config/retroarch/retroarch.cfg".
RetroArch: Looking for config in: "/home/pi/.retroarch.cfg".
RetroArch: Looking for config in: "/etc/retroarch.cfg".
=== Config ===
=== Config end ===
RetroArch [WARN] :: system_directory is not set in config. Assuming system directory is same folder as game: "".
RetroArch: Found default config: /etc/retroarch.cfg.
=== Build =======================================
Compiler: GCC (4.6.3) 32-bit
Built: Aug  7 2013
=================================================
RetroArch: Loading dynamic libretro from: "/home/pi/mupen64plus-libretro-master/mupen64plus_libretro.so"
RetroArch: Environ SET_VARIABLES.
RetroArch: Core option:
RetroArch:      Description: Texture filtering
RetroArch:      Key: mupen64-filtering
RetroArch:      Current value: automatic
RetroArch:      Possible values:
RetroArch:              automatic
RetroArch:              bilinear
RetroArch:              nearest
RetroArch: Version of libretro API: 1
RetroArch: Compiled against API: 1
RetroArch: Environ SET_PIXEL_FORMAT: XRGB8888.
RetroArch: Environ SYSTEM_DIRECTORY: "n64/".
RetroArch: Loading ROM file: n64/Super Mario 64 (U) [!].z64.
RetroArch: Did not find a valid ROM patch.
RetroArch: CRC32: 0x3ce60709, SHA256: 17ce077343c6133f8c9f2d6d6d9a4ab62c8cd2aa57c40aea1f490b4c8bb21d91
RetroArch: ROM size: 8388608 bytes.
RetroArch: Environ GET_VARIABLE mupen64-filtering:
RetroArch:      automatic
RetroArch: Environ SET_HW_RENDER.
RetroArch: Requesting OpenGLES2 context.
mupen64plus: Goodname: Super Mario 64 (U) [!]
mupen64plus: Name: SUPER MARIO 64
mupen64plus: MD5: 20B854B239203BAF6C961B850A4A51A2
mupen64plus: CRC: 635a2bff 8b022326
mupen64plus: Imagetype: .z64 (native)
mupen64plus: Rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
mupen64plus: ClockRate = f
mupen64plus: Version: 1444
mupen64plus: Manufacturer: Nintendo
mupen64plus: Cartridge_ID: 4d53
mupen64plus: Country: USA
mupen64plus: PC = 80246000
mupen64plus: Save type: 0
RetroArch: Set audio input rate to: 31973.33 Hz.
RetroArch: Adjusting aspect ratio to 1.33
RetroArch: Video @ 1920x1440
RetroArch: [VC/EGL]: Initializing...
RetroArch: Found GL context: videocore
RetroArch: Detecting screen resolution 1280x720.
RetroArch: [GL]: Vendor: Broadcom, Renderer: VideoCore IV HW.
RetroArch: Querying GL extension: BGRA8888 => exists
RetroArch: [GL]: BGRA8888 extension found for GLES.
RetroArch: GL: Using resolution 1280x720
RetroArch: [GL]: Using GLSL shader backend.
RetroArch [WARN] :: [GL]: Stock GLSL shaders will be used.
RetroArch: Found GLSL vertex shader.
RetroArch: Shader log: Compiled
RetroArch: Found GLSL fragment shader.
RetroArch: Shader log: Compiled
RetroArch: Linking GLSL program.
RetroArch: Found GLSL vertex shader.
RetroArch: Shader log: Compiled
RetroArch: Found GLSL fragment shader.
RetroArch: Shader log: Compiled
RetroArch: Linking GLSL program.
RetroArch: Found GLSL vertex shader.
RetroArch: Shader log: Compiled
RetroArch: Found GLSL fragment shader.
RetroArch: Shader log: Compiled
RetroArch: Linking GLSL program.
RetroArch: GL: Loaded 1 program(s).
RetroArch: Querying GL extension: OES_rgb8_rgba8 => exists
RetroArch: [GL]: Initializing HW render (1024 x 1024).
RetroArch: [GL]: Max texture size: 2048 px, renderbuffer size: 2048 px.
RetroArch: Using font rendering backend: freetype.
RetroArch: Graphics driver did not initialize an input driver. Attempting to pick a suitable driver.
RetroArch: [Joypad]: Found pad: SZMy-power LTD CO.  Dual Box WII on /dev/input/js0.
RetroArch: [Joypad]: Found pad: SZMy-power LTD CO.  Dual Box WII on /dev/input/js1.
RetroArch: Found joypad driver: "linuxraw".
RetroArch: ALSA: Using signed 16-bit format.
RetroArch: ALSA: Period size: 384 frames
RetroArch: ALSA: Buffer size: 1536 frames
RetroArch: Sinc resampler [C]
RetroArch: SINC params (8 phase bits, 16 taps).
RetroArch: [RGUI]: Opening history: /home/pi/n64/.retroarch-game-history.txt.
RetroArch: Environ SYSTEM_DIRECTORY: "n64/".
INI_FindSection trying to find name for DEFAULT
mupen64plus: No video plugin attached.  There will be no video output.
mupen64plus: No RSP plugin attached.  The video output will be corrupted.
mupen64plus: No audio plugin attached.  There will be no sound output.
mupen64plus: No input plugin attached.  You won't be able to control the game.
mupen64plus: Memory initialized
INI_FindSection trying to find name for DEFAULT
INI_FindSection trying to find name for SUPER MARIO 64
&ConfigOpenSection is 0xb05f1da4
mupen64plus: ConfigGetParamBool(): Parameter 'VerticalSync' not found!
(II) Setting video mode 640x480...
Congratulations, you have 4 auxilliary buffers, we'll use them wisely !
mupen64plus: Starting R4300 emulator: Dynamic Recompiler
mupen64plus: Init new dynarec
Illegal instruction

The errors about no plugins seem to be normal, and with the interpreter, it runs normally (albeit slowly) with sound and video. The problem I have now is, I don't understand how the dynarec works well enough to tell what instructions are throwing it off. Looks like tonight will be spent reading tech docs and scouring Google.

[HonkeyKong]

Small status update:

The dynamic recompiler now builds, links, and runs successfully, though the speed boost isn't what I had hoped it would be. It seems like it runs about twice as fast as the interpreter, so it's still not quite playable. In the meantime, I'll be tearing into the config files and video/audio plugin code to see what I can do to squeeze some more speed out of it. If anyone knows the ins and outs of N64 emulation well enough that they could give me some pointers, it would be greatly appreciated.

[marqs]

Great work!

Code: Select all

...
RetroArch: Video @ 1920x1440
RetroArch: [VC/EGL]: Initializing...
RetroArch: Found GL context: videocore
RetroArch: Detecting screen resolution 1280x720.
RetroArch: [GL]: Vendor: Broadcom, Renderer: VideoCore IV HW.
RetroArch: Querying GL extension: BGRA8888 => exists
RetroArch: [GL]: BGRA8888 extension found for GLES.
RetroArch: GL: Using resolution 1280x720
...

Have you tried forcing the Rpi output to 640x480 (hdmi_mode=1 in /boot/config.txt)? That should save some cpu cycles and speed up emulation.

[HonkeyKong]

Great work!

Code: Select all

...
RetroArch: Video @ 1920x1440
RetroArch: [VC/EGL]: Initializing...
RetroArch: Found GL context: videocore
RetroArch: Detecting screen resolution 1280x720.
RetroArch: [GL]: Vendor: Broadcom, Renderer: VideoCore IV HW.
RetroArch: Querying GL extension: BGRA8888 => exists
RetroArch: [GL]: BGRA8888 extension found for GLES.
RetroArch: GL: Using resolution 1280x720
...

Have you tried forcing the Rpi output to 640x480 (hdmi_mode=1 in /boot/config.txt)? That should save some cpu cycles and speed up emulation.

Yes, it runs exactly the same. I believe what it's doing is rendering the frames at 640x480 to a quad that's stretched to the native resolution. I haven't torn through enough of the rendering code to confirm this though.

[ric_rpi]

I have something running fairly well https://github.com/ricrpi/mupen64plus-rpi but would appreciate some help with optimizing and bug fixing it.

Currently on a 950Mhz overclocked PI, I get 25-30FPS so with frame skipping on, it is almost running at normal speed.

I intend to rewrite the Audio plugin next, to squeeze some more performance out as there are a lot of unnecessary data moving going on.

If someone could sort out the screen flickering and translucent picture that would be great

[KitchUK]

This is looking promising! keep at it guys

[welshy]

ric_rpi
Do you have any instruction on how to build the source? Having issues, seems to build ok but there is no Binary produced (even with a make install). Looking at the above I'm guessing its a Retro Arch (Retro Pie) Core (that's why I have no Binary?)?

[ric_rpi]

I uploaded an incorrect m64p_build.sh script to git. You need to build all the modules by setting M64P_COMPONENTS within the script by including the hashed out libraries.

I have been modifying the standard Mupen64Plus 2.0

[welshy]

ric_rpi
Mmm, still no 'Binary' even with the suggested changes. Going to use a 'DevBuild' Wheezy Image (with shed loads of dependencies installed!) and try again...

[ric_rpi]

What output/error message do you get and which libraries are built?

You will need SDL dev libraries

[welshy]

ric_rpi
I don't seem to get any errors on the build and I have sdl, png, zlib, gtk, etc etc in my 'DevBuild' Wheezy Image (I have built all my binaries using it). I just don't seem to end up with a usable Binary when completed.

[ric_rpi]

I have updated m64p_build.sh on git to include all the libraries and binary that need to be built.

The libraries and binary should be in a folder called test/

If you capture the build output, I'll check to see if anything is missing?

[chibcha8]

(Total noob here)

So does this mean it works? One one hand it sounds like it does, but on the other you said "with no video output" so does that mean it runs, but we cant actually put it on the tv?

And you mentioned that you are confident it could run mario 64, is this a slow game? Honestly the real reason i want n64 roms is for 007 and pokemon stadium. So would those games be do-able?

[ric_rpi]

The video partially works, it has a translucent effect to it but is rendering the expected textures, There is an OPENGL error on a Zbuffer clear or something like that just after the screen is redrawn - this may be the cause of the translucency. I may look at this when I next get on the pi or if I can test for translucency within a screen shot.

The code is quite a way off to being fully functional and the keyboard input does not appear to work in-game but I have not tried with a joystick yet.

I have been testing with Zelda64 and the Mupen64plus test rom.

Given that it is rendering textures and runs at almost full speed, I think that it's just possible to run mupen64plus on the pi with sound. - But a lot of optimisation is required...

[welshy]

Running the m64p_build.sh Script it fails at -

************************************ Building ui-console front-end
make: Entering directory `/home/pi/mupen64plus-rpi-master/source/mupen64plus-ui-console/projects/unix'
Makefile:87: Architecture "armv6l" not officially supported.'
CC _obj/cheat.o
CC _obj/compare_core.o
CC _obj/core_interface.o
CC _obj/main.o
../../src/main.c: In function ‘ParseCommandLineFinal’:
../../src/main.c:466:1: error: expected ‘)’ before numeric constant
make: *** [_obj/main.o] Error 1
make: Leaving directory `/home/pi/mupen64plus-rpi-master/source/mupen64plus-ui-console/projects/unix'

Editing the Script, makes it build ok but no Binary/Executable is produced.

[ric_rpi]

I've corrected the file in git now.

Line 466 in source/mupen64-plus-ui-console/src/main.c should be

Code: Select all

DebugMessage(M64MSG_WARNING, "%s:%d couldn't parse resolution '%s'", __FILE__, __LINE__, res);

[welshy]

ric_rpi
I can confirm it builds successfully and SDL Input works with an xbox360 wired joypad. I will do some further testing and report my findings.

[welshy]

ric_rpi
I have been conducting some testing with Super Mario 64, Starfox 64 and Pilotwings 64. All are playable with some texture issues, but, they do work! Congratulations! I am running my RPi at 900MHz and they seem to perform at approx 45FPS without sound, 25FPS with sound. I conclude (as suspected) N64 emulation is possible on the RPi with further optimisation and help from the community. I wont add to the 'Emulation on the Raspberry Pi Thread' as yet though, I have already indicated things are progressing in regards to N64 emulation (A link to Honkey Kong's Video posted at Shea's Blog). Once again, great work!

[Toad King]

Great work!

Code: Select all

...
RetroArch: Video @ 1920x1440
RetroArch: [VC/EGL]: Initializing...
RetroArch: Found GL context: videocore
RetroArch: Detecting screen resolution 1280x720.
RetroArch: [GL]: Vendor: Broadcom, Renderer: VideoCore IV HW.
RetroArch: Querying GL extension: BGRA8888 => exists
RetroArch: [GL]: BGRA8888 extension found for GLES.
RetroArch: GL: Using resolution 1280x720
...

Have you tried forcing the Rpi output to 640x480 (hdmi_mode=1 in /boot/config.txt)? That should save some cpu cycles and speed up emulation.

Yes, it runs exactly the same. I believe what it's doing is rendering the frames at 640x480 to a quad that's stretched to the native resolution. I haven't torn through enough of the rendering code to confirm this though.

Yes, that's how the libretro Mupen64Plus core works. By default it renders 640x480 to a framebuffer which is then stretched when drawn to the screen. If you're basing this off the libretro port (it looks like it) there is a way to change the render target size, but I doubt that would help.

What might help is fixing the video drivers. We're currently doing that in our own port, and ran into quite a bunch of big issues with the current video drivers, especially the glide2gles wrapper.

[ric_rpi]

Update:

The graphics are opaque now but there is still a texture depth issue.

I have written a new sound plug-in which is a little quicker on the pi but causes a glibc error when it closes and may have a clicking sound (not listened to latest code output).

When there is no sound plug-in the CPU is 5% idle when running at 950Mhz.

[welshy]

ric_rpi
Impressive! I have run Super Mario 64, Pilotwings 64, Mario Kart 64 and Starfox 64, without sound ALL are totally playable! (RPi Medium Overclock at 900MHz). We are definitely getting closer to a workable N64 emulator on the RPi thanks to you and Honkey Kong!

[ric_rpi]

Latest:

Graphics may be fixed but don't know why so I have now included my mupen64plus.cfg file in the repository.

New sound plugin using Native libraries, not listened to output but know it under-runs still. I suspect this is caused by the emulation itself as CPU is 5-15% idle whilst executing.

[KitchUK]

Do you think this emu will eventually be added (with permission) to RetroPie?

I'd love to start using it via the script, then updates through the binaries.

[Simonvinder]

I honestly hope this is gonna be part of the RetroPi! Would be awesome to play N64 games on it aswell