Kirby decides to save the planet by climbing a ladder. Do not try at home!

Glitches that crash the game in a lot of different ways each time you are doing them are usually a sign that really crazy stuff is going on. This video [dead link removed] made me interested in this glitch and I somehow managed to activate a debugger function or something. After a few tries I found out that the main CPU (the game has also the SA1 chip) sometimes runs over the controller registers, which is a good thing if you ask me :D.

The reason why the game freaks out when you try to climb a ladder up and down at the same time is because it doesn't expect you to do that. The initial glitch happens in the SA1 processor which indexes a location wrong and jumps to garbage code where it BRKs. Because of the BRK it jumps to location $5FFF which is just before SRAM (starting at $6000). It keeps breaking and filling up SRAM from the end to the start until it overwrites the addresses it is executing and then everything starts. It manages to lead the CPU to the controller registers at $4218 where then the fun begins.

When I say the fun begins I don't actually mean fun, because I now have to deal with two processors and a destroyed RAM. With a lot of trace logging and lua scripting I managed to kinda see the addresses I have to change for example changing the gamemode ($7390) to cutscene (0x0008) or the game chosen ($32EA) to Milky Way Wishes (0x0005). But I had a few problems while in the controller registers.

I start by trying to stay in the controller registers, which turned out to be harder than I thought. Because of the RAM being all destroyed the NMI and IRQ were going to crash once started. I managed to fix the NMI by changing $3099, but then the next interrupt that was going to happen would be IRQ. I "disabled" IRQ by setting the vcounter when it should start to 501, which is never going to happen. Then I had a fine working setup to write 2 bytes per 2 frames so far. I had to change so many addresses that it turned out to be faster to write a small code in RAM that allowed me to write 2 bytes per frame. Then I reset the SA1 processor and set it to a new location in SA1-IRAM, where I wrote a new code for it to execute, because not only RAM was damaged, the stack and direct page register were corrupted too. I changed all values and the last cutscene started.

It was very important to get a good starting state of the CPU when going in controller registers, because else the whole thing movie have failed when I tried to stay in the controller registers. By good starting state I mean the stack, the direct page and the data bank registers were normal (they could be corrupted in CPU and were corrupted in SA1). To get that I delayed a few frames at the start.

To see the code that the controller executed look at this.

Nach: After some discussions with the authors of the run and software, and some testing, it appears this run depends on various compile time specifics of the emulator. A run, especially of this nature, which is depending on various emulator issues is not acceptable.

This kind of run can probably be redone on a more accurate emulator build, one which emulates proper behavior, and may just need some memory addresses tweaked. But till then, rejecting.

Nach: Replacing with a new run from Masterjun which supposedly is valid this time, and rejudging!

Noxxa: Replaced submission file with a new version with a more accurate rerecord count.

Masterjun: Replaced branch name with a more fitting one.

Masterjun: I'm gonna cancel this TAS because I don't want to have a "cheap" SNES ACE run, which I realized after thinking about it a while. I consider these kind of runs "cheap" because they rely on the game crashing (really executing BRK instructions) and then running over controller registers by accident. The advantage of SNES runs over other consoles is that the SNES has 8 bytes that you can control with controllers, which are relatively many.

Don't expect any more cheap ACE runs by me.

Masterjun: Uncancelling. Ok, I should just stick to creating TASes and submitting them instead of deciding what happens with them here. Though, this doesn't guarantee that this is gonna be accepted, guys. I also changed the branch to "game end glitch".

feos: Accepting to Moons.

Ilari: Publishing...

Noxxa: Reverting acception due to judge dispute.

Nach: Rejudging. Again.

Nach: After reading more documentation than I ever wanted to, it seems this kind of run is possible. Recreating this run on a console would not be straight forward, but it looks like theoretically with some tweaking and enough resets, it just might. Since what occurs visually should be possible, I'll allow this.

Kirby Super Star is made up of a bunch of mini-games, which can be played individually. As more games are completed, additional games are unlocked. This run is interesting in that it goes to play The Great Cave Offensive, and then ends up completing Milkyway Wishes, which is the second to last game which can be unlocked. After the ending is completed, the cart shows that 0% of the game is completed, with no mini-games not even Milkyway Wishes or The Arena unlocked. (The Arena mini-game is unlocked when completing Milklyway Wishes in the normal fashion.)

Therefore, this run gets one ending displayed, what is usually considered by players to be the last ending (The Arena doesn't have a special ending), yet completes nothing, and doesn't show all the appropriate endings. As usual, this kind of run is problematic with its objectives and completions, and I dislike calling it game-end glitch. However it is interesting, and therefore accepting as whatever this branch ends up being called.

Ilari: Processing