Any HDMI DACs that support low (like 320x240) pixel clocks?

[maxtherabbit]

27MHz would be both line and pixel doubled

No, it's just pixel-doubled.

13.5MHz would be 858 samples per line with 262 lines, which I assume is what you're saying it outputs when you switch line doubling 'off' for 240p?

Correct, the Gamecube uses a 13.5MHz pixel clock for 15kHz modes, so either 858 or 864 total luma samples per line with 720 or less of them outside of blanking.

unless you're saying it outputs 1716 (luma) samples per line when line doubling is off?

Yes, conforming to CEA modes 6/7 (NTSC interlaced), 8/9 (NTSC 15kHz progressive), 21/22 (PAL interlaced) or 23/24 (PAL 15kHz progressive)

so 858 luma samples from the cube gets doubled to 1716 samples coming of GCV-DVI for a 27MHz pixel clock even when the OSD option for 240p line doubling is turned off?

that's interesting that you had to do that to get any HDMI sources to sync to it

(I see your point about it being pixel doubled from the perspective of GC Video, but since the GC is outputting 858 samples per line in 240p that's already "pixel doubled" relative to traditional 240p from older consoles, so it's really pixel quadrupled in a manner of speaking)

[Unseen]

so 858 luma samples from the cube gets doubled to 1716 samples coming of GCV-DVI for a 27MHz pixel clock even when the OSD option for 240p line doubling is turned off?

Yes. It's exactly according to spec in this regard.

that's interesting that you had to do that to get any HDMI sources to sync to it

I'm not surprised, DVI specifies a minimum pixel clock of 25MHz and that has been carried forward into HDMI. Pixel doubling in HDMI exists mainly to make it possible to transport 480i and 576i Bt.601-compatible signals over it, which would fall below that 25MHz limit otherwise.

(I see your point about it being pixel doubled from the perspective of GC Video, but since the GC is outputting 858 samples per line in 240p that's already "pixel doubled" relative to traditional 240p from older consoles, so it's really pixel quadrupled in a manner of speaking)

I'm very glad that I don't need to care about the origin of the data that GCVideo processes, otherwise weird questions could come up like the pixel/line-multiplication status of a 640x480 black screen.

[Classicgamer]

What graphics card that actually supports CRT emudriver doesn't have native analog output? Freesync is Displayport and that should automatically provide easy access to analog.

Furthermore, what consumer display is going to cooperate with a such a ridiculously low pixel clock? That's about 6MHz.

The OSSC isn't a true passthrough and it already changes the pixel clock. AFAIK, you can't get 6MHz pixel clock QVGA out of the OSSC at all.

Also, how would Freesync work with the OSSC in the chain?

The latest versions of CRT EMU are made to work with Windows 10 and later AMD GPUs like the 7000 series which don't have analog output. 240p is output via HDMi with a digital to analog converter. There is nothing about HDMI that prevents low resolutions if the display can handle it. The dot clock limitation is in the GPU.

The super resolutions shouldn't make a difference when output to an SD CRT as they don't recognize horizontal resolutions. It's only about the number of lines. The only time I have had issues with Super resolutions is when I try to play early 3d EGA games on Model 2 in their native 384p.

It shouldn't matter for sprite based games.

I use a Radeon 5970 which I'm told is the best GPU that works with CRT EMU and has analog RGB output. It's good enough to play anything 480p and below.

[orange808]

The dot clock limitation is in the GPU.

Yep. Sure is.

The super resolutions shouldn't make a difference...

What "super resolution"? We're talking about an exceptionally low dot clock.

...when output to an SD CRT as they don't recognize horizontal resolutions. It's only about the number of lines. The only time I have had issues with Super resolutions is when I try to play early 3d EGA games on Model 2 in their native 384p.

Yes. It's a wave and the television's circuitry and electron gun simply respond to it. Yuppers.

Furthermore, I physically fed a QVGA signal into a couple of my own consumer CRT NTSC televisions and couldn't get a proper synced picture.

800 (640 active) x 262 (240 active) with ~12.7MHz pixel clock worked, though.

Real QVGA works fine using a "multisync" VGA/EGA/CGA monitor. So, there are CRTs that will accept it.

I use a Radeon 5970 which I'm told is the best GPU that works with CRT EMU and has analog RGB output. It's good enough to play anything 480p and below.

I'll have to check out the CRT emudrivers again if I get another AMD card. I abandoned all of that some time ago and started using line doubled output from emus and a downscaler before the CRTs. It's easier and I can use an nVidia card. General AMD hardware performance and developer support from new titles is lacking.

I still personally doubt that any driver out there lets you output true QVGA timings with a real ~6MHz pixel clock. As noted, most gear won't accept the signal.

[maxtherabbit]

classicgamer is saying that it doesn't make a difference to the CRT if the HDMI DAC is receiving 429, 858, or 1716 samples per line, and he is 100% correct - the analog output of the DAC would be the same

[orange808]

classicgamer is saying that it doesn't make a difference to the CRT if the HDMI DAC is receiving 429, 858, or 1716 samples per line, and he is 100% correct - the analog output of the DAC would be the same

That's not what I see. If I misunderstood, I apologise.

I see a claim that: I can send any dot clock I want (regardless of circumstances) and get a perfectly synced image, because CRTs don't have a discrete horizontal resolution.

However, I can clearly see that isn't true. If it was, I could get this QVGA to work on both these consumer sets and a computer monitor from the mid-nineties; however, it only works with the monitor. So, there are clearly cases where it mattters.

--------

429 total samples (320 active) with 262 total lines (240 active) @60Hz fed directly to a consumer CRT display with nothing inbetween? Well:

Spoiler

https://i.imgur.com/8u7TNLP.jpg

-----

I assume you're telling me the DAC will resample the output?

[BazookaBen]

I think you're confused about something orange808, because basically every console in the 80's and 90's put out QVGA or less, and they worked on practically every CRT.

FreeSync on 15KHz CRT has been explored recently @BYOAC, and confirmed not properly working. It can work but most of what you'll get is a shaking and jumping, jerky picture, how much also depends on the display so it's a mess.
Unless a trick is found in the future to actually make it valid, there's no point in bothering with that.

I couldn't find anything from googling that website about freesync on 15kHz crts.

And my objective is to play games that already have locked framerates somwhere in the 59.7-60.1 range, which should provide a consistent picture on a CRT as long as the sync signals aren't too far off the standard.

The whole point is to get the lowest lag possible without tearing. "Scanline sync" from RTSS is relatively new thing that gets 90% there, but you have to manually change your refresh rate, up to three decimal places, to match the specific game you're playing, otherwise you get periodic tearing. And finding those refresh rates was already pretty difficult to find for the 3DS ports and Wii emulator I'm playing, and I imagine much more so for some obscure arcade game.

With Freesync, you wouldn't have to mess with refresh rates at all, just start playing the game. And there might even be a 16-8ms advantage in latency over RTSS's s-sync.

[orange808]

I think you're confused about something orange808, because basically every console in the 80's and 90's put out QVGA or less, and they worked on practically every CRT.

https://wiki.nesdev.com/w/index.php/NTSC_video

Yes and no.

[BazookaBen]

https://wiki.nesdev.com/w/index.php/NTSC_video

Yes and no.

In my understanding, in digital to analog converters, pixels are converted to microseconds. Like a red pixel at 320x240p would be twice as many microseconds as one at 640x480. I don't think there's anything in the color signal or sync signal to convey a "pixel clock", just the horizontal blanking pulse to make sure the TV moves the line back to the left side.

Maybe it's different on composite signals, maybe I'm wrong altogether

[Unseen]

However, I can clearly see that isn't true. If it was, I could get this QVGA to work on both these consumer sets and a computer monitor from the mid-nineties; however, it only works with the monitor. So, there are clearly cases where it mattters.

Did you adjust the horizontal sync timings (which are usually given in pixels) as well to ensure that the sync pulse has the same duration (in microseconds) and position relative to the active area?

[orange808]

https://wiki.nesdev.com/w/index.php/NTSC_video

Yes and no.

In my understanding, in digital to analog converters, pixels are converted to microseconds. Like a red pixel at 320x240p would be twice as many microseconds as one at 640x480. I don't think there's anything in the color signal or sync signal to convey a "pixel clock", just the horizontal blanking pulse to make sure the TV moves the line back to the left side.

Maybe it's different on composite signals, maybe I'm wrong altogether

My displays must be unusually picky. I knew my flat Trinitron was picky, but my curved tube Sony has always been more cooperate.

Something about QVGA is messing up the television's "ability" to identify sync. Essentially doubling the amount of samples on each line fixes it.

[orange808]

However, I can clearly see that isn't true. If it was, I could get this QVGA to work on both these consumer sets and a computer monitor from the mid-nineties; however, it only works with the monitor. So, there are clearly cases where it mattters.

Did you adjust the horizontal sync timings (which are usually given in pixels) as well to ensure that the sync pulse has the same duration (in microseconds) and position relative to the active area?

I'll mess with it some more and see if I can get it going.

[クリスチャン]

I recently bought a HDMI to YPbPr DAC with the usual Lontium chip and I'm having a hell of a time trying to get it to work with my 1080 ti, Windows 10, and my CRT. Lowest res I seem to be able to output is 480p. Even using custom resolutions the GPU still only outputs 480p. I was able to get it to output 480i and 240p by randomly messing with the scaling options and custom resolution settings in the NV control panel, but custom resolutions seem to be bugged in general as they wouldn't show up most of the time in the resolution list. I haven't messed with "super resolutions" and don't really understand how they work but I'm willing to try if someone could elaborate on them. I think the DAC itself has issues with the resolutions as some timing standards (DMT, GTF, etc.) don't work at all with the DAC.

[BazookaBen]

but custom resolutions seem to be bugged in general as they wouldn't show up most of the time in the resolution list.

Try the quickres utility to expose low resolutions:

https://www.ultimarc.com/download_old.html