It turns out that "RD Step 3" does not require a matching PPU address, or even a PPU address in range. In fact I set PPU address to 0x0000 and it still did the big loop around to the top. This finding removes 1 of the arrows from the diagram.
I have checked all arrows now and I believe that this diagram is correct. Additional things not shown or tested in this diagram:
- Any potential interaction with PPU /WR (none known)
- Reading from each of the 2 V-blank interrupt vector bytes from each of the 6 green boxes
- Any interaction with SL3 (pin 98), I am completely clueless on this one.
I added the v-blank FFFA/B reads to the diagram. To make the arrows lay out better, I moved RD step 0.
Testing FFFA/B in each state divulged an interesting new connection from the 3rd /RD delay state back to the initial state. Normally, from state "RD step 3", falling edge of /RD always leads a 'good' sequence of green boxes (regardless of PPU address range), after which, another good or bad sequence of green boxes must also occur. However, if you sneak in a read from FFFA/B in "RD step 3", then it then it DOES matter if the PPU address is in range. It can go directly to the bad sequence of green boxes. This observation corresponds to a state change to the initial state.
The diagram did get a little more busy with the FFFA/B stuff added, but no previous findings were changed.
There is still more going on here with reading $FFFA/B. Say that I am in a "step 0" green box. The PPU address is in range and I don't touch it. Then I read CPU bus FFFA. I switch the CPU bus back to reading the status register and the status bit went to 0, as expected. Then on the 3rd falling edge of PPU /RD, the status gets set again. Coincidentally, this is the same spot it would have been set again going through the normal process of /RD delay had none of this ever happened, which leads me to believe the /RD delay states operate independently of what is going on elsewhere in this diagram. I tested this by reading FFFA within a "step 1" box. Now it was the 2nd falling edge to set the status again, which again coincides where it would have been set with normal /RD delay. I think this proves that the state of the RD delay must be operating independently from the other stuff that is going on.
I am thinking that this is going to blow up a little more complicated until we start to notice more patterns, then we can simplify it back down into its more general state of existence. I really truly believe that this is just a counter or two and some gates.