Help batch running arcade games
-
@barbudreadmon Speaking of neogeo games, is there a compability list I could browse?
Especially for neogeo games set in MVS mode, using fbneo.
For instance, I came across kf2k5uni that fails to load.
(I'm using an older build of fbneo and corresponding romset, v0.2.97.44, on the pi400). -
@luckyluca said in Help batch running arcade games:
For instance, I came across kf2k5uni that fails to load.
Any arcade game will fail to load as long as you don't use the right romset, kf2k5uni works in FBNeo. All i can say is to follow the documentation which says to build proper romsets...
-
Thanks, that's exactly what I did, I followed the documentation and cross-checked the version required, against the Package help, which is which is v0.2.97.44. (Fbneo core was installed via source on 05 Nov 2020).
The romset I'm using is supposed to be the full non-merged v0.2.97.44 as per above.I understand this is not up to date, but so is not the core, so I suppose that as long as the two match all should be well.
-
@luckyluca said in Help batch running arcade games:
The romset I'm using is supposed to be the full non-merged v0.2.97.44 as per above.
v0.2.97.44 is the version number we used for nearly 30 months, with probably thousands of changes to the supported romsets, so thinking your download is gonna match your version from 5 nov 2020 without checking it through clrmamepro is very far fetched.
Furthermore, on 5 nov 2020, we had moved past v1.0.0.00, so i have absolutely no idea what a v0.2.97.44 version built from source on that date is supposed to be, a version built from source on that date should probably be tagged v1.0.0.01 -
I might have misread, but from what you write, is it possible to check the source build on 05 Nov against the romset in clrmamepro?
P.s. the romset is checked in Clrmamepro and should be sound as v0.2.97.44. -
@luckyluca when you are updating from sources, retropie is making a local copy of the corresponding dats at
/opt/retropie/libretrocores/lr-fbneo/dats/ -
@barbudreadmon
Many thanks, I wasn't aware of that. I'll cross-reference that against the romsets.Best
L -
@luckyluca - Talk about wack-a-mole! You're kind of reinventing the wheel before ROM management tools came into the scene.
If you're using the "Arcade" folder, in regards to BIOS files, you can dump all the ROMs from multiple core sets into one zip. Take neogeo.zip for example, just rename the "dups" by appending "_core name" or however you want to track them. It honestly doesn't matter though if you named them 1, 2, 3, etc. You'll have one neogeo.zip to run them all. Then just dump it right in with the ROMs and you're good to go for all games, regardless of the core used.
It seems like the next logical step since you're already combining core ROMs when using the Arcade folder. Why not the BIOS files too!
FBNeo requires a few BIOS files:
bubsys cchip decocass isgsm midssio namcoc69 namcoc70 namcoc75 neogeo nmk004 pgm skns ym2608Tracking a DAT for a specific core in time can be tricky. With FBAlpha2012 I've not had a lot of luck. I wrote a python script that compares the DAT to the source code trying to validate the set.
What I found is the DAT posted here has a few hundred extraneous games that don't exist in the source code. On the other hand it also has games in the source code that don't exist in DAT. It needs some work.
I wrote another short script extracting all the games from the source code but ended up with just under 6,000 entries. That is way to many. I found all the games, for all the platforms, the core supports.
I don't know the FBAlpha2012 source code well enough to remove the driver folders that pertain to "other" platforms just leaving the arcade driver folders. If I knew which folders to remove I think I could extract a proper games list and build a proper DAT for the specific version used with RetroPie.
Anyway is there any chance you're willing to share your script? I would be curious at how you're doing it. I would imagine you have ROMs that will work in multiple cores too. Some games just run and look better in certain cores.
I think you'd be much more pleased with the outcome just building sets with the proper tools. Then they are current with any corrections, updates, new games, etc. It's extremely easy with the docs explaining each step. Then as barbudreadmon pointed out with DatUtil and some simple scripting you can build and tailor the perfect set exactly as you like.
Current MAME has like 7,000 to 8,000 unique game sets and probably well over 10,000 actual ROM image sets. If you're trying to cover most games you'll need current MAME thrown into the mix too, I think.
With current MAME and the accompanying rollback set you can build any version of MAME you want. This includes CHDs if you want.
I couldn't imagine running every game with every core trying to figure what game belongs to what core and sometimes multiple cores...whew...that's a puzzle in itself and seems like a lot of work! :-/
-
I'll get back to you soon, but believe me, you don't want to see my code :)
In the meatime, I noticed that all games create a per-game .cfg file in the corresponding sub core folder, automatically, on exit.
e.g.: /home/pi/RetroPie/roms/arcade/mame2003/cfg/
Can you remember what option in retroarch.cfg disables this .cfg per-game autosaving, so that .cfg could be saved manually?
Thanks!
-
In the meatime, I noticed that all games create a per-game .cfg file in the corresponding sub core folder, automatically, on exit.
e.g.: /home/pi/RetroPie/roms/arcade/mame2003/cfg/
Can you remember what option in retroarch.cfg disables this .cfg per-game autosaving, so that .cfg could be saved manually?
this is mame's internal .cfg system with the options as set in https://retropie.org.uk/docs/lr-mame2003/#mame-menu - even if you don't go into this menu it will generate the file with the defaults or whatever.
it's nothing to do with retroarch, as such. in a 'finished' libretro MAME core the whole MAME internal menu and corresponding .cfg structure would be disabled and superseded entirely by RA's UI and files, but RA isn't quite as flexible as MAME's internal configuration in some areas...for now, so the two co-exist, slightly awkwardly.
as far as i'm aware you can't disable it the automatic generation of those files, but it causes no harm, unless you go into the MAME menu and change stuff (if so, delete the game.cfg and/or default.cfg as appropriate)
-
@luckyluca - No worries on the code. I have some code that I am sure no one could follow and other code that's neat and well organized into functions. If it's something I plan to keep and reuse I try to organize and document. If not I really don't care how it looks! :) If you clean it up to the point you deem it worthy of sharing I would grateful and if not that's ok too.
To add to dankcushions description. The *.cfg files are auto-generated when you run a game. They contain things like the controls (inherited and/or explicit), number of coin mechanisms on the machine (are they individual coin slots or a single "communal" one), number of lives, dip switch settings, etc. They may contain/cover a huge gambit of settings and need to be stored somewhere. They can be modified through the menus but they aren't contained in the F2 operator "service mode".
Under the nvram folder you'll find *.nv files. It contains similar information like coins to start, lives to continue, high scores, etc., depending on the game.
I think the difference is nvram files were meant to be consistent across "boots" similar to how the actual arcade machines worked. Basically a service menu used by an arcade operator to set and store certain settings in NVRAM, i.e., if you played to long or scores were to high...BUMP...that difficultly up (you're using to much electricity and not bringin' enough quarters) or possibly down for a charity event or something. :)
Some of the games I tweak the configurations to what we knew/remember back in the day at the arcade or if you have a machine manual it's handy for setting the dips to the defaults. You can find some online.
If you're just testing games and not locked into any configuration structure or settings I would just go ahead and delete both sets of files when you're done if you prefer to keeps things tidy. You can also delete the hiscore files *.hi located in the "hi" subfolder.
-
@riverstorm said in Help batch running arcade games:
If you're using the "Arcade" folder, in regards to BIOS files, you can dump all the ROMs from multiple core sets into one zip. Take neogeo.zip for example, just rename the "dups" by appending "_core name" or however you want to track them. It honestly doesn't matter though if you named them 1, 2, 3, etc. You'll have one neogeo.zip to run them all. Then just dump it right in with the ROMs and you're good to go for all games, regardless of the core used.
It seems like the next logical step since you're already combining core ROMs when using the Arcade folder. Why not the BIOS files too!
FBNeo requires a few BIOS files:
bubsys cchip decocass isgsm midssio namcoc69 namcoc70 namcoc75 neogeo nmk004 pgm skns ym2608I was re-reading your post (which I found extremely useful!). I was wondering what you mean exactly with the above:
Are you referring to extract the content of two bios zip files and zip these again merged into a single .zip file, and append, in the case of duplicate rom names, _SOMETHING to differentiate between them, still within the same zip file?for instance I stumbled across two decocass.zip bioses that differ a lot, one is from fbneo v1.00.01, the other from one of the mame sets.
I'm tempted to take the content of both and put them into a single merged decocass.zip file. Is htis what you meant?Also, would fbneo prioritise bios files found in the bios folder, or in roms/arcade?
Best
L -
@luckyluca said in Help batch running arcade games:
for instance I stumbled across two decocass.zip bioses that differ a lot, one is from fbneo v1.00.01, the other from one of the mame sets.
I'm tempted to take the content of both and put them into a single merged decocass.zip file. Is htis what you meant?
Also, would fbneo prioritise bios files found in the bios folder, or in roms/arcade?Exactly, you got it, if the core(s) supports hash matching.
I'm not sure what you mean by prioritize. It's not doing anything fancy. Basically it's looking at the file hashes, for whatever core you're using. It will try and find the correct files at launch. Each core wants a specific set of files per game.
You can play the shell game and name them 1.rom, 2.rom, 3.rom or whatever you fancy and it will always find the correct one! :)
-
Probably a tricky question:
I have a bunch of bios files in RetroPie/roms/arcade, used by mame cores.
I also have some legacy bios files in the ~/RetroPie/BIOS folder.If I put the correct fbneo specific bios files in the ~/RetroPie/BIOS/fbneo folder,
Would fbneo get confused by the (wrong) bios files found in the other folders first?
Do you reckon would Fbneo open them all up and use hashes to find and use correct roms?Many thanks
-
@luckyluca -That's close. It should look in the ROM folder first followed by the BIOS folder, it might be the other way around but it's irrelevant. It's looking for an exact match based on the hash from the code (so you can't force a priority of which BIOS version to use based on search order). Don't worry about confusing it either, it will find the correct file(s) or not based on the "search path".
I like to keep it simple, one neogeo.zip in with the ROMs. I can run FBNeo NeoGeo games, as well as, mame2003-plus NeoGeo games (that require different versions of NeoGeo). It's pretty straight forward just give it a go and do some play testing.
-
I tested it, location of the bios files shouldn't matter, the correct one appears to be picked up regardless.
-
@dankcushions
Quick question, what is the difference between .fs and .nv files in the roms/arcade/fbneo folder?Many thanks!
-
@luckyluca said in Help batch running arcade games:
what is the difference between .fs and .nv files in the roms/arcade/fbneo folder?
Basically the same thing (non-volatile ram to save cabinet settings), just different methods to save them.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.