Memory Breakpoints?

[Milgar]

Hi, I just started using Dolphin primarily for its debugging purposes, but I am finding it is quite difficult to find relevant memory locations in games. The debug mode has breakpoints but as far as I can tell these are only for instructions, not memory. Am I missing something or is there no way to find important memory addresses without stepping through the ASM? If not, then I would suggest adding this as a feature as it is pretty invaluable.

Similarly, to help facilitate finding important memory locations, a comparitive memory search feature would also be very useful. For example, I know a variable changes every frame, but I don't know its value. By doing a "not equal" search of the memory every frame for a few frames I could quickly find this variable. Other emulators with debugging have this, and it makes it much easier to find memory addresses for known variables.

Sorry that this post became more of a feature request, I'm mostly just asking if there is a better way to find the address of a variable with known behaviour (such as changing every frame) without having to step through the ASM. I tried to do it, but it just took way too long to advance even a single frame.

[ector]

Yeah, at a rate of 8.1 million instructions per frame (486MHz/60) or 12 in the case of Wii, there's no hope of finding stuff that way :p

There are currently no memory searching facilities in Dolphin. Feel free to add them though.

[Milgar]

Okay, well I downloaded the code and made some pretty rough hacks but was able to find the address I needed by doing comparitive memory searches (if anyone wants the code I used I'll post it).

Now that I know the address I want I would like to see how the game changes it, and the best way would be to break when the emulator tries to read or write to the address. I made another hack that breaks whenever the templated "ReadFromHardware" and "WriteToHardware" functions from MemmapFunctions.cpp are called with the address I'm interested it, however this did not work. I'm not sure if its because the internal address the emulator uses is different from the one displayed (I've tried the standard address and the address + 0x8000000) or if it is becuase these functions aren't the only ones used to do reads and writes. If someone could clarify this for me that would be great.

Incidently, while browsing through the files I noticed there was disabled code that allows memory breakpoints to be added via the breakpoint window. I enabled it by adding "#define ENABLE_MEM_CHECK" to Common.h, which made it so even the necessary GUI elements showed up, however it doesn't seem to fully work (perhaps this is why it was disabled). Does anyone know what needs to be done to get the "TMemCheck" class from Breakpoints.h to work or why it was disabled? It seems that most of the hard work is completed so it would be a shame to leave the code unused.

[Chaoscode]

you can post a patch here if you like.

[shuffle2]

er, if you build the debug (or probably much preferred debugfast) build, the memchecking will be compiled in. Then you can take advantage of the breakpoints dialog in the ppc debugger, which offers memchecks as well as code address breakpoints. (dsp lle debugger always supports breakpoints on code addresses)

[Milgar]

(07-24-2009, 01:23 PM)Chaoscode Wrote: you can post a patch here if you like.

Okay, the attached file is a patch for the code I wrote (rename from .txt to .patch). Bear in mind that I quickly wrote it as a simple hack to find the address I was interested in, so it is far from elegant. Because Visual C++ Express doesn't have a resource editor and I didn't want to waste time looking for one I hooked the code to the memory window's "Dump Memory" button. As a result this button won't dump RAM like it should- however, there seems to be a bug with this feature anyway because whenever I try to use it Dolphin crashes after writing the file.

The way the code works is when you want to initialize your comparitive memory search, you first press the "Dump Memory" button when viewing the memory as RAM. The next time you press it, a file will be generated in Dolphin's base directory called "MemDiff.txt". It will contain a list of all memory addresses up to 0x13FFFF (this was the highest I found to be applicable to the game I was running, I am unsure if other games use more address space) that have changed since the previous press of the button, in the format of "(Address)Old Value)->(New Value)". Every subsequent press will remove addresses that haven't changed since the last search.

If someone wants to use my code to build a full-fledged comparitive memory search for Dolphin, be my guest. Of course, it should not be hooked to the "Dump Memory" button, but rather have its own window. I would suggest using a listbox to display the current memory addresses and values that match the search, along with their old values (as opposed to writing them to a file). It should have "New Search" and "Continue Search" buttons, as well as radio boxes for selecting the comparison method (==, !=, >=, etc). Additionally, it would be a good idea to add a text box that would allow you to search against an entered value rather than the old value. To reduce wasted resources, the memory addresses and old values should be stored in a linked list (rather than a giant array), and every time one is removed have it be deleted from the list.

(07-24-2009, 01:47 PM)shuffle2 Wrote: er, if you build the debug (or probably much preferred debugfast) build, the memchecking will be compiled in. Then you can take advantage of the breakpoints dialog in the ppc debugger, which offers memchecks as well as code address breakpoints. (dsp lle debugger always supports breakpoints on code addresses)

Well I compiled the DebugFast version however the memory breakpoints were not included by default. I could still enable them by adding "#define ENABLE_MEM_CHECK" in Common.h as I did with the Release version, however I don't know if they would work or not as the current DebugFast version won't emulate beyond the first frame. The current Debug version won't compile at all for me (this was also the case for DebugFast initially, however after a few SVN updates it worked).

Is it really true that the Release build is different than the Debug build in terms of the functions they use for memory? I ask because like I mentioned in my last post I added a hack that would cause the emulator to break when the functions "WriteToHardware" and "ReadFromHardware" in MemmapFunctions.cpp were called with the address I am interested in, which didn't work. I admit I'm just beginning to learn how Dolphin works, but it seems to me the Release version would still be using these functions.

[omegadox]

One of my plans was to add a AR Code generate with the ability to scan ram like in Cheat Engine, may be years till I start working on it.