Home Page Forums Archives MacMAME MacMAME 0.84 Xcode source leveraged

Maybe this will be obsoleted soon by an official build from Brad Oliver, but I'm guessing that he'll be busy porting a certain other acronym for a while.

So I spent about a day on it and leveraged the Xcode build of MacMAME to 0.84. This is the first time I've leveraged MAME, and a lot of things have changed in the core since 0.77u2, so it's possible I broke stuff. For coding reference, these are roughly the steps I took:

* Start with mame084s.zip tree. Add Xcode projects and "override" from MacMAME 0.77u2c.

* Diff makefile, add commented-out HAS_* defines for new CPUs to MacMAME.h. Since I'm not sure which ones are actually used, uncomment them as needed by cpu/sound cores, after failed compilation. I end up with:

ghostwheel:~ arekkusu$ diff ~/Projects/MacMAME077u2c/override/macintosh/MacMAME.h ~/Projects/MacMAME084/override/macintosh/MacMAME.h
289a290
> //#define HAS_I386 1
311a313
> //#define HAS_M6809E 1
313a316
> //#define HAS_M68008 1
326a330,331
> //#define HAS_TMS99000 1
> //#define HAS_TI990_10 1
331a337
> //#define HAS_TMS32026 1
335a342
> #define HAS_ADSP2104 1
337a345
> //#define HAS_ADSP2181 1
345a354
> //#define HAS_R4700 1
346a356
> //#define HAS_QED5271 1
356a367
> //#define HAS_I960 1
369a381
> #define HAS_CDDA 1
372a385
> #define HAS_DMADAC 1
395a409,413
> #define HAS_NAMCO_15XX 1
> #define HAS_NAMCO_CUS30 1
> #define HAS_NAMCO_52XX 1
> #define HAS_NAMCO_54XX 1
> #define HAS_NAMCO_63701X 1
430a449,452
> #define HAS_PSXSPU 1
> #define HAS_YMF271 1
> #define HAS_ICS2115 1
> #define HAS_ST0016 1

* build the m68k opcode generator and run it:

ghostwheel:~/Projects/MacMAME084/src/cpu/m68000 arekkusu$ gcc -Os -s m68kmake.c -o m68kmake; ./m68kmake

* For each project [drivers machine sndhrdw vidhrdw MacMAME]:
* * diff relevant part of tree.
* * remove all deleted files in tree from project.
* * add all new files in tree to project.
* * add src/includes to include path.
* * compile and fix any compilation errors/warnings caused by core changes...

* Despite fixing the include path, two changes to core files were needed to get them to build properly:

ghostwheel:~ arekkusu$ diff ~/Projects/MacMAME084_org/src/drivers/cojag.c ~/Projects/MacMAME084/src/drivers/cojag.c
61c61
< #include "jaguar.h"
---
> #include "includes/jaguar.h"

ghostwheel:~ arekkusu$ diff ~/Projects/MacMAME084_org/src/machine/williams.c ~/Projects/MacMAME084/src/machine/williams.c
17c17
< #include "williams.h"
---
> #include "includes/williams.h"

* This change was leveraged from 0.77u2c to fix c99 compilation: (NOTE there are a few other instances of MAC_PORT which I did not leverage; seems to compile OK without them. Brad would have to confirm)

ghostwheel:~ arekkusu$ diff ~/Projects/MacMAME084_org/src/machine/stvcd.h ~/Projects/MacMAME084/src/machine/stvcd.h
0a1,7
> #if TARGET_RT_MAC_CFM &#0124;&#0124; TARGET_RT_MAC_MACHO // MAC_PORT
> #undef true
> #undef false
> #define true stv_true
> #define false stv_false
> #endif
>

* This #ifndef was wrong in the core; I fixed it to avoid some redefine warnings:

ghostwheel:~ arekkusu$ diff ~/Projects/MacMAME084_org/src/sha1.h ~/Projects/MacMAME084/src/sha1.h
29c29
< #ifndef _STDINT_H
---
> #ifndef _STDINT_H_

* Due to core reworking (get_info and encryption) two CPU cores had incompatibilities with the Mac Asgard asm wrappers: the m6809 and the m68000. For the m6809 I just disabled the Asgard wrapper and added the C core to the project directly. (The Asgard stuff will need to be updated for CodeWarrior, but in Xcode the assembly doesn't work anyway, so no big loss.) The 68k I was able to fix by hacking a core file to work with the funny Asgard redefine scheme:

ghostwheel:~ arekkusu$ diff ~/Projects/MacMAME084_org/src/cpu/m68000/m68kmame.c ~/Projects/MacMAME084/src/cpu/m68000/m68kmame.c
13c13
<
---
> #ifndef A68K0
18a19
> #endif

* Core changes in 0.78u2 and 0.84 required two changes to macinfo.c:

ghostwheel:~ arekkusu$ diff ~Projects/MacMAME077u2c/override/macintosh/macinfo.c ~/Projects/MacMAME084/override/macintosh/macinfo.c
1953a1954,1956
> // as of MAME 0.78u2, we must manually init the cpuintrf[] array
> cpuintrf_init();
>
2065a2069
>
2067c2071,2074
< const struct InputPortTiny *in;
---
> const struct InputPort* in;
> begin_resource_tracking();
> in = input_port_allocate(inGame->construct_ipt);
>
2071,2072d2077
< in = inGame->input_ports;
<
2111a2117
> end_resource_tracking();

* Core changes in 0.77u3 and later require a new osd function:

ghostwheel:~ arekkusu$ diff ~/Projects/MacMAME077u2c/override/macintosh/mac.c ~/Projects/MacMAME084/override/macintosh/mac.c
978a979,995
> //============================================================
> // osd_die
> //============================================================
>
> void CLIB_DECL osd_die(const char *text,...)
> {
> va_list arg;
>
> /* standard vfprintf stuff here */
> va_start(arg, text);
> logerror(text, arg);
> vprintf(text, arg);
> va_end(arg);
>
> exit(-1);
> }
>

* Finally, I updated the Info.plist version to "0.84 unofficial".

The resulting Deployment binary is 37.8 megs, considerably bigger than 0.77u2c's 23.3 megs. I'm not sure if that's all due to new drivers, but I'll look into dead-code stripping later.

I tried out a couple old ROMs which all seem to work OK, including 6809 and 68000/68020 games. The CPU usage is pretty high on some like Joust 2 due to the C cores. Other games like Ms Pac Man take about 15% of my CPU (15" AlBook) and a lot of that is the blit.

The only relatively new ROM I have to test is Strider Hiryu 2, and it does not work. So I think the PSX core may still be busted on Mac. Somebody please fix it!

Problems that existed in 0.77u2a still exist-- for example, crashing in System16 when opening Major League, or the horizontally-squished NeoGeo games. But at least it is up-to-date now.

Source is on my iDisk.

Note: this is totally unofficial. If your favorite ROM doesn't work, tough. If you don't know how to use a compiler, double tough. I won't be posting a binary for end-users.

I hope you don't mind me bothering with this, but I have several issues.

First, I had to add znsec.c to the machine project, as the path to it somehow was mangled.

After that I got one error (undefined symbols: _dasm6309). It looked like 6309dasm.c was missing, too, so I added. Now I'm getting thousands of linker errors (relocation overflow for relocation entry...).

Any idea what I'm doing wrong?

Thanks for any suggestion and thanks a lot for providing us this update.

I'm looking into a fix for the linker problems in the Debug style (detailed explanation of this error here .) You should be able to build the Deployment or Profile styles OK. You can debug (if somewhat clumsily) with the Profile style.

Just curious, why do the diff/remove/add cycle? Why not just remove all the files from the project then add all the ones in the current MAME source? That way you wouldn't have to bother to figure out what files are different.

And, I forget, what's the purpose of having subprojects, rather than just putting all the files into a single project? It seems like there's some duplication between subprojects - files common to more than one of them - so wouldn't combining them into one project simplify matters?

Among the 4 main subprojects, there are many files with the same name and different content that also reference header files with the same name. This tends to result in chaos.

What files are duplicated among subprojects? It's heavily based on the CW project layout, and there is literally no duplication there in subprojects.

Arekkusu,

Some feedback on your "Vector persistence" slider:

On my machine it slows down vector games to a crawl unless I keep the slider very close to the left.

Neat idea though!

G4 Dual-450 + Radeon 9000 pro AGP

I noticed something strange with this unofficial build:

"Hardware Info" for alien3 shows:
Analog controls:
Light Gun (Player 1)
Light Gun (Player 1)

In 0.77 it shows:
Analog controls:
Light Gun (Player 1)
Light Gun (Player 2)

(The game does use 2 light guns AFAIK)

Maybe macinfo.c needs to be updated, or is this just a recent (>0.77) bug in driver/system32.c?

Carbon:
It looks like the new drivers in 0.84 have pushed the Debug binary size over the linker's limit. I've tried several combinations of flags now and it looks like the easiest thing to do is just turn on basic optimization with -O1. Yeah, this makes stepping though code line by line a pain, but it does shrink the binary size small enough for the linker to work again (resulting app is in the 68-80 meg range!)

However there's another problem which I haven't figured out yet; with MAME_DEBUG = 1 the disassembly window is not appearing, it just falls back to the ROM list without running the game. I get a pile of warnings like:

9ballsh3 cpu #1 uses wrong data width memory handlers! (width = 8, memory = 00040005)

I've also had it crash in validitychecks + 0x578 (mame.c:1933).

It looks like there have been several changes to the MAME debugger in 0.79 through 0.82u2, the mac side probably needs some updates to support it. I'm not sure where, though.

The .dmg on my iDisk was updated yesterday to fix the znsec.c absolute path, but as it stands, the Debug style is not useable for debugging with the MAME disassembler. You can use the Profile style if all you need to do is break in Mac code.


Brian:
I leveraged that way for two reasons:
1) There are any number of source files which are NOT directly included in the MacMAME project. The windows/ directory, of course, but also several CPU cores which have Mac-specific Asgard wrappers. So, working from the known-good 0.77u2c and making only add/remove changes was safer than rebuilding the whole project.
2) I kept the subprojects because the official build is going to be in Codewarrior for the foreseeable future, and if I do ever need to rebuild the Xcode projects from scratch it is easiest to start by importing from CW. Also as Brad says, there are a lot of source files with identical names in different directories. There should be no code duplication between projects, as that will cause duplicate symbol linker errors. But there are of course duplicate header includes such as the shared .pch.


Carsten:
Vector games are slow, period, because they run at native res and spend way too much time copying and converting the bitmap from the core to the Mac GWorld to the GPU. The phosphor stuff doubles the GPU fillrate requirements by turning on blending (at any setting other than with the slider ALL the way to the left.) A Radeon 9000 still ought to be able to handle it easily, unless maybe you're running at 1920x1200 or something. Using a smaller display res will help in any case since the load is still almost entirely on the CPU. Using the GPU to draw the vectors solves the speed problem completely, but it breaks the artwork.

For the analog input info, yes macinfo.c probably needs to be updated. I just did the bare minimum to get it to build.

Oh, also; while new games like Tekken 3 run, they don't switch resolution properly. It is similar to the problems in some of the Neo-Geo games, where the playfield is squished into half of the space horizontally while the score overlay is drawn correctly. Carsten pointed out that Dancing Eyes shows the same sort of problem with vertical squishing in 0.77u2a. I don't think this problem happens on the PC? So where should I be looking to fix this? It happens in both software and GL renderers, so it's something in the vidhdwr layer? Brad seemed to know what the issue was with NeoGeo, want to help me out?

Also it looks like anything with the PSX SPU hangs. Maybe smf has an idea?

Thanks for your thoughts on this. Since I've been studying/hacking around on the report generation stuff lately, I might as well see what I can do to find out what's changed in the core since 0.77 that broke this on the Mac.