-
La manette HKT7700 comporte 2 gâchettes ainsi qu'un manche analogiques, la progressivité étant assurée par l'approche/éloignement d'un aimant permanent par rapport à des capteurs à effet Hall soudés sur le circuit imprimé principal. Ce dispositif permet d'obtenir une bien meilleure fiabilité à l'usage puisqu'il n'y a plus de contact électrique entre la partie mobile et la partie fixe de chaque mécanisme comme il y en aurait par exemple avec un potentiomètre.
Chaque gâchette du HKT7700 comporte un aimant permanent dont la pression sur la dite gâchette le rapproche du capteur associé, augmentant ainsi l'intensité du champ magnétique perçue par ce capteur.
Le manche lui n'est pourvu, en bout de tige, que d'un seul aimant permanent pouvant survoler 4 capteurs disposés en forme de croix, un pour chaque point cardinal.
- Manche au centre : l'aimant est au centre de la croix, l'intensité du champ reçu est identique pour chacun des 4 capteurs.
- Manche incliné en direction d'un des 4 points cardinaux : l'aimant survole alors une seule branche de la croix et n'exerce une influence grandissante avec l'inclinaison du manche que sur le capteur associé. Celui-ci perçoit alors une augmentation du champ magnétique reçu alors que celui diamétralement opposé le voit diminuer. Les deux autres capteurs latéraux reçoivent une intensité de champ magnétique égale, même si elle varie avec l'inclinaison du manche, car la distance de chacun avec l'aimant mobile reste identique.
- Manche incliné dans une direction intermédiaire : l'aimant, survole un seul des quatre espaces compris entre deux branches orthogonales de la croix et par conséquent n'exerce une influence grandissante avec l'inclinaison du manche que sur les deux capteurs encadrant cet espace. Ces deux capteurs perçoivent alors une augmentation du champ magnétique reçu alors que celui diamétralement opposé à chacun le voit diminuer.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100715200432-gc339-DSCF4686bis.JPG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100715200432-gc339-DSCF4686bis.JPG)
| |
Les capteurs avec leur circuiterie, ils sont essentiellement localisés sur la branche gauche du circuit imprimé en forme de "U" :
- En haut, les 4 capteurs à effet Hall, HED1 à HED4, disposés en croix. Le dispositif mécanique du manche qui les coiffe en temps normal a été démonté pour la photo.
Le centrage du mécanisme du manche est assuré par un ergot qui vient se loger dans le trou au centre de la croix. A noter que les capteurs situés sur deux branches opposées de la croix ( HED1 / HED2 et HED3 / HED4 ) sont soudés boîtier inversé de 180° l'un part rapport à l'autre.
- Au milieu sur la gauche, le capteur de la gâchette gauche (HED5). Le dispositif mécanique de la gâchette n'a pas été démonté, il n'est pas visible sur la photo car il est fixé au dos du circuit imprimé.
- A la droite des 4 capteurs et tout en bas, les deux amplificateurs double IC3 et IC4 ainsi que la foultitude de résistances périphériques.
A noter que le déplacement de l'aimant permanent est inversé par rapport à celui du manche :
- L'aimant survole HED1 disposé à droite quand le manche est incliné sur la gauche, et inversement HED2 disposé à gauche quand il est incliné sur la droite.
- L'aimant survole HED3 disposé en haut quand le manche est incliné vers le bas, et inversement HED4 disposé à en bas quand il est incliné vers le haut.
|
Les capteurs à effet Hall employés ici sont logés dans un boîtier à quatre pattes dont une est plus large que les autres pour assurer le détrompage.
Après recherche dans cette notice : http://ww1.microchip.com/downloads/en/PackagingSpec/00049AF.pdf le boîtier employé semble être du type SOT143 :
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100715221432-gc339-SOT143.JPG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100715221432-gc339-SOT143.JPG)
Les dimensions relevées au pied à coulisse semblent correspondre, le seul hic c'est que la patte plus large assurant le détrompage n'est pas au bon emplacement sur les capteurs. La patte plus large correspondrait à la patte 2 ou à la patte 4, à moins que pour une raison obscure les capteurs aient été soudés retournés, c'est à dire sens dessus dessous !
Une recherche sur le net avec les mots clef "SOT143" et "hall sensor" m'a permis de trouver le capteur CYTHS124 : http://www.bbautomacao.com/pdfs/CYTHS124.pdf qui semblerait correspondre au type employé sur cette manette HKT7700.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100715225836-gc339-CYTHS124.JPG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100715225836-gc339-CYTHS124.JPG)
Avec cette référence de capteur le positionnement de la patte la plus large comme étant la broche 4 convient bien, la longueur des pattes est même asymétrique pour mieux reconnaître le sens d'orientation du boîtier !
Quelques mots sur l'effet Hall : il se produit dans un ruban de matériau semi-conducteur parcouru par un courant électrique quand il y a présence d'un champ magnétique. Le courant circulant entre les deux extrémités du ruban ( entre les broches 1 et 3 dans le cas du CYTHS124 ), deux points situés identiquement sur les deux faces opposées sont normalement équipotentiels. La présence d'un champ magnétique vient altérer cet équilibre et une tension proportionnelle à l'intensité du champ apparaît alors entre ces deux points ( broches 2 et 4 dans le cas du CYTHS124 ), c'est l'effet Hall.
La tension engendrée par cet effet étant insignifiante, il faut alors l'amplifier pour qu'elle soit utilisable.
Avec tous ces renseignements obtenus à partir du datasheet du CYTHS124, je vais pouvoir créer ce capteur dans la librairie d'Eagle afin de dessiner le schéma de toute la circuiterie analogique de la manette HKT7700 à partir de ce logiciel.
Relever ce schéma est une entreprise fastidieuse, il faut beaucoup d'intuition et une certaine connaissance des schémas électroniques conventionnels pour s'y retrouver car il est très difficile de suivre les pistes à l'oeil nu, les connexions entre les différents composants se retrouvant la plupart du temps avec un ohmmètre. Il m'a même fallu utiliser le vieux microscope que mon épouse avait reçu comme cadeau de Noël étant gamine pour arriver à lire la valeur des résistances tellement la sérigraphie était minuscule.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100715234241-gc339-DCana.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100715234241-gc339-DCana.PNG)
Quelques commentaires sur ce schéma :
- Le courant nécessaire aux capteurs à effet Hall est obtenu à partir du rail +5 volts :
- Entrée (+) ( broche 1 ) connectée au rail +5 volts.
- Entrée (-) ( broche 3 ) connectée à la masse commune.
Ce courant doit être de l'ordre de 4 à 5 mA si l'on se fie à la valeur de la résistance interne donnée dans le datasheet du CYTHS124.
- Les capteurs du manche directionnel sont associés par paire, la paire gauche/droite et la paire haut/bas. Les deux capteurs de chaque paire sont câblés tête bêche, c'est à dire que la sortie (+) de l'un est connectée à la sortie (-) de l'autre à travers des résistances de 18 Kohms et réciproquement, ainsi la tension résiduelle de chacun se retrouve annulée en entrée de l'amplificateur associé quand le manche est en position centrale.
- La tension de repos en sortie des amplificateurs IC3A et IC3B, c'est à dire quand le manche est en position centrale, est égale à la moitié de la tension d'alimentation soit 2,5 volts. Elle est issue du pont de polarisation composé de R14 et R15, toutes les deux étant égales à 22 Kohms.
- Un déplacement du manche dans une direction donnée fera augmenter ou diminuer la tension de sortie de l'amplificateur concerné de part et d'autre de son point de repos.
Voici ce qui a été mesuré en sortie de ces deux amplificateurs :
IC3A : | manche au centre = 2,52 volts, | manche en butée à gauche = 1,32 volt, | manche en butée à droite = 3,72 volts. |
IC3B : | manche au centre = 2,54 volts, | manche en butée en bas = 1,26 volt, | manche en butée en haut = 3,66 volts. |
- La tension de repos en sortie des amplificateurs IC4A et IC4B, c'est à dire quand les gâchettes sont complètement relâchées, n'est pas égale à la moitié de la tension d'alimentation car les valeurs des résistances R26 / R27 du pont de polarisation sont inégales. La valeur théorique serait donc de 5 × 10 ÷ (56 + 10) soit 0,76 volt.
- La tension de repos de ces amplificateurs étant relativement faible, la pression sur l'une de ces gâchettes devrait donc plutôt faire croître en conséquence la tension en sortie de l'amplificateur concerné.
Voici ce qui a été mesuré en sortie de ces deux amplificateurs :
IC4A : | gâchette droite relâchée = 0,65 volt, | gâchette droite appuyée en butée = 2,48 volts. |
IC4B : | gâchette gauche relâchée = 1,06 volt, | gâchette gauche appuyée en butée = 2,95 volts. |
A noter la différence conséquente entre les tensions délivrées par les deux gâchettes, probablement due à une disparité entre les deux aimants permanents.
- Les sorties des amplificateurs sont directement connectées aux entrées analogiques ( broches 1, 62, 63 et 64 ) de la puce Maple Bus ( IC 1 ).
Un doute subsiste, à mon avis, sur le repérage des sorties (+) et (-) des capteurs à effet Hall employés, elles devraient plutôt être inversées par rapport au CYTHS124 si l'on se fie à la polarité des entrées des amplificateurs opérationnels sur lesquels elles sont raccordées. C'est à dire que la sortie (+) devrait plutôt être en 2 du capteur et la sortie (-) en 4, ce qui est le cas pour d'autre modèles de capteur du même fabricant.
Pour l'instant le schéma est dessiné avec le repérage des électrodes des capteurs issu du datasheet du CYTHS124, ce qui au fond, ne change rien à l'exactitude des connections entre composants.
-
Joli travail ! <:)
J'ai déjà vu des capteurs à effet Hall dans... les ventilateurs de PC !
C'est lui qui génère le signal de vitesse présent sur le 3e fil du ventilateur.
Le but de ce WIP est-il de documenter les manettes DC pour permettre leur connection à un panel de borne ?
N'ayant pas de console Dreamcast, je ne me suis jamais posé la question de la faisabilité.
Bonne continuation.
-
mais c'est pas vrai!
un 2ème topic fondu d'électronique en moins de 24h!
:o
vous faites un complot f4brice et Gc339 ? =:))
chapeau bas!
je ne pensait pas que sega avait fait un système aussi ingénieux et complexe dans ses (dèrnières :'() manettes! ^-^
merci pour ces infos bien intéressantes :-*
en fait l'effet Hall c'est ce qui est utilisé dans les compteurs kilométriques de cyclistes alors ?
l'aimant qu'on met sur les rayons... :)
-
en fait l'effet Hall c'est ce qui est utilisé dans les compteurs kilométriques de cyclistes alors ?
l'aimant qu'on met sur les rayons... :)
Non car trop cher.
Le capteur est un simple ILS (http://fr.wikipedia.org/wiki/Interrupteur#Magn.C3.A9tique).
-
Bonjour.
Le but de ce WIP est-il de documenter les manettes DC pour permettre leur connection à un panel de borne ?
Le but de ce WIP est de décortiquer les manettes DreamCast HKT7300 ( 6 boutons A, B, C, X, Y et Z ) et HKT7700 ( 4 boutons A, B, X et Z + 2 gâchettes analogiques ), elles sont similaires puisqu'elles utilisent le même chip Maple Bus Sega, le E2 MAPLE BUS 315-6125-AB.
Le but final est de :- Reconstituer le schéma des deux manettes.
- Retrouver l'utilité de toutes les broches du chip Maple Bus afin de pouvoir l'inclure dans une librairie Eagle.
- De dessouder un de ces chips pour l'installer sur un adaptateur TQFP64 afin de mieux l'étudier : http://www.futurlec.com/SMD_Adapters.shtml
(http://www.futurlec.com/Pictures/TQFP_64.jpg) - D'étudier les points obscurs et les non-dits du protocole d'échange avec la DreamCast : http://www.boob.co.uk/docs/MaplePatent.pdf
- Et pourquoi pas reconstituer un contrôleur simplifié à partir d'un µC hyper rapide comme le SX28 de chez Scenix / Parallax : http://www.parallax.com/Store/Microcontrollers/SXProducts/tabid/138/CategoryID/15/List/0/SortField/0/Level/a/ProductID/355/Default.aspx en s'inspirant de cet adaptateur Maple Bus to USB réalisé par Marcus Comstedt : http://mc.pp.se/dc/dchid.html
Voila de quoi occuper les veillées de l'hiver à venir ...
-
Le but de ce WIP est-il de documenter les manettes DC pour permettre leur connection à un panel de borne ?
N'ayant pas de console Dreamcast, je ne me suis jamais posé la question de la faisabilité.
Par "Hack" , c'est déjà possible. En soudant sur les pastilles et ce même pour les gâchettes (on y perd l'analogique).
Avec ce genre d'analyse, on y gagnerait quoi pour la connexion à une borne ?
Ou peut être que GC339 n'arrivais pas à dormir par ces nuits chaudes , tous simplement :D
EDIT : Ah bah non, il est curieux, c'est tous :)
-
Le pad HKT-7300 comporte 1 manche directionnel ainsi que 6 boutons A, B, C, X, Y , Z plus un bouton START.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100719003608-gc339-dcstick-header.jpg) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100719003608-gc339-dcstick-header.jpg)
La puce E2 MAPLE BUS est monté sur un petit circuit imprimé dont les liaisons sont assurées par des connecteurs :
- Le connecteur CN1 à 5 broches sur lequel s'enfiche le cordon de liaison avec la DreamCast.
- Le connecteur CN2 à 14 contacts pour le port d'extension. C'est l'unique port disponible pour ce pad pour insérer un accessoire supplémentaire comme la VMU ( Visual Memory Unit ) alors que la manette HTK-7700 en comporte deux.
- Le connecteur CN3 à 8 contacts pour le raccordement des 7 boutons du pad.
- Le connecteur CN4 à 5 contacts pour le raccordement des 4 contacts du manche directionnel.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100719002757-gc339-HKT-7300-Wires.jpg) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100719002757-gc339-HKT-7300-Wires.jpg)
Le circuit imprimé dont il est question avec ses câbles.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100719003116-gc339-DSCF4741.JPG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100719003116-gc339-DSCF4741.JPG)
Le circuit imprimé avec le repérage des connecteurs et celui de leurs broches.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100719004554-gc339-HTK-7300.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100719004554-gc339-HTK-7300.PNG)
|
Le schéma du circuit imprimé :
- A gauche les connecteurs CN3, CN4 et CN1.
- Au centre le connecteur CN2 du port d'extension.
- A droite les diverses autres broches ainsi que les broches connectées aux bus d'alimentation de la puce MAPLE BUS.
|
Quelques commentaires sur ce schéma :
- Les composants libellés FBx sont des sortes de straps, leur résistance est nulle. Ceux en série avec les contacts des boutons et des manches ( FB4 à FB14 ) sont prévus mais non équipés et ils sont court-circuités au dos du circuit imprimé par une piste sécable.
- Un doute subsiste sur le raccordement de FB3, une extrémité est effectivement soudée au rail +5 volts, pour l'autre il est difficile de savoir sans dessouder FB3, je suppose qu'elle sert à alimenter le rail commun aux résistances de polarisation des entrées et c'est comme cela qu'elle est connectée sur le schéma provisoire.
- Pour l'instant, les contacts du connecteur CN2, celui du port d'extension, ne sont pas libellés. Une recherche ultérieure faite par observation à l'oscilloscope des signaux échangés avec un VMU devrait permettre de leur affecter les noms de signaux issus de la notice de la patente (http://www.boob.co.uk/docs/MaplePatent.pdf).
- Il manque encore 17 pattes de la puce MAPLE BUS sur le schéma, aucune des ces pattes n'est connectée à un rail d'alimentation ( GND, +5 volts ou + 3,3 volts ) , difficile de savoir si elles sont reliées à quelque chose sans dessouder la puce. L'analyse du schéma de la manette HKT-7700 devrait permettre assurément de repérer les 6 ou 7 pattes normalement dédiées au deuxième connecteur d'extension de cette manette, ce qui ramènerait le nombre de pattes non repérées à une dizaine.
- A noter que les 4 entrées analogiques ( pattes 62, 63, 64 et 1 ) vues dans l'analyse de la circuiterie analogique de la manette HKT-7700 sont ici sont reliées à la masse.
-
Retour sur la manette HKT-7700, analyse de la circuiterie autour de la puce E2 Maple Bus.
Tout d'abord dessoudage de la puce E2 Maple Bus. J'ai acquis à vil prix au cash-converter du coin, après d'âpres négociations, une petite dizaine de ces manettes qui traînaient dans un carton. Pas de problèmes donc pour en sacrifier une.
- Tout d'abord enduction des pattes de la puce d'un flux à souder pour CMS.
- Aspiration du surplus de soudure avec de la tresse à dessouder, le flux facile bien l'opération.
- Il faudrait un outillage spécial à air chaud pour pouvoir chauffer toutes les pattes en même temps. Malheureusement c'est hors de ma portée aussi je vais faire avec les moyens du bord : une aiguille de couturière et un dé à coudre prélevés dans la travailleuse à couture de mon épouse.
L'aiguille, de diamètre adéquat est insérée entre cuir et chair, c'est à dire entre les pattes et le boîtier de la puce ainsi que le circuit imprimé. Il suffit de pousser l'aiguille, merci le dé à coudre, tout en chauffant les pattes de la puce pour qu'elles se soulèvent au fur et à mesure lors de la progression de l'aiguille. - Une fois qu'une rangée de pattes est dessoudée, il suffit de faire la même chose pour le suivante. Pour la dernière, il faut maintenir la puce en place pour éviter qu'elle bascule pendant l'opération et qu'elle arrache les pistes.
- Nettoyage de la puce, une fois dessoudée, à l'acétone avec un pinceau pour bien dissoudre le flux resté entre les pattes.
- Réalignement des pattes de chaque rangée en disposant la puce sur un support plat et appliquant une pression avec le bout d'un réglet métallique sur l'ensemble des méplats des pattes.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100722120427-gc339-DSCF4807.JPG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100722120427-gc339-DSCF4807.JPG)
L'aiguille en place pour le dessoudage de la première rangée de pattes.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100722120632-gc339-DSCF4780.JPG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100722120632-gc339-DSCF4780.JPG)
Le circuit-imprimé une fois la puce dessoudée, la pastille de la patte 46 a été partiellement arrachée.
C'était la première rangée que j'ai dessoudée, ma méthode s'est affinée pour les suivantes et je n'ai plus eu d'arrachage à déplorer.
Le schéma de la circuiterie autour de la puce E2 Maple Bus :
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100722122734-gc339-HTK-7700.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100722122734-gc339-HTK-7700.PNG)
Quelques commentaires sur ce schéma :
- 9 pattes de la puce ne sont pas connectées, ce qui est vérifiable sur le circuit-imprimé : les pattes 30, 31 et les pattes 53 à 60.
- Les pattes dédiées aux boutons C et Z sont inactivées puisque polarisées au + 5 volts.
- Le +5 volts alimentant les amplificateurs des capteurs à effet Hall est filtré par la self L1.
- Deux cavaliers par pont de soudure sont prévus : J1 et J2 pour une quelconque configuration de la puce. Il ne sont pas fermés par un pont de soudure sur cette manette.
-
je suis sideré par la taille de ces soudures... :o
-
je suis sideré par la taille de ces soudures... :o
C'est du "gros" CMS au pas de 1,27 mm si je ne me trompe pas. Il existe aussi ça (http://www.gamoover.net/Forums/index.php?topic=19702.msg282756#msg282756) ! ;)
C'est assez rapide à ressouder quand on possède du flux décapant.
-
C'est du "gros" CMS au pas de 1,27 mm si je ne me trompe pas.
La puce E2 Maple Bus est encapsulée dans un boîtier TQFP64 avec un écartement entre pattes de 0,8 mm ce qui est beaucoup moins "confortable" que les boîtiers CMS avec un écartement de 1,27 mm.
-
serait t'il possible que moyenant une etude du schéma, il soit possible de "transformer" un pad analogique standard en "pseudo stick arcade" aux yeux de la console, ce serait utile dans le cas d'un hack. Je crois savoir que certains jeux réagissent différemment en présence d'un stick. Plus ambitieux, le twin stick (très recherché) utilise egallement le chip (confirmé par une tof du net), voire d'autres periphs officiels (sauf peut etre le volant, du fait des potentiomètres) La possibilité de construire un twin stick à partie de composants arcade ou venant d'autres consoles serait tout simplement énorme pour les fans de virtual on
-
La possibilité de construire un Twin Stick à partie de composants arcade ou venant d'autres consoles serait tout simplement énorme pour les fans de virtual on
Puisqu'il est question de virtual on, il doit donc s'agir du Twin Stick Sega HKT-7500 et non pas du twin-stick ou du mini twin-stick Blaze. Ces derniers devant être équipés de l'équivalent de 2 puces E2 Maple Bus puisqu'il y a deux cordons de liaison avec la DC.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100723172841-gc339-01full.jpg) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100723172841-gc339-01full.jpg)
Le Twin Stick Sega HKT-7500.
(http://www.oratan.com/projects/images/twinstick_pcb_top_low.jpg) (http://www.oratan.com/projects/images/twinstick_pcb_top_high.jpg)
Le circuit imprimé à l'intérieur du Twin Stick, la puce semble bien être aussi une E2 Maple Bus.
( Images issues du site www.oratan.com : http://www.oratan.com/projects/arcstick.html# )
L'idéal serait de disposer d'un de ces Twin Stick, même en panne, le temps de relever le schéma des connections entre la puce et les contacts des deux manches et des boutons. Avis aux amateurs !
serait t'il possible que moyennant une étude du schéma, il soit possible de "transformer" un pad analogique standard en "pseudo stick arcade" aux yeux de la console, ce serait utile dans le cas d'un hack. Je crois savoir que certains jeux réagissent différemment en présence d'un stick. Plus ambitieux, le Twin Stick (très recherché) utilise également le chip (confirmé par une tof du net), voire d'autres periphs officiels (sauf peut etre le volant, du fait des potentiomètres)
C'est le but premier de ce WIP, relever le schéma de la circuiterie autour de la puce E2 Maple Bus dans les manettes HKT-7300 et HKT-7700 et pourquoi pas celle des Twin Stick HKT-7500.
Le deuxième but est d'analyser les protocoles d'échange avec la DC afin de reconstituer un contrôleur simplifié à base de µC.
L'utilisation d'une manette HKT-7700 pour réaliser une pseudo manette arcade type HKT-7300 ou un Twin Stick HKT-7500 me semble matériellement impossible : comment couper des pistes sous la puce pour récupérer les pattes des boutons C et Z par exemple ? Il faut donc la dessouder pour ce faire.
Quitte à devoir dessouder cette puce, autant la ressouder sur un autre circuit imprimé multi-configurable par cavaliers et dont les raccordements avec les contacts externes se feraient par bornier à vis. Ce circuit-imprimé permettrait alors d'utiliser la puce pour faire des manettes arcade à 6 boutons, pour l'intégrer dans une borne en le reliant aux boutons du panel, pour réaliser un Twin Stick sur mesure ... A ce stade, tout est possible, ce pourrait même être le troisième but de ce WIP.
-
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100723123008-gc339-TwinSticks-2.JPG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100723123008-gc339-TwinSticks-2.JPG)
Bien que cette photo soit partiellement oblitérée par les inscriptions en jaune, on peut en tirer quelques renseignements intéressants.
Quel dommage que ces inscriptions n'aient pas été reportées sur les cotés ! Ce serait bien si un lecteur de ce forum possédant ce TwinSticks puisse poster ou m'adresser par email la photo de ce circuit imprimé prise avec la plus grande définition possible, à défaut de pouvoir obtenir un de ces TwinSticks pour retrouver son schéma.
- Le manche de gauche utilise les pattes 48 à 51 de la puce tout comme le manche conventionnel.
- Les boutons LT et LW doivent très probablement correspondre, dans le désordre, aux boutons X et Y et le bouton PAUSE au bouton Z.
- Idem pour les boutons RT et RW avec les boutons A et B, toujours dans le désordre.
- Les contacts du deuxième manche, celui de droite, devraient correspondre aux pattes 37 à 40 qui sont inutilisées dans le cas de la HKT-7300 et dont deux seulement le sont pour des cavaliers avec la HKT-7700.
- La patte du bouton C est inutisée puisque elle est raccordée au +5 volts.
Ce qui confirmerait ce que l'on peut lire sur le site de Marcus Comstedt : http://mc.pp.se/dc/controller.html, la puce E2 Maple Bus supporterait 2 manches digitaux, 2 manches analogiques, 2 gâchettes analogiques ainsi que 8 boutons A, B, C, D, X, Y, Z et START.
Les pattes 37 à 40 seraient donc dédiées à ce deuxième manche digital.
Je suspecte deux pattes parmi les pattes 2, 3 et 4 de pouvoir être celles des entrées de ce deuxième manche analogique, et la patte 41 ou 42 d'être celle du bouton D... A confirmer.
-
évidement, fallait que les connexions qui nous intéressent soient sous le chip. Dommage, cela aurait bien facilité le hack: passage en "HKT-7300" et utilisation des broches c et z
Je vient de constater autre chose de très intéressant: le vibreur est doté d'un chip E2 mapple bus trés similaire à celui contenu dans le pad: 315-6211-AH pour le vibreur et 315-6211-AB pour le pad que j'ai démonté
Pas impossible qe Sega ait opté pour un composant unique pour toute sa gamme de périphériques (sauf le vmu qui utilise un chip tout en un
Bien sur, la quasi totalité des broches du vibreur m'ont l'air d'être reliées à la masse sous le chip (j'ai pas le matos pour dessouder sous la main, ni de vibreur à sacrifier). ca peut toujours constituer une source de chip pas cher (les vibreurs servent pas à grand chose et sont dispo pas cher)
-
Bonjour.
Tout d'abord un grand merci à speedsterharry qui à pu m'obtenir une meilleure photo du circuit imprimé du TwinSticks : http://rapidshare.com/files/408812229/DC_Twin_Stick_PCBs.zip
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100801112106-gc339-DC-Twin-Stick-pcb-hires.jpg) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100801112106-gc339-DC-Twin-Stick-pcb-hires.jpg)
Tout d'abord la puce E2 Maple Bus est référencée différemment : 315-6211-AF au lieu de 315-6125-AB. Cette même puce doit être déclinée en plusieurs versions logicielles en fonction de son utilisation : TwinSticks, clavier, vibreur, manettes. Seul son hardware ainsi que son brochage restent identiques : ports d'E/S logiques et analogiques, broches d'alimentation ...
Je me suis surtout intéressé au raccordement des manches directionnels et des boutons, une rapide vérification ayant permis de constater que toutes les autres pattes de la puce comme celles du port d'extension sont raccordées à l'identique des manettes HKT-7X00.
Les 3 tableaux ci-dessous indiquent le raccordement des pattes de la puce vers les contacts des manches et boutons à travers les connecteurs de liaison. C'est ce que j'ai pu déterminer pour la plupart ou, pour quelques unes, deviner à partir de la photo. Il faudrait avoir réellement un circuit sous la main pour valider définitivement avec un ohmmètre ces quelques connexions entachées d'incertitude.
|
|
|
|
|
|
|
|
| | | Broche | | | Désignation | | | CN3 / RL | | | CN4 / LL | | | | |
| | |
| | |
| | |
| | | | | 1 | | | GND | | | | | | | | | | | 2 | | | UP | | | 37 | | | 48 | | | | | 3 | | | DOWN | | | 38 | | | 49 | | | | | 4 | | | LEFT | | | 39 | | | 50 | | | | | 5 | | | RIGHT | | | 40 | | | 51 | | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | Broche | | | Désignation | | | CN5 / LB | | | CN6 / RB | | | Correspondance | | | | |
| | |
| | |
| | |
| | |
| | | | | 1 | | | GND | | | | | | | | | | | | | | 2 | | | LW | | | 35 | | | | | | Y | | | | | 3 | | | LT | | | 34 | | | | | | Z | | | | |
| | |
| | |
| | |
| | |
| | | | | 1 | | | GND | | | | | | | | | | | | | | 2 | | | RW | | | | | | 45 | | | A | | | | | 3 | | | RT | | | | | | 44 | | | B | | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | Broche | | | Désignation | | | CN7 / S/P | | | Correspondance | | | | |
| | |
| | |
| | |
| | | | | 1 | | | GND | | | | | | | | | | | 2 | | | PAUSE | | | 36 | | | X | | | | | 3 | | | GND | | | | | | | | | | | 4 | | | START | | | 47 | | | START | | |
|
|
|
|
|
|
|
|
|
|
|
|
Tableau de gauche :
- Ce tableau montre les raccordements des pattes de la puce sur les broches des connecteurs CN3 et CN4 respectivement libellés RL et LL sur la sérigraphie.
- Bien que cela soit impossible à valider à partir de la photo, car caché sous l'embase de CN4, j'ai supposé que le fil RIGHT longeait le bord du circuit imprimé avant d'atterrir sur la broche 3 de CN4.
- Le manche de gauche (LL) utilise les pattes 48 à 51 de la puce à l'identique des manettes HKT-7X00.
Tableau central :
- Ce tableau montre les raccordements des pattes de la puce sur les broches des connecteurs CN5 et CN6 respectivement libellés LB et RB sur la sérigraphie.
- J'ai repris les dénominations des boutons données sur les photos provenant du site oratan.com (http://www.oratan.com/projects/images/twinstick_pcb_top_high.jpg) étant donné que je ne connais pas leur localisation physique sur les manches.
- Même remarque que ci-dessus pour le bouton LW, j'ai supposé que le fil longeait le bord du circuit imprimé avant d'atterrir sur la broche 2 de CN5.
- La correspondance des boutons des manches avec ceux des manettes HKT-7X00 est indiquée dans la dernière colonne.
Tableau de droite :
- Ce tableau montre les raccordements des pattes de la puce sur les broches du connecteur CN7 libellé S/P sur la sérigraphie.
- La correspondance des boutons avec ceux des manettes HKT-7X00 est indiquée dans la dernière colonne.
-
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/pics/view_1_s.jpg) http://www.ikalogic.com/scanalogic2/ (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.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100811215254-gc339-DSCF4845.JPG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100811215254-gc339-DSCF4845.JPG)
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.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100811224804-gc339-Fig12bis.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100811224804-gc339-Fig12bis.PNG)
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.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100811231814-gc339-Analyzer1.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100811231814-gc339-Analyzer1.PNG)
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
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100811231901-gc339-Analyzer2.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100811231901-gc339-Analyzer2.PNG)
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.
-
Rhooooo, j'adore ça meuha :D
le mot décorticage "en mode expert" est bien choisi ^-
-
:o
une aspirine! vite ! ^-^
-
Joli travail ! <:)
Ca me rappelle quand j'investiguais le codage infra-rouge du module de réglage des chassis VNS2000 (lien (http://www.gamoover.net/Forums/index.php?topic=17650.msg246703#msg246703)).
-
Bonsoir.
J'ai eu bon nez d'acquérir ce petit bijou de chez IKALOGIC : http://www.ikalogic.com/scanalogic2/
(http://www.ikalogic.com/scanalogic2/pics/view_1_s.jpg) (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 :
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100814224319-gc339-SF.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100814224319-gc339-SF.PNG)
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 :
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100814230127-gc339-MP1.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100814230127-gc339-MP1.PNG)
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) :
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100814235629-gc339-MB1.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100814235629-gc339-MB1.PNG)
- 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.- 1er 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).
- 2em octet = 20H : c'est le n° du destinataire (tableau "Address format"), c'est la manette.
- 3em octet = 00H : c'est le n° de l'expéditeur (tableau "Address format"), c'est la DreamCast.
- 4em 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) :
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100815010841-gc339-MB2.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100815010841-gc339-MB2.PNG)
Décodage de cette trame en cours de rédaction ...
-
plus je lis ce topic, plus je me dis que l'i/o board board naomi pourrait passer sur un grill
équivalent.
-
:10:
-
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 ;D ) à 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? =:))
-
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 ;D ) à 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 8)
-
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) :
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100815010841-gc339-MB2.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100815010841-gc339-MB2.PNG)
- 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.
- 1er 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. - 2em 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é.
- 3em 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.
- 4em octet = 03H : c'est le nombre de blocs (4 octets) de données associées.
- Bloc n° 1, c'est le 1er 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(1), 00H(2), 0FFH(3), 0FFH(4), 80H(1), 80H(2), 80H(3) et 80H(4).
- Il faut tout d'abord réordonner les octets de chaque bloc : 0FFH(4), 0FFH(3), 00H(2), 00H(1), 80H(4), 80H(3), 80H(2) et 80H(1).
- 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.
- 1er 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. - 2em 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 2em 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 2em 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 1er 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 2em 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 2em 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.
-
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.
(http://www.archimedes-lab.org/shadoks/shadock1_s.gif)
| - C'est en forgeant que l'on devient musicien.
(http://www.archimedes-lab.org/shadoks/shamal.gif)
- 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!
(http://www.archimedes-lab.org/shadoks/descar.gif)
|
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".
-
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 ^- ^- ^-
-
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 ...
(http://www.futurlec.com/Pictures/TQFP_64.jpg)
(http://www.davesvideoarcade.co.uk/dreamcast_files/twinstick.jpg) | (http://lifeofacollector.files.wordpress.com/2008/02/hpim0914.jpg) |
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.
-
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...
-
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.
-
Bonjour.
Je me suis décidé à installer un bouton de reset (http://www.kreidler.be/Shinebi/downloads/Dreamcast%20Reset%20button.pdf) 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€.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100820110702-gc339-DC-Clear-Black-Joypad-LRG.small.JPG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100820110702-gc339-DC-Clear-Black-Joypad-LRG.small.JPG)
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.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100820231143-gc339-Fig44.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100820231143-gc339-Fig44.PNG)
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.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100820115342-gc339-Standard250.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100820115342-gc339-Standard250.PNG)
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.
1er échange
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100820123232-gc339-Standard1.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100820123232-gc339-Standard1.PNG)
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"
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100820184736-gc339-Standard3.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100820184736-gc339-Standard3.PNG)
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".
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100820184823-gc339-Standard4.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100820184823-gc339-Standard4.PNG)
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.
-
2) Phase d'initialisation de la manette configurée en mode arcade 6 boutons sans vibreur.
En fait l'enchaînement des trames de cette phase est identique à celui de la manette en configuration standard sans vibreur.
1er échange
Seuls diffèrent les paramètres retransmis dans la deuxième trame, la réponse "Device Status" à la toute première requête "Device Request" effectuée sur la fonction "Controller" du dispositif de base ou "Base Device"
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100822120741-gc339-Arcade2.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100822120741-gc339-Arcade2.PNG)
Le début de la 2èm trame "Device Status" retransmise sur le Maple bus après un reset de la DC.
Device Response *************** Bloc Octets 00 0x1C 0xA0 0x80 0x05 01 0x01 0x00 0x00 0x00 02 0xFF 0x07 0x00 0x00 03 0x00 0x00 0x00 0x00 04 0x00 0x00 0x00 0x00 05 0x72 0x41 0x00 0xFF [Ar] 06 0x65 0x64 0x61 0x63 [cade] 07 0x69 0x74 0x53 0x20 [ Sti] 08 0x20 0x20 0x6B 0x63 [ck ] 09 0x20 0x20 0x20 0x20 [ ] 10 0x20 0x20 0x20 0x20 [ ] 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 0x00 0xAA 0x01 0x2C CS 0xDB
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| Header (AP = Absolute Position) Bloc.Octet 00.1 Command Code = 5 : Device Status 00.2 Destination AP = 10.0.00000 : Port C of Host (DC) 00.3 Source AP = 10.1.00000 : Base Device on Port C 00.4 Data Size = 28
Device ID Bloc.Octet 01 Function(s) Type = 0x00 0x00 00000000b 00000001b : Only Controller Function 02 Function Definition Block 1 = 0x00 0x00 0x07 0xFF : Controller 02.1 11111111b : First joystick, buttons Start, A, B and C used 02.2 00000111b : Only buttons X, Y and Z used 02.3 00000000b : Analogue triggers and joysticks unused 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) = "Arcade Stick " 13.1 License (60 Ascii) = "Produced By Or Under License From SEGA ENTERPRISES,LTD. " 28.1 StandBy current consuption (little endian) = 0x00AA = 170 : 17 mA 28.3 Maximun current consuption (little endian) = 0x012C = 300 : 30 mA
|
Avec cette réponse la DC a obtenu des informations essentielles sur la manette :
- Les zones géographiques avec lesquelles elle est compatible.
- 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.
- Le nom du produit qui diffère de celui de la manette en configuration standard
2èm échange et échanges suivants
La DreamCast interroge périodiquement la manette avec une paire de trames "Get Condition" / "Data Transfer" tout comme celle qui a été décortiquée dans le précédent post avec configuration standard de cette manette.
Avec chaque réponse, la DC obtient l'état instantané des boutons et du manche conventionnel ainsi que les états/positions par défaut des boutons, gâchettes et manches analogiques inexistants.
A l'aide du masque de présence obtenu par l'échange "Device Request"/ "Device Status", qui suit immédiatement le reset, La DreamCast peut oblitérer ou ignorer les états ainsi que les positions par défaut de ceux et de celles dont la manette n'est pas équipée.
Petit aparté avec le Twin Stick
A la lueur de :
- Ce qui a été décortiqué dans les trames "Device Status" retransmises par la manette avec la configuration standard ainsi qu'avec la configuration arcade
- Ce qui a pu être relevé à partir de la photo de la circuiterie interne du Twin Stick : http://www.gamoover.net/Forums/index.php?topic=21932.msg322818#msg322818
On peut imaginer la trame "Device Status" que pourrait retransmettre le Twin Stick :
(http://www.davesvideoarcade.co.uk/dreamcast_files/twinstick.jpg) | | Device ID Bloc.Octet 01 Function(s) Type = 0x00 0x00 00000000b 00000001b : Only Controller Function 02 Function Definition Block 1 = 0x00 0x00 0xF7 0xFE : Controller 02.1 11111110b : 1st joystick, buttons Start, A, B equipped 02.2 11110111b : 2nd joystick, buttons X, Y and Z equipped 02.3 00000000b : Analogue triggers and joysticks not equipped 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) = "Twin Stick " 13.1 License (60 Ascii) = "Produced By Or Under License From SEGA ENTERPRISES,LTD. " 28.1 StandBy current consuption (little endian) = 0x???? 28.3 Maximun current consuption (little endian) = 0x????
|
La seule inconnue, qui pourrait être bloquante, est le "Product Name". Ce nom de produit pourrait être aussi bien "Dreamcast Twin Stick" que "Twin Stick HKT-7500", toutes les options sont permises.
Il n'y a que l'analyse des trames d'un Twin Stick réel qui tranchera.
Reste à savoir si le jeu "Virtual On" vérifie cette information plutôt que d'analyser le masque des états/positions des boutons/manches/gâchettes pour déterminer si un Twin Stick est effectivement connecté à la DC.
-
La seule inconnue, qui pourrait être bloquante, est le "Product Name". Ce nom de produit pourrait être aussi bien "Dreamcast Twin Stick" que "Twin Stick HKT-7500", toutes les options sont permises.
Il n'y a que l'analyse des trames d'un Twin Stick réel qui tranchera.
Une possibilité est de chercher (avec un éditeur hexa) dans le dump des ROM propres à la DC ou à un jeu donné la chaîne de caractères "Twin" ou "Stick".
Avec un peu de chance, la chaîne exacte sera présente en clair en plein milieu du dump.
-
Une possibilité est de chercher (avec un éditeur hexa) dans le dump des ROM propres à la DC ou à un jeu donné la chaîne de caractères "Twin" ou "Stick".
Avec un peu de chance, la chaîne exacte sera présente en clair en plein milieu du dump.
Je pense plutôt que la vérification, si vérification il y a, doit plutôt se faire au niveau du jeu "Virtual On" le seul qui utilise le Twin Stick. Le logiciel de la DC ne doit vérifier que la licence étant donné qu'un accessoire comme le Twin Stick a du être commercialisé bien après la sortie de celle-ci.
Bien sûr, ce n'est que mon avis, peut-être que les faits me contrediront.
-
3) Phases d'initialisation de la manette configurée en standard 4 boutons + gâchettes, vibreur en service.
Suite au reset de la DreamCast, la manette est sollicitée par une trame "Device Request" pour envoyer son status.
Elle répond par une trame "Device Status" à tout point de vue identique à celle de la manette standard sans vibreur, à l'exception près qu'elle indique la présence de dispositifs d'extension ou "Expansion Devices" en positionnant les bits associés dans le champ adresse source du bloc d'entête.
Le bloc "Device ID" reste identique y compris les deux indications de consommation.
Header (AP = Absolute Position)
00.1 Command Code = 5 : Device Status
00.2 Destination AP = 10.0.00000 : Port C of Host (DC)
00.3 Source AP = 10.1.01010 : Base Device on Port C, Expansion Devices n° 2 and n° 4 connected
00.4 Data Size = 28
La DreamCast demande ensuite l'état des boutons/manches/gâchette par une trame "Get Condition" conventionnelle. La manette lui répond par une trame "Data Transfert" tout aussi conventionnelle mais en indiquant à nouveau la présence des deux dispositifs d'extension dans le champ adresse source du bloc d'entête.
Après avoir obtenu cette réponse, la DreamCast émet une nouvelle requête "Device Request" à destination maintenant du premier dispositif d'extension connecté.
DC Request ********** 00 0x00 0x80 0x82 0x01 CS 0x03
| | | | | |
| Header (AP = Absolute Position) 00.1 Command Code = 1 : Device Request 00.2 Destination AP = 10.0.00010 : Expansion Device n° 2 on Port C 00.3 Source AP = 10.0.00000 : Port C of Host (DC) 00.4 Data Size = 0
|
La manette répond aussitôt avec une trame "Device Status" donnant le status de ce 1er dispositif d'extension.
Device Response *************** 00 0x1C 0x82 0x80 0x05 01 0x00 0x01 0x00 0x00 02 0x00 0x00 0x01 0x01 03 0x00 0x00 0x00 0x00 04 0x00 0x00 0x00 0x00 05 0x75 0x50 0x00 0xFF [Pu] 06 0x50 0x20 0x75 0x72 [ru P] 07 0x20 0x75 0x72 0x75 [uru ] 08 0x6B 0x63 0x61 0x50 [Pack] 09 0x20 0x20 0x20 0x20 [ ] 10 0x20 0x20 0x20 0x20 [ ] 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 0x06 0x40 0x00 0xC8 CS 0x67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| Header (AP = Absolute Position) 00.1 Command Code = 5 : Device Status 00.2 Destination AP = 10.0.00000 : Port C of Host (DC) 00.3 Source AP = 10.0.00010 : Expansion Device n° 2 on Port C 00.4 Data Size = 28
Device ID 01 Function Type(s) = 0x00 0x00 00000001b 00000000b : Only Vibration Pack Function 02 Function Definition Block 1 = 0x00 0x00 00000001b 00000001b : Vibration Pack 02.1 00000001b : Unknown usage ! no information about this bit ! 02.2 00000001b : Unknown usage ! no information about this bit ! 02.3 00000000b : ? 02.4 00000000b : ? 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 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) = "Puru Puru Pack " 13.1 License) (60 Ascii) = "Produced By Or Under License From SEGA ENTERPRISES,LTD. " 28.1 StandBy current consuption (little endian) = 0x00C8 = 200 : 20 mA 28.3 Maximun current consuption (little endian) = 0x0640 = 1600 : 160 mA
|
- La manette indique dans le champ adresse source de l'entête que ce sont bien les données associées au dispositif d'extension n°2 qui suivent.
- Dans le bloc "Device ID" il est indiqué que le dispositif n°2 possède une unique fonction : c'est le pack vibreur.
- Le champ "Product Name" du bloc "Fixed Device Data" donne le nom du dispositif : "Puru Puru Pack", c'est celui du pack officiel SEGA DreamCast.
Les consommations spécifiques de ce dispositif sont aussi indiquées en fin de ce même bloc.
Après avoir obtenu cette réponse, la DreamCast émet une seconde requête "Device Request" à destination cette fois ci du deuxième dispositif d'extension connecté.
DC Request ********** 00 0x00 0x80 0x88 0x01 CS 0x09
| | | | | |
| Header (AP = Absolute Position) 00.1 Command Code = 1 : Device Request 00.2 Destination AP = 10.0.01000 : Expansion Device n° 4 on Port C 00.3 Source AP = 10.0.00000 : Port C of Host (DC) 00.4 Data Size = 0
|
Et là, chou blanc, pas de réponse en provenance de la manette.
Le dispositif n°4 n'a rien à déclarer, cet ersatz de manette doit être bogué.
Faudra quand même que je vérifie, sur une manette officielle équipée d'un "Puru Puru Pack" tout aussi officiel, combien de dispositifs d'extension sont effectivement connectés.
Après une péride d'attente, la DC reprend ses interrogations cycliquement pour obtenir l'état des boutons/manches/gâchette avec le duo de trames "Get Condition" / "Data Transfert".
La manette continue à déclarer systématiquement la présence du disposif d'extension n°4 dans l'adresse source de sa réponse.
-
Bon, Scanlogic2 commandé pour moi aussi ^^
Et vu que maintenant je vais avoir beaucoup beaucoup plus de temps pour moi et pour bricoler, je vais essayer de faire avancer la chose si je peux te filer un coup de main gc339...
Je vais aussi voir ce qu'il est possible de créer comme truc à base de chip custom en vue de faire un truc tout propre pour l'upcb...
-
Bon, Scanlogic2 commandé pour moi aussi ^^
Bienvenue parmi les utilisateurs du Scanalogic 2 !
je vais essayer de faire avancer la chose si je peux te filer un coup de main gc339...
Dans l'immédiat je recherche un Twin Stick DreamCast pour décortiquer les trames qu'il échange avec la DreamCast. Si quelqu'un en à un et qu'il peut s'en séparer momentanément ou définitivement ...
Je vais aussi voir ce qu'il est possible de créer comme truc à base de chip custom en vue de faire un truc tout propre pour l'upcb...
J'espère que tu pourras nous exposer, ici sur gamoover, ce projet au fur et à mesure de son avancement.
-
5) Phases d'initialisation du Twin Stick
Encore faudrait-il que j'en ai un à disposition !
-
J'ai acquis un lot comprenant le jeu "House of Dead 2" et un light gun Mad Catz, le tout pour une somme modique. La boite du jeu est cassée mais le light gun est en très bon état externe et il fonctionne.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100824221237-gc339-Rallonge.gif) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100824221237-gc339-Rallonge.gif) | | J'ai aussi acheté une rallonge que je n'ai pas encore reçue.
Mon intention est d'enlever la gaine du câble en son milieu sur une faible longueur pour accéder au 5 fils du Maple bus. Une fois cette rallonge insérée entre l'accessoire et la DC, je pourrais alors raccorder les pinces de l'analyseur Scanalogic 2 sur les fils du bus à travers l'ouverture pratiquée au centre du câble. Ainsi, pour avoir accès aux fils du Maple bus, il ne me sera plus nécessaire de démonter l'accessoire dont je veux décortiquer les échanges.
|
A défaut de rallonge, il a fallu démonter le light-gun pour sortir les fils du Maple bus. L'opération a été bénéfique car elle a permis de se rendre compte que la butée de la gâchette était cassée.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100824232959-gc339-DSCF4870.JPG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100824232959-gc339-DSCF4870.JPG)
Le light gun Mad Catz une fois la butée de gâchette réparée. Il est encore équipé des fils nécessaires à l'observation des signaux sur le Maple bus.
Cette butée, qui limite normalement la course de la gâchette, est réalisée par un axe creux en plastique. Cet axe n'est pas d'un seul tenant, il est constitué de deux demi-axes creux en vis à vis et solidaires chacun d'une coquille du gun.
Rien ne solidarisait les deux demi-axes entre eux quand je l'ai démonté, aussi un des deux était cassé à sa base, au ras de la coquille.
L'évidement à l'intérieur des demi-axes est cylindrique et d'un diamètre un poil supérieur à 3 mm.
Un trou a été percé dans la coquille, celle de la cassure. Une vis à tête fraisée de Ø3 introduite dans ce trou maintient le demi-axe cassé en place, le tout à été encollé à l'araldite pour que l'ensemble soit bien monolithique.
La vis étant presque aussi longue que les deux demi-axes mis bout à bout, son extrémité libre pénètre sans jeu dans l'évidement cylindrique du demi-axe de l'autre coquille et assure ainsi la rigidité de la butée.
4) Phases d'initialisation du Light Gun Mad Catz.
Suite au reset de la DreamCast, le Light Gun est sollicité par une trame "Device Request" pour envoyer son status.
DC Request ********** 00 0x00 0x80 0xA0 0x01 CS 0x21
| | | | | |
| Header (AP = Absolute Position) 00.1 Command Code = 1 : Device Request 00.2 Destination AP = 10.1.0000 : Base Device on Port C 00.3 Source AP = 10.0.00000 : Port C of Host (DC) 00.4 Data Size = 0
|
Le Light Gun Mad Catz répond par une trame "Device Status" ,tout comme les autres accessoires déjà tracés, à l'exception près qu'il indique la présence de deux fonctions pour le dispositif de base : - Une fonction Light Gun.
- Une fonction Controller car le Light Gun possède un bouton Start et un bouton B ainsi qu'un pavé directionnel.
Le bloc "Device ID" comporte donc deux blocs de définition (Function Definition Block), un pour chaque fonction.
Device Response *************** 00 0x1C 0xA0 0x80 0x05 01 0x81 0x00 0x00 0x00 02 0x00 0x00 0x00 0x00 03 0xFE 0x00 0x00 0x00 04 0x00 0x00 0x00 0x00 05 0x72 0x44 0x01 0x01 [Dr] 06 0x63 0x6D 0x61 0x65 [eamc] 07 0x20 0x74 0x73 0x61 [ast ] 08 0x20 0x6E 0x75 0x47 [Gun ] 09 0x20 0x20 0x20 0x20 [ ] 10 0x20 0x20 0x20 0x20 [ ] 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 0x06 0xFA 0x00 0xA0 CS 0x2F
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| Header (AP = Absolute Position) 00.1 Command Code = 5 : Device Status 00.2 Destination AP = 10.0.00000 : Port C of Host (DC) 00.3 Source AP = 10.1.00000 : Base Device on Port C 00.4 Data Size = 28
Device ID 01 Function Type(s) = 0x00 0x00 00000000b 10000001b : Light-Gun + Controller Functions 02 Function Definition Block 1 = 0x00 0x00 0x00 0x00 : Nothing defined for Light-Gun function 03 Function Definition Block 2 = 0x00 0x00 0x00 0xFE : Controller function 03.1 11111110b : First joystick, buttons Start, A and B used 03.2 00000000b : Second joystick, buttons D, X, Y and Z not equipped 03.3 00000000b : Analogue triggers and joysticks not equipped 03.4 00000000b : Unused 04 Function Definition Block 3 = 0x00 0x00 0x00 0x00 : Third function does not exist
Fixed Device Status 05.1 Destination Region = 00000001b : only North America 05.2 Dummy = 0x01 05.3 Produc Name (30 Ascii) = "Dreamcast Gun " 13.1 License (60 Ascii) = "Produced By Or Under License From SEGA ENTERPRISES,LTD. " 28.1 StandBy current consuption (little endian) = 0x00A0 = 160 : 16 mA 28.3 Maximun current consuption (little endian) = 0x00FA = 250 : 25 mA
|
A noter que ce Light Gun Mad Catz n'est compatible que pour l'Amérique du Nord.
Le Light Gun indique donc qu'il supporte deux fonctions en tant que dispositif de base. Comme c'est le bit de rang le plus élevé qui est prioritaire dans le mot "Function Type(s)", c'est donc le bloc de définition du Light Gun qui suit en premier, celui du "Controller" est en second puisqu'il est le moins prioritaire.
- Le bloc du "Controller" fournit comme les fois précédentes le masque de présence des boutons/manches/gâchettes.
- Le bloc "Light Gun" est vide, il ne fournit aucun masque. La raison est que la gâchette du Light Gun ne fonctionne pas comme un bouton standard.
Le light Gun est équipé d'un bloc photoélectrique (lentille, cellule, amplificateur) qui transforme l'impulsion lumineuse reçue en signal électrique, ce dernier n'étant validé que quand la gâchette est appuyée.
Le bloc photoélectrique ne reçoit cette impulsion lumineuse que quand le spot du balayage écran illumine la surface vers laquelle le Light Gun est pointé.
Le balayage écran étant très rapide, il faut que la réponse du Light Gun vers la DreamCast soit immédiate quand le spot est focalisé sur la cellule à travers la lentille, c'est pourquoi une trame spécifique est utilisée pour cet accessoire : La trame "SDCKB Occupancy Permission".
Petit aparté : La trame "SDCKB Occupancy Permission"
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100825202708-gc339-SDCKB-Occ-Perm.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100825202708-gc339-SDCKB-Occ-Perm.PNG)
Il n'y a que la DreamCast elle même qui puisse générer cette trame, elle débute par un fanion constitué de 8 fronts descendants sur SDCKB pendant que SDCKA est maintenu à un niveau bas.
En fin de fanion, SDCKA retourne à l'état haut. Puis il repasse à nouveau à l'état bas pour indiquer que les rôles sont inversés sur SDCKB : pendant toute cette période de palier à l'état bas sur SDCKA, c'est le dispositif de base qui est émetteur sur SDCKB et la dreamcast qui est réceptrice sur ce même fil.
La DreamCast signale qu'elle reprend la main sur SDCKB quand le palier est terminé, c'est à dire quand elle repositionne SDCKA au niveau haut.
Il n'y a pas de fanion "End", la trame se termine avec la fin du palier bas sur SDCKA.
En fait cette inversion des rôles sur SDCKB ne se fait pas n'importe quand, elle est synchronisée avec le balayage de l'écran.
- Le début du palier bas sur SDCKA est synchrone avec le départ de la trame vidéo, le spot quitte alors le coin gauche en haut d'écran
- Le palier bas s'achève avec la fin de la trame vidéo, c'est à dire quand le spot est arrivé dans le coin droit en bas d'écran.
- Pendant ce palier bas sur SDCKA, le Light Gun prend le contrôle de SDCKB pendant que la DreamCast se met en observation sur ce même fil.
Le Light Gun peut donc retransmettre en temps réel sur SDCKB l'impulsion crée par le passage du spot devant son optique.
A la DreamCast de déterminer la position du spot sur l'écran au moment où elle reçoit cette impulsion sur SDCKB.
Pendant tout ce temps, le Maple bus est monopolisé et est indisponible pour tout autre échange, il ne le redevient que pendant les temps de retour trame.
- La trame "SDCKB Occupancy Permission" ne comporte pas de paramètre ni d'adressage à sa suite, cette trame ne peut donc s'adresser qu'au dispositif de base présent, en l'occurrence le seul Light Gun connecté sur le port.
- Ces trames ne circulent pas en permanence sur le Maple bus, elles ne sont activées qu'à des moments bien déterminés d'un jeu, au moment où des cibles apparaissent sur l'écran.
Aussi pour l'instant, bien que je les voie passer sur l'oscilloscope, je n'arrive pas à capturer le début ou la fin d'une de ces trames avec l'analyseur Scanalogic. Il faut dire que le palier bas sur SDCKA dure presque 20 ms avec un écran à 15 kHz, ce qui est beaucoup plus que la période de capture de l'analyseur quand l'échantillonnage est effectué à 10 Mhz.
Après avoir reçu le status du Light Gun, la DreamCast se met à requérir cycliquement l'état de son pavé directionnel ainsi que de ses boutons tout comme elle le fait avec une manette ordinaire :
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 Host (DC) 00.4 Data Size = 1
01 Function Type(s) = 0x00 0x00 00000000b 00000001b : Only Controller Function
|
Device Response *************** 00 0x03 0xA0 0x80 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 = 10.0.00000 : Port C of Host (DC) 00.3 Source AP = 10.1.00000 : Base Device on Port C 00.4 Data Size = 3
Data 01 Function Type(s) = 0x00 0x00 00000000b 00000001b : Only Controller Function
02 Function Data : 11111111b 11111111b 0x00 0x00 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 03.2 0x80 0x80 : X, Y, second Joystick
|
-
Très intéressant, ce décortiquage des échanges avec le light-gun ! ^-^
Ma compréhension est qu'en échange d'une grosse (mais temporaire) perte de bande-passante sur le bus (le bus étant occupé pendant toute la durée d'affichage de l'image, et donc libre seulement durant le retour trame), l'électronique du light-gun est simplifiée.
La DC sait très facilement se synchroniser avec le balayage trame.
Lorsqu'une cible est visible, elle active ce que j'appelle le mode "acquisition du spot" du light gun.
Le capteur envoie un "top" milli-poilesque au moment où il voit passer le spot du tube cathodique (pour info, sur ma borne Operation Wolf, je n'ai jamais pu avoir la certitude d'avoir observé ce top avec mon oscillo, il était vraiment noyé dans du bruit. Par contre je l'ai bien vu en aval des étages d'amplification)
Le light gun n'a qu'a amplifier / filtrer ce que mesure le capteur optique.
En mesurant le temps entre le début du mode "acquisition du spot" et le top envoyé par le light-gun, la DC sait quel était le point visé par le gun.
D'un point de vue logiciel / matériel, c'est souvent extrêmement simple de faire ça.
Par exemple, sur Atari ST, le processeur vidéo (appelé "SHIFTER") dispose d'un registre hardware mis à jour en temps réel qui indique en permanance quelle est l'adresse du pixel (dans la RAM vidéo) que le spot est en train d'afficher.
Ainsi, dès que le light-gun envoie son top, il suffit juste de lire ce registre hardware et l'on sait directement quel pixel de l'image est visé par le joueur !
-
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.
Bon, j'ai eu le temps de me pencher un peu plus sur les micro contrôleurs capables de tourner à une vitesse suffisante et il n'y en a pas tant que ça... Chez Microchip, en 8-bits, rien n'est capable de tourner à plus de 16 MiPS... Donc super dur d'implémenter le truc ^^
En allant voir d'autres solutions (le SX28 comme tu disais par exemple gc339), j'en ai pas trouvé beaucoup... Le SX28 parait etre pas mal, mais me remettre à l'assembleur pour coder ce genre de chose me fait un peu peur :? :? Et en plus, j'ai les platines de développement pour les PIC, va falloir réinvestir pour les SX...
Bref, c'est pas gagné... Fait chier à causer aussi vite cette console >:D >:D
-
Et en plus, j'ai les platines de développement pour les PIC, va falloir réinvestir pour les SX...
Si tes platines de développement sont compatibles avec les PIC de la famille 16C5x®, tu pourras peut être y installer un SX20 ou SX28.
A l'origine les µC SX de Scenix/Parallax/Ubicom ont été conçus pour qu'ils soient compatibles broche à broche avec les PIC de la famille famille 16C5x®, et aussi pour que leur jeu d'instructions soit compatible vers le haut.
Cette information figure dans la version 1.0 du document "Scenix SX18AC/SX20AC/SX28AC user's manual" de 1998, elle a disparu dans les nouvelles versions de ce manuel, probablement à cause des actions en justice intentées par Microchip. On retrouve cependant cette information sur le net.
En allant voir d'autres solutions (le SX28 comme tu disais par exemple gc339), j'en ai pas trouvé beaucoup... Le SX28 parait être pas mal, mais me remettre à l'assembleur pour coder ce genre de chose me fait un peu peur :? :? Et en plus, j'ai les platines de développement pour les PIC, va falloir réinvestir pour les SX...
De toutes façons tu n'auras pas le choix pour désérialiser les données à recevoir. Une fois récupérées sous forme d'octets, de mots de 16 ou 32 bits, les timings sont moins critiques.
Par contre la DC peut s'accommoder d'une vitesse de réception plus basse, il doit alors être possible d'écrire la routine d'émission en C ou autre.
Sinon l'investissement est minime :
- Le logiciel de développement est en téléchargement gratuit : http://www.parallax.com/tabid/460/Default.aspx
- Il y a juste besoin des produits suivants :
(http://www.parallax.com/Portals/0/Images/Prod/4/453/45302-M.jpg) SX28 Proto Board : $4,99 (http://www.parallax.com/Store/Microcontrollers/SXProducts/tabid/138/CategoryID/15/List/0/SortField/0/Level/a/ProductID/399/Default.aspx)
| (http://www.parallax.com/Portals/0/Images/Prod/4/452/45214-M.jpg) SX-Key (USB) : $49,99 (http://www.parallax.com/Store/Microcontrollers/SXProducts/tabid/138/CategoryID/15/List/0/SortField/0/Level/a/ProductID/494/Default.aspx)
|
L'accessoire le plus important est la SX-Key car connectée sur un port USB de PC elle permet de :
- Générer l'horloge pour le µC SXxx (entre 2,75 MHz et 100 Mhz)
- Programmer le µC en place avec le logiciel Sx-Key programming tool.
- Déboguer au niveau source avec le µC en place.
-
c'est le wip de l'année après la galaxy force DX là ! :-* ^-^
-
Ce topic de fou !!!
J'ai lu sans savoir quoi comprendre :D
Bon courage ^-
-
Bonjour.
Bien, j'ai reçu ma rallonge hier Vendredi.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100824221237-gc339-Rallonge.gif) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100824221237-gc339-Rallonge.gif)
Après avoir cogité pour trouver comment ressortir proprement les fils du Maple bus au milieu de la rallonge, j'ai décidé d'utiliser un capot de connecteur SubD15 avec une barrette de jonction mâle/mâle. Les rebords de la barrette s'insèrent presque dans les rainures qui maintiennent normalement le connecteur subD. Il faut juste fraiser un poil la lèvre de chaque coquille pour que le maintient soit parfait.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100828190411-gc339-DSCF4906.JPG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100828190411-gc339-DSCF4906.JPG)
Une des coquilles en cours de fraisage sur la petite fraiseuse Proxxon.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100828190740-gc339-DSCF4914.JPG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100828190740-gc339-DSCF4914.JPG)
Le capot de connecteur SubD15 ouvert, la barrette de jonction, la rallonge dénudée en son milieu et fixée sur une des coquilles.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100828191527-gc339-DSCF4932.JPG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100828191527-gc339-DSCF4932.JPG)
La modification de la rallonge une fois terminée.
Après avoir vissé les deux coquilles du capot, j'ai dénudé, sur un bon centimètre, les fils d'une alimentation ATX rebutée pour récupérer des morceaux de gaine. J'ai inséré ces morceaux de gaine par dessus les broches de la barrette en respectant le code des couleurs DreamCast.
La 6em broche de la barette est celle du blindage du câble, ce blindage est connecté au 0 volt au niveau du connecteur de l'accessoire, il doit en être de même au niveau du connecteur du port de la DC.
Couleur | | N° | | Nom du fil |
|
|
|
Rouge | | 1 | | SDCKA. |
Bleu | | 2 | | +5 Volts. |
Noir | | 3 | | GND ou 0 Volt. |
Vert | | 4 | | Présence accessoire, connecté au 0 volt à l'intérieur de l'accessoire. |
Blanc | | 5 | | SDCKB. |
| | 6 | | Blindage du câble, connecté au 0 volt. |
|
|
|
Les broches 2 et 4 ne sont pas utiles pour la capture des traces et sont par conséquent protégées contre tout court circuit accidentel par recouvrement total du manchon coloré, alors que les autres ne le sont qu'à moitié afin de pouvoir les agripper avec les pinces de l'analyseur Scanalogic.
Avec cette rallonge ainsi modifiée, plus besoin d'ouvrir l'accessoire dont on veut capturer les trames, il suffit d'accrocher les pinces de l'analyseur Scanalogic sur les broches du connecteur central de cette rallonge.
Je vais enfin pouvoir retirer les fils d'accès au Maple bus que j'avais soudés à l'intérieur du Loght Gun Mad Catz !
-
Trames échangée avec une manette standard suite à une réinitialisation de la DreamCast.
La console vient d'être juste réinitialisée avec le bouton de reset, elle sonde ses ports pour savoir s'il y a des accessoires de connectés.
Voici les trames échangées avec une manette standard connectée sur le port B.
Cette manette est équipée :
- D'un VMU dans le logement n° 1.
- D'un pack vibreur dans le logement n° 2.
1er échange : la DreamCast interroge le Maple bus du port B
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100902233204-gc339-Echange1.1.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100902233204-gc339-Echange1.1.png)
La toute première requête : la DreamCast recherche un dispositif de base sur le Maple bus du port B(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100902233248-gc339-Echange1.2.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100902233248-gc339-Echange1.2.png)
La réponse de la manette. Celle ci indique, dans le champ "adresse source" de son message, la présence de 2 dispositifs d'extension.A noter que maintenant le logiciel du Scanalogic 2 sait décrypter les entêtes (le bloc 0) des trames du Maple bus.- Le logiciel sait aussi décrypter le bloc 1 quand les informations qu'il contient sont des types de fonctions.
- Pour tous les autres blocs, il affiche les 4 octets dans le bon ordre en hexadécimal.
Il suffit d'amener le pointeur de la souris au voisinage ou au-dessus du bloc choisi, le détail s'affiche alors dans la fenêtre texte de gauche. |
|
|
|
DC Request ********** Bloc Octets 00 0x00 0x40 0x60 0x01 CS 0x21
| | | | | | |
| Header Bloc.Octet 00.1 Command Code = 1 : Device Request 00.2 Destination = 01.1.00000 : Base Device on Port B 00.3 Source = 01.0.00000 : Port B of DC Host 00.4 Data Size = 0
|
| | |
|
Device Response *************** Bloc Octets 00 0x1C 0x63 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 0x1A
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| Header Bloc.Octet 00.1 Command Code = 5 : Device Status 00.2 Destination = 01.0.00000 : Port B of DC Host 00.3 Source = 01.1.00011 : Base Device on Port B Source = 01.1.00011 : Expansion Devices 1 and 2 connected 00.4 Data Size = 28
Device ID Bloc.Octet 01 Function Type(s) = 0x00 0x00 0x00 00000001b : Only one Function "Controller" 02 Definition Block 1 = 0x00 0x0F 0x06 0xFF : Equipment bitmask for the 1st Function 02.1 11111110b : First joystick, buttons Start, A and B eqquiped 02.2 00000110b : Only buttons X and Y eqquiped 02.3 00001111b : Both triggers and first analogue joystick eqquiped 02.4 00000000b : Unused 03 Definition Block 2 = 0x00 0x00 0x00 0x00 : 2nd function does not exist 04 Definition Block 3 = 0x00 0x00 0x00 0x00 : 3rd function does not exist
Fixed Device Status Bloc.Octet 05.1 Destination Region = 11111111b : Areas 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 :
- Ses deux logements sont occupés par des accessoires (Expansion Devices).
- Les zones géographiques avec lesquelles elle est compatible. En fait toutes puisque tous les bits sont à 1.
- Le masque de présence (Definition Block 1), elle sait alors quels sont les boutons, les manches et les gâchettes qui l'équipent.
2èm échange : la DreamCast interroge la fonction "Controller" de la manette.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100903000540-gc339-Echange2.1.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100903000540-gc339-Echange2.1.png)
La deuxième requête de la DreamCast, elle demande les états ou les positions des boutons, manches et gâchettes de la manette.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100903000655-gc339-Echange2.2.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100903000655-gc339-Echange2.2.png)
La réponse de la manette, celle ci indique toujours, dans le champ "adresse source" de son message, la présence de 2 dispositifs d'extension.
|
|
|
DC Request ********** 00 0x01 0x40 0x60 0x09 01 0x01 0x00 0x00 0x00 CS 0x29
| | | | | | | | |
| Header 00.1 Command Code = 9 : Get Condition 00.2 Destination = 01.1.00000 : Base Device on Port B 00.3 Source = 01.0.00000 : Port B of DC Host 00.4 Data Size = 1
Parameter 01 Function Type(s) = 0x00 0x00 0x00 00000001b : Target is Function "Controller"
|
| | |
|
Device Response *************** 00 0x03 0x63 0x40 0x08 01 0x01 0x00 0x00 0x00 02 0000 0000 0xFF 0xFF 03 0x80 0x80 0x80 0x80 CS 0x2A
| | | | | | | | | | | | | | | | | | | | | |
| Header 00.1 Command Code = 8 : Data Transfer 00.2 Destination = 01.0.00000 : Port B of Host (DC) 00.3 Source = 01.1.00011 : Base Device on Port B Source = 01.1.00011 : Expansion Devices 1 and 2 connected 00.4 Data Size = 3
01 Function Type(s) = 0x00 0x00 0x00 00000001b : Response from Function "Controller"
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 dernière réponse, la DreamCast vient d'obtenir de la puce E2 Maple bus à l'intérieur de la manette :
- L'état instantané des boutons et du manche conventionnel.
- Les positions actuelles des gâchettes et du manche analogique.
- L'état/position par défaut des boutons/manches non équipés.
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 lors de l'échange précédent.
A l'aide de ce masque de présence, 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.
3èm échange : la DreamCast interroge l'accessoire inséré dans le logement n°1 de la manette, c'est le VMU.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100903002007-gc339-Echange3.1.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100903002007-gc339-Echange3.1.png)
Troisième requête de la DreamCast, elle adresse le dispositif d'extension n° 1 (le VMU) pour obtenir ses caractéristiques.(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100903002242-gc339-Echange3.2.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100903002242-gc339-Echange3.2.png)
La réponse du VMU, à noter que :- Les accessoires officiels SEGA retransmettent sur le Maple bus par rafales de 4 blocs.
Tous les clones testés jusqu'à maintenant retransmettaient en continu. - Le VMU indique qu'il supporte 3 fonctions : le timer ou horloge, l'affichage LCD ainsi que de la mémoire de stockage.
|
|
|
|
DC Request ********** Bloc Octets 00 0x00 0x40 0x41 0x01 CS 0x00
| | | | | | |
| Header Bloc.Octet 00.1 Command Code = 1 : Device Request 00.2 Destination = 01.0.00001 : Expansion Device 1 on Port B 00.3 Source = 01.0.00000 : Port B of DC Host 00.4 Data Size = 0
|
| | |
|
Device Response *************** Bloc Octets 00 0x1C 0x41 0x40 0x05 01 0x0E 0x00 0x00 0x00 02 0x40 0x3F 0x7E 0x7E 03 0x00 0x10 0x05 0x00 04 0x00 0x41 0x0F 0x00 05 0x69 0x56 0x00 0xFF [Vi] 06 0x6C 0x61 0x75 0x73 [sual] 07 0x6D 0x65 0x4D 0x20 [ Mem] 08 0x6F 0x72 0x79 0x20 [ory ] 09 0x20 0x20 0x20 0x20 [ ] 10 0x20 0x20 0x20 0x20 [ ] 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 0x00 0x82 0x00 0x7C CS 0x13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| Header Bloc.Octet 00.1 Command Code = 5 : Device Status 00.2 Destination = 01.0.00000 : Port B of DC Host 00.3 Source = 01.0.00001 : Expansion Device 1 on Port B 00.4 Data Size = 28
Device ID Bloc.Octet 01 Function Type(s) = 0x00 0x00 0x00 00001110b : 3 functions, Timer, LCD display and Storage 02 Definition Block 1 = 0x7E 0x7E 0x3F 0x40 : 1st Function, Timer 02.1 0x7E : no information available about these 4 bytes ! 02.2 0x7E : ? 02.3 0x3F : ? 02.4 0x40 : ? 03 Definition Block 2 = 0x00 0x05 0x10 0x00 : 2nd function, LCD display 03.1 0x00 : 1 LCD 03.2 0x05 : 192 bytes per block ((5 + 1) × 32) 03.3 0x10 : 1 access for writing a block 03.4 0x00 : Bit 7 = String of LCD data is horizontal, Bit 6 = Normally black, others reserved 04 Definition Block 3 = 0x00 0x0F 0x41 0x00 : 3rd function, Storage 04.1 0x00 : 1 partition 04.2 0x0F : 512 bytes per block ((15 + 1) × 32) 04.3 0x41 : 4 accesses for writing a block, 1 access for reading a block 04.4 0x00 : Bit 7 = Fixed media, others reserved
Fixed Device Status Bloc.Octet 05.1 Destination Region = 11111111b : Areas 4, 3, 2, 1, Europe, Asia, Japon, North America 05.2 Dummy = 0 05.3 Produc Name (30 Ascii) = "Visual Memory " 13.1 License (60 Ascii) = "Produced By Or Under License From SEGA ENTERPRISES,LTD. " 28.1 StandBy current consuption (little endian) = 0x007C = 124 : 12,4 mA 28.3 Maximun current consuption (little endian) = 0x0082 = 130 : 13 mA
|
Avec cette réponse la DC sait maintenant que c'est un VMU qui occupe le logement n° 1 de la manette.
- Les zones géographiques avec lesquelles il est compatible. En fait toutes puisque tous les bits sont à 1.
- Qu'il supporte 3 fonctions maximum permises : Timer, LCD et Storage.
Impossible de détailler ici le bloc de définition du Timer car il n'est pas documenté dans le "pdf" de la patente.
4èm échange : la DreamCast interroge l'accessoire inséré dans le logement n°2, c'est le vibreur.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100903004439-gc339-Echange4.1.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100903004439-gc339-Echange4.1.png)
Quatrième requête de la DreamCast, elle adresse le dispositif d'extension n° 2 (le boîtier vibreur) pour obtenir ses caractéristiques.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100903004525-gc339-Echange4.2.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100903004525-gc339-Echange4.2.png)
La réponse du boîtier vibreur, il indique qu'il ne supporte que la fonction vibreur.
|
|
|
DC Request ********** Bloc Octets 00 0x00 0x40 0x42 0x01 CS 0x03
| | | | | | |
| Header Bloc.Octet 00.1 Command Code = 1 : Device Request 00.2 Destination = 01.0.00010 : Expansion Device 2 on Port B 00.3 Source = 01.0.00000 : Port B of DC Host 00.4 Data Size = 0
|
| | |
|
Device Response *************** 00 0x1C 0x42 0x40 0x05 01 0x00 0x01 0x00 0x00 02 0x00 0x00 0x01 0x01 03 0x00 0x00 0x00 0x00 04 0x00 0x00 0x00 0x00 05 0x75 0x50 0x00 0xFF [Pu] 06 0x50 0x20 0x75 0x72 [ru P] 07 0x20 0x75 0x72 0x75 [uru ] 08 0x6B 0x63 0x61 0x50 [Pack] 09 0x20 0x20 0x20 0x20 [ ] 10 0x20 0x20 0x20 0x20 [ ] 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 0x06 0x40 0x00 0xC8 CS 0x67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| Header 00.1 Command Code = 5 : Device Status 00.2 Destination AP = 01.0.00000 : Port C of Host (DC) 00.3 Source AP = 01.0.00010 : Expansion Device n° 2 on Port C 00.4 Data Size = 28
Device ID 01 Function Type(s) = 0x00 0x00 00000001b 0x00b : Only Vibration Pack Function 02 Function Definition Block 1 = 0x00 0x00 00000001b 00000001b : Vibration Pack 02.1 00000001b : ? no information available about this bit ! 02.2 00000001b : ? no information available about this bit ! 02.3 00000000b : ? 02.4 00000000b : ? 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 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) = "Puru Puru Pack " 13.1 License) (60 Ascii) = "Produced By Or Under License From SEGA ENTERPRISES,LTD. " 28.1 StandBy current consuption (little endian) = 0x00C8 = 200 : 20 mA 28.3 Maximun current consuption (little endian) = 0x0640 = 1600 : 160 mA
|
Avec cette réponse la DC sait maintenant que c'est un pack vibreur qui occupe le logement n° 2 de la manette.
- Les zones géographiques avec lesquelles ce vibreur est compatible. En fait toutes puisque tous les bits sont à 1.
- Qu'il ne supporte que la fonction "Vibrator Pack" dont il est impossible de détailler ici le bloc de définition car il n'est pas documenté dans le "pdf" de la patente.
- Que son nom de produit est "Puru Puru Pack", nom beaucoup moins évocateur que celui de "Vibrator Pack".
5èm échange et suivants.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100903005934-gc339-Echange5.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100903005934-gc339-Echange5.png)
La DreamCast interroge cycliquement la manette, la périodicité est de l'ordre de 16 à 17 ms.
La DreamCast se met à scruter périodiquement la manette pour obtenir :
- L'état des boutons ainsi que celui du manche conventionnel.
- La position des gâchettes ainsi que celle du manche analogique.
Les échanges sur le Maple bus sont en tous points identiques au deuxième échange déjà commenté.
-
Je viens de récupérer un Twin Stick, je l'ai aussitôt raccordé sur l'analyseur Scanlogic pour analyser les trames échangées avec la DreamCast.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100903110929-gc339-DSCF4957.JPG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100903110929-gc339-DSCF4957.JPG)
A noter que j'ai raccourci ma rallonge, le câble utilisé étant de piètre qualité, il déformait trop les signaux en les arrondissant à mon goût.
1er échange : la DreamCast interroge le Twin Stick raccordé sur le port B
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100903111724-gc339-Trame2.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100903111724-gc339-Trame2.png)
La réponse du Twin Stick, avec l'affichage du masque de présence des boutons, des manches et des gâchettes du bloc 2 dans la fenêtre texte de gauche. A noter que le Twin Stick retransmet lui aussi par salves de 4 blocs. |
|
|
|
DC Request ********** Bloc Octets 00 0x00 0x40 0x60 0x01 CS 0x21
| | | | | | |
| Header Bloc.Octet 00.1 Command Code = 1 : Device Request 00.2 Destination = 01.1.00000 : Base Device on Port B 00.3 Source = 01.0.00000 : Port B of DC Host 00.4 Data Size = 0
|
| | |
|
Device Response *************** Bloc Octets 00 0x1C 0x60 0x40 0x05 01 0x01 0x00 0x00 0x00 02 0xFE 0xFE 0x00 0x00 03 0x00 0x00 0x00 0x00 04 0x00 0x00 0x00 0x00 05 0x77 0x54 0x00 0xFF [Tw] 06 0x53 0x2D 0x6E 0x69 [in-S] 07 0x6B 0x63 0x69 0x74 [tick] 08 0x20 0x20 0x20 0x20 [ ] 09 0x20 0x20 0x20 0x20 [ ] 10 0x20 0x20 0x20 0x20 [ ] 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 0x2C 0x00 0xDC CS 0x4C
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| Header Bloc.Octet 00.1 Command Code = 5 : Device Status 00.2 Destination = 01.0.00000 : Port B of DC Host 00.3 Source = 01.1.00011 : Base Device on Port B Source = 01.1.00011 : Expansion Devices 1 and 2 connected 00.4 Data Size = 28
Device ID Bloc.Octet 01 Function Type(s) = 0x00 0x00 0x00 00000001b : Only one Function "Controller" 02 Definition Block 1 = 0x00 0x00 0xFE 0xFE : Equipment bitmask for the 1st Function 02.1 11111110b : First joystick, buttons Start, A and B eqquiped 02.2 11111110b : Second joystick, buttons D, X and Y eqquiped 02.3 00000000b : No trigger, no analogue joystick 02.4 00000000b : Unused 03 Definition Block 2 = 0x00 0x00 0x00 0x00 : 2nd function does not exist 04 Definition Block 3 = 0x00 0x00 0x00 0x00 : 3rd function does not exist
Fixed Device Status Bloc.Octet 05.1 Destination Region = 11111111b : Areas 4, 3, 2, 1, Europe, Asia, Japon, North America 05.2 Dummy = 0 05.3 Produc Name (30 Ascii) = "Twin-Stick " 13.1 License (60 Ascii) = "Produced By Or Under License From SEGA ENTERPRISES,LTD. " 28.1 StandBy current consuption (little endian) = 0x00DC = 220 : 22 mA 28.3 Maximun current consuption (little endian) = 0x012C = 300 : 30 mA
|
Avec cette réponse la DC a obtenu des informations essentielles sur le Twin Stick
- Son nom de produit : "Twin-Stick".
- Les zones géographiques avec lesquelles il est compatible. En fait toutes puisque tous les bits sont à 1.
- Le masque de présence (Definition Block 1), elle sait alors quels sont les boutons, les manches et les gâchettes qui l'équipent.
Bon maintenant, voyons voir à quoi correspondent les boutons du Twin Stick par rapport à une manette Standard.
Le bouton Start : |
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100903113625-gc339-Start.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100903113625-gc339-Start.png)
|
Bloc 2, Bit 3 du 1er octet = 0, le bouton Start du Twin Stick correspond bien au bouton Start de la manette standard.
|
Le bouton Pause : |
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100903115027-gc339-Pause.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100903115027-gc339-Pause.png)
|
Bloc 2, Bit 3 du 2èm octet = 0, le bouton Pause du Twin Stick correspond au bouton "D" qui n'existe sur aucune autre manette.
|
Le bouton supérieur du manche de gauche : |
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100903120249-gc339-BoutonMancheGauche.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100903120249-gc339-BoutonMancheGauche.png)
|
Bloc 2, Bit 1 du 2èm octet = 0, le bouton supérieur du manche de gauche correspond au bouton "Y".
|
La gâchette du manche de gauche : |
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100903121354-gc339-GachetteMancheGauche.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100903121354-gc339-GachetteMancheGauche.png)
|
Bloc 2, Bit 2 du 2èm octet = 0, la gâchette du manche de gauche correspond au bouton "X".
|
Manche gauche incliné à gauche : |
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100903121908-gc339-GaucheMancheGauche.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100903121908-gc339-GaucheMancheGauche.png)
|
Bloc 2, Bit 2 du quartet supérieur du 1er octet = 0, Le manche de gauche correspond au manche conventionnel de la manette standard.
|
Le bouton supérieur du manche de droite : |
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100903122934-gc339-BoutonMancheDroit.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100903122934-gc339-BoutonMancheDroit.png)
|
Bloc 2, Bit 1 du 1er octet = 0, le bouton supérieur du manche de droite correspond au bouton "B".
|
La gâchette du manche de droite : |
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100903123014-gc339-GachetteMancheDroit.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100903123014-gc339-GachetteMancheDroit.png)
|
Bloc 2, Bit 2 du 1er octet = 0, la gâchette du manche de droite correspond au bouton "A".
|
Manche droit incliné à droite : |
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100903123051-gc339-DroiteMancheDroit.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100903123051-gc339-DroiteMancheDroit.png)
|
Bloc 2, Bit 3 du quartet supérieur du 2èm octet = 0, Ce manche correspond au 2èm manche conventionnel prévu sur la puce E2 Maple bus.
|
Ben, c'est tout de même mieux que ce que j'avais pu déduire des différentes photos de l'électronique du Twin Stick : http://www.gamoover.net/Forums/index.php?topic=21932.msg322818#msg322818.
Et toutes ces informations obtenues sans ouvrir le Twin Stick, avoir un analyseur comme le Scanalogic 2 c'est vraiement le pied !
Bon, va falloir que je renomme ce WIP en : [WIP] Décorticage manettes HKT 7300 / HKT 7500 / HKT 7700 DreamCast
-
Super allure ce twin stick ^-^
La boucle serait-elle bouclée =?=
Très chouette topic plaqué Or ^-^ les experts dans le domaine doivent se gaver :D
Il lui faut une place de choix sur Gamo non ??
<:) <:)
-
c'est marrant comme sega a compliqué les signaux sur les TS alors qu'ils auraient pu faire une config simple genre:
-stick gauche = croix directionnelle
-stick droit = YAXB
-fire L = analogique L
-fire R = analogique R
start = start.
mais en même temps les 2 sticks du TS sont analogiques non ? =?= ce qui modifie forcément le cahier des charges. :D
en tout cas quel pied ce topic :-*
tu nous fais une analyse de la canne à pêche dreamcast ? :-*
-
mais en même temps les 2 sticks du TS sont analogiques non ? ce qui modifie forcément le cahier des charges.
Eh bien non ! On entend le doux cliquetis des micro-switches quand on incline les manches de part et d'autre.
tu nous fais une analyse de la canne à pêche dreamcast ? :-*
Pas de problème, prêtes moi la tienne pour une journée. Juste le temps de raccorder l'analyseur Scanalogic par l'intermédiaire de ma rallonge de test Home Made et de faire des copies d'écran !
-
j'aurai bien aimé, mais c'est un des rares accessoires DC que je n'ai hélas pas :-[
j'ai de la maracass par contre ou bien le micro pour seaman :-* :D 8)
-
Si ca peut aider j'ai ca comme matos (vu que le sujet m'interesse aussi :P) :
- Canne a peche japonaise
- Flingue Madcatz
- Flingue Euro
- Clavier (je dois avoir un americain, un francais et un japonais. C'est marrant on dirais le debut d'une blague pourrie :P)
- Manette euro et jap (mais c'est les meme il me semble).
Je sais que les flingues officiels ne sont pas les memes selon les region car mon Confidential Mission US ne marche pas avec mon flingue euro (officiel) mais que avec mon Madcatz. De memoire il me dis que le peripherique n'est pas compatible.
Fera tu un recap sur une page web avec les differentes captures pour chaque peripherique ?
-
Je sais que les flingues officiels ne sont pas les memes selon les region car mon Confidential Mission US ne marche pas avec mon flingue euro (officiel) mais que avec mon Madcatz. De memoire il me dis que le peripherique n'est pas compatible.
Justement, je sais qu'on n'en est pas encore là, mais si/quand le moment sera venu de faire des produits dérivés issus de ce topic (reproduire une PCB DC, voire en faire une version évoluée), il faudra absolument prévoir une facon de dézonner/zoner sélectivement le périphérique (par cavaliers ? ou autre). Marre de tous ces attrape-gogos anti-users :-((
-
Si ca peut aider j'ai ca comme matos (vu que le sujet m'interesse aussi :P) :
- Canne a peche japonaise
- Flingue Madcatz
- Flingue Euro
- Clavier (je dois avoir un americain, un francais et un japonais. C'est marrant on dirais le debut d'une blague pourrie :P)
- Manette euro et jap (mais c'est les meme il me semble).
Dommage que tu ne sois pas lyonnais voir rhône-alpin, tu aurais pu venir faire un tour à la maison avec tous les accessoires dont je ne dispose pas.
Je sais que les flingues officiels ne sont pas les memes selon les region car mon Confidential Mission US ne marche pas avec mon flingue euro (officiel) mais que avec mon Madcatz. De memoire il me dis que le peripherique n'est pas compatible.
Le Light Gun Mad Catz dont j'ai détaillé les trames n'est compatible qu'avec l'Amérique du Nord (octet 1 du bloc 5 de la trame "Device Status" en réponse à la requête "Device Request" de la DreamCast)
Fera tu un recap sur une page web avec les differentes captures pour chaque peripherique ?
Dans l'immédiat non. D'abord par ce que je ne les possède pas tous et ensuite par ce que cela demande du temps, beaucoup de temps. C'est pas HSM qui attend après son écran depuis Juillet qui me contredira !
-
Dommage que tu ne sois pas lyonnais voir rhône-alpin, tu aurais pu venir faire un tour à la maison avec tous les accessoires dont je ne dispose pas.
Je passe de temps en temps sur lyon vu que ma mere habite la bas, a l'occaz et si t'as pas eu ces accessoires dans la main je te ferais signe.
Le Light Gun Mad Catz dont j'ai détaillé les trames n'est compatible qu'avec l'Amérique du Nord (octet 1 du bloc 5 de la trame "Device Status" en réponse à la requête "Device Request" de la DreamCast)
De memoire il marche correctement sur mon Confidential Mission Euro, mais je retesterais a l'occaz.
Dans l'immédiat non. D'abord par ce que je ne les possède pas tous et ensuite par ce que cela demande du temps, beaucoup de temps. C'est pas HSM qui attend après son écran depuis Juillet qui me contredira !
Meme si tu les as pas tous pour l'instant ca peux etre une bonne sources d'info deja.
-
Un p'tit tour en arrière.
Les schémas des manettes HTK-7300 et HTK-7700 publiés ces deux posts :- http://www.gamoover.net/Forums/index.php?topic=21932.msg321472#msg321472
- http://www.gamoover.net/Forums/index.php?topic=21932.msg321832#msg321832
n'étaient pas définitifs, il manquait certaines informations comme le nom des signaux sur les connecteurs CN1 et CN2, ceux qui sont au fond des logements pour les accessoires.
Le seul document que j'ai pu trouver sur le repérage des contacts de ces connecteurs est le le 1er tableau de cette page (http://soeren.informationstheater.de/vm/vm2vm.html) malheureusement il est un peu brouillon.
Avec l'analyseur Scanalogic, il va être facile de comparer les signaux présents sur les broches de l'un ou l'autre de ces connecteurs avec ceux du Maple bus et ainsi pouvoir attribuer aux différentes contacts les appellations données dans le document de la patente US (http://www.boob.co.uk/docs/MaplePatent.pdf).
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100820231143-gc339-Fig44.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100820231143-gc339-Fig44.PNG)
| | Ci-contre, le synoptique des interconnections entre la console DreamCast et ses accessoires :
- La DreamCast ou HOST avec ses 4 ports A, B, C et D est au sommet de la hiérarchie.
- 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. Un dispositif de base peut théoriquement supporter quatre dispositifs d'extension. Dans la réalité ces dispositifs de base comme la manette standard ne disposent que de deux logements maximum pour accueillir un dispositif d'extension comme un VMU ou un vibreur. D'ailleurs la puce E2 Maple bus a été conçue avec cette limitation.
|
Ci-contre le synoptique des différents bus : - Le M-Bus ou Maple bus, plus prosaïquement, c'est le cordon à 5 fils + blindage d'un accessoire comme une manette que l'on enfiche dans un des connecteurs A, B, C ou D de la DreamCast.
- Le LM-Bus ou Lower Maple bus, il est très court puisque l'on pourrait le résumer aux seuls 14 contacts entre le connecteur au fond de chaque logement d'une manette et celui de l'accessoire qui occupe ce logement.
En fait le M-Bus est éclaté en deux LM-Buses, un par logement. La puce E2 Maple bus à l'intérieur d'un dispositif de base comme une manette se charge de l'aiguillage des différents signaux entre le M-bus et les deux LM-Buses qu'elle supporte. De plus le LM-Bus n'est pas full-duplex comme le M-Bus, il est scindé en deux flux unidirectionnels : - Le flux descendant ou "Down Stream", ce sont les ordres provenant de la console.
- Le flux montant ou "Up Stream". ce sont les réponses à destination de la console.
| | (http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100905225735-gc339-Fig32.small.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100905225943-gc339-Fig32.PNG)
|
Entre la console (HOST) et le dispositif de base (une manette par exemple), les échanges sur le M-Bus nécessitent 3 fils : SDCKA, SDCKB et Masse.
- Chaque fil SDCKA ou SDCKB est à tour de rôle horloge et donnée, SDCKA transmet le front d'horloge alors que SDCKB est positionné sur le niveau logique du bit à transmettre, et vis versa.
- Les échanges se font en full duplex, c'est à dire que la transmission est bilatérale, aucun des fils SDCKA et SDCKB n'est spécialisé dans un sens de transmission donné.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100905012542-gc339-Buses.PNG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100905012542-gc339-Buses.PNG)
| | Entre le dispositif de base (une manette par exemple) et n'importe quel dispositif d'extension inséré dans un logement (vibreur, VMU ...), les échanges nécessitent beaucoup plus de fils car le LM-Bus est un M-Bus démultiplexé :
- Le principe de transmission à deux fils, ou chacun est à tour de rôle horloge et donnée, est conservé.
- Les échanges sont séparés en deux flux :
- Avec les fils SDCKA-DS et SDCKB-DS pour le flux descendant ou "Down Stream". .
- Avec les fils SDCKA-US et SDCKB-DS pour le flux montant ou "Up Stream".
- Deux autres fils SDCKA-EN et SDCKB-EN, EN pour "enable". L'accessoire ou dispositif d'extension positionne ces fils à 1 pour répondre. Ces fils commandent l'aiguillage à l'intérieur de la puce E2 Maple bus, les informations retransmises sur SDCKA-US / SDCKB-US peuvent alors transiter vers le M-Bus .
Ces deux fils de commande SDCKA-EN et SDCKB-EN sont bien dissociés car il a été prévu qu'un dispositif d'extension puisse interpréter une trame "SDCKB Occupancy" : l'ordre d'occupation est maintenu sur SDCKA-DS par la console pendant que dispositif d'extension retransmet une information à destination de cette même console sur le fil SDCKB-US.
La présence d'une tension (3,3 volts) sur le fil ID 2 permet au dispositif de base de savoir quand un accessoire est inséré dans le logement correspondant.
|
Comme les accessoires sont banalisés, les niveaux logiques sur ID 1 et ID 0, permettent au dispositif d'extension de connaître le n° du logement dans lequel il est inséré.
Il pourra ainsi reconnaître les trames qui lui sont adressées (champ adresse destination) ou insérer la bonne adresse source dans les trames qu'il émet sur SDCKA-US / SDCKB-US à destination de la console.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100906000558-gc339-DSCF5007.JPG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100906000558-gc339-DSCF5007.JPG)
Les canaux 1 et 2 (pinces et traces bleues, jaunes) de l'analyseur Scanalogic sont respectivement raccordés sur SDCKA et SDCKB par l'intermédiaire de la rallonge de test.
Les canaux 3 et 4 (pinces et traces rouges, vertes) seront baladés sur les contacts du LM-Bus du logement N°2 équipé d'un VMU, les contacts du logements N°1 étant inaccessibles.
Le petit cavalier bleu sert à court-circuiter le condensateur CE1 et permet ainsi d'appliquer un reset forcé sur la patte 33 de la puce E2 Maple Bus de la manette.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100906003710-gc339-SDCKA-DS-US.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100906003710-gc339-SDCKA-DS-US.png)
En haut les trames SDCKA en bleu, les trames SDCKB en jaune.
On distingue très bien les deux échanges :
- Le premier, le plus à gauche, se déroule entre la DreamCast et le dispositif de base
- Le second, celui du centre, entre la DreamCast et le dispositif d'extension.
La trace en vert prise sur le contact 4 du connecteur CN3 montre que c'est une trace de trames du flux descendant ou "Down Stream" car toutes les requêtes de la DreamCast y sont retransmises quelque soit le dispositif destinataire.
La trace en rouge prise sur le contact 5 du connecteur CN3 montre que c'est une trace de trame du flux montant ou "Up Stream". C'est le dispositif d'extension, c'est à dire le VMU, qui répond à la requête que la DreamCast vient de lui adresser.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100906011615-gc339-SDCKA-DowStream.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100906011615-gc339-SDCKA-DowStream.png)
Il suffit maintenant de dilater l'échelle de temps au niveau de la deuxième trame du signal vert pour savoir qu'elle est identique à la trace de SDCKA à un pas de d'échantillonage près. Le contact 4 du connecteur est donc celui du signal SDCKA-DS, DS "pour Down Stream"
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100906011641-gc339-SDCKA-UpStream.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100906011641-gc339-SDCKA-UpStream.png)
Idem pour l'unique trame du signal rouge, elle est de même identique à la trace de SDCKA à un pas d'échantillonage près. Le contact 5 du connecteur est donc celui du signal SDCKA-US, US "pour Up Stream"
Le même raisonnement et l'observation des signaux font constater pour que :
- Le contact 10 correspond à SDCKB-DS, DS "pour Down Stream".
- Le contact 11 correspond à SDCKB-US, US "pour Up Stream".
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100906094832-gc339-SDCKA-EN-1.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100906094832-gc339-SDCKA-EN-1.png)
Reste maintenant à rechercher les deux contacts SDCKA-EN et SDCKB-EN, Avec l'analyseur Scanalogic, ils sont immédiatement repérés, ce sont les contacts 3 et 12. Le problème est que leurs traces sont absolument identiques, le contact 3 est très probablement associé au signal SDCKA-US et le contact 12 à SDCKB-US, il faut en être sûr.
Sur la trace rouge ci-dessus on observe bien que le créneau à l'état haut encadre bien les salves de la trame montante ou "UpStream"
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100906101407-gc339-DSCF4976.JPG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100906101407-gc339-DSCF4976.JPG)
La solution trouvée pour départager les ex aequo à été de dessouder et de relever le conducteur du contact 3 afin que la commande d'aiguillage ne parvienne plus à la puce E2 Maple Bus.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100906100520-gc339-SDCKA-EN-2.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100906100520-gc339-SDCKA-EN-2.png)
La trame montante sur SDCKA-US ne parvient plus sur SDCKA du Maple-Bus, pas de doute le contact 3 correspond bien au signal SDCKA-EN et par conséquent le contact 12 est SDCKB-EN.
Bon, plus simple maintenant, reste à repérer les contacts ID0 à ID2 avec le voltmètre numérique.
- Avec ID2 c'est rapide, le niveau logique sur le contact 9 est à 0 volt quand le VMU est défiché et à 3,3 volts quand il est enfiché. Ce contact 9 est donc ID2
- Pour ID0 et ID1, il ne reste plus que les contacts 6 et 13, le 14 n'étant pas connecté à l'intérieur de la manette.
Voici les tensions relevées sur ces contacts :
|
|
|
|
|
|
| | | | Contact 6 | | | Contact 13 | | |
|
|
|
|
|
|
| Logement 1 / CN2 | | | 0 volt | | | 0 volt | | |
| Logement 2 / CN3 | | | 3,3 volts | | | 0 volt | | |
|
|
|
|
|
|
Donc logiquement, en s'aidant des informations données dans la table 6, colone 41, du document de la patente US (http://www.boob.co.uk/docs/MaplePatent.pdf) :
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100906110031-gc339-Table6.GIF) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100906110031-gc339-Table6.GIF)
- ID0 doit être le contact 6
- ID1 doit être le contact 13
Et c'est bien la puce E2 Maple bus qui affecte le n° de LM-Bus à chaque logement, car ID0 et ID1 sont à 0 quand elle est maintenue en reset permanent par le cavalier bleu. Le contact ID1 du logement n°2 se repositionne à 1 dès que dés que le cavalier est retiré.
Il ne reste plus qu'à dresser le tableau n° contact / nom officiel, les noms étant extraits du document de la patente US (http://www.boob.co.uk/docs/MaplePatent.pdf) ainsi qu'à les reporter sur les schémas déjà postés.
|
|
|
| | N° | contact | | CN2 / | Logement 1 | | CN3 / | Logement 2 | | | |
|
|
|
| | 1 | | +3,3V | | +3,3V | | | | 2 | | +5V | | +5V | | | | 3 | | SDCKA-EN-1 | | SDCKA-EN-2 | | | | 4 | | SDCKA-DS-1 | | SDCKA-DS-2 | | | | 5 | | SDCKA-US-1 | | SDCKA-US-2 | | | | 6 | | ID0-1 | | ID0-2 | | | | 7 | | GND | | GND | | | | | | | | | | | | 8 | | GND | | GND | | | | 9 | | ID2-1 | | ID2-2 | | | | 10 | | SDCKB-DS-1 | | SDCKB-DS-2 | | | | 11 | | SDCKB-US-1 | | SDCKB-US-2 | | | | 12 | | SDCKB-EN-1 | | SDCKB-EN-2 | | | | 13 | | ID1-1 | | ID1-2 | | | | 14 | | ? | | ? | | |
|
|
|
|
| | (http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20100906130839-gc339-HKT-7700.small.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20100906124047-gc339-HKT-7700.png)
|
-
Bonjour.
Ce Wip étant momentanément en stand-by au profit de l'écran de HSM, j'ai néanmoins continué mes recherches de documentation sur le net. Et à force de proposer des mots clef issus du glossaire DreamCast/Maple Bus, j'ai enfin pu localiser une vraie mine d'or (http://sites.google.com/site/leucemidusdc/documentacion/Hardware_doc.rar).
Que n'aie je pas trouvé cette archive plutôt, elle m'aurait épargné quelques heures de travail ! En tout cas, ces documents confirment ce que j'ai déjà observé ou déduit de mes expérimentations précédentes.
Cette archive contient deux répertoires spécifiquement dédiés au Maple Bus :
- Un répertoire "E_MapleBus_FT_Spec" avec :
- Un document word "Maple Bus Standard Specification"
- Une douzaine de documents "Maple Bus Function Type Specifications", soit un fichier word par type de fonction.
- Un répertoire "E_MapleBus_Peri_HW_Spec" avec plus d'une quinzaine de documents word "Maple Bus Peripheral Hardware Specifications", chacun décrivant un accessoire différent : pad standard, pad arcade, twinstick, canne à pêche ...
En fait cette archive est issue d'un site espagnol où il est question d'un interfaçage USB / Maple Bus à l'aide d'un PIC 18F4550 : http://sites.google.com/site/leucemidusdc/Home
Cette tentative semble ne pas avoir été concluante malgré l'utilisation de registres à décalage externes pour suppléer au manque de mips du PIC.
J'avais envisagé l'utilisation d'un SX28 Parallax à 75/80 Mhz (75/80 mips). Celui-ci n'est plus produit depuis la fin de l'été 2009, il en reste cependant un stock appréciable. C'est pourquoi je suis en train de réfléchir à l'utilisation d'un "Propeller" P8X32A de cette même firme.
(http://www.parallax.com/Portals/0/Images/Prod/P/PropellerBlock.jpg) (http://www.parallax.com/Portals/0/Images/Prod/P/PropellerBlock-L.jpg)
Cette puce comporte 8 processeurs ou "Cog"s :
- Chacun d'entre eux à un accès commun aux pattes E/S :
- Les pattes déclarées en lecture peuvent être lues en simultané par tous les Cogs.
- L'état sur les pattes déclarées comme sorties est cependant une combinaison logique de l'état imposé par chaque Cog.
- Chacun d'entre eux dispose d'une mémoire locale de 512 mots de 32 bits.
- Chacun d'entre eux a accès aux ressources globales (mémoire centrale...) à tour de rôle grâce à un tourniquet, ce qui ralenti quand même l'accès de quelques cycles machine supplémentaires en attendant le time-slot dédié à chacun.
Les cogs sont cadencés par une horloge commune, ils peuvent l'être en standard jusqu'à 80MHz (20 mips) voir même être overclockés à 100Mhz (25 mips) avec un quartz de 6,25 MHz (http://mikronauts.com/products/mikronauts-625mhz-crystal/). Cette vitesse semble un peu juste pour décoder les trames issues de la DreamCast, mais en spécialisant les Cogs (un pour la détection des fanions "Start" et "End", un pour la réception des octets de données, un pour lire les contacts sur le connecteur Jamma, un autre pour gérer les time-out ...) et surtout en utilisant des instructions WAITxxx, cela devrait être jouable.
-
:o
Gc je t'aime :-* ^-^
quel travail monstrueux! ;D
-
Ce Wip étant momentanément en stand-by au profit de l'écran de HSM
Moi aussi je l'aime :-*
:D
-
Le problème du décodage du Maple Bus se pose surtout pour la réception des trames émises par la DreamCast, elles le sont à une vitesse fixe de 2 Mbps (Mega bits par seconde) alors que l'émission vers la DreamCast est moins contraignante, cette dernière peut décoder les trames reçues avec une vitesse bien inférieure.
De plus sur le Maple Bus, le fil SDCKA et le fil SDCKB sont à tour de rôle bit de donnée et impulsion d'horloge. Pour une période d'horloge donnée SDCKA représente l'horloge et SDCKB la donnée. Pour la période suivante c'est SDCKA qui représente la donnée pendant que SDCKB représente l'horloge. Et ainsi de suite.
S'il était possible de démultiplexer l'horloge et les données pour que les impulsions d'horloge et les bits de données se retrouvent regroupés séparément sur un fil bien spécifique, l'on se rapprocherait alors du fonctionnement d'un Bus SPI : http://fr.wikipedia.org/wiki/Serial_Peripheral_Interface. Et là, la réception des trames seraient grandement simplifiée puisque certains microcontrôleurs ont une interface SPI intégrée comme certains PICs de Microchip.
L'idée est donc d'aiguiller le fil SDCKA et le fil SDCKB au moment opportun, c'est à dire sur le front descendant du signal d'horloge, vers le fil d'horloge (SCKL) et de fil des données (MOSI).
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20101020000049-gc339-Sh1.GIF) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20101020000049-gc339-Sh1.GIF)
- L'aiguilleur est réalisé avec deux éléments d'un boîtier multiplexeur 2 vers 1 type 74HCT157. Ce boîtier de la série 74HCT est compatible TTL, et de ce fait il réalise l'adaptation de niveau entre le Maple Bus fonctionnant avec des signaux à 3,3 volts et le reste de la logique qui est alimentée en 5 volts.
- Le flip flop à base de 74HC74 qui est piloté par le signal d'horloge démultiplexé en sortie du HCT157 (après inversion) et dont une des sorties commande l'aiguillage (Entrée Select du HCT157)
Le test va s'effectuer avec une trame "Request Device Info" issue de la DreamCast et préalablement sauvegardée grâce à une des fonctionnalité de l'analyseur Scanalogic 2.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20101020001954-gc339-Generateur.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20101020001954-gc339-Generateur.png)
Cette analyseur permet de "rejouer" le signal sur deux de ses sondes, c'est à dire qu'elles sont génératrices pendant que les deux autres sont réceptrices afin de capturer les signaux que l'on veut observer.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20101020002548-gc339-SPI-1.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20101020002548-gc339-SPI-1.png)
- Les deux traces supérieures correspondent à la trame Maple Bus qui est émise par les sondes bleue et jaune sur les entrées de l'aiguilleur.
- Les deux traces inférieures correspondent aux signaux observés en sortie d'aiguillage, l'horloge SCKL et les bits de donnée MOSI.
Tout semble OK pour la retransmission d'un bit à 0, par contre il manque l'impulsion d'horloge pour les bits à 1 (portions de traces cerclées de blanc).
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20101020004354-gc339-SPI-2.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20101020004354-gc339-SPI-2.png)
En fait l'impulsion d'horloge est bien présente puisque la sortie du flip flop change sur chaque front descendant de celle ci (trace verte), seulement elle est très fine et l'analyseur n'a pas le temps de la capturer, la durée de l'impulsion est inférieure à sa période d'échantillonage. En fait elle ne dure que le temps nécessaire au basculement du flip flop cumulé avec le temps d'inversion de l'aiguilleur, c'est à dire quelques dizaines de nanosecondes.
La solution va donc consister à augmenter ce temps de propagation pour que l'impulsion soit plus large.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20101020005518-gc339-Sh2.GIF) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20101020005518-gc339-Sh2.GIF)
Les 5 inverseurs non utilisés du boîtier 74HC04 ont été câbles à la queue leu leu et le tout a été inséré entre le flip flop et l'aiguilleur pour réaliser ce temps de retard.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20101020005821-gc339-SPI-3.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20101020005821-gc339-SPI-3.png)
Les impulsions sont bien visibles maintenant, leur durée est moins large que les autres et ne dépendant que du temps de propagation dans les 5 inverseurs. Inverseurs dont il a fallu changer de type de boîtier, le HC04 étant encore trop rapide, il a fallu le remplacer par un CMOS CD4069 beaucoup plus lent.
La trame au complet, En attente d'être décodée grâce à l'onglet décodage SPI du logiciel.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20101020010519-gc339-SPI6.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20101020010519-gc339-SPI6.png)
Le problème est que le logiciel de décodage intégré à besoin du signal CS du bus SPI, en utilisation normale le signal CS permet de valider les périphériques destinataires des trames SPI. La trace de la trame SDCKB a donc été sacrifiée, en fait elle a été modifiée avec l'éditeur graphique inclus dans les outils du logiciel pour disposer de ce signal indispensable au fonctionnement du module logiciel de décodage.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20101020011257-gc339-SPI-7.png) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20101020011257-gc339-SPI-7.png)
Après avoir choisi les paramètres adéquats dans l'onglet du décodeur et validé le décodage, les octets de la trame originelle sont correctement décodés : 0x00, 0x40, 0x60, 0x01 et 0x21.
Donc l'idée n'est pas bidon, la conversion Maple Bus vers Bus SPI est réalisable, maintenant reste :
- À savoir si les interfaces SPI des microcontrôleurs candidats sont aptes à réceptionner une trame SPI à 2 Mbps.
- À recréer le signal CS du bus SPI à partir du décodage des fanions "Start" et "Fin" de la trame Maple Bus. Ce même signal CS pouvant être utilisé pour valider l'aiguilleur (patte 15 du HCT157) à fin de ne pas retransmettre ces fanions sur le bus SPI.
- Remplacer tous les boîtiers nécessaires par un boîtier de logique programmable. Éventuellement synchroniser la dispositif par une horloge à 16 MHz (comme avec la puce E2 Maple Bus) pour séquencer et fiabiliser son fonctionnement en évitant d'utiliser le temps de propagation à travers plusieurs portes logiques.
(http://hico-srv004.pixhotel.fr/sites/default/files/styles/gamoovernet890px/public/gamoovernet/20101020090651-gc339-DSCF6023.JPG) (http://hico-srv004.pixhotel.fr/sites/default/files/gamoovernet/20101020090651-gc339-DSCF6023.JPG)
La bidouille qui a permis de tester cette idée, réalisée en miniwrapping à partir de l'épave d'une précédente.
- Les sondes bleu (SDCKA) et jaune (SDCKB) permettent d'injecter la trame Maple bus de test.
- Les sondes rouge (SCLK) et verte (MOSI) permettent de capturer les signaux du pseudo bus SPI.
-
Dès que je récupère des fonds, il me faudra un Scanalogic… L'oscilloscope est plus que très utile pour PLEIN de choses, mais le scanalogic me semble particulièrement bien adapté pour analyser les protocoles de joypads. Ce qui m'intéresse grandement, étant donné un des projets à long terme que je voudrais réaliser.
Vraiment très intéressant tout ça, super documentation pour un débutant comme moi.
D'après ton analyse, à condition de trouver un microprocesseur suffisamment rapide et en récupérant les connecteur d'une manette ou de VMU hors service, on pourrait carrément prévoir des slots pour VMU sur le panel de la borne.
Je connais très mal les jeux Dreamcast (j'ai juste joué à Soul Calibur version pal), je ne sais pas si il y en a un qui gère une sauvegarde différente par joueur. Mais ça me semble une option très sympathique.
Ca évite de devoir aller fouiller dans les entrailles de la borne pour brancher le VMU d'un pote de passage qui a envie de montrer son dernier score. :D
-
D'après ton analyse, à condition de trouver un microprocesseur suffisamment rapide et en récupérant les connecteur d'une manette ou de VMU hors service, on pourrait carrément prévoir des slots pour VMU sur le panel de la borne.
Pourquoi vouloir réutiliser un VMU pour sauvegarder les scores ou le contexte des dernières parties ? A partir de ton idée d'utiliser un beagle board ( http://beagleboard.org/ / http://en.wikipedia.org/wiki/Beagle_Board ) pour émuler un ou plusieurs contrôleur(s) DreamCast, il devrait être possible de sauvegarder ces données sur une banale clef USB. Le tout est que le logiciel chargé sur le beagle board émule aussi la fonction mémorisation du VMU pour que la DreamCast n'y voit pas la différence.
-
Pour être honnête, je n'y avais pas pensé, mais c'est une très bonne solution, reste à voir si je serai assez doué pour la mettre en pratique.
En ce moment, j'attends que ma Pandora (http://www.openpandora.org/) arrive, le hardware est extrêmement proche d'un beagleboard, avec l'avantage qu'elle est déjà équipée de contrôles de jeux et d'un écran lcd. Sur son port d'extension, on a accès à 6 lignes GPIO, ça devrait suffire pour la Dreamcast.
Si j'arrive à pondre un truc viable sur la pandora, j'envisagerai l'investissement dans un beagleboard et sa carte d'extension "trainer" (http://www.watterott.com/en/BeagleBoard-Trainer) qui offre pas mal d'I/O et même une zone de prototypage.
-
Je me permets de faire un "UP" du topic pour informer tout le monde que le MC Cthulhu supporte maintenant la Dreamcast (la compatibilité reste à peaufiner sur certains jeux) ! Il suffit comme d'habitude de faire une mise à jour du firmware...
-
Reste à savoir s'il intègrera le code dans l'UPCB ou pas... Mais j'ai bien peur que non...
-
Deuxieme petite diversion de ma part, j'ai testé le MC Cthulhu sur WII (Gamcube) et Dreamcast la semaine dernière, ca marche impeccable (la config des boutons est parfaite pour SF3 3rd strike).
Donc terrible :-*
Sinon pour HC, je pense que tu anticipes bien (un jour, Toodles a dit MC Cthulhu >>>>>>>>> UPCB, ce qui clarifie bien la situation pour tout le monde)
-
Je viens de recevoir mon Scanlogic (j'en avais besoin pour un autre projet), donc le temps de me familiariser avec l'outil je ferais des captures des peripheriques suivant :
- Gun Euro Officiel
- Gun Jap Officiel
- Clavier Euro (et autre si je les retrouvent)
- Canne a peche jap
-
Ah zut, l'analyse des différentes manettes DC n'a pas du tout continué alors :-[
Bon, beh tant pis hein, la docu compilée ici était déjà hyper impressionnante comme ça. ^-^
-
Ah zut, l'analyse des différentes manettes DC n'a pas du tout continué alors :-[
Bon, beh tant pis hein, la docu compilée ici était déjà hyper impressionnante comme ça. ^-^
L'analyse des différentes manettes est devenue inutile avec cette mine d'or (http://sites.google.com/site/leucemidusdc/documentacion/Hardware_doc.rar), tout est bien détaillé dans ce document original :
Et à force de proposer des mots clef issus du glossaire DreamCast/Maple Bus, j'ai enfin pu localiser une vraie mine d'or (http://sites.google.com/site/leucemidusdc/documentacion/Hardware_doc.rar).
Que n'aie je pas trouvé cette archive plutôt, elle m'aurait épargné quelques heures de travail ! En tout cas, ces documents confirment ce que j'ai déjà observé ou déduit de mes expérimentations précédentes.
Cette archive contient deux répertoires spécifiquement dédiés au Maple Bus :
- Un répertoire "E_MapleBus_FT_Spec" avec :
- Un document word "Maple Bus Standard Specification"
- Une douzaine de documents "Maple Bus Function Type Specifications", soit un fichier word par type de fonction.
- Un répertoire "E_MapleBus_Peri_HW_Spec" avec plus d'une quinzaine de documents word "Maple Bus Peripheral Hardware Specifications", chacun décrivant un accessoire différent : pad standard, pad arcade, twinstick, canne à pêche ...
J'ai en définitive mis de coté cette expérimentation (http://www.gamoover.net/Forums/index.php?topic=22728.0) à cause du nombre de cycles important absorbé par la réponse aux interruptions du micro-contrôleur SX28 qui aurait pu faire louper la prise en compte de certains bits.
Mais je n'ai pas encore jeté l'éponge, une des solutions serait l'emploi d'un CPLD pour désérialiser le flux rapide de données émises par la DC, comme dans ce boîtier interface DC2Saturn :
(http://gamoovernet.pixhotel.fr/pics_gamoovernet690px/20130527120326-gc339-Image-0253.JPG) (http://gamoovernet.pixhotel.fr/pics/20130527120326-gc339-Image-0253.JPG)
Le CPLD utilisé dans cette interface est ici un XC9536XL Xilinx (http://www.xilinx.com/support/documentation/data_sheets/ds064.pdf) comportant 36 macro-cellules :
(http://gamoovernet.pixhotel.fr/pics_gamoovernet690px/20130527121228-gc339-Image-0262.JPG) (http://gamoovernet.pixhotel.fr/pics/20130527121228-gc339-Image-0262.JPG)
Il me reste plus qu'à m'initier au langage VHDL pour reprendre cette expérimentation !
-
Ahhh, effectivement, ça me dit quelque chose :-\
Maintenant je me dis que j'aurais ptet dû relire une chouille le sujet avant de poster…
Je suis content de lire que tu ne lâches pas l'affaire et j'espère pouvoir donner un coup de main, si mes connaissances en électronique s'améliorent d'ici-là.
(disons que je suis fort rouillé, j'ai un peu de mal à lire certaines datasheets >:( )
-
Réalisation récente d'un adaptateur MapleBus/USB avec un µC Atmega168 par un québécois, rédigée en français pour une fois : http://www.raphnet.net/programmation/dreamcast_usb/index.php
(http://www.raphnet.net/programmation/dreamcast_usb/dev_setup_ready.jpg)
source : www.raphnet.net