X Modeline for CRT Super Resolution on NTSC CRT TV?

The subject pretty much says it all… I’m trying to run RetroArch under XWindows on Linux (Ubuntu 20.04), outputting to a consumer 4:3 NTSC CRT TV via an HDMI to component video transcoder.

I’m not running CRT Switchres, I just want to run X at a fixed super resolution (1920x240 would be great.)

I’ve tried creating a [email protected] Modeline using various Modeline generators I’ve found on the web, and a few have come close; they actually work on my LCD TV, but the CRT TV doesn’t quite sync up to them… I can see the picture, but it either rolls or loses horizontal sync.

Here are some that I’ve tried that DON’T work (among others):

"[email protected]"   31.92  1920 1952 2072 2104  240 245 248 253 -HSync +Vsync
"[email protected]"   34.25  1920 1864 2040 2224  240 241 244 257 -HSync +Vsync
"[email protected]" 37.25 1920 1968 2160 2400 240 243 253 259 -HSync +VSync
"[email protected]"  36.527232  1920 1968 2160 2400  240 244 248 254  -HSync -VSync

I’m guessing it has to do with the whole CEA/DMT/GFT/CVT timing standards. I think TVs need CEA timing, but all the modeline generators I’ve found online seem to only support the others?

I’m running an ancient AMD video card, so I don’t think I have any limits on the pixel clock like one does with Nvidia cards or on the Raspberry Pi.


I forgot to mention… I have gotten it to work on a Raspberry Pi using “hdmi_cvt=1920 260 59.92 1 0 0 0”, so I know the transcoder and everything works. I just don’t know how to translate the Pi’s hdmi_cvt setting into a valid modeline. I’m trying to upgrade from the Pi to a more powerful desktop so I can run some of the more resource intensive cores.


Here’s the one I’ve used in the past:

[email protected]” 31.96 1920 1952 2072 2104 240 245 248 253 -HSync -VSync

Hmmm… like the other ones, that seems really close to working. It’s still not quite syncing to it though. Maybe this is just a really sensitive TV. I have seen it work though, so I know there’s a modeline out there waiting for it. :smiley:

Have you tried poking around with the sync commands at the end? Like, changing + to - and vice versa? There’s also CSync, which may help.

Number of total lines may be a bit low, in reality it’s usually ~262. Maybe it’s an especially picky TV, or the timings are really unsuited. I don’t generate mine with Linux CVT, I usually use Winmodelines (also under Wine) or CRU under Windows. The CRU timings I modify as well though.

Here’s another you could try

xrandr --newmode “1920x240” 37.7 1920 2064 2232 2400 240 243 246 262 -hsync -vsync

If even this one doesn’t work, you could try some others of mine to see so if anything syncs at all:

xrandr --newmode “1280x228_59” 25.17 1280 1344 1472 1640 228 232 235 259 -hsync -vsync

xrandr --newmode “648x240_60” 12.84 648 672 736 816 240 243 246 262 -hsync -vsync

xrandr --newmode “1280x240_60” 25.78 1280 1352 1468 1640 240 243 246 262 -hsync -vsync

1 Like

Thanks Jamirus. None of those worked either though, nor any combination of positive or negative syncs as hunterk suggested. I did get VERY close with this one, which I actually got by using xrandr on a raspberry pi to query the modeline it was running at:

“1920x260_pi4” 39.164 1920 1976 2160 2400 260 263 273 276 -hsync -vsync

By “very close” I mean it will actually sync up, briefly (and OMG does the Sega logo look glorious after all this, lol), but then after 2-3 seconds it loses sync again. Actually I think it’s as soon as the logo goes away, so maybe that’s related.

I find it odd that the same modeline that works on the Pi doesn’t work on an X86 Linux install with an AMD card. I know the Pi has some pixel clock limits that make it less than ideal to use with a CRT, so I figured the AMD card would be much easier to get working.

I’ve tried two different AMD cards with the same results, but they’re both of the same vintage (old: one’s an X300 and the other’s an X600), so maybe it’s just some limitation of these cards? I have a beat up laptop with a somewhat more modern Radeon HD 7660G I’m installing Ubuntu on now, I’m going to give that a try just as a test to see if I get anything different.

You could be right that it’s a really sensitive TV (It’s an Insignia IS-TV040922 btw), but it seems to be so easy to get it to work with the pi. I can even throw different resolutions at it (260p, 240p, 224p) on the pi with no problem.

The pixel clock limitations are usually what makes super wide resolutions a necessity, not an option. If you use such a resolution anyway, I don’t see why using something with a lower pixel clock is an advantage in that regard. And those X cards are really old, do you actually output HDMI directly from those? The oldest card I’ve used for 15 Khz was some Radeon 2xxx of a laptop, every AMD/Nvidia/Intel card worked fine for me since then under Linux, my setup is a bit different though because PAL land.


I’m not sure if I should celebrate or bang my head against the wall for wasting so much time on this though…

Once I fired up the laptop with the 7660G, everything worked perfectly on the first try, with the exact same modeline, copy-pasted from one machine to the other. It was the darned old AMD cards all along. I still don’t get exactly what the problem was, but something about them my TV does not like.

You’re absolutely right, these cards are old, and they don’t have HDMI outputs (I was using a passive DVI to HDMI adapter). They were the only AMD cards I had on hand though, and from all I had read I thought that was the better way to go than a more modern Nvidia card. They’re listed on the CRT Emudriver page as supported, so I assumed they would be good for what I was doing as well, since I’m using the same resolutions.

I still have some fine-tuning to do as far as picture size and centering and what not, but now that I have a working setup and a stable picture, I think I can handle that.

Thanks to both of you!


In linux, the GPU vendor doesn’t matter, thankfully.