this is the kind of thing kids would make up in the schoolyard in the '90s. "I swear that if you do everything right you can turn super mario world into super mario brothers!" "No way!"
They most likely did not program all of smb through gameplay. Instead a lot of these TASs will make it so you can start writing code through controller inputs. Once you have that you can program anything super quickly
In the technical explanation part he mentions they're doing multiple controller reads per frame (hundreds of button presses) and that makes sense for why it's so fast...even if the hardware pretends it's a multi-tap the math doesn't work otherwise
@@ianproductions5540 Uses one of those TASbot-type things to do it. It is human possible just would take kinda long and more chance for mistakes. Same principle as credits warp
@@ianproductions5540I Guess they put the Mario Bros in the nes first and while its loaded on the RAM, the change to smw and trick it to read the code thats still in the RAM like its loading other smw level.
@@davidfaisca3967nope, guaranteed it can't be that because the graphics were seeing were never released on SNES, plus the SMW executable uses colossal amounts of RAM compared to SMB. Specifically, the original SMB was written for the NES, which only had a total of about 4KB (4380B iirc) of RAM across the entire system, so with a total binary blob size of 40K, the original SMB was written to only hold a fraction of the whole game in memory at the same time. So, since this is clearly the NES version of the game, this must be a patched version that is written to actually read all game data such as sprites directly from RAM, probably copying them from RAM back into RAM as necessary. See, the way the original NES worked with it's "definitely not a 6502" CPU is that RAM and the cartridge were on the same address bus as each other, so programmers would load the data from RAM or RAM by simply accessing the data from the right part of the address space.
@@DavidvanDeijk Not in this payload. Other ACE exploits I've worked on had reason to add checksums, but this payload has been stable enough that it was never an issue. Human RTA ACE exploits for example i have added a checksums for.
@@p4plus2 Thanks for replying so quickly. Does the bootloader need to be accurately synced like 0.5 miliseconds to reach that 182 keypresses per frame or is there any slack in the bootloader timing and the data still arriving uncompromised is what i wonder.
@@DavidvanDeijk There is quite a large amount of slack in this payload. Particularly compared to some later ACEs which end up doing close to 3KB/frame of transfer. But payloads like that do some real voodoo, so can be less stable. But in general the biggest sync factors are the original games reliability and replayability. For example, SMW is very stable and rarely drifts from expectations. DKC2 only had a narrow success rate due to various factors (the main one being spc desync).
Lemme take a crack at it. The holy grail of game glitches is Arbitrary Code Execution, or ACE. It's exactly what is says on the tin: a glitch that puts the console into a state where you can just feed it whatever code you want and have it run that code (usually--including in this example--by having the game interpret button presses as code). That code is called the "payload." ACE is the holy grail because of the word, "arbitrary." In principle, the payload can be absolutely _anything_ that the hardware is capable of. Anything that is technologically possible to put on a cartridge and run like any other game, can be run via ACE. So, with that said, the very short explanation of what they did goes like this: 1) Port SMB to SNES. 2) Launch SMW and activate ACE. 3) Load your SMB port as the ACE payload. Note that the video's title is kind of a lie, since once we activate ACE, we are no longer "in SMW" in any meaningful sense. It's just that SMW is one game where an ACE setup has been found, and its role in this process could be swapped out for any other SNES game where an ACE setup has been found.
@@Adamantium9001Thanks for explaining. So there's no game hidden in SMW and it's not possible to insert the code on an original SNES with a normal controller right?
@@eustab.anas-mann9510 If you could input everything the TAS does exactly the same, frame perfectly, on a normal controller with an original SNES, then yes, it could be done just the same. Humans don't really have that abillity, so it's up to the TAS for most ACE
A potential way to expand storage would be to use the second controller port as a "cartridge slot". Basically you would use all available CPU cycles except for the ones used to display graphics to read the second controller port, and do all of the calculations on the external hardware like the doom NES cartridge (or star fox kinda, doom NES is just the most extreme example). It may be limited because it will have to always have the same frequency that the external device is reading at. Not sure how low level control that you have over the cpu, so it may not be viable
here is my explanation of ACE: computer memory is a stored sequence of numbers. code that a computer runs is a special language stored in those numbers. if you can input data into the computer, for instance, through the controller, you might be able to control what numbers are stored in a position in memory. if you can perform certain types of glitches, you might be able to get the computer to think that the code that it needs to run is in the area of memory you control. if you can do that, you can make the computer execute whatever arbitrary instructions you put there, hence "arbitrary code execution".
Theoretically speaking, if you were to speedrun this, rather than going to 4-1 and 4-2 you could go from 1-2 to -1 and -2, reset to go select worlds and then pick world 8. Idk how fast that would be thougg
Absolutely. That's not impossible to do, it just wasn't how the exploit was designed originally. Though, being perfectly honest, many of our scripts for dumping TAS data to make this all work are somewhat temperamental and require a fair bit of work to use. They'd need major redesigns for distribution otherwise they'd probably simply frustrate users. But it's certainly doable.
I wouldn't call it strictly impossible (though the more complicated backgrounds may not fit in RAM), but at that point you're basically just playing SMAS :p. May be a fun challenge one day if i get bored though.
@@hotsIaw our limitation is 128KB, which is the SNES RAM size, so we have some free space to mess with. The final payload uses ~50KB give out take (including RAM SMB needs and the NES to SNES translation routines). But SMAS SMB i believe still exceeds 128KB I believe, but I'd have to double check to be sure.
Not sure if this is explained in the video since I haven't gotten to the technical explanation, but is the game running using the 65816's 6502 compatibility mode, or has the SMB1 code been translated to 65816 machine code prior to injection? I remember seeing this project a while back for a NES emulator for SNES (Project Nested) that uses a JIT compiler to translate the code on the fly, I presume because hardware registers for stuff like audio and video can't be addressed in 6502 mode. Could this be done in like a back and forth fashion where the game logic runs in 6502 mode and then jumps back to 65816 mode that handles all the audio/video stuff?
I would expect it to be very crude without any music and stuff like that, how the heck did they fit all the super mario data and graphics into that incredibly small amount of playtime? I barely saw any stops to carefully input data, let alone an entire 31k cartridge
the initial setup is so that they can get the game to read *inputs* as arbitrary code to execute, then they send inputs as a payload for it to run. They can send several inputs from 1 or 2 different controllers every frame so it can build the payload really fast!
A query in the url you clicked on, basically an outside variable that the website can use to get information about where you got the link, and anything special it should do. You can make one using the share button. When you make the link, it appends a query to the end of the URL called t, equal to the seconds into the video. UA-cam does the same thing for the video address, into a variable v. This address is always the same for any given video. In this case, v=t7yj_ypLUYk. You can also use youtu . be/{video addr} to shorten the name a bit, and the time variable can also be added if you want. The shortened link ends up as: ua-cam.com/video/t7yj_ypLUYk/v-deo.html To add queries, the first variable is separated with a "?", and the rest are divided with an "&" symbol. A ton of websites use them.
In otherwords they created a RAM disk, and because of how consoles work it crashed and found the small virtual computer then just assumed that was the right game.
It has nothing to do with assumptions or coaxing. Y'all are anthropomorphizing the Super Nintendo. They used ACE to write a program into memory, and then executed that program. No more, and no less.
There is a way to trick the game into reading the wrong data and running it as code. You can trick it into reading the positions of certain objects. If you can put those objects in just the right place you can trick the game into reading your controller inputs as game data. Then, you press those buttons in the right combination you can just input code for smb1. Sprites for sb1 are all also just code. So when they write the game data they also write sprite data
@@MattIsTheCat The TAS replay device is most likely taking advantage of the multitap. So there are actually 8 streams of input from 8 "controllers" it is working with. 2. They didn't have to code in 100% of SMB1. Some parts of SMW world were reusable for a SMB1. For example, the sound effects are still SMWs. And parts of SMW were reusable for SMB1. For example, many of the sound effect ID to sound maps were unchanged from SMB1 to SMW (like coin and power up collect sounds didn't need to have their indexes adjusted)
@@MattIsTheCat Oh, and one more thing. When it is inputting the code via controllers, it doesn't abide by the fps anymore. Instead they can input as fast as the CPU can run the loop or how fast the controller inputs can be polled (whichever rate is slower) And that is much, _much_ faster than 60 inputs per second
@@totalbro Hm, I think there is some confusion here as to what a bootloader is. A bootloader is a piece of code that helps load other pieces of code faster. So the bootloader is not a physical device. The device attached to Kosmic's controller port is something we call a replay device. Its basically a fancy controller that can replay controller presses. In the ACE we read the controller port to load new code, but this starts very slow and we can only do a single load per frame by default. So we write what is called a bootloader, a small piece of code that can read the controllers faster than the default method. So we use the slow method to read the bootloader which then can read more data much faster after. Hope this helps clarify, let me know if something isn't clear and I'll try and explain it better.
@p4plus2 so the code being written into RAM, including the bootloader program, is being written via the replay device plugged into the controller port? Do I have that right? (I called it a bootloader device because I assumed it was running the bootloader and other code in RAM using controller presses as input... didn't mean to be confusing) I don't know what "the ACE"... I didn't catch a definition for that during the technical explanation. Would you help me with that?
@@totalbro ACE stands for "arbitrary code execution". This is a type of exploit where we are able to find a way to inject our custom code into the game (typically by corrupting the game into executing some memory we can control in some way). Let me break down a simplified version of what happens: 1) We crash the game 2) In the crashed state the game will execute a region of memory that corresponds to controller data (8 bytes) 3) The SNES by default only reads the controllers once per frame, this is too slow to be useful 4) We use this slow method to read a faster method into RAM 5) Once we finish writing the faster method we start executing that code 6) Then its possible to read the rest of the data hundreds of times faster Super technical stuff: The following section is really in depth and may not be easy to follow. It involves some of the SNES specific topics. The SNES has a fairly non trivial memory layout. For the context of this discussion there is a region of memory located at "$4218-421F" These 8 bytes are where the "autojoy" data is written. "Autojoy" Is where the SNES puts controller data that is automatically read at the beginning of ever frame. This, however, only happens once each frame. In the initial crashed state we alternate between a load and store every other frame. The code will look like this: .loop LDA #$XXXX WAI STZ $10 BRA .loop and: .loop STA #$XXXX WAI STZ $10 BRA .loop (The above code blocks roughly can be read as "load/store, wait until interrupt, clear the SMW lag detector, loop and do it again) So one load/store per two frame is a throughput of 120 bytes per second -- really slow. I'll spare you from additional code details, but basically use this slow method to upload a "bootloader" which can switch to a faster method of reading code. The SNES supports manually reading the controller ports with the addresses $4016/4017. The rest is just building up in steps to do the final high speed read. The payload will actually go through 4 total stages before we get to the SMB final execution. Hope this helps a bit more.
According to the internet, SNES cartridges (like Super Mario World's) can hold up to 6 MB, so you could fit a larger game in there as long as there's room. The internet is strangely devoid of info as to how big SMW actually is.
@@benjaminoechsli1941 but they are modifying the RAM of the SNES, not the cartridge. I think you would be limited to the RAM size of 128 KB, unless you wanted to use ACE more than once to “load” another part of the game
what exactly do they mean by "upload" when talking about the music and stuff? is it external data being run through the cartridge, or is all of this done with pure SMW ACE from the TAS inputs?
The TAS uses ACE to set up a situation in which controller inputs can be used to write to RAM instead of Mario's actions, so the code can be written from scratch really quickly, from sprites to music to physics
It would have been too much work to get the SMB1 sound engine working on an SNES, so they basically borrowed the sound engine code from All-Stars and injected that instead
Ugh....watching this, have NO CLUE how they injected SMB into the game. Is it really all these pixel perfect mario moves to put in all the code? And how about what the fails look like?
there's a glitch that takes advantage of a vulnerability in the game. It often would cause a crash, but if you set things up just right you can make the code jump to where you want. The stuff Mario did is to set up enemy positions and stuff because that affects where the code goes. Things get set up in such a way that it starts looking at your inputs, so many many inputs are pressed in a crafted sequence that sets up Super Mario Bros. as a payload to run.
@@kosmicspeedruns I get the code execution part, but loading the SMB game into SMW is the question - yes, SMB is only like 32K in size but the mechanics of injecting the game code into memory is the question.
@@Crimefighter they use the slow method of code execution to set up a small program that can read controller inputs and write those to RAM. Then, the TAS bot inputs specific controller inputs to write the code for smb1 to RAM. Is this what you're asking?
but there should be a way to code into smb1 a way to reset the ram back to normal and reboot smw from the cart. I don't know for sure, but It should be possible. similar to how the coded in the reset feature for smb1, just have it take you farther back.
How does it actually run the game out of ram though?? The dude just went on and on about input device and what ACE is, and how regretful it was that the NES sound chip couldn't be emulated in time for GDQ. What I wanted to know is how NES instructions run on a SNES. I ended up reading Wikipedia to find out that the SNES cpu has the same 6502 extended instruction set as the NES. Would have loved to hear more about any and all actual incompatibilities in making the port, but the dude never seemed to get to that.
significantly more topics were covered than that, you're exaggerating because one specific thing you were curious about wasn't answered. He joined in the middle of a stream impromptu and explained something highly technical with the goal of communicating intricacies to the average viewer. Instructions set is completely meaningless to them, and pretty easy to look up like you did for the people who care/would even know to search for that.
@@kosmicspeedruns Sorry for that. I don't mean offense. It was just frustrating for me waiting for "new information" vs what was explained 7 years ago at GDQ. Hopefully there's a blog write-up at some point.
@@HamburgerExplosion it's always been available and you could always get in contact with the authors, join tas discords and ask questions... be more proactive to learn what you're searching for :) tasvideos.org/4156S.html tasvideos.org/3957S.html
@@magician531 The game was stored directly into RAM on the console. There is also a small amount SRAM on many cartridges, that can be usable too, but not in this case.
So this is with a legit SMW US cartridge? No custom ROM needed? That’s wild if it can insert 40KB of code using simply inputs, and that it’s so quick! Plus, it has to have some sort of a routine/emulator to actually handle NES format. Insane. Loving the video so far though. Now I’ve got to look into how this works lol
So... From IT perspective: A crash is considered something that has stopped responding and needs to be forcefully ended or closed. Sometimes, the machine or console has some sort of error recovery, which for instance can make a console restart, sometimes even wiping the memory clean. Early consoles don't usually have this kind of error handling built-in though, which is partially what makes this possible. With these kinds of code injections, the game doesn't actually crash, but the CPU is basically being tricked into reading certain memory values and interprets it as an instruction, which makes it try to execute code from a position in memory that usually does not contain instructions at all. In this case a position that is easy to manipulate like the gamepad input register. The correct button presses then can be interpreted as further instructions, writing values to the RAM, and then pointing the CPU to it to execute. This is possible because these consoles treat ROM and RAM as a single massive page with subsequent addresses. The CPU doesn't care what address it is fed for obtaining instructions or data, whether that address points to ROM, RAM, VRAM or sometimes even the SRAM (save data) of a cartridge; it's all accessible from the same address table.
Technical explanation starts at 1:25:56
cap
??
@@Kosmicd12 have this cap 🧢
@@Kosmicd12 Replying even after it's been a year... legendary
@@Atomlxe notifications exist...
this is the kind of thing kids would make up in the schoolyard in the '90s. "I swear that if you do everything right you can turn super mario world into super mario brothers!" "No way!"
I don’t xde I. Wid
@@comicsofzach wld
And the same kids made it happen 30 years later :D
Somebody in chat at some point said "more like a ramhack than a romhack" and that's the most creative way of describing ACE I've ever heard
44:44
I'm impressed with how fast the payload for the whole game was delivered
They most likely did not program all of smb through gameplay. Instead a lot of these TASs will make it so you can start writing code through controller inputs. Once you have that you can program anything super quickly
@@jimmyjam2373shhhhh it’s magic not controller inputs
In the technical explanation part he mentions they're doing multiple controller reads per frame (hundreds of button presses) and that makes sense for why it's so fast...even if the hardware pretends it's a multi-tap the math doesn't work otherwise
The moment we get doom running inside mario world is the moment my life's any% speedrun will be completed
SNES Doom is open source, but sadly we need a Super FX chip for it to run, I believe.
@@ZGURemixerNOOOOOOOOO I'm sure there's a way to do it low poly
emulate the sfx chip >:D no matter how slow
@@ZGURemixer do it in Yoshi's Island
1:29:20 "faster and faster and faster" syncs with the BIOS animation
At first, I was like, “oh! So someone remade the SMB levels in SMW?”
then I was presented with this madness…
You're not wrong. Arbitrary Code Execution basically tells the game "Hey, here's some new code to run. Do it."
And that code... is Super Mario Bros.
@@benjaminoechsli1941Was this made within the vanilla game? (without rom hacks)
@@ianproductions5540
Uses one of those TASbot-type things to do it.
It is human possible just would take kinda long and more chance for mistakes.
Same principle as credits warp
@@ianproductions5540I Guess they put the Mario Bros in the nes first and while its loaded on the RAM, the change to smw and trick it to read the code thats still in the RAM like its loading other smw level.
@@davidfaisca3967nope, guaranteed it can't be that because the graphics were seeing were never released on SNES, plus the SMW executable uses colossal amounts of RAM compared to SMB. Specifically, the original SMB was written for the NES, which only had a total of about 4KB (4380B iirc) of RAM across the entire system, so with a total binary blob size of 40K, the original SMB was written to only hold a fraction of the whole game in memory at the same time.
So, since this is clearly the NES version of the game, this must be a patched version that is written to actually read all game data such as sprites directly from RAM, probably copying them from RAM back into RAM as necessary.
See, the way the original NES worked with it's "definitely not a 6502" CPU is that RAM and the cartridge were on the same address bus as each other, so programmers would load the data from RAM or RAM by simply accessing the data from the right part of the address space.
I love how everyone's interpretation of this is Just Speedrunner Mario able to control the Multiverse and enter parallel dimentions.
Really interesting stuff, I'd never thought about how ACE actually builds the bootloader in steps
Fun fact: Without using multiple bootloader stages and just the base exploit it would take about 40 minutes to upload all the code/data.
@@p4plus2 Is there any checksumming or other safeguard to ensure that all data is correctly transferred?
@@DavidvanDeijk Not in this payload. Other ACE exploits I've worked on had reason to add checksums, but this payload has been stable enough that it was never an issue. Human RTA ACE exploits for example i have added a checksums for.
@@p4plus2 Thanks for replying so quickly. Does the bootloader need to be accurately synced like 0.5 miliseconds to reach that 182 keypresses per frame or is there any slack in the bootloader timing and the data still arriving uncompromised is what i wonder.
@@DavidvanDeijk There is quite a large amount of slack in this payload. Particularly compared to some later ACEs which end up doing close to 3KB/frame of transfer. But payloads like that do some real voodoo, so can be less stable. But in general the biggest sync factors are the original games reliability and replayability. For example, SMW is very stable and rarely drifts from expectations. DKC2 only had a narrow success rate due to various factors (the main one being spc desync).
This reminds me of that Genesis homebrew SMB4MD where the creator decompiled the original game's code and adapted it for the Genesis.
Arbitrary Code Execution is absolutely crazy
1:31:55 HEY! i know that jumping pattern! that's Masterjun3!
1:41:16 even more basic explanation as to how they pulled this off
Lemme take a crack at it.
The holy grail of game glitches is Arbitrary Code Execution, or ACE. It's exactly what is says on the tin: a glitch that puts the console into a state where you can just feed it whatever code you want and have it run that code (usually--including in this example--by having the game interpret button presses as code). That code is called the "payload." ACE is the holy grail because of the word, "arbitrary." In principle, the payload can be absolutely _anything_ that the hardware is capable of. Anything that is technologically possible to put on a cartridge and run like any other game, can be run via ACE.
So, with that said, the very short explanation of what they did goes like this: 1) Port SMB to SNES. 2) Launch SMW and activate ACE. 3) Load your SMB port as the ACE payload.
Note that the video's title is kind of a lie, since once we activate ACE, we are no longer "in SMW" in any meaningful sense. It's just that SMW is one game where an ACE setup has been found, and its role in this process could be swapped out for any other SNES game where an ACE setup has been found.
@@Adamantium9001Thanks for explaining. So there's no game hidden in SMW and it's not possible to insert the code on an original SNES with a normal controller right?
@@eustab.anas-mann9510 If you could input everything the TAS does exactly the same, frame perfectly, on a normal controller with an original SNES, then yes, it could be done just the same.
Humans don't really have that abillity, so it's up to the TAS for most ACE
18:06 The live chat comment: "It's like the Mario theme on mario paint" lol
*talking about the game*
kosmic: casually switches to the fds
A potential way to expand storage would be to use the second controller port as a "cartridge slot". Basically you would use all available CPU cycles except for the ones used to display graphics to read the second controller port, and do all of the calculations on the external hardware like the doom NES cartridge (or star fox kinda, doom NES is just the most extreme example). It may be limited because it will have to always have the same frequency that the external device is reading at. Not sure how low level control that you have over the cpu, so it may not be viable
* him proving its smb1 *
A random dude in chat: just use all-stars
Sometimes I would rather not see chat
I've heard of that guy before, if they're not joking someone stole their computer
here is my explanation of ACE:
computer memory is a stored sequence of numbers. code that a computer runs is a special language stored in those numbers. if you can input data into the computer, for instance, through the controller, you might be able to control what numbers are stored in a position in memory. if you can perform certain types of glitches, you might be able to get the computer to think that the code that it needs to run is in the area of memory you control. if you can do that, you can make the computer execute whatever arbitrary instructions you put there, hence "arbitrary code execution".
also you have to crash the game and you have to have your code to be the next thing it executes
Ty for the awesome discussion and showcase of this amazing work!
Theoretically speaking, if you were to speedrun this, rather than going to 4-1 and 4-2 you could go from 1-2 to -1 and -2, reset to go select worlds and then pick world 8. Idk how fast that would be thougg
thats 30-40 seconds slower than just warping to 8
err wait, I'm thinking of normal minus world ending. It would probably be a bit faster here, yeah
5:51 Bullet Bill ftw!!!! 🙌🏼
i love how the chat went what the fuck when you switched over to Mario brothers XD
I love it! This is fascinating
in another realm of existence: "Running 'multidimensional universe' on my cellphone"... 😂
When I saw this title, I was expecting a SMW hack with ported Mario 1 levels playable with SMW physics and vertical scrolling.
I mean with a converter that creates a files locally you should be in the clear legally
Absolutely. That's not impossible to do, it just wasn't how the exploit was designed originally. Though, being perfectly honest, many of our scripts for dumping TAS data to make this all work are somewhat temperamental and require a fair bit of work to use. They'd need major redesigns for distribution otherwise they'd probably simply frustrate users. But it's certainly doable.
@@p4plus2 yeah, i feel you, making something work and making something work for other people is completely different
Imagine using ACE to beat smw by using another game to get to the ending
Ace is like giving someone random ascii characters and forcing them to read it
i forgot i wrote this
"Fail yay"'s silhouette world seems prescient given Super Mario Wonder...
23:56 Now it all makes sense
alt title: speedrunning smb1 with badabum's pitch
Bismuth: a ramhack is just a romhack in Tennessee lmao 🤣🤣🤣
Would you technically be able to do this same thing but with smas graphics
@@hotsIaw year that makes sense
I wouldn't call it strictly impossible (though the more complicated backgrounds may not fit in RAM), but at that point you're basically just playing SMAS :p. May be a fun challenge one day if i get bored though.
@@hotsIaw our limitation is 128KB, which is the SNES RAM size, so we have some free space to mess with. The final payload uses ~50KB give out take (including RAM SMB needs and the NES to SNES translation routines). But SMAS SMB i believe still exceeds 128KB I believe, but I'd have to double check to be sure.
@Rudy also true, but i figured that was cheating :p
1:42 he broke the game, so bad it went back five years
Not sure if this is explained in the video since I haven't gotten to the technical explanation, but is the game running using the 65816's 6502 compatibility mode, or has the SMB1 code been translated to 65816 machine code prior to injection? I remember seeing this project a while back for a NES emulator for SNES (Project Nested) that uses a JIT compiler to translate the code on the fly, I presume because hardware registers for stuff like audio and video can't be addressed in 6502 mode. Could this be done in like a back and forth fashion where the game logic runs in 6502 mode and then jumps back to 65816 mode that handles all the audio/video stuff?
This guy played a 4:57 to cointoss first try I’m legit impressed (maybe low 4:58 because the show was slow)
I would expect it to be very crude without any music and stuff like that, how the heck did they fit all the super mario data and graphics into that incredibly small amount of playtime? I barely saw any stops to carefully input data, let alone an entire 31k cartridge
the initial setup is so that they can get the game to read *inputs* as arbitrary code to execute, then they send inputs as a payload for it to run. They can send several inputs from 1 or 2 different controllers every frame so it can build the payload really fast!
@@kosmicspeedruns Its really cool how that stuff works
How can a link send you to a video and a certain point in that video
right click on the video, then you should see the option to do so
A query in the url you clicked on, basically an outside variable that the website can use to get information about where you got the link, and anything special it should do. You can make one using the share button.
When you make the link, it appends a query to the end of the URL called t, equal to the seconds into the video. UA-cam does the same thing for the video address, into a variable v. This address is always the same for any given video. In this case, v=t7yj_ypLUYk. You can also use youtu . be/{video addr} to shorten the name a bit, and the time variable can also be added if you want. The shortened link ends up as: ua-cam.com/video/t7yj_ypLUYk/v-deo.html
To add queries, the first variable is separated with a "?", and the rest are divided with an "&" symbol. A ton of websites use them.
there's a "start at x" option when you use the share link function
So does SMW have a rom of SMB1 in it or does ACE create SMB1 within SMW?
ace writes smb1 into memory.
Arbitrary Code Execution (ACE) gives you the ability to run your own code. What this TAS does is writes all the code to run smb1 and then runs it
@@rhysbaker2595 holy shit that's fucking crazy
In otherwords they created a RAM disk, and because of how consoles work it crashed and found the small virtual computer then just assumed that was the right game.
they managed to coax the game into running the controller inputs as actual computer instructions and used that to build up the payload from scratch
It has nothing to do with assumptions or coaxing. Y'all are anthropomorphizing the Super Nintendo.
They used ACE to write a program into memory, and then executed that program. No more, and no less.
1:43 hahahahhaahahaha
Games Cosmic is playing: Super Mario World, Super Mario Bros., Super Mario All Stars
So how did they get SMB1 in the game? (including the sprites and everything)
This is just magic
There is a way to trick the game into reading the wrong data and running it as code. You can trick it into reading the positions of certain objects. If you can put those objects in just the right place you can trick the game into reading your controller inputs as game data. Then, you press those buttons in the right combination you can just input code for smb1.
Sprites for sb1 are all also just code. So when they write the game data they also write sprite data
@@rhysbaker2595 I know, but how does it write a whole 40KB so fast?
@@MattIsTheCat The TAS replay device is most likely taking advantage of the multitap. So there are actually 8 streams of input from 8 "controllers" it is working with.
2. They didn't have to code in 100% of SMB1. Some parts of SMW world were reusable for a SMB1.
For example, the sound effects are still SMWs. And parts of SMW were reusable for SMB1. For example, many of the sound effect ID to sound maps were unchanged from SMB1 to SMW (like coin and power up collect sounds didn't need to have their indexes adjusted)
@@TechSY730 Thank you for your insight.
@@MattIsTheCat Oh, and one more thing. When it is inputting the code via controllers, it doesn't abide by the fps anymore.
Instead they can input as fast as the CPU can run the loop or how fast the controller inputs can be polled (whichever rate is slower)
And that is much, _much_ faster than 60 inputs per second
Where is the boot loader device connected to the SNES? In the service port?
The bootloader is code written into RAM and reads off the controller ports.
@@p4plus2 so the device that Kosmic shows is plugged into the controller ports?
@@totalbro Hm, I think there is some confusion here as to what a bootloader is. A bootloader is a piece of code that helps load other pieces of code faster. So the bootloader is not a physical device.
The device attached to Kosmic's controller port is something we call a replay device. Its basically a fancy controller that can replay controller presses.
In the ACE we read the controller port to load new code, but this starts very slow and we can only do a single load per frame by default. So we write what is called a bootloader, a small piece of code that can read the controllers faster than the default method. So we use the slow method to read the bootloader which then can read more data much faster after.
Hope this helps clarify, let me know if something isn't clear and I'll try and explain it better.
@p4plus2 so the code being written into RAM, including the bootloader program, is being written via the replay device plugged into the controller port? Do I have that right? (I called it a bootloader device because I assumed it was running the bootloader and other code in RAM using controller presses as input... didn't mean to be confusing)
I don't know what "the ACE"... I didn't catch a definition for that during the technical explanation. Would you help me with that?
@@totalbro ACE stands for "arbitrary code execution". This is a type of exploit where we are able to find a way to inject our custom code into the game (typically by corrupting the game into executing some memory we can control in some way).
Let me break down a simplified version of what happens:
1) We crash the game
2) In the crashed state the game will execute a region of memory that corresponds to controller data (8 bytes)
3) The SNES by default only reads the controllers once per frame, this is too slow to be useful
4) We use this slow method to read a faster method into RAM
5) Once we finish writing the faster method we start executing that code
6) Then its possible to read the rest of the data hundreds of times faster
Super technical stuff:
The following section is really in depth and may not be easy to follow. It involves some of the SNES specific topics.
The SNES has a fairly non trivial memory layout. For the context of this discussion there is a region of memory located at "$4218-421F" These 8 bytes are where the "autojoy" data is written. "Autojoy" Is where the SNES puts controller data that is automatically read at the beginning of ever frame. This, however, only happens once each frame. In the initial crashed state we alternate between a load and store every other frame.
The code will look like this:
.loop
LDA #$XXXX
WAI
STZ $10
BRA .loop
and:
.loop
STA #$XXXX
WAI
STZ $10
BRA .loop
(The above code blocks roughly can be read as "load/store, wait until interrupt, clear the SMW lag detector, loop and do it again)
So one load/store per two frame is a throughput of 120 bytes per second -- really slow.
I'll spare you from additional code details, but basically use this slow method to upload a "bootloader" which can switch to a faster method of reading code. The SNES supports manually reading the controller ports with the addresses $4016/4017. The rest is just building up in steps to do the final high speed read. The payload will actually go through 4 total stages before we get to the SMB final execution.
Hope this helps a bit more.
So what's the cartridge size limit? Is it limited to 40k games like Super Mario Bros, or can you do larger games like Mega Man?
bit trip pfp? you're awesome
According to the internet, SNES cartridges (like Super Mario World's) can hold up to 6 MB, so you could fit a larger game in there as long as there's room.
The internet is strangely devoid of info as to how big SMW actually is.
@@benjaminoechsli1941 but they are modifying the RAM of the SNES, not the cartridge. I think you would be limited to the RAM size of 128 KB, unless you wanted to use ACE more than once to “load” another part of the game
Is there any TAS files for this?
what exactly do they mean by "upload" when talking about the music and stuff? is it external data being run through the cartridge, or is all of this done with pure SMW ACE from the TAS inputs?
The TAS uses ACE to set up a situation in which controller inputs can be used to write to RAM instead of Mario's actions, so the code can be written from scratch really quickly, from sprites to music to physics
What I don't understand is, i thought the music would be just directly the smb ost with mario world sounds, but they have more instruments and such
it's mario all stars music
It would have been too much work to get the SMB1 sound engine working on an SNES, so they basically borrowed the sound engine code from All-Stars and injected that instead
The one dislike: make the sounds the same!
I would attempt to make a tas to have Celeste in snes, but I am intimidated.
Not to mention the technical limitations.
@@legendgames128 do it
And here I thought TASbot was conciously pressing the buttons on the controller.
Nope, it's playing back a TAS made by a human
33:09 FPG
A year later and Nintendo hasn't got this guy sentenced to death yet for selling Mario tas bots??? What universe is this?
Playing sonic 1 in super mario world?
Maybe sonic from the master system
@@magnafide that would also be cool.
It's not going to fit into ram.
First sonic was 16 bit iirc so it literally wouldn't be able to run
Ugh....watching this, have NO CLUE how they injected SMB into the game. Is it really all these pixel perfect mario moves to put in all the code? And how about what the fails look like?
there's a glitch that takes advantage of a vulnerability in the game. It often would cause a crash, but if you set things up just right you can make the code jump to where you want. The stuff Mario did is to set up enemy positions and stuff because that affects where the code goes. Things get set up in such a way that it starts looking at your inputs, so many many inputs are pressed in a crafted sequence that sets up Super Mario Bros. as a payload to run.
@@kosmicspeedruns I get the code execution part, but loading the SMB game into SMW is the question - yes, SMB is only like 32K in size but the mechanics of injecting the game code into memory is the question.
@@Crimefighter they use the slow method of code execution to set up a small program that can read controller inputs and write those to RAM. Then, the TAS bot inputs specific controller inputs to write the code for smb1 to RAM. Is this what you're asking?
cool
1:40:44 Is this loss?
Would it be possible to Inception this and induce arbitrary code execution again while in Super Mario Bros mode to recreate Super Mario World?
there's no way to do ACE in smb1
but there should be a way to code into smb1 a way to reset the ram back to normal and reboot smw from the cart. I don't know for sure, but It should be possible. similar to how the coded in the reset feature for smb1, just have it take you farther back.
@@kosmicspeedrunsWELL NOW WITH TENNIS AND WORLD N YOU CAN!
Beta test all stars
i thought he was doing the data edit thing
TLDR. What was the best run?
How does it actually run the game out of ram though?? The dude just went on and on about input device and what ACE is, and how regretful it was that the NES sound chip couldn't be emulated in time for GDQ. What I wanted to know is how NES instructions run on a SNES. I ended up reading Wikipedia to find out that the SNES cpu has the same 6502 extended instruction set as the NES. Would have loved to hear more about any and all actual incompatibilities in making the port, but the dude never seemed to get to that.
significantly more topics were covered than that, you're exaggerating because one specific thing you were curious about wasn't answered. He joined in the middle of a stream impromptu and explained something highly technical with the goal of communicating intricacies to the average viewer. Instructions set is completely meaningless to them, and pretty easy to look up like you did for the people who care/would even know to search for that.
@@kosmicspeedruns Sorry for that. I don't mean offense. It was just frustrating for me waiting for "new information" vs what was explained 7 years ago at GDQ. Hopefully there's a blog write-up at some point.
@@HamburgerExplosion it's always been available and you could always get in contact with the authors, join tas discords and ask questions... be more proactive to learn what you're searching for :)
tasvideos.org/4156S.html
tasvideos.org/3957S.html
Any descent speed run, a super Mario bros speedrun but it’s within a different game
paper mario 64 speedruns (some of them) use tloz:oot. does that count?
fing sit wrong place
this has to be the worst way to port a game to a different system
_"as long as it works..."_
Ok, but can smw run doom?
Either way you’d get a world record because nobody has done this before
B u t n o b o d y c a m e . . .
You said "you can't overwrite ROM", but isn't the whole cartridge ROM? So how do you write on any of it?
Or did you load the game directly into the ram
@@magician531 The game was stored directly into RAM on the console. There is also a small amount SRAM on many cartridges, that can be usable too, but not in this case.
@@p4plus2 okay, that makes sense
@@magician531 There's actually an SMW RAM editor that DOES save itself into SRAM and you can load it by just loading slot 3.
Bro is gonna end up making people clickbait Mario videos real cuz now u can code whatever u want on the nes
I thought this guy stopped being a guy, i must have got him confused with someone else.
yooooo smw 8 exit
uhhh just like playing other games in gen 1 pokemon?
yes, very much the same
Basically lol
ermmm this isnt sonic prime!!!! fals
WTF
So this is with a legit SMW US cartridge? No custom ROM needed? That’s wild if it can insert 40KB of code using simply inputs, and that it’s so quick! Plus, it has to have some sort of a routine/emulator to actually handle NES format. Insane. Loving the video so far though. Now I’ve got to look into how this works lol
1:24:46 I found a mistake that you ended early so I think it should be a 5:04.6xx or 5:04.7xx
this is so fucking confusing
So... From IT perspective: A crash is considered something that has stopped responding and needs to be forcefully ended or closed. Sometimes, the machine or console has some sort of error recovery, which for instance can make a console restart, sometimes even wiping the memory clean. Early consoles don't usually have this kind of error handling built-in though, which is partially what makes this possible.
With these kinds of code injections, the game doesn't actually crash, but the CPU is basically being tricked into reading certain memory values and interprets it as an instruction, which makes it try to execute code from a position in memory that usually does not contain instructions at all. In this case a position that is easy to manipulate like the gamepad input register. The correct button presses then can be interpreted as further instructions, writing values to the RAM, and then pointing the CPU to it to execute. This is possible because these consoles treat ROM and RAM as a single massive page with subsequent addresses. The CPU doesn't care what address it is fed for obtaining instructions or data, whether that address points to ROM, RAM, VRAM or sometimes even the SRAM (save data) of a cartridge; it's all accessible from the same address table.