We don’t keep copies of old cores anywhere but you can checkout any revision of the source tree from github and compile it yourself.
i was thinking maybe we should, at least for mame and fba at least for major version upgrades(like fba029739->fba029740)since games rely very much of romset crc and not everyone has the bandwidth to update.
it would also be good if the accompanying rdb for that version be saved as well.
1 Like
I agree that there may be some value in having a FBA 2016 or FBA 2017 core forked off the main FBA core like the “frozen” MAME cores.
It seems that this was done in 2012 with FBA, maybe now is the time to do it again?
On the other hand with MAME: there is a MAME 2014, MAME 2016, and current MAME core already available. Those seem like enough stable reference points.
1 Like
Yeah, each one adds to the maintenance burden. The 2003 core is one we chose because it’s right before they did a big rewrite of the whole program that cost it a lot of speed. 2000 and 2010 are just there because they match commonly used/available ROMsets for iMAME4all and other mobile MAME releases and people kept saying “why don’t muh rawmz works??”. 2014 is when we first started providing a modern MAME core, 2016 is when MAME drastically changed their build system and current is … current.
If it were just me, I would purge 2000, 2010, 2014 and 2016 and just keep current and 2003, but I know people depend on those others for various reasons, and I’m not directly doing any of the maintenance, so whatever.
2 Likes
i don’t like the always changing “current” Mame/FBA (in Retroarch and as Standalone). they are timebombs and it’s only question of time when your Romset doesn’t match it completly - than you have to rebuild it from scratch or download a new one (both can take many hours) - in my case copy over 40 GB to the lakka device - and on next update the same again -and again - and again …
The freezed ones (for an certain “reference set”) are the way to go, i think.
i think whole MAME-Thing in RA is very WIP at moment … (no quickmenu for Mame OSD-things, no input remap-feature, officiall artworks are shown lowres only, no playlist-scanner(*) and some other issues allmost about controlls)
- i know playlist-scanner is ready for first checkups
1 Like
A lot of that is unlikely to change. There’s no way we’re going to provide every MAME OSD option as a core option. That’d be crazy and wouldn’t even really be possible due to limitations in our core option system. The artwork thing is never going to change, either, since that’s a part of the core’s display. We could increase the internal res as we’ve discussed, but that’s a pretty crummy solution.
I think there’s a point where, if you’re depending on a bunch of functionality from the MAME frontend, you’re best off using that frontend. However, if all you do is run games through it and want to use RetroArch (or another libretro frontend)'s features instead, the libretro core has you covered.
2 Likes
Is it possible to build a specific MAME version from the latest MAME core from git? Sometimes there are changes in the core that aren’t specific to the latest core and it would be nice if one could build a specific version of MAME with all the latest core bug fixes included.
That’s a good question. I don’t think so, but I could be mistaken. @r-type would know more. If he doesn’t chime in here, you might try making an issue at the libretro-mame repo.
I don’t understand the question , if there is change in latest mame, buildbot will update it .
I think he’s wondering if he can drop in an arbitrary MAME version and have it actually build. That is, could he git checkout libretro-mame, then git checkout regular mame and then merge/overwrite libretro-mame with the regular mame files and expect the libretro bits to still compile?
So the answer is yes .
just checkout libretro mame , setup a remote upstream to mame regular.
then sync the fork, git fetch upstream
and merge git merge upstream/master
then you maybe have to resolve some conflicts
once done and no conflict , build and see if it run ,
if it run you are fine but if not start to digging why 
https://help.github.com/articles/configuring-a-remote-for-a-fork/
https://help.github.com/articles/syncing-a-fork/
https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/
1 Like
Thats exactly what I was envisioning, yes. Thanks for the info. I’ll try muddling around with it for a bit. It certainly would be cool if some enterprising (smarter) person than me figured out how to buildbot versions newer than 0.159 or so. As someone stated above, it’s hard to keep up with romsets as they now change every month. It would be the best of both worlds to get the latest MAME core changes along with the specific MAME version for the romset you have.
hunterk, can you please compile the mame version of 0.185 for us?
I still have and use the 185 core and I would be willing to share it openly if Hunterk and the rest of the devs have no objections to it. Of course I won’t do this without their permission.
Sure, dude, go nuts.
1 Like
Thanks Hunterk, i’m uploading it now to my google drive, I will post a link when it is done.
Here’s the Googledrive link, I will also upload it over on the Launchbox forums for extra backup purposes.
https://drive.google.com/open?id=1MXT4VfuE55uFDZOUpE3B1k_n-h4Vj_7t
1 Like
Thanks. How do I get Breakers Revenge and Buriki One to work? I already have the 185 roms. What’s making them crash retroarch? Do they require specific bios files? If so, which ones?
Breakers Revenge works for me without issues and I couldn’t find Buriki One in my collection to test (I use Launchbox to organize and load my games).
i figured it out, thanks. However, how do you enable overclocking like in the standalone?
The exact same way - press tab and go to slider controls.
1 Like