This one took a very long time to produce, and I am super happy with it. I hope you enjoyed it. If you know someone that you think would like it, please share it with them. I'd really appreciate it!
This is fantastic! I would also love to see how you would fix these bugs programmatically (and other game issues you find in future/past series). It would be neat to see what the patch looks like to prevent all of the glitching that was never intended.
I think of holding left and right at the same time as a small form of hacking. This is why I prefer the yellow crash. Actually, there is also the reason that safeguarding against the orange crash uses another controller. It would be preferable to avoid this as much as possible, while maintaining the ability to achieve ACE.
Well, Fractal has been mentionioning the use of the Famicom ports a while back on stream. I don't know if anyone else of the crashers or crash-candidates has access to a Famicom and the required hardware. I would love to see it, though.
SethBling was famous for pulling off Arbitrary Code execution in Super Mario World, so it's not out of the question. He managed to get a SNES port of Flappy Bird injected into console RAM and start the game.
Wow, incredible video! Very cool to see someone else independently engineer an ACE setup, with a different idea - I never thought of resetting the score to prevent the crash. Inside the community, we've made our own setups; to prevent the crash, you can block blue and green crashes by just holding P3/P4 such that the code just goes where it was supposed to anyway, no ACE involved. Blue/green are the highest priority to fix because they're the ones that come into play at 255 for placing pieces- nobody's been able to play with flashing the nextbox to dodge it. For general purpose, we have a fully-built bootstrapper in the highscore table, but to get to it, we allowed the PC to jump to the beginning of ram and used the next piece plus the current rng value to have it jump to the names and such. Building code around the name/score limitations is a fascinating challenge; we used a couple invalid opcodes to get around it. A constraint you didn't touch on is that the scores have to be in order; your code fit neatly into single scores, but for us that was a big roadblock, as we used all 6 names, highscores, and levels. The code we write is used to build another bootstrapper which builds another bootstrapper that grants full control over all of RAM. The TAS has kinda just been sitting around for 2 years because none of us know what to do with total control over the game lol.
as proud as I am of total control without the famicom expansion port (or L+R, iirc?), it's super cool to have any custom code execution in nestris see the light of day, and this strategy is really neat. it's got me thinking again about what's human viable to execute. like, what if we could use P3+P4+something like this to copy P2's inputs somewhere, increment that address, and safely return? it's back to the opcode drawing board to see if you can cram that into the high score table! it's really nice to have a problem be so constrained but not intractable.
Awesome. I knew that this was an endeavor in the Tetris community, but I didn't research anything that the community had done yet so I would use my own approach. That was one of the reasons why I asked people to pause the video and come up with their own ideas. There are so many possibilities! The one I included here was maybe the 8th version I did. I wanted to try and maximize impact but minimize complexity since I had to explain it in a video.
Suppose someone actually used ACE in this way to achieve a tetris record (e.g. using this crash prevention to reach level 256). Would it be considered to count? (I assume it wouldn't, since they could have just used ACE to skip to level 255 instead).
@@Kirby703 In my comment on this vid I mapped out a total control exploit that fits into the high score table, using p3 and p4 controllers to write anywhere in memory. I think the memory writing is human viable to execute as long as you just follow a careful sequence of steps to write everything, it's not time-dependent or anything. Though it does require very specific scores in the 200ks. don't actually know if it works for sure since i haven't tested it, i just paused the vid as instructed and solved it myself, and i just kind of assumed what we were going for was total control because... that's what ACE is for lmao
Brilliant video. Love how you reasoned about the ACE setup. It was totally different from anything we came up with and your explained your thought process brilliantly. You've inspired me to attempt unmodified human ACE sometime in the future... if so, my current idea is to enable the 2-player mode. It's tough to program more intricate things using our current knowledge, but maybe in the future we will overcome this obstacle as well.
Did... did you just patch a calculation that crashed the game due to taking too long by gaslighting the program into thinking it was actually a way smaller number mid-cycle? Amazing.
as a kid i often saw my mom reach the rocket ship cutscenes in tetris! i could never reproduce it! later i was even convinced i must have dreamt those rocketship cutscenes! so yeah even though i did not really enjoy the game much as a kid, i do have very fond memories of it :)
@@InsaneFirebat ugh, why are moms so good at tetris??? she was always borrowing our gameboys and then like an hour later she would call us down to come check out the rocket cutscenes xD
23:25 Okay I tried to solve this. I have a solution, not 100% sure if it would work but I think it would. The general idea is that you put yourself in a loop where now you are using controller inputs to write arbitrary data to arbitrary memory locations. By doing this, you can write a much larger payload without restriction*, and then overwrite the end of the loop in order to jump there. The controller input scheme will work by checking whether the high byte ($01) is positive or negative. If positive, then we are in "data" mode, and the low byte $00 will be stored as the next byte to write. If negative, then we are in "address" mode, and the stored value will be written. You'll set up your controllers, probably with toggleable switches as was shown earlier. Start by flipping bit 7 of $01 to be on to be in data mode, and set $00 to be whatever you want. Now, flip bit 7 back off. The one thing you have to be careful of here is that you'll start writing that value to whatever you have your controllers set to. I think this is probably fine, as the code only exists in a tiny portion of memory and so you can just set $01 to some memory region far away from anything you're currently updating, set $00 to be what you want, then change $01 to be in the memory region you're looking to edit. * Unfortunately, due to the allowed jump instructions, there is a restriction that we must only use positive data values. But given that we can access a much larger portion of memory with this, this is overall a much less restrictive setup than the initial one. If needed, we could create a very similar piece of code in that area which did the same thing but without this restriction. There's also probably a way to avoid it - I would only need to save two bytes to do so, due to two PLA instructions being required to remove stuff on the stack. And also, if stack overflow wasn't a concern (It might just wrap around instead of crashing, I'm not sure) then all you need to do is replace 720-722 with a JSR instead of a BPL. Here's the code: NAMES 706: PLP // Previously, we had to jump into this as a subroutine to allow a jump backwards. 707: PLP // This pops the two pushed bytes off so we don't cause a stack overflow. 708: AND zpg // Clear the A register. 709: $ZZ // This can be any spot on the zero page that has a 0 at the time, I will just assume some such location exists. 70A: ORA zpg // Load $01 into the A register to check the sign bit. 70B: $00 70C: BPL rel // Branch to positive or negative locations. 70D: +21 // $723 70E: AND zpg // Continuing if negative (data mode), clear the A register again. 70F: $ZZ 710: BPL rel // Jump past the zeroed out parts. This always triggers since we just wrote 0 which is positive. 711: +12 // $71E 712-71D: A-type Name 4 (zeroed) and B-type Name 1 (containing $27 $07) 71E: ORA zpg // Continuing the negative path (data mode), load the data. 71F: $00 720: BPL rel // Jump to the score section. Of note: Because this must be a BPL instruction, all data must be positive. 721: +18 // $734 722: * // Unused. 723: AND zpg // Continuing if positive (address mode), clear the A register again. 724: $ZZ 725: BPL zpg // Jump to the score section. This always triggers since we just wrote 0 which is positive. 726: +9 // $730 727: JSR abs // Jump to the start of the loop. This uses JSR to go back, since we don't have access to small neg offsets. 728: $06 729: $07 72A-72F: B-type Name 4 (zeroed) 730: ORA zpg // Load the saved data. 731: $02 732: STA ind,Y // Store the data at the address specified by the controller inputs. Note that Y is added... we'll likely need to know what this is to play around it, but this should be fine. 733: $00 734: STA zpg // Store the data. This is executed on both address and data mode, since in address mode we just loaded the data so saving it back is fine. 735: $02 736: JSR // Jump back to the start of the loop. This uses JSR to go back, since we don't have access to small neg offsets. 737: $06 738: $07 Okay with that done I'll finish watching the video. I'm sure there's a better solution than this, you'd just need to save a few bytes to improve things and remove some restrictions, but at the very least I *think* it should work. Was a fun puzzle to figure out. I think the biggest challenge was there were effectively no ways to interact with X and Y, so I couldn't really find a method to use these at all. And of course, there are only limited means of branching.
Here's the new version. I fixed the scores going from highest to lowest, and also made it so that it takes in any bytes, not just positive ones. I did this by using PLP right before the branch rather than at the start - this will load a low value into the status flags, clearing the negative bit and guaranteeing the branch is successful. This uses A-Type name 1, but since you already need all 3 scores this is not a problem. Assembly 700:AND $00 ; Start of loop ORA $01 ; Load controller 4 to A register BPL ~71E ; Branch based on value being negative or positive 706:AND $00 ; Negative path (data mode) ORA $00 ; Load controller 3 to A register PLP ; Get low byte of return addr off the stack BPL ~731 ; Always branches since PLP sets negative flag to 0 71E:AND $00 ; Positive path (address mode) ORA $02 ; Load stored value to A register PLP ; Get low byte of return addr off the stack BPL ~733 ; Always branches since PLP sets negative flag to 0 727:JSR $700 ; Jump to the start of loop 731:STA ($00),Y ; Only in address mode, store the saved value to the address 733:PLP ; Get high byte of return addr off the stack STA $02 ; Store the saved value JSR $700 ; Jump back to the start of the loop Hex dump A TYPE NAMES 700: 29 00 05 01 10 18 29 00 05 00 28 10 26 -- -- -- -- -- 00 00 00 00 00 00 B TYPE NAMES 718: -- 27 07 -- -- -- 29 00 05 02 28 10 0C -- -- 20 00 07 00 00 00 00 00 00 SCORES 730: -- 91 00 28 85 02 20 00 07 00 00 00 -- -- -- -- -- -- -- -- -- 00 00 00
Coding via high score table is something brand new. You want to know what else does high scores? Arcade games. I would love to see if there are any coin-op arcade games that can be "reprogrammed" via manipulating the high score tables a la Tetris. This is a very great find, Chris.
The essence of ACE is exactly that, big contiguous areas of memory that can be manipulated by player input AND be triggered to execute as code due to some exploit in the program. Once that's done you might be able to gain full control of the machine if there is enough space for you and no restrictions on what you can put in the memory to stop you from doing it.
I've been following your channel for many years now, alongside competitive classic tetris. I get a big grin when the two merge together. Anyway, your videos are spectacular. Thanks as always.
I´m not a programmer, therefore have a hard time getting some concepts fast enough, but oh good gods I love your videos. It´s EXTREMELLY fascinating to me and I have a lot of fun trying to understand.
And I thought it was impressive when I saw some dude modify Mario's model in Super Mario 64 in a hex editor. Forget 3d modelling in hex, programming 6502 assembly in tetris is something else.
If you think that's impressive, when Factorio was still in early access someone made a Sandstorm Video within it. Other's have built working CPUs, and some have even made a 3D Raytracing Doom Style Engine. Of course there's Minecraft and a plethora of awesome builds within that... but one of the impressive things I've seen was about a year or so ago a teenager had built a working CPU in the game Terraria and programmed it to play Pong however, the game's internal mechanics for it's wiring system was measuring or recording each block or segment of wire which made this very inefficient. This kid took the game logic and rewrote some of it through scripting a mod that caused the entire connected set of wires to act a single unit so that the games logic would only test the two endpoints of the wire regardless of how many blocks or game cells it traversed to check it's signal. He optimized the game in order to get the game to perform better to do what he wanted. Then there are people who made the A CPU in the Conway's Game of Life that would in turn generate Conway's Game of Life. This is why I love just about everything that is involved with computer science. Man went from the stone age to refining stone - sand into silica to make transistors and CPUs then to program them to make video games, and video games doing what? Mining Rocks! We went from the stone age to the virtual stone age!
I decided to patch the ROM by changing the scratch memory used by the Dynamic Jump routine to a pair not used too much by the game. Wasn't hard at all... the two zero-page RAM locations, $02 and $03, next to $00 and $01 clearly looked like they weren't being used, so I incremented these system bus values by two: AC87, AC8A, AC8C, AC90, AC92, AC94, AC96 A direct ROM patch would change these locations instead: 2C97, 2C9A, 2C9C, 2CA0, 2CA2, 2CA4, 2CA6 (headered ROM; the header is 16 bytes long, so the hex offset is 0x10) 2C87, 2C8A, 2C8C, 2C90, 2C92, 2C94, 2C96 (headerless ROM; no header, no hex offset) The reason for this massive location discrepancy is because the PRG ROM (which is located before the CHR ROM) is mapped with a hex offset of 0x8000 in system bus. Tetris uses the MMC1, but doesn't have more than 32KB of PRG ROM so all of it is mapped at once with no bank switching. The Game Genie Codes to patch the Dynamic Jump routine (there are unfortunately seven, so they can't be used on a physical Game Genie): ZEEZNGAA LEEXXGPA ZEEXKGAA ZEOZEGAA LEOZXGPA ZEOZKGAA ZEOZVGAA I managed to find a proper "Fastest Crash%" TAS (tried to get StackRabbit to work, but failed) and verified that: 1. The TAS indeed crashes Tetris. 2. The patch successfully prevents* the crash. 3. The patched ROM plays identically to the original version (RNG is identical; the exact same tetriminos dropped in the exact same order during the TAS between the original and the patched versions). 4. The Game Genie codes also successfully prevent* the crash. The TAS in question: tasvideos.org/8254S (it was rejected due to poor optimization, but good enough for my needs). To be honest, the solution to this crash looks so simple that there is NO WAY that no one has thought of it! Surely there's a patch out there that does this, it's only seven ROM values!! * The patch prevented the first possible crash. Due to not being able to get StackRabbit to work properly, I am only able to verify as far as the TAS is capable of. EDIT: Added an asterisk-disclaimer. EDIT2: Expanded bulletpoint 3 to reduce confusion.
Loving these recent deep dives! Very interesting to understand these edge cases and their effects. And now, taking it a step further and exploiting them too. It really scratches that low-level itch.
Top-tier nerding, top-tier presentation, top-tier voice, top-tier content all around. Not that I understand much (well, anything, really) about assembly, but you always make it so interesting! I'm always fascinated by deep dives into the intricacies of old tech. I hope you blow up someday. 🙏
The real challenge is to make the code corrupt some parts of memory and do this crash save multiple times to mangle memory somewhere into code that does this more efficiently and then do a different setup to jump there. That, or just crash the game, change the scores in some normal, low-level gameplay so that it fixes the stack, maybe does some extra stuff, and then jumps to that RAM you corrupted. Then, use crash saves to corrupt even more RAM into code that allows you to completely hijack the game, like a hex editor. Doing ACE in NES Tetris is an extreme challenge to see if a TAS could be made to do it with as few add-ons as required. This is what I would love to see!
Hey! So I haven't watched the full video yet but will finish it this weekend. This looks really well presented man! I was thinking I'd try this using my NES Automatica. I have everything I need but I just moved and am still getting everything setup. If you think you'd use it, I'd be happy to send you a fully assembled one if you want to try automating the vulnerability. Good work man!
I had to pause the video just to point out that the song playing around 8:30-some I only know because of Synth Riders, and it is an awwwwwesome song. Also, hooray more Tetris stuff!
I enjoy watching these behind the code series videos really into nes hacking as well I been messing around with mega man 1 with the messen emulator improving the game like life bar placement and made sprite edit on mega man to hold his arm cannon when he shoots to rebalancing boss damages etc keep making these videos
Excellent video. Clear explanations and after watching RGMEX's video on why Tetris crashes, it perfectly complements it. Keep up the great video work, I really enjoy the videos on the technical aspect with splashes of humor into the mix while keeping it easy to understand. 😄
I loved watching this and I appreciate all the research you must have done to accomplish this. Thank you for yet another interesting deep dive into a classic game!
This was incredible, amazing, awesome and I will always find arbitrary code execution to be one of the coolest parts of gaming. Not just the what, but as this video demonstrates, the where and how. Very cool video, very cool demonstration. Edit: and afterwards I realize I missed the premise was already explained and the assignment given 😅
Can you make a Controller Breakdown video on the Genesis controller next? Since it is backwards compatible with the Master System, and how it multiplexes the data lines
That was in-tense! Lots of it went over my head but it was very cool. Loved that you made your own 'tupperware' controller with simple toggle switches - loll!!
For some reason I expected showing off some really fancy community-made code injections, like the things where Super Mario World is programmed to play Pong, Snake, or Flappy Bird. I guess this is too newly-discovered for that? Or is there not enough accessible ram and inputtable op codes for something that impressive, even given years of creative ingenuity by the world?
Here's a fun little idea I had immediately, even before learning what you wanted to do with the changes: Instead of fixing bugs in Tetris, how about using one of the multi-game cartridges with Tetris and simply launch one of the other games. Didn't bother checking whether instructions for doing so would be within reach, though.
I just *know* there are gonna be purists who wouldn't allow left and right being held at the same time, hopefully we'll discover a way of doing something similar without the need of opposing directions being held at the same time. But that aside, it's amazing how this was achieved in the first place, and it's only a matter of time before someone uses the ACE with a TAS to make all the crazy stuff that you can do with total control
This may be a noob question, but since you can literally change a value of an arbitrary RAM address, wouldn't it be more useful to just override the game's code directly? That way maybe it would be possible to disable the game from recalculating the score entirely
You would need to alter something that would cause the existing score calculation code to not execute for the remainder of gameplay. You cannot override existing ROM code the way you would if you were using a game genie and are limited to RAM modifications. Even drop speed is recalculated/looked up via code each frame.
Have you tried to test these on an AVS console? The built in Game Genie software allows you input 5 Game Genie codes instead of the usual 3 Game Genie codes.
I think the BRK instruction should be clarified a bit more than it is in the video. That opcode isn't just a two-byte NOP like the video makes it sound. It's a software-triggered interrupt. It actually will call the standard IRQ. The interrupt handler probably actually causing the glitch is Tetris is likely the NMI (As the VBLANK of the NES/Famicom hardware is hardwired to the 6502's NMI line.), which has its own vector separate from IRQ/BRK. The reason this is important is that the BRK instruction and hardware IRQ (Not NMI.) use the same vector, and it's up to the software to make a distinction between these. There's a flag in the status register that allows the software to know if the interrupt is caused by the BRK instruction, which can be used to branch elsewhere in the interrupt handler to do things more relevant to a software-triggered interrupt. This could have consequences depending on how Tetris handles software-triggered interrupts.
I didn't think I made it sound like it was just a two byte NOP. I left out the details about it on purpose for several reasons. The video was already pretty long, and the details behind BRK are trivial because all we needed to do was advance the program counter. Tetris has the interrupt vector set to the address for the RTI code at the end of NMI.
Amazing video! Is SMB doing the same input merge? In that case speedrunners would be able to make the same "impossible" button combinations as the tas...
6502 huh.. Assembly is always so tricky to deal with.. I always wonder how do they debug. I mean emulator provides this facility to see registers, RAM etc. But how do they think? Always assembly is so interesting.. And scary!
For holding Down, Left and Right, could you just open up the controller and put aluminum foil across the contacts to bridge the connection? Or just clamp down the silicon pads without the D-pad on the open pcb?
True. Perhaps just using some electrical tape to hold down the silicon piece would do it. If this method is used, placing something between the tape and the pads to prevent any damage from occurring upon removal would be a good idea.
