DCMOTO améliorations

Couvre tous les domaines de l'émulation logicielle ou de la virtualisation ainsi que les discussions sur les divers outils associés.

Modérateurs : Papy.G, fneck, Carl

kripouille

DCMOTO améliorations

Message par kripouille »

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.
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: DCMOTO améliorations

Message par __sam__ »

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
kripouille

Re: DCMOTO améliorations

Message par kripouille »

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.
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: DCMOTO améliorations

Message par Daniel »

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.
Daniel
L'obstacle augmente mon ardeur.
kripouille

Re: DCMOTO améliorations

Message par kripouille »

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.
En fait non l'option ligne ne fonctionne pas comme ce que je proposais. Voici un exemple :

$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 ?
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: DCMOTO améliorations

Message par Daniel »

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.
Daniel
L'obstacle augmente mon ardeur.
kripouille

Re: DCMOTO améliorations

Message par kripouille »

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.
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.

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

Image
kripouille

Re: DCMOTO améliorations

Message par kripouille »

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

Image
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: DCMOTO améliorations

Message par __sam__ »

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
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: DCMOTO améliorations

Message par Daniel »

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.
kripouille

Re: DCMOTO améliorations

Message par kripouille »

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
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,X
kripouille

Re: DCMOTO améliorations

Message par kripouille »

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.
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).

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

Image

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

Image

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

Image

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.
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: DCMOTO améliorations

Message par Daniel »

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
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 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.
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.

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.
kripouille

Re: DCMOTO améliorations

Message par kripouille »

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.
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...

Ainsi les sous-programmes appartiennent au programme principal.
, 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
Très bonne remarque, effectivement cela règle le problème.
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".
C'est une très bonne idée pour exécuter jusqu'au prochain RTI et RTS.

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.
kripouille

Re: DCMOTO améliorations

Message par kripouille »

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

Image

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

Image

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 ?
Répondre