852
Bearbeitungen
Gamecube Controller Sniffer: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Gamecube Controller Sniffer (Quelltext anzeigen)
Version vom 4. Februar 2018, 02:52 Uhr
, 4. Februar 2018keine Bearbeitungszusammenfassung
HKay (Diskussion | Beiträge) (Init) |
HKay (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
| (7 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
|
=Projekt eingestell=
Es besteht kein Bedarf mehr. Daher wurde das Projekt eingestellt
==Ziel==
Ein PC soll in der Lage sein die Tasteneingaben auf einem Gamecube controller zu lesen. Gleichzeitig soll jedoch auch die Wii/Gamecube in der Lage sein mit dem controller zu sprechen. Diese Informationen sollen dann in einer GUI visualisiert werden. Schlussendlich werden Speedrunner den Aufbau in [http://www.youtube.com/watch?v=0M7IINwTFVw livestreams] verwenden.
* Erkennen welche tasten gedrueckt wurden
*
* Visuelles feedback wie zeitgenau bestimmte Eingaberhythmen eingehalten werden.
Optisches Vorbild: [http://www.youtube.com/watch?v=z9gTSNTeGsY Der PS3 Controller visualiser] oder [http://www.youtube.com/watch?v=JjM9zfdhIpM Siglemics custom controller grabber] der sogar das richtige Protokoll spricht (N64=Gamecube)
==Verantwortlich==
==Ansatz==
;2013-05-26: Ein Microcontroller liest den Bus des Controllers zur Wii mit. Die Daten werden dann ueber eine serielle Verbindung zu einem FTDI-Chip ubertragen, der auf USB umsetzt. Auf dem PC uebernimmt dann Software den Rest.
;2013-06-09: Leider reichen 16MHz CPU-Takt nicht aus um das Signal des Controllers zuverlaessig lesen zu koennen. Daher wird jetzt ein evaluations Board mit einer STM32F107 cpu benutzt, welches direkt USB sprechen soll. Mit 72MHz sollte es auch schnell genug sein.
==Probleme==
(fixed)Das USB example von LibOpenCM3 ist veraltet und laeuft nichtmehr auf der referenz hardware.
==Status==
* Bus Protokoll verifiziert.
* Bus Protokoll fuer den N64 ist identisch
* USB wird auf dem OLIMEX stm32-h107 evalboard in betrieb genommen
* Ein Atmega ist doch schnell genug und in kombination mit FTDI auch angenehm zu benutzen.
* GUI Software schreiben
* Firmware schreiben
== Das Protokoll ==
Wie berreits im unten verlinktem Artikel beschrieben kommen die Daten ueber einen einzelnen Pin ueber den Bus.
Erst spricht die Konsole und dann uebernimmt der Controller mitten im Datenstrom den Bus(erkennbar am erhoehten Jitter).
Die Bitclock ist im Datensignal enthalten und kann daher leicht asynchron gesnifft werden.
Jeder Taster entspricht einem bit im Protokoll. Analog Taster und Sticks haben zusaetzlich noch mehrbittige Daten weiter hintem im Datenstrom. Ein Bit besteht aus einem Low- und einem High-Teil. Je nach dem, welcher Pegel mehr Zeit im Bitsymbol beansprucht(Verhaeltnis: ein Drittel zu zwei Drittel) ist das bit eine 0 oder 1.
{| align="center" border="1"
| GameCube
| N64 Controller
|-
|
| [[Datei:N64-controller zoom0.png |left|160x120px|thumb|N64 controller zoom level 0]]
|-
| [[Datei:Gc-controller zoom1.png |left|160x120px|thumb|GameCube controller zoom level 1]]
| [[Datei:N64-controller zoom1.png |left|160x120px|thumb|N64 controller zoom level 1]]
|-
| [[Datei:Gc-controller zoom2.png |left|160x120px|thumb|GameCube controller zoom level 2]]
| [[Datei:N64-controller zoom2.png |left|160x120px|thumb|N64 controller zoom level 2]]
|-
| [[Datei:Gc-controller zoom3.png |left|160x120px|thumb|GameCube controller zoom level 3]]
| [[Datei:N64-controller zoom3.png |left|160x120px|thumb|N64 controller zoom level 3]]
|}
==Files==
[[Category:Projekt]]
{{Abgeschlossen}}
| |||