Welcome, this is the discussion board of TASVideos.
There are 2 TAY's here that aren't moving A to Y, a jump to $0029 that I can't tell where it's coming from, and execution jumping from 3C8C to 3C9E on the 87 instruciton (which is just supposed to AND X and A.) I read in the original publication of this branch by MUGG that the glitch itself is console verified, but on a different level. Is the glitch console verified on this level?
c64248952 A:7E X:FF Y:62 S:FC P:nvUBdizc $3C78:A8 TAY c64248954 A:7E X:FF Y:62 S:FC P:nvUBdizc $3C7A:10 00 BPL $3C7C c64248957 A:7E X:FF Y:62 S:FC P:nvUBdizc $3C8C:87 UNDEFINED c64248960 A:7E X:FF Y:62 S:FC P:nvUBdizc $3C9E:23 UNDEFINED c64248963 A:7E X:FF Y:62 S:FC P:nvUBdizc $3CA0:A8 TAY c64248970 A:7E X:FF Y:62 S:F9 P:nvUBdIzc $0029:48 PHA
I stopped at $3C3F because that's where the code differs. $3C3F is a mirror of $2007 which is the PPUDATA register. The important part here is the fact that we're not in VBlank (the part of the frame where the scanline laser reverts back to the top left of the screen), and reading PPU registers when not in VBlank will give us strange values, values used by the PPU drawing pixels on the screen. What does this tell us? It means two things: 1. Changing the pixels on the screen could change the results of the glitch. 2. Changing the time at which $3C3F is executed could change the results of the glitch. And how do you change the timing? Exactly! Different button presses lead to different branch paths in the button processing code and thus lead to different timing. This also means that it's possible to exchange different buttons (assuming they both aren't accessed beyond the processig) and still get the credits! (Which is confirmed to work.) Most importantly though, which timing do we need now? The problem is that even small cycles amounts can and will change the outcome completely, so I wrote a bot that tries every single cycle (to like +300, because we won't be able to change it much more). The only cycles it found was the one we already got, and this one, which resets you to the start of the room. The one we already got requires so many buttons, and changing buttons before the frame with the mandatory Start barely changes the cycles, so it won't be possible to reduce that two frame input to a single one. At least not without changing the pixels on the screen, which is what I'm trying currently.  - You might have seen that $3C37 is also a mirror of $2007, but it seems like the first read of that register (including mirrors) in non-VBlank gives you a stable 00.
3C37: 00 BRK <BRK> 3C39: 00 BRK <BRK> 3C3B: 00 BRK <BRK> 3C3D: 00 BRK <BRK> 3C3F: