ReaperSMS wrote: ↑
Fri Dec 06, 2019 10:00 am
Short answers: Yes, yes, and yes.
Technically you count from either RESET or power on, and there's the question of counting CPU clocks, master clocks, or PPU dots, but where you come down on that depends on how accurate you are trying to be.
More or less every game is going to start with two of those vb: LDA $2002 / BPL vb busy waits before they start executing the rest -- Big N said you had to, and the PPU needs some warmup time to get everything in order, and ignores anything you send before it is ready. Two vblanks guarantees it is ready.
I read the documentation and came to these conclusions:
1) I can only think of counting clock cycles from the first instruction. As I increment the clocks cycles when reading an instruction, I would just keep switching between the bpl and the lda instruction until the cpu clock cycle where the seventh bit of the ppu status register changes to one.
2)I mentioned before here 241*113.667 cpu clock cycles. Honestly I do not remember from where I took these numbers, nonetheless, this link: http://wiki.nesdev.com/w/index.php/PPU_frame_timing
mentions 341*262/3 = 29780 2/3. It says
If the CPU checks the VBL flag in a loop every 29781 clocks, the read will occur one PPU tick later relative to the start of the frame each frame, until at some point the CPU "catches up" to the location where the flag gets set. At this point, the CPU and PPU synchronization is known down the PPU tick.
Does this have some immediate impact to what I intend to achieve (leave the bpl-lda loop and resume the execution of the other instructions) ? If not, will cause trouble in the future, to the point I will have to change this checking?