Home Page Forums Archives MacMAME MacMAME 0.95 Xcode projects posted

Updated from the 0.94u1 projects , 0.95 source is now available on my .mac public folder .

The included readme lists step-by-step compile instructions and some info on the mac-specific bugs and changes since 0.87b. This build fixes some important bugs (cheat.dat, upside down vectors, the debugger), but there are still some games that hang or crash on the Mac.

For those of you unable to compile, a pre-built binary is also available. Please keep in mind this is an unofficial build.

If you discover any problems which are not listed in the readme and which do not happen on the PC, please add them to this thread.

@Brad: No code changes were required to match the core, but I cleaned up gcc compiler warnings and fixed bugs (comments added to wiki .) As before, diffing against the 0.88u4b1 tree will show everything I changed. Notably, project flags and the .pch include order were fixed, so it finally compiles with zero warnings. The shell script phase also builds chdman now.

Wow! For the first time in a long time, MacMAME comes out a day after the official release. No offense Brad. We understand your busy at Aspyr and appreciate the time you do give to MacMAME.

Thanks arekkusu for this release! Even if it is unofficial.

arekkusu, you rock! Thank you!

And I see you have a binary up there also - that's great, so now I can be sure I'm on the same page as the other people who are using version 95. Thanks again!

Woo hoo! Thanks.

Voch

Hoe Lee Poop! Thanks Arekkusu

Great arekkusu!

Right On! :what:

arekkusu-san, you are my hero!

Ok Fava, now it's available!

At least i've write right

Great to see a new unofficial update so soon. Of course, I already said this on the Emuscene board, but still.

One quick question to anyone who knows: Roughly how long does it take for ROM sites to become up to date with the newest ROM sets? Because apparently Bubble Bobble was changed between 0.94u1 and 0.95, and it's not available yet at a certain, remaining nameless site.

A certain nameless site that I know of is typically one three weeks behind the MAME releases.

You have a better chance checking a.b.e.m. You can find them there the same day a release occurs.

I looked all over " a.b.e.m. " and couldn't find a thing...

I can't use bittorrent on the network I'm currently on. They disable you if they catch it because they don't want large files clogging up the network.

Let's not turn this thread into a ROM hunt, OK? That's not what this forum is for.

Sorry. Believe me, my post wasn't an underhanded tactic of obtaining ROM sites.

I'll leave it at: I read the news and found what I was looking for.

hmmm, I have to add Pong again.

Senkyuu doesn't work. It just hangs on one and that's it.

R.Belmont mentioned the flash ROM is busted in Senkyu. Core bug.

Is Mahjong Hyper Reaction really not working? It's got a big red X through the icon, and it gives the "not working" warning, but it seems to be playable. I just beat the first girl. I didn't play all the way through.

A few games with the red X are nonetheless playable; Soul Edge is a good example.

I played MJ Hyper Reaction all the way through and couldn't find any problems (sad, I know).

Arekkusu, can you do something for Afterburner and Primal Rage that is the only rom I have that don't work at full speed as on the PC side?
Thanx for this relase again!

arekkusu,

query re: config:

Why do the .cfg settings need to be trashed between 94u1 and .95 -- isn't it using the same style configuration?

They don't have to between 0.94 and 0.95. They do need to be trashed between 0.88 and 0.94, though.

I had real problems with my pad going from .94u1 to .95 until I trashed the configs...maybe it was just a fluke with my Playstation pad?

By the looks of it, these games may have used the PPC 68K cores that are not compatible with Xcode. So instead they use the C 68K cores which are much slower.

Which brings up another question. MAME seems to be doing away with Assembly cores now. Will the same happen on the Mac side seeing as CPU core fixes are done on C cores instead, e.g. the Sega System16 games rewrite?

Well, I've been with MacMAME for a long time. One of the major features of MacMAME is the use of ASM 68k cores. I believe those will still be a part of MacMAME.

No, the official builds will still use the assembly cores for the foreseeable future.

Yes, but (and I'm not trying to be insulting here) if Arek is actually putting out updates in sync with PC and you aren't, maybe his should be official and your build can be a special "turbo" one that comes out whenever you have time.

Alex,

As always

I've still been having some issues myself. 95 was holding the default configuration for a while, then I opened up "Narc" (which was a bad idea for so many reasons), and it all went back to default.
To prevent this from happening, I set up all the default configurations I could possibly want, then quit MacMAME, opened default.cfg, and locked it.
I may not know how to do it right, but I can do it so it works.

Belmont's got a point, why not make the new MacMame the official one, and Brad's a special turbo one. I'd really like to see a version of MacMame updated at the same rate as the PC one, no disrespect to Brad's work...

For speed-problems on Sega games and other's which seem to be slow, be sure to uncheck frame-skipping in the MISC menu. I was so happy to find out Thunder Blade now 100% in MacMame, running pretty much full speed on my PowerBook... I luv the new MacMame!

Rapha?�l Nabet had the PPC assembly cores compiling (for MacMESS) under Project Builder/Xcode. I reverted to Arekkusu's method for my current releases. I plan on moving back to PPC core as soon as I figure out how he did it.

all i have to say is THANK YOU. Mortal Kombat 3 is now again playable with the xcode compile. I havent been keeping up with mame recently, but i sure will be now. Thanks again.

Forking it just to have a "fast" build vs. a "slow" seems like a waste of energy and IMHO would really only confuse end-users. Ultimately I'd like to open my SVN server to the world and just have Alex and everyone else check in and build off of it.

That way, he could build "official" binaries off of it with XCode and I could easily come along later (or, gasp, earlier) and do a CodeWarrior release and we could share a consistently-progressing version numbering scheme even though we're building in two totally different environments.

Of course, if Alex wants to end up being point man for support alongside myself, that's his choice.

I was wrong about Rapha?�l's use of the PPC ASM cores. He didn't port them, he just used the Asgard source file to load the C core.

Sorry for the confusion.

BTW, I love this passage from MovingProjectsToXcode.pdf:
The PPC cores do all the heavy lifting with globals.

I took a look at these. Although it is true that both these games use the 68k, and the C core used in the Xcode build is slower than the asm core in the official build, the 68k emulation isn't the biggest bottleneck for these games.

For Afterburner, the bottlenecks are cpu_timeslice (it has a high cpu interleave?) and segaic16_sprites_outrun_draw (the video hardware.)

For Primal Rage, the bottlenecks are video_update_atarigt (the video hardware) and tms32031_execute (which doesn't have an asm core in the official build anyway.)

For comparison, on my hardware with fskp 0, 0.95 runs Afterburner II at around 50/60, and Primal Rage at around 36/60.

0.87b runs Afterburner II at 60/60 with some CPU left over, but Primal Rage is still around 36/60.

There is not a lot I can do to improve the speed of these in the Xcode build (with the available time I have.) You can still use 0.87b to get some speedup in games with CPUs that use asm cores (68k, 6502, Z80 etc) but it won't be faster in every case.


I'd also appreciate info on that.

My note in the readme was ambiguous about "old versions"; going from 0.87 to 0.9whatever will cause problems, but 0.94u1 to 0.95 should be OK.

If you've found otherwise, and you can reproduce the problem, please list the exact steps you take, so I can make it happen here and look into it.

Ah. Well, maybe this can be revisited in gcc4.

The SCM would be great (MacMESS folk would also benefit), and I'm honored to be considered for official-dom.

But-- this week my life is changing: I'm being hired. So it is quite possible I won't be able to work on MAME (due to time constraint and company IP.) We'll have to wait and see.

I can't say that I did much: unpacked the MacMAME .95 binary, renamed the existing one to MacMAME.94u1 (but left it in the /Applications/Games/MacMAME directory), plugged in the Lik Sang Adapter with PSX joypad already connected like I always do and then started up MacMAME. When I went to play a game I noticed that some controls weren't behaving right. I went into the control menu and looked at the controls an some weren't set any more (most notably the P1 right joystick). I tried re-setting them, but a lot of key presses were coming up completely different than they had previously with different axes or multiple control directions. I trashed everything in Config started MacMAME again and everything was normal.

I'll try launching from .94u1 and switch back to .95 and see if it happens again. Could be it was just a fluke.

In any event aside from Golden Axe II not working I have no problems with this release (outside of old outstanding bugs with software rendering that I can work around by flipping back-and-forth to OpenGL -- which is nice in that some games definitely run better with OpenGL than software). Thanks much for your fine efforts!

Okay, I've done some testing and found the following:

1. If I start MacMAME without the joypad plugged in the config settings for the controller are removed and next time I start with the joypad plugged in I have to re-input all joypad settings; as long as I start MacMAME with the joypad plugged in settings are retained (this appears to be true for both .94u1 and .95). Minor, but given the inoperability of trackball/analogue controller being simultaneously connected this is a little annoying as it means going back-and-forth between trackball and joypad controlled games will require re-entry of settings.

2. After having made settings in .95 I then started up .94u1 (the binaries both live in the same directory: /Applications/Games/MacMAME and ~Documents/MacMAME has gui aliases -- as opposed to UNIX symbolic links -- to folders in that directory) and found that the config was retained. When I started up .95 again, however the default config was loaded, requiring me to re-enter the joypad settings. The joypad was connected to the system the entire time. I'm running a Titanium Powerbook 500MHz G4 and OS X 10.3.8.

If you need me to supply further information, I'm more than happy to do so.

Couldn't find anything about this in the Wiki or this BBS by searching, but Food Fight appears to be broken. The game loading only says RAM, ROM 6 and ROM 7 -- never gets any further and button presses have no effect. Same thing if I try starting in service mode. Trashed nvram and config without change -- is this something broken in the MAME source or just MacMAME?

Another game issue which definitely looks like an emulation problem: collision detection in Front Line is seriously messed up. If I'm using grenades I hit enemies just fine (and vice versa) --except for the stationary tank at the end of the level which never gets damaged -- but if I'm shooting using soldier or tank guns my shots pass through enemies, who also are unable to shoot me. Likewise enemy tanks pass through brick walls as if they're not there.

Please let me know if there's a wiki for unofficial builds!

Gradius 3 won't come up. Gets through RAM ROM tests, displays grid test and then a black screen -- same if dip switch set to service mode.

Gravitar doesn't work with OpenGL at all -- just get mess of amber coloured lines and not even the in-game menu will display. Software-rendering is just fine.

Land Breaker won't play. It gets to the ROM check screen, then reports all the ROMs as being bad. Could this be an endian issue, or is it broken on the PC as well?

You might check at MAMEtesters (www.mametesters.org) to see if any of this was reported on the PC.

I cannot find any known issues against the 3 titles I've reported issues with (foodf, gradius3, frontlin).

Kid Niki (kidniki) causes MacMAME to crash following MAME screens, but before in-game boot screens.

Sean: is this with the 0.95 binary from my site, or did you build it yourself? What's your hardware/OS config?

I see that Food Fight is broken (NVRAM fails) but I can't reproduce the other problems-- collision detection in Front Line seems fine (I can shoot them, they can shoot me) and Gradius 3 and Gravitar both come up and play fine.

[Edit: Kid Niki also works fine here.]

Can anybody else confirm/deny the issues Sean describes?

I'll look at the .cfg problem in some more detail later.

Setting up a wiki for post-0.88u4b1 builds is probably a good idea.

Land Breaker does look broken. The checksums are swapped for every pair of ROMs. Does this happen on the PC?

I've got the .95 binary from your site; hw is Powerbook G4 500MHz Titanium running OS X 10.3.8.

Front line may need a little qualification. I think it was working, but then I did a config change because the default of having the left stick aim and right stick move threw me off, so I mapped the controls for P1/Right to the d-pad (which shows up as four additional fire buttons) and P1 left to the right analogue stick with button two as my lower-left shoulder button and button one as lower right. I'll try changing back to default and see what happens, but I'm confused as to why changing the default controls for the game would cause such a radical difference in play unless the controller config setup is somehow messing with the emulation?

Gravitar plays fine; it's just OpenGL that doesn't work with it; this could be due to my old chipset though (8MB ATY,RageM3 is how it gets identified in System Profile). I'll try Gradius 3 with software rendering to see if that could be what's causing my problem there as well.

IIRC, it always does this the first time through. I think you have to twiddle the service mode switch to continue.

Land Breaker works fine on the PC, but it's extremely slow. Likely a ROM_REGION in need of LE or BE.

I recommend you all download the mameinfo.dat file which then provides specific game info on the GAME HISTORY pull down menu on the INFO tab.

http://www.mameworld.net/mameinfo/

For Food Fight it says, "- The first time you run the game, it will say 'NVRAM FAILED:'. Press P1 Button 1 to proceed. The NVRAM will be automatically initialized."

So just press the control (fire) button, it works fine for me.

I also just played Gradius 3 no problems with MacMAME 0.95

OK, I fixed Land Breaker. I changed

to

on line 234 in eolith.c - now I'm wondering if any other Eolith games need this fix.

Thanks everyone!

Yes, there is a known bug ("low-VRAM" in 0.87b wiki ) with 8MB Rage128 systems and "big" games (typically vector games, or games with bezel artwork.)

The problem is that if you run at 1024x768 (or 1152x768 on your PowerBook) in Millions of colors, there isn't enough VRAM left for the texture. This should throw an error so MAME can revert to software rendering, but it doesn't.

If you change to Thousands of colors, or lower the display resolution, it ought to work.

I'm aware of the NVRAM issue with Food Fight, however that's not what's happening here. It never says NVRAM failed, it just prints:
RAM
ROM 7
ROM 6

and that's all she wrote; software vs. OpenGL rendering makes no difference, so I'm not sure where to go next with this.

Well, colour me confused. The problem seems to have "fixed itself" (but as an IT person I know "these things don't fix themselves, sah") and the NVRAM OK message now appears and the game starts with both software rendering and OpenGL.

Actually I think all the problems I've been seeing outside of this one are OpenGL-related. The Front Line collision issue is definitely being caused by OpenGL: starting game with Software Rendering on it works fine even with my redefined controls; start with OpenGL and bango: the shots miss their targets (grenades still work, though -- kooky).

Kid Niki seems to crash MacMAME occasionally when using OpenGL, either when the game first boots or when exiting to the front-end using Command+o.

Gradius 3 is very strange. I started it with OpenGL, and saw that if I wait for about 2-3min. after the screen goes black I start seeing what can only be described as blue graphics test patterns punctuated by the occasional sound ("bloop", "bleep"). I let this go for 10+min. like this and tried again with Software Rendering -- ditto. I then tried Kid Niki which started under OpenGL (surprise!) and then crashed MacMAME when quitting (no surprise) and when I restarted MacMAME I went back to running Gradius 3, but this time starting out using Software Rendering and it just started up normally (game runs a little slow, but that's normal on my system), so something seems to be happening if I switch from using OpenGL to Software Rendering which isn't quite clean. Thankfully this only matters if I try to run Gradius 3 with OpenGL first; running other games with it doesn't matter as long as I remember to switch to Software Rendering before launching Gradius 3.

Weird and kinky, but at least everything else seems to be working. Someday I'll have a system with enough video ram and new enough AGP chipset that it won't be an issue, but at least I've got something to point to!

Looks like my only outstanding issue is with the config, then!

Both games work fine with Mame v95

You might want to try getting a fresh Food Fight ROM...

How do you play Food Fight without the rotating joystick that it had (wasn't it like the 720? stick?)

I believe Food Fight used a 49-way joystick. That's somewhere between an 8-way joystick and a 720 style joystick.

The 49 way joysticks are all the rage now since Randy over groovygamegear released his 49 way interface. With his interface, you can select between 8 different joystick modes... 4way, 8way, 49way, diagonal, etc. Pretty cool.

Nope, Food Fight used a Hall-effect joystick which gives full analog joystick accuracy (8 bits in each direction).

Aaron

Thanks Aaron, I knew there was something different about the way those Food Fight games played...

Mahuti, the grrovy stick looks cool and they've got a lot of other interesting stuff. I like the chromed joysticks...

Sorry if the question is not very original. Can someone tell me how to compile the 0.95 source code? I'm using the 0.87 at the moment

@ Stefano - You'll need Xcode 1.5 or you can grab the binary from Alex's link on page 1! Hope this helps.

New Rally X - Screen Redraw error... Could not get a screen shot that depicts what I was seeing, but it seems that on screen refresh intermittant zig-zag lines would form on some of the corners.

Running 10.3.8 - G5 - Radeon 9600 installed.. Wondering if it is the video card? Certainly did not show up on screen shots but was prevelant during game play.. anyone else have any issues with New RallyX?

Cheers

"zig-zag" lines? Need more info.

I can't reproduce that, on a G4 AlBook with Radeon 9600 running 10.3.8, Xcode MacMAME 0.95 with the GL plugin.

But, there are two possible causes for intermittent artifacts:

1) you turned off VBL sync. This will cause horizontal "tears" across the entire screen. Some people have had the GL plugin tear even when VBL sync is turned on, but I can't reproduce that. It might be caused by other apps they are running in the background.

2) timing issue with some video cards can cause texture corruption such as in this pic . I haven't seen this in MacMAME for a long time though.

No other apps were running in the back ground, tried turning off VBL sync and it worked.

Thanks!

Can���t seem to load Spider-Man: The Videogame (World) in the latest Xcode build of MacMAME! MacMAME crashes after the emulation inaccuracy warning screen!

Apologies if this has already been noted on the forum and/or Wiki.

Spider-Man uses a V60 CPU, it is probably an endian problem similar to Golden Axe II.