Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Programmation : Assembleur - Tests logiques avec le Blitter
(Article écrit par Frédéric Mazué et extrait d'Amiga News Tech - avril 1990)
|
|
Nous commençons sans plus attendre avec les tests logiques. Ceci concerne les Minterms. Savoir bien les utiliser c'est
aussi savoir bien utiliser le Blitter. Il est ainsi possible par exemple d'éviter que deux images se superposent.
Voyons donc le premier programme. C'est un exemple d'utilisation des Minterms qui montre la possibilité de faire un test
logique avant la recopie d'une image.
Comme le mois dernier, les bibliothèques nécessaires sont ouvertes,
un écran à deux plans de bits est
ouvert et le programme se réserve l'usage du Blitter. Un écran Intuition à deux plans de bits est
ainsi fait qu'un bit mis dans le premier plan de bits allumera un point de couleur blanche et un bit
mis dans le deuxième plan de bits allumera un point de couleur noire.
Tests logiques
Ceci à la condition bien sûr d'utiliser les préférences du Workbench sans modification. Sinon vous
verrez apparaître les couleurs 2 et 3 de vos propres préférences. La première image est copiée dans
le premier plan de bits exactement de la même façon que dans l'exemple du mois dernier. C'est-à-dire
que le Blitter tient seulement compte du contenu de la source A. L'image apparaît en blanc.
La deuxième image est elle aussi copiée dans le deuxième plan de bits de la même façon qu'à l'endroit où
la deuxième image chevauche la première, la couleur change et devient orange. L'explication est
que lorsque un bit est mis en même temps et au même endroit dans les deux plans de bits on obtient
la couleur numéro 4.
Comment éviter cet effet désagréable ?
Il faut tester si des points sont allumés dans le premier plan de bits dans la zone correspondante sur
l'écran à l'endroit où l'on veut allumer des points dans le deuxième plan de bits. Pour cela,
on fait pointer BLTDPTH à l'endroit où l'on veut transférer l'image. Pour l'instant, c'est comme
d'habitude. On fait pointer BLTAPTH sur les données de l'image, c'est toujours comme d'habitude.
Enfin, on fait pointer BLTBPTH dans le premier plan de bits à l'endroit correspondant sur l'écran à
la position "écran" de la deuxième image (attention à la valeur modulo). Voir dans le listing
les lignes toutes prêtes à être ajoutées.
Il suffit maintenant de choisir les Minterms afin que le Blitter ne transfère les bits de la
source A dans le deuxième plan de bits uniquement quand les bits de la source B (premier
plan de bits et donc image blanche) ne sont pas mis.
Détermination des Minterms
On veut la source A. Les bits LF0-LF3 correspondant aux combinaisons "abc abC aBc aBC"
sont donc éliminés et il reste avec les bits LF4-LF7 les combinaisons suivantes :
"Abc AbC ABc ABC". Maintenant, on ne veut pas la source B. Il faut donc éliminer les combinaisons
"ABc" et "ABC" et il ne reste plus que les combinaisons "Abc" et "AbC" correspondant aux bits
LF4 et LF5. Il faut conserver ces deux bits afin d'annuler les effets de la source C.
Il ne faut pas oublier d'activer le DMA B. Ainsi, l'instruction
move.w #%0000100111110000,BLICON0(a0) doit donc être remplacée par
move.w #%0000110100110000,BLICON0(a0) comme expliqué dans le programme.
Les masques
Le Blitter peut, mais seulement pour la source A, modifier le début et la fin de chaque ligne d'une
image. Le registre BLTAFWM doit contenir la valeur du masque pour le mot de début de ligne.
Le registre BLTALWM doit contenir la valeur du masque pour le mot de fin de ligne. Le Blitter fera
un "ET" logique entre le contenu de ces registres et les mots de début et de fin de ligne.
Attention : si vous ne mettez rien dans ces registres, ils contiendront quand même quelque
chose et le Blitter fera son "ET" logique quoi qu'il en soit. Donc gare aux mauvaises surprises
dans le cas où ces registres ne seraient pas initialisés correctement.
Deuxième programme
C'est une démonstration des possibilités de masquage offertes par le Blitter.
Pour la première image, les masques sont "#$ffff", ceci s'écrit en binaire "#%1111111111111111".
Tous les bits y sont donc, le "ET" logique ne modifiera rien et l'image apparaît en entier.
Pour la deuxième image, les masques sont "#$5555", ceci s'écrit en binaire "#$0101010101010101".
Un bit sur deux va disparaître à l'issue du "ET" logique. L'image perd donc un point sur deux
au début et à la fin de chaque ligne.
Pour la troisième image, les masques sont "#$0000". Tous les bits disparaissent.
L'image est carrément amputée à chaque extrémité.
Il ne faut pas négliger cette possibilité de masque qui peut s'avérer très utile. Nous en verrons
une application lors de la programmation de défilement.
Deuxième possibilité de masque
Si on bloque un canal DMA, par exemple le DMA C, le registre BLTCDAT qui correspond à ce canal
contient de toute façon quelque chose. Plus encore, il est possible de charger soi-même ce registre
afin qu'il contienne ce que l'on désire. Quand le Blitter commencera son travail, le contenu du
registre BLTCDAT ne sera pas modifié puisque le canal DMA C est bloqué. Le Blitter fera alors
à chaque mot traité une opération logique entre le mot de donnée et le contenu de BLTCDAT.
Cette opération logique étant définie par les Minterms.
C'est ce qui se passe pour la mise en place de la quatrième image par le deuxième
programme : le canal DMA C est bloqué et BLTCDAT est chargé avec la valeur "#$5555".
Les Minterms choisis correspondent aux combinaisons "ABC" et "AbC". On voit que la source B
n'intervient pas et qu'il faut à la fois un bit de la source A et un bit de la source C pour
que le Blitter mette un bit dans la cible. Comme BLTCDAT contient "#$5555",
chaque ligne de l'image perd un point sur deux. Soit dit en passant, c'est exactement de cette façon
que le système d'exploitation de l'Amiga décode les données lues sur disquette.
Théoriquement, chaque source peut masquer ou peut être masquée par n'importe qu'elle autre.
Toutefois, si on essaie de masquer la source A par la source B on risque de se heurter à un petit bogue.
Petit bogue
Dans le deuxième programme se trouve une ligne marquée "1" et une ligne marquée "2".
A la place de l'instruction en "1" mettez move.w #%0000100111000000,BLTCON0(a0)
et à la place de l'instruction en "2" mettez move.w #$5555,BLTBDAT.
Ainsi, la source A devra être masquée par le contenu de BLTBDAT ($5555) et c'est bien ce qui se
passe lorsqu'on essaie le programme. Et alors ce bogue, où est-il ?. Eh bien ce bogue
ne se manifeste pas de manière régulière. Il semble apparaître selon le type de la dernière
opération traitée par le Blitter.
Troisième programme
Ce n'est rien d'autre que le deuxième programme duquel on a extrait la partie concernant le
masque par une source. Mais ici, la source A est masquée par le contenu de BLTBDAT. Si vous
essayez ce programme, vous pourrez constater que cette fois rien n'apparaît dans notre écran :
le Blitter a refusé de travailler et pourtant le programme est théoriquement correct !
Les remèdes ? Il y en a deux possibles : le premier consiste à rajouter à la ligne "1"
l'instruction move.w #$5555,BLTBDAT(a0), ce qui revient à charger deux fois de suite le registre BLTBDAT avec la même valeur.
Assemblez le programme : ça marche. Mais cette solution n'est pas très esthétique
dans un listing.
Le deuxième remède consiste à charger BLTBDAT après avoir chargé BLTCON1.
Essayez en supprimant les deux instructions move.w #$5555,BLTBDAT(a0)
en "1" et en mettant une seule instruction move.w #$5555,BLTBDAT(a0)
en "2", c'est-à-dire après l'initialisation de BLTCON1. Assemblez le programme : ça marche
également. Curieux, non ?
J'ai découvert ce petit bogue après avoir cherché des heures durant pourquoi un
de mes programmes ne tournait pas convenablement. Ce fut très dur... Aussi,
je me permets de vous recommander dans tous les cas d'initialiser BLTBDAT après
avoir initialisé BLTCON1 pour éviter les mauvaises surprises et autres caprices
blitteresques...
Mais attention : je viens de vous décrire un bogue de mon Blitter à moi (Amiga 500).
Je ne sais pour le moment absolument pas ce qu'il en est avec le nouveau Fat Agnus.
C'est tout pour cette fois. Le mois prochain nous verrons comment programmer le Blitter
pour les défilements. Et avec tests de collisions s'il vous plaît !
|
