Obligement - L'Amiga au maximum

Mercredi 19 décembre 2018 - 06:02  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

 · Accueil
 · A Propos
 · Articles
 · Galeries
 · Glossaire
 · Liens
 · Liste jeux Amiga
 · Quizz
 · Téléchargements
 · Trucs et astuces


Articles

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

 · Articles in english
 · Articles en d'autres langues


Twitter

Suivez-nous sur Twitter




Liens

 · Sites de téléchargements
 · Associations
 · Pages Personnelles
 · Matériel
 · Réparateurs
 · Revendeurs
 · Presse et médias
 · Programmation
 · Logiciels
 · Jeux
 · Scène démo
 · Divers


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


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


Partenaires

Annuaire Amiga

Amedia Computer

Relec

Hit Parade


Contact

David Brunet

Courriel

 


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 l'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. A 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.


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