Apologies in advance if this should have been posted in the Implementations section.
I recall reading a while back that somebody was working on a MAME implementation, and I was curious whether or not any such work has gotten to a functional point yet.
To my knowledge, there are several MAME implementations in various stages of usability. There’s imame4all, which works well in low-resource settings but is based on a super-old version of MAME, so it’s missing many, many compatibility/accuracy improvements (I’ve also been less-than-successful getting it to compile on some platforms, but that may just be me). One of the actual MAME devs was working on a libMAME that could then be wrapped with libretro but I think he’s still in the fairly early stages with it. There was also talk of working on another older-than-current version of MAME as a higher-performance alternative to imame4all but I’m not sure far along it has gotten. There may be others…?
If you don’t need MAME, specifically, and just want to emulate arcade games, the Final Burn Alpha (FBA) port is your best option, IMO.
There is a port of MAME 0.78 to libretro.
It will not make it in time for the RetroArch 0.9.8 end-of-year release on consoles and Android.
I’m trying to get it to compile on Windows (MinGW32), and I keep getting:
sh: C:\Program: No such file or directory
makefile:172: recipe for target 'obj/mame/version.o' failed
mingw32-make: *** [obj/mame/version.o] Error 127
Any insight?
Try putting quotes around the path name. It looks like it got cut off at the space in “Program Files”.
The problem is that I’m not actually defining a path anywhere. Does mingw32-make have a default path to build things in Program Files? Is there any way for me to define my own path? I’m still a little new to mingw, so I’m not super familiar with it.
Here’s my little lexbuild.bat file that I run from the mame078-libretro directory when I build.
gcc -v
make -f Makefile clean
make -f Makefile
ren retro.dll libretro-mame078-lex-x86_64.dll
move libretro-mame078-lex-x86_64.dll ..
pause
I’m not sure what you’re doing in order to run your build process, but perhaps this will give you some insight.
Mind you, mame078-libretro still doesn’t build properly in Windows, but I’m getting an error when linking, after compiling everything. I’ve told Squarepusher about it.
03:46:05 <LexSfX> still compiling what seems like >9000 games
03:46:08 <LexSfX> or machines
03:46:21 <LexSfX> oh!
03:46:25 <LexSfX> it finally errored out
03:46:26 <LexSfX> lemme seeeee
03:46:52 <LexSfX> Compiling src/libretro/performance.c...
03:46:52 <LexSfX> Linking retro.dll...
03:46:52 <LexSfX> make: execvp: gcc: Bad file number
03:46:52 <LexSfX> make: *** [retro.dll] Error 127
03:47:06 <Squarepusher> hmm
03:47:11 <Squarepusher> might be some stupid thing in the Makefile
I managed to get this to build on 64-bit Linux, but not 32-bit. It seems to work well even at this early stage.
I just nailed the “sh: C:\Program: No such file or directory” bug. The troublesome space wasn’t in the PATH or in any makefile; it’s in the command used to launch your command prompt in the first place.
I’m using MSYS-Git on my system, and the Git Bash shortcut to get a bash prompt from which I’m building things (the standard windows command prompt can have issues when trying to build Linux-targetted makefiles.) The shortcut launches this command on my machine (x64):
C:\Windows\SysWOW64\cmd.exe /c ""C:\Program Files (x86)\Git\bin\sh.exe" --login -i"
And forever after when make tries to launch another process bash will dumbly copy the path from that commandline across to the new process path. And fail horribly. Changing the shortcut to this fixes it for 32-bit windows:
C:\Windows\SysWOW64\cmd.exe /c ""C:\Progra~1\Git\bin\sh.exe" --login -i"
and this for 64-bit windows:
C:\Windows\SysWOW64\cmd.exe /c ""C:\Progra~2\Git\bin\sh.exe" --login -i"
bangs head against desk I think I need to go tell the msys-git people about this one…
Hmm, so that’s what was up with that. Interesting. I made a directory called Program anyway so stuff would compile, but yeah, how weird.
That said, I am having issues compiling this core, but Lex stated above it doesn’t compile well on Windows, so that’s probably why. Can someone share a compiled core for Windows x64?