If it runs Quake..why not SNES?

Hello everybody,

I am a software developer, quite new to RaspberryPi, and I am using it for my hobby projects, hacking, tweaking and fun of course!

My (slightly flaming) subject is about the bad performance I have experienced with the wheezy raspbian and PocketSNES (with Retroarch). Most games are badly lagging, smooth playback is a dream.

Can somebody please explain me why? I am interested in the technical reasons, because I'd like to fix this problem either by leveraging other people's experience or by going on a deep dive myself.

I have tried overclocking the rPI, but after experiencing bad troubles with filesystem corruption I stopped.

I suspect the reasons for bad performance are strongly coupled with the CPU clock and the intensive SNES assembly emulation that goes on..but I am still confident it should be possible to correctly emulate it even without overclocking.

Thanks!

eix
From what I have discovered the problem seems to be most “modern” emulators rely on heavy assistance from the Grafx cards (Most new revisions aim for “Accuracy” rather than optimisation for “Performance”). However, as the RPi GPU drivers are “Beta” the assistance is generally NOT being applied (be it Opengl or SDL)! A good example of this is in SNES9X-SDL, I have found v1.39 works “Almost” FULL SPEED (Even at 700MHz!), however, v1.53 DOES NOT! (It’s due to the SPC700 (sound processor) cores). Also, v1.39 DOES NOT use ALSA drivers for sound, only OSS requiring separate use. Another issue is “Fullscreen” mode, which requires config adjustements. v1.53 has NONE of these problems but framerate/rendering is the issue! (I have added Links to the SNES-9X threads below). As I have posted in numerous threads, USUALLY its these “Custom” Processors that are the BANE of emulation, (Obviously writers of the code have little or NO documentation for their work and have to “Reverse Engineer” their operation, a good case in point being the Atari VCS and TIA emulation (Added to the fact it isn’t really a processor, just LSI logic circuits), it took quite a few years before emulators for the System started appearing!). In recent years this HASN’T been much of an issue due to the processing ability/power of modern computers (Which negates many of these Issues), but the RPi is a different BEAST altogether! That’s one of the reasons I have AVOIDED Retroarch, as it was initially written a method of achieving emulation on the Xbox360, PS3 and Wii (Comparing the performance of MAME on Retroarch to compiled AdvMAME source code shows this clearly!). The BEST results I have achieved are with compiling “Stand Alone” Linux emulator code, or modifying source for the GP2X, Cannoo etc which are a more coupled/related to the performance/hardware of the RPi!

Palerider’s “Guide”(v1.39) - viewtopic.php?f=78&t=23272

My “Guide” (v1.53) - viewtopic.php?f=78&t=24318

Thanks a lot for your detailed reply, welshy! very much appreciated

I was already thinking to get rid of the man-in-the-middle (retroarch) and try with some codebase that is more lean-and-mean; my first thought was to check ZSNES codebase (or eventually its forks).

Looking at GP2X that really makes sense, thanks for the pointers! I will check later the links you gave me and reply back.

By the way, I get what you mean regarding the custom processors: each of the SNES cartridge contains custom logic (of variable complexity) and I guess the Nintendo licensing process would just check that it does not create interference and/or damage to the SNES itself. An (in)glorious case is the FX processor

I have been digging in those topics and read about Snes9x ports (gregwar's 1.39 and yours' 1.53), and about the native bsnes package (which apparently does not work, I tried it as well some time ago but had also forgot by then).

Fact is that BSNES is technically a re-implementation of ZSNES, with focus on accuracy, so not sure if it should be the way to go for RPI.

I have found an interesting (old) discussion about porting the GP2X SNES emulator to Nokia N800, and they do mention optimizations for ARM:

http://talk.maemo.org/archive/index.php/t-6954.html

Honestly I feel a bit unpleasant that there are so many competitive projects and even not at all documented/well published online.

The risk is to reinvent wheels all the time and loose important fixes/improvements after the fork.

I will post again when I dig more

[jamesh]

One thing wrong in the above posts =- the Raspi GPU drivers are NOT beta. They are fully Khronos compliant, fully tested and fully released. The ones I'm talking about are OpenGLES2.0, OpenVG and OpenMAX, along with libEGL. If [insert you emulalator here] uses those libraries then you should be able to get decent performance. However, if you rely solely on the CPU, then it has the emulate the games system entirely in software (so, it's instruction set, its API's, its graphics, its audio etc) and without using GPU acceleration for the graphics it will be slow.

jamesh
Ok, point taken (I should perhaps have been MORE specific!). But THAT’S the problem with the RPi at the moment (Especially with regards to Homebrew Software), from what I have seen MOST Linux software (Homebrew) use’s OpenGL and SDL Drivers! (Not the ones listed). Please don’t think I’m having a “PoP” here, just explaining the problem with reference to eix’s post!

One thing wrong in the above posts =- the Raspi GPU drivers are NOT beta. They are fully Khronos compliant, fully tested and fully released. The ones I'm talking about are OpenGLES2.0, OpenVG and OpenMAX, along with libEGL. If [insert you emulalator here] uses those libraries then you should be able to get decent performance. However, if you rely solely on the CPU, then it has the emulate the games system entirely in software (so, it's instruction set, its API's, its graphics, its audio etc) and without using GPU acceleration for the graphics it will be slow.

To be really honest, I would like to contribute in making this work second best practices (I do not have a lot of free time but I am really looking forward to work on something I am so motivate and passionate about, like SNES emulation), but before adding/changing the 1st line of code I'd like to have a good picture about the current emulator codebases, those which have similar platform as Raspberry Pi, and their genealogy (to eventually lookup ancestors/descendants for fixes and improvements, as per any sanely mantained software project).

I guess we can collaborate to build up this picture, this is a community forum so..please tell me if you have more information

So far I have discovered that in the last 10 years there has been an explosion of forks/variants, I remember the times when there was only Snes9x and ZSNES..I am still digging information

jamesh
Ok, point taken (I should perhaps have been MORE specific!). But THAT’S the problem with the RPi at the moment (Especially with regards to Homebrew Software), from what I have seen MOST Linux software (Homebrew) use’s OpenGL and SDL Drivers! (Not the ones listed). Please don’t think I’m having a “PoP” here, just explaining the problem with reference to eix’s post!

I don't see porting code to Raspi GPU as an impossible task, it is actually quite interesting for me to work on these embedded devices.

I am now wondering: would it be possible to use the GPU also for the DSP emulation tasks? Although technically part of the same family of processors, it might be impossible for technical reasons.

The idea is: if we do not fully use the GPU for rendering the graphics, maybe we can leverage some processing power for the sound emulation

I am posting here some useful links.

I have read the whole maemo thread, those people were trying to run Snes9x on a Nokia N800..more than 4 years ago! and some of them say that they could emulate SNES even on < 200 Mhz processors, I partially agree with their point. Now we have a 700 Mhz processor, guys we can and will get decent SNES emulation!

(1) OpenSnes9x, that is the Snes9x port to GP32, it contains optimizations to make Snes9x run faster. I did not yet analyze it and I doubt it might be useful for merges. It would indeed be interesting to see how the developer(s) applied optimizations on a Snes9x codebase, in case we are going to do the same.
http://yoyofr92.free.fr/os9xgp/files/os ... ta.src.zip

(2) http://little-john.net/ A multi-console emulator for Palm OS, that - guess what - is ARM-based, this might be interesting but did not check it out yet

(3) snes9x-0.40.tbz, notaz' port that should contain ARM optimizations for DSP emulation. Is this what palerider was referring to in viewtopic.php?f=78&t=23272&p=231239 ?

There's also Snes9x EX for Android by Robert Broglia:

http://www.explusalpha.com/home/snes9x-ex

[jamesh]

jamesh
Ok, point taken (I should perhaps have been MORE specific!). But THAT’S the problem with the RPi at the moment (Especially with regards to Homebrew Software), from what I have seen MOST Linux software (Homebrew) use’s OpenGL and SDL Drivers! (Not the ones listed). Please don’t think I’m having a “PoP” here, just explaining the problem with reference to eix’s post!

Someone is working on accelerating SDLusing the GPU - and the conversion from OpenGL to OpenGL ES isn't a huge amount of work, depending on how well the original code was written.

jamesh
Thanks’ for the Heads Up! Unfortunately, due to the nature of Linux/Open architecture, it's sometimes hard to keep up with EVERYTHING going on! Again, apologies if my reply to the post offended anybody! I for one FULLY appreciate the work being done in the background!

If these games/emulators are running using SDL on an X window, they will have an extremely bad performance hit on Raspbian.

X redraw is horribly slow without GPU support on an ARMv6, and to run an SDL app on this is likely to max out the ARM and leave little room for fullspeed emulation. Check the thread on SDL 1.2 with dispmanx backend for a work-in-progress solution which bypasses X for applications which use SDL, including emulators.

If these games/emulators are running using SDL on an X window, they will have an extremely bad performance hit on Raspbian.

X redraw is horribly slow without GPU support on an ARMv6, and to run an SDL app on this is likely to max out the ARM and leave little room for fullspeed emulation. Check the thread on SDL 1.2 with dispmanx backend for a work-in-progress solution which bypasses X for applications which use SDL, including emulators.

++++!!! Great! Let's make this libSDL binding work correctly, then it would be a great performance enhancement (for any SDL application).

All the 4 ports posted here above so far do not use SDL since they are ports to specific hardware platforms, thus we would have to skip SDL at all when using/merging their code.

The fact that we could still keep the SDL portability features would be indeed a great plus.

Thanks for posting this Mequa! I will give it a try

I'm not a big programmer myself, but I want to encourage you in your work and I'm looking forward to many optimization done in the future. I'm sure we only scratch the surface of the Pi's true abilities.

For everybody still interested: I have chosens snes9x as candidate SNES emulator and I am studying the status of the main git repository codebase (https://github.com/snes9xgit/snes9x) compared to snes9x-sdl (https://github.com/domaemon/snes9x-sdl).

Looks like byuu's (BSNES author) APU has been merged into snes9x (that's good). Such APU was originally by Blargg, and according to his home page (http://www.slack.net/~ant/libs/audio.html#snes_spc) there is a pseudo-cycle version implemented.

So my plan is to compile snes9x on the rPI (with distcc) and verify the status of the loose DSP emulation + OpenGL output.

If those are not good enough, then I will start from there looking at the other projects mentioned here.

So my plan is to compile snes9x on the rPI (with distcc) and verify the status of the loose DSP emulation + OpenGL output.

I am currently adding OpenGL ES support to snes9x, in a bare metal version.

Will let you know about progress

I'm following this thread from the beginning and I want to encourage you to continue your work! Much appreciated!

I've always wanted a tiny little board I could "hide" in a real snes and the RPi just looks like the real candidate! Once I figure out how to connect the original snes controllers I'm set. Can't wait to play all the goodies like secret of mana 2

Adding GLES support will not help SNES emulation, SNES emulation is just too intense for the rpi's relatively weak CPU. Frameskipping can help but then you get a stuttering game which a lot of people (myself included) can't stand.

Yes, emulating a 20-year old system is too much for the Rpi. That's what you get with an old ARM11 CPU. That added on top of the fact that the SNES is very complicated and difficult to emulate, plus with almost no work done in ARM optimization for SNES emulators, and the ones with work done are either closed-source forks of SNES9x (which is against its license I'm pretty sure) or open-source but the ARM optimizations break compatibility too much and both still depend on frameskipping to get full speed on Pi-level hardware anyway.

Adding GLES support will not help SNES emulation, SNES emulation is just too intense for the rpi's relatively weak CPU. Frameskipping can help but then you get a stuttering game which a lot of people (myself included) can't stand.

Please let me politely dissent. SNES emulation can be divided in 3 parts (not talking authoritatively here, just by my knowledge):

1. gameplay + graphical frames generation
2. DSP sound emulation
3. cartridge-specific chips emulation

The order is least-to-most difficult to emulate.

In regards to (1), adding GLES will add - in my opinion - a substantial improvement over any other indirect rendering. However (1) is not even the problem here..I am quite sure it's (2) draining the CPU.
I will ignore (3) for now for simplicity. (2) will need some hacks, so I expect the end result to be playable but with sub-optimal audio.

Yes, emulating a 20-year old system is too much for the Rpi. That's what you get with an old ARM11 CPU. That added on top of the fact that the SNES is very complicated and difficult to emulate, plus with almost no work done in ARM optimization for SNES emulators, and the ones with work done are either closed-source forks of SNES9x (which is against its license I'm pretty sure) or open-source but the ARM optimizations break compatibility too much and both still depend on frameskipping to get full speed on Pi-level hardware anyway.

Still, I do not agree with you fully. We are not talking about BSNES-level emulation (that is: best 1-to-1 emulation), that has been proven to need a 3 GhZ processor at least. Here I'm talking about the kind of emulation that I could enjoy with ZSNES on a 500Mhz x86 (yes, I know, ZSNES is highly optimized).

So yes, something will be lost, but I will not give up on this idea.

Which closed-source forks are you referring to? Can you name some, just for curiosity?

I'm following this thread from the beginning and I want to encourage you to continue your work! Much appreciated!

I've always wanted a tiny little board I could "hide" in a real snes and the RPi just looks like the real candidate! Once I figure out how to connect the original snes controllers I'm set. Can't wait to play all the goodies like secret of mana 2

Hey, send some pizza - that would be a better encouragement!

Just joking..that means you might help at testing later

An update on status: I am merging some of snes9x-sdl to snes9x (at least SDLinput) and then use direct OpenGLES for video rendering.

Adding GLES support will not help SNES emulation, SNES emulation is just too intense for the rpi's relatively weak CPU. Frameskipping can help but then you get a stuttering game which a lot of people (myself included) can't stand.

Please let me politely dissent. SNES emulation can be divided in 3 parts (not talking authoritatively here, just by my knowledge):

1. gameplay + graphical frames generation
2. DSP sound emulation
3. cartridge-specific chips emulation

The order is least-to-most difficult to emulate.

In regards to (1), adding GLES will add - in my opinion - a substantial improvement over any other indirect rendering. However (1) is not even the problem here..I am quite sure it's (2) draining the CPU.
I will ignore (3) for now for simplicity. (2) will need some hacks, so I expect the end result to be playable but with sub-optimal audio.

Yes, emulating a 20-year old system is too much for the Rpi. That's what you get with an old ARM11 CPU. That added on top of the fact that the SNES is very complicated and difficult to emulate, plus with almost no work done in ARM optimization for SNES emulators, and the ones with work done are either closed-source forks of SNES9x (which is against its license I'm pretty sure) or open-source but the ARM optimizations break compatibility too much and both still depend on frameskipping to get full speed on Pi-level hardware anyway.

Still, I do not agree with you fully. We are not talking about BSNES-level emulation (that is: best 1-to-1 emulation), that has been proven to need a 3 GhZ processor at least. Here I'm talking about the kind of emulation that I could enjoy with ZSNES on a 500Mhz x86 (yes, I know, ZSNES is highly optimized).

So yes, something will be lost, but I will not give up on this idea.

Which closed-source forks are you referring to? Can you name some, just for curiosity?

The issue is all those steps are done in software, and so far all the emulators I know of only use SDL/OpenGL for drawing the final frame to the screen, a very simple task compared to everything else. and one that GLES acceleration will not improve much.

The issue is there are no emulators as performance-light as ZSNES for ARM. There are some that get close, but the fact of them being partial ports of SNES9x and the fact that clock-for-clock x86 (even old Pentiums) perform better than the ARM11 in the Raspberry Pi mean that it will take a new project to get fullspeed.

Most of the closed source ones I talk about are ports for the GPX2 consoles, where I can't seem to find the sources for, so I assume they just never release them.

...I am currently adding OpenGL ES support to snes9x, in a bare metal version...

That's an exciting prospect and I'm really looking forward to your work on that!

Running the emulator directly on the hardware means less overhead and a much faster (nearly instant) boot time. Coupled with support for something like this GPIO adapter, and you'd end up with (in theory) a modern SNES appliance that could even use actual controllers for an authentic experience.

Using a similar approach (bare metal) a SNES emulator was even possible on a Nintendo DS, which had just 2 67Mhz ARM9 chips. Granted it wasn't perfect but many games worked and ran full-speed.

Embedded/low power systems involve compromise, but with optimization/speed hacks, certainly the RPi, with it's MUCH more powerful hardware, is capable enough to do it.

Here's a video of that emulator (snemulds) in action for anyone that is curious.