cheat.xml and CPU tags

[angelosa]

While developing for Teradrive and using the SW list there's something kinky going on:

./mame teradrive -cart dashdes
Ignoring MAME exception: megadriv/dashdes.xml(5): error parsing cheat expression "maincpu.pb@FFD503=99" (unknown symbol)

megadriv/dashdes.xml(5): error parsing cheat expression "maincpu.pb@FFD503=99" (unknown symbol)

Ignoring MAME exception: megadriv/dashdes.xml(11): error parsing cheat expression "maincpu.pw@FF8946=0999" (unknown symbol)

megadriv/dashdes.xml(11): error parsing cheat expression "maincpu.pw@FF8946=0999" (unknown symbol)

Ignoring MAME exception: megadriv/dashdes.xml(17): error parsing cheat expression "maincpu.pb@FF89C2=01" (unknown symbol)

megadriv/dashdes.xml(17): error parsing cheat expression "maincpu.pb@FF89C2=01" (unknown symbol)

Ignoring MAME exception: megadriv/dashdes.xml(23): error parsing cheat expression "maincpu.pb@FF8A22=01" (unknown symbol)

megadriv/dashdes.xml(23): error parsing cheat expression "maincpu.pb@FF8A22=01" (unknown symbol)

[LUA ERROR] error in machine reset callback: plugins/cheat/cheat_xml.lua:83: attempt to index a nil value (field '?')

I gather that the cheat engine searches for a tag named maincpu (that is, the one that normal megadrive/genesis uses), but this falls short for something like teradrive (where there isn't a maincpu but rather a md68kcpu) and presumably megapc later on (where the MD 68k lives on an ISA backplane, so it will be isaX:<main>cpu anyway)

I'm not sure who's at fault here, is it a pure cheat engine bug or there's something that MAME can do around cheat_script::script_entry::script_entry?

[cuavas]

I don’t think there’s anything you can really do. It’s always been a problem for software that can run on multiple systems. The cheat file doesn’t represent the “three degrees of freedom” (system, software list, software item), and if it did, that would mean making separate sets of cheats for each system the software runs on.

[PugsyMAME]

Yes as Vas said, it would need separate cheats (which I'm happy to provide in cheat.7z for some problematical systems if there is a need/call for them)

In the teradrive example this could be done by looking for a cheat in the machine basename before looking at the swlist name.
In the non plugin cheat engine this could be done by editing cheat.cpp
Replace:

			if (image.loaded_through_softlist())
			{
				load_cheats(string_format("%s" PATH_SEPARATOR "%s", image.software_list_name(), image.basename()));
				break;
			}

With:

			if (image.loaded_through_softlist())
			{
				load_cheats(string_format("%s" PATH_SEPARATOR "%s", machine().basename(), image.basename()));
				if (m_cheatlist.empty())
					load_cheats(string_format("%s" PATH_SEPARATOR "%s", image.software_list_name(), image.basename()));
				break;
			}

It's an imperfect solution/workaround but maybe better than nothing.

Also as it stands some swlist xml names would be an issue, as there seems to be a inconsistency of how they are named.
If there's a single swlist for a system then systemname.xml seems fine but if there are multiple swlists then they
should possibly follow the sytemname_imagetype.xml convention.

For instance a800 & a800_flop both have "zaxxon" and it would mean that the a800/zaxxon.xml cheats would be applied
to the floppy version as well. For consistency a800 should possibly be a800_cart, the same way the 3 c128 swlists are named.

[cuavas]

Just using the system name won’t help because the same item name can be present in multiple software lists, and then you get the issue that for marginally different systems, (e.g. NES and Famicom) it won’t find the cheats from any of the clones.

[PugsyMAME]

Maybe there's a bigger picture I'm missing but...

I don't understand with the above minor change I posted the nes cheats from the cheatfile (eg nes/gradius) still work with the famicom.

The possible issue that I mentioned with the swlist names I can fix by replacing the existing code with this instead:-

			if (image.loaded_through_softlist())
			{		
				load_cheats(string_format("%s-%s" PATH_SEPARATOR "%s", image.software_list_name(), machine().basename(), image.basename()));
				if (m_cheatlist.empty())
					load_cheats(string_format("%s" PATH_SEPARATOR "%s", image.software_list_name(), image.basename()));
				break;
			}

If it's a swlist entry it tries to load
swlistname-systemname/gamename.xml (eg nes-famicom/gradius.xml or megadriv-teradrive/dashdes.xml)
if it loads no cheats or comments because there is no xml file it then tries to load
swlistname/gamename.xmll (eg nes/gradius.xml or megadriv/dashdes.xml)

The only issue I can see is that this only applies to the built-in cheat engine, the plugin cheat engine would need a similar fix.

I can add a megadriv-teradrive/ folder in the cheat collection with working cheats.
Obviously I wouldn't need to add any "-famicom" folders as the existing nes cheats work fine.

I can make the changes to the cheat collection for teradrive and other systems that are brought to my attention.