Recalbox sur TV CRT en RGB

[ajefr]

Already working
http://www.neo-arcadia.com/forum/viewtopic.php?f=14&t=54733

https://www.youtube.com/watch?v=v4pR3LKDCPw

[Substring]

@ajefr This is not exactly the same :

• RPI2JAMMA doesn't handle the sound out from GPIO, but from the jack output
• RPI2JAMMA is mostly for JAMMA, where as we are, for now, more looking into a SCART system
• I didn't get how you handle inputs

Do you have a documentation on how to plug everything ?

[aTg]

If my version incorporates the sound by the GPIO and is much smaller, I hope the opinion of the community if you think it interesting to continue with the development of jamma-pi or you think that with rpi2jamma is enough.

[ian57]

@ajefr @aTg I think that the thing that will make the difference is the software support

[Substring]

Both are great. Rpi2jamma is great for jamma-wired cabs, aTg's device is for crt only, like back in the old days

[aTg]

@Substring I am thinking in launch a version for jamma but im not sure.

I see that rpi2jamma is very expensive, could drastically reduce its cost, size and number of components.

[Akik]

J'ai enfin mis la main sur une petite Trinitron de 36cm, je vais pouvoir me lancer dans le CRT en RGB grâce à ce post. Merci ! C'est une Sony KV-14LM1B.

[aTg]

[aTg]

I have finished assembling the prototype and it works very well, I reduced the noise in the image, for the production version I will change the size of the components to a larger one but basically everything is fine.

[aTg]

I have uploaded a small script that I have done to check all bits of the RGB output separately and also the two audio outputs by the GPIO 18 and 19, this test is also valid for vga666 or other devices that use mode 6 of the DPI.

It is necessary to have raspi-gpio, fbi and alsa.

rgbpi-test.zip

[Substring]

@aTg no sudo (who cares, we are root hahaha), no rasp-gpio, no fbi on recalbox
Anyway, most of your magic is done by overlays, so it shouldn't be a problem (unless it's a kernel version problem)

[aTg]

@Substring Sorry I forgot to mention the test it is for Raspbian.

[Substring]

@aTg i guessed already lol i'm just thinking beyond retropie

[Akik]

Hello,
Ayant depuis peu une TV Sony KV-14LM1B (la même que aTg), je me lance dans l'aventure "construction d'un câble VGA/HDMI en RGB" et étant sur le point d'acheter l'adaptateur/convertisseur VGA-HDMI, je souhaitais savoir si celui du recalstore est le "meilleur" : https://www.amazon.fr/VicTsing-Convertisseur-Adaptateur-Ordinateur-Chromebook/dp/B016Q2AU9Q/ref=as_sl_pc_tf_til?tag=httpwwwrecalb-21&linkCode=w00&linkId=&creativeASIN=B016Q2AU9Q
Si vous avez des conseils pour un modèle encore meilleur, je suis preneur ! Merci bien.

edit: quelle(s) différence(s) avec ces adaptateurs ? https://www.amazon.fr/s/ref=nb_sb_noss_2?__mk_fr_FR=ÅMÅŽÕÑ&url=search-alias%3Daps&field-keywords=hdmi+scart
Hormis le prix bien plus élevé

[aTg]

I continue with the development of the hardware so that all of us can have something with which to work in a standardized way, once I finish I collaborate with the software.

After the first prototype I found that the circuit is very simple but the wiring is very complex, the welding points in a disorderly way make lose many efforts and make mistakes when having to check each wire one by one.

I have redesigned the circuit so that the pins are numbered and in the same order as in the flat cable, this way you only have to remove unused cables first and then go soldering without having to check anything or think, a purely mechanical work.

The problem with this is that it has made the circuit more complex, I have had to put a lot hours of work, the positive side is that it has been reduced in size by almost half.

Edited:

[aTg]

Ok, let's go with the software part.

To get the audio at the same time as the video for the GPIO we need to use pins 18 and 19 which in the case of vga666 are occupied by the color red.

These two pins are the option we have to move the PWM channels from the minijack to the GPIO. So the vga666 scheme is not worth it, but the DPI output of the RPi has different configurations.

vga666 uses mode 5 that we see in the image and we need mode 6 so it is necessary to use the overlay dpi24 that supports all modes and select the 6 with dpi_output_format

The problem in recalbox is that we do not have this overlay.

Edit:
I linked a custom compilated overlay made by me to be able to use mode 6, I hope devs can include it in future versions.

rgb-pi.dtbo

[ian57]

@aTg I think we will no include the dtbo file as is. Please make a github with the sources (the dts file) and we will make a package with it for recalbox.
From http://elinux.org/RPi_BCM2835_GPIOs here is your dts file

/dts-v1/;
/plugin/;

/ {
  compatible = "brcm,bcm2708";

  fragment@0 {
    target = <&gpio>;
    __overlay__ {
      pinctrl-names = "default";
      pinctrl-0 = <&pwm_audio_pins>;

    pwm_audio_pins: pwm_audio_pins {
    brcm,pins = <18 19>;   /* gpio no ('BCM' number) */
    brcm,function = <2 2>; /* 0:in, 1:out, 2: alt5, 3: alt4, 4: alt0, 5: alt1, 6: alt2, 7: alt3 */
    brcm,pull = <0 0>;     /* 2:up 1:down 0:none */
      };
    };
  };
 };

In fact your dtbo file only moves PWM audio to pin 18-19... so the file should be named differently : rpi-audio-on-gpio.dtbo or something like that

[aTg]

@ian57 You're confused.

The audio moves with the overlay pwm-2chan that is already included do not need to rename or recompile.

The file that is required is for the video output.

Vga666.dtbo is exactly the same as dpi24.dtbo, if decompile the files you can see it, the difference is that dpi24 uses gpio pins from 4 to 27 while vga666 uses only from 4 to 21.

Rgb-pi.dtbo is another distinct compilation of dpi24 and uses pins 4 to 9, 12 to 17 and 20 to 25 to be able to use mode 6 of the DPI output as I explained above.

You could include dpi24 to use all modes, but if vga666 has its reason to exist being a custom version of dpi24 I do not understand why rgb-pi.dtbo no. This is another adapter other than vga666 and you can not use that overlay.

Here rgbi-pi-overlay.dts

/dts-v1/;

/ {
compatible = "brcm,bcm2708";

fragment@0 {
	target = <0xdeadbeef>;

	__overlay__ {
		pinctrl-names = "default";
		pinctrl-0 = <0x1>;
	};
};

fragment@1 {
	target = <0xdeadbeef>;

	__overlay__ {

		rgb-pi_pins {
			brcm,pins = <0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9 0xc 0xd 0xe 0xf 0x10 0x11 0x14 0x15 0x16 0x17 0x18 0x19>;
			brcm,function = <0x6>;
			brcm,pull = <0x0>;
			phandle = <0x1>;
		};
	};
};

__symbols__ {
	rgb-pi_pins = "/fragment@1/__overlay__/rgb-pi_pins";
};

__local_fixups__ {

	fragment@0 {

		__overlay__ {
			pinctrl-0 = <0x0>;
		};
	};
};

__fixups__ {
	leds = "/fragment@0:target:0";
	gpio = "/fragment@1:target:0";
};
};

[ian57]

So vga666 and rgb-pi are only particular case of dpi24. VGA66 is named like that according to the hardware but is making also rgb. So I still think you should rename your work rgb-scart.dtbo ( or sort of) to include the specific problem of audio + gpio pin shift due to audio ouput on scart.

but as a sum up, we can use your hardware without new dtbo with :

dtoverlay=pwm-2chan,pin=18,func=2,pin2=19,func2=2
dtparam=i2c_arm=off
dtparam=spi=off
dtoverlay=dpi24
dpi_group=2
dpi_mode=87
dpi_output_format=0x6f000 # or something like that :)

[aTg]

VGA666 is a trade name associated with the gert adapter, for the DPI port it comes out in 666 mode in other ways, my adapter is also 666, I have to put scart666&audio.dtbo? It does not seem logical to me, vga666 could perfectly use dpi24 and instead uses an overlay associated with its mark, I do not understand why it can not be the same with rgb-pi.

Rgb, evokes console video output for tv, while vga implies the use of pc monitors.

I do not want to use the term scart, because scart can also be confused with composite video.

If you mean that the same overlay includes the movement of the sound pins I think it's OK but I do not understand why I have to use a generic name.