Here’s a little editorial by me… Today I was asked why the iPhone & iPod Touch runs emulators slower than the GP2X. This is an excellent question which I’d like to address. Many of the emulators I port over to the iPhone come from the GP2X. The GP2X is a 200MHz ARM920T processor based homebrew-friendly handheld. The iPhone for instance, has an ARM11 processor running at about 412MHz. You’d think if I were to take the same code from the GP2X and get it running on the iPhone, it would run faster. Sadly that’s wrong. It seems there’s quite a few factors in the way of getting certain types of applications such as emulators running to their full potential on the iPhone.

Take for example snes4iphone. In this case there were many optimizations done in tightly written ARM assembly for the assorted chipsets the SNES uses within the PocketSNES software being ported. The sad fact was I was unable to use most of that assembly code as it would take major rewrites and time to get it to work on the iPhone. The reason for this is the iPhone & iPod Touch’s operating system keeps a register globally allocated. This register, R9, can not be used in the majority of ARM assembly code out there for emulators (there are instances where you can save and restore this register to use it). So I have to drop back to a slower C/C++ interpreter for emulation. The same holds true for dynarecs used in gpSPhone and psx4iphone. Losing a register in a dynarec tends to bring performance down. Basically, existing ARM assembly (fast) can’t be used, dynarecs lose a register making them slower, and we’re left with generally the slowest form of interpreters.

Next we have the fact we are dependant on touch controls. I’ve noticed, and others have too, that touching the screen at more than one point at the same time (multitouch) and moving a bit will slow down my emulators. In fact it should slow down anything hogging the CPU. PocketPC’s also tend to have this issue come up. There’s not much that can be done to get around it except make the program you use fast enough to handle the extra load multitouch equates to. This is difficult when we’re already being slowed down by other factors. Then add a translucent screen overlay for landscape play and your emulator gets an instant and large performance hit. This too is noticed when the emulator is question can’t handle the extra load placed on it by the feature.

Another factor is the operating system itself. It keeps background processes going which can suck up RAM, chew up precious CPU time, or both. What else you find out is there is no way to directly access the framebuffer (though I’ve tried and got close) to simply blit pre-rendered frames to the screen. The iPhone & iPod Touch didn’t seem to be designed with the thought in mind that some games, and especially emulators will pre-render a frame to display in memory, then copy that memory to the screen X times a second to get it’s X FPS. Instead we’re left with two options. For jailbroken devices we have the Private Framework CoreSurface. CoreSurface lets us write directly to a CALayer of a view. But this is not the same as writing to a framebuffer, and you have the overhead of calling setNeedsDisplay which lands up drawing other views and generally slowing things down where it not need be.Then you have CoreGraphics which lets you do something similar to CoreSurface during the drawRect portion of setNeedsDisplay, and also takes longer in the process. Why not OpenGL? Well we’re stuck with Open GL ES 1.1, and 1.1 doesn’t include the functionality needed for doing this any faster than what we have already. In fact it’s usually slower, and some have benchmarked blitting a frame to the 320×480 screen as 15FPS slow

Speaking of frameworks, we have AudioToolbox. This framework works great for streaming music, but when you want to stream audio being generated at specific intervals, you land up getting a very touchy timing situation. When dealing with OSS for Linux then coming to AudioToolbox, there will be some stress involved seeing how many buffers in your ring to use. Then tweaking that alongside the best buffer size to get by with decent audio is a pain. Change the audio rate and it all goes out of whack. It would be nice to have more control of the callbacks and their intervals when it comes to AudioToolbox, but this is what we deal with.

And finally we have the simple premise of writing more pixels to the screen and adding (even hardware based) scaling and rotation for things like landscape mode just plain ole slow things down. The GP2X has a 320×240 screen. The iPhone & iPod Touch have twice that, at 320×480. When you have a higher resolution screen and, for instance, no hardware to handle rendering at a lower resolution…you’re left with slowdowns.

Part of what I enjoy about working on these emulators for systems like