Posts for amaurea

1 2 3 4
16 17
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Cpadolf: I don't think you need to worry about in-game time here. Whether you use the death pause trick or not, the final ingame time can be whatever we want. Why not go for 00:00.00? It's just a memory address like any other, so we can set it to any value. I've been busy with work today, so no progress. But if you (or somebody else) want to speed things up, one thing you could do is to see how quickly you can glitch out of bounds and reach a place where memory.readbyte(0xdc4) is 0x10, 0x30, 0x50, 0x80, 0x82, 0x90, 0xd0 or 0xf0 (that is, one of many relative jump instructions that can be made to work in this situation), and memory.readbyte(0xdc5) is 0x38 (the distance to jump to a copy of the input for controller 1, which will be enough to get us to the real target of 4218). If you can reach that in reasonable time, then we can skip the ammo and OAM requirements (though you still need the beams, of course).
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Here are some notes on what I've found for the uncharged murder beam (together with PJBoy). It jumps to 0dc2, where we have
0dc2  Beam charge counter   00-3c
0dc3  00
0dc4  Last processed block index low
0dc5  Last processed block index high
I have confirmed that the charge counter still hasn't been reset to zero by the time we get here, so this will work. By itself, 0dc2 lets us choose between the same non-fatal instructions as super missiles (the slightly higher range does not help us here): ORA, TSB, BPL, TRB, JSR, BIT, AND, BMI Coupled with the 00 in the following byte, this puts us in much the same situation as with super missiles, but with the possibility of jumping even higher in memory, and being able to avoid the ammo requirements. Both dc4 and dc5 are quite easy to manipulate, since collision detection is done in the air too. The 16 bit number at 0dc4 is roughly given by (x>>4)*w+(y>>4) where x and y are Samus coordinates, and w is the width of the room in blocks. This method can be a drop-in replacement of sorts for the charged space-time beam (though the position requirements might be incompatible with the 0b00 appraoch total developed. But I think the flexibility of 0dc4 and 0dc5 can be used to do something more interesting too, by executing 0dc4 as a conditional jump, with 0dc5 as the argument. In theory this would let us jump ±80 bytes, but due to the limited range of 0dc6 (which is due to the size of rooms - the bigger the rooms the larger the range, but even the biggest rooms are < 30). This won't be a very long jump, and only forwards. This lets us jump as far as about 0df6, which is almost but not quite far enough to get to 0dfe-0e01, which are controller inputs for the previous frame. Of course, going out of bounds will fix this, and going downwards OOB is a very effective way of increasing that byte.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Cpadolf: Total^ has looked into this. He has found a way by glitching out of bounds in the room next to GT, and running for about 20 seconds. One also needs to collect the GT's super missiles repeatedly. But right now, the uncharged (or should I say partially charged) murder beam looks like it is even easier to use. It's still under investigation, though.
Post subject: Super Metroid page updated
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I've updated the Super Metroid page with technical details for the glitched beams and arbitrary code execution now.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Cpadolf wrote:
@amaurea: I noticed that controller 1, 2, 4 and 5 were used in the smv to trigger the ending, is the numbering of the controllers important (as 3 was not used) and would this prove problematic for Bizhawk which doesn't seem to support a 5th controller?
No, I don't think that should be a problem. This is just an issue of Snes9x using a weird numbering scheme for its controllers. What matters is that the emulator can provide inputs for the four controllers that are read by the auto joypad read function, and while I'm not familiar with Bizhawk, there's no reason why it shouldn't be able to do that.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I'll elaborate on this later today, but I can now jump to the ending (in fact, before jumping to the ending I have total control). This is using snes9x, so it should be ported to lsnes or similar. I'll describe what happens in details later.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Tub: The game operates at the highest level in one of several modes, which usually transition into each other. I think this happens by having a top-most driver function which just loops and calls the game-mode function corresponding to the current value of 998. When a game mode is done and wants to switch to the next one, it can simply write a new value to 998. Sometimes I think this simply takes the form of incrementing 998, since some modes follow each other sequentially. See the death stuff here, for example:
00   0: Hang - black screen
01   1: Hang - black screen
02   2: Hang - black screen
03   3: Hang
04   4: Load game screen
05   5: Select map screen - glitched
06   6: Starts from last save
07   7: ?
08   8: Normal
09   9: Door transition
0a  10: Door transition
0b  11: ?
0c  12: Fade to map screen
0d  13: Map screen
0e  14: Glitched map screen
0f  15: Glitched map screen
10  16: Fade to normal play
11  17: Temporary hang, then normal
12  18: ?
13  19: Death
14  20: Death
15  21: Death anim
16  22: Death no anim
17  23: Death no anim
18  24: Death no anim
19  25: Game over
1a  26: Game over
1b  27: ?
1c  28: Hang
1d  29: Game quit menu (weird)
1e  30: Hang
1f  31: Samus load from save
20  32: Space colony explodes
21  33: Space colony explodes
22  34: Hang
23  35: Space colony explodes, game over
24  36: Space colony explodes, game over
25  37: Hang
26  38: Zebes explodes, ending
27  39: Hang
28  40: Demo
29  41: Demo-related
30  42: Demo-related
31  43: Demo
32  44: Hang
33  45: Hang
34  46: Hang
35  47: Hang
36  48: Hang
That makes most sense if the death and game over stuff is a series of modes which are meant to follow one after another. Many of them result in the same thing because they quickly increment the game mode. The point is that if you suddenly call the wrong game mode, control will probably revert to the mode indicated by 998 the next frame (probably messing stuff up) unless that mode quickly writes something to 998. But this is very speculative - I haven't tested this. While I'm at it, I should mention that if we shoot up-right, A will contain 9f27 when we get here, which just needs a single DEA instruction to make the lower byte 26. That gives us several alternatives for getting 26 in 998. LDA #$XX26 or DEA or something more complicated followed by STA 998. Or one could put 998 in a direct page address and then use STA (foo). Or similar. The hard thing is getting the byte sequence "09 98". It might be easier to instead use the OAM to perform a JMP to somewhere better, for example somewhere with controller input stored. I think this should be quite doable.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Let's look at the addresses we jump to for the beams that jump to RAM, and compare them with the RAM map:
  • 0ps00: 3920: Part of tilemap for layer 3 (HUD).
  • 0psiw: 0dc2: Unknown. Possibly related to the grapple beam.
  • cps00: 1cad: Pre-PLM instruction
  • cpsi0: 0a0a: Mirror of super missile count(!). (Followed by power bomb count and currently selected status bar item).
The last one (charged space-time beam) seems very promising! So with the charged spacetime beam, we will jump to [2 byte sm count] [2 byte power bomb count] [2 byte item select]. Without glitching out the item counts (which should be possible, though), all these counts are smaller than one byte, so the pattern will be [SS 00 PP 00 0s 00]. All those zeros are quite constraining on what one can run, but thankfully, the first byte (the instruction) is pretty freely controllable between 0x00 and 0x32. This range includes lots of interesting instructions such as subroutine jumps, stack manipulation and changing processor flags. In particular, with 32 (0x20) super missiles we can use the power bomb count to jump anywhere between 0x0000 and 0x3200 in steps of 0x100. Lots of player-manipulable variables can be found in that range. Particularly interesting is the jump to 0x0400, which puts us inside OAM. The data here takes on many values, and is quite manipulatable through Samus' position and actions. Also, since the projectile stays out, this will happen every frame (as long as one successfully returns from the glitched jump). This can be good (letting one make do with just a few instructions), but also bad: Since OAM is quite volatile, what works one frame might not work at all another frame. For example, I positioned Samus next to her ship, and jumped to a position such that memory at 0x400 was FA EA 60, after making sure Samus had 32 super missiles and 4 power bombs. At that point I shot a charged space-time beam. Normally that would instantly crash the game, but in this case what was executed was: JSR 0a0a, JSR 0400, PLX, NOP, RTS, which safely managed to return to a normal state. However, the next frame Samus had fallen by one pixel, changing one of the OAM entries associated with the ship, leading to a crash on the next frame. By the way, the game state is stored in 0x998, and writing 0x26 to this address will play the ending. I haven't found quite the right OAM setup to do this, but it seems definitely doable. This would mean that a TAS with the GT code could end the game there and then, rather than making its way back to the ship.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
HHS: Thanks for pointing that out. I was heading off on the wrong track there. I'm not sure why I thought that that would be ROM reads/writes. Perhaps I was confused by geiger's "show hex" command classifying 808000-bfffff as ROM. What addresses correspond to the ROM, then? Edit: I know this can be different depending on the cartridge, but if these apply, then 908000-90ffff would be ROM. I'll fix my earlier post to stop assuming all those addresses are ROM, and hence fixed and predictable.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Eye of the beholder: Aren't those the same thing? Isn't that why it's called the spacetime beam? It lets you travel into the past zebes.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I don't think so Patashu. I think the completion percentage is simply based on counting the upgrades you currently have equipped, not which items are marked as collected. I think you can get >100% using the space-time glitch. PS: I've updated my previous post with more information. It's not fully done yet, but perhaps there is something useful there.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Starting from total's link, I did some tracing myself to see how the space-time beam glitched copy loop works. I think it does this, basically (in a C-like notation) (The beam is a bit-mask, where each bit represents charge (c), plasma (p), spazer (s), ice (i) and wave (w)):
*beam_table = 0x9383c1
beam = 000cpsiw (p=plasma, etc.) (RAM address 0x9a6)
dir = {U UR R DR D D DL L UL U} (0..9)
*target = 0x7ec1c0
y0 = *(beam_table[(beam&0xf)<<1]+(dir+1)<<1)
x0 = 0?
for(y=y0+2,x=x0+2;y<0x20;y+=2,x+=2)
    target[x] = (*direct_page[0:3])[y]
For the space-time beam, plasma, spazer and ice are active, giving beam=0xe. The index into the beam table will be 0x1c, which I think goes out of bounds, since the highest possible beam combination is supposed to be plasma, ice, wave, which would give an index of 0x16. The value that is read from this table is used as a pointer after adding a number which depends on which direction you fire the beam. The location this points to is then where we read the loop counter from. During the loop, A, X and Y are all 16 bit registers, so no bytes are skipped in the memcpy. By examining the beam_table, it should be easy to find all the values y0 could take at this point. This can be used to choose the range of memory overwritten by the glitch, and coupled with the firing direction, one has quite a bit of flexibility. I didn't use the charge beam in this test, so that gives another set of possibilities. I don't think it's obvious that this couldn't eventually be used to gain control. We write lots of garbage to memory, and that is clearly capable of affecting the instruction pointer in some way, since it can make the game crash. Cpadolf: How much did you test for rooms in which to activate the space-time beam? Did you try the murder beam too? Charged vs. uncharged and direction one fires in, and whether the projectile materializes in a door are all things that I think matter for this. (Cpadolf: I agree that a space-time TAS should be in the same category as an X-ray TAS, and having a space-time tas obsolete the less-glitched TAS would be pretty crazy. I spent a lot of time making that argument in the thread I linked to. I was just saying that some people involved with category management thought otherwise) Edit: The beam table is (little endian; left column indicates which beam combinations lead there):
   9383c1       9383d9
00000: 31 84  c0000: 39 85
0000w: B5 84  c000w: D3 85
000i0: 9F 84  c00i0: A7 85
000iw: E1 84  c00iw: E9 85
00s00: 47 84  c0s00: 4F 85
00s0w: F7 84  c0s0w: FF 85
00si0: 5D 84  c0si0: 65 85
00siw: 73 84  c0siw: 7B 85
0p000: CB 84  cp000: BD 85
0p00w: 0D 85  cp00w: 2B 86
0p0i0: 23 85  cp0i0: 15 86
0p0iw: 89 84  cp0iw: 91 85
0ps00: 39 85  cps00: 41 86
0ps0w: D3 85  cps0w: 41 86
0psi0: A7 85  cpsi0: 57 86
0psiw: E9 85  cpsiw: 71 86
Coupled with the possible directions, this means that y0 will be read from these locations in bank 93:
         U   UR    R   DR    D    D   DL    L   UL    U
00000: 8433 8435 8437 8439 843b 843d 843f 8441 8443 8445
0000w: 84b7 84b9 84bb 84bd 84bf 84c1 84c3 84c5 84c7 84c9
000i0: 84a1 84a3 84a5 84a7 84a9 84ab 84ad 84af 84b1 84b3
000iw: 84e3 84e5 84e7 84e9 84eb 84ed 84ef 84f1 84f3 84f5
00s00: 8449 844b 844d 844f 8451 8453 8455 8457 8459 845b
00s0w: 84f9 84fb 84fd 84ff 8501 8503 8505 8507 8509 850b
00si0: 845f 8461 8463 8465 8467 8469 846b 846d 846f 8471
00siw: 8475 8477 8479 847b 847d 847f 8481 8483 8485 8487
0p000: 84cd 84cf 84d1 84d3 84d5 84d7 84d9 84db 84dd 84df
0p00w: 850f 8511 8513 8515 8517 8519 851b 851d 851f 8521
0p0i0: 8525 8527 8529 852b 852d 852f 8531 8533 8535 8537
0p0iw: 848b 848d 848f 8491 8493 8495 8497 8499 849b 849d
0ps00: 853b 853d 853f 8541 8543 8545 8547 8549 854b 854d :c0000
0ps0w: 85d5 85d7 85d9 85db 85dd 85df 85e1 85e3 85e5 85e7 :c000w
0psi0: 85a9 85ab 85ad 85af 85b1 85b3 85b5 85b7 85b9 85bb :c00i0
0psiw: 85eb 85ed 85ef 85f1 85f3 85f5 85f7 85f9 85fb 85fd :c00iw
       8551 8553 8555 8557 8559 855b 855d 855f 8561 8563 :c0s00
       8601 8603 8605 8607 8609 860b 860d 860f 8611 8613 :c0s0w
       8567 8569 856b 856d 856f 8571 8573 8575 8577 8579 :c0si0
       857d 857f 8581 8583 8585 8587 8589 858b 858d 858f :c0siw
       85bf 85c1 85c3 85c5 85c7 85c9 85cb 85cd 85cf 85d1 :cp000
       862d 862f 8631 8633 8635 8637 8639 863b 863d 863f :cp00w
       8617 8619 861b 861d 861f 8621 8623 8625 8627 8629 :cp0i0
       8593 8595 8597 8599 859b 859d 859f 85a1 85a3 85a5 :cp0iw
       8643 8645 8647 8649 864b 864d 864f 8651 8653 8655 :cps00
       8643 8645 8647 8649 864b 864d 864f 8651 8653 8655 :cps0w
       8659 865b 865d 865f 8661 8663 8665 8667 8669 866b :cpsi0
       8673 8675 8677 8679 867b 867d 867f 8681 8683 8685 :cpsiw
This leads to the y0 values:
          U   UR    R   DR    D    D   DL    L   UL    U
00000:  86db 86e7 86f3 86ff 870b 870b 8717 8723 872f 86db
0000w:  873b 87c7 884b 88cf 8743 8743 87c7 884b 88cf 873b
000i0:  8953 8953 8953 8953 8953 8953 8953 8953 8953 8953
000iw:  873b 87c7 884b 88cf 8743 8743 87c7 884b 88cf 873b
00s00:  8977 8993 89af 89cb 89e7 89e7 8a03 8a1f 8a3b 8977
00s0w:  8a57 8aab 8aff 8b53 8ba7 8ba7 8bfb 8c4f 8ca3 8a57
00si0:  8977 8993 89af 89cb 89e7 89e7 8a03 8a1f 8a3b 8977
00siw:  8a57 8aab 8aff 8b53 8ba7 8ba7 8bfb 8c4f 8ca3 8a57
0p000:  8cf7 8d0b 8d1f 8d33 8cf7 8cf7 8d0b 8d1f 8d33 8cf7
0p00w:  8d4f 8d9b 8ddf 8e33 8d4f 8d4f 8d9b 8ddf 8e33 8d4f
0p0i0:  8cf7 8d0b 8d1f 8d33 8cf7 8cf7 8d0b 8d1f 8d33 8cf7
0p0iw:  8d47 8d93 8ddf 8e2b 8d47 8d47 8d93 8ddf 8e2b 8d47
0ps00:  8e77 8e8b 8e9f 8eb3 8ec7 8ec7 8edb 8eef 8f03 8e77 :c0000
0ps0w:  8f17 8fa3 9027 90ab 8f1f 8f1f 8fa3 9027 90ab 8f17 :c000w
0psi0:  912f 912f 912f 912f 912f 912f 912f 912f 912f 912f :c00i0
0psiw:  9153 91df 9263 92e7 915b 915b 91df 9263 92e7 9153 :c00iw
        936b 93bf 9413 9467 936b 936b 93bf 9413 9467 936b :c0s00
        94bb 957f 9643 9707 97cb 97cb 988f 9953 9a17 94bb :c0s0w
        936b 93bf 9413 9467 936b 936b 93bf 9413 9467 936b :c0si0
        94bb 957f 9643 9707 97cb 97cb 988f 9953 9a17 94bb :c0siw
        9adb 9b1f 9b63 9ba7 9adb 9adb 9b1f 9b63 9ba7 9adb :cp000
        9beb 9c9f 9d53 9e07 9beb 9beb 9c9f 9d53 9e07 9beb :cp00w
        9adb 9b1f 9b63 9ba7 9adb 9adb 9b1f 9b63 9ba7 9adb :cp0i0
        9beb 9c9f 9d53 9e07 9beb 9beb 9c9f 9d53 9e07 9beb :cp0iw
        9ebb 9ec7 9ed3 9edf 9eeb 9eeb 9ef7 9f03 9f0f 9ebb :cps00
        9ebb 9ec7 9ed3 9edf 9eeb 9eeb 9ef7 9f03 9f0f 9ebb :cps0w
        9f1b 9f27 9f33 9f3f 9f4b 9f4b 9f57 9f63 9f6f 9f1b :cpsi0
        9f87 001e 9fbf 0008 a007 0008 a039 0000 a06b 012c :cpsiw
These are almost all negative, even for normal beam combinations, so if all the beams performed the same glitched jump as the spacetime beam, they would all have much the same effects. But they don't. Where to jump is determined by $0c68,x. This seems to be given by another table with 2*beam as the lookup, located at 90b96e or 90ba3e depending on whether the beam is charged (unless firing into a door or similar, when the constant value 69 B1 is used):
  90b963         90ba3e
00000: F3 AE   c0000: F3 AE
0000w: E4 B0   c000w: C3 B0
000i0: F3 AE   c00i0: F3 AE
000iw: E4 B0   c00iw: C3 B0
00s00: F3 AE   c0s00: F3 AE
00s0w: C3 B0   c0s0w: C3 B0
00si0: F3 AE   c0si0: F3 AE
00siw: C3 B0   c0siw: C3 B0
0p000: F3 AE   cp000: F3 AE
0p00w: C3 B0   cp00w: C3 B0
0p0i0: F3 AE   cp0i0: F3 AE
0p0iw: C3 B0   cp0iw: C3 B0
0ps00: 20 39   cps00: AD 1C
0ps0w: AC B0   cps0w: 0A 0A
0psi0: 16 AD   cpsi0: 0A 0A
0psiw: C2 0D   cpsiw: AA A4
So for the spacetime beam, y0 will always be 0x912f. For the other beams, we get:
  • 0ps00: Jumps to 903920, which RAM. In my trace, this was a BRK instruction, hanging the game
  • 0ps0w: This is the chainsaw beam. Jumps to 90b0ac (ROM), which is close to the beginning of the function for some other shot type. Ends up executing the code for that shot, plus one other side effect, a write of the current Y register value to address 0x60. This has little potential for doing anything useful.
  • 0psi0: This is the space-time beam, described above. Jumps to 90ad16 (ROM).
  • 0psiw: Jumps to 900dc2, which is RAM, but a BRK instruction in my tests, hanging the game.
  • cps00: Jumps to 901cad, which is RAM, but in my test it lead to PLY, ROL A, BRK, hanging the game.
  • cpsi0: Jumps to 900a0a, which is RAM. In my tests, this memory region contained AND, AND, BRK, hanging the game.
  • cps0w: Same as above.
  • cpsiw: The murder beam. Usually jumps to 90a4aa. This is ROM. It leads to the incredibly glitched function below. However, if y0 is zero (which it is when facing left), the jump is skipped. This avoids a crash, and is needed for the normal, useful behavior of the murder beam (which happens elsewhere). For all other directions, the jump will happen.
As HHS points out, half of the beams jump to RAM, and are therefore promising for arbitrary code execution, if some way can be found to control those memory locations. Wow, the murder beam is more messed up than the spacetime beam. It completely breaks the stack. Much of its shenanigans are sadly blocked by most writes being redirected to ROM, where they have no effect. But not all. And some logic depends on possibly manipulatable RAM values. I think this beam has much higher potential for eventually leading to arbitrary code execution than the spacetime beam.
A is set using the same logic as for the spacetime beam, i.e.
 y0 with the forum post terminology. Depending on the direction
 it is fired in, A can take the values
  0000 (L),   0008 (DR DDL), 001e (UR),  012c (UUL)
  9f97 (UUR), 9fbf (R),      a007 (DDR), a039 (DL),  a06b (UL)
 I.e. both positive and negative values are possible. The value of
 A only affects the initial test. So the cases that matter are
 A positive but less than the value in $9e99=500, and A outside this range.
 I.e. [L DR DDL UR UUL] vs. [UUR R DDR DL UL].
 if(A>=0&&A<$9e99) {
 ·$0dfa = $dfa & #ff00 | #0001
 ·if($8f & $09b4) call $9098bc
 }
 $90/A4AA 30 1C       BMI $1C    [$A4C8]
 $90/A4AC CD 99 9E    CMP $9E99  =0500
 $90/A4AF 10 17       BPL $17    [$A4C8]
 $90/A4B1 AD FA 0D    LDA $0DFA
 $90/A4B4 29 00 FF    AND #$FF00
 $90/A4B7 09 01 00    ORA #$0001
 $90/A4BA 8D FA 0D    STA $0DFA
 $90/A4BD A5 8F       LDA $8F    Controller button pressed this frame!
 $90/A4BF 2D B4 09    AND $09B4
 $90/A4C2 F0 04       BEQ $04    [$A4C8]
 $90/A4C4 22 BC 98 90 JSL $9098BC
 The intial value of A no longer matters at this point.
 $90/A4C8 AD 1C 0A    LDA $0A1C
 $90/A4CB C9 81 00    CMP #$0081
 $90/A4CE F0 39       BEQ $39    [$A509]
 $90/A4D0 C9 82 00    CMP #$0082
 $90/A4D3 F0 34       BEQ $34    [$A509]
 $90/A4D5 80 00       BRA $00    [$A4D7]
 $90/A4D7 A5 12       LDA $12
 $90/A4D9 F0 1A       BEQ $1A    [$A4F5] Perhaps
 $90/A4DB AE 96 0A    LDX $0A96
 $90/A4DE AD 94 0A    LDA $0A94
 $90/A4E1 C9 01 00    CMP #$0001
 $90/A4E4 D0 0F       BNE $0F    [$A4F5]
 $90/A4E6 BD 14 A5    LDA $A514,x
 $90/A4E9 29 FF 00    AND #$00FF
 $90/A4EC F0 07       BEQ $07    [$A4F5]
 $90/A4EE A9 2F 00    LDA #$002F
 $90/A4F1 22 49 90 80 JSL $809049
 $90/A4F5 AD D0 0C    LDA $0CD0  =0000
 $90/A4F8 C9 3C 00    CMP #$003C
 $90/A4FB 30 12       BMI $12    [$A50F]
 $90/A4FD A5 12       LDA $12
 $90/A4FF D0 0E       BNE $0E    [$A50F]
 $90/A501 A9 04 00    LDA #$0004
 $90/A504 8D 6E 0A    STA $0A6E
 $90/A507 80 06       BRA $06    [$A50F]
 $90/A509 A9 03 00    LDA #$0003
 $90/A50C 8D 6E 0A    STA $0A6E
 $90/A50F 20 40 90    JSR $9040
 $90/A512 28          PLP This messes up the stack!
 $90/A513 60          RTS Will return somewhere crazy
In my test, game eventually reached a BRK instruction after a long series of jumps after this broken RTS, and halted. But exactly what happens could depend on RAM contents. I really should explore this further.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Oh, I had missed that this could actually beat the X-ray TAS if you used the GT debug code. Hm.. Still, when saturn submitted his GT TAS, the use of that code was the main criticism. But perhaps it would pass this time. But I should point out that we don't have a glitched category any more. It's now "any%" (the glitched one) and "no X-ray glitch" (the normal one). So even if this one were slower than the X-ray glitch, it could obsolete the "no X-ray glitch" one, since it doesn't use that glitch. I discussed this with Radiant (who has much influence over categories here) using this specific example a month ago or so, and he confirmed that a space-time TAS would compete in the "no X-ray glitch category". In that case, the time to beat is 38:41, not 21:25.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I've been hoping for a space-time TAS for a while. But: Why use the GT code? It's not necessary at all, and would greatly reduce the chances of publication. And secondly: I thought there wasn't a need to visit Tourian at all with this glitch. I'm pretty sure I've read that firing it in the correct room will trigger the self destruct sequence. Other fun possibilities with this glitch is a playaround which visits the space colony with full equipment (as well as seeing the opening sequence cutscenes with full equipment). Does one really need to worry so much about emulator accuracy? lsnes and bizhawk are already very accurate, and I don't think the TASer should have to worry about console sync when making the TAS. That is a possible bonus that can come afterwards. Edit: Also, this glitch seems like a likely way to execute arbitrary code in super metroid. Anything that can horribly crash the game is a good candidate for that. I think there are other broken beam combinations that are usually much less useful than the space-time beam and murder beam, and which usually crash a game. Those should also be checked to see if they can be made to run arbitrary code.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Allowing different input for a "one set of input completes N games" category destroys the whole concept, and I'm sure it would cheapen your own sense of achievement too. If fixing the desync is too time-consuming, then I would suggest removing that game from the set, and doing an 8 game TAS rather than a 9 game TAS. This desync sounds pretty magical, though. How can the input that synced previously now suddenly desync? If sync has changed, that must be due to something changing. Do you have a copy of the version that synced? Does that still sync? If not, you should consider using version control when TASing, so that you don't have to worry about losing input. And anyway, if sync is that fragile, it seems pretty unlikely that the TAS would sync on somebody else's computer.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
In wintaser.cpp I saw that you had tried to work around hangs in some games by changing the process privileges. I can't help with that (I know next to nothing about windows programming, and I don't even have a windows computer to run hourglass on), but I've seen Process Monitor recommended for figuring out for example why a process hangs. Apparently it's a sort of windows equivalent to strace. If you know what the hung process is waiting for, then you're half the way to fixing it. I don't think you should underestimate IRC for project coordination and even support. Especially on the Freenode IRC network there are dedicated IRC channels for many open source projects, and in the more active ones one can get interactive help from developers or other users in just a few minutes. I should also mention that there are 62 people on the #tasvideos channel on the same network right now. I also recommend using something newer than svn. The advantage of distributed version control like git or mercurial (the latter tries to resemble svn) is that people can check it out, develop it locally with the full advantages of version control without having to ask for commit privileges before they actually want to share their results. On the other hand, things like svn-git allow this even with svn, though in a somewhat inefficient fasion. But really, which version control system to use is not important compared to the actual programming. I also think it would be nice with a document describing what parts of the source you've explored, how you think the parts fit together and which files are the most important/promising ones to look into. This will be a great help for new people joining the project.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
ais523 wrote:
I'm genuinely unsure on whether to redo from halfway through the TAS or not. It looks sloppy, and it is sloppy, so I don't really want it in the run, but it might be a lot of effort to get everything lining up like it should.
Don't restart. Finish the current version and then start on a v2. It takes basically the same amount of time, but you learn more things from the endgame that you can use in your next version; you might get more feedback from the outside that reveals further improvements by publishing; publication renews interest and might inspire others to try to TAS the game; and this way we reduce the risk of nothing being published at all due to redoing burning you out. Publish early and often.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Baka: Have you read TASVideos and metroid 2002's pages about Super Metroid? Once you gain more skill and knowledge about the game you will hopefully become a bit more humble about your own skills and impressed by others'. Perhaps then you would stop implying that well-established and often used tricks are just lies, and that people demonstrating them are cheaters. The Draygon movie you saw was a Tool-Assisted Speedrun (I.e. what this whole site, with the exception of this subsection of the forum) is about. It used the so-called super-short charge, which is documented on the pages I linked to.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
creaothceann wrote:
Just for the record, my idea in a diagram: http://i.imgur.com/GpNEfUZ.png
I see. So your idea is
  • For every input frame, PerFrameRerecordCounter[frame] = NormalRerecordCounter
That's nice and simple. I like it. I had misunderstood your idea, and thought it was
  • For every loadstate, PerFrameRerecordCounter[frame]++
The two differ in how the rerecords in the discarded branches are treated. With your idea, they are all condensed into the frame where they branch off from the trunk. With what I first thought your idea was, they would be flattened down to the corresponding frame in the trunk. I think the latter is what RachelB implemented, though I only skimmed through that. Both versions would work, but I think I prefer your real suggestion. And they are both really simple to implement.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Flip: The rerecords would be displayed where you indicate. That is the price one pays for such a simple implementation. The full branching tree of input and rerecords is what my previous suggestion was about. That can be visualized for example like this: Link to video But getting the full history requires much more work than simply getting the rerecord count per frame, and there was not enough interest in implementing it. creaothceann's suggestion is so simple to implement that it is worth it to do so even though some care must be taken when interpreting the result. And most branches are short, so the results won't be that misleading in most cases.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
If I recall correctly the jump button must be held when you push down. So to do a low mochball you would press jump, let it go, then press and hold jump, then press down etc.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I like this idea. It is basically a scaled back version of my previous suggestion for saving the full input history. Simpler to implement, but a bit harder to interpret.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
On the linux version of snes9xrr, launching lua scripts directly from the command line is supported. There one does
snes9x rom -loadlua foo.lua
It also supports specifying a movie to play using the -autodemo argument, and one can also specify a maximum number of frames to run, and tell it to dump video and audio (-dumpstreams). This makes it suitable for automatic encodes, though some work is needed to get around it not supporting running headless (it needs to open up a graphical window). I fix that with Xvfb, which creates a fake graphical environment for snes9x to put its window in. With that in place (and a database mapping CRC to rom), encoding a smv file to h264 in mkv is as simple as doing "smvenc foo.smv foo.mkv". Not having a proper command line interface makes it difficult to automate things like that, so I hope that gets added to the windows version eventually. Especially since the linux version has its own slew of problems. In the absence of a built-in command line interface, your auto hot key script is a nice workaround. And it's surprisingly compact.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Which scientific papers are you talking about, by the way, Warp? Are they very old ones from the beginning of last century? I don't think there is anything controversial about the expansion of the universe and its effect on the recessional velocity of galaxies nowadays. The only thing I think you will find people quibbling about is calling it "velocities", since comparing velocities non-locally is a bit iffy in GR (one should really parallel transport the proper velocity vectors to the same location, and only then compare them. But in curved space-time, there are multiple ways of parallel transporting that give different results.)
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I'm also looking forward to the next update, whether that is an actual submission or just an update of turnbyturn or t2000timings.
1 2 3 4
16 17