[THOMSON] Jouer des MODs amiga

[__sam__]

Oui, ca élimine un CMP qui n'est déjà plus là dans ma solution actuelle.

Pour rappel dans le dernier code, le test de fin d'échantillon est gratuit. Cela ne coute que les 3 cycles du saut conditionnel. Si on veut aller encore plus vite--et il le faut si on veut s'approcher de la vitesse des players ZX--il faut trouver le moyen de virer les sauts et ne garder que le stricte minimum dans le code. C'est un exercice d'optimisation assez passionnant et je pense avoir une piste. Mais pour le moment, ce n'est pas la vitesse de rendu qui me préoccupe.

Ce qui me préoccupe serait de faire jouer des mods sur 1 bits. J'aimerais tant pouvoir faire chanter un TO7 ou un MO5 de base. Or je ne sais pas ce qu'il se passe, mais quand j'arrive à avoir un truc +/- correct, c'est lié à un gros bug pas désiré. A l'inverse quand le bug est corrigé et que le code est conforme à ce que je voulais faire, le son est de la bouillie de bits.

Je dois louper un truc gros comme un éléphant devant mes yeux, mais je n'arrive pas à comprendre comment ca se fait que ma conversion 1 bit soit d'aussi piètre qualité

[Daniel]

J'ai encore une idée, mais je ne sais pas ce qu'elle vaut :

Nous utilisons en général des algorithmes dont la boucle principale tourne à une fréquence fixe. Cette fréquence étant assez basse avec les processeurs que nous utilisons, elle s'entend. On peut l'augmenter de quelques centaines de Hz, la filtrer, ajouter du bruit, elle s'entendra toujours. L'idée serait de faire une boucle à fréquence variable. Au lieu d'avoir des échantillons régulièrement espacés on modulerait la période en fonction de la valeur de l'échantillon, ou d'un nombre au hasard, ou de tout autre phénomène non cyclique.

[__sam__]

Tu veux dire qu'en introduisant une vibration aléatoire (un frisson, c-à-d dither en anglais) dans la fréquence du canal, ca pourrait amméliorer ? Peut-être. Il faut experimenter ce que donne le rendu du La440 à 440+random() hz. J'ai le présentiment que l'oreille est très sensible à la justesse des notes les unes par rapport aux autres, donc il faut que le random() ne soit pas trop gros pour se rapprocher du La# qui n'est à moins de 6% au dessus de la fréquence du La de base.

Cela dit, les autres bécanes ne font pas ca, donc il y a forcément un truc évident que je loupe dans le dither 1 bit.

[Daniel]

Mon idée n'était pas d'introduire une petite variation de période entre les échantillons, mais une grosse variation, de l'ordre de 1 à 8, pour qu'on ne puisse pas avoir de phénomène cyclique audible. Ce n'est peut-être pas réaliste, car pour ne pas modifier la fréquence de restitution il faut complètement modifier l'original, c'est à dire recalculer de nouveaux échantillons avec une période d'échantillonnage variable. C'est facile pour de la musique en streaming mais probablement beaucoup plus compliqué pour les MODs Amiga.

Par exemple, on pourrait définir 8 valeurs différentes pour l'amplitude a, numérotées de 0 à 7. Chaque échantillon serait remplacé par une séquence avec le buzzer à 1 pendant une période a x n, suivi du buzzer à zéro pendant une période n. La boucle pour jouer l'échantillon durerait (a + 1) * n, n étant un nombre de cycles constant à choisir en fonction de la durée des instructions du programme. Avec cette méthode on supprime totalement le phénomène cyclique aux alentours de 8 kHz. Je ne sais pas si c'est compréhensible ?

[__sam__]

Là j'avoue être perdu à la 1ère lecture. Il faut que je relise une paire de fois encore

(après 2 - 3 lectures) Ce que tu décris c'est du PWM. Mais avec une fréquence de a_max = 8 fois la période du cycle de la routine de rendu. Ca fait une très longue période: 8*142=1136µs environ, soit une fréquence de 880hz. C'est bien trop bas pour de la musique.

[jasz]

J'ai profité de la soirée pour jeter les deux yeux sur la source de ton nouveau player mais il y a un truc que je ne comprends pas. Outre le fait que je ne pompe rien aux macros, pourquoi deux table des volumes?

[__sam__]

Bah les macros c'est de la simple substitution de texte. Le \0 se voit remplacé par le 1er paramètre lors de l'appel de la macro. Par exemple LD\0 #0, devient LDX #0 si le 1er paramètre de la macro est X.

Maintenant le volume: Il va de 0 à $F, et les échantillons de -7 (codé comme 1) à +7 (codé comme $f). Sur un octet en mémoire on fait tenir 2 échantillons de 2 instruments distincts: $xy, x correspond à un instru, y à un autre. Par un jeu de masque suivant qu'on s'interresse à l'un ou l'autre des instrus, on obtient $x0 et $0y. On place alors le volume du canal dans la partie à 0: $xv et $vy. Il y a alors 2 tables, l'une pour les $xv et l'autre pour les $vy. Elles convertissent les x,y (échantillon) et le volume suivant la formule (échantillon-8)*volume/15+8.

On pourrait n'utiliser qu'une table si on transformait $vy en $yv avec des rotations, mais c'est bien trop lent sur le 6809. Mieux vaut avoir 2 tables pil-poil adaptée pour chacun des $xv et $vy.

[__sam__]

Bon, j'ai --je crois-- un peu mieux compris ce qu'il se passe avec mon approche (insxtruments déjà bit-streamés en mémoire et rejoués à 8khz). C'est un peu long à expliquer, aussi j'invite ceux que ca interresse à lire mon analyse >>ICI<<. J'y pose quelques questions théoriques annexes (par exemple: pourquoi le dither audio est plus exigeant que le dither graphique) et si certains d'entre vous ont des idées là dessus, merci de m'en faire part.

[Fool-DupleX]

Je viens de lire ton analyse sur [silicium] logicielsmoto.

Sur les MO, il me semble possible de commuter le bit de son sans passer par les registres. Mais sur les TO ? Un peu plus compliqué, il faudrait que j'étudie à fond le registre de config pour comprendre les implications.

[Daniel]

Oh le lapsus ! Silicium ne s'intéresse pas aux Thomson, il n'y a pas eu de post depuis le 22/09/2016.

Pour répondre à la question de __sam__ sur la modification de l'état du buzzer sans utiliser les accumulateurs, pour les MO il y a INC et DEC car le buzzer est sur le bit 0. Malheureusement ça ne marche pas pour les TO car dans ce cas le buzzer est sur le bit 3.

Sinon, il y a le 6309. J'hésite encore à développer pour ce processeur car j'ai peur de faire un bide complet. Pourtant il résoudrait beaucoup de nos problèmes d'optimisation. Par exemple, pour la simulation de disquette sur carte SD, on gagnerait 30% en vitesse de lecture, j'ai déjà écrit le programme et compté les cycles.

[Fool-DupleX]

Lapsus, en effet. Je n'arrive d'ailleurs plus a me logger sur logicielsmoto ...

Oui y'a pas que INC et DEC d'ailleurs qui fassent l'affaire, même si c'est le plus propre. C'est pas facile de trouver une combinaison qui fonctionne sur le registre du 6846, mais le bit 6 est pas utilisé du tout ? Ca a pas l'air documenté dans la DS. Ca se relit toujours 0 je suppose ?

Le 6309, que j'utilise aussi pour OS-9, est une forme de triche et de moyen réservé à une certaine d'élite, si bien que je ne cautionne pas cette solution, même si je suis un fan de ce processeur.

Pour en revenir au 6846, CP1 est utilisé sur les TO ou pas ?

[Fool-DupleX]

Je dis peut-être une bêtise, mais si on fait abstraction de CP1 qui ne me semble pas utilisé, ne pourrait-on pas mettre $37 dans le registre de config et utiliser ensuite INC et DEC ? Ca ferait flipper CP2 et la config de CP1, ce qui ne me semble pas gênant du moment que les interruptions sont inhibées sur le 6809. En utilisant DP, ca ferait 6 cycles par commutation.

[__sam__]

En mettant $37 dans le registre de config, tu transforme temporairement le TO8 en MO6, c'est ca ? En fait si ca marchait en vrai ca ne marcherait pas sur TO7(/70), et surtout: je ne pense pas que les émulateurs soient capable d'émuler cette option du Gate-Array système

Maintenant si on cible les MO, alors oui aucun problème pour un INC/DEC comme on le fait pour la commutation FORME/FOND de la ram vidéo, mais ca coute 7 cycles car DP est déjà utilisé par ailleurs. Au fait, sur MO, il y a combien de RAM contigüe utilisable au juste ? (Sur TO7/70, on peut aller de $6100 à $DFFF, soit ~32ko)

Nota: je viens de me rendre compte qu'avec un peu d'astuce, il y aurait moyen de faire du PWM à 11 niveaux quitte à manger un peu plus de place en RAM. J'évalue le player à 4Ko de ram environ dans ce mode, ce qui laisse 26 ou 28ko pour la musique. C'est quand même assez confortable.

PS: pour ta connexion sur logicielsmoto, tu as perdu le mot de passe, ou est-ce autre-chose ? tu veux que je ping Préhisto à ce sujet ?

[Fool-DupleX]

En mettant $37 dans le registre de config, tu ...

Heu non, je ne parle pas du tout de ça. Je parle du registre PRC du 6846, dans lequel se trouve CP2, qui pilote la sortie son. En passant de $37 à $38 et vice-versa, ca commute la sortie son mais aussi la config de CP1, qui sauf erreur n'est jamais utilisé sur les TO, sauf sur le TO7, et encore, faut le dire vite.

Mais je m'aperçois que CP2 n'est pas utilisé pour le son sur TO8, mais pour le mute. Décidément. CP1 est utilisé pour le clavier, mais ca ne change rien à l'affaire. Et d'ou sort le son sur le TO8 alors ?

Sur MO5, 40 Ko contigus en comptant les 8 Ko de RAM video au debut.

Et pour logicielsmoto, ben disons que j'ai perdu le mot de passe, même si je suis certain que non ...

[__sam__]

Et pour logicielsmoto, ben disons que j'ai perdu le mot de passe, même si je suis certain que non ...

Lors de la connexion il y a un bouton "j'ai oublié mon mot de passe" le cas échéant.