forum.system-cfg.com

Tout d'abord, bonne année à tous les rétros utilisateurs qui lisent ce forum.

Pour cette nouvelle année, je crois bien que j'ai un petit challenge à soumettre aux auteurs d'émulateurs Thomson (dcmoto et téo)
Pour se faire, il va falloir disposer d'assdesass en version To9 dispo ici: http://dcmoto.free.fr/programmes/assdes ... index.html

Cet assembleur fonctionne bien sur To9 et sur To8 (je l'ai déjà utilisé sur un vrai To8 avec la version crackée).

Après l'avoir lancé, il faut rentrer en mode debug en appuyant sur F1. La couleur du crayon passe en bleu ciel.
Ensuite, il faut lancer le débugueur en tapant: P $E803
J'aurai pu mettre n'importe quelle autre adresse, c'est juste pour un exemple concret.

Alors, c'est là que va commencer le challenge...

Sur Assdesass, pour avancer en pas à pas, il suffit juste d'appuyer sur la touche espace. Assdesass exécute les instructions à chaque appuie. Bilan:
- dcmoto fait n'importe quoi et se plante après (pas dcmoto mais la machine émulée)
- téo fait n'importe quoi en sautant à la mauvaise adresse, puis n'importe quoi
- mon émulateur (Tomix) ne change pas d'adresse, donc il fait n'importe quoi
- sur un vrai thomson, assdesass exécute le jmp et saute à la bonne adresse

Bref, il semble qu'Assdesass utilise une astuce dans son mode pas à pas, qui ne passe pas sur TOUS les émulateurs.

Est-ce que au moins un dev est chaud pour comprendre le binz?

Une idée pour faire du pas à pas, y compris en ROM:

• bloquer les IRQs, puis
• mettre le timeout du timer à 1 cycle d'horloge (c'est le mnimum), puis
• prépaprer la pile pour être compatible avec un RTI avec retour sur l'instruction à déboguer, puis
• puis faire RTI.

On saute donc alors à l'instruction à déboguer, le RTI restaurant les IRQs, on va être interrompu par le timer juste après le cycle de fetch. Or comme les instructions sont in-interruptibles sur 6809, la routine IRQ est n'appellée qu'après la fin de l'instruction suivante, ce qui est pile ce qu'on voulait faire: un seul pas juste au dessus d'une seule instruction sans avoir besoin de deviner sa taile pour mettre un SWI juste après (ce que font pas mal d'asembleur/débuggeurs qui n'arrivent pas à faire du pas-à-pas en ROM).

Bref L'interruption timer correctement programmée permet de faire du pas-à-pas partout sans soucis.

Et du coup, ce mode de fonctionnement ne marche pas sur les émulateurs parce que, peut-être, l'émualtion du timer n'est pas assez fines (au cycle près, et utilisation d'un mode spécial style one-shot).

Bonjour

Est-ce que Assdeass marche aussi sur TO9+?
Si oui, je peux voir ce que ca donne sur XEMUL569 (Emulteur de Foolduplex, que j'ai amelioré et que j'utilise pour les dev d'OS9).
Je vais tenter et vous dire ce que ca donne

Jacques

Je vote pour l'hypothèse de Sam, car il n'y a pas d'autre moyen à ma connaissance de faire du pas a pas en ROM sur TO (et d'ailleurs c'est pas possible sur MO, comme par hasard). Le 6846 a toujours posé des tas de problèmes à émuler ...

@__sam__
T'as encore tout compris sam. C'est à peu près comme ça qu'Assdesass procède.
Le soucis, c'était que mon émulateur était censé émuler parfaitement le timer...
Donc, après avoir écrit mon post précédent, j'ai commencé à creuser l'affaire.

Avant d'exécuter l'instruction en debug, Assdesass initialise le registre de contrôle avec la valeur $46, et le décompteur avec la valeur 7, puis il initialise tous les registres du 6809 et il bidouille la pile. Du coup, l'interruption timer est censée arriver juste après tout le bousin. Mais, chez moi, elle arrive un chouille trop tôt. Bref, pas le temps d'exécuter l'instruction.
Chose étrange puisque, comme je le disais, mon timer est censé être géré au tic tac près.

Après analyse et quelques tests empiriques, j'ai maintenant mon émulateur qui fonctionne.

Bon, j'explique ma modif, sachant que mon implémentation n'est sûrement pas identique aux autres émulateurs:
Donc, le décompteur peut s'initialiser en mode normal, ou en mode division par 8. Mon implémentation fait en sorte que, quel que soit le mode, le décompteur est toujours initialisé en mode normal en interne. Bref, quand on met la valeur 7, je la multiplie par 8 avec un simple décalage de 3 bits à gauche.
Assdesass met donc la valeur 7 avec le diviseur. Je partais donc de la valeur 56 en interne.

Et bien, ma conclusion actuelle, c'est qu'il semble qu'il faille multiplier par 8.5 cette valeur et faire un arrondi par excès. Et donc rajouter 4 cycles pour que le truc fonctionne. En gros, valeur_finale=valeur_utilisateur*8+4.
En conséquence, pour la valeur 7, le timer se déclenche maintenant au bout de 60 cycles.
Si je rajoute 3 cycles, c'est pas bon. Si j'en mets 5, c'est pas bon non plus.

J'essaierai d’approfondir un peu plus pour confirmer cette méthode.

@jb_jb_fr
Oui, ça fonctionne.
Mais je sais que sur To8 comme sur To9+, il peut y avoir quelques problèmes à l'utilisation. Cet assdesass est vraiment conçu pour le To9 à la base.

Le 8.5 est vraiment empirique et risque de poser des problèmes sur les périodes plus longues (ca fait un écart de 6%, c'est énorme).

Je pense qu'en fait l'interruption se produit exactement pendant le 1er cycle de l'instruction à débugger (le cycle fetch) et dans le cas de l'émulateur, il y a un truc important avec le timer: le timeout ne se déclenche pas à la valeur 0, mais à la valeur -1. Donc initialisé à 56 cycles, il se déclenchera au 57e cycle en réalité. Ce simple petit cycle en plus sert à exécuter le fetch et donc amorcer l’exécution de l'instruction. Si ton émul déclenche le timer à 0, alors l'interruption arrive juste avant l'instruction au lieu de juste après je pense.

@__sam__
J'ai dit 8.5 pour faire un équivalent dans ce cas précis. C'était une mauvaise comparaison. Comme je l'ai dit ci-avant, je ne multiplie pas par 8.5. Je rajoute juste 1/2 de 8. Donc, 4 cycles.
J'ai dis une connerie sinon: si je rajoute 5 cycles, ça semble fonctionner. Mais si je rajoute 6 cycles ou plus, le debugueur saute des instructions. En revanche, si j'en rajoute moins de 4, le debugueur ne fonctionne plus.

Si je suppose que mon décompteur est faussé et qu'il ne se déclenche pas à -1, et que je lui rajoute un petit coup pour le fun, ça ne marche pas non plus. Mais en vérité, ça fait tellement longtemps que j'ai codé le timer, que je ne sais plus quand il se déclenche.
Mais bon, en gros, je pense que mon émulateur émule bien le décompteur. Il y a juste une petite subtilité dans le mode "divisé par 8".

Note: je viens à l'instant de faire un bref tour de la doc 6846 et il semble que le timeout doit se déclencher à 0, et pas à -1. Tu peux me trouver la source de ton assertion?

Oui c'est dans la doc page 12 du datasheet. Il y a le tableau 4. Avec un compteur initialisé à la valeur N, la periode de l'interruption est de N+1 (le timeout a lieu à t0 + (N+1)µs). Donc avec 56 ca veut dire 57 cycles, comme si l'interrupt se déclenchait sur -1.

@__sam__
Désolé de t'avoir fait chercher sam. Entre temps, j'avais regardé et j'ai pu vérifier que t'avais raison.
J'ai pu vérifier également que mon émulation timer était déjà ok de ce coté là. Donc RAS. Sauf pour les 4 cycles de plus en mode division par 8...
J'aimerai bien savoir comment les autres émulateurs vont s'en sortir pour corriger ce défaut.

Ce serait bien de faire une procédure de test avec tous les cas de figure sur le timer. Donc, avec tous les modes, vérifier les relevés de compteur, contrôler les timeout, etc.

As tu essayé MESS ? Il me semble qu'il émule aussi le TIMER très précisément (puisqu'il génère les fichiers WAV avec lui depuis la ROM non modifiée).

J'ai installé Mame sous Win10. Je lance bien le To9. Mais après, tu fais comment pour sélectionner un disque?

Je ne connais pas les TO (désolé) mais il faut peut être aussi prendre en compte le moment du cycle de l'instruction ou on charge le timer : l'instruction processeur ne s’exécute pas "d'un bloc" et le résultat d"une instruction qui s’écoule sur 4 cycles n'est pas forcément réalisée au 4eme cycle (je 'ai jamais réussi à le savoir ça).

Pour prendre un exemple (avec une syntaxe de Z80, je ne connais pas le 6809)
Un "LD ($1234),A" charge à l'adresse 1234 le contenu du registre A. Cette instruction prend 13 cycles sur le Z80. Mais le chargement de la mémoire se réalise peut être au 11Eme ou 12eme cycle.
Ceci peut peut être expliquer le +2 ou +3 qu'il faut faire en plus du +1 de la fin du timer... ?

@Tomix: Pour MAME je ne sais pas. J'ai mess0136b_i686, et le chargement des disk se fait le menu en haut de la fenetre

@yo_fr
Très bonne remarque mais c'est pas ça.
C'est vrai qu'en comptage de cycle sur tout ce qui est accès mémoire, je ne dois pas être très fidèle à l'original. Il faudrait faire le tour de toutes les instructions (ST, LD, PSH, COM, etc.) pour savoir à quel instant consommer les cycles. Personnellement, j'ai supputé un cycle pour la lecture de l'opcode, puis les cycles sont consommés en fonction du décodage des adresses, etc. Mais j'ai tendance à "bouffer" les cycles avant l'écriture en mémoire, comme pour l'instruction STD $xxxx. Donc, si je consomme après, le décalage est encore pire.

@__sam__
J'ai récupéré ta version de MESS. Malheureusement, il tombe dans les choux également. Il a l'air de se comporter comme Téo.
Donc, pour l'instant, il n'y a que mon Tomix fixé qui fonctionne.

Dans la datasheet 6809 il y a une grosse machine à état s'étendant sur plusieurs pages qui décrit cycle après cycle ce qu'il se passe sur le bus d'adresse pour chaque instruction . Un extrait où l'on voit que l'écriture du résultat 8bits en RAM se fait toujours sur le dernier cycle de l'instruction par exemple: