Quoi de neuf ?
FlipperFrance

Quoi! Comment! Pas encore membre d'FF ! Franchissez le pas, incrscrivez vous avec le mail de votre F.A.I (VPN Exclus) et participez à la vie flippéristique

wpc ghosting : le patch

  • Auteur de la discussion Auteur de la discussion mkael
  • Date de début Date de début

mkael

Membres
Membre FF
Je précise, je n’ai rien invente je ne suis qu’un utilisateur.
Le ghosting/flicker apparait quand une nouvelle LED est allumée alors que la précédente n'est pas tout à fait éteinte.
Le "ghosting" est devenu un problème avec l'arrivée des LED dans nos flippers, l'effet est plus prononce avec les LEDs car celle-ci sont plus "rapides" que les ampoules incandescentes.
La cause prédominante du ghosting viendrait de l'interaction du soft de contrôle de la matrice avec l'ASIC.

Bon l'explication de John Honeycutt :
extrait du driver :

CLR WPC_LAMP_ROW #Eteint toutes les rangées
STAA WPC_LAMP_COLUMN # passe `a la colonne suivante
STAB WPC_LAMP_ROW # allume la rangée correspondante

Le problème vient de l'instruction CLR (voir la data sheet du 6809) : le CLR fait une lecture avant d'écrire 0 et l'ASIC ne fait pas la différence entre une lecture et une écriture, ce qui peut produire un "allumage" intempestif (ce qui au passage produit un bon pique de courant) juste avant l'extinction de l'ampoule (colonne/rangée).

L'idée est de remplacer le CLR par une écriture de 0 :
CLRB
STAB WPC_LAMP_COLUMN
STAB WPC_LAMP_ROW

Normalement depuis 95 williams a modifié le contrôle de la matrice de lampes.
En 2010 John Honeycutt a écrit un patch qui repaire le driver de matrice, vérifie qu'il n'y a plus de CLR et dans le cas contraire propose, une modification du code avec update du checksum bien sûr.
Pour ceux qui veulent en savoir plus (et vérifier que je n’ai pas dit trop de bêtises) si ça ne viole pas la charte du forum, je peux mettre le lien d’où je sors ce petit résumé.
Je l’ai donc essaye sur LX-7 du STTNG et ça marche plutôt bien.
 
Tu as fait une traduction par Google ?

Car j'ai du mal à piger les dernières phrases

Normalement depuis 95 williams a modifié le contrôle de la matrice de lampes.
En 2010 John Honeycutt a écrit un patch qui repaire le driver de matrice, vérifie qu'il n'y a plus de CLR et dans le cas contraire propose, une modification du code avec update du checksum bien sûr.

Surtout que sur les WPC et WPC-S et ou WPC95 jamais il n'était prévu de DEL ..
 
Heu non pas google traduction ... Ce que je voulais dire c'est que le patch trouve l'adresse ou se trouve la partie driver de matrice dans la ROM d'origine, puis verifie s'il y a des CLR addr et les modifie si demande.
Oui ils n'etaient pas fait pour des LEDs, mais le probleme existe aussi avec les ampoules incandescentes juste il n'est pas visible car le temps d'allumage est suffisament court, par contre avec des LEDs basiques ca se voit et ca genere un pic de courant
 
Ah c'est un soft qui modifie toutes les mémoires WPC ?
 
Oui, c'est bien ca il y a quelques options, comme corriger le checksum (Utile par exemple si on a modifie le .HEX `a la main)
 
Aller j'essaie d'expliquer un peu mieux, parce que je trouve ce patch vraiment tres interessant :

CLR WPC_LAMP_ROW #Eteint toutes les rangées (row) : 00000000 (un 0 par rangee) dans l'adresse WPC_LAMP_ROW veut dire eteint alors que 11111111 veut dire rangees allumees, 10101010 une rangee sur 2 etc...
STAA WPC_LAMP_COLUMN # passe `a la colonne suivante
STAB WPC_LAMP_ROW # allume la ou les rangée(s) correspondante(s) (en fonction du nombre de 1 dans le registre B)

Le problème vient de l'instruction CLR (clear) (voir la data sheet du 6809) : l'instruction CLR WPC_LAMP_ROW doit "effacer" l'adresse WPC_LAMP_ROW (soit mettre 0 `a l'adresse WPC_LAMP_ROW) pour ce faire CLR excute une lecture (read) de l'adresse suivie du ecriture (write) (0) `a cette meme adresse :
La lecture de l'adresse WPC_LAMP_ROW (qui n'a pas d'utiliter dans ce cas) renvoie "11111111" (tout `a 1), L' ASIC ne faisant pas la difference entre lecture et ecriture , interprete cette lecture (11111111) comme un ordre d'allumage de toutes les rangees aussitot suivi du de l'ecriture des 0 qui eteint toutes les rangees.
Donc l'instruction CLR va allumer toutes les rangees un tres court instant avant de les eteindre effectivement .

La correction proposee est d'utiliser, `a la place du CLR, CLRB (efface le registre B) + STAB WPC_LAMP_ROW (stocke B dans l'adresse WPC_LAMP_ROW) on remarque qu'il n'y a plus de lecture.
 
Ah Clear n'est pas un effacement alors
C'est une écriture de 000000 comme les PIAS avant sur les sys11 pour éteindre donc rendre les transistors bloqué
En tous cas confond pas CLEAR et RESET du processeur
Pas tout a fait pareil
 
Donc l'instruction CLR va allumer toutes les rangees un tres court instant avant de les eteindre effectivement .

La correction proposee est d'utiliser, `a la place du CLR, CLRB (efface le registre B) + STAB WPC_LAMP_ROW (stocke B dans l'adresse WPC_LAMP_ROW) on remarque qu'il n'y a plus de lecture.

Je m'étais posé la question de ce qu'il y avait dans l'Asic
Si c'est ce que tu dis, en fait il ont fait comme les PIA (Registre deux accus on a dire) et ils ont monté la vitesse pour lancer cela sur les bascule D qui font office de mémoire ....
Poru cela le "0" et "1" forcé dont tu parles
 
Retour
Haut Bas