Obligement - L'Amiga au maximum

Dimanche 18 février 2018 - 11:53  

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 in other languages


Twitter

Suivez-nous sur Twitter




Liens

 · Sites de téléchargements
 · Associations
 · Pages Personnelles
 · Moteurs de recherche
 · Pages de liens
 · Constructeurs matériels
 · Matériel
 · Autres sites de matériel
 · Réparateurs
 · Revendeurs
 · Presse et médias
 · Programmation
 · Développeurs logiciels
 · Logiciels
 · Développeurs de jeux
 · Jeux
 · Autres sites de jeux
 · Scène démo
 · Divers
 · Informatique générale


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

 


Livre : Amiga ROM Kernel Reference Manual: Devices (3e édition)
(Article écrit par Xavier Leclercq et extrait d'Amiga News - septembre 1992)


Ce deuxième volet est consacré au manuel technique (3e édition) de Commodore-Amiga, Inc. se rapportant aux "devices" (Bruce Lepper : le premier volet était sur les "Includes et AutoDocs"). Je vais profiter de l'occasion pour éclaircir un peu votre lanterne, si besoin est, à propos de notions fondamentales se rapportant à ces fameux devices. Je vais d'abord essayer de vous persuader d'utiliser les devices et donc de justifier l'achat de ce volume RKRM.

RKRM - devices

RKRM - devices

Les devices

Un device est une interface entre le logiciel que vous concevez et le matériel de l'Amiga. Pour illustrer par une image, établissons un parallèle entre vous, un expert fiscal et le percepteur d'impôts. Pour payer au mieux votre contribution à la société, vous engagez un expert fiscal qui se fait un devoir de connaître les modalités les plus adéquates, et susceptibles d'être modifiées au cours des ans, pour assumer votre devoir d'honnête citoyen.

Le percepteur est un homme heureux, puisqu'il reçoit dans les meilleures conditions ce qu'il vous réclame. Pour revenir à des conceptions plus terre-à-terre, mettons à bas les masques pour découvrir que le device de notre jolie histoire n'est autre que l'expert fiscal et que bien entendu le percepteur d'impôt est le matériel de l'Amiga. En effet, pour commander une action X d'un périphérique, il faut utiliser sur l'Amiga Y une adresse en mémoire Z (qui correspond en règle générale à un circuit dédié au périphérique). Mais l'eau ne cesse de couler sous les ponts et un beau jour vous décidez d'acheter un Amiga Y+... Malheureusement pour vous, l'Amiga Y+ n'emploie plus l'adresse Z pour commander le périphérique mais une adresse Z+ ! Conséquence : votre géniale application ne fonctionne plus !

Pourtant, ce problème peut être résolu assez facilement, en déclarant à votre application de ne pas directement commander le périphérique via l'adresse Y, mais d'adresser votre requête au device correspondant du périphérique. En fait, si vous écoutez ce conseil d'ami, c'est Commodore-Amiga qui réalisera le travail de mise à jour de programmation via son interface, c'est-à-dire le device. Le premier point est donc d'assurer le bon fonctionnement de la commande du périphérique, quelle que soit la version de la ROM et de l'Amiga.

Le multitâche

Le deuxième point qui doit vous motiver à programmer via les devices est plus lié à la nature même de l'Amiga. Ce point à lui tout seul (petit mais costaud) justifie pour ma part à 200%, l'achat d'un Amiga plutôt qu'un #!@$? de PC : le multitâche (sans la lourdeur de Windows).

Prenons le cas par exemple d'un programme désirant lire le bloc racine (root) d'une disquette introduite dans le lecteur interne. Ce programme commande l'allumage du moteur, le positionnement de la tête de lecture, et les diverses autres opérations en attaquant directement les adresses des circuits spécialisés pilotant le lecteur interne. Et si, simultanément un second programme veut ajouter une information au bloc racine, l'information lue par le premier programme ne correspondra plus. Donc il est intéressant de fixer des priorités et un système de dialogue entre le périphérique et l'application. Bref, la programmation via le device du périphérique répondra à tous ces critères.

Standard de programmation

Le troisième point est une question de standard de programmation. Pour réaliser des opérations aussi différentes qu'écrire des informations sur une disquette ou jouer un échantillon sonore via les canaux audio, la procédure à suivre sera toujours identique... L'idée est donc que la programmation des différents devices vous faciliteront la vie.

Mais quelle est la nature des devices ? Réponse simple : des tâches... Il y a autant de devices, et donc de tâches, que de périphériques qui lui correspondent. Par exemple, il y aura trois tâches "trackdisk.device" pour trois lecteurs de disquette branchés (l'input.device, le printer.device, l'audio.device sont aussi des tâches ayant le type NT_DEVICE).

Votre programme en exécution est lui aussi une tâche camouflée en processus car comme il évolue dans un environnement multitâche, il ne peut pas monopoliser tout le temps processeur. Il peut être chargé à n'importe quel endroit de la mémoire. Nous avons donc deux "tâches" : un device et un processus qui peuvent se trouver n'importe où en mémoire et n'ayant, à première vue, aucun lien entre eux. Le problème du processus est de trouver un moyen pour communiquer au device, les actions qu'il veut commander. Et le problème du device est de trouver un moyen de communiquer à son tour au processus si, par exemple, la commande s'est déroulée sans problèmes.

Une "mémoire tampon commune" sera employée pour une communication bilatérale entre le processus et le device. Cette mémoire tampon très spéciale est connue sous le vocable "message port". Prenons un exemple concret qui sera suivi de sa codification en C. Vous désirez fixer le pointeur de votre souris à une position (X,Y) donnée de votre écran Workbench. Le nom du device se chargeant du traitement de ces événements est "l'input.device". Votre programme, "inerte" sur disquette, est chargé à l'aide du CLI/Shell quelque part en mémoire et devient alors un processus actif.

A ce stade, ce qui différencie le processus d'une tâche, est le fait qu'un processus possède un pointeur sur le CLI courant et peut ainsi exécuter des commandes DOS à tout moment (ce qui est impossible à une tâche). Le processus possède une priorité, c'est-à-dire un nombre qui détermine son classement d'ordre dans une liste. Cette liste est la liste des tâches/processus qui attendent de passer à un état d'attente (WAIT) à un état d'exécution (RUN).

La liste est triée par un programme qui est à la base du système multitâche sur Amiga et dont on ne parle pratiquement jamais car non référencé par les manuels techniques (y compris les ROM Kernel). Cette procédure clé est l'ordonnanceur ("scheduler"). Vous ne vous êtes sans doute jamais posé la question mais que fait l'Amiga quand il n'est sollicité nulle part ? Il boucle dans le noeud d'Exec, c'est-à-dire l'ordonnanceur !

L'ordonnanceur

Il "ordonnance" ! (offset -42 de l'exec.library). En clair, il calcule le temps d'exécution qui sera accordé à chaque tâche suivant chaque priorité. Mais attention, le processus ne peut, même avec une très haute priorité, dépasser un certain temps. Ce temps est le "quantum time", temps maximum où une tâche est en état d'exécution (+/- 50ms). Il n'y a d'ailleurs toujours qu'une tâche en mode "RUN" à la fois. Lorsque l'ordonnanceur estime qu'une tâche doit passer du mode RUN au mode WAIT, il passera la main à une procédure de commutation de tâche ("task-switching", améliorée avec le 2.04) qui effectuera en douceur le passage d'une tâche à l'autre (simplement en sauvegardant l'environnement, c'est-à-dire la pile, les registres et le compteur ordinal de la tâche).

Sur Amiga, une seule adresse est toujours connue : execbase à l'adresse absolue $00000004. Tout le reste (liste des tâches en attente, liste des ports messages) est lié inévitablement à cette adresse.

Notre processus est donc actif. Il va d'abord créer/allouer un port message, c'est-à-dire un endroit de la mémoire qui servira de rendez-vous au processus et au device. Puis il préparera sa demande d'entrées/sorties dans une structure IORequest standard qui devra posséder la référence au port message qui a été créé.

Ensuite, le lien est enfin établi en ouvrant l'input.device et en lui fournissant notre demande d'entrées/sorties (BeginIO). Reste alors à attendre que l'input.device se manifeste via le port message pour signifier la réalisation de la commande. Le processus se met en mode WAIT car il attend un événement du port message (Wait-Port). Et il se "réveille" lorsque le message en provenance du message port arrive et transmet au device qui l'a correctement réceptionné (GetMsg).

BeginIO() et WaitPort() peuvent être remplacés par un unique DoIO() ce qui revient au même mais est moins parlant pour mon exemple pédagogique. Reste alors à tout fermer. Remarquez que j'utilise malloc() plutôt que la fonction d'Exec AllocMem() car cela prend moins de place et est en norme ANSI (pas besoin d'un type de mémoire spécial non plus). Voir listing ci-dessous.

RKRM - devices
RKRM - devices

Conclusion

L'Amiga ROM Kernel Reference Manual "devices" (3e édition) est un volume de 580 pages en anglais composé de 15 chapitres traitant des devices suivants : Audio, ClipBoard, Console, Gameport, Input, Keyboard, Narrator, Parallel, Printer, SCSI, Serial, Timer et Trackdisk.

Il est manifeste qu'il se révèle indispensable pour aborder le nouveau Kickstart 37.175. La mise en garde reste qu'il est tout aussi vital de connaître le C si l'on veut progresser à la lecture de l'ouvrage. Pour un environnement agrémenté de multitâche et de devices, votez pour ce ROM Kernel Manual.

Nom : Amiga ROM Kernel Reference Manual: Devices (3e édition).
Auteur : Commodore-Amiga, Inc.
Éditeur : Addison Wesley Publishing Company.
Genre : livre sur le système d'exploitation Amiga.
Date : 1991.
Prix : 490 FF.


[Retour en haut] / [Retour aux articles]