When I connected it to my Mac in USB drive mode to transfer files, it appeared in the Finder as two storage devices, one for the internal storage and one for the memory stick. When I’d finished transferring files I would click Eject on the memory stick’s device to safely remove it. Then I’d do the same on the internal storage’s device, but this would eventually fail and report an I/O error. The phone’s screen would show that the USB connection had ended, but one of the devices would still show in the Finder. If I then unplugged the USB cable the Finder would tell me that data might have been lost since I didn’t eject the storage device properly.

I eventually found a workaround – go into the Disk Utility app, and Unmount (not Eject) one device, then Eject the other. The order didn’t seem to matter, as the Eject would cause both devices to disappear. However this required me to launch Disk Utility to do the unmounting every time I had to unplug the phone from the Mac.

I started to get fed up of the extra time and clicking involved, so I decided to write a single-function Service to do the unmounting. Check it out here.

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.

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!

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