ijor wrote:I think it probably remains to be seen if it would be compatible with HDMI 2.1 VRR. I don't know the low level details of VRR. Anyone have access to the specs or have seen a low level technical description? I understand it can accept an arbitrary refresh rate. But can it accept an arbitrary pixel clock as well? Or the refresh cycle must be a multiple of the standard pixel clock cycle for the given resolution?

These are exactly my thoughts. New VRR TV sets will be able to process more unusual refresh rates than current ones, but we’ll have to see if they’ll simply accept strange timings over HDMI 1.4 or if they’ll need specific HDMI 2.1 handshakes/signals. Honestly we don’t even need the first V in VRR, the Variable aspect is tied to modern gaming with the GPU asking the Display to show the rendered frame as soon it’s available; with retro computing/gaming we need just odd framerates.HDMI 2.1 VRR came to my mind reading a Byuu’s post about Higan being able to perfectly emulate a 6.098Hz SNES output only on G-Sync and FreeSync monitors; so I made the G-Sync:Higan=VRR:FPGA proportion.

I don't know why VRR is required. It's more a formal writing of limits.Current HDMI v1.4 is able to use any frequencies. I'm working on pi-top case adaptation. It uses 1920x1080 aDP LCD with HDMI to eDP converter chip on the board. Although this display doesn't support anything except 1920x1080 resolution, it completely indifferent to pixel clock. So i can use any possible pixel clock like 100MHz, or even 80MHz. Everything works fine. So, i even can control what resulting refresh rate i set. So, i can make refresh like 48.8Hz to match some retro cores and get butter smooth video.So, it's only limited by display capabilities.

Many modern TVs are so-called Smart TV. They have OS inside and always display some extra info. So, they cannot relay on input frequency in wide range because they need to follow the input refresh. So they accept only standard frequencies to simplify the processing. VRR won't change much here. It's more for some specific devices for video processing. I don't think home TVs will adapt it soon as it usually not required.

Sorgelig wrote:I don't know why VRR is required. It's more a formal writing of limits.Current HDMI v1.4 is able to use any frequencies. I'm working on pi-top case adaptation. It uses 1920x1080 aDP LCD with HDMI to eDP converter chip on the board. Although this display doesn't support anything except 1920x1080 resolution, it completely indifferent to pixel clock. So i can use any possible pixel clock like 100MHz, or even 80MHz. Everything works fine. So, i even can control what resulting refresh rate i set. So, i can make refresh like 48.8Hz to match some retro cores and get butter smooth video.So, it's only limited by display capabilities.

Many modern TVs are so-called Smart TV. They have OS inside and always display some extra info. So, they cannot relay on input frequency in wide range because they need to follow the input refresh. So they accept only standard frequencies to simplify the processing. VRR won't change much here. It's more for some specific devices for video processing. I don't think home TVs will adapt it soon as it usually not required.

Ok, so the current situation is that virtually HDMI 1.4 is able to carry many strange refresh rates, but current TV sets, aimed to Movies and TV shows, are only compatible to 24p, 50i, 50p, 60i and 60p; this makes sense and won’t change with any HDMI 1.4/2.0 TV. There is a potential in HDMI 1.4 that will never be actual. My point is that future HDMI 2.1 TV sets capable of VRR will be specifically aimed to gaming (more than video processing), like current G-Sync and FreeSync monitors, and this feature will be actually usable. Higan can take advantage of g-sync (or FreeSync) mode, without setting a specific monitor refresh rate; it processes a video frame each 1/60.1 second and asks the monitor to display the result ASAP, having the frame displayed in a very tiny lapse after the request, resulting in a near seemless 60.1p output. I think that FPGA retro computing/gaming could take advantage of VRR the same way.

[EDIT]Even without relying to VRR mode, we can hope that VRR capable TV sets won’t be picky about strange fixed refresh rates.

I have small 7" HDMI monitor. It supports HDMI video with wide tolerance. It accepts any pixel clock i throw on it. But it does frame rate conversion into its internal frame rate, i believe 60Hz. So, besides accepting wide range of HDMI video, monitor/TV should NOT try to convert the frame rate. I think, most TVs will do frame rate conversion even if they accept non-standard video input. Not sure about HDMI monitors. Probably only some very expensive models will output exact input frame rate. I never saw spec telling if it does frame rate conversion or not besides just mentioning accepting range of input frame rates. So, it will be a challenge to find correct models.

Pi-top display outputs exactly frame rate as input, so you can have a retro video with butter smooth scrolling. I'm working on MiSTer API extension which will allow to adjust(probably automatically) output frame rate to match original one. So compatible displays will be able to get advantage.

Sorgelig wrote:I have small 7" HDMI monitor. It supports HDMI video with wide tolerance. It accepts any pixel clock i throw on it. But it does frame rate conversion into its internal frame rate, i believe 60Hz. So, besides accepting wide range of HDMI video, monitor/TV should NOT try to convert the frame rate. I think, most TVs will do frame rate conversion even if they accept non-standard video input. Not sure about HDMI monitors. Probably only some very expensive models will output exact input frame rate. I never saw spec telling if it does frame rate conversion or not besides just mentioning accepting range of input frame rates. So, it will be a challenge to find correct models.

www.hdmi.org wrote:Q: Are these primary for gaming applications? A: Certain aspects are better suited for gaming, but it depends on how the manufacturers implement the features. For example, for better gaming, Variable Refresh Rate (VRR) that synchs up source and display with continually changing refresh rate, and Quick Frame Transport (QFT) that allows frames to transmit faster from the source, both allow for smoother, no-lag, and no screen tearing gaming experiences.

It seems that optional VRR will be actually aimed to gaming TV sets, just like G-Sync and FreeSync monitors, without any frame rate conversion (or a conversion to a super high internal frequency that won’t be discernible).

Sorgelig wrote:Pi-top display outputs exactly frame rate as input, so you can have a retro video with butter smooth scrolling. I'm working on MiSTer API extension which will allow to adjust(probably automatically) output frame rate to match original one. So compatible displays will be able to get advantage.

This is great (as all your work).Now let’s hope that new HDMI 2.1 VRR TV sets will accept arbitrary framerates through HDMI 1.4, without relying on specific VRR and QFT techniques.

Sorgelig wrote:I don't know why VRR is required. It's more a formal writing of limits. Current HDMI v1.4 is able to use any frequencies. ...I have small 7" HDMI monitor. It supports HDMI video with wide tolerance. It accepts any pixel clock i throw on it. But it does frame rate conversion into its internal frame rate, i believe 60Hz. So, besides accepting wide range of HDMI video, monitor/TV should NOT try to convert the frame rate. I think, most TVs will do frame rate conversion even if they accept non-standard video input.

Exactly. Technically we don't need VRR. Nothing prevents current monitors using an older HDMI standard to accept any frequency. But it is not very common. And as you are saying, most monitors (that don't support freesync) that accept non standard frequencies do perform a refresh rate conversion.

So VRR standard will probably make more widespread both accepting and actually refreshing at, non standard frequencies.

Btw, I'm still not sure if the standard allows arbitrary pixel clocks, and not just arbitrary refresh rates. I spent quite some time trying to find any low level technical info about any of the VRR standards, HDMI 2.1, VESA adaptive sync, AMD freesync and NVIDA g-sync. Except a couple of white papers and some marketing info, I couldn't find anything at all. Seems all those standards are completely undisclosed.

Probably only some very expensive models will output exact input frame rate. I never saw spec telling if it does frame rate conversion or not besides just mentioning accepting range of input frame rates. So, it will be a challenge to find correct models.

Any monitor supporting AMD freesync should not convert the frame rate. Still mostly a gamer feature, so probably not common on very cheap monitors, but I think there are some affordable ones.

Currently i'm using the first method as it allows very precise adjusting by simple calculation. Usually my function adjusts HDMI frame rate with 0.00001ms tolerance which can be treated as a genlock. Second method is more tricky and not precise. And usually will work only to lower FPS direction.

Another option i'm adding into API but not currently using is setting specific height of scaled image. It will allow to set divisible vertical scaling and reduce artifacts. Horizontal scaling follows core aspect ratio setting. It's impossible to set divisible scaling on both vertical and horizontal scaling at the same time because pixel clock on old television wasn't defined, so different systems have used any convenient pixel clock.

Got my Super NT yesterday, and I have to say... It's an amazing piece of kit.The sheer polish level of the interface and the FPGA simulation are incredible!It has the best image I've ever seen from any SNES and no noticeable lag.

The way I see it it's a great companion for my MiST, as I use the MiST to emulate computers like the Amiga, the ST or the Spectrum, and this one has (near) perfect compatibility with the SNES library.

If we could ever have this level of polish on the MiST and/or MiSTer cores it would be amazing. I am especially impressed by the menu and the variety of configuration options.

If anyone here is on the line to get a Super NT, I wholeheartedly recommend it.

But you do have available a "Jailbreak" that will allow running games from the SD Card. I have tested it and it works flawlessly for all games except the ones that use extra hardware on the cartridge (like the SuperFX chip, etc.)

No, it has an unofficial "jailbreak" firmware that allows loading ROMs. It doesn't have many mappers supported in that mode, but that's less of an issue for SNES (unlike the NES that needs lots of different memory mappers). Most games work.

Yeah, those ancient consoles like NES, SNES have a big issue when it comes to cartridge emulating. They have a lot of mappers and additional hardware in cartridge. So, making a main hardware is actually half job. The second half probably even larger if you take in account additional CPUs and 3D chips in cartridges.