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.


TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 15585
Location: 127.0.0.1
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
Oh, cool, encoding. SD encode YouTube HD
zem
Joined: 10/3/2009
Posts: 32
the description is amazing. i can't wait to watch this.
Active player (279)
Joined: 4/30/2009
Posts: 791
I notice in this and the previous version, there was no corner/edge boosting, unlike the any% version. Why is this removed?
Experienced player (623)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
well, corner boosting saves 1 pixel. Jumping with the new pixel trick saves 1 pixel. So if I have to sacrifice a jump to do a corner boost, it's not worth doing a corner boost. Also, because of the different way of doing the pixel trick, I can only jump on 2 out of 8 frames, which severely limits the number of corner boosts that I can do anyway. It just do happens that it's not worth doing any in this movie.
Measure once. Cut twice.
Joined: 5/13/2009
Posts: 141
Wow! That was completely sick. The glitch feels much more streamlined now. Hats off to Grunzy for glitch hunting again.
Editor
Joined: 3/10/2010
Posts: 899
Location: Sweden
Yup, directly editing memory by using the game engine itself, that's high class. Nice improvements too. Now there is even less gameplay left in.
Joined: 1/6/2011
Posts: 12
Well done on the improvement! If I could vote, I would vote Yes.
Warepire
He/Him
Editor
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
This was truly remarkable, obvious yes vote from me.
ALAKTORN
He/Him
Former player
Joined: 10/19/2009
Posts: 2527
Location: Italy
sweet new strategy, yes vote like before
Noxxa
They/Them
Moderator, Expert player (4125)
Joined: 8/14/2009
Posts: 4090
Location: The Netherlands
I love seeing runs that dig through game data in the form of levels. Yes vote.
http://www.youtube.com/Noxxa <dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects. <Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits <adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
Joined: 2/20/2010
Posts: 209
Location: I'm in space
I vote yes on any run that contains the submission text "I need at least big Mario to crush the credits block in the depths of the garbage". I thoroughly enjoy watching any game get turned on its head and kicked down a flight of stairs, and this is no exception. Thanks for brightening my day. =) Andymac: is that a toaster wearing a santa cap?
Oh, play it cool. Play it cool. Here come the space cops.
Joined: 7/2/2007
Posts: 3960
goldfish wrote:
Andymac: is that a toaster wearing a santa cap?
No, the Santa hat is riding a toaster.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Joined: 5/14/2007
Posts: 525
Location: Pisces-Cetus filament
Nice improvement. The uncertainty about whether or not this is actually possible in a real Game Boy is what stops this movie from being amongst my favourites. I have selected three screenshots: If the authors like any of them, I will optimize it.
AzumaK wrote: I swear my 1 year old daughter's favorite TASVideo is your R4MI run :3 xxNKxx wrote: ok thanks handsome feos :D Help improving TASVideos!
MarbleousDave
He/Him
Player (13)
Joined: 9/12/2009
Posts: 1559
Signum wrote:
Well done on the improvement! If I could vote, I would vote Yes.[/quote Now you can vote because you have made 4 posts.
BigBoct
He/Him
Editor, Former player
Joined: 8/9/2007
Posts: 1692
Location: Tiffin/Republic, OH
Awesome glitching. Yes vote for sure.
Previous Name: boct1584
Joined: 10/14/2010
Posts: 27
Location: California
So the question that remained on my mind... What *else* did you mess with the assorted POKEs into game memory on your way to 0xA2D5? And yes vote, again, of course.
>> Standing on head makes smile of frown, but rest of face also upside down
GabCM
He/Him
Joined: 5/5/2009
Posts: 901
Location: QC, Canada
You made this even better! Yes vote again!
Skilled player (1652)
Joined: 11/15/2004
Posts: 2202
Location: Killjoy
Zeupar wrote:
Nice improvement. The uncertainty about whether or not this is actually possible in a real Game Boy is what stops this movie from being amongst my favourites.
This is bothering me a bit... does anyone have the means to test this? By test, I mean make sure the game doesn't crash if you break a block inside the ROM area. I realize that the horizontal position makes it difficult to complete the game by replicating this. I'm wondering if it could damage the cartridge or gameboy if you attempt to write to the ROM area... I'd hate for someone to ruin their gameboy in this test.
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.
Warepire
He/Him
Editor
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
DarkKobold wrote:
Zeupar wrote:
Nice improvement. The uncertainty about whether or not this is actually possible in a real Game Boy is what stops this movie from being amongst my favourites.
This is bothering me a bit... does anyone have the means to test this? By test, I mean make sure the game doesn't crash if you break a block inside the ROM area. I realize that the horizontal position makes it difficult to complete the game by replicating this. I'm wondering if it could damage the cartridge or gameboy if you attempt to write to the ROM area... I'd hate for someone to ruin their gameboy in this test.
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
Editor, Expert player (2330)
Joined: 5/15/2007
Posts: 3933
Location: Germany
Breaking blocks in the ROM area on a real gameboy always resets the game for me. I can't easily test the glitch route since I have 1.1 or 1.2, so no pipe glitch there. My only fear would be the first two rows of garbage, since I tested another out of bounds bug the other day and the two rows differed (in fact, the ROM area did too, but that was to be expected with the version differences). Maybe we can just test the glitch route on Gambatte (more accurate gameboy emulator) or something...
Joined: 6/4/2009
Posts: 570
Location: 33°07'41"S, 160°42'04"W
Speaking of ROM, in which area are you when you collect the 144 coins? I just want to be sure, because maybe you are in the ROM area and you try to collect a block which is marked as a coin, trying and retrying to turn it from "coin" to "collected coin", and failing because the block can't be overwritten. Either way, as I did with the other submission, I cast a gigantic YES vote because this is amazing, even though it might not be possible on a real Game Boy. I'd test it on my real Game Boy, but I'm not sure which version of the game I have, and I never managed to perform the pipe glitch anyway.
Editor, Experienced player (570)
Joined: 11/8/2010
Posts: 4036
Great job! The glitching is even better than in the cancelled one! YES vote!
Editor, Expert player (2330)
Joined: 5/15/2007
Posts: 3933
Location: Germany
Experienced player (623)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I found some information on writing to ROM in the gameboy for MBC1:
MBC1 (max 2MByte ROM and/or 32KByte RAM) This is the first MBC chip for the gameboy. Any newer MBC chips are working similiar, so that is relative easy to upgrade a program from one MBC chip to another - or even to make it compatible to several different types of MBCs. Note that the memory in range 0000-7FFF is used for both reading from ROM, and for writing to the MBCs Control Registers. 0000-3FFF - ROM Bank 00 (Read Only) This area always contains the first 16KBytes of the cartridge ROM. 4000-7FFF - ROM Bank 01-7F (Read Only) This area may contain any of the further 16KByte banks of the ROM, allowing to address up to 125 ROM Banks (almost 2MByte). As described below, bank numbers 20h, 40h, and 60h cannot be used, resulting in the odd amount of 125 banks. A000-BFFF - RAM Bank 00-03, if any (Read/Write) This area is used to address external RAM in the cartridge (if any). External RAM is often battery buffered, allowing to store game positions or high score tables, even if the gameboy is turned off, or if the cartridge is removed from the gameboy. Available RAM sizes are: 2KByte (at A000-A7FF), 8KByte (at A000-BFFF), and 32KByte (in form of four 8K banks at A000-BFFF). 0000-1FFF - RAM Enable (Write Only) Before external RAM can be read or written, it must be enabled by writing to this address space. It is recommended to disable external RAM after accessing it, in order to protect its contents from damage during power down of the gameboy. Usually the following values are used: 00h Disable RAM (default) 0Ah Enable RAM Practically any value with 0Ah in the lower 4 bits enables RAM, and any other value disables RAM. 2000-3FFF - ROM Bank Number (Write Only) Writing to this address space selects the lower 5 bits of the ROM Bank Number (in range 01-1Fh). When 00h is written, the MBC translates that to bank 01h also. That doesn't harm so far, because ROM Bank 00h can be always directly accessed by reading from 0000-3FFF. But (when using the register below to specify the upper ROM Bank bits), the same happens for Bank 20h, 40h, and 60h. Any attempt to address these ROM Banks will select Bank 21h, 41h, and 61h instead. 4000-5FFF - RAM Bank Number - or - Upper Bits of ROM Bank Number (Write Only) This 2bit register can be used to select a RAM Bank in range from 00-03h, or to specify the upper two bits (Bit 5-6) of the ROM Bank number, depending on the current ROM/RAM Mode. (See below.) 6000-7FFF - ROM/RAM Mode Select (Write Only) This 1bit Register selects whether the two bits of the above register should be used as upper two bits of the ROM Bank, or as RAM Bank Number. 00h = ROM Banking Mode (up to 8KByte RAM, 2MByte ROM) (default) 01h = RAM Banking Mode (up to 32KByte RAM, 512KByte ROM) The program may freely switch between both modes, the only limitiation is that only RAM Bank 00h can be used during Mode 0, and only ROM Banks 00-1Fh can be used during Mode 1. MBC2 (max 256KByte ROM and 512x4 bits RAM) 0000-3FFF - ROM Bank 00 (Read Only) Same as for MBC1. 4000-7FFF - ROM Bank 01-0F (Read Only) Same as for MBC1, but only a total of 16 ROM banks is supported. A000-A1FF - 512x4bits RAM, built-in into the MBC2 chip (Read/Write) The MBC2 doesn't support external RAM, instead it includes 512x4 bits of built-in RAM (in the MBC2 chip itself). It still requires an external battery to save data during power-off though. As the data consists of 4bit values, only the lower 4 bits of the "bytes" in this memory area are used. 0000-1FFF - RAM Enable (Write Only) The least significant bit of the upper address byte must be zero to enable/disable cart RAM. For example the following addresses can be used to enable/disable cart RAM: 0000-00FF, 0200-02FF, 0400-04FF, ..., 1E00-1EFF. The suggested address range to use for MBC2 ram enable/disable is 0000-00FF. 2000-3FFF - ROM Bank Number (Write Only) Writing a value (XXXXBBBB - X = Don't cares, B = bank select bits) into 2000-3FFF area will select an appropriate ROM bank at 4000-7FFF. The least significant bit of the upper address byte must be one to select a ROM bank. For example the following addresses can be used to select a ROM bank: 2100-21FF, 2300-23FF, 2500-25FF, ..., 3F00-3FFF. The suggested address range to use for MBC2 rom bank selection is 2100-21FF. MBC3 (max 2MByte ROM and/or 32KByte RAM and Timer) Beside for the ability to access up to 2MB ROM (128 banks), and 32KB RAM (4 banks), the MBC3 also includes a built-in Real Time Clock (RTC). The RTC requires an external 32.768 kHz Quartz Oscillator, and an external battery (if it should continue to tick when the gameboy is turned off). 0000-3FFF - ROM Bank 00 (Read Only) Same as for MBC1. 4000-7FFF - ROM Bank 01-7F (Read Only) Same as for MBC1, except that accessing banks 20h, 40h, and 60h is supported now. A000-BFFF - RAM Bank 00-03, if any (Read/Write) A000-BFFF - RTC Register 08-0C (Read/Write) Depending on the current Bank Number/RTC Register selection (see below), this memory space is used to access an 8KByte external RAM Bank, or a single RTC Register. 0000-1FFF - RAM and Timer Enable (Write Only) Mostly the same as for MBC1, a value of 0Ah will enable reading and writing to external RAM - and to the RTC Registers! A value of 00h will disable either. 2000-3FFF - ROM Bank Number (Write Only) Same as for MBC1, except that the whole 7 bits of the RAM Bank Number are written directly to this address. As for the MBC1, writing a value of 00h, will select Bank 01h instead. All other values 01-7Fh select the corresponding ROM Banks. 4000-5FFF - RAM Bank Number - or - RTC Register Select (Write Only) As for the MBC1s RAM Banking Mode, writing a value in range for 00h-03h maps the corresponding external RAM Bank (if any) into memory at A000-BFFF. When writing a value of 08h-0Ch, this will map the corresponding RTC register into memory at A000-BFFF. That register could then be read/written by accessing any address in that area, typically that is done by using address A000. 6000-7FFF - Latch Clock Data (Write Only) When writing 00h, and then 01h to this register, the current time becomes latched into the RTC registers. The latched data will not change until it becomes latched again, by repeating the write 00h->01h procedure. This is supposed for <reading> from the RTC registers. It is proof to read the latched (frozen) time from the RTC registers, while the clock itself continues to tick in background.
Measure once. Cut twice.