Screen tearing with JTS16B July 8th update

[Lagerfeldt]

Problem description Screen tearing in the upper part with JTS16B games such as Alien Syndrome (about 5 or 10% down from the top of the screen) and Sonic Boom (=left side, when screen is pivoted). Does not happen with JTS16(A) or any other cores. See screenshot. IMG_1666.HEIC.zip

Occurrance Constant. Since latest (early July) update. Did not happen earlier. No other changes to the setup or equipment used.

Other facts All other cores and games work, including ones with odd frequencies slightly over 60 Hz, such as Donkey Kong. Only JTS16B has this problem after the last update. Alien Syndrome 16A version works fine - only 16B is affected

I understand this issue does not necessarily mean the core itself has an error, but that something else is at play with some combination after the last build (re. MegaSys1 recent issue).

INI changes tested · Different custom video modes. Calculated mode. No difference. · Unique modes per PAL and NTSC. No difference.

Workaround Change refresh max rate to 60 Hz (bypass/uncomment will not work - it needs to be set to 60 to workaround) or change vsync adjust to 1, which causes a bit of lag.

Screens purchased and tested · Eizo F2456 FlexScan 1920 x 1200 @ 49-61 Hz screen · Asus PA248CRV 1920 x 1200 @ 48-75 Hz screen with and without MediaSync VRR · Asus PA248QV 1920 x 1200 @ 48-75 Hz screen with and without Adaptive-Sync VRR · AOC G2790VXA 27" 1920 x 1080 @ 144Hz screen with AMD FreeSync Premium VRR

All screens and VRR settings had no effect on the problem.

Cables tested 4 different high speed HDMI-HDMI cables + Delock USB-powered HDMI-DisplayPort cable. No difference.

Machine used Ultimate MiSTer BlisSTer Pro (2022)

MiSTer version and [OS] MiSTer V230716, OS V230501

Only updated using Update All script. No manual changes to the system or files AFAIK. Standard setup.

INI file attached as requested. MiSTer.ini.zip

[Lagerfeldt]

Yesterday tried a complete re-install of MiSTer on a new SD-card. Problem persists with JTS16B.

[jotego]

Thank you for the detailed report. I cannot see any tearing when testing on a cheap EYOYO screen, but my more expensive Sony TV does show tearing via HDMI. I do not see tearing either when using the analogue output of a MiST device.

I believe there is not much I can do from the core side. I reckon this is a generic HDMI/MiSTer issue and it would not occur on a CRT screen or maybe even if you take the analog VGA output and connect it to a LCD screen. As the MiSTer framework evolves and cores are recompiled to match the latest version of MiSTer files, behavior may change.

There is a new video-related release planned for MiSTer files, as described in #500. I will update all cores then, and hopefully this will change.

That is all I can do.

[Toryalai1]

Did you try to enable VRR on mister and did you have vsync_mode=2?

[Lagerfeldt]

Hello,

Thanks for your replies.

Yes, VRR on or off makes no difference to this issue. I’ve tried with four screens now, including three with VRR and one without.

Yes, I’m using vscync mode 2.

It’s certainly an issue that only occurs from this specific core release and onwards, i.e. reverting the core version will fix the problem: Older core = no problem. Newer core (JTS16B july 8th update) = problem.

The version of MiSTer does not play a part in this matter per se.

I’ve tried with four screens, several HDMI cables and DisplayPort, with VRR on and off, and with several MiSTer installs - the problem prevails with these newer core version, but works with the older core version.

For this reason logic dictates that it’s something in the way the core and MiSTer/HDMI/etc. play together.

This doesn’t mean something is done incorrectly in the core or that the problem isn’t related to the way the MiSTer handles things, but it’s a fact that it would be possible to find out what is causing this problem based on the changes between the July 8th update and the previous version.

I understand if this is not a high priority problem, I appreciate all the work that goes into this under all circumstances.

Regards,

Holger

-

Holger Lagerfeldt Audio Alchemist

Tel. +45 26 799 003

@. @. @.***

-

Platinum Audio Group

On 20 Jan 2024, at 08.15, Toya @.***> wrote:

Did you try to enable VRR on mister and did you have vsync_mode=2?

— Reply to this email directly, view it on GitHub https://github.com/jotego/jtcores/issues/313#issuecomment-1901835633, or unsubscribe https://github.com/notifications/unsubscribe-auth/A7CY7P65Q6CFKVARIN7WPLTYPNVKDAVCNFSM6AAAAAA2R3TVZ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBRHAZTKNRTGM. You are receiving this because you authored the thread.

[jotego]

Thank you for the detailed checks.

There is a part of the MiSTer logic (here that goes directly compiled in the core. So even if the core logic does not change, you can get changes to the video signal path. Recently, cores got an update for the composite output in this way. Only the MiSTer logic was updated while the core logic remained the same.

This must be happening to more cores in MiSTer. If you identify one in the main MiSTer repository sensitive to this, the MiSTer maintenance team may look into it.

I will review the files on the next MiSTer template update, expected soon, just in case there is something not copied over correctly.

[Lagerfeldt]

I see, that could explain it.

It also happend with the Rod-Land core, but this was fixed (at least at some point it was fixed in a copy to me).

Thanks again

-

Holger Lagerfeldt Audio Alchemist

Tel. +45 26 799 003

@. @. @.***

-

Platinum Audio Group

On 20 Jan 2024, at 15.08, JOTEGO @.***> wrote:

Thank you for the detailed checks.

There is a part of the MiSTer logic (here https://github.com/MiSTer-devel/Template_MiSTer that goes directly compiled in the core. So even if the core logic does not change, you can get changes to the video signal path. Recently, cores got an update for the composite output in this way. Only the MiSTer logic was updated while the core logic remained the same.

This must be happening to more cores in MiSTer. If you identify one in the main MiSTer repository sensitive to this, the MiSTer maintenance team may look into it.

I will review the files on the next MiSTer template update, expected soon, just in case there is something not copied over correctly.

— Reply to this email directly, view it on GitHub https://github.com/jotego/jtcores/issues/313#issuecomment-1902104881, or unsubscribe https://github.com/notifications/unsubscribe-auth/A7CY7P7VGYII2PQP37OWBP3YPPFVDAVCNFSM6AAAAAA2R3TVZ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBSGEYDIOBYGE. You are receiving this because you authored the thread.

[Toryalai1]

@jotego maybe it is better to check with sorg first if the template changes are final. Doesn’t hurt to update though

[jotego]

@Lagerfeldt please try again after today's update. A missing connection to the HDMI chip was discovered this week. It might be related to your issue.

[Lagerfeldt]

Confirmed! This is now fixed with JTS16B. <3

Similar problem still persists in SNK68 (Ikari Warriors III) and Alpha68K (Time Soliders), but I’m very pleased to see it’s fixed in JTS16B.

- Holger Lagerfeldt Audio Alchemist

Tel. +45 26 799 003

@. @. @.***

- Platinum Audio Group

On 9 Feb 2024 at 15.55 +0100, JOTEGO @.***>, wrote:

@Lagerfeldt please try again after today's update. A missing connection to the HDMI chip was discovered this week. It might be related to your issue. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[JanGunheD]

I am using version V8533440 and it also happens to me. Any core internal "scandoubler fx" or core internal "scale" setting other than "normal" solves the problem.

I use "vsync_adjust=2".

[Lagerfeldt]

Yes, this problem is back again.

[jotego]

I updated the mister framework to work with the new IO boards. That might have fixed this (again). Could you test this file: jts16b.rbf.zip?

[JanGunheD]

I updated the mister framework to work with the new IO boards. That might have fixed this (again). Could you test this file: jts16b.rbf.zip?

Yes, that fixes it.

[jotego]

Thanks for testing it. I'll close the issue then. The new files will be distributed on Friday.

[jotego]

This may -or may not- have reappeared again this week. I found the root cause and fixed it for good here. From the next update, it will be robust.