Submission Text Full Submission Page

Skilled player (1705)
Joined: 9/17/2009
Posts: 4952
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
Spikestuff wrote:
jlun2 wrote:
Uh...this bug is getting irritating. Can anyone please upload a temp encode to youtube?
Free Encode for $9.95 Link to video
TY! Yes vote.
Site Admin, Skilled player (1235)
Joined: 4/17/2010
Posts: 11264
Location: RU
MESHUGGAH wrote:
In case you don't like game overs: http://tasvideos.org/userfiles/info/1454916043573621
The last ending titles appear at frame 4849. In the submitted movie - at 7698. 00:47.48. EDIT: note that all those glitched endings are not bugged. As you press start you go to the title screen as normally. EDIT2: MESHUGGAH, how the heck you did that???
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
MESHUGGAH
Other
Skilled player (1888)
Joined: 11/14/2009
Posts: 1349
Location: 𝔐𝔞𝔤𝑦𝔞𝔯
feos wrote:
MESHUGGAH wrote:
In case you don't like game overs: http://tasvideos.org/userfiles/info/1454916043573621
The last ending titles appear at frame 4849. In the submitted movie - at 7698. EDIT: note that all those glitched endings are not bugged. As you press start you go to the title screen as normally. EDIT2: MESHUGGAH, how the heck you did that???
When we tased it a year ago maybe, I made a list of the possible patterns and their possible positions. Different pattterns has different results on different positions. Let me somewhat explain the possibilities... imagine this as a frame by frame analysis. I will use the tas made by TheZlomus and DyLaX and frame numbers from TASEdtor to demonstrate: 1. The glitching part uses the memory, so everything you input before respawning (from the 1st frame of level 3 (2191) to the respawn (3469)). This means that just simply putting another input on P1 or P2 pad will lead to a different result (just like failing to reach the ending credits). 2. There are different positions of "controlling frames" (where you can manipulate the memory greatly) for P1 and P2 pad. P1: the first 3 frames (3474, 3475, 3476) P2: the first 2 frames and the 4th frame. (3474, 3475, 3477) 3. However, there's a trick to reuse these controlling frames by two method. The first one is using the ABSTUDLR (2^8 == 0xFF == 256) input on these controlling frames. The second method is using the pause (T) to "delay" the instruction you would normally do on an earlier controlling frame. Here's a simple example. You can "disable" the ongoing sprites by pressing L (2^1) on the 2nd controlling frame (3475) on the P2 pad. If you want to delay it (delaying leads to different results) you can pause the game on P2 pad 1st controlling frame (3474) and unpause on P1 pad on the 3rd frame (notice its not a controlling frame but since you paused the game it won't be increased (you will be using the *2nd controlling frame)) and press L (2^1) on the P2 pad. Like this: 3474 P1: - P2: T 3475 P1: - P2: - 3476 P1: T P2: TL Soooooooo..... using this two methods you can nearly do anything you want, just like skipping the game over, restarting the 3rd level (entirely, not just from the jets), changing different game logics, spawning items and stuffs... However, this isn't simple as pressing an input for a desired effects since this way you are corrupting the memory heavily. *edit: I wrote 1st instead of 2nd
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
AnS
Emulator Coder, Experienced player (723)
Joined: 2/23/2006
Posts: 682
So, MESHUGGAH, you didn't analyze the actual memory corruption principles but manipulated the best outcome by the trial and error method?
MESHUGGAH
Other
Skilled player (1888)
Joined: 11/14/2009
Posts: 1349
Location: 𝔐𝔞𝔤𝑦𝔞𝔯
AnS wrote:
So, MESHUGGAH, you didn't analyze the actual memory corruption principles but manipulated the best outcome by the trial and error method?
Well, mostly, I wrote out a few memory addresses and functions by debugging, however the patterns (values) and their positions are came by trial and error. I can dump the patterns and some positions but they are really get vastly different if you delay them using the simple pause or the reset trick (ABSTUDLR).
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Site Admin, Skilled player (1235)
Joined: 4/17/2010
Posts: 11264
Location: RU
Before reading I'm going to post the script that displays the CURRENT address object pointer loads object IDs from. It starts from $0B first frame after restart. It can be resetted if it gets $FF in the address it reads from. Note that the actual value it contains is what it reads from, but the object with this ID will be created NEXT FRAME. So you need to prepare the values you can affect. Okay. The pointer jumps over $B (length of object descriptors line) addresses for searching IDs. It gets 0 as initial value, because the checkpoint that changes the game logics is still unchecked, and after restart at the RACE it contains the value that it GIVES to object pointer. Getting 0, object pointer measures 11 steps off and sticks to $0B. Then every frame it jumps through $16, $21, $2C, $37 and normally stops rolling, because it thinks it created enough objects to start the level (see how it works for normal levels). $0B contains scene timer, or something like that. Objects with that low ID get removed as there are no such objects. Interesting thing here is that $16 contains TEMPORARY P2 input value, that gets read from $4017. After the frame ENDS it contains some different value it is actually used for. But reading objects occurs at the same time it contains whole P2 input! It will spawn any object equal to P2 input value. Then it reads from $21 and I don't know what it is. Second direct manipulation chanse is reading from $2C! It contains InputTap_P2 value, updates every frame. The way Zlomus worked is: 1. Nothing. 2. Spawn object when pointer sticks to $16. 3. Nothing. 4. Reset the pointer when it reads from ;2C. 5. Repeat from 1. Download BtObjects.lua
Language: lua

-- feos, 2012 -- Object IDs and atributes display script for NES Batletoads. -- Developed with 256x240 screen in mind. lastVal = 0 function info() CamX = memory.readbyte(0x87) + 256*memory.readbyte(0x88) CamY = memory.readbyte(0x89) + 256*memory.readbyte(0x8A) -- LevelCheckpointVal = memory.readbyte(0x585) ObjectPointerLo = memory.readbyte(0xB7) ObjectPointerHi = memory.readbyte(0xB8) newVal = ObjectPointerHi*0x100+ObjectPointerLo PointedAddr = memory.readbyte(lastVal) -- AAA = memory.readbyte(0x2a) CCC = memory.readbyte(0x2c) -- gui.box(0,0,256,40,"#000000ff") -- gui.text(130,231, "ChP: "..string.format("%02X",LevelCheckpointVal), "#00ff00ff") gui.text(95,17, string.format("Cur:%04X=%02X\nNew:%04X",lastVal,PointedAddr,newVal), "#00ff00ff") gui.text(200,17, string.format("2C=%02X",CCC), "#00ff00ff") gui.text(1, 1, "slot:\nid:") for i = 0, 14 do id = memory.readbyte(0x3c1+i) x = memory.readbyte(0x3FD+i) + 256*memory.readbytesigned(0x3EE +i) - CamX y = memory.readbyte(0x493+i) - memory.readbyte(0x475+i) xSH = memory.readbyte(0x484+i) ySH = memory.readbyte(0x493+i) move = memory.readbyte(0x4A2+i) state = memory.readbyte(0x4B1+i) hp = memory.readbyte(0x51a+i) linked = memory.readbyte(0x529+i) linker = memory.readbyte(0x538+i) dthTmr = memory.readbyte(0x574+i) follow = memory.readbyte(0x592+i) if id>0 then gui.text(x, y, string.format("%2X",id)) end if x<0>242 then x=242 end gui.text(1+i*16+18, 1, string.format("%2d\n%2X\n\n\n%2X",i+1,id,dthTmr)) -- gui.text(xSH,ySH,"Sh") end lastVal = newVal end emu.registerafter(info);
EDIT: Updated the post contents, also: RNG in this game rolls all the time CPU is free from other calculation. It mixes multiple values over and over, making direct manipulation impossible. BUT it gets more or less time to roll if you change INPUT, so you can only do trial & error, watching at how addresses $25-$28 change. The way to catch when it READS from these addresses to decide the enemies or game behaviour is in some future plans, but I dunno how to do it. EDIT2: Fixed the script again.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Editor, Experienced player (608)
Joined: 11/8/2010
Posts: 4012
Thanks for the temporary encode, Spikestuff! This was a good improvement over Marx's submission. Voting Yes.
Active player (250)
Joined: 7/30/2006
Posts: 207
Location: Alefgard, USA
Fun Fact: This video has 58 seconds of input. 21 of those seconds are just waiting to get to the title screen to start the game.
Skilled player (1705)
Joined: 9/17/2009
Posts: 4952
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
dave_dfwm wrote:
Fun Fact: This video has 58 seconds of input. 21 of those seconds are just waiting to get to the title screen to start the game.
Kinda reminds me of the Starfy TAS where 1/2 of the run is waiting at the main screen.
Player (12)
Joined: 6/17/2006
Posts: 498
AnS wrote:
To make the movie sync with any other FCEUX (except 2.1.5), authors of the movie should add 1 blank frame at the end of the movie, and then ask admins to replace the file.
Wait what? Why would the authors need to artificially add an extra input frame when it's just a matter of fixing a simple emulator bug?
AnS
Emulator Coder, Experienced player (723)
Joined: 2/23/2006
Posts: 682
SmashManiac wrote:
AnS wrote:
To make the movie sync with any other FCEUX (except 2.1.5), authors of the movie should add 1 blank frame at the end of the movie, and then ask admins to replace the file.
Wait what? Why would the authors need to artificially add an extra input frame when it's just a matter of fixing a simple emulator bug?
Well, until the bug was revealed, people had to do it without even knowing, and I'm not sure the conditions should change mid-frame war. Also, the fixed emulator will only be released in a month or so, and I thought it's important for a submission to sync with some released version, not just with SVN revision. If it's not necessary then I don't object.
Post subject: Information about!
Former player
Joined: 9/4/2012
Posts: 9
To call the end of the game, the game logic certainly needs to use initial function (and not just for that what I see). The feature you can found in the rom address: 0x91AC (but exist exceptions?). For this: https://feos-tas.googlecode.com/svn/trunk/DJ-stuff/Movies/bt_improve_ends.fm3 and for MESHUGGAH video, function launched "game end" in the level 3 instantly. Not exactly is known cause of this sudden call.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Note: I'm not going to be accepting an NES movie which requires a special unofficial FCEUX build, or requires special tricks to playback. AnS: If you're done fixing FCEUX, please see what you can do about getting an official release out. Authors: Please correct your game to complete the entire game on an official emulator, without needing anything special to run and complete it. When you're done improving, give me a link to your new file, and I will replace it. MESHUGGAH: If you want to frame war against the other two groups please make your own separate submission. If you want to join one of the groups, please let us know which group you're joining. Judges: I'm preclaiming all runs submitted in this iteration of frame wars.
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.
Post subject: Re: Information about!
Site Admin, Skilled player (1235)
Joined: 4/17/2010
Posts: 11264
Location: RU
TheZlomuS wrote:
To call the end of the game, the game logic certainly needs to use initial function (and not just for that what I see). The feature you can found in the rom address: 0x91AC (but exist exceptions?). For this: https://feos-tas.googlecode.com/svn/trunk/DJ-stuff/Movies/bt_improve_ends.fm3 and for MESHUGGAH video, function launched "game end" in the level 3 instantly. Not exactly is known cause of this sudden call.
Ending starts at frame 4826. Nach: Would you consider a movie as improvement, if it is slower by the amount of frames in the submission, but reaches the credits faster?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Post subject: Re: Information about!
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
Nach: Would you consider a movie as improvement, if it is slower by the amount of frames in the submission, but reaches the credits faster?
Recall the argument of the four ways to end a movie. I'd want to hear from the players and views of this particular game, and see which type of goal they prefer.
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.
MESHUGGAH
Other
Skilled player (1888)
Joined: 11/14/2009
Posts: 1349
Location: 𝔐𝔞𝔤𝑦𝔞𝔯
I just modified the glitching part to skip the boring part however you still have to wait some seconds. I don't belong to TheZlomuS and DyLaX's team so as long as I can't reduce it (being faster / shorter movie) I let them to use my file without adding me as a co-author. If I somehow reduce it, I will submit it with all the authors (feos, AnS, TheZlomuS and DyLaX).
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Site Admin, Skilled player (1235)
Joined: 4/17/2010
Posts: 11264
Location: RU
Count in BoneMage as well haha. Though now he lacks of time to disasm the ending event code, but I hope he will find it.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
AnS
Emulator Coder, Experienced player (723)
Joined: 2/23/2006
Posts: 682
Nach wrote:
AnS: If you're done fixing FCEUX, please see what you can do about getting an official release out.
The interim version of FCEUX 2.1.6 can be downloaded from the official site: http://www.fceux.com/web/download.html (http://www.fceux.com/zip for short) It's not the final release (more like RC), but the bug is fixed here.
Post subject: Re: Information about!
Player (12)
Joined: 6/17/2006
Posts: 498
Nach wrote:
feos wrote:
Nach: Would you consider a movie as improvement, if it is slower by the amount of frames in the submission, but reaches the credits faster?
Recall the argument of the four ways to end a movie. I'd want to hear from the players and views of this particular game, and see which type of goal they prefer.
In a perfect world, I would say that the time it takes to reach the end state is what matters first, and then ending input at a point where extra input cannot change this outcome second. In reality however defining what exactly is the end state is not trivial and testing for extra input is a NP problem. The only reliable way to measure the length of an arbitrary TAS is by the length of its input, even if it means delaying the actual game end. There has been multiple precedents of this (Monopoly just to name one), so I don't see why Battletoads should be judged differently.
Post subject: Re: Information about!
Site Admin, Skilled player (1235)
Joined: 4/17/2010
Posts: 11264
Location: RU
SmashManiac wrote:
In a perfect world, I would say that the time it takes to reach the end state is what matters first, and then ending input at a point where extra input cannot change this outcome second. In reality however defining what exactly is the end state is not trivial and testing for extra input is a NP problem. The only reliable way to measure the length of an arbitrary TAS is by the length of its input, even if it means delaying the actual game end. There has been multiple precedents of this (Monopoly just to name one), so I don't see why Battletoads should be judged differently.
Thread #11887: #3313: adelikat's NES Teenage Mutant Ninja Turtles in 16:26.23
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Active player (266)
Joined: 9/14/2011
Posts: 349
Once again, another part of someone's childhood has been demolished. Yes vote.
Emulator Coder, Skilled player (1141)
Joined: 5/1/2010
Posts: 1217
A version that has the extra frame at the end and syncs on 2.1.4a: http://dehacked.2y.net/microstorage.php/info/1389530568/3710S-compat.fm2
Post subject: Re: Information about!
Player (12)
Joined: 6/17/2006
Posts: 498
feos wrote:
SmashManiac wrote:
In a perfect world, I would say that the time it takes to reach the end state is what matters first, and then ending input at a point where extra input cannot change this outcome second. In reality however defining what exactly is the end state is not trivial and testing for extra input is a NP problem. The only reliable way to measure the length of an arbitrary TAS is by the length of its input, even if it means delaying the actual game end. There has been multiple precedents of this (Monopoly just to name one), so I don't see why Battletoads should be judged differently.
Thread #11887: #3313: adelikat's NES Teenage Mutant Ninja Turtles in 16:26.23
Ah, I had completely forgotten about that submission. So there has been precedent for both cases then. My opinion doesn't change however: while a quicker game ending is always better in theory for me, measuring it is not trivial in the general case unlike input length and this will inevitably lead to conflicting goals in some runs, including this one potentially.
Site Admin, Skilled player (1235)
Joined: 4/17/2010
Posts: 11264
Location: RU
Events of this movie.
  • Pointer sticks to some line (likely starting at $B7) that looks like 00, 00, 00, 00, $C8... It creates an object with ID=0, and with Xpos=$C8.
  • To determine the slot to create it in, game checks if this ID<3. If it is, game thinks it is a player. Players are tied to slots 0 (for ID=1) and 1 (for ID=2). If ID<3, the game subtracts 1 from the ID, and thinks it is a slot. So, it subtracts 1 from 0 and gets $FF, that will be the slot (offset for all atributes of this object).
  • The game checks if the lives ($11)>0, because if lives<0, it won't spawn. Shifting $FF off $11, it checks adderss $110 as it is lives.
  • Then the value, that was read as Xpos from configs, gets written to Xpos address, considering it is slot $FF (shifting $FF from Rash's Xpos address). There it gets address of the Rash's Hit ID. But there's NO ANIMATION for that hit ID, there's no pointer. Line 3438.
  • $2207 gets read as it is the pointer for that hit ID, and it contains #$FE. Bitwise AND between #$FE and #$1F occurs,to determine the needed animation code, but the resulting value is bigger that $16 (amount of pointers).
  • Game jums to arbitrary address $75BD. $6000-$7FFF = Battery Backed Save or Work RAM. It is all filled with $6F and is an undefined code. So the game just rolls through all this area and then gets to $8000.
  • Line 4705.
Thanks to BoneMage.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
AnS
Emulator Coder, Experienced player (723)
Joined: 2/23/2006
Posts: 682
feos wrote:
[*] Game jums to arbitrary address $75BD. $6000-$7FFF = Battery Backed Save or Work RAM. It is all filled with $6F and is an undefined code. So the game just rolls through all this area and then gets to $8000.
The scary thing is, Battletoads don't have any Battery Backed Save or Work RAM. So what's happening there is called "reading from open bus", and is not a regular situation. Usually it returns the last bits that were on the bus due to the capacitance of the bus, in this case it's the high byte of the address (0x75) and then the last byte read from $75 (at zero page), which is fortunately not a #00 (BRK) at the moment, but some undefined opcode (#6F) which lets the CPU eventually proceed to a sane code. The more we dig into the bug, the less we are aware of the range of its possibilities.