[0.171] Is Atari Lynx broken?

Here on Arch Linux with 0.171 version (packaged by distro) I get:

Code:

[zadduk@arch ~]$ sdlmame lynx -cart "/home/zadduk/Downloads/roms/Pac-Land (USA, Europe).zip"
lynx.bin ROM NEEDS REDUMP
WARNING: the machine might not run correctly.
FATALERROR: Device Generic ROM Socket / RAM Socket / Cartridge Slot load failed: Unspecified error

It was working a few versions ago. Can anybody comfirm?

The version for Windows and the lynx driver is still working.
Did you tried the softwarelist instead of the full path?

Hmm, yes, it works via softwarelist...Thanks for that!

But I still think that it is a bug...Every system that I tried works with full path except Atari Lynx.

Just for the record, this bug has been reported here.

Summarizing, MESS does not load lynx headerless roms (like No-Intro ones) via fullpath load, but it does via softwarelist (lynx softlist entries are No-Intro based).
I wrote a patch but it is not accepted, I guess.

You need to submit code through official channels. Patches there may not be looked at or processed in any timely manner.

http://wiki.mamedev.org/index.php/Submitting_Source_Code

nope. lynx headerless rom *CANNOT* be loaded, for the simple reason that different carts use different PCBs that need to be loaded differently.

I'm sure that you managed to load the game(s) you are interested in, but other games will fail and thus your changes cannot be accepted. The only way to really support headerless roms would be to hardcode a database of CRCs of all headerless roms, and it is not going to be accepted

The fault of this whole situation is of no-intro guys who do not explain properly that headerless roms are useless for lynx as well as for nes.

Sorry to disappoint you, but you can only go through adding back the headers or to use softlist.

I think that's being excessively strict. There are under 50 total Lynx commercial ROMs, so it would be quite easy to test if a given fullpath loader is detecting properly.

It's OK, but MESS support lynx headerless roms if extension is '.lyx'. (If you rename a no-intro rom from '.lnx' to '.lyx' works fine).
You can see the code here.

So I merely to tried extend that. What my patch is doing:

Code:

if image has header
  load as usual
else
 load like a softlist rom

So:

Quote:

[...]you managed to load the game(s) you are interested in, but other games will fail[...]

is not true. Header roms works as usual and headerless roms are loaded as softlist ones.

Edit: For the sake of clarity I would like to mention that No-intro roms are exactly the sames as softlist ones, but with different name and extension.

Originally Posted By Zadduk

It's OK, but MESS support lynx headerless roms if extension is '.lyx'. (If you rename a no-intro rom from '.lnx' to '.lyx' works fine).
You can see the code here.

I'm the one who wrote that code, so I'm fully aware of what MAME loading routine supports. But as you can read in the comment to the code, that code which loads games based on their size is just an heuristics which might fail for carts which use different PCBs (Lynx dumps are in a pityful state concerning documentation of the actual cart content, so we don't even know what cart uses what PCB, with the result that games might fail at a very later stage when an unemulated bankswitch is required... unlikely, since Huygens tested most games extensively, but still possible)

the correct fix is to change extension to the files, or to explain no-intro guys that their creating unsupportable sets by removing the header with no advice to the users.

Originally Posted By R. Belmont

I think that's being excessively strict. There are under 50 total Lynx commercial ROMs, so it would be quite easy to test if a given fullpath loader is detecting properly.

tentative fullpath loading is already supported if the user changes the extension to .lyx
maybe no-intro should change extension to their dumps, but extending the heuristics to the format .lnx, which was created to use the header information, is not really a solution IMHO

Originally Posted By etabeta78

Originally Posted By Zadduk

It's OK, but MESS support lynx headerless roms if extension is '.lyx'. (If you rename a no-intro rom from '.lnx' to '.lyx' works fine).
You can see the code here.

I'm the one who wrote that code, so I'm fully aware of what MAME loading routine supports.

Well, you said: "lynx headerless rom *CANNOT* be loaded" so you did not seem "fully aware" to me...

Originally Posted By etabeta78

the correct fix is to change extension to the files, or to explain no-intro guys that their creating unsupportable sets by removing the header with no advice to the users.

But lynx softlist does the same thing!
It creates a set that you can not use via fullpath. Even roms from arcade can be used in that way ('sdlmame /whichever_path/shinobi.zip' works)

I just said that it is inconsistent to say "headerless roms are useless for lynx" and to do the same thing with softwarelist entries.

Err, no, arcade ROMs definitely cannot be loaded by a direct path. MAME has no way of knowing what machine you're using then so it *can't* work.

Originally Posted By etabeta78

tentative fullpath loading is already supported if the user changes the extension to .lyx
maybe no-intro should change extension to their dumps, but extending the heuristics to the format .lnx, which was created to use the header information, is not really a solution IMHO

Just add a check for the header and treat it as .lyx if one isn't present. We need to meet common use cases in the middle, and this seems like a simple and obvious one.

Put another way: this user wants to actually use a non-arcade driver and you're trying to drive them away to Handy instead. That's bad for the project, especially considering how simple the necessary code change is.

Originally Posted By R. Belmont

Just add a check for the header and treat it as .lyx if one isn't present. We need to meet common use cases in the middle, and this seems like a simple and obvious one.

The idea was to see if no-intro would make the most sensible thing by renaming their extension, since it boils down to a search & replace in the datfile...

I don't think they would change it all around just to suit one stubborn emulator. We have to work with what is out there already.

actually, it's not one stubborn emulator. it's the whole meaning of file extensions:
- lnx was for original headered dumps
- lyx was for unheadered dumps

if no-intro tries to impose a faulty standard it's not MAME's fault, and they should rethink their approach.
they tried as well to impose headerless NES roms, which are simply unusable with emus since they miss all the hardware info needed to make them run, with the simple result that they needed to code with Roman a "skip-header in rom manager" workaround to avoid becoming ridiculous

I don't see why the same approach cannot be followed here, or the extension to be changed to .lyx...

the only result as things stand is that people remove header from some .lnx dumps which need it and we potentially lose info until some new dumper spend his time re-dumping the carts

I don't give a shit. Users are in pain, they just know that e.g. Mednafen/Retroarch/Handy runs things fine and we don't. You will not win this argument, either with myself or with No-Intro. Just make it work.

Mednafen doesn't support headerless Lynx ROM images at all.

nor does Handy: see line 84 at http://handy.cvs.sourceforge.net/viewvc/handy/win32src/Cart.cpp?revision=1.2&view=markup
if the header is not present an error is prompted

this leaves 0 chance to retroArch support for headerless roms

I'm not being stubborn here: no-intro are harming information about the dumps with their work, in this case, so they shall be the ones to change not all emulators

Then take the fight to No-Intro if you feel that way.

Originally Posted By etabeta78

nor does Handy: see line 84 at http://handy.cvs.sourceforge.net/viewvc/handy/win32src/Cart.cpp?revision=1.2&view=markup
if the header is not present an error is prompted

this leaves 0 chance to retroArch support for headerless roms

RetroArch support lynx headerless roms: https://github.com/libretro/libretro-handy/pull/17/commits/6b5908e554388b587172490e5db85e34b3656094

Originally Posted By Zadduk

Originally Posted By etabeta78

nor does Handy: see line 84 at http://handy.cvs.sourceforge.net/viewvc/handy/win32src/Cart.cpp?revision=1.2&view=markup
if the header is not present an error is prompted

this leaves 0 chance to retroArch support for headerless roms

RetroArch support lynx headerless roms: https://github.com/libretro/libretro-handy/pull/17/commits/6b5908e554388b587172490e5db85e34b3656094

using unreliable shitty hack code..

but it's RA, so expected.

You either have a database, or you have a header, or you're going to get false positives.

Database approach (aka Software Lists) is preferable for me, allows us to document, in readable text, what is in the cartridges. Allows us to update it, if new information appears, or we're wrong, without forcing everybody to update fake data attached to rom files. Means current 'correct to best of our knowledge' information can always be found in the source.

I think MAME should have a 'cartridge template' model too, so that you can specify a template (defining sram, banking scheme etc.) to load a headerless file into, this would be handy for homebrew development.

I understand that MESS devs don't want to support headerless roms, but then don't use them for your softlist.
And I would understand that, if softlist had information about different PCBs in order to load properly a rom... but right now softlist loads the roms based on their size and the same "heuristics which might fail".

No, softlist loads ROMs based on what the softlist entry in the XML says. This info can and does include all of the information that a cartridge header would contain. MAME NES softlist loading can load and run split headerless ROMs for that reason.

Not true for lynx softlist which entries does not include the information that a cartridge header would contain. Actually the code get the information:

Code:

if (image.software_entry() == nullptr)
{
        [...] // try to get information from header
}
else
{
        if (size > 0xffff) // 64,128,256,512k cartridges
	        m_granularity = size >> 8;
	else
		m_granularity = 0x400; // Homebrew roms not using all 256 banks (T-Tris) (none currently in softlist)
}

that could be improved then.

In that case, that code should be moved for loading headerless images and the the softlist path reworked to get the data from XML.

Originally Posted By etabeta78

the correct fix is to change extension to the files, or to explain no-intro guys that their creating unsupportable sets by removing the header with no advice to the users.

It should be noted that No-Intro supplies a template to use with clrmame pro to ignore the headers when checking the checksum. However, people still remove the headers in order to fill their romsets. This also applies to other systems where the header is ignored but needed like NES.
This is why No-Intro specifies the lnx extension. It is purely the users at fault.