ASSEMBLEUR

 

 
COURS D'ASM 68000
(par le Féroce Lapin)

retour au VOLUME 2

            
******************************************************************
*                                                                *
*             COURS D'ASSEMBLEUR 68000 SUR ATARI ST              *
*                                                                *
*                 par Le Féroce Lapin (from 44E)                 *
*                                                                *
*                         Seconde série                          *
*                                                                *
*                         Cours numéro 8                         *
******************************************************************

J'espère que vous n'abordez pas ce cours immédiatement après avoir
fini  de  lire le précédent, mais, qu'au contraire, vous vous êtes
plongé dans la ligne A avec bonheur!

Nous  allons  maintenant  aborder  un sujet qui, je dois l'avouer,
m'effrayait un peu au début: le GEM.

En  fait, en programmation comme dans beaucoup d'autres sujets, on
se  met  à  bosser  simplement  lorsqu'on  y  est obligé. Ainsi je
n'avais   réalisé  que  de  tout  petits  trucs  avec  le  GEM  en
assembleur, des  trucs du genre ACCessoire de bureau qui permet de
mettre  l'écran  en  inverse  vidéo, avec  un choix dans une boîte
d'alerte, avant  de  me  trouver face au descriptif du soft que me
proposait  une  boîte  Parisienne. Je dois avouer que les premiers
jours  ont été un peu durs, mais qu'à la longue j'ai découvert que
le  GEM est vraiment une chose fabuleuse, pas très dur à maîtriser
et que les possibilités sont largement suffisantes pour combler de
bonheur tout programmeur digne de ce nom!!! J'espère donc que vous
prendrez  autant de plaisir que moi à programmer sous GEM une fois
que vous aurez lu ce chapitre.

Tout  d'abord  les  remarques qui se trouvent au début du chapitre
sur  la  ligne A, méritent d'être relus. Chercher donc de la docu-
mentation  sans  vous  soucier  du langage. Vous trouverez dans le
dernier  cours de cette série une bibliographie dans laquelle j'ai
essayé de recenser divers articles bien sympas.

Le GEM est accessible par le TRAP #2, mais en fait grâce à ce trap
nous  avons  accès  à plusieurs parties du GEM, un peu comme si le
trap #1 débouchait  en  même temps sur GEMDOS et BIOS. Le GEM est,
en effet, composé principalement de 2 parties:

 l'AES et le VDI.

Les routines du VDI  - VIRTUAL DEVICE INTERFACE -
s'occupent des graphismes;

traçage de cercles,
ellipse,
traits,
rectangles
etc ...

Par contre, l'affichage des objets typiques du GEM :

fenêtres,
boîtes d'alertes

est réalisé par l'AES - APPLICATION ENVIRONMENT SYSTEM - .

Au  fur  et à mesure que vous découvrirez les fonctions VDI et AES
vous vous rendrez compte de l'interaction des 2.

Le  gros  avantage  de  ce système peut s'expliquer simplement: il
semble  évident à tout le monde que sortir un dessin sur un écran,
une disquette ou une imprimante, ce n'est pas la même chose.

ERREUR! Pour le GEM c'est pareil!

En  fait, on  peut dire que vous avez à préparer votre dessin et à
dire  "je  l'envoie". Où? Ah là, c'est comme vous voulez parce que
pour le VDI
                   l'écran,
                   la table traçante,
                   le disque,
                   l'imprimante
                   etc..

ne  sont que des périphériques. Il suffit de lui désigner le péri-
phérique de notre choix et il fait le boulot tout seul!!!!


Le seul problème: 
les  routines  véritablement  indépendantes  des  périphériques se
trouvent dans GDOS - ce nom vous fait sûrement frémir d'effroi...-

-- Plusieurs programmes en même temps ?
Le  principe  du GEM est très attirant mais doit nous amener à ré-
fléchir  un petit peu sur le mélange potentiel des données. En ef-
fet le GEM, même s'il n'est pas réellement multitâche (être multi-
tâche consiste à pouvoir faire tourner des applications exactement
en même temps, ce qui est de toute façon impossible avec un 68000)
le  GEM  donc, permet  d'avoir plusieurs programmes actifs en même
temps, en  l'occurrence  un  programme principal et 6 accessoires.
Pour  le  GEM il n'y a fondamentalement pas de différence entre un
PRG  et  un  ACC et, pour cette raison, dans le vocabulaire GEM on
les nomme "applications". Le GEM peut donc se retrouver avec 7 ap-
plications  à gérer, chacune ayant potentiellement plusieurs fenê-
tres. On imagine facilement le bazar dans la mémoire!!! 

-- Comment le GEM s'y retrouve t-il?

Au  démarrage  d'une application, celle-ci appelle la fonction AP-
PL_INIT (Application_Init). Cette fonction prévient le GEM que no-
tre  application  désire  devenir active, et le GEM répond en nous
fournissant  un  numéro, l'APP_ID  (Application_Identificator) qui
nous  servira maintenant de référence. Notre application sera donc
par  exemple la 3, et sera reconnue comme telle par le GEM. Atten-
tion, l'APP_ID  n'est  donné  à l'application que pour la durée de
présence  en  mémoire de celle-ci. Si je lance un ACC le lundi, il
peut hériter de l'APP_ID 4 mais si je le relance le mardi dans des
conditions  différentes, il  peut obtenir l'APP_ID 5. Seulement il
gardera cet APP_ID pendant toute son activité.

Lorsque  l'on  ouvre  une  fenêtre, c'est le même principe. Le GEM
fournit  ce  que l'on nomme un HANDLE, c'est à dire un numéro cor-
respondant à la fenêtre. En fait le HANDLE c'est le numéro d'iden-
tification  d'une fenêtre mais potentiellement aussi d'un périphé-
rique.


-- Multitraitement ?

Une  des  parties  les plus importantes du GEM concerne la gestion
des événements. Un événements c'est une action de l'utilisateur de
la machine: clic souris, appui sur une touche etc... En fait, sous
GEM les applications passent la plus grande partie de leur temps à
attendre. Imaginons  un  PRG  avec  une fenêtre ouverte et un menu
déroulant, et en même temps en mémoire 3 accessoires. Je vais dans
le  menu des accessoires. Le menu se déroule et les titres passent
en  inverse  vidéo  lorsque  la souris passe dessus. Tout ceci est
fait  par le GEM, tout seul comme un grand. Je clique sur le titre
de l'accessoire 2.

Le GEM détecte le clic, sait que je suis dans les accessoires, re-
garde  sur quelle entrée j'ai cliqué. Comme c'est le GEM qui a at-
tribué  les entrées aux ACC, il envoie un message à l'accessoire 2
pour lui dire "il faut que tu t'ouvres". Celui-ci s'ouvre donc, et
affiche  une fenêtre à l'écran. Nous avons donc 2 fenêtres en même
temps. Je clique sur celle du PRG, le GEM regarde à qui appartient
cette fenêtre et envoi au PRG un message pour lui dire "on a acti-
vé  ta  fenêtre numéro XX" etc... Nous allons donc construire dans
nos  programmes sous GEM, un noyau de surveillance des actions, et
nous réagirons en fonction de celles-ci.


-- Pour appeler les fonctions du GEM.

Les  appels  se font avec des paramètres que nous passons dans des
tableaux. Comme  nous  utilisons  DEVPACK, nous utiliserons sa bi-
bliothèque. En  effet, pour les appels au GEM, les paramètres sont
nombreux et à placer à des endroits bien précis dans les tableaux.
Pour  ces raisons, les macros trouvent ici tout leur intérêt. Nous
appellerons  donc  les  fonctions du GEM avec les macros contenues
dans  la bibliothèque de DEVPACK. Cependant il convient de connaî-
tre  également les tableaux, afin de pouvoir parfaitement compren-
dre le principe de fonctionnement. 

Pour l'AES, il faut 6 tableaux:

CONTROL,
GLOBAL, 
INT_IN,
INT_OUT,
ADDR_IN,
ADDR_OUT.

Pour le VDI il en faut 5:

CONTRL,
INTIN,
INTOUT,
PTSIN,
PTSOUT.

Attention  à  la  légère différence d'orthographe entre  INT_IN et
INTIN ! Pour indiquer, lors de l'appel au GEM, l'emplacement où il
trouvera ces tableaux, leurs adresses sont placées dans 2 listes:

Une pour l'AES:
aes_params dc.l control, global, int_in, int_out,addr_in, addr_out
et une pour le VDI:
vdi_params dc.l contrl, intin, ptsin, intout, ptsout

Voici  les  tableaux tels qu'ils sont définis dans la bibliothèque
GEM de DEVPACK:

control   ds.w  5
global    ds.w  14
int_in    ds.w  16
int_out   ds.w  7
addr_in   ds.l  3
addr_out  ds.l  1

contrl    ds.w  1
contrl1   ds.w  1
contrl2   ds.w  1
contrl3   ds.w  1
contrl4   ds.w  1
contrl5   ds.w  1
contrl6   ds.w  1
contrl7   ds.w  1
contrl8   ds.w  1
contrl9   ds.w  1
contrl10  ds.w  1
contrl11  ds.w  1

intin     ds.w  128  min  30
intout    ds.w  128  min  45
ptsin     ds.w  128  min  30
ptsout    ds.w  128  min  12

Vous  remarquez l'étrange mise en place du tableau CONTRL (tableau
pour le VDI). En effet il faut assez souvent passer des paramètres
'à  la main' dans ce tableau. Avec ce système, il sera possible de
réaliser une opération du genre MOVE.W #10,CONTRL2

Attention  cette  numérotation  des CONTRL correspond au nombre de
words  car chacune des entrées est définie par DS.W et non pas par
DS.B!!! Ceci s'explique par le fait que 99% des documents relatifs
au  GEM  sont pour le 'C' et que c'est ce type de commande qui est
faite  en  'C'.  Ainsi  vous  trouverez  souvent;  "mettre  10  en
contrl(2)"; il vous suffira de faire MOVE.W #10,CONTRL2 et le tour
est joué.

-- Pourquoi tant de tableaux? Parce que chacun de ces tableaux est
destiné  à  recevoir  ou  à  renvoyer  un certain type de données.
Voyons un descriptif rapide de ces tableaux.

Tableaux AES

** control

Destiné à contenir, dans l'ordre:

numéro   de la               fonction  (.W),
nombre   d'octets de         INT_IN (.W),
nombre   d'octets de         INT_OUT (.W),
nombre   de longs mots de    ADDR_IN (.W)
nombre   de longs mots de    ADDR_OUT


** global
Ce  tableau  est un peu spécial, et les explications le concernant
ne sont d'aucune utilité dans le cadre de ces cours. Une fois bien
ingurgité le reste, vous pourrez toujours vous pencher dessus mais
actuellement cela ne ferait que vous embrouiller! (Voir la biblio-
graphie pour en savoir plus)


** int_in
Ce  tableau  est  destiné à recevoir des valeurs entières (Integer
In) dont l'AES aura besoin.

Par exemple un numéro de fenêtre.


** int_out
A l'inverse du précédent ce tableau renvoi des résultats par exem-
ple  si vous demander la surface disponible pour une fenêtre, vous
aurez ici les dimensions.


** addr_in
Liste dans laquelle vous pourrez placer des adresses


** addr_out  et là, vous pourrez en lire! En fait il suffit, comme
toujours, de  lire  le  nom  du  tableau  pour en déduire ce qu'il
contient!


Tableaux VDI

** contrl
Dans contrl0 nous plaçons l'opcode de la fonction, c'est ainsi que
l'on appelle son numéro.

Dans  contrl1 nous  plaçons  le  nombre de données qui seront mise
dans le tableau intin

Dans  contrl2 nous plaçons le nombre de points (donc de couples de
données) qui seront placés dans le tableau ptsin

Dans contrl3 nous placerons l'identificateur de la sous-fonction.
Par  exemple  le traçage des cercles, ellipse, rectangle etc... ce
fait  avec la fonction 11. Il faut donc un sous-code permettant de
définir quel module dans la fonction 11 on désire utiliser.

Dans  contrl6 nous  plaçons  le handle du périphérique. (voir plus
haut) 
A  partir  de  contrl7 il  y  a parfois des informations à passer,
suivant la fonction.

** intin et ptsin
Nous  remplirons  ensuite le tableau INTIN avec les paramètres en-
tiers  demandés par la fonction et le tableau PTSIN avec les coor-
données  demandées  par la fonction. Une fois la fonction appelée,
nous récupèrerons:

en contrl2 le nombre de couples de coordonnées de ptsout et
en contrl4 le nombre de mots de intout.


Voici  un  appel au GEM. Cette fonction affiche une phrase où l'on
veut  sur  l'écran, contrairement  à Gemdos (9) qui est limité sur
les lignes et les colonnes de texte. De plus cette fonction permet
d'afficher  du  texte avec des effets (gras, souligné etc...) avec
la fonte de notre choix:

         LEA       MESSAGE,A1            adresse de la phrase
         LEA       INTIN,A0              tableau de réception
         MOVEQ.L   #0,D2                 init le compteur de lettres
ICI3     CLR.W     D0
         MOVE.B    (A1)+,D0              prélève en bytes
         BEQ       GO_ON                 fin du texte
         ADDQ.B    #1,D2                 on compte les lettres
         MOVE.W    D0,(A0)+              transfère dans INTIN (en words)
         BRA       ICI
GO_ON    MOVE.W    #100,PTSIN            position X
         MOVE.W    #150,PTSIN+2          position Y
         MOVE.W    D2,CONTRL3            nombre de lettres
         MOVE.W    #1,CONTRL1
         MOVE.W    CURRENT_HANDLE,CONTRL6
         MOVE.W    #8,CONTRL             opcode
         MOVE.L    #VDI_PARAMS,D1
         MOVE.W    #$73,D0
         TRAP      #2

AAAAAAAAAARRRRRRGGGLLL!!!!!! C'est l'horreur n'est ce pas!

Il faut vous munir de patience et décortiquer les multiples appels
au GEM.

Pour  vous  aider dans vos essais, vous trouverez ci-joint un dos-
sier  intitulé GEM. Il contient le source d'un ACC qui affiche une
boîte  d'alerte, d'un  PRG qui gère une ressource (listing issu de
WERCS) et  d'un accessoire gérant une fenêtre. Pour ce qui est des
éditeurs de ressources, je travaille avec K Ressource qui est bien
sympa et qui ne plante pas, contrairement à Wercs!

Essayez  de  bien  comprendre  le  principe:  affichez  une  boîte
d'alerte  avec  un  seul  bouton, puis  avec plusieurs, faites des
petites  ressources  toutes  simples, puis de plus en plus compli-
quées  etc... Le principe restera toujours le même quelle que soit
la  taille de votre application. Essayez de faire de petits acces-
soires  du genre formateur de disquettes, avec un petit formulaire
qui  demande  si l'on veut formater le disque A ou le B, en simple
ou en double face etc...

A l'aide de ces exemples, vous devriez réussir à vous débrouiller.
C'est  avec  ça  que j'ai commencé! Jetez également un coup d'oeil
sur la bibliographie, il y a quelques trucs intéressants!