Sunday, November 30, 2008

New repository for iPhone examples created

I've created a google code project , which I will use to post working mini-examples for iPhone developers.

The first installment is an example of using parallel ARM assembler in XCode to do basic processing of an ARGB image.  I'll post a follow up with more detail.  In summary, for each iteration, the routine

  • reads 16 bytes into 4, 32-bit registers (r2-r5) in 1 ldmia (load multiple) instruction, 
  • processes the 16 bytes in 4 uqadd8 instructions, which equates to 4 pixels (ARGB).
  • stores the 16 bytes back to memory, and increments the buffer point in 1 stmia instruction

Saturday, November 15, 2008

C64 for iPhone: There and back again

Lately, I've had a chance to play some more with the iPhone (and I'm really enjoying XCode).  The title, 'There and back again' eludes to the fact that in my quest to have a C64 on my iPhone, I started by porting Frodo, and then ported VICE.  Now I'm 'back again' to Frodo.

Why?

I'll spare all the technical details for another post, but essentially the design of VICE (written in C) was not optimal for achieving playable performance out of a mobile CPU, like the iPhone.  Frodo is a much smaller code base, written in C++ and designed in such a way that GCC's optimizations were fully utilised.  I've spent time fixing some lingering issues with Frodo the last few days and now have iFrodo running 100% emulation speed at 25fps.  I could run the emulator at 50fps, but frame buffer access is not optimal in the public SDK today, adding significant overhead. When running Frodo in 'turbo' mode, the emulator runs up to 900%!

I fixed an issue in the 'fake' drive emulation, where many games would fail to load using the 'fast drive mode'.  This mode typically loads games in less than a couple of seconds at 100% emulation (even fast in turbo mode).  I found they would work when enabling the 'Emulate 1571' switch, but given this emulates the 6502 CPU similar to a real 1571 drive, it can take many minutes to load a game in some cases.  With that fix, the majority of games can load in fast mode.  For usability, I also updated the fast drive code to alert the user when a game requires the 1571 emulation, so it doesn't just crash, leaving you wondering.

I also found out that some games are cracked in such a way that are incompatible with Frodo (such as Wizball and Fist II).  I located alternative images of these games that worked, so Frodo is a go!

I resolved some remaining issues with the 'touch stick', and now can play games effectively.  I think the idea has turned out great in practice.  I chose this over the more popular on-screen 'D' pad and fire button, which forces the user to press a specifically targeted area, that is difficult to master without any tactile feedback.  What lead to my design was that I attended a User Experience seminar, presented by Chris Nodder of Nielsen Norman Group (ironically, their website appears to be an example of poor design) and learnt about Fitts' Law.  I've alloted the whole screen to joystick function, meaning you can watch the game and not your fingers.

The majority of work left is related to
  • Saving state when the app is terminated (such as by the Home button or an incoming phone call).
  • save / load named game state and
  • landscape mode.
I'll create a video demonstration the emulator in action on a physical device very soon.

This all helps with some of the issues I had with mSID too - so I'll post an update on that shortly.