vscale_mode=2 instability?

[zakk4223]

I was testing various cores and came across something odd with all the Scramble based cores:

If I run vscale_mode=2 and video_mode=8 (1920x1080@60Hz) it doesn't work with any HDMI display or capture device I own. If I run 1280x720@60hz it works on all of them. If I run mode 12 (1920x1440@60) it also works on all the devices capable of displaying 1440p.

If I run mode 9 (1920x1080@50hz) it works properly on every device I have.

I started trying old versions of the RBF. I discovered if I run the release 20200205 it works perfectly with vscale_mode=2 and video_mode=8

On the core versions that don't work, the symptom is that nothing seems to be able to 'lock' to the video signal. It constantly blinks on and off.

This is the Main_Mister output when using 1080p@60hz

INFO: Video resolution: 256 x 224, fHorz = 16.0KHz, fVert = 60.6Hz, fPix = 6.14MHz
INFO: Frame time (100MHz counter): VGA = 1649999, HDMI = 1666666
Set vertical scaling to : 896
adjust_video_mode(1649999): vsync_adjust=2.
FileOpenEx(open) File:/media/fat/config/scramble_gamma.cfg, error: No such file or directory.
FileOpenEx(open) File:/media/fat/config/scramble_scaler.cfg, error: No such file or directory.
Send HDMI parameters:
video: 1920(1920), 88(88), 44(44), 148(148), 1080(1080), 4(4), 5(5), 36(36), Calculate PLL for 150.0001 MHz:
Fvco=450.000273, C=3, M=9, K=0.000005 -> K is outside allowed range
Fvco=600.000364, C=4, M=12, K=0.000007 -> K is outside allowed range
Fvco=750.000455, C=5, M=15, K=0.000009 -> K is outside allowed range
Fvco=900.000545, C=6, M=18, K=0.000011 -> K is outside allowed range
Fvco=1050.000636, C=7, M=21, K=0.000013 -> K is outside allowed range
Fvco=1200.000727, C=8, M=24, K=0.000015 -> K is outside allowed range
Fvco=1350.000818, C=9, M=27, K=0.000016 -> K is outside allowed range
Fvco=1500.000909, C=10, M=30, K=0.000018 -> No exact parameters found
Fvco=450.000000, C=3, M=9, K=0.000000(1) -> Fpix=150.000000

PLL: 0x4, 0x20504, 0x3, 0x10000, 0x5, 0x20201, 0x9, 0x2, 0x8, 0x7, 0x7, 0x1, Fpix=150.000000
sending keymap: 0
INFO: Video resolution: 256 x 224, fHorz = 16.0KHz, fVert = 60.6Hz, fPix = 6.14MHz
INFO: Frame time (100MHz counter): VGA = 1649999, HDMI = 1643822
Set vertical scaling to : 896

This is the output when using 1080p@50hz

INFO: Video resolution: 256 x 224, fHorz = 16.0KHz, fVert = 60.6Hz, fPix = 6.14MHz
INFO: Frame time (100MHz counter): VGA = 1649999, HDMI = 1999999
Set vertical scaling to : 896
adjust_video_mode(1649999): vsync_adjust=2.
FileOpenEx(open) File:/media/fat/config/scramble_gamma.cfg, error: No such file or directory.
FileOpenEx(open) File:/media/fat/config/scramble_scaler.cfg, error: No such file or directory.
Send HDMI parameters:
video: 1920(1920), 528(528), 44(44), 148(148), 1080(1080), 4(4), 5(5), 36(36), Calculate PLL for 180.0001 MHz:
Fvco=540.000327, C=3, M=10, K=0.800007(3436001949) -> Fpix=180.000109

PLL: 0x4, 0x505, 0x3, 0x10000, 0x5, 0x20201, 0x9, 0x2, 0x8, 0x7, 0x7, 0xCCCD3A9D, Fpix=180.000109
sending keymap: 0
INFO: Video resolution: 256 x 224, fHorz = 16.0KHz, fVert = 60.6Hz, fPix = 6.14MHz
INFO: Frame time (100MHz counter): VGA = 1649999, HDMI = 1638168
Set vertical scaling to : 896

[sorgelig]

there are some frequencies impossible to generate according to PLL datasheet. With vsync_adjust=2 you can use 1080p@50hz as a base - it will be adjusted to core's frame rate.

[badvision]

Can confirm, I have the same issue. I set a max framerate of 60 and the core still tries for 60.6hz on the core and 61hz on the video out. Confirmed that setting the max refresh to 50hz helps bypass this issue, but is there no way to set max refresh to 60hz?

[birdybro]

vsync_adjust=2 + video_mode=9 yields heavily distorted graphics:

https://www.youtube.com/watch?v=ERdpHOtWgWM

I don't think this is the proper resolution, instead people should just set either vsync_adjust=1 or vsync_adjust=0 for now. The current aspect ratio could probably be adjusted as well. The aspect ratio calculator says it should be 8:7 | 7:8

[zakk4223]

those same settings are rock solid on my display. No distortion, perfect scrolling. I suspect this is going to come down to how well your display handles some of the odder refresh rates. This LG Ultrawide of mine is great as long as you're inside the freesync range

[birdybro]

Right, but this means that vsync_adjust=2@1080p50 is a higher frequency than vsync_adjust=2@1080p60 though, just to be clear (because of the lower frametime value over HDMI). vsync_adjust=1 just works in this case without changing the video signal so drastically.

[SegaSnatcher]

I think this is a case where a 60hz adjust mode option would be very nice for people who don't want to have to use a heavier buffered mode. Ace actually implemented that in many of the cores he's worked on (e,g, Jackal, Gyruss, Time Pilot), and it works great.

I own a LG CX and C1 and the only way I can currently get Frogger to sync properly while using V_Sync=2 is lowering the resolution down to 720p, so a 60hz adjusted option to stay in 1080p or higher resolutions would be more ideal for my use case.

[sorgelig]

to shift PLL clock to a comfortable value where K will be inside allowed range you can make a custom video mode based on existing 1080@60 mode with slightly different vblank/hblank

[birdybro]

I think he means something like the 60hz mode that Ace implemented here --> https://github.com/MiSTer-devel/Arcade-TimePilot84_MISTer/commit/24e6d823bdff537609b2f004c42fd2cc1b30f452

"OL,Game Speed,Native,60Hz Adjust;",

But this was done with a reconfigurable PLL which can introduce a lot of stability issues if not done right and would have to be done on a core by core basis. Some cores can't deal with it because of crossed clock domains and might need a FIFO added as a result, so it can turn into a lot of work. A lot of things aren't easy, but maybe there are some cores where this could be done in much the same way with little problems. I'm not sure enough on the details to comment further.

[SegaSnatcher]

Yes, that is the commit I was referring to, the 60hz adjust/normalized option.

Correct, it would be on a core by core basis. It is an extremely helpful option for some of those pesky cores with specific timings.

I guess I could ask Ace about it since he has experience with this.

[birdybro]

I talked to Ace and other devs about it. It is a difficult thing to implement without harming the core's timings in some cases and it was very situational for his cores because they had especially incompatible native frequencies.

It's something that would, at scale, make continuing maintenance of the cores that much harder for very little gain, and the games would play either too fast or too slow.

[SegaSnatcher]

I talked to Ace and other devs about it. It is a difficult thing to implement without harming the core's timings in some cases and it was very situational for his cores because they had especially incompatible native frequencies.

It's something that would, at scale, make continuing maintenance of the cores that much harder for very little gain, and the games would play either too fast or too slow.

I don't personally believe allowing for better display compatibility while keeping low lag is of little gain. Kevtris has made the adjusted to 60hz low latency mode a staple for his cores and people seem genuinely happy about the compatibility on their displays. The amount of downclocking from 60.6hz down to 60hz is too small for the vast majority of gamers to even notice while in gameplay, only speed runners might notice it, but then again speed runners wouldn't use such a feature anyways.

I'm curious why adding such an optional feature on a core by core basis would make it harder to maintain. I really do believe a lot of people would benefit if more cores had a 60hz compatibility low lag mode available. It really would help take care of a lot of sync issues people run into without having to sacrifice latency with using one of the fully buffered modes.

I can only speak from my own experience, but all the MiSTer cores with that mode has greatly improved my enjoyment with them and I'm deeply grateful that Ace put in the work to make it happen.

By any chance did you talk to Grabulosaure about it? Lastly, I understand such a mode doesn't make sense or might not even be possible for every core, but is it really not possible at all for the Scramble/Frogger core?

[birdybro]

I'm curious why adding such an optional feature on a core by core basis would make it harder to maintain.

Crossed clock domains and less flexibility for the fitter's annealing algorithm which reduces the number of possible solutions. I understand somewhat how sensitive timings can get when introducing a reconfigurable clock, I added it to the Genesis core by copying how it was done with SMS, and it did introduce metastability issues unbeknownst to me at the time in my lack of experience. The current unstable build of MegaCD does not achieve timing due to the reconfigurable pll being added as well, for instance.

Kevtris's cores (respectfully, because I think he has quite a bit of skill) are mostly irrelevant to discussion of what MiSTer should or shouldn't do. His cores are closed source so they cannot be independently evaluated on their merits and his cores do not work 100% with every rom (sideloaded through "jailbreak" aka an official release by Analogue but they claim no responsibility for) in the case of consoles with cartridge mappers that had enhancement chips and other sorts of things like that. His boards he's running these cores on are also purpose-built for use with his cores, whereas MiSTer runs on a generic development board, so this has to be taken into consideration. Additionally, the GPIO and features on MiSTer, compared to Analogue Inc. boards, adds stressors to timings. His cores don't have to natively support multiple video output methods, don't have open ended shadowmasks, don't have 256-phase 10-bit coefficient adaptive filters, don't have open-ended audio filters, and don't have complex interconnections via HPS the way MiSTer does. All of these things in aggregate put stress on timings. Shadowmasks and the new Adaptive filters are some of the most timing stressing features in MiSTer ATM.

If Kevtris and Analogue Inc. ever want to actually contribute to the preservation of retro gaming, they are free to open source their proprietary profitable FPGA cores for the world to see and benefit from. Hopefully they don't let all of that research go to waste.

When you limit the freedom of the fitter algorithm and you add stressors on timings, not only is it harder on developers to modify the design and meet timing requirements, but it increases compilation time even more, which slows the iterative process.

I'm not an expert, but I've learned a lot about this in the past couple years and it's given me pause in just wanting to add all features.

This is not to say that it's impossible to add to the scramble core, it's probably very simple. however adding it here entails a slippery slope where everyone will demand it be added to every core, and your question was more broad across all of the cores and you have asked about this before regarding other cores, so I was responding to the broader implications of a trend being adopted.

By any chance did you talk to Grabulosaure about it?

No, I don't see why that would be relevant to. He made the scaler and he understands video timings really well. This isn't something that could be standardized in the scaler easily, if at all. Each core generates it's own native video timings --> https://mister-devel.github.io/MkDocs_MiSTer/advanced/nativeres/

[SegaSnatcher]

Thanks for the detailed explaination, I appreciate that.

This is not to say that it's impossible to add to the scramble core, it's probably very simple. however adding it here entails a slippery slope where everyone will demand it be added to every core, and your question was more broad across all of the cores and you have asked about this before regarding other cores, so I was responding to the broader implications of a trend being adopted.

I can totally understand your point here, but if people are properly informed about the pros and cons and that this is something that can't/won't likely ever be a global feature I think users would accept special cases for this feature to be implemented on certain cores. There are a lot of cores on MiSTer that have their own unique special features and people seem to be okay with it. I think prioritizing user experience when possible is definitely not a bad thing.

I forgot to add that it's not just sync that can be improved by this feature, but also scrolling stutter. For example, I don't have sync issues playing Jackal at native frequency, but unfortunately the scrolling stutters on my display. Switching to the 60hz mode fixes that and now I have smooth scrolling.