DCMOTO améliorations
Modérateurs : Papy.G, fneck, Carl
DCMOTO améliorations
Bonjour,
Serait-il possible d'ajouter un quatrième mode dans le désassembleur de DCMOTO ? (touche F9).
Il y a les modes normal, pas-à-pas, saut de ligne.
serait il possible d'ajouter un mode "plage pas-à-pas" avec deux cases à remplir :
adresse de début et adresse de fin.
Dans ce mode si on choisit : $8000 plage de début, $9000 plage de fin, le désassemblage ne se produit en pas à pas que dans la plage indiquée, on ne voit pas les sauts ailleurs (mais ils se produisent quand même).
Cela permettrait d'analyser un programme sans avoir les sauts vers le moniteur ou vers la cartouche basic par exemple.
Serait-il possible d'ajouter un quatrième mode dans le désassembleur de DCMOTO ? (touche F9).
Il y a les modes normal, pas-à-pas, saut de ligne.
serait il possible d'ajouter un mode "plage pas-à-pas" avec deux cases à remplir :
adresse de début et adresse de fin.
Dans ce mode si on choisit : $8000 plage de début, $9000 plage de fin, le désassemblage ne se produit en pas à pas que dans la plage indiquée, on ne voit pas les sauts ailleurs (mais ils se produisent quand même).
Cela permettrait d'analyser un programme sans avoir les sauts vers le moniteur ou vers la cartouche basic par exemple.
-
- Messages : 7986
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: DCMOTO améliorations
C'est une sorte de notion de point d'arret sur une "zone" ? (sitôt qu'on tombe dans la zone on bascule dans le debuggeur en quelque sorte)
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: DCMOTO améliorations
Non il faudrait déjà être dans le débugger pour activer cette option.
Je ne sais pas trop comment l'expliquer autrement.
exemple :
ORG $8000
LDX #$000
LOOP LDB #$41
JSR $E803
LEAX 1,X
CMPX #200
BNE LOOP
RTS
END
Zone début : $8000
Zone fin : adresse de END
Si j'active cette option, le débugger affiche le code qui commence en $8000 et qui boucle en LOOP mais n'affiche jamais ce qui se passe en $E803. On affiche en pas à pas ce qui se troue dans le zone début-fin mais pas ce qui se trouve à l'extérieur comme en $E803.
Ca permet d'analyser un programme assembleur sans se perdre dans toutes les routines du moniteur.
Je ne sais pas trop comment l'expliquer autrement.
exemple :
ORG $8000
LDX #$000
LOOP LDB #$41
JSR $E803
LEAX 1,X
CMPX #200
BNE LOOP
RTS
END
Zone début : $8000
Zone fin : adresse de END
Si j'active cette option, le débugger affiche le code qui commence en $8000 et qui boucle en LOOP mais n'affiche jamais ce qui se passe en $E803. On affiche en pas à pas ce qui se troue dans le zone début-fin mais pas ce qui se trouve à l'extérieur comme en $E803.
Ca permet d'analyser un programme assembleur sans se perdre dans toutes les routines du moniteur.
Re: DCMOTO améliorations
L'option "ligne" du debugger permet de faire la même chose. Avec cette option les sous-programmes (JSR, BSR et LBSR) sont exécutés sans interruption. C'est exactement comme une exécution normale avec un point d'arrêt à la ligne suivante.
Pour les MO, les SWI avec un octet de paramètre sont analogues à un appel de sous-programme, mais dans ce cas l'option "ligne" ne fonctionne pas. Depuis longtemps j'ai le projet de modifier le debugger pour prendre en compte cette particularité, mais je n'ai pas encore trouvé le temps.
Pour les MO, les SWI avec un octet de paramètre sont analogues à un appel de sous-programme, mais dans ce cas l'option "ligne" ne fonctionne pas. Depuis longtemps j'ai le projet de modifier le debugger pour prendre en compte cette particularité, mais je n'ai pas encore trouvé le temps.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
Re: DCMOTO améliorations
En fait non l'option ligne ne fonctionne pas comme ce que je proposais. Voici un exemple :L'option "ligne" du debugger permet de faire la même chose. Avec cette option les sous-programmes (JSR, BSR et LBSR) sont exécutés sans interruption. C'est exactement comme une exécution normale avec un point d'arrêt à la ligne suivante.
$8000
C6 50
BD E8 03
7E 80 00
l'option saut ligne reste bloquée sur BD E8 03 (affichage du débuggeur) alors que dans l'émulateur la lettre P s'affiche en boucle.
Dans mon option le debuggeur devrait afficher BD E8 03, afficher la lettre P dans l'émulateur, afficher 7E 80 00, revenir en C6 50 etc...
Alors que là dès BD E8 03 le debuggeur se bloque et rend la main à l'émulateur.
Est-ce que mon explication est assez claire ?
Re: DCMOTO améliorations
Non, ce n'est pas clair.
En cochant l'option "Saut ligne" chaque appui sur le bouton "Exécuter" fait passer à la ligne suivante.
Si la ligne est une instruction simple elle s'exécute, exactement comme en mode "Pas à pas".
Si la ligne est un JSR, BSR ou LBSR toute la routine appelée s'exécute sans interruption et le programme s'arrête à la ligne suivante.
En cochant l'option "Saut ligne" chaque appui sur le bouton "Exécuter" fait passer à la ligne suivante.
Si la ligne est une instruction simple elle s'exécute, exactement comme en mode "Pas à pas".
Si la ligne est un JSR, BSR ou LBSR toute la routine appelée s'exécute sans interruption et le programme s'arrête à la ligne suivante.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
Re: DCMOTO améliorations
Pourtant non chez moi il ne s'arrête pas à la ligne suivante mais au contraire passe en mode Normal et ne reste pas en mode pas à pas.Si la ligne est un JSR, BSR ou LBSR toute la routine appelée s'exécute sans interruption et le programme s'arrête à la ligne suivante.
Test effectué avec DCMOTO 2018.03.17 mode TO9+
Au premier passage sur BD E8 03, le debugger passe en mode Normal et l'écran se remplit de P.
Preuve :
https://www.noelshack.com/2018-23-5-152 ... preuve.jpg
Re: DCMOTO améliorations
Voici une deuxième capture d'écran où le mode pas à pas passe en mode normal dès la première exécution de $E803 :
https://www.noelshack.com/2018-23-5-152 ... reuve2.jpg
https://www.noelshack.com/2018-23-5-152 ... reuve2.jpg
-
- Messages : 7986
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: DCMOTO améliorations
Oui ca me parait logique: la ligne suivante après le JMP n'est jamais atteinte et l'émul reste en mode "normal" sans jamais pouvoir atteindre la ligne souhaitée. Sans doute qu'il faudrait que la notion de ligne prennent en compte les sauts inconditionnels.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: DCMOTO améliorations
Il faudrait refaire les mêmes essais en cochant la case "Exec". Il est possible que le point d'arrêt à la ligne suivante ne soit pas pris en compte si cette case n'est pas cochée. Si c'est le cas, je corrigerai dcmoto pour cocher automatiquement la case "Exec" en mode "Saut ligne".
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
Re: DCMOTO améliorations
Non ce n'est pas ça car on voit bien dans le deuxième exemple où il y a un LEAX 1,X à la suite du JSR $E803, que l'on ne passe jamais au LEAX 1,XOui ca me parait logique: la ligne suivante après le JMP n'est jamais atteinte et l'émul reste en mode "normal" sans jamais pouvoir atteindre la ligne souhaitée
Re: DCMOTO améliorations
Merci beaucoup pour votre réponse c'était bien ça. Si Exec est cochée en même temps que Saut de ligne, alors le debuggeur fonctionne comme attendu (même s'il y a une autre adresse qui n'a rien à voir dans la case à côté de Exec).Il faudrait refaire les mêmes essais en cochant la case "Exec". Il est possible que le point d'arrêt à la ligne suivante ne soit pas pris en compte si cette case n'est pas cochée.
Par contre il y a un fonctionnement perturbant :
On commence le debuggage normal et tout se passe bien :
https://www.noelshack.com/2018-23-6-152 ... image1.jpg
Mais lorsque l'on revient du saut en JSR $E803, les lignes précédentes le JSR $E803 du debuggeur affichent les dernières lignes du moniteur, ce qui est perturbant :
https://www.noelshack.com/2018-23-6-152 ... image2.jpg
Serait-il possible d'avoir un mode où l'on ne voit dans le debuggeur que les lignes qui concernent le programme en cours ? car lorsque l'on étudie le fonctionnement d'un programme on a besoin de voir les lignes précédentes de ce programme juste avant le saut vers le moniteur.
Mon explication est-elle claire ?
Deuxième demande comme tout au début : serait-il possible d'avoir un mode "saut de ligne" dans une plage d'adresses (on entre l'adresse de début et de fin) car lorsque l'on étudie un programme qui va de $8000 à $9000 (par exemple) il peut y avoir des sauts LBRA, JSR etc... a l'intérieur de ce programme.
On peut ne pas voir voir les sauts vers le Basic ou le Moniteur mais voir tous les sauts de $8000 à $9000.
Voici un exemple :
https://www.noelshack.com/2018-23-6-152 ... image3.jpg
Dans le debuggeur en mode "saut de ligne" avec "exec" activé, on ne voit pas ce qui se passe lors du saut en $800A, alors que ce saut fait partie du programme principal.
Re: DCMOTO améliorations
L'affichage des trois dernières instructions avant l'instruction en cours a été ajouté à partir de la version 2017.97.14, à la demande d'un utilisateur. Je suis d'accord, au retour d'un sous-programme en mode "Saut ligne" c'est un peu perturbant. Je vais voir si on peut l'éviter dans ce mode. Et aussi je cocherai automatiquement la case "Exec" quand "Saut ligne" est sélectionné. Il faudra attendre la prochaine version, peut-être pas avant quelques semaines.kripouille a écrit : ↑09 juin 2018 14:48 les lignes précédentes le JSR $E803 du debuggeur affichent les dernières lignes du moniteur, ce qui est perturbant
Sur ce point je suis un peu moins d'accord. Tout d'abord, quel est l'intérêt d'avoir un JSR qui appelle un autre JSR ? On ajoute un grand nombre de cycles inutiles. Ensuite, pour voir le passage en $800A, il suffit d'utiliser l'option "Pas à pas" pour le premier JSR et l'option "Saut ligne" pour le deuxième. On pourrait évidemment automatiser ces manipulations, mais c'est beaucoup de complications pour pas grand chose. Je ne suis pas sûr que l'utilisateur moyen comprendra comment ça marche.kripouille a écrit : ↑09 juin 2018 14:48 Dans le debuggeur en mode "saut de ligne" avec "exec" activé, on ne voit pas ce qui se passe lors du saut en $800A, alors que ce saut fait partie du programme principal.
Il y a un autre point perturbant quand on met au point un programme : les interruptions. Sans aucune instruction de branchement on se retrouve subitement dans le moniteur, et on ne revient au programme principal qu'après le RTI. Une fonction "Exécuter jusqu'au prochain RTI" serait peut-être utile. De même une fonction "Exécuter jusqu'au RTS de la routine en cours" quand on se retrouve dans une routine que l'on ne souhaite pas étudier. Cette dernière fonction pourrait même remplacer l'option "Saut ligne".
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
Re: DCMOTO améliorations
En fait ce n'est pas un JSR qui appelle un autre JSR mais un programme principal en $8500 par exemple qui appelle différents sous-programmes $B200 pour afficher un sprite à l'écran, $C500 pour de la musique etc...Sur ce point je suis un peu moins d'accord. Tout d'abord, quel est l'intérêt d'avoir un JSR qui appelle un autre JSR ? On ajoute un grand nombre de cycles inutiles.
Ainsi les sous-programmes appartiennent au programme principal.
Très bonne remarque, effectivement cela règle le problème., pour voir le passage en $800A, il suffit d'utiliser l'option "Pas à pas" pour le premier JSR et l'option "Saut ligne" pour le deuxième
C'est une très bonne idée pour exécuter jusqu'au prochain RTI et RTS.Il y a un autre point perturbant quand on met au point un programme : les interruptions. Sans aucune instruction de branchement on se retrouve subitement dans le moniteur, et on ne revient au programme principal qu'après le RTI. Une fonction "Exécuter jusqu'au prochain RTI" serait peut-être utile. De même une fonction "Exécuter jusqu'au RTS de la routine en cours" quand on se retrouve dans une routine que l'on ne souhaite pas étudier. Cette dernière fonction pourrait même remplacer l'option "Saut ligne".
Par contre je ne suis pas sûr que cela remplace "saut de ligne".
Si je suis dans une routine du moniteur et que je suis perdu je peux exécuter jusqu'au prochain RTS, le debuggeur stoppe alors à l'instruction RTS.
Je peux alors repasser en mode pas à pas et voir où retourne le moniteur.
Par contre si je suis dans un programme normal
LDB #$50
JSR $E803
LEAX 1,X
que se passerait il avec"exécuter jusqu'au prochain RTS" ? si je m'arrête au RTS de la routine $E803, donc dans le moniteur, alors je perds en fonctionnalités par rapport à "saut de ligne" qui me permet de passer directement en LEAX 1,X
et si exécuter "jusqu'au prochain RTS" me renvoie en LEAX 1,X alors cela veut dire qu'il n'a pas la fonction attendue pour debbuger le moniteur : je suis perdu dans une routine et le prochain breakpoint ne sera pas au RTS de fin de cette routine mais au retour du programme principal, ce qui ne me semble pas la fonction attendue de "exécuter jusqu'au prochain RTS" pour un utilisateur lambda qui analyse une phrase en français.
Re: DCMOTO améliorations
J'en profite avec une autre demande d’amélioration : la commutation de banques en mode debugger pas à pas.
Exemple de code (qui ne fonctionne qu’en mode TO8) :
ORG $8000
LOOP STA >$0000 (commute en bank rom interne 0)
JSR >$0029 (exécute du code en rom interne 0, ce code contient un RTS)
STA >$0001 (commute en bank rom interne 1)
JSR >$00F3 (exécute du code en rom interne 1, ce code contient un RTS)
BRA LOOP
Ce code fonctionne bien en mode pas à pas, en passe d’une banque à l’autre pour exécuter le code.
Par contre on ne peut passer commuter soit même d’une banque à l’autre en mode manuel.
Exemple : dans la fenêtre « Mise au point(2) » je modifie la valeur Rom interne 0 et je clique sur rafraîchir, je vois bien le contenu de la rom interne 0 dans la fenêtre. (avec le code 39 RTS en offset 0x29) :
https://www.noelshack.com/2018-23-7-152 ... image1.jpg
Mais si je passe dans la fenêtre « Mise au point(1) », je mets PC à 0029 et je clique sur « modifier », je ne retrouve pas mon 39 RTS car le debugger a commuté dans la banque rom interne 1 :
https://www.noelshack.com/2018-23-7-152 ... image2.jpg
Serait-il possible d’inclure une fonction pour pouvoir debugger dans une autre ROM manuellement, pour que je puisse dire d’exécuter du code en offset 0x29 en banque rom interne 0 ?
Pareil pour d’autres banques : exemple je passe en banque Ram paginée 15 dans « Mise au point(2) » si je tente d’exécuter du code en $A000 dans mise au point (1) le debugger repasse en banque Ram paginée 2.
Mon explication est assez claire ?
Exemple de code (qui ne fonctionne qu’en mode TO8) :
ORG $8000
LOOP STA >$0000 (commute en bank rom interne 0)
JSR >$0029 (exécute du code en rom interne 0, ce code contient un RTS)
STA >$0001 (commute en bank rom interne 1)
JSR >$00F3 (exécute du code en rom interne 1, ce code contient un RTS)
BRA LOOP
Ce code fonctionne bien en mode pas à pas, en passe d’une banque à l’autre pour exécuter le code.
Par contre on ne peut passer commuter soit même d’une banque à l’autre en mode manuel.
Exemple : dans la fenêtre « Mise au point(2) » je modifie la valeur Rom interne 0 et je clique sur rafraîchir, je vois bien le contenu de la rom interne 0 dans la fenêtre. (avec le code 39 RTS en offset 0x29) :
https://www.noelshack.com/2018-23-7-152 ... image1.jpg
Mais si je passe dans la fenêtre « Mise au point(1) », je mets PC à 0029 et je clique sur « modifier », je ne retrouve pas mon 39 RTS car le debugger a commuté dans la banque rom interne 1 :
https://www.noelshack.com/2018-23-7-152 ... image2.jpg
Serait-il possible d’inclure une fonction pour pouvoir debugger dans une autre ROM manuellement, pour que je puisse dire d’exécuter du code en offset 0x29 en banque rom interne 0 ?
Pareil pour d’autres banques : exemple je passe en banque Ram paginée 15 dans « Mise au point(2) » si je tente d’exécuter du code en $A000 dans mise au point (1) le debugger repasse en banque Ram paginée 2.
Mon explication est assez claire ?