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