Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
02188 Cheat System Critical (emulation) Always Aug 31, 2008, 22:21 Sep 14, 2008, 00:13
Tester Fujix View Status Public Platform MAME (Self-compiled)
Assigned To aaron Resolution Fixed OS Windows XP/Vista 32-bit
Status [?] Resolved Driver neodriv.hxx
Version 0.127u1 Fixed in Version 0.127u3 Build I686
Summary 02188: Many sets in neodrvr.c: Freeze on start up with a Work RAM Error.
Description The game stop on start up what an work ram error.
Steps To Reproduce vliner, vlinero, lastbld2
Additional Information
Regression Version
Affected Sets / Systems Many sets in neodrvr.c
Attached Files
related to 02189Resolvedaaron gradius4: C'ant pass Setup 
related to 02177Resolvedaaron All lethal.c sets: T 4 EEPROM error(BAD) 
has duplicate 02166Resolvedaaron garou and clones: Work RAM Error 
related to 02200Resolvedaaron galaga: Locks up 
User avatar
Sep 1, 2008, 04:23
edited on: Sep 1, 2008, 04:26
Sadly, this is a problem the XML Cheat. Might want to let Pugsy know about the problem. Doesn't error if you don't have the XML for that game being used. Same behavior as 02166. The same solution of "Skip RAM/ROM Checks" applies..
User avatar
Sep 1, 2008, 09:22
Hah, I'm not qualified to be a decent Tester ;)
User avatar
Sep 1, 2008, 15:12
It happens to all of us once in a while. Some people, though, it happens ALL THE TIME. Those are the bad noodles. :D
User avatar
Sep 5, 2008, 13:17
Reopened to allow input from users.

Apparently from what I was told by Pugsy - this is a side effect of the using the new (min/max/step) value parameters in a cheat. There is no function in the cheat engine currently to stop the cheat from poking a value even if the cheat hasn't been selected.
 	<cheat desc="Select Constant Line A Bet">
 		<parameter min="0" max="10" step="1"/>
 		<script state="run">
This above will immediately adjust the RAM for a game, without choice. Since this (min/max/stop) functionality in a cheat cannot be in an initial OFF state, it seems to trigger many games' RAM/ROM tests and causing many false reports here in MAME Testers.

Is there default="off" flag that can be added or something similar so that cheats like this must be explicitly activated by the user?
User avatar
Sep 5, 2008, 13:21
edited on: Sep 5, 2008, 13:38
a solutions was posted few days ago by ShimaPong. not sure


could be an elegant solution for cheats which have to be turned off

<mamecheat version="1">
	<cheat desc="Select Teritory">
		<parameter default="1">
			<item value="1">Off</item>
			<item value="0x80">Arcade (MVS)</item>
			<item value="0">Neo Geo (Home)</item>
		<script state="run">
			<action condition="param != 1">main.pb@10FD82 = param</action>

you can use 1 or any other value you don't need to poke into the location
User avatar
Sep 5, 2008, 14:00
edited on: Sep 5, 2008, 14:10
Etabeta, thanks but neither of them is relevant, ShimaPong is merely "discovering" what I already know. All the 'list' select cheats in the xml files already have an "Off" option.

<cheat desc="Select Cartridge/NeoGeo Type"> <comment>Enable it DURING the neogeo bios booting sequence. If you miss the boot sequence reset and THEN enable it. The Home (NEOGEO) setting is unlikely to have any effect as there was no HOME version.</comment>
			<item value="00">Off</item>
			<item value="01">Arcade (MVS)</item>
			<item value="02">Home (NEOGEO)</item>
		<script state="run">
			<action condition="(param==01)">main.pb@10FD82=80</action>
			<action condition="(param==02)">main.pb@10FD82=00</action>

This is done in a slightly different manner than the method you quoted because the method I used can be easily automated and will work for ALL 'list' select cheats whilst the other method won't work for all possibilities as it stands.

However, the problem is with the "min/max" select cheat and for that it pokes the minimum value regardless so when it does the 55/AA test it will fail.

If there is a cheat.xml related solution other than converting all "min/max" select cheats to "list" select cheats I will happily implement it . But I think the best option is for there to be a "Off" option coded into the cheat engine for "min/max" select cheats.

I may have to implement the "list" option...but it does rather make the work for the min/max/step and tobcd/frombcd functions somewhat wasted.
User avatar
Senior Tester
Sep 5, 2008, 14:14
Allowing cheats to be enabled by default (and with no way to disable them) is a poor design decision, and on-par with the mess hiscore.dat caused.

I suspect this will be rectified, no cheat should be active without the user setting it to be so on a per game basis. Allowing them to then save the cheat file so that it's activated next time would be fine, but causing problems silently is bad.
User avatar
Sep 5, 2008, 14:59
If people want to use -cheat on the commandline (or cheat 1 in mame.ini), I don't see why they should also "activate" the cheat engine. It's the same thing as when you use -debug on the commandline (or debug 1 in mame.ini) and the debugger always open at start without doing anything else.

Now the question remains about how to deactivate the "select value" cheats.
User avatar
Sep 5, 2008, 17:36
Poorly written cheats can affect things from the start, yes. I guess we need an explicit Off state for value cheats. While we're there, I might as well build in a default Off state for item cheats as well, to make the behavior consistent.

For these type of cheats, the "Off" state will be triggered when off is selected (and this will be the default). The "Change" state will be triggered when the value is changed (even if previously off). There will be no trigger for the "On" state for these cheats; it is either "Off" or "Change".
User avatar
Sep 5, 2008, 18:56
I'm OK with having a default "Off" item, be it for lists or user-select values.

The things I'd like to know are :

1) Will it be possible to trigger the "on" state once when changing from "Off" to anything else ? This is required for ROM cheats where we need to backup some data in memory.

2) Will it be possible to return to the "Off" status (and then trigger once the "off" state) ? This is required for ROM cheats where we need to restore to initial memory contents.

3) Will we need to have a condition in the "run" state or does "Off" imply that the "run" state is never triggered ?

'galaga' IMO seems to be "best trickiest" thing you can find (ROM cheat + user select value), so if you manage to get this cheat running correctly, other cheats won't be as problematic.
User avatar
Sep 5, 2008, 19:24
1. I could make it so that changing from "Off" to anything else triggers "On" first, followed by "Change". Or it could just be "On" by itself.

2. Yes, you can return to "Off". When you select Off in the list, it will trigger the "Off" state.

3. No, "Run" will only be executed if the cheat is not Off.
User avatar
Sep 5, 2008, 19:51
1) I would say "On" then "Change", but I'd like to have Pugsy's opinion first.
User avatar
Sep 5, 2008, 22:14
edited on: Sep 5, 2008, 23:05
I agree pretty much in the above, in that:

"on" should be triggered when OFF is toggled off
then "change" or "run" is done
"off" should be triggered when OFF is toggled again

If the item cheat functionality is also going to be effected we still need to use "run", otherwise perm. type select cheats will become one-shot. "change" should just be used just for one-shot select cheats.

Off-topic slightly, I've been quite disappointed in the select cheats with the fact they don't operate as i'd hoped in that:-
1. There's no way of telling the difference between a perm and one-shot select cheats (maybe for one-shot change cheats the OFF should be SET?
2. Pressing ENTER on any of them will return the selection to the first option (regardless if it's perm. or one-shot) which can be a massive PITA.
3. There's no wraparound for select cheats in that if you have 15 options and you want to enable say weapon 15 followed by weapon 1 you have to press right 15 times and press left 14 times, rather then press left once and right twice.

On a unrelated matter, any chance of adding a condition to the "run" script so that it will effectively turn the cheat OFF when the condition is false as it would be the only way of making one-shot "Wait for Modification" cheats work properly. I've been manually changing many to different cheat types to do things differently and generally better but there's going to be hardcore of cheats that will be better as they are. Ideally "run" cheats with conditions should display Set rather than Off.

eg. <script state="run" condition="temp9!=1">
User avatar
Sep 6, 2008, 22:32
Okay, it is done as described above. "Run" is only executed if the cheat is not in the off state. All value cheats have an off state now.

I don't understand the rest of your complaints entirely. You are using terminology that confuses me.

1. A cheat that has only an "On" state is treated as a one-shot and the text is displayed as "Set" already. You must be referring to something else. You will have to explain what that is.

2. I changed this so that you press IPT_UI_CLEAR (normally Del) to reset a cheat to its default state. Also, value cheats no longer have a default value, they default to Off.

3. Sorry the lack of wraparound is annoying but I don't see why the cheat menu should behave any differently from any other menu in MAME. It is valuable to know what the first and last values are. And there is autorepeat on the left/right keys if you have to go through a lot.

Regarding the last point, I think always changing a conditional run cheat to Set is making a lot of assumptions about the behavior. If the cheat has to wait for something to happen before it activates, the user should have some mechanism to turn it off if that condition never occurs. For that reason, these should be on/off cheats and not be confused with set cheats which have a different behavior.
User avatar
Sep 8, 2008, 15:57
edited on: Sep 8, 2008, 15:57
Updated all related bugs "Cheat System" category.
User avatar
Sep 10, 2008, 18:55
I'm assuming this is resolved for U3. If so, Aaron, please assign this fixed/resolved.
User avatar
Sep 14, 2008, 00:13
Thanks for the changes. I've updated the xml files to remove the hardcoded OFF options.

1. List cheats that use script state="change" are one shot cheats but they have a default displayed value of 'Off' rather than 'Set' whether of list type (eg aof2) or range type (eg 1945kiii).

2. Thanks

3. The 'Off' (+ hopefully 'Set' {see 1}) should adequately mark the first and last values. The wraparound feature for list cheats can be handy even when the menus are not displayed - if activation key support is added. A good example would be tetris - where a list cheat is used for the shapes pressing R could increment the shape but without wraparound it would require two activation keys one for left and one for right. The old cheat engine supported two activation keys for this reason but it was still possible just to use one because of the wraparound.

On the last point, I'm not saying 'always changing a conditional run cheat to Set' is a good idea either. A "run" script would always activate if there is no condition specified, however there are occasions where that behaviour is needed and there needs to be an element of trust in the person creating the cheat. 'wait for modification' is an advanced cheat and I've only ever seen it used by people who know what they are doing. The complexity of the new xml cheat format if anything is going to make sure only a VERY limited number of people will create cheats with it and the lack of this functionality is a limitation. But, if the capabability of the user to switch such cheats off before they activate then my ideal of "run" cheats with conditions displaying Set rather than Off is a non-starter - but the loss of that 'ideal' is probably no biggie.