i think i finally understand why the "infinite" confetti isn't infinite on PAL (if this was even known before). since the frames last 17% longer, the tile countdown can actually reach 0 and finish before it is interrupted again. speaking of PAL, it would be interesting to see where the crashes are on that version.
I thought this was wrong, but I just looked it up, and while the PAL CPU Hz IS lower, the frames are longer by a greater % than the CPU is slower, so it does indeed have more time to do stuff per frame. Interesting!
update to the above: if FCEUX isn't failing me, the earliest crash on PAL (for all intents and purposes) should be a single into level 181 with a crash timing of 33227 cycles. i need someone to verify this though.
@@jthecollector6108On the PAL version of Tetris the crash happens on later levels than on NTSC because the frame is longer. (I tested the standonle ROM, I did not test the combo cartige ROM. I modded the game so I never goes past level 18 speed and I can start on high levels) The first crash I was able to trigger was a single into level 180, but this seems to have low odds of happening. In general singles only have a low probability to crash. Singles on level 181 and 182 have a low chance to crash. A single into level 183 seems to have the highest chance of crashing but not 100%. Singles on 183 and 184 are risky bust still way less risk than single on level 157 NTSC. Singles on level 185 trigger corruption glitches but no crash. There is no "infinite confetti" on PAL inestead the screen flashes. (I now know why) The PAL version can not crash by just placing a piece with out a lineclear, because the calculations without a lineclear always happen before the end of the frame. At about level 194 other lineclears start to become dangerous. I need to test that behavoir more, I don't know which is the first crash with other lineclears. Levels 196 to 199 are dagerous for linclears other than singles but by far not as bad as level 169 (or 170) on NTSC.
As a lifetime tetris player and computer scientist / epidemiologist, I love these deep cuts HD. Thanks for all the work you do for the scene, for science, for tetris!
>decrement before checking the counter Knowing how the dev initially thought no one would get pass level 29, I love how much horror lying in this code, it works as long as it works lol, and the something waiting for the FF terminator is literally me hostage in ranked matches waiting for the FF from my teammate
Just a fan here, although I once got 188 lines on GameBoy Tetris as a 13-year-old in 1995. I would love to see your spreadsheet containing all possible killscreens. If it were public, fans like myself could see all the roadblocks on the way to defeating level 255, and would therefore be able to better follow and appreciate each player's journey to get there. In a recent video about Blue Scuti's achievement, aGameScout shows a glimpse of the spreadsheet, and provides a link, but the link is broken. From that gimpse, I can tell that casual fans, myself included, will need a tutorial on how to understand the various acronyms and comments. Do you know what level Blue, Fractal, and Andy started at? It seems like for them, the line count at single-line level transition is always (level# -1) / 10 - 50. I would have assumed that meant they were starting at level 6, but given some levels take more or less than 10 lines to clear, I have no idea anymore. Thanks. Brett
hm, link shouldn't be broken. docs.google.com/spreadsheets/d/1zAQIo_mnkk0c9e4-hpeDvVxrl9r_HvLSx8V4h4ttmrs/edit?usp=sharing fractal & scuti started on 19, andy on 18. the first level will last until you have cleared 10*level lines, ie lvl 9 start = lvl 10 at 100 lines. this desyncs at levels > 10, where 10-15 all proceed to next level at 100 lines, and then they start increasing again 16+, so that's where that difference of 6 is coming from; 18 to 19 at 130 lines, 19 to 20 at 140 lines.
Simple game, made for a potato CPU and it contains lot more interesting things than some modern games do. Even if i dont properly understand any of this, i do get the general story behind things being explained and i aint done being amazed
I love the style of these videos, such a good explanation. How come you refer to the VBlank Interval as NMI though? Is the VBlank interrupt the only non-maskable one on the NES?
I'm not entirely sure but I think it's either 1) any NMI trigger/handler causes the memory corruption or 2) (more likely imo) as you guessed VBlank is the only (interesting) NMI trigger used by Tetris
Yeah there's no other interrupts that happen on NES tetris, just vBlank. I think maybe some games set the PPU to send more interrupts for better timing info? Don't quote me on that though. Probably poor practice on my part to use the terms interchangeably.
@@wiirambo7437yeah it's funny that it's called non-maskable when you can literally turn it off if you want to. doing that for the scoring frame would patch the crash and related bugs.
I love how the scenario of each one is just about this worker in the shape of a Tetris piece just acts stupid and delusional, it’s like a teacher teaching in an interesting way.
Doesn't the 6502 have an instruction that switches the processor into BCD mode? Does that get turned off when the NMI happens or is there a way to get it stuck like that and trash everything?
because the crash happens when a particular routine is interrupted, and if the scoring takes so long it doesn't even get to that routine before the interrupt, there won't be a crash.
Very well described. I do have a few thoughts through. I'm not too deep into this, so I might be drawing completely wrong conclusions. From your older videos, it looks like the scoring algorithm is always starting at the same time during a frame since the crashes require the PPU to interrupt precisely at certain instructions, yet its very reproduceable. This brings me to the assumption that there must be some code waiting for the PPU interrupt after all of this. If the PPU happens before (like when the scoring is too long), this would skip a frame. With this in mind, could we somehow extend some other routine and make the game run at slower speed?
Yes, you're spot on; there is a place in code where the CPU waits for the PPU to keep game timing consistent. Under normal circumstances, all game logic completes in less than one video frame and enters an infinite busyloop to wait for the vblank interrupt. The interrupt code unsets a wait flag so that, when returning from interrupt, the busyloop is allowed to exit and proceed to the next frame of logic. On the other hand, when scoring calculation starts taking too long, we end up with a lag frame; The CPU won't reach the busyloop before the vblank interrupt. When returning from interrupt, the CPU picks back up from where it left off, reaches the busyloop, and waits for the _next_ vblank interrupt. So, the scoring frame's logic will end up stretching over the course of 2+ video frames, but (assuming the crash is missed) we'll be able to pick back up as normal after that.
the game adds score every time you place a piece, its just that 0 line clears add 0 to the score a million times. this is usually fine until the last few levels
The game crash can be used for ACE since it happens due to reading RAM as code (and Kirjava, Fractal, & HydrantDude have done some work in researching it which you can find online if you look hard enough), but as far as I can tell, confetti isn't useful because it's interpreting the data as parameters for the drawing routine, not executing the data as code.
Given that the NES has no networking and no writable storage media, I'm not sure how you'd ever get any exploit code onto the system in the first place.
@@cspiff in ACE you use the controllers to write exploit code. there's also the gimmick way where you write a payload using a different cartridge and hot swap them before RAM is cleared, which is used in 100th Coin's ACE video on SMB1
@@Patashu Yeah, but its unfortunately going to stay TAS only. It would be sick if users could abuse it to take over the game like with 1st Gen Pokemon. We'd need some way to interrupt the game flow and store user input in some point at RAM, then exec it. Unless we can abuse some routine, that probably needs 5-10 bytes written.
@@cspiff you can write into the high score tables for A and B type, including the name you enter, the score you get, and the level you top out on.. question becomes whether that is enough to boostrap up the next level where you get to use controller inputs to program higher amount of complexity
