Faculté des Sciences Appliquées Cours de Systèmes porgrammés enfouis. Chess Game FRANÇOIS DUPONT, GEOFFREY DORET, SÉBASTIEN PIÉRARD, RENAUD WARMON

Faculté des Sciences Appliquées Cours de Systèmes porgrammés enfouis Chess Game FRANÇOIS DUPONT, GEOFFREY DORET, SÉBASTIEN PIÉRARD, RENAUD WARMON Année académique 2005-2006

i Table des matières Table des matières Table des figures ii iii Remerciements 1 1 Introduction 2 2 Historique 3 3 La souris 9 3.1 L interface électrique....................... 9 3.2 Le protocole PS/2......................... 10 3.2.1 Généralités........................ 10 3.2.2 Communication périphérique microprocesseur.. 11 3.2.3 Communication microprocesseur périphérique.. 12 3.3 Le protcole souris......................... 13 3.3.1 Mode Reset........................ 14 3.3.2 Mode Stream....................... 14 3.3.3 Mode Remote....................... 14 3.4 Structure de la communication................. 14 4 Le signal vidéo 16 4.1 Description générale....................... 16 4.2 Synchronisation horizontale................... 17 4.3 Synchronisation verticale..................... 18 4.4 Implémentation du circuit vidéo................ 19 5 L interface graphique 22 6 La gestion du jeu 24 7 Conclusion 28 8 Le circuit 29

TABLE DES MATIÈRES ii Bibliographie 31

iii Table des figures 3.1 Schéma d un port PS/2...................... 9 3.2 Schéma électrique de la souris.................. 10 3.3 Schéma d une trame de réception................ 12 3.4 Schéma d une trame d envoi................... 13 3.5 Schéma d activité de la souris.................. 15 4.1 Balayage de l image........................ 16 4.2 Signal vidéo PAL monochrome................. 17 4.3 Top de synchronisation horizontale............... 18 4.4 Tops de synchronisation verticale................ 19 4.5 Circuit vidéo............................ 19

1 Remerciements Nous tenons vivement à remercier Monsieur BERNARD BOIGELOT pour le savoir qu il nous a communiqué tout au long de ce quadrimestre dans le cadre du cours de Systèmes programmés enfouis, ainsi que pour nous avoir donné l occasion de découvrir le monde merveilleux de la logique programmable. Nous adressons également nos plus vifs remerciements à Monsieur PASCAL HARMELING qui a montré beaucoup d intérêt pour notre projet et nous a accordé un peu de son temps. Nous remercions également Monsieur CHRISTOPHE BURNOTTE. Nous n oublions pas Monsieur FABRI- ZIO IACOPETTI qui, par l exemple qu il a mis à disposition sur son site internet, nous a permis de nous initier rapidement au fonctionnement du protocole PS/2.

2 Chapitre 1 Introduction Le projet consiste en la réalisation d un jeu d échecs électronique. L affichage se fait sur une télévision. Le choix des pièces ainsi que leurs déplacements est commandé grâce à une souris. Nous ne développons pas d intelligence artificielle, deux joueurs s échangent la souris tour à tour. Cependant, quelques fonctionnalités intéressantes sont proposées.parmi celles-ci, notons : la vérification systématique des coups joués. Seuls ceux étant en accord avec le règlement du jeu d échecs sont possibles ; la gestion complète des règles. Les coups tels que la promotion, le roque et la prise en passant sont supportés ; l affichage des pièces perdues par chaque clan ; l affichage des déplacements autorisés pour la pièce sélectionnée ; l affichage de l ensemble des déplacements licites que chaque clan peut effectuer ; la détection des échecs, des mats, des pats, ainsi que des parties nulles. Du point de vue technique, nous adoptons deux standards. Le premier pour la communication avec la souris : le protocole PS/2, l autre pour l affichage sur écran de télévision : le signal PAL.

3 Chapitre 2 Historique Notre projet a connu plusieurs phases. S il peut paraître à première vue inutile de se pencher sur l histoire du développement, il en est en réalité tout autrement. En effet, les quelques paragraphes qui suivent expliquent pourquoi le projet a été réalisé tel qu il est. Il est par exemple intéressant de comprendre pourquoi le projet actuel utilise deux PIC 18F2550 et non un seul PIC 16F877 comme prévu initialement. L idée initiale d implémentation se basait sur un seul PIC 16F877. Dans celui-ci, nous souhaitions générer des interruptions sur timer toutes les 64 micro-secondes (à chaque début de ligne du signal PAL). Le code appelé par l interruption aurait généré la partie visible d une ligne du signal PAL ainsi que le top de synchronisation qui la suit. La tâche la moins prioritaire, en dehors des interruptions, aurait répétitivement attendu un mouvement ou un clic de la souris et aurait mis les données à jour. Le développement a commencé avec l élaboration d un algorithme de gestion des règles du jeu. Nous n avons pas recherché l algorithme le plus performant. Il est probable que la littérature regorge d algorithmes plus efficaces que le nôtre. Au lieu de cela, nous avons développé notre propre algorithme, pouvant procurer facilement les informations supplémentaires que l on souhaitait afficher, en mettant l accent sur l optimisation des différentes tâches. L algorithme a été implémenté en langage C. Nous avons fait la tentative de traduire ce code en assembleur PIC avec l utilitaire SDCC 1. Cela a été un échec total. Le code produit était complètement incompréhensible, terriblement long et contenait des messages d erreurs. De plus, SDCC utilise une nouvelle zone de mémoire à chaque fois qu il a besoin de stocker une valeur. Il nous fallait absolument réutiliser ces emplacements, sinon nous n aurions pas eu assez de mémoire de don- 1 http ://sdcc.sourceforge.net/

CHAPITRE 2. HISTORIQUE 4 nées dans le PIC 16F877. Notons qu il est signalé dans la documentation de SDCC que le support des PIC est inachevé. Aucune autre tentative de ce genre n a été faite. Il serait peut-être intéressant de tester d autres traducteurs de C vers assembleur PIC. Il était donc indispensable de réécrire nous-même l algorithme en assembleur. Ceci a été profitable puisque aussi bien la quantité de mémoire utilisée que la taille du code ont diminués significativement. Le langage C a donc été complètement abandonné dans la suite et le développement du code destiné au PIC a été exclusivement réalisé en assembleur. S est alors posée la question de l affichage. A l époque, nous étions persuadés de l impossibilité de générer en live le signal PAL en fonction des données du jeu. Nous nous étions alors orientés vers une solution avec deux mémoires externes. Une ROM contenant les images des pièces ainsi qu une RAM (de type SD pour éviter de devoir rafraîchir nous-même le contenu) connectée en I 2 C. La ROM était destinée à contenir les images des pièces de l échiquier, non compressées, à l instar du format bitmap privé des en-têtes habituels. La RAM, quant à elle, aurait du contenir l image telle quelle aurait du être envoyée à la télévision. Pour éviter que le joueur ne voit les changements se dessiner progressivement, une solution de double buffering avait été envisagée. La RAM contenait deux images, l une d entre elles étant l image en cours de modification et l autre étant l image lue par le PIC lors de la génération du signal PAL. Un bit du PIC aurait servi à indiquer celle en cours de modification. En une instruction, nous pouvions basculer de l une à l autre et ainsi garantir que le joueur n aurait pas vu de changement progressif. L ensemble consistait donc en une carte graphique rudimentaire, permettant même de créer facilement des drag and drop. Bien que cette solution soit parmi les plus élégantes, elle souffrait d un problème de taille. En effet, la lecture de la RAM aurait été lente. Par conséquent, il aurait été impossible d obtenir une image de résolution suffisante à l écran que pour dessiner un échiquier. Nous avons jugé que le seuil minimal de confort se situe aux environs de 8 x 8 pixels par pièce. En -dessous de cette taille, il aurait fallu abandonner la représentation classique des pièces afin de permettre à l utilisateur de les distinguer facilement. Le premier tournant principal qu a connu notre projet date du jour où nous avons pris conscience de notre erreur de jugement concernant l impossibilité de générer en live le signal PAL en fonction des données du jeu. Il en est heureusement tout autrement. Ce dont nous avions besoin, c était d une fonction, pour chaque ligne de chaque pièce, qui manipule direc-

CHAPITRE 2. HISTORIQUE 5 tement la sortie. Nul besoin de lire une image et de la traduire en sortie, nous pouvons générer la sortie directement, puisque nous connaissons à l avance les pieces qui doivent être affichées. Les deux mémoires externes ne sont donc pas nécessaires. Par la même occasion, le problème de la résolution disparaissait. En effet, la partie visible d une ligne de l image dure 52 µsec. Avec une horloge à 20 MHz, cela correspond à 260 cycles d instructions 2, soit 32 cycles par case, ce qui est largement suffisant. Cependant, cette technique rendait impossible l affichage d un curseur, superposé à l image pour la souris, ainsi que les drag and drop des pièces. Ces différentes améliorations graphiques ont été abandonnées dans notre projet, au profit d une méthode de pointage plus rudimentaire. Cependant, deux problèmes subsistaient. Premièrement, nous avions l ambition d afficher plus que l échiquier (les pièces perdues par chaque clan, les déplacements autorisés pour la pièce sélectionnée ainsi que pour chaque clan). Avec ces exigences, la limite de résolution est vite atteinte. Deuxièmement, nous avions calculé une borne sur le temps d exécution d un déplacement. L algorithme implémenté présentait une borne (très pessimiste) d environ 900 000 instructions pour mettre à jour les tableaux indiquant l ensemble des déplacements possibles de chaque clan, sur base desquels sont détectés les échecs, les mats et les pats. Rappelons que ce calcul était destiné à s effectuer dans la tâche de priorité basse, i.e. dans le temps où aucune transition n est nécessaire durant les tops de synchronisation horizontaux et verticaux. Ainsi aurions nous du attendre au pire environ 1.5 seconde 3 lors des déplacements. Cela n est en soi pas une limitation trop gênante, mais il serait néanmoins préférable de la réduire. Avant de continuer la petite histoire de notre projet, une remarque s impose ici. La deuxième limitation tient au fait que l on souhaite afficher un message lors des échecs, des mats et des pats ainsi que les déplacements autorisés pour chaque clan. Seul un tableau de déplacements est utilisé pour déterminer si on est en situation d échec, de mat ou de pat. Si l on ne souhaitait afficher que l un d entre eux, le temps de calcul serait diminué par un facteur 2 lors des mouvements. De plus, si nous n étions pas intéressés par afficher ces tableaux ni les messages, ce temps deviendrait bien plus faible. En effet, déterminer si un déplacement est autorisé ou non revient à déterminer si la destination appartient à l ensemble des déplacements possibles pour la pièce sélectionnée, soit un temps de calcul 32 fois moindre que celui annoncé ci-dessus. Cependant, cela n arrangerait en rien le problème liés à la résolution. Il y a cependant une solutions commune aux 2 Un cycle d instruction correspond à quatre cycles d horloge. 3 Une image complète se compose de 625 lignes durant lesquelles 7.3 µsec sont libres, et elles sont générées au rythme de 25 par seconde.

CHAPITRE 2. HISTORIQUE 6 deux problèmes qui ne nécessite aucun abandon de fonctionnalités. L étude attentive des microcontroleurs proposés par la société microchip 4 a révélé l existence d une autre famille de PICs supportant une fréquence d horloge supérieure. Il s agit de la famille 18F pouvant supporter des fréquences d horloge de 40 MHz et certains mêmes de 48 MHz. L adoption d un tel composant pour notre projet résoudrait les deux problèmes soulevés ci-dessus. Après lecture de quelques datasheets, nous avons finalement opté pour le PIC 18F2550, travaillant à 48 MHz. En effet, un composant à 28 pins nous convenait amplement et les 32 Ko 5 de mémoire de programme de celui-ci nous permettent de stocker les différentes fonctions générant les lignes des différentes pièces, en gardant une marge de sécurité. Hormis la vitesse, ce PIC ne nous apporte rien de plus qu un 16F877. Les fonctionnalités USB2 qu il présente ne nous intéressent pas, et il est possible de les désactiver. La RAM additionelle n est pas utilisée, étant donné que l algorithme du jeu était initialement prévu pour un PIC 16F877 et qu il utilisait moins de la moitié de sa RAM (115 octets). Les instructions supplémentaires se divisent en deux classes. Les instructions faisant partie du jeu étendu ne sont pas utilisées. D ailleurs, il est possible de les désactiver, ce que nous avons fait puisque leur utilisation modifie l adressage de la mémoire. Les autres instructions supplémentaires peuvent toutes se ramener facilement à celles de base, elles ne permettent donc que de petites optimisations locales. Remarquons néanmoins l existence d opérations permettant la multiplication. Nous n utilisons que des multiplications avec des littéraux, qui sont faisable avec des décalages binaires et des additions. Quant aux instructions de lecture et d écriture en mémoire de programme (table reads et table writes), nous ne les utilisons pas. En conclusion, notre projet pourrait être adapté pour fonctionner sur 16F877 au prix d une résolution plus faible et d une attente plus longue lors du mouvement d une pièce. Une phase de traduction du code du jeu pour le rendre compatible avec le nouveau matériel fut nécessaire. Premièrement, remarquons que les PICs de la famille 16F ont une architecture 14 bits alors que ceux de la famille 18F ont une architecture 16 bits. Alors que les mots en mémoire de programme ont une longueur de 14 bits dans les premiers, ils sont de 8 bits dans les seconds. Autrement dit, les instructions sont stockées sur un mot de mémoire de programme dans un PIC 16F alors qu elles sont stockées sur deux ou quatre mots dans les PICs 18F. Ils nous fallait donc obligatoirement réécrire les parties de code comprenant des sauts calculés. De plus, certaines opéra- 4 www.microchip.com 5 Les pics de la famille 18F ont des instructions stockées sur 2 ou 4 octets. 32 Ko correspondent donc à une capacité de 16384 instructions.

CHAPITRE 2. HISTORIQUE 7 tions des PICs 16F n existent plus dans les PICs 18F. Il s agit par exemple de l instruction CLRW dans l équivalant PIC 18F est CLRF WREG (le registre de travail est maintenant accessible en tant qu un registre ordinaire). Les derniers changements à effectuer ont pour but de tirer parti des instructions supplémentaires offertes afin d optimiser localement le code lorsque cela est possible. La difficulté suivante à laquelle nous avons du faire face fut l impossibilité de fixer le moment auquel la souris envoie les données. Il est possible de fixer le nombre de paquets transmis par seconde grâce à une valeur envoyée à la souris lors de son initialisation, mais il n est pas possible de fixer le moment auquel un bit va être transmis. Interroger soi-même la souris n était pas non plus faisable vu le temps dont nous disposions entre deux tops de synchronisation consécutifs. Sans rentrer dès à présent dans les détails, disons juste que le problème est qu il aurait fallu écouter ce qui passe sur la ligne CLK de la souris. Lors des transitions, nous savons qu une valeur doit être lue immédiatement sur la ligne DATA. Nous ne pouvions pas nous permettre d avoir des interruptions sur les transitions d une pin, celles-ci ne pouvant pas temporellement se combiner à celles indiquant le début des lignes de l image à générer. La solution trouvée à l époque consistait en la création d une sorte de buffer de taille suffisante à l extérieur du PIC. Le choix d un registre à décalage s impose par la nature même de la tâche. Sans rentrer dans les détails, disons juste que la ligne CLK de la souris aurait servi de clock au registre et que la ligne data aurait servi d entrée de données. Deux autres lignes du même type seraient venues du PIC, permettant de réinitialiser son contenu. La taille du registre aurait été choisie d une unité de plus que le nombre de bit à recevoir durant un paquet (34 bits), et une initialisation intelligente (33 bits à zéro et 1 bit à 1) aurait permis au PIC de déterminer lorsque le registre était rempli. Le temps nécessaire à sa ré-initialisation et à la récupération des valeurs était assez faible que pour permettre leur exécution durant une ligne noire de l image. Nous étions également assurés de ne pas écraser de paquets dans le registre à décalage, en choisissant un taux faible de paquets par seconde. Malheureusement, le composant choisit (HEF4557B notament commercialisé par Phillips) n était pas disponible dans le commerce à prix raisonnable. Sous les conseils de Monsieur BOIGELOT, nous avons opté pour l utilisation d un deuxième PIC. Ceci nous ouvrait de nouvelles perspectives. Nous nous sommes donc posés deux questions : 1. Pourquoi ne pas transférer la gestion de la souris entièrement à ce microcontroleur supplémentaire?

CHAPITRE 2. HISTORIQUE 8 2. Pourquoi ne pas transférer la gestion des règles du jeu à ce microcontroleur supplémentaire? Il s agit là certainement d un choix. Nous avons répondu à ces deux questions par l affirmative. Cela permet d avoir une gestion meilleure de la souris, notament la gestion des erreurs qui n était pas possible dans le premier PIC étant donné le temps nécessaire au renvoi des données d initialisation. En ce qui concerne le jeu, ce transfert était aussi relativement naturel. En effet, il permet d avoir une réactivité importante, sans pour autant devoir limiter nos souhaits 6. Dans un projet commercial, nous aurions opté pour un PIC de faible coût. Cependant, nous avons opté pour utiliser un deuxième PIC 18F2550. Ceci principalement pour trois raisons : 1. Le code des règles du jeu d échecs avait été réécrit en vue d être compatible avec ce modèle de PIC et de tirer parti des instructions des PICs de la famille 18F. 2. Nous avions un PIC de ce modèle à notre disposition (un PIC supplémentaire avait été commandé par sécurité) 3. Nous préférions nous focaliser sur l étude d un modèle plutôt que de deux. En effet, une compréhension fine des PICs de cette famille est nécessaire avant toute utilisation. Il est par exemple important de bien maîtriser les bits de configuration. Cependant, ces deux transitions nous obligent à faire communiquer deux PICs. Il nous fallait donc imaginer un protocole de communication adapté à nos besoins, ce que nous avons fait. En conclusion, notre projet consiste donc actuellement en la réalisation d un jeu d échecs en logique programmable avec deux PICs 18F2550. Le premier se chargeant de la gestion de la souris, de la mémorisation de l état du jeu, de la vérification des règles ainsi que de l envoi des données au deuxième. Celui-ci se charge, quant à lui, de la réception des données et de la génération en live du signal PAL en fonction des données reçues. 6 L exécution des 900 000 instructions que prend au maximum le calcul des nouvelles données lors d un déplacement de pièce se fait avec un PIC à 48 MHz en 75 msec, ce qui est nettement inférieur à ce dont l utilisateur peut se rendre compte. Ce temps est à comparer avec les 1.5 secondes qui étaient nécessaires si ce traitement était effectué par bribes sur le PIC gérant l affichage.

9 Chapitre 3 La souris 4 6 2 1 5 3 Légende: 1. Data 2. Not Implemented 3. Ground 4. Vcc (+5V) 5. 4Clock 6. Not Implemented FIG. 3.1 Schéma d un port PS/2 3.1 L interface électrique L alimentation électrique se fait par Vcc/Ground 1. Le périphérique ne doit pas consommer plus de 275 ma et on doit veiller aux surtensions transitoires. De telles surtensions peuvent être provoquées "en branchant à chaud" le périphérique. Les données et l horloge sont lues sur les broches DINPS2 et CINPS2 du microcontroleur, respectivement. Les deux lignes sont normalement maintenues à +5V, mais peuvent êtres mises à la masse en appliquant "1" sur les broches COUTPS2 et DOUTPS2. En conséquence, lorsque l on envoie des données à la souris, DINPS2 = DOUTPS2 et CINPS2 = COUTPS2. Les lignes de donnée et d horloge sont naturellement tirées à 5V par des résistances tire-haut (10k). Deux transistors commandés en courant (BJT) 1 V cc doit être compris entre 4.5 et 5.5 V.

CHAPITRE 3. LA SOURIS 10 CINPS2 Clock COUTPS2 5V DOUTPS2 DINPS2 Data FIG. 3.2 Schéma électrique de la souris permettent de tirer les lignes à zéro volt. Pour ce faire, l émetteur est mis à la masse et leur collecteur est connecté à la ligne. La base est à 0.7 Volt, et son raccord au PIC via une résistance suffisamment élevée (6.5k) garantit un courant le commandant. 3.2 Le protocole PS/2 3.2.1 Généralités Le protocole PS/2 est un protocole série synchrone bidirectionnel. Par défaut, le bus de communication est vide et les lignes Data et Clock sont à l état haut. C est le seul état où le périphérique connecté peut transmettre des données. Le microprocesseur à le contôle du bus et peut empêcher ou interrompre la communication à tout moment en mettant la ligne Clock basse. Le périphérique est responsable de générer le signal d horloge. Si le microprocesseur veut envoyer des données, il doit d abord empêcher la communication en mettant la ligne Clock à l état bas pendant un certain temps puis mettre la ligne Data basse avant de relacher la ligne Clock. Cette opération initialise le bus pour l envoi et demande au composant de commencer à générer le signal d horloge. En résumé, le bus peut se trouver dans trois états de communication : Data = 1, Clock = 1 : État vide (par défaut) Data = 1, Clock = 0 : État inhibé

CHAPITRE 3. LA SOURIS 11 Data = 0, Clock = 1 : État d envoi Les données sont transmises octet par octet sous forme de trames de 11 ou 12 bits se composant exactement : D un bit de début toujours à 0 ; des 8 bits de données en commançant par le bit de poids faible ; d un bit de parité impaire ; et enfin, d un bit d arrêt toujours à 1. Un douzième bit d acquittement est envoyé par le périphérique au microprocesseur lors d un envoi pour signaler la bonne réception de la trame. Le bit de parité se calcule sur les 8 bits de données et est utilisé pour la détection d erreur. Il doit être mis à 1 s il y a un nombre pair de 1 dans les bits de données et à 0 s il y a un nombre impair de 1 dans les bits de données. Si ce bit est incorrect, le périphérique doit considérer la commande comme invalide. Les données envoyées depuis le périphérique vers le microprocesseur sont lues sur le flanc descendant du signal d horloge. Les données envoyées depuis le microprocesseur vers le périphérique sont lues sur le flanc montant du signal d horloge. La fréquence de ce signal - généré par le périphérique - se situe entre 10 et 16.7 khz. Cela implique un signal d horloge haut pendant 30 à 50 µs. 3.2.2 Communication périphérique microprocesseur Lorsque le périphérique veut envoyer des données, il doit d abord s assurer que la ligne Clock n est pas inhibée. Si elle l est, le microprocesseur inhibe la communication et le périphérique doit bufferiser les données à envoyer jusqu à ce que le microprocesseur libère l horloge. La ligne Clock doit rester haute pendant au moins 50 µs avant que le périphérique puisse commencer à transmettre les données. Comme expliqué dans la section 3.2.1, le périphérique envoie un octet de données dans une trame de 11 bits. Il écrit un bit sur la ligne Data lorsque le signal d horloge est haut. Ce même bit est lu par le microprocesseur lorsque le signal d horloge est bas. La ligne de données change donc d état lorsque l horloge est haute et est valide lorsque l horloge est basse. Le schéma suivant illustre cela : Le microprocesseur peut inhiber la communication à tout moment en mettant la ligne Clock basse pendant au moins 100 µs. Si la communication est inhibée avant le onzième coup d horloge, le périphérique doit inter-

CHAPITRE 3. LA SOURIS 12 Clock Data START DATA0 DATA1 DATA2 DATA3 DATA4 DATA5 DATA6 DATA7 PARITY STOP FIG. 3.3 Schéma d une trame de réception rompre la transmission en cours et se préparer à retransmettre le message. Un message peut être l identifiant du périphérique, un packet de mouvement, etc... Si le message se compose de plusieurs octets, le composant retransmettra tous les octets et pas uniquement celui qui était en cours de transmission. 3.2.3 Communication microprocesseur périphérique Le périphérique PS/2 génére toujours le signal d horloge. Si le microprocesseur veut envoyer, des données, il doit d abord mettre les lignes Clock et Data dans l état d envoi. Plus précisément : Empêcher la communication en forçant le signal d horloge bas pendant au minimum 100 µs, mettre le bus en état d envoi en mettant la ligne Data basse et enfin, relacher le ligne Clock. Le périphérique vérifie l état du bus à un interval n excédant pas 10 ms. Lorsqu il détecte un état d envoi, il commence à générer le signal d horloge. Le microprocesseur change alors l état de la ligne Data quand la ligne Clock est basse ; la donnée est lue par le périphérique quand la ligne Clock est haute. C est l opposé de de ce qui se produit dans une communication du périphérique vers le microprocesseur. Après réception du bit d arrêt, le périphérique enverra le bit d acquittement en mettant la ligne de données basse et en générant une dernière impulsion d horloge. Si le microprocesseur n envoie pas ce bit,le périphérique continuera de générer le signal d horloge jusqu à ce que la ligne Data soit relachée. Le message sera alors considéré comme erroné.

CHAPITRE 3. LA SOURIS 13 La figure 3.4 montre quels signaux sont générés par le microprocesseur et quels signaux sont générés par le périphérique. Clock Data START DATA0 DATA1 DATA2 DATA3 DATA4 DATA5 DATA6 DATA7 PARITY STOP (a) Microprocesseur Clock Data ACK (b) Périphérique FIG. 3.4 Schéma d une trame d envoi Il y a deux quantités temporelles que le microprocesseur doit vérifier : 1. Le temps que prend le périphérique pour commencer à générer le signal d horloge après que le microprocesseur ait mit la ligne Clock basse, qui ne doit pas dépasser 15 ms. 2. Le temps que prend l envoi du bit de début, de l octet et du bit de fin, qui ne doit pas dépasser 15 ms. 3. Si la commande envoyée requiert une réponse, celle-ci doit être envoyée au maximum 20 ms après que le microprocesseur ait relaché la ligne d horloge. Si une de ces trois limites est atteinte, le microprocesseur doit considérer l envoi comme erroné. 3.3 Le protcole souris Le protocole souris PS/2 se base sur le protocole PS/2 pour communiquer avec la souris. Il définit l ensemble des commandes comprises par la souris et le format des réponses à ces commandes. Chaque commande et chaque réponse se compose d un ou plusieurs octets. La souris supporte plusieurs modes de fonctionnement.

CHAPITRE 3. LA SOURIS 14 3.3.1 Mode Reset La souris entre en mode Reset à la mise sous tension ou après avoir reçu la commande Reset (0xFF). Elle initialise ensuite sa configuration à : Taux de raffraichissement : 100 échantillons/sec Résolution : 4 unités/mm Mise à l échelle : 1 :1 Report de mouvements : désactivé Si aucune erreur ne survient durant cette opération d initialisation (appelée BAT 2 ), la souris renvoie le code 0xAA (BAT success). Sinon, elle renvoie le code 0xFC (BAT error). Elle envoie ensuite un code 0x00, permettant de la différencier d un autre type de périphérique (comme par exemple un clavier). 3.3.2 Mode Stream Dans ce mode, la souris envoie un message de mouvement lorsqu elle détecte un clic ou un mouvement de souris. C est le mode de fonctionnement par défaut. Nous ne l utiliserons cependant pas, au profit du mode Remote. La fréquence d échantillonnage est configurable à l aide de la commande Set Sample Rate (0xF3), et peut prendre les valeurs 10, 20, 40, 60, 80, 100 et 200 échantillons/sec. 3.3.3 Mode Remote C est le mode que nous utilisons par défaut. Dans ce mode, la souris est toujours mise à jour à la fréquence d échantillonnage. Cependant, les informations de mouvement ne sont envoyées au microprocesseur que lorsqu il en fait explicitement la demande à l aide de la commande Read Data (0xEB). 3.4 Structure de la communication Initialement, la commande Reset est envoyée à la souris. Le code d initialisation peut ainsi être utilisé pour tenter de récupérer une erreur de communication. Durant cette phase, le code 0xFF (Reset) est envoyé par le microprocesseur. La souris doit renvoyer en réponse un code 0xFA (Acknowledge), suivit de 0xAA (BAT success) et de 0x00 (Mouse Id). Si la réponse de la souris est correcte, la phase d initialisation peut réellement commencer. C est à cette étape que sont envoyées les commandes de taux d échantillonnage (0xF3), de résolution (0xE8), etc... (bien que ces 2 BAT : Basic Assurance Test

[OK] CHAPITRE 3. LA SOURIS 15 [ERROR] [OK] Initialiser la souris [ERROR] Erreur générale Redemander le paquet de mouvmement [ERROR] Demander paquet de mouvement [OK] Appeler le jeu FIG. 3.5 Schéma d activité de la souris commandes peuvent être envoyées n importe quand). Si l initialisation réussi, la souris est mise en "Remote Mode". Si elle échoue, une erreur générale est émise et la LED d erreur clignote en boucle avec une période de 2 secondes. Une fois en "Remote mode", la commande 0xEB (Read Data) est envoyée. La souris doit répondre par 0xFA (Acknowledge), suivit de 3 octets de mouvement. Si une erreur survient, la commande Resend est envoyée à la souris pour redemander la réponse. Si celle-ci est à nouveau erronée, la commande Reset est envoyée pour tenter une dernière fois de récupérer la souris.

16 Chapitre 4 Le signal vidéo 4.1 Description générale Une séquence vidéo est une suite d images diffusées à une cadence de 25 images par seconde. Pour économiser la bande passante tout en évitant un phénomène de scintillement, chaque image est divisée en deux trames entrelacées : une trame pour les lignes paires, l autre pour les lignes impaires. La fréquence d affichage des trames est donc de 50 Hz. Chaque trame se compose de 312.5 lignes, soit 625 lignes par image. Ces lignes sont générées de gauche à droite et de haut en bas, en commençant par les lignes impaires. FIG. 4.1 Balayage de l image L impression d une image sur l écran est réalisée grâce au tube cathodique, dans lequel un faisceau d électrons est envoyé par un canon. Ce fais-

CHAPITRE 4. LE SIGNAL VIDÉO 17 ceau, commandé en intensité par le signal vidéo, vient frapper les luminophores qui composent l écran. Des tops de synchronisation, contenus dans le signal vidéo, indiquent la fin d une ligne ou d une trame, ce qui autorise le retour du faisceau. Chaque ligne possède une durée de 64 µs. Cette durée comprend la partie de synchronisation de ligne (12 µs), ainsi que la partie réellement affichée sur l écran (52 µs). Parmi les 312.5 lignes d une trame, 25 lignes ne sont pas affichées. Ces lignes non visibles sont réservées pour la synchronisation des trames, ainsi que pour d autres signaux d information, tels que le télétexte. Signalons encore que, pour une trame paire, seule la deuxième moitié de la première ligne visible est affichée, tandis que pour une trame impaire, c est la première moitié de la dernière ligne visible qui est affichée, comme indiqué à la figure 4.1. Le signal vidéo noir et blanc est en fait un signal électrique dont la tension varie entre 0 V et 1 V, le niveau nul correspond à celui des tops de synchronisation, le niveau infra-noir est à 0.3 V, celui du blanc à un 1 V, et les niveaux de gris se situent entre les deux, comme détaillé sur la figure 4.2. Le signal électrique est transmis sur une ligne vidéo composite d impédance d entrée égale à 75 Ω. FIG. 4.2 Signal vidéo PAL monochrome 4.2 Synchronisation horizontale La figure 4.3 décrit le détail du top de synchronisation horizontale. On a d abord un palier avant d une durée de 1.5±0.2 µs au niveau du noir, suivi d une impulsion au niveau de synchro de 4, 7 ± 0, 2 µs et, pour terminer,

CHAPITRE 4. LE SIGNAL VIDÉO 18 un palier arrière de 5, 8 ± 0, 4 µs. La durée totale de la synchronisation est donc de 12 µs. FIG. 4.3 Top de synchronisation horizontale 4.3 Synchronisation verticale La figure 4.4 décrit le détail des deux tops de synchronisation verticale, un top par trame. Ils sont tous les deux d une durée totale de 25 lignes, soit 1,6ms. Le top qui suit la trame impaire commence et termine au milieu d une ligne, celui qui suit la trame paire commence et termine en début de ligne. Les deux tops de synchronisation sont composés de quatre parties : 5 impulsions de pré-égalisation sur 2.5 lignes 5 impulsions larges sur 2.5 lignes 5 impulsions de post-égalisation sur 2.5 lignes 17.5 lignes noires pour le retour du spot. On notera que la durée des tops d égalisation est de 2.35 ± 0.1 µs alors que celle des impulsions larges est de 4.7 ± 0.1 µs.

CHAPITRE 4. LE SIGNAL VIDÉO 19 (a) Trame 1 (b) Trame 2 FIG. 4.4 Tops de synchronisation verticale 4.4 Implémentation du circuit vidéo Le PIC génère le signal vidéo via les pins RA0 (b 0 ), RA1 (b 1 ), RA2 (b 1 ), RA3 (top). Les trois premières codent 8 niveaux de gris, du noir au blanc, et la dernière est destinée au niveau de synchronisation. Les différentes combinaisons sont présentées à la figure 4.5. Télévision 3000 1500 b0 b1 Signal PAL 750 b2 75 1000 top FIG. 4.5 Circuit vidéo Le montage choisi pour faire la conversion numérique/analogique est un montage de résistances en étoile. Remarquons qu une de ces résistances correspond à l impédance d entrée de la télévision (75 ohms). Le noeud central a un potentiel V qui doit pouvoir varier entre 0 et 1 volt, suivant nos besoins, pour générer les différents niveaux de gris et les tops de syn-

CHAPITRE 4. LE SIGNAL VIDÉO 20 chronisation. La détermination des valeurs des résistances du montage s appuie sur les considérations suivantes : Souhaitant les différents niveaux de gris régulièrement espacés en tension, il faut que le poids associé à la sortie b 2 soit double de celui associé à b 1, et lui-même double de celui associé à b 0 (donc des valeurs de résistances doubles les unes des autres). Les valeurs des résistances sont définies à un facteur près. Cependant, il est souhaitable de limiter la puissance dissipée par le circuit. L introductuction d une résistance supplémentaire tirant à la masse n est donc pas souhaitable, puisqu elle augmenterait le courant débité par le PIC. On choisit donc le facteur de tel sorte que la résistance tirant le noeud V à la masse soit de 75 ohms. La dernière chose à imposer est une valeur de 1 Volt pour le blanc, i.e. pour toutes les sorties du PIC à 5 volts. Imposer une valeur de 0 V pour le niveau des tops de synchronisation est inutile puisque mettre toutes les sorties du PIC à 0 V tire le noeud au bon niveau. Nous obtenons les valeurs de résistances suivantes : 3000, 1500, 750 et 1000 Ohm. V = b 0 3000 + b 1 1500 + b 2 750 + top 1000 + 0 75 1 3000 + 1 1500 + 1 750 + 1 1000 + 1 75 b 0 b 1 b 2 top V signification 0 0 0 0 0.0 volt top 0 0 0 1 0.3 volt 1 0 0 1 0.4 volt 0 1 0 1 0.5 volt 1 1 0 1 0.6 volt 0 0 1 1 0.7 volt 1 0 1 1 0.8 volt 0 1 1 1 0.9 volt 1 1 1 1 1.0 volt La mise à 0 V d une pin de sortie place la résistance de la ligne qui lui est associée en parallèle avec l impédance d entrée de la télévision. Les résistances des lignes correspondantes aux pins à 1V se mettent en parallèle entre elles. On obtient donc deux groupes de résistances en série. La valeur de la tension à l entrée de la télévision se calcule aisément par division potentiométrique.

CHAPITRE 4. LE SIGNAL VIDÉO 21

22 Chapitre 5 L interface graphique L interface graphique a une résolution de 624 256. En effet, nous arrivons a générer une transition de niveau de gris par cycle d instruction et la durée de la partie visible d une ligne est de 52 µsec, soit 624 cycles avec une fréquence d horloge de 48MHz. Verticalement, nous centrons une région réellement utilisée de 512 lignes, avec les trames paires et impaires identiques, ce qui équivaut à 256 lignes réellement différentes. Notons qu une image de télévision a une résolution de 720 576. Deux bandes noires sont ajoutées en haut et en bas de l image, et horizontalement, l image est dilatée de 15 %. Sans rentrer dans les détails, trois points méritent l attention concernant cette interface. Premièrement, nous souhaitons avoir l échiquier le plus étroit pos-

CHAPITRE 5. L INTERFACE GRAPHIQUE 23 sible, pour des raisons esthétiques et pour laisser la place latérale destinée à afficher les pièces perdues par les deux clans. Nous ne pouvons donc pas calculer les adresses auxquelles sauter pour afficher les pièces ainsi que les couleurs dans lesquelles les pièces doivent s afficher lors des transitions de case. Nous précalculons donc,en dehors de l échiquier,un tableau contenant les adresses des sauts ainsi que les couleurs dans lesquelles nous souhaitons afficher les pièces pour les huit cases de la ligne suivante de l échiquier. Deuxièmement, nous ne souhaitions pas écrire nous-mêmes les fonctions affichant les différentes lignes des pièces et des messages possibles, cela aurait été fastidieux et sujet à de nombreuses erreurs. Au lieu de cela, nous avons écrit un compilateur en Java. Prenant une image jpeg contenant les différentes pièces en entrée, celui-ci nous fournit automatiquement le code source assembleur PIC souhaité. Ceci nous garantit une résistance face aux erreurs de comptage d instructions ainsi qu une facilité de création et de modification des icônes et des messages. Pour finir, notons que l affichage étant légèrement étiré latéralement (15 %), la souris ne serait pas agréable à utiliser sans correction. En effet, le curseur se déplacerait plus vite horizontalement que verticalement. C est pourquoi une correction est appliquée sur la coordonnée x avant affichage.

24 Chapitre 6 La gestion du jeu La gestion du jeu consiste, comme nous l avons déjà souligné, en trois responsabilités. Pour commencer, elle se doit de calculer et mémoriser les informations pouvant être affichées à l utilisateur. Puis, elle doit assurer qu aucun mouvement illicite n est commis par l utilisateur. Enfin, elle doit détecter automatiquement les situations spéciales telles que les situations d échec, de pat, de mat ou de parties nulles. Pour ce faire, un algorithme a été mis au point. Ces quelques lignes le décrivent de manière superficielle afin de n en retenir que l essentiel. On peut se demander comment faire pour détecter une situation d échec et mat. La piste qui nous vient en premier à l esprit s inspire directement de la définition qui en est donnée dans le règlement : on est en échec et mat si et seulement si le roi, ne pouvant pas bouger, est menacé par une pièce adverse, et que l on ne peut ni supprimer cette pièce, ni faire interposition. Il est bien évidemment possible d implémenter cette règle, mais cela pose certaines difficultés. Plusieurs pièces adverses peuvent attaquer le roi simultanément. 1. Heureusement, nous pouvons borner le nombre de ces pièces à deux. Cela n est pas sans poser certains problèmes. En effet, cette façon de procéder oblige à pouvoir détecter toutes les pièces pouvant se rendre sur une case donnée, à la fois pour déterminer quelles pièces menacent le roi, et quelles pièces peuvent faire interposition. Il est néanmoins tout à fait possible d implémenter cet algorithme, mais nous avons choisis une autre voie. La solution adoptée consiste en l implémentation d une fonction marquant les différentes destinations auxquelles peuvent se rendre une pièce donnée sans mettre le roi de son clan en échec. Déterminer si le roi est mis en échec se fait en recherchant une pièce qui le menace, la recherche s ar- 1 Le lecteur qui n en est pas convaincu placera sur l échiquier un roi blanc en c3, une tour noire en e5 et un fou noir en f6, puis effectuera le mouvement e5 c5.

CHAPITRE 6. LA GESTION DU JEU 25 rêtant dès qu on en trouve une. Ayant cette fonction, il est alors aisé de déterminer l ensemble 2 des cases atteignables par un clan sans mettre son roi en échec. Ces deux ensembles nous apprennent beaucoup de choses : 1. Si l un d entre eux est vide et que l autre contient la position du roi adverse, alors celui-ci est mat. 2. Si l un d entre eux s avère être vide sans que l autre ne contienne la position du roi adverse, on peut en conclure une situation de pat. 3. Si l un d entre eux contient la position du roi adverse, et que l autre n est pas vide, alors il y a échec. Les situations de parties nulles sont déterminées facilement, par une traduction quasiment littérale des règles : la partie est nulle si on est dans une situation de roi contre roi, de roi contre roi avec un fou ou un cavalier, ou de roi avec fou contre roi avec fou, les deux fous étant sur des cases de la même couleur. Un simple parcours de l échiquier permet de vérifier ces conditions. De façon remarquable, cette implémentation permet la détermination presque gratuite de l état du jeu sur base des informations affichées. En effet, les deux ensembles mentionnés ci-dessus correspondent immédiatement aux deux minis échiquiers affichés pour montrer aux joueurs l ensemble de leurs déplacements possibles. Venons-en à un petit survol de quelques optimisations fondamentales qui ont été implémentées : 1. La fonction évoquée ci-dessus, marquant les différentes destinations auxquelles peuvent se rendre une pièce donnée sans mettre le roi de son clan en échec, est scindée en deux. La première détermine l ensemble des positions auxquelles peut se rendre une pièce donnée, peu importe que ce mouvement mette le roi en échec ou non, et, pour chacune d entre elles, appelle la seconde. Celle-ci ne marque la destination que si elle n est pas déjà marquée, et si le roi n est pas mis en échec. Il n est donc plus nécessaire d exécuter le code déterminant si le roi est en échec à chaque fois. 2. Le code qui détermine si le roi est en échec se base sur une autre fonction, utile dans le cas des roques, qui détermine si une case est menacée par une pièce d un clan donné. Cette fonction peut avoir des per- 2 Cet ensemble est représenté facilement par huit octets dont chaque bit correspond à une case de l échiquier. La valeur d un bit indique si cette case est accessible.

CHAPITRE 6. LA GESTION DU JEU 26 formances significativement améliorées dans certains cas. Sans rentrer dans les détails, disons juste que si le roi n était pas précédemment en échec, il n y a nul besoin de regarder si les pions, rois, et cavaliers adverses le menacent après un mouvement d une autre pièce. En effet, on ne saurait pas découvrir le roi vis-à-vis des pions, rois, et cavaliers adverses puisqu aucune pièce ne peut être interposée entre ceux-ci et le roi (et donc retirée). Cette fonction va donc prendre un argument booléen supplémentaire fast permettant d écourter son exécution. D autres optimisations ayant un impact beaucoup plus faible ont été effectuées : Le problème essentiel de la prise en passant consiste à déterminer si un pion a avancé de deux cases au coup précédent. Pour ce faire, nous avons introduit un nouveau type de pièce, dont le glyphe associé est identique à celui des pions, qui représente un pion ayant avancé de deux cases au coup précédent. Nous avons donc un total de 15 types de pièces différentes 3, qui se codent donc sur quatre bits. Bien souvent, dans le code, on se demande si une pièce donnée est une tour ou une dame, un fou ou une dame. Le code binaire associé à chaque type de pièce est choisi de manière intelligente pour que ces opérations soient effectuées le plus rapidement possible. Ayant souvent besoin de connaître la position des rois, celles-ci sont mémorisées. On évite ainsi de devoir parcourir à nouveau souvent l échiquier. Du point de vue pratique, on souhaite avoir les coordonnées des cases auxquelles peut se rendre un roi ou un cavalier. Nous avons des tableaux qui donnent les distances horizontales et verticales des déplacements. Ces vecteurs de déplacement ne sont pas stockés dans un ordre quelconque. On les classe dans un ordre tel que si l application du ième vecteur de déplacement pour les rois conduit à une case en dehors de l échiquier, alors l application du ième vecteur de déplacement pour les cavaliers conduira lui aussi à une case en dehors de l échiquier. Cela permet quelques optimisations lors de la vérification de la mise en échec éventuelle du roi. Pour finir, remarquons que le nombre d arguments des différentes fonctions a été significativement augmenté depuis le premier code source écrit en C. Ceci afin d éviter les calculs multiples des mêmes 3 Hormis les six types de pièces blanches et les six types de pièces noires classiques, nous rajoutons donc deux types pour les pions blancs et noirs ayant avancé de deux cases au coup précédent. On doit aussi ajouter une occupation différente des cases de l échiquier : l absence de pièce. On a donc bien un total de 15 types.

CHAPITRE 6. LA GESTION DU JEU 27 données dans les différentes fonctions. Du point de vue de la mémoire, il nous fallait obligatoirement 4 utiliser une technique de variable locale. Autrement dit, à chaque variable du programme ne correspond pas un emplacement mémoire. Lorsque nous sommes assurés que deux fonctions ne seront jamais activées simultanément, les variables peuvent être à des emplacements mémoire identiques. C est ce que nous avons fait. Terminons cette succincte présentation du jeu par l étude des performances de l algorithme mis en place. Nous avions compté le nombre de cycles d instruction que prend au maximum l exécution de chaque fonction, dans la version écrite en assembleur pour PIC 16F877. Tous les temps calculés sont des bornes au pire des cas. Les deux optimisations fondamentales soulevées ci-dessus ne peuvent donc malheureusement pas être prises en compte. Le code le plus long donnant les destinations possibles est relatif aux dames. Prenant en compte qu au début du jeu, deux dames sont présentes et que seize pions peuvent être promus en dames, on obtient un maximum de dix-huit dames présentes simultanément sur le plateau de jeu 5. Considérant toutes ces contraintes, nous arrivons à un temps le plus défavorable de l ordre de 900 000 instructions. Cette borne est bien évidemment très défavorable, et ne sera sans doute jamais atteinte. Rien que l application des deux optimisations fondamentales font gagner énormément. Bref, il est difficile de donner une fourchette réaliste du temps d exécution. Nous savons juste qu il sera nettement plus faible que la borne de 900 000 cycles. Cependant, les 75 msec nécessaires à un PIC cadencé à 48 MHz pour les exécuter est suffisamment faible pour ne pas perturber la gestion de la souris et pour ne pas être remarqué par l utilisateur. Aucune autre méthode de calcul tel que l analyse amortie n est indispensable. 4 L obligation date du temps où l on espérait encore faire tenir le projet dans un PIC 16F877. Maintenant, nous avons nettement plus de mémoire. Cependant, d une part, on souhaite éviter autant que possible les changements de banques, et d autre part on souhaite également garder une implémentation qui puisse être adaptée à un PIC moins onéreux sans grands changements. 5 Il semble impossible que les seize pions puissent être tous promus. Il est donc très pessimiste de dire que dix-huit dames peuvent se trouver simultanément sur l échiquier. Nous n avons malheureusement pas été capables de déterminer avec certitude une borne plus faible.

28 Chapitre 7 Conclusion Nous nous sommes lancés dans un projet ambitieux. Lors du choix de celui-ci, nous n avions aucune idée des difficultés auxquelles nous avons du faire face. Certes, notre inconscience nous à conduit à choisir un travail de taille inattendue, mais probablement un des plus intéressants et passionnants de notre cursus. Il nous a permis de découvrir le monde de la logique programmable, l assembleur PIC, le fonctionnement d un signal vidéo et du protocole PS2. De plus, nous avons découvert de nouvelles techniques de programmation et nous avons eu l occasion d améliorer notre pratique de la conception de circuits. A l heure actuelle, nous sommes pleinement satisfaits du résultat obtenu.

29 Chapitre 8 Le circuit

CHAPITRE 8. LE CIRCUIT 30

31 Bibliographie [1] The PS/2 Mouse/Keyboard Protocol. Adam Chapweske, Septembre 2003. [2] The PS/2 Mouse Interface. Adam Chapweske, Janvier 2003. [3] PIC - PS/2 mouse interfacing and communication. Fabrizio Iacopetti, Août 2003. [4] The F.I.D.E. Laws of Chess. Multiple, Juillet 2003. [5] Les Règles des Échecs. Multiple, Janvier 1997. [6] La télévsion couleurs,fonctionnement et dépannage. Dunod, 1991.