Developer Mode update for bad VSYNC

[SpiceWare]

AtariAge user Cisano wrote a game and tested it using Developer Mode.

Everything looked fine in Stella, but during the Exclusive Premier on ZeroPage Homebrew the picture jumped around.

He posted the ROM here and alex_79 figured out it was due to an incorrectly done VSYNC:
https://forums.atariage.com/topic/342563-invaders-from-andromeda-beta/

Stella should show similar image jumping issues if VSYNC isn't done correctly.

ROM
InvadersFromAndromedaBETAV0.9-byCisano-2022-NTSC.bin.zip

[thrust26]

That's already emulated, see Developer settings/Video/Jitter/roll effect/Sensitivity.

It did not show during development because the default sensitivity is set to 8 for Developer mode. This requires at least 174 VSYNC cycles, which is fine for most CRTs. Sensitivities 9/10 require 200/228 cycles. The game does 200, so it will roll in Stella only at sensitivity 10.

If we set the default to 10, many games will roll in Stella but work perfect on real hardware. What would you suggest here?

[SpiceWare]

Awesome, didn't realize that adjustment handled this issue.

Considering developer mode is normally used while creating new games, and they often premier on ZPH which is susceptible to this VSYNC issue, I think it would make sense to change the default to 10. Otherwise the programmer won't know their code has this issue until during the premier itself, which is not a great time to find out about it.

[thrust26]

I agree. However 10 is really sensitive, even the slightest deviation will trigger here. It is not only checking minimal VSYNC lengths, but also VSYNC length changes and scanline changes. We know that ZPH is very sensitive, but we do not know the exact tolerance (if any). Going to extreme sensitivity might be too much, if you test with 10, you will find a lot of games rolling.

Maybe still better safe than sorry?

[ale-79]

What about adding an indicator to the console info overlay?

E.g. display "VSYNC" in red each time any deviation from the standard 3 lines VSYNC is encountered.

[thrust26]

You mean also more than 3.00 scanlines?

[ale-79]

Yes, and also in case it doesn't start at the beginning of the line. It wouldn't break existing the games, so I guess it could be very strict.

[thrust26]

Why above 3.00? Do you know any examples where this caused trouble?

[ale-79]

I imagine some TVs might not like too long VSYNC pulses as well, but I haven't actually tested or investigated it.
I think it would just be better to alert whenever any deviation occurs, and have developers of new games stick to the exact specs.

[thrust26]

But exact specs would e.g. mean 262 scanlines and nothing else. A restriction which is only coming from modern hardware.

[ale-79]

With exact specs I was only referring to VSYNC: 3 full scanlines like those generated by the VERTICAL_SYNC macro.

[thrust26]

I know, but why would you want to be strict only for VSYNC? Seems arbitrary.

[ale-79]

Because while varying the number of scanlines compared to the standard might have a purpose, to get more cycles for calculations, I see no point in generating an off-spec VSYNC pulse when developing a new homebrew. You risk compatibility issues without getting any advantage.

Plus, it would only be an indicator. If someone is messing with VSYNC timing for a reason (e.g. interlacing), he can just ignore it.

[thrust26]

I will think about it... 😈

[thrust26]

For now I have implemented with +/- 3 cycles tolerance (6cbb06b). That's because many games which are known to work on modern hardware (e.g. ZPH) need this. Many even use a larger tolerance and still worked for ZPH (see the 45th anniversary marathon). And three cycles allow adding one instruction before VSYNC, which is frequently used. Maybe I will increase the tolerance a bit.

Anyway, a red "VSYNC!" is displayed instead of "Developer" in the console info overlay if the length is outside the tolerance.