Recalbox sur TV CRT en RGB

[archimage]

le groupe facebook pi2jamma, le développeur lui même l'a dit

[Substring]

@archimage oh yeah !

[dranozir]

Bonjour !

J'avoue que je n'ai pas eu la patience pour lire tous les posts de cette page.

Je voudrai savoir quoi faire pour brancher ma recalbox vers un écran cathodique ( dans un bar )

Je comptais acheter un câble HDMI vers RCA mais ce ne serai pas la meilleur solution.

Car j'ai vu ce tuto ici : https://github.com/recalbox/recalbox-os/wiki/Connectez-votre-recalbox-à-un-CRT-avec-composite--(FR)

si je doit faire la manipulation a chaque fois que je passe d'une télé a l'autre ...

[ian57]

@dranozir pour pas t’embêter à lire achète un rgb-pi http://www.rgb-pi.com/ et mets la distro associée, y'a aussi le pi2scart http://www.smallcab.net/pi2scart-raspberry-p-1654.html et son tuto https://www.smallcab.net/telechargement/manuel/manuel-pi2scart.pdf

[Substring]

@ian57 on peut aussi ne pas recommander ceux qui ont jugé inutile de ne pas contribuer au projet

[voljega]

@substring elle manque un peu de négation ta phrase je ne suis pas sûr de ne pas avoir compris de quoi il ne retourne pas. ou pas. :)))

[dranozir]

@ian57

A ouai il faut carrément changer de distribution ?

[Substring]

@voljega c'est tout l'art de ne pas noyer le poisson

[gkralicek2]

@ian57 pfewww ils y vont pas avec le dos de la cuillère avec le pi2scart niveau prix. Près de 40 euros le bousin alors qu'une carte GPIO VGA 666 coûte 3 euros sur alibaba (https://m.fr.aliexpress.com/item/32860497400.html?pid=808_0002_0109&spm=a2g0n.search-amp.list.32860497400) et qu'un câble vga peritel (d'excellente facture de surcroît) coûte 10 euro chez retrocable (http://retrocables.es/tienda/index.php?id_product=55&controller=product&id_lang=1)
Au final on a exactement le même produit mais... 27 euros d'écart. Ca fait une belle grosse marge tout ça :-)))))

[ian57]

@substring moi je suis toujours aidant mon coté fairplay

[ian57]

@gkralicek2 le pi2scart embarque une connectique audio et une connectique péritel de bonne qualité. Moi je réalise mes vga2scart à la mano mais vu le temps que ça prend... ben 40balles des fois c'est pas cher payé.

[ian57]

@dranozir oui mais sur rgbpi ça reste une recalbox...

[Substring]

@ian57 un VGA666 + VGA2SCART avec audio reste moins cher, c'est ce qu'explique @gkralicek2

[archimage]

https://www.youtube.com/watch?v=OVKw_jJmAYY&t=37s

La versions nightly de Windows et Linux intègrent déjà la mise à jour, il vient d'annoncer qu'il se concentre sur le pi

[Substring]

@archimage oh yeah !!!

[archimage]

Salut tout le monde,

J'ai longtemps cru que seuls les CRT 15khz ou trisync pouvaient encaisser du 240p tel qu'on l'aime, avec de vraies grosses scanlines, et une image sharp non upscalée sans filtres.

Cela est vrai pour du 240p en 60hz, 60 images par seconde, on rentre dans le spectre des écrans 15khz.

Cependant, lorsqu'on envoie du 240p120hz, par un savant calcul mathématique on rentre dans le spectre de compatibilité 31khz, et l'image 240p devient désormais compatible.

C'est ce que Mike Chi et Ben Templeman démontrent avec ingéniosité dans ces 2 vidéos.

L'image est affichée 120 fois par seconde au lieu de 60 fois par seconde, car il s'agit d'émulation, en effet l’émulateur contrairement à la console peut envoyer 2 images à la fois sur 2 instances séparées sans produire de lag.

On a donc le même rendu qu'un bon BVM en termes de finesse et de scanlines.

Dans le cas d'un upscaler et une vraie console il aurait nécessité d'enregistrer la premiere frame, et de la renvoyer immédiatement à l'écran, ce qui résulte à une frame de lag. Pour le moment un tel upscaler n'existe pas car il n'y a pas de fonctions de frame buffer suffisament puissant intégré.

Aujourd'hui Ben Templeman, qui a déjà porté CRT Switchres sur Linux et Windows en branche officielle, est en train de porter cette fonction 31khz dans Retroarch nativement, et ça va bientôt débouler sur Windows, Linux et une distribution spéciale Raspberry pi via la sortie HDMI, sans aucune limite de pixel clock, car il utilise des drivers video X11 spéciaux qui ne sont pas fournis d'office dans nos distributions habituelles. Il arrive avec ça à débloquer les limitations du pixel clock du pi et du coup rendre obsolète VGA666.

Cela veut dire qu'avec un simple pi, un vulgaire convertisseur hdmi>vga et un vieux crt de pc dont tout le monde veut se débarrasser car incompatible avec les jeux retro 240p, bein on fait à peu près ce qu'on peut faire avec un BVM multisync, pour le moment en émulation, et peut être bientôt avec de vraies consoles, notamment celles en fpga...

Donc si vous avez un vieux cathodique de pc qui traine et que vous êtes desespéré de trouver un bvm multisync... ou une Naomi 31khz qui traine par là, ou si vous avez peur de cramer votre trisync à switcher tout le temps en émulation, soyez patients...

Je vous laisse apprécier les vidéos.

15khz Ben Templeman Raspberry Pi Retroarch avec X11 et HDMI>VGA

31 khz Ben Templeman

31 khz Mike Chi

[Substring]

@archimage qq éléments sur tout ca :

• les jeux ne sont pas 120Hz d'origine, et je doute qu'un pi puisse tourner à 120FPS sur tous les emulateurs
• l'arcade n'a jamais utilisé de timings standards (qui respectent la GTF). Là, c'est encore pire : on s'eloigne vraiment du hardware d'origine
• ca m'étonnerait énormément qu'on ajoute x11 sur pi, parce qu'on va vraiment prendre cher niveau perfs

Donc techniquement, on pourrait sûrement déjà profiter de retroarch linux avec le switchCRT intégré du moment qu'on a X11, mais ca n'est pas vraiment la philosophie Recalbox pour le coup. Mais ca doit tout à fait pouvoir s'essayer sur une raspbian.

[archimage]

@Substring :

• Si un jeu est en 54.5hz par exemple, la fréquence à passer avec un nombre entier si on veut l'afficher sur du 31khz est de 109hz (54.5x2). Retroarch est capable soit d'insérer une blank frame à chaque image, ou une double frame, c'est ce que préconise Ben. Si tous les cores ne sont pas capables de supporter le double frame sur le pi pour une question de ressources ce n'est pas si grave, il suffirait de désactiver l'option 31khz 240p et passer en 31khz linedoublé (480p). Il faut voir le 31khz comme une cerise sur le gateau permettant de se passer d'un moniteur pro. Si tout tourne bien sur 15khz, c'est déjà pas mal. Je ne m'inquiète pas trop pour ça Ben fait partie de l'équipe de Retroarch et ils sont très enthousiastes avec l'arrivée de ses fonctionnalités, ils vont surement optimiser pour que tout marche bien sur le pi.

• je ne vois pas en quoi on s'eloigne si on reste sur un ratio X2 entier sur la fréquence, 30 images par seconde peuvent tres bien passer dans 60 images par seconde, si c'est 59.9 la fréquence d'origine, ça donnera tout simplement 119.8

• comme tout, il faut savoir ce qu'on gagne et ce qu'on perd : ce qu'on gagne c'est le support plug and play 240p 15khz/31khz avec toutes les modelines déjà fournies par retroarch en temps réel (cf sonic 2 switch bien en 480i automatiquement quand il passe en 2 players) et ça c'est déjà un bijou car on a les vraies infos délivrées par le core en temps réel y compris celles de mame ou fba. Deuxièmement, le fait de ne plus être dépendant d'un gpio, ou d'une extension quelconque, un simple hdmi>vga suffit pour faire le taf. C'est la solution la moins chère niveau matos, ça laisse le gpio libre. On perdrait de la perf ? Combien ? Quel impact sur nos jeux ? Je pense que c'est bien d'avoir une philosophie mais il faut la mettre à l'épreuve...

A suivre

[cazeysan]

Bonjour tout le monde, question de débutant peut-être un peu hors sujet.
Un adaptateur HDMI=>VGA, avec donc une conversion numérique/analogique ne produit pas de latence ?

[archimage]

@cazeysan Ben a mesuré ça avec une camera tournant à 60fps passée à 1 frame par seconde, il n'a aucune frame de décalage en utilisant X11 et hdmi>vga, la frequence affichée correspond à la fréquence du jeu, pas de limitation comme on peut le constater sur un hdmi>vga utilisé avec le driver video natif qui donne accès à seulement une panoplie limitée de fréquences. Donc le hardware n'est pas réellement la cause du lag, mais la limite posée par le driver.