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 - SinusScroll géré par le Blitter (1re partie)
(Article écrit par Little Zeus et extrait d'Amiga News Tech - février 1990)
|
|
Depuis le temps que vous l'attendez, nous vous proposons une explication très facile à
comprendre du fonctionnement complet du Blitter avec son application directe dans un
merveilleux programme, un SinusScroll entièrement géré par le Blitter.
Car, rappelez-vous, notre devise est la "compréhension par l'application", ainsi, si
l'utilisation du Blitter ne vous est pas encore parfaitement claire à la suite de ce numéro, elle le
sera dès que nous l'illustrerons par la routine. Le programme intégral vous est proposé en trois
numéros avec, dès ce mois-ci, une explication générale du Blitter, condition sine qua non pour la
compréhension de la routine.
Blitter, définition
Le Blitter, ou Block Image Transferer, permet principalement de copier des zones de données, le
plus souvent graphiques, en mémoire. Il peut aussi réaliser des décalages de données, des opérations
logiques, tracer des lignes et remplir des surfaces à une vitesse très nettement supérieure à celle du
68000. De plus, Blitter et 68000 peuvent travailler simultanément. Ainsi, si l'Amiga apparaît
comme un merveilleux outil graphique, c'est en grande partie grâce au Blitter. Vous avez
certainement déjà vu ses prouesses dans de beaux défilements de jeux (je ne parle pas des éditeurs qui
font des adaptations d'Atari en se servant uniquement du 68000 pour leurs défilements), dans
des démos à vecteurs, etc.
Dans la mesure où notre routine utilise le Blitter uniquement pour faire des
transferts de données, nous n'étudierons que cette spécificité. Ce qui ne veut pas dire que dans un futur
plus ou moins proche, nous lui ferons exécuter, dans le cadre d'une vecteur-démo, quelques tracés
de lignes...
Le Blitter et la copie de données
Nous allons principalement utiliser dans notre routine la copie de données, dans la mesure où elle
est base de tout défilement. Le mode de copie utilisé par le Blitter est assez simple : celui-ci traite trois
zones sources nommées A, B et C et les unités suivant une opération logique où en inhibe une ou deux. Le
résultat est placé dans une zone cible nommée D. Précisons tout de même que le Blitter ne travaille
qu'en mémoire Chip, c'est-à-dire dans la zone mémoire allant de $0 à $7FFFF et qu'il ne peut copier plus de
128 ko à la fois (c'est déjà pas si mal).
Le Blitter travaille indépendamment du 68000 certes, mais pour être lancé, l'utilisateur se sert de
ce dernier afin de "poker" dans les cases mémoire concernant le Blitter. Ainsi, pour être lancé, le Blitter
"doit avoir pris connaissance" :
- Du mode utilisé, en l'occurrence, on choisit le mode "copie de données".
- De (ou des) zone(s) mémoire source(s) et de la zone cible.
- De la liaison logique.
- De paramètres divers très importants concernant la copie des données.
- De la taille des fenêtres que le Blitter devra traiter.
Les zones de données source et cible
L'Amiga offre quatre paires de registres contenant les adresses de base de chacune des zones de
données. En "pokant" ces valeurs, le Blitter sait à partir de quelles adresses il doit travailler.
Néanmoins résident plusieurs problèmes : vous n'ignorez pas qu'un plan de bits, s'il est représenté à
l'écran en deux dimensions, n'est en mémoire qu'une suite de données unidimensionnelle. Vous
n'ignorez pas non plus que de manière à ce que l'ordinateur sache, au moment d'afficher ces
données à l'écran, à partir de quel octet il doit passer à la ligne suivante, existent des registres en
mémoire spécifiant la largeur et la hauteur des plans de bits. Enfin, si certaines données en fin de
lignes sont indésirables, il vous est possible de les "sauter" au moyen de modulos (si ces motions ne
vous semblent pas très claires, reportez-vous aux premiers articles de la Tube-Intro).
Le Blitter, à quelques petites différences près, traite les zones mémoires de la même manière.
Le registre BLTSIZE précise la hauteur et la largeur des "rectangles-mémoire" à traiter et
les registres BLTAMOD, BLTBMOD, BLTCMOD et BLTDMOD contiennent respectivement les modulos des quatre zones
mémoires A, B, C et D. Le mieux est d'avoir recours à un exemple : imaginons que nous désirions copier
une zone A (correspondant à une partie rectangulaire de plan de bits) en une zone D (qui serait
le plan de bits destination). Voici une zone mémoire :
$0 abcdefgh
$8 ijklmnop
$16 qrstuvwx
|
Chaque lettre représente d'un octet du plan de bits. Imaginons que nous désirions copier la partie du
plan de bits qui a pour coin supérieur gauche "c" et pour coin inférieur droit "u".
Nous devons donc spécifier au Blitter...
- Que la largeur du rectangle à copier fait deux mots (4 octets).
- Que sa hauteur fait trois lignes.
- Que son adresse de base est celle qui contient "c" ($2).
- Que son modulo est de quatre octets (largeur du plan de bits - largeur du rectangle).
Ainsi on copie :
Nous voulons copier cette partie de plan de bits dans un autre plus large :
$0 ABCDEFGHIJKL
$8 MNOPQRSTUVWX
$16 YZ0123456789
|
...à partir de E. En spécifiant que l'adresse de base de "D" est celle contenant "E" ($4)
et que son modulo fait huit octets, on obtient après avoir activé le Blitter :
$0 ABCDcdefIJKL
$8 MNOPklmnUVWX
$16 YZ01stuv6789
|
Le mode ascending et le mode descending
Le Blitter permet deux modes de copie, l'un par incrémentation, l'autre par
décrémentation. Avant d'entrer dans les détails, il convient d'expliquer le déroulement
d'un transfert mémoire effectué par le Blitter. Dès lors que le registre BLTSIZE,
celui qui contient les hauteurs et largeurs des rectangles à traiter, est initialisé,
le Blitter se met en route. Il est donc important d'accéder à ce registre en dernier.
Par défaut, en imaginant que nous désirions copier une zone "A" et le met en première position "D",
puis il en fait de même avec le second, le troisième et ainsi de suite jusqu'au dernier.
N'oublions pas que le Blitter saute le nombre d'octets spécifiés par le modulo à chaque
fin de ligne copiée. Cependant, il peut apparaître un problème si les zones sources et
cibles se chevauchent. Trève d'explications, voici un exemple :
| Adresse |
Données de
la source A |
Données de
la source D |
Résultat après transfert |
| 0 |
A |
|
|
| 2 |
B |
B |
A |
| 4 |
C |
C |
A |
| 6 |
D |
D |
A |
| 8 |
|
E |
A |
Ceci est dû au fait que lorsque le Blitter arrive à l'adresse 2, celle-ci contient "A"
et non plus "B", résultat du transfert précédent. Afin d'échapper à ce problème, il suffit
de demander au Blitter de partir de l'adresse 8 pour aller jusqu'à 0 plutôt que de partir
de 0 pour aller jusqu'à 8, ce qui est fait par défaut. On utilise alors le mode décrémentation
("descending"). Dans notre programme, le mode incrémentation ("ascending") conviendra
parfaitement car notre défilement se fait vers la gauche, c'est-à-dire que les transferts
mémoire se feront vers la base. Dans l'exemple suivant et pour la même raison, le mode
incrémentation serait préférable :
| Adresse |
Données de
la source A |
Données de
la source D |
Résultat après transfert |
| 0 |
|
E |
|
| 2 |
B |
B |
E |
| 4 |
C |
C |
E |
| 6 |
D |
D |
E |
| 8 |
E |
|
E |
En conclusion, on n'utilise le mode décrémentation que pour copier une zone mémoire
source dans une zone mémoire cible la chevauchant en partie et dont l'adresse lui est
supérieure.
Les masques
Le Blitter traite uniquement des mots, c'est déjà pas mal. Mais imaginons que l'image
que nous désirons copier soit large de 7 mots et quelques bits. Comment copier ces quelques
bits supplémentaires ? Heureusement existent deux masques permettant d'inhiber les bits
désirés des mots les plus à droite et les plus à gauche de l'image à transférer.
Seuls sont copiés les bits activés dans les masques Blitter. Remarquons que lorsque
le rectangle mémoire à copier ne fait qu'un mot de large, alors il s'effectue un "et
logique" entre les deux masques, autrement dit, seuls sont conservés les bits étant
activés par les deux masques à la fois. Rappelez-vous bien ceci car nous y ferons
largement appel dans notre SinusScroll.
En ce qui concerne les opérations logiques entre les différentes zones sources,
le plus simple sera d'en voir directement une application dans le prochain numéro.
Nous avons nommé un certain nombre de registres, en voici la liste avec leur utilisation.
BLTCON0
- 15 : valeur de décalage des données la source A.
- 14 : (nous n'en avons pas parlé).
- 13 : cette valeur est exprimée sur 4 bits.
- 12 :
- 11 : active le canal DMA de A.
- 10 : active le canal DMA de B.
- 09 : active le canal DMA de C.
- 08 : active le canal DMA de D.
- 07 à 00 : utiles aux opérations logiques que nous verrons prochainement.
BLTCON1
- 15 : valeur de décalage des données de la source B.
- 14 : (nous n'en avons pas parlé).
- 13 : cette valeur est exprimée sur 4 bits.
- 12 :
- 11 à 05 : inutilisées.
- 4 : bits servant au remplissage de surfaces.
- 3 : (nous n'en avons pas parlé).
- 2 :
- 1 : mettre à 1 pour le mode décrémentation.
- 0 : mettre à 0 pour la copie de données.
Pour utiliser le Blitter, les 4 canaux DMA le concernant (un pour chaque zone A, B, C et D)
doivent être activés (registre BLTCON0) et le bit 6 du registre DMACON
doit être mis à 1.
Enfin, le dernier registre à "poker", BLTSIZE. Rappelons que dès lors que celui-ci a
été "poké", le Blitter démarre.
BLTSIZE
- 15 à 06 : contiennent la hauteur du rectangle en nombre de mots. Des valeurs
comprises entre 0 et 1023 sont donc possibles, 0 sélectionnant la hauteur maximale 1024
(une hauteur nulle est interdite).
- 05 à 00 : contiennent la largeur du rectangle en nombre de mots. Des valeurs comprises
entre 0 et 63 sont donc possibles, 0 sélectionnant la largeur maximale 64 (une largeur
nulle est possible).
Rappel : quelle que soit la résolution choisie, un mot contient 16 pixels. La largeur maximale
est donc de 16x64=1024 pixels.
Vous avez maintenant suffisamment de matière pour aborder le SinusScroll dès le mois
prochain. Si quelques notions vous paraissent encore un peu floues, sachez que tout
s'éclaircira en passant à l'application même. Sur ce, je vous quitte et vous donne rendez-vous
dans le prochain numéro.
|
