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 - Utiliser l'interruption VERTB sur Amiga
(Article écrit par Yragael et extrait de www.stashofcode.fr - juillet 2017, mis à jour en octobre 2018)
|
|
Un dernier pour la route ! Dans la foulée des précédentes séries d'articles prenant pour prétexte la
programmation d'une cracktro
(1 et
2)
et celle d'un défilement sinusoïdal
(1,
2,
3,
4 et
5),
pour présenter dans le détail la manière d'attaquer le matériel de l'Amiga 500 en assembleur 68000
après avoir court-circuité le système d'exploitation, il convient de revenir sur un point délicat qui
a été soulevé, à savoir celui de la gestion des "interruptions matérielles".
Le problème plus particulièrement étudié est le suivant : comment mettre sous "interruption VERTB"
un bout de code dont l'unique fonction est de modifier la couleur de fond (COLOR00) ? Pour bien en
visualiser les effets, nous allons élaborer un scénario au fil duquel la couleur de fond sera notamment
modifiée par un tel bout de code quand le faisceau d'électrons atteindra certaines positions verticales :
Changement de COLOR00 par le Copper, le programme principal et un gestionnaire d'interruption VERTB
Cliquez ici pour télécharger le source du programme présenté ici.
- Mise à jour du 02/10/2018 : tous les sources ont été modifiés pour intégrer une section
"StingRay's stuff" qui permet d'assurer le bon fonctionnement sur tous les modèles d'Amiga, notamment
dotés d'une carte graphique.
Le fonctionnement des interruptions matérielles
Comme cela a été expliqué dans un précédent
article, le matériel de l'Amiga génère des événements qui
peuvent entraîner des interruptions de niveau 1 à 6 du processeur.
Par exemple, l'événement VERTB, qui survient quand le faisceau d'électrons ayant atteint le bas de l'écran
entame son retour vers le haut de ce dernier pour afficher la trame suivante, peut entraîner une interruption
de niveau 3 du processeur. Le processeur cesse alors d'exécuter le programme principal pour exécuter le
gestionnaire d'interruption dont l'adresse est stockée dans une table des vecteurs d'interruptions. S'agissant
d'une interruption de niveau 3, le
M68000 8-/16-/32-Bit Microprocessors
User's Manual nous apprend qu'il
s'agit du vecteur 27, qui renvoie au gestionnaire d'interruption logé à l'adresse $6C :
Appel du gestionnaire de l'interruption Level 3 Interrupt Autovector en cas d'événement VERTB
C'est donc par abus de langage qu'on parle d'interruption matérielle, par exemple d'interruption VERTB
pour désigner l'interruption dont il vient d'être question. Toutefois, cette convention étant pratique,
nous l'utiliserons par la suite.
La liste des événements signalés le matériel qui sont susceptibles d'entraîner une interruption de niveau 1
à 6 du processeur figure dans la documentation du registre INTENA dans
l'Amiga Hardware
Reference Manual :
| Bit |
Nom |
Niveau |
Desciption |
| 15 |
SET/CLR |
|
Ce bit est décrit plus loin. |
| 14 |
INTEN |
|
Ce bit est décrit plus loin. |
| 13 |
EXTER |
6 |
Interruption externe |
| 12 |
DSKSYN |
5 |
Le contenu du registre DSKSYNC correspond aux données du disque |
| 11 |
RBF |
5 |
Tampon de réception du port série plein |
| 10 |
AUD3 |
4 |
Bloc du canal audio 3 terminé |
| 09 |
AUD2 |
4 |
Bloc du canal audio 2 terminé |
| 08 |
AUD1 |
4 |
Bloc du canal audio 1 terminé |
| 07 |
AUD0 |
4 |
Bloc du canal audio 0 terminé |
| 06 |
BLIT |
3 |
Opération au Blitter terminée |
| 05 |
VERTB |
3 |
Début du blanc vertical |
| 04 |
COPER |
3 |
Copper |
| 03 |
PORTS |
2 |
ports d'entrée/sortie et timers |
| 02 |
SOFT |
1 |
Réservé pour une interruption initiée par logiciel |
| 01 |
DSKBLK |
1 |
Bloc disque terminé |
| 00 |
TBE |
1 |
Tampon de transmission du port série vide |
Le matériel signale toujours les événements énumérés en positionnant les bits correspondants dans un
autre registre, INTREQ. Par contre, il n'interrompt pas toujours le processeur dans la foulée. En effet,
tout dépend de la gestion que le registre INTENA permet de configurer.
Lorsqu'une valeur 16 bits X est écrite dans INTENA, l'état du bit SET/CLR dans X indique si un bit d'INTENA
désigné par un bit positionné dans X doit être positionné ou effacé. Par exemple, pour inhiber le déclenchement
d'une interruption niveau 3 du processeur sur un événement VERTB, nous devons écrire $0020 dans INTENA. A
l'inverse, pour l'activer, nous devons écrire $8020 dans ce registre. Toutefois, il faut encore compter avec
le bit INTEN.
Le bit INTEN est une sorte d'interrupteur général :
- Lorsque INTEN est effacé, le déclenchement de toute interruption du processeur sur événement matériel
est inhibé, quand bien même le bit correspondant à un événement est positionné dans INTENA. Par exemple, si
jamais INTEN n'était pas positionné, écrire $8020 dans INTENA ne suffit pas à activer le déclenchement d'une
interruption de niveau 3 du processeur sur événement VERTB. Il faudrait plutôt écrire $C020 dans le registre
pour positionner simultanément INTEN et VERTB, ou alors y écrire $8020 pour positionner VERTB puis $C000 pour
positionner INTEN - l'inverse étant possible.
- Lorsque INTEN est positionné, le déclenchement d'interruptions du processeur sur les événements matériels
est activé, mais uniquement pour les événements dont les bits correspondants sont positionnés dans INTENA.
Par exemple, écrire $C000 n'a d'autre effet que d'activer le déclenchement d'une interruption de niveau 3
du processeur sur événement VERTB, si jamais VERTB est le seul bit correspondant à un événement à avoir été
positionné dans INTENA.
Une conséquence importante de ce fonctionnement, c'est que nous pouvons écrire dans INTENA pour modifier
la manière dont le matériel génère des interruptions processeur sur événements matériel - la gestion des
interruptions matériel pour faire plus court - de manière très sélective. Dans l'exemple suivant, la première
instruction ne fait qu'activer l'interruption matériel TBE, et la seconde ne fait qu'inhiber l'interruption
VERTB - tout ce qui concerne la gestion des autres interruptions matérielles et l'interrupteur générale
INTEN est inchangé :
move.w #$8001,INTENA(a5)
move.w #$0020,INTENA(a5)
|
Pour cette raison, seule une lecture de INTENAR, le registre homologue de INTENA en lecture seule - INTENA
est en écriture seule -, permet d'être exactement renseigné sur la gestion des interruptions matérielles
à un instant donné.
Couper les interruptions matérielles
Nous n'allons pas rentrer dans le détail des opérations requises pour mettre en place un environnement de
développement en utilisant WinUAE pour Windows et pour écrire un programme minimal en assembleur 68000 qui
prend le contrôle total du matériel de l'Amiga. Tout cela a déjà été soigneusement exposé dans
cet article.
D'emblée, concentrons-nous donc sur ce que concerne la gestion des interruptions matérielles. Après avoir
court-circuité le système d'exploitation, il s'agit de prendre le contrôle des six vecteurs d'interruption
du processeur qui, parmi les 255 dont ce dernier dispose, correspondent aux interruptions de niveau 1 à 6.
Autrement dit, les vecteurs 25 à 30.
Tout d'abord, nous devons sauvegarder l'état de la gestion des interruptions matérielles pour la restaurer
à la fin. Pour cela, nous lisons et stockons dans des variables intena et intreq le contenu des registres
INTENAR et INTREQR, versions en lecture seule des registres INTENA et INTREQ :
move.w INTENAR(a5),intena
move.w INTREQR(a5),intreq
|
Nous pouvons alors couper toutes les interruptions matérielles :
Dans la foulée, nous acquittons tous les événements que le matériel pouvait avoir signalés. Certes, le
matériel va continuer à en signaler, mais du moins saurons-nous à partir de cet instant que si le matériel
positionne un bit dans INTREQ, ce sera pour signaler un événement survenu après que nous ayons pris la main :
Enfin, nous détournons les vecteurs des interruptions de niveau 1 à 6 en les renvoyant sur un sous-programme
de type gestionnaire d'interruption qui nous appartient. Ces vecteurs pointent sur les adresses $64 à $78 :
lea $64,a0
lea vectors,a1
REPT 6
move.l (a0),(a1)+
move.l #_rte,(a0)+
ENDR
|
Plus loin, après le RTS final du programme principal, nous programmons le gestionnaire d'interruption _rte
en question :
Ce gestionnaire ne fait donc strictement rien, pas même acquitter la notification de l'événement matériel
qui est à l'origine de son appel - nous reviendrons sur ce point.
Un scénario à base d'interruptions VERTB
Comme expliqué, INTREQ fonctionne exactement comme INTENA, sauf qu'il sert à signaler des événements
plutôt qu'à activer/inhiber le déclenchement d'interruptions du processeur associées aux événements en question.
Il faut rajouter deux choses sur INTREQ :
- Rien ne peut empêcher le matériel de continuer à signaler dans INTREQ les événements qui surviennent.
- Il est possible d'écrire au processeur dans INTREQ pour simuler un ou plusieurs événements matériels.
Nous allons illustrer ces points. Le scénario retenu est le suivant :
- Le programme principal attend le quart supérieur de l'écran (ligne DISPLAY_Y+(DISPLAY_DY>>2)) pour
déclencher une interruption VERTB dont le gestionnaire passe COLOR00 à $00F0 (vert).
- La liste Copper attend la moitié de l'écran (ligne DISPLAY_Y+(DISPLAY_DY>>1)) pour passer COLOR00
à $0F00 (rouge).
- Le matériel attend le bas de l'écran (fin de la ligne 312 en PAL) pour déclencher une interruption
VERTB dont le gestionnaire passe COLOR00 à $000F (bleu).
Programmer le scénario
Commençons la liste Copper.
Cette dernière se résume à une instruction WAIT pour attendre le faisceau d'électrons atteigne ou
dépasse la mi-hauteur de l'écran, suivie d'une instruction MOVE pour stocker $0F00 (rouge) dans COLOR00 :
move.l copperlist,a0
move.w #((DISPLAY_Y+(DISPLAY_DY>>1))<<8)!$0001,(a0)+
move.w #$FF00,(a0)+
move.w #COLOR00,(a0)+
move.w #$0F00,(a0)+
|
Bien évidemment, nous n'oublions pas de terminer la liste Copper par le traditionnel WAIT impossible :
Programmons maintenant le programme principal.
Tant que l'utilisateur n'a pas pressé le bouton gauche de la souris, ce programme attend en boucle le
faisceau d'électrons au premier quart de hauteur de l'écran. Il stocke alors $00F0 (vert) dans une
variable color dans laquelle le gestionnaire d'interruption VERTB trouvera la couleur à stocker dans
COLOR00. Enfin, il provoque l'appel à ce gestionnaire en générant une interruption VERTB par une écriture
dans INTREQ :
_loop:
;Attendre le quart supérieur de la hauteur de l'écran
_wait0:
move.l VPOSR(a5),d0
lsr.l #8,d0
and.w #$01FF,d0
cmp.w #DISPLAY_Y+(DISPLAY_DY>>2),d0
blt _wait0
;Déclencher une interruption VERTB
move.w #$00F0,color
move.w #$8020,INTREQ(a5)
;Tester la pression du bouton gauche de la souris
btst #6,$bfe001
bne _loop
|
Attention ! Ce code doit être complété par une boucle _wait1 venant immédiatement après la boucle _wait0.
Son objet est d'attendre le faisceau d'électrons à la ligne 0 :
_wait1:
move.l VPOSR(a5),d0
lsr.l #8,d0
and.w #$01FF,d0
bne _wait1
|
En effet, l'exécution du code de notre programme prend moins de temps qu'il n'en faut au faisceau d'électrons
pour terminer de balayer la ligne DISPLAY_Y+(DISPLAY_DY>>2). A défaut d'attendre une ligne suivante - en
l'occurrence, la ligne 0, mais cela aurait parfaitement pu être la ligne du dessous DISPLAY_Y+(DISPLAY_DY>>2)+1 -,
le code du programme ne serait donc pas exécuté une fois par trame, mais plusieurs fois, ne produisant alors
pas l'effet désiré.
Enfin, il nous reste à programmer le gestionnaire d'interruption.
Avant toute chose, il faut se rappeler qu'un gestionnaire d'interruption est un sous-programme exécuté alors
qu'un programme était en cours d'exécution. Partant, il faut au moins sauvegarder le contenu des registres
qui seront utilisés par le gestionnaire pour être en mesure de les restaurer quand ce dernier se terminera.
Cela s'effectue généralement à l'aide de l'instruction MOVEM pour stocker et lire le contenu de registres
dans la pile.
Ensuite, il faut savoir que tant que l'événement n'est pas acquitté en effaçant son bit dans INTREQ,
le matériel génère l'interruption processeur associée. Pour s'en convaincre, il suffit d'oublier d'acquitter
l'événement VERTB dans le gestionnaire d'interruption et de modifier le programme principal pour lui demander
de passer en boucle COLOR00 à $0FF0 (jaune) :
_loop:
move.w #$0FF0,COLOR00(a5)
btst #6,$bfe001
bne _loop
|
L'écran est totalement bleu ou presque, n'étant ponctué de jaune que lors des rares cycles d'exécution que
la fin du gestionnaire d'interruption permet au processeur de récupérer pour continuer à exécuter le programme,
avant qu'il ne doive exécuter de nouveau le gestionnaire d'interruption :
Le programme est presque court-circuité par le gestionnaire d'interruption qui n'acquitte pas VERTB
Dans ces conditions, le gestionnaire d'interruption doit impérativement acquitter l'événement à la suite
duquel il a été appelé.
Dès lors, le code de notre gestionnaire d'interruption doit au moins être le suivant :
_vertb:
; movem.l d0-d7/a0-a6,-(sp) ;Indispensable, mais à limiter aux registres modifiés
move.w #$0020,INTREQR(a5)
; movem.l (sp)+,d0-d7/a0-a6 ;Indispensable, mais à limiter aux registres modifiés
rte
|
En l'espèce, son code complet est le suivant :
_VERTB:
; movem.l d0-d7/a0-a6,-(sp) ;Indispensable, mais à limiter aux registres modifiés
move.w color,COLOR00(a5)
move.w #$000F,color
move.w #$0020,INTREQ(a5)
; movem.l (sp)+,d0-d7/a0-a6 ;Indispensable, mais à limiter aux registres modifiés
rte
|
La liste Copper, le programme principal et le gestionnaire d'interruption étant programmés, il ne reste
plus qu'à activer l'ensemble. Après avoir activé le Copper et lui avoir demandé d'exécuter en boucle
la liste Copper, il suffit de stocker l'adresse de notre gestionnaire d'interruption à l'adresse contenue
dans le vecteur de l'interruption de niveau 3 du processeur, c'est-à-dire $6C... :
...avant d'autoriser de nouveau le matériel à générer cette interruption de niveau 3 quand il détecte
l'événement VERTB :
move.w #$C020,INTENA(a5) ;INTEN=1, VERTB=1
|
Le résultat produit est celui présenté dans l'image du début de cet article.
Restaurer les interruptions matérielles
Lorsque l'utilisateur clique sur le bouton gauche de la souris, le programme se termine en rendant aussi
proprement que possible la main au système d'exploitation. Sans revenir sur les autres tâches qui nous
incombent - elles sont détaillées dans cet
article -, concentrons-nous donc encore sur ce que concerne
la gestion des interruptions matérielles.
Nous commençons donc pas couper de nouveau la génération d'interruptions processeur par le matériel... :
move.w #$7FFF,INTENA(a5)
move.w #$7FFF,INTREQ(a5)
|
...avant de restaurer les vecteurs d'interruption... :
lea $64,a0
lea vectors,a1
REPT 6
move.l (a1)+,(a0)+
ENDR
|
...et de rétablir la génération des interruptions processeur par le matériel :
move.w intreq,d0
bset #15,d0
move.w d0,INTREQ(a5)
move.w intena,d0
bset #15,d0
move.w d0,INTENA(a5)
|
C'est fini !
Une subtilité pour conclure...
Noter que le Copper a accès en écriture à INTREQ. Par conséquent, il est parfaitement possible de déclencher
une interruption VERTB à n'importe quelle position du faisceau d'électrons que le Copper peut repérer
- comme cela a été expliqué dans
cet article,
ses capacités en la matière sont limitées, la granularité
verticale étant certes d'une ligne, mais la granularité horizontale n'étant que de 4 pixels en basse résolution.
Il suffit donc d'utiliser un MOVE dans la liste Copper :
move.l copperlist,a0
;...
move.w #INTREQ,(a0)+
move.w #$8020,(a0)+
|
A titre, d'exemple, voici le résultat produit par une variante du programme présenté plus tôt. Ici, le Copper
déclenche une interruption VERTB quand le faisceau d'électrons atteint ou dépasse le dernier quart de la hauteur
de l'écran, avec pour effet de passer COLOR00 à $0000 (noir) :
Version plus complexe où le Copper déclenche une interruption VERTB
Cliquez ici pour télécharger le source du programme qui produit cet effet.
|
