COURS207.TXT/fr
******************************************************************
* *
* COURS D'ASSEMBLEUR 68000 SUR ATARI ST *
* *
* par Le Féroce Lapin (from 44E) *
* *
* Seconde série *
* *
* Cours numéro 7 *
******************************************************************
Inutile de vous complimenter inutilement, mais si vous avez suivi
bien tranquillement les cours depuis le début, si vous avez pris
soin de vous exercer avec des petites applications, vous devez
déjà avoir un niveau correct en assembleur! N'oubliez donc pas les
commandements principaux: bien commenter les programmes, réfléchir
simplement, utiliser papier et crayon etc... Plus vous avancerez
et plus vos listings seront longs, et plus une programmation
propre sera indispensable!!! De même cherchez par vous même avant
de poser dès questions, cela évitera bien souvent de demander
n'importe quoi...
Dans ce cours ainsi que dans les 2 suivants, nous aborderons2
sujets tabous: la Ligne A et le GEM.
Concernant ces 2 sujets, les critiques vont bon train: la ligne A
c'est pas commode, c'est nul et le GEM, pouah!!! Après pas mal de
temps passé à discuter et à écouter les opinions de plusieurs
personnes, je suis arrivé à la conclusion suivante: Tout d'abord
les critiqueurs sont rarement les programmeurs Ligne A ou GEM.
Ensuite, imaginons un cours instant notre ST sans GEM et préparons
nous à faire un effort, GEM nous le rend bien! En dernier lieu je
dirais que ces cours sont destinés à faire de vous des
programmeurs et pas des bidouilleurs. Vous devez donc avoir
connaissances des possibilités de la ligne A et de celles du GEM.
Ne pensez pas cependant trouver dans ces cours la totalité des
commandes GEM. Ces cours sont destinés à levez un coin du voile,
et si possible à vous donnez de quoi continuer vos recherches.
En tout cas je peux vous assurer que la ligne A et le GEM ne sont
pas plus dur qu'autre choses (D'ailleurs y a t-il quelques chose
de dur en assembleur?????). Il y a également un avantage
non-négligeable concernant la ligne A et surtout GEM: Jusqu'à
maintenant, nous avons utilisé des instructions assembleur 68000,
et il semblait évident que dans un ouvrage sur le PASCAL, le BASIC
GFA ou le C, nous aurions eu du mal à trouver des précisions sur
l'instruction MOVEM.L par exemple ! Concernant la ligne A, mais
surtout GEM, nous allons utiliser principalement des macros (vous
voyez pourquoi ce sujet a été abordé avant!). Or ces macros ont
chacune un nom, et ce nom est un nom 'GEM' et non pas relatif à
tel ou tel assembleur!! Ainsi ouvrir une fenêtre pour la faire
apparaître sur l'écran, se fera avec une macro nommée WIND_OPEN.
L'avantage c'est que cette fonction GEM est utilisée en Pascal, en
C etc... Pour cette raison, vous pouvez chercher de la documen-
tation sur GEM quelque soit le langage utilisé dans cette
documentation. Dans 99% des cas ce sera le C.
Pour ma part mes connaissances en C sont réduites et pourtant, une
grande partie des documents GEM avec lesquels je travaille, fait
référence à ce langage. Surtout ne vous contentez pas des ouvrages
traitant du GEM en assembleur car vous serez bien vite dégoûté!!
Idem pour la ligne A, les paramètres nécessaires ne dépendent pas
du langage!!
Un autre avantage très important, surtout pour le GEM, concerne
les formats de données. Ayant la chance de pouvoir travailler sur
des Macs, de nombreuses choses y rendent la manipulation des pro-
grammes plus aisée que sur ST. Par exemple on charge un logiciel
de dessin, on fait un petit gribouillis, ensuite on charge
n'importe quel traitement de texte et hop on y colle notre
gribouillis. Sur ST il y a 99% de chance que le format de l'un ne
soit pas reconnu par l'autre! Si on jette un coup d'oeil vers le
monde PC, on se rend compte qu'il n'existe pas de format normalisé
pour ce type de machine, et que c'est l'anarchie à ce niveau. De
tels formats normalisés existent sur Mac, ils sont respectés, et
les rares softs ne se pliant pas à cette norme sont voués à un
formatage rapide de la disquette!!! Le comble c'est que sur ST de
telles normes de formats existent, mais elles ne sont pas
respectées....
En fait l'utilisation de la ligne A et surtout celle du GEM,
doivent nous amener à une réflexion plus globale sur ce qu'est la
programmation. Raymond Loewy (1893-1986), que l'on peut considérer
comme le père du design industriel, a eu beaucoup de réflexions
sur ce qu'il faut donner au consommateur. Dans notre langage nous
parlons d'utilisateur de softs mais c'est en fait de la même
personne qu'il s'agit. Comparons un soft Mac et un soft ST.
L'écran est allumé, le soft est chargé, et la seule chose que nous
faisons, c'est promener notre oeil sur les icônes et la souris
dans la barre de menu. Difficile de juger des qualités respectives
des 2 softs sans aller plus loin. Pourtant, la simple disposition
des entrées dans les menus, le positionnement des icônes, le
faible nombre de celles-ci mais en même temps leur impression de
clarté donne dans 99% des cas l'avantage au Mac Intosh. Sur le ST,
les menus dégueulent de partout (surtout dans les softs récents),
et les icônes recouvrent un bureau qui n'en demande pas tant! Ceci
est à rapprocher d'une réflexion de Raymond Loewy que je vous
demande de méditer: "Un véhicule aérodynamique bien dessiné donne
une impression de vitesse, même quand il est arrêté". Inutile donc
d'en rajouter à la pelle, les 14524874 fonctions du softs ST sont
simplement des délires de programmeurs alors que les 20 fonctions
du softs Mac ont été pensées pour l'utilisateur. Lorsque Raymond
Loewy a été demandé pour faire le nouveau logo de la société
Shell, ainsi que tout le design des stations services, il a
simplement dit à ses employeurs: "Vos clients, ce ne sont pas les
automobiles, ce sont les automobilistes". Evident, sauf qu'à
l'époque la Shell vendait pour les automobiles, sans s'en rendre
compte!
Eh bien, sur ST les programmeurs programment pour le ST (ou pour
eux!) mais très rarement pour les utilisateurs...
Tout ceci étant dit, nous allons aborder maintenant la ligne A, en
espérant cependant que cela vous fera réfléchir lorsque vous
concevrez vos programmes!
LA LIGNE A
Doc officielle Atari, Chapitre Ligne A: Bon descriptif des
différentes fonctions, assez brut mais efficace.
Bible ST: Bon descriptif des fonctions Livre du développeur: idem
mais en plus descriptif des données dont on peut déduire l'empla-
cement avec la ligne A.
Doc du GFA 3.00: Assez étrange. Si les fonctions ligne A du GFA
sont appelées de la même manière qu'en assembleur, le concepteur
de ce langage a réussi à 'inventer' des fonctions en clamant bien
haut qu'il s'agit de fonction Ligne A !!! Peut-être pour que le
GFA soit encore moins compatible... A ce propos, il semblerait que
la ligne A ne soit plus officiellement supportée par le TT.... A
voir...
Dans le premier kilo de mémoire de notre machine, nous avons un
bon paquet d'adresses utilisées par le microprocesseur. Nous avons
passé pas mal de temps à éplucher le principe de fonctionnement de
ce kilo, qui sert au 68000 de 'relais' afin qu'il trouve l'adresse
de la routine qu'il doit exécuter pour telle ou telle raison.
J'espère de tout coeur que vous avez parfaitement assimilé ce
principe car pour la ligne A, le GEM, les interruptions etc...
c'est encore et toujours ce même principe qui est appliqué !
Prenez la feuille qui vous a été fournie avec les cours de la
série 1, et qui montre ce premier kilo. Le vecteur 10 (adresse 40
en décimal et $28 en hexa.) possède comme 'description': émulateur
ligne 1010. Convertissons 1010 en hexadécimal, nous obtenons....
$A ! Première constatation, si ce vecteur est dans le premier kilo
de mémoire, c'est donc que l'émulateur ligne A n'est pas une
particularité du ST mais bien du 68000. Ces vecteurs vont donc
nous donner accès à une ou des routines, en utilisant toujours le
même principe:
Ordre au 68000, celui-ci analyse l'ordre, saute dans le premier
kilo de mémoire à l'adresse correspondant à cet ordre, y trouve
l'adresse de la routine à exécuter, il ne lui reste plus qu'à
sauter à celle-ci.
Comment donc appeler les routines accessibles par l'intermédiaire
de l'émulateur ligne A, que font ces routines, et comment 'discu-
ter' avec elles, c'est à dire comment leur passer d'éventuels pa-
ramètres ?
Dans le cas de l'Atari ST, les routines accessibles par le biais
de l'émulateur ligne A sont des routines graphiques. Ces routines
sont les routines graphiques de base de notre machine. Elles sont
utilisées par le GEM. Leur accès est rustique et mal commode mais
la commodité n'est pas le but recherché. Généralement en assem-
bleur on recherche souvent à faire soit même ses routines (c'est
toujours mieux que celles des copains) Il faut cependant noter que
dans beaucoup de cas, une bonne utilisation de la Ligne A ou du
Gem est amplement suffisante. De plus, c'est bien souvent une
bonne connaissance de ces interfaces qui vous permettra d'amé-
liorer vos routines. Une raison supplémentaire réside dans la
facilité de mise en oeuvre et dans la facilité d'amélioration. Il
est tout a fait possible que la société pour laquelle vous avez
réalisé un soft, vous demande la version 2.00 plusieurs années
après la version 1.00. Les infâmes bidouilles pour gagner 3 cycles
d'horloges vous semblerons alors bien moins claires qu'un appel
classique à la ligne A, peut être un peu plus lent. Mais là
encore, il faut penser en se mettant à la place de l'utilisateur !
Ainsi SPECTRUM 512 est un excellent soft pensé avec un esprit
programmeur et le résultat c'est que tout le monde utilise
DEGAS...
Les routines ligne A sont donc des routines graphiques de base.
Elles sont au nombre de 16, et sont numérotés de 0 à 15. Voici
leur fonctions par numéro:
0 = initialisation
1 = placer un pixel à une couleur donnée
2 = demander la couleur d'un pixel
3 = tracé d'une ligne quelconque
4 = tracé d'un ligne horizontale
5 = tracé d'un rectangle rempli
6 = remplissage d'une ligne d'un polygone
7 = transfert d'un bloc de bit
8 = transfert de matrice de caractère
9 = visualisation de la souris
10 = non-visualisation de la souris
11 = transformation de la forme de la souris
12 =effacement de sprite
13 = affichage de sprite
14 = copie de zone (FDB)
15 = remplissage de zone
Nous avons répondu à la première question: "qu'est ce que ça
fait?" Nous pouvons passer à la suivante :"comment l'appelle-t-on
?" Un appel ligne A se fait à l'aide d'un word. Le poids faible de
ce word contient le numéro de la fonction, et le poids fort est
équivalent à $A (d'où le nom ligne A). Ainsi pour appeler la
fonction 3, on utilisera le word $A003. Mais où le placer? Et bien
tout simplement dans notre programme ! Pour pouvoir le noter tel
quel nous le ferons précéder de DC.W de façon à ce que DEVPACK ne
cherche pas à transformer ceci en code 68000 puisqu'aucune
mnémonique ne correspond à ce nombre! Pour appeler la fonction 1
de la ligne A nous mettrons donc dans notre programme:
DC.W $A001
Note: si cela vous intéresse, vous pouvez suivre les appels
ligne A de la même manière que les appels Trap, sous MONST, en
tout cas si vous avez une des dernières versions de MONST.
Question suivante: comment passer des paramètres. En effet si nous
voulons utiliser par exemple la fonction 2 pour connaître la
couleur d'un pixel, il faudra bien fournir les coordonnées de
celui-ci. Nous avons vu avec Gemdos, Bios et Xbios que les
paramètres étaient passés par la pile. Nous avons également
utilisé ce principe dans nos propres routines. Empilage, saut à la
routine (par BSR ou TRAP) puis correction de la pile. Concernant
la ligne A et le GEM, la pile n'est pas utilisée. En effet, la
ligne A et le GEM utilisent un système de tableau. Nous avons
étudié les tableaux et nous avons vu comment lire dans ceux-ci. Et
bien c'est un peu ce principe qui va être utilisé. Les paramètres,
parfois très nombreux, vont être placés dans un ou plusieurs
tableaux, à des endroits précis, avant l'appel de la fonction
choisie. Celle-ci ira chercher les paramètres nécessaires et
retournera ensuite ses résultats également dans des tableaux.
L'avantage du système des macros devient évident: si pour des
appels gemdos, bios et xbios il suffit d'empiler (le nombre de
paramètres n'est pas énorme et le principe et toujours le même),
il faut en revanche une sacré dose de mémoire pour se rappeler
dans quel tableau et surtout où dans ce tableau doivent être
déposés les paramètres de chaque fonction. Malheureusement dans la
bibliothèque de Devpack, il n'y a pas de macros pour la ligne A.
Nous allons donc détailler quelques fonctions 'à la main'. Etant
donné que vous avez sous la main le cours sur les macros, je ne
peux que vous conseiller de réaliser les macros correspondantes à
ces fonctions. Nous allons tout d'abord tracer un rectangle sur
l'écran. Voir listing numéro 5.
Tout d'abord inclusion de la routine de démarrage des programmes,
petit message de présentation en effaçant l'écran au passage.
Ensuite initialisation de la ligne A. En retour, nous avons en A0
l'adresse du tableau que nous allons remplir avec les paramètres.
Ceux-ci sont assez nombreux et doivent être passés à des endroits
bien précis. Certains demandent une petite explication: Le
clipping. C'est un système bien utile, que nous retrouverons dans
le GEM. Par exemple nous voulons afficher sur l'écran une image,
mais celle-ci ne doit apparaître que dans un petit rectangle. Il
va donc falloir se compliquer sérieusement la tache afin e de ne
pas afficher toute l'image. Au lieu de cela nous pouvons utiliser
le clipping. Cela consistera à donner les coordonnées du rectangle
dans lequel nous voulons que l'image apparaisse, et à dire que
c'est le rectangle de clipping. Ensuite il reste à afficher
l'image sur tout l'écran et elle n'apparaîtra que dans le
rectangle, le reste de l'écran étant 'clippé'. La encore, il est
bien évident que cela ralenti l'affichage, nous avons en effet
affiché tout une image pour n'en voir qu'un bout, et de plus le
système a été obligé de tester sans arrêt pour savoir s'il devait
nous montrer ce pixel, puis l'autre etc... Cette méthode est
pourtant hyper-utile et nous verrons cela de nombreuses fois.
Le type d'affichage. C'est un descripteur permettant de savoir
comment va se faire l'affichage. 0= mode remplacement, 1=mode
transparent, 2=mo deXOR, 3=transparent inverse. Essayer de faire
2e rectangle qui se recouvre et observez le résultat en faisant
varier les modes.
Nous allons maintenant utiliser une autre fonction, qui demande la
couleur d'un pixel. Dans le cas du traçage d'un rectangle nous
avons utilisé la tableau dont l'adresse était en A0 pour passer
les paramètres. Pour la demande de couleur d'un pixel et pour le
coloriage d'un pixel, nous allons utiliser d'autres tableaux.Alors
là, suivez bien parce que les tableaux que nous allons décrire
maintenant sont également utilisés pas le GEM? nous allons donc
faire d'une pierre deux coups !!!!!
Tout comme le GEM donc, la ligne A utilise des tableaux, destinés
chacun à recevoir ou à rendre des choses différentes. Le premier
tableau, c'est le tableau CONTRL (Control) Il reçoit le numéro de
la fonction et quelques autres paramètres. Le second c'est le
tableau INT_IN. Cela signifie Integer In, c'est donc un tableau
qui va recevoir des entiers (un nombre entier c'est en Anglais un
integer) Le troisième tableau c'est PTSIN (Points In). C'est un
tableau destiné à recevoir les coordonnées des points ou bien des
dimensions. Disons que ce tableau va recevoir par exemple les
coordonnées X et Y pour le centre d'un cercle, mais aussi son
rayon. Il règne une certaine confusion dans les explications sur
ce tableau. En effet il reçoit entre autre des coordonnées, qui
vont souvent par couple (X et obligatoirement Y), ce qui fait que
bien souvent on dit par exemple "il faut mettre 1 donnée dans
PTSIN" alors qu'en fait il faut mettre un couple de données! Le
quatrième tableau c'est INTOUT. C'est la même chose que INT_IN
sauf que c'est en sortie, pour les résultats. Vous vous en doutez
maintenant, le dernier tableau, c'est PTSOUT!!!!
Jetons maintenant un coup d'oeil sur le listing numéro 6.Un peu de
réflexion et cela ne doit pas vous poser de problème. Essayez
cependant de refaire ce listing avec des boucles parce qu'avec le
coloriage d'un seul pixel, c'est bien sur un peu limité... Juste
une chose, essayer de bien imaginer ce qui se passe avec les
tableaux Contrl, Int_in, Ptsin, Intout et Ptsout parce dans le
chapitre suivant il va y en avoir beaucoup.....
Bon maintenant que vous savez tracer un rectangle, vous pouvez
également tracer des lignes, demander la couleur d'un pixel etc...
La fonction la plus délicate est à mon avis celle qui sert pour
l'affichage de texte. Elle permet cependant des effets assez
intéressants (écriture avec différents styles).
Pour utiliser maintenant la ligne A, reportez vous aux descriptifs
donnés dans la Bible et essayez! 2e remarque cependant: avec le
GEM et la ligne A nous abordons en quelque sorte le concept du
multi-utilisateur/multi-machines. En effet le GEM utilise beaucoup
la ligne A et partage donc avec lui les tableaux. Or, votre
programme peut très bien être en train de tracer de jolis
rectangles lorsqu'il vient à l'utilisateur l'idée de promener sa
souris dans le menu déroulant... Appel à GEM, modification des
tableaux communs au GEM et à la ligne A, et au retour adieu les
rectangles...
Là encore prudence et réflexion pour se mettre à la place de
l'utilisateur...
Seconde remarque, les adresses fournies par la ligne A.
Nous pouvons prendre comme exemple les fontes. Où se trouvent-
elles? Avec MONST, en se balladant en mémoire, il sera toujours
possible de les trouver. Malheureusement elles ne sont pas au même
endroit dans toutes les machines. Ce n'est pas grave, il suffit de
passer par la ligne A. En effet la fonction $A000 permet
d'initialiser mais en grande partie cela ne fait que nous fournir
des adresses. Grâce à celles-ci nous pouvons en déduire de très
nombreuses choses (emplacement des fontes entre autre). Là encore,
il est préférable de passer par DC.W $A000 puis de faire des
décalage pour trouver ce qui nous intéresse. Le petit rigolo qui
se vante d'avoir trouvé l'adresse cachée qui donne les fontes se
rendra bien vite compte que cela ne marche pas tout le temps alors
qu'avec la ligne A, c'est moins frime mais c'est sûr!
Pour l'utilisation de la ligne A, le descriptif des fonctions dans
la bible est suffisant. Commencez par les rectangles, les lignes,
placez des points où demander leur couleurs etc... Voici un
exemple qui a été dans les premiers que j'ai réalisé avec la ligne
A: Affichage d'un petit texte en haut à gauche (environ 5 lignes
de 20 caractères). A l'aide d'un boucle, on demande la couleur des
pixels, et on recolorie les pixels sur la droite de l'écran et de
façon à ce que le texte apparaissent verticalement.
Pour ce qui est de déterminer l'emplacement de certaines données
grâce à un saut dans les adresses d'initialisation ligne A, la
bible est un peu silencieuse là-dessus alors que le Livre du
Développeur chez Micro-App est plus fourni.
Conseil de dernière minute: faites beaucoup d'exercices avec la
ligne A et surtout faites vous une bibliothèque de Macro pour ses
fonctions.
Back to ASM_Tutorial