RetroPie forum home
    • Recent
    • Tags
    • Popular
    • Home
    • Docs
    • Register
    • Login
    Please do not post a support request without first reading and following the advice in https://retropie.org.uk/forum/topic/3/read-this-first

    Retroarch and 240p on CRT TV

    Scheduled Pinned Locked Moved Help and Support
    crtretroarchretropie 4.6crt tv240p composite
    19 Posts 5 Posters 5.7k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • mituM
      mitu Global Moderator
      last edited by mitu

      Firsthand, I'd say the proper solution is to use anx11 environment and xrandr to add custom modes. Xorg acts like a 'drm master' and any clients started will automatically pick up the new videomode. AFAIR this is what initially CRTSwitchRes feature in RetroArch implemented, but later on they added support for hdmi_timings and used the BCM api - on the Pi - to do something similar to what tvservice/vcgencmd does.

      2nd solution would be to add custom video mode support in SDL2. As you discovered, when using KMS/DRM, runcommand uses modetest to get a list of available video modes and to allow modesetting by setting an environment variable (SDL_VIDEO_KMSDRM_MODEID). This var is picked by SDL2, which switches (usign the DRM api) to that video mode upon video initialization. I'm thinking it would be possible something similar - to pass a modeline definition to SDL2 and in turn SDL2 would create a custom video mode and switch to it.

      If you replace SDL2 in the 2nd solution with X11, you get the first solution, which is already working. The SDL2 version used by RetroPie is specifically patched to understand runcommand's env var, but it doesn't have an implementation of adding custom video modes.

      1 Reply Last reply Reply Quote 0
      • B
        b0xspread
        last edited by

        I noticed I had to kill emulationstation to run modetest, I am guessing it is the 'drm master' until it gives control over to SDL2? Adding a custom mode with xrandr and running it under X11 would work but the gui would look terrible in 240p as it is essentially a 480p image with only half the pixels being shown.

        The second solution sounds much better. Ideally the device should expose both modes, not just the boot mode. Where can I find the code or documentation for this build of SDL2? I can't seem to find any references for this variable (SDL_VIDEO_KMSDRM_MODEID).

        With the hack I have in place, I have emulationstation in 480i and then certain emulators in 240p based on runcommand, this has to be the end goal.

        mituM 1 Reply Last reply Reply Quote 0
        • mituM
          mitu Global Moderator @b0xspread
          last edited by

          @b0xspread said in Retroarch and 240p on CRT TV:

          I noticed I had to kill emulationstation to run modetest, I am guessing it is the 'drm master' until it gives control over to SDL2?

          When running an emulator, via runcommand, ES goes into background and it's no longer using the GPU.

          Adding a custom mode with xrandr and running it under X11 would work but the gui would look terrible in 240p as it is essentially a 480p image with only half the pixels being shown.

          Which GUI ?

          The second solution sounds much better. Ideally the device should expose both modes, not just the boot mode. Where can I find the code or documentation for this build of SDL2? I can't seem to find any references for this variable (SDL_VIDEO_KMSDRM_MODEID).

          As I said, it's the RetroPie modified version - which you can find at https://github.com/RetroPie/SDL-mirror.

          B 1 Reply Last reply Reply Quote 1
          • B
            b0xspread
            last edited by

            By 'gui' I meant emulationstation. I have it running at 640x448, but when I set the mode to 240p effectively half the lines are lost as the image is no longer being interlaced and only one field is showing. Might be possible to resize it further, but still the issue of switching on the fly remains.

            1 Reply Last reply Reply Quote 0
            • B
              b0xspread @mitu
              last edited by

              @mitu said in Retroarch and 240p on CRT TV:

              @b0xspread said in Retroarch and 240p on CRT TV:

              I noticed I had to kill emulationstation to run modetest, I am guessing it is the 'drm master' until it gives control over to SDL2?
              

              When running an emulator, via runcommand, ES goes into background and it's no longer using the GPU.

              Adding a custom mode with xrandr and running it under X11 would work but the gui would look terrible in 240p as it is essentially a 480p image with only half the pixels being shown.

              Which GUI ?

              The second solution sounds much better. Ideally the device should expose both modes, not just the boot mode. Where can I find the code or documentation for this build of SDL2? I can't seem to find any references for this variable (SDL_VIDEO_KMSDRM_MODEID).

              As I said, it's the RetroPie modified version - which you can find at https://github.com/RetroPie/SDL-mirror.

              I see your merge request.

              https://github.com/RetroPie/SDL-mirror/pull/16

              I will give SDL_VIDEO_KMSDRM_MODELINE a shot when I have some free time. Thanks for your help!

              mituM 1 Reply Last reply Reply Quote 0
              • mituM
                mitu Global Moderator @b0xspread
                last edited by mitu

                @b0xspread said in Retroarch and 240p on CRT TV:

                I will give SDL_VIDEO_KMSDRM_MODELINE a shot when I have some free time. Thanks for your help!

                I don't think this will be enough. Runcommand already uses that to switch the resolution - from the list of detected resolutions.

                1 Reply Last reply Reply Quote 0
                • RionR
                  Rion
                  last edited by

                  @b0xspread

                  vc4-fkms-v3d and framebuffer #3391

                  Well at least they are aware of the issue..

                  FBNeo rom filtering
                  Mame2003 Arcade Bezels
                  Fba Arcade Bezels
                  Fba NeoGeo Bezels

                  1 Reply Last reply Reply Quote 0
                  • Y
                    youxia
                    last edited by

                    This sounds really disappointing. Rpi4 was supposed to make things better for CRT users (because of exact pixel clock or something like that) not worse. We've spent literally years tweaking these conigs and runcommands...it'd be a pity if it all went to waste,

                    mituM 1 Reply Last reply Reply Quote 0
                    • mituM
                      mitu Global Moderator @youxia
                      last edited by mitu

                      @youxia said in Retroarch and 240p on CRT TV:

                      Rpi4 was supposed to make things better for CRT users (because of exact pixel clock or something like that) not worse

                      First time I hear about this - do you have a source ? If any, video support was augmented for the HDMI output (4K/2 outputs), which makes sense, since that's what most users have. CRT (and 240p) usage is a niche market.

                      We've spent literally years tweaking these configs and runcommands...it'd be a pity if it all went to waste

                      The fact that the previous configurations do not work doesn't mean the same level of customization will not be possible. New methods would be developed to configure and improve the CRT output.

                      Y 1 Reply Last reply Reply Quote 1
                      • B
                        b0xspread
                        last edited by

                        @mitu

                        I installed X11, added a new modeline and added it to the Composite-1 output with xrandr, but it's just cutting off half the vertical resolution.

                        xrandr --newmode "240p" 13.51 720 734 798 858 240 243 246 262 +HSync +Vsync
                        xrandr --addmode Composite-1 240p
                        xrandr --output Composite-1 --mode 240p
                        
                        

                        If I set it to 240p in the console using tvservice, prior to launching X, it still comes up interlaced with half the screen cut off.

                        # xrandr 
                        Screen 0: minimum 320 x 200, current 720 x 240, maximum 7680 x 7680
                        Composite-1 connected primary 720x240+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
                           FIXED_MODE    60.00 +
                          FIXED_MODE (0x42) 13.513MHz +HSync +VSync
                                h: width   720 start  734 end  798 total  858 skew    0 clock  15.75KHz
                                v: height  240 start  243 end  246 total  262           clock  60.11Hz
                        
                        

                        I was trying to look at the tvsource code to see what it was doing different when the 'P' flag was provided, but it seems to just set mode to 16 and push VC_TV_SDTV_ON to the VCHI message queue.

                           if (sdtv_progressive)
                              mode |= SDTV_MODE_PROGRESSIVE;
                           LOG_STD( "Powering on SDTV with explicit settings (mode:%d aspect:%d)",
                                    mode, aspect );
                        
                           ret = display_id != -1 ? vc_tv_sdtv_power_on_id(display_id, mode, &options) : vc_tv_sdtv_power_on(mode, &options);
                        

                        Thoughts?

                        1 Reply Last reply Reply Quote 0
                        • Y
                          youxia @mitu
                          last edited by youxia

                          @mitu said in Retroarch and 240p on CRT TV:

                          First time I hear about this - do you have a source ? If any, video support was augmented for the HDMI output (4K/2 outputs), which makes sense, since that's what most users have. CRT (and 240p) usage is a niche market.

                          https://github.com/raspberrypi/firmware/issues/734

                          See the last bunch of comments.

                          The fact that the previous configurations do not work doesn't mean the same level of customization will not be possible. New methods would be developed to configure and improve the CRT output.

                          Maybe so, but it may take a very long time, like with Rpi 3. It's been out nearly for a year already. I'm well aware how niche the CRT zone is, but it does not make it any less disappointing (especially given the massive amount of work which went into getting it sorted on Rpi3).

                          I thought I might make a jump now that new Retropie is out finally, but seeing how things are on this front I'll put this on hold. Thinking I'd have to go through all this config-battling malarkey again gives me shivers. My Rpi3 works fine for the less demanding platforms anyway, for others I have a crtemudriver PC.

                          @b0xspread if you're on reddit, try to ping u/ErantyInt. He knows a lot about connecting via composite, maybe he has some info on Rpi4 too.

                          1 Reply Last reply Reply Quote 0
                          • mituM
                            mitu Global Moderator
                            last edited by

                            @youxia said in Retroarch and 240p on CRT TV:

                            https://github.com/raspberrypi/firmware/issues/734
                            See the last bunch of comments.

                            It's an interesting topic, looks useful for VGA/Scart HATs that use the HDMI timings.

                            Maybe so, but it may take a very long time, like with Rpi 3. It's been out nearly for a year already. I'm well aware how niche the CRT zone is, but it does not make it any less disappointing (especially given the massive amount of work which went into getting it sorted on Rpi3).

                            This is not an issue that's solvable in RetroPie - it's a kernel/firmware feature that was present in the legacy drivers and it's not present/un-implemented in the new ones. It's been known for quite some time that dynamic mode switching doesn't work like before and I don't think it's on the short term list of things the RPT engineers are working right now.

                            1 Reply Last reply Reply Quote 0
                            • B
                              b0xspread
                              last edited by b0xspread

                              @youxia thanks, I'll give him a shout.

                              The issue is with the timing and format of the VSync pulse within the CSync signal needed to draw a progressive image.

                              My understanding is two things are needed:

                              1. Integer number of lines (either 262 or 263) instead of 262.5 used for interlacing
                              2. This will cause the VSync pulse to be sent at the beginning/end of each scanline and not in the middle, thus the scanline will be retraced instead of being shifted due to the ramp of the electron beam sawtooth wave.

                              It seems to me like changing the mode with xrandr just changes the size of the framebuffer, but the board is still outputting 525 lines with the second field vsync coming in mid scanline, so all my ModeLine efforts seem futile.

                              tvservice is able to alter the signal timing and modulation at the hardware level. I wish someone who knows how to use a oscilloscope could verify this.

                              I also wouldn't be this pessimistic about RP4 retropie as a whole. Apart from the CRT issues described , everything else has worked just fine. Albeit this is my first Raspberry pi so I have no point of comparison.

                              1 Reply Last reply Reply Quote 0
                              • B
                                b0xspread
                                last edited by b0xspread

                                For now my conclusion is this:

                                1. Progressive scan with RP4b still works. You just have to either set it in config.txt as the appropriate sdtv_mode (16 NTSC/18 PAL), but then Emulationstation will also be in 240, which looks terrible, or use tvservice to enforce it on a per rom/platform basis after retroarch starts to switch back and forth.

                                You can use my watcher python script and run it on startup in the background and then make an appropriate runcommand-onstart script or make your own solution.

                                Script: https://retropie.org.uk/forum/post/220137

                                pi@retropie:~ $ tail -2 /etc/rc.local 
                                su pi -c 'python3 -u /opt/retropie/configs/all/vmodes_watcher.py &> /var/log/vmodes_watcher.log' &                                                                         
                                exit 0                                                                                                     
                                
                                # taken from https://github.com/Sakitoshi/retropie-crt-tvout/tree/master/to_configs
                                pi@retropie:~ $ cat /opt/retropie/configs/all/runcommand-onstart.sh
                                if [ -f "/opt/retropie/configs/$1/480i.txt" ]; then interlaced=$(tr -d "\r" < "/opt/retropie/configs/$1/480i.txt" | sed -e 's/\[/\\\[/'); fi > /dev/null
                                if [ -f "/opt/retropie/configs/ports/$1/480i.txt" ]; then interlaced=$(tr -d "\r" < "/opt/retropie/configs/ports/$1/480i.txt" | sed -e 's/\[/\\\[/'); fi > /dev/null
                                if [ ! -s "/opt/retropie/configs/$1/480i.txt" ] && [ ! -s "/opt/retropie/configs/ports/$1/480i.txt" ] || [ -z "$interlaced" ]; then interlaced="empty"; fi > /dev/null
                                if [ -f "/opt/retropie/configs/$1/240p.txt" ]; then progresive=$(tr -d "\r" < "/opt/retropie/configs/$1/240p.txt" | sed -e 's/\[/\\\[/'); fi > /dev/null
                                if [ -f "/opt/retropie/configs/ports/$1/240p.txt" ]; then progresive=$(tr -d "\r" < "/opt/retropie/configs/ports/$1/240p.txt" | sed -e 's/\[/\\\[/'); fi > /dev/null
                                if [ ! -s "/opt/retropie/configs/$1/240p.txt" ] && [ ! -s "/opt/retropie/configs/ports/$1/240p.txt" ] || [ -z "$progresive" ]; then progresive="empty"; fi > /dev/null
                                if tvservice -s | grep NTSC && { ! echo "$3" | grep -wi "$interlaced" || echo "$interlaced" | grep empty; } && ! echo "$interlaced" | grep -xi "all" && { echo "$3" | grep -wi "$progresive" || echo "$progresive" | grep empty; }; then echo 'NTSC 4:3 P' > /opt/retropie/configs/all/desired_mode/value; else echo 'NTSC 4:3 ' > /opt/retropie/configs/all/desired_mode/value;   fi
                                echo "runcommand-onstart $1 $2 $3"
                                pi@retropie:~ $ cat /opt/retropie/configs/all/runcommand-onend.sh
                                if tvservice -s | grep NTSC; then tvservice -c "NTSC 4:3"; fbset -depth 8; fbset -depth 32; fi > /dev/null
                                
                                

                                240p is default, override per platform/ROM in 480i.txt files

                                pi@retropie:~ $ cat /opt/retropie/configs/mame-libretro/480i.txt 
                                all
                                
                                1. As stated in this thread: https://github.com/raspberrypi/firmware/issues/683#issuecomment-283179792 what was done in the firmware to make these new modes work is

                                A. Setting the progressive scan bit in the VEC (Composite TV out) register set:
                                https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/vc4/vc4_vec.c#L104

                                B. Remove the interlace flag for the mode:
                                https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/vc4/vc4_vec.c#L256

                                tvservice does essentially the same thing and sets the new modes:

                                https://github.com/raspberrypi/userland/blob/2448644657e5fbfd82299416d218396ee1115ece/interface/vmcs_host/vc_sdtv.h#L60
                                https://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/tvservice/tvservice.c#L703
                                https://github.com/raspberrypi/userland/blob/master/interface/vmcs_host/vc_vchi_tvservice.c#L1213
                                https://github.com/raspberrypi/userland/blob/master/interface/vmcs_host/vc_vchi_tvservice.c#L698

                                Since there is a hardware flag that needs to be set, it won't be possible to resolve this with xrandr modesetting alone as was suggested.

                                Ideally RetroPie in some form could enforce this natively in a similar fashion by taking the SDTV_MODE as a parameter and enforcing it through VCHI like tvservice does, alongside the modsetting being done in the modified SDL library.

                                1 Reply Last reply Reply Quote 1
                                • J
                                  jimrogerz
                                  last edited by jimrogerz

                                  A simple workaround is to delay the tvservice call in runcommand-onstart.sh , e.g.:

                                  #!/bin/bash
                                  echo "starting emulator "$2 >&2
                                  if [ "$2" == 'lr-fceumm' ]; then
                                     sleep 5 && tvservice --sdtvon="NTSC 4:3 P" &
                                  fi
                                  
                                  1 Reply Last reply Reply Quote 1
                                  • First post
                                    Last post

                                  Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.

                                  Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.