Best way to output SCART (RGB) from Pi 3?

maxriptide

@Rion OK, I got it, composite video output is really awful

maxriptide

@Dochartaigh said in Best way to output SCART (RGB) from Pi 3?:

What was wrong with the "custom_viewport" settings you used?

There is nothing wrong with the custom_viewport setting I used, it is the solution I come up with to display different systems using a fixed resolution in the config.txt. Resolutions lower than the config.txt can be "framed" inside that one, I sketched the following image to explain this

So, let's say you set 320x240 in the config.txt and you want to display SNES games (256x224), you have to edit the SNES retroarch.cfg file adding the following lines:
custom_viewport_width = "256"
custom_viewport_height = "224"

and, if needed, custom_viewport_x and custom_viewport_y to center the image. As I wrote before, the final image will have black borders, that may be thin or thick depending on the h-size and v-size settings on your monitor.

Dochartaigh

Thanks for the diagram.

Is there really no "fit to screen" setting anywhere?

Via HDMI, which is set to 1080p (1920x1080), how does every single system properly stretch top to bottom (with of course black bars on the left and right since 1080p is widescreen/16:9, and these systems are mostly 4:3 ratio), without doing anything special to the setup files. Same thing happens when my system config.txt is set to 720p - and it does all this automatically. Is it a function of a modern flat-screen LCD TV and that's why these CRT's can't do that without complex settings?

I'm just not understanding what the problem is....

pjft

@Dochartaigh I think that's the Pi/retroarch video scaler's doing, similar to what was mentioned a few posts back about the integer scale.

That's the video renderer scaling the image to fill the 1920x1080 pixels based on the source image. You may get artifacts and it won't be quite perfect.

What you are looking for is getting the Pi to only output exactly the pixels you want and get the PVM to do the scaling (well, to just tender that image on its full screen).

Sorry if it isn't clear, writing on my phone.

Dochartaigh

@pjft said in Best way to output SCART (RGB) from Pi 3?:

@Dochartaigh I think that's the Pi/retroarch video scaler's doing, similar to what was mentioned a few posts back about the integer scale.

That way you get lots of flickering thought they said because of the progressive signal (or not at the right hZ frequency or something?) - that wouldn't be good.

I am looking for NES, SNES, and Genesis, mostly, but I also LOVE arcade game too (and Doom and Quake through Ports, and The 7th Guest through ScummVM, bunch of MS-DOS games) so even the multiple SD card solution which was mentioned won't work for arcade games with all those resolutions which were listed as well...

pjft

Right - I was exactly not suggesting that. I was answering to your question around "Via HDMI, which is set to 1080p (1920x1080), how does every single system properly stretch top to bottom (with of course black bars on the left and right since 1080p is widescreen/16:9, and these systems are mostly 4:3 ratio), without doing anything special to the setup files". That's because of the software scaler from RetroArch. It has nothing to do with the TV.

maxriptide

This post is deleted!

maxriptide

@Dochartaigh said in Best way to output SCART (RGB) from Pi 3?:

Via HDMI, which is set to 1080p (1920x1080), how does every single system properly stretch top to bottom (with of course black bars on the left and right since 1080p is widescreen/16:9, and these systems are mostly 4:3 ratio), without doing anything special to the setup files. Same thing happens when my system config.txt is set to 720p - and it does all this automatically. Is it a function of a modern flat-screen LCD TV and that's why these CRT's can't do that without complex settings?

It's a matter of math.
I'll try to explain it but English is not my mother language so sorry if I don't make myself clear.

In order to make an image fit a screen bigger (in terms of pixels) than the image itself, the CPU has to perform an interpolation, a mathematical algorithm which spreads out the original pixels into a bigger "surface" and generates new pixels in order to fill the blank spaces.
If you have a small image, let's say 256x224, and want to display it onto a big screen, let's say 1280x720, the interpolation algorithm has a really great number of blank pixels to fill (as you can see in the following image):

0_1488616312337_snes 1_1 in big frame.jpg

The algorithm will "create" all the new pixels and you'll get this:

0_1488616420645_snes resized in big frame.jpg

if you don't like pixel look you may also want to use a bilinear filtering algorithm which smooths out the edges by blurring the image:

0_1488616626325_snes resized Bilinear filtering in big frame.jpg

Instead, when you want to resize an image into a "surface" only slightly bigger than the image itself (e.g. from 256x224 to 320x240), the interpolation algorithm has very few blank pixels to fill:

0_1488616873772_snes 1_1 in small frame.jpg

the algorithm will not be able to generate a perfect slightly-bigger copy of the original image and artifacts will be present:

0_1488617124405_snes resized in small frame.jpg

please take a look at the text characters at the bottom of the image and at the jagged lines of the writing "super mario world" which are are not uniformly shaped. And it gets even worse watching a scrolling background!

I hope I made myself clear :-)

A final note: I know that this is the retropie forum and we are supposed to talk only about retropie and Raspberry PI but the solution to your problem may be using a different machine. A softmodded PAL Nintendo Wii coupled with a SCART RGB cable with WiiMednafen installed is perfectly capable to display all the 16-bit consoles in their fullscreen glory on your PVM without any artifacts and without the need to fiddle with config files and video hardware add-ons.

tjohnson

I have managed to output 240p RGB to a scart socket connected to my CRT TV. I used an HDMI>VGA connector and a custom homemade cable to convert to RGB. The cable was actually very easy to make using instructions found on the web, the worse part was getting all the wires inside the connector. Effectively VGA outputs RGB but with separate horizontal and vertical sync signals. Using a couple of resistors it is possible to combine those sync signals into a composite sync signal which works on my old CRT. There are more elaborate circuits that use logic chips to combine the signals but the simple resistor approach works for me. A 5v supply, which can be taken from the Pi usb socket, tells the TV it is receiving RGB signal. If your PVM monitor accepts RGB you probably don't need 5v as the monitor can probably be told it is receiving RGB. I found the image was outside the display so used overscan settings to bring it to the edges of the display. Image quality is very good and gives an authentic arcade experience with no horrible flicker from interlaced composite.

If trying to get an authentic experience on LCD I would suggest the best route is to use a scanline generator i.e. HDMI to VGA with a scanline generator to blank out the lines.

Dochartaigh

I received the PI2SCART today and used these settings in boot/config.txt:

disable_audio_dither=1
dtparam=audio=on
dtoverlay=vga666
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87
hdmi_timings=320 1 16 30 34 240 1 2 3 22 0 0 0 60 0 6400000 1 
#240p

So far it's pretty good. Everything is fitting to screen automatically for the most part. Pixel-TFT theme is working nicely for the small 240p space (well, if you like things pixelated at least ;)

Couple questions:

1.) The picture is cut off around 5-10% of the top/bottom/left/right on 3x different monitors. Can I change this in that hdmi_timing line? I'm only seeing documentation from Raspberry Pi foundation on hdmi_cvt parameters...

2.) SNES (and some NES) is having the characters in the foreground move smoothly, but the backgrounds seem like they're getting some lag - like the background movement isn't smooth and a little jagged as you run by. My brother even noticed it when I had him compare it to a real SNES. Genesis seems fine (maybe because it's running in the exact 240p the config.txt is setup for).

What config.txt settings would I use to put the system into 256x240 mode for SNES and NES? I want to see if the problem is because the system is setup in 320x240 where SNES/NES are 256x240.

3.) Similar to the above, how would I test a 480i mode (which is the max res of these monitors)?

4.) The color looks pretty good but it's a little washed out and brighter than it should be (ironically Genesis is closer than SNES/NES/Arcade). I even reset my monitors to their default factory-calibrated settings (which are usually a little dark), and have compared 4 different actual console systems. –– Just trying to get a good defacto baseline before I start tweaking the settings on the monitors themselves.

maxriptide

@Dochartaigh said in Best way to output SCART (RGB) from Pi 3?:

What config.txt settings would I use to put the system into 256x240 mode for SNES and NES?

You should put the following hdmi timings in the config.txt:
hdmi_timings=256 1 8 17 21 224 1 7 10 24 0 0 0 60 0 4800000 1

and also add the following lines in the retroarch.cfg files:
for NES:
aspect_ratio_index = "22"
custom_viewport_width = "240"
custom_viewport_height = "224"

for SNES:
aspect_ratio_index = "22"
custom_viewport_width = "256"
custom_viewport_height = "224"

Dochartaigh

@maxriptide

Thanks Max! Is there a primer for what all those numbers mean? I would like to know what I'm doing instead of copying and pasting (which I do appreciate!!!). I can tell it's going to make the overall size 256x244 (maybe 60 hz, 48khz for sound, maybe front and back porch settings whatever the heck those are...), but have no clue what the other numbers mean.

Are some of those numbers the margins so I can get this picture to fill up the screen more properly (instead of like a quarter of it cut off)?

Last, won't the NES be letterboxed on the top and bottom if I edit the /opt/retropie/configs/nes/retroarch.cfg to be 240 when the overall size is 256? Or does something prevent that? (would totally LOVE to learn how to start tweaking these...but can't find much on the hdmi_timing setting).

maxriptide

@Dochartaigh
The meaning of the hdmi parameters is:
hdmi_timings=<h_active_pixels> <h_sync_polarity <h_front_porch> <h_sync_pulse> <h_back_porch> <v_active_lines> <v_sync_polarity> <v_front_porch> <v_sync_pulse> <v_back_porch> <v_sync_offset_a> <v_sync_offset_b> <pixel_rep> <frame_rate> <interlaced> <pixel_freq> <aspect_ratio>

I found these information on the Raspberry Pi forum: https://www.raspberrypi.org/forums/viewtopic.php?t=24679

For an explanation of the parameters affecting the screen position take a look at this thread on the neo-arcadia forum:
http://www.neo-arcadia.com/forum/viewtopic.php?f=58&t=37718&sid=234b0e9379b081851bd78589af7ba599

it's in French but the image is self-explanatory.

Please notice that it is not that easy to "play" with these parameters, if you try (like I did) you will come up with with video signals which may be out of your monitor specifications. In most cases you will get a distorted image but you may also damage your monitor, that's why during my attempts to find the correct parameters for the pc engine emulator, I did most of my tests with an old SCART TV instead of my monitors.

@Dochartaigh said in Best way to output SCART (RGB) from Pi 3?:

won't the NES be letterboxed on the top and bottom if I edit the /opt/retropie/configs/nes/retroarch.cfg to be 240 when the overall size is 256?

We are talking about the horizontal resolution here so you might get left and right black bars (not top and bottom) but, as I wrote before, there's no way to prevent this at the moment. The difference in terms of number of pixels between 256 and 240 is really low so you may adjust the overscan parameters on your monitor to avoid letterboxing.

Dochartaigh

@maxriptide said in Best way to output SCART (RGB) from Pi 3?:

Please notice that it is not that easy to "play" with these parameters, if you try (like I did) you will come up with with video signals which may be out of your monitor specifications. In most cases you will get a distorted image but you may also damage your monitor, that's why during my attempts to find the correct parameters for the pc engine emulator, I did most of my tests with an old SCART TV instead of my monitors.

Thank you for all the info!

I already found this out myself too - it's REALLY touchy. I think I literally changed the margin (front/back porch) numbers by like 2 or 3 and my signal was totally unviewable and scrambled on the monitor (like all wavy jumpy lines). I have to do some more research - only need to shrink the margins by maybe 10 pixels and it would fit on these PVM monitors fine. The problem is two of my PVM's don't even have centering in the service menu (it's only increase or decrease the overall size - everything else I have to open it up and manually adjust the pots inside or something to that effect).

Also, when I tried your numbers for NES and SNES the picture was viewable but with horrible dark banding on large areas of it - tried it on my BVM-14F5U, PVM-20N2U, and PVM-14L2MD (they're all daisy chained together) - I think mine might just be different than the monitors you're using (or I messed up someplace with the code!). I will report back when I have some more time to mess with it, and THANK YOU so much for your help so far.

tjohnson

@Dochartaigh You might be able to bring the image in using overscan like I did. I used HDMI_CVT to set the resolution and refresh then adjusted overscan to ensure the image filled the screen without borders.

Dochartaigh

@tjohnson said in Best way to output SCART (RGB) from Pi 3?:

HDMI_CVT

What's the difference between HDMI_CVT and hdmi_timings (I've been using hdmi_timings as that's what everybody - including the manufacturer - says to use).

maxriptide

@Dochartaigh in my experience hdmi_cvt doesn't work with GPIO output. It works flawlessly with an HDMI-VGA adapter and it is really easy to change resolution parameters, but unfortunately the HDMI-VGA introduces lag, that's why I switched to the Gert GPIO VGA adapter having to deal with hdmi_timings.

tjohnson

@maxriptide Im using vga to hdmi so using hdmi_cvt and have got the resolution and image size working great, not sure on the introduction of lag, some people claim to be sensitive to it, I haven't noticed any lag myself, long term gamer but no "pro" gamer. Has anyone got any hard facts on times to convert the hdmi signal to vga or any tests I could run to determine actual lag?

maxriptide

@tjohnson I am a shmupper and very sensitive to lag. I have tried measuring the lag by the manual lag measurement tool found in the 240p Suite available for Megadrive, PC engine, SNES and some other consoles. At first I got the hang of it with the real consoles (Megadrive and PC engine) where I could measure an average lag of 0,7 frames which roughly should be your "human response time" since it depends on your reflexes, I used this value as a baseline for the upcoming measurement with retropie emulators. With two different HDMI-VGA adapters I got approximately 1 frame lag more than Gert VGA Adapter. Try yourself, it could be interesting to get lag data with different adapters.

tjohnson

@maxriptide had to look up what shmupper meant. I enjoy games like Rtype, Phoenix, Galaga, I'll try and do some lag test with the 240p suite using hdmi to vga and direct output from the composite output.