On Wednesday, I gave a talk at the Student Techmeetup here in Edinburgh on DS homebrew development. As promised, I’ve uploaded the slides from that talk as a PDF here, with links to a few tutorials and resources included in them, along with some notes.
Student Tech Meetup talk
February 18th, 2010emitSMS plugin update
January 16th, 2010The emitSMS plugin has been updated with a small new feature – it will now strip out dashes and spaces from your phone numbers in Address Book before sending them to the phone, as most phones don’t seem to accept numbers in this format. Grab the new version here.
emitSMS plugin bug fix
October 25th, 2009Here’s a new version of the Address Book plugin for SMS sending, with a small bug fix intended to stop it hanging after sending an SMS. If you’ve seen this problem with earlier versions, please let me know if this version has fixed it or not 
emitSMS Address Book Plugin updated
October 1st, 2009emitSMS plugin for Mac OS X Address Book.app
September 14th, 2009In the distant past, the Address Book app in Mac OS X Tiger could send mobile SMS messages directly from within the app, if you paired your mobile phone with your Mac via Bluetooth. Along came Leopard, and the feature mysteriously vanished without trace or explanation, and hasn’t reappeared since. Missing the feature, I found a roundabout replacement in the emitSMS dashboard widget. It offers SMS sending via Bluetooth and can also search the Address Book for phone numbers. Having seen that the source code for emitSMS was released, I adapted the backend into a plugin for Address Book.app to provide the missing former functionality.
Download, unzip and place the plugin in /Library/Address Book Plug-Ins/ and restart Address Book. You should then be able to click on a phone number on a person’s card and select “Send SMS via Bluetooth” to send them a SMS.
The source code is also available, under the same MIT license as the original emitSMS source code.
Notes
The plugin should be compatible with Address Book in Leopard and Snow Leopard.
To use the plugin (or the emitSMS widget, in fact) you need to set up a virtual serial port over Bluetooth to your phone. This will normally be set up automatically by OS X when you pair your phone with your Mac, but the serial ports can be edited in the Bluetooth panel in System Preferences if necessary. (edit: No longer necessary in the latest version, all you need to do is pair your phone with your Mac).
After you select a port to use in the pop-up menu, it will test the port for SMS sending capabilities. The port will only be usable if the test succeeds. Some phones seem to be a little flaky when communicating via Bluetooth and require the test to be run a few times before it can establish a connection successfully. If it fails initially, try clicking on the port again.
If ‘Long Messages’ is not enabled your messages will be limited to 160 characters (or 70 characters if you use symbols outside the standard GSM set, e.g. ^ ). Not all phones support the sending of long messages (actually splitting the message into several SMSs). Additionally, not all phones support requesting delivery receipts.
In general, if your phone works with the emitSMS dashboard widget, it should work with this plugin as the same underlying method is used to send the SMSs.
Deflektor remake for Nintendo DS
June 7th, 2009Here is a project I’ve been working on for a few weeks to learn more about DS homebrew coding. It’s a remake of Deflektor, an old puzzle game that I played on the Amiga. I’ve tried to keep the retro feel of the original while updating it to use the touchscreen interface.
The aim is to rotate the mirrors (
) to reflect the laser beam from the source (
) to blow up all the triggers (
) and then enter the target (
). Rotate the mirrors by tapping on them and then dragging to align the mirror at a particular angle. You start with an amount of energy which is constantly declining (the green bar). Directing the beam into a spike (
) or reflecting the beam back to the source will cause it to overload (represented by the red bar). If the source is overloaded too much or if you run out of energy, you lose a life. There are also rotating blocks which only allow the beam to pass at a certain angle (
), teleports (
) which work in pairs, and blocks which randomize the beam direction (
). In addition, in some levels there are gremlins which roam about the board and mess with your stuff. You can get rid of them by tapping on them repeatedly.
There are a few things I’d like to add to the game, like highscore saving and a level editor, which might appear if I have time to work on it. For now it comes with all the levels from the original game. You can download it here. Any comments, bug reports, etc are welcome!
DesMuME for Mac OS X with GDB stub support
April 5th, 2009I’ve built a Mac (Intel) binary of DesMuME, from the latest SVN code, with a patch to enable masscat’s GDB stub. With it you can load a homebrew rom, connect to DesMuME with the copy of GDB that’s provided with devkitARM, and start debugging your homebrew code while it’s running in the emulator. For more details check out this post on the official forums.
The binary can be found here, and the modified parts of the source code can be downloaded here. Please let me know if you find any bugs related to using the GDB stub – I’ve tested it a bit and most features seem to work, but this is the first time I’ve worked on the DesMuME code and I may have overlooked something. I take no responsibility for bugs in the unmodified Mac version of DesMuME though 
How to use it:
Currently the only method of specifying the debugger ports to use is on the command line. So, open up Terminal.app and run DesMuME from there, like so:
orange:~ sigmaris$ /path/to/DeSmuME.app/Contents/MacOS/DeSmuME -arm9gdb 20000
Note the single dash before the argument. This will start the ARM9 stub listening on port 20000. You can also use -arm7gdb <port> to start the ARM7 stub. You can omit either of the arm9gdb or arm7gdb arguments and it won’t start the respective GDB stubs at all. If startup was successful you should see log messages like this on the console:
2009-04-05 22:32:41.896 DeSmuME[29404:10b] Using ARM9 GDB port 20000
Then go to the DesMuME window, set up a FAT image if necessary, and load your homebrew ROM. You’ll notice it doesn’t start immediately but just shows a white screen. It is waiting for GDB to connect, so go ahead and start it up (I assume you have devkitPRO installed in /usr/local)
orange:~ sigmaris$ /usr/local/devkitPRO/devkitARM/bin/arm-eabi-gdb homebrew.elf
You should point gdb to the compiled ELF file of the homebrew ROM that you loaded earlier. You should see the (gdb) prompt, now tell GDB to connect to the DesMuME stub:
(gdb) target remote :20000 Remote debugging using :20000 0x02000000 in _start () (gdb)
If you see the above output, you’re ready to start debugging. For example, set a breakpoint on a function that you use in your homebrew program, and then enter ‘cont’ to tell DesMuME to continue running the program. You should see your program run up to the breakpoint and then stop, and GDB will print a message saying it encountered the breakpoint. You can now examine the state of local variables, print a backtrace, or step line-by-line through your code.
Hopefully this will be useful for some homebrew DS developers on the Mac. Unfortunately, even with the GDB stub in place, DesMuME doesn’t catch many of the errors that would trip you up on a real DS like writes to invalid memory and other similar errors. But being able to jump in anywhere and examine the running state of your code is a step forward from just using tons of iprintf() calls