General Mame Debugger Questions

[Abystus]

Is there a way to lock the value at an address through the debugger?

I know that maincpu.pb@123456=10 will poke the value once, but the value will not lock in place like if it were turned to the on position within the cheats menu. I find it cumbersome to continually modify the xml associated with the game to achieve this result, which is the reason I'm asking. I was also asked this question today by a fellow hacker, but could not give him a definite answer (other than modifying the xml).

Is there a way to allow controller input in-game while the debugger window is in focus?

I usually use the method of watching the addresses that write to the coordinate addresses while the character moves in game to make a walk through walls type code, but find this method impossible due to MAME not allowing (by default) controller input in-game while the debugger is focused.

[Pugsy]

You can lock a poke to a breakpoint (doesn't work with watchpoints for some reason) with a command like this example for space invaders:-

bp 1a87,1,{maincpu.pb@21ff=7;g}

You will obviously need to find a suitable code address to bp though.

As far as I know there no way to automatically to give priority to a game window when the debugger window is open other than selecting it with the mouse.

[Abystus]

I would have thought there was a param to make the poke constant, but I guess there isn't. The breakpoint trick is neat, but then again the game would be stopping every time it broke (which would get rather annoying). I guess the XML is really the only way to make it happen without hiccups. Btw, how do you go about hacking your walk through walls in Mame since the debug window steals input? Thanks for the detailed response.

[Pugsy]

I would have thought there was a param to make the poke constant, but I guess there isn't. The breakpoint trick is neat, but then again the game would be stopping every time it broke (which would get rather annoying). I guess the XML is really the only way to make it happen without hiccups. Btw, how do you go about hacking your walk through walls in Mame since the debug window steals input? Thanks for the detailed response.

No the game won't stop every time it reaches the BP...that's what the ';g' in the expression is for - it will automatically hit the breakpoint, poke the value and continue (GO) the game without entering the debugger. Try it in Space Invaders to see it in action. Personally I use the XMLs and reload to test stuff, at some point I must looking at adding a few new debugger commands to make it easier to test stuff.

I rarely use F5 in the debugger - I use F12 so I don't get to see the debugger window. I'm just quick with ` and then use the TRACE file.

[Abystus]

No the game won't stop every time it reaches the BP...that's what the ';g' in the expression is for - it will automatically hit the breakpoint, poke the value and continue (GO) the game without entering the debugger. Try it in Space Invaders to see it in action. Personally I use the XMLs and reload to test stuff, at some point I must looking at adding a few new debugger commands to make it easier to test stuff.

I rarely use F5 in the debugger - I use F12 so I don't get to see the debugger window. I'm just quick with ` and then use the TRACE file.

The BP poke trick should come in handy (until something better gets implemented). Maybe in the next implementation of the debugger, it could have cheats (maincpu. variations) grouped into a collection like it does the BPs/WPs to where you could list them, enable, disable, or delete. Possibly a param could be added to these variations with a "state" in mind like the cheat xml supports (ex: "maincpu.pb@123456=14, r" where r would be "run", or with the parameter excluded would poke once and not be added to the collection list).

Also there needs to be a way (haven't seen this in any debugger yet), to ignore an address writing to, or reading from a ram address (ex: the movement routine will continually write to the coordinate addresses until either you hit a wall, a second address writes a stop value, or the write gets branched over), where you could specifically ignore (don't break on) a known read/write. This ignore list could be it's own collection similar to the current BP/WP system in place (options similar to the above cheat example). Having this option would allow you (in the listed example of WTW) to freely move until something else wrote/read from the address, allowing the user to get around the focus stealing issue. If nothing wrote, you could just disable the ignore on that address to examine what is happening (ex: a branch over, or a constant write where something above it is determining if your coordinate value should change or not)

Overall I'm very pleased with the debugger (with a few gripes about testing codes, and the interface stealing focus from the game), and hope to master it like every other debugger I have used in the past. Thanks for your continued feedback on the issues at hand.

[Pugsy]

Also there needs to be a way (haven't seen this in any debugger yet), to ignore an address writing to, or reading from a ram address (ex: the movement routine will continually write to the coordinate addresses until either you hit a wall, a second address writes a stop value, or the write gets branched over), where you could specifically ignore (don't break on) a known read/write. This ignore list could be it's own collection similar to the current BP/WP system in place (options similar to the above cheat example). Having this option would allow you (in the listed example of WTW) to freely move until something else wrote/read from the address, allowing the user to get around the focus stealing issue. If nothing wrote, you could just disable the ignore on that address to examine what is happening (ex: a branch over, or a constant write where something above it is determining if your coordinate value should change or not)

If I'm understanding you correctly you can do that now, BP and WP are very powerful.

For instance if you want to watch writes on 21ff but ignore the writes that performed by the code at 7d4 (and so it would normally break at 7d7) then type this:-

wp 21ff,1,w,pc!=7d7

you can gang lots of writes to ignore by simplying using &&
wp 21ff,1,w,pc!=7d7 && pc!=990 && pc!=aa0

and of course you can add other conditions so that it only breaks when certain values or a ranges of values are poked

wp 21ff,1,w,pc!=7d7 && pc!=990 && pc!=aa0 && wpdata>2 && wpdata<6

pretty much any C type expression will work

[Abystus]

Also there needs to be a way (haven't seen this in any debugger yet), to ignore an address writing to, or reading from a ram address (ex: the movement routine will continually write to the coordinate addresses until either you hit a wall, a second address writes a stop value, or the write gets branched over), where you could specifically ignore (don't break on) a known read/write. This ignore list could be it's own collection similar to the current BP/WP system in place (options similar to the above cheat example). Having this option would allow you (in the listed example of WTW) to freely move until something else wrote/read from the address, allowing the user to get around the focus stealing issue. If nothing wrote, you could just disable the ignore on that address to examine what is happening (ex: a branch over, or a constant write where something above it is determining if your coordinate value should change or not)

If I'm understanding you correctly you can do that now, BP and WP are very powerful.

For instance if you want to watch writes on 21ff but ignore the writes that performed by the code at 7d4 (and so it would normally break at 7d7) then type this:-

wp 21ff,1,w,pc!=7d7

you can gang lots of writes to ignore by simplying using &&
wp 21ff,1,w,pc!=7d7 && pc!=990 && pc!=aa0

and of course you can add other conditions so that it only breaks when certain values or a ranges of values are poked

wp 21ff,1,w,pc!=7d7 && pc!=990 && pc!=aa0 && wpdata>2 && wpdata<6

pretty much any C type expression will work

Very handy information there Pugsy. I know how I'll be hacking my WTW codes (or any other codes that I have to fight constant writes/reads) from now on. Btw, was this documented somewhere? Maybe I just overlooked it in the help documentation within the debugger? I am planning to write a guide on these obscurities so that they are well known to the community at some point. Thanks again for all your help.

[Pugsy]

It's all in the debugger help system

type
help wpset
and
help bpset

[RedBeam]

tip
Try to go next to the wall. pause mame, switch to dbg
type
trace walk.txt,0
then walk until you hit the wall, then pause again and type
trace off,0
then if you examine a bit the cycles, it should be visible when it changes... search for a recurrent line until the flow changes.
I made a useful cpp prog that finds rows that repeat for n times into a txt file, that is super useful when analyzing traces!