vblank and vsync stats

[ZacharyScolaro]

I would like for the FPS overlay (F7) to include the low-water and high-water marks for vblank and vsync enable and disable as well as the last scanline that each one took place. It would also be great if there's a way to configure it to always break when there is any variance in either signal. I don't know if there are any games that use vblank to selectively blank out lines mid screen. It may be good to only count the first disable of vblank after vsync and the last enable of vblank before vsync just in case.

This would make it easier for game developers and publishers to verify that the vsync and vblank signals stay consistent throughout all screen transitions in a game.

[JetSetIlly]

I would like for the FPS overlay (F7) to include the low-water and high-water marks for vblank and vsync enable and disable as well as the last scanline that each one took place.

It's a great idea. The FPS overlay might get very busy though so I think we'd need some way of configuring what appears on it.

I don't know if there are any games that use vblank to selectively blank out lines mid screen.

There are. Custer's Revenge and a version of Donkey Kong by Andreas Dietrich both use VBLANK as a cheap way of outputting black. It's a neat trick but it's not clear to me if every TV likes it - but that's a discussion for another day.

only count the first disable of vblank after vsync and the last enable of vblank before vsync just in case.

Yes. I keep track of this in the television "resizer" code.
https://github.com/JetSetIlly/Gopher2600/blob/master/hardware/television/resizer.go

This code tries to find the best framing for the TV image, the most important element for framing is the top and bottom VBLANK.

This would make it easier for game developers and publishers to verify that the vsync and vblank signals stay consistent throughout all screen transitions in a game.

I agree. One of my goals for the Timeline window was to visually show historic information of this nature. At the moment it doesn't show VSYNC and VBLANK information but I could easily add it I think. It does show scanline count information, which is related I suppose. In the example below the red line shows the jitter

Something similar to that but tracing the limits of VBLANK.

It would also be great if there's a way to configure it to always break when there is any variance in either signal.

There's a BREAK JITTER command which breaks execution whenever the refresh rate changes. I could add something similar for whenever VBLANK position changes.

I'm thinking a BREAK FRAMING command would be good.

I'll have to think about how to watch for changes in VSYNC but it would be something similar I think.

[JetSetIlly]

I've not forgotten about this. I'm working through a list of code refinements that I've been meaning to make. It should make adding this sort of thing easier.

[JetSetIlly]

I'll be looking at this today. First attempt is quite simple. Max extent of top and bottom values of both VSYNC and VBLANK. These values are only set once the screen has settled down after ROM startup

I'll put in the break to debugger option if any of these values change. But I'm wondering how to present these numbers so that it is clear whether the values are the current values. I'm thinking maybe an icon, showing that the values are now, or have in the past, been different. The debugger can show details of where and how the values were different.

Is this what you had in mind?

[ZacharyScolaro]

Yeah, that looks great. An icon would be good. You might also consider changing the font color to red when there was a deviation.

When debugging the main thing to understand will be what the value was previously, and where in the code the deviation started. As long as the information in the screenshot is available when the debugger has hit the breakpoint, I think the breakpoint is all that's really needed here.

[JetSetIlly]

I've rewritten how the television handles the VSYNC signal. The results are in the latest release https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.32.0

The changes should make it easier to add debugging information with regards to VSYNC and VBLANK. I'll start work on that this weekend.

[JetSetIlly]

television_halts branch shows work so far. VSYNC stats and "halting conditions" are working but I've not finished the VBLANK equivalent yet.

Video here https://youtu.be/2GOA_Ir18EQ

Demonstration ROM is Snow White, which has very bad VSYNC programming and so is a good test case.

Things to notice in the video:

1. Overlay show VSYNC data scanline and scanline count
   1a. This is instead of the start and end scanline. I thing the count is clearer
2. The bug icon indicates that the VSYNC profile has changed since it first stablised
   2b. You suggested colour but I wanted to avoid that if possible
3. The screen rolls & jitters and the VSYNC data changes
4. The debugger is activated at 13 seconds into the video
5. The timline shows a new VSYNC trace (in white). Mouse hovering shows the VSYNC information for a specific frame
6. Playmode is resumed and the game reset at 25 seconds into the video
7. Halting conditions for the television are enabled
8. This time, the debugger is activated automatically
9. The menu bar now includes a reason to indicate why the debugger was enabled

[JetSetIlly]

I've added the VBLANK statistics to the overlay. Top and bottom indicated by icons. I hope that's clear enough.

The tick icon is a reintroduction of an old idea that had removed some time ago. The tick indicates that the VBLANK values are exactly as recommended by Atari in the Stella Programmer's Guide

[JetSetIlly]

I should also add that the bug icon will appear if the top/bottom values change once they've reached stability after startup

I've also checked that the top/bottom values are correct for ROMs that monkey with the VBLANK during the visible part of the screen.

[JetSetIlly]

These changes have been merged into the master branch and are part of the v0.33.0 release