Alrighty, I've not seen any bugs and I'm pretty sure my routines are all optimized (or good enough anyway...)
I just want to know if there's a way to test on a frame-by-frame basis how much vblank/CPU was used to get an idea of how well I coded something.
I've heard of something like breakpoints with FCE XDSP (whatever it's called), but have no idea how to actually do those.
So, what can I do and is there anything I should be looking for?
I hope the post makes sense.
In Nintendulator, you can put a break point on the NMI address. Then put a break point on the RTI from your NMI. Then you could see what cycle and scanline NMI starts and when it finishes up. This would let you see how much time you used and what was left.
Or just turn on monochrome mode right before you start your vblank wait code, then you see what percentage of the screen is not grayed
Wouldn't that show how long past VBlank he went? If he's in VBlank, then no grayed lines would be drawn right?
Are you just wanting to see how long something took that you execute in Vblank?
Well if so, execute that same peice of code outside of Vblank and do the monochrome thing. If you do writes to $2006/$2007, or any other register that can't be written to outside of Vblank without screwing things up, just change those $200x writes to some other non-zero-page address; it'll take the same amount of time.
Yeah, if you want to know long in the frame you're working and how long you're waiting the monochrome bit tricks is really great (almost make me think this bit was made for this purpose).
If you want to test your code in VBLank how long it takes then I can see no other chose than using Nintendulator's tracer and/or breakpoints (FCUXD too but it's less accurate).
If you're afrait your updates takes too long you could as well turn the emulator in PAL mode, and see it that works. If it works on PAL, but not NTSC, chances are that you are taking too much time in VBLank.