Home Page Forums Archives MacMAME MacMAME 0.84 Xcode source leveraged

Arek: Thanks for testing! Ok, *now* try my first suggestion with adding the two ^1s (in sharedram_sub_w and sharedram_sub_r) and see if that gets it going.

Heh. Yes, with both patches namco12 games are working, the JAMMA screen is gone in a flash. Hooray!

The addition of sound drops the fps on my laptop from the 30s to the 20s, but such is life without dynarec...

Now, any similar fix for the ZN games?

I'm happy to report that by applying both fixes, xmame 0.86 for OS X now works for namco12 games too.

Sweet :-)

The ZN games are a harder nut to crack, but at least we know the basic PSX emulation is in good shape. If I think of something, I'll certainly post it.

My first question is - what makes you think it's not defined anywhere? ;-)

It's actually defined in osd_cpu.h (which is in either windows/osd_cpu.h or overrides/macintosh/osd_cpu.h). Since you're totally starting from scratch, you're going to have to create that yourself rather than use the existing Mac (or Win32) ones.

My suggestion would be to get used to searching the entire source tree from the PC or Mac version, including the "windows" directory. If you do, you'll find this and other upcoming headaches a little quicker.

If you have CodeWarrior, you can open the existing Mac project to get a dependency listing for files that compile, so you can see that adsp2100.c includes cpuintrf.h which includes osd_cpu.h. I'm actually surprised you didn't get a warning about that header being missing before the error you got.

Look again - in the archive, in the folder mame086s, right at the root, there's a file called "Makefile". Hidden in plain sight, as it were. ;-)

Sorry, I wasn't precise - by "INT32 isn't defined anywhere" I meant "it's not defined in 2100ops.c itself, and that file has no #includes." Yes, it's defined elsewhere, but how's that file supposed to know about it?

The answer appears to be that 2100ops.c is #included by adsp2100.c, which contains the necessary definitions, so therefore 2100ops.c does not appear to be intended for someone to compile by itself. It appears that this is the case for other files in the distribution as well, and I'm working on figuring out which ones they are.

Thanks for pointing me to the Makefile - when I downloaded MAME 0.86, I kept the 'src' directory and deleted all else, and I hadn't realized that the Makefile lived outside that directory. My fault!

The Windows makefile is made up of makefile & src\*.mak

Although 2100ops.c is mentioned in the makefile:

$(OBJ)/cpu/adsp2100/adsp2100.o: adsp2100.c adsp2100.h 2100ops.c

that is only a dependancy ( i.e. rebuild adsp2100.o if adsp2100.c, adsp2100.h or 2100ops.c change ).

This line:

CPUOBJS += $(OBJ)/cpu/adsp2100/adsp2100.o

shows that only adsp2100.o will be built, and as far as the compiler is concerned it just has to compile adsp2100.c to do it ( the fact it #includes other .c files is irrelevant ).

If this is the first time you've ever seen it then you might get a suprise once you've fixed it as there are loads of places in mame where this is done ( going back years ).

smf

It's in the same sort of shape on the mac as windows, I wouldn't describe it as a good shape.

smf