Absolute maximum horizontal resolution for HD 5450 at 240p?

[SamIAm]

tl;dr: For science, how high can the horizontal resolution possibly be set on an HD 5450 with CRT Emudriver doing 240p (or 480i) at 60Hz with generic TV timings? Does this change with other CRT Emudriver-compatible graphics cards and/or operating systems?


Background: Some CRT enthusiasts are beginning to consider the possibility of completely replacing the RGB amplifier circuitry and other signal processing circuitry in consumer televisions because it appears that they are a major bottleneck - more so than even the dot-pitch of the tube's grille or mask in many cases. To test new designs and run comparisons, it would now be very useful to have a TVL test-pattern generator: that is, something which would produce alternating black and white vertical lines at various frequencies.

I recently made up a bunch of images targeted at 2560x240 resolution which feature alternating lines, each of a single pixel width per image. The largest width is fifteen, and the smallest is one. This is what the fifteen-pixel width image looks like (scaled):



This, of course, is what it looks like on a real TV in 2560x240:



Download all the images here if you like. I use irfanview as an easy full-screen viewer.

Dividing 2560 evenly, we get a very useful range of TVL test patterns. In fact, this is already probably the best option currently available. However, the higher we can set
the base horizontal resolution, the finer the steps in the relevant range (<1000 TVL) we can take. I'd like to push my HD 5450 to its maximum, if it's not there already.

I figured I'd ask before tinkering around and possibly breaking something.

Thank you!

[buttersoft]

I saw your post on the TVL mod thread too. The images are a great idea, thanks for sharing.

AS for theoretical max resolution of a 5450... cnet says it can do 2560 x 1600. Assuming for the moment that's wrong, and it can only do 1920x1080@60Hz and factoring backwards even more conservatively:

2200 x 1100 x 60 = 145Mhz pixel clock bandwidth.

145,000,000 / ( 262 x 60) = ~3800 pixels wide

I know there were people out there pushing 3840 as a modeline for being a multiple of more base resolutions. There is no way in hell a consumer CRT amp can go that high though, surely. I haven't looked at the transistors for too long, but what bandwidth are they typically? A 480i modeline is only just over 20Mhz. The result over exceeding the limit is just dull blended colours, but the phosphor pitch and TVL can't get anywhere near a super resolution anyway, even with the spot-size mod to G1, can they? I'd always assumed the fact the pixels were in groups meant the transistors were just squirting colour until told to switch. I can't remember if Luke Evans Simon was talking specifically about the transistors switching on and off for each pixel? Given the electron beam is dynamic, and spot size was deliverately poorly-controlled on consumer sets, would they really need to?

I'm really hoping someone will write out a summary guide from that thread on shmups so i don't have to wade through it all. Then i can try it out when i get bored and when i have time (which given i have kids now is going to be in about twenty years, lol).

[SamIAm]

I did look into it a little, and the 2560x240p60 mode is using a 51MHz pixel clock, while the HD 5450's 2560x1600 max is right around 250MHz. So, the pixel clock alone shouldn't be a limiting factor, but I'm still wondering if there is some sort of horizontal line pixel-limit that's common among CRT Emudriver-compatible cards.

Right now, dividing 2560 pixels evenly (and multiplying the result by 0.75 to get TVL for a 4:3 screen) we can get 1920, 960, 640, 480, 384 and lower TVL test screens. If we were dividing 5120 evenly, we'd get 3840, 1920, 1280, 960, 768, 640, 548, 480, 426, 384, 349 and lower TVL test screens, all near-instantly switchable. The test screens over 1000 TVL don't really matter, but the additional screens under 1000 TVL would be really nice to have.

EDIT: Also from the TVL mod thread - A quick and cheap video showing how easy it is to change TVL screens with this approach. All I'm doing is pressing left on my keyboard.

[Calamity]

Hi SamIAm,

I don't think there are any limit for xres in the drivers, except for the size of the type (unsigned short if I remind right). The actual limit, as buttersoft pointed, is likely in the pixel clock. But I'd say you can go up to 3840 and probably higher.

[SamIAm]

Hi Calamity,

Thank you for your reassuring reply. I'll give some crazy-high resolutions a shot, then. If 2560 x 1600 is possible, then 10240 x 240 ought to be possible as well, and that would give us all of the TVL test pattern increments we'd ever really need. I'll let you know how it goes!

[SamIAm]

After a small amount of experimenting last night, I have an update.

By simply adding the line "3840 x 240 @ 60.000000 super" to the file "user_modes - super.ini" and going through Generate Modes -> Install Modes again in VMMaker, I was able to successfully get a 3840 x 240 modeline working. It appeared in arcade_osd, and when I set it as my desktop resolution, it was perfectly functional. For anyone else who tries this, here is another set of test patterns tuned to 3840 x 240. It's unmistakably superior to the 2560-wide version.

When I added the line "5120 x 240 @ 60.000000 super", it was listed during the VMMaker install but did not appear at all in arcade_osd.

And then, when I added the line "10240 x 240 @ 60.000000 super" and clicked Install Modes in VMMaker, there was a failure that resulted in the video mode switching to something my TV wouldn't sync. Upon rebooting, the desktop was in 640x480p, which I could manage to use, and it looked as though all VMMaker modelines had been erased. Fortunately, all I had to do was delete that one line from user modes - super.ini and do the VMMaker install one more time, and everything was back.

Any thoughts?

[donluca]

Thanks for doing those tests. It is really interesting and I've always been a bit skeptical about super resolutions.
I really miss the days where you could install 200+ modelines so that you had 1:1 resolution for the various arcade games.
I know that super resolutions are a godsend for those who don't have monitor controls so that they can always have the image centered and properly stretched to full screen, but I remember there were a couple of cases where graphical imperfection arose (one was in R-Type I believe? There's an image of this buried somewhere in a thread in this forum).

Maybe 3840 would give enough granularity to make the rendering of the images perfect or, at least, hardly undistinguishable from a 1:1 resolution.

[Calamity]

I've done some tests and it looks like there's a built in limitation for horizontal resolution at 4096, that's independent of the pixel clock.

E.g., 5120 x 240 isn't allowed, while 4096 x 480p, with much higher pixel clock, is allowed.

3840 is nicer as a super res because it's an integer multiple of 256, 320 and 384.

[donluca]

I've done some tests and it looks like there's a built in limitation for horizontal resolution at 4096, that's independent of the pixel clock.

E.g., 5120 x 240 isn't allowed, while 4096 x 480p, with much higher pixel clock, is allowed.

3840 is nicer as a super res because it's an integer multiple of 256, 320 and 384.

I wonder if this is the case in Linux as well, can someone with GroovyArcade test this?

[SamIAm]

I've done some tests and it looks like there's a built in limitation for horizontal resolution at 4096, that's independent of the pixel clock.

E.g., 5120 x 240 isn't allowed, while 4096 x 480p, with much higher pixel clock, is allowed.

3840 is nicer as a super res because it's an integer multiple of 256, 320 and 384.

That's fantastic information to have. Thank you for taking the time to check yourself.

Between the 3840-wide and 2560-wide sets, we have a very thorough collection of test screens. Beyond that, it's probably better for anyone hoping to test a specific TVL number to make a custom modeline and simply truncate one of the 3840 test screens.

I really do hope that one day we can achieve a significantly improved picture quality on a mid-range consumer CRT by replacing the entire RGB signal processing pipeline. If it happens, perhaps I'll post an update here!

Thanks again, Calamity. I'm a big fan of everything you do and have done.