Horizontal tearing running from bottom to top at 50Hz with core 20220105

[Threepwood]

I encountered this issue with the latest version of this core, anybody else experiencing this when the region is set to EU?

https://github.com/MiSTer-devel/Genesis ... issues/201

[kalach.x]

I saw tearing when using scaler few times already with different cores. I always use vsync_adjust=2.

I never investigated source of the tear though, and I assumed I changed aspect ratio too much... or too little as it also disappeared when changing aspect ratio. When I saw it on LCD I feared my LCD didn't keep up but I also saw similar tear on CRT. Though while playing Sharp x68000 512p game on 15KHz CRT which is hardly supported configuration

It did look different though, not rolling like in the video but stayed somewhere in the middle of the screen almost constant suggesting scaler output got synchronized somehow with input video.

What video_mode do you use? And on what kind of display?

This commit https://github.com/MiSTer-devel/Genesis ... 59f64d702d is most likely a cause or this https://github.com/MiSTer-devel/Genesis ... 09ea4b544c

Monitors and especially modern TV sets might not be able to handle all video modes and might introduce stuttering or tearing. Some times very minuscule differences do make a difference.

Imho making version of the core that supports incorrect timings doesn't make any sense and even making option for it (at least if this is not super wide spread issue) but thankfully you can always build your own core using free version of Quartus software, first commenting offending lines Unlike typical open source project you do not even need to worry about any external dependencies. Just build time is horrendous, and especially on older laptop you might want to finish few NTSC games while the core is cooking

[Threepwood]

What video_mode do you use? And on what kind of display?
might want to finish few NTSC games while the core is cooking

In general I use vsync_adjust=2 on all my screens and on my Samsung 4k TV that shows the rolling tear I use the standard video_mode=8 (for NTSC) and 9 (for PAL). No core so far has caused me trouble on my TV, no tearing ... nothing. So it is very forgiving already.

This commit https://github.com/MiSTer-devel/Genesis ... 59f64d702d is most likely a cause or this https://github.com/MiSTer-devel/Genesis ... 09ea4b544c


Monitors and especially modern TV sets might not be able to handle all video modes and might introduce stuttering or tearing. Some times very minuscule differences do make a difference.

Yes, I too assume that PAL Master Clock adjustment to be the culprit. But the slight drop in refresh rate does not explain why I can only see the tearing on parallax scrolling that is induced by user input. If I just let the title screen of Sonic 2 loop or stand still in a level, I never noticed it. I cannot say for sure that there are no glitches in games like After Burner II or Space Harrier, but I could never make out a rolling tear in the image.

Vertical Crop makes it worse, by the way, there is still some brief tearing when it is off, but it is not rolling like this from bottom to top. I would not be surprised if interally something is now out of sync in the core, but the more I am surprised that I don't get the same issue on my Eizo. Anyways, all guesswork at this point. I wished I could measure if the refresh rate changes during gameplay.

Imho making version of the core that supports incorrect timings doesn't make any sense and even making option for it (at least if this is not super wide spread issue) but thankfully you can always build your own core using free version of Quartus software, first commenting offending lines Unlike typical open source project you do not even need to worry about any external dependencies. Just build time is horrendous, and especially on older laptop you might want to finish few NTSC games while the core is cooking

That depends on wether or not the Mega Drive was really running spot on at 50 Hz. If I knew enough about measuring video signals with an oscilloscope, then I would stick a probe into my real, unmodified PAL Mega Drive to see what the video signal is like. Thus I don't want to claim that the video signal is now not more correct than before.

Setting refresh_min=50 and refresh_max=60 circumvents the issue of course, but it disables vsync.

thankfully you can always build your own core using free version of Quartus software, first commenting offending lines Unlike typical open source project you do not even need to worry about any external dependencies. Just build time is horrendous, and especially on older laptop you might want to finish few NTSC games while the core is cooking

You are reminding me that I wanted to install Quartus again ...

[kalach.x]

I have most fun with Quartus. Even more than I have with games

Regarding video mode you might want to try changing video mode used.
1920x1080 != 1920x1080 as far as scalers are concerned because other than visible stuff you also have different amounts of blanking/synchronization lines. Adding/removing line or three might resolve your issue.

BTW. To get perfect synchronization of output video from scaler and incoming video data from simulated console you have to make sure console starts drawing stuff when scaler is outputting. It is not as trivial as setting vsync_adjust=2 + set any resolution and scaling mode and you will get nice synchronization with at most 4 lines of input lag. It cannot work like that. Of course lag can be very small, also counted in lines but what is it depends on how clever scaler is written. From experience I can tell you that while it seems to be cleverly written it is not always working correctly. I do get tear lines in certain video modes and since I test it on VGA CRT I can be sure this isn't CRT scaler issue.

[FoxbatStargazer]

Try video_mode_ntsc=8 and video_mode_pal=9 for increased compatibility. Mode 9 uses more blanking that is more standard for PAL and some displays interpret it better.

[kalach.x]

Try video_mode_ntsc=8 and video_mode_pal=9 for increased compatibility. Mode 9 uses more blanking that is more standard for PAL and some displays interpret it better.

I second that
My plasma doesn't even want to run at video_mode=8 with vsync_adjust=2 and displays garbage if I do not add exception for pal to use video mode 9 but if I do that then it mostly runs great. Not in all cores/modes because eg. Dendy mode on NES core has some issue and I see frame skipping even though PAL work ok and the same video mode works correctly on my LCD monitor and CRT without frame skipping indicating obvious TV not liking the timings issue.

Little hint for video modes:

cru.jpg (108.24 KiB) Viewed 5640 times

If you get program Custom Resolution Utility then when you run adding video mode you can define timings and you can pretty much directly write values to mister.ini
video_mode={horizontal active},{horizontal front porch},{horizontal sync width},{horizontal back porch},{vertical active},{vertical front porch},{vertical sync width},{vertical back porch},{pixel clock}

The pixel clock you need to convert from MHz to KHz so for screenshot example 123.75 becomes 123750. The value here is not very exact because of precission but actually this value doesn't matter as much when you use vsync_adjust=2 and having it correct is only to not stress TV/monitor too much because it takes some time for scaler to detect vertical synchronization and recalculate its pixel clock.

Usually issues stem from vertical parameters and you might want to add or remove a line or two from standard mode.

There are probably better tools/method but CRT is must have tool for PC and I am used to it hence the recommendation. Especially useful when defining video modes for VGA CRT monitors