[DCMOTO] Bug timer pour freq particulière

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

Modérateurs : Papy.G, fneck, Carl

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

[DCMOTO] Bug timer pour freq particulière

Message par __sam__ »

Dans le cadre du projet de jeu TO8 de 6502man je fais un player de samples.

Pour faire tenir des sons de 4 secs ou plus dans les 16Ko d'une banque mémoire, je downsample les échantillons de 44Khz à 5.5khz. Jusque là tout va bien. Je programme le timer 6848 pour qu'il ait une période de 180 µs. Sur MESS et TEO les sons sont joués à la bonne fréquence. Mais sous DCMOTO les sons m'ont semblés à l'oreille être joués à une fréquence double.

En utilisant le mode débug et un point d'arret sur une boucle qui teste le TC0 du timer, j'ai noté les positions ligne/colonne courante consécutives entre deux timeout du timer:

Code : Tout sélectionner

LIGNE=301 COL=26
LIGNE=302 COL=56
Comme une ligne dure 64µs, je calcule que le timeout se produit au bout de (302-301)*64 + (56-26)=94µs..

Tiens la période mesurée est sensiblement la moité de celle demandée (180µs). Est-ce que c'est normal ?

En tout cas cela confirme bien que la fréquence jouée n'est pas de 5.5khz mais 11khz contrairement à ce qui est demandé au timer.

Bizarrement quand la fréquence n'est pas un multiple de 44Khz, par exemple quand c'est 2087hz (timer=478) comme dans mes démos de la Forever party, on a pas ce pb. Je soupçonne qu'il y a une erreur d'arrondi qui fait passer le 180 du timer à 90. Y a t'il un bug ou une astuce à savoir dans l'émul (style : il est connu que le timer n'est pas fidèle pour les fréquences trop élevées ou trop proche d'un diviseur exact de 44.1Khz).
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
__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [DCMOTO] Bug timer pour freq particulière

Message par __sam__ »

Ce matin j'ai fait un petit programme de test (6848.BIN sur la D7 jointe), et j'observe bien un comportement inattendu de DCMOTO (20130310).

Le prog positionne le timer à une période de 181µs, et fait alterner le bit du buzzer ce qui doit faire un son de période 2*181µs, soit 2762Hz, et c'est bien la fréquence mesurée sous TEO (voir graphique). Par contre sous DCMoto la fréquence est sensiblement double! (j'ai fait des mesures de spectre son sous audacity)
Pb6848.png
Pb6848.png (73.36 Kio) Consulté 8466 fois
[EDIT] ben le fichier devrait s'appeller 6846.BIN et pas 6848.BIN.. C'est pas bien grave :P
Pièces jointes
disk.zip
(80.26 Kio) Téléchargé 192 fois
Dernière modification par __sam__ le 23 juin 2014 19:03, modifié 1 fois.
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
__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [DCMOTO] Bug timer pour freq particulière

Message par __sam__ »

A noter: en mode TO7, la fréquence semble être meilleure (autour de 2khz et pas 4khz).

Donc le soucis c'est le fonctionnement du TC0 du timer en émulation TO8, et TO9(+).

Autre précision: dcmoto_20100722 marche bien, mais dcmoto_20101022 affiche le bug. Il y a donc eu une régression entre ces deux versions dans l'émulation du bit TC0 du timer (b0 de $E7C0).
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
jester3
Messages : 11
Inscription : 23 sept. 2013 13:03

Re: [DCMOTO] Bug timer pour freq particulière

Message par jester3 »

le premier reflexe que j'ai eu a été de regarder la notice DCMOTO afin de voir quelles sont les différences entre les versions :
http://dcmoto.free.fr/fr.html
en rapport avec le son il y a :
Simplification de l'émulation du son (suppression de DirectSound) dans la version 201004
et en nouveauté 201010 les changements suivant en particulier des interruptions de signaux :
Correction d'une anomalie de gestion du signal IRQ des TO8 et TO9 et diffusion de la sous-version 2010.10.22
Augmentation de la durée du signal IRQ pour obtenir un son correct dans La Malédiction de Thaar
ainsi que :
Suppression des réglages de la fréquence d'affichage et du nombre de buffers sons

Le reglage differents des IRC pourrait-il modifier la fréquence?
__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [DCMOTO] Bug timer pour freq particulière

Message par __sam__ »

Peut-être. Il faudra attendre le retour de vacance de Daniel pour en savoir plus. Par contre moi je serais absent une paire de jours à ce moment là.
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 : 17286
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [DCMOTO] Bug timer pour freq particulière

Message par Daniel »

Et voilà, je suis rentré, je retrouve tous les messages accumulés depuis 10 jours, il me faudra un peu de temps pour traiter tous les sujets...

L'émulation du 6846 est assez difficile, avec toutes les subtilités de masquage des interruptions du clavier et/ou du timer, et je suis sûr qu'il reste des tas d'erreurs. Le timer est quand même assez simple, s'il y a une anomalie je devrais la trouver.

La dernière version officielle de dcmoto date de plus d'un an. Depuis il a été modifié et recompilé une bonne centaine de fois, mais je n'ai pas encore eu le temps de finaliser une version "présentable". Avec un peu de chance l'erreur est peut-être corrigée. Le problème de "La Malédiction de Thaar" est résolu proprement, alors que la modification précédente n'était pas correcte. Il y a peut-être un rapport avec le timer. Je vais me replonger dans les sources pour voir ce qu'il en est. Je compterai ensuite sur vous pour les tests...

[Edit 17:45]
Dans la version 2013.03.10, le signal IRQ généré par le timer reste positionné trop longtemps et peut, dans certains cas, être pris en compte deux fois. Cette anomalie expliquerait la fréquence double. Elle a été corrigée depuis. Voici la toute dernière version, non finalisée (ne pas diffuser s.v.p.). Pouvez-vous l'essayer ?
http://dcmoto.free.fr/emulateur/prog/dc ... 140703.zip
Daniel
L'obstacle augmente mon ardeur.
Avatar de l’utilisateur
6502man
Messages : 12242
Inscription : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: [DCMOTO] Bug timer pour freq particulière

Message par 6502man »

Ce soir j'essaie cette version en comparant avec la précédente si les fréquences sont différentes.

En tout cas entre DCMOTO (version précédente) et un vrai TO8D ont entend bien la différence.
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.
__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [DCMOTO] Bug timer pour freq particulière

Message par __sam__ »

Bon j'ai fait le test avec la version temporaire. J'ai toujours le même défaut: en mode TO8 ca joue trop haut (pic à 4814Hz) par rapport au même code en mode TO7 (pic à 1804Hz). Il doit y avoir une différence dans le traitement du bit 0 de $E7C0 (timeout timer) entre l'emul TO7 et l'emul TO8 ce qui n'est pas normal vu que c'est la même puce dans les deux cas.
Image1.gif
Image1.gif (112.05 Kio) Consulté 8360 fois
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 : 17286
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [DCMOTO] Bug timer pour freq particulière

Message par Daniel »

Alors ce n'était pas la durée du signal IRQ. Je vais chercher autre chose...
En attendant, voici une nouvelle version à la demande de 6502man : le curseur est masqué dans l'écran Thomson si le crayon optique est désactivé dans les options de dcmoto : http://dcmoto.free.fr/emulateur/prog/dc ... 140704.zip
Daniel
L'obstacle augmente mon ardeur.
Avatar de l’utilisateur
6502man
Messages : 12242
Inscription : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: [DCMOTO] Bug timer pour freq particulière

Message par 6502man »

Merci Daniel, pour cette nouvelle version :D

Impeccable pour le jeu SECTE NOIRE. :wink:
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.
Daniel
Messages : 17286
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [DCMOTO] Bug timer pour freq particulière

Message par Daniel »

Après enquête, il y a effectivement de gros problèmes d'émulation du 6846 dans dcmoto. Probablement des erreurs en mode TO8, mais aussi une très grosse anomalie en mode TO7 : la lecture de $E7C0 renvoie toujours &H81. C'est un miracle si la fréquence est bonne. Il faut tout reprendre et comparer avec les vraies machines pour vérifier.
Daniel
L'obstacle augmente mon ardeur.
__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [DCMOTO] Bug timer pour freq particulière

Message par __sam__ »

Ce qui est étonnant est que dans mon souvenir les IRQ (cpu) sont correcte.

De ce que je comprends du fonctionnement de CSR=$E7C0, les bits 0 à 2 (CSR0 à CSR2) représentent des demande d'IRQ des différentes parties (timer, clavier serie, etc). Ces demande sont filtrées par des bits de masque (TCR6 pour CSR0, PCR0 pour CSR1, et PCR3 pour CSR2). Le bit 7 est à 1 si et seulement si l'une des 3 demandes d'interruption filtrée est active CSR7 = TCR6.CSR0 + PCR0.CSR1 + PCR3.CSR2, auquel cas une demande d'IRQ est effectivement envoyée au CPU.

Dans mon prog de test j'ai TCR6=0, donc même si CSR0 passe à 1 (sur timeout du timer dans le mode que j'utilise), la sortie CSR7 reste à 0: il n'y a pas de demande d'IRQ a cpu.

Tu as peut être fait une optim qui disais que si on a pas d'IRQ alors on ne fait rien, or il faut quand même sortir dans tous les cas le bit CSR0 qui peut être testé de façon active par le CPU. C'est ce que je fais dans le prog de test, et ce que fait aussi la routine d'écriture du K7 (mais elle est by-passée dans la plupart des emuls).
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 : 17286
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [DCMOTO] Bug timer pour freq particulière

Message par Daniel »

Quand j'ai commencé l'émulation des TO, j'avais seulement le manuel technique TO9/TO8/TO9+ qui est très laconique à propos du 6846. J'ai fait pas mal d'impasses sur le positionnement des bits du registre CSR, et surtout une grosse erreur : le bit CSR0 de l'interruption timer est positionné mais jamais remis à zéro. C'est probablement la cause de l'anomalie sur les fréquences. Il faut que je reprenne ce point avec les informations données par la datasheet. Il y a 4 conditions provoquant la remise à zéro, pas très simples. La quatrième, en particulier est assez complexe.

Par la même occasion je vais revoir en détail les conditions précises de positionnement de CSR7 (IRQ), car je ne suis pas sûr que toutes les règles soient bien respectées. Bref, il faut arrêter d'improviser et suivre la datasheet point par point. Dans ce type de maintenance il y a toujours des risques de régression, il faudra tout tester soigneusement après les corrections.
Daniel
L'obstacle augmente mon ardeur.
__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [DCMOTO] Bug timer pour freq particulière

Message par __sam__ »

Daniel a écrit :Quand j'ai commencé l'émulation des TO, j'avais seulement le manuel technique TO9/TO8/TO9+ qui est très laconique à propos du 6846.
Le manuel technique TO7 contient beaucoup plus d'infos extraites du datasheet.
J'ai fait pas mal d'impasses sur le positionnement des bits du registre CSR, et surtout une grosse erreur : le bit CSR0 de l'interruption timer est positionné mais jamais remis à zéro. C'est probablement la cause de l'anomalie sur les fréquences.
oui très probablement.
Il faut que je reprenne ce point avec les informations données par la datasheet. Il y a 4 conditions provoquant la remise à zéro, pas très simples. La quatrième, en particulier est assez complexe.
J'ai toujours trouvé la datashett 6846 et les autres docs décrivant le timer pas claires du tout, ce qui fait croire à une apparente complexité qui est je pense factice. Ce truc doit faire des choses très simple (il n'y a pas des zilions de transistors là dedans pour s'occuper de la partie timer), mais comme c'est expliqué avec le pieds on ne trouve qu'une suite de cas particuliers ou de redondance inutiles. Ainsi comment interpréter ceci
mode continue si TCR3=0, TCR7=1, TCR5=0
Dans ce mode un signal carré est généré sur la sortie 19 (CTO), si cette sortie est validée par TCR7 à 1
Ben oui, mais on est précisément dans le cas TCR7=1. A quoi sert cette info redondante ???
Autre exemple de spec "par exception qui n'en sont pas mais du coup on ne comprends pas pourquoi parler de ca"
- en mode monocoup normal.
A deux exceptions près ce mode est identique au précédent (sam: le mode continu).
1) (sam: détail de la 1ere exception)
2) Le TO7 n'est pas concerné par la 2eme exception (sam: quelle 2eme exception, on en a listé qu'une seule????) puisque les deux entrées CTG-bar et CTC-bar sont au 0V
Pfff... beau b*rdel cette partie de la doc :?

Cependant la doc indique précisément ce qui fait passer CSR0 à 0:
Le bit CSR0 peut être remis à 0 par:
1) reset externe ou interne (TCR0 à 1) (sam: donc poke &hE7C5,peek(&hE7C5) or 1, le truc qui stoppe le timer)
2) initialisation du compteur
3) commande de lecture du compteur précédé d'une lecture de CSR pendant que CSR0 est à 1. (Sam: c'est ca que je fais: je lis $E7C0 (CSR) jusqu'à ce que le CSR0 est à 1, puis je fais un CMPX (ou D) $E7C6 qui va lire le compteur).
Sauf que le point (2) est mystérieux.

La doc indique ailleurs
Le contenu des registres tampon n'est transféré dans le compteur que lorsqu'on lui en donne l'ordre. Dans le TO7 cet ordre ne peut venir que de la mise à 1 du registre TCR0 (sam: c'est le point 1 ca, encore une redondance inutile) ou avec une commande d'écriture des registres tampons (en fonction du mode (sam: heu ??? ca sert à quoi cette précision compliquer la compréhension???).
Bref je pense que lorsqu'ils parlent du point 2) ils ne font référence qu'à l'écriture dans le registres $E7C7 ($E7C6 ne copie pas le latch, c'est sur la partie basse qu'il est copié) car le point 1) est déjà couvert.

Je suis sur que si on voyait le code Verilog du 6846, ca serait beaucoup plus clair que ces docs verbeuses, redondantes, incomplètes et mal écrites (IMHO).

Tomix avait trouvé certains aspect intéressants du 6846 pour son emul: http://www.logicielsmoto.com/phpBB/view ... 3581#p3581

A défaut de verilog, le code le plus exact qui existe (car utilisé pour d'autres machines) doit être celui de MAME: http://mamedev.org/source/src/mess/mach ... 846.c.html
De ce que j'en comprends c'est que lors de la lecture de CSR ($E7C0), les bits CSR0-2 sont indiqués comme devant être passé à 0 le moment venu. Pour CSR0 cela se fait lors de la prochaine lecture du compteut en $E7C6 ou $E7C7 (au 1er des deux lu).
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 : 17286
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [DCMOTO] Bug timer pour freq particulière

Message par Daniel »

Le 6846 est un circuit complexe. Même le module Mame d'Antoine Miné n'émule pas toutes ses fonctions. C'est d'ailleurs inutile pour le TO8, puisque par construction hard il n'a pas l'usage de tous les modes ni de tous les paramètres.

Par prudence, je n'ai pas osé repartir de zéro. Je préfère modifier dcmoto par petites touches pour corriger les anomalies visibles. Pour commencer, j'ai remis à zéro le bit CSR0 (interruption timer) selon mon interprétation des quatre points de la datasheet. Voici une nouvelle version provisoire : http://dcmoto.free.fr/emulateur/prog/dc ... 140705.zip

Je ne sais pas si elle résout le problème des fréquences, je compte sur vous pour tester. Si ça ne suffit pas je chercherai autre chose...
Notez une autre nouveauté, sans rapport avec le bug : le curseur représente le crayon optique (s'il est sélectionné dans les options de dcmoto), sinon il n'y a pas de curseur dans l'écran Thomson.
Daniel
L'obstacle augmente mon ardeur.
Répondre