Topic by pirohiko

Posted: 5/30/2015 1:11 PM

Quote

pirohiko

Skilled player (1769)

Joined: 5/7/2008
Posts: 187
Location: Japan

A new glitch seems to have been found. When you lost a battle 52 times in OW, various defects seem to occur by the representative character. For details, I know nothing. Link to video

Posted: 5/30/2015 7:46 PM

Quote

jlun2

Skilled player (1707)

Joined: 9/17/2009
Posts: 4952
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"

pirohiko wrote:

A new glitch seems to have been found. When you lost a battle 52 times in OW, various defects seem to occur by the representative character.

Were people just bored as hell? x.x

LLCoolDave wrote:

This seems to be competing for the "Worst looking TAS of 2011" Award.

Posted: 5/30/2015 8:13 PM

Post subject: Testing

Quote

Catastrophe

Joined: 11/17/2005
Posts: 278
Location: Massachusetts, USA

I can't believe how reliable this is? x_x It must have something to do with the music track. I tested Celes, Edgar, Locke, Setzer, Terra, Relm, and Strago each in a party of 2. And all I got was the same softlock as above for Umaro. I tried multiple spots on the WoB, but nothing changed. Cyan however caused the game to explode! But, I was using a save file which had done 1 of 2 sketch glitches from the old route, and Cyan's palette was wrong as a result. Also my Celes was Kutan. I'm not sure if these things matter? I have a feeling keylie's glitch is much more important, though. I think the setup for this one will be too much, if it ever does anything besides end the game anyway.

Posted: 5/31/2015 3:31 AM

Quote

pirohiko

Skilled player (1769)

Joined: 5/7/2008
Posts: 187
Location: Japan

The number of times [51*5 = 255] seems to be similar to the 64th-floor glitch. According to the rumor, I seemed to have possibilities to repeat a part of the ending. Because an item changes, and a game crashes, and data may disappear, may it lead to ACE?

Posted: 5/31/2015 9:07 AM

Post subject: Game Over Glitch

Quote

Catastrophe

Joined: 11/17/2005
Posts: 278
Location: Massachusetts, USA

I found two memory addresses which increment consistently when you "Game Over" on the overworld: 7E021C and 7E12E8. The second one seems to be the trouble. I don't know what that memory address normally controls, but it only ever does two things:

* Reset to 0 * Increment by 3 I think it has something to do with the scripting engine. A list of things that use/reset it include: starting a battle (except on the overworld), any time a scripted sequence runs, getting a game over (see previous), returning to the title screen, and opening the menu (except on the overworld). This variable pretty much never gets above 6 during normal play. When the Game Over scripted sequence begins to execute (kneel, change music, fade, etc) $12E8 is incremented by 3 like it is for most scripts. But if you do it repeatedly on the overworld then none of the common things which would reset it to zero ever happen. This is easy to arrange: save one step away from an encounter, at low life, and hold right+A plus emulator turbo. $12E8 will climb by 3 each death until it reaches 153 (0x99h). When $12E8 is equal to 0x99h then the Game Over script will have some other junk appended to it. What garbage the scripting engine is fed doesn't seem to have anything to do with your lead character (in my experience). I think it has everything to do with your input:

* the timing of when you press A to acknowledge the "Annihilated..." message * when/if you press A to cut the Game Over sequence short By varying those two things I was able to get a number of crazy effects: a screen that said "form 4 groups" (!), a save file selection screen that looped, regaining control after the game over event (you're still softlocked), a music change, a rename screen for Locke, the final battle's "Determine Order" prompt, the snow scene from the prologue, and a bunch of parts of the credits. Again, all I did was save state with the "Annihilated..." message up and press A randomly to get different effects. This doesn't seem like a broken stack or memory corruption. (Except for when that does happen as a consequence.) All of those effects, although crazy, are consistent with the scripting engine doing those things intentionally. So now the question is, what data is the script engine reading from, and can it be made to set a few choice event flags and return safely? The run would end real quick if it's that easy.

Posted: 5/31/2015 9:58 AM

Quote

keylie

He/Him

Editor, Emulator Coder, Expert player (2830)

Joined: 3/17/2013
Posts: 391

Thanks Catastrophe for the work. $12E8 is a copy of $E8 that is made at the beginning of a battle. At the end of the fight, the game copies back $12E8 into $E8. At a game over, the game calls event B2: "call subroutine xxxxxx". Here is the code of this event (US rom actually, but the code is identical to the JAP version):

Call subroutine aaaaaa (+$CA0000/$0A0200)
(gen. act. B2)

C0/B1A1:	A904    	LDA #$04	
C0/B1A3:	A6E8    	LDX $E8
C0/B1A5:	18      	CLC
C0/B1A6:	65E5    	ADC $E5
C0/B1A8:	9D9405  	STA $0594,X
C0/B1AB:	A5E6    	LDA $E6
C0/B1AD:	6900    	ADC #$00
C0/B1AF:	9D9505  	STA $0595,X
C0/B1B2:	A5E7    	LDA $E7
C0/B1B4:	6900    	ADC #$00
C0/B1B6:	9D9605  	STA $0596,X
C0/B1B9:	A5EB    	LDA $EB
C0/B1BB:	85E5    	STA $E5
C0/B1BD:	9DF405  	STA $05F4,X
C0/B1C0:	A5EC    	LDA $EC
C0/B1C2:	85E6    	STA $E6
C0/B1C4:	9DF505  	STA $05F5,X
C0/B1C7:	A5ED    	LDA $ED
C0/B1C9:	18      	CLC
C0/B1CA:	69CA    	ADC #$CA
C0/B1CC:	85E7    	STA $E7
C0/B1CE:	9FF60500	STA $0005F6,X
C0/B1D2:	E8      	INX
C0/B1D3:	E8      	INX
C0/B1D4:	E8      	INX
C0/B1D5:	86E8    	STX $E8
C0/B1D7:	A901    	LDA #$01
C0/B1D9:	9DC405  	STA $05C4,X
C0/B1DC:	4C6D9A  	JMP $9A6D

My interpretation of this code is that the game stores the current event pointer ($E5-$E7) into the event stack. The pointer to the top of the stack is precisely $E8. Then the game loads the address of the subroutine ($EB-$ED) into the event pointer ($E5-$E7), then increment $E8 by 3. I guess that in the case of our glitch, we make the game call a subroutine for each Game Over without returning from the subroutine, so that in the end the event stack becomes overflowed.

Posted: 5/31/2015 11:07 AM

Post subject: Game Overflow

Quote

Catastrophe

Joined: 11/17/2005
Posts: 278
Location: Massachusetts, USA

Thanks for posting that snippet! So now we know where the bad event code is loaded from, right? A 3-byte value starting at $7E062D. When calling a new script the game first takes the current function ($E5+6+7) and writes it to $7E0594 + $E8. (Since $E8 is the stack pointer.) It then loads the new script data offset and starts running that. Forgive me if this example is obvious. Say the event code is 7 functions deep, then $E8 will equal 21 and the current script pointed to by $E5-7 should also be located at $7E05A9. Since 0x594 + 21 = 0x5A9. Apparently the engineers decided that 50 nested scripts was enough and reserved space for exactly that amount. So when E8 gets up to 153 then the game will take script data from whatever is next in memory. $7E0594 + 0x99 = $7E062D. Now what the heck is at that memory address? And how can I manipulate it? I see it changing during the Game Over sequence. Since it appears right after the scripting engine's stack maybe it is some temporary variables used by the scripting engine? EDIT: let's call the glitch Game Overflow ^_^ EDIT2: script engine op-codes ctrl-f for "Event Commands"

Posted: 6/3/2015 7:56 AM

Post subject: New Info

Quote

Catastrophe

Joined: 11/17/2005
Posts: 278
Location: Massachusetts, USA

I think I understand what's happening. The scripting engine's stack seems to be a mere 10-14 elements deep. The game never needs more than 4 or 5 anyway. I watched memory during complicated sequences like the Lete River and it was only ever two events deep then: [semi-random battle] on top of [raft movement code]. At the point where you get off the raft and touch a save point the script ends (stack flushed, no scripts running) and a new one starts when you touch the next raft tile. Only in sort of complicated situations like the Returner's Hideout and post-Ultros1 does the stack ever get 4 deep. Immediately following the stack are a few other variables, then 10-14 more offsets, mirrored from the stack, but usually a bit off. Obviously it's for returning to the scripts where they left off. But fun fact: FF6 doesn't really pop the stack and resume very often. The Lete River random battles are an early example. But for the most part when a new script is launched the stack pointer is reset to 0. Seems like the game has "new script" and "new child script" functionality and the former automatically places the new script at the base of the stack. Basically everything uses the former and so this bug went undiscovered for so long. Also, loading an interior map will zero-out all the memory for the script engine, fixing whatever damage previous scripts may have caused. Good idea whoever decided to do that. I think there's still some obscure bug with saving Gogo, then Strago, then taking the Gem Box all consecutively with no breaks? But the scripting engine is pretty solid otherwise. Who is going to launch 10+ child scripts? After a "Game Over" the scripting engine will always be reloaded, right? Not on the overworld! Slight miscalculation in my previous post. The 51st death writes to 7E062[DEF], but reads from 7E063[012] when the script ends. And that's where the fireworks happen. Theoretically the game is busted long before then. Your first 10 or so Game Overs write the Game Over script repeatedly onto the stack. Your next couple deaths overwrite the middle variables that don't seem to be important. And then if you keep dying after that you'll start writing the offset of the Game Over script into the area where the return offsets belong. (Meanwhile, the return offsets themselves are also corrupting unimportant memory a few bytes ahead!) But none of this matters, because like I said, FF6 never pops the stack. The next non-Game Over script or map-load event will just zero all the memory. By the way, if you manipulate the 51st death to end safely without a softlock you can keep going forever. $BE just keeps going up and up and you can continue to corrupt a wide area of memory that really does nothing. I haven't tested 85 and 86 deaths, where $E8 would overflow and return 0x02. But a stack pointer which isn't a multiple of 3 probably still does nothing, even if it is abhorrent. The 51st death/script is the interesting special case. By then the RAM is completely wrecked. But each new copy of the Game Over script "paves the road it's about to drive on" so it is safe. (And the other territory it paves is never looked at.) However, the Game Over script contains an animated actor! Think about it: the music changes, your party leader takes a knee, and the scene fades out. $0630 (2 bytes) seems to be an animation counter for the animation of whichever actor is the #1 actor in the currently running script. $0632 (1 byte) is something about the graphics that actor is using. Together they make up a 3 byte offset that gets used to load a new script when the current script finishes. This position in memory is initially written with the Game Over script's offset, but of course it changes once the animation starts playing. As a result, the garbage fed to the scripting engine is determined by: a) your party leader and b) which frame you end the Game Over script on. And it can be predicted by $7E0630 (3 bytes). Now to figure out where I can load data from, and how to build interesting scripts in that area. EDIT: I can't predict which data is being loaded? What gets copied to $12E5 or $E5 is never quite a copy of what I see at $0630. Some other instructions must be modifying it. And sometimes I see the stack pointer jump all the way from 0x99 to 0x9C or higher in one frame, which tells me that whatever junk it loaded, then loaded more junk. (And hung.) I've been going about this by watching memory while frame advancing. So if multiple writes happen when I press A then it's impossible for me to follow.

Posted: 6/24/2015 5:11 AM

Quote

Oddity

Joined: 8/1/2004
Posts: 178

I'm watching someone play FF6 1.1 SMC on Bizhawk (blind, so taking his time), and I noticed various equipment like Tao Robe, and other armors (and such?), simply say "Recovers 50 HP," which makes absolutely no sense. The only explanation that quote is reserved is for Tonic. I don't recall seeing this happen before. What? (Supposedly it's 1.1 according to file size, but Sketch Glitch still happens on vanished enemies... not sure if that's always the case.)

<^>v AB X LR s

Posted: 7/2/2015 8:48 AM

Quote

keylie

He/Him

Editor, Emulator Coder, Expert player (2830)

Joined: 3/17/2013
Posts: 391

I did a bit of more work about that glitch and came up with the same conclusions as Catastrophe, using the US version. To be exact, during the 52 Game Over: - The game calls a subroutine, writing the return address into $062D-$062F - The game calls another subroutine, writing the return address into $0630-$0632 - Addresses $0630-$0632 are rewritten many times (see code around C0/0159) - The game returns from the second subroutine, writing $0630-$0632 into $E5-$E7 - The game then uses the address coded by $E5-$E7 as the current event ~~I didn't investigate yet how $0630-$0632 are rewritten.~~ See below. We could use this glitch to load the ending sequence. We could either manipulate $0630-$0632 to: - code the address $CA1362 (or around that) leading to the beginning of the ending sequence - code an address leading to somewhere in RAM or SRAM, and manipulate the content of that address to be the event B2 00 13 62 (jump to subroutine $CA1362), which jumps to the beginning of the ending sequence. EDIT:

Catastrophe wrote:

I've been going about this by watching memory while frame advancing. So if multiple writes happen when I press A then it's impossible for me to follow.

Geiger's Snes9x Debugger is a very useful tool, as it allows you to put breakpoints on addresses been read, written or executed, and advance op by op. EDIT2: $0630-$0632 are actually filled from horizontal/vertical scanline location!

C0/0153:   AD3721     LDA $2137    Software latch for hor/vert counter
                                   Necessary to fetch the hor/vert location later
C0/0156:   AD3C21     LDA $213C    Low byte of Horizontal scanline location
C0/0159:   8D3006     STA $0630    Stores into $0630
C0/015C:   AD3C21     LDA $213C    High byte of Horizontal scanline location (unused)
C0/015F:   AD3D21     LDA $213D    Low byte of Vertical scanline location
C0/0162:   8D3106     STA $0631    Stores into $0631
C0/0165:   AD3D21     LDA $213D    High byte of Vertical scanline location (unused)
C0/0168:   AD3106     LDA $0631
C0/016B:   CD3206     CMP $0632
C0/016E:   9003       BCC $0173    If vert scan is higher than $0632 then...
C0/0170:   8D3206     STA $0632    ...stores vert scan into $0632
                                   $0632 stores the maximum of all vert scan apparently
C0/0173:   20D4C5     JSR $C5D4
C0/0176:   4C2BC6     JMP $C62B

A doc about PPU registers: http://bin.smwcentral.net/26993/regs.txt

Posted: 7/5/2015 4:08 AM

Quote

jlun2

Skilled player (1707)

Joined: 9/17/2009
Posts: 4952
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"

Hey, if a game end glitch is found, how fast is this potentially compared to that other item glitch method you linked a while back?

LLCoolDave wrote:

This seems to be competing for the "Worst looking TAS of 2011" Award.

Posted: 7/5/2015 9:01 AM

Quote

keylie

He/Him

Editor, Emulator Coder, Expert player (2830)

Joined: 3/17/2013
Posts: 391

Well, this method would take 15 minutes to get to the overworld, then about 20 seconds per death, meaning about 17 minutes of deaths (maybe less if we manage to get 0 HP on both characters). So a total of 32 minutes.

Posted: 7/29/2015 9:52 PM

Quote

MarbleousDave

He/Him

Player (12)

Joined: 9/12/2009
Posts: 1555

How about an all Moogle run? Save after Narshe, Airship glitch to Zozo, Save after Zozo, Airship glitch to Vector. Molulu/Kuku can still use Blitzes after fighting Vargas. Also enter Phantom Forest from the south with Molulu/Kuku and Moglin/Kupek after getting Strago and Relm. For "Aims for in-game time instead of real-time" use the GBA version. otherwise it trades speed for entertainment.

Posted: 8/5/2015 11:44 PM

Quote

keylie

He/Him

Editor, Emulator Coder, Expert player (2830)

Joined: 3/17/2013
Posts: 391

32 minutes and 50 seconds is the new time: Link to video

Posted: 8/12/2015 8:31 PM

Quote

keylie

He/Him

Editor, Emulator Coder, Expert player (2830)

Joined: 3/17/2013
Posts: 391

Both the ACE and the game end glitch TASes have been reproduced on Niconico: Game end glitch: Link to video ACE: Link to video

Posted: 8/20/2015 7:07 PM
(Edited: 8/21/2015 2:43 PM)

Quote

MattyXB

Player (24)

Joined: 4/23/2005
Posts: 435
Location: Germany

Question, what means ACE? I read it here and don't understand it. Searched through this thread, found nothing. Only that it crash the game and the Endcredits rolls. But what means ACE? Edit: Thanks for the Info.

Last TAS finished: Final Fantasy Adventure (4.0 Warp Glitch Run) WIP in the moment: Tail Gator (GB) Matty

Posted: 8/20/2015 7:09 PM

Quote

Lil_Gecko

He/Him

Player (94)

Joined: 4/7/2011
Posts: 520

Arbitrary Code Execution.

Posted: 8/20/2015 7:10 PM

Quote

xy2_

Editor, Experienced player (818)

Joined: 5/2/2015
Posts: 671
Location: France

MattyXB wrote:

Question, what means ACE? I read it here and don't understand it. Searched through this thread, found nothing. Only that it crash the game and the Endcredits rolls. But what means ACE?

ACE means Arbritrary Code Execution, which is the feat of executing code within the game (usually to warp to the end credits). FF6 has a much 'minor' type of ACE compared to games like Super Mario World for example.

Youtube

Posted: 8/21/2015 8:06 PM

Quote

amaurea

Former player

Joined: 2/19/2007
Posts: 424
Location: UK

xy2_ wrote:

ACE means Arbritrary Code Execution, which is the feat of executing code within the game (usually to warp to the end credits). FF6 has a much 'minor' type of ACE compared to games like Super Mario World for example.

It's arbitrary code execution if you can execute whatever code you want. So how is the FF6 one more 'minor' than the one in SMW?

Posted: 8/22/2015 6:07 AM

Quote

OmnipotentEntity

He/Him

Player (36)

Joined: 9/11/2004
Posts: 2624

amaurea wrote:

xy2_ wrote:
ACE means Arbritrary Code Execution, which is the feat of executing code within the game (usually to warp to the end credits). FF6 has a much 'minor' type of ACE compared to games like Super Mario World for example.
It's arbitrary code execution if you can execute whatever code you want. So how is the FF6 one more 'minor' than the one in SMW?

If I understand what's going on: it's because only the FF6 internal scripting engine is subverted, not the underlying machine code. So you have arbitrary code execution within the context of the scripting engine, but you'd have to find a flaw in the scripting engine to break out of that sandbox.

Build a man a fire, warm him for a day, Set a man on fire, warm him for the rest of his life.

Posted: 8/22/2015 7:42 AM

Quote

keylie

He/Him

Editor, Emulator Coder, Expert player (2830)

Joined: 3/17/2013
Posts: 391

The recently published TAS has indeed total control over the scripting code of the game, but the second niconico video that I posted above (based on this post) is pure ACE (executing arbitrary assembly instructions).

Posted: 2/17/2016 5:22 AM

Quote

MarbleousDave

He/Him

Player (12)

Joined: 9/12/2009
Posts: 1555

Link to video Changes in pony hack includes some tweaks and bugfixes, so the vanish/doom trick no longer works. Also, longer dialogue, and bosses are tougher.

Posted: 4/11/2016 2:29 AM

Quote

thesabin

Joined: 4/11/2016
Posts: 3

Hi, I am currently studying and working on FFVI Sketch Glitch and I would like to know something regarding the Excel spreadsheet https://github.com/clementgallet/ff6-tas/blob/master/SketchGlitch.ods On Mold_3, I would like to understand how $3A8A $3A8D $3EBC can be understood. I kinda watched RAM values using Land Worm fight to see what happens to the values and it seems that if a 4 party battle, $3A8D is being set as "1111" and $3A8A is changing depending on who gets engulfed, and if all the party is Engulf'd, then the value $3A8A = $3A8D and the warp happens. I don't really understand how $3EBC effects the glitch. If someone could give me some tips regarding this I would appreciate it. Thanks.

Posted: 4/11/2016 9:45 AM

Quote

keylie

He/Him

Editor, Emulator Coder, Expert player (2830)

Joined: 3/17/2013
Posts: 391

Hey thesabin, I wrote a little description on the first tab regarding these addresses. You are right about the first two variables. For $3EBC, it is an address indicating how the fight ended (win, escape, gameover, engulfed, etc.) Bit 7 of $3EBC is set when the engulf conditions are met (all characters from the beginning of the battle engulfed, and at least one character engulfed). Then the game proceed based on this variable, meaning that if you set bit 7 of this variable, you will get engulfed even if you didn't meet the requirements. However, I didn't check if there were high priorities regarding this variable. For example, if the variable says you got killed and engulfed, which one of the two is processed first. If you need more details, I can do more investigation. This way of being engulfed was not retained in the TAS, so I didn't dig much.

Posted: 4/11/2016 4:34 PM

Quote

thesabin

Joined: 4/11/2016
Posts: 3

Thank you for your help. One last question, If the address $3EBC is set at 0 but $3A8A == $3A8D during the sketch, will the game write the Bit 7 on $3EBC that will allow the warp? I guess my question is if we simply ignore $3EBC and write 07 (0000 0111) both on $3A8A and $3A8D, will the warp work? Thanks.