new mame2010 folder structure

[mediamogul]

@markwkidd said in new mame2010 folder structure:

could you possibly tell me what I need to recreate a mame2010 overlay that stopped working?

Sure. I'll continue to use 'Gorf' as an example because I'm familiar with it. Surprisingly, before this update, you really didn't need an artwork file, just the ROM itself. I'm guessing that means that the simulated ranking panel MAME generates is somehow generated from artwork within the actual ROM. However, 'Gorf' does indeed have it's own art file overlay as well that cosmetically completes the rest of the panel. When the standard art overlay is loaded and the game is launched, you can tell that you're intended to see it in the recent update, as the screen has been scaled down by MAME to accommodate the the panel, but everything is just drawn black. So in short, you should really only need the 'Gorf' ROM and art file to test.

[markwkidd]

@mediamogul said in new mame2010 folder structure:

@markwkidd said in new mame2010 folder structure:

could you possibly tell me what I need to recreate a mame2010 overlay that stopped working?

Sure. I'll continue to use 'Gorf' as an example because I'm familiar with it. Surprisingly, before this update, you really didn't need an artwork file, just the ROM itself. I'm guessing that means that the simulated ranking panel MAME generates is somehow generated from artwork within the actual ROM. However, 'Gorf' does indeed have it's own art file overlay as well that cosmetically completes the rest of the panel. When the standard art overlay is loaded and the game is launched, you can tell that you're intended to see it in the recent update, as the screen has been scaled down by MAME to accommodate the the panel, but everything is just drawn black. So in short, you should really only need the 'Gorf' ROM and art file to test.

I am annoyed that the automatic bezel you were getting from just gorf.zip is not working. If we can figure out what that is called and/or how it works I'd like to see that still work the same way.

Here's what I have been able to do to get a bezel to appear:

1. move mame.ini to /libretro saves directory/mame2010/ini (making sure that bezels are set to 1 to be enabled)
2. download the gorf.zip artwork file from Mr. Do's MAME artwork site, place in /libretro system directory/mame2010/artwork

[mediamogul]

@markwkidd

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