RetroArch iOS release (v1.0.0.1)

[system]

RetroArch iOS

This is a port of RetroArch to iOS-based devices.

Cores currently supported:

• PCSX ReARMed
• Genesis Plus GX
• Picodrive
• SNES9x Next
• VBA Next
• NEStopia
• FCEUmm
• Mednafen PCE Fast
• Mednafen NGP
• Mednafen VB
• Mednafen Wonderswan
• Prboom
• Tyrquake
• NX Engine (Cave Story)
• FInal Burn Alpha
• Gambatte
• MAME 2003 [0.78]
• Mupen64 Plus NEW !

Pre-announcement (initial version - 0.9.9):

OK guys, I am already pre-emptively announcing this for when the next big release hits -

It will be released on Cydia for free with absolutely no strings attached -same as with the Android port.

Most of the cores were easy to port over but one in particular took a pretty intensive rewrite - done by notaz - and that is PCSX ReARMed. he has spent nearly two days rewriting all the ASM so that it could be compiled with Apple’s ancient version of GAS - something that apparently no ‘emu porter for money’ was able to do before - and he deserves a lot of credit for the dedication he’s shown to give us something usable on RetroArch iOS.

As far as I know - this will be the first time PCSX ReARMed will be coming over to iOS (previously there was only PSx4All by Zodtd) and since there’s no ePSXe or FPSe there as well (the Apple Store not accepting emulators - payware or free - obviously makes this not worth their time since they only care about money) - it will be nice to offer something that is leagues ahead of the rest - and for free.

Here is a long screenshot gallery - I’ve played through quite a couple of games today with the PCSX ReARMed iOS port to make sure most of the games work.

[Album] PCSX ReARMed - RetroArch iOS

Stay tuned for when the real release hits. As ever - we (err - me) made a slightly premature release date - but rest assured that things are moving fast so it won’t take much longer until I can properly bump up versions to 0.9.9.

Also - meancoot deserves mad props for putting a large substantial amount of work into this port - in fact, nearly 80% so far. Him making that initial iOS port is what drove me to buy myself an iPad as well - in time before Apple closed the jailbreak window of opportunity - so thanks for that, and credit will be paid where it is due.

I can guarantee so far that all of the cores (except for VBA Next) run at fullspeed on my iPad 2. So this is looking to be a slamdunk port - it is exactly what I wanted RetroArch Android to be in the first place.

Versions

Version 0.9.9.5 - August 15, 2013

• [SNES9x] Fixes by Alcaro to libretro port
• [SNES9x Next] Fixes savestates from not being able to be loaded.
• [Mednafen NGP] Fixes input issues in a number of games, such as:
  • Card Fighters games
  • Etc.
• [Picodrive] Updates/32X compatibility/accuracy improvements
• [NEStopia] Updated to 1.46 WIP - added ability to load NstDatabase.xml, fixes Vs. System games and Startropics 1/2
• [iOS] Only player 1 gets default keyboard bindings
• [iOS] Fixes PS3 gamepad bindings in RGUI
• [iOS] Fixes iCade button mappings
• [iOS] UI additions - Refresh / New Folder / Move options.
• [iOS] Some lifecycle management fixes - should deal better now with phone calls received and then returning back to RA, etc.

Version 0.9.9.3 - June 28, 2013

• [iOS] Fixed input issues -
  • Rewrite of BTStack code
  • Multiple gamepad support
  • More reliable syncing/pairing
  • Cleanup of L2CAP commands
  • Stop Wiimote inquiry loops while game is running, fixes horrible lag
• [iOS] Add a ‘TV Mode’ option which forgoes the Cocoa file browser for RGUI. NOTE: You might have trouble launching PS1 games from this mode if they are the first ROM/ISO you load.
• [iOS] Shaders should work now. Note - for best results - set Scale to 1x per shader pass. Quite a few shaders are fullspeed from iPad 2 and up - your mileage may vary depending on the device.
• [GENERAL] Should fix GPU screenshots if last frame was duped
• [PCSX ReARMed] Add core option to switch between Dual Shock and regular gamepad modes
• [TyrQuake] Add core option so that you can change the internal screen resolution (note that TyrQuake uses the software renderer - it is slow - an OpenGL ES option will be added in the future for mobile devices and others)
• [TyrQuake] For RetroArch ports that support RETRO_KEYBOARD and RETRO_MOUSE - mouse/keyboard controls should work now
• [Genesis Plus GX] Updated to the latest version - 1.7.4 -
  • fixed SRAM incompatibilities between BIG ENDIAN & LITTLE ENDIAN platforms for libretro (note: this breaks old .srm files with LITTLE ENDIAN platform ports - which includes iOS, Android, PC)
  • A lot of compatibility/maintenance fixes by ekeeke (main author) - see this for more - https://github.com/libretro/Genesis-Plus-GX/commit/11d275e2f881d5eefac9d9473db3fc3d52f19c75
• [MAME 2003] ‘game might not run correctly. Press any key to continue’ games can be run now - such as Tekken 2
• [MAME 2003] Correct resolutions for Namco System 11 games
• [MAME 2003] Some minor optimizations (very slight though)

First version - 0.9.9

OK, here is the first version.

How to install

1. Go to Cydia, go to ‘Sources’.
2. Click on ‘Edit’.
3. Click on ‘Add’.
4. Add as a source ‘http://themaister.net/cydia’.
5. After it is done with fetching the package listings, click on ‘Search’.
6. Type in ‘RetroArch’.
7. Install.
8. You will now find an icon of ‘RetroArch’ on your start screen.

Notes

• Shaders don’t work yet so don’t bother trying to get them to work right now. This will be looked at.
• Remember that your system directory is a hidden folder -

/var/mobile/Documents/.RetroArch

This folder is where you should store BIOS files for emulators, such as the PSX BIOS Files for PCSX ReARMed and the Sega CD BIOS files for Genesis Plus GX.

• If you want to use PS3 pads and/or Wiimote Classic pads on a jailbroken iOS device, you will first need to install BTStack. Note - you cannot use BTStack on non-jailbroken iOS - it’s only iCade support for you there.

Manual

retroarch-ios-0.9.9.pdf

You should read this before asking any questions about RetroArch iOS.

[system]

I pulled the source from git and compiled it to test on my iPad 3. All the cores I tried compiling and testing except for vba-next worked, and at full speed. However, on snes9x-next, the integer scaling is somewhat inaccurate.

(I compiled genesis-plus-gx, nestopia, snes9x-next and vba-next)

So far, looks quite good. I could even use my bluetooth keyboard, which is a big plus for me

[system]

Oh yeah, the iOS port is great - I don’t know if you have an Android tablet to compare it against but I think the runtime performance is much better on iOS.

VBA Next I’m afraid will be too slow (it is on an iPad 2) - perhaps you would have better luck on an iPad 4 but I’m not too hopeful to be honest. We really need a gpSP libretro port for ARM because VBA requires at least a CPU comparable to the ones inside the PS3/360 - anything lower than that (ie. all Android/iOS devices) will just run below fullspeed.

[system]

VBA can run full speed on an iPad4. I just played through the beginning of Final Fantasy 6, with a build that logs the frame rate, and the lowest recoded fps was 80. A while back I also played a good chunk of Golden Sun with it and had no speed problems there either.

I just wish the keyboard messages sent on the device had the character and modifier key data. Ruined all hope of using it for dosbox.

[system]

VBA can run full speed on an iPad4. I just played through the beginning of Final Fantasy 6, with a build that logs the frame rate, and the lowest recoded fps was 80. A while back I also played a good chunk of Golden Sun with it and had no speed problems there either.

That’s very impressive - that would make it much faster than PS3 and 360 even since PS3 dips to 53fps or so in the FF6 intro with VBA Next.

[system]

Just tested VBA on my iPad 3 using MOTHER 3. It had some audio regressions, particularly during the naming screens and intro cutscene.

While testing, I noticed some bugs: It appears that I can’t load a game again until I kill RetroArch in the task switcher if I stop the emulation with ESC (providing ESC is mapped to quit game). Attempting to play a game will show the game screen for a moment and then send me back to the core selection screen. Also, the integer scaling under the snes9x-next core is slightly incorrect.

[system]

Just tested VBA on my iPad 3 using MOTHER 3. It had some audio regressions, particularly during the naming screens and intro cutscene.

Those are not audio regressions but just your iPad 3 CPU being too slow for VBA (Next). VBA and all its forks uses a CPU interpreter rather than a recompiler so things are (at a bare minimum) at least twice as slow as - say - gpSP - probably more like 4x slower in fact. But then again, recompilers don’t work on non-jailbroken iOS anyway so perhaps it’s good to have an interpreter GBA emulator to begin with so that non-jailbroken users can use it as well (PCSX ReARMed will only work on jailbroken iOS for this reason).

In general, CPU interpreters are more accurate than CPU recompilers - but are a lot, lot slower. gpSP still has some game-breaking bugs with Golden Sun games while VBA does not - and there are other compatibility issues like that still associated with gpSP.

Anyway, according to meancoot it should be comfortably fullspeed with FF6/FF5 on an iPad 4 (80fps or so unthrottled) - which should mean it should be fullspeed on any game since those two are some of the most demanding ones. 80fps on those games should be way better performance than I’m getting on 360/PS3 with the VBA Next libretro core - at least a good 25fps faster or so.

Do let me know about any and all issues you have before release time so that we can fix as many potential issues before we do the release - which should be soon (probably end of next week).

[system]

While testing, I noticed some bugs: It appears that I can’t load a game again until I kill RetroArch in the task switcher if I stop the emulation with ESC (providing ESC is mapped to quit game). Attempting to play a game will show the game screen for a moment and then send me back to the core selection screen. Also, the integer scaling under the snes9x-next core is slightly incorrect.

If you bind the ‘Menu toggle’ action to a key (say - the Wii home button or PS button on a PS3 pad - or some key on your Bluetooth keyboard), you can bring up RGUI, select ‘Load Game’ and choose another ROM from the built-in OSD menu.

Alternatively, you can press at the top center edge of the screen - which will bring up a Cocoa overlay menu. In this menu you can change settings, load or save states and/or quit the game and go back to the Cocoa game selection menu.

[Cent]

I compiled and tested the latest version on my non-JB iPhone 5 and discovered a couple issues.

First, I had an alarm pop up while I was running VBA-Next and it completely froze the emulation. I could pop up the cocoa menu, but none of the buttons would do anything. I had to end the app and restart it.

Also, this may be intentional, but loading a save state replaces the battery save. I had an instance where I loaded a save state that I didn’t intend to, and I lost my save data. I haven’t looked into it, but I bet it’s because VBA-Next saves as SRAM (.srm) instead of a battery save (.sav) like most GBA emulators do. An easy to way to get around accidental save game loss might be to have an autosave state, like every 10 minutes or so.

Last, is not really an issue, more of an enhancement request. But it would be nice to have alphabetical sections in the UITableView while selecting a ROM. I have some very large folders that take a while to scroll through. If you are looking for help, this would probably be an easy thing to implement.

I also just wanted to mention that I’m really impressed overall. Performance is superb on the iPhone 5. And the large list of cores is awesome. It’s really hard to believe you don’t plan on charging for it when, in my opinion, it’s quite a bit better than the other offerings on Cydia. It’s also really neat that you are supporting both a JB version and a non-JB version.

One last question, how interested are you in supporting controllers for iOS? I’m really intrigued by the BladePad that is coming out next month, so support for that would be neat. I’ve contacted the Bladepad devs and they have an SDK you can use. If your not interested, I can look into adding the support myself, though I’m very new to iOS development.

Thanks again for the amazing job so far!

[system]

I compiled and tested the latest version on my non-JB iPhone 5 and discovered a couple issues.

First, I had an alarm pop up while I was running VBA-Next and it completely froze the emulation. I could pop up the cocoa menu, but none of the buttons would do anything. I had to end the app and restart it.

Also, this may be intentional, but loading a save state replaces the battery save. I had an instance where I loaded a save state that I didn’t intend to, and I lost my save data. I haven’t looked into it, but I bet it’s because VBA-Next saves as SRAM (.srm) instead of a battery save (.sav) like most GBA emulators do.

This most often catches people by surprise thinking it’s a bug but it’s actually how it works on nearly every emu where SRAM is part of the internal save state. This means that if you ‘load’ a state, it will also load into memory the exact contents of the SRAM from that state - hence overwriting your pre-existing SRAM file when you exit the ROM.

There could be a couple of ‘solutions’ for this -

1. the ‘thread’ thing you mention where it would auto save state based on some interval. The problem with this is that it requires another thread to run concurrently - adding some overhead - and file I/O is slow so it can create a gameplay ‘hiccup’ when savestating.

Currently the ‘auto state’ feature is only enabled on PC, but it could be introduced on certain mobile platforms after it has been found to be decent from a performance standpoint.

2. Have an ‘SRAM write block’ toggle which could be set ON/OFF ingame - this way, it would not ‘overwrite’ the SRAM file - so you could load states to your heart’s content and not be worried that it overwrites the main SRAM file.

Last, is not really an issue, more of an enhancement request. But it would be nice to have alphabetical sections in the UITableView while selecting a ROM. I have some very large folders that take a while to scroll through. If you are looking for help, this would probably be an easy thing to implement.

Could be looked at after the 0.9.9 release - I really want to finish this thing up and release it already since we keep adding more and more stuff and like every other major release - it’s hard to get at that stage where you just go ‘OK, just press the ‘release button’ and let’s ship this thing already’. Everytime I think releasing the next version will be a cakewalk and then we always want to add something more and more.

One last question, how interested are you in supporting controllers for iOS? I’m really intrigued by the BladePad that is coming out next month, so support for that would be neat. I’ve contacted the Bladepad devs and they have an SDK you can use. If your not interested, I can look into adding the support myself, though I’m very new to iOS development.

I know that it’s slim pickings in terms of gamepad support on non-jailbroken iOS so I understand and see the need for more controller support since BTStack is JB territory and not available on non-JB. I’m open to having as much support for gamepads as possible in RetroArch iOS but one thing I’m very wary of is dependencies.

I have this ‘unwritten rule’ where a platform port of RetroArch should have as close to zero dependencies as possible for it to be able to be built by a user who just ‘git clones’ the repository. If those gamepad SDKs require an app to statically link certain libraries or whatever then I’m definitely not in favor of that - however, if they are dynamic libraries or if it creates no additional dependencies for building the app then I’m all for it.

Which leaves the ‘supply’ issue - we don’t have all these pads and this is a hobbyist project with no monetary aims at all - so either contributors who have such peripherals to add those things will be needed or ‘hardware gifts’ (ie. some guy or manufacturer sends us the pad, we add support for it). It makes a lot of logic for these peripheral guys to do that at this point since RetroArch will definitely not stay confined to merely emulators and there are some big developments up ahead that will change how people look at RetroArch altogether.

[system]

First, I had an alarm pop up while I was running VBA-Next and it completely froze the emulation. I could pop up the cocoa menu, but none of the buttons would do anything. I had to end the app and restart it.

Perhaps meancoot can chime in here - don’t really know what this could be about.

[Cent]

[quote=Cent]I compiled and tested the latest version on my non-JB iPhone 5 and discovered a couple issues.

First, I had an alarm pop up while I was running VBA-Next and it completely froze the emulation. I could pop up the cocoa menu, but none of the buttons would do anything. I had to end the app and restart it.

Also, this may be intentional, but loading a save state replaces the battery save. I had an instance where I loaded a save state that I didn’t intend to, and I lost my save data. I haven’t looked into it, but I bet it’s because VBA-Next saves as SRAM (.srm) instead of a battery save (.sav) like most GBA emulators do.

This most often catches people by surprise thinking it’s a bug but it’s actually how it works on nearly every emu where SRAM is part of the internal save state. This means that if you ‘load’ a state, it will also load into memory the exact contents of the SRAM from that state - hence overwriting your pre-existing SRAM file when you exit the ROM.

There could be a couple of ‘solutions’ for this -

1. the ‘thread’ thing you mention where it would auto save state based on some interval. The problem with this is that it requires another thread to run concurrently - adding some overhead - and file I/O is slow so it can create a gameplay ‘hiccup’ when savestating.

Currently the ‘auto state’ feature is only enabled on PC, but it could be introduced on certain mobile platforms after it has been found to be decent from a performance standpoint.

2. Have an ‘SRAM write block’ toggle which could be set ON/OFF ingame - this way, it would not ‘overwrite’ the SRAM file - so you could load states to your heart’s content and not be worried that it overwrites the main SRAM file.

Last, is not really an issue, more of an enhancement request. But it would be nice to have alphabetical sections in the UITableView while selecting a ROM. I have some very large folders that take a while to scroll through. If you are looking for help, this would probably be an easy thing to implement.

Could be looked at after the 0.9.9 release - I really want to finish this thing up and release it already since we keep adding more and more stuff and like every other major release - it’s hard to get at that stage where you just go ‘OK, just press the ‘release button’ and let’s ship this thing already’. Everytime I think releasing the next version will be a cakewalk and then we always want to add something more and more.

One last question, how interested are you in supporting controllers for iOS? I’m really intrigued by the BladePad that is coming out next month, so support for that would be neat. I’ve contacted the Bladepad devs and they have an SDK you can use. If your not interested, I can look into adding the support myself, though I’m very new to iOS development.

I know that it’s slim pickings in terms of gamepad support on non-jailbroken iOS so I understand and see the need for more controller support since BTStack is JB territory and not available on non-JB. I’m open to having as much support for gamepads as possible in RetroArch iOS but one thing I’m very wary of is dependencies.

I have this ‘unwritten rule’ where a platform port of RetroArch should have as close to zero dependencies as possible for it to be able to be built by a user who just ‘git clones’ the repository. If those gamepad SDKs require an app to statically link certain libraries or whatever then I’m definitely not in favor of that - however, if they are dynamic libraries or if it creates no additional dependencies for building the app then I’m all for it.

Which leaves the ‘supply’ issue - we don’t have all these pads and this is a hobbyist project with no monetary aims at all - so either contributors who have such peripherals to add those things will be needed or ‘hardware gifts’ (ie. some guy or manufacturer sends us the pad, we add support for it). It makes a lot of logic for these peripheral guys to do that at this point since RetroArch will definitely not stay confined to merely emulators and there are some big developments up ahead that will change how people look at RetroArch altogether.[/quote:2e8rf6bf]

Interesting about the SRAM issue. I really like the SRAM block toggle idea and sounds much easier than any alternative. Don’t worry about any enhancements that aren’t necessary - go ahead and release when you are ready. I’m just giving you ideas and perhaps you’ll want to look into it for a future release.

I completely agree about dependencies - I can try to gather more information about it. I’ll see if they’d be willing to donate a controller to the cause, but otherwise I’m not against donating a controller to get support for it.

Anyway, thanks for the detailed reply. Best wishes.

[system]

I pushed a fix for the issue with using the keyboard to quit the game not letting another start.

The issue where the Cocoa menu would work but not do anything means the emulator thread had stopped responding to events. I’ll try to reproduce it and find out what’s going wrong.

[system]

Found another issue: when I hit the “Settings” button in the ROM selection menu, it takes me to the settings menu, but the button stays there, and can be tapped again to create another settings menu.

Also, it appears that the issue I had with snes9x-next also occurs on my desktop, but it can be corrected by going into RGUI, setting the aspect ratio to “8:7 (1:1 PAR)” and Integer Scale to off. I couldn’t get this to work on iOS, however. No matter what configuration I tried I couldn’t get the scale perfect. However, I can get perfect scaling if I turn integer scaling off, set the aspect ratio to core provided, set the bottom-right corner custom ratio to 1536x1344, then turning it back on (to center the image).

[system]

Okay,

So I had to register and get on the forums. CRAZY interested in being able to play my old PS1 games on iOS.

Couple questions:

Any ETA on when the iOS update is going to be coming out? And, is there any way to donate to the devs? If the PSX emulator works, I’ll be more than happy to donate. I was thinking about picking up an Android device JUST so I could emulate on a mobile device. This would be, by far, the cheaper option.

Thanks

[hunterk]

@diadem there’s no firm release date but it’s very soon. A matter of weeks, rather than months.

As for donations:

Q 6b: What if I offer to pay you? A: RetroArch is totally free and always will be. Bringing money into the mix causes nothing but trouble and resentment, and there’s no way we could track down and give appropriate compensation to all of the authors involved in the various emulation cores. Keep your money and be happy that so many individuals have worked so hard to bring you something great. Q 7: I love RetroArch! Where’s the ‘donate’ button? A: See Q 6b. The only exception to this rule is donation of hardware for support on other platforms (see Q 8). There is also a ‘donate’ button on the forum to help pay for hosting costs but these costs are relatively minor, so don’t feel obligated.

[system]

Oh, and will saves be transferable between, say, iOS and PC?

[hunterk]

srm saves will be, for sure. Savestates may or may not, depending on the individual core, endianness, weather forecast, etc. Some people have reported good luck with savestates from Android vs PC.

[system]

Cool!

And thanks for the quick replies

[system]

All ARM libretro cores (and RetroArch itself) are compiled with LSB_FIRST implicitly defined - so little-endian.

PC (or, well, x86 arch) is little-endian as well.

So swapping savestates and save files should be no problem between iOS and PC. Same is true for Blackberry / Android and PC.