I love figuring out how these old games are built cause I feel like they were built to be on the constant verge of breaking but just barely keeping away from actually exploding all over itself.
They had to build them that way because they had little memory and processor power to work with, so they had to cut all the corners they could. I mean, for bleb's sake, the actual code is kept in the same space as the data, and the're using jumps. One wrong jump is all it takes to execute data as if it were code and explode everything, as this video demonstrates.
Funnily enough, pwning without modern security features like ASLR (random addresses), NX-bit (prevent data from being executed) and stack canaries (detect buffer overflows) were so similar to this NES ACE. I am talking about Windows XP times. Returning to existing code for example is still done to this day with “return-to-libc”. Having an invalid MP3 (M4A) file still crashes the Nintendo 3DS, like eating a chuck with Yoshi does in SMW. Source engine games had similar issues. Some while ago in Team Fortress 2, a player could spawn with a deformed ragdoll model, so everytime he died he could execute arbitrary code on the PCs of EVERY PLAYER ON THE SERVER. He could open up the calculator, but he could also quickly install viruses. of course, nowadays, one update patches everything and NES games are immutable. But all software on modern processors still share the same basic vectors like on the NES :P
+Potato on a stick I'm terrified. Which instruction set are you using? I'm being taught the same instruction set in my computer science class and I'd like to learn more about it
to put it simply: when yoshi eats the mushroom, the chuck really wants to be in item spot 9, which is where the mushroom was, which is on yoshi's tongue. the game doesn't know what to do about this, flips the fuck out, and asks the open bus to solve its problems. the open bus takes the x value of the p-switch and uses it to determine that it needs to look at the sprite of the third dragon coin. if it's empty, the data bus does some stuff to the address and the stack that makes the code look at the x and y values of the block particles. if they were in the right position, the code starts to run the values of the red shells, which tell the game to roll the credits if Mario is facing right and not swimming, which is all well and good, except we cant get him back in the game with that alone. the rest of the code introduces a routine that brings Mario into an encounter with iggy, which brings him back into the game, but since we're going to the credits and not iggy, the game glitches out.
@Beef Bronson: you explain the first part incorrect, the reason why the chargeing chuck spond on yoshi tongue, his because mario interupt yoshi eating the mushroom, causing a nil sprite in slot 9 to be on Yoshi tongue, so the chargeing chuck still see slot 9 being empty at would take that spot to appear, but that empty spot his on Yoshi tongue, making the chargeing chuck appear on Yoshi tongue and then get eaten by Yoshi. The mushroom in the reserve box when it come out it was force into slot 9 since the 2 glitch berries are taking slot 11, and slot 10.
@densch123 : Lets expalining with the real world example: you have 12 basket with numbers on them from 0 to 11, number 0 to 9 are brown basket, while basket 10 and 11 are golden basket, all of the fruit your instructed to put them in basket 9 first except for Pineapple, Pineaplle are instructed to be place in the gold basket number 11 first if it his empty. So you have the normal fruit and then the special fruit, you place a fruit first that his not a Pineapple you have to place it in basket 9 first even thought basket 10, and 11 are empty, then if Baske number 9 to 0 are all full, and you try to put a fruit that his not pineapple even though 10 and 11 are empty, that fruit will go to the trash, it will always search for the highest number besket that it can go to that his empty, the mushroom in this case was the pineapple, so two pineapple as to be already in basket 11, and basket 10, so the next pineapple goes into basket 9, then the buyer bought basket 9, while he bought it the seller takes away the object inside so he carries an empty bucket 9, but the buyer as not notice that yet, that it his empty, and the buyer never notice that bucket 9 his empty, so but the seller knows that bucket 9 his empty, so if the seller put a diffrent fruit in the new basket 9 it will disapear and appear in the buyer same number basket. I'm well aware that in the real world you can't actually do that, that was just an example if the real world would behave like a video game.
This is fascinating. I can barely grasp the concepts involved, but I get it just enough to be very impressed and interested. I like how it is all pure logic down in the metal, but by the way Mario is behaving it looks like witchcraft XD
+JimPlaysGames If you are interested in getting a better understanding down to the bare metal, look up a book called Code www.amazon.com/Code-Language-Computer-Hardware-Software/dp/0735611319 It is a pretty good introduction that is very accessible, but not insulting if you already know how to code. :)
lol asm in mario world isnt that bad i made a captain falcon mod that's in testing but i am trying to make a wavedash power up but i keep getting it to work in a conveyor belt fashion which i dont want i want him to slide.
Hello guys, sethbling here. Today, I'm going to show you something unique. This super Mario Bros cartridge is the only one in the world... Well, here's the other one, but that's it. These two games are one of a kind because me, and a friend made an AI using arbitrary code execution with koopa shells. Here, I'll show you. " This is your fault. I'm going to kill you. And all the cake is gone. You don't even care, do you? " *Unplugs super Mario world* As you can see, it's still glitchy but nothing big. That's about it, thanks for watching
+Bea Al My guess is that someone who knows the assembly language (eg someone who wrote an emulator, or just some nerd), had a debug session open while playing the game, and figured out what code was needed to get to the credits screen. Then they *had to* figure out how to do it early in the game. An interest that became a life style ;P
+Lurvik Pretty much. Basically to figure out this glitch, they looked at an existing glitch which would jump to the sprite X coordinate table located at the OAM (object attribute memory), as those values are easily manipulateble by just moving around sprites on the screen. This glitch happened to be the item swap glitch, the glitch which lets yoshi eat an (I think it has to be a non-charging) chuck. From here, they worked out what code they needed to set the gamemode to the gamemode corresponding to the credits, and assembled it to be byte-code readable by the machine. After having figured out what code they need, they just found a way to manipulate the sprite X coordinate table in such a way that that code would be run by the game, and voila, mario warps to the credits. I am by no means an expert in ASM or SMW glitches in general, there might be mistakes in this explanation. Correct me if I'm wrong.
I think it's more than that. The item swap glitch only causes the SNES to be confused, and execute instructions from open bus. They still had to find a way to then manipulate the open bus value to make the SNES execute a jump instruction to their code they wrote in the sprite coordinate tables. All the stuff about making sure that the mushroom would spawn in slot 9, only collecting one dragon coin, the P-switch being in Slot 6 & having x-coordinate 0EFF, and the y-coordinate of the particles being at a certain range of values was to manipulate the open bus value to do that, I think.
Thank you! It's rare to find a good explanation video of old glitches like this. I liked how you joined those images together to help the explanation. Thank you!
+pannenkoek2012 For the majority of it I use Adobe Premiere. For more detailed stuff like the numbers at 2:54, I created a Java program that displays graphics that I capture with a screen recorder.
SilentDust and the code writing has gotten pretty crazy. look up "tasbot plays mystery game". they've also gone on to re-write pokemon, one of the times they made it connect to the internet and stream twitch chat
+darkmagician135 That's not quite correct. It didn't connect to the internet. The SNES has no internet capabilities. From what I understand, their laptop was connected to the internet and TASbot was connected to the console, translating the text from Twitch chat into button presses while the console translates those button presses back to text. Stuff like "press L and SELECT at the same time" meaning "A" or something along those lines. It's still pretty crazy how quickly it all works. You'd have to get into the detail of how quickly the console can actually register button presses. 'cause just using one letter per frame sounds like it would be way too slow.
It all makes sense, but christ! Who just sits down and figures all this out, let alone timing everything JUST right so all the code falls into place. This is both simply ridiculous and simply amazing!
+ThePixelPaladin F'n-A, that's what I don't get, how you can execute what you want flawlessly, not like you get on screen indicators of what x-y position you're on...
As someone who does reverse code engineering and exploit development for a living, I recognize the extreme level of care and detailed analysis that went into the research and development of this video. I'm sure this took a lot of time to make, especially given the great care that went into the presentation of data on screen. All of the graphics, organization, and detailed step by step display of each register's value, memory address, and the transformation of each subsequent CPU instruction was simply beautiful. It clearly takes someone who has a passion for reversing (and sharing that skill with others) to put so much time and effort into something that sadly isn't going to have an equal level of payback in views and attention because of the limited audience who will understand, even in a very limited/abstract way, what was being explained in the video. I applaud your efforts man, and I thank you for putting so much time into making something that I, and I'm sure many others, enjoyed immensely. You definitely earned my subscription, and I'm anxious to see what other videos you've made, as well as what future videos you will create.
Just wait until you make a deal with Satan to tie a villager to one of those armor stands with a lead and end up with duplicate UUIDs...no amount of gamemode 3 or kill command spam will save you.
It is impossible to explain. Assembly doesn't go well with English as higher level languages like C++ and Java do. Nothing makes any sense, it's all numbers, and numbers designed to behave in very specific ways that would take a huge tutorial to explain in itself. I made an entire program based on corrupting NES and SNES ROMs and had to study a ton of it, and I still don't understand half of it.
I started with assembly and my "4 years moment" would sooner have come with an obscure C++ feature. Within 2 weeks of deciding to edit my sword damage in Minish cap I probably would have understood this video. Maybe you should get into game hacking!
RMoribayashi in hindsight, being able to “compile” a program yourself on paper seems like an amazing consept. It’s like being able to speak another language without an interpreter
I originally saw this video years ago, and just came back because I was playing SMW earlier & it made me remember the vid. Point being, as someone that’s been programming since I was a kid, and have always been known & considered myself a nerd; you sir are some sort of super nerd. I mean that as a compliment. The way that you’re able to explain & break down the code, and the way the hardware runs it. Bravo, sir.
Very interesting - I'm also really curious how this was discovered (most especially how the specifics were mapped). Also, would be killer to see the original coders of the game react to this the first time they saw / heard of it.
I love this video, and the comments/replies to comments helped a lot with understanding the more complicated parts, as well as why certain things work the way they do.
Ah, this is the TH-cam algorithm doing its thing again and I end up with the age old question: "Why the hell am I even watching this???" ... and for some reason I have absolutely no regrets in doing so.
You probably need to know how a computer works and this is not easy. If you got the general idea (they make code with the sprites and then execute it) it's OK.
What I don't fully undertand is this....YOU can interpret the bites as code, but how, and more importantly, why does the GAME do that? Why does it come across this specific series of bites (corresponding to the positions of objects on-screen, and the slots they occupy at the time) and read it as code? I get that it has to do with Yoshi eating Chuck and that causes some kinda weirdness with how the game's memory is read, but that's where you lose me. I still don't understand why the game executes the positions set earier as code.
+PremierMilenkov If you are familiar with programming, you know that you can call a function in say, C, by using its name (e.g. do_something()). In assembly, you have to call a function by using the address in memory at which it is stored (e.g. JSL $009047). In all the address space, $000000 - $FFFFFF, everything is stored, including RAM, ROM, hardware registers, PPU registers, and more. Normally ROM is stored from $xx8000 to $xxFFFF, which is where most of the code is. $xx0000 - $xx7FFF is saved for pretty much everything else. So really you can call a subroutine that exists in ROM or RAM. So in this case we have JSR $00E0 (effective address $0100E0), which is a call to RAM instead of ROM like normal. In fact, SMW does write code to RAM and executes it fairly often, it's just that in our case we get to chose where in RAM we want to "write" a subroutine. Sprite X-positions are super easy to manipulate in game so we just use that.
***** Gah, all too complicated...but I think I may have an inkling of why this works. So basically, you're trying to say, rather than calling a function from the game's normal code, that is the ROM, you force the game to call from RAM, which is where the code you wrote using the sprite positions is stored at the time, correct? And so you have to manipulate the game into starting to execute the code from the addresses where you set up said snippet of code with the object positions.
Awesome video! You won your more subscribe! Could you explain the glitches in Donkey Kong 1? For example, when you use a barrel and the Rino... and then you make a donkey kong riding another donkey kong. Thx
**Alternate attempt to explain this ridiculous exploit** (I knew almost nothing about Assembly before watching this video so bear with me if I've made mistakes in interpreting how it works.) Like so many other games of its era, Super Mario World runs in Assembly language, which can't tell the difference between different kinds of data and is not neatly organized like an object-orientated language is. Nothing has a "name" or a "type" - everything is referred to by memory address, which is labeled with a hexadecimal value. In addition, the raw data in those memory addresses is also hexadecimal, and can itself be read as a memory address or vice versa. You can also happily leap right into the middle of a totally random part in the code as Assembly doesn't formally recognize where one function ends and another begins. Thus, depending on the context, an Assembly program can read the exact same data as code, or graphics, or sound, or a memory address pointing to any of these assets. This makes weird shit happen like the Secret World in Metroid or glitch Pokemon - it's trying to read data as the wrong kind of thing, and horrifying garbage comes out as a result. 12 "sprites" (enemies, pickups etc.) can appear in Super Mario World at a time, and their x/y positions (in hexadecimal) are not cleared unless a new sprite takes up one of these 12 slots and overwrites it. This means you can write (very short) Assembly code by positioning sprites. Particles such as the bits of blocks that fly around when you break them are stored outside of these 12 slots and are partially RNG-based so they're harder to manipulate. Anything Yoshi can normally swallow such as a powerup has a memory address associated that tells the game where to go to run the proper code for that item. The game will basically save its current position in the stack, start running the code found at that address when Yoshi swallows, and return to the address that it put in the stack. You can force Yoshi to eat something he's not supposed to by making him grab a powerup with his tongue, then taking the powerup yourself before he swallows it (might be fixed in US version). This causes the next sprite that loads to replace the powerup Yoshi is eating, causing him to swallow that instead; but because Yoshi is not supposed to eat that, it contains an invalid address (here 014A13) as the location of code to run. When the SNES tries to jump to an invalid memory address to run its code, it instead jumps to the Magic School Bus and runs its value as code, for whatever reason someone decided that was remotely a good idea. The Magic School Bus contains the high byte ("first" byte) of the last value successfully read or written - not the address read FROM or written TO. Some values are read or written a byte at a time, causing the MSB to update with each byte. In addition, this value continues to change as the code read from the MSB is executed, because executing it causes more values to be read and written. The main register and MSB do not "wait" for one another like a single process, so the MSB can return multiple different values within a single line of code. The entire business is highly unintuitive. Because this started from Yoshi eating something, the item that Yoshi ate is referenced in the code, allowing the player to manipulate it. Eventually, this mess causes the game to execute the y positions of the sprites as code. Because that code must be very short (3 lines), it has to be awkward and weird to do what is needed. LDA #$1C stores the value 1C in the accumulator, which is a part of the CPU that remembers numbers when doing complex math. If placed in the right spot, a value of 1C makes the game go to the credits. STA ($75) takes the accumulator value (1C) and stores it in the given address. As an indirect address, the precise location is taken as a value from 75 and 76 (because addresses are two bytes + a presumed 01 at the start.) These addresses correspond to whether Mario is swimming and which direction he is facing. The address needed is 0100, which requires Mario to be facing to the right and not swimming or else it will go to some other address and mess everything up. The code must return to the normal game to stop it from hanging, but to do that it needs to read the return address it left in the stack. Our mindblowing code adventure has added two extra bytes to that stack that need to be removed, so we JUMP to an existing game function at $FF46 to solve both problems. If the destination function had been executed from the start, it would've added 2 bytes to the stack and then taken them back out; but because this code jumps right into the middle, it skips the lines adding +2 bytes to stack and only runs the lines taking 2 out. Even if this function repeats itself for some reason, this -2 deficit will be retained. Also, this function happens to draw Iggy's sprites to the screen, which is why Iggy explodes all over the place. Phew! I hope I've got it right. @ _ @
DracoHandsome but you sound like you know what the opcodes does.. your explanation and wording doesn’t seem like a newbie to me. I’m 1 year in, and that explaination is around my skill level, so I believe you are pretending to not know this stuff
He said he used Adobe Premier for the animations. Any screen recorder works for the recording, however he probably uses OBS because he regularly streams. Any good emulators works for this. Probably using Snes9x or BizHawk. Any good text editor works. Vim/EMACS is enough, but some people like simpler editors, I really don't know.
Cool vid! Was this skip discovered through 'standard' gameplay and then the explanation was reverse engineered or did someone break down the code and then search for an optimum place in game to execute the steps you outline in your video?
George B Most definitely the latter. Super Mario World is probably one of the most documented, reverse-engineered game out there. All it takes is a bunch of thinking and planning along with the knowledge of the game and it's mechanics to come up with something like this.
I understand this. The cliff notes? You swallow a Charging Chuck with everything set up perfectly, and Yoshi and Mario completely break the Space Time continuum
As I understand it, the old credits warp assembly code - the one that jumped to the middle of the credits - was one byte shorter. Suppose you went back to using the old code, but stuck an EA (NOP) at the beginning. Would that double the odds of the credits warp executing successfully, since starting the code from $00E4 or $00E5 would both work? Or would it make no difference in practice?
You can't get E4 or E5 starting points (I think the next after E3 is E6), but you have the right idea. The old old version of the route used 6 bytes. We used the data bus value (4A), divided it by two (25) and stored that to $0100. No LDA was used. The reason it went to the middle of the credits was because it was game mode 25 instead of 1C.
Expanding on that, you could use the old code with the new route that would save one shell position. However, I think we have decided that it is more important that we warp to Yoshi's House since it shows the full enemies list and has a fanfare. Ignoring that, you could probably save a second or two by only placing 5 shells and a P-switch.
I watched this video a few years ago not knowing any programming. A few years later and now able to understand x86 Assembly I'm glad to have found it again now because now I actually understand what's going on even though I don't actually know 65816 Assembly
@@kjl3080 You're fucking kidding me. Hexadecimal is binary. 00 = 00000000, 01 = 00000001... FF = 11111111. It's not that fucking hard. Assembly instructions are written in hexadecimal(binary) and each instruction is the size of the Instruction Register. You wouldn't know what that is since you clearly haven't even taken basic CS yet. Stop arguing on topics you know nothing about.
a wonderful explanation, although a bit too fast. I have a question: there is another end glitch th-cam.com/video/FkQdwUns7H8/w-d-xo.html , but it seems to be much easier. I don't see that the player moved the shells into specific positions, and I don't understand how he triggers the end scene. probably eating a fruit while jumping off? (it is too fast to see)
dracenmarx That TAS uses 4 controllers and inputs that don't exist on console. tasvideos.org/4315S.html The last 5 frames have 121 button inputs, which is why we don't use that route for real-time.
+dracenmarx Aside being impossible, Masterjun did move them into specific positions, but in a TAS you can advance frame by frame. He probably went 1 frame forward until he got the perfect position.
This could all be made up nonsense and I wouldn't know any better...
VivaValdez lmao
VivaValdez it checks out pretty well for me
+ thereal SuperEthan5 :-D Same. I'm taking a CS class and we're learning assembly! It's super fun.
I thought the same thing at a particular point in Bismuth's "Why 4:54 is the perfect speedrun" 😂
Just run address $0069, and if the upload date is 1 April, return nonsense. If not, return false
I love figuring out how these old games are built cause I feel like they were built to be on the constant verge of breaking but just barely keeping away from actually exploding all over itself.
You must absolutely love Pokemon R/B/G then!
They had to build them that way because they had little memory and processor power to work with, so they had to cut all the corners they could. I mean, for bleb's sake, the actual code is kept in the same space as the data, and the're using jumps. One wrong jump is all it takes to execute data as if it were code and explode everything, as this video demonstrates.
Had the same thoughts man! xD
Funnily enough, pwning without modern security features like ASLR (random addresses), NX-bit (prevent data from being executed) and stack canaries (detect buffer overflows) were so similar to this NES ACE. I am talking about Windows XP times.
Returning to existing code for example is still done to this day with “return-to-libc”.
Having an invalid MP3 (M4A) file still crashes the Nintendo 3DS, like eating a chuck with Yoshi does in SMW.
Source engine games had similar issues. Some while ago in Team Fortress 2, a player could spawn with a deformed ragdoll model, so everytime he died he could execute arbitrary code on the PCs of EVERY PLAYER ON THE SERVER. He could open up the calculator, but he could also quickly install viruses.
of course, nowadays, one update patches everything and NES games are immutable.
But all software on modern processors still share the same basic vectors like on the NES :P
as a programmer, I can assure you that literally every piece of software you have ever used is barely held together by duct tape and prayer
This is what women really want.
You sir, are my hero
Sooo they want everything in place and then jump to the happy ending??? o_O
shadowmax889 The girl will only ever accept the man if he spin jumps and manipulates specific sprite slots at various x and y coordinates
F'ing A!!!! LoL!!!!!
Really? They want a credits warp
5:55 "Remember these for later"
Oh man, I hope there's not a quiz at the end, I've already forgotten them :D
Daniel Lo Nigro I was thinking the same thing xD lol
I love how there's "wut" in the URL address of this video xD
"wut_I" Perfect xD
Fits this video perfectly.
Oh, TH-cam and it's Base64 video ID systems.
lol
ibb.co/Hn4hpDN
XD
"I hope you now have a general idea of what's going on behind the screen."
*Magic?*
AHHHHH ASSEMBLY CODE
HOLD ME I'M SCARED
+DragonDePlatino same
LDA [$00],Y
INY
INY
TAX
LDA [$00],Y
INY
INY
STA $2142
SEP #$20
CPX #$0001
LDA #$00
ROL A
STA $2141
ADC #$7F
PLA
STA $2140
CMP $2140
BNE $80D3
BVS $808D
STZ $2140
STZ $2141
You scared yet?
+Potato on a stick I'm terrified. Which instruction set are you using? I'm being taught the same instruction set in my computer science class and I'd like to learn more about it
SkyewardSword I just disassembled the SMW ROM and pasted a part of that in here. 65c816 assembly
+Berzark _ ;)
....whut.
lol
I read that in Billy's voice ;)
Tapaleurre I agree with you and not these other heathens
I'm just a front end web developer :-(
Agreed
to put it simply:
when yoshi eats the mushroom, the chuck really wants to be in item spot 9, which is where the mushroom was, which is on yoshi's tongue. the game doesn't know what to do about this, flips the fuck out, and asks the open bus to solve its problems. the open bus takes the x value of the p-switch and uses it to determine that it needs to look at the sprite of the third dragon coin. if it's empty, the data bus does some stuff to the address and the stack that makes the code look at the x and y values of the block particles. if they were in the right position, the code starts to run the values of the red shells, which tell the game to roll the credits if Mario is facing right and not swimming, which is all well and good, except we cant get him back in the game with that alone. the rest of the code introduces a routine that brings Mario into an encounter with iggy, which brings him back into the game, but since we're going to the credits and not iggy, the game glitches out.
@Beef Bronson: you explain the first part incorrect, the reason why the chargeing chuck spond on yoshi tongue, his because mario interupt yoshi eating the mushroom, causing a nil sprite in slot 9 to be on Yoshi tongue, so the chargeing chuck still see slot 9 being empty at would take that spot to appear, but that empty spot his on Yoshi tongue, making the chargeing chuck appear on Yoshi tongue and then get eaten by Yoshi. The mushroom in the reserve box when it come out it was force into slot 9 since the 2 glitch berries are taking slot 11, and slot 10.
Nope, still makes no sense.
@densch123 no, you do not have to play this game at all to understand the video
@densch123 : Lets expalining with the real world example: you have 12 basket with numbers on them from 0 to 11, number 0 to 9 are brown basket, while basket 10 and 11 are golden basket, all of the fruit your instructed to put them in basket 9 first except for Pineapple, Pineaplle are instructed to be place in the gold basket number 11 first if it his empty. So you have the normal fruit and then the special fruit, you place a fruit first that his not a Pineapple you have to place it in basket 9 first even thought basket 10, and 11 are empty, then if Baske number 9 to 0 are all full, and you try to put a fruit that his not pineapple even though 10 and 11 are empty, that fruit will go to the trash, it will always search for the highest number besket that it can go to that his empty, the mushroom in this case was the pineapple, so two pineapple as to be already in basket 11, and basket 10, so the next pineapple goes into basket 9, then the buyer bought basket 9, while he bought it the seller takes away the object inside so he carries an empty bucket 9, but the buyer as not notice that yet, that it his empty, and the buyer never notice that bucket 9 his empty, so but the seller knows that bucket 9 his empty, so if the seller put a diffrent fruit in the new basket 9 it will disapear and appear in the buyer same number basket. I'm well aware that in the real world you can't actually do that, that was just an example if the real world would behave like a video game.
SuperNickid that’s genuinely even more confusing
Wow... I understood none of that.
+★ ShadowBolt ★ Same here.
TRANSLATION: This glitch makes the credits appear.
ShadowBolt I did understand
im a programmer and i had a bit of a hard time lol
honestly stuff like this is probably more complicated then the actual process that created the game, so dont feel bad.
This is fascinating. I can barely grasp the concepts involved, but I get it just enough to be very impressed and interested. I like how it is all pure logic down in the metal, but by the way Mario is behaving it looks like witchcraft XD
+JimPlaysGames If you are interested in getting a better understanding down to the bare metal, look up a book called Code www.amazon.com/Code-Language-Computer-Hardware-Software/dp/0735611319 It is a pretty good introduction that is very accessible, but not insulting if you already know how to code. :)
Wow, Jim! How is your next game project by the way? I still enjoy 'earth got mooned' from time to time, by the way :)
lol asm in mario world isnt that bad i made a captain falcon mod that's in testing but i am trying to make a wavedash power up but i keep getting it to work in a conveyor belt fashion which i dont want i want him to slide.
I don't understand this shit but I liked it.
Óscar Pérez. Same
#metoo
Can you glitch me up a girl friend?
I wonder how long it will be before some speed runner accidentally discovers the code that allows Super Mario World to become self aware.
umm program AI asm code using shells and run it
Hello guys, sethbling here.
Today, I'm going to show you something unique. This super Mario Bros cartridge is the only one in the world... Well, here's the other one, but that's it.
These two games are one of a kind because me, and a friend made an AI using arbitrary code execution with koopa shells.
Here, I'll show you.
" This is your fault. I'm going to kill you. And all the cake is gone. You don't even care, do you? "
*Unplugs super Mario world*
As you can see, it's still glitchy but nothing big.
That's about it, thanks for watching
What is this? Skynet?
It's at 94df0d
@@sackboy1665 panic
Assembly... buses... things... (Pretending that I'm understanding)
Having somehow understood this, my only question is who on earth took the time to figure this out?!
he did
+Bea Al That's true...
+Bea Al My guess is that someone who knows the assembly language (eg someone who wrote an emulator, or just some nerd), had a debug session open while playing the game, and figured out what code was needed to get to the credits screen. Then they *had to* figure out how to do it early in the game.
An interest that became a life style ;P
+Lurvik Pretty much. Basically to figure out this glitch, they looked at an existing glitch which would jump to the sprite X coordinate table located at the OAM (object attribute memory), as those values are easily manipulateble by just moving around sprites on the screen. This glitch happened to be the item swap glitch, the glitch which lets yoshi eat an (I think it has to be a non-charging) chuck. From here, they worked out what code they needed to set the gamemode to the gamemode corresponding to the credits, and assembled it to be byte-code readable by the machine. After having figured out what code they need, they just found a way to manipulate the sprite X coordinate table in such a way that that code would be run by the game, and voila, mario warps to the credits.
I am by no means an expert in ASM or SMW glitches in general, there might be mistakes in this explanation. Correct me if I'm wrong.
I think it's more than that. The item swap glitch only causes the SNES to be confused, and execute instructions from open bus. They still had to find a way to then manipulate the open bus value to make the SNES execute a jump instruction to their code they wrote in the sprite coordinate tables. All the stuff about making sure that the mushroom would spawn in slot 9, only collecting one dragon coin, the P-switch being in Slot 6 & having x-coordinate 0EFF, and the y-coordinate of the particles being at a certain range of values was to manipulate the open bus value to do that, I think.
7:03 it's nice to know that while Jotaro was studying Marine Biology, Star Platinum was apparently coding in Super Mario World.
good to know that I wasn't the only one thinking that XDD
RickitySplit ORA ORA ORA ORA ORA ORA ORA ORA!
Ya feel like he should be off working on the cure for cancer or something
Hehe funny jojoke
instructions not clear, I have a Yoshi stuck in my urethra
Aw *shoot* here we go again.
😂 thank you for this comment.
i woke up today and i said "i absolutely need to see this comment"
[Insert Franklin's "What?" Here]
what the hell happened here
But first, let's talk about parallel universes.
TheLolCraft Lol
Thank you! It's rare to find a good explanation video of old glitches like this. I liked how you joined those images together to help the explanation. Thank you!
This was incredibly informative. I'm going to go spawn some dolphins where they don't belong.
zenzetra XD
zenzetra or spawn yosi in cloud
spawn as many mario as you can
What did you use to make the animations?
+pannenkoek2012 For the majority of it I use Adobe Premiere. For more detailed stuff like the numbers at 2:54, I created a Java program that displays graphics that I capture with a screen recorder.
pannenkoek2012!
pannenkoek2012 An A press is an A press.
holy shit its the pancake man himself?
pannenkoek2012 PANNENKOEK
I can only imagine the type of memorization needed to get the values just right by eye.
***** I can only think about how anyone came on this idea. "Hey! Lets use sprites to execute code in SMW!"
SilentDust and the code writing has gotten pretty crazy. look up "tasbot plays mystery game". they've also gone on to re-write pokemon, one of the times they made it connect to the internet and stream twitch chat
+darkmagician135 Connect to the internet? Holy shit. Link please. Now.
+darkmagician135 That's not quite correct. It didn't connect to the internet. The SNES has no internet capabilities.
From what I understand, their laptop was connected to the internet and TASbot was connected to the console, translating the text from Twitch chat into button presses while the console translates those button presses back to text. Stuff like "press L and SELECT at the same time" meaning "A" or something along those lines.
It's still pretty crazy how quickly it all works. You'd have to get into the detail of how quickly the console can actually register button presses. 'cause just using one letter per frame sounds like it would be way too slow.
You might not believe me but after you've done it like 10 times you won't need any more help because it will all be in your head after a few times
That was an absolutely incredible video. I have a masters in Computer Science and you blew my mind.
I bet he has a PHD in computer science and his essay thing for getting excepted was on this
+Patata Potato excepted....
EXCEPTED....
Are you kidding me?
Too much Sprites make me thirsty
LOL
Fuck off
ha
"bitch you thirsty please grab a sprite."
a sprite's x position, duh
Well, I think, I think I got it... I mean, I migth lost it at 0:11 when you said "write some code using koopa shells"...
if that lost you then im guessing that coding pong into pokemon using the pokedex is a bit too much also....
clear as water
(screams internally in spanish)
kinsaktube jaja, cierto.
JAJAJAJAJJAJAJAJAJAJA
You:clear as water!
Your mind:DESPACITO!
It all makes sense, but christ! Who just sits down and figures all this out, let alone timing everything JUST right so all the code falls into place. This is both simply ridiculous and simply amazing!
+ThePixelPaladin F'n-A, that's what I don't get, how you can execute what you want flawlessly, not like you get on screen indicators of what x-y position you're on...
You can. Emulators let you look at the entire RAM, so you can keep track of your subpixel perfectly. Also, there is a full assembly dump
It wasn't an individual person that figured it out, it was a lot of people making small discoveries over the course of decades.
As someone who does reverse code engineering and exploit development for a living, I recognize the extreme level of care and detailed analysis that went into the research and development of this video. I'm sure this took a lot of time to make, especially given the great care that went into the presentation of data on screen. All of the graphics, organization, and detailed step by step display of each register's value, memory address, and the transformation of each subsequent CPU instruction was simply beautiful. It clearly takes someone who has a passion for reversing (and sharing that skill with others) to put so much time and effort into something that sadly isn't going to have an equal level of payback in views and attention because of the limited audience who will understand, even in a very limited/abstract way, what was being explained in the video. I applaud your efforts man, and I thank you for putting so much time into making something that I, and I'm sure many others, enjoyed immensely. You definitely earned my subscription, and I'm anxious to see what other videos you've made, as well as what future videos you will create.
14yr old me: "math is dumb, won't ever need that crap"
Nearly 30yr old me: "man thats cool asf! how did they figure that out. oh wait.."
I’m taking differential equations in college rn and I still have no idea what this video is about.
Well if I go into gamemode 3 you'll see these armor stands...
Just wait until you make a deal with Satan to tie a villager to one of those armor stands with a lead and end up with duplicate UUIDs...no amount of gamemode 3 or kill command spam will save you.
Everything related to sethbling is armor stands
5:55 "Remember these for later"
**frantically grabs pen and paper**
Timothy Creasman *and opens eyes as wide as possible and looks at every single detail of the video*
I wonder what the creators think about this glitch! xD
This is impossible to follow without being experienced in coding... :(
Someguy8231 shit ive coded for 4 years and this is too funky for me lmao
It is impossible to explain. Assembly doesn't go well with English as higher level languages like C++ and Java do. Nothing makes any sense, it's all numbers, and numbers designed to behave in very specific ways that would take a huge tutorial to explain in itself.
I made an entire program based on corrupting NES and SNES ROMs and had to study a ton of it, and I still don't understand half of it.
I started with assembly and my "4 years moment" would sooner have come with an obscure C++ feature. Within 2 weeks of deciding to edit my sword damage in Minish cap I probably would have understood this video.
Maybe you should get into game hacking!
I just don't get why anybody would dislike this video.
Thanks, it's been over 40 years since I had to look at assembly code but I had no problem following along.
RMoribayashi in hindsight, being able to “compile” a program yourself on paper seems like an amazing consept. It’s like being able to speak another language without an interpreter
good
thank you
CosmoSpeedruns hey look it's cosmo! xD
CosmoSpeedruns hello babe
this was edited very nicely. reminds me of sancarn, who does really strange minecraft physics theory videos. well done and it was effective : )
In other words, you flip flop the flip table in memory, so it flops into the credits.
“I hope you have a general idea of what is going on…”
This is more thorough and comprehensive than I ever thought I would get!
"I hope you now have a general idea of what's going on behind the scenes"
yup. sure do
that was the most insane assembler joy ride i have ever experienced.
wow
i didn't think Mario world is more complicated than Mario 64
but i won't give up...
I really isn't, the N64 is an incomparable beast
I originally saw this video years ago, and just came back because I was playing SMW earlier & it made me remember the vid. Point being, as someone that’s been programming since I was a kid, and have always been known & considered myself a nerd; you sir are some sort of super nerd. I mean that as a compliment. The way that you’re able to explain & break down the code, and the way the hardware runs it. Bravo, sir.
this shit makes colonizing mars look like child's play
"I hope you now have a general idea of what is going on behind the scenes during the Super Mario World credits warp."
IN NO WAY WHATSOEVER
It takes a bit of thinking but I actually understand everything.
I actually don't grasp what you explained, but it was entertaining nonetheless.
Very interesting - I'm also really curious how this was discovered (most especially how the specifics were mapped).
Also, would be killer to see the original coders of the game react to this the first time they saw / heard of it.
"I hope you now have a general idea of what's going on behind the screen."
My brain: *dial-up noises*
Yea.... what he said....
I'll bet they didn't teach you this in school!
It's not because it's too complex, it's because it's useful.
How did someone figure this out?
Reading the codw
WARNING: Basic understatement of assembly code is required to understand this video...
This is an amazing video man. It's super neato mosquito to see what happens in the background of these runs.
***** Holy sheez you're here
That bus was quite creative. And scientific...
I love this video, and the comments/replies to comments helped a lot with understanding the more complicated parts, as well as why certain things work the way they do.
Great. Now my brain is on fire. Thanks
I love that you made a for dummies version of this. Definitely watching that next
Ah, this is the TH-cam algorithm doing its thing again and I end up with the age old question:
"Why the hell am I even watching this???"
... and for some reason I have absolutely no regrets in doing so.
I don't get most of the technical explanation, but the video and the animation are very well made. Thanks for that.
Nice explanation, even though I didn't catch half of it lol
:)
You probably need to know how a computer works and this is not easy. If you got the general idea (they make code with the sprites and then execute it) it's OK.
This video is a fantastic way to learn how a computer works. Everyone with an interest in computers should watch it.
I barely understood this but it was cool
Dragon Soul Same, I find how game engines actually work very fascinating
Barely isn't even the right word xD
Wow, that's amazing. I had no idea the games code could be manipulated like that. I'm amazed that someone managed to figure that all out..
Well it can't anymore. Games today run their memory with the NX-Bit set to 1 by default which prevents the memory in the stack from executing.
Fucking computers.
+CloudCuckooCountry lol
+CloudCuckooCountry ikr, how do they work!?
Aha XD
+CloudCuckooCountry started studying computer science it's really interesting but also very mind blowing lol
+DragunSlyer yep its interesting how the super nintendo handles code is all he is explaining
This is my favourite computer science video ever.
What I don't fully undertand is this....YOU can interpret the bites as code, but how, and more importantly, why does the GAME do that? Why does it come across this specific series of bites (corresponding to the positions of objects on-screen, and the slots they occupy at the time) and read it as code? I get that it has to do with Yoshi eating Chuck and that causes some kinda weirdness with how the game's memory is read, but that's where you lose me. I still don't understand why the game executes the positions set earier as code.
+PremierMilenkov If you are familiar with programming, you know that you can call a function in say, C, by using its name (e.g. do_something()). In assembly, you have to call a function by using the address in memory at which it is stored (e.g. JSL $009047). In all the address space, $000000 - $FFFFFF, everything is stored, including RAM, ROM, hardware registers, PPU registers, and more. Normally ROM is stored from $xx8000 to $xxFFFF, which is where most of the code is. $xx0000 - $xx7FFF is saved for pretty much everything else. So really you can call a subroutine that exists in ROM or RAM. So in this case we have JSR $00E0 (effective address $0100E0), which is a call to RAM instead of ROM like normal.
In fact, SMW does write code to RAM and executes it fairly often, it's just that in our case we get to chose where in RAM we want to "write" a subroutine. Sprite X-positions are super easy to manipulate in game so we just use that.
*****
Gah, all too complicated...but I think I may have an inkling of why this works. So basically, you're trying to say, rather than calling a function from the game's normal code, that is the ROM, you force the game to call from RAM, which is where the code you wrote using the sprite positions is stored at the time, correct?
And so you have to manipulate the game into starting to execute the code from the addresses where you set up said snippet of code with the object positions.
+PremierMilenkov Correct!
*****
Ah, thank fudge, so I did get it after all :D
*****
This is fascinating stuff, really.
This was an awesome explanation that made the technical stuff a lot more accessible, while still going into fairly deep details! Thanks!
Awesome video! You won your more subscribe!
Could you explain the glitches in Donkey Kong 1? For example, when you use a barrel and the Rino... and then you make a donkey kong riding another donkey kong.
Thx
Okay, wow. That was REALLY thorough. I actually understand roughly what's going on in that warp now, thanks!
My goal is to one day watch this video and understand 100% of it.
3 years later, how's it going?
@@ShaneChandler87 I've actually been a part of the SMW speedrunning community (on hiatus rn) since then...still don't understand it 100% yet lol
**Alternate attempt to explain this ridiculous exploit**
(I knew almost nothing about Assembly before watching this video so bear with me if I've made mistakes in interpreting how it works.)
Like so many other games of its era, Super Mario World runs in Assembly language, which can't tell the difference between different kinds of data and is not neatly organized like an object-orientated language is. Nothing has a "name" or a "type" - everything is referred to by memory address, which is labeled with a hexadecimal value. In addition, the raw data in those memory addresses is also hexadecimal, and can itself be read as a memory address or vice versa. You can also happily leap right into the middle of a totally random part in the code as Assembly doesn't formally recognize where one function ends and another begins.
Thus, depending on the context, an Assembly program can read the exact same data as code, or graphics, or sound, or a memory address pointing to any of these assets. This makes weird shit happen like the Secret World in Metroid or glitch Pokemon - it's trying to read data as the wrong kind of thing, and horrifying garbage comes out as a result.
12 "sprites" (enemies, pickups etc.) can appear in Super Mario World at a time, and their x/y positions (in hexadecimal) are not cleared unless a new sprite takes up one of these 12 slots and overwrites it. This means you can write (very short) Assembly code by positioning sprites. Particles such as the bits of blocks that fly around when you break them are stored outside of these 12 slots and are partially RNG-based so they're harder to manipulate.
Anything Yoshi can normally swallow such as a powerup has a memory address associated that tells the game where to go to run the proper code for that item. The game will basically save its current position in the stack, start running the code found at that address when Yoshi swallows, and return to the address that it put in the stack.
You can force Yoshi to eat something he's not supposed to by making him grab a powerup with his tongue, then taking the powerup yourself before he swallows it (might be fixed in US version). This causes the next sprite that loads to replace the powerup Yoshi is eating, causing him to swallow that instead; but because Yoshi is not supposed to eat that, it contains an invalid address (here 014A13) as the location of code to run. When the SNES tries to jump to an invalid memory address to run its code, it instead jumps to the Magic School Bus and runs its value as code, for whatever reason someone decided that was remotely a good idea.
The Magic School Bus contains the high byte ("first" byte) of the last value successfully read or written - not the address read FROM or written TO. Some values are read or written a byte at a time, causing the MSB to update with each byte. In addition, this value continues to change as the code read from the MSB is executed, because executing it causes more values to be read and written. The main register and MSB do not "wait" for one another like a single process, so the MSB can return multiple different values within a single line of code. The entire business is highly unintuitive.
Because this started from Yoshi eating something, the item that Yoshi ate is referenced in the code, allowing the player to manipulate it. Eventually, this mess causes the game to execute the y positions of the sprites as code. Because that code must be very short (3 lines), it has to be awkward and weird to do what is needed.
LDA #$1C stores the value 1C in the accumulator, which is a part of the CPU that remembers numbers when doing complex math. If placed in the right spot, a value of 1C makes the game go to the credits.
STA ($75) takes the accumulator value (1C) and stores it in the given address. As an indirect address, the precise location is taken as a value from 75 and 76 (because addresses are two bytes + a presumed 01 at the start.) These addresses correspond to whether Mario is swimming and which direction he is facing. The address needed is 0100, which requires Mario to be facing to the right and not swimming or else it will go to some other address and mess everything up.
The code must return to the normal game to stop it from hanging, but to do that it needs to read the return address it left in the stack. Our mindblowing code adventure has added two extra bytes to that stack that need to be removed, so we JUMP to an existing game function at $FF46 to solve both problems. If the destination function had been executed from the start, it would've added 2 bytes to the stack and then taken them back out; but because this code jumps right into the middle, it skips the lines adding +2 bytes to stack and only runs the lines taking 2 out. Even if this function repeats itself for some reason, this -2 deficit will be retained. Also, this function happens to draw Iggy's sprites to the screen, which is why Iggy explodes all over the place.
Phew! I hope I've got it right. @ _ @
DracoHandsome but you sound like you know what the opcodes does.. your explanation and wording doesn’t seem like a newbie to me. I’m 1 year in, and that explaination is around my skill level, so I believe you are pretending to not know this stuff
But yeah you made some mistakes, just not as much as I expected. You got like 90% correct
Aahh...NOW I GOT IT!, no I don't.
You made an amazingly thorough and well illustrated explanation, thank you so much for taking the time!
super well produced, kudos!
Yes, I wonder what tools/editors he used!
He said he used Adobe Premier for the animations. Any screen recorder works for the recording, however he probably uses OBS because he regularly streams. Any good emulators works for this. Probably using Snes9x or BizHawk. Any good text editor works. Vim/EMACS is enough, but some people like simpler editors, I really don't know.
No he just ripped the audio from Retro Game Mechanics Explain
I love how I took Microprocessors at my university last semester and actually understood this.
Cool vid! Was this skip discovered through 'standard' gameplay and then the explanation was reverse engineered or did someone break down the code and then search for an optimum place in game to execute the steps you outline in your video?
George B Most definitely the latter. Super Mario World is probably one of the most documented, reverse-engineered game out there. All it takes is a bunch of thinking and planning along with the knowledge of the game and it's mechanics to come up with something like this.
*****
You mean, "its". I thought you might appreciate that tip since you are a nerd.
mandokir
OH NO !
Someone call Dr. House.
I beleive I've found a severe case of stupidity.
I understand this. The cliff notes? You swallow a Charging Chuck with everything set up perfectly, and Yoshi and Mario completely break the Space Time continuum
Shoutouts to Simpleflips
But can you do it in HALF an item swap?
Why did i type this 5 months ago? Its quite irrelivent
7:02
oraoraoraoraoraoraora
UltimaNylocke muda muda muda
I can't beat the shit out of you without getting closer.
This is amazing.
Great job, and thanks a lot for explaining it in a video!
As I understand it, the old credits warp assembly code - the one that jumped to the middle of the credits - was one byte shorter.
Suppose you went back to using the old code, but stuck an EA (NOP) at the beginning. Would that double the odds of the credits warp executing successfully, since starting the code from $00E4 or $00E5 would both work? Or would it make no difference in practice?
You can't get E4 or E5 starting points (I think the next after E3 is E6), but you have the right idea.
The old old version of the route used 6 bytes. We used the data bus value (4A), divided it by two (25) and stored that to $0100. No LDA was used. The reason it went to the middle of the credits was because it was game mode 25 instead of 1C.
Expanding on that, you could use the old code with the new route that would save one shell position. However, I think we have decided that it is more important that we warp to Yoshi's House since it shows the full enemies list and has a fanfare. Ignoring that, you could probably save a second or two by only placing 5 shells and a P-switch.
I watched this video a few years ago not knowing any programming. A few years later and now able to understand x86 Assembly I'm glad to have found it again now because now I actually understand what's going on even though I don't actually know 65816 Assembly
And I thought learning binaries was hard...
This is binary idiot
@@glitchisfluffy no this is assembly (assembled in hex) idiot
@@kjl3080 You're fucking kidding me. Hexadecimal is binary. 00 = 00000000, 01 = 00000001... FF = 11111111. It's not that fucking hard. Assembly instructions are written in hexadecimal(binary) and each instruction is the size of the Instruction Register. You wouldn't know what that is since you clearly haven't even taken basic CS yet. Stop arguing on topics you know nothing about.
This was really well put together and SUPER informative. You're definitely going places! I subscribed and can't wait to watch your next video.
but an A press is still an A press
yeah. the half A press is imaginary.
Ok, I will rewatch this video until I deeply get it. See you next century.
Literally shellcode ;)
AH! I knew my Computer Science degree would come in handy some day!
I know what I must do...
a wonderful explanation, although a bit too fast. I have a question: there is another end glitch th-cam.com/video/FkQdwUns7H8/w-d-xo.html , but it seems to be much easier. I don't see that the player moved the shells into specific positions, and I don't understand how he triggers the end scene. probably eating a fruit while jumping off? (it is too fast to see)
dracenmarx That TAS uses 4 controllers and inputs that don't exist on console. tasvideos.org/4315S.html The last 5 frames have 121 button inputs, which is why we don't use that route for real-time.
+dracenmarx Aside being impossible, Masterjun did move them into specific positions, but in a TAS you can advance frame by frame. He probably went 1 frame forward until he got the perfect position.
+dracenmarx He kicks a green shell while it gets burnt and turns into a coin.
Perfect explanation and so easy to follow! This gave so much insight in the 6502 internals!!
uhm... what?
This is on a next level. Who knows what's possible anymore. Maybe somebody will do this to reality one day
This is both brilliant and autistic as hell!
Even though I have my master's degree in Computer Science, this video was mind blowing! Very neat stuff!
Now do this in 0.5x a presses
Suuuuuper confusing. I don't really understand still, but its a better explanation than any other one I've seen. Cool video!
I GET IT!
(i don' get it...)
Nice video, really helped ;)
Now I need to study what all those codes are and what they do.