You may remember from my post about hacking the boot image of Intel Macs that I was interested in doing this for a MAME arcade cabinet. Astute readers will also know that there is currently no Intel port of MAME for OS X. The MacMAME project has been dormant for most of the year, and is PowerPC only. SDLMAME does compile and run fine, but as with most cross-platform projects, there are a couple minor things that would be nicer if it could target OS X only. So, being the freak that I am, I decided to work on my own MAME port to OS X. After a couple months of work in the background, it is finally ready for general release. I am officially annoucing the “MAME OS X” project, so check out the home page for download links to a universal binary.

It definitely has some warts and in need of some spit and polish, but at least it’s not embarrasing. All video and sound emulation should be working, and it shouldn’t crash. Enjoy, and please report any problems you find on the SourceForge bug page or the web forum. I’ll describe some of the behind the scenes tech details in the next few paragraphs.

I’ve got to applaude the MAME developers, because the project is well abstracted to be OS agnostic. On OS X, the sound is implemented with Core Audio and the graphics are implemented using Core Video, Core Image, and OpenGL. This not only ensures the best performance, but allows real-time Core Image filtering on the emulation output. While mostly pretty useless, it can add a new twist to an old game. The screen shot above is an example of the CIEdges filter applied to Ms. Pac-Man. I’m sure someone with mad CIKernel skillz could do something pretty cool with this capability.

One of the more difficult aspects to the port, was actually getting the whole thing to build in Xcode. MAME uses a fairly complex Makefile-based build system. Many of the Makefile tricks, like dynamically generating the list of files to build, and creating #defines are not possible in Xcode. Also, MAME is a huge project, with over 2,000 source files. Xcode can cope, but it feels like it struggles at pionts. Getting all of the correct source files into the project was a challenge. Unfortunately, it’s not possible to just grab every .c file and throw it into Xcode. There are many .c files that are used as include files (a .c file #includes another .c file), and the only way to find out which was is to look for compilation errors. I’m currently devising a way to automate this as much as possible.

In the mid-term, I’m going to work on putting the emulation, graphics, and sound into a framework I’m calling MameKit. With MameKit, you’ll be able to embed a MameView/MameRenderer in any Cocoa application, much like QCView/QCRenderer for Quartz Composer. I’d really like to see a dashboard widget and a Quartz Composer custom patch.