I did a very basic cheat search engine, it is not intended to be anything final (It would really be bad right now).
I'm attaching this here so whoever interested on fixing and adding things to it can do so.
Ok, let's see if we can help close the oldest open issue so far.
======== Basics
The search engine is currently done on the Dolphin Memory window that shows up when we start in Debugger mode.
It works by comparing two main ram dumps, byte by byte. This is the main reason of being slow.
Before starting any kind of emulation, take a look at the Memory window, there a new buttons and text boxes, brief description ahead:
Search Combobox: Pick a search criteria.
Search Parameter: (HEX format) Used for value related searches.
Search Button: Perform a search.
Reset Button: Destroy previous search records, perform a new ram dump.
Ignore Address: Memory address in the 'Seek' box will not be searched in the future
Ignore Selected: The 4 addresses selected in the main box will be ignored.
10 Empty text boxes: After performing a search, the first 10 results will be displayed here.
Refill Button: Refill the 10 text boxes, useful after manually ignoring any of the first 10 addresses.
======== Usage
I strongly recommend disabling Dual Core mode here.
Reset to perform a new main ram dump and delete old records.
Choose a comparison criteria, the first 6 choices will compare new and old memory, the second 6 will compare new memory with the written parameter, the other 2 will compare both old and new memory with a parameter into account.
Unfortunatly, the first search will take up to 3-5 minutes, the button and the whole Memory window will lock up, so be patient.
A 'non-equal' search is proved to discard the highest amount of unneeded memory addresses at a time, so I recommend finding a way to perform a non-equal search in the first place.
Following searches will keep filtering the amount of hits, the less hits, the less time searches will take.
The addresses of the very first 10 hits every search produces will be displayed in the empty boxes, they are editable, just to allow easy select'n copy.
======== Logic
This one needs changes.
When performing a search:
Check for primary ram dump, if exists, create a secondary ram dump.
Create or read a reference table file, this file is a duplicate of a ram dump, where instead of storing actual ram data, stores yes/no switches (check address: 00, ignore address: 01)
This file tells the engine what memory regions have already been searched and failed our criterias, when we manually ignore an address, it will be marked as 01 as well.
Then the an optimization (not really) file is loaded, and a second one is written.
The first one (loaded) contains directives made by a previous search which tells the engine to skip huge amounts of useless iterations (because they will always check on 01 areas) VASTLY reducing search time, of course, on the first search, this file does not exist.
The second one (written during search) counts the amount of consecutive failed hits (01 byte in table), if it reaches a considerable amount before hitting a positive (00 byte), a directive will be written to this file.
Directive format, as seen in a HEX editor:
XX XX XX XX YY YY YY YY
XX XX XX XX YY YY YY YY
X's represent a u32 value which is the START address
Y's represent the END address
When START address is reached, the main search iterator will jump to END address, after all, everything between those are already marked as 01.
Right now, the minimum amount of consecutive 01's required to create a jump is 1000, you can change that til you get the best results.
Once the search is finished, the primary ram dump file is deleted and the secondary ram dump will become primary.
The reference table stays there till you reset.
The old and already read 'optimization' file gets deleted, the new one will be read next time and so on.
======== Problems
I don't understand wxWidgets, the result of it, an awful Memory Windows. Please take a look at it.
Speed, checking directly from RAM instead of a secondary ram dump would be great and faster, the only thing that worries me is that the main RAM would keep changing, even in the middle of a search (Auto pause/search/play anyone?).
Can the reference table be replace with something more efficient? Or smaller? The reference table is as big as a full ram dump!
Would reading the table in big buffers speed up things?
Ignore selection is currently not working.
Search modes (XX, XX XX,...) not working, only searches in XX.
The coding here is horrible, expect your eyes to get hurt while trying to understand it.
Don't worry, I left plenty of (un?)helpful comments.
Also, someone fix the AR patcher for Wii games! My newfound codes aren't working at all.
I'm attaching this here so whoever interested on fixing and adding things to it can do so.
Ok, let's see if we can help close the oldest open issue so far.
======== Basics
The search engine is currently done on the Dolphin Memory window that shows up when we start in Debugger mode.
It works by comparing two main ram dumps, byte by byte. This is the main reason of being slow.
Before starting any kind of emulation, take a look at the Memory window, there a new buttons and text boxes, brief description ahead:
Search Combobox: Pick a search criteria.
Search Parameter: (HEX format) Used for value related searches.
Search Button: Perform a search.
Reset Button: Destroy previous search records, perform a new ram dump.
Ignore Address: Memory address in the 'Seek' box will not be searched in the future
Ignore Selected: The 4 addresses selected in the main box will be ignored.
10 Empty text boxes: After performing a search, the first 10 results will be displayed here.
Refill Button: Refill the 10 text boxes, useful after manually ignoring any of the first 10 addresses.
======== Usage
I strongly recommend disabling Dual Core mode here.
Reset to perform a new main ram dump and delete old records.
Choose a comparison criteria, the first 6 choices will compare new and old memory, the second 6 will compare new memory with the written parameter, the other 2 will compare both old and new memory with a parameter into account.
Unfortunatly, the first search will take up to 3-5 minutes, the button and the whole Memory window will lock up, so be patient.
A 'non-equal' search is proved to discard the highest amount of unneeded memory addresses at a time, so I recommend finding a way to perform a non-equal search in the first place.
Following searches will keep filtering the amount of hits, the less hits, the less time searches will take.
The addresses of the very first 10 hits every search produces will be displayed in the empty boxes, they are editable, just to allow easy select'n copy.
======== Logic
This one needs changes.
When performing a search:
Check for primary ram dump, if exists, create a secondary ram dump.
Create or read a reference table file, this file is a duplicate of a ram dump, where instead of storing actual ram data, stores yes/no switches (check address: 00, ignore address: 01)
This file tells the engine what memory regions have already been searched and failed our criterias, when we manually ignore an address, it will be marked as 01 as well.
Then the an optimization (not really) file is loaded, and a second one is written.
The first one (loaded) contains directives made by a previous search which tells the engine to skip huge amounts of useless iterations (because they will always check on 01 areas) VASTLY reducing search time, of course, on the first search, this file does not exist.
The second one (written during search) counts the amount of consecutive failed hits (01 byte in table), if it reaches a considerable amount before hitting a positive (00 byte), a directive will be written to this file.
Directive format, as seen in a HEX editor:
XX XX XX XX YY YY YY YY
XX XX XX XX YY YY YY YY
X's represent a u32 value which is the START address
Y's represent the END address
When START address is reached, the main search iterator will jump to END address, after all, everything between those are already marked as 01.
Right now, the minimum amount of consecutive 01's required to create a jump is 1000, you can change that til you get the best results.
Once the search is finished, the primary ram dump file is deleted and the secondary ram dump will become primary.
The reference table stays there till you reset.
The old and already read 'optimization' file gets deleted, the new one will be read next time and so on.
======== Problems
I don't understand wxWidgets, the result of it, an awful Memory Windows. Please take a look at it.
Speed, checking directly from RAM instead of a secondary ram dump would be great and faster, the only thing that worries me is that the main RAM would keep changing, even in the middle of a search (Auto pause/search/play anyone?).
Can the reference table be replace with something more efficient? Or smaller? The reference table is as big as a full ram dump!
Would reading the table in big buffers speed up things?
Ignore selection is currently not working.
Search modes (XX, XX XX,...) not working, only searches in XX.
The coding here is horrible, expect your eyes to get hurt while trying to understand it.
Don't worry, I left plenty of (un?)helpful comments.
Also, someone fix the AR patcher for Wii games! My newfound codes aren't working at all.
ASRock Conroe 1333-D667
Intel Pentium Dual Core E2180 2.00GHZ
2GB ram
Windows XP x64
Ati Radeon HD3650 256mb GDDR3![[Image: bugwk7.gif]](http://img503.imageshack.us/img503/301/bugwk7.gif)
![[Image: 338184.jpg]](http://www.danasoft.com/sig/338184.jpg)
Intel Pentium Dual Core E2180 2.00GHZ
2GB ram
Windows XP x64
Ati Radeon HD3650 256mb GDDR3
. I think still the AR needs some fixes, and still not sure if all the operations it can do are correct, but I managed to get most of the commonly used operations to work well enough.
![[Image: 1147431.png]](http://valid.canardpc.com/cache/banner/1147431.png)
![[Image: jg2snk.gif]](http://i102.photobucket.com/albums/m109/shaoranmps/jg2snk.gif)
