https://www.youtube.com/watch?v=ZQ1cX5RbTbY

It is a tool to automatically detect data which is a cause of a bug by using backup data when bug which can not be solved by any means occurs in ROM.

Suppose you have an unknown bug in your ROM.
This bug is a bug that it is difficult to fix such as checking the setting many times but making a mistake why the game freezes and does not work at all.
FEBuilderGBA uses various means to protect ROM, but still can not do without occurrence.
This function is to automatically detect the cause of the bug by taking DIFF with backup data.

First of all, advance the game with the emulator until the bug is reproduced.
When the bug comes up to where it reproduces, this tool comes in.
(Before starting this tool, please save any data that is not written.)

From the menu, select Tool→ Difference Debug Tool.

When you start this tool, the backup data is displayed in order of date.
The data above the list is new, the more you go down, the older the data.
Double click on the list, the emulator will start up automatically.
7z compression and ups etc are automatically changed to gba rom and the emulator starts up.

From the list of backups, look for “the most recent date without bugs”.

This time it is a test so we only have three data.
I think that there are lots of data actually lined up.


First of all, let's look at the oldest backup at the bottom of the list.
Double-click the item in the list to start the emulator.


It worked normally.
This seems to be correct data.
Close the emulator and take a look at the next data.


Let's see the data in the middle.
Likewise, double-click the item in the list to start up the emulator.


This also worked normally.
This seems to be correct data.


Then, how about the backup at the top of the list?
Double-click the item in the list to start up the emulator.


A bug has been reproduced.
This data seems to be broken.


So, which is the latest backup data that works correctly?
That is the middle data.

The latest backup data on the top was broken.
Therefore, the last data that worked correctly is the second data.

Please be careful not to make a mistake here.
I am looking for the latest backup data that works properly, not broken data.
Naturally, it is not the bottom.
The bottom works correctly, but it is not the latest data that works properly.

The latest data that works correctly is the second data.
This is an important point.


When you find the latest data that works correctly, press the button in the lower right to get 3 points DIFF.

On the importance of the latest data that works correctly.

The latest data that works correctly is very important.

Be sure to look for “the most recent date backup that does not cause bugs”.

Backup data of the next generation of the most recent backup that does not cause bugs is
It is the oldest backup data that causes a bug.

In other words, somewhere in the difference between the two is the data that is generating a bug.

The program does not work exactly what you thought, it only works as written.
A bug occurs because We are writing something by mistake.
Therefore, bugs are always hidden somewhere in the difference between the two ROMs.
The culprit is certainly in this difference. Let's find it out.

However, if you make various changes, there will be more changes.
Then, it is difficult to find out.
Therefore, we narrow down the range by taking the difference from the current ROM data.

Because bugs are occurring in the current ROM as well.
A similar bug in the current ROM also means that there is similar data in the current ROM.

Among the differences between them, the data present in the current ROM is data that causes a bug.

As the name gets longer, we call it with this tool as follows.
The most recent backup that does not cause bugs is called OK ROM.
The oldest backup that causes a bug is called NG ROM.
The current ROM is called CURRENT.

It is in OK ROM, it is not in NG ROM.
And it is in OK ROM, it is not in CURRENT.
Also, it exists in NG ROM and CURRENT.

We will use three point DIFF for data that satisfies these three conditions.
Push the button.

A comparison method will come out, but choose the top method.
(This is the condition explained earlier) ~.

Then the calculation is done and the result of 3 points DIFF is displayed in the list.




There is data that is causing bugs in this.
Let's find out.
(There is only one this time.)

Let's adapt the listed difference appropriately.
Press the 1 key to write the data of OK ROM.
Press the 2 key to write the data of NG ROM.
Press the 3 key to write the data of CURRENT.
Press the 0 key to write the data of CURRENT And clears the write mark.


Basically, please press the 1 key to write the data.
After writing the data, please press the F5 key to start up the emulator.
Please check the operation.
Has the bug been resolved?

If the bug has not been resolved, it seems this data is not.
Let's write the following data.

Of course, since the differential data is forcibly written, the game may not work.
In that case, press the 3 key to restore the CURRENT data.

Let's merge the differences like this. ~


If the bug was resolved, it is the data that is causing the bug.
Let's estimate the cause from the data address and the written contents.

When you find the address that resolved the bug, it seems that data other than that data is unrelated, so let's return to CURRENT by pressing the 3 key.
Also at this time, I will check whether the bug will reoccur while returning the data.
Perhaps, the perpetrator may not be alone but multiple perpetrators. Let's watch out.


Well, by merging the data, the problem has been solved.
If the problem is solved by merging the differences, that's fine.
If so, let's investigate what is in the address where the data was written.
Let's set a break point and observe the behavior using the debugger.
Something strange should be there.

This time, I specified the wrong map object in map setting.
Originally I have to specify 0x01, but since 0x02 was specified, the screen was broken.



Using this method, we can fix mysterious bugs in around an hour.
By all means, if you get a bug that you do not know the cause, you may want to explore the bug data in this way.

If you are merging data and you do not understand well, please press the button on the bottom right.
“Cancel all changes”.
Rewinds all data to the data just before starting merge.
With this you can merge again and again.

Let's ease it as you get used to using the tool.
If there is a large amount of data, hold down the SHIFT key and press the 1 key.
It automatically moves the focus to the next data by writing data.
Keep pressing the key all the time, the writing continues more and more.
It might be good to do something like binary search of checking the operation after about half merging.

This feature simplifies bug fixes by binary comparison I wrote a long time ago.
It is troublesome to merge two points with a binary comparison tool and so it is possible to merge easily with a 3 point merge, narrowing down the changes.

http://ngmansion.xyz/wiki/hackfe/index.php?cmd=read&page=%E8%A7%A3%E8%AA%AC%2F%E3%83%90%E3%82%A4%E3%83%8A%E3%83%AA%E6%AF%94%E8%BC%83%E3%81%A7%E3%83%90%E3%82%B0%E4%BF%AE%E6%AD%A3