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 : C - gestion des ports manette
(Article écrit par Laurent Faillie et extrait d'Amiga News - mai 1994)
|
|
Les bidouilles matérielles pour Amiga utilisent principalement le port parallèle Centronics.
Il faut dire qu'il a de nombreux avantages : il est bidirectionnel, relativement rapide,
facile à utiliser et à programmer, avec un "bus de données" de 8 bits ce qui est indispensable
pour tout numériseur et surtout, il est facile de trouver des informations le concernant...
Mais il a aussi des inconvénients : il est très mal protégé et une mauvaise manoeuvre risque de griller
un des précieux CIA 8520 (parlez-en à certains utilisateurs de ParNet !). Pour moi, cependant, son
principal défaut est d'être unique : on est obligé d'utiliser ce port pour les numériseurs
et les imprimantes, mais en ce qui concerne les cartes d'E/S simples, il y a une autre possibilité :
les ports manette.
Sur ces connecteurs 9 broches, nous disposons :
- D'une alimentation +5 Volts (125 mA maxi).
- D'une masse évidemment.
- De 7 entrées dont 3 peuvent être retournées en sorties. Eh oui, ces ports peuvent
sortir des signaux...
En plus ces ports sont particulièrement bien protégés contre les parasites. Les Amiga
1000 disposent en plus de protections contre les surcharges et les mauvaises manoeuvres
(quand on vous dit que l'A1000 est le meilleur ordinateur jamais construit !).
Les brochages
Les deux ports ont les mêmes caractéristiques et les mêmes brochages. L'un comme l'autre
peuvent gérer une souris, une manette, qu'elle soit analogique (proportionnelle)
ou non, ou enfin un crayon optique.
Attention : sur les manettes, tous les boutons sont généralement connectés en parallèle sur
la même entrée Feu 1. Bon, je ne vous ferai pas l'affront de vous rappeler que ces signaux sont
actifs au niveau bas : une manette en position Gauche par exemple ne fait que relier la broche
3 à la masse. Je passerai aussi sur la lecture de la position de la souris car le sujet a déjà
été largement traité, ainsi que sur les crayons optiques... car je n'en ai pas !
Peut-être une autre fois.
Test des broches 1 â 4 (haut, bas, gauche, droite)
La position de ces signaux est accessible grâce aux registres joy0dat et joy1dat
des circuits spécialisés qui, je le rappelle sont sur 16 bits.
- Haut = ou_exclusif(bit 8 (0x0100), bit 9 (0x0200))
- Bas = ou_exclusif(bit 0 (0x0001), bit 1 (0x0002))
- Gauche = bit 9 (0x0200).
- Droite = bit 1 (0x0002).
Ce procédé complexe permet d'utiliser les mêmes registres que ce soit pour lire la position de la
souris ou les entrées de la manette. Leurs valeurs dépendent donc du périphérique connecté.
Ces quatre broches ne peuvent être utilisées qu'en entrée.
Les broches 6 (Feu 1)
Ces broches sont gérées par le port A du 8520A. Bit 6 pour le port 0 (souris) et
bit 7 pour le port 1 (manette). On peut donc facilement les retourner en sortie.
Je rappelle que les ports A et B de chaque 8520 sont accessibles par les champs pra
et prb des structures CIA et disposent de registres de direction nommés ddra
et ddrb. Dans ces registres, les bits mis à 0 indiquent que les bits correspondants
du port sont utilisés en entrée et inversement. Pour tester F1 de la manette,
il suffit de rajouter les lignes suivantes au source précédent...
Certains ont dû remarquer que je n'initialisais pas ce bit en entrée car il l'est
déjà par défaut. Utilisons maintenant cette broche en sortie :
Ce listing ne présente pas de difficulté particulière. Prenez un voltmètre ou une simple LED
pour voir que la broche 6 varie bien. Attention, tout comme le timer.device, le signal délivré
n'est pas précis au millième de seconde près : l'Amiga étant une machine multitâche, d'autres
processus peuvent utiliser le processeur au moment de "réveiller" ce programme, différant quelque
peu le changement d'état de la sortie. Le seul et unique moyen d'avoir un signal extrêmement précis
est d'utiliser les timers des CIA.
Les broches 5 et 9 (feu 2 et 3)
L'utilisation de ces signaux est plus complexe que pour les précédents. Ils sont
commandés par un registre nommé POTGO en écriture et POTINP en lecture...
Le bit 0 sert à débuter la lecture d'une donnée sur les quatre entrées analogiques, c'est-à-dire
POTX et POTY des ports souris et manette. J'en reparlerai plus tard. A l'instar des registres
de direction des CIA, "Dir??" indiquent si les broches correspondantes sont utilisées en entrée
(0) ou en sortie (1), et "Dat??" contiennent les données correspondantes.
Il est fort probable que ce programme ne marche pas correctement. Pour comprendre le pourquoi,
examinons l'utilisation de ces signaux en entrée. Comme je l'ai dit précédemment, ces
signaux sont aussi utilisés pour lire des données analogiques. Ils ont donc des structures différentes
des autres ports d'E/S. J'ai mis du temps à trouver l'astuce suivante car aucune doc en ma possession
ne disait comment procéder. Mais après quelques minutes de PEEK et de POKE
et l'utilisation d'un oscillo, la solution m'est apparue... lumineusement.
Pour connaître le niveau d'une entrée, il faut d'abord la positionner à l'état haut.
A la lecture, si le bit correspondant de POTINP est à 0, l'entrée est activée. Niveau programmation, cela
donne, toujours pour le port 1 :
Le fait de remettre immédiatement les signaux en entrée évite de sortir réellement une tension.
Et le multitâche dans tout ça ?
Comme vous avez dû remarquer, dans tout ce qui précède, je n'ai utilisé que le port 1, et,
quelle que soit l'action faite, j'ai toujours mis à 1 les bits DATOX et DATOY de POTGO.
En effet, dans un environnement multitâche normal, le port 0 est utilisé en permanence par...
l'input.device. Eh oui, rappelez-vous, qu'est-ce qui est branchée sur ce port ?
La souris bien sûr. Pour la gérer, l'input.device fait appel au gameport.device qui place une
routine sur l'interruption VBL. Elle se produit tout les 1/50e de seconde sur nos machines PAL.
Cette routine va lire évidemment les compteurs de la souris, les positions des divers boutons et
réinitialiser DATOX et DATOY. C'est pourquoi le programme OutF2.c ne marche pas correctement :
il a bien commuté en sortie DATOX. Au prochain VBlank, le gameport.device va replacer ce signal en
entrée car il ne peut pas savoir à quelle valeur nous l'avons initialisé. Résultat : nous ne verrons
qu'un bref flash mais pas un signal d'1/2 seconde.
Enfin, en ce qui concerne DATOX, si vous ne le laissez pas au niveau haut vous verrez la ligne
de menu clignoter en haut de l'écran car le système croira que vous cliquez sur le second bouton de la souris...
Comment utiliser ces ports ?
Dans le cas où votre application n'utilise pas le système, comme les jeux, les exemples de code
que je donne précédemment devraient suffire. Attention à supprimer l'interruption VBL
du gameport.device qui reste active même après que l'on ait interdit le multitâche. Cette
routine n'est installée qu'à partir du moment où une console est ouverte ou qu'Intuition est lancé.
Pour une utilisation normale, c'est-à-dire utiliser une souris ou une manette, dans un environnement
multitâche normal, la meilleure solution est d'utiliser le gameport.device.
De nombreux exemples existent, dont la disquette Fish 5
qui contient divers exemples de programmation provenant directement de l'équipe Amiga.
Si les périphériques logiques ne sont pas suffisants, choisir principalement le port 1, voir le Feu 3
du port 0 qui n'est pas utilisé en standard par le système, pour lire les boutons 2 et 3
des ports, utiliser la méthode expliquée précédemment mais en interdisant les interruptions.
Attention : le système d'exploitation est très dépendant de ces dernières. Elles doivent
être interdites le moins longtemps possible. Donc, pas de Wait(), sleep(), ou autres
printf(), etc. Exemple :
Le cas le plus complexe est quand on utilise F2 et F3 en sortie : il faut installer notre propre
routine d'interruption pour initialiser PotGo.
"inter()" est donc appelé à chaque VBL. Gardez toujours à l'esprit que ces routines doivent être
les plus courtes possibles. Allocations mémoire interdites, ainsi que les fonctions d'E/S
comme ?printf(). Concernant cet exemple, notez bien que PotGo ne contiendra "val" qu'après l'interruption
VBL suivante.
Enfin, une dernière remarque : si ces signaux doivent commander des circuits intégrés, il faut que notre
routine soit placée immédiatement après celle du gameport.device, sinon F2 et F3 risquent de comporter
des pics dû à l'exécution des serveurs entre le gameport et notre programme.
Lecture d'une valeur analogique
L'Amiga possède deux entrées "analogiques" par port manette : PotX et PotY. Pour les utiliser,
il faut placer un potentiomètre d'au maximun 470 kiloohms entre l'entrée utilisée et le +5.
On commence la mesure en plaçant le bit 0 de PotGo à 1. Les condensateurs qui se trouvent sur les quatre
entrées analogiques sont alors déchargés et les registres POT?DAT initialisés. A chaque nouvelle ligne
d'écran, les compteurs sont incrémentés, pendant que les condensateurs se chargent petit à petit à travers
les potentiomètres. Lorsque la tension aux bornes d'un condensateur devient supérieure à une valeur déterminée,
le compteur correspondant n'est plus incrémenté : son contenu représente alors la valeur du potentiomètre.
Pour éviter de voir les menus des fenêtres s'agiter, nous allons encore utiliser le VBL.
Voilà, c'est tout ! J'espère que l'on va pouvoir trouver des cartes d'extension pas chères utilisant
ces ports qui sont vraiment très intéressants. Petit rappel quand même : l'Amiga utilise des circuits
TTL alimentés en 5 V et qui supporteraient très mal le 220 V. D'un autre côté, sur mon A1000, la masse
est reliée à la terre. Attention donc en utilisant les oscilloscopes.
Mise à jour de juin 1994
Les exemples que je vous ai donnés plus haut concernant l'utilisation des
signaux de feux 2 et 3 des ports manette ne respectaient pas le système d'exploitation :
ils provenaient d'une application que je développais qui fonctionnait en même temps
que des programmes multimédias comme AmigaVision ou Scala. Ces derniers pouvant utiliser les
ports manette, il n'est plus possible à d'autres tâches de modifier la valeur des signaux
inutilisés avec le mécanisme du système d'exploitation. Voici donc ces mécanismes qui
sont disponibles à travers le PotGo.device :
allocated = AllocPotBits(bits);
Cette fonction permet d'allouer des bits du registre PotGo. Ces bits sont spécifiés
par l'argument. On trouve bien sûr les "DatLX", "DatLY", "DatRX" et "DatRY" pour indiquer
les bits à allouer. Les bits "Out??", que j'avais nommés "Dir??" plus haut,
ont un sort particulier : s'ils sont mis à 1, l'entrée correspondante est insensible
au bit "Start". Si le bit "Start" est alloué simultanément, cela signifie que les
entrées dont le bit "Out??" est à 0 seront utilisées en temps qu'entrée analogique.
FreePotBits(allocated);
C'est le pendent de la fonction précédente : elle libère les bits passés
en argument.
WritePotgo(word, mask);
Permet d'écrire une valeur, word, dans le registre PotGo. Mask
permet d'indiqué quels sont les bits touchés.
|
