Recalbox sur TV CRT en RGB

[ian57]

@Scandy great news... will try that ASAP :)... but 1.5 directly to 3.0?

[Scandy]

@ian57 I suppose it's because now in AdvanceMAME are included also AdvanceMESS and AdvanceMENU (previous version was at 2.9). I'm curious to read about tests with VGA and SCART. Thank you.

[Substring]

@ian57 dude, need your rpi-(userland|firmware) b*mp PR ! You also need to remove the 2nd advancemame patch from the package

[Scandy]

@aTg thank you for sharing this, but I really hope to have the possibility to buy soon a cable assembled by yourself.
IMHO a "female" SCART would be more practical.

[aTg]

@Scandy The reason that it is a male cable is so that no extra cables are necessary, to move to a female connector should completely redo the circuit since the pins are not all symmetrical, some are crossed.
If there is a lot of interest, I'll do something female.

Well here I finally have revision 2 of the circuit (I already have list 3)
The improvements are very important, the simplification in the soldier is great.

[Substring]

@aTg IMHO telling people to buy a male to female adapter is much better
But the pictures show a very short cable, that could bother some people

[aTg]

It is also possible to use a flat cable extension, or as you say a female/male extension cable.
What happens is that the RPi is not like a SNES that is something that you like to see in the furniture while you play.
Anyway the length of the cable is pending, you can make your requests, the only difference will be in the final price of the product.

[aTg]

This is the most similar to the final result, the last problem I have is that the scart connector creates a curvature in the cable.

One solution that occurs to me is to cut the cable asymmetrically, some other idea?

Edit: Tonight I'll try to test an idea, cut the flat cable in angle.

[Substring]

@aTg For a second thought : a female cable is not that stupid either, it would be like a good old SCRAT DVD player that you plug in your TV with a good old Male-Male SCART.

[ajefr]

Another solution
http://www.neo-arcadia.com/forum/viewtopic.php?f=14&t=56947

[aTg]

I have been investigating how to do the installation of recalbox with NOOBS from the DPI output and the easiest way to do it is PINN.

The problem is that it only has the overlay for vga666 and with rgb-pi the colors are changed.
Anyway the installation is automatic so it's just that you can see the progress and little else.

You have to add to recovery.cmdline disablesafemode and generate a config.txt with the following:

dtoverlay=VGA666
enable_dpi_lcd=1
display_default_lcd=1
dpi_group=2
dpi_mode=87
hdmi_timings=320 1 20 29 35 220 1 10 14 16 0 0 0 60 0 6400000 1

[tikiandskull]

@aTg green screen and dpi make me think a this https://forum.recalbox.com/topic/5104/aide-parametrage-ecran-geekwrom-hd-3-5/44 solved with «dtoverlay=pi3-disable-bt-overlay" in config.txt...

[aTg]

@tikiandskull Thanks for the information, I tried, in this case does not look blue for that reason but it is important to have it present for recalbox.

[david-rose]

Bonjour
j'ai essayé de trouver la réponse dans vos posts mais j'ai pas trouvé. pouvez vous me dire l'intérêt du VGA (à la place du HDMI) pour faire le cable VGA TO SCART,
est ce que la qualité sera meilleure (du fait que le VGA est bloqué en 640*480).
autrement que peuvent m'apporter le VGA to SCART (comparé à un adaptateur HDMI vers SCART que j'ai et dont je trouve la qualité pas très nette même en rgb)
merci

[Scandy]

@david-rose HDMI > VGA est une conversion de digital en analogique qui introduit un certain retard vidéo.
Avec le VGA acquis directement auprès GPIO ce retard ne devrait pas être là.

[gkralicek2]

@Scandy Le VGA n'est pas directement acquis auprès du GPIO puisqu'il faut un réseau de résistance (R-2R ladder) entre la sortie GPIO et le connecteur VGA. Par contre il est vrai que cette méthode n'induit, sur le papier, pas de latence d'affichage comme c'est le cas avec un convertisseur HDMI-VGA (DAC). Dans la pratique et pour avoir comparé les deux longuement, la latence est quasi imperceptible pour peu que le convertisseur HDMI->VGA soit de bonne qualité. Après l'usage du GPIO présente certaines limitations concernant le nombre de couleurs affichables simultanément (codage couleur sur 6 bits par canal donc 18 bits au total soit 262144 couleurs max). Pas vraiment gênant en soi pour des jeux retro utilisant rarement plus de 65536 couleurs à l'écran :=). Par contre l'adaptateur GPIO->VGA monopolisant un grand nombre de broches sur le GPIO, il n'en reste plus assez pour pouvoir connecter des sticks arcade en montage dans un bartop par exemple. La connexion de manettes en USB générant plus d'input lag dans les jeux qu'un stick arcade branché en GPIO (dans les jeux de type Vs fighter c'est flagrant), perso je préfère reserver l'usage du GPIO pour les contrôleurs jeux et sortir du RGB à partir d'un convertisseur HDMI-VGA de qualité avec une latence d'affichage quasi-nulle :=)

[archimage]

Le HDMI a aussi l'avantage de procurer un DAC audio, ou laisser libre le GPIO pour utiliser quelque chose de plus qualitatif comme du Hifiberry. Pour ma part je trouve ça plus facile de commencer par là. En revanche j'ai constaté un défaut assez contraignant, des fois en sortant d'un émulateur, au retour à Emulation Station j'ai des pertes de synchronisation intempestives. Rebrancher le HDMI ou réinitialiser l'affichage avec la commande tvservice résoud le problème sur le coup. Mais je n'ai pas encore compris d'où ça vient pour l'éliminer entièrement et empêcher que ça revienne en sortant de Retroarch. Le passage du 240p au 480i a l'air d'être un peu chaotique...

[archimage]

Rendu sur un sony BVM .

[Scandy]

@gkralicek2 said in Recalbox sur TV CRT en RGB:

Le VGA n'est pas directement acquis auprès du GPIO puisqu'il faut un réseau de résistance (R-2R ladder) entre la sortie GPIO et le connecteur VGA. Par contre il est vrai que cette méthode n'induit, sur le papier, pas de latence d'affichage comme c'est le cas avec un convertisseur HDMI-VGA (DAC). Dans la pratique et pour avoir comparé les deux longuement, la latence est quasi imperceptible pour peu que le convertisseur HDMI->VGA soit de bonne qualité. Après l'usage du GPIO présente certaines limitations concernant le nombre de couleurs affichables simultanément (codage couleur sur 6 bits par canal donc 18 bits au total soit 262144 couleurs max). Pas vraiment gênant en soi pour des jeux retro utilisant rarement plus de 65536 couleurs à l'écran :=). Par contre l'adaptateur GPIO->VGA monopolisant un grand nombre de broches sur le GPIO, il n'en reste plus assez pour pouvoir connecter des sticks arcade en montage dans un bartop par exemple. La connexion de manettes en USB générant plus d'input lag dans les jeux qu'un stick arcade branché en GPIO (dans les jeux de type Vs fighter c'est flagrant), perso je préfère reserver l'usage du GPIO pour les contrôleurs jeux et sortir du RGB à partir d'un convertisseur HDMI-VGA de qualité avec une latence d'affichage quasi-nulle :=)

Il serait intéressant de faire des test "scientifique" dans le "monde réel", pour évaluer l'existence de:

• convertisseurs HDMI > VGA presque lagless
• arcade stick USB presque lagless (utilisés dans le tournois EVO?)

En outre, le retard induit par le port USB dépend souvent du OS et par l'UI. Je lis quelque part (Shmups forums?) que les ports USB en Linux sous CLI sont pratiquement lagless.

[Substring]

@Scandy let's see where lag can come from, depending on the input method :

• GPIO : the mechanics of sticks/buttons do not generate any lag. The clock scanning the gpio + the processing of the gpio information (which is inside the kernel, not in userspace), then udev or SDL2, is the only source of lag before the data is processed by the emulator
• USB : again, let'.s not bither with mechanics. The info has to be processed by the onboard chip, send the right info through the usb, then processed by the usb-hid kernel module, udev/sdl2 then emulator

I'd say the gpio is slightly faster as the processing preceding the emulator is a bit shorter.

A while ago i tried increasing the kernel rate (known as the Hz patch) + switch the context environment (server/desktop/realtime) ... I wouldn't say i found any miracle, but worse : ES constantly had micro stutters