PolySnd - Page 47

Ximoon :
Tu radottes petit

Non, je répète parce que visiblement, tu n'as pas compris...

--register-prefix-optional
Since the compiler as configured for TIGCC does not prepend an underscore to the names of user variables, the assembler requires a % before any use of a register name. This is intended to let the assembler distinguish between C variables and functions named a0 through a7, and so on. The '--register-prefix-optional' option may be used to permit omitting the % even in TIGCC. If this is done, it will generally be impossible to refer to C variables and functions with the same names as register names.

Je signale aussi que la syntaxe de GNU as est généralement plus flexible que celle de A68k. GNU as n'a pas besoin d'indentation pour distinguer les instructions des labels, et il comprend plusieurs syntaxes: (%a0)+ ou %a0@+, 6(%a0) ou (6,%a0) ou (%a0,6) ou %a0@(6), ...

Ceci dit y'a pas que ça ...

Il y a quoi aussi?

.asciiz et cie... enfin chacun ses goûts.
jbne c'est pas beau.
Autant respecter la syntaxe officielle nan? Toi qui est toujours en train de faire de la pub pourles formats natifs?

Ximoon
: .asciiz et cie... enfin chacun ses goûts.

.asciz est pratique parce que ça termine automatiquement la chaîne par un 0.

jbne c'est pas beau.

Mais c'est très utile et flexible. C'est un des avantages les plus importants de GNU as: une seule instruction qui sera transformée en la bonne taille automatiquement, même s'il faut un jmp.

Et le standard?
Ceci dit ça ressemble presque à un compilo pour assisté si tu sais pas faire la bonne taille de branchement tout seul... Surtout que des jmp ça arrive souvent à l'intérieur d'un programme asm de moins de 32ko tiens ...

Hier quand tu as écrit le post #1361 le fichier que j'uploadé était identique à la version précédente en date et contenu et donc je n'ai pas osser te le dire, donc je me suis dit que j'allais tester cette version aujourd'hui.

Ah bon? C'est bizarre ça... tu l'as peut-être téléchargé en plein uploadage. Aujourd'hui c'est bon?

Si bit en cours et à 1 impulsion sinon pas impulsion

Heu non... Je ne fais pas d'impulsion si le bit est à 1, je ne fais d'impulsion que si l'état change entre deux -> un bit passe de 1 à 0, et inversément. Mais qu'entends-tu par "une impulsion"? Tu mets le port à 0 puis à 1 de nouveau?

Donne moi les fichiers avec ce genre de qualitée ou essaye de nous faire écouter un enregistrement

Ces fichiers sont tout simples... Ce sont des musiques de jeux divers n'excédant pas une minute. La qualité, 8kHz 1 bit Mono, est respectable.

En plus de ça il existe une fonction pour répéter ce bit plusieurs fois et ça améliore la qualitée en 1 bit mais la consommaton CPU monte.

Voilà ce que je trouvais bizarre; si un bit est à 1, tu vas en fait remettre plusieurs fois de suite le port à 1, ce qui n'augmente (théoriquement) pas la qualité. Maintenant il se peut que mon algo soit incorrect.
En gros, il ne faut pas mettre plusieurs octets par ligne en A68k? Je vais également faire pour le GNU AS, si quelqu'un pouvait me donner un aperçu de ce que ça pourrait donner...

Tu as testé sur TI avec ton algo en C du jeux tetrisse?

Je n'ai pas testé avec Tétrisse mais avec le projet Sound, et on-calc en plus. Il date de Sound.exe et ça doit être exactement le même que Tétrisse.

--register-prefix-optional, c'est pour les chiens?

Si tu pouvais me dire comment tu définirais un sprite en GNU AS, ça pourrait être sympa... Un truc qui prenne le moins de temps possible à la compilation.

Heu non... Je ne fais pas d'impulsion si le bit est à 1, je ne fais d'impulsion que si l'état change entre deux -> un bit passe de 1 à 0, et inversément. Mais qu'entends-tu par "une impulsion"? Tu mets le port à 0 puis à 1 de nouveau?

Tout simplement si le bit est à un le port I/O est mis à 1 est inversement.
Dans ton cas tu essaye de me dire que si bit à 1 tu inverse l'état du port sinon tu fait rien?

Ces fichiers sont tout simples... Ce sont des musiques de jeux divers n'excédant pas une minute. La qualité, 8kHz 1 bit Mono, est respectable.

Dans ce cas tu pourrais me les envoyer et faire juste un enregistrement pour que je puisse comparer et si la qualitée et meilleur trouver l'algo, ça ne pourras que améliorer tout les format (1,2 4 bits).

En gros, il ne faut pas mettre plusieurs octets par ligne en A68k? Je vais également faire pour le GNU AS, si quelqu'un pouvait me donner un aperçu de ce que ça pourrait donner...

Si tu peut mais dans ce cas tu doit ne pas faire d'espace entre donc ça donne:

dc.b $68,$47,$FF...

Si tu pouvais me dire comment tu définirais un sprite en GNU AS, ça pourrait être sympa... Un truc qui prenne le moins de temps possible à la compilation.

Avec la fonction .byte suivit des octets de ton sprite ou .word ou .long.

C'est d'ailleurs ça que j'aime bien avec GNU AS.

Un exemple?
.byte $01,$02,$03,$04,$05
Je ne crois pas trop...

Play0:
.word -32768
.word -16384
.word -8192
.word -4096
.word -2048
.word -4096
.word -8192
.word -16384
.word -32768
.even

Code produit par TIGCC mais tu peut faire des modife surtout sur les nombre....

OK mais j'utilise des byte. Ton algo aussi?

#1388 : sa ne change rien

car
.word 0x1234

equivaux a

.byte 0x12, 0x34

(sur un 68000 cela s'entend ! sur un x86 sa serait plutot
.byte 0x34, 0x12 )

Brunni :
Un exemple?
.byte $01,$02,$03,$04,$05 Je ne crois pas trop...

Non. C'est:
.byte 0x01,0x02,0x03,0x04,0x05
(et les espaces sont tolérées, contrairement à A68k).

Ximoon
: Ceci dit ça ressemble presque à un compilo pour assisté si tu sais pas faire la bonne taille de branchement tout seul... Surtout que des jmp ça arrive souvent à l'intérieur d'un programme asm de moins de 32ko tiens ...

Alors tu appelles aussi A68k de l'assisté vu qu'il te permet d'écrire bra et d'avoir la taille choisie tout seul?
Dans GNU as, au moins on voit clairement que c'est "de l'assisté" comme tu l'appelles, parce que l'instruction est codée exprès pour ça.

godzil :
.word 0x1234
equivaux a
.byte 0x12, 0x34
(sur un 68000 cela s'entend ! sur un x86 sa serait plutot .byte 0x34, 0x12 )

C'est cette histoire de Big Indian? J'aurais pensé, mais ce que je voulais savoir c'est si geogeo utilisait des mots plutôt que des octets pour son algo...

Kevin> Merci. Je vais m'amuser! Mais j'ai plus beaucoup de place sur cette pauvre boîte de dialogue

J'aurais pensé, mais ce que je voulais savoir c'est si geogeo utilisait des mots plutôt que des octets pour son algo...

Pourquoi cette question? Tu parle de mon algo WAV dans la librairei PolySnd? Il lit octet par octet.

Brunni
: C'est cette histoire de Big Indian?

Big Endian, pas Big Indian.

Je trouve que les possibilités de GNU AS que tu as décrites sont inintéressantes, parce que j'aime vraiment contrôler ce que je code, spacialement quand je code en ASM. Donc les optimisations d'instructions, je préfère les faire moi même.
Sinon, c'est vrai que c'est pratique qu'il permette une certaine flexibilité dans la syntaxe.

Brunni, excuse moi de pas tester réellement ton convertisseur mais c'est juste qu'il faut que j'améliore mes routines, parce que niveau vitesse c'est pas trop ça.

Bon a votre avis le son sera de meilleur qualitée comme ça:

Si le bit est à un, le port I/O est si à 1 sinon 0.

Ou comme ça:

Si le bit change d'état le port I/O passe à 1 sinon 0.


En théorie dans la méthode 2 le son devrait être plus faible et avoir un son un peu mieux au point de vue des pics de volumes mais pas, pour ce qui est dans des volumes presque constant.

Alors que dans la 1 le volume devrait être fort et privilégier les fréquences inutile donc craquements... mais permettre une meilleur gestion des volumes.

Brunni> Si tu as réalisé cette algo, peut tu me l'envoyer pour que je compare avec le mien et ainsi améliorer mon algo. Je n'ai pas trop envie de faire un travil supplémentaire inutile pour tout avouer car si je touche à un mode (1, 2, 4 bits) je touche à tout l'algo.

L'algorithme correct est le premier.

C'est bien ce que je pensais.
Mais peut être que la méthode de Brunni apportera quelque chose.

sa ne change rien !

le seul truc qui va changer c'est qu'il faudra stoquer les wav differement

d'ailleur la seconde méthode risque de mieux "supporter" la compression


Se que je veux dire si ton wav est :

10110101110101111000010110001

en méthoe 1 sa sera identique
et en méthode 2 tu stoquera :

11101111001111000100011101001

On vois tt de suite qu'il y a plus d'allignement de bits donc sa porte bcp plus a la compression

enfin de tte tu fait comme tu veux, mais la remarque de KK est infondé

Et si ton wav est :
11001100110011001100

La deuxième méthode donnera :
10101010101010101010

C'est mieux hein pour compresser

jackichan > il y auras toujours des cas pour démonter se que j'ai pu dire, mais en pratique sur un wav tu tombera rarement sur se cas de figure..

Comment tu peux en être sûr ?
Moi j'ai juste trouvé un exemple où ça compressera mal, mais comment savoir comment ça se comportera en général ?

je dit pas que sa arriverait jamais mais c juste que le format wav est une transcription d'un phénoméne réel et tu trouvera rarement quelque chose d'aussi "parfait" dans un phénomene reel...le seul moyen (et encore?) pour avoir un son 'pur' en wav est de le generer par ordinateur je disait juste qu'en regle général utiliser le 1 comme bit de changement sera surement plus approprié pour compresser un wav que la méthode 1

d'ailleur au passage la méthode 2 risque d'etre moins consomatrice en ressource (enfin je sais pas comment marche le link mais je pense que si tu le laisse a 1 il y reste tant que tu y touche pas non ? dans sa cas si tu rencontre un bit a 1 tu a juste a faire un bchg si tu renontre un 0 tu fait rien

alors que la méthode 1 c
1 -> bset
0 -> bclr

godzil tu as tout as fait résond sur la consommation en ressources mais le problème et de changer de format.

Pour la compression je suis un peu d'accord avec la méthode 2 mais je reste septique.

La seul façon de vérifier tout ça est de faire des testes or je ne voit pas comment m'y prendre.


Au faite si le port I/O est un 1 ou 0 il y restera tant que tu ne lui fait pas changer d'états.

geogeo: en nostub tu utilise un .a non ?

ta qua fournir les deux version ?

qu'est-ce tu en pense ?

olalala, déjà avec une version dynamique en C et ASm+ noistub en C et ASm aussi c'est difficile à mettre à jours alors encore une version de plus, là je pete un cable.

Brunni, excuse moi de pas tester réellement ton convertisseur

Bah tant pis c'est pas grave. Désolé poru l'autre fois mais ça m'avait assez énevé.

Si le bit est à un, le port I/O est si à 1 sinon 0.
Ou comme ça:
Si le bit change d'état le port I/O passe à 1 sinon 0. En théorie dans la méthode 2 le son devrait être plus faible et avoir un son un peu mieux au point de vue des pics de volumes mais pas, pour ce qui est dans des volumes presque constant.

La seule méthode utilisable avec mon convertisseur est la première tout simplement parce qu'il a été prévu pour celle-ci
Sinon entre la première et la deuxième méthode il n'y a aucune différence (pour autant que les outils de conversion soient adaptés) et au niveau de la compression, ça se tient.

La seul façon de vérifier tout ça est de faire des testes or je ne voit pas comment m'y prendre.

Ben demande à Brunni qu'il adapte son convertisseur de manière à produire un code utilisable avec la deuxième option...

jackichan > il y auras toujours des cas pour démonter se que j'ai pu dire, mais en pratique sur un wav tu tombera rarement sur se cas de figure..

Hm... tu serais étonné. A mon avis, la méthode #2 n'est pas valable. Maintenant faut essayer, c'est tout.

il n'y a absolument aucune raison que la méthode 2 ne soit pas valable et elle poste plus a compression que la 1 (en tte logique) d'ailleur pour info cette méthode est utilisé dans certain type de transmition fillaire (1 = changement d'etat, 0 = rien ne change)

Oui, je pense également qu'elle est valable.
Quant à savoir si elle se compressera mieux... Je ne sais pas.
J'aimerais qu'on me le démontre.