-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Retrotink 2x HDMI issue - black and white display #8
Comments
This sounds like a Retrotink bug, it sounds like those devices have upgradable firmware so they might be able to fix it if you bug them enough. It may be possible to fix by fiddling with color burst width or other VI config options, if you get something working I'll consider taking it. |
This issue is not present in neon64 v1.2 |
v1.2 has some pretty unpleasant video quality issues of its own, so I'm not just going to take its VI config, and the current 2.0 beta works on all the TVs I've tried. I don't have this device to test, if you fiddle with the VI regs and find something that works for you I'll consider making the adjustment. |
do you by chance have the v1.2 vi.asm color burst width or other values for comparison? I will try and adjust and build a file to see what works, but no clue what should be changed. |
Here is the old VI init. |
I'm a complete novice when it comes to this. Please correct if there's anything misstated, but to the best of my understanding, its possible the video is being degraded to black and white due to the colorburst signal being sent from the N64 as configured in the Neon64 rom from vi.asm is stating to start the colorsync 20 pixels past the hsync line. Perhaps this is slightly off from the requirements when this is converted to a digital signal through the Retrotink. Any concerns with attempting a 1 pixel modification as follows: // hsync width (pixels)(0), color burst width (pixels)(8), vsync height (lines)(16), color burst start (pixels from hsync)(21) Or: // hsync width (pixels)(0), color burst width (pixels)(8), vsync height (lines)(16), color burst start (pixels from hsync)(19) |
I got color working! With the help of other developers, I was pointed to the libdragon display.c which uses 0x03e52239 https://github.com/DragonMinded/libdragon/blob/trunk/src/display.c Here's the diff of the changes I made (replacements first)
|
To match VI_TIMING as per libdragon, you'd want:
@chmcarro tried the following (just color burst set to 34 to match libdragon) and color worked: Matching the full value as per my suggestion also worked. |
@hcs64 This user has been talking about other games/software that exhibit similar behavior in IRC, most recently Dark Rift. Don't break your nice software because it doesn't work on a cheap upscaler. |
The problem exhibited on Dark Rift is independent from the RetroTINK-2X scaler and neon64. For context on the Dark Rift report, see here: https://videogameperfection.com/forums/topic/n64-game-issue-dark-rift-no-signal/ |
I don't have any objection to making the change in principle, I just need to test on a few TVs to make sure things still look like I intend. I expect the color burst is probably independent from the scaling stuff I'm interested in, but I need to run the tests and haven't had the time yet. |
Please check that this fixes it, sorry for the delay. |
This issue appears to be fixed as of d7046be - tested via s-video on retrotink 2x-pro with latest v1.7 firmware. Thank you!! |
The ROMs play in black and white when displayed through the Retrotink 2x with either composite video or s-video with output via HDMI.
This issue is not present when the composite video is sent directly to the display without HDMI.
This issue is not present when using the the OSSC RGB signal via SCART and displayed via HDMI.
The text was updated successfully, but these errors were encountered: