If I take the koopa shell to the breakable blocks with a koopa on them, and spinjump through the whole thing, I get a lot of lag and many results, but I haven't seen A201 (or is it 4201 , I don't know).
It's 4067 that we're looking for, however there are a few other addresses that work:
I have confirmed that 405B-406A lead to A201 execution, however only 4067-406A will not crash game after code at A201 is executed. (It seems like 4067 is the most common of these addresses, but it's good to be aware of the others. For our run we should focus on 4067-6A, but for a total control hack the earlier addresses will work too.)
If it's not too much trouble, I suggest you try making a test run, just entering the first level without optimizing your movement but still going at a steady pace. If you then manage to do 'something' in the testrun, then I can make an optimized VBM. Ok?
Okay, I'll work on that. Do you mean like an actual exploitation of the glitch (like by a bot)? I'm not sure if I did something like that it'd be optimizable - since the return address of the glitch is heavily timing dependent.
Also probably a stupid question, but how do I record over a vbm I've already saved? I've only been able to re-record using savestates, but once I save the movie I'm not able to record any more. Not sure what I've been doing wrong.
Okay, I'll work on that. Do you mean like an actual exploitation of the glitch (like by a bot)? I'm not sure if I did something like that it'd be optimizable - since the return address of the glitch is heavily timing dependent.
Also probably a stupid question, but how do I record over a vbm I've already saved? I've only been able to re-record using savestates, but once I save the movie I'm not able to record any more. Not sure what I've been doing wrong.
I dunno. I just think we should confirm that the glitch even works - within the game's bounds.
To record over a vbm, you need to be aware of read-only and read+write mode. You can switch between the two via hotkey. Read-only will be so you are only watching the VBM play back, and you can load only savestates that are from the VBM. *
If you are in Read+write mode, loading a savestate will make it so that you record input from that point onwards, provided that that state is from the VBM.
______
* There was a glitch in VBA that would make it so that it records from the current point if you load a state that's not from the movie. I don't know if it's been fixed, but you might want to make backups of your VBMs.
I wanted to make an enemy display so I wrote one with my poor lua skills. Still in progress but I'm not sure if I'll finish it.
todo:
*make it so it recognizes enemies even for IDs which are shared by multiple enemies.
*Make the display "better" (at best, it would remember on which side sprites go offscreen. Cause currently it will warp to the right side when going offscreen on the left).
*make it so things dont overlap
http://pastebin.com/Ukyhqypr
I want to make a correction to one of Spikeman's posts.
One final note: an alternative to setting A2D5 is setting FFB9 FF9B to 12,13, or 23 -- this will skip to the credits directly without having to die first. 13 hits the cutscene two frames before 23 and one frame before 12 - although I'm not sure that matters if last input is how movie length is counted.)
So it's been a while. People managed to run arbitrary code to go to the credits in SMB3 by jumping inside an out-of-bounds glitch tile. And so I was interested to see if I could manage to do anything in SML2, but I'm just an amateur with this CPU instruction stuff...
Anyway, this movie (SML2 (U) [!] (v1.0) VBA 24m svn3xx) performs the pause glitch at frame 12554. The "return address" would be 4067 which means that code at address A201 would be executed. At that very moment in the movie, A201 onwards would read:
My question is where does the code execution end? Is it at the first '10' (STOP)?
If I edit the first bytes to be 08 D5 A2 or EA D5 A2 then it will change address A2D5 to nonzero which means that revisiting a level will trigger the ending. But if I write those hex strings anywhere later, or into the 'FF's, then the game crashes... If I write the hex string into the '00's after the 'FF's, and remove the '10', then it does still not affect A2D5, and I don't understand why. ( I think the string would work in A201~A205 but not anywhere else, and sadly that part of memory is almost impossible to change into something meaningful)
Actually, I found out that the values in addresses A203~A205 may be possible to manipulate to our desires.
A203 is dependent on Mario's X position in the level and can become "EA". At the end of the first level, Mario has to be on the left side of the staircase facing right. Or he has to be on the right side of the staircase and face left. Alternatively, be near the beginning of the level for it to spell out "08" This could be a problem because those areas might not yield "return address" 4067 easily. I would need to bring two koopa shells and try.
A204 is dependent on Mario's Y position in the level. It becomes "D4" when Mario is standing on the lowest ground. This might be good enough because affecting A2D4 sometimes affects A2D5 too (I need to test again). Otherwise, even if I entered the ground (I don't know if it's possible) it would prevent creating lag and performing the pause glitch a lot...
A205 depends on what block or coin you touched (depends on its position?). Needs testing but should be possible to make it spell "A2". Even if no breakable block corresponds to A2, I could make one appear in the right position using "pause glitch".
With more testing and some luck I could spell out
EA D4 A2
or
08 D4 A2
Hopefully it would affect A2D5 and hit a STOP before crashing.
andymac wrote:
08 D5 A2 (assuming SP !=0)
EA D5 A2 (assuming the register A != 0 )
02 (assuming BC = D5 A2)
12 (assuming DE = D5 A2)
EDIT: It looks like A205 may be not be possible to change into "A2". It changes into odd numbers when blocks are hit, and can only change into even numbers when touching coins from a certain side. And no coins are located at where it can change to A2.
Sorry but I have bad news. Like my edit in my last post said, you can't easily make A205 into "A2". I made test attempts when I thought my code was fine with 08 D4 2A (instead of 08 D4 A2)...
The above movie performs the glitch and gets return address 4067. I'm not sure if it executes any code at A201.. and then it resets.. After figuring out that my code was wrong, I researched what level I could visit that have "A2 coins":
http://i.imgur.com/Vs7iY3r.pnghttp://i.imgur.com/8Gx2Qms.pnghttp://i.imgur.com/kmfjr89.png
So in order to run the code, you have to visit one of those levels, touch the coin from a certain side and then go to the place that makes the other two addresses become 08 D4 or EA D4. Create lag and do the pause glitch. This will take 1.5 minutes which means the TAS wouldn't be improved by much..
Alternatively, you could still try to run some other code and hope to achieve something. After all, I changed level data in one of my VBMs, and that could be used to get a A2 coin. Or idk...
---
EDIT: I think that it will be possible to execute the code. But the setup takes way too long. So I was thinking that I try different code: C3 'a16'
When I use this to jump to the ROM ($0000~$7fff) weird stuff happens sometimes. Maybe I can find an address that will trigger the credits with this.
So, like the edit in my last post says, you could possibly execute code that would write to A2D5 but it would require you to finish the first level, go to a level that has a coin in a right place so touching that coin would get an address to read 'A2', and then you would have to go to another level and perform the lag glitch in the correct x position in the level. This takes way too long to do or at least it would save not more than 5 seconds over the current TAS...
I had a better idea yesterday:
On version 1.0, on the title screen you can press a button combination to go to a level. This probably was a feature that was used by the developers to create the demos that play when you wait at the title screen too long and they forgot to remove it.
Up + Select: Mushroom level demo
Up + A + Select: Hippo level demo
Up + B + Select: Turtle Zone level demo
Up + A + B + Select: Macro Zone level demo
As you play the level, the music is muted and the game will save your input in SRAM. When all input slots are used up, it freezes and you have to reset. With those input slots you could write out:
08 D5 A2
or
AE D5 A2
---
http://i.imgur.com/sM1KCXc.pngThe first address in a slot states how long you waited doing nothing, the second tells what input you pressed, and the third tells how long you pressed it. So you would wait 8 or 174 frames and press "^v>As" for 162 frames.
EDIT: Please note that the way I labeled the bytes seems to be wrong. It is really like this: 1 byte for the button combination, and 1 byte for how long you pressed it. Doesn't change the fact that you can write up a program in 0xA300 onwards.
---
Then you try to do the pause glitch with the addresses A203~A205 reading a code that jumps to the code that we just wrote. Unfortunately I don't really know how or if that would work.
According to this, it seems that I want A203-A205 to read something like this:
C3 <address where we wrote our code>
I would love it if somebody helped me with this
EDIT:
Another image, describing the idea that I had:
I edited values manually for testing purposes. And the game would execute A201~ over and over and over and never stop. I don't understand why.
If I don't put in C3 00 A3, it executes whatever code was there originally and stops at C0 (RET NZ, which I don't know what it means to be honest...). If I put a C0 or other RETURNs at, say, A303, it doesn't prevent the game from getting stuck in an infinite loop.
Again, I hope someone can help me because I will not be able to get it to work by myself...
It looks like I managed to make it work, but I'm not sure.
The "jump to where PC left off" sometimes doesn't seem to work...
And I need to confirm / find a way to make the initial jump to A300~onwards work. I will attempt a testrun later
This is again with manually edited values for testing - in this particular image, it triggers the credits on the next frame successfully.
There is one thing to think about: Since we use the title screen demo to write a program, and it eventually freezes when all input slots are used up, we should try to prevent that freeze from happening.
EDIT: It seems this strategy is completely useless because Pause glitch doesn't seem to work while in demo mode.
As my last edit says, you can't pause glitch in demo mode so my idea was useless.
I was trial-and-erroring around more today and this is what I found:
I was looking if any addresses spell "9b ff" or "d5 a2" so jumping to those could perform operations with the two addresses.
0x7101 = ef 9b ff
0xaa36 = 56 9b ff (varies)
0x05c1 = fa d5 a2
But it didn't help.
By trying around, I found that if certain code is executed via pause glitch, you can get stuff to happen such as gameover or end credits.
c34c0a -> gameover
c3c805 -> 9bff set but frozen
c4c805 c3c354 -> 9bff set but keeps fading screen (softlock)
c4c804 c3c354 -> level finish
c4c803 c3c354 -> credits
c47883 c3c354 -> level data changed
c46883 c3c354 -> level data changed
It may be possible to spell out c4c803 in 0xa201 onward. In that case it would set 0x9bff to 12 but reset itself subsequently.
EDIT:
It seems that C4 ZZ 03 YY, where ZZ is anything between C0~C9 and where YY is an additional value (EF or 5E or other) triggers credits, using only 4 bytes of code.
Goal was to set a203~a205 to C4 CZ 03, where Z is 0,1,2,3,4,5,6,7,8 or 9.
In order to set a203 to "C4" you (actually, the camera) have to be in a certain Xposition in a level.
In order to set a205 to "03" you have to touch a coin in a certain location from above.
The first level doesn't have such a coin.
The hippo level doesn't let you reach position C4.
Tree Zone 1 doesn't have such a coin.
Macro Zone 1 is untested. Probably you won't be able to reach Ypos C0~C9 in a204 in this level though.
Pumpkin Zone 1 doesn't let you reach position C4(?)
Mario Zone 1 doesn't let you reach position C4(?)
Turtle Zone 1 is untested.
I tested in Pumpkin Zone 2:
http://dehacked.2y.net/microstorage.php/info/1645084574/sml2testtas.vbm VBA24m Super Mario Land v1.0 EU
This will set FF9B to 12 (i.e. end credits are triggered) at frame ~12050. It also executed until at least a20d and reset itself. My hope is that it will execute something that will prevent the reset/freeze...
This is the lua script I use btw
http://pastebin.com/vejgycXj
"C4 CZ 03" was kind of a stupid destination address because you cannot set $a205 to "03" easily (you have to go through 3 levels to do so). So I went and tried to find other destination addresses. Turns out that "CD CZ 05" will set FFB9 to 23 which also triggers the credits. And we can set $a205 to "05" in the first level. Now we just need to prevent the game from freezing after executing these 3 bytes. With C4 CZ 03, sometimes "EF" or "5E" worked. Sometimes a C3 jump to somewhere works...
http://dehacked.2y.net/microstorage.php/info/191381586/sml2level1ACETAS.vbm VBA24m Super Mario Land v1.0 EU
This executes CD C4 05 and sets FF9B to 23, but then resets.
I deleted a post I made yesterday because it didn't contain new information. Here is new information though:
I found that instead of
CX YY ZZ
where X = 2,3,4
where YY = D4,C4 or similar
where ZZ = 03,05
You can execute
21 YY ZZ E9
which will load the desired address to HL and then jump to HL.
I don't know if this is useful yet. I want to look at some other possibilities, too.
$a203 is actually the offset for the level graphics. Using pause glitch, you can mess up the level graphics rendering and freeze this address at the cost of the time it takes to pause every few frames.
The idea is to run until $a203 reads "21", then freeze this value until the underground room and collect the coin there to make $a205 read "05" (it hasn't been confirmed if this strategy works, yet). $a204 would read "D4" or "C4" regardless what happens. So you end up with the code I suggested in my previous post:
21 C4 05 (...)
The goal now is to stumble across an address that reads "E9" to jump to (HL). $a229 depends on Mario's x position and can read "E9" every 256 pixels. The only challenge would be for the ACE to reach this address and not kill the game in the process.
If this works out I can see 20 sec saved.
---
EDIT:
I have tested this on three occasions and the game would never survive. Not even on the vbm of the published TAS.
I verified the pause glitch also works on Bizhawk (gambatte core). $A201 onward are executed on rare occasion when doing the bug, and depending on the values of those addresses, various things can happen, as was the case in VBA.
I didn't manage to do the credit warp by editing memory to C4 C3 05 ... C0 though. I only did manage to leave the level early by C4 BC 05 ... C0.
This could be because of the glitch being stubborn or because of emulation differences, I don't know. I tried with five different scenarios and it barely works. I remember the bug was more compliant in VBA.
I apologize if this has already been discussed, but there might be a small time save in the wario battle. right as wario leaves the screen, you're able to scroll the screen and continue to the next room. the TASes for this game have mario getting up to speed to go to the next room, however I thought about maybe trying to get mario to top speed before the screen can scroll. I made a short demonstration of what that would look like (was done better in the 2nd time trying to do this):
Link to video
(i apologize for the bad sound, was recorded with obs)
only problem with this is when wario moves off screen, it causes mario to halt, however doing a jump when that happens seems to prevent your speed from changing, that means you most likely would have to be on a higher level when going to the next room.
and the other problem is having to hit the wall in the loading zone, but that maybe could be avoided by jumping after the screen scrolls.
again, not sure if this has been mentioned before so I apologize for not looking into discussion for it.
Edit: should also mention that this same method is used in a different game as well: DecapAttack
(example is at 1:59 if you cant get time stamps)
Link to video
after every boss battle, the player get's to maximum speed and hits the edge of the screen as soon as the game allows him to continue.
[14:15] <feos> WinDOES what DOSn't
12:33:44 PM <Mothrayas> "I got an oof with my game!"
Mothrayas Today at 12:22: <Colin> thank you for supporting noble causes such as my feet
MemoryTAS Today at 11:55 AM: you wouldn't know beauty if it slapped you in the face with a giant fish
[Today at 4:51 PM] Mothrayas: although if you like your own tweets that's the online equivalent of sniffing your own farts and probably tells a lot about you as a person
MemoryTAS Today at 7:01 PM: But I exert big staff energy honestly lol
Samsara Today at 1:20 PM: wouldn't ACE in a real life TAS just stand for Actually Cease Existing
I verified the pause glitch also works on Bizhawk (gambatte core). $A201 onward are executed on rare occasion when doing the bug, and depending on the values of those addresses, various things can happen, as was the case in VBA.
I didn't manage to do the credit warp by editing memory to C4 C3 05 ... C0 though. I only did manage to leave the level early by C4 BC 05 ... C0.
This could be because of the glitch being stubborn or because of emulation differences, I don't know. I tried with five different scenarios and it barely works. I remember the bug was more compliant in VBA.
MUGG, do you still have a bk2 of this? I'm interested in seeing if this can be made to work now that there is a fairly robust console verification pipeline available.
I verified the pause glitch also works on Bizhawk (gambatte core). $A201 onward are executed on rare occasion when doing the bug, and depending on the values of those addresses, various things can happen, as was the case in VBA.
I didn't manage to do the credit warp by editing memory to C4 C3 05 ... C0 though. I only did manage to leave the level early by C4 BC 05 ... C0.
This could be because of the glitch being stubborn or because of emulation differences, I don't know. I tried with five different scenarios and it barely works. I remember the bug was more compliant in VBA.
MUGG, do you still have a bk2 of this? I'm interested in seeing if this can be made to work now that there is a fairly robust console verification pipeline available.
The question isn't if I "still" have it but if I "ever" had one. Everything I ever did was on standalone VBA-rr. Pause bug does happen on Bizhawk-Gambatte, but I can't remember the ACE bug to happen in my testing. I had tested for 1-2 hours and it should have happened in that time span at least once...
Here is a lua that might help, but I can't confirm if it works.
Language: Lua
memory.usememorydomain("System Bus")
local dbg=false
local CurrentBank = memory.read_u8(0xA24E)
local StartBank = nil
local ReturnAddress = nil
local Unpause = 0
local vblank = function()
StartBank = CurrentBank
ReturnAddress = memory.read_u16_le(emu.getregister("sp"))
if dbg then
print("== VBLANK ==")
print("start bank: "..CurrentBank)
print("return addr: "..string.format("%X",ReturnAddress))
end
end
local vblank_done = function()
if dbg then
print("end bank: " ..CurrentBank)
end
if ReturnAddress >= 0x4000 and StartBank ~= CurrentBank then
print("*** GLITCH - " .. string.format("%X",ReturnAddress) .. " ***")
gui.drawText(4,2,"glitch! return addr: " .. string.format("%X",ReturnAddress),0xFF00FF00)
client.pause()
end
end
local A201_executed = function()
print("A201 executed !!")
gui.drawText(2,12,"!! A201 executed !!",0xFFFFFF00)
client.pause()
end
local writeBank = function()
CurrentBank = emu.getregister("a")
end
event.onmemoryexecute(vblank, 0x0154)
event.onmemoryexecute(vblank_done, 0x01E4)
event.onmemoryexecute(A201_executed, 0xA201)
while true do
emu.frameadvance()
end
Ah, thank you that script did help in finding proper frames.
With it I was able to get a game end glitch:
http://tasvideos.org/userfiles/info/47098069959194767
It works in both gambatte and GBHawk, so it's pretty likely it also works on console.
Unfortunately, this is only in DMG mode. I haven't found even a close hit in GBC in GBA mode (the one where console verification is easy to check.)
Maybe it's possible to directly check on a regular GB but I don't know, seems pretty likely though.
Oh, it looks like you took the TAS and converted it from VBM to BK2, is that the case? Did you have to adjust the ending?
I didn't expect a gameboy movie from VBA to work on Bizhawk... I don't know why but I always assumed the timing was different. Now I'm interested to see if other games can sync as well (such as SML1).
Up until this point I had feared that it might just have been a VBA bug. So it's reassuring to know it's actually legit.
Yes I just converted the VBM. Then I had to adjust the start point a bit for loading (and BIOS of course.) After that the gameplay was identical except for the very end where I adjusted the input by random guess and check until I got the glitch.
I briefly tested SML1 and it does look like it would sync with only adjusting for load times (I made it through the first few levels anyway.)
Well, the movie as it is published now is definitely not accuracte, since the current inputs do not even come close to hitting correct timing, so in that sense yes VBA is bugged, but the new movie still needs to be confirmed on console somehow to be sure.
¹ Items are: Mushroom, Fireflower, Carrot, Starman, Heart, Bubble, Money Bag, Checkpoint Bell, Goal Bell
² What happens when you carry over a Checkpoint Bell to a level that does not have one, then re-enter the level
Notes:
- Carrying over a Goal Bell results in Mario slowly walking forward.
In this state, he will not take damage from enemies (But he will take damage in Macro 1 from boulders that are spawned inside him).
He will not enter pipes automatically, but you can press down or right to enter one if you are close to one.
Time will not run.
If you enter the overworld autoscroller, items that would be hidden in blocks are floating above the blocks.
After the level (press select to quit, die or touch the goal), the bonus game starts.
- You cannot carry over multiple items because it seems you can only touch one item per frame.
- In levels that start you in position 0,0 after carrying over a checkpoint bell, you can carry over the "pipe glitch effect" to this level to travel downwards or upwards but there are only limited uses to this.
I looked at the pause bug ace again.
* To reach credits, make $A203 onwards read one of these at the time of the bug occuring:
C4 B0 03
C4 B1 03
C4 B4 03
C4 B5 03
C4 B6 03
C4 D2 03
C4 D3 03
C4 D4 03
C4 D5 03
C4 D6 03
C4 D7 03
C4 D9 03
C4 DA 03
C4 DB 03
C4 DC 03
(The critical code is located in $03DC: 3E 12 E0 9B - Sets $FF9B to 12.)
C4 C3 05 - Used in the Pause bug run
C4 C4 05
C4 C5 05
C4 C6 05
C4 C9 05
C4 CA 05
C4 CB 05
C4 CD 05
C4 CE 05
C4 CF 05
C4 D0 05
(The critical code that triggers the credits is located in $05D0: 3E 23 E0 9B - Sets $FF9B to 23.)
* With this current method, it is also theoretically possible to mute audio, restart the level, game over or level clear.
* Possible opcodes seem to be:
C2 JP NZ,a16
C3 JP a16
C4 CALL NZ,a16
D2 JP NC,a16
D4 CALL NC,a16
* To achieve total control, an idea would be to set $A2CE temporarily to make the game record input (= your code) in $A300 ~ $A3FF (a remnant used by the devs to record input for the title screen demos).
When $A2CE is 0x01 ~ 0x0F, the game is in "playing back input" mode and you are no longer controlling Mario.
When $A2CE is 0x10 or above, the game is in "recording input" mode. Audio is muted (maybe the audio processing is skipped altogether). With no audio, pause bug does not work.
You could theoretically pause bug the block corresponding to $A2CE into a breakable block (value 0x00) by pause bug. But pause bug does not work in "recording" mode since audio is muted. Maybe it is possible to enable audio somehow while recording input.
Other ways of achieving total control seem very unfeasible. For example you could run pause bug ace multiple times to piece code together one by one, but that would require running around in levels which takes a lot of time.
With more testing and some luck I could spell out
I edited values manually for testing purposes. And the game would execute A201~ over and over and over and never stop. I don't understand why.
If I don't put in C3 00 A3, it executes whatever code was there originally and stops at C0 (RET NZ, which I don't know what it means to be honest...). If I put a C0 or other RETURNs at, say, A303, it doesn't prevent the game from getting stuck in an infinite loop.
Again, I hope someone can help me because I will not be able to get it to work by myself...
This is again with manually edited values for testing - in this particular image, it triggers the credits on the next frame successfully.
There is one thing to think about: Since we use the title screen demo to write a program, and it eventually freezes when all input slots are used up, we should try to prevent that freeze from happening.
EDIT: It seems this strategy is completely useless because Pause glitch doesn't seem to work while in demo mode.
