So it seems that $0000a5 always comes from the same two scanline counter variables. I'm confused about a few things though:
80e3d9 bne $e3e2 [80e3e2] A:0048 X:0005 Y:f06c S:1ff4 D:0000 DB:80 nvMxdiZc V: 74 H: 68
80e3db pla A:0048 X:0005 Y:f06c S:1ff4 D:0000 DB:80 nvMxdiZc V: 74 H: 80
80e3dc adc $a5 [0000a5] A:0049 X:0005 Y:f06c S:1ff5 D:0000 DB:80 nvMxdizc V: 74 H: 106
80e3de sta $a5 [0000a5] A:0000 X:0005 Y:f06c S:1ff5 D:0000 DB:80 nvMxdiZC V: 74 H: 126
80e3e0 bra $e3e3 [80e3e3] A:0000 X:0005 Y:f06c S:1ff5 D:0000 DB:80 nvMxdiZC V: 74 H: 146
80e3e3 lda $a5 [0000a5] A:0000 X:0005 Y:f06c S:1ff5 D:0000 DB:80 nvMxdiZC V: 74 H: 164
That's what happens if you don't take that bne $e3e2 branch in the first code I posted, and...
80e3d9 bne $e3e2 [80e3e2] A:0003 X:0050 Y:c963 S:1ff2 D:0000 DB:80 nvMxdizc V:259 H: 810
80e3e2 pla A:0003 X:0050 Y:c963 S:1ff2 D:0000 DB:80 nvMxdizc V:259 H: 828
80e3e3 lda $a5 [0000a5] A:0003 X:0050 Y:c963 S:1ff3 D:0000 DB:80 nvMxdizc V:259 H: 854
That's what happens if you do. So, can anyone explain to me what's at address 80e3e2? As I understand it, if you have BRA $e3e3 at 80e3e0 then your ROM looks like this:
80e3e0 - 80 (BRA)
80e3e1 - e3
80e3e2 - e3
Yet when we branch directly to 80e3e2 we get PLA, which is $68. Shouldn't it be a Stack Relative SBC ($e3)? Anyways. If you take that branch you simply skip the part where you add the vertical scanline counter to a5, ie/ you only add it if it's an even number.
EDIT: Hey me from the past, it's me from the future. Yeah I can answer that: Branches are relative, so the $e3e3 isn't actually in the ROM. The ROM goes like 80 01 68.
I still don't get how the counters work though. For example:
80e3c4 lda $213c [80213c] A:0021 X:0050 Y:c963 S:1ff3 D:0000 DB:80 nvMxdizc V:259 H: 596
80e3c7 pha A:0094 X:0050 Y:c963 S:1ff3 D:0000 DB:80 NvMxdizc V:259 H: 620
80e3c8 lda $213c [80213c] A:0094 X:0050 Y:c963 S:1ff2 D:0000 DB:80 NvMxdizc V:259 H: 640
80e3cb pla A:0094 X:0050 Y:c963 S:1ff2 D:0000 DB:80 NvMxdizc V:259 H: 664
Both reads return $94 which is 148, while H is at 596 and 640.
80e3d0 lda $213d [80213d] A:00b7 X:0005 Y:f06c S:1ff5 D:0000 DB:80 NvMxdizc V: 73 H:1352
80e3d3 pha A:0049 X:0005 Y:f06c S:1ff5 D:0000 DB:80 nvMxdizc V: 74 H: 12
80e3d4 lda $213d [80213d] A:0049 X:0005 Y:f06c S:1ff4 D:0000 DB:80 nvMxdizc V: 74 H: 32
80e3d7 bit #$01 A:0048 X:0005 Y:f06c S:1ff4 D:0000 DB:80 nvMxdizc V: 74 H: 56
In this one, first read of the vertical scanline counter returns $49 which is 73, okay. Second read, after it has incremented to 74, returns $48....
80e3d0 lda $213d [80213d] A:0094 X:0050 Y:c963 S:1ff3 D:0000 DB:80 NvMxdizc V:259 H: 730
80e3d3 pha A:0003 X:0050 Y:c963 S:1ff3 D:0000 DB:80 nvMxdizc V:259 H: 754
80e3d4 lda $213d [80213d] A:0003 X:0050 Y:c963 S:1ff2 D:0000 DB:80 nvMxdizc V:259 H: 774
80e3d7 bit #$01 A:0003 X:0050 Y:c963 S:1ff2 D:0000 DB:80 nvMxdizc V:259 H: 798
And when V is 259, reading 80213d gives 0003... As in 256+3? And the start of this block always has that useless read of 802137 "SLHV - Software Latch for H/V Counter" first. I'm guessing that's just some prerequisite for reading the counters?
Anyways. I think you can forget my earlier optimism about this being easily predictable. Seems like it could be next to impossible to predict what part of what scanline this block will fall on...
For the purposes of TASing at least I've got a variety of input combinations on and before the frame I need, so hopefully I can provoke one every time without having to sacrifice frames for it. I just really hope there's no artificial limitation put on it like it not happening twice inside the same battle or something.
And just for the record I also know that 009473 and 009474 are involved somewhere down the line, since you can screw with the results by freezing them. If you freeze 9474 you can end up getting the bounty of drops but not just restricted to jade, and freezing them both tends to make the outcome stay the same.