Research Problem

Logging: Nein, du suchst ja keine Ressourcen über die Datenströme, sondern eine Routine bzw. Bytes, die die Koordinaten repräsentieren. Deshalb Kapitel 2. Debugger. Das heißt also, dass du als Ausgangswert eine RAM-Stelle oder das Offset einer Routine brauchst, die mit der Sache, Healingplaces, zutun hat. Aus Dokumentationen im Forum, außerhalb oder selber herausgefunden. Daher musst du Breakpoints setzen mit dem VBA-SDL-H. Da du am Anfang wohl noch gar keine eigenen Research-Ergebnisse haben wirst, musst du auf die Informationen von anderen zurückgreifen.

Es würde sich lohnen special 0xC8 zu untersuchen, da es für das in Ohmachtfallen zuständig ist. Die Pointer der einzelnen specials sind in einer Table angeordnet: 0x15FCC0
Daraus ergibt sich die Formel:

Den Pointer an dieser Stelle schreibst du zu einem Offset um, und ziehst noch 1 ab, da es sich um eine thumb-Routine handelt. Die Routine könntest du dir dann mit einem Debugger ansehen, z.B. im VisualBoyAdvance, Disassembler im Tools-Menü.
In diesem Post haben dir bereits wichtige Informationen zu den Healingplaces verraten. Setze doch mal einen Breakpoint auf die Table. Inmittelbar nach dem Auslesen der Bank und Map, sollte die Koordinaten in der Routine stehen.

Zum Schluss noch die Notizen von JPAN, der die Koordinaten abhängig von Variablen gemacht hat, für die englische Feuerrot:

Was du gemacht hast: Du hast mit der Formel das Offset errechnet und davon dann den ersten und dritten Byte vertauscht.
Das ist Blödsinn. Wenn du bei 0x15FFE0 landest, sieht du dort einen Pointer 7DA50C08.
Umdrehen: 080CA57D
1 abziehen, weil Thumb-Routine: 080CA57C

Dieses Offset kannst du jetzt im Disassembler eingeben.
Dann wirst du nur eine kleine Routine sehen, wo aber ein Callback (grün) übergeben wird (Fenster 1).
Das führt dich zur nächsten Routine (Fenster 2).

Was soll man da jetzt interessantes sehen?

Wenn du einen Thumb-Breakpoint auf den Anfang der Routine setzen wolltest, ja.

Zitat von Kairyon

Bei 0x3EE500 liegt eine Table, die die Zielmaps der einzelnen Healingplaces angibt.
Zwei Bytes für die Bank, zwei Bytes für Map.

Nein, das ist der I/O-RAM. Die Lösung habe ich eigentlich schon genannt, man muss nur weitersehen. Schau doch einfach mal ab dem Offset, wo JPAN seine Routine eingefügt hat bzw. wo diese Table geladen wird. Wie ich mir schon gedacht habe, liegen die Koordinaten nicht weit entfernt. Das ganze fängt bei 080BFF24 an. Halte nach mov rX Ausschau, die genau die Koordinaten sind. Die Überprüfung der Mapbank und Mapnummer ist immer unmittelbar vor der X-Koordinate. Das habe ich gefunden:

Alabastia

X-Koordinate

Y-Koordinate

Pokémon-Center

X-Koordinate

Y-Koordinate

Indigo Plateau Pokémon-Center

X-Koordinate in Abhängigkeit von Mapbank 13
Es wird geprüft, ob es Mapbank 0xD ist (Indigo Plateau). Da die X-Koordinate auch 0xD ist, wird gleich der Wert von Register r1 von dem cmp genutzt. Somit kann man die X-Koordinate nicht ändern ohne die Überprüfung der Mapbank zu ruinieren.

Y-Koordinate

Eiland 1 Pokémon-Center

X-Koordinate

Y-Koordinate

Trainerturm Pokémon-Center

X-Koordinate

Y-Koordinate

Jop,
Müssten den Code halt so umschreiben das die Überprüfung der MapBank nicht zerstört wird.

Gehen tut es
Jpan's methode Funktioniert eigentlich ganz gut. Müsstest da halt nur die offsets anpassen

-SoulK3

Ich kann übrigens sehr den No$gba Debugger über dem VBA-SDL-H empfehlen.
Der ist irgendwie einfacher zu bedienen und macht nicht so viel Probleme und ist 32 MB ROM kompatibel:
http://problemkaputt.de/gba.htm (einfach die Debug Version runterladen)

Keine Ahnung, was du gemacht hast.
Du hättest einfach nur an den Offsets ein Byte ändern müssen, so wie ich:

Wahrscheinlich hast du dich irgendwo vertippt oder zu viel überschrieben.