We all know that Generation I is glitchy, and the game might crash as a result of all that glitchiness. Turns out, there are a lot of patterns in the types of crashes you can encounter. Let's investigate!
Yeah, ZZAZZ posted a video a while back showing off a "make your own trainer" glitch where you could change ZZAZZ trainer 0xFC's first roster using glitch Pokemon. He stressed that you should always look at a non-glitched Pokemon's sprite before encountering 0xFC, because if you don't, its entire party will be level 255 Charizard 'Ms
More nerd stuff, explaining the STOP instruction: The actual opcode is just 10. However, there's a bug in the GB CPU (might be fixed in GBC?) where it will read the byte following this opcode twice. So if you did something like "stop; inc a", it could increment twice; if you put a multi-byte instruction there, it would be read incorrectly. The official fix for this was to pretend "10 00" is the opcode for STOP, since repeating a NOP is harmless, and "10 xx" where xx ≠ 0 is undefined behavior. This also applies to HALT. That's sometimes called the "double halt bug" since if the instruction immediately after HALT is another HALT, it can get stuck there forever.
That's not entirely correct. In the usual case, the second byte is entirely skipped and not executed at all. You can have an invalid instruction in the second byte and the GB would run fine usually. In some cases it is executed, but generally that won't happen (and there is never a "double read" here). The "double read" you refer to only applies to halt, stop does not have this issue. Also, the "double read" only occurs when halt mode is entered while an interrupt is already pending due to rIF and rIE (although ignoring IME here). It's also in reality not a "double read" but rather an extraneous decrement to the PC (so when IME is disabled, it "double reads" the next byte, but when IME is enabled, it instead causes the return address of the interrupt to point to the halt rather than the opcode after halt, the latter case being rare of course given that means rIF would have to change at the exact cycle you enter halt, that or IME is enabled on that cycle (nice for testroms given ei's delay)). Also, of course, due to this, halt after halt doesn't mean it will always be stuck forever (just "can"). You can check more info on STOP on the pandocs here (which includes details on the quirky cases): gbdev.io/pandocs/Reducing_Power_Consumption.html#using-the-stop-instruction
@@Curioust2020 "There are approximately 1,010,300 words in the English language, but I could never string enough words together to properly express how much I want to hit you with a chair." -Alexander Hamilton
Oh wow, I remember back in 2007 when I first saw videos on the TMTRAINER effect that I was spending countless hours trying to figure out a way to not make it crash and I discovered that you could do that glitch in the seafoam island cave east of cinnabar island without it crashing. At the time, it seemed to be the only area that it worked but now I know that it's because there are no NPCs in that cave. Thanks for the info
This here is my answer to questions of the kind "Why are you wasting your time digging into old video games?" Because these can serve as excellent "toy"* models for learning skills like assembly level debugging, understanding memory corruption, and reverse engineering. All of these are immensely useful skills of real world computer science. Plus, the "old video games" have a nice, fun incentive for you to learn about these skills, until you start to find the skills themselves to be interesting and motivating enough in their own right. * or rather, real architectures, but simpler than modern counterparts which are much harder to understand when learning from scratch
i tried doing yami shop glitch at the celadon dept store(yes on a 3ds vc on red), but even though i did the steps for it correctly, my game still crashed and save data actually just got erased entirely. Luckily, even though i didnt like my save being erased, that meant i could do the save corrupt glitch (or whatever its called) to get myself champion in 1 min lol
Honestly, Game Crashes just intrigue and fascinate me; just seeing the game fall apart or react in a different way due to an unexpected event is so much fun and I love it when crashes are explored in depth as to what's happening behind the scenes. I'd *_love_* for more Game Crashes (maybe not even just Pokémon, but in other games) to be explored as to what happens, how they happen and what the outcome could be
That aside about corrupting a _different_ game's SRAM sounds fun... particularly if there's any games that don't notice the corruption and actually treat it as valid data, somehow. Though like you said there's a lot that could make the whole idea not work at all.
@@reddodeado301 no, it's just work RAM that's being corrupted in that strat, not save RAM. Save RAM is harder because there's typically a checksum or similar so the game can detect a dead battery.
Welcome back, ZZAZZ! Was having an *especially* terrible day and all my favorite content creators suddenly started uploading today... Glad you're providing us with that nice glitchiness again :)
11:21 I love how you can hear the great harmony for Pallet Town really clearly here. This has nothing to do with the video, I just thought it was neat.
@@drdca8263 Indeed, not bad but it's only lightly corrupted. I prefer completly new music from hard glitch (for exemple the cursed musique in the japanes version of pokemon green when you mess with the professor Oak's package and you exit the Map through a glitch in the wall)
"In fact, some types of crashes have been given specific names by the community, just because of how common they are." Game Freak: *monkey puppet meme*
I’m pretty happy the video was slightly more beginner friendly as while I know a small amount of programming and video game tech, I don’t know anything about low-level programming languages or where hex value data goes. Giving an explanation of what certain hex values do what helped a lot!
Delighted to see another upload from you!! This is a fun one, I genuinely love hearing about specific reasoning behind glitch stuff like this. (And how the VC emulator being terrible is still relevant...)
Holy crap, I thought I was the only one who saw that! It took me a few seconds to realize that yes, it *was* in fact an AA reference and not just a typo.
I just wanted to say how much I appreciate you working on this channel. It's so utterly unique and interesting, it's always exciting to see what you've discovered in these games. Thanks so much for all the crazy information!
Love the video! I'm super interested in tech stuff, and you explained everything in a way I could follow along with, despite not having seen any of your videos before. Wasn't expecting the arm warmers, but they were a nice touch !
Welcome back, ZZAZZ. You're a legend and an inspiration to glitchers everywhere, including myself when I first got into RB glitching 5 years ago. You rock, dude.
It's pretty amazing to see that you're still around. I remember watching your videos wayyy back in the day. Missingnoxpert is long since gone but you're still holding up. Keep up the good work! 👍
Always nice to see a ZZAZZ video. I've spent a small amount of time every once in a while trying to see what weirdness occurs in glitching things with the 3DS VC, losing many saves in the progress. It was only a few days ago I actually just got my 3DS setup to use Checkpoint so I could at least start backing up my saves. Great job explaining showing and explaining the RST crash, makes it pretty easy to understand.
Welcome back! It's great to see videos again and the technical analysis behind it. The added sprinkle of memes/humor/sound effects keeps it from being "boring" - not the actual definition, but basically adds a little spice to keep you entertained while learning what's going on under the hood.
I love these videos they're highly informative and presented visually well. Glad to see more. Very interested in the corruption of another cartridges SRAM while RST38 is a ctive in a scenario when a game's bank is left vulnerable by default.
I feel that it would mainly work with older titles, and that later titles would be less prone to RST38. GBC titles especially would most likely be quite immune to the effects, and titles that don't support the original Game Boy would probably only show their respective GBC only screens.
So glad to see you're back, ZZAZZ! My sibling and I don't really share many common interests, but Pokemon glitching and your content in particular is something we can both agree on. Happy to have a new video we can discuss together, and I'm hoping to see more from you in the future! Fantastic video!
Oh, man, I remember being a kid and just learning about glitches while everyone was trying to figure out how stuff worked. And now, I get to actually understand everything that's going on and keep up with every technical bit that's mentioned, while people that spent years researching the Game Boy figure out exactly how the glitches work in Pokemon. Even the fact that we can have a memory editor is a massive technical breakthrough.
Yoooo welcome back!! This was an interesting one. Learning about the potential for RST 38 to have unknowingly caused 4 4's true cry... It seems that mystery will Never truly die and I can't say I blame you. It's fascinating
I feel like you're the only one that puts good editing in these kinds of videos. Usually glitch channels record on source 480p and add some text on a black background. The only thing missing off of yours is voice over and i can fully binge watch them
Need a video on "fixing" crashes, where the game crashes but with a memory editor either remove the erroneous bit of code that caused the crash or repair it then we can see the game can keep running beyond the crash. If I am not mistaken, I believe you did similar before with one or more of the glitch pokemon or was it glitch move/item, but would be nice to see more.
Well, it would depend on the type of crash. But rarely is just a memory editor going to be enough to recover the CPU, you're going to have to modify the registers and the stack----which would probably require the use of an emulator.
Usually if the LCD is turned off outside of the VBI you’ll see a line or two. If left like that for too long I suppose it may cause damage, but if you power cycle the Game Boy quickly after seeing that it’ll usually be just fine. (This effect is only visible on monochrome Game Boys; the GBC screen just goes blank AFAIK)
Watched all these videos and I still don't understand what a bunch of it is, but i see my childhood game get torn apart from the inside and its fun to watch
babe wake up, new zzazz video (i'm glad you're back! i honestly understand 0 things of the stuff you talk about but i love reading people nerd about their interests!)
