mamedev
Support for using paths as gamename
If I'm trying to choose a path for the gamename argument for example by executing "mame ./circus.zip" the game doesn't start as MAME claims that files are missing. Maybe MAME could also support using a path for the gamename argument.
This is not how it works. You need to place any roms in the default place "ROMS", a folder where you MAME executable stands. It can be a .zip or a .7z file. If you want another path outside of default, you can manually adjust the mame.ini file and add a ROMPATH entry (with a ; separator) or use the MAME's internal UI to select one: "Configure Options" -> "Configure Directories" -> "ROMs".
On Fri, Mar 11, 2016 at 4:10 PM, Sworddragon [email protected] wrote:
If I'm trying to choose a path for the gamename argument for example by executing "mame ./circus.zip" the game doesn't start as MAME claims that files are missing. Maybe MAME could also support using a path for the gamename argument.
— Reply to this email directly or view it on GitHub https://github.com/mamedev/mame/issues/708.
That said, if you are using a machine which doesn't fall under the normal "mame (setname)" usage, such as a game console, computer or other machine which uses detachable media, you can use a logical path to start those in MAME, as in this example: "mame nes -cart c:\nintendo\nes\super mario 3.nes" (or a .zip/.7z containing that file similarly named).
So arcade games are called with their name and detachable medias with their path if I'm seeing this correct. And this could be maybe made more consistent for example if both variants would support both methods.
You're not seeing it as completely correct ;) All machines (both arcade games and home computers and anything else we support) are launched only referring to their name and the actual files are searched in the correct path. Verified dumps for detachable medias (coming from software lists) are only fully supported as loaded via their names and not via their paths (see e.g. multi-part dumps for NES carts, SNES carts, NeoGeo carts, C64 carts, etc. which cannot be launched through their path unless the different parts of the dump are glued together in one of the not-accurate-to-real-hardware formats), so that you are expected to use the syntax
mame *machine* -media *software*
or the shortcut
mame *machine* *software*
always with "machine" and "software" being the internal name and not the path.
Detachable medias are also supported as launched via their path because you might want to be able to e.g. run your own software on any home computer you have written software for (spanning from ZX to C64 to CoCo to IBM PCs), without adding them to the software list. The fact that some of the items from software lists (notably tapes and floppies) can also be launched from their path is a nice bonus but it is not the intended way to launch them.
Greetings Fabio "etabeta"
On Sat, Mar 12, 2016 at 3:25 PM, Sworddragon [email protected] wrote:
So arcade games are called with their name and detachable medias with their path if I'm seeing this correct. And this could be maybe made more consistent for example if both variants would support both methods.
— Reply to this email directly or view it on GitHub https://github.com/mamedev/mame/issues/708#issuecomment-195749855.
Ok, so then only the support for paths on non-detachable medias like arcadegames is missing which would also be a nice bonus (on testing this I have also noticed that starting a game with its path does show for example "GBA: Detected (ROM) SRAM GBA: Emulate SRAM" a few times and the loading needs a few seconds longer while renaming the file of the game so that it matches the name in the software list and starting it with its gamename skips these steps).
Yes, using a path requires that we detect the features of the original cartridge; when using the software list that information is included in the list.
It's possible to change it so you can load arcade ROMs by path if the set name is given, but I'm not convinced it's a useful feature except for people hacking games. It wouldn't give the ease of use Sworddragon is seeking because you'd still need to know the set name.
It's not feasible to make arbitrary ROM paths to be recognized by MAME as system to execute, it's ID standardized because the alternative would be to identify said ROM with the internal DB and execute depending on what it finds and eventually exposing to UI/UX issues at very least i.e. if the detection outright fails or execute the wrong media, or make it to return a list of possible candidates like Altirra does, which poses the additional question around will the user be smart enough to select various options, or go moaning over the first wrong choice by what sums up in skill issue in not following normal directives?
Also considering that we don't do something of the like with SW lists themselves I'm not sure why we should bother with the harder version first.
