Newpuc2

[mahlemiut]

...although I clearly remember moaning to the macmame dev with 0.66 cuz many games ran a factor of at least 2-3 times slower in 0.66 versus what they ran in 0.60. He said that was because he removed the assembly from those game CPUs in 0.66.

Like I said earlier, there is no ASM Z80 core in MAME. There used to be, way back when 2-300MHz PCs were the norm, but not any more. Removed ages ago, I presume.

The only CPU compile-time options in regular MAME are:
68000/68010: C (portable and more accurate), x86 ASM (a bit faster, and less accurate)
68020: C (portable, and actually works), x86 ASM (should never be used, doesn't even work on the older Psikyo games - Gunbird, Strikers 1945...).
MIPS III: C (slow, but portable), x86 dynamic recompiler (much faster, as far as I know is as accurate as the C core). Killer Instinct 1 and 2 are the only playable games, speed-wise, that use this CPU (3Ghz for the C core, 1.5GHz approx. for the dynarec core).

[LN2]

Like I said earlier, there is no ASM Z80 core in MAME. There used to be, way back when 2-300MHz PCs were the norm, but not any more. Removed ages ago, I presume.

Ok fine, I believe you there...but why can't you believe me when I state that even macmame 0.60 had assembly optimizations for pacman?

My mac at version 0.60 was still a decently fast mac...at 400MHz. The fastest mac then was likely a 550-600Mhz G3/G4. Tons of mac users still were using pre-G3 PPCs....systems like 200Mhz 603e or 604e.

The only CPU compile-time options in regular MAME are:

yeah, my first build would certainly be with nothing but the c-cores.

Several have built macmame on their systems and yet all have serious bugs. However, I think none of them are building just the c-cores.

one guy that directly built x-mame and released it....I tried it and it for the most part didn't run at all. For a few games I managed to get a window with an initializing screen for the game...but the game never finished the boot process.

anyway...I won't touch this until I have Panther and the latest gcc and X-code tools to use.

[mahlemiut]

Ok fine, I believe you there...but why can't you believe me when I state that even macmame 0.60 had assembly optimizations for pacman?

I never said I didn't believe you. I am well aware that there are many ASM optimisations in MacMAME. But when it gets to using a different CPU core than what MAME provides, that's where INP playback issues can occur. That's been proven with the 68000 cores in MAME.

anyway...I won't touch this until I have Panther and the latest gcc and X-code tools to use.

You can always get the latest GCC at any time. Last I checked, X-MAME still compiled with GCC 2.95.1 (really crusty old version, I use 3.3.3 under Linux and 3.2.2 "MAME standard" under Windows, though).

[LN2]

I am well aware that there are many ASM optimisations in MacMAME. But when it gets to using a different CPU core than what MAME provides, that's where INP playback issues can occur. That's been proven with the 68000 cores in MAME.

Yes, I am aware of that. There were a few versions of macmame that when you ran games you had the option to run it using only the c-cores instead of the assembly. Doing so would result in replay files that could only be viewed running with that same option.

You can always get the latest GCC at any time. Last I checked, X-MAME still compiled with GCC 2.95.1 (really crusty old version, I use 3.3.3 under Linux and 3.2.2 "MAME standard" under Windows, though).

yeah, but you are talking linux and PC there. gcc for mac was still in development(regardless of the version number)....mainly the libraries and various frameworks though.

...I heard many issues about the previous gcc apple had released...that were fixed in this latest version that comes with the X-Code tools for Panther. I think the last upgrade to X-Code actually included an upgrade for gcc also. I am not sure what version that is at since I have not looked into it...no point until I am using Panther.

I look at it from the standpoint that if a CLI XMAME port was fairly simple...just recompiling the source with perhaps different lib names here and there that a good port of it would have long been done.

There hasn't been to date AFAIK a "working" port of xmame for OS X. Some have claimed it works...but I try it and it doesn't. Maybe it does...but was built where it depends on you having the exact same dev tools and libraries installed as the guy who built it had.

That isn't good IMHO.

Again, I do plan on getting into this...just be patient. It might not even get off the ground for the next couple of months...but then again come Thanksgiving I could be working on it. I can't say at this point.

[Chad]

i feel a dejavu coming on, but if you've tried it and it failed could you give us the errors you got, maybe we can find a work around? I agree that it's probably unlikey that it works if no one's said mac xmame does, however you just said some claimed worked?

[LN2]

i feel a dejavu coming on, but if you've tried it and it failed could you give us the errors you got, maybe we can find a work around? I agree that it's probably unlikey that it works if no one's said mac xmame does, however you just said some claimed worked?

in a nutshell, through the macmame forums a few have given links for a build of a port of xmame for OS X. I download it and it doesn't run at all or does run...but is very limited. ie. game window opens up and I get the intro splash screen...but hit any key just goes to a black window content or bogus graphics in the window...tha game bootup isn't working.

I have not checked the console logs to see if it shows anything from these runs. I just figured at that time it was something to quickly try...thinking if it ran I could quickly test Barry's theory that replays from a port of xmame for OS X would be compatible with xmame for linux...then that build could quickly be made to a xwolfmame.

...then later I could work on a new GUI project and see how the assembly for various game CPUs affects play and playback compatibility of replay files.

At that time I mainly was looking at it from a user perspective...cuz at that time the latest official macmame build was already several versions old....so this xmame build I was trying was worthwhile just to have access to play the latest version of MAME.

[mahlemiut]

yeah, but you are talking linux and PC there. gcc for mac was still in development(regardless of the version number)....mainly the libraries and various frameworks though.

http://gcc.gnu.org/install/specific.htm ... c-*-darwin*

And yet it's listed as a supported platform.

[LN2]

And yet it's listed as a supported platform.

Ok, in a nuthshell..maybe it's different for gcc...

...but are you developing wolfmame to make sure it runs on MSDOS 3.3?!? are you building it with concerns for Win95 users?

I am guessing even with gcc builds with modern versions have issues running in older OSes....it all depends on the source and what libraries are linked versus libraries the application needs to run.

Well, with the changes to OS X and the extreme changes to Apple's Dev Tools between 10.0.x, then 10.1.x, then 10.2.x(Jaguar), then 10.3.x(Panther) and the soon coming Tiger(10.4.x?!?)...

....I would prefer to develop with the very latest X-Code and gcc...versus the older Dev Tools and gcc that work with Jaguar. Sure, maybe most Jaguar tools developed applications would run with Panther...but certainly not all.

I am totally new to the Apple dev tools anyway...so why take time to learn the Jaguar IDE and gcc to then have to totally start over and relearn X-Code IDE package?

From what I have read they are so different it really takes some time to adjust from one to another....tons of different libraries....not even structured the same way. This means doing through the linking on projects and overhauling them for the newer tools/gcc.

Perhaps for a complete CLI application that isn't an issue....but when I need to invoke a window where video will be drawn in it plus audio plus controllers etc. that other stuff comes into play.

I would rather not develop with an already "obsolete" IDE and link with libraries that can cause issues for using the build in other OSes...like Panther.

Here is a question...is there a quick and easy way to get the gcc version?
ie. a CLI command I can issue that will report the general info of the gcc compiler including the version?

I think the one I have is actually 2.9x.x but not sure.

[mahlemiut]

Here is a question...is there a quick and easy way to get the gcc version?
ie. a CLI command I can issue that will report the general info of the gcc compiler including the version?

gcc -v should do the trick.

Code: Select all

C:\mame>gcc -v
Reading specs from c:/mingw/bin/../lib/gcc-lib/mingw32/3.2.2/specs
<snip config>
Thread model: win32
gcc version 3.2.2 (mingw special 20030208-1)

Code: Select all

[bsr@betapc bsr]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)
[bsr@betapc bsr]$ gcc-333 -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/specs
<snip config>
Thread model: posix
gcc version 3.3.3

[LN2]

ok, here ya go...

Code: Select all

[localhost:~] rickc% gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs
Thread model: posix
Apple Computer, Inc. GCC version 1175, based on gcc version 3.1 20020420 (prerelease)

Notice that is termed a prerelease...cuz it was. It has issues that were fixed in later versions...some quite major issues.

[mahlemiut]

Ok, but I shouldn't think that there'd be any issue with compiling a more recent version of GCC.

Download the source, configure it, and compile it. Pretty straightforward.

[LN2]

for the so-called ansi-c I agree...

..but so many libraries and various includes and headers etc. have changed that the libraries with my version of gcc will need some quite different includes and linking structure to work.

From what a developer recently wrote, it took him(a very experienced developer) 2 full days to go through all the mame code and update those headers.

..oh, he also had to change some of the job control lines as well.

given I am new to all of that...it would take me far longer.

I might as well just use the IDE....and not waste my time using an IDE for this one project..an IDE I likely will never use beyond this project if I even used it for this project.

You are looking at it as a linux user. oh...just adjust the makefile and off you go.

That's great...but as I said I have ALWAYS used IDEs so have little to NO idea how to adjust and structure a makefile.

I likely could download someone else's xmame port to OS X and use that as a better starting point.

If it was so so simple, then a fully working port of this would have been done by several users already.

it hasn't...which supports the idea it isn't trivial.

far more have done the build-rebuild of the official macmame project...not xmame port.

[mahlemiut]

You are looking at it as a linux user. oh...just adjust the makefile and off you go.

Welcome to the world of Unix.

[Chad]

You are looking at it as a linux user. oh...just adjust the makefile and off you go.

Welcome to the world of Unix.

if you're into accepting help, instead of adjusting the makefile yourself. Just download it, type make, and send us the error messages and we'll adjust the makefile (or tell you what else to download) by proxy.

[tar]

notman strikes again.
22 megabytes.
200,000 on first man.