RetroArch - Native CRT Support

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 :slight_smile:

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.

1 Like

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.

1 Like

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?

I’ve found that using crt switchres with super resolutions (2560) on windows 7, retroarch can’t seem to get the correct refresh rate so the game is stuttery and the sound skips. However if I use native resolution modes it runs fine. my video card is an HD5450 and groovymame works just fine with super resolutions. I don’t really mind having super resolutions for mame and native for retroarch, but I’m still curious why this would happen. My cpu is a Pentium G3258 OCed to 4.5GHZ with 8GB ram. This cpu has great single thread performance so I’m not sure what’s happening here.

That’s a strange one. I’ve never had sync problems. You’ll need VSYNC and audio sync turned on. It will Probably be due to the modelines you have installed. Grroveymame uses dynamic hz which Retroarch does not.

You’ll have to install static modelines. You’ll find the ones you need on the front page of the Retroarch Github.

Also Retroarch has mame with switching so you don’t need both.

I’m trying to enable super resolution but can’t find the super resolution settings under the \Video in Retroarch. Do i have to enable something so they show up? I have CRT Emudriver installed and GroovyMame is running fine with super resolutions.

You need to enable advanced settings. This can be found in user interface I believe.

Once enabled CRTSwitch will be found in video settings.

You need to make sure that you install your super resolutions in static mode not dynamic. RetroArch can do 3840, 2560 and 1920. you need to change these values within the retroarch.cfg file

(EDIT: Discussion complete)

Re: $1082 BountySource on RetroArch lagless VSYNC

Question: Does the Native CRT support preserve original machine’s input latencies for mid-screen input reads too, with the CRT module implementation?

EDIT: No, it is refresh cycle granularity, not scanline granularity

(e.g. no surge-execution, no pre-rendering of framebuffer before scanning out, just 1:1 emulator execution speed while having original machine’s lag, streaming scanlines out of graphics output in realtime, aka realtime beam racing – emulator executes at 1:1 original machine speed with no surge-execution, yet is streaming pixels out in realtime, rather tham framebuffering all of them first before display?)

EDIT: The beam racing sync support can be later merged with CRT support, to achieve exact original signal with exact original-machine lag without need for pre-framebuffering).

Context:

Lagless VSYNC Support (beam raced synchronization) - [$1082 !]

I’m just trying to research commonalities.

EDIT: Done. Thanks, @Alphanu

P.S. I must compliment you in this great work in CRT support.

I manualy added the modes to my super resolution setup. The ones which are listed in the FAQ: 15 khz CRT documentation wiki.

Set the CRT Switch in retroarch and started a game with BigBox. I hear a switching noise from my chassis and then my screen goes black. The games run well if i connnect a LCD with the CRT Switch OFF.

Hello @Alphanu Let me ask if there was any progress implementing calamity 's dynamic modelines to your code.

I have been having a break recently. Taking some time out for family!

However, I am back now. I am still talking with calamity and it will be happening. ATM I don’t have a time scale on when this will be implemented as he is quite busy.

3 Likes

this is quite fair.
thanks for your job!

I’m trying to get the Commodore 64 core (vice_x64_libretro) to work with CRT Switchres.

I have the 2560x272@50hz resolution available on the CRT, but the core will not switch to the resolution. CRT Switchres is on and I have the aspect set to Core Provided.

Other cores I tried up until now work perfectly with CRT switchres, but this Commodore 64 seems to have some issues.

@Alphanu could you possibly take a peek to what’s going wrong with this core? (Or what I may be doing wrong :smiley: )

@Alphanu

In case you missed my previous post.

Does the vice_x64_libretro core (commodore 64 core) work for you with switching under Linux?