Obligement - L'Amiga au maximum

Vendredi 29 mars 2024 - 15:51  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

Actualité (récente)
Actualité (archive)
Comparatifs
Dossiers
Entrevues
Matériel (tests)
Matériel (bidouilles)
Points de vue
En pratique
Programmation
Reportages
Quizz
Tests de jeux
Tests de logiciels
Tests de compilations
Trucs et astuces
Articles divers

Articles in english


Réseaux sociaux

Suivez-nous sur X




Liste des jeux Amiga

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z,
ALL


Trucs et astuces

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Glossaire

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Galeries

Menu des galeries

BD d'Amiga Spécial
Caricatures Dudai
Caricatures Jet d'ail
Diagrammes de Jay Miner
Images insolites
Fin de jeux (de A à E)
Fin de Jeux (de F à O)
Fin de jeux (de P à Z)
Galerie de Mike Dafunk
Logos d'Obligement
Pubs pour matériels
Systèmes d'exploitation
Trombinoscope Alchimie 7
Vidéos


Téléchargement

Documents
Jeux
Logiciels
Magazines
Divers


Liens

Associations
Jeux
Logiciels
Matériel
Magazines et médias
Pages personnelles
Réparateurs
Revendeurs
Scène démo
Sites de téléchargement
Divers


Partenaires

Annuaire Amiga

Amedia Computer

Relec


A Propos

A propos d'Obligement

A Propos


Contact

David Brunet

Courriel

 


Programmation : GFA Basic/AMOS - création d'une commande d'affichage de texte
(Article écrit par Pierre-Philippe Launay et extrait d'Amiga News - mars 1992)


Une instruction Workbench est composée d'une commande et de plusieurs paramètres optionnels, même chose pour AMOS et GFA Basic.

Programmation spécifique AmigaOS 2.0 (A500 Plus)

J'ai déjà parlé des nombreux tracas que nous a causé cette nouvelle race d'ordinateur. Pour résumer, je dirai que je n'ai pour l'instant pas découvert de véritables bogues (et pourtant je cherche). Par contre, j'ai pu m'apercevoir que certaines fautes logicielles ne passent plus quel que soit le langage utilisé.

Petit avantage : AMOS utilise son propre système d'exploitation. Aussi, avec ce BASIC, les erreurs n'apparaîtront le plus souvent qu'après la compilation car il est rare de lancer AMOS ou un programme source AMOS par un cliquetis direct sur son icône comme on le fait avec les autres langages. Quel que soit le langage utilisé, il faut garder à l'esprit que :
  • Toute fenêtre ou écran préalablement ouvert doit être refermé.
  • Toute zone de mémoire réservée doit être libérée avant la sortie du codage.
La mémoire gruyère, autre problème spécifique

Ce bogue est fréquent sur de nombreux langages mais seul AMOS à le courage de le décrire. Je m'explique : chaque fois que vous chargez quelque chose en mémoire, cela se place dans les trous disponibles. Par exemple, si la mémoire est remplie comme suit ABCDEF... et que vous quittez le programme D, cela donnera la nouvelle configuration ABC.EF...

Si vous rajoutez une image pql, dans la mémoire cela donnera en principe ABCpEFql. Peu de logiciels savent bien utiliser la mémoire fragmentée (les trous). Il leur faut de la mémoire contiguë, autrement dit d'un seul bloc, et ainsi, si vous chargez et déchargez de nombreuses fois le même codage, celui-ci finira par ne plus fonctionner par manque de mémoire, alors que celle-ci existe pourtant mais pour son (notre) malheur, elle est morcelée.

Petit avantage du GFA, il regrouperait la mémoire morcelée en un seul paquet dès qu'il le peut et en général après qu'il ait rendu la main. Cela se passe souvent dans les trois à cinq secondes qui suivent et c'est pour cette unique raison qu'il est conseillé d'attendre un peu après l'exécution d'un codage GFA pour que celui-ci remette tout en ordre. Sinon, vous agissez à vos risques et périls.

Les erreurs de compilation

Pour en terminer, je voudrais parler d'un problème particulier à la compilation. Dans la plupart des langages évolués, les paramètres des commandes devront impérativement être des farfadets LONG%. "Paste Bob n" en AMOS risque fort par exemple de planter le système si n=2.3. Je dirais ici qu'il faut presque le faire exprès car AMOS travaille par défaut avec des farfadets LONG%.

Ce casse-tête devient encore plus spécifique avec les cartes accélératrices et se trouve exacerbé sur un A3000. On ne peut plus par exemple écrire en GFA "MOUSE sourisx,sourisy,sourisk" car les farfadets par défauts sont des réels en GFA et que cette fonction "MOUSE" travaille avec des LONG%, notés "ivar" dans le manuel. Il faudra mettre ici "MOUSE sourisx%, sourisy%. sourisk%".

J'ai passé plus de sept heures pour trouver mon erreur sur A3000 jusqu'au moment où j'ai eu l'idée de visionner toutes mes variables avec Dump. Comme il n'apparaissait pas de variables autres que celles que j'avais choisies, cela voulait dire que je n'avais pas mal orthographié l'un ou l'autre nom. J'en déduisais que soit le type de farfadet soit la logique du codage était défectueux. Je savais que la logique était correcte puisqu'elle fonctionnait sur A500. Je me demandais alors si le compilateur devenait beaucoup plus chatouilleux quand on passait de l'A500 à l'A3000 ou A2500. Pas du tout. Le bogue apparaît tout simplement plus vite. Il faut aussi préciser que c'était un miracle que le codage tienne cinq minutes sur un A500.

En résumé, quand on compile avec le mauvais farfadet, le plantage est immédiat ou presque. Il n'y a donc ici rien de nouveau par rapport aux compilateurs C ou autres. Peut-être devrons-nous attendre la version 4.0 du GFA et 3.0 d'AMOS ?

La spécificité d'AmigaOS 2.0

Les programmes réservant beaucoup de mémoire et qui fonctionnaient de façon limite sur AmigaOS 1.3 en AMOS, C, Devpac ou GFA ne fonctionnent parfois plus sur AmigaOS 2.0. C'est alors le code du fichier source qui est en cause. AmigaOS 2.0 demande plus de mémoire qu'AmigaOS 1.3.3 et en laisse donc moins pour le programme. Si vous n'aviez pas pris la peine de tester la mémoire disponible avant de la réserver, vous risquez le message "Manque de mémoire" dans le meilleur des cas, le Gourou s'il fait beau ou même le gel complet du système si votre signe est malchanceux.

Rencontre du troisième type

Ce mois-ci, nous allons afficher un texte à la manière du droit d'auteur du jeu Eye Of The Beholder ou des dialogues de Iron Lord. Lire du texte ASCII est aussi ce que fait la commande "Type" du Workbench.

Type permet de visionner les textes. Ainsi, si l'on voulait voir le contenu du fichier appelé "startup-sequence", on écrirait sous Shell :

Type df0:s/startup-sequence

Le plan d'action de cette commande, que nous allons nommer "Lit", consiste à rechercher le nom du texte, à vérifier s'il existe bien puis à présenter ce texte à l'écran. "Lit" le fera plus rapidement, page par page, en d'autres couleurs et avec l'heure en prime. Sa syntaxe sera identique :

Lit "nom_du_fichier" ; commentaires éventuels

Tout ce qui suit "Lit" depuis le guillemet avant "nom" jusqu'au "s" de "éventuels" est en effet contenu dans une variable spéciale nommée. Le codage va la convertir en majuscule puis, partisan du moindre effort, testera ce qu'elle contient. On ne décryptera le nom dans tout ce fatras que s'il y a quelque chose à lire.

Examinons la variable. Ce farfadet est ici constitué d'un nom de fichier parfois encadré de guillemets puis de remarques débutant par un ";". On délimite tout d'abord ces remarques grâce à une recherche "INSTR" sur le premier ";" du farfadet et on ne garde que la partie gauche "LEFT$" nous intéressant. On en profite pour élaguer les espaces superflus du début et de la fin du nom ("TRIM") puis on termine en supprimant les éventuels guillemets. Dernier débroussaillement ("TRIM") et on passe à la deuxième partie, la vérification de l'existence du texte ("EXIST").

Et c'est déjà la troisième partie. Il faut noter que la commande AmigaDOS "FF" permet d'accélérer encore la commande en GFA et pour l'activer, il suffit d'ouvrir le Shell et écrire "FF -0". En résumé, chaque page aura 19 lignes, sera en crème sur fond prussien et le page par page se fera comme pour Iron Lord. On attendra 10 secondes ou le cliquetis de la souris.

Pour en savoir plus

Passons aux détails : on ouvre un écran de 640x200 et non 640x256 car les écrans NTSC n'ont que 200 lignes. Il aura une épaisseur et sera en mode haute résolution. On ouvre alors une fenêtre activée sans avoir à cliqueter dedans. "OPEN" ouvre notre fichier de texte en lecture "i" et lui attribue le numéro 1.

"LOF" donne la longueur totale du texte et "INPUTS" le saisit ainsi totalement pour le stocker dans un farfadet appelé "fichier$". On n'oublie pas de tout refermer ("CLOSE") et on continue. Amiga étant international, Lit sélectionnera au hasard l'une des trois langues dominantes. En fait, c'est faux, il y a deux chances sur quatre pour que le titre soit en français. Écriture du titre puis présentation du texte.

Chaque ligne de texte se conclut par une touche "RETURN" codée 10 en ASCII. Il suffit de compter le nombre de return pour trouver le nombre de lignes. Et ça devient complexe. Au premier tour de la boucle REPEAT UNTIL, debut%, cherche% et fin% auront la valeur 0. Puis fin% augmentera de 1 et cherche% prendra pour valeur la position du premier return$ du farfadet fichier$. Par exemple 17.

Le nombre de ligne ligne% passe à 1. Et c'est le deuxième tour. fin% prendra la valeur 18 tandis que cherche% changera pour la nouvelle valeur de position du return$ suivant. Et de deux lignes. Bien. Cela continue ainsi jusqu'à la ligne 19 de la page sauf si on atteint la fin du fichier (et dans c cas il n'y aura pas toujours 19 lignes). Affichage de la première page. Affichage de l'heure. Passage à la deuxième page et tout le reste...

Ah ! J'oubliais. Il faut ôter la ligne "DF0:s/startup-sequence"... rajoutée ici pour la démonstration. Et il y a bien sûr encore et toujours les fameuses trois erreurs, deux de logique et une de syntaxe.

Codage de "Lit" en GFA Basic

GFA Basic
GFA Basic

Codage de "Lit" en AMOS

GFA Basic
GFA Basic


[Retour en haut] / [Retour aux articles] [Article précédent]