I’m currently taking a short break from “heavier” things and doing something I meant to do years ago (but MAME wasn’t capable of supporting it at the time) – emulating the Konami programmable amplifier chip. It’s actually a big ceramic thing that’s sadly rather fragile and it’s found in games from Xexex pretty much onward. This will make the test menu volume control work in a whole bunch of games, and also effectively make the sound emulation “perfect” in them.

After that it’s back to disassembling Mach Breakers (it’s written in C and uses a pseudo-multitasking system internally so it’s a real pain to figure out the flow of control) and prepping the next SDLMAME test release. That would be done by now except I’m stubbornly insisting on making it work on MinGW first 🙂

Spent most of the day pulling apart the music player in the Namco NA-1 (C69) BIOS looking for exploits we can use to trojan the C70. Unfortunately, unlike the later players, there isn’t a wide open opcode that’ll do it for us, but I still have many other ideas.

Also stopped to fix two minor things: the V60/V70 core works again when compiled with GCC 4.0 or later, and Polygonet Commanders now passes POST again and now hits unimplemented opcodes in the 56156 DSP. Over to you, Andrew.

Look for a new SDLMAME test release based on 0.106u5 soonish. In addition to the updated games and such we’ve fixed logging (both to a file and to the terminal) and eliminated the NASM requirement. There’s also improved Mac support (you can compile and link on G4 and G5 Macs now, but only sound works) and hopefully improved MinGW support too.

SDLMAME had a problem on some systems when exiting the app while in full-screen mode. Updated full source is posted below, and this single source file fixes it for folks who already downloaded 1A. There are no other changes between Test 1A and Test 1B.

What is SDLMAME? It’s a port of the base Windows command-line version, simply replacing DirectX with SDL. As a result it retains all of the assembly optimizations, features, and command-line switches from that version. Plus it’s very lean and very fast compared to other ports of MAME, and you don’t have to relearn anything if you’re familiar with the Windows version. Joypads and other controllers are fully supported the same way as in Windows MAME, and Alt-Enter even toggles windowed and full-screen modes.

WARNING: SDLMAME is not intended for unskilled end-users in it’s current form (with a nice front end and suitable binary packaging, that could be very different of course). Of course, if you’ve compiled MAME or XMAME before and been able to use them directly from the command line, then you can handle SDLMAME no problem.

Here’s the source for SDLMAME 0.106u1 Test 1B (this version is obsolete!). This is based on MAME 0.106u1 with the asmtile removal from u3 backported so it runs properly on CPUs with execute-disable. A canned Mac OS X binary will appear when there’s a front end for it (and once I’ve figured out how Apple’s packaging stuff works).

Build instructions: on Linux, make sure you have SDL, it’s development packages, and nasm installed via apt-get, yum, emerge, or whatever your distro of choice uses. On Fedora 4 or 5, “yum install SDL SDL-devel nasm” will get you going assuming you already have GCC. If you already can compile XMAME/XMESS with the SDL target you’re good to go. Just edit the makefile, change the options as necessary, and type “make” (or “make -j2” on hyperthreaded/dual core systems).

On Intel MacOSX, you’ll need Xcode 2.3 (a free download from developer.apple.com) and SDL 1.2.10. Get SDL here. It will open into a disk image. Click “Macintosh HD” or whatever your disk is named in the left pane of a Finder window, then open the Library folder and drag the SDL.framework folder from the SDL disk image into the “Frameworks” folder. Unzip the SDLMAME source and edit the makefile with your favorite editor (even good old emacs). Change the “SUBARCH=linux” line to “SUBARCH=macosx” (lowercase is important). All of the other defaults are fine for a Mac (in particular, optimizing for the Pentium M series) so save and type “make”. “make -j2” is a good deal faster if your Mac has a Core Duo instead of a Core Solo.

Again, front ends are needed for both versions, and we’ll cough up a more appropriate home page later. If you work on front ends built on cross-platform technology (e.g. C#, Tcl/Tk, Perl, or whatever) here’s your big chance: you can target MAME/W on Win32 and SDLMAME on Linux and MacOSX. (I expect it’ll be trivial to compile SDLMAME on Open/Free/NetBSD and possibly even BeOS as well).

UPDATE: I should note that the default .ini path on Linux is $HOME/.mame/, then the current directory, then ini/. On the Mac, it’s the current directory, then ini/. The -inipath switch overrides it in both cases.

For now, for questions, we might as well use the M1 forum.

GCC versions from 3.2 to 4.1.1 should work, with varying amounts of warnings. We don’t guarantee it compiles free of warnings on any compiler.

PS: SDLMAME is brought to you by Olivier Galibert and R. Belmont. Olivier had the idea and did most of the initial port, while RB did the audio, input/controller, execute-disable, and MacOSX support.

Coming soon (and I don’t know when soon is): the “new debugger”, using GTK+, and the “new renderer”, using OpenGL (which will eliminate the issue of SDLMAME’s lack of hardware scaling) (it’s now fully implemented).