Home Page
Posted By: arekkusu MacMAME 0.84 Xcode source leveraged - 07/04/04 05:16 PM
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! smile

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.
Posted By: Carbon Re: MacMAME 0.84 Xcode source leveraged - 07/05/04 03:29 PM
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.
Posted By: arekkusu Re: MacMAME 0.84 Xcode source leveraged - 07/05/04 05:01 PM
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.
Posted By: Brian Kendig Re: MacMAME 0.84 Xcode source leveraged - 07/05/04 07:01 PM
Quote:
Originally posted by arekkusu:
* 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.
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?
Posted By: Brad Oliver Re: MacMAME 0.84 Xcode source leveraged - 07/06/04 05:14 AM
Quote:
Originally posted by Brian Kendig:
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. wink

What files are duplicated among subprojects? It's heavily based on the CW project layout, and there is literally no duplication there in subprojects.
Posted By: Carsten Re: MacMAME 0.84 Xcode source leveraged - 07/06/04 06:22 AM
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
Posted By: Carsten Re: MacMAME 0.84 Xcode source leveraged - 07/06/04 08:02 AM
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?
Posted By: arekkusu Re: MacMAME 0.84 Xcode source leveraged - 07/06/04 10:10 AM
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. frown

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.
Posted By: arekkusu Re: MacMAME 0.84 Xcode source leveraged - 07/06/04 10:18 AM
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? wink
Posted By: Carsten Re: MacMAME 0.84 Xcode source leveraged - 07/06/04 10:20 AM
Quote:
Originally posted by arekkusu:
For the analog input info, yes macinfo.c probably needs to be updated. I just did the bare minimum to get it to build.
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.
Posted By: Carsten Re: MacMAME 0.84 Xcode source leveraged - 07/06/04 10:28 AM
I'm seeing "Out of malloc tracking slots!" errors in stdout when I run my custom tab-delimited reports. It's okay, I just do test runs by launching MM from the Finder instead of from within XCode.

I'm using the deployment build so I'm not so sure this is related to any of the debug build problems you talked about, but just thought I'd mention it.
Posted By: Brad Oliver Re: MacMAME 0.84 Xcode source leveraged - 07/06/04 12:29 PM
Quote:
Originally posted by arekkusu:
Brad seemed to know what the issue was with NeoGeo, want to help me out?
Yes, easy - the Mac port should no longer dictate the bit depth and instead let the MAME core tell the osd code what depth to use. There's some old code in the MAME core that will attempt to use a bit depth specified by the osd layer, but the drivers are no longer required to conform to that, so you get a case like with the NeoGeo drivers where they assume a forced bit depth.
Posted By: Brad Oliver Re: MacMAME 0.84 Xcode source leveraged - 07/06/04 01:45 PM
Quote:
Originally posted by Carsten:
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.
The entire input port handling scheme has changed in recent MacMAME builds, so there's some Mac-specific work to make this kosher again. It's not terribly difficult. The core is still seeing some minor changes in this area as well as the code settles down, so keep that in mind.
Posted By: Carsten Re: MacMAME 0.84 Xcode source leveraged - 07/06/04 07:31 PM
Yes! I got it working. I'll post updated source on my website later today.

While I'm here, I was thinking of showing other info in the Info pane too besides just analog controls. Like "Tilt-ability" and maybe number of buttons. Good idea or no?
Posted By: R. Belmont Re: MacMAME 0.84 Xcode source leveraged - 07/06/04 07:51 PM
Quote:
Originally posted by arekkusu:
Also it looks like anything with the PSX SPU hangs. Maybe smf has an idea? wink
Try something from konamigv.c - if you don't have the CHDs currently, weddingr is the smallest (only 14 megs), and it also makes the heaviest use of the SPU (no redbook audio for music like the other games). That would let us rule out the SPU as opposed to the znsec, which I suspect is the real enemy.
Posted By: Carsten Re: MacMAME 0.84 Xcode source leveraged - 07/06/04 11:49 PM
http://ca.geocities.com/carstenklapp/macmame/override/macintosh/

This macinfo.c is preliminary, it still needs some work to clean up the formatting.

Added reporting for:
  • joy4way, joy8way, doublejoy4way, doublejoy8way (per player)
  • Buttons (per player)
  • Start buttons
  • Tilt detector
  • Unknown controls
  • Coin slots
  • Dip-switches
  • Service switch
Posted By: Brad Oliver Re: MacMAME 0.84 Xcode source leveraged - 07/07/04 01:24 AM
Quote:
Originally posted by Carsten:
[b]
]http://ca.geocities.com/carstenklapp/macmame/override/macintosh/[/QB][/QUOTE]

If you'd like something included in MacMAME, please e-mail me a copy of the code in question until I get the Subversion server set up. That will help me out a great deal, because it means I don't have to surf around this forum looking for patches. smile
Posted By: Carsten Re: MacMAME 0.84 Xcode source leveraged - 07/07/04 01:28 AM
Ok thanks Brad, will do.

For now these are not quite finished yet, they are just on my web site for anyone who wants to see what I'm working on.

Oh BTW, I think the existing code is using tabs instead of spaces? (width 4, indent 4?) I want to make sure any code I send you is formatted consistently.
Posted By: arekkusu Re: MacMAME 0.84 Xcode source leveraged - 07/07/04 05:07 AM
Quote:
Originally posted by R. Belmont:
Try something from konamigv.c ... That would let us rule out the SPU as opposed to the znsec, which I suspect is the real enemy.
You're right-- weddingr runs fine, with sound.
Posted By: Carsten Re: MacMAME 0.84 Xcode source leveraged - 07/07/04 05:09 AM
The new updated & "enhanced" macinfo is finished for anyone who wants it, available at my website (and emailed off to Brad.)
Posted By: smf Re: MacMAME 0.84 Xcode source leveraged - 07/07/04 05:20 AM
Quote:
Originally posted by arekkusu:
Quote:
Originally posted by R. Belmont:
Try something from konamigv.c ... That would let us rule out the SPU as opposed to the znsec, which I suspect is the real enemy.
You're right-- weddingr runs fine, with sound.
There is a known ( intermitent ) issue with at least bloody roar 2 which causes a lockup when booting, it seems to happen if frame skipping is active. It might be that is causing you more issues than it does under windows. Knock out all the calls to set_visible_area in vidhrdw/psx.c and see if any of the zn.c games boot.

smf
Posted By: arekkusu Re: MacMAME 0.84 Xcode source leveraged - 07/07/04 08:33 AM
Nope, Strider 2/Brave Blade/Ray Storm all still lock up, with set_visible_area commented out and fskp0. (Working PSX games like Dancing Eyes, Wedding Rhapsody, Tekken are running at 25-40 fps ingame, really wish there was a ppc_drc... )

I had actually just started to look at set_visible_area, since that seems like half of the resolution switch problem. The mac video plugins (well, the GL one anyway) should probably disable window size changes when the visible area changes, and just stretch the bitmap to fill the initial (largest?) size.
The other half is somewhere else, it is still squishing the bitmap. Not sure where yet.
Posted By: R. Belmont Re: MacMAME 0.84 Xcode source leveraged - 07/07/04 08:37 AM
Squishing the bitmap means the driver and your OSD code are disagreeing on the bit depth probably.

And disabling size changes and stretching to initial is what the Win32 version does. That's why the initial size is so large even though only 1 game (doapp) actually uses a mode that large for more than a splash screen.
Posted By: arekkusu Re: MacMAME 0.84 Xcode source leveraged - 07/07/04 09:11 AM
NeoGeo and Virtua Fighter Kids look like bpp issues. But I think this is something else, since Tekken for example is squished to 512x240 in a 640x480 window wink
Posted By: smf Re: MacMAME 0.84 Xcode source leveraged - 07/07/04 01:26 PM
Quote:
Originally posted by arekkusu:
NeoGeo and Virtua Fighter Kids look like bpp issues. But I think this is something else, since Tekken for example is squished to 512x240 in a 640x480 window wink
A 640x480 window is the intended behaviour. You then need to make it stretch the 512x240 image to 640x480. Thats easy for the height ( in theory you only need to space the lines out as you'll then get scanlines ), the width is trickier and would require something like OpenGL to stretch the image.

smf
Posted By: Hack7 Re: MacMAME 0.84 Xcode source leveraged - 07/08/04 11:28 AM
Quote:
Originally posted by smf:
A 640x480 window is the intended behaviour. You then need to make it stretch the 512x240 image to 640x480. Thats easy for the height ( in theory you only need to space the lines out as you'll then get scanlines ), the width is trickier and would require something like OpenGL to stretch the image.

smf
Been doing some experimenting along these lines. Maybe someone will find this helpful.

If I take out all the AdjustWindowSize() calls except for the one in UpdateBitmap(), the window remains the correct size, although the "squishing" still occurs.

If I force the offsets in ComputeSourceandDest to be the same as the window (in software.c using software rendering) and turn off fast blitting, everything looks *almost* like it is supposed to. There are two asterisks in the lower left corner, but CopyBits obviously stretches the bitmap to fit. Of course, it's slow as molasses, and it really posses off OpenGL.

CopyBit is not a workable solution. Has anyone tried to use the open source DDX -> OpenGL front end and the windows DDX video/winddraw files? Seems like that would be a quicker fix, at least temporarily, over rewriting macvideo, software and/or the OpenGL plugins, since someone has already written the DDX code. It's at http://sourceforge.net/projects/dxglwrap .

Cheers,
Hack7 :shadow:
Posted By: Carsten Re: MacMAME 0.84 Xcode source leveraged - 07/09/04 05:45 AM
About the assembly cores:

What needs to be done to get these to compile in XCode? Will Tiger's Xcode & gcc address this?

It it just changing asm to __asm__, and __inline__ instead of inline for gcc etc?

I'm way in over my head when it comes to assembly, but if it's just a tedious "monkey job" like searching and replacing keywords I'm willing to spend the time doing this sort of thing:

#ifdef __GNUC__
__asm__ ...
#else
asm ...
#endif

I'd just need a couple examples to get me started.

ck
Posted By: Hack7 Re: MacMAME 0.84 Xcode source leveraged - 07/09/04 11:11 AM
Quote:
Originally posted by Carsten:
About the assembly cores:

What needs to be done to get these to compile in XCode? Will Tiger's Xcode & gcc address this?

It it just changing asm to __asm__, and __inline__ instead of inline for gcc etc?

I'm way in over my head when it comes to assembly, but if it's just a tedious "monkey job" like searching and replacing keywords I'm willing to spend the time doing this sort of thing:

#ifdef __GNUC__
__asm__ ...
#else
asm ...
#endif

I'd just need a couple examples to get me started.

ck
They'll have to be converted. While XCode supports CodeWarrior style inline assembly, you can't access global variables from within the routines. I suppose you could mix gcc style assembly and CodeWarrior inline assembly to access globals, such as:

//Begin CodeWarrior assembly
__asm__ {
mflr r0
stmw r15,-76(sp)
stw r0,8(sp)
stwu sp,-128(sp)
}
//GCC assembly
__asm__ (" lis r4,hi16(GLOBAL_VAR)\n\t ori r4,r4,lo16(GLOBAL_VAR)": : ) ;

//Back to CodeWarrior
__asm__ { ...

But honestly I have never tested this myself. Maybe someone else has? I suppose any assembly routines which just use passed parameters and no globals could be converted by placing the __asm__ {} around them, but most of the ones I looked at access global vars. What a pain...

MacBlitters.S and MacBlitters.c are good comparisons for insight into assembly conversion IMHO.

Hack7 :shadow:
Posted By: Carsten Re: MacMAME 0.84 Xcode source leveraged - 07/09/04 11:40 PM
(On second thought... looks way too complicated for me. frown )
Posted By: Carsten Re: MacMAME 0.84 Xcode source leveraged - 07/10/04 08:15 PM
tabreport.patch.gz (patches: macstrings.h, macreports.h, macreports.c. Requires a RSRC patch to reportopt.rsrc and mamelang.rsrc).

This is finished. Adds a new report called "Game Properties (Tab-delimited)", which outputs a table of the following properties
for all ROMs:

Name, Descriptive name, Manufacturer, Year, Video type, Stereo, Video orientation, Width, Height, Colors, Video refresh Hz, Parent, BIOS, Source file, Sound status, Color status, Samples, Multiple monitor, Pixel aspect, Not working, Parent or clone, Analog controls, Digital controls, Other inputs, Coinslots & Switches

Patch available at my web site (already emailled to Brad).

Carsten
Posted By: Carsten Re: MacMAME 0.84 Xcode source leveraged - 07/11/04 04:59 AM
BTW, what are the requirements for XCode's Zero-link? I remember seeing a page at the Apple Developer web site but now that I'm interested in it, I can't find it again.

The "Upgrade to Native target" menu command is greyed out. Is it only for Cocoa or can Carbon use it too?

The linking phase of MacMAME is the most time-consuming part of my little report & info contributions.

Thanks
Posted By: Fava Re: MacMAME 0.84 Xcode source leveraged - 07/13/04 03:28 PM
I've just compiled the Deployment without any add but the app start and quit automatically...i've try to delete preference but nothing. Any ideas?
Posted By: bumpy Re: MacMAME 0.84 Xcode source leveraged - 07/13/04 03:55 PM
I imagine I know the answer to this already, but what the hell...

Is this something that us non-programmer types could compile ourselves? Isnt x-code one of the things that came on that OSX developer tools disk that I never use?

Also, how are the video improvements arekkusu made working out? Any impressions? Did v-sync ever get off the ground?

Finally, for those that have been able to toy around w/ the Capcom ZN-1, the Namco System 1 and 2 and the Sega Model 1 and 2 games - what is a realistic system spec to run these games at 60 fps? Does the required mac even exist yet? At some point down the road I'd like to include some of the aforementioned games in my MacMAME cabinet (eta: whenever I can scrape the cash together).
Posted By: will Re: MacMAME 0.84 Xcode source leveraged - 07/14/04 12:35 AM
Quote:
Originally posted by bumpy:
Isnt x-code one of the things that came on that OSX developer tools disk that I never use?
Yes XCode comes with Panther on the developer tools CD but it cannot yet take advantage of the faster PPC native assembly cores which means this build (if you can even get it to compile) will run with the much slower C cores. Since you're asking about speed, it doesn't seems like something you'd be interested in.

Quote:
Finally, for those that have been able to toy around w/ the Capcom ZN-1, the Namco System 1 and 2 and the Sega Model 1 and 2 games - what is a realistic system spec to run these games at 60 fps? Does the required mac even exist yet?
OK I think you meant Namco System 11, 12, 21 & 22, Namco System 1 & 2 are not that demanding.

Also I think the first Sega Model 1 game has just started to work with MAME 0.84u1, Virtua Fighter 1. There are no Sega Model 2 games in MAME yet, don't ask don't tell. wink

To answer your question, no the required Mac probably doesn't even exist yet, I have yet to try a G5 but the problem is that most of these PSX hardware based games do not run in MacMAME yet, not just because we are behind several versions but according to the MAME WIP page, the authors of these drivers have just started to fix the endian bugs in their code which would allow these games to work on a PPC processor in the first place.
Posted By: arekkusu Re: MacMAME 0.84 Xcode source leveraged - 07/14/04 02:16 AM
Carsten:
The ZeroLink docs are still here. It doesn't work with MacMAME in any version of Xcode that I've tried.

The Xcode "Upgrade to Native Target" converts old PB jam-based targets to the new system that supports ZeroLink/Fix&Continue. It doesn't have anything to do with Carbon vs Cocoa. MacMAME is already using a native target.


Fava:
First thing I'd try is building the Profile build (basically the same as the Deployment build, except with debug symbols) and run that. If it quits, look in Console and ~/Library/Logs/CrashReporter/MacMAME.crash.log to see if there's any explanation.


bumpy:
v-sync works fine in 0.77u2c and 0.84 for me. The other video improvements (as described in the xcode note) are: fixed dark border around GL window, correct aspect scaling of multimonitor games in fullscreen mode, and a phosphor persistence slider.

The other important improvement in the Xcode build over the official 0.77u2a is that it yields time to other apps correctly, so Ms Pac Man takes 10% of the CPU instead of 100%, and your fan(s) don't come on.

The big tradeoff is that it uses the C cores, so if your Mac was too slow, or barely fast enough to run a game fullspeed before, it will be slower now.

For the newer games, Tekken (System 11) runs at a pretty solid 30fps on my 1.25GHz laptop, so a new G5 ought to be full speed. This is without sound, though. On the other hand, Virtua Fighter Kids (Sega Titan) runs at about 8 fps. frown
Posted By: R. Belmont Re: MacMAME 0.84 Xcode source leveraged - 07/14/04 02:34 AM
Actually, the base PSX hardware works well on the Mac as of 0.84. There's some additional complication with zn.c we haven't worked out yet though.

Edit: if anyone has the port up to 0.84u2 level on the Mac, I'd love to hear if the updated System 12 driver is working properly. It should be, but you never know with this stuff =)
Posted By: Hack7 Re: MacMAME 0.84 Xcode source leveraged - 07/19/04 11:10 AM
Hello all,

I've managed to convert and compile some of the Asgard assembly routines under XCode. Konami seems to work fine. In the 68000 family, Gauntlet runs, Arabian Nights gives an error on power up ROM check (1111 Emulate, and then some sort of ROM address, if anyone has any suggestions...).

If anyone is interested in the code, let me know.

Hack7
Posted By: arekkusu Re: MacMAME 0.84 Xcode source leveraged - 07/19/04 02:18 PM
By "convert" you mean to GAS syntax, or reformatting to work around the multiple line problems?
Posted By: Brad Oliver Re: MacMAME 0.84 Xcode source leveraged - 07/20/04 04:56 AM
Quote:
Originally posted by Hack7:
If anyone is interested in the code, let me know.
I'm very interested. smile E-mail me : bradman@pobox.com.
Posted By: arekkusu Re: MacMAME 0.84 Xcode source leveraged - 07/25/04 01:00 PM
Quote:
Originally posted by R. Belmont:
if anyone has the port up to 0.84u2 level on the Mac, I'd love to hear if the updated System 12 driver is working properly. It should be, but you never know with this stuff =)
That's a negative. I patched to 0.84u3: Tekken works, Tekken3 dies with no crashlog or backtrace available. Not very useful info, but there it is.
Posted By: MAMEBase Re: MacMAME 0.84 Xcode source leveraged - 07/25/04 02:35 PM
Well, since we seem to be asking about games that may or may not be working in upcoming releases in this thread, I'd like to know if Mr Driller has been taken off the 'Not Working' list...
Posted By: Carsten Re: MacMAME 0.84 Xcode source leveraged - 07/26/04 12:33 AM
Quote:
Originally posted by MAMEBase:
I'd like to know if Mr Driller has been taken off the 'Not Working' list...
Yes Mr Driller is playable now, but no sound and the video is not 100%. Only runs at 3 fps on my dual 450.
Posted By: arekkusu Re: MacMAME 0.84 Xcode source leveraged - 07/26/04 03:45 AM
Mr Driller works in 0.84 (no sound, 25-30 fps on Powerbook here) but not in 0.84u3.
Posted By: bumpy Re: MacMAME 0.84 Xcode source leveraged - 07/27/04 08:13 PM
Is this anything that someone (arekkusu?) could post a pre-compiled version of?

Also, does Sexy Parodius still crash MacMAME after the "OK" screen?
Posted By: will Re: MacMAME 0.84 Xcode source leveraged - 07/28/04 11:46 AM
Quote:
Originally posted by bumpy:
Is this anything that someone (arekkusu?) could post a pre-compiled version of?
Source code for Xcode is good too! smile
I wonder if anybody is willing to tackle the new core changes for 84u4 & 84u5

Oh and Sexy Parodius works :p
Posted By: Arnoud Re: MacMAME 0.84 Xcode source leveraged - 08/02/04 03:04 AM
It has been a while since I played around with MacMAME, mostly because my G4/450MP was just getting too damn slow to run most things without complaining, but since I got my boss to hand over a G5 1.8DP (to which I added 2.5GB RAM) I thought I'd give it another shot..

So I downloaded the 0.84 source files and started looking at XCode for about the first time (lately I have only been doing PHP coding...)...

It actually took me more time to find out how the heck I could get the project to compile as non-debug than the actual compilation itself smile A lot longer smile

After I finally got it to build the target I've been playing games, games and more games (I was so smart to pull the 0.84 full archive off bittorrent so I didn't have to update my hopelessly out of date ROM archive)...

I am pretty pleased with the speed of the games I play a lot, so after that I thought I would do some speed checking of the games that were totally unplayable before...

Well, most still are stangely enough... Hard Drivin' is no where near fluid, and the mentioned Tekken is only managing 4-6/60fps on my machine... Am I doing something wrong here? (no, no other apps running, CPU load is fairly low)..

Compiling MAME does manage to warm up the room here quite a bit, wow, that rear exhaust of my G5 is amazingly warm... smile

Arnoud
Posted By: Arnoud Re: MacMAME 0.84 Xcode source leveraged - 08/02/04 03:12 AM
oh, and total compilation time on my G5 was about 20 minutes...
Posted By: Carsten Re: MacMAME 0.84 Xcode source leveraged - 08/02/04 03:20 AM
One thing to keep in mind with the current XCode build is the cores are the ones written in C instead of the assembly cores, a lot of games will run slower simply because of that.

The official releases are built with CodeWarrior and therefore take advantage of the speedier asm cpu cores.
Posted By: Isaac Re: MacMAME 0.84 Xcode source leveraged - 08/02/04 08:56 AM
Quote:
Originally posted by Arnoud:
Well, most still are stangely enough... Hard Drivin' is no where near fluid, and the mentioned Tekken is only managing 4-6/60fps on my machine... Am I doing something wrong here? (no, no other apps running, CPU load is fairly low)..
Have you turned off frameskipping? I know that helps the Tekken games so they don't runs choppy.
Posted By: arekkusu Re: MacMAME 0.84 Xcode source leveraged - 08/02/04 10:40 AM
Turn off frameskip. It goes to 11 if your machine can't catch up.
Posted By: Arnoud Re: MacMAME 0.84 Xcode source leveraged - 08/04/04 02:42 AM
Right, turned off frameskipping (frameskip0) and it now manages 45-50/60 fps on Tekken, and about the same for Hard Drivin'.... see how long I didn't play the thing? smile

thanks guys smile

Arnoud
Posted By: Bakasama Re: MacMAME 0.84 Xcode source leveraged - 08/05/04 05:57 AM
Well, autoframeskipping from my experience is that tends to cause more problems than solving them.
Posted By: will Re: MacMAME 0.84 Xcode source leveraged - 08/06/04 10:14 AM
So Xcode 1.5 is out folks! Start your engines wink
Posted By: Willou Re: MacMAME 0.84 Xcode source leveraged - 08/12/04 04:24 PM
Hi there

just downloaded the source, but unable to build with Xcode1.5

sad...

W.
Posted By: Carbon Re: MacMAME 0.84 Xcode source leveraged - 08/12/04 08:38 PM
FYI, I just updated to Xcode 1.5 and compiled the code without any problem (remember to switch the build style to deployment).
Posted By: Willou Re: MacMAME 0.84 Xcode source leveraged - 08/12/04 11:06 PM
oh...

yes it work with "deployment"
but for now, and with only the two roms i have on my computer (12" ibook g4 1ghz) ssriders & esprade
the framerate seems very poor and slow, and if i disable the autoframeskip option, this turn to be unplayable...

any way to fix this ?
(at this point, i'm unable to rewrite the code, too lame perhaps :-)
but i seems the old macmame run better than this build

compilation optimisation ?

W.
Posted By: Isaac Re: MacMAME 0.84 Xcode source leveraged - 08/12/04 11:14 PM
It could be that those games use a PPC core that Xcode can't compile yet.
Posted By: arekkusu Re: MacMAME 0.84 Xcode source leveraged - 08/13/04 05:59 AM
Both of those are 68k games.

On my 1.25GHz 15" PowerBook:

Both of them run at full frame rate in CW 0.77u2a, using the OpenGL plugin and 0 frameskip. They aren't VBL synced and use 100% of the CPU.

Both of them run at full frame rate in Xcode 0.84, using the OpenGL plugin and 0 frameskip. They are VBL synced and use about 45% of the CPU.

So, no problems here.
Posted By: Willou Re: MacMAME 0.84 Xcode source leveraged - 08/13/04 12:57 PM
mmmh..
perhaps i'm bad in compilation
because my ibook is an 1.1ghz, with 512mb and a faster hard drive
but still the radeon 9200 mobile inside (sic)
i try other builds but they don't have this kind of problems
on the windows(and dos) version, by pressing the F11 key we can see the framerate and the frameskip on the upper right corner, i don't found this option on macmame

i don't know why but it slow...

W.
Posted By: EvilWraith Re: MacMAME 0.84 Xcode source leveraged - 08/14/04 04:34 AM
Try option-F11
Posted By: Brian Kendig Re: MacMAME 0.84 Xcode source leveraged - 08/23/04 10:35 PM
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?
Posted By: Brad Oliver Re: MacMAME 0.84 Xcode source leveraged - 08/23/04 10:38 PM
Quote:
Originally posted by Brian Kendig:
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.
Posted By: Brian Kendig Re: MacMAME 0.84 Xcode source leveraged - 08/25/04 11:01 AM
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?
Posted By: Brad Oliver Re: MacMAME 0.84 Xcode source leveraged - 08/26/04 03:33 PM
Quote:
Originally posted by Brian Kendig:
Thanks! But when I try to compile the latest MAME sources, I get lots of errors with the CPU files.
I assume this is with XCode?

Quote:
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?


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.

Quote:
What determines whether a CPU file should be in the project or not?
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.
Posted By: arekkusu Re: MacMAME 0.84 Xcode source leveraged - 08/26/04 04:42 PM
Quote:
Originally posted by Brian Kendig:
But when I try to compile the latest MAME sources
Which source would that be, then?
Posted By: smf Re: MacMAME 0.84 Xcode source leveraged - 08/26/04 10:11 PM
Quote:
Originally posted by Brad Oliver:
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.
Rename it to something like ppcstate & submit a diff. There was a similar issue with mips to compile on SGI machines.

smf
Posted By: R. Belmont Re: MacMAME 0.84 Xcode source leveraged - 08/26/04 11:31 PM
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
Posted By: Carbon Re: MacMAME 0.84 Xcode source leveraged - 08/27/04 01:51 AM
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.
Posted By: R. Belmont Re: MacMAME 0.84 Xcode source leveraged - 08/27/04 02:02 AM
Ow. That's more serious then. Thanks for the message though.
Posted By: Carbon Re: MacMAME 0.84 Xcode source leveraged - 08/27/04 02:13 AM
You're welcome.

I'm so glad I could help in a little, tiny, minuscule way to my favourite program (for 8 years now). laugh
Posted By: arekkusu Re: MacMAME 0.84 Xcode source leveraged - 08/27/04 05:16 AM
I tried in 0.84u3, no difference. Same immediate quit in Tekken3. "H8/3002: Unknown opcode (PC=142)" is in Console.
Posted By: R. Belmont Re: MacMAME 0.84 Xcode source leveraged - 08/27/04 06:04 AM
Yeah. My patch had nothing to do with that error message - I was under the impression that the games started up and just didn't do anything on the Mac, which my posted fix would correct. This is a much more fundamental (e.g. MAME core) problem than that. You could try changing the ROM_LOAD16_WORD_SWAP for the H8 program (the .11s ROM for most S12 sets - usually labeled as "sound prg" in the source) to just ROM_LOAD and seeing if that corrects the "Unknown opcode" error.

(Note: in 0.86, if you do correct that, the games will crash anyway. That happens on the PC also. 0.84u3 oughta be fine though).
Posted By: arekkusu Re: MacMAME 0.84 Xcode source leveraged - 08/27/04 06:32 AM
It's the Sony ZN games that start up and just don't do anything.

The Namco 12 games worked in 0.84, but are broken in later builds. Namco 11 games still work.
Posted By: R. Belmont Re: MacMAME 0.84 Xcode source leveraged - 08/27/04 06:47 AM
Ok. With an assist from Aaron Giles, I have a real fix. Put namcos12.c back to original form, and open up src/cpu/h83002/h83002.c instead. In h8_execute line 432, change

opcode = cpu_readop32(h8.pc); to
opcode = cpu_readop16(h8.pc);

That should fix the problem.
Posted By: arekkusu Re: MacMAME 0.84 Xcode source leveraged - 08/27/04 11:17 AM
Yes, that fixes the immediate quit. Now Tekken 3 starts up in 0.84u3, and says 'Good Morning', so the sound is working too.

But, then it sits at the JAMMA initialization screen for a minute... five minutes... ten minutes... ??? How long is this supposed to take? (Running at 65% of realtime on my laptop, fskp0...)

Same thing with Mr. Driller.
Posted By: Brian Kendig Re: MacMAME 0.84 Xcode source leveraged - 08/27/04 11:19 AM
I'm trying to use Xcode 1.5 to compile the MAME 0.86 source with the overrides from the earlier version of MacMAME. I know it won't compile cleanly, but I'm puzzled by the sheer number of errors it's giving me; for example, here are the first few errors I get when I try to compile 2100ops.c:

Code:
src/cpu/adsp2100/2100ops.c:60: error: parse error before "constants"
src/cpu/adsp2100/2100ops.c:66: warning: data definition has no type or storage class
src/cpu/adsp2100/2100ops.c: In function `set_mstat':
src/cpu/adsp2100/2100ops.c:86: error: `adsp2100' undeclared (first use in this function)
src/cpu/adsp2100/2100ops.c:88: error: `ADSPCORE' undeclared (first use in this function)
src/cpu/adsp2100/2100ops.c:88: error: parse error before "temp"
src/cpu/adsp2100/2100ops.c:90: error: `temp' undeclared (first use in this function)
The "parse error before 'constants'" is because "INT32" isn't defined anywhere. The other errors are also generated by things which aren't defined anyplace. This particular C code file has no #includes; it itself is #included from adsp2100.c, which defines the things it uses. I've never seen any other project where one .c file #includes another .c file; I figure that 2100ops.c itself isn't meant to be compiled.

The MAME 0.86 source distribution has no Makefile, per se: it has a "mame.mak", which references only object files (no C files), and a "rules.mak", which appears to reference every available C file (including 2100ops.c). So I haven't yet figured out how this is supposed to be able to compile on Windows, much less Mac.

I apologize for my utter cluelessness here. I'm trying to make sense of this so that I can reach a point where I can make a positive contribution, and until I get there I don't want to slow down anyone else who knows what he's doing.
Posted By: Bakasama Re: MacMAME 0.84 Xcode source leveraged - 08/27/04 11:26 AM
Well, since we're talking about MacMAME 84 xcode. I'll like to mention that Tempest looks real bad in software mode but it's fine in GL mode. In software mode, the game just looks like a bunch of dots.

Anyway, I'll like to say it's great having GL mode back in MacMAME.
Posted By: arekkusu Re: MacMAME 0.84 Xcode source leveraged - 08/27/04 11:33 AM
Brian, are you starting from my 0.84 and leveraging or from scratch? The Xcode .pch includes mach_fixup.h to undef the symbols Brad mentioned.

Either way, you're going to have a bunch of Mac OSD code to rewrite to get the input systems to work with the 0.86 code.
Posted By: arekkusu Re: MacMAME 0.84 Xcode source leveraged - 08/27/04 11:37 AM
The software renderer's rotation doesn't work with vector games' dirty updates. Just another problem with rotation.
Posted By: Brian Kendig Re: MacMAME 0.84 Xcode source leveraged - 08/27/04 11:45 AM
I'm starting from scratch, not using your 0.84, because I want to understand exactly how this is put together. I don't understand what went into making the five Xcode project files you're using, and I want to have a better comprehension of exactly what files are going into the project and where. That's why I'm doing this the "hard way" - my goal isn't to just update your project, but to teach myself exactly how the MAME source relates to the MacMAME overrides.

I know work will be needed to get the new stuff in MAME 0.86 working nicely with Xcode and the older MacMAME source files - so I'm expecting that when I try to compile everything all together I should get a bunch of errors relating to the input systems and the assembly-language cores and other things - but I don't think I should be seeing dozens of CPU (and other core) files fail to compile due to undeclared variables, and so I'm thinking I'm doing something really wrong.

(I haven't even *gotten* to any problems with 'ppc' being a reserved word yet!)
Posted By: R. Belmont Re: MacMAME 0.84 Xcode source leveraged - 08/27/04 07:14 PM
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.
Posted By: arekkusu Re: MacMAME 0.84 Xcode source leveraged - 08/27/04 10:38 PM
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? wink
Posted By: Carbon Re: MacMAME 0.84 Xcode source leveraged - 08/27/04 10:50 PM
I'm happy to report that by applying both fixes, xmame 0.86 for OS X now works for namco12 games too. laugh
Posted By: R. Belmont Re: MacMAME 0.84 Xcode source leveraged - 08/27/04 11:37 PM
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.
Posted By: Brad Oliver Re: MacMAME 0.84 Xcode source leveraged - 08/27/04 11:56 PM
Quote:
Originally posted by Brian Kendig:
The "parse error before 'constants'" is because "INT32" isn't defined anywhere.
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.
Posted By: Brad Oliver Re: MacMAME 0.84 Xcode source leveraged - 08/28/04 12:00 AM
Quote:
Originally posted by Brian Kendig:
The MAME 0.86 source distribution has no Makefile, per se:
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. ;-)
Posted By: Brian Kendig Re: MacMAME 0.84 Xcode source leveraged - 08/28/04 09:31 AM
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!
Posted By: smf Re: MacMAME 0.84 Xcode source leveraged - 08/28/04 02:28 PM
Quote:
Originally posted by Brian Kendig:
The MAME 0.86 source distribution has no Makefile, per se: it has a "mame.mak", which references only object files (no C files), and a "rules.mak", which appears to reference every available C file (including 2100ops.c). So I haven't yet figured out how this is supposed to be able to compile on Windows, much less Mac.
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
Posted By: smf Re: MacMAME 0.84 Xcode source leveraged - 08/28/04 02:31 PM
Quote:
Originally posted by R. Belmont:
but at least we know the basic PSX emulation is in good shape.
It's in the same sort of shape on the mac as windows, I wouldn't describe it as a good shape.

smf
© Forums