Stablizing Pokemon Emerald (Preventing Corruption)

[Sky0fBlades]

How to Prevent Sound Corruption in Pokemon Emerald, + Get Lots More Free Space

by Sky0fBlades
_________________________________


Supplies List:

☆ A fresh and unmodified ROM of Pokemon Emerald (U) - unless you've only used free space at 0xE3CF64+
☆ Xtreme Script Editor [made by HackMew]
☆ Advance Map 1.92 and/or 1.95 (this is if you use either of them) [made by LU-HO]
☆ HxD (or another good hex editor, Hex Workshop does fine here too but HxD is free) [made by Maël Hörz]


◙ Introductions:

Alright, this should answer a lot of questions about whether Emerald is good to hack or not, and I also want everyone who hacks Emerald to see this as it is very important for hack quality. I have been 'studying' about Emerald's free space and offsets. I have looked around on Google on and off for a while about this, and it seems I've figured it out. Pokemon Emerald has been called 'unstable' because of it's tendency to become corrupted in different ways from having the wrong offsets overwritten instead of the ones that should be.

To make things easier, an attachment at the bottom of this post includes a .ips (AKA patch) file and a patcher that will automatically fix the ROM (can't give you the ROM, though). This guide however will show you how to do it without that. The patch is basically for convenience, especially once you aleady know how the steps to do this. Here we go:


◙ Preparations:

Spoiler:

With some insight from Diegoisawesome, the creator of Pokemon CrystalDust version (Emerald ROM base), I have found out that Pokemon Emerald uses both 0xFF AND 0x00 bytes for free space, not just 0xFF. However, the TRUE free space bytes are in particular areas in the ROM as I will mention in this guide. As many of us know, Advance Map by default searches out in Emerald for free space starting out at offset 0x6B0000. This is NOT free space in Emerald and will lead to corruption of the game's musical instruments, causing random notes to 'beep'. This is little known until it's too late, and is permanent and cannot be fixed after it happens. There have been ways to bypass this, such as setting A-Map's INI file to use the TRUE free space, which is:

Spoiler:

0x9C0B20 to 0xAFFFFF
0xB98B30 to 0xBFFFFF
0xD3CEA0 to 0xD437EF
0xDE4018 to 0xE3CF48
0xE3CF64 to the End


There may be more but these are the only safe ranges I have found so far.

How to solve the A-Map problem is below:

Spoiler:

If you don't want to change the ROM's free 00s to FFs, then at the very least change the following "$6B0000" to $E3CF64, although you'll run out of ROM space faster but not corrupt it, making it still worth it in the long run (but you'll have to expand the ROM with XSE). However, if you go along with this guide and change these 00s to FFs you will have more than double the amount of free space E3CF64+ alone will give you.

1) Open A-Map's main folder, then open the "Ini" folder.
2) Open "AdvanceMap.ini" in notepad, and open the Find interface (Ctrl+F).
3) Type version:bpe in the field, and hit "Find Next".
4) When it goes to it, scroll down a bit, and make these changes:

SuchByte=$00 change to SuchByte=$FF
SuchBeginn=$6B0000 change to SuchBeginn=$9C0B20

5) Now save.

There, now Advance Map will not overwrite critical bytes; but even if you make these changes, adding new Wild Pokemon data where there is none - or even adding new map banks (not sure about that one though) - will still overwrite the wrong bytes. I just recently found out about that (wild pokemon problem), courtesy of Diegoisawesome.

◙ Fixing the Free Space:

Spoiler:

Alright, now here is the part that may be tricky for one to figure out on their own. Here, you will be turning these ranges of true free space offsets with 0x00 bytes into 0xFF, so now you will only have to work with 0xFF bytes and have many more of them than normal as well. I also have a great tip on scripts using XSE that complements this procedure greatly, after this. That section after this one here will show you why doing these next steps is a VERY good idea.

Requirements:

- HxD
- An unmodified Pokemon Emerald ROM

Spoiler:

Now, open the ROM in HxD, and proceed with the following steps:

1) Go to the Menu Bar, click 'Edit', then click on 'Select block...'.

2) Now Type 9C0B20 into the Start-offset box, and enter AFFFFF into the End-offset box. It will now have highlighted everything between these two offsets, which is all '00' bytes.

3) Now right-click on the highlighted field (or go back to the Edit menu), and click 'Fill selection...' on the list. When the menu comes up, enter FF in the 'Hex-values' box. Click OK, and you will now see it turn all of the 00s into FF in a flash. Neat, huh?

4) Now if you want even more FFs for free space, follow the same steps for these offset ranges as well: 0xDE4018 to 0xE3CF48, 0xB98B30 to 0xBFFFFB, and 0xD3CEA0 to 0xD437EF

0xE3CF64 and onwards is already FF bytes, so no need to worry about that one; but don't alter the space between 0xE3CF48 and 0xE3CF64. It's taken for some reason, although it may not actually affect anything.

◙ Making Scripting (Esp. In Emerald) a Lot Less of a Pain in the Backside:

Spoiler:

Now for the next thing to do, which is really going to help you a ton. Many of us scripters already know that we can use "Dynamic" offsets. However, if you want to know about it then here is the definition from XSE's scripting guide file by HackMew (comes with it):

Spoiler:

"#dynamic Sets the dynamic start offset, or better, the offset the compiler will use to search free space for dynamic offsets.

Usage:
#dynamic lOffset

Example:
#dynamic 0x720000

The compiler will start searching free space starting from offset 0x720000. "

Now that we have made the earlier changes in HxD, we now have a load more FF bytes in Emerald we can work with as well as a new Dynamic offset much higher up in the list than 0xE3CF64, which is 0x9C0B20.

OK, now what will make things even easier is using a command like #dynamic, but with a different function. This one is called #freespace. Use this at the beginning of any script to make it search out specific bytes. In this case, it will definitely be 0xFF now that we have a lot more of those particular bytes. An example of use of this system which is in one of my own scripts (made with XSE) is below for clarification:

Spoiler:

// This is a special wildbattle script from Emerald I messed with for the heck of it, anyone is free to use it if they want :)

#freespace 0xFF
#dynamic 0x9C0B20
#org @start
lock
faceplayer
cry 0x149 0x3 // with 'roar' sound effect.
pause 0x28
waitcry
callasm 0x8EB0501 // shiny routine, remove this line if you do not have it integrated in the ROM.
setwildbattle 0x149 0x2D 0xC9
setflag 0x8C1
special 0x139 // screen effect before battle.
playsong 0x1DD 0x0
waitstate
clearflag 0x8C1
setflag 0xAB00 // flag to make it disappear, when also used as Person ID in A-Map.
fadescreen3 0x1
hidesprite LASTTALKED
fadescreen3 0x0
release
end

◙ Conclusions:

There, now when adding things into your Emerald ROM you will not have to worry about if you are overwriting the wrong set of 00 bytes, because now all of of the correct ones will be FF instead. I'd say that's pretty nifty :D

I really hope this helps you all out. If anyone has suggestions on something I should add, correct, or anything really, post about it below. This is as much as I know about this particular topic so far, so if you ask me certain questions about things not covered here there is a chance that I may not be able to answer, but I will do my best anyway.


◙ Extra Notes:

Spoiler:

> Here's something a bit important that I just realized (It is not affected by this guide): If you are using ZodiacDaGreat's version of the Day/Night Tool, remember to have it use an offset that does not include an area that you've scripted over. By default, the program uses 0xAF0000 for its location in the game, which of course is good since this is free space in the ROM; but if you already put in scripts in that area, they could be overwritten. Just a thought.

> If you are using LU-HO's Tileset Animation Editor, make the same changes in the .INI file as shown for Advance Map, as it also uses the same configuration for Emerald.

vV Download the Patch Vv (Optional)

1) Emerald FF Byte Patch.ips - Warning, use on a non-hacked ROM unless you've only used 0xE3CF64 and onwards for your hack.

2) Lunar IPS (LIPS) - IPS Creation/Application Tool

[ShinyDragonHunter]

This is a great tutorial. I'm sure a lot of people (including me) will find this extremely useful :)

[Sky0fBlades]

Thank you! Although there are other ways to accomplish what I described in this tutorial, this is the way I do it. I do know that you can also keep the values as 00, start from 9C0B20 and use the FF's at the bottom of the ROM for ASM pointers/other data.

EDIT: I have changed the color of most of the text in the guide, for better readability. Also fixed a couple of spelling errors.

EDIT 2: Screw it, I decided to just rid of all text coloring so this will be more legible for all forum skin styles at once.

[ShinyDragonHunter]

I've just noticed that the free space actually starts at 0x09C15AC, I know this because I'm currently using that space in my hack.

[droomph]

Originally Posted by ShinyDragonHunter

I've just noticed that the free space actually starts at 0x09C15AC, I know this because I'm currently using that space in my hack.

Can you explain in more detail, of how would you know?

[Shiny Quagsire]

This. I personally think this should be a requirement to hack Pokemon Emerald, since it increases stability on the Emerald engine and prevents any glitching.

[Sky0fBlades]

Originally Posted by ShinyDragonHunter

I've just noticed that the free space actually starts at 0x09C15AC, I know this because I'm currently using that space in my hack.

Originally Posted by droomph

Can you explain in more detail, of how would you know?

I'm now wondering about this too, I looked at that offset area in HxD and didn't see any difference at all from 0x9C0B20 to there.

Originally Posted by Shiny Quagsire

This. I personally think this should be a requirement to hack Pokemon Emerald, since it increases stability on the Emerald engine and prevents any glitching.

I agree. The first problem that comes to mind though is that I'm sure some good programs out there will use the first 00's they can find as free space in this game regardless.

600th post! Yeah!

[ShinyDragonHunter]

Originally Posted by droomph

Can you explain in more detail, of how would you know?

I know because that offset has a bunch of 00's. I can't really explain it, tbh.

[Sky0fBlades]

Originally Posted by ShinyDragonHunter

I know because that offset has a bunch of 00's. I can't really explain it, tbh.

Do you mean there is some kind of hidden data somewhere between 9C0B20 and that offset? I've only seen that there are all 00's from 9C0B20 onwards (which also have no written-in text data in them) including that offset you mentioned which comes after it. I'll look into it some more just in case. It's just that when I see it in the editor, all the 00s start directly on 9C0B20. BTW I used the space you mentioned already in my ROM too after starting with the regular offset, by using the Dynamic function.

[ShinyDragonHunter]

Originally Posted by SkyLine

Do you mean there is some kind of hidden data somewhere between 9C0B20 and that offset? I've only seen that there are all 00's from 9C0B20 onwards (which also have no written-in text data in them) including that offset you mentioned which comes after it. I'll look into it some more just in case. It's just that when I see it in the editor, all the 00s start directly on 9C0B20. BTW I used the space you mentioned already in my ROM too after starting with the regular offset, by using the Dynamic function.

Oh right. I used that offset for music and stuff.