Okay, I was definitely not expecting this.
This movie aims to get to the final credits in the smallest amount of time. It does this, through major glitching in 2 minutes and 28 seconds. It's *almost* short enough to be played with my old movie and still be shorter than Soulrivers' movie. Unfortunately, it's not quite. Maybe next time. (it is now) The game title is misleading, and Mario doesn't even see one of these "golden coins", instead Mario just says "Fuck it." goes straight into the depths of hell and summons the credits.
This is a 651 frame improvement to the cancelled movie. Improvements come from a new strategy to get to the garbage data with a mushroom, and some small, minor optimizations.
Last time, I thanked MUGG right at the start. This time, it's not quite enough. Because he found the glitch itself and helped me enormously with route planning and other stuff, I'm listing him as a coauthor. Unfortunately, none of his input is in the final movie, but he still put in enough effort to be listed as an author.

General comments

I'm not really sure whether or not this movie should obsolete the old one. Although they are technically both any%, they are sufficiently different enough to warrant separate publications until a 100% run comes along (Also, the old any% is pretty similar to a 100% anyway).
So here's how it's done. You need to manipulate the byte at address 0xA2D5 to 0x60 from 0x00 in order to set the credits as the next level. Then, the next time you go into a level, the credits will roll. The end!
In Super Mario Land 2, every block represents a byte in memory. Normally, the level is stored in the 0xC000 - 0xDFFF range, but if we go out of bounds we can see other parts of memory as if they were a level, albeit a very glitchy looking one. Basically, I have to bury mario deep enough into the garbage up until the point where I can jump and crush the block that represents 0xA2D5. Once that's done, I quit, and restart the level, and hey! credits roll!

Detailed comments

introductory stage

Here I was battling between two different strategies. I could either run straight through the level, or I could slow down a bit and collect 30 coins. 30 coins? let's talk about that later.
I use a speed trick which requires mario to repeatedly hop through the whole level. Mario gets 1 pixel boost every time. I mention this trick in the comments for my last run, so I'll just copy it here:
The "new" pixel trick
This idea came about when I was trying to prove that the maximum time possibly saved using the pixel trick would be 1 pixel every 8 frames. The problem boiled down to whether or not you could change the number at A200 from D0 to CC in exactly four "moves" using only +4, -4 and -C, OR +8, -8 and +0. This is quite obviously impossible, as no matter how many times you apply +8, -8 and +0, you will never change D0 to CC, and if using +4, -4 and -C, you can only reach CC from D0 in odd moves. This seemed like case closed to me until I realise that if I could use all of +4, -4, -C +8, -8 and +0, the problem was gone.
Although the above paragraph makes little sense, let me try to explain. D0 and CC represent different 8 frame oscillations. If I were to be able to change between D0 and CC in exactly 4 frames, then I could save 2 pixels per 8 frames. On land, I can add or subtract 4, or subtract C from D0 once per frame. In the air, I can add or subtract 8, or keep the value the same once per frame depending on what buttons I had pressed. Normally, It would be a fair assumption that it would be impossible to be on land and in the air at the same time, so it would be fair to say that I couldn't use +4, -4, or -C along with any of +8, -8 or +0. This is of course false. If I decide to jump during the period of time where I am changing between D0 and CC, then I have the opportunity to use all of +-4, +-8, -C, and +0 within that window of time. Similarly, landing on the ground presents a similar opportunity. This would mean that I could save an entire pixel every time I jumped, much like the moonwalking technique described above
This would logically mean that I would necessarily be jumping around as much as possible all the time. Perhaps in the future a run with this technique can be used, but for now, I enjoy the relative freedom of using a slightly outmoded version.
I must admit, I use this trick ONCE in the run: in pumpkin zone 1 near the end, it allows me to land on an odd numbered frame. However, this was just luck, and I had no real idea what had happened. I actually discovered that it could save time much later on.
Twice I abstain from doing this trick in this level because it caused more lag than time saved.

Macro Zone 1

Thanks for MrGrunz for hypothesizing that this could work. If you die on the same frame you go down a pipe, then you can use the pipe glitch without completing the level first. Normally, you would complete the level to enable the use of start/select and then use start/select to exit while in the pipe. But this is pretty cool. You can't do this in pumpkin zone, so I do it here.

Pumpkin Zone 1

Wheee! I just fall to a block that I manipulate to be an exit by changing Mario's horizontal position on screen. Why don't I bury myself just yet? Because I need at least big Mario to crush the credits block in the depths of the garbage.

Pumkin Zone 1 pipe glitch setup

Now there are two ways to get a powerup before the garbage data. Option 1 is shown in the movie. Complete pumpkin zone using the pipe glitch, and then get a mushroom when you set it up again, or you can get 30 coins in the intro level and buy a powerup between macro zone 1 and pumpkin zone. This would mean you wouldn't have to do the pipe glitch twice. However, when I tested it, the second method saved about 90 frames, or a bit more if you entered into Mario zone instead of pumpkin zone, but the first method saved 10 seconds! Because me and MUGG thought it would be slower to do the pipe glitch twice, we almost missed this route, even though it seems inherently more obvious to start off with.
But getting the mushroom without slowing down is pretty cool.

Pumkin Zone 1 garbage

I'd like to note that due to the stop-start nature of this level, and the weird, timer based acceleration, sometimes I have no choice but to lose or gain frames. sometimes you accelerate slower or faster, and usually, it's slower to manipulate it than to get what you've been given. I also lose some frames because I don;t have a fireflower, so i can't do some things that I normally could.
Route planning was the major difficulty here. I have an accurate map for the first 64 rows, but for the next 100, I'm on my own. The route for the first 64 rows is designed to stay as close as possible to the left, Because it's faster to go left, and let the game's horizontal position overflow than it is to go right and get to 0xA2D5 directly like in mugg's testrun. The game has a tendency to make mario move right, because that's the way mario is ejected once inside a block.
The first 64 rows were pretty simple. I had a map, so I could just make some theories and test them. The number of routes is pretty limited so it was easy to test. There is also no weird camera movement, and the blocks shown are actually what they look like, unlike the next 64 rows. There are also very little programming errors to abuse here, apart from a weird behaviour that if you fireball a fire block, you can't fall downwards unless mario jumps. I couldn't use this in this run because I don't have a fireflower when I go through the garbage
The next 64 rows represent ROM that is bank-switchable. That means that if I perform certain behaviors, I can completely change the level layout. One behavior frequently used is B + ^, which changes the bank number, which can be used to fall through some floors or insert solid objects in the way of marios path while in the "pipe" animation, so that he will continue to be ejected. It means mario can fall through floors because I switch to a level layout where there is no floor, and then switch back to the original layout.
The basic strategy here is to go to the left until Mario is over 0xA2D5 using pipes, because going left in a pipe is faster than running (2 pixels per frame compared to 1.625 which is the speed of running with the pixel trick), and then falling to the end. The last pipe I found was excellent for this purpose. It goes left for as long as you want it to, (it is so long it can almost take Mario back to where he started!) and has many places Mario can exit using B + ^. it is also situated directly above a large recess, so Mario can fall almost straight to 0xA2D5, with a few stops along the way. I think I found a good route for these rows. Too far to the right, and you have to go even further to the right to get to 0xA2D5, Otherwise, you would have to go as far left as I did anyway in order to get down to 0xA2D5. Overall, even though I didn't have a map for this part, I think there is the possibility of 1 or 2 potential improvements, and minor ones at that (I don't know of any improvements, I'm just saying, they could be there).
The last few rows of garbage are pretty simple This part of RAM represents graphics of blocks. Break a few blocks and you're at 0xA2D5.
Well, hope you enjoyed the run!

Nach: Judging.
Flygon: Added YouTube module.

Nach: Just great, I need a debugger, hex editor, and dev manual to follow what went on in this game. I don't know about these 6 Golden Coins (not that there's any Gold at all that can be seen), I'm not even sure if there's much of a land here either. Too confusing to follow, therefore, I have no choice but to accept this run.

GabCM: Using Flygon's stuff for publication.


Active player (429)
Joined: 9/7/2007
Posts: 329
It's a good thing that Mario did not warp to the Pokemon Hall of Fame at the end of the run. Yes vote for the game breaking.
Skilled player (1652)
Joined: 11/15/2004
Posts: 2202
Location: Killjoy
Warepire wrote:
It was mentioned in the cancelled submission that breaking blocks in the ROM area of memory will crash the emulator. The post in question: http://tasvideos.org/forum/viewtopic.php?p=258195#258195
For some reason, it always seems like mario hasn't gone that far before breaking blocks. I think a lua script that showed where you were in the ROM/RAM would be awesome, or a note in the youtube stream once he crosses over. Sorry, it was my misinterpreting what happened. Awesome, awesome run. Easy Yes vote.
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
Experienced player (642)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I'll post this here. A write to ROM is actually not an illegal write. Writing to the ROM adresses is the way of sending instructions to the MBC inside the actual cartridge. Super Mario Land's cartridge type is MBC1 + RAM + BATTERY, so here's what should happen if you break blocks in the ROM area. If you write anywhere between 0000-1FFF (first 32 rows), it will enable or disable the external RAM (i.e the RAM between A000-BFFF) This part of RAM contains all the important game variables. if you write 0x60 anywhere in this region by breaking a block, you will disable this RAM, and the program can't run without it. This probably causes a soft reset. (It crashes the emulator generally, this is due to innacurate emulation)at If you break any block between 2000-3FFF (next 32 rows), it will change the bank of ROM adressed at 4000-7FFF to bank 0x01 (for some reason, you can't select 0x00 as the bankable ROM in a gameboy, and an attempt to access bank 0x00 will result in acess to bank 0x01, This is also) This doesn't seem to disrupt gameplay, because it switches back quickly. Also you won't be in 4000-7FFF when it changes. If you break any block in 4000-5FFF, it will take the lower 2 bits of your write and change the RAM bank OR the upper two bits of the ROM bank, depending on the mode of acess (see 6000-7FFF). If you break a block or collect a coin, it will do absolutely nothing, because it will write 0x60 to that space and change the upper two bits of the ROM bank to the lower two bits of 0x60 (which are 0 and 0), but they were always 0, so it doesn't make a difference. I'm not so sure what happens when you hit a coin block in this area. It should do nothing, because SML2 has no ROM past bank 0x20. (There is never any reason for SML2 to ever write to this area during normal play, since it only has a 512kB cartridge) If you break a block in 6000-7FFF, it will change the mode of the above addresses. If you break a block, it will do nothing, but if you hit a coin block, the MBC mode of the above will change from ROM bank switching to external RAM bank switching. (ROM bank switching is the default mode, and since SML2 has a 512kB ROM with 8kB RAM, there is no need to ever change the modes) This will only change anything if you go back up and change something in the above blocks AFTER you have changed something here. EDIT: it appears that the glitch that I used during my previous run, where I fireball a block in the 2000-3FFF range and that allows me to go through a pipe quicker may be an emulator glitch. This is because VBA allows for the access of ROM bank 0x00 between 4000-8FFF with the MBC1 controller, whereas the real GB does not (it will acess bank 0x01 instead)
Measure once. Cut twice.
Dwedit
He/Him
Joined: 3/24/2006
Posts: 692
Location: Chicago
I'm far more concerned about the VRAM area 8000-9FFF. Reads during render time are supposed to be effectively "random", because they return whatever the PPU was reading at that exact instant, and not return what's actually in those bytes. Even Gambatte says that render time reads/writes are "TODO" for its emulation. Not sure what happens when you write during render time, it probably scrambles either that byte, or another byte. During HBLANK or VBLANK time, they read/write as normal. I haven't stepped through the game's code... We need to know what time it checks for collisions with Mario at. If it all somehow happens during VBLANK time, you got really lucky that everything is consistent. Otherwise, there's no clue as to what's going on. The time it fetches the VRAM map tiles for that byte doesn't really matter, you'll just see the wrong tile on the screen before you interact with it. The FE00-FF80 region (OAM, "unused", and IO ports) is also questionable.
Experienced player (642)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
Is there any documentation about this phenomena? or is it just a bit of hit and miss? "Random" doesn't really play a part in TASing at all, so if there is any information concerning the workings of the PPU in conjunction with the RAM it would be much appreciated. (Also, information about I/O, and OAM would also be appreciated) EDIT: As far as I can tell, OAM and VRAM behave the same way. Writes will be ignored during render time and reads will return undefined values. Also the part of I/O I come into contact with are to do with the sound controller. I mean, none of this information is particularly useful, so I was wondering if there was any further information on this kind of thing.
Measure once. Cut twice.
Experienced player (603)
Joined: 2/8/2009
Posts: 656
2:28, what an awesome time :D glad I could help you guys with this a bit. the run itself looks really clean, so how could I not vote yes?
mklip2001
He/Him
Editor
Joined: 6/23/2009
Posts: 2227
Location: Georgia, USA
Somewhere early in the run, you stopped playing SML2, and you started playing the system itself. Brilliant run, and it's funny to see the strategy of dying in the pipe. This earns my Yes vote and a lot of respect. I also really like the second screenshot in MUGG's latest post here: http://tasvideos.org/forum/viewtopic.php?p=258527#258527 This picture does a good job of looking glitched without being a garbled mess. Mario also looks pretty carefree in it.
Used to be a frequent submissions commenter. My new computer has had some issues running emulators, so I've been here more sporadically. Still haven't gotten around to actually TASing yet... I was going to improve Kid Dracula for GB. It seems I was beaten to it, though, with a recent awesome run by Hetfield90 and StarvinStruthers. (http://tasvideos.org/2928M.html.) Thanks to goofydylan8 for running Gargoyle's Quest 2 because I mentioned the game! (http://tasvideos.org/2001M.html) Thanks to feos and MESHUGGAH for taking up runs of Duck Tales 2 because of my old signature! Thanks also to Samsara for finishing a Treasure Master run. From the submission comments:
Shoutouts and thanks to mklip2001 for arguably being the nicest and most supportive person on the forums.
zem
Joined: 10/3/2009
Posts: 32
zem wrote:
the description is amazing. i can't wait to watch this.
I wasn't disappointed. corrupting the data by literally running around in it and breaking blocks is hilarious + cool
Active player (294)
Joined: 12/16/2008
Posts: 458
Location: Houston
is there a reason you can't simply create a mushroom on your way down, there seem to be plenty of ? blocks
Experienced player (642)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
There is no specific "mushroom" block. There are ? blocks with the mushroom object inside them. SInce there are no objects in the garbage data, only tiles, all of the ? blocks contain coins.
Measure once. Cut twice.
Player (146)
Joined: 7/16/2009
Posts: 686
I love these glitchy runs. Obvious yes vote.
Editor, Expert player (2364)
Joined: 5/15/2007
Posts: 3940
Location: Germany
Comparison video 2:28.08 vs. 2:40.95 (starts at 6:10 in the video) account | free
Skilled player (1652)
Joined: 11/15/2004
Posts: 2202
Location: Killjoy
Nach: You didn't clarify in your decision - is this going to obsolete the current any% run, or start as a new glitched category?
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
sgrunt
He/Him
Emulator Coder, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
This should be a separate branch.
Senior Moderator
Joined: 8/4/2005
Posts: 5777
Location: Away
So is this confirmed to be a game glitch and not an emulator glitch?
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
sgrunt
He/Him
Emulator Coder, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
I know there was a post somewhere indicating that this glitch was reproducible on console, but I'm having trouble finding it right now.
Post subject: Movie published
TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 15628
Location: 127.0.0.1
This movie has been published. The posts before this message apply to the submission, and posts after this message apply to the published movie. ---- [1721] GB Super Mario Land 2: 6 Golden Coins "game end glitch" by andymac & MUGG in 02:28.08
Joined: 6/4/2009
Posts: 570
Location: 33°07'41"S, 160°42'04"W
Here is a version of the chosen screenshot that was run through pngout if you want to replace it:
Skilled player (1652)
Joined: 11/15/2004
Posts: 2202
Location: Killjoy
Alright, this quick pub was crap - more discussion should have occurred. #1, the current any% run uses the exact same glitch, the pipe glitch, for a different effect. #2, The precedent for this type of obsoletion was for it to obsolete the any%, see http://tasvideos.org/forum/viewtopic.php?t=7865 or http://tasvideos.org/forum/viewtopic.php?t=8001 Both of these movies were obsoleted by movies that used BRAND NEW GLITCHES, simply because the previous run had used glitches as well. This movie even uses the same dang glitch as the current any%.
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3576)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
I have to agree with DarkKobold completely here. And to add to the precedent, there's SM64 low 14%. Also, there is the soon to be precedent of SM64. Like this game, SM64 used a glitch (BLJ) to beat the game in 16 stars, then later found a way to use the same glitch to beat it with only 0 stars. I set this to obsolete the previous movie and named them pipe glitch as the branch name. IIRC the previous movie before that did not use the pipe glitch? Perhaps the debate is whether it should be unobsoleted as a glitchless category.
It's hard to look this good. My TAS projects
Experienced player (642)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
Personally, I think we have two options, firstly, we can use the Yoshi's island precedant. The reason being is that the old SML2 any% is already too similar to a 100% run, so previously there were going to be no two categories due to redundancy. Now, with the ability to skip straight to the credits, the any% and 100% are now sufficiently different to warrant separate publications, so that when a 100% run does come along, it obsoletes the old any%. Alternatively, like adelikat said,we can use the SM64 precedent, obsolete the old any% with the new any%, but I would be against having a glitchless category, because it would be too similar to the 100% to warrant separate publication. Personally I don't really care. The only difference is whether the old any% still remains published during the creation of a 100% (maybe glitchless 100%) movie.
Measure once. Cut twice.
mklip2001
He/Him
Editor
Joined: 6/23/2009
Posts: 2227
Location: Georgia, USA
With the examples of Chrono Trigger and Earthbound that have been brought up, a large part of the debate was whether to keep an outdated run published. The previous any% run for this game wasn't really outdated at all. I'm not entirely sure whether this affects the argument about using the precedent set by Chrono Trigger and Earthbound. I prefer the argument andymac brings up about Yoshi's Island. In that game and this one, the old any% run is quite close to a 100% run in terms of the gameplay it shows, whereas this new any% run is radically different-looking. I guess this doesn't make a strong enough argument to keep the old any% around for now, since it did use the pipe glitch. It does make an argument for a 100% run to obsolete a former any% run, though. In any case, congrats on the publication, and I look forward to hearing more about a 100% run!
Used to be a frequent submissions commenter. My new computer has had some issues running emulators, so I've been here more sporadically. Still haven't gotten around to actually TASing yet... I was going to improve Kid Dracula for GB. It seems I was beaten to it, though, with a recent awesome run by Hetfield90 and StarvinStruthers. (http://tasvideos.org/2928M.html.) Thanks to goofydylan8 for running Gargoyle's Quest 2 because I mentioned the game! (http://tasvideos.org/2001M.html) Thanks to feos and MESHUGGAH for taking up runs of Duck Tales 2 because of my old signature! Thanks also to Samsara for finishing a Treasure Master run. From the submission comments:
Shoutouts and thanks to mklip2001 for arguably being the nicest and most supportive person on the forums.
GabCM
He/Him
Joined: 5/5/2009
Posts: 901
Location: QC, Canada
Sorry, and sorry for that publication. I didn't watch the older movie and by seeing the time and the lack of branch name in the older movie, I thought it was something to publish alongside this one. * Mister Epic is ready to get shot in the face.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Sorry, I didn't clarify, I thought it was obvious. I meant for this to be accepted as a unique set of glitches employed, and not obsolete the previous movie which did not use the ROM rewriting to my knowledge.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Dwedit
He/Him
Joined: 3/24/2006
Posts: 692
Location: Chicago
There is no ROM rewriting, just precision poking to RAM.