[WIP 100%] Normaliser un signal vidéo
Page 1 sur 8
Page 1 sur 8 • 1, 2, 3, 4, 5, 6, 7, 8
[WIP 100%] Normaliser un signal vidéo
Le résultat final pour ceux qui ne veulent pas tout lire
.
Aujourd'hui, j'ai décidé que ça devait être plus simple!
Je vais avancer par étages:
- Le premier va suivre le signal d'entrée, en isolant les signaux de synchro horizontale et verticale
- Le second va décaler celui-ci dans le temps (pour produire le décalage horizontal de l'image)
- Le troisième va compter les lignes de balayage et décider quand produire des signaux VBL (pour produire le décalage vertical de l'image)
Mon boulot du jour concernait le premier étage, et je vais tenter de faire la même chose qu'avec le paquet de puces que j'avais mis en place ci-dessus... avec un micro-contrôleur tout nimbus cadensé à 8MHz que j'utilise pour la première fois, un ATTiny85:
![[WIP 100%] Normaliser un signal vidéo 20191016](https://i.servimg.com/u/f10/20/08/08/03/20191016.jpg)
Le principe: code 95% dans un gestionnaire d'interruptions, déclenché à chaque impulsion détectée. Le code est plutôt optimisé, balance très rapidement une impulsion en retour et calcule des moyennes de durées de trames pour produire les siennes lors des séquences de VBL.
Tout ça utilise 900 octets de ROM et 29 octets de RAM.
Une fois que tout ça est en place, pour me rapprocher encore un peu plus di signal d'origine, je décide d'innover et d'utiliser pour la première fois de ma vie un quartz externe. Ca tombe bien, j'en avais acheté quelques uns à 20MHz et c'est justement la cadence maximum de ce micro-contrôleur.
Le montage se complique juste un tout petit peu:
![[WIP 100%] Normaliser un signal vidéo 20191017](https://i.servimg.com/u/f10/20/08/08/03/20191017.jpg)
Et quand je lui donne mon signal le plus pourri, celui avec une absence totale de pics de synchro pendant le VBL, eh ben il s'en sort quand même...
![[WIP 100%] Normaliser un signal vidéo Tiny8410](https://i.servimg.com/u/f10/20/08/08/03/tiny8410.png)
Vu que ça marche bien, j'en profite pour ajouter la détection des signaux VBL et la production d'un signal qui indique le retour à la première ligne de l'écran. Ca me permettre de savoir quand commencer à compter les lignes.
Voilà ce que ça donne dans mon super analyseur logique à 5€:
![[WIP 100%] Normaliser un signal vidéo Logiqu10](https://i.servimg.com/u/f10/20/08/08/03/logiqu10.png)
La stabilité du signal n'est pas parfaite, mais elle est tout de même plutôt pas mal. Je valide cet étage pour le moment et je vais m'attaquer au suivant: le décalage.
S'il ne fallait gérer qu'un décalage horizontal, cette installation serait suffisante. Mais vu qu'on n'est pas ici pour rigoler, on continue avec les étages suivants!
=> Retour sur le sujet un mois plus tard... Je me suis remis sur ces saletés de microcontrôleurs ATTINY85. Et puis ça m'a gonflé parce que c'est compliqué à programmer, alors je suis passé à l'ATTINY84 (plus de pattes, et j'ai déjà bricolé un kit pour les programmer) => c'est trop compliquer à debugger et ça m'a gonflé aussi.
Résultat: j'ai opté pour le canon à mouches: j'utilise directement deux plaquettes toutes intégrées avec un microcontrôleur chacune.
- La première fait ce que faisait le petit ATTiny ci-dessus, à savoir détecter et séparer les signaux VSync et VBL
- Ma deuxième fait le comptage de lignes, le calcul des plages de VBL, et les décalages horizontal et vertical.
Vu que j'étais plutôt content du résultat, j'ai branché là-dessus un potar qui permet de régler le décalage horizontal et d'observer le résultat direct sur l'oscilloscope.
Voilà la chose:
![[WIP 100%] Normaliser un signal vidéo Deuxmi10](https://i.servimg.com/u/f10/20/08/08/03/deuxmi10.jpg)
Et une fois tout ça branché, on arrive au résultat attendu depuis des mois, et de manière plutôt stable, en plus!
Sur l'image ci-dessous, on peut observer un décalave vertical de 5 lignes, un VBL de 3 lignes et un décalage de synchro en avance (donc décalage de l'image vers la droite):
![[WIP 100%] Normaliser un signal vidéo Chaine10](https://i.servimg.com/u/f10/20/08/08/03/chaine10.png)
Et on commence par le test sur une vraie carte JAMMA pour s'apercevoir... Que ça ne marche pas: Des soucis de timing font que le VBL n'est pas détecté correctement. En plus, la forme d'onde est un peu différente de celle sur laquelle je travaillais: cette carte envoie des impulsions durant le VBL, ce qui n'était pas le cas de mon modèle.
=> Je corrige
Puis le VBL est détecté correctement, mais les impulsions générées pendant le VBL ne le sont pas. Et je trouve enfin l'explication à une génération un peu fluctuante autour de al zone de VBL... En un mot: concurrence entre le code de secours (qui génère pendant le VBL) et le code qui produit les impulsions sur interruptions.
=> Je corrige
Je joue un peu avec les décalages horizontaux, pour voir que je suis uniquement capable d'injecter beaucoup de retard dans la synchro, et donc de l'avance, et donc un décalage de l'image vers la droite.
=> Je me prends bien la tête pour ajouter du retard de traitement sur le microcontrôleur qui décode les pulsations en entrée, et j'arrive à générer de l'avance ET du retard. De l'ordre d'une quarantaine de pixels, ça me semble très correct!
J'arrive à quelque chose comme ça:
![[WIP 100%] Normaliser un signal vidéo Chaine11](https://i.servimg.com/u/f10/20/08/08/03/chaine11.png)
On voit que le VBL est déclenché en avance de 7 lignes (décalage vers le bas) et on distingue un décalage horizontal de quelques millisecondes en avance, donc décalage de l'image à droite.
Histoire de m'amuser un peu, parce qu'il faut... Je rajoute un 2ème potar pour le décalage vertical.
Après ça, je me prends la tête avec le code pour comprendre pourquoi, quand je bouge l'offset horizontal, ça me fait bouger l'offset vertical. Et j'en arrive à la conclusion que les deux convertisseurs analogique/numérique du microcontrôleur que j'utilise pour lire les potars interfèrent entre eux! J'utilise un autre port et ça atténue un peu la chose. Jamais vu ça avant, c'est couillon.
Ensuite, je me dis que le signal que je produis n'est pas dans les normes, parce qu'il n'y a pas d'impulsion pendant le VBL. Bon, dans les faits, l'écran s'en accommode, c'est le modèle de la carte 60in1. Générer un vrai signal pendant la phase de VBL est carrément pas simple. Mais pour maximiser les chances d'avoir un signal correctement interprété, je vais me rapprocher du modèle de signal de la carte 138in1. Le modèle n'est pas parfait, mais il a le mérite de produire des pulsations durant le VBL, et ça, c'est bien.
=> Je modifie mon code pour gérer des pulsations en logique inverse par rapport aux pulsations habituelles.
J'obtiens le signal suivant:
![[WIP 100%] Normaliser un signal vidéo Chaine12](https://i.servimg.com/u/f10/20/08/08/03/chaine12.png)
Cette fois-ci, on observe un signal décalé de 7 lignes vers le bas avec un offset horizontal vers la gauche, et on a bien des pulsations pendant le VBL. A bien y regarder, ça ressemble quand même furieusement au signal d'entrée!
Prochaine étape: supergun de la mort avec 6 résistances et des fils, puis j'intercale mon montage au milieu et on regarde ce qui se passe!
Pour commencer, je me débarrasse des fils soudés directement sur le connecteur JAMMA de la 138in1. Je les remplace par des jolis connecteurs soudés sur une rallonge JAMMA. Ce sera plus simple à connecter sur mes plaques de proto, et sur les PCB de proto qui arriveront potentiellement derrière. Et en plus, je pourrai tester d'autres cartes JAMMA très facilement.
Un connecteur d'alimentation, et un connecteur pour les signaux vidéo. Ca suffira pour le moment:
![[WIP 100%] Normaliser un signal vidéo 20200116](https://i.servimg.com/u/f10/20/08/08/03/20200116.jpg)
Je fais les premiers tests... pas d'image. Visiblement, ma carte 138in1 tire la tronche. Je recherche donc une candidate au suicide, et je trouve une Pandora Box X. Parfait!
Voici donc l'installation, avec fils qui se promènent et cosses sur les pins de la prise Peritel!
![[WIP 100%] Normaliser un signal vidéo Instal10](https://i.servimg.com/u/f10/20/08/08/03/instal10.jpg)
Les deux potars servent à régler l'image. Concrètement, elle n'est pas terrible, elle ondule légèrement. Après observation du signal de synchro à l'oscillo, je trouve un signal pas beau du tout. Il se dégrade dès que je le raccorde à la télé. L'absence de blindage n'a pas l'air de faire du bien...
Ca devrait être bien carré, mais donne ça:
![[WIP 100%] Normaliser un signal vidéo Sycnhr10](https://i.servimg.com/u/f10/20/08/08/03/sycnhr10.png)
J'essaie de remplacer le signal de synchro par le mien, et... l'image n'est pas plus belle, mais elle n'est pas plus moche non plus, donc ça me convient. Et comme disait Yannick pendant ces soirées-là...
En haut...
![[WIP 100%] Normaliser un signal vidéo Enhaut10](https://i.servimg.com/u/f10/20/08/08/03/th/enhaut10.jpg)
En bas...
![[WIP 100%] Normaliser un signal vidéo Enbas10](https://i.servimg.com/u/f10/20/08/08/03/th/enbas10.jpg)
A gauche...
![[WIP 100%] Normaliser un signal vidéo Agauch11](https://i.servimg.com/u/f10/20/08/08/03/th/agauch11.jpg)
A droite...
![[WIP 100%] Normaliser un signal vidéo Adroit11](https://i.servimg.com/u/f10/20/08/08/03/th/adroit11.jpg)
![Wink](https://2img.net/i/fa/i/smiles/icon_wink.gif)
- On parle de quoi?:
- Préambule
Comme discuté précédemment, j'ai des soucis de réglage de mon écran (une télévision, en l'occurrence) quand je passe de mon slot MVS à ma Pandora Box (et à mon PC, accessoirement, mais on verra plus tard (480i)).
Mes problèmes
Le souci est classique: l'image ne fait pas la même taille, et n'est pas centrée de la même manière. Il faut donc passer par le menu de service de la télé pour régler la position de l'image. Et il ne s'agit pas simplement de toucher des potars sur un moniteur arcade (déjà bien casse bonbons), mais bel et bien d'entrer dans cet horrible menu prévu pour les réparateurs en entrant un Konami code sur la télécommande de la télé.
Problème similaire: j'ai une carte 60in1 sur une autre borne, qui tourne sur une petite télé que j'ai récupérée
gratuitement sur un vide grenier sans sa télécommande (donc pas d'accès au menu service).
Le but de la manoeuvre
Ce que je cherche à faire, c'est un système qui me permettrait de paramétrer rapidement le centrage de l'image sur mon écran (ou sur celui de quiconque serait intéressé) en appuyant juste sur un bouton.
Généralités - ce que j'ai compris
Concrètement: le fait que l'image varie d'une machine à l'autre est lié à plusieurs facteurs:
- Le balayage d'une ligne affichable est plus ou moins long, potentiellement à cause d'une résolution différente, mais potentiellement aussi simplement pour une raison de timing => l'image est plus ou moins large à l'écran
- Le timing entre la synchro et le signal vidéo est différent: l'image commence à s'afficher plus ou moins tôt lors du balayage => l'image est décalée horizontalement ou verticalement (ou très probablement les deux)
Warning, Will Robinson
Attention, avertissements:
- je ne suis pas spécialiste du signal vidéo. J'ai fait un supergun minimaliste en appliquant des résistances adaptées pour mettre les signaux au bon niveau de tension pour un téléviseur.
- je vais m'occuper uniquement du signal 240p, qui est utilisé par tout le matériel que j'ai en JAMMA, et qui me semble plus simple à comprendre
- il est très probable que je n'arrive à rien à la sortie, mais au pire, j'aurai appris 2 ou 3 trucs au passage ;-)
- il est probable aussi qu'il existe des appareils tout prêts qui font déjà ça très bien et pour pas cher
- En théorie:
- La doc que j'ai pu trouver
Je vais tenter d'expliquer ce que j'ai compris, en me concentrant dans un premier temps sur la problématique horizontale. J'imagine que la verticale se comporte à peu près pareil, mais je n'ai pas encore pu le constater. Si vous avez des infos ou compléments ou corrections à apporter, n'hésitez pas à intervenir!
D'un point de vue documentation, je n'ai pas trouvé grand chose sur Internet. Quand on parle de synchro et de balayage, on trouve beaucoup de doc sur la configuration des émulateurs. En creusant un peu, on finit par trouver des infos sur les signaux composites (synchro et couleurs sur le même fil). Or le JAMMA, c'est un fil par couleur et un pour la synchro.
Un affichage par balayage, comment ça marche (à mon avis) => On s'accroche!
J'imagine que tout le monde connait à peu près le fonctionnement d'un écran CRT, avec ses 3 canons à électrons, chacun dédié à une couleur, et qui parcourent l'écran ed gauche à droite et de haut en bas.
Je vais tenter de schématiser les différentes zones de l'écran d'après ce que je comprends...
On distingue 4 zones de balayage:
1 - La zone de synchro (canons éteints). Je ne sais pas vraiment où la caser sur le dessin, parce que j'imagine que ça correspond aussi à peu près au temps que mettent les canons pour traverser l'écran. Je le montre quand même parce que ça pourrait rendre la suite plus simple.
2 - La marge à gauche (et en haut) ou "Back Porch": les canons affichent la couleur de fond (noir en général, mais certains ordinateurs savent afficher une couleur ici, qui change potentiellement à chaque ligne)
3 - L'image (le plus facile, finalement)
4 - La marche à droite (et en bas) ou "Front Porch"
Pour la dénomination Front et Back, j'aurais utilisé la dénomination inverse, mais qui suis-je pour exprimer un avis? :-)
On peut rapprocher ces 4 zones des signaux qui transitent sur les fils Rouge, Vert, Bleu, Synchro (RVBS, ou RGBS en anglais).
Ca donne ça (je suis dessinateur professionnel):
On retrouve nos 4 zones sur 2 graphiques.
Le premier montre ce qui transite sur les fils rouge, vert et bleu (il y a 3 fils, mais comme il se passe la même chose sur les 3, j'ai superposé les signaux).
Le second montre ce qui transite sur le fil de synchro.
Le principe de réglage de la position de l'image
Si on met en relation des deux dessins (l'écran et les graphiques), on serait tenté de se dire qu'il serait éventuellement envisageable peut-être... de décaler le signal de synchro dans le temps sans toucher au signal video:
- On avance le signal de synchro: il bouge vers la gauche sur le graphique, ça diminue le Front porch (4) et ça augmente le back porch (2) => ça diminue la marge à droite et ça augmente la marge à gauche => ça décale l'image vers la droite.
- On retarde le signal de synchro: il bouge vers la droite sur le graphique et l'image se décale vers la gauche.
Ca, c'est mon interprétation. Ca doit pouvoir s'appliquer aux marges verticales également.
L'idée serait donc ce jouer sur le centrage de l'image simplement en jouant sur le timing des signaux de synchro.
Les avantages
- On ne touche pas aux signaux R, V, B. Du coup, pas de perte de qualité
- On ne touche qu'à la synchro: elle est beaucoup moins complexe à gérer, parce qu'elle véhicule seulement une donnée binaire à une fréquence de 15kHz, ce qu'un microcontrôleur devrait pouvoir gérer sans le moindre problème.
- Si un microcontrôleur peut le gérer, alors on peut assez facilement proposer une interface de réglage intuitive et rapide, avec des pré-configurations par carte JAMMA à raccorder.
Les inconvénients
- On ne touche pas aux signaux R, V, B. Du coup, on n'a pas la main sur la longueur de la phase de balayage n°3 (l'image) => on ne peut pas régler la largeur de l'image
- On ne pourra donc pas avoir une image plein écran pour toutes les cartes JAMMA, et il faudra faire des compromis.
Les interrogations
- Est-ce que mon écran ne va pas me péter à la figure si je modifie les timings? Il doit y avoir un minimum de standard à respecter, mais je n'en ai pas la moindre idée. Mais c'est comme ça qu'on innove :-). Au pire, je pense que j'aurai de la perte de synchro et une image qui saute. Rien de grave.
- Je crois que les timings des signaux VGA, eux, sont super normés. On s'en fout, on ne produit pas du VGA :-)
- Les observations:
- L'analyse du signal sur une carte JAMMA
La première étape concrète est de souder des fils sur l'adaptateur JAMMA de ma carte MVS 138in1 (dont je n'ai plus l'utilité), et de regarder ce qui passe sur les canaux couleur (jai pris le vert) et synchro quand elle affiche son menu. J'arriverai peut-être ainsi à comprendre comment fonctionne la synchro verticale (comment on distingue le retour à la ligne du retour en haut de l'écran).
J'ai choisi l'option soudure parce que mes connecteurs JAMMA sont occupés à des tâches plus nobles, et je ne compte pas en acheter un juste pour ça. Je soude donc les fils directement sur le connecteur, et j'ajoute au bout des connecteurs Dupont pour pouvoir facilement brancher des fils dessus.
Voilà ce que donne l'installation. La carte est alimentée en +5V et +12V par un bloc d'alim de PC. Les sondes d'oscilloscope sont reliées sur le fil de la synchro et sur le fil du vert.
Une fois que tout est branché, vient le moment de faire plein de réglages passionnants de l'oscilloscope pour attraper un balayage complet de l'écran...
Ouf, voilà globalement ce que donne un balayage (entre les deux lignes verticales en pointillés).
La courbe bleue montre le signal de synchro, qui fait une impulsion par ligne de balayage. La courbe rouge montre le signal du vert (tiens, j'aurais peut-être mieux fait de changer la couleur sur le graphique). Nous avons donc sous les yeux une série de lignes d'affichage avec des signaux de vert (en rouge).
Comme on pouvait s'y attendre, le signal couleur est analogique.
Pour ce qui est de la synchro, je pense qu'il est purement logique. Il plafonne à 4.42V, ce qui est la tension d'alimentation (j'ai des câbles pourris, je perds 0,45V entre l'alim et la carte!), mais qu'il est distordu parce pas généré proprement par la carte. Après, pour prouver ça, ça va être compliqué.
La mesure de fréquence du signal de synchro (en bas) indique une monenne de 15.67kHz. C'est rassurant, ça correspond à peu près à la norme pour du 240p.
Par contre, la mesure entre les barres me donne approximativement le temps de balayage de l'écran. Et 17.48ms, ça nous fait 57Hz. Pas tout à fait ce que je voulais, mais après tout, il ne s'agit que de la carte JAMMA de menu, et non du slot MVS. Je en m'attends donc pas à tomber pile dans des choses connues. Me voilà en tout cas rassuré sur le fait qu'une télé n'est pas très regardante sur le timing...
On zoome et on regarde d'un peu plus près ce qui se passe pendant le balayage d'une ligne:
Point important: les impulsions de synchro sont sur les fronts descendants et pas sur les fronts montants comme je le pensais. La synchro est donc active à 0V, et on obtient presque exactement ce que j'avais dessiné, mais avec la synchro à l'envers et en moins joli.
On voit qu'on a du signal video jusqu'à très près du signal de synchro, et repart plus loin (mais peut-être qu'il y avait du noir à gauche de l'écran, qui sait?). L'image doit être pas mal à droite de l'écran, d'après ma théorie. On a donc un front porch court et un back porch long.
On voit aussi que le signal de synchro est tout pourri. Peut-être à cause de la carte qui n'est pas de top qualité, peut-être à cause de mon alimentation qui n'est pas de top qualité. En tout cas, on dirait bien qu'il ne faudra pas trop se fier aux niveaux de synchro.
A présent, on se rapproche de la zone de vertical blanking (ou VBL, ça vous parle?), donc quand les canons à électrons repartent viser le haut de l'écran:
On distingue un signal de synchro bizarre, que j'assimile à un signal de VBL: on compte 6 impulsions dont la durée est proche de celle du balayage d'une ligne (il faudra que je creuse ça pour mesurer le timing exact).
On compte à peu près 22 lignes vides avant le signal de VBL, et à peu près 21 lignes après. Vous les avez reconnues, il s'agit du front porch et du back porch verticaux.
- Premiers essais - Pas assez rapide:
- Qu'est-ce qu'on fait avec ça?
Maintenant qu'on sait à peu près à quoi ressemble le signal de synchro, il va falloir apprendre à la mesurer avec un microcontrôleur, de manière à pouvoir le reproduire avec un timing différent.
L'idée serait de faire grossièrement ça:
En gros, les signux vidéo sortent du connecteur JAMMA et partent sur l'écran, mais on intercepte le signal de synchro et on en produit un légrement déphasé.
La prochaine étape se passera donc au niveau soft. Il va falloir que je programme:
- la détection des différents timings
- le code de production d'impulsions courtes (changement de ligne) et longues (VBL).
- la génération d'un signal identique à celui d'origine
- la génération du signal décalé horitontalement
- la génération du signal décalé verticalement
Pour la production des impulsions, il me faudra peut-être passer par des circuits externes pour plus de précision, je ne sais pas encore.
Après génération du signal d'origine, je devrais être en mesure de brancher mon montage sur un écran et d'observer une image identique à l'image d'origine. Il m'aura fallu des heures pour ne rien faire à la sortie
Mise en place du microcontrôleur et premiers tests de kecture de synchro
Je branche donc un Arduino sur le signal de synchro, et j'attaque le code...
Les sondes de l'oscilloscope sont branchées sur le signal de synchro produit par la carte JAMMA, et sur le signal produit par le microcontrôleur:
Premiers essais... étant donnée la fréquence du microcontrôleur (un Arduino Uno à 16MHz), on a une résolution de l'ordre de la micro-seconde. C'est également l'ordre de grandeur des largeurs d'impulsion de synchro, alors j'appréhende un peu les résultats quand il va falloir produire la synchro.
Je commence par essayer de détecter et mesurer les signaux produits par la carte JAMMA.
Pour gagner au maximum en précision, j'utilise une interruption matérielle pour compter les impulsions et mesurer l'écart entre les impulsions. L'écart entre impulsions doit correspondre à la durée de balayage d'une ligne.
Pour faire le calcul, j'attends une impulsion de référence, je prends une référence de temps, puis je compte 10 impulsions et je calcule le temps écoulé depuis le temps de référence et je le divise par 10.
Et ça donne ça:
Le nombre d'impulsions indiqué correspond au nombre d'impulsions comptées sur une période de 2ms.
Les résultats sont cohérents et surprenants à la fois (tout est en micro-secondes):
- La durée de scan d'une ligne est très variable, entre 60 et 67 µs. Ce qui donne une fréquence horizontale de 14,9kHz à 16,7kHz. C'est à peu près ça, mais ça devrait être constant! D'autant qu'on est sur u microcontrôleur, ça devrait être du temps réel, donc toujours le même comportement.
- Cependant, le nombre d'impulsions sur 2ms est stable entre 31 et 32 impulsions.
- La durée d'impulsion est aussi assez bizarre... 8µs, c'est ce qu'on trouve quand on mesure avec l'oscillo. 64µs, c'est ce qu'on droit trouver quand on est sur les pulsations de VBL. Ca correspond avec les 31 impulsions ci-dessus, ça tombe bien. Par contre, d'où sortent les 16µs?!
Premiers essais de génération de signal de synchro
J'ai de sérieux doutes sur la précision de tout ça. On va devoir décaler le signal d'une fraction de microseconde. Ca doit pouvoir se faire avec un peu d'assembleur, mais je n'en ai pas fait depuis une vingtaine d'années.
Pour éprouver le temps de réaction du microcontrôleur, je vais tenter de faire un "suiveur": à chaque fois que je vois qu'une impulsion démarre, je démarra la mienne. Quand je la vois se terminer, je termine la mienne.
Voilà ce que ça donne à l'oscilloscope. En bleu le signal de synchro, et en rouge celui que je génère:
On observe un décalage de 8µs entre le début du signal de synchro et le début du signal généré, soit la durée d'une impulsion de synchro. Sans la mesurer, l'impulsion générée est quand même aussi sensiblement plus longue que l'impulsion de synchro.
Et donc?
... et donc je me tâte à continuer l'expérience avec ce microcontrôleur.
Il me reste 3 macro-solutions:
- m'aider de composants externes (PLL, oscillateur, compteurs, portes logiques, ...) pour produire un signal de synchro qui ressemble à quelque chose. Ca peut être intéressant et enrichissant, mais ça va être une usine à gaz!
- utiliser un microcontrôleur plus rapide
- lâcher l'affaire
Dans l'ordre, on va tenter les options 2, 1 et 3.
- Nouvel essai avec un nouveau micro-contrôleur:
- Quel microcontrôleur choisir?
Voilà en gros ce que j'ai sous la main:
- Cartes Arduino Uno ou Pro Mini ou Pro Micro: toutes à base de microcontrôleur Atmel 8 bits cadensés à 16MHz => Ca a l'air un peu léger en termes de vitesse. Dommage, parce que c'est facile à utiliser
- Circuit intégré ATtiny84: microcontrôleur similaire à ceux embarqués sur les cartes ci-dessus, avec moins de RAM et moins de mémoire flash, mais qui peut monter à 20MHz => Ca risque de ne pas être beaucoup mieux, et ce n'est pas vraiment pratique de prototyper dessus.
- Carte STM32 "Blue Pill", on change de gamme avec un microcontrôleur 32 bits cadensé à 32MHz => Ca devient sensiblement plus rapide, mais pas énormément, et on passe à 3.3V, donc on ne pourra pas produire directement le signal de synchro.
- Carte ESP32, on change de monde avec un microcontrôleur 32 bits dual core à 240MHz => Fini la rigolade. Par contre, on est toujours en 3.3V.
Vu comme ça, mon choix s'oriente vers l'ESP32. Niveau prix, on est à environ 5€ pour ce modèle, c'est plutôt raisonnable.
Ce qui me gène pour le moment, c'est que les API de l'environnement de développement de l'Arduino, que j'utilise habituellement pour programmer tout ce petit monde, ne semblent pas supporter de timings en-dessous de la micro-seconde. Je vais creuser un peu, mais il va probablement falloir que j'installe (et que je découvre) l'environnement de développement de l'ESP32...
En creusant un peu plus, il semble que le SDK ESP32 sous environnement Arduino fournisse un jeu d'API complémentaire, qui permet entre autres choses de connaître le nombre de cycles d'horloge entre deux opérations. Et étant donnée la fréquence d'horloge de 240MHz, ça nous ramène à 4ns de précision. Là, on commence à parler!
Bon, dans les faits, j'ai remplacé l'Arduino Uno par un ESP32 et adapté le code... L'installation ressemble à peu près à la précédente, avec en plus un "level shifter" pour faire parler le monde 5V et e monde 3.3V :
La résolution est bien meilleure, on tombe à 2.6µs de retard entre le signal détecté et le signal produit. La conversion de niveau de tension n'occasionne aucun retard significatif.
On va voir si je peux faire plus rapide en utilisant directement l'environnement du constructeur. Au pire, j'aurai appris un truc!
=> tout est installé, et les premiers tests sont faits. La réactivité n'est pas fulgurante, mais c'est quand même un peu mieux parce qu'un nouveau monde d'API, avec notamment de nouveaux timers de précision, est à portée.
J'ai passé pas mal de temps à réfléchir à la manière de générer une synchro qui ne se déphase jamais par rapport à la source (sinon, c'est les vagues verticales assurées). Le plus simple me semble de réagir systématiquement aux impulsions de la source, puis de temporiser avant de les reproduire (décalage horizontal) et de jouer sur leur largeur (pour placer le VBL où je veux, et donc jouer sur le décalage vertical).
Je viens de trouver un super article qui explique ça super bien, et qui me fait réaliser que les pulsations de VBL sont en fait décalées d'une demi-période par rapport aux pulsations de HSYNC! => Fausse frayeur. Les demi-pulsations, c'est pour le 480i. En fait, j'avais tout bon, ouf.
Ca se passe ici:
HDRetrovision - Engineering CSYNC
A l'attaque
Je commence à me familiariser avec l'environnement de développement.
Je crée mon premier bout de code concret: je configure un gestionnaire d'interruption pour compter les impulsions de synchro de ma source vidéo.
Le calcul est simple: je mesure le temps qu'il faut pour compter 5000 impulsions.
Après ça, une division me donne la fréquence horizontale.
Et ça marche, je suis tout chose
Pour la fréquence verticale, ça va être plus compliqué, parce qu'il va falloir mesurer les largeur d'impulsions pour détecter le VBL.
Mais la structure est là et ça marche, c'est déjà bon pour le moral.
A force de prise de tête, j'ai fini par produire du code à peu près optimisé pour reproduire le signal d'origine avec un décalage temporel réglable.
Le principe est de faire deux choses à la fois: scruter les impulsions produites par la carte JAMMA, attendre un certain temps en fonction du décalage horizontal ou vertical qu'on veut, et reproduite les mêmes impulsions.
Pour faire deux choses en même temps, le secret, c'est d'utiliser les interruptions matérielles...
En gros, on dit au microcontrôleur d'arrêter tout ce qu'il est en train de faire dès qu'il reçoit un événement sur l'une de ses broches. Ici, on va lui dire de scruter les débuts et les fins d'impulsions.
Quand une impulsion a lieu, on exécute donc du code spécifique pour détecter le type d'impulsion (courte ou longue, en fonction du temps écoulé entre le début et la fin), et détecter la ligne en cours de balayage.
On peut voir ça comme ça:
Pour faire des tests tranquille dans mon salon, j'ai reproduit un signal de référence dans le générateur de fonctions intégré à mon oscilloscope. Le signal correspond à 8 lignes d'image et 2 lignes de synchro, émises à un fréquence équivalente aux 15,67kHz de la carte JAMMA de test.
Le signal généré ressemble donc à ça:
Là, je commence à penser que je m'en suis bien sorti, ça a l'air de fonctionner...
Voilà ce que je peux observer à l'oscillo. En bleu, la pulsation de référence, et en rouge celle que je produis en retour:
Et puis il m'arrive de détecter un décalage. On dirait qu'il m'arrive de perdre des signaux d'entrée, et du coup de me décaler dans mon comptage de lignes... et donc de produire un signal de synchro décalé d'une ligne, puis 2, puis 3...
Je me dis qu'à la vitesse où ont les choses, ça ne devrait pas trop se voir à l'écran, mais ce n'est pas très satisfaisant.
J'essaie donc d'en savoir plus, et j'observe des kilomètres de courbes à la recherche d'un départ de décalage qui me mettrait sur une piste.
Et là, horreur, voilà sur quoi je tombe:
Grosse lassitude... Je ne perds pas un signal de temps en temps, j'en perds carrément une caisse... Je relis mon code dans tous les sens, et je finis par en conclure que le problème vient de l'OS du microcontrôleur ESP32 pour gérer les deux coeurs et le matériel embarqué (Wifi, Bluetooth). Il s'appelle FreeRTOS, avec RT qui signifie Real Time. Et sur le coup, j'ai bien l'impression que le côté RT est un peu usurpé. J'ai beau faire en sorte d'avoir l'exclusivité du coeur 1 du microcontrôleur, on dirait bien que je me prends une préhension de 10ms qui me met dedans.
Ne nous laissons pas démonter. Après tout, j'ai quand même appris à utiliser l'environnement de ce microcontrôleur, ça servira un jour ou l'autre!
- Encore un autre essai avec encore un autre micro-contrôleur:
- On passe donc au nième plan B... Les plateformes du genre Arduino à base de microcontrôleur 8 bits ont montré leurs limites (pour faire ça, en tout cas). Je passe donc au dernier modèle que je n'ai pas encore testé: le STM32. Par contre, l'architecture n'a rien à voir, on ne fait pas les choses de la même manière, et je dois reprendre tout le code.
Un STM32 Blue Pill (comme dans Matrix), ça ressemble à ça:
Une fois le code repris, j'arrive assez bien à suivre le signal...
Je n'ai pas encore récupéré le code qui permet de retomber sur ses pattes quand le signal de désynchronise. Je laisse tout ça tourner un moment pour voir si je tiens enfin ma solution! Et là, j'observe un truc auquel je ne m'attendais pas. OK, je ne perds pas de pulsations, mais curieusement, j'ai des pulsations en trop!!! En remontant un peu le temps, je trouve ça:
Je relis mon code pour la 27ème fois pour voir où je me suis raté. Et là, je me dis que je n'ai pas pu me rater à ce point, et je cherche une cause externe. Illumination, je réduis la résolution verticale de l'oscilloscope, qui produit une sortie 12 bits à partir d'informations 8 bits, induisant un lissage du signal invisible quand on ne travaille pas en hautes fréquences (ce n'est pourtant pas le cas ici).
Voilà ce que ça donne quand je passe la voie d'entrée en 8 bits:
Et voilà donc l'explication! Les débuts et fins d'impulsions générées par le microcontrôleur produisent des parasites sur l'entrée, qui sont interprêtés comme des pulsations par le gestionnaire d'interruption, qui me détecte un changement de ligne!
Si j'affiche tout en 8 bits, ça donne un bon aperçu du carnage. Voilà donc ce qui se passe dans les tuyaux, et pourquoi les gens utilisent des condensateurs de découplage!
Après un test en version soudée, j'ai à peu près les mêmes résultats pas terribles. Le passe donc au 27ème plan B, et je teste l'option buffer: c'est un circuit intégré qui prend un signal numérique d'un côté, et qui sort le même de l'autre. En gros, c'est comme une porte logique qui renvoie toujours le signal d'entrée (une porte "OK"?).
L'avantage de ce circuit est qu'il peut nettoyer un signal d'entrée pas beau, et le sortir à niveau de tension de son alimentation. Ici, je rentre du 3.3V crado, et j'en fais un joli 5V. J'en profite pour augmenter l'impédence d'entrée et de sortie pour calmer un peu les pics quand même (j'ajoute des résistances en série, quoi).
Et là, comme par magie, j'obtiens un signal tout beau, tout propre:
Du coup, je me sens en veine, et je fais un essai sur le vrai matériel, la carte JAMMA 138in1.
Et là, ça ne marche pas terrible, la fréquence, est fausse, c'est n'importe quoi. En même temps, ça aurait été dommage, on s'amuse tellement.
Visiblement, le signal de sortie de la carte n'est pas le même que celui que j'avais trouvé sur Internet. On m'avait prévenu qu'il pouvait y avoir des variations, mais là, j'en suis à me demander comment la télé arrive à s'en sortir...
- Les différents signaux vidéo de mes différentes cartes JAMMA:
- Voilà les différentes techniques de synchro VLB sur les différentes cartes que j'ai à la maison. Il faut garder en tête qu'une ligne dure un peu plus de 63µs...
- 138in1 (Carte JAMMA qui pilote la carte multi MVS): la synchro se fait sur les fronts descendants. Puis, pendant le VBL, la synchro se fait sur le front montant (pourquoi faire simple?):
- 60in1 (Carte JAMMA avec 60 jeux des années 80, super bien quoi qu'en disent certains). La synchro se fait sur les fronts montants, puis plus de synchro pendant le VBL (débrouille-toi avec ça):
- Pandora Box X (hardware de la Pandora Box 3): la synchro se fait sur les fronts descendants, puis le VBL arrive et un front descendant disparait et tout se décale, mais à la fin, ouf, tout revient dans l'ordre (et on perd aussi un front descendant à la sortie):
- Slot MVS (c'est pour ça qu'on est là): enfin quelqu'un qui fait les choses bien! on a bien des fronts descendants réguliers, la vie est belle. Par contre, on a un record de nombre de pulsations de VBL (8!):
Si je me restreins au slot MVS, mon montage devrait fonctionner. Mais le but de la manoeuvre est de régler les marges en fonction de la carte branchée (hors 60in1 qui est dans une borne qui lui est dédiée). Il va donc falloir gérer tous ces cas, et potentiellement d'autres!
- Essais en électronique discrète - le PLL:
- En faisant le point au calme, je me dis que la plus pourrie des télés trouvée dans la rue s'en sort très bien pour afficher une image. La différence entre elle et mon système est qu'elle se pose beaucoup moins de questions, et qu'elle n'a pas un programme qui tourne et qui essaie de comprendre ce que le constructeur du périphérique d'entrée a essayé de faire.
La piste qu'elle choisit est celle de l'électronique, et plus précisément d'un composant que j'ai découvert il y a peu, le PLL (ou Phase-Locked Loop, ou boucle à verrouillage de phase).
Il s'agit en gros d'un oscillateur, et qui prend pour référence un signal d'entrée et qui essaie de vibrer à la même fréquence. Il met un certain temps avant de s'accorder sur le signal qu'il imite, ce qui fait qu'il ne verra pas trop passer les signaux de VBL bizarres.
Ici, on va s'en servir pour suivre le signal de synchro aussi bien que possible. Et c'est son signal de sortie qui nous servira à produire le nôtre!
Curieusement, on se rapproche un peu du scénario usine à gaz du départ. On va avoir de la porte logique et du PLL, il ne manque que le compteur et la panoplie du cauchemar est complète :-).
Premiers tests avec un PLL et le générateur de fonctions de mon oscilloscope. Il y a un paquet de composants à ajuster pour paramétrer la boucle de verrouillage. Il faut trouver les bonnes valeurs de résistances (il y en a 3) et de consendateurs (il y en a 2) pour que la boucle verrouille sur du 15kHz et pour qu'elle lisse correctement les signaux VBL moisis.
L'installation fait un peu flipper...
Voilà ce que fait un PLL bien réglé sur un signal 15kHz (en bleu l'originaml, en rouge le signal de sortie du PLL):
Sur un signal qui sort de la carte JAMMA, c'est pareil, sauf quand arrive le signal VBL. On voit qu'il y a un créneau plus long que les autres, utilisé pour raccrocher les wagons avec la fréquence de base:
C'est donc reparti pour les essais de valeurs de résistances pour que la rétroaction soit moins violente. Et j'arrive à ça... la pulsation est plus régulière, et je rattrape les bizarreries du signal d'entrée (ici la durée horitontale change carrément pendant le VBL). On voit le déphasage pendant le VBL, puis le PLL raccroche délicatement les wagons et se recale tranquillement sur le signal de synchro:
Je vais me caler sur ce signal pour produire mes pulsations. Le PLL fait pour moi tout le travail d'intégration du signal en entrée pour me produite un signal tout propre pour produire mon signal déphasé en sortie (oui, c'est le but).
... et le code est refait pour s'adapter à ce nouveau signal, issu du PLL.
Sur le papier et de loin, tout fonctionne impec.
En observant les signaux original/copie, je m'aperçois de variations temporelles: les fronts descendants ne sont pas toujours parfaitement alignés. La conséquence, prévisible sur l'écran, c'est une ondulation de l'image. C'est rigolo, mais ce n'est vraiment pas le but recherché.
Deux explications:
- Le PLL ne synchronise pas parfaitement, il lui faut un peu de temps pour se remettre des fluctuations du signal d'entrée pendant les VBL. Pour ça, en bricolant encore un peu avec les résistances et condensateurs, je devrais arriver à trouver un réglage un peu plus stable (peut-être?)
- Le microcontrôleur met un temps qui n'est pas constant pour traîter les interruptions. Et pour cause... Les calculs ci-dessous.
En 15kHz, une ligne s'affiche en environ 63µs. Pour donner une idée, une machine comme la NeoGeo a une résolution de 320x224 pixels. On affiche donc 320 pixels en 63µs, soit environ 5 pixels par µs.
Quand j'affiche une version rémanente de l'écart entre le front descendant issu du PLL et celui issu du microcontrôleur, je visualise une instabilité qui s'étale sur à peu près 800ns (nano secondes, oui):
En faisant le calcul, on peut compter que, même sans compter l'erreur du PLL, on a déjà une erreur équivalente à 4 pixels. Le résultat doit donc être carrément flou.
Je ne m'explique pas totalement cette erreur. Le microcontrôleur travaille en temps constant, et dispose d'une horloge de 72MHz, donc environ une instruction (machine) tous les 13ns avec 1 MIPS/MHz (c'est le cas pour l'Arduino, pas forcémént pour le STM32, mais ça donne une idée). Avec ça, je ne vois pas comment je peux me retrouver avec une variation de 800ns, sachant que je réagis directement à l'impulsion, sans consultation de l'horloge (ça, par contre, ça induit de sacrés décalages, l'API d'horloge fournit seulement de micro secondes).
Bref, je vais réfléchir à tout ça, et je devrai peut-être partir sur ue piste un peu plus hard (c'est le cas de le dire) et jouer du compteur et de la porte logique.
Nouvelle idée à base de composants discrets. Ca promet d'être amusant !
Ce n'est pas forcément clair, mais la grosse difficulté de l'entreprise n'est pas le calage vertical. Pour celui-là, il suffit de produire des impulsions de VBL au même rythme que le signal original, mais décalés d'un nombre entier de cycles en avant ou en arrière.
La craie difficulté, c'est de parvenir à décaler finement l'impulsions à l'intérieur d'une période de 63µs (une ligne de balayage) pour décaler l'image horizontalement de quelques pixels.
Dans un premier temps, j'ai pensé utiliser un second PLL pour découper le signal de synchro en rondelles (donc un signal de fréquence plus élevée), pour piloter un registre à décalage qui me permettrait de décaler dans le temps le démarrage de la synchro.
Cette option m'a paru plutôt chouette, avec encore quelques inconnues sur la possibilité de multiplier mes 15kHz de départ par un nombre suffiant pour une bonne résolution de réglage horizontal, tout en restant gérable. En partant sur un découpage de la ligne en 20 crans de réglage, il faut multiplier mes 15kHz par 20 et je produis déjà 300kHz. Etant donnée la précision de mon matériel, je crais d'induire de nouvelles "vibrations" horizontales, qui pourrissent l'image rendue.
Et là, il y a 2 jours, je tombe sur une vidéo de présentation des PLL très bien fichue et dans les 2 dernières minutes, le gars présente une astuce l'air de rien: en injectant une tension à l'entrée du générateur de fréquence, on peut déphaser le signal de sortie. Ca n'a l'air de rien, mais c'est EXACTEMENT CE QUE JE CHERCHAIS A FAIRE pour mon décalage horizontal!
Je viens de faire le test, ça marche impec. Je peux décaler le signal d'au moins une période complète (une ligne de balayage) sans perdre la syynchro du PLL!
Du coup, je suis passé à l'expérimentation, et je commencer à tester l'enchaînement de PLL:
- le premier récupère un signal de synchro propre, sans ces cochonneries d'impulsions de VBL toutes plates
- Le second gère le décalage horizontal.
J'ai encore un peu de boulot pour le réglage de ces deux PLL.
Par contre, niveau matériel, je n'ai qu'un oscilloscope à 2 voies, qui ne me permet pas d'afficher à la fois le signal d'entrée, et celui de sortie des deux PLL qui suivent. Or il est essentiel que je puisse observer ces trois signaux pour détecter et mesurer leurs décalages respectifs.
Et c'est ici qu'intervient mon nouveau jouet chinois à 5,51€: un analyseur de protocoles 8 bits. C'est un petit boitier USB avec 8 fils qu'on branche où on veut, et le PC engegistre les signaux logiques envoyés sur ces fils et fait de jolis graphiques interactifs.
Je viens de faire le test, c'est carrément chouette (et pour le prix, c'est hallucinant)!
L'installation à 5,51€:
Le rendu, avec seulement 3 voies sur les 8 utilisées:
La suite: régler les PLL correctement, essyer de virer les impulsions de VBL avec des filtres pour perturber un peu moins les PLL. Tout un programme, mais au moins j'aurai les outils pour le suivre!
- On bouche les trous avec un oscillateur fait à la main:
Tout cela fonctionne plutôt bien à première vue, mais je compte utiliser les fronts montants de mon signal de synchro généré comme référence pour introduire mon décalage horizontal.
Je place mon logiciel d'oscillo en position "persistance" (je ne sais pas comment ça s'appelle) et je zoome sur mon signal. Je m'aperçois qu'il n'est pas stable: il "vibre" horizontalement sur près de deux microsecondes (soit environ 5 ou 6 pixels potentiels, c'est énorme!).
Je me dis que les gros potentiomètres que je j'utilise pour régler mon signal sont peut-être en cause. Je les ai eu avec ma boîte de découverte de l'Arduino et ils m'ont toujours posé des problèmes.
Heureusement, j'ai reçu des "trim pots": des potentiomètres multi-tours à vis super méga précis. Je remplace des potars pourris par mes trim pots tout neufs.
C'est un peu plus joli:
Par contre, le résultat est à peu près le même...
Pour en avoir le coeur net, je repositionne ma sonde d'oscillo pour observer la charge du condensateur qui permet de déclencher la bascule du mode haut au mode bas:
J'observe bien mes créneaux qui bougent horisontalement. Par contre, la courbe de charge du condensateur reste stable. Je pensais que mes condensateurs chinois avaient un comprtement bizarre, alors que ce sont les comparateurs et/ou la bascule internes du circuit intégré NE555 qui posent problème en ne déclenchant pas à chaque cycle au même niveau!
On le voit un peu sur la vue en mode 'persistance":
La courbe de charge du condensateur ne bouge pas verticalement, alors que le créneau, lui, bouge latéralement.
Je passe dont au plan B numéro [?]... Vu comme je galère depuis quelques semaines, de commence à comprendre comment fonctionne le NE555 en interne, et je décide de créer mon propre circuit de minuterie, sans les limitations du NE555 et, qui sait, avec plus de stabilité...
Le circuit sera composé de deux comparateurs et une bascule RS, ainsi que d'un transistor de décharge et un condensateur pour la temporisation. Il ressemblera à ça:
Un moment plus tard, tout est en place:
L'instant de vérité... Et ça oscille comme prévu, et du premier coup. Un miracle! L'ajuste l'armée de trim pots pour régler la fréquence et le cycle de service, et ça donne ça:
La stabilité me semble bien meilleure. Je vérifie le signal en passant en mode persistant...
Le résultat est bien meilleur! Je suis à 200 nanosecondes de vibration horizontale en comptant large sur la demi-période qui m'intéresse.
Par contre, il y a une chose à laquelle je n'ai pas encore réfléchi concernant mon circuit. Il faut que je puisse faire repartir le signal à zéro à la demande, pour me caler sur les fronts montants du signal de référence.
J'utilise le petit circuit générateur d'impulsion à partir d'une porte logique, une diode, un condo et une résistance. Je le colle sur le signal de référence, et je le fais sortir sur la bascule de mon circuit oscillant. Ce n'est pas parfait, parce que ça va forcer la décharge du condo dans une résistance, donc avec un délai. Même si l'état bascule instantanément, le réarmement pourrait se refaire avant que le condo ne soit déchargé, avec pour conséquence une phase de niveau haut plus courte.
Bref, j'essaie, on verra bien. Je fais entrer le signal de référence en haut à droite du circuit:
Et j'observe l'évolution du signal de référence et du signal généré:
=> Ca me va, le contrat est rempli:
- les signaux sont bien synchronisés sur les fronts descendants
- l'oscillation se poursuit durant la période de VBL moisi
- le signal de référence est stable en fréquence et pourra me servir de base pour produire mon signal final moyennant décalage temporel.
Pour la suite, je suis un peu frileux à l'idée d'utiliser un PLL pour le décalage. Je crois que je vais partir sur une charge de condensateur, comme je viens de le faire. La système me semble suffisamment précis.
Aujourd'hui, j'ai décidé que ça devait être plus simple!
Je vais avancer par étages:
- Le premier va suivre le signal d'entrée, en isolant les signaux de synchro horizontale et verticale
- Le second va décaler celui-ci dans le temps (pour produire le décalage horizontal de l'image)
- Le troisième va compter les lignes de balayage et décider quand produire des signaux VBL (pour produire le décalage vertical de l'image)
Mon boulot du jour concernait le premier étage, et je vais tenter de faire la même chose qu'avec le paquet de puces que j'avais mis en place ci-dessus... avec un micro-contrôleur tout nimbus cadensé à 8MHz que j'utilise pour la première fois, un ATTiny85:
![[WIP 100%] Normaliser un signal vidéo 20191016](https://i.servimg.com/u/f10/20/08/08/03/20191016.jpg)
Le principe: code 95% dans un gestionnaire d'interruptions, déclenché à chaque impulsion détectée. Le code est plutôt optimisé, balance très rapidement une impulsion en retour et calcule des moyennes de durées de trames pour produire les siennes lors des séquences de VBL.
Tout ça utilise 900 octets de ROM et 29 octets de RAM.
Une fois que tout ça est en place, pour me rapprocher encore un peu plus di signal d'origine, je décide d'innover et d'utiliser pour la première fois de ma vie un quartz externe. Ca tombe bien, j'en avais acheté quelques uns à 20MHz et c'est justement la cadence maximum de ce micro-contrôleur.
Le montage se complique juste un tout petit peu:
![[WIP 100%] Normaliser un signal vidéo 20191017](https://i.servimg.com/u/f10/20/08/08/03/20191017.jpg)
Et quand je lui donne mon signal le plus pourri, celui avec une absence totale de pics de synchro pendant le VBL, eh ben il s'en sort quand même...
![[WIP 100%] Normaliser un signal vidéo Tiny8410](https://i.servimg.com/u/f10/20/08/08/03/tiny8410.png)
Vu que ça marche bien, j'en profite pour ajouter la détection des signaux VBL et la production d'un signal qui indique le retour à la première ligne de l'écran. Ca me permettre de savoir quand commencer à compter les lignes.
Voilà ce que ça donne dans mon super analyseur logique à 5€:
![[WIP 100%] Normaliser un signal vidéo Logiqu10](https://i.servimg.com/u/f10/20/08/08/03/logiqu10.png)
La stabilité du signal n'est pas parfaite, mais elle est tout de même plutôt pas mal. Je valide cet étage pour le moment et je vais m'attaquer au suivant: le décalage.
S'il ne fallait gérer qu'un décalage horizontal, cette installation serait suffisante. Mais vu qu'on n'est pas ici pour rigoler, on continue avec les étages suivants!
=> Retour sur le sujet un mois plus tard... Je me suis remis sur ces saletés de microcontrôleurs ATTINY85. Et puis ça m'a gonflé parce que c'est compliqué à programmer, alors je suis passé à l'ATTINY84 (plus de pattes, et j'ai déjà bricolé un kit pour les programmer) => c'est trop compliquer à debugger et ça m'a gonflé aussi.
Résultat: j'ai opté pour le canon à mouches: j'utilise directement deux plaquettes toutes intégrées avec un microcontrôleur chacune.
- La première fait ce que faisait le petit ATTiny ci-dessus, à savoir détecter et séparer les signaux VSync et VBL
- Ma deuxième fait le comptage de lignes, le calcul des plages de VBL, et les décalages horizontal et vertical.
Vu que j'étais plutôt content du résultat, j'ai branché là-dessus un potar qui permet de régler le décalage horizontal et d'observer le résultat direct sur l'oscilloscope.
Voilà la chose:
![[WIP 100%] Normaliser un signal vidéo Deuxmi10](https://i.servimg.com/u/f10/20/08/08/03/deuxmi10.jpg)
Et une fois tout ça branché, on arrive au résultat attendu depuis des mois, et de manière plutôt stable, en plus!
Sur l'image ci-dessous, on peut observer un décalave vertical de 5 lignes, un VBL de 3 lignes et un décalage de synchro en avance (donc décalage de l'image vers la droite):
![[WIP 100%] Normaliser un signal vidéo Chaine10](https://i.servimg.com/u/f10/20/08/08/03/chaine10.png)
Et on commence par le test sur une vraie carte JAMMA pour s'apercevoir... Que ça ne marche pas: Des soucis de timing font que le VBL n'est pas détecté correctement. En plus, la forme d'onde est un peu différente de celle sur laquelle je travaillais: cette carte envoie des impulsions durant le VBL, ce qui n'était pas le cas de mon modèle.
=> Je corrige
Puis le VBL est détecté correctement, mais les impulsions générées pendant le VBL ne le sont pas. Et je trouve enfin l'explication à une génération un peu fluctuante autour de al zone de VBL... En un mot: concurrence entre le code de secours (qui génère pendant le VBL) et le code qui produit les impulsions sur interruptions.
=> Je corrige
Je joue un peu avec les décalages horizontaux, pour voir que je suis uniquement capable d'injecter beaucoup de retard dans la synchro, et donc de l'avance, et donc un décalage de l'image vers la droite.
=> Je me prends bien la tête pour ajouter du retard de traitement sur le microcontrôleur qui décode les pulsations en entrée, et j'arrive à générer de l'avance ET du retard. De l'ordre d'une quarantaine de pixels, ça me semble très correct!
J'arrive à quelque chose comme ça:
![[WIP 100%] Normaliser un signal vidéo Chaine11](https://i.servimg.com/u/f10/20/08/08/03/chaine11.png)
On voit que le VBL est déclenché en avance de 7 lignes (décalage vers le bas) et on distingue un décalage horizontal de quelques millisecondes en avance, donc décalage de l'image à droite.
Histoire de m'amuser un peu, parce qu'il faut... Je rajoute un 2ème potar pour le décalage vertical.
Après ça, je me prends la tête avec le code pour comprendre pourquoi, quand je bouge l'offset horizontal, ça me fait bouger l'offset vertical. Et j'en arrive à la conclusion que les deux convertisseurs analogique/numérique du microcontrôleur que j'utilise pour lire les potars interfèrent entre eux! J'utilise un autre port et ça atténue un peu la chose. Jamais vu ça avant, c'est couillon.
Ensuite, je me dis que le signal que je produis n'est pas dans les normes, parce qu'il n'y a pas d'impulsion pendant le VBL. Bon, dans les faits, l'écran s'en accommode, c'est le modèle de la carte 60in1. Générer un vrai signal pendant la phase de VBL est carrément pas simple. Mais pour maximiser les chances d'avoir un signal correctement interprété, je vais me rapprocher du modèle de signal de la carte 138in1. Le modèle n'est pas parfait, mais il a le mérite de produire des pulsations durant le VBL, et ça, c'est bien.
=> Je modifie mon code pour gérer des pulsations en logique inverse par rapport aux pulsations habituelles.
J'obtiens le signal suivant:
![[WIP 100%] Normaliser un signal vidéo Chaine12](https://i.servimg.com/u/f10/20/08/08/03/chaine12.png)
Cette fois-ci, on observe un signal décalé de 7 lignes vers le bas avec un offset horizontal vers la gauche, et on a bien des pulsations pendant le VBL. A bien y regarder, ça ressemble quand même furieusement au signal d'entrée!
Prochaine étape: supergun de la mort avec 6 résistances et des fils, puis j'intercale mon montage au milieu et on regarde ce qui se passe!
Pour commencer, je me débarrasse des fils soudés directement sur le connecteur JAMMA de la 138in1. Je les remplace par des jolis connecteurs soudés sur une rallonge JAMMA. Ce sera plus simple à connecter sur mes plaques de proto, et sur les PCB de proto qui arriveront potentiellement derrière. Et en plus, je pourrai tester d'autres cartes JAMMA très facilement.
Un connecteur d'alimentation, et un connecteur pour les signaux vidéo. Ca suffira pour le moment:
![[WIP 100%] Normaliser un signal vidéo 20200116](https://i.servimg.com/u/f10/20/08/08/03/20200116.jpg)
Je fais les premiers tests... pas d'image. Visiblement, ma carte 138in1 tire la tronche. Je recherche donc une candidate au suicide, et je trouve une Pandora Box X. Parfait!
Voici donc l'installation, avec fils qui se promènent et cosses sur les pins de la prise Peritel!
![[WIP 100%] Normaliser un signal vidéo Instal10](https://i.servimg.com/u/f10/20/08/08/03/instal10.jpg)
Les deux potars servent à régler l'image. Concrètement, elle n'est pas terrible, elle ondule légèrement. Après observation du signal de synchro à l'oscillo, je trouve un signal pas beau du tout. Il se dégrade dès que je le raccorde à la télé. L'absence de blindage n'a pas l'air de faire du bien...
Ca devrait être bien carré, mais donne ça:
![[WIP 100%] Normaliser un signal vidéo Sycnhr10](https://i.servimg.com/u/f10/20/08/08/03/sycnhr10.png)
J'essaie de remplacer le signal de synchro par le mien, et... l'image n'est pas plus belle, mais elle n'est pas plus moche non plus, donc ça me convient. Et comme disait Yannick pendant ces soirées-là...
En haut...
![[WIP 100%] Normaliser un signal vidéo Enhaut10](https://i.servimg.com/u/f10/20/08/08/03/th/enhaut10.jpg)
En bas...
![[WIP 100%] Normaliser un signal vidéo Enbas10](https://i.servimg.com/u/f10/20/08/08/03/th/enbas10.jpg)
A gauche...
![[WIP 100%] Normaliser un signal vidéo Agauch11](https://i.servimg.com/u/f10/20/08/08/03/th/agauch11.jpg)
A droite...
![[WIP 100%] Normaliser un signal vidéo Adroit11](https://i.servimg.com/u/f10/20/08/08/03/th/adroit11.jpg)
Dernière édition par Bouz le Mar 11 Juin 2024 - 22:05, édité 36 fois (Raison : Avancement)
Re: [WIP 100%] Normaliser un signal vidéo
Super intéressant et beau projet ,effectivement pour moi le plus compliqué ce sera de ne pas perdre les synchros . ![mrgreen](/users/3617/16/87/35/smiles/3227475016.gif)
![mrgreen](/users/3617/16/87/35/smiles/3227475016.gif)
_________________
"Il est indispensable d'avoir une euro dans un setup arcade" :Raditz 2/02/2018.
![[WIP 100%] Normaliser un signal vidéo Sign_m10](https://i.servimg.com/u/f21/19/34/64/46/sign_m10.png)
John Caffe le 25/09/2018:"Je comprends mieux ta remarque. Toi, t'es au moins ingénieur, et probablement inscrit à Mensa "
Re: [WIP 100%] Normaliser un signal vidéo
Semaine de boulot terminée, en route pour le bricolage!
Ce soir, analyse du trafic sur les fils des signaux Vert et Synchro d'une carte Jamma.
Prochaine étape, connecter un micro-contrôleur là-dessus. La bonne nouvelle, c'est que la tension de synchro est la même que celle des entrées-sorties logiques du microcontrôleur. On va gagner du temps et ce sera bien plus simple!
Ce soir, analyse du trafic sur les fils des signaux Vert et Synchro d'une carte Jamma.
Prochaine étape, connecter un micro-contrôleur là-dessus. La bonne nouvelle, c'est que la tension de synchro est la même que celle des entrées-sorties logiques du microcontrôleur. On va gagner du temps et ce sera bien plus simple!
Re: [WIP 100%] Normaliser un signal vidéo
Edit: premiers essais de détection et génération d'impulsions de synchro avec un microcontrôleurs, et premières interrogations.
Re: [WIP 100%] Normaliser un signal vidéo
Edit: on essaie avec un ESP32.
Promis, quand j'arrive à quelque chose de concret, je fais du ménage et je garde 2 images et 3 paragraphes ;-)
Promis, quand j'arrive à quelque chose de concret, je fais du ménage et je garde 2 images et 3 paragraphes ;-)
Re: [WIP 100%] Normaliser un signal vidéo
T'es un sacré bidouilleur! tu devrais bien t'entendre avec Bernamaphrodite ^^
cypher- Scellé
- Messages : 4546
Date d'inscription : 25/10/2015
Age : 47
Localisation : 62
Re: [WIP 100%] Normaliser un signal vidéo
cypher a écrit:T'es un sacré bidouilleur! tu devrais bien t'entendre avec Bernamaphrodite ^^
C'est gentil, mais on ne joue pas dans la même cour!
![bave](/users/3617/16/87/35/smiles/3532323268.gif)
Re: [WIP 100%] Normaliser un signal vidéo
Edit: découverte d'une super page qui décrit le fonctionnement du signal de synchro. Je n'ai pas dit que des bêtises, c'est rassurant ;-)
HDRetrovision - Engineering CSYNC
HDRetrovision - Engineering CSYNC
Re: [WIP 100%] Normaliser un signal vidéo
Edit: maintenant que je sais que je suis sur la bonne voie, je commence le code, et je parviens à calculer la fréquence horizontale. Je suis tout excité.
Re: [WIP 100%] Normaliser un signal vidéo
J'arrive à produire un signal avec un microcontrôleur ESP32. Problèmes, changement de plan.
J'alterne les problèmes et les soucis, mais je pense que je tiens la solution cible.
Nous voilà donc avec un microcontrôleur STM32 et un nouveau lot de problèmes à régler.
Vraiment sur la bonne voie, cette fois-ci?
J'alterne les problèmes et les soucis, mais je pense que je tiens la solution cible.
Nous voilà donc avec un microcontrôleur STM32 et un nouveau lot de problèmes à régler.
Vraiment sur la bonne voie, cette fois-ci?
Re: [WIP 100%] Normaliser un signal vidéo
Aujourd'hui, prise de conscience du fait qu'il y a autant d'interprétations du standard 240p qu'il y a d'outils pas rangés sur mon bureau.
Présentation des 4 cas que j'ai sous la main, et on part dans une nouvelle direction. Destination le PLL...
Présentation des 4 cas que j'ai sous la main, et on part dans une nouvelle direction. Destination le PLL...
Re: [WIP 100%] Normaliser un signal vidéo
Edit: le PLL est dans la place! Ca y est, j'ai un signal propre pour travailler. Plus qu'à reprendre tout le code
![bat](/users/3617/16/87/35/smiles/4028884632.gif)
Re: [WIP 100%] Normaliser un signal vidéo
Edit: code repris, analyse du résultat: le résultat n'est pas assez stable, ça va onduler ![combat](/users/3617/16/87/35/smiles/424633636.gif)
Projet en pause le temps de trouver une solution alternative!
![combat](/users/3617/16/87/35/smiles/424633636.gif)
Projet en pause le temps de trouver une solution alternative!
![scratch](https://2img.net/i/fa/i/smiles/icon_scratch.png)
Re: [WIP 100%] Normaliser un signal vidéo
Je suis certain que ça va bouleverser votre potentiellement long week-end (moi je bosse vendredi), mais je vous annonce quand même que j'ai trouvé de nouvelles pistes à explorer...
Ce sera à base de:
- micro-contrôleur pour compter les lignes, gérer le décalage vertical, et piloter le reste
- PLL pour générer des pulsations régulières pendant le VBL
- portes logiques pour utiliser les pulsations d'origine tout le temps et celles du PLL pendant le VBL d'origine (c'est ça le coeur de l'astuce n°1).
- un autre PLL et deux compteurs décimaux pour multiplier par 20 la fréquence du signal de synchro et générer les crans de décalage horizontal.
- des registres à décalage en chaîne, pilotés par le signal ci-dessus, pour générer des impulsions décalées dans le temps qui permettront de gérer le décalage horizontal
Des multiplexeurs câblés sur les registres à décalage, et configurés par le micro-contrôleur pour laisser passer la pulsation décalée choisie.
Voilà, avec tout ça, le micro-contrôleur n'est plus responsable du calage temporel des pulsations, et je ne devrais plus rien perdre.
C'est presque trop facile.
Je vais commencer par tester la génération 15x20=300kHz à partir d'un signal de référence à 15kHz.
Puis direction les tests de registres à décakage pour voir s'ils supportent des commandes à 300kHz. Je devrai peut-être revoir la finesse du réglage horizontal si ça ne passe pas.
Un nouvel espoir, donc!
J'espère avoir été clair (j'en doute).
Ce sera à base de:
- micro-contrôleur pour compter les lignes, gérer le décalage vertical, et piloter le reste
- PLL pour générer des pulsations régulières pendant le VBL
- portes logiques pour utiliser les pulsations d'origine tout le temps et celles du PLL pendant le VBL d'origine (c'est ça le coeur de l'astuce n°1).
- un autre PLL et deux compteurs décimaux pour multiplier par 20 la fréquence du signal de synchro et générer les crans de décalage horizontal.
- des registres à décalage en chaîne, pilotés par le signal ci-dessus, pour générer des impulsions décalées dans le temps qui permettront de gérer le décalage horizontal
Des multiplexeurs câblés sur les registres à décalage, et configurés par le micro-contrôleur pour laisser passer la pulsation décalée choisie.
Voilà, avec tout ça, le micro-contrôleur n'est plus responsable du calage temporel des pulsations, et je ne devrais plus rien perdre.
C'est presque trop facile.
Je vais commencer par tester la génération 15x20=300kHz à partir d'un signal de référence à 15kHz.
Puis direction les tests de registres à décakage pour voir s'ils supportent des commandes à 300kHz. Je devrai peut-être revoir la finesse du réglage horizontal si ça ne passe pas.
Un nouvel espoir, donc!
J'espère avoir été clair (j'en doute).
Re: [WIP 100%] Normaliser un signal vidéo
C'est bien tu gardes le moral ! ![yesss](/users/3617/16/87/35/smiles/1556860224.gif)
![yesss](/users/3617/16/87/35/smiles/1556860224.gif)
_________________
"Il est indispensable d'avoir une euro dans un setup arcade" :Raditz 2/02/2018.
![[WIP 100%] Normaliser un signal vidéo Sign_m10](https://i.servimg.com/u/f21/19/34/64/46/sign_m10.png)
John Caffe le 25/09/2018:"Je comprends mieux ta remarque. Toi, t'es au moins ingénieur, et probablement inscrit à Mensa "
Re: [WIP 100%] Normaliser un signal vidéo
Je ne lâche rien, même si je sais pas forcément dans quoi je mets les pieds au départ. C'est un poil chronophage mais très enrichissant.
Mais du coup, il ne faut pas être pressé!
Cette rubrique est parfaite pour moi: ça me pousse un peu plus à aller jusqu'au bout et à structurer ma pensée, même si ça ne passionne pas les foules ;-)
Merci de me suivre!
Mais du coup, il ne faut pas être pressé!
Cette rubrique est parfaite pour moi: ça me pousse un peu plus à aller jusqu'au bout et à structurer ma pensée, même si ça ne passionne pas les foules ;-)
Merci de me suivre!
Re: [WIP 100%] Normaliser un signal vidéo
Aujourd'hui (enfin avant-hier), découverte d'une nouvelle possibilité avec un PLL: lui injecter une tension qui déphase le signal de sortie: l'idéal pour produire un décalage de l'image horizontal tout en douceur et en prévision!
Et aussi, j'utilise pour le première fois mon analyseur logique à 5€ pour contrôler le déphasage de mes signaux dérivés de la synchro. Et c'est trop la classe!
Et aussi, j'utilise pour le première fois mon analyseur logique à 5€ pour contrôler le déphasage de mes signaux dérivés de la synchro. Et c'est trop la classe!
Re: [WIP 100%] Normaliser un signal vidéo
Bon, vu que ça commence à être franchement chargé, et que je vais attaquer le 37ème plan B (il n'y a plus assez de lettres dans l'alphabet), j'ai rassemblé tout ça en spoilers. Je ne laisserai en clair que la tentative en cours :-)
Re: [WIP 100%] Normaliser un signal vidéo
Et donc le 37ème plan B à base de portes logiques et d'un oscillateur. L'air de rien, je commence à voir pas mal de composants intéressants. Si ça continue, il est possible que je parvienne à quelque chose.
J'obtiens le signal le plus propre que j'aie pu voir jusqu'ici. Pourvu que j'arrive à en faire quelque chose!
J'obtiens le signal le plus propre que j'aie pu voir jusqu'ici. Pourvu que j'arrive à en faire quelque chose!
Re: [WIP 100%] Normaliser un signal vidéo
Ou tu trouves tes composants ? Tu as un shop d'électronique par chez toi ?
_________________
Sanjuro a écrit:en Special Guest Star, WRC dans le rôle de theWave
ancien directeur du service de renseignements NGS, il a le bras long comme un anaconda sous stéroïdes, si un gros bonnet doit se coucher, c'est qu'il en a donné l'ordre.
theWave- Pièce unique
- Messages : 10143
Date d'inscription : 25/10/2015
Re: [WIP 100%] Normaliser un signal vidéo
Si seulement... j'habite à la campagne. J'ai deux boulangeries et une boucherie pas loin.
Pour les composants, je commande des lots de 20 circuits intégrés à 1€ sur eBay et je les reçois 2 mois plus tard. Ca demande pas mal d'anticipation :-)
Pour les composants, je commande des lots de 20 circuits intégrés à 1€ sur eBay et je les reçois 2 mois plus tard. Ca demande pas mal d'anticipation :-)
Re: [WIP 100%] Normaliser un signal vidéo
OK un peu comme nous dans le 47...
Pour les condos et autres capkits ou composants on a Conrad...
Pour les condos et autres capkits ou composants on a Conrad...
_________________
Sanjuro a écrit:en Special Guest Star, WRC dans le rôle de theWave
ancien directeur du service de renseignements NGS, il a le bras long comme un anaconda sous stéroïdes, si un gros bonnet doit se coucher, c'est qu'il en a donné l'ordre.
theWave- Pièce unique
- Messages : 10143
Date d'inscription : 25/10/2015
Re: [WIP 100%] Normaliser un signal vidéo
J'ai fait un capkit sur une télé, je suis passé par Farnell. Pas de frais de port au-delà d'un prix pas très élevé que j'ai oublié, et composants de qualité. Mais forcément plus cher que les lots douteux à 1€ chinois.
Je n'acheterais pas de condos en vrac sur eBay pour un cap kit!
Je n'acheterais pas de condos en vrac sur eBay pour un cap kit!
Re: [WIP 100%] Normaliser un signal vidéo
Edit: j'ai enfin un signal d'horloge calé sur le signal de synchro, et qui poursuit son chemin indépendamment des cochonneries de VBL.
Je suis donc, a priori, en mesure d'introduire un décalage vertical de l'image sur les 3 cartes JAMMA dont je dispose.
Maintenant, il va falloir trouver un moyen d'introduire un décalage horizontal. Soit avec un PLL, soit avec un autre timer 555. En tout cas, la base est stable et c'est très cool.
Je suis donc, a priori, en mesure d'introduire un décalage vertical de l'image sur les 3 cartes JAMMA dont je dispose.
Maintenant, il va falloir trouver un moyen d'introduire un décalage horizontal. Soit avec un PLL, soit avec un autre timer 555. En tout cas, la base est stable et c'est très cool.
![cheers](https://2img.net/i/fa/i/smiles/icon_cheers.png)
Re: [WIP 100%] Normaliser un signal vidéo
Bouz a écrit:J'ai fait un capkit sur une télé, je suis passé par Farnell. Pas de frais de port au-delà d'un prix pas très élevé que j'ai oublié, et composants de qualité. Mais forcément plus cher que les lots douteux à 1€ chinois.
Je n'acheterais pas de condos en vrac sur eBay pour un cap kit!
Intéressant pour Farnell car sur Conrad il y a tjs du port même pour des sommes élevées.
_________________
Sanjuro a écrit:en Special Guest Star, WRC dans le rôle de theWave
ancien directeur du service de renseignements NGS, il a le bras long comme un anaconda sous stéroïdes, si un gros bonnet doit se coucher, c'est qu'il en a donné l'ordre.
theWave- Pièce unique
- Messages : 10143
Date d'inscription : 25/10/2015
Page 1 sur 8 • 1, 2, 3, 4, 5, 6, 7, 8
![-](https://2img.net/i/empty.gif)
» Pas de signal vidéo et audio sur Neo geo CD
» [CFC] VIDEO VOL.14
» [CFC] VIDEO VOL.16
» Le jeu vidéo est-il un art ?
» [CFC] VIDEO VOL.9
» [CFC] VIDEO VOL.14
» [CFC] VIDEO VOL.16
» Le jeu vidéo est-il un art ?
» [CFC] VIDEO VOL.9
Page 1 sur 8
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum