Direct Messages
SMB1 ACE
Need 1 more
Bullet barely too late
Koopas barely too early
Normally could turn them around with damage… doesn’t happen underwater
Could turn them around by being on the right side of them when they land…. They are not high up.
The goomba is…. Goombas dont turn around.
Exactly 1 enemy too late, the buzzy beetle you can turn around
Bloopers could come down and turn koopas around but blooper is too late
Actually… enemies never turn each other around when underwater
Assuming this is done so bloopers dont turn cheep cheeps around
..is what i thought. But they never turn around regardless. Why???
Could do it later but run out of time lol
Could maybe do it with earlier firebar? But it’s actually not a full double firebar….
Could maybe turn enemies around with firebar glitch but firebar isn’t next to enemies on the ground
Test if COULD turn cheep cheep around…. But cheep is too slow lol!! Out of time
Hammer bros chase you after a while….. But NOT to the right!
Earlier bowser??? How close is that. Oh… powerup slot
Midway, different bowser?
If you could keep fire from midway with the vine glitch it’s possible (apparently?)
Killing bowser turns into a fireflower that hurts you lol?? 
1
1
-1 though.
1
1
1
1 2
1
1
1 1NOP instruction, or some other insignificant operand, we won't be accurately emulating the outcome.
BPL instruction, and now we need to know the state of the CPU's negative flag. BCC, otherwise, BPL again. Regardless, I think we end up executing $20x4, at which point we read from the OAM buffer that FCEUX is emulating incorrectly. 
1
1 1
hahaFC from the last value OAM2, but both Mesen and Bizhawk are reading the first value of OAM2. That's probably a single line fix. Also, the fewer objects there are on the following scanline, the larger that range will be, since the OAM address will overflow sooner. 
fun fun 1 1
1 1
JMP ($6C6C) would jump to $3524. 
1 1Dots 1 through 64 of a scanline will always read $FF. (Secondary OAM initialization)
Dots 65 through 256 will read from the "OAM Buffer" (OAM Evaluation)
- Odd ppu cycles set up the OAM Buffer with the value read from Primary OAM.
- Even ppu cycles write the OAM buffer to secondary OAM (even if the object isn't in range of this scanline) unless:
- The OAM Address has overflowed, in which case even ppu cycles will now read from secondary OAM.
- Secondary OAM is full, in which case even ppu cycles will now read from index 0 of secondary OAM.
Dots 257 through 320 read from the "OAM Buffer" in an 8 cycle pattern: (Sprite Fetch)
- There are $20 bytes of secondary OAM. Starting at index 0, these cycles will all read from secondary OAM.
- the secondary OAM address is incremented after the read on cycle 0, 1, 2, and 7 of this 8-cycle-pattern.
Dots 321 through 340 (and dot 0 of the following scanline) will read secondary OAM, index 0. (Idle)
The most important thing to note is that it's fairly common to read the Y position of the final entry in OAM. (set by the blooper in that TAS)
The OAM address is going to overflow long before dot 256, making reads from the final object's Y position more frequent. (The fewer objects there are on the scanline, the sooner the OAM Address will overflow.) We're certainly not guaranteed to read from that object's Y position every time we read from $2004, but it's more common than you'd think. Something like 40%. BRK routine. BRKs and RTIs 1SLO <$03
BRK
BRK
BRK
BRK
BEQ
BRK
BRK
CPX #$F0
BEQ JMP ($6C6C) would jump to $3524. 1TXS opcode into RTI? 1 1
1KIL 1
1 1 1
1
1 
1
1 1
1
1 1 1
1 1
1
1
1
this time the regular dump was what worked 1
1 1
1 1
1 1
1 1 1 1
1
6E : Write $37 to address $6E6E
6F : Write $1A to address $6F6F
7B : Write $50 to address $7B85
7E : Write $01 to address $7E7E
7F : Write $DD to address $7F7F
8C : Write $0A to address $8C8C
8D : Write $20 to address $8D8D
8E : Write $00 to address $8E8E
8F : Write $00 to address $8F8F
99 : Write $20 to address $99A3
9B : Write $00 to address $9BA5
9C : Write $08 to address $9C9C
9D : Write $20 to address $9D9D
9E : Write $00 to address $9EA8
9F : Write $20 to address $9FA9
CE : Write $5D to address $CECE
CF : Write $06 to address $CFCF
DB : Write $9E to address $DBE5
DE : Write $85 to address $DEDE
DF : Write $47 to address $DFDF 
7E : Write $23 to address $7E7F
7F : Write $07 to address $7F80
9C : Write $08 to address $9C9D
9D : Write $20 to address $9D9E
DE : Write $07 to address $DEDF
DF : Write $BC to address $DFE0 
1
9C : Write $08 to address $9C9D 1
1
1 1
5
1
1Player_State, used to run the correct movement subroutine (grounded, jumping, falling, climbing) 1 1 
1 1
1
1
1 1 1 1 1 1 1
1 1
1
1
1 1 1
1 2
1
1 1 1 1 1 1 2
1
1
1
2
1 1 1 1
STY $0090 -> $0090 = 0x2E
LSR $0090 -> $0090 = 0x17
LSR $008F -> $008F = 0x50
STA ($8A,X) -> $0750 = 0xFE
STY $008D -> $008D = 0x2E
LSR $008D -> $008D = 0x17
DEC $008C -> $008C = 0x5F
ISC ($87,X) -> $075F = 0x03
SLO ($87,X) -> $075F = 0x06
ISC ($87,X) -> $075F = 0x07
ASL $00D0 -> $00D0 = 0x06
INC $00D0 -> $00D0 = 0x07
ASL $00CF -> $00CF = 0x70
SLO ($CA,X) -> $0770 = 0x02 1STY $0090 -> $0090 = 0x2E
LSR $0090 -> $0090 = 0x17
LSR $008F -> $008F = 0x50
STA ($8A,X) -> $0750 = 0xFE
STY $008D -> $008D = 0x2E
LSR $008D -> $008D = 0x17
DEC $008C -> $008C = 0x5F
ISC ($87,X) -> $075F = 0x03
SLO ($87,X) -> $075F = 0x06
ISC ($87,X) -> $075F = 0x07
ASL $00D0 -> $00D0 = 0x06
INC $00D0 -> $00D0 = 0x07
ASL $00CF -> $00CF = 0x70
SLO ($CA,X) -> $0770 = 0x02 
STY $0090 -> $0090 = 0x2E
LSR $0090 -> $0090 = 0x17
LSR $008F -> $008F = 0x50
STA ($8A,X) -> $0750 = 0xFE
STY $008D -> $008D = 0x2E
LSR $008D -> $008D = 0x17
DEC $008C -> $008C = 0x5F
ISC ($87,X) -> $075F = 0x03
SLO ($87,X) -> $075F = 0x06
ISC ($87,X) -> $075F = 0x07
ASL $00D0 -> $00D0 = 0x06
INC $00D0 -> $00D0 = 0x07
ASL $00CF -> $00CF = 0x70
SLO ($CA,X) -> $0770 = 0x02 1
2 2 1 1 1
1 1
%0000 0010. There are a lot of read-modify-write instructions to zero page addresses with opcodes ending in 6. That's left + down. 
1
1Absolute to Absolute, X or something similar. Instead of (Indirect, X) you get (Indirect), Y code block 
1
1
2
1
1
1
1 1
1 1
1 1 1 2 1
1 1 1
Use hardware quirks / undefined behavior as a probe
That means:
Different alignments
→ Same inputs
→ Produce different observable outcomes
Your job is:
Use input to detect which alignment you're currently in Different alignments cause:
Missing sprite
Extra sprite
Flicker differences 1 1
Alignment 0: The CPU and PPU cycle are synced to the same master clock cycle
Alignment 1: The CPU clock occurs 1 master clock cycle later than the ppu clock.
Alignment 2: The CPU clock occurs 2 master clock cycles later than the ppu clock.
Alignment 3: The CPU clock occurs 3 master clock cycles later than the ppu clock.
"Alignment 4" would just land in sync again, making it equivalent to alignment 0.
Technically, there are more alignments. Again, the counter for the CPU could be anywhere from 0 to 11 at power on. This forms a 12-phase alignment between the CPU clock and the PPU's VBlank flag being raised for the first time. I'm pretty sure this is the alignment business that threecreepio has talked about the most in the past, as this alignment can result in "VBlank Suppression" occurring or not, resulting in an entire lag frame around power on. This would not affect our TAS though, as the way the replay device works is based on controller strobes, not by counting vblanks. Lag frames are not part of the .r08 file. 1 1 1
1
1
1
1 1 1 1 1 1 ? 1 1 1
1 1 1 1
2
1
2 1
1? one?
DRAW Alignment test is specifically set up with the values that work on my console, so it might not be accurate on yours. But running RMW $2007 should have unique results for each alignments. It will always say "PASS", so you would need to screenshot the debug menu. 
1 ?
1
1 1
2
22064. Take the value from PPU Cycle and add 12, then modulo 341. That tells us what ppu cycle in a scanline this read was on. 1 1 1
1
1 1 1 1 1 1 1 2 1 1
2
1
1
1
1 1 1 1 1 1 1
1 1 1 1
1
1
1
1 1 1 1 1
INY before the SHY $9C9C, X, which would instead write the value 09 instead of 08. 09, then the game won't crash, but the item would stop moving around, which would be a pretty good way to tell that we landed on dot 235.
1
1