Obligement - L'Amiga au maximum

Dimanche 15 juillet 2018 - 21:08  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

 · Accueil
 · A Propos
 · Articles
 · Galeries
 · Glossaire
 · Liens
 · Liste jeux Amiga
 · Quizz
 · Téléchargements
 · Trucs et astuces


Articles

 · Actualité (récente)
 · Actualité (archive)
 · Comparatifs
 · Dossiers
 · Entrevues
 · Matériel (tests)
 · Matériel (bidouilles)
 · Points de vue
 · En pratique
 · Programmation
 · Reportages
 · Tests de jeux
 · Tests de logiciels
 · Tests de compilations
 · Articles divers

 · Articles in english
 · Articles en d'autres langues


Twitter

Suivez-nous sur Twitter




Liens

 · Sites de téléchargements
 · Associations
 · Pages Personnelles
 · Matériel
 · Réparateurs
 · Revendeurs
 · Presse et médias
 · Programmation
 · Logiciels
 · Jeux
 · Scène démo
 · Divers


Jeux Amiga

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


Trucs et astuces

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


Glossaire

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


Partenaires

Annuaire Amiga

Amedia Computer

Relec

Hit Parade


Contact

David Brunet

Courriel

 


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.

assembleur
assembleur
assembleur
assembleur

Comme le mois dernier, les bibliothèques nécessaires sont ouvertes, un écran à deux bitplanes est ouvert et le programme se réserve l'usage du Blitter. Un écran Intuition à deux bitplanes est ainsi fait qu'un bit mis dans le premier bitplane allumera un point de couleur blanche et un bit mis dans le deuxième bitplane 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 bitplane 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 bitplane 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 bitplanes 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 bitplane dans la zone correspondante sur l'écran à l'endroit où l'on veut allumer des points dans le deuxième bitplane. 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 bitplane à 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 bitplane uniquement quand les bits de la source B (premier bitplane 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.

assembleur
assembleur
assembleur
assembleur

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 !

assembleur
assembleur
assembleur
assembleur

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 !


[Retour en haut] / [Retour aux articles] [Article précédent] / [Article suivant]