Home Page Forums Archives MacMAME MacMAME 0.84 Xcode source leveraged

Question - when compiling the MacMAME source code, is there an #ifdef switch to use to tell it to use the C cores instead of the assembly cores? Or do I just have to remove the assembly core files from the build?

The start of each PPC assembly file contains a switch for that file. Take a look at, e.g., Asgard6502MAME.c.

Thanks! But when I try to compile the latest MAME sources, I get lots of errors with the CPU files. For example, src/cpu/adsp2100/2100ops.c fails with hundreds of parse errors and undeclared identifiers (some of which, like "ADSPCORE", I can't find declared anywhere). Are these CPU files not supposed to be included in the project at all? What determines whether a CPU file should be in the project or not?

Does this have anything to do with the Asgard files? I haven't quite figured those out yet - is Asgard one of the CPUs, or does it mean something else?

I assume this is with XCode?



If you're getting hundreds of errors, odds are that the first few errors are causing a cascading effect on the rest of the file.

That particular CPU core should be included, so if I were to guess, I'd say that one of the first errors you are seeing has to do with "ppc". It's a reserved word in OSX's gcc compiler, so you have to do some magic to get those files to work. I use a file called "mach_fixup.h" in the CodeWarrior build and include it globally for each file. I assume the XCode project has something similar going for it. if not, I'd just do a search/replace in that CPU core, changing ppc to _ppc.

Simple answer - if it's in the makefile for the Win32 build. Amost-as-simple answer - if a MAME driver references it. The "easy" way to check for the latter is to add all the new driver files for a MAME build, compile and then see what linker errors you get at the end. This assumes you've got lots time to kill and are really lazy.

I usually don't have lots of time, so I compare "mame.mak" with MacMAME.h and add/change any CPU cores and sound cores as appropriate for each new build.

Which source would that be, then?

Rename it to something like ppcstate & submit a diff. There was a similar issue with mips to compile on SGI machines.

smf

BTW, if someone has a fairly recent (0.84u3 I think is sufficient) MAME building on the Mac, please try this change which I think will make the System 12 games run again:

in src/drivers/namcos12.c, line 85 or so (function sharedram_sub_w), change

COMBINE_DATA( &shared16[ offset ] ); to COMBINE_DATA( &shared16[ offset^1 ] );

Then a few lines down in sharedram_sub_r, change

return shared16[ offset ]; to
return shared16[ offset^1 ];

Let me know if it works and I'll submit a proper version for mainline MAME.

-RB

I have a working build of xmame 0.86 for OS X using X11 as the display (yeah, sounds complicated, but it runs rather well, if not fast).

I made sure to first try some Namco12 games without your modifications. I get the following error as soon as the game tries to start:

H8/3002: Unknown opcode (PC=142)

After having made both modifications, I still get the same error.

Hope this helps.

Ow. That's more serious then. Thanks for the message though.

You're welcome.

I'm so glad I could help in a little, tiny, minuscule way to my favourite program (for 8 years now).