Le fonctionnement du 6846 sur thomson

[Tomix]

Bonjour,

Je poste ici une question que j'avais posé sur un autre forum.
De temps à autre, je peaufine mon émulateur To9 sur Amiga. Je m'attaque à une bizarrerie du Timer que j'ai détectée il y a X temps grâce au tortur'test de sam (la disquette des guignols).

Selon mes tests, il se passe 8 cycles avant que le Timer commence à décompter dès qu'on lui en donne l'ordre. Je ne suis plus certain, mais il semble que DCMOTO prenne en compte ces 8 cycles également. Ceci dit, j'ai fait le test il y a plus d'un an.

Pour arriver à cette déduction, en arrivant à bien faire fonctionner le test de sam, j'ai ajouté 8 unités au compteur de mon timer au moment de son initialisation. En gros, quand un programme mets 1000 comme valeur d'initialisation, je mets 1008 à la place et le latch est à 1008 également. Donc pas cool puisque ça ne correspond pas à la valeur de départ. Pourtant, du coup, le test fonctionne bien. C'est-à-dire que la fréquence de restitution du son est équivalente à ce que je peux entendre sur mon vrai To9. Je précise que la fréquence de restitution est plus élevée (son plus rapide) quand le test ne fonctionne pas.

Mon émulation timer est, en principe, bien implémentée. C'est-à-dire que je suis rigoureusement la doc de Motorola. Les sources de MAME concernant le 6846, vont dans le même sens que mon implémentation.
Or, il ne me semble pas qu'il faille rajouter 8 unités au compteur quand on l'initialise. J'en déduis que c'est le décompteur qui doit démarrer en retard de 8 cycles sur mon To9, comme j'ai pu le constater sur DCMoto (mais mon test date et je ne l'ai fait qu'une fois).

Bref, où est-ce qu'on peut trouver une info officielle sur ce tempo de 8 cycles? Est-ce qu'on doit appliquer ce même tempo lors du recycle (en mode recycle)? D'autres trucs à prendre en compte?
Ou, est-ce que j'aurai loupé une feinte dans mon implémentation.

Merci tout le monde.

[Daniel]

Si dcmoto respecte le nombre de cycles, c'est par chance plus que par calcul. Je ne me suis pas vraiment penché sur l'émulation fidèle du 6846. J'ai simplement programmé les fonctions utilisées par les programmes connus, jusqu'à obtenir un fonctionnement à peu près réaliste. Je sais qu'il reste des bugs, car on m'a signalé des anomalies, en particulier dans la vitesse de certaines animations ou musiques.

[Tomix]

C'est bon, j'ai trouvé l'origine de mon problème. Et bonne nouvelle, il n'y a pas de décalage de 8 cycles au démarrage du 6846.
J'ai fait une série de benchs quand j'ai eu accès à mon To9, avec des relevés de compteur. Ces mêmes benchs donnent maintenant les mêmes résultats sur mon émulateur, sans rustine de code. Mais il faut arriver à bien maîtriser les subtilités internes du 6846 et bien lire la doc qui dissémine presque toutes les informations.

@Daniel
Je confirme du coup que ton timer joue trop vite le test des guignols de sam.
Si ça te dit de régler le timer de DCMoto...

[Daniel]

Cette anomalie ne me surprend pas, car on m'en a signalé aussi dans d'autres musiques. Dès que j'aurai l'occasion de revenir au développement de dcmoto je me plongerai à nouveau dans la doc du 6846 pour améliorer l'émulation. Et au besoin je te demanderai conseil. Merci

[__sam__]

Pour info Daniel, je viens de me rendre compte d'un truc curieux dans l'émulation TO7(70) sous DCMOTO et le 6848. Quand je mets un point d'arrêt sur l'accès en lecture sur $6027 (timerpt) pour debugger un de mes programmes, je me suis rendu compte qu'à chaque fois le debugger indique ligne courante 0/352. En emul TO8/9 on a une ligne plus arbitraire.

Est-ce que la génération d'une interruption IRQ par le 6848 ne se produirait qu'en début de VBL alors qu'il devrait avoir lieu n'importe quand? Il faudrait probablement avoir une comportement similaire du 6848 quel que soit la machine je crois.

Une autre hypothèse est qu'en emul TO7 le traitement des IRQ ne se produit qu'en début de VBL au lieu de n'importe où. Entre les deux hypothèses je n'ai pas trouvé comment trancher :p

[Daniel]

Je me suis posé exactement la même question et je n'ai pas trouvé la réponse.

Pour les TO7 et TO7/70 c'est assez simple : j'ai un compteur de cycles pour les IRQ, un autre compteur pour les VBL, c'est assez normal que ça reste synchrone dans dcmoto. Sur la vraie machine, je ne sais pas si c'est pareil : est-ce parfaitement synchrone ? y-a-t-il un décalage entre la VBL et l'IRQ ? Il faudrait avoir le courage d'écrire un petit programme de test.

Pour les TO8 et TO9 c'est beaucoup plus compliqué, et je suis encore très loin de tout maîtriser. Il y a des IRQ générées par le timer, d'autres par le clavier, plus les FIRQ pour le crayon optique et j'en oublie sûrement. Je crois aussi que certaines IRQ's peuvent être masquées par le 6846. Cette complexité doit produire de temps en temps des décalages, qui expliquent la désynchronisation des IRQ par rapport aux VBL. Et comme dcmoto n'émule pas tout au niveau hard (en particulier le crayon optique, la souris, le contrôleur de disquette...) le décompte des cycles n'est pas parfaitement exact. C'est ce qui doit expliquer aussi les décalages de fréquence de la musique.

J'aimerais bien avoir un émulateur parfait, mais je crois que c'est un rêve inaccessible si on n'émule pas les circuits électroniques au plus près du matériel, comme le fait Antoine Miné dans ses modules MESS. Il y a des chances qu'il soit plus réaliste que TEO et dcmoto sur ces points précis.

[__sam__]

Ben sur TO7 tout comme sur TO8/9 on peut programmer le timer pour marcher à une frequence arbitraire. Il me semble alors pas logique d'avoir une IRQ uniquement sur ligne=0. Vu que les routines "quizz" de logicielsmoto fonctionnent sous DCMOTO j'en déduis que le bit 0 de $E7C0 passe bien à 1 quand le timer fait un cycle. Donc le timer semble bien décompter correctement. Parfait! Si le timer est configuré correctement (cas par défaut), le passage du bit 0 de $E7C0 à 1 devrait positionner une demande d'IRQ sur le 6809 et la routine de traitement d'IRQ devrait être aussi appelée quasiment tout de suite c'est a dire très probablement en plein milieu d'une "frame" (ligne!=0). Or ce n'est pas ce que j'arrive à avoir: Le traitement de l'IRQ ne semble être pris en compte par le 6809 uniquement lorsque ligne=0. Sur TO8/9 en revanche ca marche bien. Quelque part le traitement fait sur les TO8/9 est plus correct que celui simplifié fait dans l'émul TO7.

C'est dommage, j'ai un truc sur le feu (chut!) qui devrait marcher sur toute machine TO: du 7 au 9+ en passant par le 7/70 et le 8, mais qui ne marche pas bien sur le TO7(70) de DCMOTO à cause du fait que l'indirection de TIMEPT du moniteur n'est appelée qu'à 50hz là où on devrait avoir autour de 440 (c'est un indice )

Pour moi il faudrait que l'emul appelle la routine de l'irq juste avant l'exécution de la prochaine instruction (c'est à dire dès la demande faite par le timer). Si c'est trop gourmand, on peut imaginer la retarder au début de la ligne suivante, mais pas trop car les routines qui utilisent l'interruption timer précisement sont complètement fausses (par exemple ma D7 jouant les samples des "guignols de l'info" en tache de fond).

La routine ROM du TO7 de traitement de l'IRQ est assez simple

Code : Tout sélectionner

FB73 B6E7C0     LDA    $E7C0              
FB76 2B04       BMI    $FB7C        ; IRQ venant du 6846 (plusieurs causes) ?
FB78 6E9F6021   JMP    [$6021]      ; non => routine IRQ utilisateur
FB7C 44         LSRA                ; BIT0 de $E7C0 à 1?
FB7D 2501       BCS    $FB80        ; oui => IRQ du timer
FB7F 3B         RTI                 ; IRQ 6848 non reconnue
FB80 B66019     LDA    $6019        ; IRQ timer: Appel de TIMEPT si bit5 de $6019 à 1  
FB83 8520       BITA   #$20               
FB85 2704       BEQ    $FB8B              
FB87 6E9F6027   JMP    [$6027]            
FB8B B66019     LDA    $6019              
FB8E 8504       BITA   #$04               
FB90 2716       BEQ    $FBA8              
FB92 F6E7C3     LDB    $E7C3              
FB95 3404       PSHS   B                  
FB97 CA01       ORB    #$01               
FB99 F7E7C3     STB    $E7C3              
FB9C 639F605A   COM    [$605A]            
FBA0 736075     COM    $6075              
FBA3 3504       PULS   B                  
FBA5 F7E7C3     STB    $E7C3              
FBA8 7C605F     INC    $605F              
FBAB 8A08       ORA    #$08               
FBAD B76019     STA    $6019              
FBB0 BCE7C6     CMPX   $E7C6              
FBB3 3B         RTI                       

Le crayon optique génère une FIRQ et n'est donc pas géré par cette routine qui est finalement très simple. Elle regarde juste la source de l'IRQ. Si c'est le timer du 6848 elle appelle TIMEPT, sinon elle "RTI"direct.

Pour MESS, je n'ai même pas l'impression que TIMEPT soit appellé. J'ai essayé mes"K7" du quizz, mais pour une raison mystérieuse (IO error) elles ne sont pas chargées (elles passent bien sous DCMOTO). Je subodore que lui aussi a des soucis avec le timer.

[Daniel]

Je vais regarder la programmation de l'IRQ du TO7 et du TO7/70 pour voir si je peux l'améliorer. Probablement pas avant la semaine prochaine, car je ne suis pas chez moi. Si tu as un programme de test pour vérifier le bon fonctionnement, ça m'aiderait beaucoup (mon adresse mail est en bas de la page d'accueil du site dcmoto).

[__sam__]

Ce soir je comptais justement faire un court programme qui
1) programme le timer pour fonctionner à 200Hz en mode continu
2) change le tour d'écran à chaque interruptions

Normalement si tout se passe bien, pour chaque image on doit voir 2 changements de couleurs (qui peuvent démarrer n'importe où).

Avec ca je devrais pouvoir distinguer les emuls qui:
- soit prennent en compte l'IRQ à la mauvaise fréquence (en gros 50hz max si la gestion de l'irq est retardée en fin d'image)
- soit emulent mal le mode continu du timer et n'appellent l'IRQ qu'une seule fois

sam.

[Edit] le fichier K7 est ici: 6848.zip Il contient un binaire (source inclus) qui se charge en $A000 depuis le basic et fait apparaitre 8 changements de couleurs (rouge/vert 4 fois) par image tout en jouant un son à 200hz ($E7C1 voit son bit 3 inversé à chaque interruption). On sort en appuyant sur une touche. Normalement sur un vrai TO les bandes sont stables. Or sur la plupart des emuls elles défilent un peu. Si on recompile en remplacant 2499 par 2491 elles sont stables. Je pense qu'il s'agit de la manifestation du retard de 8 cycles trouvé par TOMIX dans l'émulation fine du 6848 (explications ici ). Mais bon ca n'est pas si grave.

Ce qui est plus ennuyeux pour DCMOTO est qu'en mode TO7 ou TO7/70 on ne voit pas de bandes et que le son joué est à la mauvaise fréquence. L'analyse sous Audacity fait apparaitre un pic du spectre (pas très net) autour de 12hz, indiquant que l'interruption est probablement appelée à 24-25Hz. J'en conclue que le tour est uniquement changé en fin de construction de l'écran 25 fois par sec ce qui est loin des 400 fois par sec attendu. En mode TO8 on voit bien apparaitre les bandes et le son est bien joué à 200Hz.

FunzyTO770 possède le même problème: le son est joué à une très basse fréquence. Bon c'est un vieux programme, c'est pas trop gênant.

TEO qui se comporte bien sur mes programmes plus gros a un tour qui ne fait pas apparaitre de bandes, mais le son est bien à 200Hz, ce qui traduit juste que l'émulation de la couleur du tour n'est pas recalculé à chaque ligne, mais probablement en fin de VBL. (C'est fou ce que l'analyse spectrale peut faire apprendre sur un émulateur).

Au final il n'y a que MESS qui montre bien les bandes et le son que ce soit en mode TO7 ou TO8. Pour lui tout va bien. Il me reste juste à comprendre pourquoi sur mon vrai programme l'interruption n'est appelée qu'une seule fois, mais c'est une autre histoire (l'interception des lectures/écritures en ram du débugger de DCMOTO manque vraiment à MESS pour comprendre ce qu'il se passe finement).

[Daniel]

Dès lundi je me mets au travail pour améliorer dcmoto. Depuis la création de l'émulateur c'est ainsi que je procède : dès qu'on me signale une différence avec la vraie machine, je cherche le moyen de reproduire le comportement correct. Les démonstrations, comme HCL, Chinese Stack et Space Project, ont beaucoup contribué à l'amélioration de l'émulation TO8/TO8D/TO9+. D'autres machines, comme le MO6, le TO9 et le TO7/70, sont un peu en retard faute de programmes de test. C'est le moment de combler ce retard...

[Edit]
Pour revenir sur l'analyse spectrale : le son de dcmoto est échantillonné à 22050 Hz, ce qui explique bien la fréquence de coupure aux alentours de 11000 Hz. Chaque échantillon est calculé en intégrant le signal du buzzer + le signal du CNA sur la période d'échantillonnage. Je ne sais pas si ça peut expliquer les défauts constatés.
A l'époque où j'ai choisi 22050 Hz il y avait des contraintes de performances des PC. Aujourd'hui la vitesse des processeurs a beaucoup augmenté, je dois pouvoir passer à 44100 Hz, voire plus, sans aucun problème. Reste à déterminer s'il vaut mieux intégrer le signal, ou prendre sa valeur instantanée au moment de l'échantillonnage. J'ai longuement hésité, et encore aujourd'hui je ne suis pas certain que l'intégration soit la meilleure solution.
Si, comme je pense, space project joue la musique à 44100 Hz, il n'est pas surprenant que dcmoto la restitue très mal.