Sunday, November 30, 2008
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
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.
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
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
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
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 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.
Saturday, July 12, 2008
Friday, June 20, 2008
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.
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.
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
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
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:
The number and glyph layout (Fn keys will go here):
Sunday, June 01, 2008
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.
Wednesday, May 28, 2008
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:
Sunday, May 25, 2008
Thursday, May 22, 2008
Saturday, May 17, 2008
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
Sunday, May 11, 2008
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.
- Portrait: Partial
- 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.
- Two options
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
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
Monday, May 05, 2008
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.
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
Tuesday, April 29, 2008
Saturday, April 26, 2008
- Rewrite of the UI
- iTunes look and feel
- Export to mp3, AAC, AIFF and Apple Lossless
- Integrated Spotlight search
- Core Audio support