new mame2010 folder structure

mediamogul

The mame.ini made all the difference. Both with and without the bezel overlay, the rank panel is visible. I took the time to go a round in the game and after the Gorf flagship is destroyed, the panel did in fact change from "Space Cadet" to "Space Captain". This is very keen!

I do have a couple of questions about the mame.ini file though. It's always been my understanding that RetroArch ignores this file for it's MAME cores, but losing these features after the update makes me wonder if there's an errant mame.ini file it was calling to before. If it did exist, do you have any idea where it was being called from? This is partly out of curiosity and partly as a good housekeeping measure to keep superfluous config files from floating around my system.

Also, the mame.ini is usually generated by MAME at the users request and normally isn't a standard part of a base MAME install. Do I understand you right that this file will be automatically created and placed in the proper location when installing from the RetroPie setup script?

My last question is regarding the directory path settings in mame.ini. I didn't want them to conflict with what is set in RetroArch, so I commented them out, but is this a necessary step, or will RetroArch just override these settings. If that's the case, does RetroArch override any other settings found in mame.ini?

markwkidd

My understanding is that best practice for libretro mame cores is to implement all of the mame.ini options as part of the hardcoded port (as in the folder structure) or as libretro core options. I don't think mame2010 ever made it to that point. @msheehan79 has experienced this as well.

@mediamogul said in new mame2010 folder structure:

If it did exist, do you have any idea where it was being called from? This is partly out of curiosity and partly as a good housekeeping measure to keep superfluous config files from floating around my system.

I think RetroPie-Setup was smart enough to copy the boilerplate mame.ini from the github repository to wherever non-conformant place mame2010 was looking for. I don't understand that part of the RetroPie-Setup script yet.

Also, the mame.ini is usually generated by MAME at the users request and normally isn't a standard part of a base MAME install. Do I understand you right that this file will be automatically created and placed in the proper location when installing from the RetroPie setup script?

That's what it seems to be doing. What I would really like to do is move this functionality into mame2010 itself and spawn a minimal boilerplate into the ini folder only if one doesn't already exist there.

I believe I know how to do that based on my recent mame2003 hiscore work.....

My last question is regarding the directory path settings in mame.ini. I didn't want them to conflict with what is set in RetroArch, so I commented them out, but is this a necessary step, or will RetroArch just override these settings. If that's the case, does RetroArch override any other settings found in mame.ini?

My recent patches means that mame2010 will ignore the paths in mame.ini. I've submitted a patch just now to to the boilerplate mame2010 mame.iniso those parts are omitted.

It should be looked as to whether anything else in the mame2010 boilerplate mame.ini no longer is functioning. This is the boilerplate: https://github.com/libretro/mame2010-libretro/blob/master/mame.ini

See also this issue with information from msheehan79: https://github.com/libretro/mame2010-libretro/issues/81

markwkidd

Closed at least one elderly issue, woohoo! https://github.com/libretro/mame2010-libretro/issues/31

mediamogul

@markwkidd

Very informative. Thanks.

markwkidd

I submitted a new PR to automatically generate and place a shortened mame.ini if there is not one in the ini folder: https://github.com/libretro/mame2010-libretro/pull/94

markwkidd

That PR is approved. From here on, if the user doesn't have a mame.ini, a minimal one will be generated in the ini folder. I hope that it has the necessary settings to keep things functional for everyone while not 'stepping on the toes' of the core options.

I also discovered a pretty fundamental bug that somehow doesn't seem to be causing problems in general. It does however throw up an annoying speedbump to implementing 'hiscore' support in mame2010: https://github.com/libretro/mame2010-libretro/issues/95

estefan3112

@markwkidd Hello there, MAME2010 now compiles in Ubuntu 16.04, but MAME does not start any game. Retroarch crashes and Ubuntu just reports back that This package does not seem to be installed correctly." It was a fresh install of the core in Retropie/Ubuntu. On the same machine, this core works in Retroarch for Linux, as precompiled under the Nightly Core Builds. Would an install log help or shall I provide anything else? Cheers!

markwkidd

@estefan3112 said in new mame2010 folder structure:

@markwkidd Hello there, MAME2010 now compiles in Ubuntu 16.04, but MAME does not start any game. Retroarch crashes and Ubuntu just reports back that This package does not seem to be installed correctly." It was a fresh install of the core in Retropie/Ubuntu. On the same machine, this core works in Retroarch for Linux, as precompiled under the Nightly Core Builds. Would an install log help or shall I provide anything else? Cheers!

If you can please post a pastebin link to the install log as well as the retroarch log when it crashes.

estefan3112

@markwkidd Unfortunately the logfile seems to be too large for pastebin. It is 3.6 MB.
You can download it from there:
https://drive.google.com/open?id=1C779_P_o5kk2kr6WhIAMg2JXv0jDaK4g

This is interesting:
https://pastebin.com/2pf3uPRH
The error tells me that no files are there, but the files are there, they all run e.g. with MAME2003, whily MAME2010 does not find them (in the Arcade folder).

Will dig further

dankcushions

@estefan3112 mame2010 uses a different romset to mame2003. what works in mame2003 will almost certainly NOT work in mame2010. you need to get the right romset.

TillmanZ

Seems like I have the same issue with a newly build lr-mame2010 on an Odroid XU4.
I definitely have a matching 0.139 10yard.zip rom but still the core complains that it allegedly cannot find any of the modules (which definitely are inside the ZIP).
With lr-mame2014 (and a matching rom obviously) it works without any issues.

Any idea what might be causing this?

Best,

Tillman

TillmanZ

I can confirm that the issue is definitely caused by the new build.
I have replaced the core with a known-to-be-working build from a couple of weeks ago and all roms work flawlessly.
Only the new build complains about the missing files (all of them) inside the zip.

Best,

Tillman

markwkidd

@tillmanz said in new mame2010 folder structure:

I can confirm that the issue is definitely caused by the new build.
I have replaced the core with a known-to-be-working build from a couple of weeks ago and all roms work flawlessly.
Only the new build complains about the missing files (all of them) inside the zip.

Best,

Tillman

Thanks. Could you post a log?

TillmanZ

@markwkidd Sure, here we go:

https://pastebin.com/uEAdmUMu

Best,

Tillman

markwkidd

@tillmanz said in new mame2010 folder structure:

@markwkidd Sure, here we go:

https://pastebin.com/uEAdmUMu

Best,

Tillman

That seems like an ordinary missing file type of log. Until these updates mame2010 was looking for files in unpredictable places. Could you make absolutely sure that you have a file with this path and name? /home/pi/RetroPie/roms/arcade/10yard.zip

If you have that file in that location do, could you open up that zip file and confirm it contains these files?

yf-a-3p-b NOT FOUND
yf-a-3n-b NOT FOUND
yf-a-3m-b NOT FOUND
yf-s.3b NOT FOUND
yf-s.1b NOT FOUND
yf-s.3a NOT FOUND
yf-s.1a NOT FOUND
yf-a.3e NOT FOUND
yf-a.3d NOT FOUND
yf-a.3c NOT FOUND
yf-b.5b NOT FOUND
yf-b.5c NOT FOUND
yf-b.5f NOT FOUND
yf-b.5e NOT FOUND
yf-b.5j NOT FOUND
yf-b.5k NOT FOUND
yard.1c NOT FOUND
yard.1d NOT FOUND
yard.1f NOT FOUND
yard.2h NOT FOUND
yard.2n NOT FOUND
yard.2m NOT FOUND

TillmanZ

@markwkidd I can 100% and absolutely confirm that not only this file 10yard.zip is exactly in that folder but also that it includes all of the mentioned modules.

Just to re-confirm - as soon as I replace the core with a core that was build several weeks ago it just works fine.

Best,

Tillman

markwkidd

@tillmanz said in new mame2010 folder structure:

@markwkidd I can 100% and absolutely confirm that not only this file 10yard.zip is exactly in that folder but also that it includes all of the mentioned modules.

Just to re-confirm - as soon as I replace the core with a core that was build several weeks ago it just works fine.

Best,

Tillman

Well dang, it's always nice when the answer is that simple for everyone. This problem hasn't shown up yet so you'll pardon me if I keep making some shots in the dark while I try to narrow things down.

The next most common source of issues in general has been from mame.ini files so I want to check on that. (Next might be .cfg files.)

Do you currently have a mame.ini file in a folder called `libretro saves folder/mame2010/ini ?
If so, is it one you placed there, or was it autogenerated once you updated your core?
If you do have a mame.ini, could you make a backup copy, delete the mame.ini, and try to start 10yard.zip again?

TillmanZ

Actually I don't see the libretro saves folder. Where should it actually be?
I do have a mame.ini in /opt/retropie/libretrocores/lr-mame2010 but I have put it there (trying to fix the loading issue) using a mame.ini from an earlier build.
Because this current build script apparently does not generate a mame.ini file in this folder anymore.
The install_lr-mame2010() function in the lr-mame2010.sh script only copies the mame2010_libretro.so and a README.md file.

Best,

Tillman

estefan3112

@dankcushions I forgot to mention that my Romsets work perfectly in Retroarch with the new MAME 2010 Core, but that the same Roms do not work in the Retropie reincarnation! I also was suspicious of a different romset needed, but since it works perfectly in Upstream Retroarch, this cannot be the case.

markwkidd

Somehow there must indeed be a path issue. I'm working to add more logging to the game loading process to see if we can narrow this down.