Friday, December 26, 2008

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.


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.

Wednesday, October 29, 2008

The GPL and iPhone development

I have read through the GPLv3, and whilst I am not a lawyer, it is worded without too much legalese.  Here is my take in FAQ style, addressing some points of contention that I have come across on a number of forums.

Doesn't the signing certificate imply 'Tivoization'?

To clarify what 'Tivoization' is, included is the following from the article A Quick Guide to GPLv3:
Tivoization: Some companies have created various different kinds of devices that run GPLed software, and then rigged the hardware so that they can change the software that's running, but you cannot. If a device can run arbitrary software, it's a general-purpose computer, and its owner should control what it does. When a device thwarts you from doing that, we call that tivoization.
Many users are confusing the purpose of the signing certificate as a potential 'Tivoization' violation.  Your signing certificate has nothing to do with a specific application, nor is your application tied to a specific signing certificate (unless you were to somehow code it as such).  It is simply a requirement imposed by Apple that all 'official' applications be signed and it's purpose is to identify who built the application and that the application has come from a trusted source.  Remember, anyone who has access to the SDK and has paid their dues can sign an application and install it on the physical device.

GPL requires all the source be released, but doesn't the NDA prevents this?

Apple has revised the NDA, and now it applies to unreleased versions of the SDK.  At the time of publication, that would imply anything built on version 2.2 of the SDK (which is currently in beta) is under NDA.

GPL software requires all installation scripts ('Corresponding Source') be released, so don't I have to release my signing certificate, which would be a violation of Apple's license?

You do not need to release your signing certificate.  The source code or the compiled application is not tied to the original author's signing key, and as mentioned elsewhere in this FAQ there is no 'Tivoization' violation.  An individual can simply uninstall the original version of GPL'd application, compile using XCode and reinstall their modified version.  Releasing the compilable XCode project will ensure your project is in compliance with the GPL, as this handles the installation of the software to the device.

You must pay to enter the Apple Developer Program, is this a violation of the GPL?

Yes, and you had to pay to get an iPhone in the first place.  You also had to pay for an Apple computer running OS X to do official iPhone development.  Paying to enter the developer program is another cost, but this is not a violation with regards to GPL'd software.  Once you've paid your dues and received your own signing certificate, you can compile and install the GPL'd software you downloaded. 

Ultimately, the user still has complete freedom to modify and install the GPL'd application - and that is the essence of GPL'd software.

Sunday, October 05, 2008


This is a huge boon for all the GPL software out there. The more I researched the issue, the more I realised I wasn't going to be able to release any GPL'd software via the App Store until it was lifted.

Also, I've been quiet lately - not because I've lost interest in the iPhone, but my day job has required more of my personal time lately - admittedly, the GPL issue didn't help. I have been talking to Andreas, who is the author of SIDPLAY for OS X. We are going collaborate, which should result in a great version of SIDPLAY for the iPhone. Unfortunately, we have both been very busy lately, so things have been moving slowly, but don't despair, as in the coming months I'm sure we will be able to finish off SIDPLAY for the iPhone.

Tuesday, September 02, 2008

mSID and the High Voltage SID Collection

The default format for running the High Voltage SID Collection (HVSC) on the device will be in a ZIP archive. The HVSC is about 65mb zip'ed up, which in turn contains a 200mb uncompressed archive, This inner archive contains over 35,000 files. It is impractical to expect that will extract on the device in a reasonable amount of time, hence the decision to stick with an archive. I will provide a re-compressed version of, which you will be able to download via mSID and from then on, one should be able to download the HVSC updates direct from their site. I will also include a sqlite database of all the files, in order to improve performance for searching. I expect that long-term, the role of the database will grow to become your store of ratings, play lists, etc. Given it's sqlite, it will be open to reading and updating.

From an implementation perspective, I have pulled together the necessary code to be able to read a ZIP archive as Cocoa does not have ZIP support built in. I have built this as a .framework, and will probably open-source it at some point.

The browser will use the familiar hierarchical navigation built in to the iPhone.

Monday, September 01, 2008

Introducing mSID

'm' what? mobile-SID!

Given the setback in rendering iC64 usable, I wanted to tackle something that would generate results relatively quickly.  There has been a modest amount of interest in a SID player for the iPhone (it is a mobile music player after all) and so mSID has begun.

As of this evening, I have played Wizball on the the device, and to my delight it works like a charm.  There is no user interface to speak of yet so no screenshots; however, I can focus on the design now that playback is not going to be an issue.

I'll be working on brining mSID to the App Store in the coming weeks.

How will I get songs on the device?

I have several games that allow downloading of content (new levels) from the internet, so I will provide the same feature.

What about STIL and song length support?

Of course.

What's going on with iC64?

Lot's of emails and posts asking how the emulator, iC64 is coming along, so I wanted to post a short update.  Firstly, iC64 is still alive, but took a back seat for a while due to life commitments, both work (travel and major release going out the door) and much needed vacation. I am beginning to find some spare time, allowing me to return to my hobby.

What's the problem?

I'm running into some significant performance problems running iC64 on the device.  Let's not forget this is a mobile device, and VICE is designed to run on some pretty hefty hardware.  I believe the iPhone can do it, but it's going to take some work on my part to get it there.

What can you do about it?

I've been staring at ARM assembly (not Thumb) and monitored the device with Shark, which is a tool used for performance analysis.  It's obvious that there simply aren't enough cycles to run the emulator as it stands today.

Part of the issue is that VICE is broken into 100's of small files for modularity, but that causes problems accessing shared static data across object files.  What I'm finding is that a variable 'foo' declared in file 'a' and accessed in file 'b' generates three memory accesses. Two indirect reads before getting the value.  Ouch.  I've found ways to mitigate this, but it's going to require a fair amount of refactoring.  I'll start with the hot-spots first and work my way on from there, until I've squeezed out the performance I need.  Unfortunately, how long this will take is an unknown, so I'll post updates as I progress.

Stay tuned.

Saturday, July 12, 2008

I'm in!

It seems with the release of iPhone 2.0, Apple opened the flood gates to the iPhone developer programme on Friday. I received my acceptance email late in the day. I've subsequently paid my dues ($99 USD) and now have iC64 running on the device. This brief experience leads to a separate post about compiler settings for hi-performance applications on the iPhone.

Friday, June 20, 2008

iFrodo is dead, long live iC64

The Obituary

To whom it may concern:

After repeated gaming accidents, it is with sincere regret that iFrodo is no longer.  A team of 1 and countless hours spent operating in the debugger simply could not save it.

And for all that you, iFrodo have taught me about the iPhone SDK, I am forever in your debt.

The Diagnosis

During routine exercises (testing), iFrodo was consistently passing out.  The first occurrences were running Wizball and Fist II, which caused iFrodo to report an invalid opcode.  In an attempt to eliminate any genetic issues, I decided to check family history, which included WinFrodo and their .NET cousin, sharp-64; however, they showed almost identical symptoms.

Next, to eliminate the possibility the D64 images were corrupt, I tested the offending games using iFrodo's distant relatives, CCS64 (PC), WinVICE (PC), VICE (OSX) and Power64 (OSX) all of which had no issues.

I spent many hours and explored many avenues, but could not come up with the elusive fix.

The Future

I have completed a port of VICE to the iPhone, iC64.  Any suggestions for an alternative name for the 'product' are welcome.  More importantly, all functionality that was present in iFrodo is available in iC64, with the exception of the previously mentioned bugs.

A picture is worth a thousand words and a video is worth a lot more:

Update: Video now plays the emulator sound.  Forgive the voice-over, as it is a little quite when the sound is on.

Wednesday, June 04, 2008

iFrodo - Keyboard mania

I've now successfully hooked the keyboard up to iFrodo.  Without a doubt, the experience is much better.

I've uploaded a short video to youtube to demonstrate the new functionality in action. Forgive the green text over the video implying 'please register me, you bad, bad individual' - I will buy a copy of the software and redo the video.

Tuesday, June 03, 2008

iFrodo Keyboard: Working

I've now completed the keyboard to the point where I can load and run programs via the emulator, including support for multiple layouts.

I will add the Fn keys next and then hook it all up to the emulator, removing the clunky NSTextField and built-in keyboard. I short video will follow with this milestone.

A longer term usability goal is to show the actual 'drawing' keys when the shift or C= key is pressed, but gathering all the images of the keys is a lot of work for a rainy day.

The default layout:

Picture 1.png

The number and glyph layout (Fn keys will go here):

Picture 2.png

Sunday, June 01, 2008

iFrodo - More keyboard features

A lot of 'under the hood' changes have been made to the keyboard, including support for left, centre and right snap regions (note the shift and del keys), sticky keys (like the shift or the Commodore key) and multiple layouts. Multiple layouts will lead to support for switching between the QWERTY or number layout.

I will be pretty close to hooking the basic keyboard up to the Frodo emulator.

iFrodo Keyboard 2.png

Wednesday, May 28, 2008

iFrodo - The keyboard is shaping up

I have the basic framework for rendering any virtual keyboard (in a resolution independent manner) almost completed. The keyboard supports touch events; however, I now have to complete the shift-key support and a few other enhancements for switching layouts (to numbers, etc).

For nostalgia, the colors are pulled from numerous pictures of Commodore 64 keyboards:

iPhone keyboard for emulators
Update: I will be including full support for all the Commodore 64 keys (C64 key, del, clr, etc)

Sunday, May 25, 2008


I'll definitely purchase one of these when they are released. In addition, I'll be particularly interested in adding support for the device to iFrodo, using their provided SDK. assuming I can access the unit via the Apple SDK

Thursday, May 22, 2008

iFrodo - 'Touch-Stick' demonstration

Attached is a short video to demonstrate the joystick (touch-stick) emulation in action using the iPhone Simulator and Impossible Mission by Epyx. Hopefully, once I receive my developer certificate, the experience will be functional on the device. I do plan to support landscape mode, along with switching the position of the fire button area.

Saturday, May 17, 2008

SQLite management tool

For those using SQLite (particularly relevant given it's the default database engine for the iPhone / iPod Touch), here is a great tool for visually managing you database. What is most impressive is the tool is a Firefox add-on, compatible with versions 2.0 - 3.0.*.

Monday, May 12, 2008

iFrodo - Let there be sound

Watch and listen.
Be aware that the video and audio are greatly compressed on it's journey to YouTube.  It sounds significantly better on the simulator.

Sunday, May 11, 2008

iFrodo - progress

Where are we today?

  • Graphics: Done
    • I am using the scan-line mode for the emulator, but I may change to the single-cycle mode after some performance testing. So far it screams on the simulator. I could deploy both versions of the emulator, but that would require considerable work. Hopefully this runs with similar performance characteristics as the real device. I won't know until Apple accepts my application...

  • User Experience : None
    • Portrait: Partial
      • In this mode, the full keyboard will be available, as well as playing games

    • Landscape: None
      • This mode will be primarily for playing games, with the availability of the joystick and probably the Fn keys. Switching to portrait will be necessary to perform more work with the keyboard.

  • Audio : Researching
    • I've found that the Audio Queue Services look to be exactly what I need. Frodo was conveniently built to support sound 'drivers', so shouldn't be too much work here.

  • Input, Keyboard : Planning
    • What I have to day is a 'line editor', using the built-in keyboard (as you can see in the video clip). I type a line of text and 'send' it to the emulator. This is just a debugging tool and will go away before the release.

    • The iPhone SDK and associated frameworks do not allow the built-in keyboard to be repurposed, so I'm going to have to roll my own. This is probably okay, as I'd like to make it generic enough to work with other emulators in the future - think Atari 800XL and Apple II.

  • Input, Joystick : Planning
    • Two options
      • Multi-Touch: I have some ideas for joystick support, which I'll document in a future post - it's going to take advantage of the multi-touch interface and the entire screen surface - 'Touch Stick'.

      • Accelerometer: Something similar to what was shown for the initial SDK release for the space shoot-em-up style game.

Show and Tell
Here is a short video showing 'Hello World' and running IK+ (International Karate +). As mentioned above, it uses the built in keyboard, in 'line mode', which is simply a debugging tool, until I build the UI. No sound either, but that is underway. I'll follow up with another video once sound is activated.

Note about the video recording: It was recorded at 15 frames/sec to limit the size up to youtube; however, the emulator runs at 30 fps without breaking a sweat.

Thursday, May 08, 2008

iFrodo - Success!

After getting over the Objective C and Cocoa learning hump, I have a running C64 on the iPhone simulator.
Next will be to create a UI to manage the user experience, such as
  • Save / Resume state
  • File browser for disk / tape images
    • Ability to 'auto launch' games
  • Virtual keyboard and joystick

First run of C64 in iPhone

Monday, May 05, 2008

iFrodo - porting C64 emulator to the iPhone / iPod Touch

As an Objective-C / Objective-C++ / XCode / iPhone development learning experience, I have began porting the Frodo C64 emulator to the mobile OS X platform. I chose Frodo, as I have experience with this code-base, and there is a certain satisfaction of seeing the READY prompt for the first time.

What will some of the challenges be?
  • The iPhone screen is 320x480 pixels. The C64 had a 320x200 pixel display, so ideally the top of the screen will represent the C64's virtual display, without the need to scale.
  • The C64 had a keyboard and games were typically played with a joystick. We have 280 pixels left to represent these devices. I'm not sure if I can display the iPhone's virtual keyboard, and it is unlikely I can reconfigure the keys. Therefore, I'm probably going to have to design my own virtual keyboard image.
  • For the joystick, I'll probably model something off the NES emulator, with a virtual D-Pad and fire button.
Where are we today?
I have reached my first milestone, which was to create an XCode project and compile the basic Frodo engine for the iPhone platform.

What is next?
An emulator typically virtualises numerous devices of the original hardware, so the first I will tackle is the display, as this provides the most immediate rewards. We need an in-memory buffer to write the output of the virtual display device, which finally is rendered to host screen. I experimented with the OpenGL ES API, but found that Core Graphics / CGImage will do the job just fine.

Last night I achieved my goal of writing to an in-memory buffer and rendering this to the iPhone screen. Next is to incorporate this test code into the Frodo engine, to get a C64 running. Screenshots will follow.

Sunday, May 04, 2008

SDL coming to iPhone / Touch

I've learnt that Google SoC is sponsoring a project to bring SDL to the iPhone / iPod Touch. Great news!

Tuesday, April 29, 2008

Can't see drivers\etc folder or hosts file in Vista x64?

I've just joined the Windows 64-bit OS club and ran into a frustrating issue, whereby I couldn't edit my hosts file (%systemroot%\system32\drivers\etc) using Altap Salamander. If I used Vista's Explorer, there it was.
Now, what's important to understand is Salamander is a 32-bit Windows application and the Wow64 layer is redirecting 32-bit applications to %systemroot%\SysWOW64. I remembered I 'knew' this, but surely there must be a way for a 32-bit application to see the native system32 folder, for file management operations.
Turns out there is. Create a folder %systemroot%\sysnative, and navigate via this to see the native system32 folder from within 32-bit applications.

Saturday, April 26, 2008

Vista x64 officially supported on Apple hardware

The Vista x64 update for Boot Camp is available here.  Perfect timing, as I'll be getting a new 17" Macbook Pro for 'research' at work in the coming weeks, and was hoping to dual-boot with Vista x64.

SIDPLAY 4.0 for OS X 10.5

For all those old Commodore 64 chip-tune fans out there, take a look at the re-released SIDPLAY for OS X.
In Summary:
  • Rewrite of the UI
  • iTunes look and feel
  • Export to mp3, AAC, AIFF and Apple Lossless
  • Integrated Spotlight search
  • Core Audio support

Friday, April 25, 2008

Get latest code from TFS via command line

I tend to work from the command line for managing builds and source control.  For my day job, we use TFS, so I use the Team Foundation command-line utility tf.exe with the 'get' option.
Be sure to start a Visual Studio 200x command-line prompt, to ensure tf.exe is available in the search path.
tf get will recursively grab changes from the current directory, so you can be somewhat selective.
If there are any conflicts, the familiar conflict dialog is presented, allowing you to determine the appropriate resolution.

Improve MSBuild performance with multi-processor builds

Using the command line :\>msbuild /m[:max cores] will automatically take advantage of multiple cores if they are available. Without the max cores parameter, msbuild will use all available cores. I've seen some recent posts on this topic, and wanted to point out I have been using this feature for a number of months, and can confirm noticable performance gains on my dual-core laptop. A big issue for laptops is the IO performance, so if you have slower drives, you may not see the same gains. Have not had a chance to try it on my 8-core Mac Pro :-)