| |
1
No wonder the game falls apart, either the name is too long and it’s overwrites the 0x50, or there isn’t one in that section of VRAM. Either way it trashed the game completely, I couldn’t move anywhere after the battle and menus were invisible.
2
« Last post by bbbbbbbbba on Yesterday at 03:10:59 am »
I think I've found out the culprit. After a battle, the game copies the enemy trainer's name in a weird way ( disassembly). According to this table, the 0xFD trainer's name should come from $9481, which is in the VRAM. Since this copy is until a 0x50 terminator, mass corruption happens. Edit: I think I've found out why the game does this, too. In the Japanese version, some trainer names actually have an abbreviated version that is used as dialog tags ( video). Presumably the entries in TrainerNamePointers that aren't wTrainerName were originally those abbreviations in the Japanese version.
3
So 0xFD in the TrainerDex. I’ve battled him a few times and while his AI in battle is stable (just spamming Guard Special), it seems as though once he is defeated, something trashes the data, causing major effects (mainly name being overly long) and after it dropped me in what looks like a glitch city version of the Celadon Department Store. Does the prize money pointers have anything to do with this? (Referring to too much prize money, which can cause the ZZAZZ glitch.)
4
« Last post by Parzival on September 12, 2019, 09:20:59 pm »
when someone tries to wrap their MIDI in 3 layers of crypto to distribute it without allowing access but they used ZipCrypto on a headered file format where only 4 of 14 header bytes can change
5
I see.
Anyways I’ll do more of these later, I gotta go eat dinner and then I’m gonna play video games-
6
« Last post by Parzival on September 12, 2019, 04:28:08 pm »
A Pokédex entry is a relatively complicated object. A valid Pokédex entry looks like this:
; string: species name
; height in feet, inches
; weight in pounds
; text entry
RhydonDexEntry:
db "DRILL@"
db 6,3
dw 2650
TX_FAR _RhydonDexEntry
db "@"
Here "DRILL" means Rhydon is the Drill Pokémon. This string is the first to be printed to the screen, and with good reason: The game need to know where that string ends in order to find all the other data.
Consider a Pokédex entry at $AA00. Contrary to what I initially believed, the SRAM is actually unlocked during the battle. It is locked when the game finished loading the player's back sprite, but is then unlocked when the game loaded the back sprite of my first Pokémon and never locked again. I can't tell if this is intentional.
Well, on my save file for testing, SRA0:AA00 is a bunch of 0xFF anyway. (Probably because I have cleared the save file some time in the past.) Which is an awfully long string of "9". More "9"s than healthy for the game. For example, at some point it overwrites wOptions and then wLetterPrintingDelayFlags, which causes the game to wait 15 frames between characters. And that's terrible.
For some reason, beginning at SRA0:BBB7, my save data is no longer 0xFF. It begins with some bytes I don't understand ("E4 35 70 01 67 3E 8C 00 00 39 C3 BB 94 20 20 D3 01 8C 8C 8C 20 D3 38"), and then (starting at $BBCE) becomes "00 39 00 39 00 39 ...". I guess old crashes don't die that easily.
Anyway, the game mercy kills the PlaceString subroutine when it sees 0x00 at $BBBE. But it puts the pointer de at $19F3, which is... here. Starting from $19F4, the bytes "17 96 66 22" are interpreted as the height and weight data (23'150"/880.6 lb; the 150 displayed as " 0" when forced to be printed in two digits). Right after there happens to be a 0x50 terminator. Everything is fine!
Except that wJoyIgnore has also been overwritten to 0xFF, so I softlock. Oh well. At least I can soft reset.
It should be clear by now why this Pokédex entry behaves differently depending on the save file, especially after looking at glitch Pokémon sprites (which are known to trash SRAM Bank 0, also known as HOF data). Anyway... why don't you set a breakpoint at 10:435E and see for yourself?
Well that explains why I get random everything; I have never cleared the file. Also I haven’t got a clue how to set a breakpoint...
Breakpoints are only possible with a debugger. Like BGB's.
7
A Pokédex entry is a relatively complicated object. A valid Pokédex entry looks like this:
; string: species name
; height in feet, inches
; weight in pounds
; text entry
RhydonDexEntry:
db "DRILL@"
db 6,3
dw 2650
TX_FAR _RhydonDexEntry
db "@"
Here "DRILL" means Rhydon is the Drill Pokémon. This string is the first to be printed to the screen, and with good reason: The game need to know where that string ends in order to find all the other data.
Consider a Pokédex entry at $AA00. Contrary to what I initially believed, the SRAM is actually unlocked during the battle. It is locked when the game finished loading the player's back sprite, but is then unlocked when the game loaded the back sprite of my first Pokémon and never locked again. I can't tell if this is intentional.
Well, on my save file for testing, SRA0:AA00 is a bunch of 0xFF anyway. (Probably because I have cleared the save file some time in the past.) Which is an awfully long string of "9". More "9"s than healthy for the game. For example, at some point it overwrites wOptions and then wLetterPrintingDelayFlags, which causes the game to wait 15 frames between characters. And that's terrible.
For some reason, beginning at SRA0:BBB7, my save data is no longer 0xFF. It begins with some bytes I don't understand ("E4 35 70 01 67 3E 8C 00 00 39 C3 BB 94 20 20 D3 01 8C 8C 8C 20 D3 38"), and then (starting at $BBCE) becomes "00 39 00 39 00 39 ...". I guess old crashes don't die that easily.
Anyway, the game mercy kills the PlaceString subroutine when it sees 0x00 at $BBBE. But it puts the pointer de at $19F3, which is... here. Starting from $19F4, the bytes "17 96 66 22" are interpreted as the height and weight data (23'150"/880.6 lb; the 150 displayed as " 0" when forced to be printed in two digits). Right after there happens to be a 0x50 terminator. Everything is fine!
Except that wJoyIgnore has also been overwritten to 0xFF, so I softlock. Oh well. At least I can soft reset.
It should be clear by now why this Pokédex entry behaves differently depending on the save file, especially after looking at glitch Pokémon sprites (which are known to trash SRAM Bank 0, also known as HOF data). Anyway... why don't you set a breakpoint at 10:435E and see for yourself?
Well that explains why I get random everything; I have never cleared the file. Also I haven’t got a clue how to set a breakpoint...
8
« Last post by bbbbbbbbba on September 12, 2019, 03:11:52 pm »
A Pokédex entry is a relatively complicated object. A valid Pokédex entry looks like this: ; string: species name
; height in feet, inches
; weight in pounds
; text entry
RhydonDexEntry:
db "DRILL@"
db 6,3
dw 2650
TX_FAR _RhydonDexEntry
db "@"
Here "DRILL" means Rhydon is the Drill Pokémon. This string is the first to be printed to the screen, and with good reason: The game need to know where that string ends in order to find all the other data. Consider a Pokédex entry at $AA00. Contrary to what I initially believed, the SRAM is actually unlocked during the battle. It is locked when the game finished loading the player's back sprite, but is then unlocked when the game loaded the back sprite of my first Pokémon and never locked again. I can't tell if this is intentional. Well, on my save file for testing, SRA0:AA00 is a bunch of 0xFF anyway. (Probably because I have cleared the save file some time in the past.) Which is an awfully long string of "9". More "9"s than healthy for the game. For example, at some point it overwrites wOptions and then wLetterPrintingDelayFlags, which causes the game to wait 15 frames between characters. And that's terrible. For some reason, beginning at SRA0:BBB7, my save data is no longer 0xFF. It begins with some bytes I don't understand ("E4 35 70 01 67 3E 8C 00 00 39 C3 BB 94 20 20 D3 01 8C 8C 8C 20 D3 38"), and then (starting at $BBCE) becomes "00 39 00 39 00 39 ...". I guess old crashes don't die that easily. Anyway, the game mercy kills the PlaceString subroutine when it sees 0x00 at $BBBE. But it puts the pointer de at $19F3, which is... here. Starting from $19F4, the bytes "17 96 66 22" are interpreted as the height and weight data (23'150"/880.6 lb; the 150 displayed as " 0" when forced to be printed in two digits). Right after there happens to be a 0x50 terminator. Everything is fine! Except that wJoyIgnore has also been overwritten to 0xFF, so I softlock. Oh well. At least I can soft reset.
It should be clear by now why this Pokédex entry behaves differently depending on the save file, especially after looking at glitch Pokémon sprites (which are known to trash SRAM Bank 0, also known as HOF data). Anyway... why don't you set a breakpoint at 10:435E and see for yourself?
9
Certainly possible, this may be a complicated situation. In the mean time, I got a few more pokedex variations done:
1'18"/204.0 lb: Eventually locked up with the gym battle theme, with light buzzing sound occasionally.
52'7"/4591.3 lb: Bunch of hyper beams early on, gave a 48 error, but continued, eventually the game halted while stuck on a sound, assuming an unknown opcode.
9'7"/179.9 lb: Short burst of sounds, quick exit with a 48 error.
34'7"/6357.0 lb: Same as above, different sounds.
10
« Last post by Parzival on September 12, 2019, 11:40:27 am »
O-Ok sorry... 
Don't worry about it buddy ^^
Hmm I think SRAM can be locked at points; I wonder is there a point where all the data is read as FF FF FF (...) because it is locked? So 999 category max height/weight etc. Or is the region always unlocked for when the Pokédex entry is brought up.
I’m not sure.. There may be some points where it is locked and only (or mostly) reads FF FF FF (999...) when the game spams 9999 at the bottom. But it seems it’s unlocked, as the species description (normal example would be New Species for Mew) isn’t just mostly 9's, it varies from a few letters to complete garbage.
Sounds like VRAM, however. Might be pulling from multiple places...
|
Home
Help
Search
Calendar
Members
Login
Register
Recent Posts