Main Menu
Main Page
Forums
New pages
Recent changes
Random page
Help

Glitches
Arbitrary code execution
Pokémon cloning
Pomeg glitch and Glitzer Popping
Tweaking and voiding
Glitches by generation
Glitch categories

References/Resources
Databases
Disassembly projects
The Big HEX List
Pokémon cheat codes
Pokémon glitch terminology
Useful tools
More

Affiliates
Legendary Star Blob 2 (Hakuda) (日本語/Japanese)
Pokémon Speedruns wiki (English)
PRAMA Initiative (Français/French)
MissingNo. Glitch City (Italiano/Italian)
Become an affiliate!

Technical
Site source code

Search Wiki

 

Search Forums

 

Author Topic: Any new info about "4 4's true cry"?  (Read 322 times)

0 Members and 1 Guest are viewing this topic.

RST 38

  • Make RSTs useful
  • GCLF Member
  • Offline Offline
  • Gender: Male
  • Glitch researcher, a fan of this community
    • View Profile
Any new info about "4 4's true cry"?
« on: March 24, 2019, 10:04:58 am »
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.

First: Why do we hear this in the first place?
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.

So, I can hear something similar, but it doesn't sound the same.
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)

Exactly how it does that?
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.
  • Number one - Decompression, that I haven't yet looked into, but it definitely can go wrong
  • Number two - The AlignSpriteDataCentered sub.
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
Lazy until inspired™

RST 38

  • Make RSTs useful
  • GCLF Member
  • Offline Offline
  • Gender: Male
  • Glitch researcher, a fan of this community
    • View Profile
Re: Any new info about "4 4's true cry"?
« Reply #1 on: March 25, 2019, 10:13:48 am »
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
Lazy until inspired™

Sherkel

  • Ringsome on the aquaface
  • Administrator
  • *****
  • Offline Offline
  • Gender: Male
  • PSYNCIN' IN THE VaiN
    • View Profile
Re: Any new info about "4 4's true cry"?
« Reply #2 on: March 25, 2019, 10:17:14 pm »
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.

I come and go. Apparently still more than most of the other regulars, so hard to say it's a semi-hiatus of some sort. Suggestions for wiki organization are appreciated here if you haven't seen this thread yet.
I don't have a habit of keeping Discord open, so direct inquiries are still preferred through here.

ISSOtm

  • The French Lord of Laziness (and a huge The Legend Of Zelda fan)
  • Staff
  • *****
  • Offline Offline
  • Gender: Male
  • Pewter City (B)rocks !
    • View Profile
    • My Little Website
Re: Any new info about "4 4's true cry"?
« Reply #3 on: March 26, 2019, 05:57:45 am »
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 =)
"THOU SHALL NOT PASS !!"  RIVAL's effect, Gandalf.

Proudly glitching Pokémon Red and Yellow on a Black & White GB, Pocket GB, GB Color, GBA SP and new 3DS.

My Twitter (beware, I'm French)
My YouTube (same warning)

Here is an online tool to build 8F setups : GBz80 to Items !

They see me layzin', they ha-tin'...
Heavy contributor of the global augmentation of entropy (my room's is too damn high !)