As it will happen eventually, destroying all my previous work for this game, have fun watching even less of this game.
Game objectives
Emulator used: lsnes rr2-β21
Aims for fastest time
Uses game-breaking glitches
Achieves credits early
Comments
Go ahead and watch the TAS first, it doesn't really take that long.
This is basically the reason why I cancelled the Kirby Super Star submission. You can maybe see why I prefer the previous movie over this one. But first...
What happens this time?
Let's start at the basics. In SMW there are sprites which can change the status of Mario called powerups (such as mushrooms, flowers, stars and so on). It's easy enough for the game to just run a routine to change it as soon as Mario touches a sprite which is listed as a powerup. Now the problem comes when Yoshi eats a sprite, because if it is a powerup, it should be applied to Mario. The game checks if the sprite has a specific property that says the game if it should give Mario a powerup when it is being eaten. Interestingly enough, chucks have this property! Normally, this isn't a problem because you can't actually eat chucks because they have another property which ensures that the sprite won't be caught by Yoshi's tongue (it goes right through), making it impossible to get it on Yoshi's tongue and eat it... or is it?
Item Swap
This glitch is also used in the warps run in YI2 to get the goal tape to replace the shell on Yoshi's tongue, getting the level end earlier or in YI1 to replace a sprite on Yoshi's tongue with a chuck so that Yoshi can... eat it!
This is what I'm doing, too. I replace a sprite on Yoshi's tongue with a chuck. How do I do that? Well, it is possible to get a coin by touching it, but it is also possible to get a coin on Yoshi's tongue. Now just do both things at the same time (see pictures on the right) and Yoshi's tongue will hold a nonexistent sprite or simply nothing. All the game now knows is that Yoshi's tongue holds a sprite in a specific slot and if in that moment a sprite such as a chuck wants to spawn in that slot, its position will be overwritten since it's now on Yoshi's tongue. Yoshi is now able to eat the chuck which is apparently a powerup to the game.
Eating a chuck
Since the chuck powerup isn't intended by the developers and accidentally in the game, the code doesn't account for it and incorrectly indexes the sprite to put in the item box (which is a lakitu cloud) and also gets the subroutine location wrong to jump afterwards. Instead of jumping to a routine to change Mario's status, it jumps to $014A13... which is Open Bus.
Open Bus
Open Bus is an area in the SNES which isn't mapped to a location like WRAM or ROM, which means no such device answers the request from the console to get the next instruction to execute. This means that the console will just execute whatever value was the last one on data bus.
The code just jumped to $014A13 so the last value on data bus is 0x01.
data bus
instruction
information
0x01
ORA ($01,x)
X is 0x09, $0A holds 0x0107, $0107 holds 0x17, A turns to 0x17 and data bus is 0x17
0x17
ORA ($17),Y
$17 is interesting because $17 and $18 are SMW's controller data, so this is where I can kinda manipulate the outcome
This is the reason why I pressed X and the next frame AXL just before the glitch started so that $17 is 0xE0 and $18 is 0xA0. The code manages to change the SNES to emulation mode so now it can survive BRKs easily, as the vector changed. Then it managed to reach $4219 which are controller registers.
Controller Registers
These are the last 5 frames of input:
1-1 1-2 2-1 2-2
F. 0 0|....u.l.AXL.....|BY..u.lr...R....|.Ys..d..AXLR0.23|................
F. 0 0|...Su...A.L.0..3|BY..u.lr...R....|.Ys..d..AX.R0...|BYsSu...A.......
F. 0 0|..sSud.rA....123|BY..u.lr...R....|.Ys..d......0.23|BYsSu...A.......
F. 0 0|....u...A.L.0..3|BY..u.lr...R....|.Ys..d..A.L.0.23|BYsSu...A.......
F. 0 0|BY...dl.A...01.3|B........XLR..2.|..s........R..23|BYsSu...A.......
One thing to notice is that "64 10 CB" and "80 F8" occur often. "64 10 CB" is executed as STZ $10 : WAI which STores Zero to $10 and then WAits for an Interrupt. That effectively advances one frame and lets Auto-Joypad Read finish so that we have new input. Then it executes "80 F8" of the next frame (which is why there isn't one in the first frame). "80 F8" means BRA $F8 or BRAnch -8 bytes (or simply 8 bytes back), so we reach $4218 once again and can execute more code.
(The 0xE0 in the first frame isn't actually executed since we start at $4219, which is good because we needed that for the Open Bus part)
byte
instruction
information
0A
ASL A
used for clearing carry
FB
XCE
to recover to native mode after emulation mode to safely let NMI execute
A9 18
LDA #$18
load 0x18 into A for the game mode later
D8
CLD
clear decimal mode flag to avoid the game getting confused with calculations
87 3D
STA ($3D)
store A to whatever long address is in $3D, which happens to be $000100 which is the game mode
0B
PHD
push direct page register so that I have 00's on the stack for later
A9 08
LDA #$08
load 0x08 into A for $13C6 later
AB
PLB
pull data bank which is now 00 thanks to the PHD before
8D C6 13
STA $13C6
store A to $13C6 to complete all necessary steps
20 72 80
JSR $8072
jump to the main game routine and free the game from any further gameplay
Are we at the point where we need to remake the replay specs to specify you must use a controller and have a specific category if you're just pumping polls into the controller port?
"The guy was fatally injured and wants to be covered by God's tears (rain) before he dies. God is too busy to bother because it wastes frames."
Frames 16:26
Are we at the point where we need to remake the replay specs to specify you must use a controller and have a specific category if you're just pumping polls into the controller port?
No.
Replay _is_ a controller. (It's just a shift register for NES/SNES, and straight lines and a mux for Genesis, so very easy to emulate). With my implementation, timings aren't as fast as the original chips, but they are fast enough that the console wouldn't know the difference anyway. You could argue perhaps that some SNES runs that use the 4 extra lines isn't being a controller but I still believe it is - it's either a controller with 16 buttons or a modified controller, and in this latter case verification isn't the task that should be questioned.
We'll be at this point when we start acting not like a controller and getting usable or different results.
Why is this not an issue? Because the run would verify exactly the same either way. Verification isn't an exercise in creativity. It's a very specific task with a specific end result. If the expected end result is reached, then it was a success, and it wouldn't matter if I used a controller or direct wire. Importantly, verified runs are not modified from the original replay data. If they were modified, this might be worth looking at - but then again, they wouldn't be verified against the videos hosted here, would they?
It would be possible to make an intermediary device to press buttons on an actual controller, but that is the mechanical engineering realm which is something I don't know about.
The Replay is not a controller, it is a device that sends electrical impulses to the SNES. And if you were conveying controls that aren't possible via button press on stock hardware, then you are not console verifying.
I'm fine with these runs existing, and even saying they work on a real console with the device, but we're getting to the point where we need to specify and separate runs that cannot be achieved using the real buttons on stock hardware.
Also, do we have any Gameboy console verifications? All you'd need to do is solder in the button leads, right?
"The guy was fatally injured and wants to be covered by God's tears (rain) before he dies. God is too busy to bother because it wastes frames."
Frames 16:26
No, that's a definition of a controller. The definition of an SNES controller is different. We're console verifying the run, we need to use the stock controller that that console uses. Emulating signals of buttons you can press instead of pressing the mechanical buttons is fine, but sending raw signals down the pipe and pretending it's a legitimate console verification is stretching it.
Like I said, I'm all for separate categories. I'm not saying we should delete or stop making these runs, we just need to make a separate category that defines that the run was made using only signals a stock SNES controller could produce by pressing it's buttons.
Wire up leads to the button switches on the SNES controller and send signals that way if you aren't sure.
"The guy was fatally injured and wants to be covered by God's tears (rain) before he dies. God is too busy to bother because it wastes frames."
Frames 16:26
The Replay is not a controller, it is a device that sends electrical impulses to the SNES.
Congratulations, you just described a controller.
xnamkcor wrote:
No, that's a definition of a controller. The definition of an SNES controller is different.
No, you don't understand definitions. You are retarded.
xnamkcor wrote:
And if you were conveying controls that aren't possible via button press on stock hardware, then you are not console verifying.
No, that's not what I was saying. What I was saying is that of the runs I have verified, every single one could be verified with a stock controller. I'll happily make it work with my device if you can make the mechanical construct to press the buttons. But, honestly, it's wholly unnecessary. The result is exactly the same - the console plays back the video and we get the expected result. A brief look on an oscilloscope between an original controller and my device would prove this. A brief look at a fucking verification video actually playing through would prove this. How could you say at this point that the expected result is NOT possible on console? It clearly is. Emulators are good enough for this now. Whether the input is a membrane switch, an output pin to an SR, or an output directly emulating Q7 doesn't matter one bit.
xnamkcor wrote:
I'm fine with these runs existing
Congrats. Glad you're fine with it.
xnamkcor wrote:
and even saying they work on a real console with the device, but we're getting to the point where we need to specify and separate runs that cannot be achieved using the real buttons on stock hardware.
It's simple - those that currently can't be verified with my device also could not be verified with my device pressing buttons on a stock controller. There is no difference. And just because something can't be verified with my device, doesn't mean it's not an implementation flaw, or an emulator bug, or uninitialized memory (different starting conditions) or.... In other words, it may be possible still, so marking something as "unverifiable" would not be a good idea.
In short, you are ignorant of the details regarding verification. I know the information is scattered and sometimes hard to find, but communicate with us, search, read (not just verification stuff but technical documents about these consoles) and learn rather than posting pointless drivel. Or don't and I'll just ignore you from this point forward. Thanks.
xnamkcor wrote:
We're console verifying the run, we need to use the stock controller that that console uses.
You are and idiot ;-)
xnamkcor wrote:
Also, do we have any Gameboy console verifications? All you'd need to do is solder in the button leads, right?
Yeah. It'll just magically play by itself.
I can tell you for sure we don't need an input dumper script or firmware for the device to play back Gameboy. Don't try working on these two things, it's not needed.
Additionally this doesn't "press buttons" per your super secret specification. Your retardation can't even be consistent.
xnamkcor wrote:
Wire up leads to the button switches on the SNES controller and send signals that way if you aren't sure.
I seriously fucking LOL'd. This isn't what you have been arguing all this time. Also, this is exactly what GhostSonic's shit does except without a controller in the way. Do you know what a shift register is? I guess you don't.
You are not qualified to argue this issue. You don't know what you are talking about.
We're console verifying the run, we need to use the stock controller that that console uses.
The 10-year practice of pressing opposite directions during TASing kind of disagrees with you.
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.
Joined: 8/14/2009
Posts: 4083
Location: The Netherlands
feos wrote:
xnamkcor wrote:
We're console verifying the run, we need to use the stock controller that that console uses.
The 10-year practice of pressing opposite directions during TASing kind of disagrees with you.
Which can be done on stock controllers for quite a few consoles, SNES included.
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.
Which can be done on stock controllers that consoles use.
Specify the range please. AFAIK NES or SNES regular ones don't allow 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.
Joined: 8/14/2009
Posts: 4083
Location: The Netherlands
feos wrote:
Mothrayas wrote:
Which can be done on stock controllers that consoles use.
Specify the range please. AFAIK NES or SNES regular ones don't allow that.
I've lost count of the amount of times I've linked to this video:
Link to video
Fairly sure it's possible for NES controllers too, perhaps with a little wear.
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.
Tell that it was an official feature and I'll agree with you.
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.
Joined: 8/14/2009
Posts: 4083
Location: The Netherlands
feos wrote:
Tell that it was an official feature and I'll agree with you.
Does that matter?
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.
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.
Joined: 8/14/2009
Posts: 4083
Location: The Netherlands
Please do cite specifications that says pressing left and right or up and down on a controller must be mutually exclusive actions.
Also, even if you can prove that, what meaning does it have? I don't even see how it's relevant. The point is it can be done. In fact, this is a whole site dedicated to breaking rules because it can be done. What's next, we should reject and unpublish arbitrary execution runs because programming the game isn't an official feature?
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.
Please do cite specifications that says pressing left and right or up and down on a controller must be mutually exclusive actions.
"The guy was fatally injured and wants to be covered by God's tears (rain) before he dies. God is too busy to bother because it wastes frames."
Frames 16:26
Joined: 8/14/2009
Posts: 4083
Location: The Netherlands
That doesn't look like a very robust argument to me, considering it still resulted to the above video.
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.
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.
That doesn't look like a very robust argument to me, considering it still resulted to the above video.
The that thing in the middle doesn't look like such an argument for you, I don't know what does.
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.
We're console verifying the run, we need to use the stock controller that that console uses.
The 10-year practice of pressing opposite directions during TASing kind of disagrees with you.
You imply that left+right is not legitimate input on a "stock controller" of a SNES console.
Otherwise, I still don't get why you brought this up in the first place.
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.
And if you disagree with someone, just call them an idiot.
"The guy was fatally injured and wants to be covered by God's tears (rain) before he dies. God is too busy to bother because it wastes frames."
Frames 16:26
We're console verifying the run, we need to use the stock controller that that console uses.
The 10-year practice of pressing opposite directions during TASing kind of disagrees with you.
You imply that left+right is not legitimate input on a "stock controller" of a SNES console.
Otherwise, I still don't get why you brought this up in the first place.
I never brought up Left+Right. They did.
"The guy was fatally injured and wants to be covered by God's tears (rain) before he dies. God is too busy to bother because it wastes frames."
Frames 16:26
You imply that left+right is not legitimate input on a "stock controller" of a SNES console.
I was saying that it's not designed as a feature.
Mothrayas wrote:
Otherwise, I still don't get why you brought this up in the first place.
We use that technique no matter what for 10 years now, which should make it a borderline for the guy who wants stock controllers for verification. Either he considers the site's approach illegal, or agrees to stretch his views.
xnamkcor: read the post I linked there, the one that JXQ (does he need an introduction?) called "very well-written".
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.
You imply that left+right is not legitimate input on a "stock controller" of a SNES console.
I was saying that it's not designed as a feature.
Mothrayas wrote:
Otherwise, I still don't get why you brought this up in the first place.
We use that technique no matter what for 10 years now, which should make it a borderline for the guy who wants stock controllers for verification. Either he considers the very approach illegal, or agrees to stretch his views.
xnamkcor: read the post I linked there, the one that JXQ (does he need an introduction?) called "very well-written".
The one with Left+Right? I'm perfectly fine with Left+Right.
"The guy was fatally injured and wants to be covered by God's tears (rain) before he dies. God is too busy to bother because it wastes frames."
Frames 16:26
