240p via HDMI on Raspberry Pi to RGBS, no need for RGB hats!

[vol.2]

Okay, I put some hours into this again, I want to share some details:

1) CEA mode 8 is 720x480 not 320x240

2) I have not been able to get any 320x240 modeline to pass through my U-Green HMDI to VGA adapter

3) The particular adapter I have only seems to pass specific standard modelines and when something else is fed to it, it will sometimes display nothing and sometimes "round up" or "round down" For example, when fed mode 12 (2880x240) it will output it as 1080p, but it will stretch the image horizontally and squish the image vertically.

4) It does pass 640x480 correctly, but I can't output directly to the PVM from this, I have to go through my emotia (or a VSC if I want interlaced) This also presents issues with the readablity of the console text, which is an issue for me because I use emulation on top of debian.


Does anyone have a specific HDMI-VGA converter that they know to be pretty good and also to be able to pass a wider range of signals than mine does? The ability to pass arbitrary modelines would be best, because I like the flexibility of centering the screen with the porches.

Thanks,

[fernan1234]

Okay, I put some hours into this again, I want to share some details:

1) CEA mode 8 is 720x480 not 320x240

2) I have not been able to get any 320x240 modeline to pass through my U-Green HMDI to VGA adapter

3) The particular adapter I have only seems to pass specific standard modelines and when something else is fed to it, it will sometimes display nothing and sometimes "round up" or "round down" For example, when fed mode 12 (2880x240) it will output it as 1080p, but it will stretch the image horizontally and squish the image vertically.

4) It does pass 640x480 correctly, but I can't output directly to the PVM from this, I have to go through my emotia (or a VSC if I want interlaced) This also presents issues with the readablity of the console text, which is an issue for me because I use emulation on top of debian.


Does anyone have a specific HDMI-VGA converter that they know to be pretty good and also to be able to pass a wider range of signals than mine does? The ability to pass arbitrary modelines would be best, because I like the flexibility of centering the screen with the porches.

Thanks,

Sorry to hear you put in some hours into this to unsuccessful results. CEA (hdmi group 1) mode 8 is 240p for sure. That is the universal mode I've set in my config.txt file, and it is also listed as 240p in the official Raspberry Pi video modes document: https://www.raspberrypi.org/documentati ... t/video.md

There may be something else in your config, either in the config.txt file in the SD card or in a USB drive with a configuration file that the image you use supports, that may be overriding this output mode and forcing 720x480 instead (which would be 480p DTV, generated by CEA mode 2). There are also two other 240p modes (mode 9 for 16:9 and mode 12 for pixel quadrupling). 640x480 would be a DMT mode. Could it be you have hdmi group set to 2 (DMT) instead of 1 (CEA)? In any case, you don't want a 320x240 mode, but a 240p mode (which would be something like 720x240, enough horizontal resolution to accommodate pretty much all low res games).

In terms of HDMI to VGA adapters, I've only really used an HDFury 3. Those are expensive, though there are supposed to be clones on Aliexpress, maybe even on eBay and other places too. It's weird that the U-green adapter doesn't work, since it's been reported to work with the MiSTer's direct mode, which does something similar to output low res 15khz. I still suspect something is off in your config somewhere.

[vol.2]

Thanks for the reply.

CEA (hdmi group 1) mode 8 is 240p for sure. That is the universal mode I've set in my config.txt file, and it is also listed as 240p in the official Raspberry Pi video modes document: https://www.raspberrypi.org/documentati ... t/video.md

I thought so too, until I started having issues with my setup. I found some sources that include the actual resolutions from the Vesa documentation. Mode 8 is 240p, but it's 720x240p. Here's one source with a better explanation (Go to page 10) : http://pdf.dzsc.com/99999/201086102952641.pdf

And if you still don't believe it, here's the EDID standards for the Vesa modes that lines up with this: https://en.wikipedia.org/wiki/Extended_ ... ation_Data

Wikipedia's EDID chart erroneously claims that both 8&9 are 1440x240, but other places indeed show that 8 is 720 and 9 is 1440 (because it's stretched to 16:9. Both are technically 240p.

[edit: the reason for this, from what I have gathered, is that the HDMI standard does not support pixel clocks lower than 25MHz, so actual 320*240 at 60Hz couldn't happen math-wise. The pi can ignore that requirement, but any standard mode would adhere to it. My HDMI-VGA adapter doesn't seem to output anything from a custom modeline.]

There may be something else in your config, either in the config.txt file in the SD card or in a USB drive with a configuration file that the image you use supports, that may be overriding this output mode and forcing 720x480 instead

I'm not ruling out that my config could have something weird in it, but I am using stock raspian lite and have basically nothing in my config except for the video lines. If somethings wrong, I fucked that up, or I didn't add something important.

In any case, you don't want a 320x240 mode, but a 240p mode (which would be something like 720x240, enough horizontal resolution to accommodate pretty much all low res games).

Okay, maybe this is what I need to focus on if I want to use Lakka. What I still don't get is the 720 width. Isn't it bad to use a width that doesn't integer divide by 320, or does the width not really matter?

[fernan1234]

Okay, maybe this is what I need to focus on if I want to use Lakka. What I still don't get is the 720 width. Isn't it bad to use a width that doesn't integer divide by 320, or does the width not really matter?

Well, remember that the original "240p" is actually a mode of 480i, which is originally an analogue signal. The internal digital horizontal resolution of some old systems and games (like 320) was simply stretched out into the 720 samples of the 480i (240p) signal, with the analogue display and user ultimately handling the aspect ratio, overscan, etc. When 480i sources are digitized, they become 720x480 pixel images (if only the visible lines are digitized, otherwise it would be 720x525), with an incorrect, non-4:3 aspect ratio (an aspect corrected 480i digitization would be 704x480). Correspondingly, a theoretical source in 240p is digitized into 720x240, and that's why the 240p CEA video modes reflect that. They're basically an accommodation for a hacked 480i resolution for HDMI/digital signals.

And 320x2 is 640, which still fits within 720. So for a game with an internal resolution of 320x240, when using CEA 8 mode you simply want to turn on integer scale and set vertical resolution to x1 and horizontal to x2 (doing x3 would stretch the picture beyond the 720x240 frame). So the picture may not fill up the screen, but on a CRT you can stretch and contract it as needed, or just be fine with the underscan. Also remember that old games even within the same system had different horizontal resolutions. Games with 256 horizontal resolution are more awkward to deal with, since x2 only adds up to 512, requiring more stretch to display in the correct AR. Alternatively, you can use one of the preset AR profiles instead of custom/integer scale, and see if those look good enough and don't produce shimmering and other motion artifacts.

There is also the possibility of using custom video modes with super resolutions (such as 1920 as the horizontal resolution) to fit anything nicely, but I had a bit of audio/video sync troubles for some cores, which is why I don't recommend it, though this is the method used in the Recalbox guide. Info is in the hidden spoiler in the original post.

Finally, I could never get this setup to work correctly with Lakka. I use Recalbox, but was also able to test Retropie with good results.

[vol.2]

Well, remember that the original "240p" is actually a mode of 480i, which is originally an analogue signal. The internal digital horizontal resolution of some old systems and games (like 320) was simply stretched out into the 720 samples of the 480i (240p) signal, with the analogue display and user ultimately handling the aspect ratio, overscan, etc. When 480i sources are digitized, they become 720x480 pixel images (if only the visible lines are digitized, otherwise it would be 720x525), with an incorrect, non-4:3 aspect ratio (an aspect corrected 480i digitization would be 704x480). Correspondingly, a theoretical source in 240p is digitized into 720x240, and that's why the 240p CEA video modes reflect that. They're basically an accommodation for a hacked 480i resolution for HDMI/digital signals.

Thanks for this info.

Okay, I've been working with analog modelines and I wasn't aware of the 720 width thing. After reading your post, I read the DV-NTSC specs and it says that they do a 720 pixel sample and send 480 pixels centered timings. I had no idea that older systems also sampled 720 in width, I've never really looked into that. I will say that when I use my Raspi over the VGA output, I set 320x240 modelines with appropriate porches. This works flawlessly with VGA titles, except that I have to stretch my screen vertically to make up for the 40 pixels vertically. (and I don't get such a sharp vertical picture because "real" VGA line-doubles the vertical to 400 before sending it out) This approach also works for Lakka, but even with Mike Chi's ultratink, there is some weird dot-crawl stuff that bugs me. I was hoping to find an HDMI out solution that gave identical results without dotcrawl. (sounds easy, right!)

What I still don't get is that, when I send CEA mode 8 out of the pi, it sends a 60Hz vertical, 67.35kHz horizontal signal out. It isn't 15kHz, so I can't sync to it. I was assuming that this had something to do with my HDMI-VGA adapter, but I hooked up the HDMI cable to my projector and it also sees mode 8 as a 67.35 kHz signal @720x240. (but the projector can sync to it)

There is also the possibility of using custom video modes with super resolutions (such as 1920 as the horizontal resolution) to fit anything nicely, but I had a bit of audio/video sync troubles for some cores, which is why I don't recommend it, though this is the method used in the Recalbox guide. Info is in the hidden spoiler in the original post.

This is what is kicking my ass. I can't seem to figure out the right combo of retroarch.cfg settings and config.txt settings to make it work. I believe that it's possible to set things independently (retroarch sets it's own output to display after it launches) but there isn't fine-control over porches and whatnot.

Finally, I could never get this setup to work correctly with Lakka. I use Recalbox, but was also able to test Retropie with good results.

Recalbox looks to be only Pi3, and I have a Pi4. Are you using it with a 4?

[fernan1234]

I made this topic before the Pi4 was released. All my testing and use was on a 3. Don't own a 4 to test. The video modes are supposed to be the same across the two Pis though, as far as I know.

This is what is kicking my ass. I can't seem to figure out the right combo of retroarch.cfg settings and config.txt settings to make it work. I believe that it's possible to set things independently (retroarch sets it's own output to display after it launches) but there isn't fine-control over porches and whatnot.

RA should load on the mode specified in config.txt regardless of other settings, except CRTswitchres, which can alter the signal out when active. Not sure what the problem may be in your case. Is there an Pi4 compatible Retropie image now? I'd try that. Otherwise, the Retrorink Ulitmate was confirmed working on a Pi4 by another user here. That hat is supposed to be used with a super resolution custom video mode (2048 horizontal, the timings are posted on the retrotink website), which should prevent shimmering in a majority of game resolutions as long as integer scale is used, increasing the horizontal res multiple up to 2048 or as close to it as possible for each system/game. Using the default core preset is likely to cause shimmering.

[vol.2]

That hat is supposed to be used with a super resolution custom video mode (2048 horizontal, the timings are posted on the retrotink website), which should prevent shimmering in a majority of game resolutions as long as integer scale is used, increasing the horizontal res multiple up to 2048 or as close to it as possible for each system/game. Using the default core preset is likely to cause shimmering.

Ok. Thanks. I was under the impression that the super-resolution was only implemented because of the capped dot-clock on the Pi3 (dot clock could only be integer multiples of the base clock) and that it had nothing to do with the shimmering. Or maybe it's the same thing. In any case, I didn't realize that the super-resolutions were supposed to address the dot-crawl issue. I'll give that another shot. Worth a try.

Edit: the 2048 resolution made the dot crawl much, much worse. hahahahaha. stick a fork in my ass and turn me over, I'm done. I'll just wait until the internet figures something out; I'm not familiar enough with this to force it to work

[Unseen]

Wikipedia's EDID chart erroneously claims that both 8&9 are 1440x240

Which is both correct and wrong - on the wire they are indeed 1440x240, but the actual source resolution is just 720x240 with each pixel sent twice.

but other places indeed show that 8 is 720 and 9 is 1440 (because it's stretched to 16:9. Both are technically 240p.

This is incorrect, both mode 8 and 9 have the same horizontal resolution. The only difference between the two modes is that the display is supposed to show one of them in 4:3 and the other in 16:9.

[edit: the reason for this, from what I have gathered, is that the HDMI standard does not support pixel clocks lower than 25MHz, so actual 320*240 at 60Hz couldn't happen math-wise.

In theory that's what CEA modes 12 and 13 are for, 2880x240 on the wire with a pixel repetition factor from 4 to 10. In practice I suspect that they are even less supported than modes 8/9, but I don't have enough data for a definitive claim.

What I still don't get is the 720 width. Isn't it bad to use a width that doesn't integer divide by 320, or does the width not really matter?

720 is the standard width for digital SD material, specified in Bt.601. You could also try to build a pixel-doubled 640x240p mode by basing it on standard VGA timings (640x480), but your results may vary because it's not a standard mode.

[vol.2]

both mode 8 and 9 have the same horizontal resolution. The only difference between the two modes is that the display is supposed to show one of them in 4:3 and the other in 16:9.

Thanks for clearing that up for me. Also for the other insights.

You could also try to build a pixel-doubled 640x240p mode by basing it on standard VGA timings (640x480)

This is a good idea. If the adapter passes it, It would make the end of my chain a lot easier.

I think the real issue is (and has always been) that my HDMI-VGA adapter is intolerant of many resolutions. I was able to finally get it to pass some thing at 320*240 by creating a CVT mode and passing it as a custom mode in the kernal, but for some reason it came out as 14kHz horizontal and it looks really unfocused and weird. My theory is that the HDMI-VGA adapter may have fixed pixel clock rates for resolution subdivisions and it's trying to squeeze my CVT mode into something. It's important to note that the CVT method alone doesn't specify custom timings; when I do specify the timings, nothing shows up. (With the same modeline that works with a VGA signal)

What I think I need is a better adapter, if anyone has a good suggestion?

Perhaps a DVI to VGA adapter?

[kitty666cats]

Anybody made any breakthroughs on Pi 3B / 3B+ with this lately via putzing around? I've been fiddling with HDMI to VGA > Extron Sync combiner > 15kHz RGBS again after a long hiatus, I'll report in if I find anything really to my liking... the 24bit output just looks SO much better than the various GPIO hats I've owned, really blows 'em away IMHO.

I've helped out ErantyInt out a bit with his various CRTPi-Project releases, and RetroPie CRT Edition is great. RGB-Pi's new OS is pretty cool, but they are far too weirdly-protective of their shit. But, man, HDMI to VGA really takes the cake! What ALSO rocks socks is simply rocking 31kHz 640x480 Pi configs with the mini-SLG and X-Vue Gamma Boost on my 34" Sampo, looks much better than RetroArch shaders IMHO. But for now, I'm putzing around with 15kHz again!

[vol.2]

Anybody made any breakthroughs on Pi 3B / 3B+ with this lately via putzing around? I've been fiddling with HDMI to VGA > Extron Sync combiner > 15kHz RGBS again after a long hiatus,

What is your software setup and what kind of results are you getting?

I have been quite a bit farther down this particular rabbit hole and I found out that it's not a great solution at the moment.

There are a couple of issues. 1) Lakka specifically can't use an HDMI->VGA adapter. I don't know for sure, but I think it has something to do with the bootloader included with the distro. I don't think it can be
swapped out for a newer one because there are other dependencies that would be broken. I've put in a request with the Lakka folks to look into supporting HDMI-VGA, but I wouldn't hold your breath.

2) Raspbian works with the HDMI-VGA setup, but only with standard resolutions (i.e. mode 8 NTSC 720x480 centered timings). You can't use super resolutions with it because when you output over HDMI,
modedb throws out your timings and substitutes a mode from it's internal list of EDID. Adding a custom EDID is supported, but modedb is hard-coded to only pull from it's internal list that you cannot alter.
Nobody over at linux or the raspberry pi foundation gives a flying fuck about changing this behavior (trust me I've asked) just to help out retrogamers with a penchant for crispy CRTs.

The newest Raspberry Pi OS appears to be even more problematic and I was unable to get it working with an HDMI-VGA setup at all. Honestly, I'd like it as an option because it's the only way to interlaced
resolutions. that isn't a huge issue with the games I'm playing on it, so I've been mostly content with my Retrotink Ultimate doing 3840x240 on the CRT. It makes NES games look a Rousseau painting.

But I will certainly follow any success had or follow up on leads.

[Mahdiy0]

Hi all!

I have a HDMI to component no lag converter that simply does the digital to analog conversion. My config file has these changes:

hdmi_ignore_edid=0xa5000080

hdmi_group=1

hdmi_mode=8

hdmi_pixel_encoding=2

avoid_safe_mode=1

disable_overscan=0

config_hdmi_boost=4

hdmi_force_hotplug=1

gpu_mem_256=128

gpu_mem_512=256

gpu_mem_1024=512

boot_delay=3

It seems to work, but only for the initial boot with the 3 raspberry logos and terminal text thing...then it gets wonky...like the signal is too high frequency for my SD tv.

Any tips? I've tried hdmi_mode=6 as well, but that just changes the initial raspberry stuff I can see to be interlaced 480i instead, but the rest is the same signal that can't be viewed on the CRT.

All guides say just use hdmi_group=1 and hdmi_mode=8/6 ..... I must be missing something. Tested on 3 CRTs

this is a RPI 4 with a retropie image

[vol.2]

Any tips?

As far as I've been able to determine, HDMI->Component or HDMI->VGA adapters do not work with the Raspberry Pi 4 OR a Raspberry Pi 3 running any version of Raspbian after a certain point for 15kHz displays.

If you want to explore this, your best bet is to go to the CRT switch-res forums or the threads relating to "CRT Switchres" on the Retroarch forums.

Do not expect getting it to work to be easy. Even getting things setup properly with a working GPIO-RGB adapter can be difficult, depending on what you're trying to accomplish.

If you go back and read this whole thread, note the dates that people had things working and cross-reference the version of Pi, and the OS being used at that time to the date. The last person who got it working in this thread was RPI3 like over a year ago. You can try to replicate that setup perhaps, but figuring out the exact version of the OS might be a chore. Also, you will have to make sure you are running the Firmware that was available at the same time. The firmware will make a huge difference.

[Pikkon]

For me recalbox box works the best.

I only have a pi 3 but the latest version of recalbox does work in 15kHz via rgb,you could give that a try.

[fernan1234]

For me recalbox box works the best.

I only have a pi 3 but the latest version of recalbox does work in 15kHz via rgb,you could give that a try.

Yeah I also recommend Recalbox before giving up on this. I don't think there's been a new release for Recalbox since I made this topic. I'm still frequently using my Pi 3 B+ with the setup mentioned here, mainly to use Kodi media player to play back DVD rips (or actual discs sometimes) in their intended glorious 480i picture.

[kitty666cats]

Hi all!

I have a HDMI to component no lag converter that simply does the digital to analog conversion. My config file has these changes:

hdmi_ignore_edid=0xa5000080

hdmi_group=1

hdmi_mode=8

hdmi_pixel_encoding=2

avoid_safe_mode=1

disable_overscan=0

config_hdmi_boost=4

hdmi_force_hotplug=1

gpu_mem_256=128

gpu_mem_512=256

gpu_mem_1024=512

boot_delay=3

It seems to work, but only for the initial boot with the 3 raspberry logos and terminal text thing...then it gets wonky...like the signal is too high frequency for my SD tv.

Any tips? I've tried hdmi_mode=6 as well, but that just changes the initial raspberry stuff I can see to be interlaced 480i instead, but the rest is the same signal that can't be viewed on the CRT.

All guides say just use hdmi_group=1 and hdmi_mode=8/6 ..... I must be missing something. Tested on 3 CRTs

this is a RPI 4 with a retropie image

Try lowering “ pu_mem_1024=512” to 256 instead of 512. Also perhaps try lowering the HDMI boost? I got 240p working fine with a Portta HDMI to VGA + sync combiner, but I used a Pi 3B+...

https://www.instagram.com/p/CD7p_FQlMb6 ... bysew4s0yy

Gotta try to dig up my working config.txt again, gahh

[604_degrees]

Hi folks,

I wonder if anyone had succeeded with making RPI4 output 240p over HDMI-to-YPbPr converter?

I've tried several configs described here https://www.retrorgb.com/rpi240p.html but all I get is static (right pic).



However if RPI4 is first connected to an HDMI display, and then being swapped to an HDMI-to-YPbPr converter during boot sequence, resulting image will be visible, but split in half (left pic.)

Someone on Youtube had mentioned that:

I've been looking into this recently. Using the latest Retropie image for RPi 4B. Like the method in the video 5:45 where you use an HDMI to component converter.
EDIT: Further searching and trying, it seems this method won't work for RPi 4 + Retropie at the moment. I believe that's why you were using the RPi 3 in the video.

So I wonder if its true, and if I should opt to RPI3 instead, to complete my build, or wait some time for a possible software fix.

Maybe it is also worth trying to install a different emulation system, instead of Retropie?

[vol.2]

I wonder if anyone had succeeded with making RPI4 output 240p over HDMI-to-YPbPr converter?

So far as I know, the firmware and kernel break it. It's not actually a RPi4 specific issue. Any RPi3 running a new enough firmware and OS also won't work.

It's been awhile since I looked into it, but I believe that it's an issue with the way modedb chooses modlines. The reason you are seeing this is because the Pi is ignoring your custom modeline completely and sending the task to modedb which is choosing from a pool of preset modelines, none of which are proper 240p.

I've even tried to compile custom modelines and added them to the modedb pool with no success. It parses them and then tosses them out, even after saying they are valid.

I suspect it's something with the way they are now doing screen input detection, but driver debugging is above my head.

I think we're stuck until someone at the Pi foundation fixes it with a new update, or someone in the community develops their own fix. When that happens, it's most likely not going to be on shmups. You are better off on github or somewhere else you can follow CRT-switchres or on the Pi forums.

Unfortunately, this isn't a big deal for the pi foundation people. They care zero percent about 240p output over HDMI or custom modelines or any of this and it won't get fixed unless it's by accident while fixing something else.

[kitty666cats]

RGBS HDMI to VGA 240p on 15kHz CRT


https://www.instagram.com/p/CH1DZ0alyAr/


SETTINGS ARE FOR RASPBERRY PI 3B+
Disable Monitor EDID

hdmi_ignore_edid=0xa5000080
hdmi_ignore_cec_init=1

Uncomment For TATE Mode (270 Degree)
#Display_lcd_rotate=3

Uncomment This If Your Display Has A Black Border Of Unused Pixels Visible And Your Display Can Output Without Overscan
#Disable_overscan=1

HDMI To VGA - DMT 640x480p@60hz
#Hdmi_group=2
#Hdmi_mode=4

HDMI To VGA 240p *Needs Sync Combiner, Set Width In LibRetro RetroArch 'Config' Cores To 640 - CEA 720x240p@60hz
hdmi_group=1
hdmi_mode=8
hdmi_pixel_encoding=4

Uncomment To Disable Rainbow Splash On Boot
disable_splash=1
boot_delay=1

Uncomment If You Get No Picture On HDMI For A Default "Safe" Mode
#Hdmi_safe=1

Uncomment The Following To Adjust Overscan. Use Positive Numbers If Console Goes Off Screen, And Negative If There Is Too Much Border
#Overscan_left=16
#Overscan_right=16
#Overscan_top=16
#Overscan_bottom=16

Uncomment To Force A Console Size. By Default It Will Be Display's Size Minus Overscan.
#Framebuffer_width=1280
#Framebuffer_height=720

Uncomment If Hdmi Display Is Not Detected And Composite Is Being Output
hdmi_force_hotplug=1

Uncomment To Force A HDMI Mode Rather Than DVI. This Can Make Audio Work In DMT (Computer Monitor) Modes
hdmi_drive=2

Uncomment To Increase Signal To HDMI, If You Have Interference, Blanking, Or No Display
config_hdmi_boost=5

Uncomment To Overclock The Pi2. 900 MHz Is The Default.
#Total_mem=1024
#Arm_freq=1000
#Gpu_freq=500
#Core_freq=500
#Sdram_freq=500
#Sdram_schmoo=0x02000020
#Over_voltage=2
#Sdram_over_voltage=2

Uncomment To Overclock The Pi3B. DO NOT USE FOR 3B+ 1200 MHz Is The Default.
#Total_mem=1024
#Arm_freq=1300
#Gpu_freq=500
#Core_freq=500
#Sdram_freq=500
#Sdram_schmoo=0x02000020
#Over_voltage=2
#Sdram_over_voltage=2

Uncomment To Overclock The Pi3B+. DO NOT USE FOR 3B 1400 Mhz Is The Default.
#Total_mem=1024
#Arm_freq=1425
#Core_freq=600
#V3d_freq=400
#Sdram_freq=550
#Over_voltage=1
#Temp_soft_limit=70

You Can Also Raise The Minimum Frequency Of The Dynamic Clock (Defaults Are 600 & 250 For Pi3B+)
#Arm_freq_min=900
#Core_freq_min=325

Uncomment Some Or All Of These To Enable The Optional Hardware Interfaces
#Dtparam=I2c_arm=On
#Dtparam=I2s=On
#Dtparam=Spi=On

Uncomment This To Enable The Lirc-Rpi Module
#Dtoverlay=Lirc-Rpi

Additional Overlays And Parameters Are Documented /Boot/Overlays/README
Enable Audio (Loads Snd_bcm2835)
dtparam=audio=on

gpu_mem_256=128
gpu_mem_512=256
gpu_mem_1024=256

#Overscan_scale=1



^ This is what I use with a Portta HDMI to VGA and a sync combiner

May also work with a HDMI to YPbPr!

[vol.2]

That's pretty consistent with OP. The issue is mostly that newer firmware updates have broken the way modedb handles kernel set modelines for many resolutions over HDMI.

It will work like it always worked if your Pi3 is still at a firmware from 2 years ago, otherwise it won't. Pi4 won't work period.

[fernan1234]

That's pretty consistent with OP. The issue is mostly that newer firmware updates have broken the way modedb handles kernel set modelines for many resolutions over HDMI.

It will work like it always worked if your Pi3 is still at a firmware from 2 years ago, otherwise it won't. Pi4 won't work period.

If anyone with a Pi3 has an incompatible firmware, it's possible to "update" to an earlier firmware. Info here: https://www.raspberrypi.org/forums/view ... p?t=275321

[kitty666cats]

That's pretty consistent with OP. The issue is mostly that newer firmware updates have broken the way modedb handles kernel set modelines for many resolutions over HDMI.

It will work like it always worked if your Pi3 is still at a firmware from 2 years ago, otherwise it won't. Pi4 won't work period.

I keep my updates in “Retropie Setup” constantly updated, at least...

P sure I keep whatever’s in “RaspPi Config” consistently updated too?

Which firmware updates do you speak of / benefits of updating ‘em?

[vol.2]

Which firmware updates do you speak of / benefits of updating ‘em?

You wouldn't get firmware updates with retropie. It's done from the command line in raspbian. If things are working for you, there's no need to mess with it as it can break what you have working. My comment was more for random people who might be trying to get this working and have a RPI3 with a more recent firmware on it.

If you follow the link in the previous comment, you can learn more about the firmware update process, etc.

[kitty666cats]

Which firmware updates do you speak of / benefits of updating ‘em?

You wouldn't get firmware updates with retropie. It's done from the command line in raspbian. If things are working for you, there's no need to mess with it as it can break what you have working. My comment was more for random people who might be trying to get this working and have a RPI3 with a more recent firmware on it.

If you follow the link in the previous comment, you can learn more about the firmware update process, etc.

My previous Pi got borked and the one I am currently using (3B+ rather than 3B) is merely ~2 months old... I must have lucked out when setting the thing up from scratch (far before getting Retropie set up etc), hah! Dodged a lil bullet

[WelshMegalodon]

Will this work with other emulators that can output at native resolution? Budget alternatives to CRT Emudriver are always welcome. (Yes, I know this has been attempted before).

[vol.2]

Will this work with other emulators that can output at native resolution?

If you mean, "will this work without creating modelines and loading CRTemudriver in windows." No, I doubt it. I think the path of least resistance with a PC is Linux and groovymame. It's reportedly a painless setup. http://forum.arcadecontrols.com/index.p ... 667.0.html

However, if you just want to get RGB output on a Pi, you can use a VGA output device from the GPIO and output natively by modeline setting in the kernel. The drawback is no interlaced resolutions and you need an add-on board.

This is the basic kind of thing you would need https://texelec.com/product/lo-tech-rpi-vga-board/ though I don't know if that particular one is good or not.

In general, the Pi4 isn't going to be able to play the interlaced generation of game systems, so I find that kind of solution works well for me. I have it hooked up to a PVM and I use a 3840x240 resolution out of the Pi in Retroarch and it looks insanely good to me. Bahn-Yuki here on the forums posted some videos of the same setup on youtube playing Street Fighter, I think in the first page of this thread.
I know there are a few SNES games that switch in and out of interlaced resolutions and PSX games with interlaced menus mostly, but you can view those in 240p with Retroarch, so I don't really care.

[andy64]

When I tried a couple of those cheap made-in-China HDMI-Component boxes (not for this, but for HD stuff) they all seemed to perform about the same.

Edit: will be making an edit to OP. I discovered that simply setting CEA 8 as the video mode is by far better than using the custom video timing (cvt) setting.

Hi, i tried the config that you say with my retropie build and all the systems look much better than before, however, when i excecute the comand tvservice -s shows me that the resolution is 720x240 progressive, is all that correct?

[kitty666cats]

I've made some minor tweaks to what I posted before, with a teensy bit more info intertwined. I rock this instead of any ol' pre-made CRT Pi image... because I needs my X68000 and PC98!

I know it's not exactly new news, but if you follow the simple instructions about 1:1 PAR and then the custom aspect ratio width adjustments, you're sailing smooth without super resolutions. If you apply the EmulationStation theme "RETROCRT-240P" then navigating looks fine, too.

This is for a 3B+. Would love to hear of anyone trying this with a HDMI to component!

This works with any new RetroPie 3B+ (or 3 / 3B I believe?) release / update, I update any marginal changes in "RetroPie Setup" quite frequently (maybe 2 or 3 times a month).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SETTINGS ARE FOR A RASPBERRY PI 3B+ DISABLE OVERCLOCKING ETC IF YOU HAVE ANY ISSUES.

Disable Monitor EDID
hdmi_ignore_edid=0xa5000080
hdmi_ignore_cec_init=1

Uncomment For TATE Mode (270 Degree)
#Display_lcd_rotate=3

Uncomment This If Your Display Has A Black Border Of Unused Pixels Visible And Your Display Can Output Without Overscan
#Disable_overscan=1

HDMI To VGA for 4:3 PC CRT's / HD CRT's etc - DMT 640x480p@60hz
#hdmi_group=2
#hdmi_mode=4
#hdmi_pixel_encoding=2

HDMI To VGA/Component 240p * VGA Needs Sync Combiner Set Width In LibRetro RetroArch 'Config' Cores To 640. Ideally, boot the ROM, press select and "Y" (whatever button you've set as “Y” on your USB gamepad etc) go to settings > scaling > aspect ratio > 1:1 PAR (and set integer scaling to ON!) > change to 'custom' aspect ratio and change width to 640 * - CEA 720x240p@60hz
hdmi_group=1
hdmi_mode=8
hdmi_pixel_encoding=2

* The above setting at "2" is full 0-255 RGB. If you want a bit more vibrant/saturated image, set to "4" for full 0-255 component/YCbCr/YPbPr/YUV/whatever you wanna call it *

Uncomment To Disable Rainbow Splash On Boot
disable_splash=1
boot_delay=1

Uncomment If You Get No Picture On HDMI For A Default "Safe" Mode
#Hdmi_safe=1

Uncomment The Following To Adjust Overscan. Use Positive Numbers If Console Goes Off Screen, And Negative If There Is Too Much Border
#Overscan_left=16
#Overscan_right=16
#Overscan_top=16
#Overscan_bottom=16

Uncomment To Force A Console Size. By Default It Will Be Display's Size Minus Overscan.
#Framebuffer_width=1280
#Framebuffer_height=720

Uncomment If Hdmi Display Is Not Detected And Composite Is Being Output
#hdmi_force_hotplug=1

Uncomment To Force A HDMI Mode Rather Than DVI. This Can Make Audio Work In DMT (Computer Monitor) Modes
hdmi_drive=2

Uncomment To Increase Signal To HDMI, If You Have Interference, Blanking, Or No Display. Increase to 7 if you have continued interference, static etc
config_hdmi_boost=5

Uncomment To Overclock The Pi2. 900 MHz Is The Default.
#Total_mem=1024
#Arm_freq=1000
#Gpu_freq=500
#Core_freq=500
#Sdram_freq=500
#Sdram_schmoo=0x02000020
#Over_voltage=2
#Sdram_over_voltage=2

Uncomment To Overclock The Pi3B. DO NOT USE FOR 3B+ 1200 MHz Is The Default.
#Total_mem=1024
#Arm_freq=1300
#Gpu_freq=500
#Core_freq=500
#Sdram_freq=500
#Sdram_schmoo=0x02000020
#Over_voltage=2
#Sdram_over_voltage=2

Uncomment To Overclock The Pi3B+. DO NOT USE FOR 3B 1400 Mhz Is The Default.
Total_mem=1024
Arm_freq=1425
Core_freq=600
V3d_freq=400
Sdram_freq=550
Over_voltage=1
Temp_soft_limit=70

You Can Also Raise The Minimum Frequency Of The Dynamic Clock (Defaults Are 600 & 250 For Pi3B+)
Arm_freq_min=900
Core_freq_min=325

Uncomment Some Or All Of These To Enable The Optional Hardware Interfaces
#Dtparam=I2c_arm=On
#Dtparam=I2s=On
#Dtparam=Spi=On

Uncomment This To Enable The Lirc-Rpi Module
#Dtoverlay=Lirc-Rpi

Additional Overlays And Parameters Are Documented /Boot/Overlays/README
Enable Audio (Loads Snd_bcm2835)
dtparam=audio=on

gpu_mem_256=128
gpu_mem_512=256
gpu_mem_1024=512

#Overscan_scale=1

[kitty666cats]

I don’t own a 15kHz component display right now, but someone in the CRT Discord tested this config via HDMI to YPbPr on their PVM-20L5 and it worked perf! They used that generic black unit with flat sides and slightly rounded “roof”. I use the black Portta HDMI to VGA with blue text and combine sync for RGBS.

“ 640 width should be perf in RetroArch if u have Pi set to hdmi mode 1 group 8 (720x240p)

load libretro emulator into retroarch with 'config' as the retroarch output, go to settings and scaling, set integer scaling ON and then switch aspect ratio to 1:1 PAR. then switch it to custom, leaving integer scaling on, and change width to 640

and it should fill up your screen just right“

^ that’s what I expounded to the person last night on Discord (config.txt states this already but above info is a tad more detailed.


So yeah, this is a pretty damn solid alternative to overpriced GPIO hats, custom HDMI modes & the battle to sort through super resolutions tryna decide on which best suits you! Party on, dawgies (p.s. Game Boy Advance width should be 480)

This isn’t a ~ massive breakthrough ~ or whatever but it’s a good mash up of different dependable configs I have encountered over the year, with some decently easy to follow directions in the .txt for the newer Pi users! Hecc yeah

[vol.2]

This isn’t a ~ massive breakthrough ~ or whatever but it’s a good mash up of different dependable configs I have encountered over the year, with some decently easy to follow directions in the .txt for the newer Pi users!

So, the main issue I think with the hdmi->analog rgb is that we don't know which combinations of firmware and software on the Pi3B+ are working and which ones are not.

Further compounding that question mark is the fact that, in non-working situations, it appears that modedb is the problem; it is choosing incorrect resolutions in spite of being told to choose a specific one in the kernel.

Perhaps someone has a better approach, but I think that if we want a meaningful body of useful information pertaining to using an hdmi -> [analog rgb] adapter with a Pi3B+, we need to at the very minimum include the firmware revision and the software release (for example Lakka 1.78 or something) that is being tested. If we don't know those two things, then it doesn't really tell us anything we don't already know. (we know it works on some combos already, and doesn't work on others)
Ideally, we would also have the log output from boot. That will have the relevant information where the kernel mode is passed to modedb, and it will then show it's answer and what resolution is actually chosen. It doesn't seem to be an issue for dpi overlays, it's only with hdmi that modedb become the gatekeeper and scraps the kernel set mode for one that resides in it's pool of edid. The log file would show what it is picking for whatever mode that is chosen, and then a correlative database could be formed describing what you actual get when you set what you set for any given combo of firware/software.