Retroarch and 240p on CRT TV

b0xspread

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.

b0xspread

@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!

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.

Rion

@b0xspread

vc4-fkms-v3d and framebuffer #3391

Well at least they are aware of the issue..

youxia

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,

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.

b0xspread

@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?

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.

mitu

@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.

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:

Integer number of lines (either 262 or 263) instead of 262.5 used for interlacing
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.

b0xspread

For now my conclusion is this:

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

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.

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