forum.system-cfg.com

Nouvel essai :
- L'arrêt sur Read et Write est corrigé. En plus des opérations avec registres 16 bits qui ne marchaient pas, il y avait aussi les PULS-PULU-PSHS-PSHU, seul le dernier octet dépilé ou empilé était testé. Si je n'ai pas fait d'erreur ça devrait marcher maintenant.
Remarquez que la mémoire est lue pour l'acquisition du code opération et des opérandes. Si un point d'arrêt en lecture est activé pour une adresse de l'instruction il arrête le programme. Avant il ne fonctionnait que pour le dernier octet lu par l'instruction, ce dernier octet n'était pas forcément dans l'instruction elle-même.

- Le type de banque "ram sur rom" a été ajouté. Dans ce cas, le numéro de banque est celui de la banque de ram qui recouvre la rom. L'adresse d'arrêt est une adresse dans l'espace rom ($0000-$3FFF pour les TO8, TO8D et TO9+ ou $B000-$EFFF pour les MO6).

Aucun test sérieux n'a été fait, à vous de jouer...

Un grand (é-n-o-r-m-e) merci Daniel, je viens de tester rapidement et ça marche vraiment bien.
On a maintenant un outil de mise au point de compétition !!! bravo !

un premier retour : J'ai vu que tu as également ajouté "Ram sur rom" dans le tableau "Commutation pages mémoire" sur l'autre fenêtre de l'outil de mise au point, mais aucune valeur ne s'affiche dedans (après avoir monté une page de ram dans l'espace cartouche évidement).

Dans la deuxième fenêtre c'est une erreur. J'utilise les mêmes messages que dans la première, mais l'ordre a changé et j'ai oublié de le rétablir. Je vais faire la correction. Dans la foulée j'ajouterai aussi rom sur ram. Le numéro de banque est déjà calculé, il suffit de l'afficher.


[Edit 17:40]
Les erreurs des libellés des numéros de banque de la deuxième fenêtre sont corrigées. D'autres m'ont peut-être échappées, soyez prudents....

Nouvelle remarque :

Quand je positionne un point d'arrêt n°3 :
Après fermeture/réouverture de DCMOTO (redémarrage complet du logiciel) on perd le LSB de l'adresse du point d'arrêt 3 :

Ce bug était subtil, c'est juste une petite faute de frappe que je n'avais pas vue. Après correction j'espère qu'il n'y aura plus d'autre gros problème, j'ai donc mis en ligne la dernière version sur le site dcmoto : http://dcmoto.free.fr/emulateur/dcmoto_20210604.zip

Notez que le type d'arrêt n'est pas sauvegardé après la fermeture de dcmoto. C'est volontaire, pour désactiver automatiquement les points d'arrêt à la prochaine utilisation. Pensez à les réactiver si c'est nécessaire.

Merci à tous pour vos interventions : suggestions, tests, signalements de bugs. Dcmoto progresse surtout grâce à ses utilisateurs

Je viens d'observer un phénomène curieux avec dcmoto_20210615.exe fraichement chargé. Je ne sais pas la procédure minimale pour reproduire, mais voici ce que je viens de faire: J'ai mis un point d'arrêt "Write" en $4254 (sans choisir le type de bank) et je fais "lancer juqu'au point d'arret". Ca ne stoppe pas. Ah ok il faut donc renseigner le type de banque peut être, aussi j'ajoute "Ram video" et laisse la bank 0. Ca ne breakpoint pas non plus. Je passe la bank à 1.. et là ca vient enfin de toucher le point d'arrêt. Après réflexion je me dis que peut-être je n'ai pas eu de chance avec la bank0 qui n'était pas écrite à ce moment là contrairement à ce que je croyais.

Bon toujours est-il que là je veux lancer du pas à pas.. mais hélas le bouton correspondant ne fait rien. Le PC ne bouge pas ! Le compteur cycle reste à 7 (la durée de l'instruction sur laquelle le débuggeur est stoppé). J'ai beau repasser le type point d'arret à <no>, rien ne fait bouger le PC quand on fait "pas à pas". Il est coincé!

En fait, j'ai une petite idée: c'est l'instruction juste avant qui est affichée... et quand je fais "pas à pas" je tombe sur le breakpoint (pourtant désactivé), et le débuggeur affiche la ligne précédente. Il y a bouclage. Je me demande si quelqu'un n'avait pas déjà reporté ce scenario (ici c'est avec des points d'arrêts Write).

De mémoire il m'est déjà arrivé de rester bloqué comme ça, le seul moyen de sortir de cette boucle est de fermer la fenêtre de debug puis de la réouvrir. Par contre je n'ai pas réussi a reproduire le problème depuis.
La piste que tu évoques semble la bonne :
j'avais fait remarquer qu'un arrêt sur Write ou Read s'arrêtait après l'instruction et pas sur l'instruction, du coup on ne voyait pas depuis quelle instruction la lecture/modif avait été effectuée. C'est probablement cette modification qui provoque l'erreur.

Pour le bouton "Pas à Pas", mon "EDIT" du message du 15 juin dans le sujet sur la Trace est peut-être passé inaperçu :

Daniel a écrit : ↑15 juin 2021 17:23 [Edit] La version mise en ligne à 17h20 avait une erreur (boutons ARRETER et PAS à PAS inversés dans la fenêtre de l'outil de mise au point).
Elle a été corrigée à 17h40. Assurez-vous d'avoir la dernière.

Pour les arrêts :
- Avec arrêt sur EXEC l'instruction affichée en premier dans le désassemblage n'a pas été exécutée
- Avec les autres arrêts elle a été exécutée. La nouveauté est que maintenant elle s'affiche (le désassembleur revient en arrière d'une instruction), alors que dans les versions précédentes elle disparaissait (le désassembleur affichait l'instruction suivante).

Une nouvelle version de dcmoto est imminente, avec les modifications dont nous avons discuté pour le fichier trace. J'espère la terminer avant ce soir.

Bonjour,

Un autre problème concernant les points d'arrêt, illustré par une capture : On a deux points d'arrêts :
- un premier en $610F qui se déclenche sur une boucle principale a un intervalle de 25000 - 65000 cycles
- un second en $7255 (point d'entrée d'une routine déclenchée par IRQ) qui se déclenche tous les 20000 cycles

Si j'active le premier, j'ai bien un arrêt sur ce point (tous les 25000 - 65000 cycles)
Si j'active en plus le point d'arrêt dans l'IRQ : j'ai bien un point d'arrêt tous les 20000 cycles mais il n'y a plus d'arrêt sur le premier point d'arrêt.

Le test a été fait sur la version 2021.12.30 et 2021.10.05

C'est surprenant. J'ai parcouru le code de l'outil de mise au point sans trouver d'explication, donc pour l'instant le bug reste ouvert.

Que se passe-t-il si on inverse les deux breakpoints (n°2 et n°3) ?
Est-ce toujours le 3 qui masque le 2, ou est-ce le premier rencontré qui masque l'autre ?

J'ai inversé l'ordre des deux points d'arrêt pour voir mais ça ne change rien.
C'est toujours le point d'arrêt dans l'IRQ qui masque l'autre.

Ci joint le .fd (TO8) pour reproduire le pb.
(Il faut attendre qq secondes que l'anim se charge avant de passer en debug)

Toujours pas trouvé la cause du bug, mais je n'abandonne pas. Patience...

Un indice :
Quand on a juste le point d'arrêt sur la boucle principale on voit qu'on a un changement d'image de l'animation tt les 40000 à 60000 cycles environ (ce qui est le comportement normal).

Quand le point d'arrêt est posé seulement dans l'IRQ, on peut avancer n fois sur ce point d'arrêt (IRQ à 50Hz donc par pas de 20000 cycles) mais l'animation ne change jamais (même en avançant de 200000 cycles) ce qui veut certainement dire qu'on boucle sur l'IRQ, comme si le timer qui déclenche l'IRQ tournait toujours, alors qu'on est arrêté sur le break point.

C'est un bon indice, et c'est la piste vers laquelle je m'orientais. Je n'ai rien trouvé d'anormal dans le traitement des points d'arrêt, on peut donc en déduire que si le programme ne s'arrête pas à l'adresse indiquée il n'y passe pas. Reste à trouver pourquoi.

C'est un problème subtil, mais j'avais déjà eu d'autres indices de ce comportement anormal avec le debugger : un programme plantait en fonctionnement normal et ne plantait plus quand il était exécuté avec le debugger. Je n'ai jamais trouvé pourquoi mais je soupçonnais déjà un rapport avec le déclenchement de l'IRQ.

Je n'ai pas eu beaucoup de temps à consacrer au problème, je vais m'y remettre sérieusement en fin de semaine...

J'ai enfin trouvé le temps de chercher le bug sur les points d'arrêt de l'outil de mise au point. C'est assez subtil :

La lecture des registres du 6846 provoque la mise à jour de bits d'interruption du registre CSR, en fonction des lectures précédentes et de l'ordre dans lequel elles ont été faites. C'est assez compliqué.

CSR0 timer interruption flag reset condition :
1) Timer Reset - Internal Reset Bit TCR0=1 or External Reset=0
2) Any Counter Initialization condition
3) A Write Timer Latches command if Time Interval modes (TCR3=1) are being used.
4) A Read Timer Counter command, provided this is preceded by a Read Composite
Status Register while CSR0 is set. This latter condition prevents missing
an Interrupt Request generated after reading the Status Register and prior
to reading the counter.

En particulier le point 4) nécessite de positionner des flags pour savoir si les registres ont été lus et dans quel ordre.

Dans dcmoto ce fut long à mettre au point, mais maintenant ça fonctionne bien quand le programme s'exécute normalement.
Par contre dans le debugger, les registres du 6846 sont lus par le programme, c'est normal, mais ils sont lus aussi pour l'affichage des registres périphériques, ce qui modifie à tort les flags de l'émulateur et les bits d'interruption du registre CSR. C'est ce qui provoquait une interruption IRQ trop fréquente et empêchait de passer par l'autre point d'arrêt.

Pour corriger je fais maintenant une sauvegarde des flags et du registre CSR avant de lire les registres du 6846 pour les afficher, et après je restaure tout dans l'état précédent. La nouvelle version dcmoto 2022.01.28 est à la page http://dcmoto.free.fr/emulateur/index.html
Lien direct (valable seulement jusqu'à la prochaine version) : http://dcmoto.free.fr/emulateur/dcmoto_20220128.zip