Glitch City Laboratories Archives

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.

Generation I Glitch Discussion

Any new info about "4 4's true cry"? - Page 1

Any new info about "4 4's true cry"?

Posted by: RST 38
Date: 2019-03-24 11:04:58
I've seen this post https://forums.glitchcity.info/index.php?topic=8609, but not much else. So I've decided to look into it myself. Here is what I found in this one day.

[size=10pt]First: Why do we hear this in the first place?[/size]
Well, as TheZZAZZGlitch already showed in his video (https://www.youtube.com/watch?v=Op0jFsZP5Q8), jumping to 0150 makes the game play this PCM noise. What exactly is at that address? The PlayPikachuPCM subroutine. It's obvious that calling it with invalid parameters won't sound nice.

[size=10pt]So, I can hear something similar, but it doesn't sound the same.[/size]
Thats where 4 4 comes into play. When it's sprite is viewed, it spreads data thin(maybe not that thin) across the entire address space… 2 times…. This scrambles the original pikachu PCM into an earrape mess(along with your party, name, and just the memory in general)

[size=10pt]Exactly how it does that?[/size]
This is the most important question, I don't think much is known about that. But, there are basically two stages that can go catastrophically wrong.

The problem with both of these things is that they operate on variable-length data. And both of them treat 44's sprite size of 0x0 as 256x256. Yeah, it makes AlignSpriteDataCentered go through the entire address space. Even worse, that sub is called two times!

But, it's not as random as decompression can be. Actually, I looked at where the C0EF and C0F0 (sound banks) addresses take their values from, it turns out, they are from ROM bank 0, from addresses 3217-3218. So it seems as if the current sound bank and saved sound bank values should be the same every time! At least if something else doesn't corrupt them…

So, yeah, thats all I could gather today, maybe tomorrow I will look into the decompression. Post any new discoveries in this thread, everybody on this site will like to hear it!

Or, well, at least me :p

Re: Any new info about "4 4's true cry"?

Posted by: RST 38
Date: 2019-03-25 11:13:48
Okay, I've looked into decompression. While it also screws up, it doesn't do it as much as AlignSpriteDataCentered. In fact, it can only reach the first 0x300 bytes of RAM, at max.

Surprisingly, 4 4 doesn't do that. Why?
Sometimes in this Gen you've got essentially the same data stored in two different places. That's why hybrid glitch pokemon are a thing. The same goes for width and height of 4 4's sprite. The AlignSpriteDataCentered takes these values from the pokemon data(not sure, correct me if I'm wrong), while the decompression takes them from the first byte of input stream. For 4 4, they end up being 2x3. The sprite data of 0xBF starts at 510, that's ROM bank 0, so constant. And it doesn't go far from there. So we can say, that the corruption due to decompression is constant!
(Not really, as there are also "unpacking functions", which do some bitwise operations on the sprites, effectively making random even more random.)

If that's the case, then, if we skip the dreaded AlignSpriteDataCentered, everything should be okay. And thats exactly what we see! Don't believe me?
Open BGB, load the ROM, open the debugger by pressing ESC, press Ctrl-G(Go to…), write AlignSpriteDataCentered, double-click to place a breakpoint there. Then modify wCurOpponent(D058) to BF (instant encounter). Now, when the breakpoint is hit find a RET opcode right before the next function, right-click on it, click "Jump to cursor". Return to the game, the breakpoint will trigger once more, do the same thing as before. Upon returning to the game, you will be battling a wild black rectangle called 4 4.
Now, I haven't tested that under all conditions, tell me if you encounter something different.

So, it seams that we found the function to blame for the 4 4's wild effects. Now what? Well, we need to find the exact conditions under which the "true cry" occured. We know that ASDC(thats how I will call this sub now) isn't all that random. At least some of it's parts aren't, specifically when the read pointer is inside first 0x4000 bytes(ROM0). Writing a "corruption emulator" will be the next step.
Another thing that is way harder to predict, but which probably did most of the work was the garbage code. Well, I guess there is only one entry point for it - the invalid sound bank. But, from my previous post(if I haven't missed anything), we know that these values are constant! 0xF6 for sound bank and 0x21 for saved sound bank. So thats something to look into.

Anyways, thats it for today. Sadly, posts don't have likes, because I would've told you to leave one, as this sounds suspiciously like a YouTube outro…    0xD

Re: Any new info about "4 4's true cry"?

Posted by: Sherkel
Date: 2019-03-25 23:17:14
Consider this me leaving a "like"! :D Very nice analysis.

When it comes to the exact conditions behind that infamous "true cry", if I recall correctly he was using VBA at the time…so maybe that's not as important as playing with these breakpoints on our own without having to rely on luck.

Re: Any new info about "4 4's true cry"?

Posted by: ISSOtm
Date: 2019-03-26 06:57:45
Interesting use of the BGB debugger! But, you can do better to leave the function: when triggering the breakpoint, double-click the highlighted entry in the right-side (stack) panel, then press F6 to "Jump To Cursor". That should work just nicely =)