Le Kiosque à Musique Musique PSG en assembleur
Tu peux encore optimiser
Tu gagnes 8 cycles.
Mais là, le code peut peut-être être plus difficile à comprendre. Edité par Metalion Le 20/01/2021 à 20h20
Code :
; en remplaçant ça:
;------------------
ex de,hl
ld hl,#100
add hl,de
; par ça:
;--------
ex de,hl
ld h,d
ld l,e
inc h
Tu gagnes 8 cycles.
Mais là, le code peut peut-être être plus difficile à comprendre. Edité par Metalion Le 20/01/2021 à 20h20
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)

Metalion :
Tu peux encore optimiser
Tu gagnes 8 cycles.
Mais là, le code peut peut-être être plus difficile à comprendre.
Code :
; en remplaçant ça:
;------------------
ex de,hl
ld hl,#100
add hl,de
; par ça:
;--------
ex de,hl
ld h,d
ld l,e
inc h
Tu gagnes 8 cycles.
Mais là, le code peut peut-être être plus difficile à comprendre.
Alors là, je bug complétement...

"inc h" ça fait pas +256 !?
EDIT: Ah, c'est p'être une confusion. Dans l'assembleur SDDC (asz80), #100 c'est du décimal.
On est toujours ignorant avant de savoir.
aoineko :
EDIT: Ah, c'est p'être une confusion. Dans l'assembleur SDDC (asz80), #100 c'est du décimal.
Oui, c'est une confusion, je pensais que c'était 100h.

MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)

J'ai bien étudié le PSG hier soir et j'ai réécrit la routine qui copie les données décodées par PT3 vers les registres du PSG.
Je suis passé de 906 T-States à 528 !
J'ai déroulé la boucle (l'augmentation de taille du code me semble négligeable pour une routine si importante) et j'ai parallélisé les out et les outi sans jongler avec le registre C.
Ancienne version :
Nouvelle :
Si j'avais une description précise du format PT3, je pourrais surement optimiser la fonction de décodage (la plus grosse et la plus gourmande de la lib) et/ou ajouter des fonctionnalités, mais j'ai rien trouvé.
Enfin, si j'ai trouvé un fichier txt en russe.
J'ai fait de l'ingénierie inverse sur le header et je comprends mieux certaines infos, mais le cœur des données est tellement compacté que c'est vraiment difficile à déchiffrer (surtout en assembleur).
Je suis passé de 906 T-States à 528 !
J'ai déroulé la boucle (l'augmentation de taille du code me semble négligeable pour une routine si importante) et j'ai parallélisé les out et les outi sans jongler avec le registre C.
Ancienne version :
Code C :
// Registers value copy loop xor A // 5 Register number (0 to 13) ld C, #PSG_PORT_REGS // 8 Port number ld HL, #_g_PSG_Registers // 11 Data to copy to PSG registers RegCopyLoop: out (C), A // 14 port_reg <- reg_num inc C // 5 outi // 18 port_data <- data[i++] dec C // 5 inc A // 5 cp #13 // 8 jr NZ, RegCopyLoop // 13/8 out (C), A // 14 ld A, (HL) // 8 and A // 5 ret M // 12 inc C // 5 out (C), A // 14
Nouvelle :
Code C :
// Registers value copy loop ld HL, #_g_PSG_Registers // 11 Data to copy to PSG registers ld C, #PSG_PORT_DATA // 8 Setup outi register xor A // 5 Initialize register number // R#0-12 .rept 13 out (PSG_PORT_REGS), A // 12 port_reg <- reg_num outi // 18 port_data <- data[i++] inc A // 5 .endm // R#13 out (PSG_PORT_REGS), A // 12 port_reg <- reg_num ld A, (HL) // 8 and A // 5 ret M // 12 don't copy R#13 if value is negative out (PSG_PORT_DATA), A // 12 port_data <- data[i]
Si j'avais une description précise du format PT3, je pourrais surement optimiser la fonction de décodage (la plus grosse et la plus gourmande de la lib) et/ou ajouter des fonctionnalités, mais j'ai rien trouvé.
Enfin, si j'ai trouvé un fichier txt en russe.

J'ai fait de l'ingénierie inverse sur le header et je comprends mieux certaines infos, mais le cœur des données est tellement compacté que c'est vraiment difficile à déchiffrer (surtout en assembleur).
On est toujours ignorant avant de savoir.

ericb59 :
hummm
Quelles valeurs ont donc tes constantes STP ? (_g_PSG_Registers, PSG_PORT_DATA, PSG_PORT_REGS)
Quelles valeurs ont donc tes constantes STP ? (_g_PSG_Registers, PSG_PORT_DATA, PSG_PORT_REGS)
Code C :
u8 g_PSG_Registers[14]; // Mon buffer de registres du PSG #define PSG_PORT_REGS 0xA0 ///< Used to select a specific register by writing its number (0 to 15) #define PSG_PORT_DATA 0xA1 ///< Used to write to any register once it has been selected by the Address Port. #define PSG_PORT_STAT 0xA2 ///< Used to read any register once it has been selected by the Address Port.
On est toujours ignorant avant de savoir.

Si ça peut aider, c'est fait pour. 
Toi qui aime le code généraliste, tu pourrais même mettre ça :
Bon, par contre, j'ai un gros soucis, c'est que j'arrive pas à faire fonctionner le décodeur PT3 parfaitement quand la frame gameplay dure plus longtemps qu'une frame graphique.
Ca donne des sons tout cassés (comme j'avais avant).
C'est bizarre car toute ma partie d'update du son est fait dans le hook H.TIMI est dure pas longtemps (~1/5 de frame voir moins).
Du coup, je comprends pas comment la longueur de la frame gameplay peut influer sur mon code du H.TIMI...

Toi qui aime le code généraliste, tu pourrais même mettre ça :
Code C :
#ifdef __SDCC_OPTIMIZE_SIZE // version original #else // ma version #endif
Bon, par contre, j'ai un gros soucis, c'est que j'arrive pas à faire fonctionner le décodeur PT3 parfaitement quand la frame gameplay dure plus longtemps qu'une frame graphique.
Ca donne des sons tout cassés (comme j'avais avant).
C'est bizarre car toute ma partie d'update du son est fait dans le hook H.TIMI est dure pas longtemps (~1/5 de frame voir moins).
Du coup, je comprends pas comment la longueur de la frame gameplay peut influer sur mon code du H.TIMI...

On est toujours ignorant avant de savoir.

@Eric, tu pourrais essayer ton sample PT3 en faisant ramer la boucle principale (pour qu'elle dure plusieurs frames graphiques) et me dire si ça impacte la musique ?
D'une musique à l'autre, la perte de qualité est très disparate donc si tu peux essayer plusieurs musique, ça serait cool.
D'une musique à l'autre, la perte de qualité est très disparate donc si tu peux essayer plusieurs musique, ça serait cool.
On est toujours ignorant avant de savoir.

C'est bon, j'ai trouvé !
La version du PT3 que j'ai récupéré utilisait le registre IX... registre utilisé par SDCC pour gérer la pile.
Du coup j'ai tout passé sur IY et ça marche nickel.
Encore un mystère résolu !
@Eric, j'ai check sur Fusion-C ; vous avez le même problème, mais vous avez ajouté des push/pop à toutes les fonctions donc normalement c'est safe.
La version du PT3 que j'ai récupéré utilisait le registre IX... registre utilisé par SDCC pour gérer la pile.

Du coup j'ai tout passé sur IY et ça marche nickel.
Encore un mystère résolu !
@Eric, j'ai check sur Fusion-C ; vous avez le même problème, mais vous avez ajouté des push/pop à toutes les fonctions donc normalement c'est safe.

On est toujours ignorant avant de savoir.

Oui, sa version 1.2. Fusion-C utilise la 1.1 je crois.
J'ai pas regardé dans le détail, mais d'après les commentaires la seule différence c'est de pouvoir initialiser les tables de notes depuis l'application.
Ceci dit, y a maintenant beaucoup plus de différences entre ma version et la 1.2 qu'entre toutes les versions précédentes.
J'ai pas regardé dans le détail, mais d'après les commentaires la seule différence c'est de pouvoir initialiser les tables de notes depuis l'application.
Ceci dit, y a maintenant beaucoup plus de différences entre ma version et la 1.2 qu'entre toutes les versions précédentes.

On est toujours ignorant avant de savoir.

J'ai fini une premier passe de clean sur le player PT3 :
- Ajout d'une option pour virer les 100 octets d'entête (pratique pour les ROM),
- Ajoute d'une fonctionnalité pour mute les channels indépendamment,
- Ajout de quelques fonctions pour lire l'état du player,
- Optimisation / clean d'une partie du code.
Voici un petit sample : s_pt3.rom.
Bon, dans 32K, j'ai pu mettre que 3 musiques, mais ça permet de tester que tout fonctionne bien.
@Eric, c'est archivé sur GitHub si tu veux jeter un œil.
Par contre, je trouve le code de décodage vraiment très très sale.
Y a quasiment pas de commentaire, le nom des labels est imbitable et à chaque fois que je comprends de quoi il s'agit, je me rends compte que c'est pas écrit de façon optimal.
Le fait que la description du format soit introuvable est très problématique.
Bref, je vais laisser PT3 en l'état pour le moment et je vais tenter d'intégrer un autre player...
J'hésite entre Arkos, WYZ et TriloTracker...
Je vais creuser la question
- Ajout d'une option pour virer les 100 octets d'entête (pratique pour les ROM),
- Ajoute d'une fonctionnalité pour mute les channels indépendamment,
- Ajout de quelques fonctions pour lire l'état du player,
- Optimisation / clean d'une partie du code.
Voici un petit sample : s_pt3.rom.
Bon, dans 32K, j'ai pu mettre que 3 musiques, mais ça permet de tester que tout fonctionne bien.

@Eric, c'est archivé sur GitHub si tu veux jeter un œil.
Par contre, je trouve le code de décodage vraiment très très sale.

Y a quasiment pas de commentaire, le nom des labels est imbitable et à chaque fois que je comprends de quoi il s'agit, je me rends compte que c'est pas écrit de façon optimal.
Le fait que la description du format soit introuvable est très problématique.
Bref, je vais laisser PT3 en l'état pour le moment et je vais tenter d'intégrer un autre player...
J'hésite entre Arkos, WYZ et TriloTracker...
Je vais creuser la question
On est toujours ignorant avant de savoir.

Cool ! 
Tu devrais t'attaquer au replayer AYFX plutôt
La version qui utilise la routine play du PT3 est ici ;
https://github.com/theNestruo/msx-msxlib/tree/master/libext
Il n'y a pas des masses de code... Edité par ericb59 Le 24/01/2021 à 10h32

Tu devrais t'attaquer au replayer AYFX plutôt

La version qui utilise la routine play du PT3 est ici ;
https://github.com/theNestruo/msx-msxlib/tree/master/libext
Il n'y a pas des masses de code... Edité par ericb59 Le 24/01/2021 à 10h32

Le replayer ayFX a été super simple à ajouter.
Je suis partie de la version originale de SapphiRe (j'ai été échaudé par les versions passées entre plusieurs mains).
Ca fait du bien d'avoir du code propre et bien commenté !
J'ai ajouté pas mal de fonctions de get/set des données mais sur le cœur du code, je prévois qu'une modification (utiliser un pointer de fonction pour simplifier le code spécifique à 1 canal).
C'était quoi le problème de Fusion-C en utilisant ayFX et PT3 ?
Tout à l'air de bien fonctionner.
Je suis partie de la version originale de SapphiRe (j'ai été échaudé par les versions passées entre plusieurs mains).
Ca fait du bien d'avoir du code propre et bien commenté !

J'ai ajouté pas mal de fonctions de get/set des données mais sur le cœur du code, je prévois qu'une modification (utiliser un pointer de fonction pour simplifier le code spécifique à 1 canal).
C'était quoi le problème de Fusion-C en utilisant ayFX et PT3 ?
Tout à l'air de bien fonctionner.
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie