- 135
- Posts
- 4
- Years
- Seen May 13, 2024
There are some Pokémon games that use the engine of Pokémon Emerald, like Mega Power. But many of the music tracks sound different from their vanilla counterparts − they sound a bit more 8−bit. At first, I thought the developers did this on purpose considering the theme of that game. Then I learned that it was probably unintentional − it will be a mistake most Emerald hackers will encounter as novices.
The best program to edit maps in Gen 3 games is AdvanceMap. When editing things like Wild Pokémon data, script offsets and names of cities/towns, it searches for 00 bytes at and after 0x6b0000 for Emerald hacks, by default. At the time, people thought this was free space, but the 00 bytes are actually used for musical instrument data starting at 0x6b46bb. I don't know where this bit ends, but I THINK it's at 0x6b482f. Either way, changing any 00, 01 or 02 byte in this range will add random beeps to the soundtracks.
Steps on how to fix this:
− You need HexManiacAdvance, the best hex editor for Generation 3 games. The author is haven1433. It helps to have a clean Emerald ROM that had nothing modified in it.
1) Open up the "corrupted" ROM in HexManiacAdvance (HMA).
2) Type in 6b46c0 and click [Go].
3) Open up a vanilla Emerald ROM and type in the same hexadecimal number.
4) Compare the bytes side by side; you will find out which bytes you need to replace in the custom ROM with the vanilla ROM's bytes to fix the sound corruption.
5) Repoint any important data to free space* (0xE3CF64 and beyond) by selecting the bytes (by dragging your mouse) and pressing Ctrl + X, then press Ctrl + G to type in an offset beyond 0xE3CF64 that has FF bytes. Paste the data with Ctrl + B. (The blue circumflexes above some bytes are called "anchors". Avoid cutting and pasting more than 1 at a time.)
6) Go back to where you cut bytes from. Use Ctrl + G to go to that offset.
7) Fill those FF bytes with 00 bytes. Double check by comparing the bytes with a vanilla ROM.
8) Repeat steps 5 to 7 until you are at 0x6b482f. I don't think there would be more critical 00 bytes to overwrite.
Steps on how to avoid this in the future:
1) Go to the folder that has the Advance Map executable. (Should be somewhere in your Downloads folder)
2) Click on the Ini folder, then click on the AdvanceMap.ini file to edit it.
3) Scroll down to where it says "[Version:BPE]".
4) Change "SuchByte" from 00 to FF.
5) Change "SuchBeginn" from $6B0000 to $E3CF64.*
6) Save your changes.
Now you can open the ROM and your audio should be back to normal. Since you moved around some data, there could be issues in those offsets, so you might need to rescript them. Unfortunately, AdvanceMap (I believe) has a hardcoded offset of 0x6b0000 when it comes to map script offsets and wild pokémon data searching, so it's not a perfect fix.
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Extra notes about free space:
*There are quite a few bytes between 0xe3cf64 and 0xffffff, but for some developers, they may want to expand the ROM so that its file size is 32 MB. According to this web site, there are sections of Pokémon Emerald where 00 bytes were used as placeholders to separate between 2 sections of the ROM. Those can be used as free space if you use a different hex editor to change those 00 bytes to FF bytes. The web site mentions these offset ranges of 00 bytes: 0x9C0B20 to 0xAFFFFF, 0xB98B30 to 0xBFFFFF, 0xD3CEA0 to 0xD437EF and 0xDE4018 to 0xE3CF48. I have not tested using those byte ranges, but they might be legitimate free space ranges. Not many Emerald hacks utilize this, which is OK.
The catch to this is: as I was scrolling through HMA, in between the 00 bytes, I noticed those anchors, and they point to different areas of the ROM that have code assigned to them. I found these specific offsets within the supposed free space:
![[Emerald] HOW TO Fix audio corruption / 8 bit buzzes and beeps](https://cdn.discordapp.com/attachments/561296209529274380/833232288472760350/unknown.png "[Emerald] HOW TO Fix audio corruption / 8 bit buzzes and beeps")
The offsets on the left are inside the 00 bytes, and they have the blue "^" on the top left; these offsets point to their respective memory addresses after their arrows. Ex. 0x9f44f8 points to 0x9b6970.
I don't see any reason for something in the game to call hundreds of 00 bytes as they would just spend lots of time finding a byte that ≠ 00. But these may be important to the game; not much is known about them. Stick with 0xe3cf64 for free space, to stay on the safe side.
Edit: I thought I put this in the ROM Hacking Help forum.
The best program to edit maps in Gen 3 games is AdvanceMap. When editing things like Wild Pokémon data, script offsets and names of cities/towns, it searches for 00 bytes at and after 0x6b0000 for Emerald hacks, by default. At the time, people thought this was free space, but the 00 bytes are actually used for musical instrument data starting at 0x6b46bb. I don't know where this bit ends, but I THINK it's at 0x6b482f. Either way, changing any 00, 01 or 02 byte in this range will add random beeps to the soundtracks.
Steps on how to fix this:
− You need HexManiacAdvance, the best hex editor for Generation 3 games. The author is haven1433. It helps to have a clean Emerald ROM that had nothing modified in it.
1) Open up the "corrupted" ROM in HexManiacAdvance (HMA).
2) Type in 6b46c0 and click [Go].
3) Open up a vanilla Emerald ROM and type in the same hexadecimal number.
4) Compare the bytes side by side; you will find out which bytes you need to replace in the custom ROM with the vanilla ROM's bytes to fix the sound corruption.
5) Repoint any important data to free space* (0xE3CF64 and beyond) by selecting the bytes (by dragging your mouse) and pressing Ctrl + X, then press Ctrl + G to type in an offset beyond 0xE3CF64 that has FF bytes. Paste the data with Ctrl + B. (The blue circumflexes above some bytes are called "anchors". Avoid cutting and pasting more than 1 at a time.)
6) Go back to where you cut bytes from. Use Ctrl + G to go to that offset.
7) Fill those FF bytes with 00 bytes. Double check by comparing the bytes with a vanilla ROM.
8) Repeat steps 5 to 7 until you are at 0x6b482f. I don't think there would be more critical 00 bytes to overwrite.
Steps on how to avoid this in the future:
1) Go to the folder that has the Advance Map executable. (Should be somewhere in your Downloads folder)
2) Click on the Ini folder, then click on the AdvanceMap.ini file to edit it.
3) Scroll down to where it says "[Version:BPE]".
4) Change "SuchByte" from 00 to FF.
5) Change "SuchBeginn" from $6B0000 to $E3CF64.*
6) Save your changes.
Now you can open the ROM and your audio should be back to normal. Since you moved around some data, there could be issues in those offsets, so you might need to rescript them. Unfortunately, AdvanceMap (I believe) has a hardcoded offset of 0x6b0000 when it comes to map script offsets and wild pokémon data searching, so it's not a perfect fix.
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Extra notes about free space:
*There are quite a few bytes between 0xe3cf64 and 0xffffff, but for some developers, they may want to expand the ROM so that its file size is 32 MB. According to this web site, there are sections of Pokémon Emerald where 00 bytes were used as placeholders to separate between 2 sections of the ROM. Those can be used as free space if you use a different hex editor to change those 00 bytes to FF bytes. The web site mentions these offset ranges of 00 bytes: 0x9C0B20 to 0xAFFFFF, 0xB98B30 to 0xBFFFFF, 0xD3CEA0 to 0xD437EF and 0xDE4018 to 0xE3CF48. I have not tested using those byte ranges, but they might be legitimate free space ranges. Not many Emerald hacks utilize this, which is OK.
The catch to this is: as I was scrolling through HMA, in between the 00 bytes, I noticed those anchors, and they point to different areas of the ROM that have code assigned to them. I found these specific offsets within the supposed free space:
The offsets on the left are inside the 00 bytes, and they have the blue "^" on the top left; these offsets point to their respective memory addresses after their arrows. Ex. 0x9f44f8 points to 0x9b6970.
I don't see any reason for something in the game to call hundreds of 00 bytes as they would just spend lots of time finding a byte that ≠ 00. But these may be important to the game; not much is known about them. Stick with 0xe3cf64 for free space, to stay on the safe side.
Edit: I thought I put this in the ROM Hacking Help forum.
Last edited: