WIP: Playable Nintendo 64 Emulator Available

[whise]

I have my gpu to use 384 mb of ram... i guess i have been doing this all wrong...

[welshy]

whise
Not to worry, at least your now aware! Most programs only require a maximum of 64MEG applied to the GPU (in certain instances 128) and then ONLY if the software uses OpenGLES rendering. As a general rule 64MEG should be sufficient in most cases.

[KitchUK]

whise
Not to worry, at least your now aware! Most programs only require a maximum of 64MEG applied to the GPU (in certain instances 128) and then ONLY if the software uses OpenGLES rendering. As a general rule 64MEG should be sufficient in most cases.

It might just be my setup but I noticed that if you assign 64mb to the GPU then you can get some missing textured in emulationstation with Retropie. For example backgrounds will be blank (white) logos can sometimes be missing.

[welshy]

It might just be my setup but I noticed that if you assign 64mb to the GPU then you can get some missing textured in emulationstation with Retropie. For example backgrounds will be blank (white) logos can sometimes be missing.

Yup, that's why I said "In Certain Instances", the RetroArch Psx_ReARMed Core also requires 128MEG applied to prevent flickering (although the standard Binary doesn't) and strangely only with a 512MEG RPi.

[NITROgaming]

Does anyone know of a possible way to run goldeneye X / Perfect dark in this? It is the only game i want on my pi at the moment but at most i could get is the menu. With the settings sugested for regular goldeneye, the game quits itself and returns to the menue I made in emulation station. The rom is good because it runs on my 2 laptops no problem. Any help is appreciated.

[ric_rpi]

I would have thought Mupen64plus is too slow to play Perfect Dark at the moment but I have not tried it. Note the compatibility list states Perfect dark has issues.

However, do you get any error mesages and which video plug-ins are you using or have you tried both?

[welshy]

I would have thought Mupen64plus is too slow to play Perfect Dark

It works with the correct settings, but very, very, slowly! (i.e. not worth playing).

[whise]

Is there a way to make settings game specific?

[ric_rpi]

Only video-rice and video-glide can set parameters on a per game basis.

You could create config files in a directory structure on a per-game basis then when you run mupen64plus, point it to the config directory with '--configdir'.

[moocow1452]

Currently I'm trying to monkey around with the Beaglebone Black to see if I can port the n64 code over in a more stable fashion than the Pi would allow. No luck thus far, build chokes up on the bcm_host file and I can't find hide or hair of the source of the Ari64 version used to put it to ARM. Any ideas on if a port is even possible or worth the time to put into it?

[welshy]

moocow1452
I would think the BBB should be capable of a improved port given the newer, faster ARM rev and the GPU is supposed to be superior for polygon generation, although, the optimisations ric_rpi has used may negate this advantage.

[moocow1452]

moocow1452
I would think the BBB should be capable of a improved port given the newer, faster ARM rev and the GPU is supposed to be superior for polygon generation, although, the optimizations ric_rpi has used may negate this advantage.

Okay. So where would I start poking around in order to see how it ticks? esUtil.o seems to be the problem child here, but I can't find it in the file tree after a build attempt in order to snip the bcm_host reference out.

Code: Select all

debian@arm:~/mupen64plus-rpi$ sh m64p_build.sh
************************************ Building core library
make: Entering directory `/home/debian/mupen64plus-rpi/source/mupen64plus-core/projects/unix'
Makefile:101: Architecture "armv7l" not officially supported.'
rm -f -r libmupen64plus.so.2.0.0 libmupen64plus.so.2 _obj
make: Leaving directory `/home/debian/mupen64plus-rpi/source/mupen64plus-core/projects/unix'
make: Entering directory `/home/debian/mupen64plus-rpi/source/mupen64plus-core/projects/unix'
Makefile:101: Architecture "armv7l" not officially supported.'
    CC  _obj/api/callbacks.o
    CC  _obj/api/common.o
    CC  _obj/api/config.o
    CC  _obj/api/debugger.o
    CC  _obj/api/frontend.o
    CC  _obj/api/vidext.o
../../src/api/vidext.c: In function ‘VidExt_GL_GetProcAddress’:
../../src/api/vidext.c:268:5: warning: implicit declaration of function ‘glXGetProcAddress’ [-Wimplicit-function-declaration]
../../src/api/vidext.c:268:5: warning: return makes pointer from integer without a cast [enabled by default]
    CC  _obj/api/esUtil.o
../../src/api/esUtil.c:35:23: fatal error: bcm_host.h: No such file or directory
compilation terminated.
make: *** [_obj/api/esUtil.o] Error 1
make: Leaving directory `/home/debian/mupen64plus-rpi/source/mupen64plus-core/projects/unix'

[ric_rpi]

moocow1452

On the pi the GPU needs to be initialized with respect to the application that wishes to use certain GPU features (such as GLES).

This is done by calling a function bcm_host_init().

For your port to BBB you need to comment out/remove the lines #include <bcm_host.h> and bcm_host_init(). I don't know if BBB has a similar requirement for GPU initialization.

There is some code in rpiGLES.c that will also need tweaking. I have a feeling esUtil.c is no longer needed in my port but I haven't tried to remove it.

There may be some arm assembler that might not be compatible but the rest of the code should be portable. You may also need to modify the makefiles as the pi has lots of headers and libraries in /opt/vc/...

[ric_rpi]

Hardware DMA is now working for some n64 memory data transfers (spmem <=> dram) but I am only seeing a 1% speed increase. My assumption is that Linux can't be 'lazy' with caching so the gain from hardware DMA is reduced.

I haven't completed HW DMA for dma_pi_read() and dma_pi_write() yet due to some technical issues but this should increase the speed further.

[rathalex]

Hi all,

first: thank you for this great work!

I have a problem with the emulator: The emulation freezes after a while. "Freeze" means, it just stops with the frame that is currently displayed, while the music plays on. It happens in Super Mario 64, while Mario walks around in the entrance hall of the castle. It doesn't happen always in exactly the same situation, but it is reproducible. The Pi itself, however, is not stuck. I can hit "Esc" (local or via SSH) in order to close the emulation. Do you have any idea, what could cause this behavior?

Some background info:
I use a B-Model
GPU split is set to 128MB (I've also tried 64MB, no difference)
The swap file is 1GB
OC is set to 900MHz (no difference with other settings)
I have a game controller attached to the Pi
I have a WiFi stick attached to the Pi
I did rpi-update (no difference)
Super Mario 64 is the only ROM I've tested so far

Regards,
Alex

[ric_rpi]

rathalex

I think this is a problem with the emulation 'collapsing' with Super Mario when using the dynamic recompiler. mupen64plus is still running which is why you can press escape to quit.

I have seen files created which might by 'dumps' from the dynamic recompiler. They seem to suggest ucode problems. Do you have one in the mupen64plus/test directory with a time stamp around when the error occurred?

Can you also remember if the sound carries on playing and if you hear sounds when pressing 'start' to pause/unpause the game?

[welshy]

rathalex
Welcome to the Forum! OK, this sound like the Screen Update Settings issue (See previous Posts)

[Video-Rice]
# Control when the screen will be updated (0=ROM default, 1=VI origin update, 2=VI origin change, 3=CI change, 4=first CI change, 5=first primitive draw, 6=before screen clear, 7=after screen drawn)
ScreenUpdateSetting = (Default: 6)

In early builds a setting of 4 prevented the render 'Freeze', for some reason on later versions 1 was needed. I have just compiled the latest revision and it doesn't seem to be an issue in either setting.

So
1. Download/Build the latest version at GitHub
OR
2. In the cfg file (located at /home/pi/.confg (Hidden Folder) mupen64plus/mupen64plus.cfg)
Change ScreenUpdateSetting to 1 or 4, see if that solves the issue

[moocow1452]

Does the unlocking of the GPU code make any difference in Emulation? The way I understand it, the CPU does the bulk of the work, but the GPU is not entirely useless either...

[welshy]

Does the unlocking of the GPU code make any difference in Emulation?

It can make a big difference! An obvious example is MAME, if we take puddings PiMAME4ALL (which is OpenGLES rendered, thus utilising the GPU) it is 250-300% faster than AdvanceMAME (which is SDL rendered, where the GPU cannot be accessed). The easiest analogy is to think of the GPU as a 'Co-Processor' taking the burden of graphics rendering from the CPU. One thing is clear, ric_rpi's N64 emulator would not be possible (at a playable frame rate) if it was SDL rendered!

[ric_rpi]

moocow1452

There are videos of Super Mario using SDL for audio and video on youtube (pre August 2013). They look like they are running at around 5-10 fps wheras with GLES mupen64plus normally runs at 30-60 fps with a few other optimizations as well.

[danny_bhoy67]

Hi guys,

First off, let me just share my admiration for the work going on with this project. Your commitment to this is commendable.

I'm relatively new to emulation on the RPi and have only recently gotten RetroPie running on an Ultimate Raspian build using Emulationstation as a front end. It was only after getting this all set up that I realised the N64 wasn't included in this set up. After finding this out I began my research and found this thread and another with ric_rpi and welshy documenting the journey of trying to generate an N64 emulator that was functional for the Pi.

With that said, I have decided that I'd like to get involved with this alpha version and see how well it works. I know I am late to the party, and please don't think I am being cheeky, but I was hoping I could ask for some pointers.

As I am new to game emulation on the Pi and have only started understanding how the cfg files work, a lot of what is in this thread is above my knowledge level by some way. I have decent linux understanding and am fairly comfortable working in terminal - I am also pretty good at following step by step instructions!

So basically what I want to know is:

Can I take any of the information in this thread to allow me to include this N64 emulator in my RetroPie/ES setup and if so, where do I start?

If that is not possible, would following the instructions in the OP accurately, allow me to run Mario 64 and Mario Kart 64 to a reasonably playable level? My understanding is that if I follow the method in the OP, to run the N64 emulator, I'd have to exit out of ES into terminal and run the executable and rom using the command given? Is this correct?

I guess my final question for now is that I use my PS3 controllers to control games in RetroPie/ES and I configured this by writing the config into the RetroArch config file. I'm assuming there would have to be some separate set up for controlling the N64 games, regardless of what method I use to get it up and running, and was wondering if anyone could point me in the direction of how I'd get the controllers configured also?

I know I'm being a bit of a NOOB with all the questions, but hopefully a few helpful pointers and I'll be on my way to emulating Mario64 and Mario Kart 64 on my Pi.

Thanks in advance for any help and keep up the fantastic work. I will definitely be continuing to follow the progress of this project.

[ric_rpi]

danny_bhoy67

welcome to the forum,

No one is too late to the party with regards to helping get N64 emulation working well on the pi.
If you wish to get stuck in with coding then it would be very appreciated and I can get you started/familiar with whatever part you wish to work on.

I am afraid I have not used RetroPie nor EmulationStation so can't comment on them but if you want to ask any questions with regards to mupen64plus then please fire away, we can all learn something from raspberry pi ...

With regards to controller setup, there is a file in mupen64plus/test called AutoInputConfig.ini where you can configure controllers. The values are copied into the mupen64plus.cfg file but there is an issue with Input configurations being overwritten when mupen64plus runs.

Mario64 runs pretty well on the pi but some games can only mange around 50% speed (Perfect Dark, Golden eye, games with generated cut scenes like the Introduction in Zelda OOT). However there are still things to be tried which may bring about substantial speed improvements ...

[danny_bhoy67]

Hi ric, thanks for the reply!

I think the best place for me to start would be just by following the OP and at least getting a couple of games running in some capacity on my Pi. I guess I will ditch the idea of RetroPie integration for now and see how I go just running straight from terminal.

I'm off on holiday tomorrow for a week, so probably won't get a chance to get properly set up and stuck in before then. No doubt you'll hear back from me in a week or so with a number of questions!

Thanks for the heads up[ on the location of the controller config. Does what you are saying mean that every time I want to re-run mupen64plus, I will have to rewrite the controller configs? That's a bit of an inconvenience...I don't suppose there is a way to get around this or minimise the impact of it? I guess I could just save a copy of the config file in another location and copy it across each time I want to run the emulator?

[ric_rpi]

The controller configuration in mupen64plus.cfg is taken from AutoInputConfig.ini so if you set the values there you won't have to change the mupen64plus.cfg file every time.

[danny_bhoy67]

Well I'm back from holiday and decided to give mupen64 a go. Thanks for the advice so far, ric!

So I managed to install the emulator via RetroPie by updating the RetroPie setup script and updating the binaries, so I can only assume I have the most up to date version of Mupen, or at least reasonably up to date. I then managed to configure EmulationStation to allow me to launch Mupen straight from there and so that it was consistent with the setup of my other emulators.

I then created a folder for roms and put a Mario64 and MarioKart64 rom in there and it all seems to be picked up fine by ES, it picks up the emulator and the related roms and allows me to launch the roms straight from ES - so far, pretty damn excellent It even seems to have picked up my RetroPie controller config so that I didn't have to reconfigure my PS3 controllers and they seemed to work pretty much perfectly except for the button I have configured to quit out of the emulator and back into ES didn't seem to be working - so my only option was to power down and back up again or plug in a keyboard and quit out that way. Needs more investigation I guess.

So now we come to the dreaded performance issues and questions...

I have a 512mb model b Pi. I'm running the OS from a good quality class 10 SD card. I have the overclock set to high (950mhz) and am running a ram split of 128mb. This all seems to be fairly efficient and stable for all of my other needs and I had hoped that it would suffice for mupen also.

The reason I chose Mario and Mario Kart was a) Those are the only 2 games that I REALLY want to be able to emulate on my Pi as far as the N64 goes (I guess Goldeneye would be nice but I'm not holding my breath) and b) They were both on the list of games in the OP that apparently run the best.

I was a little disappointed to not see greater performance out of these two games, with one of them being fairly playable (Mario64, decent graphic performance but terrible choppy sound) and the other being pretty unplayable (Mario Kart 64, stuttery graphics and sound. Game would load and I could just about force it into a race by constantly hammering the correct button, but it was no where near being playable).

My question then is this: I had a look in the mupen.cfg file and tried to compare it with some of the stuff in the OP. There are a lot more config options in there than I had anticipated and it is a bit overwhelming!!! In the end i left all the config settings as default and got the results as described above. Can anyone offer some advice as to where I may be going wrong or what I could do to help me experience the stable performance related to these games as described in the OP.

My only initial thoughts were that launching the emulator out of ES might degrade performance, but I wouldn't have thought it would do so to this degree and Es is supposedly fairly resource light. I suppose the other option would be to try launching straight from the console...is there any validity in this?

Thanks for the continued advice and keep up the great work. It felt awesome to see Mario 64 spring to life from the depths of my humble little Pi