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 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.