Need some help on 4 4
Posted by: TheUnReturned
Date: 2016-07-14 23:33:35
Also, where does it its cry point to?
I know, I know it's invalid, but where exactly it's invalid cry point to?
I'm so lost on discovering 4 4
Glitch City Laboratories closed on 1 September 2020 (announcement). This is an archived copy of a thread from Glitch City Laboratories Forums.
You can join Glitch City Research Institute to ask questions or discuss current developments.
You may also download the archive of this forum in .tar.gz, .sql.gz, or .sqlite.gz formats.
4 4's "cry" is really an effect due to the game jumping to 0x019A for somereason.
I see… So every glitch Pokemon that uses a invalid sound bank might have a chance to jump to a part of memory…
4 4's "cry" is really an effect due to the game jumping to 0x019A for somereason.
This is something I didn't know, yet it is every important.
After hacking the game to jump to address $0135 from an RST vector (change bytes at $0038 to C3 35 01), not too far away from $019A, the "true cry" happens exactly how it did in my video. Similar effects happen when jumping to other nearby locations. So, somehow, one of the invalid sound banks causes jumps to this part of memory.
If I had a way of determining which sound bank it was (and why invalid sound banks tend to crash), I could then use my "SRAM corruption emulator" to find the conditions necessary to reproduce the effect. Obviously nobody knows if the effect was actually caused by corrupting sound bank data, because 4 4's effects also partially depend on location. But still, it's worth a shot.
4 4's actual cry is one of the sound channels of the move Surf. https://youtu.be/_0czHNnhUVs?t=2m55s
This cry is not related in any way to the effects caused by decompressing 4 4's sprite. The "true cry" is just a reference to a similar glitch, "Missingno.'s true cry". They are both caused by corrupting sound-related RAM addresses. https://youtu.be/X71p0sKAaFw
0x04 corrupts the value of address $DFE1, depending on which sound is played, and then returns without crashing. I'm not sure what this address does.
0x40 causes the game to jump to $E137, which is in the middle of sprite data. This area of memory is hard to control in real time, but it could be manipulated during a TAS to gain arbitrary code execution. Assuming we can get a Missingno. encounter with sound bank 0x40 early on, it could be an interesting and viable strategy in no save corruption any% TASes.
SECTION "Stack", WRAMX[$dfff], BANK[1]
wStack:: ; dfff
ds -$100
Glitch sound banks cause jumps to $6BD4 every time a sound is played (more information: http://forums.glitchcity.info/index.php/topic,7518.msg200772.html#msg200772)
I checked all possible sound banks to see what code they execute.
We see all kinds of common effects:[li]0x01 - "learned"/"trying to learn" effect[/li]
[li]0x03, 0x06, 0x07, 0x09, 0x0A, 0x0C, 0x0D, 0x10, 0x12-0x1E, 0x21, 0x22, 0x24-0x3F - game crashes[/li]
[li]0x05 - the game falls into an infinite loop and softlocks[/li]
[li]0x0E - returns gracefully or gives an unknown opcode, depending on which sound is played[/li]
[li]0x02, 0x04, 0x08, 0x0F, 0x23 - returns gracefully[/li]
Sound banks repeat every 0x40 entries (so banks 0x01, 0x41, 0x81 and 0xC1 are identical).
So, what else can we do with them?
0x11 delays a few frames by executing lots of halt instructions, then writes 0x2E to $C4C1 and then returns. $C4C1 is one of the tiles in the tilemap. So, this sound bank actually has visible effects - we can see the tile change for a few frames:
[img]https://aww.moe/3dn5ol.png[/img]
0x04 corrupts the value of address $DFE1, depending on which sound is played, and then returns without crashing. I'm not sure what this address does.
0x40 causes the game to jump to $E137, which is in the middle of sprite data. This area of memory is hard to control in real time, but it could be manipulated during a TAS to gain arbitrary code execution. Assuming we can get a Missingno. encounter with sound bank 0x40 early on, it could be an interesting and viable strategy in no save corruption any% TASes.
Unfortunately, I don't see anything that would be the cause of 4 4's true cry.
Party Pokemon corrupted
It has chances to be huge. The game won't be running normally after, that I can almost guarantee.
Glitch sound banks cause jumps to $6BD4 every time a sound is played (more information: http://forums.glitchcity.info/index.php/topic,7518.msg200772.html#msg200772)
I checked all possible sound banks to see what code they execute.
We see all kinds of common effects:[li]0x01 - "learned"/"trying to learn" effect[/li]
[li]0x03, 0x06, 0x07, 0x09, 0x0A, 0x0C, 0x0D, 0x10, 0x12-0x1E, 0x21, 0x22, 0x24-0x3F - game crashes[/li]
[li]0x05 - the game falls into an infinite loop and softlocks[/li]
[li]0x0E - returns gracefully or gives an unknown opcode, depending on which sound is played[/li]
[li]0x02, 0x04, 0x08, 0x0F, 0x23 - returns gracefully[/li]
Sound banks repeat every 0x40 entries (so banks 0x01, 0x41, 0x81 and 0xC1 are identical).
So, what else can we do with them?
0x11 delays a few frames by executing lots of halt instructions, then writes 0x2E to $C4C1 and then returns. $C4C1 is one of the tiles in the tilemap. So, this sound bank actually has visible effects - we can see the tile change for a few frames:
[img]https://aww.moe/3dn5ol.png[/img]
0x04 corrupts the value of address $DFE1, depending on which sound is played, and then returns without crashing. I'm not sure what this address does.
0x40 causes the game to jump to $E137, which is in the middle of sprite data. This area of memory is hard to control in real time, but it could be manipulated during a TAS to gain arbitrary code execution. Assuming we can get a Missingno. encounter with sound bank 0x40 early on, it could be an interesting and viable strategy in no save corruption any% TASes.
Unfortunately, I don't see anything that would be the cause of 4 4's true cry.
Glitch sound banks cause jumps to $6BD4 every time a sound is played (more information: http://forums.glitchcity.info/index.php/topic,7518.msg200772.html#msg200772)
I checked all possible sound banks to see what code they execute.
We see all kinds of common effects:[li]0x01 - "learned"/"trying to learn" effect[/li]
[li]0x03, 0x06, 0x07, 0x09, 0x0A, 0x0C, 0x0D, 0x10, 0x12-0x1E, 0x21, 0x22, 0x24-0x3F - game crashes[/li]
[li]0x05 - the game falls into an infinite loop and softlocks[/li]
[li]0x0E - returns gracefully or gives an unknown opcode, depending on which sound is played[/li]
[li]0x02, 0x04, 0x08, 0x0F, 0x23 - returns gracefully[/li]
Sound banks repeat every 0x40 entries (so banks 0x01, 0x41, 0x81 and 0xC1 are identical).
So, what else can we do with them?
0x11 delays a few frames by executing lots of halt instructions, then writes 0x2E to $C4C1 and then returns. $C4C1 is one of the tiles in the tilemap. So, this sound bank actually has visible effects - we can see the tile change for a few frames:
[img]https://aww.moe/3dn5ol.png[/img]
0x04 corrupts the value of address $DFE1, depending on which sound is played, and then returns without crashing. I'm not sure what this address does.
0x40 causes the game to jump to $E137, which is in the middle of sprite data. This area of memory is hard to control in real time, but it could be manipulated during a TAS to gain arbitrary code execution. Assuming we can get a Missingno. encounter with sound bank 0x40 early on, it could be an interesting and viable strategy in no save corruption any% TASes.
Unfortunately, I don't see anything that would be the cause of 4 4's true cry.
Cool. Can you do one for Pokemon Red/Blue as well?