Résumé du projet

Les manettes de N64 et Gamecube sont d'excellentes manettes qui conviennent parfaitement à une multitude de jeux sur PC. Comme ce circuit utilise la class HID du standard USB, il n'est pas nécéssaire d'utiliser des pilotes spécifiques. J'ai testé sous Linux et Windows.

Caractéristiques:

Pourquoi?
Un de mes amis souhaitait pouvoir jouer à des jeux de Nintendo 64 sur son PC avec une manette d'origine. J'ai donc mis au point ce convertisseur. Puisque le protocol des manettes de Gamecube est très similaire, il m'a été facile de supporter du même coup les manettes de Gamecube.

Étant donné que les manettes de N64 et Gamecube requièrent une alimentation à 3.3 volts et que le bus USB fournit seulement du 5 volts, il est nécéssaire d'utiliser un régulateur de voltage. À l'exception du logiciel, c'est la seule différence (et complexité additionelle) avec mon projet de Manettes Nes/Snes à USB.

Adaptateurs prêts à utiliser disponibles

Photos

Exemple d'adaptateur

Convertisseur N64 ou Gamecube à USB avec régulateur sur petit circuit imprimé:

Conversion de manette

Exemple de conversion permanente d'une manette N64. Il n'y a pas beaucoup d'espace, mais en coupant un peu de plastique, on arrive à installer le circuit dans le «doigt» central de la manette. Il faut faire attention au passage des fils pour ne pas bloquer le couvercle lors de la fermeture. Pour fixer les fils au bons endroits, j'ai utilisé de la colle chaude.

Photos historiques et/ou de développement

Photos du circuit-imprimé avec régulateur lm1117:

Développement avec le nouveau circuit imprimé:

Photos du prototype N64. J'ai utilisé un régulateur lm317:
La N64 Hori-mini et la manette Gamecube blanche avec câble très long fonctionnent!
Le clavier Gamecube ASCII est supporté depuis la version 2.9.

---

Contributions

Voici des photos que Declan Williams (16 ans!), m'a fait parvenir:

---

Sean Green a construit et utilisé ce circuit pour certains projets:
NOTE: Le bliss-4pack n'est pas une version à 4 joueurs du circuit. Il s'ajit seulement d'un HUB USB et 4 circuits Gamecube/N64 à USB.

---

2013-02-14: Ludivine a fabriqué un adaptateur basé sur ce projet. Le régulateur de tension est sur la face arrière.

---

19 juillet 2014 (Samedi)
TALENTO m'envoie de Bulgarie ces photos de l'adaptateur GC/N64 à USB qu'il s'est fabriqué.

---

5 octobre 2014 (Dimanche)
Browner87 a utilisé son imprimante 3D pour fabriquer un boîtier contenant deux circuits GC/N64 à USB et un concentrateur USB. Il a conçu le boîtier pour qu'il s'installe sous son bureau. Commentaires et photos supplémentaires disponibles sur imgur.

---

11 octobre 2014 (Samedi)
Jonathan m'envoie ces photos de l'adaptateur Gamecube à USB qu'il a réalisé. Il a utilisé un Atmega8L-8PU, malgré qu'il soit surcadancé dans ce circuit. Cela fonctionne sans problèmes pour lui.

---

10 mars 2015 (Mardi)
Rickey m'a envoyé cette photo d'un adaptateur fabriqué sur une platine d'expérimentation. Il a utilisé un ATMega328P programmé avec le firmware et les fuses pour Atmega168 et tout fonctionne!

---

25 mars 2015 (Mercredi)
Ashley de Queensland, Australie, aide son petit frère Shaun (Agé de 14 ans) à réaliser quelques projets pour l'intéresser à autre chose que de jouer. Ensemble, ils ont construit un adaptateur SNES/NES à USB ainsi qu'un adaptateur Gamecube/N64 à USB une même platine d'expérimentation. Les composantes pour la version finale sont en chemin.

Schéma

Voici les schémas:

Notes et commentaires: Certains documents sur internet prétendent que les manettes de Gamecube fonctionnent à 3.43 volts, d'autres disent que c'est avec un voltage entre 3.3 à 3.8! volts... J'ai vu un vieux message dans le newsgroup comp.emulators.game-consoles ou l'auteur prétendait que le N64 donne du 5 volts à ses manettes! (C'est faux). Certains projets abaissent le voltage à 3.3 volts (plus ou moins) en faisant passer l'alimentation de la manette à travers des diodes. J'ai mesuré 3.36 volts sur mon N64 alors pour ma part, je choisi d'alimenter les manettes de N64 et Gamecube avec 3.3 volts.

Pour obtenir du 3.3 volts, vous pouvez utiliser un régulateur de voltage fixe tel que le 78M33C ou un régulateur de voltage variable comme le lm317 ou lm1117 (exemple). Si vous utilisez un régulateur variable comme le lm317, voici un petit outil permettant de trouver une valeur de résistance R1 adéquate. Un voltage de sortie entre 3.26 à 3.40 volts devrait être parfait.

Résistance d'ajustement (R2): Résistance Fixe (R1): Voltage de sortie (Vout):

Note: L'image provient du datasheet du lm317 par motorola, que voici: lm317rev1g.pdf

---

Code de couleur wavebird
On m'a fait savoir qu'à l'intérieur du récepteur de la manette wavebird, le code de couleur des fils utilisés entre le connecteur gamecube et le circuit imprimé semble être contant:

• +3.3v: Rouge
• Data: Vert
• GND: Brun (broche)
• GND: Violet (bouclier)

Attention, la couleur des fils varie d'un manufacturier à l'autre. Il est toujours mieux de vérifier pour éviter des catastrophes.

Circuit imprimé

Le circuit imprimé est une amélioration du PCB du projet Manettes Nes/Snes à USB. Sur celui-ci, il y a maintenant un régulateur et des contacts de reprogrammatin sur la face inférieure. Voici des vues composées pour connaître le placement des composantes:


Le régulateur utilisé est un lm1117mp-adj. Des résistances de 0 ohms doivent être installés pour sélectionner la source d'alimentation (5 volts d'USB ou voltage de sortie du régulateur) du Microcontrôleur et de la sortie d'alimentation du circuit (ce qui va à la manette). Dans notre cas, il faut installer R5 et R8:


Voici un shéma de câblage pour ce circuit imprimé:


Et voici finalement les fichiers gerbers à partir desquels vous pouvez reproduire ce circuit:
multiuse.zip

Étant donné tout les 'vias' sur ce circuit, le fabriquer chez soi peut être difficile ou désagréable. J'offre donc des circuits fait en usine dans mon magasin en ligne. Cependant, les circuits que j'offre ne sont pas aussi à jour que dans les gerbers ci-haut. J'en ai fait produire quelques centaines avec une légère erreur: Le 5 volts d'USB ne se rends pas au régulateur!

Il est donc nécéssaire de souder un petit fil sur la face inférieure du circuit:

Circuits imprimés pré-assemblés et pré-programmés disponibles

Logiciel

Version v2.9.2 9 décembre 2015 (Mercredi)
Correction du code de détection des manettes Wavebird (n'était pas fiable depuis la version 2.9)
Fichier(s): gc_n64_usb-2.9.2.tar.gz (474.4 KB) gc_n64_usb-m8-2.9.2.hex (19 KB) gc_n64_usb-m168-2.9.2.hex (19.7 KB)

Code source:
Le code source est rendu publique sous la license GPL version 2. Voir License.txt pour plus d'information. Le projet se compile avec avr-gcc.

Utilisation des fichiers .hex
Les fichiers au format gc_n64_usb-m8-x.x.hex sont pour Atmega8, les fichiers gc_n64_usb-m168-x.x.hex sont pour l'Atmega168. (Note: On me rapporte qu'il est aussi possible d'utiliser un Amega328p avec le firmware et les fuses pour Atmega168)

Pour que le microcontrôleur fonctionne à la bonne vitesse, il est essentiel de configurer les 'fuses' correctement. Les valeurs pour ce projet sont:

• Pour Atmega8, utilisez high_byte=0xc9 low_byte=0x9f.
• Pour Atmega168, utilisez HFUSE = 0xD5, LFUSE = 0xD7, EFUSE = 0x01.

Pour de l'information sur la programmation d'un AVR, visitez ma page sur la programmation d'AVR

Puces Atmega8 DIP pré-programmés disponibles

Support Hori-mini

Depuis la version 1.3 du firmware, toutes les manettes HORI-Mini pour N64 devraient fonctionner correctement grâce à un nouvel algorithme plus tolérant aux différences de timing. Une explicaiton technique du problème et de la solution est donnée ci-dessous.

Il est connu que les manettes HORI-mini pour N64 ne se comportent pas bien avec bien des adaptateurs. Après un premier test avec le mien, je croyais qu'elles fonctionnait correctement... Jusqu'à ce qu'on me contacte à propos de problèmes. Lorsqu'on effectuait un déplacement du joystick, la position de celui-ci semblait sauter d'un point à l'autre de manière imprévisible rendant le jeu difficile, voir impossible. J'ai donc réessayé mon adaptateur avec plusieurs de mes adaptateurs sur différents ordinateurs. J'ai fini par trouver une combinaison ayant le même problème et me suis penché sur le problème.

Dès que j'ai regardé les signaux avec un oscilloscope, j'ai remarqué quelque chose d'inhabituel. La vitesse de transmission de la manette HORI semblait être plus basse et très différente de ce à quoi je m'attendais. Les images ci-dessous montre que les ratios haut/bas pour chauque bit est très différent entre l'interrogation (provenant de l'adaptateur) et la réponse (provenant de la manette). La manette HORI répond à 66% de la vitesse 'normale' d'une manette N64:


Vous savez peut-être déjà que l'encodage des bits est fait comme suit. Normalement ( du moins, avec les manettes Nintendo), un bit 0 est représenté par un niveau bas de 1μS suivi d'un niveau haut de 3μS. Et l'inverse pour un bit 1 (1μS bas, 3μS haut). (Consultez les références pour plus d'informations).

Vitesse normale Bon: Échantillon centré.

Vitesse Hori Mauvais: Échantillon près du front.

Pourquoi échantillonner près du front est un problème:

• L'échantillonnage ne peut pas être fait exactement après 2μS.. Le moment exact dépends de la synchronisation entre la boucle de détection et le front. En d'autre termes, l'échantillon sera parfois prit un peu plus tôt ou pendant le front montant.
• il se pourrait que la fréquence d'horloge interne à la manette HORI soit différente d'une unité à l'autre.. Cela veut dire que certaines manettes pourraient transmettre encore plus lentement (ce qui nuit) ou plus rapidement (ce qui aide).
• La lenteur du front montant pourrait aussi nuire. À quel moment exactement le MCU verra-t-il un niveau logique 1? Ceci fait partie des spécifications, mais il pourrait y avoir de petites différences d'une unité à l'autre ou encore avec les nouvelles versions de la puce (Le Atmega8a, par exemple). Et si l'utilisation d'un câble d'extension augmente la capacité, la situation empirera.

Le correctif: (depuis la version 1.3)
J'ai conclu qu'il me fallait un meilleur algorithme de réception. Plutôt que de simplement retarder l'échantillon ou modifier le code pour que la position d'échantillonage se déplace automatiquement, j'ai opté pour un algorithme complètement différent qui pourra tolérer une transmission plus rapide ou sinon beaucoup plus lente:

1. Mesurer le temps passé à attendre un front montant (temps bas)
2. Mesurer le temps passé à attendre le front descendant (temps haut)
3. Comparer le temps bas vs. temps haut. Si le temps passé bas est plus long, il s'agit d'un bit 0, sinon il s'agit d'un bit 1.
4. Repeat

Le chronométrage est fait en assembleur pour la vitesse et la prédictabilité (pas d'optimisations du compilateur C dans le chemin, etc). À 16Mhz, chaque cycle d'échantillonage prends environ 312.5nS. Un niveau maintenu pendant 1μS mesurera 3 cycles et un niveau maintenu pendant 3μS mesurera 9 cycles. Si la vitesse de transmission est plus lente, ces mesures seront plus élevées mais la relation du temps passé bas vs. le temps passé haut sera toujours valide.

Synchro-usb

Depuis la version 1.4, le "polling" de la manette est maintenant synchronisé avec la communication USB afin d'aider à maintenir la stabilité du rythme des impulsions lors de la communication avec les manettes. En théorie, cela augmente la compatiblité et fiabilité du circuit. L'explication technique suit.

Rappelons que l'implémentation USB est entièrement logicielle. Le MCU peut donc se faire interrompre à tout moment pour s'occuper de communication USB. Il arrive donc que ces interruptions se produisent en pleine communication avec la manette et empêche le maintient d'un rythme constant. La partie marquée en rouge sur la photo à droite montre que la transmission (trace d'en haut) s'est arrêté pendant la communication usb (trace d'en bas).

Lorsque qu'une interruption USB survient au mauvais moment, la trame gamecube/n64 est potentiellement corrompue et doit être ignorée si c'est le cas. En transmission, nous comptons sur la manette pour détecter l'erreur et ne pas répondre. Il y a donc un 'timeout' à la réception qui suit. Si au contraire, la corruption survient pendant la réception, nous manquerons des transitions et le nombre de bits reçus sera inférieur à ce qui était attendu.

Malgré la théorie énoncée ci-haut, il semblerait qu'il arrive très rarement (une fois dans plusieurs minutes) qu'il se produise une erreur non détectée. En effet, quelques utilisateurs prétendaient avoir vécu des cas où des boutons semblaient à l'occasion s'appuyer d'eux mêmes un bref instant. J'ai donc décidé d'enlever ce risque en trouvant une solution aux interruptions USB survenant au mauvais moment. Et avec les nouvelles manettes blanches pour Gamecube, la seule manette avec laquelle j'ai pu oberver ce problème, ce comportement très rare semble maintenant avoir complètement disparu.

Déactiver les interruptions pendant cette phase critique n'est pas possible en raison du pilote USB qui nous empêche de pouvoir les déactiver assez longtemps pour être utile. En revanche, les interruptions sont espacés d'environ 900μS ce qui nous laisse le temps d'interroger la manette, pourvu que nous puissions nous enligner pour le faire pendant la période d'inactivité.

J'ai pensé à une solution logicielle très simple. La logique contrôlant le rythme auquel la manette est interrogée reste la même. Mais juste avant l'interrogation, le MCU est mis en veille (mode IDLE). En ce mode, l'exécution normale s'arrête jusqu'à ce qu'une interruption survienne. À la reprise de l'exécution, le simple fait que l'exécution ait reprit nous donne le feu vert pour effectuer l'interrogation de la manette qui est faite après un court délais permettant d'éviter les autres interruptions qui suivent parfois de près l'interruption initiale.

Avec la mise en place de cette solution, nous obtenons un "polling" de la manette de jeu sagement placé dans l'espace de 900μS disponible entre les interruptions tel que ci-dessous:

Correctif de calibration

Le fait que les leviers analogiques L et R des manettes Gamecube n'aient pas une position de repos centrale cause souvent des problèmes. Plusieurs jeux voient l'axe correspondant comme actif dès que la valeur reçue s'éloigne suffisamment du centre. Lorsqu'on configure les boutons, les leviers L et R sont souvent pris en compte immédiatement et nuisent à la configuration (Lorsqu'elle n'est pas complètement empêchée.).

Pour palier à ce problème, exécutez l'outil suivant après avoir effectué la calibration de la manette avec les outils standard de Windows. Lorsque cet outil s'exécute, il trouve les adaptateurs raphnet GC/N64 à USB et retouche les donnés de calibration en vigueur. La calibration des axes liées aux leviers sont modifiés afin que dorénavant ils apparaissent centrés lorsqu'au repos.

Voici l'outil:
gc_calfix_ng_v1.3.zip.

Une opération réussie (ici pour deux adaptateurs) ressemble à ceci:

Versions précédentes:
gc_calfix_ng_v1.2.zip.

Support du clavier

Depuis la version 2.9, le clavier pour Gamecube est supporté et peut être utilisé sous Windows et Linux. Notez que je n'ai pu tester que le modèle ASC-1901P0 de ASCII. Ce clavier comporte un câble à deux connecteurs. Le connecteur gris correspond à la fonction clavier, le violet à la fonction manette. Pour utiliser les deux simultanément, sur un PC, il faut deux adaptateurs.

Voici quelques photos du clavier:

Journal et détails techniques

23 Novembre 2013

Pour débuter, j'ai regardé quelle était la réponse à la commande 0x00 (GET ID). L'adaptateur envoi déjà cette commande pour détecter le type de manette (N64 ou GC?) raccordé à l'adaptateur, alors il est logique d'effectuer la détection du clavier à cet endroit. J'ai décodé la réponse manuellement (plus facile que pour la communication de Dreamcast avec laquelle j'ai récemment travaillé, ce qui fait du bien.)

	0000 1000 0010 0000 0000 0000 : 0x082000

Note: Seuls les 16 premiers bits sont l'identification. Donc en fait, 0x0820.

J'ai ensuite consulté de la documentation pour gamecube^[1] pour constater que nous avions le même code d'identification. Donc tout allait bien. J'ai continué en essayant d'interroger le clavier avec la même commande que pour obtenir l'état d'une manette (0x400300) mais il n'y avait pas de réponse. Normal car ce n'est pas la bonne commande. Retour à la documentation qui m'a alors apprise qu'il faut utiliser 0x540000. Et cela fonctionne évidemment.

Le clavier retourne 64 bits (8 octets):

Premier mot 32 bit	Deuxième mot:
Bit 31: Errstat	Bits 31-24: Code de touche (1)
Bit 30: Errlatch
Bits 29-28: ?
Bits 27-24: Semble être un compteur 4 bits
Bits 23-0: ?	Bits 23-16: Code de touche (2)
	Bits 15-8: Code de touche (3)
	Bits 7: ?
	Bits 6-4: Peut-être une sorte de checksum. Variable en fonction des touches et combinaisons.
	Bits 3-0: Semble être un compteur 4 bits

Le clavier gamecube supporte un maximum de 3 touches simultanées alors j'ai construit le descripteur de rapport d'état HID en conséquence. Habituellement les touches «spéciales» comme CTRL, SHIFT et ALT sont transmises via des bits dédiés dans le rapport d'état HID, mais comme le clavier Gamecube n'a pas ce concept et rapporte l'état de ces touches comme les autres (par codes de touches 8 bits), je pense simplement faire la même chose. Sinon j'aurai à «émulter» fonctionnalité.

Contrairement au clavier de Dreamcast, le clavier gamecube ne semple pas utiliser les codes de touches standard figurant dans le manuel des tables HID (USB HID Usage Tables, section 10 : Keyboard/Keypad page [0x07]).

J'ai donc créé le tableau de conversion suivant. Puisqu'il s'agit d'un clavier de style Japonais, il y a quelques touches inhabituelles et pour que certaines produisent le caractère voulu, il faut évidemment configurer son PC pour utiliser un clavier Japonais.

Nom(s) Gamecube	Code(s) gamecube	Nom(s) HID	Code(s) HID	Commentaires
A - Z	0x10 - 0x29	A - Z	0x04 - 0x1D
1 - 9	0x2A - 0x32	1 - 9	0x1E - 0x26
0	0x33	0	0x27
ESC	0x4C	ESC	0x29
BACKSPACE	0x50	BACKSPACE	0x2A
TAB		TAB	0x2B
SPACE		SPACE	0x2C
_=	0x34	-_	0x2D	Première touche à droite de 0
^~	0x35	=+	0x2E	Deuxième touche à droite de 0
@`	0x37	[{	0x2f	À droite de la touche P
[{	0x38	]}	0x30	Deuxième touche à droite de P
]}	0x3B	Non-US # and ~	0x32	Troisième touche à droite de L
;+	0x39	;:	0x33	Première touche à droite de L
:*	0x3A	'"	0x34	Deuxième touche à droite de L
半角・全角	0x3F	`~	0x35
,<	0x3C	,<	0x36
.>	0x3D	,>	0x37
/?	0x3E	/?	0x38
Caps lock・英数	0x53	Caps lock	0x39
F1 - F12	0x40 - 0x4B	F1 - F12	0x3A - 0x46
Scroll lock	0x0A	Scroll lock	0x47	Accessible via FN
Insert	0x4d	Insert	0x49
Home	0x06	Home	0x4A	Accessible via FN
PgUp	0x08	PgUp	0x4B	Accessible via FN
Delete	0x4E	Delete	0x4C
End	0x07	End	0x4D	Accessible via FN
PgDn	0x09	PgDn	0x4E	Accessible via FN
Right(→)	0x5F	RightArrow	0x4F
Left(←)	0x5C	LeftArrow	0x50
Down(↓)	0x5D	DownArrow	0x51
Up(↑)	0x5E	UpArrow	0x52
Enter	0x61	Enter	0x58
\_	0x3F	International 1	0x87	Touche supplémentaire aprés /? [HID usage tables Footnote 15-20]
カタカナ・ひらがな	0x5B	International 2	0x88
¥|	0x36	International 3	0x89	Touche supplémentaire avant «back-space»
全候補・変換（次候補）	0x5A	International 4	0x8A
無変換	0x58	International 5	0x8B
CTRL (gauche)	0x56	Left control	0xE0
SHIFT (gauche)	0x54	Left shift	0xE1
SHIFT (droite)	0x55	Right shift	0xE5
ALT (gauche)	0x57	Right alt	0xE6	À gauche sur clavier, mais requis pour l'accès aux fonctions alternatives telles que 漢字、漢字番号、全候補 et ローマ字

---

Références:
^[1] Joy-Bus Devices, section 9.1, ID and Device List
^[2] Joy-Bus Devices, secion 9.3.2, Scancodes

Support Bongo DK

Les Bongo DK fonctionnent comme une manette normale et est donc supporté par l'adaptateur sans complications.

Élément Bongo	Équivalent manette
Tambour gauche (centre)	Y
Tambour gauche (avant)	B
Tambour droit (centre)	X
Tambour droit (avant)	A
Bouton start	Start
Microphone	Bouton R, intensité liée au son

Références

Informations techniques à propos des manettes de Nintendo 64:
http://www.mixdown.ca/n64dev/

Informations techniques à propos des manettes de Gamecube:
http://www.int03.co.uk/crema/hardware/gamecube/gc-control.htm

Le 'pinout' des manettes de Nintendo 64 apparait sur ces pages:
http://www.hardwarebook.info/N64_Controller
http://www.fpga-games.com/n64tst.htm

Avertissement

Je ne saurais être tenu responsable pour les dommages que l'utilisation des informations ou la mise en œuvre des instructions présentées sur cette page pourrait causer à votre équipement, à vous-même ou à autrui. Aussi, je ne donne aucune garantie quant à l'exactitude des informations et à leur fonctionnement.