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, C64Music.zip. 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 C64Music.zip, 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.

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.