[WIP] Décorticage manettes HKT 7300 / HKT7500 / HKT 7700 DreamCast

[gc339]

Bonsoir.

Afin de pouvoir étudier le protocole d'échange entre la puce Maple bus et la DC, je viens d'acquérir ce petit analyseur logique à 4 canaux.

http://www.ikalogic.com/scanalogic2/

Il est alimenté par l'USB du PC. La fréquence d'échantillonage peut être choisie entre 125 kHz et 20 Mhz. Sa capacité d'acquisition est de 256k bits par canal. Le logiciel PC et ses évolutions/corrections sont téléchargeables en libre service sur le site ikalogic.com Son prix de 59 euros est imbattable en regard de ses performances.

Je n'ai pas pu résister à le tester immédiatement sur un clone de manette DC.

Le circuit en mini-wrapping à pour but de décoder les différentes séquences (Start, Stop ...) qui encadrent toutes les trames échangées entre la manette et la DC.

Les informations échangées entre la manette et la DC, le sont sous forme de trames quelque soit la direction de l'échange :

• La séquence de Start correspond à 4 impulsions d'horloge sur SDCKB (broche 5, fil blanc) pendant que SDCKA (broche 1, fil rouge) est maintenu à zéro.
• La séquence de Stop correspond à 2 impulsions d'horloge sur SDCKA pendant que SDCKB est maintenu à zéro.
• Les bits des données utiles ainsi que ceux du checksum sont retransmis alternativement sur chacun des fils et rythmés par le front descendant sur le fil antagoniste.

Un échange de trames entre la DC et la manette, on distingue très bien les séquences de start et de stop de chaque trame.

• Celle de gauche correspond à une requête de la DC.
• Celle de droite est la réponse de la manette à cette requête

Le même échange, mais dilaté à partir de l'impulsion issue du circuit de décodage en mini-wrapping.

• L'impulsion sur la trace bleue (canal 1) correspond au signal de synchronisation issu du circuit en mini-wrapping.
• La trace jaune (canal 2) correspond au signal SDCKA.
• La trace rouge (canal 3) correspond au signal SDCKB.

Bon, ben c'est déjà pas mal pour un galop d'essai, il faut maintenant que j'approfondisse le fonctionnement de cet analyseur avant de poursuivre plus en avant.

[Eko]

Rhooooo, j'adore ça meuha  
le mot décorticage "en mode expert" est bien choisi  

[maldoror68]

 
une aspirine! vite !  

[f4brice]

Joli travail !  
Ca me rappelle quand j'investiguais le codage infra-rouge du module de réglage des chassis VNS2000 (lien).

[gc339]

Bonsoir.

J'ai eu bon nez d'acquérir ce petit bijou de chez IKALOGIC : http://www.ikalogic.com/scanalogic2/

Il est en constante évolution logicielle et maintenant il intègre le décodage du Maple Bus en plus des protocoles standards comme l'USB ou I2C.
Voici ce que l'on peut lire sur le portail du site dans la rubrique "Technical specifications" du SCANALOGIC 2 :

Effectivement, après une mise à jour logicielle (à chaque démarrage, le logiciel SCANALOGIC 2 va vérifier si une nouvelle mise à jour est disponible), un nouvel onglet "Maple bus" apparait dans l'onglet "Decoding" de la fenêtre de gauche :

A vrai dire je ne suis pas étranger à cette nouvelle fonctionnalité.
Ayant contacté IKALOGIC pour un problème bénin de débordement de la fenêtre SCANALOGIC sur mon deuxième écran, Ibrahim Kamal, le concepteur de cet analyseur, m'a proposé d'y inclure le décodage du protocole Maple bus en plus des protocoles déjà présents.

Le décodage de protocole est une opération que l'on doit activer après acquisition des signaux à observer. Les informations viennent alors se superposer sur les traces de ces signaux.
Dans le cas du Maple bus, les données sont toujours retransmises par bloc de 32 bits, soit 4 octets, de plus l'ordre de retransmission de ces 4 octets est inversé.

• Les valeurs des ces octets se superposent sur la trace du signal SDCKA.
• La délimitation des blocs de 4 octets avec leur numérotation est surimposée sur la trace du signal SDCKB.

Décodage d'un échange sur le Maple bus.

1) Traces de la capture d'une requête faite par la DreamCast (cliquer sur l'image pour la zoomer) :

• Bloc n° 0, c'est l'entête de la trame, octets 01H, 00H, 20H, 09H
  • En fait il faut inverser l'ordre des octets : 09H, 20H, 00H, 01H.
  • Ensuite il faut consulter la page http://mc.pp.se/dc/maplebus.html sur le site de Marcus Comstedt, le tableau "Frame header" renseigne sur la signification de ces octets. Les tableaux associés donnent les informations complémentaires sur chacun de ces octets.
    Le document de la patente US http://www.boob.co.uk/docs/MaplePatent.pdf donne ces informations sur ces octets (figure 48 et texte associé) mais elles sont beaucoup moins conviviales bien qu'elles soient officielles.
    • 1^er octet = 09H : c'est le n° de la Commande (tableau "Commands"), il s'agit de "Get condition". Il y a un paramètre associé : le code fonction. La réponse attendue est la n° 8 (Data Transfert).
    • 2^em octet = 20H : c'est le n° du destinataire (tableau "Address format"), c'est la manette.
    • 3^em octet = 00H : c'est le n° de l'expéditeur (tableau "Address format"), c'est la DreamCast.
    • 4^em octet = 01H : c'est le nombre de blocs (4 octets) de données associées.
• Bloc n° 1, c'est le paramètre associé sur 32 bits : octets 01H, 00H, 00H et 00H qu'il faut inverser, ce qui donne 00000001H sur 32 bits. C'est le code fonction pour cette commande n°9 car un destinataire peut supporter plusieurs fonctions, cas du MMS par exemple : écran LCD ou mémoire flash.
  Le tableau "Available function codes" renseigne sur le nom de la fonction à atteindre, c'est la $001 donc le "Controller".
• Le dernier octet est le checksum de tous les octets de la trame.

2) Traces de la capture de la réponse à la requête précédente (cliquer sur l'image pour la zoomer) :

Décodage de cette trame en cours de rédaction ...

[funkycochise]

plus je lis ce topic, plus je me dis que l'i/o board board naomi pourrait passer sur un grill
équivalent.

[f4brice]

 

[Darth Nuno]

Bueno 
Bon sang, si j'aurais plus de compétence en électronique, la première chose que j'étudierais serait les signaux envoyé par certains jeux à leur laser disc player .
Cela à déjà été fait pour mettre au point l'émulateur Daphne, ou encore 'EURO DL' interface,  qui permet de piloter un lecteur LD récent (récent ...enfin...tout est relatif  ) à la place des plus anciens très difficilement réparable. En clair le PCB envois les signaux originaux destiné au vieux lecteurs, mais un petit soft 'traduit' ces signaux (qui ont été au préalable analysé grâce à un procédé similaire à ce que tu fait dans ce post pour la manette DC) et envois les signaux vers un autre lecteur plus récent (le soft/interface joue un rôle de 'gateway' en quelque sorte).
Bon, je t'invite un WE chez moi afin d'analyser tout ce qui sort du Galaxian Theater, oki?   

[funkycochise]

Bueno  
Bon sang, si j'avais plus de compétence en électronique, la première chose que j'étudierais serait les signaux envoyé par certains jeux à leur laser disc player .
Cela à déjà été fait pour mettre au point l'émulateur Daphne, ou encore 'EURO DL' interface,  qui permet de piloter un lecteur LD récent (récent ...enfin...tout est relatif   ) à la place des plus anciens très difficilement réparable. En clair le PCB envois les signaux originaux destiné au vieux lecteurs, mais un petit soft 'traduit' ces signaux (qui ont été au préalable analysé grâce à un procédé similaire à ce que tu fait dans ce post pour la manette DC) et envois les signaux vers un autre lecteur plus récent (le soft/interface joue un rôle de 'gateway' en quelque sorte).
Bon, je t'invite un WE chez moi afin d'analyser tout ce qui sort du Galaxian Theater, oki?  

faut déjà le remonter  

[gc339]

Décodage d'un échange sur le Maple bus. (suite)

2) Traces de la capture de la réponse à la requête précédente (cliquer sur l'image pour la zoomer) :

• Bloc n° 0, c'est l'entête de la trame, octets 03H, 20H, 00H, 08H
  • Il faut toujours inverser l'ordre des octets : 08H, 00H, 20H, 03H.
  • 1^er octet = 08H : c'est le n° de la Commande (tableau "Commands"), il s'agit de "Data transfert" et c'est bien cette réponse que la DreamCast attend suite à sa requête.
    Il y a deux paramètres associés : le code fonction suivi des informations sur l'état actuel de la manette.
  • 2^em octet = 00H : c'est le n° du destinataire (tableau "Address format"), en l'occurrence c'est le port A de la DreamCast et c'est effectivement le port sur lequel le cordon de la manette est physiquement enfiché.
  • 3^em octet = 20H : c'est le n° de l'expéditeur (tableau "Address format"), c'est le périphérique principal. En l'occurrence la manette elle même et non pas un accessoire enfiché dans l'un de ses logements pour extension.
  • 4^em octet = 03H : c'est le nombre de blocs (4 octets) de données associées.
  
  
• Bloc n° 1, c'est le 1^er paramètre associé sur 32 bits : octets 01H, 00H, 00H et 00H qu'il faut inverser, ce qui donne 00000001H sur 32 bits. C'est donc le code fonction $001 et c'est à nouveau le "controller" Les deux blocs qui suivent sont donc les informations qui viennent d'être lues dans ce "controller".
  
  
• Blocs n° 2 et n° 3, les octets lus : 00H₍₁₎, 00H₍₂₎, 0FFH₍₃₎, 0FFH₍₄₎, 80H₍₁₎, 80H₍₂₎, 80H₍₃₎ et 80H₍₄₎.
  
  
  • Il faut tout d'abord réordonner les octets de chaque bloc : 0FFH₍₄₎, 0FFH₍₃₎, 00H₍₂₎, 00H₍₁₎, 80H₍₄₎, 80H₍₃₎, 80H₍₂₎ et 80H₍₁₎.
    
    
  • Il faut ensuite interpréter ces octets selon la structure "Gamepad Condition" de la page http://mc.pp.se/dc/controller.html, toujours sur le site de Marcus Comstedt. Sinon il faut se référer au tableau 14 du document de la patente.
    • 1^er octet : 0FFH ou 1111 1111 en binaire, ce sont les états, en lisant les bits du MSB (le plus significatif, donc celui de l'extrême gauche ) en direction du LSB (le moins significatif, donc celui de l'extrême droite ), des contacts Droite, Gauche, Bas et Haut du manche directionnel puis des boutons Start, A, B et C.
      Ces bits sont tous à 1 donc on peut en déduire que le manche est en position centrale et qu'aucun des boutons A, B  ou Start n'est enfoncé, le bouton C n'existant pas sur la manette standard il est considéré par défaut à l'état repos.
    • 2^em octet : 0FFH ou 1111 1111 en binaire, ce sont les états, toujours en lisant les bits du MSB vers le LSB des contacts Droite, Gauche, Bas et Haut du 2^em manche directionnel puis des boutons D, X, Y et Z.
      Les bits du quartet de gauche sont tous à 1, les contacts du deuxième manche sont donc considérés au repos par défaut puisque ce 2^em manche n'existe pas. Je suppose que ces bits doivent être utilisés par le deuxième manche du TwinStick, celui de droite.
      Les bits du quartet de droite sont aussi à 1 donc aucun des boutons X et Y n'est enfoncé, les boutons D et Z n'existant pas sur la manette standard, ils sont considérés par défaut à l'état repos.
    • Octets 3 et 4 à zéro : valeur analogique lue sur le capteur à effet Hall de la gâchette de droite suivie de celle de celle lue pour la gâchette de gauche.
      La valeur doit croître vers la valeur butée de 255 en fonction de l'appui sur la gâchette concernée, la valeur doit revenir à zéro quand celle-ci est complètement relâchée.
    • Octets 5 et 6 à 80H ou 128 en décimal : position en X et puis celle en Y du manche analogique. 128 est la valeur centrale entre 0 et 255 (256 ÷ 2 = 128). Cette valeur de 128 correspond aux 2,5 volts en sortie de chaque amplificateur quand le manche analogique est au repos en son centre. Cette valeur croit vers 255 ou décroît vers 0 en fonction du la direction et du degré  d'inclinaison du manche. Voir à ce sujet les commentaires en fin du 1^er post de ce fil de discussion : http://www.gamoover.net/Forums/index.php?topic=21932.msg321166#msg321166 .
    • Octets 7 et 8 à 80H ou 128 en décimal : position en X et puis celle en Y d'un 2^em manche analogique. A l'heure actuelle je suis incapable de dire s'il y a des pattes d'entrées analogiques prévues à cet effet sur la puce E2 Maple Bus. Je n'ai pas non plus connaissance d'accessoires DreamCast utilisant cette fonctionnalité pour un deuxième manche analogique ou qui la dévoie pour un capteur analogique autre.
      Ce 2^em manche fantôme est considéré par défaut en position centrale puisque la valeur de ses deux octets est lue égale à 128.
  
  
• Le dernier octet est toujours le checksum de tous les octets de la trame.

[gc339]

Bon sang, si j'aurais plus de compétence en électronique, la première chose que j'étudierais serait les signaux envoyé par certains jeux à leur laser disc player.
[couic]

Je te réponds en citant f4brice :

Connaissances en électronique + Passion + Motivation + Temps = PCB et bornes réparés !

Ingrédient n° 1 : Compétences : tu en as un minimum si on interprète bien tes dires.
Ingrédient n° 2 : Passion, c'est le cas.
Ingrédient n° 3 : Motivation, je pense que oui.
Ingrédient n° 4 : Le temps, t'es sur un pied d'égalité avec quiconque, on en manque tous.

C'est en forgeant que l'on devient musicien. Ce n'est qu'en pompant que vous arriverez a quelque chose et même si vous n'y arrivez pas... hé bien ca vous aura pas fait de mal!

Donc plus d'hésitation possible, investissement de quelques piastres pour acquérir un analyseur comme le SCANALOGIC 2 d'IKALOGIC et en avant, fais toi plaisir.
 
Au bout de quelque temps, je suis sûr que t'arriveras à écrire des posts comme les miens, qui n'intéresseront que quelques rares érudits et que tu arriveras pour le dessert quand Nunette aura crié déjà 3 ou 4 fois "à table".

[High_Cobra]

rahh putain, félicitations gc !!! Superbe boulot ! La, tu vois, vu comme ça, je me dit qu'on est pas loin de pouvoir implémenter le standard Dreamcast dans l'upcb et ainsi se passer du piggyback... Ca cause à quelle vitesse tout ce merdier ? C'est rapide ou pas ?

Et merci de m'avoir fait découvrir ce type d'analyseur, vraiment pas cher, je pense que je vais m'en commander un très bientot...

Encore félicitations pour ton topic

[gc339]

rahh putain, félicitations gc !!! Superbe boulot ! La, tu vois, vu comme ça, je me dit qu'on est pas loin de pouvoir implémenter le standard Dreamcast dans l'upcb et ainsi se passer du piggyback... Ca cause à quelle vitesse tout ce merdier ? C'est rapide ou pas ?

C'était d'ailleurs une de mes idées idée à l'origine : http://www.gamoover.net/Forums/index.php?topic=21932.msg321195#msg321195

• De reconstituer un contrôleur simplifié à partir d'un µC hyper rapide comme le SX28 de chez Scenix / Parallax car les transmissions sur Maple s'effectuent à 2 Mb/s coté DC, elles peuvent être néanmoins plus lentes coté périphérique.
  Marcus Comstedt à déjà réalisé une interface USB / Maple bus, mais il a pris soin de choisir un µC Cypress qui dispose d'E/S spécifiques pour traiter plus facilement les données transmises à 2 Mb/s par la DC : http://mc.pp.se/dc/dchid.html
  
  
• De dessouder la puce E2 Mapple bus d'une manette rebutée et la ressouder sur un adaptateur TQFP64 ( http://www.futurlec.com/SMD_Adapters.shtml ) pour réaliser par exemple :
  
  • Un clone du TwinStick.
  • Un clone du stick arcade à 6 boutons.
  • Ou que sais je encore comme réalisation home-made ...
  
  
  
  
  

Et merci de m'avoir fait découvrir ce type d'analyseur, vraiment pas cher, je pense que je vais m'en commander un très bientot...

Va y fonce, ce joujou vaut vraiment le coup, son rapport performances / prix est imbattable.

Le logiciel n'est pas figé et son concepteur, Ibrahim Kamal, y inclura des fonctionnalités au fur et à mesure.
Il est à l'écoute de toute demande qui pourrait améliorer le produit, comme le décodage d'un protocole, tu peux le contacter sans problème si tu as un besoin spécifique.

A chaque démarrage, le logiciel Scanalogic 2 va tester si une mise à jour est disponible et il te propose alors de la faire, opération qui dure quelques secondes. Donc tu est sûr de bénéficier à chaque fois des dernières évolutions.
Il n'y a que la mise à jour du logiciel de la sonde qui est manuelle puisque exceptionnelle, il faut rapatrier le fichier .hexe adéquat à partir du site Ikalogic, puis lancer l'opération à partir d'un des menus de Scanalogic 2.

[High_Cobra]

En fait, je me demandais si le 18F4550 de l'upcb serait capable de se démerder pour aller assez vite pour gérer ça sans aucun chip additionnel, ce qui serait quand même le pied.

Ca permettrait d'ajouter le support DC uniquement par MAJ du l'UPCB...

J'ai pas encore potassé la doc assez en profondeur pour savoir s'il est assez rapide pour tenir la cadence...

[gc339]

En fait, je me demandais si le 18F4550 de l'upcb serait capable de se démerder pour aller assez vite pour gérer ça sans aucun chip additionnel, ce qui serait quand même le pied.

Ca permettrait d'ajouter le support DC uniquement par MAJ du l'UPCB...

J'ai pas encore potassé la doc assez en profondeur pour savoir s'il est assez rapide pour tenir la cadence...

La vitesse maximale du 18F4550 est de 12 Mips (Horloge 48 MHz, 4 cycles par instruction) donc 12 instructions par µs si je ne me suis pas trompé en lisant son datasheet.
Un changement d'état sur le Maple bus est susceptible de se produire 0,25 µs après le précédent donc le 18F4550 n'aura le temps d'exécuter que 3 instructions basiques !

Le SX28 légèrement overclocké (80 Mhz au lieu de 75) peut tourner à 80 Mips, il aura donc le temps d'exécuter 20 instructions entre chaque changement d'état. Il doit donc être possible de faire du polling ou encore d'utiliser les interruptions en optimisant les routines.

[gc339]

Bonjour.

Je me suis décidé à installer un bouton de reset sur ma DreamCast à fin de pouvoir tracer les phases d'initialisation des accessoires connectés sur les ports.

Les traces ont été d'abord capturées à partir de ce modèle de manette acquise chez MoeroShop à une époque où elle était en promotion à 1€.

Cette manette a l'avantage d'être reconfigurable par deux switches facilement accessibles :

• Le premier permet de choisir entre une configuration standard à 4 boutons + gâchettes ou une configuration arcade à 6 boutons.
• Le deuxième permet de mettre en service le vibreur. La présence de ce vibreur étant faite au détriment de celle d'un deuxième logement pour accessoire supplémentaire.

Quelques mots sur l'adressage entre la DreamCast et ses accessoires.

L'octet d'adresse est utilisé dans les champs adresse source et/ou adresse destination des entêtes des trames échangées sur le maple bus.

Sur ce schéma sont stylisés :

• La DreamCast ou HOST avec ses 4 ports A, B, C et D.
• Les différents contrôleurs (comme les manettes, le light gun ...) que l'on peut raccorder sur les ports de la DreamCast. Ils sont dénommés "base devices" ou dispositifs de base.
• Les différents accessoires (pack vibreur, MMS ...) que l'on peut insérer dans les logements des différents contrôleurs.Ils sont dénommés "expansion devices" ou dispositifs d'extension.

L'octet d'adresse :

• Deux bits sont utilisés pour le n° de port, ce sont les bits 6 et 7 dans l'octet d'adresse.
  • 00 binaire = port A.
  • 01 binaire = port B.
  • 10 binaire = port C.
  • 11 binaire = port D.
• Etant donné que l'on ne peut connecter qu'un seul "Base Device" ou dispositif de base sur un port de la DreamCast, un seul bit lui est réservé, c'est le bit 5 dans l'octet d'adresse.
  Il est à 1 pour adresser le "base device" ou dispositif de base, et à 0 pour tous les autres cas.
• Il reste donc 5 bits dans cet octet d'adresse, Chacun de ces bits est donc utilisé pour adresser, ou indiquer la présence, du dispositif d'extension associé.
  En fait il n'y a que 4 dispositifs physiques possibles et ils sont associés aux bits de 0 à 3. Le cinquième dispostif, celui associé au bit 4, est un dispositif virtuel utilisé par le logiciel de la DreamCast.

Exemples :

• Adresse 0x80 ou 10.0.0000 : Port C seul.
• Adresse 0xE0 ou 11.1.0000 : Dispositif de base sur le Port D.
• Adresse 0x23 ou 00.1.0011 : Pour adresse source uniquement, dispositif de base sur le port A. Par ce moyen, le dispositif de base indique la présence de ses dispostifs d'extension n° 1 et n ° 2.
• Adresse 0x42 ou 01.0.0010 : Dispositif d'extension n° 2 sur le port B.

1) Phases d'initialisation de la manette configurée en standard 4 boutons + gâchettes sans vibreur.

Aperçu global

La fréquence d'échantillonnage a été abaissée à 250 khz histoire d'obtenir un aperçu global des trames échangées qui puisse être contenu dans la fenêtre du Scanalogic 2.

L'affichage étant condensé temporellement, les paires de trames requête + réponse ne peuvent se distinguer l'une de l'autre sur cette capture d'écran, elles se retrouvent figurées dans le même "paquet" par une raie verticale ± épaisse. Certains "paquets" n'y sont même pas figurés pour cause de résolution de l'affichage, ils disparaissent/réapparaissent de la fenêtre en fonction de la contraction/dilatation de l'échelle temporelle. L'emplacement de chacun d'eux est néanmoins indiqué par un marqueur qui a pu être disposé en dilatant temporairement cette échelle.

La première trame qui suit le reset est une requête "Device Status", elle est immédiatement suivie de la réponse "Device Status" indiquant le type d'accessoire connecté sur le port impliqué ainsi que sa configuration.
Les deux autres échanges qui suivent sont des trames "Get Condition" + "Device Reply" où la manette renvoie l'état des boutons, du manche, ainsi que des gâchettes et du manche analogiques.
Après un grand moment d'accalmie (de l'ordre de 400 ms) les échanges "Get Condition"/"Device Reply" reprennent à nouveau cycliquement.


1^er échange

La trame "Device Request" de la requête suivie du début de la trame "Device Status" de la réponse

A noter que la fréquence de retransmission de la manette est plus basse que celle de la DC, cette dernière retransmettant avec une horloge de 1 MHz.

DC Request ********** Bloc   Octets 00     0x00   0x40   0x60   0x01 CS     0x21	|       |       |       |       |       |	Header   (AP = Absolute Position) Bloc.Octet 00.1   Command Code = 1 : Device Request 00.2   Destination AP = 01.1.00000 : Base Device on Port B 00.3   Source AP = 01.0.00000 : Port B of Host (DC) 00.4   Data Size = 0
	|
Device Response *************** Bloc   Octets 00     0x1C   0x60   0x40   0x05 01     0x01   0x00   0x00   0x00 02     0xFE   0x06   0x0F   0x00 03     0x00   0x00   0x00   0x00 04     0x00   0x00   0x00   0x00 05     0x72   0x44   0x00   0xFF     [Dr] 06     0x63   0x6D   0x61   0x65   [eamc] 07     0x20   0x74   0x73   0x61   [ast ] 08     0x74   0x6E   0x6F   0x43   [cont] 09     0x6C   0x6C   0x6F   0x72   [roll] 10     0x20   0x20   0x72   0x65   [er  ] 11     0x20   0x20   0x20   0x20   [    ] 12     0x20   0x20   0x20   0x20   [    ] 13     0x64   0x6F   0x72   0x50   [Prod] 14     0x64   0x65   0x63   0x75   [uced] 15     0x20   0x79   0x42   0x20   [ By ] 16     0x55   0x20   0x72   0x6F   [or U] 17     0x72   0x65   0x64   0x6E   [nder] 18     0x63   0x69   0x4C   0x20   [ Lic] 19     0x65   0x73   0x6E   0x65   [ense] 20     0x6F   0x72   0x46   0x20   [ Fro] 21     0x45   0x53   0x20   0x6D   [m SE] 22     0x45   0x20   0x41   0x47   [GA E] 23     0x52   0x45   0x54   0x4E   [NTER] 24     0x53   0x49   0x52   0x50   [PRIS] 25     0x4C   0x2C   0x53   0x45   [ES,L] 26     0x20   0x2E   0x44   0x54   [TD. ] 27     0x20   0x20   0x20   0x20   [    ] 28     0x01   0xF4   0x01   0xAE CS     0x19	|       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |	Header   (AP = Absolute Position) Bloc.Octet 00.1   Command Code = 5 : Device Status 00.2   Destination AP = 01.0.00000 : Port B of Host (DC) 00.3   Source AP = 01.1.00000 : Base Device on Port B 00.4   Data Size = 28 Device ID Bloc.Octet 01     Function Type(s) = 0x00 0x00 00000000b 00000001b : Only Controller Function 02     Function Definition Block 1 = 0x00 0x0F 0x06 0xFF : Controller 02.1      11111110b : First joystick, buttons Start, A and B used 02.2      00000110b : Only buttons X and Y used 02.3      00001111b : Both triggers and first analogue joystick used 02.4      00000000b : Unused 03     Function Definition Block 2 = 0x00 0x00 0x00 0x00 : 2nd function does not exist 04     Function Definition Block 3 = 0x00 0x00 0x00 0x00 : 3rd function does not exist Fixed Device Status Bloc.Octet 05.1   Destination Region = 11111111b : Area 4, 3, 2, 1, Europe, Asia, Japon, North America 05.2   Dummy = 0 05.3   Produc Name (30 Ascii) = "Dreamcast controller          " 13.1   License (60 Ascii) = "Produced By Or Under License From SEGA ENTERPRISES,LTD.     " 28.1   StandBy current consuption (little endian) = 0x01AE = 430 : 43 mA 28.3   Maximun current consuption (little endian) = 0x01F4 = 500 : 50 mA

Avec cette réponse la DC a obtenu des informations essentielles sur la manette :

• Les zones géographiques avec lesquelles elle est compatibile.
• Le masque de présence ( Function Definition Block 1 ), elle sait alors quels sont les boutons, les manches et les gâchettes qui équipent cette manette.
  

2^èm échange et échanges suivants

La DreamCast interroge périodiquement cette manette à l'aide de la paire de trames "Get Condition" / "Data Transfer"

La trame "Get Condition" de la requête

DC Request ********** 00   0x01   0x80   0xA0   0x09 01   0x01   0x00   0x00   0x00 CS   0x29

|       |       |       |       |       |       |       |

Header   (AP = Absolute Position) 00.1   Command Code = 9 : Get Condition 00.2   Destination AP = 10.1.00000 : Base Device on Port C 00.3   Source AP = 10.0.00000 : Port C of DC Host 00.4   Data Size = 1 Parameter 01   Function Type(s) = 0x00 0x00 00000000b 00000001b : Only Controller Function

Avec cette requête, la DC interroge la manette dans le but d'obtenir :

• L'état des boutons et du manche conventionel.
• Les positions des gâchettes et du manche analogique.

La DC connaît exactement quels sont les boutons, manches et gâchettes qui sont présents sur cette manette, elle a obtenu le masque de présence suite à l'échange "Device Request"/ "Device Status".

La trame "Data Transfer" de la réponse

Device Response *************** 00   0x03   0x60   0x40   0x08 01   0x01   0x00   0x00   0x00 02   0000   0000   0xFF   0xFF 03   0x80   0x80   0x80   0x80 CS   0x2A

|       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |       |

Header   (AP = Absolute Position) 00.1   Command Code = 8 : Data Transfer 00.2   Destination AP = 01.0.00000 : Port B of Host (DC) 00.3   Source AP = 01.1.00000 : Base Device on Port B 00.4   Data Size = 3 01   Function Type(s) = 0x00 0x00 00000000b 00000001b : Only Controller Function 02   Function Data : 11111111b 11111111b 0x00 0x00 Buttons and Joysticks Data 02.1      11111111b : Right a, Left a, Down a, Up b, Start, A, B et C 02.2      11111111b : Right b, Left b, Down b, Up b, D, X, Y et Z Analogue Triggers Data 02.3      0x00 : Right Trigger 02.4      0x00 : Left Trigger 03   Function Data : 0x80 0x80 0x80 0x80 Analogue Joysticks Data 03.1      0x80 0x80 : X, Y, First Joystick 03.2      0x80 0x80 : X, Y, Second Joystick

Avec cette réponse la DC a obtenu l'état instantané des boutons, des manches conventionels ainsi que les positions des gachettes et manches analogiques.
A l'aide du masque de présence obtenu par l'échange "Device Request"/ "Device Status" elle peut oblitérer ou ignorer les états ou les positions par défaut de ceux et de celles dont la manette n'est pas équipée.