Tweaking monitor.ini for NTSC TV Sony kv-27s42

[feltz]

Hey all, i been working on trying to setup my GM + CrtEmudriver for this TV for quite some time, and I think I have it pretty close. Apologies for any ignorant things, as I still dont quite fully understand it all.

So i setup the crtemudriver successfully and got an RGB signal out.
I'm running that into a RGB2YC transcoder (https://www.axunworks.com/RGB-to-Composite-S-Video-p341706.html)
After some adjustments in the service menu for my TV, i was able resolve some vertical overscan issues.
Now i'm trying to resolve the horizontal ones. Doing it within my TVs service menu did not resolve it.

Doing lots of searching and reading the various posts around ArcadeOSD usage, it sounded as if I could simply find the adjustments i needed for the horizontal timings, write those values down, and make the modification to the crt_range0 for the monitor i am using (I have it set to "ntsc" currently)

What I dont fully understand, is how those adjustments go into the monitor file.

When I run ArcadeOSD, i only see the desktop mode available. I went into the horizontal geometry of that resolution, 640x480@30i, and noted the values there. Those values dont match whats currently in the monitor.ini file for "ntsc". So that's where im stuck.

When i made adjustments to the H front and back porch values, i was able to fix the overscan.

Attaching pictures of both before and after changes. How do I go about applying that to the monitor file?

[Trnzaddict]

I see no one has responded after 400 views. FWIW and someone can correct me if I’m wrong, I looked at the transcoder you’re using and it only has composite or svideo out. I’ve never seen this transcoder before….I was told when I went CRT hunting that CRT_Emudriver will only work correctly on a component in connection.

According to your TV specs you only have an svideo and composite input, no component.

But again I’ve never seen this transcoder and the only ones I’ve seen have a VGA in and component out ONLY.

Maybe Calamity can chime in?

[buttersoft]

You can't move that single 480i mode in your list because it's the mode in the EDID. To fix your issues you need to...

Firstly, follow one of Calamity's setup guides, step by step, right to the end. That will install more modelines. For Radeon HD 5000 series cards or newer, this is the guide - https://geedorah.com/eiusdemmodi/forum/viewtopic.php?id=301

Next is horizontal timings (positioning). Below is the arcade_15 range line from the monitor.ini file. In bold are the values for HFrontPorch, HSyncPulse, HBackPorch respectively, and you can find them in ArcadeOSD when editing. Your values will be different, remember.

      crt_range0  15625-16200, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 0, 0, 192, 288, 448, 576

You find these timings by editing modes in ArcadeOSD. Write down the numbers you settle on. Then either edit monitor.ini (just copy your existing preset and name it something different, and then overwrite your timings) and redo VMM and setting up your modelines. Or simply edit those timings into the mame.ini crt_range0 line. I prefer the latter, as i'm using a wider spread of modes than most people and it works better for that. And for specific machines or games you can create files like neogeo.ini or ffight.ini in the mame/ini directory, if needed, with the range line adjusted.

When you set up GroovyMAME, make sure to leave the infoscreens enabled. That means when you load a game you get a screen showing the game's native resolution, and the resolution switchres has picked. If you're using super resolutions, the vertical mode picked should be the same or slightly larger than the native res. 2560x240p is fine for CPS1 games at 384x224p, for example, and will leave 8 blank lines top and bottom - assuming you've set integer scaling for the vertical res, of course.

Now, once all that is done, there's your converter. Cheap S-video/composite converters will simply produce 480i no matter what the input is, and they tend not to take 480i input. Yours looks to be a higher quality model, i'll grant, but that site provides no specific information about signal formats. A good converter will output the same signal format as the input (so a RGBS input at 384x224@5997Hz comes out as exactly that, only as S-video PAL/NTSC). So, when a game loads at 240, does the image look nice and solid, of do horizontal lines still flicker? A good way to check this is to set your desktop to 320x240p and take a look at horizontal window borders. Then go back to 480i and see the difference, because it should be pretty marked. (Obviously the resolution is a lot lower, but the flicker of horizontal lines should be there at 480i and not at 240p)

If you give any of this a go, and are still confused, have a read of this guide: https://www.aussiearcade.com/forum/arcade/m-a-m-e-emulation-projects-and-discussion/89704-a-guide-to-connecting-your-windows-pc-to-an-sd-crt-tv-pvm-or-arcade-monitor#post2194681

[Trnzaddict]

You can't move that single 480i mode in your list because it's the mode in the EDID. To fix your issues you need to...

Firstly, follow one of Calamity's setup guides, step by step, right to the end. That will install more modelines. For Radeon HD 5000 series cards or newer, this is the guide - https://geedorah.com/eiusdemmodi/forum/viewtopic.php?id=301

Next is horizontal timings (positioning). Below is the arcade_15 range line from the monitor.ini file. In bold are the values for HFrontPorch, HSyncPulse, HBackPorch respectively, and you can find them in ArcadeOSD when editing. Your values will be different, remember.

      crt_range0  15625-16200, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 0, 0, 192, 288, 448, 576

You find these timings by editing modes in ArcadeOSD. Write down the numbers you settle on. Then either edit monitor.ini and redo VMM and setting up your modelines, or simply edit those timings into the mame.ini crt_range0 line. I prefer the latter, as i'm using a wider spread of modes than most people. And for specific machines or games you can create neogeo.ini or ffight.ini files in the mame/ini directory, if needed, with the range line adjusted.

When you setup GroovyMAME, make sure to leave the infoscreens enabled. That means when you load a game you get a screen showing the game's native resolution, and the resolution switchres has picked. If you're using super resolutions, the vertical mode picked should be the same or slightly larger than the native res. 2560x240p is fine for CPS1 games at 384x224p, for example, and will leave 8 blank lines top and bottom - assuming you've set integer scaling for the vertical res, of course.

Now, once all that is done, there's your converter. Cheap S-video/composite converters will simply produce 480i no matter what the input is, and they tend not to take 480i input. Yours looks to be a higher quality model, i'll grant, but that site provides no specific information about signal formats. A good converter will output the same signal format as the input (so a RGBS input at 384x224@5997Hz comes out as exactly that, only as S-video PAL/NTSC). So, when a game loads at 240, does the image look nice and solid, of do horizontal lines still flicker? A good way to check this is to set your desktop to 320x240p and take a look at horizontal window borders. Then go back to 480i and see the difference, because it should be pretty marked. (Obviously the resolution is a lot lower, but the flicker of horizontal lines should be there at 480i and not at 240p)

If you give any of this a go, and are still confused, have a read of this guide: https://www.aussiearcade.com/forum/arcade/m-a-m-e-emulation-projects-and-discussion/89704-a-guide-to-connecting-your-windows-pc-to-an-sd-crt-tv-pvm-or-arcade-monitor#post2194681

Butter, so you’re saying that CRT_emudriver CAN indeed work on Svideo and composite out?

I wish this would of been clarified better when I chose my CRT. I was forced to pick a flat screen unit, I wanted an older curved CRT But they usually only have composite/svideo in.

[buttersoft]

It's not really a matter of crt_emudriver being compatible. Crt_emudriver doesn't care, or do anything different. The PC would still be outputting via a VGA port here. (or DVI-I port). The trick is getting a 1:1 converter to turn RGBHV or SCART into S-Video (Y/C) or composite video without scaling, stretching or reprocessing the image in any way, just converting the signal. That converter feltz posted might be nice, it looks nice, but there's no info on this. I'm not sure if Retrotink make something that will suit, but i reckon they would. And J-rok certainly do. But there have got to be others.

This is exactly the same thing as converting VGA to component, conceptually, you're just targeting a different video signal to convert to. And losing a small amount of quality in the case of S-video, and more than that for composite. But it works fine given those limitations.

Not sure about a converter to take HDMI and turn it into S-video at 1:1 - none of those cheap boxes on eBay are going to do that.

[Zebidee]

Svideo color transcoding is done to a preset frequency, and I imagine that is what the NTSC/PAL switch on your transcoder is for.

If using svideo for arcade games, pay attention to the vertical frequency/refresh rate. This may mean you should try using NTSC or PAL presets for CRT_emulator (in monitor.ini), because they limit video mode generation to the relevant frequencies expected by the transcoder. Otherwise the colors may seem a little off.

[buttersoft]

Svideo color transcoding is done to a preset frequency, and I imagine that is what the NTSC/PAL switch on your transcoder is for.

If using svideo for arcade games, pay attention to the vertical frequency/refresh rate. This may mean you should try using NTSC or PAL presets for CRT_emulator (in monitor.ini), because they limit video mode generation to the relevant frequencies expected by the transcoder. Otherwise the colors may seem a little off.

I must admit i didn't think about/know that. Does that mean that most if not all real arcade boards, when run through a converter like the j-rok which is designed for that purpose, are going to have altered colours?

[Zebidee]

Svideo color transcoding is done to a preset frequency, and I imagine that is what the NTSC/PAL switch on your transcoder is for.

If using svideo for arcade games, pay attention to the vertical frequency/refresh rate. This may mean you should try using NTSC or PAL presets for CRT_emulator (in monitor.ini), because they limit video mode generation to the relevant frequencies expected by the transcoder. Otherwise the colors may seem a little off.

I must admit i didn't think about/know that. Does that mean that most if not all real arcade boards, when run through a converter like the j-rok which is designed for that purpose, are going to have altered colours?

I confess I don't have a lot of experience breaking apart svideo signals for retrogaming, so I can't give a full answer. The following is from my understanding of the theory, rather than personal practice.

My primitive understanding of svideo (Y/C) creation is:
- the RGB is first separated/converted into component (YPbPr), which is Y (luma, which includes sync, and is essentially a black & white video signal) and two colour elements (Pb',Pr'); then
- the colour elements Pb Pr are converted into a single C (Chroma). So that Pb + Pr can be carried on same signal wire, the signals are 90 degree phase-shifted and modulated according to relevant frequency (NTSC,PAL), so that they can be decoded by the TV.

The frequency is typically set by a crystal oscillator, which you might see on the circuit board as a long silver box with rounded ends, maybe ~1cm long (there are other kinds too, but these are what I commonly see). These are set to specific frequencies (eg 3.58Mhz for NTSC, 4.43Mhz for PAL). There are other ways to do this too which give a wider range of frequencies (e.g. via a phase locked loop, or PLL) but they all involve crystal oscillators.

Why did they do this? TL;DR: There is a lot of history involved, it comes down to backwards compatibility with old-school broadcast analogue TV signals and how TVs/VCRs interpret those signals.

With this in mind, I imagine that if you were trying to run PAL or 50hz modes through a RGB to Y/C transcoder set to NTSC (or vice-versa), then you would probably get some colour weirdness, especially for highly saturated colours, and maybe some other kinds of video "artifacts" like shadowing. So, I'd suggest using NTSC 60hz (59.94hz) video modes in CRT_emulator when using the transcoder in NTSC setting, or using PAL (50.00hz) video modes for PAL setting.   

As for arcade boards, where the game frequency is fixed, on svideo - I imagine the colours will be a bit off at best. Games that run at close to 60hz will probably look OK in NTSC setting. However, nobody expects them to be perfect either. Svideo picture quality is better than composite but will never be as good as RGB or component. Games like R-Type, Mortal Kombat and many shmups like Flying Shark probably won't look so great as they use vertical frequencies around ~55hz, which are close to neither PAL nor NTSC.

[buttersoft]

surely that's just the colour subcarrier we're talking about. So it doesn't care about other parts of the signal?

[Zebidee]

In the component video world, each component influences the other components. If your C or PbPr is out of whack with your Y then your colours will be too.

[buttersoft]

Hmmm, in your research did you come across any schematics for an RGB-to-S-video conversion? I know i ordered a chip once for a rainy day, maybe i should look up which one it was.

If we're talking NTSC, would the colour imbalance be the sort that could be corrected using a HUE control?

[Zebidee]

Hmmm, in your research did you come across any schematics for an RGB-to-S-video conversion? I know i ordered a chip once for a rainy day, maybe i should look up which one it was.

Good idea, some TVs can be easily modded for S-video but not component or RGB. Can't name any off the top of my head though!

If we're talking NTSC, would the colour imbalance be the sort that could be corrected using a HUE control?

Do those controls ever do anything useful? I usually just leave it in the middle.

I'm not even sure the s-video NTSC vs PAL colour subcarrier signal imbalance theory has any substance. I'd be interested to know how colours in games like R-type and MK and Flying Shark look when displayed at original video modes/frequencies using a good s-video transcoder.