MiSTer sends the wrong VIC code in the AVI InfoFrame for resolutions above 1920x1080, forcing an incorrect aspect ratio (16:9).
skooterblog opened this issue · comments
Since I bought a Magewell USB Capture HDMI I noticed that it always detects my MiSTer output as 16:9, even when I'm using resolutions with other aspect ratios, like 1920x1200 (8:5) or 1920x1440 (4:3). That didn't happen with other sources, like an OSSC in 1920x1200, for instance, which is correctly identified as 8:5.
After some research I found out MiSTer is sending the wrong VIC info in the AVI InfoFrame. Apparently, the automatic VIC detection of the HDMI chip (ADV7513) fails when we set resolutions or frequencies above its specifications. According to its specs, the limit is 165 MHz and 1920x1080.
When MiSTer is set to 1920x1440, the VIC is set to 16, which corresponds to 1920x1080 @ 60 Hz with a 16:9 aspect ratio. When the sink (in this case Magewell USB Capture HDMI) realizes this mismatch between the resolution and refresh rate in the actual image and in the VIC field, it uses what is in the image. However, there is no aspect ratio in the image, so it keeps using the wrong information set in VIC.
I confirmed this issue by building the SNES core with the VIC detection disabled. This is accomplished by disabling pixel repetition and setting VIC manually, according to the ADV7513 Programming Guide.
So what I did in hdmi_config.sv was:
- set register 0x3B[6:5] to '10'
- set register 0x3C to '00000000'
This fixed the issue and the aspect ratio is correctly identified in any resolution.
My suggestion is to update the framework so the automatic VIC detection is not used when the resolution is above 1920x1080 or the frequency is above 165 MHz. In these cases, VIC should be set to zero. There will be no loss since there are no valid VIC numbers for 1920x1440 resolutions (or any resolution above 1080p and below 2160p).
While I was messing in hdmi_config.sv, I also realized that the A0 field in the AVI InfoFrame (0x55[4]) is set to 1, which indicates that the Active Format Data is present in Data Byte 2 bits R3 through R0. However, R3 to R0 (0x56[3:0]) is currently set to '0000', which is not valid. It should be set to '1000', which means "Same as Picture Aspect Ratio". Moreover, when the aspect ratio is 16:9 or 4:3, it can be set to 0x56[5:4]. It is not mandatory, but I think it would increase the compatibility with some devices. When the aspect ratio is different than that, it should be set to '00'.
Finally, I also did some tests by setting the IT content to Game (0x57[7] to '1' and 0x59[5:4] to '11') and it makes my TV automatically change to game mode, like modern systems like PlayStation 4, PlayStation 5 and Nintendo Switch do. I believe this should be a mister.ini option, so people could choose the IT mode (Game, Graphics, etc.) or IT disabled according to what is best for their TVs/monitors.
I would implement this stuff myself but I have no experience with FPGA programming and I have no idea how to bring the variables I need to check into hdmi_config.sv, like frequency and resolution.
My current test hdmi_config.sv file is here. It is always sending VIC=0, but no VIC is always better than the wrong VIC, since with no VIC the capture device defaults to the square pixels aspect ratio.
https://github.com/skooterblog/Template_MiSTer/blob/master/sys/hdmi_config.sv
A video demonstrating the correct behavior with 1920x1440 and VIC=0 is here:
https://www.youtube.com/watch?v=2AW-cYGV8Kc
The video starts with the current core running showing the wrong aspect ratio (16:9) and later I load my test build which shows the correct aspect ratio (4:3).
I'd like to thank wickerwaka and Zakk for all the knowledge shared on the official Discord server, which helped me a lot in figuring out what was causing these issues and how to fix them.
MiSTer assumes all HDMI resolutions have square pixels as all calculations based on this fact, so it should be safe to set VIC=0.
Probably game mode can be turned ON permanently as well.
Thank you. I'm closing this issue as it should be fixed with the merge of the changes I did:
#59
yes, that's an excellent practice, keeps traceability all linked up.