Perfect output on consumer CRTs - CRTSwitchRes pointless?

I took the Philips PM5544 test image available at https://en.wikipedia.org/wiki/Philips_PM5544, scaled it to 768x576px as well as 640x480px, and that´s how it looks like on a “normal” consumer CRT TV, output with Kodi set to the appropriate resolution:

Original:

NTSC (640x480):

PAL (768x576):

In fact, this is not reference quality, but you can guess that ~40px are cut on the left, 45-50px on the right, 20px on top and 20-25px at the bottom with the standard settings - maybe I am gonna check the service menu to move the image a little to the left… But I would not say the factory settings result in a complete misalignment.

Then, I took a closer look at the cores´ settings. Mednafen Beetle PSX seems nearly to work as it should: When I enable the overscan setting, the internal resolution is being changed. In the tests I did, e.g.

  • 640x576_50 was changed to 700x576_50
  • 365x576_50 was changed to 400x576_50
  • 320x288_49.76 was changed to 350x288_49.76

However, I still had to disable integer scaling (do not unterstand yet, why I have to) to get an output without borders, but the aspect ratio seemed to be right, nothing was cut on the left or right.

I also found border settings in Genesis Plus GX - setting it to “full” changed the resolution from 320x224_59.92 to 348x240_59.92.

And Stella changed from 152x240_60 to 160x240_60.

But I had no success with several other cores like the NES and SNES cores delivered with Batocera - even if there were border or overscan settings, the NES resolution was always set to 256px instead of 280px.

I don´t know how the developers of Beetle PSX and Genesis Plus GX calculate the overscan area. But according to the nesdev-Wiki at https://wiki.nesdev.com/w/index.php/Overscan, it is sufficient to multiply the pixel rate by the scanline length to get the really needed horizontal resolution for a CRT with overscan area - as long as the dot clock rate is known (see the table for 240px in the link above).

Therefore, it would be great if a core would either deliver the right resolution depending on the overscan setting (as we see with Beetle PSX, Genesis Plus GX and Stella) out-of-the-box, if a core would optionally deliver the corresponding dot clock rate in addition to the internal resolution or if there was an option in CRTSwitchRes to add it manually. But this won´t be that easy because for different resolutions, you would have to be able to define different dot clock rates.

Hi All,

Let me start with the dotclocks and Porches. Dotclocks are calculated on the fly. They are all different per resolution. (Padding) porch values are also the same, without then you would not be able to generate a 15khz signal that your CRT could decode.

During development, I compared real hardware to RA CrtSwitchRes. This was done visually and using a oscilloscope. So when it comes to accuracy outputting the correct video signal per resolution, it is pretty close. Emulators are designed to show you the entire image whereas games on real hardware took into account CRT over scan. Most if not all had a hole area that was not visible, it was designed this way so the video would fit most consumer CRTs all with different hardware. If you take a look back through my videos from the start of this development you will see a few comparisons.

https://www.youtube.com/channel/UCT73WExrpXVzgeo33hOvvYw/videos?view_as=subscriber

One large limitation with this is that most is not all PC video card were not designed to output these low resolutions. Through development I found that different video card would output slightly differently.

With windows you are limited to CRTEmudriver, to get the correct resolutions you need to know the exact hardware setting other wise you need to edit the overscan in Arcade OSD.

When using Linux the best option it to use dynamic resolution for best compatibility but even then same video cards will not work well if at all. Then you need to try the super wide options.

All PC hardware is different, and due to this there will never be consistency across the board. This is why MME4CRT development has changed direction.

1 Like