Récupérer un nombre - Page 2

J'ai trouvé le problème, il suffisait de mettre lea ptridle(PC),a0 au lieu de move.l ...

Le problème n'ai pas corrigé j'ai même mis movea et ça marche pas.
Qu'est ce-que je doit faire pour que cette adresse soit paire?

le problème vient peut-être d'ailleurs

J'arrive pas à trouver

Est-ce qu'il est possible de lire un octet puis un mot puis un octet puis un mot... de telle sorte qu'on incrémente de 3 l'adresse contenu dans ptridle et ainsi alterner les données mot, octet....

C'est pas une bonne idée

Bas c'est la meilleurs idée que je trouve pour compromis mémoire et vitesse. Car j'ai pas; envie que les données soit 2x plus grosse et perdre un octet par durée à chaque fois.

geogeo
a écrit : Est-ce qu'il est possible de lire un octet puis un mot puis un octet puis un mot... de telle sorte qu'on incrémente de 3 l'adresse contenu dans ptridle et ainsi alterner les données mot, octet....

Ben non, parce que tu aurais des words à des adresses impaires...

c'est vraiment pas possible!

Tu peux, mais il faut que tu fasses attention.
En fait, je n'avais pas bien compris. Ce que tu veux, c'est stocker des nombres sur 24 bits, n'est-ce pas ?
Dans ce cas, c'est évidemment plus économique de ne pas utiliser des longword. Mais ce sera aussi plus lent à la lecture...

C'est pas vraiment ça, je veut parcourir une liste de valeurs composé de mot pour les fréquences et d'octet pour les durée par exemple:

channel1:
dc.w 4000
dc.b 30
dc.w 1200
dc.b 10
dc.w #FFFF

Voilà et lire ça au fur et à mesur donc avancer de 3 octets à chaque fois.

Ah ben là, c'est clair que tu ne peux pas !
supposons que ton channel1 soit une adresse paire, le word 4000 et correct. Le byte qui suit est à l'adresse channel1+2, mais le word suivant est à l'adresse channel1+2+1, forcément une adresse impaire !

Je vais lire octet par octet et pour former un word je metterais dans les 8 bits de poids faible le première octet et le deuxième dans le poids fort.

En effet, tu peux faire ça à condition de lire octet par octet. Pour lire tes words, utilise ce que j'ai posté dans le message #15.

C'est ce que j'vais epnsais en dernier recourt. Merci Kevin mais c'est dommage qu'il ne soit pas possible de faire ça directement mais bon du temps qu'il y a des méthodes pour contourner ça.

Mais pourquoi tu ne ne fais pas une liste de words et une liste de bytes séparées ?
Ce serait plus simple...

Techniquement c'est possible bien entendus mais en pratique ça complique car voici le problème si je fait ça:

-L'adresse qu'on me donne est l'adresse d'un morceau de musique et je ne sais pas quand ce termine dans ce cas la liste des fréquences et des durée alors que dans mon cas je peux savoir ou ce trouve la durée correspondant à la fréquence.
-La librairie doit au pare avant lire le morceau en entier puis séparer les fréquences et les durée... Hors cela est long et ne me facilite pas la tâche.
-La conception d'effet sonores serat complexe car il faudrat séparer les fréquences des durée et déjà que c'est difficile de faire des effets sonores corrects alors séparer les fréquences... c'est encore plus long.
-Grand ralentissement pour changer de morceaux bref la galère.

Le format mot,octet,mot,octet... c'est l'idéal pour moi et pour les utilisateurs reste plus qu'à trouver une méthode de lecture.

kevin>JE viens de faire t'as mléthode avec lsl et je suis obliger de passer par des registre comme d0 car sinon le compilateur me renvoie un message d'erreur: adresing mode not allowed here. Même en passant par registre les valeurs retourné sont fausse, elle doivenet être décalé et même en changant lsl #8,... par muls #256,... ça n'y change rien, peut être que je lis à l'envers. Pour le problème e plantage j'ai corrigé car en effet j'ai mal passé l'argument dans de la pile. Reste plus que ce problème.

J'ai trouvé le problème la routine fonctionne bien mais y a un problème avec le compilateur car quand je fait ceci:

channel2:
dc.w 10
dc.b 30
dc.w 65534
dc.b 30
dc.w 65535

Dans le fichier o je constate ceci:
 ÿþ ÿÿ

Ce qui signifie que le compilateur met autmatiquement les octets sur une adresse paire donc ma liste devient:

channel2:
dc.w 10
dc.b 30
dc.b 0
dc.w 65534
dc.b 30
dc.b 0
dc.w 65534

Donc les dc.b m'enerve ici car fausse mon programme et font perde de la place, n'y aurait t'il pas une autre méthode d'écriture de données sans avoir des dc.b 0 ajouté (des caractères null).

Je crois qu'il existe ds mais aucune doc ne précise les fonctions du même type que dc ou ds.

Ca ne devrait pas faire ça. prend un vrai éditeur hexa plutôt qu'ouvrir en mode texte, certains caractères ne sont pas affichés et faussent donc la vision que tu as du fichier si tu l'ouvres sous notepad par exemple.

Sinon, tu écris chaque octet un par un :
au lieu d'écrire :
dc.w $1456
tu mets :
dc.b $14,$56

Bien sûr qu'il existe cette solution là mais ça complique beaucoup de choses pour moi car je parle de programmes externe en plus cette méthode est sale. Ya vraoment pas moyenne au compilateur de dire de ne pas ajouter des caractères null pour avoir des adresses paires en permanence?

normalement il ne les mets pas ces octets nuls, sauf si tu les réclames avec un EVEN. tu es certain qu'ils y sont?

even

channel2:
dc.w 10
dc.b 30
dc.w 65534
dc.b 30
dc.w 65535
end

Je ne rajoute aucun even entre chaque octet. Je peux assurer que le compilateur ajoute des caractère null et ceux sans que je le demande, cela est peut être dû au fait que j'alterne mot,octet... et que de lui même il ajoute un caractère null. Ca ne serait pas un bug du compilateur ASM de TIGCC ou ce que je demande est trop compliqué.

Vraiment je ne comprend pas.

En HEXA avec Visual C++ 6.0:

00 0A 1E 00 FF FE 1E 00 FF FF
------- -- ------ -- -----
w10 b30 w65534 b30 w65535

Là on voit vraiment que le compilateur rajjoute des octets.

Comme je disais ça n'est pas normal...

Donc c'est un bug.

quoique c'est peut-être voulu mais ça me parait étrange... vais voir la doc tiens

Oui, ce n'est pas normal...

J'ai regardé dans la doc et je trouve rien à ce sujet seulement des exemples expliquant comment utiliser dc.[b,w,l]

Y'a encore bcp de risques avec db92?