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