Questions ASM
-
Si tu as compris le principe d’une copper-list, c’est exactement ce que tu as sous les yeux….
C’est pareil qu’à partir de “bplptr” ! Une série de “move” qui charge les divers registres avec une valeur !Par exemple, la ligne concernée par “; clear spriteptrs” :
$0120,$0000 équivaut à un move.w #$0000,$dff120 (où $dff120 = $dff000 (base des custom chips) + $0120 (offset qui mène au pointeur du sprite 0))
Ou si tu préfères, à partir de l’adresse de base des custom chips ($dff000) on ajoute $0120 et on y mets des zéros. C’est le principe du MOVE d’une copper-list…A500 (1.3 / 2.0 / ACA500+) - A2000 - A1200
Alors là si tu commence à vouloir attaquer directement le hard je te conseil de mettre la main soit sur les RKM soit sur la bible amiga (celle de micro application pas le bouquin de Titan) tu auras toutes les réponses à ce genre de questions.
Donc là les deux premier move servent juste à garder un compatibilité entre AGA et non AGA (le 106 sert, entre autre, a gérer la nouvelle palette de 256 couleurs et le 1fc te permet de passer en mode burst).
Sur amiga tu peux dire au contrôleur vidéo à quelle cycle de ligne il doit démarrer le décodage de l’image (tu peux donc facilement faire de l’overscan), c’est le role des registre 8e et 90, les valeurs sont un peu inscrite dans la pierre (en gros tu ne peux pas mettre n’importe quoi) en plus plus tu défini un écran large plus tu vas empiéter sur les cycles des autres composant DMA (comme les sprites).
92 et 94 te servent à placer ton écran sur ton moniteur (du coup si tu fais un overscan faudra le placer plus a gauche), la pareil les valeurs sont généralement déterminées par rapport à 8e et 90.
102 a 108 ça sert à contrôler l’affichage (priorité des sprite, fine scrolling, etc) et après c’est les adresse des sprites hard (donc là 0 vue que t’en utilise pas)
voilà
La valeur $1A64 se réfère donc au registe $dff08e (ou “DIWSTRT”, position de départ de l’écran).
Cette valeur est à “couper en deux”: 1A pour la position vertical de départ, et 64 pour la position horizontale de départ (tout ça en héxadécimal bien sûr, donc en décimal ça donne : un début de fenetre aux coordonnées 26,100)A500 (1.3 / 2.0 / ACA500+) - A2000 - A1200 
Mod Concernant move.l 4.w, a6
Le move se fait bien sur 32 bits vers le registre A6, cependant, le .w indique simplement à l’assembleur que le 4 peut être codé sur 16 bits au lieu de 32.
Voici le résultat en opcode des instructions :
move.l 4.w, A6 -> 2C780004
move.l 4.l, A6 -> 2C7900000004
En fait, tout assembleur un peu sérieux n’a pas besoin du .w pour ‘optimiser’ la taille de la valeur immédiate.
Le gain est de 2 octets avec la forme .w et ne permet que le chargement d’une adresse sur 16 bits soit les 64 premiers Ko…
Cependant, si l’assembleur utilisé est lazy, il se peut qu’il n’utilise que le stockage en 32 bit de la valeur immédiate par soucis de simplicité.
Le seul intérêt du .w est d’être sûr que l’assembleur utilise la forme immédiate sur 16 bits et non 32 bits.
Egalement, le suffixe .w et .l peut être utile pour forcer la taille de la valeur immédiate lors de la compilation. Dans le cas d’un code qui s’automodifie (booo honte à toi! :)), on pourrait avoir besoin de 32 bits. Le .l serait alors utile pour forcer la main à l’assembleur et avoir l’instruction avec un stockage sur 32 bits de la valeur immédiate.
++
Mod @Tcheko: oui, en fait il s’agirait d’un move.l $4.w,a6 qui n’a de toute façon aucune utilité puisque le mot long (.l) est pris en compte quoiqu’il arrive (seul un move.w fonctionnerait)
De plus, si un move.w $4,a6 donnerait A6=0000XXXX , un move.l $4,a6 donnerait A6=XXXXXXXX et non pas XXXXXXXXXXXX , comme tu l’écris dans ton example “move.l 4.l, A6 -> 2C7900000004” (c’est du 48 bits là !)
@bombseb: si tu as vu morceau de code avec un “move.l 4.w, a6” , sache que ça n’a aucun effet et que ça revient exactement à un “move.l 4,a6” (les 32 bits situés à l’adresse 4 sont récupérés dans les 2 cas !). Je ne comprends meme pas pourquoi certains se sont emmerdés à ecrire ce genre de code…A500 (1.3 / 2.0 / ACA500+) - A2000 - A1200
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › Questions ASM