21:36 Every CPU should come with a tiny sticker reading: “WARNING: THIS CPU DOES NOT KNOW THE DIFFERENCE BETWEEN INSTRUCTIONS AND DATA NOR DOES IT CARE”
Instructions are data and have been since the first stored-program computers in the late 1940's. Your web browser compiles Javascript into machine instructions to make your webpages go faster.
This type of exploit is exactly why most modern CPUs have a way to flag pages of memory as being executable or not. If used correctly, it completely prevents this type of exploit (and stuff like the ACE exploits used for the trifoce% run of Ocarina of Time). It’s a really important part of modern cybersecurity because it makes a significant percentage of ACE exploits much harder to execute.
@@EchoFaustMusic true, but most modern architectures/runtime often have memory regions flagged as exclusive for code and everything else can only be regarded as data. This is done for security and safety guarantees, so that shenanigans doesn't happen when you're trying to do serious work.
TH-cam engagement stats be foobazzlin, nummers augminted by 25.7 persen. Wat a hootenanny, bidness fribbulate frumbles crooz and bimble zooble ooper doopin! Meenwhile, skweekles zamboozled by 4.9 persen, crinkamink ramped to the gibblewackes by 19.6 persen.
Started watching Bismuth's video, he said to come watch yours, then you said to watch Bismuth's video, now I'm caught in an infinite loop, hoping for an RTS to come my way
Open bus is basically the result of Nintendo failing to implement the use of a 65x family chip properly. The "correct" way to implement a data bus is to make sure each line on the data bus is connected to ground via a pulldown register, so that if the CPU tries to read from open bus, it'll get $00, and not whatever is on the MDR. The $00 opcode corresponds to the BRK instruction, and that's no accident: It's so that if the CPU finds itself trying to execute code from a place where there's not even any hardwae, a software interrupt will fire and this can enable the program to properly handle the fact it's trying to access open bus. There's not a lot to do for data reads/writes on open bus that aren't instructions, although arguably an engineer could put some logic in the circuit to detect if the bus is being pulled down as a result of the CPU's actions and raise an interrupt or NMI to alert the program of an invalid memory access. It's probably not a huge deal Nintendo botched this particular aspect of implementation, and of course for speedrunners and other fun stuff it's actually kind of neat this happens, and maybe even something like a weird RNG could possibly be implemented using open bus... But if Nintendo was designing a computer someone was actually planning on using, they just opened a gaping security hole on the computer not tying the bus to ground properly, since this open bus behavior is pretty much how arbitrary code execution happens on the SNES. Of course, the 65816 is hardly a CPU you'd find on any computer anyone would want to compromise, but it's still sloppy when you get down to it.
How is it improper if there are no possible negative consequences? A device that the SNES that doesn't even have an operating system doesn't need these security measures. "This would be a problem if Nintendo were making a completely different product" doesn't actually constitute a problem.
nintendo had a very strict testing and approval process for first and especially third parties before they let a game out lol this wouldn't be a problem
I actually completely forgot about it, and should have at least mentioned it. It's just a normal held item (like a springboard, P-switch, etc.) that turns invisible and makes Mario puffy and unable to drop the held item until it runs out. It's why you can't hold another item while puffy, and why you get an item from the goal tape if you finish the level while puffy (see Tubular).
Very detailed explanation. I've heard many times in the past about the chargin' chucks being "powerups" but never heard it explained. Makes me wonder if the chucks sprite properties were victim of copypasta leaving those erroneous bits set. The open bus broadcast analogy was also very understandable.
if i were a coder, i would make these states true for everything so if ya glitched it, no patching unless possible accidentally. "ya got an enemy as a powerup? heres a glitch state."
Some lower-level details on how open bus works at the electrical level, in case anybody's curious: The "memory data register" is a very useful model for understanding the open bus and implementing it in emulators, but no such physical register actually exists within the CPU. Rather, open bus behavior is the result of the analog effects that occur when the CPU attempts to try to read from a digital input that's not connected to anything ("open" in electrical-engineer speak, hence the term "open bus"). The data lines are not being driven by any hardware, and so the voltage on each line is said to be "floating". In many situations, a floating input is unpredictable -- the voltage can fluctuate based on tiny effects such as current leaking from other parts of the system, or even EM waves from nearby electronic devices or radio stations. So, we have to look at the analog characteristics of the circuit to see if we can understand how it will behave. A data bus is made up of very long copper traces on the circuit board, separated from the ground plane by a thin layer of insulating substrate. And two large conductors separated by a thin insulator makes a capacitor! (This effect is called "parasitic capacitance", and engineers usually try to minimize it because it makes it harder to drive the bus lines and thus limits the maximum length and speed of the bus.) In an open-bus scenario, the capacitance of the bus traces will cause the bus lines to tend to stay at whatever voltage they were last driven to before the bus went open -- in other words, each bus line forms a (rudimentary and unintentional) DRAM cell. This is the cause of the "MDR" behavior -- there is no actual memory data register built into the CPU, but the bus itself acts like a register when it doesn't have anything better to do. (For this reason, open bus behavior is not always stable. It's possible that the value on the bus might "leak" out of the capacitors and decay over many consecutive open-bus reads, and flashcarts and other similar devices sometimes have pull-up resistors that can defeat the parasitic capacitance.) Another fun thing that can mess with the open bus in surprising ways is HDMA. An HDMA transfer can interrupt the CPU at any point, even in the middle of an instruction; if it occurs immediately before the CPU reads an open-bus value, it can replace the value you would expect to see on the bus. I'm not sure if this happens often in Super Mario World, but in the Super Metroid speedrunning community this effect is notorious for ruining "GT Spacetime" runs (which rely on open-bus behavior). I'm also currently working on a (soon to be published) TAS that intentionally exploits this effect, by manipulating timings so that HDMA puts a "good" value on the open bus at the right time.
In the Discord server, we've been discussing whether there actually is a physical MDR or not. If there isn't, then something is helping the bus stay stable even for several seconds and minutes at a time. I've done some tests on Super Mario World and Super Mario All-Stars cartridges that let the CPU hang on a JMP $4C4C like in this video, and it doesn't seem to ever decay at all.
@RGMechEx Idk what y'all said on Discord, but I have read the datasheet for the modern W65C22 versatile interface adapter from WDC. The 22S has bus holding devices between each bus pin & the corresponding internal input, each having 3 components, a resistor & 2 inverters. (Shown in sections 3.6, 3.7, & 5.3) (Also, I have no idea what would have some type of bus holding device back then in the SNES... but at least that's a related example.)
@@RGMechEx Maybe the gate capacitance of it's internal MOSFETs? Gate capacitance is way higher than the PCB trace parasitic capacitance, and can hold charge for much longer.
I've been writing a bit of C64 code lately, and that's also a 6502-derived machine, so a lot of this is very familiar. Thanks for doing your part in keeping these from turning into lost arts. If even a few people become interested in low level machine code I think it will help the world just a little bit. 37:55 -> 38:30 "X equals 9 at this point" Oh my oh my oh my. A certain CarlSagan42 might find this a funny coincidence. 41:36 "Memory address $17 holds the status of the buttons" That's wild! Seems like a miracle that this journey through open bus eventually gets out unscathed.
"Seems like a miracle that this journey through open bus eventually gets out unscathed." Exactly my thoughts. Ok so 6502 is simple enough to not have as many modes of failure executing garbage as more complex systems - but still, this is an entirely new level of black magic for me. How in the world was this discovered, or even how did anyone know this tumble through depths of chaotic heck could even possibly be survivable?
@@jwhite5008 data mining is powerful, you see certain things like sprites being flagged as power ups erroneously, and wonder if that can be used for something funny. If you already know of methods to abuse it, then it's just a matter of either further dissection like this, or just testing it out and seeing what happens. If you don't then you can still try to find ways to make it happen by force Or get a lucky accident, like the yoshi tongue thing could totally happen by accident and leave someone confused and wanting to test out new things
@@Charmlie.R Data mining is real until you reach stuff like open bus, manipulating in-game objects to later read them in completely unrelated places, and especially reading code directly from controller inputs...
I just want to bring attention to the fact that the open bus was actually explained in RGME first ever video but the analogy and explanation was much different back then Now, the way is explained here, is a million times better than back then, is very understandsble and covers everything one must know about what it means It just comes to show how much has our boi improved ever since, plz keep up with the amazing work with your videos!
Especially since this is different from the usual 6502-based breadboard computer, where the address decoder is often implemented in discrete logic and it is very unlikely that a given address does not enable any chip on the data bus at all. For example, the NES's memory map mirrors work RAM three times, but the PPU's control registers over a thousand times, simply because nothing else occupies that part of the address space. Even then, without that "holding area" you would be reading floating bit garbage most of the time.
As someone who is just a "mathematician" but doesn't know programing these videos are just fascinating. I had known of the 11 exit glitch from Summoning Salt's video and interesting to see it explained in detail here.
Well coding would be quite interesting to you I feel, as coding is basically math with extra steps, especially assembly, which is all manual for the most part
1:00 Wow, I didn't expect to get slapped in the face with *that* title! XD I was just watching the Bismuth video covering the full run, and I know a lot of more casual viewers enjoy that more surface-level explanation a lot more, but I'm glad there's a much more in-depth explanation by yourself for those like myself that enjoy it!
58:30 Worth noting is that the Mechakoopas actually occupy specific sprite slots (one actually occupies the same slot as sprites carried from the previous level) Also, I think the Peach sprite itself is what triggers some of the effects on its init routine.
I’m doing a computer science A-Level, and this video gave me a better understanding of how the fetch-execute cycle works than any lesson I have ever had. Your content is amazing
I didn’t expect to jump and laugh maniacally when I heard such a phrase uttered an a completely unrelated Mario world video that has to do with explaining niche glitches, but here we are LMAO
@@kales901 'X=9' is a known glitch in the Mario Maker games, where based on the x coordinate of the level (i.e. 9 blocks from the left, and I think also 129 blocks?) interactions with game objects differ on that spot compared to anywhere else in the level. An example would be an exploding Bob-omb normally only destroys a single block to the left, but if that Bob-omb were to be on the 9th block, it would destroy two blocks to the left. And there's many other oddities with other items. ...actually not sure why this happens. Might be a rounding issue in the code? Would be interesting to look into.
I just watched Bismuth's video about the newest 11 exit SMW speedrun and was wondering why I couldn't remember a video by you about the cloud glitch. Turns out you've uploaded them together! xD
How the devil was this ever discovered? Absolutely fascinating walkthrough, especially for those who have watched Ben Eater’s videos on how to make a CPU on a breadboard. Makes for an interesting connection with things like the open bus
Discoveries like these are often made in baby steps. Some people crash their console by stumbling into the glitch by complete accident, and it becomes known that the game can crash there, and then someone figures out a consistent crash setup. It's still not a useful glitch by any measure. Then a hacker, emulator developer or glitch hunter (or all of the above) look at the code and document all the possible outcomes. The Cloud Glitch is discovered proper either here or before this, by someone stumbling into it accidentally or as a result of testing every possible incorrect value. Of course, its usefulness in speedruns wouldn't have been discovered until later when someone likely messing around with an item box cheat likely noticed Bowser behaving weird, hanging around doing nothing for prolonged periods of time and then suddenly attacking and jumping through phases sooner than expected. Someone smart connected all the dots, and here we are. Of course, this is just me guessing.
@@3lH4ck3rC0mf0r7 I'd also add in the possibility that it could be known by disassembling and documenting each pieace of memory. For example, the RAM Map on SMW Central mentions that $14B0 and co are used by Bowser and the Lakitu cloud and that information stood there for many years. The effects of what happens when you bring a cloud into the Bowser battle thus might have been known for years, it just was never put in practice as this could only happen by modifying the level data or as showcased in this video, by putting it into the item box and moreover not let the game crash (and given how it requires basically ACE, that one is the hardest part to figure out).
@@MarioFanGamer659 Only very recently have old games begun to get fully disassembled, documented and decompiled. Complete memory maps with accurate, detailed information on how every region is used just aren't possible without it. Glitches have been found using this information, but it's a more recent phenomenon. Usually the research that results into an ACE setup is more localized, finding where the game crashed in a debugger, figuring out the ways it reacts to the game state prior, and the memory corruption, if it does those things at all, and then targeting specific functions and variables that tend to be of interest (like setting flags and calling functions to load and play the ending cutscene immediately, for instance)
Reverse engineering, basically. The SNES hardware is pretty thoroughly documented at this point. The CPU itself is a 65816, for which you can get plenty of detailed information from Western Design Center on how it works, as that's not really Secret Nintendo Sauce(tm) there. The rest basically comes from disassembling a game and glitch hunting, then examining what happens. I imagine some die-hards gleefully attach logic analyzers to a SNES to see what's happening, although an emulator with a debugger probably does just as well.
The entire Magic Open Bus Ride section is so complicated that it's a marvel that we can even make games at all. Amazing work on this explanation and video!
Fascinating! I didn't really think the explanation would go deeper than CPU instructions, but here we are! Open bus explained with ease, great work with the analogy and animations! It's enlightening to see how much work goes into fetching a CPU instruction and its parameters. **crickets**
it's not the language that matters, you could do this in c as well the problem is the os which in smw is nothing! so it lets anything happen with no restrictions modern systems have oses that are very careful of where you read write and execute, even if you code in assembly (ever heard of Segmentation fault?)
there are people who prefer that, for good reason! Of course for real software that you want to run safely in the real world, it's far too complex and prone to error to even be considered at this point… but it's a valuable skill to have, and for personal hobby projects, sure why not play around with it.
Just want to say that I love this channel and to keep on doing what you do. There are no other channels like this one that put the extra homework and love into this. Thank you.
your channel is awesome both for entertainment of seeing how glitches work but also I think it is a really good way to start to learn how computers work, it is much less abrupt than daunting books and articles on low level stuff
The planet explanation you used for read and write in terms of code has just changed my life, as a programmer this has always bugged me in a way i couldn't explain then now as a AI dev I can never unsee that, THANK YOU!
I wonder if the Chargin Chucks were originally intended to be eaten and give an item (a football? or maybe some coins). I'd be willing to bet that being able to eat them made the places they're used too easy to clear and the behaviour was removed.
I had no idea about this speed run, but the explanation was fascinating. On the SNES, is efficient memory management not as critical, where a developer can "waste" memory just to be safe?
Yeah it'd definitely not as big of a deal as say, the NES. There's 128 kB of work RAM to use, and Super Mario World uses it very generously (along with a lot of unused sections).
It depends on the type of memory, at least. With 128KiB, WRAM is plenty, though there are games which only ended up needing half of it. Others, on the other hand, need so much RAM that they even have to include additional RAM from cartridge beyond saving the data (not just these with enhancement chips but also those without). However, what also contributes to not using all of WRAM is the fact that the CPU can further use of ROM which is freely accessible. This is different to video and audio as the PPU and SMP can only access VRAM and ARAM, respectively and as a result, the developers have squeeze out as much from the 64 KiB each as possible.
My friend attempted this speed run and got an almost world record time, but his recording software bugged out and it never worked. This video helped him out a ton, so I’m giving an indirect thanks.
I took a Computer Architecture course this term at my university so it was really cool to hear the terms I learned this term (PC, RAM blocks and more) in use! Thanks for the video
It's funny just how I've been doing the Cloud Glitch for a while now in order to get better PBs and while I did have to understand the very basics of what was going on in order to get the glitch in the first place, I've never actually delved into the inner workings of the actual glitch in such details like it was explained here. I will have to re watch this explanation (Specifically on why the B5 value is needed and how to back it up) in order to get more successful attempts so I don't have to reset as much. Thank you so much for this video!
Watching the open bus code tracing, I realized how fortunate it was that there were no instructions along the way that manipulated the stack, which would have broken the return back to regular execution. Most excellent video, the time just melted away!
Bismuth sent me here from his video, I already started doing a deep dive. Your playlist on the snes hardware/software had my attention all day long, super interesting concepts with equally beautiful visuals ❤
For the pedantic among you: Yes I know what is unmapped is a virtual memory _address_ , not the memory itself. And actually more so, a _region_ of virtual memory address space is unmapped. But come on, the joke wouldn't work if I went into all that. 😉
I really appreciate the devotion to making sure the watcher doesn’t get lost, but the easiest place to get lost IMO is the radix (indexing in particular), which you kinda speed past
its insane how much you can fundamentally break this game, its also insane how youtubes auto game detection in the description is also still fundamentally broken saying that this game was the original arcade Mario Bros
Absolutely brilliant video! You explain things so well, I've been watching your channel for a long time and your videos have always been so interesting and educational! You helped me find my passion for game programming, and I still love to watch your amazing explanations for these fascinating topics now that I'm making my own games, thank you so much for your work ❤
Amazing video, I swear your videos get better with each new one you create! The way you explain how everything works is super clear - I've heard of concepts like open bus before but haven't understood them until watching this. Thank you!
These are ridiculously in depth explanations. I play with code on NES and SNES games, but I have no where near the knowledge required to elaborate to this degree
6-1-23 So, effectively, here's what happens: The SNES tries to get information and launches itself, trying to find the information it needs to complete the task. However, something goes wrong on its Navigation software. After Yoshi eats the Chargin' Chuck, it gives the SNES the address of $014A13, sending it off into the Void of Open Bus. The SNES tries desperately to find its way, but everytime it tries to communicate with ANYTHING, it just comes back empty. The player needs to help it find its way back. The Variables all align perfectly to allow it to find its way. Eventually, after 767 BPL Instructions, at $018007, the SNES finds its way to the Wilds of the ROM Planet. It gets found and returns back home, with a Lakitu Cloud in Tow. The Stars have to align for you to be able to get the Cloud without the SNES crashing.
So, it boils down to "This object was never expected to be in the same room as Bowser, so it uses some of the same memory addresses as the boss object, which if manipulated properly, makes timers shorter than they usually would be, causing phases of the fight to be easily skippable.". Takes all of 15 seconds to say, but that isn't nearly as interesting.
So the goal is to get executable code by building an _incredible machine_ that causes a read into a void to generate it's own executable code that also returns back to where it started. That's a hellova glitch.
The TAS community has a more strict definition of arbitrary code execution, and using the controller buttons, sprite position and speed to manipulate open bus falls under that. For real-time speedruns though, the rules are more relaxed. It's not so much about banning ACE altogether, but only allowing just enough to be able to get the cloud without crashing the game. The run is ultimately about beating the 11 intended levels and defeating Bowser as fast as possible without major skips. It's slightly arbitrary itself, but it's what most runners find fun to play.
WAIT. That video was more than an hour? I swear I didn't noticed. Now it's 2am. But the most impressive thing is that I actually understood it! I'm a biologist with no good knowledge of SNES programming. That's proof of the excellent RGME's didactics.
Darbian explaining frame rules: "Imagine a bus..."
RGME explaining a bus: "Imagine the planet Earth..."
Underrated comment
@@Bismuth9
so true
@@Bismuth9 so true!!
@@Bismuth9 yoo bismuth wassup
@@Bismuth9 83
21:36 Every CPU should come with a tiny sticker reading: “WARNING: THIS CPU DOES NOT KNOW THE DIFFERENCE BETWEEN INSTRUCTIONS AND DATA NOR DOES IT CARE”
Modern processors often dedicate a bit in the page of an address to indicate wheter the memory should be executable or not.
Instructions are data and have been since the first stored-program computers in the late 1940's. Your web browser compiles Javascript into machine instructions to make your webpages go faster.
This type of exploit is exactly why most modern CPUs have a way to flag pages of memory as being executable or not. If used correctly, it completely prevents this type of exploit (and stuff like the ACE exploits used for the trifoce% run of Ocarina of Time). It’s a really important part of modern cybersecurity because it makes a significant percentage of ACE exploits much harder to execute.
Most CPU just do what you tell it to. Whether or not it's gonna crash everything is determined on what ya do
@@EchoFaustMusic true, but most modern architectures/runtime often have memory regions flagged as exclusive for code and everything else can only be regarded as data. This is done for security and safety guarantees, so that shenanigans doesn't happen when you're trying to do serious work.
When you see a video from Retro Video Game Mechanics Explained that lasts for over an hour, you know you're in for a ride
Right? I saw the video length and had to look again.
yeah
TH-cam engagement stats be foobazzlin, nummers augminted by 25.7 persen. Wat a hootenanny, bidness fribbulate frumbles crooz and bimble zooble ooper doopin! Meenwhile, skweekles zamboozled by 4.9 persen, crinkamink ramped to the gibblewackes by 19.6 persen.
When you see a video you like that is long, you know it will be a long time.
A magic open bus ride
Started watching Bismuth's video, he said to come watch yours, then you said to watch Bismuth's video, now I'm caught in an infinite loop, hoping for an RTS to come my way
Here's the RTS
JSR GoToRickroll
I think we need Summoning Salt for this
eating a football player
Yo jan Misali!
eating a football player
eating a football player
Eating a football player
eating a football
Open bus is basically the result of Nintendo failing to implement the use of a 65x family chip properly. The "correct" way to implement a data bus is to make sure each line on the data bus is connected to ground via a pulldown register, so that if the CPU tries to read from open bus, it'll get $00, and not whatever is on the MDR. The $00 opcode corresponds to the BRK instruction, and that's no accident: It's so that if the CPU finds itself trying to execute code from a place where there's not even any hardwae, a software interrupt will fire and this can enable the program to properly handle the fact it's trying to access open bus. There's not a lot to do for data reads/writes on open bus that aren't instructions, although arguably an engineer could put some logic in the circuit to detect if the bus is being pulled down as a result of the CPU's actions and raise an interrupt or NMI to alert the program of an invalid memory access.
It's probably not a huge deal Nintendo botched this particular aspect of implementation, and of course for speedrunners and other fun stuff it's actually kind of neat this happens, and maybe even something like a weird RNG could possibly be implemented using open bus... But if Nintendo was designing a computer someone was actually planning on using, they just opened a gaping security hole on the computer not tying the bus to ground properly, since this open bus behavior is pretty much how arbitrary code execution happens on the SNES.
Of course, the 65816 is hardly a CPU you'd find on any computer anyone would want to compromise, but it's still sloppy when you get down to it.
How is it improper if there are no possible negative consequences? A device that the SNES that doesn't even have an operating system doesn't need these security measures. "This would be a problem if Nintendo were making a completely different product" doesn't actually constitute a problem.
nintendo had a very strict testing and approval process for first and especially third parties before they let a game out lol this wouldn't be a problem
It is rather strange that the P-Balloon isn't counted as a powerup by the game
I actually completely forgot about it, and should have at least mentioned it. It's just a normal held item (like a springboard, P-switch, etc.) that turns invisible and makes Mario puffy and unable to drop the held item until it runs out. It's why you can't hold another item while puffy, and why you get an item from the goal tape if you finish the level while puffy (see Tubular).
Same with the 3-Up Moon, given the 1-Up Mushroom is a powerup.
@@2WaterGuns The 3-Up Moon is actually an Object, like a coin or a block, not a sprite. Its Extended Object 0x18 in the game.
3-up moons are also kept track of (they won’t reappear until the game is reset or powered off).
@@Realrich456 It was probably done that way to reuse code from the Dragon Coins, since copy & paste is much easier than starting from scratch.
“Oh nice this will be a good short little video talking about how the cloud glitches out Bowser’s AI script.”
*looks at timestamp*
Done this so many times get like 10 mins in then i look at the time and am like tf xD
Most interestingly, the rl span of the code time during execution (of the explained parts) is only a few 10s of milliseconds.
Also in the video: "please watch this video for a deeper explanation. And that one too, I won't explain the details here."
Very detailed explanation. I've heard many times in the past about the chargin' chucks being "powerups" but never heard it explained. Makes me wonder if the chucks sprite properties were victim of copypasta leaving those erroneous bits set. The open bus broadcast analogy was also very understandable.
@@paulmccartney2327 Are you going to respond to every comment with that? We get it, you don't like furries.
@@JorWat25 I just went ahead and reported every single one of them for harassment.
@Pinkamena! I also would like to know that.
@@rruhland you sir are an ally
if i were a coder, i would make these states true for everything so if ya glitched it, no patching unless possible accidentally.
"ya got an enemy as a powerup? heres a glitch state."
Some lower-level details on how open bus works at the electrical level, in case anybody's curious:
The "memory data register" is a very useful model for understanding the open bus and implementing it in emulators, but no such physical register actually exists within the CPU. Rather, open bus behavior is the result of the analog effects that occur when the CPU attempts to try to read from a digital input that's not connected to anything ("open" in electrical-engineer speak, hence the term "open bus"). The data lines are not being driven by any hardware, and so the voltage on each line is said to be "floating".
In many situations, a floating input is unpredictable -- the voltage can fluctuate based on tiny effects such as current leaking from other parts of the system, or even EM waves from nearby electronic devices or radio stations. So, we have to look at the analog characteristics of the circuit to see if we can understand how it will behave. A data bus is made up of very long copper traces on the circuit board, separated from the ground plane by a thin layer of insulating substrate. And two large conductors separated by a thin insulator makes a capacitor! (This effect is called "parasitic capacitance", and engineers usually try to minimize it because it makes it harder to drive the bus lines and thus limits the maximum length and speed of the bus.)
In an open-bus scenario, the capacitance of the bus traces will cause the bus lines to tend to stay at whatever voltage they were last driven to before the bus went open -- in other words, each bus line forms a (rudimentary and unintentional) DRAM cell. This is the cause of the "MDR" behavior -- there is no actual memory data register built into the CPU, but the bus itself acts like a register when it doesn't have anything better to do. (For this reason, open bus behavior is not always stable. It's possible that the value on the bus might "leak" out of the capacitors and decay over many consecutive open-bus reads, and flashcarts and other similar devices sometimes have pull-up resistors that can defeat the parasitic capacitance.)
Another fun thing that can mess with the open bus in surprising ways is HDMA. An HDMA transfer can interrupt the CPU at any point, even in the middle of an instruction; if it occurs immediately before the CPU reads an open-bus value, it can replace the value you would expect to see on the bus. I'm not sure if this happens often in Super Mario World, but in the Super Metroid speedrunning community this effect is notorious for ruining "GT Spacetime" runs (which rely on open-bus behavior). I'm also currently working on a (soon to be published) TAS that intentionally exploits this effect, by manipulating timings so that HDMA puts a "good" value on the open bus at the right time.
In the Discord server, we've been discussing whether there actually is a physical MDR or not. If there isn't, then something is helping the bus stay stable even for several seconds and minutes at a time. I've done some tests on Super Mario World and Super Mario All-Stars cartridges that let the CPU hang on a JMP $4C4C like in this video, and it doesn't seem to ever decay at all.
@RGMechEx Idk what y'all said on Discord, but I have read the datasheet for the modern W65C22 versatile interface adapter from WDC. The 22S has bus holding devices between each bus pin & the corresponding internal input, each having 3 components, a resistor & 2 inverters. (Shown in sections 3.6, 3.7, & 5.3) (Also, I have no idea what would have some type of bus holding device back then in the SNES... but at least that's a related example.)
@@RGMechEx Maybe the gate capacitance of it's internal MOSFETs? Gate capacitance is way higher than the PCB trace parasitic capacitance, and can hold charge for much longer.
@@RGMechEx I used to work with 74HC logic gates, you can flip a logic gate just by touching it's floating pins, and it will stay for a very long time.
I've been writing a bit of C64 code lately, and that's also a 6502-derived machine, so a lot of this is very familiar. Thanks for doing your part in keeping these from turning into lost arts. If even a few people become interested in low level machine code I think it will help the world just a little bit.
37:55 -> 38:30 "X equals 9 at this point"
Oh my oh my oh my. A certain CarlSagan42 might find this a funny coincidence.
41:36 "Memory address $17 holds the status of the buttons"
That's wild! Seems like a miracle that this journey through open bus eventually gets out unscathed.
"Oh my oh my oh my. A certain CarlSagan42 might find this a funny coincidence."
That or TanukiDan who wrote this song (or both).
"Seems like a miracle that this journey through open bus eventually gets out unscathed."
Exactly my thoughts.
Ok so 6502 is simple enough to not have as many modes of failure executing garbage as more complex systems - but still, this is an entirely new level of black magic for me.
How in the world was this discovered, or even how did anyone know this tumble through depths of chaotic heck could even possibly be survivable?
@@jwhite5008 data mining is powerful, you see certain things like sprites being flagged as power ups erroneously, and wonder if that can be used for something funny. If you already know of methods to abuse it, then it's just a matter of either further dissection like this, or just testing it out and seeing what happens. If you don't then you can still try to find ways to make it happen by force
Or get a lucky accident, like the yoshi tongue thing could totally happen by accident and leave someone confused and wanting to test out new things
@@Charmlie.R Data mining is real until you reach stuff like open bus, manipulating in-game objects to later read them in completely unrelated places, and especially reading code directly from controller inputs...
idk how to feel about the fact that the instant x=9 was mentioned, i lost my mind like i just discovered the hidden meaning of life
I know it's a good day when he uploads a video that's over an hour long for 1 glitch
There's several glitches.
@@henke37
But an hour was spent on one of the two entire glitches showcased here.
So the point still stands.
I just want to bring attention to the fact that the open bus was actually explained in RGME first ever video but the analogy and explanation was much different back then
Now, the way is explained here, is a million times better than back then, is very understandsble and covers everything one must know about what it means
It just comes to show how much has our boi improved ever since, plz keep up with the amazing work with your videos!
Man... all the explanations about Open Bus always confused me, but the explanation in this video was just BRILLIANT.
Thank you very much! XD
Especially since this is different from the usual 6502-based breadboard computer, where the address decoder is often implemented in discrete logic and it is very unlikely that a given address does not enable any chip on the data bus at all. For example, the NES's memory map mirrors work RAM three times, but the PPU's control registers over a thousand times, simply because nothing else occupies that part of the address space. Even then, without that "holding area" you would be reading floating bit garbage most of the time.
29:50 the address being "D00D1E" actually made me laugh a bit
Could either be Doodle, or Doodie
💀💀💀
😭✋
As someone who is just a "mathematician" but doesn't know programing these videos are just fascinating. I had known of the 11 exit glitch from Summoning Salt's video and interesting to see it explained in detail here.
I recommend the talk "Reverse-engineering the MOS 6502 CPU" by Michael Steil and Ben Eater's series about creating a 6502 computer on a breadboard.
Seconded, watch Ben's breadboard series and prepare to understand how computers work!
Well coding would be quite interesting to you I feel, as coding is basically math with extra steps, especially assembly, which is all manual for the most part
1:00 Wow, I didn't expect to get slapped in the face with *that* title! XD
I was just watching the Bismuth video covering the full run, and I know a lot of more casual viewers enjoy that more surface-level explanation a lot more, but I'm glad there's a much more in-depth explanation by yourself for those like myself that enjoy it!
Yeah, kinda weird they made the same video at the same time. Different overall videos, but the topic is very similar.
58:30 Worth noting is that the Mechakoopas actually occupy specific sprite slots (one actually occupies the same slot as sprites carried from the previous level)
Also, I think the Peach sprite itself is what triggers some of the effects on its init routine.
I’m doing a computer science A-Level, and this video gave me a better understanding of how the fetch-execute cycle works than any lesson I have ever had.
Your content is amazing
As someone who's seen quite a few Mario Maker videos over the years, hearing 'X=9' at 38:33 sent my brain into fight-or-flight mode.
SAME LMFAO
I didn’t expect to jump and laugh maniacally when I heard such a phrase uttered an a completely unrelated Mario world video that has to do with explaining niche glitches, but here we are LMAO
why
@@kales901
'X=9' is a known glitch in the Mario Maker games, where based on the x coordinate of the level (i.e. 9 blocks from the left, and I think also 129 blocks?) interactions with game objects differ on that spot compared to anywhere else in the level.
An example would be an exploding Bob-omb normally only destroys a single block to the left, but if that Bob-omb were to be on the 9th block, it would destroy two blocks to the left. And there's many other oddities with other items.
...actually not sure why this happens. Might be a rounding issue in the code? Would be interesting to look into.
@@Meteorite_Shower ok
I just watched Bismuth's video about the newest 11 exit SMW speedrun and was wondering why I couldn't remember a video by you about the cloud glitch. Turns out you've uploaded them together! xD
35:00 this is the best, most intuitive way of demonstrating what a typical glitch/bug induced crash may look like on a technical level.
Bro, I love how you guys coordinate. This is great.
How the devil was this ever discovered? Absolutely fascinating walkthrough, especially for those who have watched Ben Eater’s videos on how to make a CPU on a breadboard. Makes for an interesting connection with things like the open bus
Discoveries like these are often made in baby steps.
Some people crash their console by stumbling into the glitch by complete accident, and it becomes known that the game can crash there, and then someone figures out a consistent crash setup. It's still not a useful glitch by any measure.
Then a hacker, emulator developer or glitch hunter (or all of the above) look at the code and document all the possible outcomes. The Cloud Glitch is discovered proper either here or before this, by someone stumbling into it accidentally or as a result of testing every possible incorrect value.
Of course, its usefulness in speedruns wouldn't have been discovered until later when someone likely messing around with an item box cheat likely noticed Bowser behaving weird, hanging around doing nothing for prolonged periods of time and then suddenly attacking and jumping through phases sooner than expected.
Someone smart connected all the dots, and here we are.
Of course, this is just me guessing.
@@3lH4ck3rC0mf0r7 I'd also add in the possibility that it could be known by disassembling and documenting each pieace of memory. For example, the RAM Map on SMW Central mentions that $14B0 and co are used by Bowser and the Lakitu cloud and that information stood there for many years. The effects of what happens when you bring a cloud into the Bowser battle thus might have been known for years, it just was never put in practice as this could only happen by modifying the level data or as showcased in this video, by putting it into the item box and moreover not let the game crash (and given how it requires basically ACE, that one is the hardest part to figure out).
@@MarioFanGamer659 Only very recently have old games begun to get fully disassembled, documented and decompiled. Complete memory maps with accurate, detailed information on how every region is used just aren't possible without it.
Glitches have been found using this information, but it's a more recent phenomenon. Usually the research that results into an ACE setup is more localized, finding where the game crashed in a debugger, figuring out the ways it reacts to the game state prior, and the memory corruption, if it does those things at all, and then targeting specific functions and variables that tend to be of interest (like setting flags and calling functions to load and play the ending cutscene immediately, for instance)
Reverse engineering, basically. The SNES hardware is pretty thoroughly documented at this point. The CPU itself is a 65816, for which you can get plenty of detailed information from Western Design Center on how it works, as that's not really Secret Nintendo Sauce(tm) there.
The rest basically comes from disassembling a game and glitch hunting, then examining what happens. I imagine some die-hards gleefully attach logic analyzers to a SNES to see what's happening, although an emulator with a debugger probably does just as well.
5:44 "Swallow it it immediately" Nice.
The entire Magic Open Bus Ride section is so complicated that it's a marvel that we can even make games at all. Amazing work on this explanation and video!
Fascinating! I didn't really think the explanation would go deeper than CPU instructions, but here we are! Open bus explained with ease, great work with the analogy and animations! It's enlightening to see how much work goes into fetching a CPU instruction and its parameters. **crickets**
You know it's a good day when RGME and Bismuth release videos in tandem.
Over an hour of RGME makes me smile. That powerup visual is super satisfying ngl
27:05 it was at this moment in the video I realized SRAM is MARS backwards, and now I can't unsee it.
Dang, missed opportunity to make it the red planet.
Great now I can't unsee it either
Assembly sounds fun. No safety nets, no handholding. The cpu just continues doing whatever it thinks it should be doing.
Yes, but coding directly in assembly just isn't done anymore
it is, until it isnt
@@FFKonoko its not exactly practical for anything anymore but the tools are still maintained for modern systems
it's not the language that matters, you could do this in c as well
the problem is the os which in smw is nothing! so it lets anything happen with no restrictions
modern systems have oses that are very careful of where you read write and execute, even if you code in assembly (ever heard of Segmentation fault?)
there are people who prefer that, for good reason! Of course for real software that you want to run safely in the real world, it's far too complex and prone to error to even be considered at this point… but it's a valuable skill to have, and for personal hobby projects, sure why not play around with it.
The casual "DOODIE" in the open bus explanation made me giggle
Deadpan "Part 1: eating a football player" is the best sentence I've ever heard in my life.
Just want to say that I love this channel and to keep on doing what you do.
There are no other channels like this one that put the extra homework and love into this. Thank you.
WOW! Great explanation!
Nice, nothing can make me more happy than over an hour technical stuff about retro games!
your channel is awesome both for entertainment of seeing how glitches work but also I think it is a really good way to start to learn how computers work, it is much less abrupt than daunting books and articles on low level stuff
"Part 1: Eating a Football Player"
Shoutout to RGMechEx for either captioning this whole 1:12:54 video or having somebody else caption the whole thing
26:20
(00-7B, 80-FF)8000-FFFF: ROM
(00-3F, 80-BF)0000-1FFF, (7C-7F)0000-FFFF: WRAM
(70-7B, F0-FF)0000-7FFF: SRAM
(00-3F, 80-BF)2200-25FF: CPU
(00-3F, 80-BF)4000-43FF: Joy
(00-3F, 80-BF)4400-47FF: PPU
(00-3F, 80-BF)2000-21FF, 2600-3FFF, 4800-7FFF, (40-6F, C0-EF)0000-7FFF: Open Bus
38:34 X equals 9. Science Yoshi's racing the clock and it ain't no joke.
Casually:
"Part 1: Eating a football player"
Ok, a reasonable start... But now I need to know what the next parts are
The planet explanation you used for read and write in terms of code has just changed my life, as a programmer this has always bugged me in a way i couldn't explain then now as a AI dev I can never unsee that, THANK YOU!
I wonder if the Chargin Chucks were originally intended to be eaten and give an item (a football? or maybe some coins). I'd be willing to bet that being able to eat them made the places they're used too easy to clear and the behaviour was removed.
"It's a stone Luigi, you didn't make it!"
@@dontworry4945 "It's a football, I chiseled it!"
@@anstheram "Well, what are you waiting for, throw me a pass!"
I feel like it would have been for an earlier version of the cape since some leaked sprites depicted Mario wearing a helmet with the cape.
50:30 that the stars line up like that in any reproducible way is quite stunning 😂
absolutely beautiful distraction on a hellish day... an hour?? a whole hour??? life is beautiful despite its cruelties. thank you. o7
The amount of time it took to put together the visual portion of this video and line it up with commentary had to be astronomical.
I had no idea about this speed run, but the explanation was fascinating. On the SNES, is efficient memory management not as critical, where a developer can "waste" memory just to be safe?
Yeah it'd definitely not as big of a deal as say, the NES. There's 128 kB of work RAM to use, and Super Mario World uses it very generously (along with a lot of unused sections).
It depends on the type of memory, at least.
With 128KiB, WRAM is plenty, though there are games which only ended up needing half of it. Others, on the other hand, need so much RAM that they even have to include additional RAM from cartridge beyond saving the data (not just these with enhancement chips but also those without). However, what also contributes to not using all of WRAM is the fact that the CPU can further use of ROM which is freely accessible.
This is different to video and audio as the PPU and SMP can only access VRAM and ARAM, respectively and as a result, the developers have squeeze out as much from the 64 KiB each as possible.
My friend attempted this speed run and got an almost world record time, but his recording software bugged out and it never worked. This video helped him out a ton, so I’m giving an indirect thanks.
I took a Computer Architecture course this term at my university so it was really cool to hear the terms I learned this term (PC, RAM blocks and more) in use! Thanks for the video
I loved every moment of this. Your visuals and explanation were really well done great job!
It's funny just how I've been doing the Cloud Glitch for a while now in order to get better PBs and while I did have to understand the very basics of what was going on in order to get the glitch in the first place, I've never actually delved into the inner workings of the actual glitch in such details like it was explained here.
I will have to re watch this explanation (Specifically on why the B5 value is needed and how to back it up) in order to get more successful attempts so I don't have to reset as much.
Thank you so much for this video!
Came from Bismuth, incredibly interesting video! Learned how to write assembly code recently so this was a great watch.
"eating a football player"
HUH?
Once again I am amazed at the lengths speed runners go to break games! Excellent explanation!
I like how both Bismuth and RGME uploaded a video on the same Speedrun within an hour of each other lol
1hour RGMechEX video. My face literally morphed into a pog when I saw the length. You're the best.
Watching the open bus code tracing, I realized how fortunate it was that there were no instructions along the way that manipulated the stack, which would have broken the return back to regular execution.
Most excellent video, the time just melted away!
"part one, eating a football player"
I tabbed back in so fast
Bismuth sent me here from his video, I already started doing a deep dive. Your playlist on the snes hardware/software had my attention all day long, super interesting concepts with equally beautiful visuals ❤
26:08
Phoebe: "We never went to unmapped memory at my old school"
For the pedantic among you:
Yes I know what is unmapped is a virtual memory _address_ , not the memory itself.
And actually more so, a _region_ of virtual memory address space is unmapped.
But come on, the joke wouldn't work if I went into all that. 😉
it's my sleepover, i pick the movie
I really appreciate the devotion to making sure the watcher doesn’t get lost, but the easiest place to get lost IMO is the radix (indexing in particular), which you kinda speed past
5:39 "Swallow it it immediately"
you've done it again, RGME. seeing this all happen is so cool!
1:00 i fucking died how he just said that like it wasnt the weirdest thing ever 💀💀💀he could have said chargin chuck but chose to say football player 💀
Imagine he does a video at this depth explaining every step of a ACE run where they code snake or something like what sethbling did.
The video explaining Triforce% is a very in-depth explanation of loading custom behaviors into Ocarina of Time using ACE.
that would be the absolute dreeeaaam
its insane how much you can fundamentally break this game, its also insane how youtubes auto game detection in the description is also still fundamentally broken saying that this game was the original arcade Mario Bros
"Eating a football player" feels like it would fit in with one of those out of context videos.
exactly.
Amazing video as always. Really accessible explanations of the open bus trip
Just wondering, why is the cloud's smile a little broken? And why does it switch from time to time from being visible to invisible?
Okay, I did part one, and I'm in jail. What do I do next?
spin jump at just height and angle and you can clip between the bars
Absolutely brilliant video! You explain things so well, I've been watching your channel for a long time and your videos have always been so interesting and educational! You helped me find my passion for game programming, and I still love to watch your amazing explanations for these fascinating topics now that I'm making my own games, thank you so much for your work ❤
This being uploaded super close to Bismuth's SMW 11 Exit WR Explained vid is so cool
29:50 imagine trying to read D00D1E
Doodle
@@Cacodevidro432 doodie
Amazing video, I swear your videos get better with each new one you create! The way you explain how everything works is super clear - I've heard of concepts like open bus before but haven't understood them until watching this. Thank you!
These are ridiculously in depth explanations. I play with code on NES and SNES games, but I have no where near the knowledge required to elaborate to this degree
bismuth to retro game mechanics explained true combo
LOVED IT! It's a really good explanation! Thank you very very much! You clarified another "how do speedrunners do it". Thank you very very much!!!
Made my day with this ONE HOUR upload. I love your videos and probably watch at least one daily.
4:58 You added an extra It to "Will yoshi swallow it immediately".
6-1-23
So, effectively, here's what happens:
The SNES tries to get information and launches itself, trying to find the information it needs to complete the task. However, something goes wrong on its Navigation software. After Yoshi eats the Chargin' Chuck, it gives the SNES the address of $014A13, sending it off into the Void of Open Bus. The SNES tries desperately to find its way, but everytime it tries to communicate with ANYTHING, it just comes back empty. The player needs to help it find its way back. The Variables all align perfectly to allow it to find its way. Eventually, after 767 BPL Instructions, at $018007, the SNES finds its way to the Wilds of the ROM Planet. It gets found and returns back home, with a Lakitu Cloud in Tow.
The Stars have to align for you to be able to get the Cloud without the SNES crashing.
The titlecard reading "Part 1: Eating a Football Player" is funnier than I think it has any right to be lol
Love the breakdown of assembly code in retro games!
Thanks for your great explanations, now I understand functions and aspects of SMW's code better than my own!
I love how dedicated speedrunners are, great video! Would love to know who first found this glitch.
oh snap a new RGME video, lemme just
**opens vid**
*1 HOUR*
the earth image at 27:00 is accurate because the UK isn't visible and in reality it's not a real country
So, it boils down to "This object was never expected to be in the same room as Bowser, so it uses some of the same memory addresses as the boss object, which if manipulated properly, makes timers shorter than they usually would be, causing phases of the fight to be easily skippable.".
Takes all of 15 seconds to say, but that isn't nearly as interesting.
So the goal is to get executable code by building an _incredible machine_ that causes a read into a void to generate it's own executable code that also returns back to where it started. That's a hellova glitch.
This was amazing. So clearly and simply explained.
This is super neat, perhaps the most complete explanation of this sort of glitch I’ve ever seen!
I watched the whole video, only to realize at the end that it was 1 hour long, time passes fast when you're doing what you like;
watching your videos!
So why is getting the cloud from the Chuck not banned in 11-exit RTA speedruns, when in the TAS community it's banned for being ACE?
The TAS community has a more strict definition of arbitrary code execution, and using the controller buttons, sprite position and speed to manipulate open bus falls under that. For real-time speedruns though, the rules are more relaxed. It's not so much about banning ACE altogether, but only allowing just enough to be able to get the cloud without crashing the game. The run is ultimately about beating the 11 intended levels and defeating Bowser as fast as possible without major skips. It's slightly arbitrary itself, but it's what most runners find fun to play.
WAIT. That video was more than an hour? I swear I didn't noticed. Now it's 2am. But the most impressive thing is that I actually understood it! I'm a biologist with no good knowledge of SNES programming. That's proof of the excellent RGME's didactics.
Those poor crickets, stuck out there in space
It always takes me a while to get tone to watch your longer videos, but man it's always worth it ❤️
man, the Magic Open Bus Ride is wild
Huh this video and bismuth's SMW video came out within an hour of each other. neat you can never have too much SMW
Bismuth mentions this video at the end of his
I dare you to find another process for anything where the first step involves eating a Football player.
Crazy you and Bismuth release the same kind of video at the same time.