Release RetroArch (NES, SNES, Genesis, GBC, GBA, and more)

[lifning]

I'm sure some of you may be familiar with RetroArch and libretro, being that the Pandora community has many emulation enthusiasts. For those who aren't, it replaces the older "ssnes" and "libsnes," respectively. libsnes was originally the emulation core of bsnes as a shared library with a specific API that allowed for other frontends to be developed (bsnes' author, byuu, did this to allow features to be implemented that he didn't want in his own emulator). Eventually SNES9x was modified to expose the same "libsnes API" so it could be dropped into those same frontends. After a short while, some non-SNES emulators also got ported to the increasingly poorly named "libsnes," resulting in the API being renamed and revised to support other systems as well. If you're looking to write an emulator (or even a game), consider targeting libretro, as it could save you the trouble of worrying about cross-platform video/audio/input.


Anyway, I was fiddling with Yactfeau and built the RetroArch frontend for Pandora, as well as a handful of libretro backends. With some good old-fashioned Pandora-style "zenity UI," it's a reasonably functional multi-system emulator.


edit: Uploaded to repo! http://repo.openpandora.org/?page=detail&app=retroarch.lifning.001

 

[EvilDragon]

SNES9x libretro builds and runs but produces a black screen and silence.

Yes, that's an issue of more recent SNES9x-versions and ARM-builds.


They all have that same issue. That's why SNES9x for all ARM-devices is based on an earlier version.


Someone really should find out what's the issue here.


EDIT: Ubuntu has snes9x-gtk 1.52 built for armel: https://launchpad.net/ubuntu/oneiric/armel/snes9x-gtk/1:1.52-1


I need to test whether this is just a non-working compiled version or whether they really fixed that issue, as it still seems to exist:


http://www.snes9x.com/phpbb3/viewtopic.php?f=6&t=5264

 

[sebt3]

I'll be attempting to build the other libretro backends (NXEngine, etc.) for this as well.

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

 

[BAFelton]

The emulators don't appear for me in the emulators menu. Are they somewhere else ?


I'm on SZ final.

 

[crow_riot]

SNES9x libretro builds and runs but produces a black screen and silence.

Yes, that's an issue of more recent SNES9x-versions and ARM-builds.


They all have that same issue. That's why SNES9x for all ARM-devices is based on an earlier version.


Someone really should find out what's the issue here.

just guessing ... dave18 had some similar problem with his FBA build ... and a adding the "-fsigned-char" flag to the compiler options fixed it...

 

[lifning]

Yes, that's an issue of more recent SNES9x-versions and ARM-builds.


They all have that same issue. That's why SNES9x for all ARM-devices is based on an earlier version.


Someone really should find out what's the issue here.


EDIT: Ubuntu has snes9x-gtk 1.52 built for armel: https://launchpad.net/ubuntu/oneiric/armel/snes9x-gtk/1:1.52-1


I need to test whether this is just a non-working compiled version or whether they really fixed that issue, as it still seems to exist:


http://www.snes9x.com/phpbb3/viewtopic.php?f=6&t=5264

Ah, that makes sense. I think all the SNES emulators on Android are 1.43 or earlier, come to think of it. Maybe a libretro could be made out of that version.

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

I'm well aware of this port; it's how I first played through Cave Story I know the Pandora has a lot of these as stand-alone emulators and games, but I'm still interested in getting them working as libretro cores so future performance/UI improvements to the frontend(s) can apply to them across the board.

The emulators don't appear for me in the emulators menu. Are they somewhere else ?


I'm on SZ final.

Shows up in the "Emulators" menu for me in both XFCE and MiniMenu. Look for "RetroArch." Does it work if you "pnd_run retroarch.pnd" from Terminal?

just guessing ... dave18 had some similar problem with his FBA build ... and a adding the "-fsigned-char" flag to the compiler options fixed it...

I tried building it with that cflag, but the resulting library refused to load. Thanks anyway!

 

[Toad King]

SNES9x libretro builds and runs but produces a black screen and silence.

Yes, that's an issue of more recent SNES9x-versions and ARM-builds.


They all have that same issue. That's why SNES9x for all ARM-devices is based on an earlier version.


Someone really should find out what's the issue here.


EDIT: Ubuntu has snes9x-gtk 1.52 built for armel: https://launchpad.ne...9x-gtk/1:1.52-1


I need to test whether this is just a non-working compiled version or whether they really fixed that issue, as it still seems to exist:


http://www.snes9x.co....php?f=6&t=5264

I've ported Snes9x to the Raspberry Pi (ARMv6) and the issue is almost certainly an endianness one. Check out port.h, specifically for the LSB_FIRST or MSB_FIRST macros. Odds are the detection for little-endian is not working in the Pandora SDK environment so it defaults to big-endian, which is making the games not run.

 

[Autechre]

Hi there lifning,


i've been considering an SNES9x 1.43 libretro port actually as well. While the 1.52 fork (with alterations) that I call SNES9x Next runs all games fullspeed on PS3/360 (with some necessary speedhacks to accomplish this), SA-1/SuperFX games dip below fullspeed on the Wii. Xbox 1 (which has a preliminary Retro Arch port as well now done by me) will likely struggle with SNES9x 1.52 as well going off reports I heard from the current maintainer of SNES9xbox - so a 1.43 port is definitely needed in the long run for low-performance systems like this.


ToadKing has a pocketsnes port for libretro that might work on Pandora as well at more favorable speeds than SNES9x Next. It's chockful of non-portable ARM ASM so it's not very portable (the very antithesis of most libretro ports) but it should work out in this case.


BTW - do let me know what kind of performance you're getting with all these ports on Pandora - I'd be highly interested to hear.

 

[lifning]

Thanks for the tip ToadKing, I've built SNES9x{,-next} with " || defined(PANDORA)" tacked on to the conditional for setting LSB_FIRST and FAST_LSB_WORD_ACCESS, and it works (slowly, as expected).


Also, I was previously unaware of your PocketSNES port! I built that too, and it performs pretty well, albeit with the usual PocketSNES bugs. Thanks to Squarepusher for pointing it out too On a related note, I wonder how plausible/worthwhile a PicoDrive port would be for systems like Pandora and RPi.


As for the other libs' performance, FCEUmm and Gambatte both run smoothly. Meteor and VBA are "playable," but run about 20-50% speed depending on the game, with stuttering sound (haven't tried disabling audio_sync yet, though). Genesis Plus runs Sonic 1 full speed with a 900MHz overclock (above the usual 600MHz), and Sonic 2 runs about half speed.


I've updated the first post with a build containing the SNES libraries.

 

[sebt3]

I wonder how plausible/worthwhile a PicoDrive port would be for systems like Pandora and RPi.

http://repo.openpandora.org/?page=detail&app=package.picodrive.notaz


and for RPi, if notaz had one ... the port would be probably done

 

[lifning]

Blasted ambiguous language, I've done it again! Revised: "I wonder how plausible/worthwhile a PicoDrive libretro port would be for RetroArch on systems like Pandora and RPi." Though distributing it in the same PND might be a dead end if it's not GPL-compat? Just a thought, anyway.


I've cleaned up my sources for potential inclusion in upstream. This resulted in a slightly nicer PND, but functionally no different from the one I've already uploaded.

 

[notaz]

ToadKing has a pocketsnes port for libretro that might work on Pandora as well at more favorable speeds than SNES9x Next. It's chockful of non-portable ARM ASM so it's not very portable (the very antithesis of most libretro ports) but it should work out in this case.

So you are against platform optimized ports?


Then I guess a potential libretro version of PCSX possibly fast enough to be usable on RPi is of no interest to you? I'm sort of interested to see how well it would run there.

 

[Autechre]

ToadKing has a pocketsnes port for libretro that might work on Pandora as well at more favorable speeds than SNES9x Next. It's chockful of non-portable ARM ASM so it's not very portable (the very antithesis of most libretro ports) but it should work out in this case.

So you are against platform optimized ports?


Then I guess a potential libretro version of PCSX possibly fast enough to be usable on RPi is of no interest to you? I'm sort of interested to see how well it would run there.

No, I didn't mean it like that at all. In fact, I checked out your ARM versions of Picodrive, PCSX-ReARMed and co - it's impressive work and I would love to see them as libretro ports. I just hope that (in general) we can keep libretro ports somewhat portable/compilable on all libretro targets by having C/C++ fallback code in case we are not compiling for (say) an ARM-based machine. (iMAME4All can be compiled for non-ARM based platforms for instance). It's sorta nice being able to run the same codebase (say, Genesis Plus GX-libretro or Final Burn Alpha-libretro) on anything ranging from a Raspberry Pi to a PS3/360 (and Linux, OSX and Windows on PC).


But having said that, I'm not saying that I don't want to see ports where lots of platform-specific ASM is used - not at all. There are no real restrictions or 'rules' imposed on anybody using the API. An idea I have in my mind though is that it could/should be possible to have a libretro port of (say) PCSX where all platform-specific code is put in its own subdir and/or (depending on libretro target) certain optimizations are enabled / code compiled in through ifdefs - for instance, __ARM_NEON__ would include the PCSX-ReARMed NEON GPU plugin, __WII__ would include a dynarec for Wii, and so on. Such a thing would likely have to be a group effort though since not everybody is likely to own all platforms that libretro targets.

 

[notaz]

ok fair enough, I'm also trying to have C versions of any asm I work on nowadays. I'll see if I can cook a libretro version of PCSX, I'd like to see it run on more ARM platforms. It already does have fallback C code for all asm and the recompiler (switches to interpreter on anything but ARM).

 

[lifning]

Updated with iMAME4all and Final Burn Alpha cores, as well as some config tweaks to make the upscaling look nicer for most systems. I don't have any ROMs for FBA, so if someone could test that, that'd be swell.


Pacman was able to run in iMAME4all at full speed, so that's a good sign, though I don't know that hard-coding a resolution for arcade emulators at the environment variable level will work out as it has for the other systems. I'm experimenting with hacking some new keywords for SDL_OMAP_LAYER_SIZE into notaz's SDL that automatically do proportional scaling and whole-number scaling. Seems to be working so far. Posted the patch here if anyone's interested.


Another solution would be a new driver, and I've done a bit of work toward that end, adapting the Dispman/EGL/OpenVG driver for RPi to X11+SDL/EGL/OpenVG, but I am admittedly untalented at all things GL-related, so it just crashes at the moment.

 

[ekianjo]

WIll it be possible to have a NeoGeo emulator as well in the lot?


GnGeo works very well, but does not support TV-out... if Retroarch could replace it, i'd go for it.

 

[lifning]

Apparently Finalburn Alpha supports NeoGeo, so you might wanna give that a shot. libretro-fba.so in the backend menu.


Made RetroArch use my modified libSDL. Also did some usability hacks in the launcher script; it should now remember your last-selected ROM on a per-backend basis. Updated the PND in first post accordingly.


Also, open question: What would make good default L2/R2/L3/R3 bindings on the Pandora? I was thinking something along the lines of 1/Backspace/E/I.

 

[ekianjo]

Apparently Finalburn Alpha supports NeoGeo, so you might wanna give that a shot. libretro-fba.so in the backend menu.

In my experience FBA is not as good as GnGeo and is not as fast / as compatible... I'll need to try again and compare.

 

[Autechre]

Apparently Finalburn Alpha supports NeoGeo, so you might wanna give that a shot. libretro-fba.so in the backend menu.

In my experience FBA is not as good as GnGeo and is not as fast / as compatible... I'll need to try again and compare.

ToadKing tried FBA on the Raspberry Pi through RetroArch and apparently the performance was really bad for CPS1/CPS2/Neogeo games. So you might well need GnGeo for acceptable Neo-Geo performance on something like a Pandora or Pi (I admittedly have no idea how the OMAP3530 in the Pandora compares to the Pi's ARM11 - so for all I know it might perform a lot better). AFAIK ToadKing reported that Metal Slug 2 ran pretty well on the Pi with the iMAME4All libretro port.Compatibility-wise though, FBA should have nothing to fear from Gngeo - in fact, I'd suggest it's very much the opposite.


Also, about the 'FBA compatible ROMs' - the ROMset for FBA should be in sync with MAME's right now.

 

[Toad King]

I actually tried to do a libretro port of GnGeo, but I found that it depends way too much on SDL, and would take forever to extract all that and get a working version.