New map names in FR

[ShinyBill]

I am currently trying to add new map names without the need of deleting the old ones. Fire Red as exactly 108 map names.

Using A-Map's World Editor, I found the offset for the map names. I went to Hex Workshop, reversed the offset and found it. It is at address 0x003F1CAC. Names are stored with 3 bytes, followed by a 08. For Pallet Town, it's FCEC3E. Reversing that, it's 3EECFC. That's the offset for the name. If you look that offset using HackMew's Poke Adv Hex table, it will say PALLET.TOWN

I compiled some text using XSE so I could make a new name. This is where I stop. I don't know where to add the reversed offset. This is the normal offset for my text: 80407C, reversed: 7C4080. So in Hex Workshop it should be 7C 40 80 08 but IDK if I could put it right next to the CELADON DEPT. which is 0x003F1E5C and it's stored at 3EF22E.

I hope someone finds a way to add new names for the maps.

PS: Sorry for my english.

[Giga Universe]

The data at 0x3F1CAC appears to be a table. You can repoint it. Split it up and reverse it, you get AC 1C 3F 08. Search that in a your hex editor. Then find some free space (For an example lets use 800000), and reverse it. In my example that would give you 00 00 80 08. Replace AC 1C 3F 08 with 00 00 80 08. And you have your new table. Copy the old data from 0x3F1CAC to your free space, then add your own offsets. That SHOULD work. I haven't tried it, but it is the general way of repointing...

[ShinyBill]

I think I tried that but I gonna try again.


EDIT: Didn't seem to work. It ruined my rom's palletes and didn't add the needed names.

I searched for 864 bytes (the double the original tables uses) in FSF then, I pasted it twice so it could have the same names twice. But it didn't work. Lucky me I made a backup.

[Pokepal17]

Repoitning won't work because it's not just a name. It's a lot of data with each map name including a value which places it on the worldmap. This is gonna take a lot of ASM to work out.

[ShinyBill]

Well that's not good 'cause i s**k at ASM.

[Full Metal]

err...has anyone even began to listen to what Lu-Ho is saying? Really though, he's said it about a million times (sorry for having you repeat it again for me a while back...lol?) and he's even said he's looking into a way around it i think but that could be my memory playing tricks on me again...

[ShinyBill]

I found a temp. way of doing it. I went to A-Map general INI. It said AnzMapNamen=109 in BPR. My german isn't very good but I think that means number of map names. I changed it to 110 to test it. Once I open a FR Rom it showed a error. It said '$3F1E60 isn't a valid pointer!' I went to Hex WS and went to that address. It's right after the names table. I thought I could try it out, so I inputed a free offset and wrote text in that same offset. It went all good, I have the new name. The problems are:

In A-Map's World Map Editor, the value C5, which was before to the Empty/Don't display now belongs to the new name.

You can't choose Empty/Don't Display.

If you make a map with the newly created name and put its name to appear when you enter, the name box will be blank.

[LU-HO]

As i say mani times bevor.
this value "C5" is used on many ASM Routines to limit the number of names.
it check if number is smaller then c5 than do ASM work, else exit...

so you have to change this C5 -Check on each ASM routine that use name-Indexes.
and also you have to change the whole C5's on worldmaps and other data.

i do not find all ASM routines, and all Data using these namepindex, so i cannot finish a insert routine for it...

[ShinyBill]

Thanks for that information. How many routines did you found?

I went a little deeper, and found some logical information xD, that C5 is the limit and 58 is the beggining. C5-58=6D=109, those 109 map names, and so if we could change the C5 to 132 (the double) maybe and then, as LU-HO said, we would change the C5 value on the worldmap to 132. Maybe that should work. All we need is find the missing routines. Maybe I can follow a tutorial somewhere about ASM routines, 'cause, like I said before, I s**k at ASM.

[Team Fail]

I think this is getting somewheres good. If this can actually work, then this would be amazing. I know nothing on ASM and I'm learning Hex, but yeah. I see where you're going with this: Expanding the table to capacity could do the trick, but repointing it appearantly won't work. But, (tbh, I don't think this will work) if the names are reduced in size, it'll take up less room, and that'll leave more room to work with. If the names of the maps are reduced, it may leave with a bit more budge room to work with, wouldn't it?

[NarutoActor]

No, it's not about space with hex. It's about the amount. There are multiply asm routines that check the amount, and if the amount is not correct the game crashes.

[Team Fail]

Originally Posted by NarutoActor

No, it's not about space with hex. It's about the amount. There are multiply asm routines that check the amount, and if the amount is not correct the game crashes.

I sat and looked at this post for forever, and BAM!

The ASM routine(s):
As you said, when it checks the amount of map names, if that amount doesn't match up to what's in the routine/routines, the game will crash, right? Well, what if you change the amount of names that ASM routine(s) looks for? That way, you can expand the table, and the routine(s) will match it properly. I wouldn't know where to look, but do you think that ASM routine/ those ASM routines could be modified?

EXAMPLE (note, I'm making an example, NOT writing out an entire ASM routine, as I don't know ASM)

Amount to look for: 9F:Map Name 128
Change the routine to do this:
Amount to look for: AA: Map Name 138.

Wouldn't that work?

[Darthatron]

Originally Posted by Team Fail

I sat and looked at this post for forever, and BAM!

The ASM routine(s):
As you said, when it checks the amount of map names, if that amount doesn't match up to what's in the routine/routines, the game will crash, right? Well, what if you change the amount of names that ASM routine(s) looks for? That way, you can expand the table, and the routine(s) will match it properly. I wouldn't know where to look, but do you think that ASM routine/ those ASM routines could be modified?

EXAMPLE (note, I'm making an example, NOT writing out an entire ASM routine, as I don't know ASM)

Amount to look for: 9F:Map Name 128
Change the routine to do this:
Amount to look for: AA: Map Name 138.

Wouldn't that work?

Of course that will work. It's finding (ALL of) the routines that we are having trouble with.

[Full Metal]

so....
here's an idea
cmp rx , #0xC5
blt : PTR @i think that's "branch if less than, but i have no honest clue, but that is what it's supposed to be in my mind of crazy...
assemble that into a binary file
remove the : PTR part from the end (which should be only 2 bytes) since thumb uses shorts for it's commands/arguments afaik.
then in HW continuously search for those matching values and then debug at that area and see if it's accessed at all when messed around with the world-map or map-loading procedure. I honestly have no idea if thats possible, or which register to check though. lol i'm blubbering again, but i'm trying to contribute :D

[Jambo51]

BIG EDIT: The limiting byte for the routine is located at 0x080C4D8A! The byte stored at this location is 0x6C. The sharper minded of us with have deduced that 0x6C = 0xC4 - 0x58. (Where 0xC4 is the highest allowed header in A-Map and 0x58 is the difference between Pallet Town's A-Map header, and it's "true" header in the FR rom.)

(Side note - All FR maps were created relative to the RSE maps, so as not to cause confusion between the games when traded Pokémon are viewed. The Relative map header number for Pallet Town is 0x58, but it is treated by the game as map header 0x0 - and as such, all maps are read following that order).

The actual routine itself is as follows (There's obviously much more to it than that, but it isn't relevant for this as far as I can tell):

cmp r5, #0x6C
bhi $080C4D40

This leaves us with a slight problem. Without a rewrite (OK, I could do it, but it'd take a while) there is no way to support more than 0xFE (254) map headers at any time. This means that we will NOT be able to have multi-region hacks.
My idea for having more than that is to use something similar to the following code to do the work for us:

push {r5}
cmp r5, #0xFF
bhi greater
pop {r5}
[Rest of Original Routine...]
 
greater: mov r0, #0x1
lsl r0, r0, #0x8
sub r5, r5, r0
lsl r0, r5, #0x2
cmp r5, #0xFE
bhi return
pop {r5}
[Rest of Original Routine...]
 
return: pop {r5}
[Return to Original Routine]

This would allow support for 0x1FE (510) map headers, which should be more than enough. Obviously, the cmp r5, #0xFE in the greater routine now contains the limiting byte, so it could still be limited to as few as you like.
This has NOT been tested, and I wouldn't suggest trying it yet without backing up your rom as I still need to do some serious research to see if it'll work.

However, this only takes into account the actual names, and not the positions on the map and such, so this still needs a LOT of research. There are at the very least 8 routines which will need modified to support extra maps.
Name Reading (2 versions of), Position Reading (Layer 1), Position Reading (Layer 2), Map Flags (Layer 1), Map Flags (Layer 2), "Map number on World Map" and "Head Moving on Map", which means there's a lot of work to go yet XD.

Theoretically, they should all be simple enough to actually track down, going backwards from the reading of a piece of data in the rom, but these are only the ones we ACTUALLY KNOW ABOUT! Who's to say there isn't more data which is read from somewhere that we can't find. All of the routines mentioned above can be found by looking at the World Map Editor on A-Map, and tracking the read of the data on A-Map back to the limiting byte.

On the plus side, they are designed exactly the same way as all other limited routines in FireRed, with a simple byte controlling how many we can have, so in theory, with some repointing and some rewriting, we can have as many map headers as we like (well, up to 0xFFFFFFFF - as if the rom has enough free space for that XD).

Incidentally, the layer 2 map flags are the problem behind the red text with white background on most hacks for secondary locations, as for some reason, that's how they're displayed unless they have a flag associated with them.

I'm really struggling to find the limiting bytes for the layer reading routines. Maybe I could contact Lu-Ho for some information, or read the A-Map inis?

The following bytes are only read while either accessing the world map or accessing the map names for display. Game Freak have consistently used R0 throughout here making compares with 0xC5 or 0xC4 (etc) relatively easy to find. For the first one, a "better" way to make it work is to change the bytes preceding the check to this:

0D 0C 58 3D 09 0C C4 29

At 0x080C4D84. This changes the map name reader into the same format as the rest of the routine, making it more compatible with the rest of the routine, and any extra map names we manage to add.

FOUND LIMITING BYTES:
Name Reader: 0x080C4D8A (0x6C)
Map Header on World Map (For Sevii Islands): 0x080C0080 (0xC5)
Map Header on World Map (For Sevii Islands): 0x080C00CC (0xC5)
Name on World Map: 0x080C0B32 (0xC5)
Name on World Map 2: 0x080C067A (0xC5)

[Team Fail]

Originally Posted by Jambo51

This leaves us with a slight problem. Without a rewrite (OK, I could do it, but it'd take a while) there is no way to support more than 0xFF map headers at any time. This means that we will NOT be able to have multi-region hacks.

So, are you saying here that we cannot have more than FF (255) maps or map names unless it can be expanded?

[Jambo51]

Originally Posted by Team Fail

So, are you saying here that we cannot have more than FF (255) maps or map names unless it can be expanded?

Without rewriting the routine in a fashion similar to what I have above (Obviously, that's just a small example of what we'd need to do, not a full routine), we cannot have more than 0xFE (254) maps (as there needs to be a null map for the routine to work).

I forgot this when I posted that info last night, will modify momentarily.

We CAN have more than that, but it'd require substantially more work.

EDIT: First test, modified the limiting byte at 0x080C4D8A to 0x6D and repointed the various tables. On entering a map with 0xC5 as it's header (the previous upper limit) it correctly loaded a tester name. However, the world map simply crashes upon an attempt to load it, so I've clearly missed something important out. (Obviously, I also upped the limiting bytes for the world map routine too).

[linkandzelda]

I'm not sure if this is anything not note but, I was able to add 1 extra map name and get it to display and work in-game. This was by changing 1 or 2 limiter bytes and repointing the 3 tables. That was just to get it to display, hadn't even thought of the World Map yet...

[Jambo51]

Originally Posted by linkandzelda

I'm not sure if this is anything not note but, I was able to add 1 extra map name and get it to display and work in-game. This was by changing 1 or 2 limiter bytes and repointing the 3 tables. That was just to get it to display, hadn't even thought of the World Map yet...

Yeah, that's what I did, but I clearly missed something important in the world map loading routine because it just crashes upon an attempt to access it. Music continues to play, but it doesn't actually load the world map. I think it gets stuck in an infinite loop, so I probably made a mistake. It's hard to repoint a table when it's not immediately obvious when it ends (like the world map position bytes, as the table ends in a bunch of 0's which may or may not actually be connected to it).

[JustKidingYa]

couldn't you just use the emty headers e.i. route 4, route 10, tanoby key etc.

P.s that means some 108+ map names in emerald

[Jambo51]

Originally Posted by JustKidingYa

couldn't you just use the emty headers e.i. route 4, route 10, tanoby key etc.

P.s that means some 108+ map names in emerald

They're used for flight spots in FR. So sadly that isn't an option without sacrificing those particular flight spots, and even then, only gives us an extra 2 or 3 map names to play with. What if someone needs something of the order of 20 or 30? Currently impossible...

[NintendoBoyDX]

Map headers, may or not all be relevant to the routine but these all concern the values talked about, and are near the routines Jambo mentioned.
=========================
1. All the ones found by Jambo are FOR SURE limiting bytes.
2. String of stranges compares and moves and lsls at 080C26B0..two of the documented are found there.
3. Most important are C5 and 6C, for that reason I'm also searching for C4, cC6, 6B, and 6D.
4. No feasible compares or copies of c6 found.

These are close to the map-header functions area.

Spoiler:

Key(testing is a WIP):
* = Related to the World Map.
! = Related to the OW.
& = Related to the save menu.
^ = Related to the pokemon's caught location in it's info.
MAP HEADERS..
=========================
ADDRESS CMP
------------------------
*0x080C3880 R0, 0x47 @Jambo found, a number is subtracted from it and it becomes the new limiting byte.
__________________________________________________________________________________________
0x080C26E0 R1, 0x6C
0x080C2CBC R5, 0x6C
^&!*0x080C4D8A R5, 0x6C @ Name Reader, Jambo found.
__________________________________________________________________________________________
0x080D3DB8 R5, 0x6B @ Near this was SUBS R4, #0xC5, at 080D3DBC.
__________________________________________________________________________________________
*0x080C35E4 R0, 0x6D @Jambo found.
__________________________________________________________________________________________
0x080C3C36 R1, 0xC4
__________________________________________________________________________________________
*0x080C0080 R0, 0xC5 @ Map Header on World Map (For Sevii Islands), Jambo found.
*0x080C00CC r0, 0xC5 @ Map Header on World Map (For Sevii Islands), Jambo found.
0x080C0B00 R0, 0xC5
*0x080C0B32 R0, 0xC5 @ Name on World Map, Jambo found.
*0x080C0BE6 R0, 0xC5
*0x080C067A R0, 0xC5 @ Name on World Map 2, Jambo found.
*0x080C482C R0, 0xC5 @Jambo found.


ADDRESS MOVS
------------------------
0x080C26C8 R7, 0xC4
__________________________________________________________________________________________
*0x080C3538 R0, 0xC5
*0x080C3570 R4, 0xC5
*0x080C3598 R0, 0xC5
*0x080C35CC R4, 0xC5
*0x080C41D0 R0, 0xC5 @Jambo found.

These are not close to the routines, but in the ROM as a whole.
==============================================
1. 6B is never used as an immediate.

Spoiler:

ADDRESS CMP
------------------------
0x080E3904 R0, 0x6C
0x0813B844 R0, 0x6C
0x081E6464 R0, 0x6C
__________________________________________________________________________________________
0x080A1DCA R0, 0x6D
__________________________________________________________________________________________
0x0800BFC8 R0, 0xC4
0x0800BFFC R0, 0xC4
0x080AD6C2 R2, 0xC4
0x080B5324 R2, 0xC4
0x080B5386 R2, 0xC4
0x080AD6C2 R2, 0xC4
0x0815DF1A R0, 0xC4
__________________________________________________________________________________________
0x08152E80 R6, 0xC6



ADDRESS MOVS
------------------------
__________________________________________________________________________________________

0x0800F86E R1, 0x6C
0x080E5060 R2, 0x6C
0x081130E2 R0, 0x6C
__________________________________________________________________________________________

0x08049610 R0, 0x6D
__________________________________________________________________________________________

0x0808CAC4 R0, 0xC4
0x080AD6C2 R0, 0xC4
0x080C26C8 R7, 0xC4
__________________________________________________________________________________________
0x08026F84 R0, 0xC5
0x0804FE12 R0, 0xC5
0x080569D6 R0, 0xC5
0x08142070 R0, 0xC5
0x0814228C R0, 0xC5
0x0800F34E R0, 0xC5

[Jambo51]

This post contains all the needed offsets and steps required to extend the number of available map names.
You can now have a maximum of 0xFC map names, which is a vast improvement on the previous number of 0x6C.
You MUST leave 1 map name byte (0xFD) for the background in the World Map, and the other 2 (0xFE and 0xFF) are needed to maintain support for trading with RSE. Currently, without a fairly drastic rewrite of the routines and map headers, it is impossible to support any more map names than 0xFC (253).

Anything in normal type is for a simple extension after the end of the existing map names, that is, using 0xC5 - 0xFC.
Anything in bold type is for using map names 0x0 - 0x57. This requires some thinking to implement!

Limiting Bytes:

Spoiler:

* Layer 2 Flag Reader: 0xC3882 - 0x47 (C5 - 7E: Total Names - First Non City)
*^&! Name Reader 1: 0xC4D8A - 0x6C (C4 - 58: Total Names - No of Hoenn Names)
Not 100% Sure: 0xC35E6 - 0x6D (C5 - 58)
^ Catch Location Check: 0x13B844 - 0x6C (C4 - 58)
* Sevii Islands Check 1: 0xC0080 - 0xC5
* Sevii Islands Check 2: 0xC00CC - 0xC5
* Name on WM 1: 0xC0BE6 - 0xC5
* Name on WM 2: 0xC067A - 0xC5
* Layer 1 Flag Reader: 0xC482C - 0xC5
* Black/Grey Bar: 0xC0B32 - 0xC5

Map Data Readings:
0xC3538 - 0xC5
0xC3570 - 0xC5
0xC3598 - 0xC5
0xC35CC - 0xC5
0xC41D0 - 0xC5

*0x080C0BEC sub r0, #0x58; This needs to be removed to fix name loading.

In order to extend the table to include values below 0x58, there are MANY steps required, including some ASM.

World Map Location Data:

Spoiler:

After some fairly extensive research, I can confirm that there appears to be NO layer 2 location data. It simply reads layer 1's location data. The table of data is at 0x083F1E60.

This uses the SAME routine as the World Map's movement bytes routine, so all you need to do is repoint and appropriately extend the table.

World Map Movement Bytes:

Spoiler:

This is the data which controls how the player's head symbol moves along a route as the player travels.
Located at 0x083F2178 and lasting for 0x318 bytes again.

To allow the game to support more at the lower end, you need to insert 0x160 bytes before the repointed table. Then navigate to 0x080C3CA0 and replace the first 2 bytes with 00's.

Flight Data Controller Data:

Spoiler:

This is hard to explain, but is important nonetheless. This data controls how the game shows the map, and indeed, whether or not it has a flight spot attached to it.

Located at 0x083F2EE0 and lasting for 0x144 bytes.

To change for use from map name 0x0 instead of map name 0x58, open up the rom in a hex editor, and navigate to 0x080C5280 and replace the first 4 bytes with 00's. This changes the code, allowing it to use map names beginning from 0x0 instead of 0x58. The repoint the table mentioned above, and BEFORE the repointed table, place 0x108 0x00 bytes. Then change the original pointer to the location where the 00's start.

Names data:

Spoiler:

Speaks for itself. The actual names of the world map.
The table is stored at 0x083F1CAC and contains 0x6D entries at 4 bytes a piece. Meaning the table contains a total of 0x1B4 bytes.

To make this support map names below 0x58, you need to navigate to 0x080C4D86 and replace the following 2 bytes with 00's. This removes the lower limit on map names. Then repoint the table for the names, and put in the extra 0x58 names.

World Map Flag Data:

Spoiler:

The first table for the WM flag data is at 0x080C3654. This is just for layer 1. The limiting word (yes, word) is 0xFFFF0000. This can be different based on whether or not you have used A-Map to hack the world map. A-Map modifies the limiting word of the table, changing it from 00 00 77 77. So use the appropriate one for your rom. DO NOT CHANGE THIS. All you need to do to extend this table (and the following table) is simply insert a new flag slot over the top of the end of the table, and then put the limiting word at the end of the table. You obviously need to repoint the table to extend it however. It's 0xDC bytes long. So copy and paste away.

In other words, end the table with FF FF 00 00.

The second table for WM flags is at 0x080C38C8. This table starts at Viridian Forest, rather than Pallet Town, so it considerably shorter, coming in at 0x90 bytes. This is layer 2's table. This controls when the small dots become bigger dots, as well as the colour of the text on the WM screen. They also control whether or not the map's name has a white background or a black background on the WM. I have no idea why, but I can confirm that is the case.

What I elected to do with these, was to create full tables instead of shortened tables for the 2 layers of flags.
So I repointed layer 1's table, and inserted 0x58 entries before it in the table. This allows for layer 1 flags to be assigned to any map name.

For layer 2, I inserted 0x7E entries before the existing table (after repointing of course), and made the routine read the entirety of both tables.

To modify the routines, navigate to 0x080C3880, and change the following bytes to 00 00 C4 28. Then go to 0x080C35E4, and change the next few bytes to 00 00 C4 28. The go to 0x080C35EC, and change the byte here to 0x63. That should be it.

[diegoisawesome]

Originally Posted by Jambo51

Limiting Bytes:

Spoiler:

* Layer 2 Flag Reader: 0xC3882 - 0x47 (C5 - 7E: Total Names - First Non City)
*^&! Name Reader 1: 0xC4D8A - 0x6C (C4 - 58: Total Names - No of Hoenn Names)
Not 100% Sure: 0xC35E6 - 0x6D (C5 - 58)
^ Catch Location Check: 0x13B844 - 0x6C (C4 - 58)
* Sevii Islands Check 1: 0xC0080 - 0xC5
* Sevii Islands Check 2: 0xC00CC - 0xC5
* Name on WM 1: 0xC0BE6 - 0xC5
* Name on WM 2: 0xC067A - 0xC5
* Layer 1 Flag Reader: 0xC482C - 0xC5
* Black/Grey Bar: 0xC0B32 - 0xC5

Map Data Readings:
0xC3538 - 0xC5
0xC3570 - 0xC5
0xC3598 - 0xC5
0xC35CC - 0xC5
0xC41D0 - 0xC5

You missed at least one check in there that was found in the above post: *0x080C0BE6 R0, 0xC5

Originally Posted by Jambo51

World Map Flag Data:

Spoiler:

The first table for the WM flag data is at 0x080C3654. This is just for layer 1. The limiting word (yes, word) is 0xFFFF0000. DO NOT CHANGE THIS. All you need to do to extend this table (and the following table) is simply insert a new flag slot over the top of the end of the table, and then put the limiting word at the end of the table. You obviously need to repoint the table to extend it however. It's 0xDC bytes long. So copy and paste away.

In other words, end the table with FF FF 00 00.

Actually, this is only for a routine-changed FR ROM, and the limiting bytes are incorrect. It's actually 00 00 77 77 that you need to put at the end of the table, seen after A-Map repoints the table.
And by routine-changed, I mean that you went into A-Map, to the world map editor, and clicked 'Change routines'.

[Jambo51]

Originally Posted by diegoisawesome

You missed at least one check in there that was found in the above post: *0x080C0BE6 R0, 0xC5

No, I didn't. It's in the list, i just checked.

Originally Posted by diegoisawesome

Actually, this is only for a routine-changed FR ROM, and the limiting bytes are incorrect. It's actually 00 00 77 77 that you need to put at the end of the table, seen after A-Map repoints the table.
And by routine-changed, I mean that you went into A-Map, to the world map editor, and clicked 'Change routines'.

Ah, thanks for telling me that. I'll update the listy-half tutorial thing just now...