RGBtoHDMI
RGBtoHDMI copied to clipboard
hoglet67
HDMI screen "pickiness"
I just built a small batch of RGBtoHDMI, that is a really amazing project ! First a huge thanks.
At first I thought I screwed up my build since nothing showed on screen. After lots of testing on 7 different screens :
- Dell 2407 over hdmi-to-dvi
- Dell 2410 over hdmi and "hdmi-to-dvi"
- Samsung 23h9x over hdmi-to-dvi
- Nexdock (would be so cool) hdmi
- standalone RTD2660H controller + 11' screen hdmi
- HP LP1965 hdmi-to-dvi
- Dell U2413 hdmi
Only the last two work. At least they work fine :-)
Anything I can do to help support the other ones ?
I can't find a reference on the internet to a samsung 23h9x. Can you provide links to the specs for this?
There seems to be compatibility issues between the NexDock and the Pi: https://www.raspberrypi.org/forums/viewtopic.php?t=245153
Have you tried booting with SW1 pressed? This should force 60Hz output.
What source are you using?
Sorry wrong Samsung model, it is a 2343BW.
I have a "2nd release" Nexdock which works fine with about anything I ever threw at it (Raspberry 0,1,2,3 & 4, MiSTerFPGA, Smartphones). I just tried with SW1 pressed, not better, and tried connecting another laptop on the USB in case the Nexdock used USB to detect activity, no better result.
Just tried with SW1 pressed and got my 2410 working, great. I am now using Auto@50-60Hz (it passes the 50Hz test btw ...) I will try the other screens later this week-end. Would Auto@50-60Hz be a better default choice ?
My source is a C128 (DCR) 80 columns, no TTL board. Works fine, I tried the "VDC Mode Mania" "demo", which does a lot of tricks to get higher resolutions & colors on screen, I had to set "Auto Switch" to off since the interlaced modes where troubling rgb-to-hdmi sync. It works then, but it is quite strange to see a TFT flicker :-)
Thanks for the support !
Just tried with SW1 pressed and got my 2410 working, great. I am now using Auto@50-60Hz (it passes the 50Hz test btw ...) I will try the other screens later this week-end. Would Auto@50-60Hz be a better default choice ?
I'm not sure what's going on there. The default resolution of "Default@EDID" is the same as "Auto@50-60Hz" except that it tries to be safer and always sends 60Hz unless the EDID indicates that 50Hz will work whereas Auto@50-60Hz always sends 50Hz for 50Hz sources which means you will get blank screens on monitors that don't support 50Hz when using that.
Did you change the resolution setting to something else before running your monitor tests? (holding SW1 sets it back to "Default@EDID" as well as temporarily forcing 60hz)
Also be aware that a lot of old Dell monitors will work with 50Hz input and thus pass the test but they do an internal 50Hz to 60Hz conversion and send video to the LCD at 60Hz which makes their 50Hz support useless as you end up with the same judder on smooth motion as you would get when sending 60Hz out of the Pi instead.
My Dell 2707 and 2007 both do this but they do actually produce a display so I'm surprised you are getting no output with your 2407 which is from the same year.
HP monitors of the same vintage like your LP1965 and the LP2065 are much better as they actually work at 50Hz with no internal conversion.
I tried the "VDC Mode Mania" "demo",
Non standard modes are not yet fully supported on the C128 but at least some of them now work. There is a beta test version on my github fork which you can try with "VDC Mode Mania" https://github.com/IanSB/RGBtoHDMI/releases/tag/fdbf4a4
This build also has a "HDMI mode" setting that allows the HDMI output mode to be changed which might also have an effect on some of the non-working monitors although you will have to change the setting on a working monitor to start with. Note changing from DVI compatible will stop it working with the HP LP1965 and probably some of your other DVI monitors
EDIT: I also have a standalone RTD2660H controller board with a 7" screen and it works fine with that.
Hi again,
I just retried my monitors, with other cables this time, and yes, they all work. Sorry for the wrong alarm. The only problem remaining is the Nexdock, it still refuses to show any image.
I will try your new build next and run "VDC Mode Mania" !
OK amazing stuff. Your beta firmware works fine on my Dell 2410.
- Interlaced modes are still flickering but sync seems stable by default, much better already
- vdc-fli renders amazingly well
- vdc-hfli still has issues on my setup, sync is not stable and image cannot be seen correctly
- vdc-himono gives "auto switch : no profile matched" and does not work well
- Big-text-pal & Big-text-ntsc gets recognized ok but shows a kind of wave effect on the right side of the screen, still readable
I will get my CM8833 (mkI) I just repaired out to compare a few colors, but it is much better now. To avoid flicker, would some kind of Amiga 2024 "high persistence phosphor" emulation help (no idea how to do that maybe mix the two frames in a buffer and render around 50hz ?) Thanks again !!
"VDC Mode Mania"
Unfortunately I don't have a Commodore 128 (yet) so I'm relying on feedback from third party testers
Interlaced modes are still flickering but sync seems stable by default, much better already
The problem with those two interlaced modes (VDC-IHFLI 266 & VDC-ITFLI 315) is that they output progressive syncs with interlaced video so effectively they are alternating progressive frames for a dithering effect and they won't be weave deinterlaced because there is no way to detect that is what they are doing. If they had interlaced syncs that would be detected and they would be weave deinterlaced. It might be possible to have a forced deinterlace mode but then the pair order of the woven lines would be random each time the mode was selected.
vdc-himono gives "auto switch : no profile matched" and does not work well
Not sure what mode you mean, it supports VDC-IMONO 749i & VDC-IM800 651i which I've been told work OK and are deinterlaced correctly as they output interlaced syncs. It looks like you are using another mode so what version of the demo are you running?
Big-text-pal & Big-text-ntsc gets recognized ok but shows a kind of wave effect on the right side of the screen, still readable
This probably means the line length is set incorrectly in the geometry menu as that will cause vertical noise bars so try adjusting that setting. When adjusting, you are looking for a result that is either all clean or all noise, not alternating noisy and clean bars and after you get a result, tweak the sampling phase in the sampling menu to get rid of any remaining noise and save the profile. If you get a good result, please let me know the values you changed.
I am using V1.01 of Vdc Mode Mania. VDC-IMONO is 720x700 interlace monochrome, refresh at ~21Hz according to the demo. Interestingly when I press button 1 the image looks half ok behind, but when out of the menu I see the led blinking and the image appears interlaced flickering with the led.
I just set "line length" to 1017 and screen is perfect in both Big-text-* modes. I played with sampling phase, all but 3 and 4 work fine. So 1017 as line length and anything but 3 or 4 as sampling phase works fine on my setup !
That stuff is amazing. I just built an analog module for my CBM-II, I'll try next. Thanks for your time !
I just set "line length" to 1017
To confirm that is the correct setting: the original noisy value was 1016, does setting it to 1018 produce noise as well?
VDC-IMONO is 720x700 interlace monochrome, refresh at ~21Hz according to the demo
Can you post a screencap of the Source Summary menu in the info menu when running that mode. (Go into that menu then press the up and down buttons and that will screencap the menu image to the SD card as a PNG)
@Sch-LikA
I am using V1.01 of Vdc Mode Mania.
My other tester has been using V1.11 of VDC Mode Mania and it works with that (apart from VDC-HFLI_403 which has very strange results in the logs and may have out of spec H or V sync pulses)
That appears to be downloadable here: https://csdb.dk/release/?id=161195 Can you try that version?
Hi ! I just tried Vdc Mode Mania 1.11
Mode 1 & 2 (VDC-IHFLI & VDC-ITFLI) : All ok
Mode 3 : Pictures have a bad vertical alignment, picture starts at ~1/3 top and there is a black line in the middle, like in this capture :
Mode 4 - VDC-HFLI 403 : Gets detected but does not sync Mode 5 : Works fine !
Here is the capture of VDC 1.01 IMONO mode :
Text modes : I confirm 1017 is the correct line length, 1016 and 1018 produce noise.
@Sch-LikA
Here is the capture of VDC 1.01 IMONO mode
The current version of IMONO mode has a PAL line length of 1024 but your version has an NTSC line length of 1016 instead.
I think I've figured out what the problem is with the other modes so there should be a fix soon
@Sch-LikA
Here is an updated beta 14 which might work properly in all VCD modes:
https://github.com/IanSB/RGBtoHDMI/releases/download/98d62b35/beta14.zip
@Sch-LikA
Now up to beta 16 which according to my other tester works with all VCD Mode mania:
https://github.com/IanSB/RGBtoHDMI/releases
One option that requires manual override is NTSC Big text because it shares the same timing as regular NTSC. To select that you have to change Auto Switch to off and then select the NTSC text sub-profile (not profile). I may implement some sort of popup menu for circumstances like this where two or more sub-profiles share the same timing.
Just tried b16, Vdc Mode Mania 1.01 works fine in all modes.
Vdc Mode Mania 1.11 still has the same issue in mode 3 (the astronaut), and mode 6 (VDC-IM800) flickers and does not sync. All the rest works fine !
I even had another issue resolved after forcing a resampling, I built a 4 option roms switcher, and Basic8 was having issue in text mode. It does now work fine. I'll try some Basic8 graphic modes later.
Thanks a lot, huge progress.
Hi ... sorry for delay, here are the screenshots :
And finally text mode of Basic8 does blink too :
Btw I was working on Atari ST's lately, and was wondering if the monochrome hires "kindof" vga (640x400, 72hz vert /31.5khz hor) could be supported by RGBtoHDMI ?
@Sch-LikA
Btw I was working on Atari ST's lately, and was wondering if the monochrome hires "kindof" vga (640x400, 72hz vert /31.5khz hor) could be supported by RGBtoHDMI ?
Already works, see: https://github.com/c0pperdragon/Amiga-Digital-Video/issues/6
Hi, tokra here the author of "VDC Mode Mania". I just got an RGB2HDMI and am trying my modes with it. I had success with all of them but ITFLI, which is kind off picky and results in a flashing screen. Still investigating this.
The problem with those two interlaced modes (VDC-IHFLI 266 & VDC-ITFLI 315) is that they output progressive syncs with interlaced video so effectively they are alternating progressive frames for a dithering effect
This is news to me :) I did not consciously do anything else with these two modes than with the monochrome-modes. They both set the VDC-register 8 to "interlaces video & sync". Maybe adding colour to the mix makes the VDC do strange things? Would be interested to go deeper into this if someone can explain what exactly is and should be happening.
Anyway, the wrongly placed picture of VDC-FLI in V1.11 is due to a small screw-up of mine I realized only years later. Other than earlier versions, I must have copied a line wrong and now it load the settings for the wrong mode and as such sets reg 7 (VSYNC-position) wrong. It is probably the easiest to just use V1.13 from my homepage which fixes this issue and speeds up the screen-copy and screen-clean a bit since it now uses assembler-routines. Get it here: https://www.tokra.de/c128/vdcmodemania-v113.zip
Having a further look at the profiles for "VDC Mode Mania" I noticed that they use the wrong palette (with dark yellow instead of brown). The converter specifically uses brown and this is also what the original monitors from Commodore back then displayed (1901 / 1902 and 1084). I also made profiles for my other demos "VDC VGA Mania" and the 4in1-mode of "VDC Spectrumania". Look on CSDB for both. I have attached my profiles for Mode Mania and the newer modes. VDC VGA-Spectrumania4in1-RGB2HDMI.zip VDC Mode Mania-RGB2HDMI.zip
@victokra
I had success with all of them but ITFLI, which is kind off picky and results in a flashing screen. Still investigating this.
Flashing screen either means there isn't a profile that matches the timing or the selected profile has a capture size that exceeds the size of the video frame. (See the help menus in the latest release)
The problem with those two interlaced modes (VDC-IHFLI 266 & VDC-ITFLI 315) is that they output progressive syncs with interlaced video so effectively they are alternating progressive frames for a dithering effect
This is news to me :) I did not consciously do anything else with these two modes than with the monochrome-modes. They both set the VDC-register 8 to "interlaces video & sync". Maybe adding colour to the mix makes the VDC do strange things? Would be interested to go deeper into this if someone can explain what exactly is and should be happening.
The main problem is that I don't have any Commodore 128 hardware so debugging issues like this is not easy.
What does the source summary show for those modes (i.e are they being detected as progressive or interlaced?) Go into the info menu and select source summary while those modes are being displayed. You can screencap the menu by pressing SW2 & SW3 together.
I have attached my profiles for Mode Mania and the newer modes.
Can all these mode files be included in the single Commodore 128 profile folder? (i.e. do they all have different timings so they can be auto selected?)
@IanSB
What does the source summary show for those modes (i.e are they being detected as progressive or interlaced?) Go into the info menu and select source summary while those modes are being displayed. You can screencap the menu by pressing SW2 & SW3 together.
These are the screenshots of the menus. Apparantly bot the ITFLI and IHFLI-modes are recognized as progressive instead of interlace which they should be. The monochrome-modes are correctly recognized as interlaced and auto-deinterlaced when displayed. I actually managed to get a stable non-flickering picture now with ITFLI when I set Video type to "Progressive". The video still show the interlace-flicker that way, i.e. is not auto-deinterlaced, but at least stable.
I have attached my profiles for Mode Mania and the newer modes.
Can all these mode files be included in the single Commodore 128 profile folder? (i.e. do they all have different timings so they can be auto selected?)
Yes, apart from VDC-VGA-Text-Mono_521 and VDC-VGA-TFLI_521 - they have the same timing but different resolutions. You can leave out TFLI_521 as this will make sure the text-mode is displayed correctly and this still works for the TFLI-mode although scaling can be optimized. So, "VDC-VGA-Text-Mono_521" is the one to keep.
@victokra
These are the screenshots of the menus.
Progressive / interlace detection is done by first measuring the average line duration over 100 lines of video then measuring the time for two frames / fields. This value is then divided by the line duration (with suitable rounding) to find the number of lines for two frames / fields. If this number is odd then the video is interlaced else it is progressive. Could you use the info menu and select the save log and EDID option while displaying a problem mode then post log.txt from the SD card as this should show more details about those measurements.
Here you go with the log. Hope you can make something out of it. Searching for IHFLI and ITFLI should bring you to the affected sections.
@victokra
Autoswitch match: VDC-IHFLI_266 (8) = 63182, 63817, 266, 3
Lines per frame = 266, (266)
Actual frame time = 16891206 ns (non-interlaced), line time = 63500 ns
Autoswitch match: VDC-ITFLI_315 (12) = 63680, 64320, 315, 3
Lines per frame = 315, (315)
Actual frame time = 20160203 ns (non-interlaced), line time = 64000 ns
The time for two frames/fields is only logged when interlace is detected and in the above cases the value for only one frame is logged instead when progressive is detected but this value is merely the two frame value divided by 2 so it is easy to reproduce the original value by multiplying by two
16891206 * 2 = 33782412 / 63500 = 532.0064 so 532 lines
20160203 * 2 = 40320406 / 64000 = 630.0063 so 630 lines
As these are both even numbers I don't think they can be interlaced signals as there has to be half a line extra per field for interlace. Maybe some combination of VDC register settings is stopping interlaced sync from being generated?
Do the other interlaced modes work OK?
Yes, both VDC-IMONO (720x700) and VDC-IMONO800 are recognized as interlaced and displayed correctly. I assume it is the color-activation that messes up the interlace. The VDC was known to be a buggy chip. I found another interlace color-program (IPAINT) that shows exactly the same problem. Anyways, thanks for the explanation. That gives me a good starting point to investigate and experiment.
Maybe it could be made an option to force interlace and pick top / bottom field order?
@victokra
Here is a proposed Commodore 128 profile set with your changes plus I also set the frame buffer to double height in all profiles as that is usually required for variable scanlines and may also help with interlaced display
Delete the existing Commodore_128-80 folder in /profiles and replace with the attached folder.
Also delete the Commodore_128-80 folder in /saved_profiles as that will override the new values in /profiles
I have set the video to progressive for VDC-IHFLI_266 & VDC-ITFLI_315 but you might want to change back to interlaced to see if the double height framebuffer setting makes any difference.
If the above looks OK I'll add it to the next release, if not please post your corrections. Commodore_128-80.zip
Ok, these profiles work just as well, but did not improve the interlace-recognition. I investigated a little more why the monochrome modes are recognized correctly and the color ones are not. Basically the difference is in the character-height register (reg 9) which has to be set for the character-height - 1. While for monochrome-interlaced-modes these are set to a height of 7 (odd) for the color modes they are set to 4 or 6 (even). I've checked that odd values always lead to interlace being detected correctly and even values always don't. I can see no really good reason for this though. As said the VDC was known to be buggy.
The number of lines is calculated by (reg 4 +1) * (reg 9 + 1). For IHFLI this is: (132 +1) * (3 +1) = 532 interlaced ITFLI: (104 +1) * (5 +1) = 630 interlaced IMONO: (106 +1) * (6 + 1) = 749 interlaced IM800: (92 + 1) * (6 +1) = 651 interlaced
However for the color-modes I have to set to the register to even values as each field has to have an even number of lines for color. E.g. with 4 I get the following colors:
AAAAAAAA BBBBBBBB AAAAAAAA BBBBBBBB
CCCCCCCC DDDDDDDD CCCCCCCC DDDDDDDD
A nice setup. But with 5 the setup would look like this:
AAAAAAAA BBBBBBBB AAAAAAAA BBBBBBBB AAAAAAAA
CCCCCCCC DDDDDDDD CCCCCCCC DDDDDDDD CCCCCCCC
So, less color-granularity (2 colors per 5 lines instead of 2 per 4 lines). I've actually tried such a setting and it was correctly recognized, but it just does not make much sense :)
Only option seems to force interlace for even numbered line count and to choose field order.
@victokra
Have you tried adjusting register 5 (Vertical Total Fine Adjust) ? http://www.ffd2.com/fridge/chacking/c=hacking2.txt
If you have one of those cheap USB logic analysers it might be interesting to look at the relationship between the H and V sync pulses on two adjacent frames in progressive, normal interlaced and bad interlaced modes.