Re: problème de synchro sur moniteur Ikegami HTM 1990R

[Giants]

Lewolfeur : A voila les infos que je voulais avoir dans un doc, merci m'sieur.

J'osais pas le dire mais j'avoue aussi ne pas comprendre l’engouement que beaucoup on a utiliser ce genre de moniteur, c'est une évidence que ce n'est pas du tout prévue pour.
Alors Ok, les couleurs sont nickel etc, mais au final, on a ce genre de soucis (thread actuel) car on est 'hors marge' de ce que le moniteur attends.

Alors qu'avec une TV Crt avec un bon tube, on aurait pas ces problemes :)

mimix : Yep, tiens nous au courant.
Moi pour investigué plus dessus il faudrait que j'ai le probleme à la maison avec une console à soucis et un moniteur a soucis, choses que j'ai pas.

La tu as toutes les infos, maintenant, faut creuser :)

[mimix]

bah justement quand j'aurais solutionné ce soucis, l'intérêt d'un pvm fera l'objet d'une vidéo sur ma chaine youtube...

[Giants]

clair!

[mimix]

Voici les signaux de début de trame capturés à l'analyseur logique ! (remis en forme pour faciliter la comparaison, et j'ai rajouté les temps des impulsions à coté.



Voilà, le problème est clairement identifié je pense. maintenant je vais voir si un simple ATMEGA328 à 16Mhz sera assez rapide pour compter les impulsions et recréer le petit créneau qui manque.

pour rappel, la snes est la seule qui marche sur les 3

[Lewolfeur]

t'utilise quoi comme analyseur logique ?
j'imagine que pour la aes cela doit être pareil.

[mimix]

open bench logic snifer, un truc basique qui date un peu mais qui me suffit.
oui je pense que c'est le même problème. les temporisations de synchro sont censées être un standard.

et là on voit bien qu'il est pas respecté. mais j'ai le montage électronique pour corriger ça sur le feu...

[Giants]

Voila !
Là c'est clair.
Tu voies comme dis plus haut.
L'oscilo c'est bien mais quand il date un peu et qu'il n'est pas à mémoire, tu ne voie finalement pas grand chose.
Maintenant ils en font des pas 'trop chère' en carte pour PC (via connectique USB).
Ou comme tu as, à coté, un analyseur logique vue que, ça coute cassement rien sur ebay :)

Bien, bien, je suis content ça avance vite :)
Je suis curieux, tu prévoies quoi comme montage pour corriger le signal ? à part en re-créer un nickel from scratch, je voie pas...

[Lewolfeur]

t'a un lien pour que j'en achète un pas trop cher (moins de 100€) si un analyseur logique suffit ?

Je me demande aussi ce que tu vas faire pour corriger le signal.

[Giants]

Tu en trouves plein sur ebay mais attention.
Acheté un analyseur logique ne te servira à rien si :
- Tu n'as pas de bonne base d’électronique.
- Tu ne sais pas t'en servir.

Sans avoir de bonne base, tu ne seras pas interpréter les infos que tu récoltera et encore moins de créer un montage pouvant les corriger si nécessaire.
Sans savoir sans servir, c'est redondant avec la 1er remarque.
C'est un peu comme acheter une voiture de rally mais ne pas savoir piloter, ça ne sert, à rien.

Donc j'aurais tendance à te dire, Monte en compétence en électronique et là du coup tu trouvera l’utilité d'avoir un oscilloscope, un analyseur logique, etc.

[Lewolfeur]

J'avais fait mes années au lycée en électronique donc y'a un petit reste, donc je pars pas de rien. (juste à ressortir les bouquin si besoin ^^)
Mais bon depuis j'ai jamais à nouveau utilisé un oscillo analogique, alors que maintenant c'est du numérique et sans doute bien mieux.

[Giants]

Impec, y'a plus qu'à :)

[mimix]

attention un analyseur logique seul ne te servira à rien si tu sais pas l'utiliser. Et puis tu sais le mien il dormait au placard depuis son achat ou presque. je l'ai acheté "au cas où" un jour

pour mon oscillo, ben il me va très bien, il m'a permis de voir très rapidement le problème, l'analyseur logique m'a permis de voir l'ensemble du signal.
l'avantage de mon oscillo étant tous les modes à la con très pratiques pour de l'analogique périodique. je sais qu'un oscillo numérique sur pc c'est mieux mais un bon coute chère et j'ai pas l'utilité de plus que mon vieux machin qui doit bien avoir 20 ans.

pour le montage c'est tout simple à mon avis: un atmega328 ou un attiny bien programmé (tout dépend de la réactivité du truc), et une porte logique OU.

le signal de synchro rentre dans une entrée OU, et l'arduino dans l'autre.
l'arduino va chronométrer les impulsions de 5V et si supérieure à 5µs, alors arrivé à 59µs il va envoyer un créneau de 5V de 5µs et recommencer à surveiller.

si le signal de synchro était propre ou que l'on est sur un créneau avant celui manquant, aucun soucis, la condition OU fait que quoi qu'il arrive l'impulsion de 5µs est là, mais si la console en question était foireuse alors là l'umpulsion de l'arduino remplace l'absence d'impulsion du signal d'origine, et recompose ainsi un signal normé.

si ça marche, je teste ensuite sur une console en haute résolution comme la ps2 pour voir si les timings sont corrects.

si tout marche, j'en fait un schéma tout propre avec le programme qui va bien dispo en libre service.

et pour ceux qui veulent, je ferais sans doute une petite série d'adaptateurs disponibles sur nicekits.fr (mon site de vente).
ça sera des trucs qualité pro avec plan de masse bien comme il faut, BNC en entrée et en sortie, et alimentation 5V.

Le montage regroupera la puce pour virer le composite et filtrer le signal de synchro et mon correcteur de synchro.

j'utiliserais un atmega328 ou un attiny car c'est une base arduino très facile à mettre à jour si besoin si un jour une nouvelle console pose problème.

mais encore faut-il que ça marche.
j'ai quelques commandes à gérer ce soir et je m'en occupe après.

[Lewolfeur]

J'ai hâte de voir le résultat.

je sais pas si les infos de ce site peuvent t'aider sur la pce qui merde sur un autre moniteur multiformat : http://poorcore.blog.fc2.com/blog-category-8.html
Y'a aussi mike chi qui a trouvé une solution pour les problème de synchro sur les pvm pour son adapter de raspberry pie à 1m3 et 3min . https://youtu.be/zA4Hn9WzFQ4?t=1m3s

[mimix]

je pense pas avoir besoin de plus d'infos que ce qui a déjà été constaté pour l'instant. si ça marche pas, j'éplucherais le truc

[mimix]

bon ça y'est mon montage marche, c'était pas bien long à faire:



en rouge c'est le signal qui sort de mon montage, en violet c'est celui qui sort de la n64 mais filtré quand même sans quoi l'amplitude est à la rue.

il a fallut ajuster comme je m'en doutais certaines tempos dans mon programme simplifié au maximum pour que l'arduino arrive à tenir ces fréquences.

au final on a 58µs au lieu de 59 mais je pense que ça va passer, et les créneaux font bien 5µs.
aucun retard entre l'entrée et la sortie, gage du bon traitement des signaux analogiques associés au machin...

vu l'heure, la suite ça sera demain, et je croise les doigts pour que ça fonctionne.

[Lewolfeur]

Pour d'autre console , je sais pas si t'avais vu ici et quelques post plus bas : https://shmups.system11.org/viewtopic.php?p=1253897#p1253897
Il résume plusieurs pages plus tard :
"Analogue NT mini nes core (little warping in first lines);
Analogue NT mini gamegear, master system and a few others (all messed up).
PC engine (all messed up)
Master System (rotation screen)
3DO (warping in first lines more than usual)
N64 (little warping in first lines)
Genesis (little warping in first lines)
Dreamcast (Toro box - all messed up)"

J'utilise comme lui un gwscart avec le csync et j'ai aussi une petite vague sur ps1/ps2 par exemple.
Pour ma aes c'est identique à ce qu'il a sur sa 3DO.

[mimix]

bon ça avance bien !
déjà, c'était bien ça le problème !

ma n64 affiche enfin une image stable ! et la snes passant à travers le montage affiche toujours son image stable !

sauf que j'ai quelques sauts d'image sur ces deux consoles car imputables au montage. il faut que j'enquête pour savoir ce qui les provoque, quitte à passer sur un microcontrolleur plus rapide pour avoir des timings plus précis.

pour la pc engine par contre ça ne marche pas super... faut dire mes essais de réglage de timing, je les ais fait sur une n64 uniquement, ça se trouve mes réglages ne sont pas tops avec cette console malgré qu'elle ait les même timings.

bref, je suis déjà bien content d'être sur la bonne voie.

edit: la pc engine effectivement c'est bien un soucis de timing, va savoir pourquoi, ils ne sont pas tout à fait aussi synchro que la n64...

[mimix]

Pour d'autre console , je sais pas si t'avais vu ici et quelques post plus bas : https://shmups.system11.org/viewtopic.php?p=1253897#p1253897
Il résume plusieurs pages plus tard :
"Analogue NT mini nes core (little warping in first lines);
Analogue NT mini gamegear, master system and a few others (all messed up).
PC engine (all messed up)
Master System (rotation screen)
3DO (warping in first lines more than usual)
N64 (little warping in first lines)
Genesis (little warping in first lines)
Dreamcast (Toro box - all messed up)"

J'utilise comme lui un gwscart avec le csync et j'ai aussi une petite vague sur ps1/ps2 par exemple.

je vais éviter de m'éparpiller :p déjà quand mes consoles seront ok, je verrais avec d'autres voir si ça marche bien, et la raison éventuelle de ce genre de vague (sans doute un légé retard au démarrage du signal)

[mimix]

voilà le rendu le plus propre que j'arrive à avoir actuellement:






j'arrive aux limites d'un arduino uno... je vois que les temporisations sont trop rapides pour ce qu'il permet, et en dessous d'une valeur, les créneaux de 5µs ne diminuent plus et ça stagne à 6µs.
et coté analyse de signaux d'entrée c'est pareil, je suis obligé de mettre presque rien coté analyse des signaux sans quoi il devient trop lent et n'a plus le temps de rien faire.

les temporisations sont très légèrement différentes entre n64 et pc engine, et je constate une fois la synchro refaite, le phénomène de vagues typique de la pc engine...

moralité:
j'ai deux voies d'améliorations: acheter un arduino plus rapide, mais c'est chiant car les arduino vraiment rapides sont en 3.3V et faut rajouter des composants pour sortir en 5V...

deuxième solution: essayer de travailler avec des composants passifs, mais c'est suuuuuper moins souple. et là question composants il va en falloir quelques uns ! et c'est pas facile à modifier en plus.

donc mon premier essais, ça va être de passer sur un arduino "compatible" plus rapide: un teensy 3.6 qui à ce jour est je pense la carte arduino compatible la plus rapide ! le uno fonctionne à 16Mhz.... le teensy 3.6 à 180 Mhz .
largement de quoi avoir de la réactivité je pense, mais réactivité dans les calculs ne veut pas dire réactivité dans les entrées/sorties ! bref faut tester !
ah oui j'ai un micro controlleur Tiva TM4C1294 de chez Texas instruments sous la main. encore un truc acheté un jour "au cas où", et vu qu'il marche à 120Mhz, si ça marche pas avec le teensy je pourrais toujours tester voir si les entrées sorties de chez TI sont plus réactives.


pour info, voici le code qui donne le meilleur résultat:

Code:

//pour n64
const int  syncin = 2;
const int syncout = 3;

void setup() {
  pinMode(syncin, INPUT);
  pinMode(syncout, OUTPUT);
  digitalWrite(syncout, LOW);
  attachInterrupt(digitalPinToInterrupt(syncin), creneau, FALLING);
}

void loop() {}

void creneau() {
  delayMicroseconds(49); //mettre 48 pour pce
  digitalWrite(syncout, HIGH);
  delayMicroseconds(0);
  digitalWrite(syncout, LOW);
}



ici j'utilise de delay dans un interrupt, ce qui ne se fait pas en temps normal mais comme là ça ne fait que ça, c'est bon ça marche.
la tronche du signal est du coup pas standard avec ce système de génération d'impulsions permanentes, car elles arrivent très légèrement trop tôt par rapport à celles d'origine qui se superposent, mais ça fonctionne car celle qui fait chier le moniteur arrive elle au bon timing.

[Giants]

Tu m'enleves les mots de la bouches.
l'arduino uno de base est trop 'limite' pour faire quelque chose de propre.

Moi je passerais par un composant programmable perso.
Après, il n'y a que l’embarra du choix, bien sur, ce choix est forcément influencé par ce que l'on connait, et le matos qu'on à pour le programmer.

Mais de toute façon, y'a foule à la porte.
Utiliser un arduino uno pour faire ca ou un clone d'arduino uno plus rapide c'est un peu comme utiliser un marteau pour écraser une mouche.

Après... si tu es plus à l'aise sur l'arduino, forcément.

[mimix]

bah je ne connais que ça...
je sais que y'a des trucs différents sans doute plus adapés, comme les altera je pense.
mais je ne les connais pas.

personnellement avec un arduino uno je fais des chiées de trucs ! c'est tout rachitique mais ça force l'optimisation. et au final ça fait des trucs peu chères.

mais là, j'ai pas envie de perdre mon temps. j'ai pris le plus puissant histoire d'avoir de la marge.

en tout cas je suis bien content d'être sur la bonne voie déjà.

la puissance du teensy me permettra peut être aussi de carrément remplacer le signal de synchro de la pc engine pour virer cette foutue vague.

[Giants]

Yep !

Tant que ça coute pas un bras et que ça fonctionne, impec
Perso j'aurais fait aussi comme toi (prendre quelque chose que je connais bien), lui faire ce que je veux qu'il fasse pour corriger le bignou. Optimiser au mieux le bouzin.

Ensuite, SI temps de libre et l'envie, voir si d'autre solution H/W serait plus adapté et monté en compétence dessus.
Mais bon, au vue des prix des cartes arduino and co (a savoir que dalle), il y a plus l'envie de monter en compétence qu'autre chose qui pourrait pousser a aller chercher une autre solution.

Impec tout ça :)
Bein comme dab, tiens nous au jus.
Je suis sur qu'une solution final propre et net (avec tuto) pourrait intéressé pas mal de monde.

[mimix]

Bah le problème c'est surtout le temps. C'est sans arrêt overbooké question emploi du temps. J'aimerais bien apprendre à utiliser les altera mais bon... plus tard peu être.

[mimix]

bon, j'ai reçu mon teensy 3.6, hop montage aussitôt fait !
donc déjà je peux dire que la réactivité d'un teensy 3.6 sur ses sorties est de 0.3µs là où l'arduino uno avec son atmega 328p-pu fait 6µs maximum !

c'est vraiment un autre monde

[Lewolfeur]

c'est clair cela n'a rien à voir . hate de voir la suite, bonne chance.

[mimix]

mission accomplie pour l'image stable à la perfection !

il faut un microcontrôleur par console car les timings sont très légèrement différents et il est trop compliqué de faire un système d'auto détection fiable, enfin en tout cas vu mon niveau en programmation.

en fait le programme au dessus est le plus efficace. il permet d'être certain à 100% d'être synchro avec la console, j'ai juste eut à revoir un peu les timings, et la réactivité du teensy a permis d'affiner les timings pour ne plus avoir de saut d'image.

si on ne fonctionne pas de cette façon minimaliste et que l'on commence à mettre des lignes de traitement du nombre de créneaux, de leur durée etc... bah ça fout la merde, on arrive à des états non cohérents. Ou alors je suis trop une quiche en programmation pour faire un truc efficace

enfin bon là déjà ça MAAAAAAARCHE !

sauf... SAUF !!!!! cette putain de vague sur la pc engine !

je vais essayer de perfectionner mon programme pour résoudre ça mais là par contre c'est pas gagné du tout
Et reste à tester la NeoGeo, mais j'en ais pas en stock, donc si y'a un amis normand dans le coin qui veut bien venir avec la sienne que je trouve les timings  pour corriger cette console...

[lulrik]

Honnêtement, je suis sur le cul ! chapeau !

[Giants]

sauf... SAUF !!!!! cette putain de vague sur la pc engine !
Vidéo please !

[mimix]

voilà un petit résumé de la situation:

[mimix]

On dit que la nuit porte conseil... j'ai eut une idée sur la route du taf !
Si la PCE fait une vague avec un signal de sync normalisé, la logique voudrait qu'on pourrait en déformant le signal de sync, corriger le décalage  (sous réserve que le moniteur s'y retrouve toujours).

Le problème étant surtout que le teensy aussi rapide soit-il ne peut gérer des calculs pour se synchroniser sur les bonnes impulsions du signal d'origine et en même temps gérer les timings très rigoureux de sync...

MAIS ... l'arduino uno en parallèle est assez rapide pour gérer les calculs d'impulsion et juste faire un top pour préparer le teensy à lancer une trame générée à 100% par celui-ci où chaque impulsion de haut en bas de l'écran serait décalable !

Mais tout ça dépend de la faculté du moniteur à gérer de tels décalages et aussi au fait que j'arrive à trouver ce qui différencie trames paires et impaires si un montage unique quel que soit la trame ne corrige pas assez bien la vague.

(Reprend son souffle)

Donc je lache pas l'affaire !

[Giants]

Regarde ça, ca explique super bien le: Analog Video Vertical Sync
Vraiment très très clair, à garder sous le coude cette vidéo.

C'est en anglais, il faut vraiment le regarder, pas besoin d'être bilingue



Il y a aussi ce lien qui est intéressant : http://what-when-how.com/display-interfaces/standards-for-analog-video-part-ii-the-personal-computer-display-interfaces-part-2/

Surtout la Figure 9-8 :

Figure 9-8 “Flagging” distortion in a CRT monitor. The top of the displayed image or raster shows instability and distortion as shown, due to the horizontal deflection circuits losing synchronization during the vertical sync period (when the horizontal sync pulses are missing or incorrect)