Dans dcmoto j'ai ajouté une lecture mémoire systématique au début de l'instruction CLEAR, mais il ne faut probablement pas la faire dans toutes les formes de l'instruction. Je vais creuser un peu, et la bonne version est pour bientôt...
[Edit]
Curieux :
Dans dcmoto 2015.05.29, le premier EXEC &H9000 donne les couleurs de la copie d'écran du post précédent.
Un deuxième EXEC &H9000 donne les bonnes couleurs.
Oui c'est curieux ca. Qu'est ce qui peut changer entre le 1er et le 2eme appel. Le programme est parfaitement déterministe.
Hum... Ah si un truc peut-être: que se passe-t-il si le 1er STB qui initialise $E7DB à $00 se produit alors que $E7DB valait une valeur impair (parce qu'on pas terminé le cycle de lecture). Est-ce que le read en $E7DA va lire la valeur en $00 (que l'on vient de placer en $E7DB) ou la valeur impair que l'on a écrasée. Bref tout est question de savoir si la valeur qu'on écrit en $E7DB est latchée et utilisée immédiatement ou n'est utilisée qu'à la fin de la lecture du 2eme octet en $E7DA.
Tu n'étais pas loin de la vérité...
En fait c'était une anomalie de dcmoto : la palette était mise à jour à réception du deuxième octet de la couleur dans $E7DA. En réalité elle doit être mise à jour deux fois, à l'envoi du premier octet et à l'envoi du deuxième. Avis aux programmeurs : pour gagner quelques cycles dans vos programmes, vous pouvez modifier un seul octet de la couleur si l'autre ne change pas.
Les deux problèmes (lecture avant le CLR et mise à jour de la palette) sont maintenant corrigés dans dcmoto_nouveau. Deux nouvelles versions dans la même journée, ça me rappelle le début des années 2000, quand il y avait beaucoup de bugs. Heureusement ça commence à ralentir, mais cet épisode montre bien que ce n'est pas fini. Il n'y avait que __sam__ pour trouver une subtilité aussi improbable, je le remercie de sa nouvelle contribution à l'amélioration de l'émulateur. http://dcmoto.free.fr/emulateur/dcmoto_nouveau.zip
dcmoto_20150529b.png (9.74 Kio) Consulté 5515 fois
TEO 1.8.3 était déjà correct (cf message de prehisto sur logicielsmoto)
nous avions travaillé (enfin, surtout prehisto...) au bon découpage par cycle de toutes les instructions il y a 1 ou 2 ans.
la version 1.8.2 binaire windows dispo au téléchargement sur sourceforge donne le même résultat que le premier correctif de dcmoto par contre.
@sam: pense à mettre à jour, idéalement à partir des versions source.
(edit): pour le défaut de mise à jour de la palette il me semble que prehisto a rencontré le problème sur sa demo bloodyrun l'année dernière, le correctif sur la palette doit dater de ce moment là.
gilles a écrit :(edit): pour le défaut de mise à jour de la palette il me semble que prehisto a rencontré le problème sur sa demo bloodyrun l'année dernière, le correctif sur la palette doit dater de ce moment là.
Yep c'est fort probable car dès qu'on veut changer la palette rapidement ou en peu d'instruction on risque de tomber sur ce bug.
Je n'ai pas trouvé la version 1.8.3 de TEO pour Windows à Source Forge. La dernière est la 1.8.2.
Dans les sources, il est écrit 1.8.1. C'est normal ?
Avec un moteur de recherche, on trouve la 1.8.3 pour Mac OS X 10.4 : http://www.macupdate.com/app/mac/15924/teo
Elle date du 27 septembre 2008. Ca semble un peu vieux, non ?
La version des sources publiée (le repository) est la 1.8.3 (win/linux). Les versions mac ont suivi une autre numérotation qui sont propres à R.Bannister mais ce sont des souches 1.7.6 au niveau emulation.
La 1.8.2 corrige de nombreux cas de timing approximatif car tout est géré au cycle et plus a l'instruction. Ceci étant, il n'y a pas énormément de codeur thomson en activité qui a un réel besoin de ce niveau de précision.
Le debugger a egalement été réintroduit pour les versions linux et windows, en tenant compte du changement de mode d'emulation.
gilles a écrit :il n'y a pas énormément de codeur thomson en activité qui a un réel besoin de ce niveau de précision.
J'en connais un, il s'appelle Prehisto. Depuis plusieurs années, j'ai l'impression que TEO est son émulateur personnel. Il le modifie en fonction de ses propres besoins, et ne cherche pas à le diffuser. C'est dommage, car c'est un bon émulateur, supérieur à dcmoto sur beaucoup de points. Mais pas fait pour le grand public. Bon, tant pis pour la version 1.8.3, je ne pourrais pas la tester, mais je vous crois sur parole si vous dites qu'elle fonctionne bien.
Prehisto a beaucoup codé ces aspects là (d'emulation au cycle près) mais c'est un concept dont nous avions beaucoup discuté et pesé avant. Le debugger gtk pour linux est un module perso, son pendant revu pour windows est un dev de prehisto. Donc non teo n'est pas un projet solitaire. La version 1.8.2 diffusée est déja une belle évolution par rapport aux vieillissantes 1.7.6. Le binaire 1.8.3 pour windows se compile nativement sous linux (mais aussi sous windows avec mingw). De plus toute modification de source est reportée dans le mercurial en quelques jours donc on ne peut pas dire que la diffusion soit freinée. Les utilisateurs non développeurs ont accès a 3 versions recentes pour windows linux et msdos.
Moi aussi j'utilise plus TEO pour le développement que DCMOTO. Mais TEO en vieille version 1.7.6 que j'avais modifié pour avoir plein d'options en ligne de commande qui n'ont pas toutes été reprises dans la 1.7.8 et suivantes (comme par exemple la possibilité de voir un dossier windows comme un D7 thomson).
Pour un développeur il est important que l'émulateur puisse se lancer avec toutes les options (MEMO7, K7, D7, vitesse, taille écran, etc) depuis la ligne de commande. C'est un peu le soucis que j'ai avec DCMOTO qui ne permet pas de préciser tout cela facilement dans un makefile.
Du coup j'utilise DCMOTO plutôt pour tester le programme quasi fini mais aussi pour les spécificités qui lui sont exclusives (contrôleur CS-91280), ou encore les machines plus anciennes TO7/MO5 comme par exemple pour le thomcat de la forever 2015.
