Suivez-nous sur X
|
|
|
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
|
|
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
|
|
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
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
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
Codage de "Lit" en AMOS
|