I finally was able to restore operation of my GP2X – the “secret” was to use Linux’s fdisk utility to change the partition type on the CF card to “b” (original Win98 FAT32) and then reformat it FAT32 (mkfs.msdos -F 32). After that the GP2X had no trouble recognizing the card and fixing itself from a supplied firmware image. Now, what can I compile on this thing? 🙂

This is *not* emulation related (so don’t even think about PCPCing yourself with it on MW), but if you’re trying to play Xbox Live™ through a NAT firewall (Linux-based or dedicated hardware), you need to add a rule that forwards UDP port 3074 to your Xbox or Xbox360’s IP address. Some games may need other ports as well, but that was sufficient to get my 360 to say my NAT was “Open” and for Burnout Revenge (the native 360 version) to play lag-free online. There was no good help for this on a Google search (people were suggesting installling UPNP clients and all manner of other crazy) so hopefully will help.

SDLMAME™ is now up and running on Intel Mac OS X, including all the ASM speedups, MMX/SSE blitter effects, and dynamic recompilers from the original MAME. I’d include a screenshot, but OSX’s screen capture for some reason grabs our window’s frame without the contents. Of course, it’s purely a commandline application, but if you have a portable frontend maybe we’ve got the app you’ve been waiting to drive 😉

Oh, and the number everyone’s dying to know: on my 1.66 GHz Core Duo Mac Mini, Killer Instinct is close to but not solidly 100% (it’s extremely playable however). Any “Mactel” at 1.8 GHz+ should run it flat-out I would think (e.g. the iMac or Mac Book Pro).

I’d like to address both the general phenomenon of posts like this and some of the mistaken assumptions that drive it (and that pop up on the thread).

First off, and I don’t know how clear I need to make this, but if you wish to support MAME/MESS, do not EVER go begging to another emulator’s author like this. (And conversely, begging us to work on some other emulator is not looked up kindly either). Not only is it rude and intrusive to the person(s) you’re approaching, but it relys on the extraordinarily rude assumption (commonly held, but no less false for it) that MAME/MESSdev are a bunch of moronic dilettantes who couldn’t find their shoelaces in the morning without a colored chart, and that somehow anyone working on another emulator is by definition infinitely smarter.

I’m now going to blow these’s peoples’ minds.

MAMEdevs R. Belmont and smf also work on the non-MAME emulator ZiNc. RB also works on the big-in-Japan sound emulator M1, the nobody-cares sound emulator Audio Overload, and is porting the awesome NES emulator NEStopia to Linux.
MAMEdev ElSemi also works on the non-MAME emulators Nebula, Model 2 Emulator, and Nebula Jukebox
MAMEdev Ville Linde also works on the non-MAME emulators Project Tempest and SuperModel.
MAMEdev David Haywood is largely responsible for the last few releases of the non-MAME emulator RAINE.
MAMEdev Aaron Giles also wrote the non-MAME Gaelco3D Emulator as well as the venerable Connectix Virtual Game Station at his day job.

Apparently we’re all severely bi-polar.

In real life, we can and do approach other authors for cooperation, and one of the goals of the recently revised MAME/MESS license was to help interoperability. Our license is now LGPL compatible (although not plain GPL compatible), meaning code licensed as LGPL can be used in MAME/MESS as-is. It’s also much easier to read and understand – essentially you must send back any improvements to the code and you cannot use it in commercial products without permission.

On to specific things I’d like to address from that thread. Byuu, who’s emulator I pimp almost constantly, had these objections to working in MESS:

1) You lose the most enjoyable part. Doing something yourself.
2) You get to learn all of the ins, outs, and intricacies of programming drivers for a system you’re probably unfamiliar with.
3) Some of us don’t believe that combining all emulators into one giant program is a better approach than smaller, customized emulators for specific targets.
4) [CPU cores already exist in MESS] which may or may not be compatible due to differences between CPU revisions, and different approaches of emulating the processors.
5) [Aaron’s world-class fixed point timing system] that is completely irrelevant. Timing is one of the easiest and most processor intensive tasks (well, depending on how tightly you sync components and how many of them there are), so you want it to be as customized and lean as possible.
6) so you lose flexibility in how you want your audio and video systems to work.
7) [full cross-platform support] Not the hardest thing in the world to do if you write your code in clean c++, and you lose the ability to take advantage of platform-dependant code, e.g. native UI elements and OS functionality not available on other platforms.

To which I reply:
1) You lose the most annoying part, coding the same stupid framework for every emulation you want to try. Instead you get a solid, well-known framework with lots of great extras and a really nice debugger (which now lets you add and save comments to the code you’re stepping through!)
2) You still get to learn everything about the system you’re emulating that you would have in the first place. There is no difference here.
3) Is a matter of opinion. MAME wouldn’t rule the world if people really wanted 3000 different emulators for all the things it runs though 🙂
4) MAME’s Z80 core is good enough to run wacky MSX rasterdemos, and it’s 6502 works in Atari 2600 games (which *are* rasterdemos). If you want to go lower-level, Juergen has working versions that operate at the original microcode level (e.g. each clock cycle does exactly what it really did) which we must push him to submit sometime 🙂
5) Timing is harder than byuu thinks – most emulators I’ve seen the source for do not have a timing system anywhere near as good as MAME’s (or his).
6) What flexibility? MAME has a great deal of it built-in already (on Windows there’s a maintained and functional GDI fallback so it can draw without DirectX – try that in Bsnes 😉
7) MAME32 and the Win32 MESS UI look plenty platform-leveraging to me. If you want to do something platform-specific at an emulation internals level instead of a GUI level you’re probably doing it wrong.

Nach also had some stuff I don’t want to take the space to address here, but reading the MAME FAQ will dispell many of them. On modern operating systems, larger binaries do not have larger memory footprints thanks to ‘demand paged loading’. You do have to not use e.g. UPX or other executable compressors though (MAME unfortunately ships with one unless you build it yourself). UPX also regularly annoys virus scanners because some virii are packed with it. Not our problem though. And the Linux stuff is because X11 bites as a gaming platform, although it’s much less dire than e.g. 5 years ago. SDLMAME alt-Enters with the greatest of ease on nearly any Linux system though, I should release it sometime 😉