*Version 1.1 Released* SNES Emulator Available for Developers (No Jailbreak Required)

[iSkythe]

After the removal of iMAME from the App Store, I started searching for more emulators for iOS. I found SNES--HD- on github, but unfortunately it required a jailbroken iPad to run. Then, I came across a post by Spencer Nielsen with instructions on how to compile it for your own non-jailbroken iPad. (http://www.aorensoftware.com/blog/2011/05/23/play-snes-games-on-your-ipad-without-jailbreaking/)

I've taken his source code with his permission and modified it so it can run on both iPhone and iPad. Here's the link to the project on github:

https://github.com/iSkythe/SNES4iOS

If you're a developer, compile away! If not, I hope you're good friends with one

Changes from previous versions include:

•Sustain Button: a new button (looks like a circle with four arrows pointed towards the center) allows you to essentially sustain, or hold down a button without keeping your finger on the button. You tap the sustain button, it will turn orange, and then you tap the button you wish to sustain. For example, if you wanted to keep your character moving to the right, you’d tap the sustain button, then tap the right button, and then you can lift your finger off and it will keep going to the right. This is especially useful in platformers such as Mario games, as you can sustain the run button without having to hold it down!
•Both the Objective-C app code and the C snes9x emulator code are included in the same .xcworkspace file. It’s strongly recommended you use the workspace file instead of the individual project files.
•Since the snes9x code is now in an Xcode project, it can be compiled natively in Xcode via the included makefile. However, you MUST clean the pocketsnes target before EVERY build, or else it won’t build all your changes.
•Converted everything to LLVM 3.0! No longer need to use an old Xcode version to change the snes9s code!
•No longer crashes when loading a ROM (however, at this time it still crashes when quitting one).

 

[Bob Sharkle]

Wirelessly posted (Mozilla/5.0 (iPhone; CPU iPhone OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A405 Safari/7534.48.3)

I've downloaded the project, but whenever I try to "make" the src files it errors out. Any suggestions?

 

[iSkythe]

Wirelessly posted (Mozilla/5.0 (iPhone; CPU iPhone OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A405 Safari/7534.48.3)

I've downloaded the project, but whenever I try to "make" the src files it errors out. Any suggestions?

You don't need to make the files located in the src directory, they're already made. However, if you wanted to modify them you would go to the original_src directory which contains the files before the make. Once done modifying, you'll need to install a copy of the iOS development kit at /Developer/ that includes git 4.2.1 (the iOS 4.3 SDK for Xcode 4 can be found here: http://developer.apple.com/devcente...dk_4.3__final/xcode_3.2.6_and_ios_sdk_4.3.dmg), THEN the you can make the files

 

[Menge]

Using the SNES4iOS GitHub repository seems to work after removing the entitlements file and all references to it.

I have quite a few issues (most of the known ones), but this one seems new:
- Doesn't update the screen on portrait (iPhone 4, iOS 5)

Wow looking at the source code, the original iPhone UI code is quite a hackjob! I'm amazed it even works! The coder really fights the iOS controller hierarchy mechanism.

 

[iSkythe]

Using the SNES4iOS GitHub repository seems to work after removing the entitlements file and all references to it.

I have quite a few issues (most of the known ones), but this one seems new:
- Doesn't update the screen on portrait (iPhone 4, iOS 5)

Wow looking at the source code, the original iPhone UI code is quite a hackjob! I'm amazed it even works! The coder really fights the iOS controller hierarchy mechanism.

That was one of the biggest problems when taking over, I had no idea where to start

What do you mean by it doesn't update? Like it's frozen, or it never rotates to portrait?

 

[306Designs]

Very cool. If only saving and loading were working good, this would be a must-have

 

[Menge]

That was one of the biggest problems when taking over, I had no idea where to start

What do you mean by it doesn't update? Like it's frozen, or it never rotates to portrait?

It rotates, but then the game screen freezes while the game goes on.
It starts updating the game screen again once we go back to landscape.

I really wish I had the time and it was possible to post this to the App Store. I'd devote some of my time if that were the case...

 

[RotaryP7]

I would pay any developer to actually do this..

I doubt Apple would approve it though.

 

[Menge]

I'm very scared of this one. I spent part of my afternoon implementing a clean implementation (yes, from scratch and with no hacks) for the iOS UI just to see if all the crashing was due to the emulator original code or the UIKit implementation.

Turns out part is the UIKit implementation (my implementation reliably starts up without crashing) and part is that the underlying code does SOMETHING which makes the UIKit part VERY unstable regardless of what it does. Just running the emulator portion without even interfacing it with UIKit (separate thread but no actual passing of any values along) causes any view to crash intermittently when being touched and so on.

It was very interesting, since I had never dealt with this kind of code before, but I'm done with this experiment. Is there any other codebase for an ARM-based SNES emulator other than SNES9X?

 

[iSkythe]

I'm very scared of this one. I spent part of my afternoon implementing a clean implementation (yes, from scratch and with no hacks) for the iOS UI just to see if all the crashing was due to the emulator original code or the UIKit implementation.

Turns out part is the UIKit implementation (my implementation reliably starts up without crashing) and part is that the underlying code does SOMETHING which makes the UIKit part VERY unstable regardless of what it does. Just running the emulator portion without even interfacing it with UIKit (separate thread but no actual passing of any values along) causes any view to crash intermittently when being touched and so on.

It was very interesting, since I had never dealt with this kind of code before, but I'm done with this experiment. Is there any other codebase for an ARM-based SNES emulator other than SNES9X?

I've looked, but haven't found a good alternative yet. I spent hours the other day trying to modify the emulator code to compile with LLVM 3.0 and Xcode, and was successful, but unfortunately I found that even though it compiles fine, it does not run well The sound is garbled, and you can only see the background color of the game you're playing. Back to the drawing board...

 

[Menge]

I've looked, but haven't found a good alternative yet. I spent hours the other day trying to modify the emulator code to compile with LLVM 3.0 and Xcode, and was successful, but unfortunately I found that even though it compiles fine, it does not run well The sound is garbled, and you can only see the background color of the game you're playing. Back to the drawing board...

Disable build optimizations and sound and foreground comes back. My "test" was built with LLVM 3.0 and runs games, but still very unstable. This is so weird. I even thought of trying to update the snes9x part of it to the latest (1.53) but it seems like too much trouble to go through :\

 

[iSkythe]

Disable build optimizations and sound and foreground comes back. My "test" was built with LLVM 3.0 and runs games, but still very unstable. This is so weird. I even thought of trying to update the snes9x part of it to the latest (1.53) but it seems like too much trouble to go through :\

Where are you seeing the setting for build optimizations? In the makefile or the Xcode project? I've created a new branch on the project where I've pushed the changes I've made to allow the emulator compile with LLVM 3.0 as well as the added bonus of compiling from within Xcode. If you want to edit the project, open the SNES4iOS.xcworkspace file so you can edit both the Objective-C and C portions.

https://github.com/iSkythe/SNES4iOS/tree/experimental

 

[Menge]

Where are you seeing the setting for build optimizations? In the makefile or the Xcode project? I've created a new branch on the project where I've pushed the changes I've made to allow the emulator compile with LLVM 3.0 as well as the added bonus of compiling from within Xcode. If you want to edit the project, open the SNES4iOS.xcworkspace file so you can edit both the Objective-C and C portions.

https://github.com/iSkythe/SNES4iOS/tree/experimental

It was in build settings in Xcode. Go to your project settings, under build settings and set all "Optimization Level" to "None [-O0]" on both DEBUG and RELEASE modes.

Also, I found out why the emulator crashes so much

In "iphone_main()", the author naively uses the passed "filename" array as a destination array for the computed full path for the ROM. In both your original code and my code, the array passed in filename is exactly the same size as the ROM file name, and not sufficient for the entire path - thus overflowing and generating EXC_BAD_ACCESS at random times. A simple solution is when creating the char string to pass to the iphone_main() function to allocate it to the size of the full ROM path+1 and not the size of just the filename.

 

[iSkythe]

It was in build settings in Xcode. Go to your project settings, under build settings and set all "Optimization Level" to "None [-O0]" on both DEBUG and RELEASE modes.

Also, I found out why the emulator crashes so much

In "iphone_main()", the author naively uses the passed "filename" array as a destination array for the computed full path for the ROM. In both your original code and my code, the array passed in filename is exactly the same size as the ROM file name, and not sufficient for the entire path - thus overflowing and generating EXC_BAD_ACCESS at random times. A simple solution is when creating the char string to pass to the iphone_main() function to allocate it to the size of the full ROM path+1 and not the size of just the filename.

I've pushed the those changes to the experimental branch, but even with optimizations off the ROMs don't function properly. Would you mind posting your Makefile here or sending a pull request on GitHub?

 

[RotaryP7]

I would pay any developer to actually do this..

I doubt Apple would approve it though.

That. Whoever is up for it.

 

[iSkythe]

That. Whoever is up for it.

I would love to be able to put this in the app store (and for free!) but this current implementation uses private APIs. The original author even attempted to submit it a version without private APIs but it was still rejected. Maybe someday Apple

 

[Menge]

I've pushed the those changes to the experimental branch, but even with optimizations off the ROMs don't function properly. Would you mind posting your Makefile here or sending a pull request on GitHub?

Can you give me an example of a ROM that doesn't work properly so I can test on my build before going through all the trouble of hosting a GitHub project?

 

[psonice]

I suspect that even if apple approved it, nintendo would have it killed and buried fast. The roms are presumably copyrighted for a start! Besides, what would you run on it? Homebrew would be OK, anything else would have to be licensed - and I doubt many people want it for homebrew

I'll have a play with this at some point, either when I have some free time (no sign of that on the horizon) or when somebody gets it stable. Good luck chaps!

 

[mlukens]

I put this on my iPhone & iPad but I can't get the iPhone to connect as a controller, am I missing something?


EDIT: Nevermind I must have missed it in the release notes, got it now.

 

[iSkythe]

Can you give me an example of a ROM that doesn't work properly so I can test on my build before going through all the trouble of hosting a GitHub project?

I'm using Super Mario Bros All Stars + Super Mario World, and Legend Of Zelda a link to the past

 

[QuarterSwede]

I gotta say, I would pay for a stable version that has instructions on how to compile it and install it. I know the license for SNES9X's base code is GPL'd (or at least not suppose to be sold) but a donate button wouldn't hurt.

iOS 5 is good enough for me to not want to jailbreak it but I do miss being able to play my old SNES games on the go.

 

[Menge]

I'm using Super Mario Bros All Stars + Super Mario World, and Legend Of Zelda a link to the past

If you mean the black screen when leaving the house in Zelda, I get that too on my direct build. I think it's due to the old emulator version (It's based on SNES9X version 1.39, I believe).

Yesterday I was able to partially port the latest SNES9X 1.53 to a frontend similar to this one and it fixes ALL of those issues you had - With the drawback, however, of being slower due to the newer cores being written in C++ and not Assembly. I'm still investigating to see if it's possible to make it faster. If it is, then I'll post the code. If it's not, why bother, right?

 

[iSkythe]

If you mean the black screen when leaving the house in Zelda, I get that too on my direct build. I think it's due to the old emulator version (It's based on SNES9X version 1.39, I believe).

Yesterday I was able to partially port the latest SNES9X 1.53 to a frontend similar to this one and it fixes ALL of those issues you had - With the drawback, however, of being slower due to the newer cores being written in C++ and not Assembly. I'm still investigating to see if it's possible to make it faster. If it is, then I'll post the code. If it's not, why bother, right?

I'm not able to get anything when I launch any ROM. For instance, here is what happens when I get to the title screen in Zelda:

I've attached my Makefile that I've been using. Any chance you could compare it to your own?

 

[Menge]

I'm not able to get anything when I launch any ROM. For instance, here is what happens when I get to the title screen in Zelda:

Never had that problem. Neither with your original build nor with my own new front-end.

The problem I encountered while using the old 1.39 version of the SNES9X codebase was black screen in the outside map (screenshot of the same codebase as yours but with a rewritten controller UI):

But that is fixed by updating the codebase to SNES9X 1.53. It got slower, though.

I've attached my Makefile that I've been using. Any chance you could compare it to your own?

I'm not using a makefile. I'm building directly from within Xcode. Didn't you post a working Xcode project yourself earlier in this thread. I was building from that before I ported 1.53 over and started anew with it.

But looking at your makefile I see its build flags are almost the same as mine in Xcode with the notable exception that you're specifying -O3 when I said earlier that the emulation code breaks if you apply any optimization at all to the code while building with Apple LLVM (clang). Change -O3 to -O0 and it should go back to working.

 

[iSkythe]

Never had that problem. Neither with your original build nor with my own new front-end.

The problem I encountered while using the old 1.39 version of the SNES9X codebase was black screen in the outside map (screenshot of the same codebase as yours but with a rewritten controller UI):
Image
But that is fixed by updating the codebase to SNES9X 1.53. It got slower, though.


I'm not using a makefile. I'm building directly from within Xcode. Didn't you post a working Xcode project yourself earlier in this thread. I was building from that before I ported 1.53 over and started anew with it.

But looking at your makefile I see its build flags are almost the same as mine in Xcode with the notable exception that you're specifying -O3 when I said earlier that the emulation code breaks if you apply any optimization at all to the code while building with Apple LLVM (clang). Change -O3 to -O0 and it should go back to working.

That was it! I had changed the Optimization level in my Xcode project and Target, but didn't change it in the makefile. The reason I'm using a makefile is because Xcode can't natively build the emulator code, so I created an Xcode project which uses the supplied makefile to build.

Now, GCC is no longer needed to build the emulator OR the project! This will make it much easier for newcomers to build I'll upload the master branch on github shortly.