Necstasy

Et ?

Bah tu lui avais reinjecté les signaux à part non ? Ou tu avais refait une fusion des deux via une porte XOR ?

Car en cas de besoin de synchro séparées c'est pas tout à fait le même soucis.
Mon.moniteur je peux pas lui envoyer les synchros en deux morceaux.

Ton problème me fait penser à ça, si ça peut aider.

C'est exactement ça ! Faut que j'arrive à lire le truc pour savoir si ils ont trouvé une solution (je ne suis pas à ce point à l'aise avec l'anglais). Sinon je peux au moins leur filer ma solution pour la n64.

oui j'avais les sync séparés (qui du coup sont correctes) et le lien met bien en évidence le problème de sync non conventionnelle de la PCE.
Mon scaler m'a ensuite permis d'utiliser le composite comme synchro, la solution serait peut-être de modifier la Csync sur l'expansion port.

ben c'est ce que j'ai fait.


en rouge c'est le signal corrigé par mon montage et en violet celui d'origine.

j'ai même une version plus économique qui fait des impulsions moins "nettes" mais néanmoins correctement interprétées par le moniteur.
ça me peremet de jouer à la n64 sans aucune problème déjà !
mais ça ne corrige pas une vague sur la pc engine qu'on peut voir ici:

https://youtu.be/A-iab4ANM-Q

ce qui est rassurant c'est que tout le monde de son côté arrive à la même conclusion concernant le problème.

mais chacun y est allé de sa méthode pour trouver une solution...

bon sur l'excellent topic précité, même si ils n'utilisent pas de projo mais bien des moniteurs ikeagmi comme moi, du peu que j'en comprends il semble qu'ils privilégient eux aussi les syncros internes de la console plutôt que le c22 du port !

alors histoire de pas lâcher l'affaire, je vais sortir l'analyseur logique et comparer les signaux voir si une différence est visible !

deubeul a écrit : ↑lun. 13 nov. 2017 17:28 Ton problème me fait penser à ça, si ça peut aider.

j'ai vu aussi que toi t'avais solutionné ton problème avec un extron.

il me semblait que ce machin était pour de la répartition de signal VGA.

tu t'es démerdé comment niveau connectique ?

[Edit : pas de multiples posts d'affilée, merci d'éditer à l'avenir tes messages. Et une présentation ne serait pas superflue.]

mimix a écrit : ↑lun. 13 nov. 2017 21:02 ben c'est ce que j'ai fait.

en rouge c'est le signal corrigé par mon montage et en violet celui d'origine.
j'ai même une version plus économique qui fait des impulsions moins "nettes" mais néanmoins correctement interprétées par le moniteur.

Et c'est quoi ton montage ?

désolé j'ai pas encore fait de schéma, pour le moment c'est que sur ma plaque de test

j'ai fait deux montages, un économique qui consiste à:

prendre le composite, le passer dans un lm1881 qui resort une C SYNC.
ce CSYNC part vers une porte OU.
le teensy prend le C SYNC sur une entrée et une de ses sorties part sur l'autre entrée de la porte OU.

la sortie du OU va vers le moniteur.

et j'ai mis un programme qui en interrupt choppe une impulsion bas, crée un timing et balance un créneau à chaque fois.

ce créneau est donc généré constament, mais le timing fait qu'il tombe toujours sur des créneaux dejà Hauts du CSYNC quand il n'a pas lieu d'être là, et quand on a besoin de lui bah le C SYNC est à l'état bas, donc il le remplace et hop ça marche.

le seul problème c'est qu'on ne peut avoir une précision ultime du teensy à n'importe quel endroit du signal avec ce montage car l'interrupt se reproduit très rapidement et il faut absolument un timing et donc un créneau qui se termine juste avant la prochaine interruption.


du coup j'ai testé un deuxième montage:

un arduino uno qui en interrupt analyse le signal d'entrée C SYNC provenant du LM1881, et quand il détecte que l'impulsion est à l'état bas depuis un bon moment, il crée une impulsion "trigger" envoyée en teensy.
le teensy en interrupt lui se charge de gérer un créneau où on veut, et le C SYNC qui renre dans la porte OU est soumis à validation par une sortie du teensy. ainsi on peu "effacer" le C SYNC n'importe où et générer un train d'impulsion excatement où on veut en lieu et place du signal d'origine, car on a un seul interrupt par cycle de trame et non par synchro de ligne !

seulement il y a deux limitations:

l'arduino ne permet que de temporiser environ à la micro seconde, et uniquement via le teensy ultra rapide. donc impossible de recréer un signal de sync de toute pièce (j'ai essayé)

de temps en temps j'ai un petit saut d'image sur la pc engine. un saut très certainement à cause d'un parasite ayant fait foirer ma détection via l'arduino uno pour le trigger de la 1/2 trame en cours. Ou un soucis de réactivité de celui-ci.
Une optimisation du programme pourrait améliorer le schmilblik.

cette solution a l'avantage de pouvoir confier au uno une détection 50/60Hz via l'analyse des longueurs d'impulsions, et donc déclencher sur le teensy deux programmes différents adaptés aux timings de la zone en question.


voilà, j'espère que j'ai été assez clair.

je ferais un schéma clair une fois le problème sur pc engine solutionné, histoire de voir si je peux faire une solution commune.

Si tu veux solutionner, amha, ta solution doit être uniquement hardware. je pense que recombiner les H&V individuel avec de la logique doit pouvoir donner quelque chose

Je test ça ce soir . J'ai juste unenporte xor a récupérer au taf pour tester, les fils sont déjà soudés sur le cpu.

bon, ça ne change rien, c'est même pire, le signal est complètement foireux.

je fais de tête mais comme il y a un petit décalage entre H et V, est-ce qu'un ou de Hsync avec Vsync suivi d'un & de cette sortie avec l'inverse de Vsync ne marcherais pas ?

(Hsync or Vsync) & /Vsync

Bah moi je pensais plus à mettre un montage RC en entrée de Hsync pour le décaler vers la droite. Car si on ne le retarde pas, on va avoir des longueurs d'impulsions incorrectes.

Et dans tous les cas il manque ce foutu créneau en fin de Vsync.

Ou alors je décale mais pour obtenir le créneau.

Après je peux tester les 3 méthodes. Le problème c'est que ces signaux sont synchro sur la vidéo et que si c'est pas en face d'origine, bah c'est déjà une sacrée connerie et qu'on risque de ne pas avoir les infos de couleurs au bon moment.

il doit bien y avoir moyen d'y arriver vu que ça marche sur une tv.
edit: c'est pas tant les longueurs que les fronts qui semblent importants.

Oui on est d'accord que c'est les fronts qui importent. (Dans la mesure du raisonnable côté variation des longueurs de pulses) Mais "effacer" les petites pulses en trop revient à décaler les fronts... et que ces deux fronts ce qui est je pense source de problème car on casse la régularité du signal, sans doute source de la fameuse vague.

Bref je vais tester diverses voies, doit bien y avoir une solution !