Emulation d'Assdesass sur To9 - l'histoire du 6846 clone

[Tomix]

@__sam__
En principe, les IRQ sont désactivées à part le timer.

Sinon j'ai fait chauffer mon To8D. J'ai balancé quelques démos pour voir si ça tournait. RAS.

J'ai refait un test Assdesass dessus avec un P $E803
Toujours le même problème. Le time out se lance trop tôt. Très souvent c'est sur le LDD (voir le source posté avant). Sinon ça peut être sur le PULS. Je trouve ça bizarre que ce ne soit pas stable.

Et l'autre truc bizarre c'est que Daniel arrive à faire correctement fonctionner le debugueur sur un vrai To8 (pas le D). Mais bon, il lance depuis une interface SD... Des fois qu'un truc magique changerait la durée du time out quand un truc non conventionnel est branché... Je dis ça mais c'est sûrement une connerie. Comme je sèche...

[__sam__]

Toujours le même problème. Le time out se lance trop tôt. Très souvent c'est sur le LDD (voir le source posté avant). Sinon ça peut être sur le PULS.

Que ce soit sur le LDD ou le PULS ne change rien. Les interruptions étant bloquées au niveau du CC, l''IRQ ne sera prise en compte qu'après le PULS mettra une valeur à CC qui réautorisera les interruptions.

Je trouve ça bizarre que ce ne soit pas stable.

Je pense à un truc. Si le timer n'est pas mise en pause (de mémoire un truc en rapport au bit 7 du control-register), il me semble qu'il ne lit (latch dans la doc) la valeur en $E7C6-$E7C7 qu'à la fin du décompte courrant. Donc ca pourrait expliquer le fait que le timer fasse un timeout pas toujours au même endroit.

Il y a aussi un truc bizzare entre toi et Daniel: toi tu dois ajouter 4 cycles alors que Daniel doit en ajouter 18. Pourquoi ces valeurs? 4 cycles c'est grosso-modo une instruction, par contre 18 ca fait un paquet d'instructions.

[nicolho]

Je pense à un truc. Si le timer n'est pas mise en pause ... ca pourrait expliquer le fait que le timer fasse un timeout pas toujours au même endroit.

Là est la question... En lisant la doc 6846, il me semble que c'est la mise à zéro de TCR0 (le bit 0 de $E7C5) qui provoque le chargement du total à decompter (récupéré en sortie du "latch", le registre qui stocke le "preset" du compteur et chargé précédemment via les 16 bits à l'adresse $E7C6) avec un démarrage immédiat d'un nouveau décompte.
Il est aussi expliqué ce que tu viens de dire : le contenu du latch est également récupéré à chaque fois que le compteur atteint zéro... donc ça impliquerait que celui-ci soit déjà activé, avec un décompte en cours se terminant.
Par contre, je n'ai pas vu de "mise en pause" du décompte dans la doc, mais plutôt, soit un arrêt, soit une "réinitialisation-démarrage" du compteur, mais tu m'as mis la puce à l'oreille et donné du grain à moudre

Corrigez-moi si je me trompe (pour ça et le reste) : si on doit passer TCR0 à zéro ("Timer Enabled") pour démarrer un nouveau décompte, ça implique qu'on avait précédemment arrêté le compteur (qui passe alors en mode "Timer in Preset State" c'est à dire en phase de "configuration du preset" ou "latch") en mettant TCR0 à 1... à moins qu'on utilise un compteur en boucle, qu'on laisse "tourner" plusieurs fois.

Je n'ai pas été voir ce qui précède dans le programme d'Assdesass, mais dans le code présenté par Tomix, déjà je trouve étrange de démarrer le compteur (avec $46 passé par STB $E7C5, donc ce qui met TCR0 à zéro et déclenche aussi la sortie du latch) AVANT de "remplir" le latch avec le preset souhaité (STD $E7C6) car ce dernier ne sera transmis depuis le latch qu'à la fin du décompte en cours

Et avec cette valeur $46 (soit les bits 0100 0110 envoyés dans le registre de contrôle, voir la documentation), on réactive les interruptions en sortie en même temps qu'on configure un compteur en "mode continu" (c'est dire en boucle).
Mais dans ces conditions, si on arrête jamais le compteur, en se contentant de désinhiber momentanément les interruptions générées en sortie sur /IRQ, difficile de savoir où en est le compteur dans sa boucle et à quel moment exact il déclenchera une interruption...

Donc, au mieux, si le compteur était bien précédemment stoppé (TCR0 à 1, donc je ne parle pas des interruptions avec TCR6), dans le cas du code présenté, cela donne : "oh mon compteur, s'il te plaît, fait un premier décompte avec ton preset actuel, à la fin duquel tu génèreras une interruption, puis tu entameras un nouveau décompte avec le preset que je te mets de côté tout de suite maintenant dans ton registre" .. je vois pas bien l'idée ... ou alors le preset "attente de l'instruction visée" a déjà été mis avant pour ce premier decompte (et à quoi sert le second?) ?

Si c'est normal et que j'ai tout faux, pardonnez-moi et expliquez-nous chers experts, mais ça semblerait quand même plus "carré" en faisant les choses dans l'ordre, avec un compteur "one shot" (décompte unique), réglé pour qu'il génère juste une interruption précisément X cycles après son déclenchement, comme ceci, non ? :
- on stoppe le compteur, en passant en phase "chargment du preset dans le latch" (TCR0 à 1)
- on charge $E7C6/$E7C7 avec la valeur souhaitée
- PUIS enfin on démarre le compteur (TCR0 à 0) pour qu'il génère une unique interruption après le délai souhaité

[__sam__]

Il est aussi expliqué ce que tu viens de dire : le contenu du latch est également récupéré à chaque fois que le compteur atteint zéro... donc ça impliquerait que celui-ci soit déjà activé, avec un décompte en cours se terminant.

Si le curseur clignote alors c'est le cas. Par défaut sur thomson le timer est en mode /8 avec une période de 100ms pour faire clignoter le curseur.

Par contre, je n'ai pas vu de "mise en pause" du décompte dans la doc, mais plutôt, soit un arrêt, soit une "réinitialisation-démarrage" du compteur, mais tu m'as mis la puce à l'oreille et donné du grain à moudre

Oui c'est peut-être arret, je ne sais plus les détails.
[EDIT] remplacé 10ms par 100ms, car c'est bien en 1/10sec que le thomson compte

[Daniel]

4 cycles c'est grosso-modo une instruction, par contre 18 ca fait un paquet d'instructions.

Les compteurs utilisés par nos émulateurs sont multipliés par 8 par rapport au compteur du 6846. Quand j'ajoute 18, c'est en réalité 2,25 cycles du 6809, donc un peu moins que la moyenne d'une instruction.

Dans dcmoto, l'IRQ est déclenchée entre deux instructions, donc pas au cycle près. Au moment où elle est générée le compteur n'est pas toujours exactement à zéro. Si le nombre de cycles de l'instruction ne tombe pas juste le compteur peut être légèrement négatif. Quand le timer est en mode boucle, je compense ce décalage : je ne remplace pas la valeur du compteur par la valeur du latch, mais j'ajoute la valeur du latch.

Il y a encore un autre décalage dans l'émulateur : quand on écrit une valeur dans le latch pour réinitialiser le compteur, le compteur est mis à jour immédiatement, et les cycles de l'instruction d'écriture sont décomptés par le timer. Il ne faudrait probablement pas les décompter, ou au moins pas tous.

Tous ces petits décalages cumulés peuvent expliquer les 2,25 cycles de correction.

[Tomix]

Euh... le 6809 est à 1 mhz, soit 1 million de cycles cpu par seconde. Et le 6846 utilise l'horloge du 6809. Donc les 2 sont parfaitement synchrones.
En mode normal sur le timer, si on met la valeur 1, cela doit correspondre à un cycle cpu. Et en "divisé par 8", c'est censé être 8 cycles pour la valeur 1. Mais on a vu que c'est pas tout à fait ça en réalité.

Bien sûr, il n'y a que Daniel qui puisse savoir, mais j'avais une hypothèse concernant DcMoto et le timer. En fait, je me base sur la disquette des guignols de sam, en émulation To9. Il me semblait que DcMoto ne jouait pas les sons à la bonne vitesse (un peu plus vite de mémoire mais je ne sais plus trop). Du coup, mon hypothèse était que le timeout de l'émulation timer se jouait peut-être trop tôt. D'où l'idée de monter jusqu'à 18 cycles en plus (par rapport à mon émulateur), pour compenser le défaut avec Assdesass.

Sinon, comme l'a relevé nicholo, je trouvais en effet bizarre que le registre de contrôle soit set-é avant remplissage du latch.
Le seul truc qui utilise le timer en dehors de ça, c'est le curseur. Et il fonctionne bien pendant le mode pas à pas. Le décompteur est toujours actif avant la réinitialisation du latch à 7.
Vu le mode utilisé (contrôle avec la valeur $46), une simple écriture dans le latch suffit à relancer le compteur. Ca a également pour effet de réinitialiser le bit d'interruption si celle-ci est en cours (voir page 10 et 11 du datasheet 6846). Du coup, je ne comprends pas l'instabilité relevée sur mon To8D, alors que c'est parfaitement stable sur mon To9.

Pour info, au moment où Assdesass initialise le latch à 7, le décompteur était latché à 12500 et en cours de décomptage (entre 0 et 12500 donc).

Ce fonctionnement reste encore mystérieux pour moi. Il va falloir continuer à chercher et à comprendre.

[EDIT]
Je confirme. Je viens de tester l'ancienne version de DcMoto avec la disquette des guignols de sam, et DcMoto jouait beaucoup trop vite les samples. La nouvelle version corrige la vitesse.
Sur mon émulateur, avant mon fix, la vitesse de lecture semblait normale. En ajoutant 4 cycles, je ne vois pas la différence.

[Tomix]

Pour le fun, voici le code d'assdessass correctement déroulé dans mon émulateur:

Code : Tout sélectionner

7951  2    LDB  #$46    IRQ:$00 FIRQ:$00 RPC:$7951 DP:$61 A:$01 B:$14 X:$e803 Y:$dfff U:$e80a S:$69d6 CC:$c9
7953  5    STB  $e7c5   IRQ:$00 FIRQ:$00 RPC:$7953 DP:$61 A:$01 B:$46 X:$e803 Y:$dfff U:$e80a S:$69d6 CC:$c1
7956  3    LDD  #$0007  IRQ:$00 FIRQ:$00 RPC:$7956 DP:$61 A:$01 B:$46 X:$e803 Y:$dfff U:$e80a S:$69d6 CC:$c1
7959  6    STD  $e7c6   IRQ:$00 FIRQ:$00 RPC:$7959 DP:$61 A:$00 B:$07 X:$e803 Y:$dfff U:$e80a S:$69d6 CC:$c1
795c  4    JMP  $7cf7   IRQ:$00 FIRQ:$00 RPC:$795c DP:$61 A:$00 B:$07 X:$e803 Y:$dfff U:$e80a S:$69d6 CC:$c1
7cf7  5    LDX  <$89    IRQ:$00 FIRQ:$00 RPC:$7cf7 DP:$61 A:$00 B:$07 X:$e803 Y:$dfff U:$e80a S:$69d6 CC:$c1
7cf9  4    LDA  <$87    IRQ:$00 FIRQ:$00 RPC:$7cf9 DP:$61 A:$00 B:$07 X:$e803 Y:$dfff U:$e80a S:$69d6 CC:$c9
7cfb  6    LDS  <$81    IRQ:$00 FIRQ:$00 RPC:$7cfb DP:$61 A:$00 B:$07 X:$e803 Y:$dfff U:$e80a S:$69d6 CC:$c5
7cfe  8    PSHS X,A     IRQ:$00 FIRQ:$00 RPC:$7cfe DP:$61 A:$00 B:$07 X:$e803 Y:$dfff U:$e80a S:$dfff CC:$c9
7d00  5    LDU  <$83    IRQ:$00 FIRQ:$00 RPC:$7d00 DP:$61 A:$00 B:$07 X:$e803 Y:$dfff U:$e80a S:$dffc CC:$c9
7d02  6    LDY  <$7f    IRQ:$00 FIRQ:$00 RPC:$7d02 DP:$61 A:$00 B:$07 X:$e803 Y:$dfff U:$0000 S:$dffc CC:$c5
7d05  5    LDX  <$7d    IRQ:$00 FIRQ:$00 RPC:$7d05 DP:$61 A:$00 B:$07 X:$e803 Y:$0000 U:$0000 S:$dffc CC:$c5
7d07  4    LDA  <$88    IRQ:$00 FIRQ:$00 RPC:$7d07 DP:$61 A:$00 B:$07 X:$0000 Y:$0000 U:$0000 S:$dffc CC:$c5
7d09  6    TFR  A,DP    IRQ:$00 FIRQ:$00 RPC:$7d09 DP:$61 A:$00 B:$07 X:$0000 Y:$0000 U:$0000 S:$dffc CC:$c5
7d0b  6    LDD  $6185   IRQ:$00 FIRQ:$00 RPC:$7d0b DP:$00 A:$00 B:$07 X:$0000 Y:$0000 U:$0000 S:$dffc CC:$c5
7d0e  8    PULS CC,PC   IRQ:$00 FIRQ:$00 RPC:$7d0e DP:$00 A:$00 B:$00 X:$0000 Y:$0000 U:$0000 S:$dffc CC:$c5
e803  4    JMP  $ecff   IRQ:$00 FIRQ:$00 RPC:$e803 DP:$00 A:$00 B:$00 X:$0000 Y:$0000 U:$0000 S:$dfff CC:$00
fc14  5    LDA  $e7c0   IRQ:$01 FIRQ:$00 RPC:$fc14 DP:$00 A:$00 B:$00 X:$0000 Y:$0000 U:$0000 S:$dff3 CC:$90
fc17  3    BMI  $fc24   IRQ:$01 FIRQ:$00 RPC:$fc17 DP:$00 A:$81 B:$00 X:$0000 Y:$0000 U:$0000 S:$dff3 CC:$98
fc24  2    LSRA         IRQ:$01 FIRQ:$00 RPC:$fc24 DP:$00 A:$81 B:$00 X:$0000 Y:$0000 U:$0000 S:$dff3 CC:$98
fc25  3    BCS  $fc28   IRQ:$01 FIRQ:$00 RPC:$fc25 DP:$00 A:$40 B:$00 X:$0000 Y:$0000 U:$0000 S:$dff3 CC:$91
fc28  5    LDA  $6019   IRQ:$01 FIRQ:$00 RPC:$fc28 DP:$00 A:$40 B:$00 X:$0000 Y:$0000 U:$0000 S:$dff3 CC:$91
fc2b  2    BITA #$20    IRQ:$01 FIRQ:$00 RPC:$fc2b DP:$00 A:$20 B:$00 X:$0000 Y:$0000 U:$0000 S:$dff3 CC:$91
fc2d  3    BEQ  $fc33   IRQ:$01 FIRQ:$00 RPC:$fc2d DP:$00 A:$20 B:$00 X:$0000 Y:$0000 U:$0000 S:$dff3 CC:$91
fc2f  8    JMP  ($6027) IRQ:$01 FIRQ:$00 RPC:$fc2f DP:$00 A:$20 B:$00 X:$0000 Y:$0000 U:$0000 S:$dff3 CC:$91
795f  3    LDX  #$78f8  IRQ:$01 FIRQ:$00 RPC:$795f DP:$00 A:$20 B:$00 X:$0000 Y:$0000 U:$0000 S:$dff3 CC:$91
7962  7    TST  $6136   IRQ:$01 FIRQ:$00 RPC:$7962 DP:$00 A:$20 B:$00 X:$78f8 Y:$0000 U:$0000 S:$dff3 CC:$91
7965  5(6) LBNE $797c   IRQ:$01 FIRQ:$00 RPC:$7965 DP:$00 A:$20 B:$00 X:$78f8 Y:$0000 U:$0000 S:$dff3 CC:$91
797c  6    PULS A       IRQ:$01 FIRQ:$00 RPC:$797c DP:$00 A:$20 B:$00 X:$78f8 Y:$0000 U:$0000 S:$dff3 CC:$91
797e  5    STA  $6187   IRQ:$01 FIRQ:$00 RPC:$797e DP:$00 A:$80 B:$00 X:$78f8 Y:$0000 U:$0000 S:$dff4 CC:$91
7981  7    PULS A,B     IRQ:$01 FIRQ:$00 RPC:$7981 DP:$00 A:$80 B:$00 X:$78f8 Y:$0000 U:$0000 S:$dff4 CC:$99
7983  6    STD  $6185   IRQ:$01 FIRQ:$00 RPC:$7983 DP:$00 A:$00 B:$00 X:$78f8 Y:$0000 U:$0000 S:$dff6 CC:$99
7986  6    PULS A       IRQ:$01 FIRQ:$00 RPC:$7986 DP:$00 A:$00 B:$00 X:$78f8 Y:$0000 U:$0000 S:$dff6 CC:$95
7988  5    STA  $6188   IRQ:$01 FIRQ:$00 RPC:$7988 DP:$00 A:$00 B:$00 X:$78f8 Y:$0000 U:$0000 S:$dff7 CC:$95
798b  7    PULS A,B     IRQ:$01 FIRQ:$00 RPC:$798b DP:$00 A:$00 B:$00 X:$78f8 Y:$0000 U:$0000 S:$dff7 CC:$95
798d  6    STD  $617d   IRQ:$01 FIRQ:$00 RPC:$798d DP:$00 A:$00 B:$00 X:$78f8 Y:$0000 U:$0000 S:$dff9 CC:$95
7990  7    PULS A,B     IRQ:$01 FIRQ:$00 RPC:$7990 DP:$00 A:$00 B:$00 X:$78f8 Y:$0000 U:$0000 S:$dff9 CC:$95
7992  6    STD  $617f   IRQ:$01 FIRQ:$00 RPC:$7992 DP:$00 A:$00 B:$00 X:$78f8 Y:$0000 U:$0000 S:$dffb CC:$95
7995  7    PULS A,B     IRQ:$01 FIRQ:$00 RPC:$7995 DP:$00 A:$00 B:$00 X:$78f8 Y:$0000 U:$0000 S:$dffb CC:$95
7997  6    STD  $6183   IRQ:$01 FIRQ:$00 RPC:$7997 DP:$00 A:$00 B:$00 X:$78f8 Y:$0000 U:$0000 S:$dffd CC:$95
799a  7    PULS A,B     IRQ:$01 FIRQ:$00 RPC:$799a DP:$00 A:$00 B:$00 X:$78f8 Y:$0000 U:$0000 S:$dffd CC:$95
799c  6    STD  $6189   IRQ:$01 FIRQ:$00 RPC:$799c DP:$00 A:$ec B:$ff X:$78f8 Y:$0000 U:$0000 S:$dfff CC:$95
799f  7    STS  $6181   IRQ:$01 FIRQ:$00 RPC:$799f DP:$00 A:$ec B:$ff X:$78f8 Y:$0000 U:$0000 S:$dfff CC:$99
79a3  4    LDS  #$69d8  IRQ:$01 FIRQ:$00 RPC:$79a3 DP:$00 A:$ec B:$ff X:$78f8 Y:$0000 U:$0000 S:$dfff CC:$99

A partir de 795F, assdesass exécute son code d'interruption. Il récupère le contexte stocké sur la pile, puis repart comme si de rien n'était. Donc sans RTI. Un peu plus loin (en dehors de mon extrait), il restitue le latch timer avec la valeur du curseur, ce qui a pour effet d'inhiber l'irq timer.

Petite anecdote: juste après le STD $e7c6, il y a un JMP $7cf7 qui consomme 4 cycles... est-ce qu'il y aurait un lien avec mes 4 cycles à moi?

[nicolho]

Merci Tomix de partager ces interrogations et pour toutes ces précisions :
- "le 6846 utilise l'horloge du 6809" : oui et c'est bien précisé que "le compteur décrémente à chaque pas de l'horloge"(ou celle éventuellement divisée par 8 par le circuit). D'ailleurs, en mettant $46, ça met TCR1 à 1, ce qui d'après la doc correspond à "Timer use System Clock (E)" (l'autre choix serait d'utiliser une autre horloge via la patte /CTC mais qui n'est pas branchée)

- "le décompteur était latché à 12500 et en cours de décomptage" : donc 12500 pas (décrémentations), avec la division par 8 du compteur, ça fait 12500 x 8 = cent-mille cycles d'horloge, soit avec cette dernière à 1MHz, tout juste 1/10 de seconde (ah je crois que sam, tu as fait le même calcul pour son edit ) donc ça correspondrait bien au compteur du curseur.

- "Vu le mode utilisé (contrôle avec la valeur $46), une simple écriture dans le latch suffit à relancer le compteur" :
Ah voilà qui répond complétement à ma question, merci ! Forcément, il me manquait cet élément... J'avais un doute car dans la doc, le cas général ne l'évoquait pas et précisait simplement que la valeur du preset était uniquement transmise au compteur à chaque initialisation ou fin de décompte.
Mais je n'avais pas lu en détails ce qui était spécifique au mode continu : "a Write Timer Latches command can be selected as a Counter Initialization signal by clearing TCR4", ce qui signifie que grâce au 4ème bit du registre de contrôle, mis à zéro pour ce mode par $46, toute nouvelle écriture du preset déclenchera une réinitialisation du compteur immédiate avec la nouvelle valeur donnée.

C'est l'idée du code posté, mais ça implique que celui-ci doit au plus vite (lors du décompte suivant l'interruption qui sert au debug) rétablir la fréquence (durée du compteur en boucle) du curseur. Si c'est le cas, éventuellement tu pourrais nous montrer le code du début de la routine d'interruption, qui doit s'en charger ? (edit : on dirait que tu as posté ça entretemps, merci, je regarderai plus tard)

Cette incompréhension écartée, pour calculer de mon côté le nombre de cycle nécessaires (en reprenant ceux indiqués dans ton désassemblage) vu que le compteur s'initialise probablement au cycle suivant la fin du STD $E7C6, j'ai compté du JMP au PULS inclus, et j'obtiens 67 cycles.

Par ailleurs, si on met une valeur N (de 16bits dans les registres du preset) le tableau 4, en haut de la page 12 du pdf de la doc, précise bien que le compteur va effectuer (N + 1) périodes (de 1 ou 8 cycles d'horloge CPU, selon TCR2 ) :

extrait documentation Timer MC6846.jpg (52.55 Kio) Consulté 3922 fois

Donc avec $7 et la division de l'horloge par 8, ça fait (7 + 1) x 8 = 64 cycles avant le déclenchement l'interruption (et pas 7x8=56 comme ça avait été dit). Du coup, théoriquement ça tomberait en plein dans le PULS... est-ce le but recherché ne serait pas plutôt d'obtenir l'interruption idéalement juste après le début de l’exécution de l'instruction "cible" plutôt ? (c'est ce que j'avais compris)

[__sam__]

J'ai une explication pour le +4: d'après la figure 15 de la datasheet la prise en compte des IRQ a lien juste avant le fetch de l'instruction, ce que confirme la figure 9. Donc pour se déclencher juste après l'instruction à debugger il faut cycler 1 cycle de plus qu'après le PULS CC,PC.

Comme vu par nicolho, la valeur $0007 dans le timer compte 64 cycles ce qui nous mène pile au moment où le PULS s'apprête à récupérer CC puis PC (donc +3 cycles). Là le processeur check les interruptions qui ne sont pas encore là puisqu'on fait +4 et qu'on en est à +3. Il execute donc le fetch de l'instruction à débugger. L'interruption timer se présente durant l'execution mais elle ne sera traité que juste avant le fetch de l'instruction suivante. Résultat: on a bien obtenu un pas de 1 instruction.

Donc pour moi le +4 colle assez bien pour que ca marche. Si on ne le met pas on a l'interrupt qui apparait dans le PULS et qui passe avant l'instruction à débugger. Resultat: tu restes sur l'instruction à débugger. C'est ce que tu observais Tomix. Maintenant ce qui est étrange est qu'il faille ajouter ce +4 en émul et pas sur machine réelle, comme s'il y avait une latence implicite de +4 cycles en mode "/8".

[Tomix]

@nicholo

Donc avec $7 et la division de l'horloge par 8, ça fait (7 + 1) x 8 = 64 cycles avant le déclenchement l'interruption (et pas 7x8=56 comme ça avait été dit). Du coup, théoriquement ça tomberait en plein dans le PULS... est-ce le but recherché ne serait pas plutôt d'obtenir l'interruption idéalement juste après le début de l’exécution de l'instruction "cible" plutôt ? (c'est ce que j'avais compris)

Pour le calcul des cycles, tu as raison. Il faut en ajouter 8, ce qui fait 64 cycles.
De toute façon, dans mon émulateur, que ce soit en mode normal ou en mode "divisé par 8", j'ajoute 1 à la valeur avant de multiplier par 8. Donc, en mode normal, pour la valeur 1, j'ai 2. Et en mode "divisé par 8", pour la valeur 1, j'ai 16 en interne ((1+1)*8).

Sinon, comme le montre mon exemple ci-avant, le but n'est pas de tomber sur le PULS, mais sur l'instruction après le PULS (celle à débuguer).
Avant mon fix, mon émulateur tombait sur le PULS. Le fait est que, par rapport à un vrai To9, je suis obligé de prolonger le timer de 4 cycles (dans mon émulateur).
Je compte 67 cycles également entre le STD (non compris) et le PULS (compris). Le PULS pesant 8 cycles, on devrait bien tomber pendant son exécution (je reprends ton raisonnement).
Donc, c'est quoi le binz?

[Tomix]

@__sam__
Ouais, en gros, ton explication argumentée confirme que les calculs de cycle de mon émulateur sont cohérents pour le commun des mortel.
Sinon, autre hypothèse, est-ce que ces 4 cycles viendraient du JMP juste après le STD? Genre, le 6846 reçoit la nouvelle valeur, il lui faut une latence minimum avant de réagir et, pour une raison X ou Y à la con, il attend la fin de l'instruction suivante avant de s'enclencher.
Je dis ça mais ce serait con vu que le 6846 et 6809 sont indépendants l'un de l'autre (hormis l'horloge qu'ils partagent).

Autre chose étrange: finalement, le To8 ferait bien les choses. C'est le To9 qui serait bizarre. Le To8 de Daniel aussi. Ou alors c'est mon To8D qui déconne. L'année 2017 commence compliqué.

Et autre chose bizarre: sur mon To8D, l'interruption se fait soit sur le LDD, soit sur le PUILS. Y a de quoi terminer fou non?

[EDIT]
Hypothèse sur mon To8D: il y aurait une FIRQ qui boufferait quelques cycles entre 2. Mais c'est impossible. La FIRQ bouffe beaucoup trop de cycles pour tomber juste l'instruction avant. Donc hypothèse à la con.

[nicolho]

C'est le To9 qui serait bizarre. Le To8 de Daniel aussi. Ou alors c'est mon To8D qui déconne. L'année 2017 commence compliqué....
Et autre chose bizarre: sur mon To8D, l'interruption se fait soit sur le LDD, soit sur le PUILS. Y a de quoi terminer fou non?

En même temps, si tout se passait comme prévu, on réfléchirait pas à grand chose
Bon, je vous laisse continuer, parce que ça va me prendre déjà un moment de reconstituer dans ma tête le puzzle laissé par sam

[Tomix]

@nicolho
sam disait la même chose que toi tu sais

Sinon autre bizarrerie: sur To9 la valeur $9BF (en mode div 8 ) correspond au cycle d'1 vbl. Et sur mon To8D, il faut que je mette $9C0.
Il y a vraiment une différence entre mon To8D et mon To9.

[__sam__]

C'est curieux ces valeurs: 20ms/8 = 2500µs. Il faut donc mettre 2499 dans le compteur soit $09C3 donc ni $09BF (qui a 4 de plus) ni $09C0 (qui a 5 de plus). Toujours ces fameux 4 cycles sur TO9.

[Tomix]

@__sam__
Pour moi, la valeur $9bf était cohérente pour le timer. En nombre de cycles, ça fait ($9bf+1)*=19968 cycles. Le plus 1, c'est le tour en plus que fait le timer quand on lui fait gober une valeur.