It is nothing very fancy, I just checked the currentCycles variable on the line renderer, and spit it out along with the line number by scanline_count (just from memory, something like that) when it didn't match 1820. Of course the graphical way is in general more useful once you are actually devving a game, just working on the video mode with test codes doesn't seem to need it to be graphical that much. It may also be quite a CPU hog (flooding the console) when every line mismatches (say, you got consistent 1821 cycles since you were fooled by an rjmp after and sbrs in your counting somewhere).uze6666 wrote:But a console way is good too if you found a good way to display it. May I suggest you then add your code in your branch and enable it via the 'z' switch? Me and CunningFellow also need such functionality when working
on video modes.
It should wait a bit though. My current big performance bump needed a change again in the way that part works, so when integrating that, the count of cycles the line took will need to be calculated differently.
Doing it proper the other edge of HSYNC may also be interesting as an optional feature. In graphics modes it is not so much since it is governed by the audio code, but if you want to touch that part (the inline mixer), it could be handy.