Thank you very much again Hunterk,
With the ppa repository everything is fine in ubuntu 18.14. For the moment, I just tried the core of bsnes with the version of Supermario World ntsc. In the upper part of the tv there are some black lines.
Is there any way to vertically center the modeline without touching the TV settings using modeline generated in your code?
Can it be by touching a configuration file?
I am still working on the modeline generator, it still needs some work but I am always working on it. I don’t think allowing people to edit these would be a good idea, even making a small incorrect change can cause porching issues or even the loss of sync. Can you upload a a image for me, it will help finalizing the generator.
Maybe in the future i will include some settings to make tiny adjustments, but at the moment I am concentrating on porting the code to 31khz, Lakka and correcting the generator.
Thanks Alphanu,
Her are some images om my crt KV-32FX60E. If you need some others please request me.
The tv has an option to centering horizontal position without entering in service mode and I have centered image in horizontal.
PCE: 1 or 2 lines black lines in the up:
MEGADRIVE/GENESIS: 1 or 2 lines black lines in the up: SATURN: 1 or 2 lines black lines in the up: SNES: haves about 7 black lines in the up. Left and Right wood frame is hidden.The option for modify the modelines it could be configuration file that whill be hidden to normal users.
I found here a guide to modify modeline:
https://arachnoid.com/modelines/
Thank you again.
In previous comments I read that I can disable vsync. When I disable vsinc, the scroll is less smooth. I’ve tested it with Sonic 2(MD) and Yoshis island(SNES) in ubuntu 18:04
In interlaced modes like psx bios emulation goes very slow. In same pc with lcd conf goes well. Satrun interlaced modes haves the same problem.
Yeah in some cases it can be disabled. Mainly Mame but you have to enable Mames frame throttle. In some other cores you can enable RA throttle to 1.0x and it does work quite well too.
@rares Thanks for the images, I was already aware snes had a bit of a vertical position issue. I is gonna to be one of the first things I fix once I’ve ported over to xrandr.h. The website you mention can be helpful but not always helpful Different CRTs handle porches differently from Sony PVMs to standard home B&Os and especially arcade CRTs. The idea is to get a best match situation doing on. I have 5 CRT that we are testing on an each time they give slightly different outputs.
Your Images show me that in most cases standard home CRT handle it better. However, my algorithm is still not 100% accurate YET!
There are fixes on my git if you want to compile, the changes should position things better. Aslo it fixes the aspect issues too.
its pretty easy to compile just follow this guide but replace the libretro git with mine.
Hi,
I compiled from your source and have made a video with snes, megadrive and pce test suite.
I also test a saturn game but I have’t recorded the test.
In vertical all is ok. But in horizontal all systems goes to the left.
If you need i will make more videos and pictures with new compilations.
The 1st test is SNES
Sometimes when I change the game happens that you can see when game is changed and in the finish of the video. Retroarch loses focus and you can see the desktop of lubuntu 18.04. Sometimes I rescue the focus making random click with the mouse.
Regards.
@rares Thanks for the video.
I was on a little break from working on this recently, as I have had other important things to deal with.
Fear not! I am back 
I have some big news. Linux CRT switching has got even better. I have re-written my porch algorithm, as you can see from rares video things were not quite right. Now though things are looking great. I have built this around comparing to original hardware on the TV I am developing this on. So in short even if my TV is not calibrated correctly. The video the RA outputs is the same as the original hardware. And this is all in native resolution.
At the start of the video I am comparing real hardware to the new porch calculation on RA. I have to say it got to be 99.99% accurate 
Bear in mind that I am in the UK so I am comparing 50hz consoles with 50hz mode in RA. the video then shows a few 60hz games as well as 240p test suit.
So whats next. Well I don’t think I’ll ever be 100% happy with the outcome so I will always be tweaking these settings 
But other than that I am moving forward with the 31khz mode as well as The RPi port.
F.Y.I the new porch algorithm seems to work lovely on my 2 CRTs, but we have some weird results on a Toshiba CRT. I’m not sure why yet but if you guys can do some testing that would be great.
Hi Alphanu
This is amazing!
I have two doubts:
1 - Will this new porch algorithm be available to Windows? 2 - Are you using native or superwide resolutions to get this 99.99% of accuracy?
Thanks!
Hi @purity1516
To answer the first question. It is simply no. With windows you need resolutions pre-installed, this means that the porches are already created by Calamity’s Vmmaker. Calamity has not shared how he uses dynamic resolutions yet. But it is something I’m looking into.
The video above is all native resolutions.
This new calculation is for native resolutions only. It uses the original width, height and hz to calculate. This will not work as well with super res as all widths are 2560 or what ever is used. However, I will be working on the super res version next.
I see.
As a Windows user, I hope that Calamity can share his dynamic resolutions algorithm.
Thanks for your great job!
Hello Everyone,
First of all, huge thanks to @Alphanu for this great work, a true stride forward.
I’m posting with the hopes that some light may be shed on an issue I have encountered with the Retroarch CRT Switch Res solution on my setup.
Background
I have been using GroovyMAME and CRT_emudriver for a number of years to output from my Windows 7 machine to a Mitsubishi XC-3315C successfully.
I have installed Alphanu’s list of suggested Super modelines, along with the list of Native modelines; in both combined and separate clean installs. I have successfully configured Retroarch to enable resolution switching, which it does sucessfully in both “2560” and “0” (native switching) modes.
Questions and issues
When booting a game, Retroarch’s notification informs me that it has set the refresh rate to “60.000hz”, this is the same for any and all game/cores loaded.
First question: Is this the intended behavior?
For example: I have/had tested @Alphanu’s early pre-mainline build posted to this thread in March 3, 2018, this older build, on launching a game, notifies that it has set the refresh rate to the actual-correct-for-core-refresh (ie. 60.099, 59.xxx, etc.). In any case, this build also suffers from the problems listed below.
Once loaded and displaying in the correct 15khz resolution, in all cores (multiple systems, resolutions, cores for tested systems), in both Super-Res and Native switch modes, my setup suffers either:
I have tried, I believe, all combinations of relevant options in the Video settings. Tried manually tweaking the refresh rate in the Video settings to the hardware-correct numbers and arbitrary settings. As mentioned above, tried separate clean successful modeline installs of both Super-Res and Native lists.
Testing game for game, using say LTTP & Sonic 2 as examples: GroovyMAME displays perfect scrolling behavior.
Does this ring a bell to anyone? Have I overlooked something? Any insights much appreciated.
Thanks in advance.
I use xrandr to set desktop 640x480i on linuxmint. everything is ok using super-Res but the native switching is not available,someone would tell me how to make it work? which audio and video driver is the best ?udev or linuxraw? how can I enable kms？my graphics card is ati hd5450
@Victor bear with me here, I believe this is a native res bug. Do games sync properly in super res?
@yuuyuubaishu currently the only way to enable native res is to edit the retroarch.cfg. It is located in ~/.config/retroarch folder. Change the CRT switch resolution option to 0.
They do not, same issues in both Super and Native switch modes.
@Alphanu thanks for this! I used your latest linux native build and did some tests. Setup is a 20" sony pvm with a vga arcade 5000 (enhanced ati hd5450) on ubuntu 18.04, using native mode. the retroarch menu displays fine. on mednafen psx there is a big black border on the left (say 1/4th of the screen) as soon as the bios starts, meaning the image is shifted to the right so the right part is not visible. this also happens ingame. ingame later on with finalfantasy8 there are black borders on both sides left and right. also there is quite some white flickering when modes are switched. when using bsnes-performance with Seiken Densetsu 3, the image is at first perfect. but later on the black border on the left returns. When the sword fight starts the pictures is first perfect but then keeps switching back and forth to the resolution with the black border on the left. Also flickering on snes when modes are switched. When the camera flies over the world map the picture is perfect.
Some questions: could you list all necessary settings that MUST be enabled and disabled to test properly? I only found out to enable native mode, superres setting needs to be set to 0 in config file. It would be convenient to have all settings listed in the first post for example. Also could you make this work in KMS mode (text mode in ubuntu)? Emulation there runs at 100% speed, in desktop mode there is a lot of lag. So KMS would be a huge improvement in my opinion. Last question, does this work in KMS mode with EDID (native mode or superres)? Thanks!
Echoing previous sentiments, thanks for implementing this functionality @Alphanu
Initially I was having overscan issues with the left and right side of the screen in Genesis plus GX - enabling full borders in the options for the core seems to have solved this though - pointer if anyone else is having this problem.
I’ve pulled your MME4CRT_GA repo on Ubuntu 18.04 LTS and have been playing with it for the past couple of days, but I seem to be having issues with tearing which I can’t seem to resolve - different combinations of Vsync and hard GPU sync don’t seem to do much, although I think it seems to be worse with threaded video.
I’ve been using the intro to angel island from Sonic 3 as my test, due to the fast scrolling.
Occasionally on loading a ROM the core detects a refresh rate that is too high and runs far too fast - I’m wondering if detection is attempted possibly during the mode change and is upsetting the core/retroarch? I can only speculate since I don’t have any understanding of the code.
Does the choice of GPU matter in Linux? I know that Ati cards are generally recommended for Windows. I’m using a pretty basic Geforce GT 710, but the board I’m using does have an onboard Radeon, though it uses part of the system RAM as VRAM so I’d rather not use it.
Can anyone give me any pointers? Thanks 
Hi @dwhweb
The first issue you will have is windows. Especially with a Nvidia card!
My first question is. How have/are you creating the resolution mode-line?
With windows you really need to use a AMD 5xxx or higher with CRTemudriver.
With Linux there is less of a restriction. I has Intel GPUs working so I will assume some Nvidia cards will work too.
This only works correctly if the video card can simulate the correct video timings.
The FPS on screen display has a delay in its update. you should see a message setting refresh pop up, this is the speed that is being set by my code. Also with the current limitation of windows refresh screen hz are limited to 50, 55 or 60. I am working on this.
For all the windows users out there, I am working on a live USB so you can boot Linux RetroArch to play without having to install.
I will double check the windows code in case a bug has been introduced with the addition of Linux.
** I just read back that you are also having trouble on linux, this could be the Nvidia card. But also could be Ubuntu 18. I have only tested Ubuntu 14, 16 and Arch Linux.
I did find a VSYNC bug with Ubuntu a while back, I had to change swap frames to 2 for it to work properly, this may not be the case for you but it is worth a try.
Wrote a small shell script that changes the mode on boot via xrandr - if anyone else needs it, feel free to copy -
#!/bin/bash
xrandr --newmode "704x480" 13.27 704 720 784 848 480 483 489 523 interlace -hsync -vsync
xrandr --addmode VGA-1 704x480
xrandr --output VGA-1 --mode 704x480
This is invoked in ~/.config/lxsession/LXDE/autostart when LXDE loads - maybe this is not the preferred way to do this, I’m unsure.
I’m not intending using Windows if at all possible - was just asking in case Ati cards handle 15khz modes better and my hardware was struggling.
Thanks @dwhweb
This script is similar to what I use. Bear in mind that you may need to change “VGA-1” to your output ID wich could be VGA1 or even DVI-1 and so on. Just type xrandr in terminal and it will let you know what output is connected.
I’ve been messing around with this again today and seem to have got to the bottom of it – removing the Geforce GT 710 and re-enabling the onboard Radeon 4200 seems to have solved the problem. Works perfectly without the need for Vsync, Hard GPU sync or threaded video enabled. I would be interested if anyone knows why.
I was hoping I would get the Geforce working with it so initially I tried replacing the nouveau drivers with the nvidia binary blob – I would not recommend that others try this as from what I gather from https://devtalk.nvidia.com/default/topic/1008518/jetson-tx1/x11-configuration-xrandr-refresh-rates/ the official nvidia drivers only accept predefined modes or modes from a monitor EDID – xrandr won’t change modes with these drivers.
Maybe ATI cards are better suited for CRT displays in Linux as well as Windows?