L'explication se trouve dans le datasheet du 6809(e)
Fichier(s) joint(s):
expliq.gif [ 81.62 Kio | Vu 13405 fois ]
J'ai indiqué le problème en rouge.
On voit que les instructions ASL,ASR,COM,DEC,INC <memoire> etc commencent par un cycle de lecture de mémoire, puis sont suivi par l'opération en interne (avec don't care sur le bus à ce moment là) et terminent par un cycle d'écriture en mémoire. Tout ca pour 6 cycles (2 cycles par étapes).
C'est parfait, mais là où il y a un truc pas cool sur le 6809 est que CLR <memoire> est construit sur le même schéma. Cela signifie qu'il s'exécute lui aussi en 6 cycles, mais pire que cette instruction qui a priori ne fait qu'une simple écriture, effectue systématiquement une lecture en première étape.
Sur de la mémoire classique cela n'a pas d'influence, sauf que c'est plus lent qu'un STB <memoire> qui ne nécessite que 4 cycles.
Mais sur le circuit palette en $E7DA, cela a un effet de bord rigolo: tout accès à ce registre incrémente automatiquement $E7DB. Donc comme CLR effectue 2 accès, il incrémente $E7DB deux fois. Résultat: alors qu'on pense écrire 0 à l'offset "n" positionnant $E7DB à "n+1", on ne touche pas à la valeur à l'offset "n", mais on écrit 0 à l'offset "n+1", laissant $E7DB à la valeur "n+2".
Avec le prog de test, cela produit le motif exposé dans MESS. Je pense que MESS émule correctement le cycle de lecture de l'instruction CLR, ce que ne font ni TEO ni DCMOTO.
Je pense que cette différence entre émulateur et vraie machine se répare facilement en ajoutant un accès en lecture à l'adresse mémoire pour l'émulation de l'instruction CLR.