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
|
|
|
|
Le courrier des lecteurs d'Amiga News Tech - avril 1991
(Rubrique animée par Frédéric Mazué et extraite d'Amiga News Tech - avril 1991)
|
|
Ouvrage AmigaDOS, ARexx
J'ai deux questions :
1. Je possède déjà les RKM (Libraries & Devices, Includes & Autodocs), les deux Amiga Programmer's
Handbook et le Programmer's Guide To The Amiga. Y a-t-il un ouvrage complet sur AmigaDOS ?
Les RKM font parfois référence à un "AmigaDOS Manual". Où peut-on se le procurer ? Épargnez-moi s'il vous
plaît les références aux ouvrages français.
2. Je ne maîtrise pas du tout le langage ARexx et je trouve l'ARexx User's Reference Manuel
fort laconique et sibyllin. Pourtant, j'en ai un besoin impérieux : j'utilise CygnusEd Pro
et j'assemble avec le GenAm2 du Devpac, et je donnerais gros pour disposer de macro-commandes ARexx
me permettant au moins d'assembler à partir de CED Pro, et éventuellement de pister les erreurs,
ou autres gadgets propres à me faciliter l'assemblage. Où puis-je trouver cela ? Je lance un appel
à quiconque disposerait de tels outils [Pierre-Louis Mangeard].
Réponse
L'AmigaDOS Technical Reference Manual est un ouvrage quasi-introuvable en France. Pour se le procurer,
il faut s'adresser directement à Commodore France qui de toute façon refusera si vous n'avez pas au
moins le statut développeur. C'est dire. Vous pouvez essayer de ruser : trouvez un développeur qui
acceptera d'acheter le livre pour vous le revendre ensuite. Comme j'en vois venir, je précise d'emblée
que ni l'ANT ni Amiga Revue n'ont le statut développeur - on ne peut pas être à la fois journaliste et programmeur,
paraît-il...
Il y a foison de commandes ARexx susceptibles de vous satisfaire dans le domaine public, notamment
dans la collection Fred Fish. Il faut vous procurer le catalogue afin de localiser les disquettes
pouvant vous intéresser. Ce serait tout à fait dans l'esprit de l'ANT si un lecteur pouvait répondre
à cet appel. Et également nous en faire part car cela peut toujours servir.
Aztec C ou Lattice ?
Bonjour à toute l'équipe ! Je suis vraiment content que l'ANT soit devenu indépendant. Nous avons
enfin en France un vrai journal pour les programmeurs sur Amiga. Je ne veux pas dire que l'ANT
d'avant, celui intégré à Commodore Revue, n'était pas bien, mais un vrai journal c'est tout de même mieux.
Voilà ce qui m'amène jusqu'ici, je programmais uniquement en assembleur (à propos, vous avez raison :
Devpac, c'est vraiment ce qu'il y a de mieux), mais je me rends compte qu'il est certainement plus
avantageux de programmer en C pour de gros programmes. Aussi j'envisage d'acheter un compilateur,
mais je n'arrive pas à me décider entre l'Aztec et le Lattice. C'est un gros investissement pour moi,
alors mieux vaut ne pas risquer d'être déçu. Vous paraissez pour le Lattice, mais les gars d'A-News
(que je lis aussi, j'espère que vous ne m'en voudrez pas trop) semblent plutôt préférer l'Aztec.
Donc j'hésite. Comment faire un choix ? Est-il vrai que le Lattice comporte des bogues ?
[Denis Bortolin].
Réponse
Effectivement, je ne jure que par le Lattice et tous ici à l'ANT nous l'utilisons. En toute objectivité,
il faut dire que les deux compilateurs sont excellents, chacun avec leurs avantages et leurs défauts.
Par exemple, l'Aztec compile sensiblement plus vite, mais je trouve l'éditeur de liens peu pratique,
et pour générer des overlays, c'est une vraie m.... (ou alors je n'ai rien compris). Parallèlement,
le Lattice compile plus lentement, mais l'éditeur de liens est à mon avis très souple d'utilisation
et également plus rapide (BLink version 5.10). On pourrait ainsi multiplier les exemples.
Pour faire un choix, il peut être judicieux d'examiner les options de compilation présentées par
chacun, ainsi que leurs bibliothèques. Toutefois, on peut considérer que l'environnement de l'Aztec
est un peu austère, et c'est là surtout que se fait la différence. Le Lattice permet de compiler
et relier depuis l'éditeur, ce qui est loin d'être désagréable (le Turbo C permet aussi de déboguer
depuis l'éditeur, et c'est encore plus pratique. Pourquoi pas le Lattice ?).
Réciproquement, si l'on compile depuis le CLI, une option provoque l'appel de l'éditeur si
une erreur est rencontrée, ce qui permet des corrections très rapides. À propos d'éditeur, celui
de l'Aztec est par trop épouvantable. Le Lattice propose également un startup catch, ainsi que
certains utilitaires (tb, lprof, lstat...) que l'on ne retrouve pas dans l'Aztec. Enfin,
les "keywords" chip et _asm, entres autres, sont de véritables bijoux spécifiques au Lattice.
On peut éventuellement résumer la situation ainsi : l'Aztec est un excellent compilateur, très
rigoureux, très "C", mais qui n'offre pas un confort en rapport avec les capacités de l'Amiga. Le
Lattice est un excellent compilateur, un peu moins rigoureusement "C", mais beaucoup plus Amiga.
C'est surtout sur l'environnement de développement que se fait, à mon avis, la supériorité du Lattice.
Le Lattice comporte effectivement quelques bogues, mais il y a toujours moyen de s'en sortir. N'allez
pas croire ce que certains disent, le Lattice n'est pas bogué de partout. D'ailleurs,
il ne faut pas se faire d'illusions. Je suis sûr que l'on peut également se heurter à des bogues
dans l'Aztec lors d'une utilisation poussée. En lui "tirant les vers du nez" comme dirait Pascal
Amiable.
Programme Sentinelle
Je tiens vraiment à vous féliciter pour votre programme
Sentinelle du mois de décembre 1990.
En effet, j'ai pu grâce à lui trouver sur quel fichier s'était installé un virus-coquille qui
voulait me faire de grosses misères. Mais, même si je vous félicite, je n'ai pas toute confiance.
Je suis devenu plutôt méfiant à cause de mes déboires avec les virus ces derniers temps.
Aussi je voudrais avoir le moyen de m'assurer à n'importe quel moment si votre Sentinelle
est toujours en train de surveiller l'ordinateur. Ce moyen est sûrement donné dans l'article,
mais je suis vraiment débutant et je n'ai pas tout compris.
Autre chose. Un copain à moi a programmé un petit utilitaire destiné à vérifier le bit 31
des vecteurs de sauts d'exec.library, afin de voir par ce moyen s'il n'y aurait pas de virus
(c'est mon copain qui dit tout ça, hein, moi je ne comprends pas tout). On souhaiterait savoir
si l'idée est bonne. De plus, nous avons remarqué que s'il l'on place son petit programme au
début de la startup-sequence, tout va bien, mais si on le place à la fin, il indique la présence
d'un virus. Mais cette fois, nous n'avons pas pu en localiser. Que se passe-t-il ?
[Gilles Mingot].
Réponse
Pour vérifier que la Sentinelle est bien active, vous pouvez utiliser le programme suivant :
include 'exec/execbase.i'
move.l $4,a0
move.l d0,CoolCapture(a0)
rts
|
Si vous appelez ce programme depuis le CLI et que l'alerte apparaît, c'est que tout va bien,
la Sentinelle veille au grain. Il vous suffit alors de cliquer le bouton gauche.
Votre idée est très bonne. Rassurez-vous, vous n'avez pas de virus. C'est le programme SetPatch
de la startup-sequence qui provoque cela, et c'est normal car ce programme détourne certains sauts
(qui ne vont donc plus en ROM) afin de corriger quelques bogues des bibliothèques de l'Amiga. Il
vous faut donc d'abord savoir quelles sont les valeurs de saut normales après l'appel de SetPatch
et programmer votre utilitaire en conséquence (Note de Stéphane Schreiber : j'ai eu le même problème
avec SetPach et la Sentinelle ; en fait, si SetPatch est utilisé sans l'option "r" (résident ?)
les messages disparaissent).
Programme compatible Seka mais pas avec Devpac
Je programme en assembleur et j'ai acheté Devpac puisque vous avez tellement insisté.
J'en suis d'ailleurs extrêmement content. Le débogueur est vraiment remarquable. C'est quand
même autre chose que la petite fenêtre minable de Seka. Toutefois, il m'arrive quelque
chose de très bizarre. Un programme qui allait bien avec Seka ne fonctionne plus avec Devpac.
Je veux dire que Devpac n'arrive pas à l'assembler. Il bloque à la ligne move.l #$0a,6(a0)+.
Pouvez vous m'expliquer ce qui se passe exactement et comment faire fonctionner mon programme ?
[Philippe Boussugue].
Réponse
Ooouuaaahhh ! Une question sur Seka. Je vais pouvoir déverser tout mon fiel. Houba !
Surtout que dans ce cas, il y a vraiment de quoi rire... Voilà ce qu'il se passe : une instruction
d'adressage avec distance et post-incrémentation n'existe pas en 68000. C'est donc on ne peut
plus normal que ce brave Devpac refuse de l'assembler.
Partant de là, voyons un peu les élucubrations du Seka. Celui-ci assemble comme si de rien n'était
l'instruction. Mais en fait, si l'on examine le code produit, on s'aperçoit que l'instruction a
été remplacée par move.l #$0a,6(a0,d0.w). C'est la même chose ? Pas du tout ! La post-incrémentation
a été remplacée par une distance relative au contenu de D0. Mais le contenu de D0 n'a pas été
initialisé en conséquence. C'est donc déjà un véritable miracle que votre programme marche.
De plus, ce mode d'adressage ne modifiera pas A0, donc en aucun cas il y aura post-incrémentation.
C'est encore plus un miracle si votre programme marche ! Et enfin, si par malheur
D0 contient une valeur impaire, c'est un gourou assuré. Vous êtes vraiment sûr que votre programme
marche ?
Puisque j'y suis, en voilà (parmi tant d'autres) une bien bonne. Soit l'instruction
movea.l #$10000,a0. Voilà une instruction 68000 parfaitement correcte. Eh bien cette
fois, Seka refuse obstinément de l'assembler. Moralité, cet abruti de Seka assemble les
instructions inexistantes, mais n'assemble pas celles qui existent. Je me marre !
Programmes détachables
Comment un programme peut-il se détacher du CLI ? Je parle des programmes comme VirusX,
Cygnus Editor ou DiskMaster, qui "rendent la main" au CLI même si on ne les lance pas avec
la commande Run. Je possède la Bible de l'Amiga, mais les routines concernant cette fonction sont en C,
et je ne fais que de l'assembleur. Et je ne trouve une telle routine dans aucun ANT.
Pourriez-vous en publier une ? S'il vous plaît, répondez-moi, car si vous, programmeurs
de l'ANT, ne répondez pas à vos lecteurs avides de connaissances, qui le fera ?!?
[Xavier Averbouch].
Réponse
Les programmes que vous citez ont un moyen fort simple de se détacher du CLI : écrits
sans aucun doute avec le Lattice C, ils sont été reliés avec "cback.o", un startup
spécifique au Lattice qui permet de genre de miracle.
Êtes-vous sûr d'avoir bien lu tous les ANT ? Je me souviens avoir donné dans ces mêmes pages,
une routine assembleur équivalente au "cback.o", nommée BackStart.i et destinée à être incluse
en début de source, à la place du Startup.i standard (ou du EasyStart.i du Devpac). Mais si,
cherchez bien : c'était dans le numéro 19 de l'ANT
(c'est pourtant pas si vieux).
DMACONR et Blitter
Salut ! Juste une question simple, par curiosité : j'ai vu récemment dans le source d'un copain,
qu'il testait deux fois le bit 14 du registre DMACONR, avant de démarrer une opération avec le
Blitter. Quand je lui en ai demandé la raison, il m'a rétorqué que c'était obligatoire, sinon,
ça pouvait faire foirer le Blitter. Étant donné que c'est la première fois que je vois ça,
pourriez-vous m'en dire un peu plus ?
[Alain Garnier].
Réponse
Votre copain a certainement lu - et il en a été bien avisé - les RKM ou quelque ouvrage
en étant inspiré (je ne parle bien entendu pas de la Bible de l'Amiga). Cela dit, il n'a que partiellement
raison. Je m'explique. Tout le monde sait que le Blitter travaille en parallèle avec le 68000,
ce dernier se chargeant de l'initialiser. Mais pour ce faire, il ne faut pas que Blitter
soit déjà en train de travailler, sinon ça fait pas beau à l'écran. C'est le travail du
bit 14 de DMACONR, appelé DMAF_BLTDONE, qui renseigne le 68000 sur une éventuelle activité du
Blitter. Or, celui-ci ne positionne DMAF_BLTDONE que lorsqu'il a reçu son premier cycle DMA,
ce qui peut durer un certain temps si le DMA est surchargé de travail, ou si un 68030
travaille en mémoire Fast en mode cache...
La solution pour être sûr que le Blitter fut effectivement disponible, était de tester deux
fois DMAF_BLTDONE. Je dis "était", car depuis que Fat Agnus a été créé, ce "bogue" a
été corrigé : le Blitter positionne dorénavant DMAF_BLTDONE dès l'écriture dans BLTSIZE,
rendant ce double test obsolète. Cela dit, si l'on veut être sûr que son programme tournera
sans problème sur tous les modèles d'Amiga, et particulièrement l'A1000, il est préférable de
le laisser.
|
