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.
Skilled player (1444)
Joined: 7/15/2007
Posts: 1468
Location: Sweden
Well without the GT code I don't think S/T is that useful because the time it would take to collect all the beams would negate the time saved with the glitch so it'd be slower than the current glitched run. Also, as far as I know the escape trigger glitch has only been done on Zsnes and though it might be possible to do on some other emulator or console, it at least can't be done in the same way.
Agare Bagare Kopparslagare
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.
Skilled player (1444)
Joined: 7/15/2007
Posts: 1468
Location: Sweden
Yeah but the whole point of having a "no X-ray glitch run" was to have a relatively intact run that plays through the whole game with no major glitches. A S/T run would be even more glitched than the X-ray run, but slower.
Agare Bagare Kopparslagare
Tub
Joined: 6/25/2005
Posts: 1377
amaurea wrote:
Does one really need to worry so much about emulator accuracy?
Yes. A lag frame here or there isn't a problem, but the murder beam and its effects are more volatile than that. If parts of the glitch aren't possible on the console or give different results, then that's a problem.
amaurea wrote:
Edit: Also, this glitch seems like a likely way to execute arbitrary code in super metroid.
I cannot find the writeup, but IIRC it was kejardon (who else?) who dissected the glitch, and from what I remember, arbitrary code execution was.. unlikely. The beam goes wild, overwrites memory locations it shouldn't and everything, but IIRC there was no real way to direct the values that get written. For arbitrary code execution, you'd need to write your initial payload somewhere (often into an easily manipulateable inventory). Writing the required values by chance AND finding a way to randomly jump there is unlikely. tl;dr: the glitched beams are still poorly understood. More research would be helpful.
m00
Player (41)
Joined: 1/22/2014
Posts: 38
Location: Sweden
I've done some research on Spacetime recently and just posted my findings on the SM Speedrunning wiki: http://deanyd.net/sm/index.php?title=Spacetime_Beam Regarding arbitraty code execution, what Tub said is correct since what happens is a invalid jump to ROM, so there's no way we can manipulate what code runs. From what I can tell though, the effects are not random as long as roughly the same conditions are met, and the data that gets copied seems to be from ROM in most cases. I can't give any guarantees that it's all correct though, since I'm not that familiar with 65c816 code and the SNES architecture, but it's at least something. Feel free to contribute information to that as well.
Tub
Joined: 6/25/2005
Posts: 1377
total wrote:
I've done some research on Spacetime recently and just posted my findings on the SM Speedrunning wiki: http://deanyd.net/sm/index.php?title=Spacetime_Beam
+2 internet cookies for total! My SNES asm is a bit rusty (as in "I dabbled with m68000 assembler in my childhood and thus know the difference between a micro chip and a potato chip"), but along with your comments, I think I understand most of it. So it effectively jumps into a routine that looks similar to a memcopy which usually copies 10 bytes. Bytes are read from (address at $00) + Y + 2 and written to $7EC1C0 + X + 2, X and Y increase by 2 each loop until Y >= 20. Breakage occurs when Y is negative. Since A is 8 bit, it will copy 8 bits, the skip 8 bits, then repeat. Is that right? Have you identified where the routine is usually used, i.e. where that code came from? It's probably irrelevant, I'm just curious. Can you please copy the ASM for the other invalid beam combinations, too? Maybe something interesting turns up. The whole code for beam firing should be interesting, too, because that's the part where the values for X, Y and $00 can come from. Backtracing the call stack until the most recent manipulation of those values would be useful. X and Y are signed 16bit-registers, right? So at most one could write 32768+20 Bytes (Y range), and the addresses that could be written to are between $7EC1C0 - 0x8000 to and $7EC1C0 + 0x7FFF. Now does an adressing overflow overflow into the next bank or will it keep the bank, but start at the bottom again? In the first case, the routine could write to any address between $7E41C0 and $7F41BF, in the second case it'd be $7E41C0 to $7EFFFF and $7E0000 to $7E41BF, so essentially the whole 7E bank, which is most of the (non-expanded) RAM. Great. Let's look at http://drewseph.zophar.net/Kejardon/RAMMap.txt : Starting at 7E:CD52 things get interesting. There's a lot of gamestate, items, visited rooms etc, which may explain why the reset glitch does what it does - with a suitable start location for the copy, all the info gets zero'ed out, or at least badly mangled.
total wrote:
Regarding arbitraty code execution, what Tub said is correct since what happens is a invalid jump to ROM, so there's no way we can manipulate what code runs.
arbitrary code execution is a two-step process: a) write the code you want to execute somewhere in memory. This usually starts with a minimal payload which then reads more code from gamepad input. b) find a way to jump to that code It could be used to do a), depending on the available values in $00. If $00 ever points at a suitable hardware register, preferably the controller data, that might be useful. Should $00 always point to a RAM location (which it probably does), it's less useful, because it's just a copy. But with sufficient control over $00, X and Y we might be able to copy single instructions into just the right location. It's not yet useful for b) either. Ideally, we could use a memcopy to write the pointer into a location that contains an address (like the $0C68++ in the beam code), but if (as you say) X = 0 is given, that seems unlikely. Link I shouldn't forget: http://wiki.superfamicom.org/snes/show/65816+Reference
m00
Skilled player (1444)
Joined: 7/15/2007
Posts: 1468
Location: Sweden
Finished up a quick run with Saturns GT run as a starting point. Final time was about 1.5 seconds away from 00:08 which would definitely be reachable as the overall level of optimization is pretty low here. I'm sure there are some better spots for some of the S/T setups as well as probably some rooms where S/T could be used but no spot was found (all of the escape in particular, where every transition I hit pushed me to the wrong room). Realtime would have been about 19:15 with the rest of the run included, or around high 16 low 17 with the timing used by the speedrunners. http://dehacked.2y.net/microstorage.php/info/1882621194/GTCode_SpaceTime.smv www.youtube.com/watch?v=BmKUraqJApY Used Snes9x 1.43v12 to make it.
Agare Bagare Kopparslagare
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.
Skilled player (1444)
Joined: 7/15/2007
Posts: 1468
Location: Sweden
Well in most rooms I tried semi-blindly for a while to see if I noticed any pattern and then tried to work myself in a good position to appear in a good spot for the next room. I basically tried around with missiles and supers and shooting in different directions at different spots while running or jumping. Shooting purely with the beam rarely seemed useful and was more likely to just crash the game. I never tried murder beam but I don't think it's capable of doing anything like the S/T beam. There were a couple of rooms where I didn't really try it out where I maybe could have (first few Red Brinstar rooms for example). There seemed to be some rooms where it was only really possible to trigger one specific door transition, for example I tried a lot of spots at the Red Brinstar shaft and everything just triggered the upper right door. There were also some rooms where it didn't seem like it was possible to trigger a transition at all, like the big Green Brinstar room. I might have simply missed it but S/T seemed to behave a bit differently in that room. Also any of the elevator rooms I wasn't able to find the elevator transition which I guess might be possible and would save a lot of time.
Agare Bagare Kopparslagare
Player (41)
Joined: 1/22/2014
Posts: 38
Location: Sweden
So we did some more digging in what's possible with this, and me and Lioran made this possible on console. https://www.youtube.com/watch?v=Hfa9RHG1iB8 RIP Super Metroid :) Edit: So from testing we did, this will not work on some 1-chip old model SNES:es. I messed around a bit and found another setup that seems to work here: https://www.youtube.com/watch?v=6PXHzkKO8_Y
Skilled player (1444)
Joined: 7/15/2007
Posts: 1468
Location: Sweden
Haha, man that's really cool that you got it to work on console finally! Gotta say I'm really considering doing a full run now.
Agare Bagare Kopparslagare
Joined: 5/12/2009
Posts: 748
Location: Brazil
Really nice! Not sure how judges will deal with a run that uses GT code even if it beats the glitched fastest run. Given that when judging Saturn's run it was treated as a cheat code, i think it would still be considered a cheat code, so it would kinda not be a leggit glitched run. So, if this is the case, the way you, Cp, completed the game in the current glitched run might be the fastest way without cheating (i'm not saying GT code is a cheat code). Even if TASvideos doesn't accept a glitched run that uses the GT code i'd still love to watch a fully optimized run. What could be treated in a different way is a 100% glitched run, using X-ray and space time glitch. Maybe X-ray could be picked up early to allow to get some itens early than normal (Plasma comes to mind).
Patashu
He/Him
Joined: 10/2/2005
Posts: 4044
I think space-time clobbers your item collection status, so you couldn't use space-time and also get 100%.
My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu
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.
Joined: 5/12/2009
Posts: 748
Location: Brazil
Patashu, you're probably misunderstanding the space time glitch with the Reset Glitch, where you start from Ceres with all you had before Reset Glitching.
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.
Joined: 5/12/2009
Posts: 748
Location: Brazil
Well, as long as you don't activate the past zebes. I think there are specific spots to activate the past zebes. The only one i remember is the secret passage in the hunter shaft, where you usually get the last Super Missile pack in a 100% run.
Skilled player (1444)
Joined: 7/15/2007
Posts: 1468
Location: Sweden
Eye Of The Beholder wrote:
Really nice! Not sure how judges will deal with a run that uses GT code even if it beats the glitched fastest run. Given that when judging Saturn's run it was treated as a cheat code, i think it would still be considered a cheat code, so it would kinda not be a leggit glitched run. So, if this is the case, the way you, Cp, completed the game in the current glitched run might be the fastest way without cheating (i'm not saying GT code is a cheat code). Even if TASvideos doesn't accept a glitched run that uses the GT code i'd still love to watch a fully optimized run.
Yeah I'm not sure it would be accepted either because both the GT code and S/T are very iffy. I'm still interested in making it though, can't have speedruns beating the TAS time! Just trying to figure out the best way to get enough health to skip the Hi-jump E-tank which will definitely be slower to collect in realtime. EDIT: Also the game resets in several spots, it might even be most times when S/T is used. I tested it in 3 random spots and every spot reset the game state (items and missile doors at the very least). EDIT2: And an S/T is probably still faster without the GT code too, depends on how long it takes to collect Plasma with X-ray.
Agare Bagare Kopparslagare
HHS
Active player (286)
Joined: 10/8/2006
Posts: 356
amaurea wrote:
Much of its shenanigans are sadly blocked by most writes being redirected to ROM, where they have no effect
Why do you think that? $900000-$901fff refers to the same locations as $7e0000-$7e1fff. So, if $7e0dc2, $7e1cad or $7e0a0a can be controlled, you can execute anything.
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.
HHS
Active player (286)
Joined: 10/8/2006
Posts: 356
For Super Metroid, which is a mode 20 cartridge, addresses $8000-$ffff in banks $80-$df (and in $00-$5f) are ROM. The first 8K of RAM, as well as CPU/PPU/DMA/controller registers, are always available in banks $00-$3f and $80-$bf.
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.
Skilled player (1444)
Joined: 7/15/2007
Posts: 1468
Location: Sweden
Anyone know if there's a way to do the lava lake before LN without high jump or gravity suit?
Agare Bagare Kopparslagare
Tub
Joined: 6/25/2005
Posts: 1377
amaurea wrote:
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.
oh man. If i was an actual dog, you'd see tail wagging.
amaurea wrote:
By the way, the game state is stored in 0x998, and writing 0x26 to this address will play the ending.
You mean, on the next frame, the game loop checks the value there, and jumps to the ending routine if it contains 0x26? If so, would it be possible to jump to the ending routine directly (possibly giving us a different attack vector), or is the ending still part of the regular game loop?
m00