Gamecube Controller Sniffer: Unterschied zwischen den Versionen
HKay (Diskussion | Beiträge) (weiteres beispiel video) |
HKay (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
| (5 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
=Projekt eingestell= |
|||
Es besteht kein Bedarf mehr. Daher wurde das Projekt eingestellt |
|||
==Ziel== |
==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. |
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 |
* Erkennen welche tasten gedrueckt wurden |
||
* |
* Erkennen wie schnell tasten gedrueckt werden (mashing meter) |
||
* Visuelles feedback wie zeitgenau bestimmte Eingaberhythmen eingehalten werden. |
* 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) |
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== |
==Verantwortlich== |
||
| Zeile 20: | Zeile 22: | ||
==Probleme== |
==Probleme== |
||
Das USB example von LibOpenCM3 ist veraltet und laeuft nichtmehr auf der referenz hardware. |
(fixed)Das USB example von LibOpenCM3 ist veraltet und laeuft nichtmehr auf der referenz hardware. |
||
Das kabel hat einen Wackelkontakt und erzeugt auf ungeklaerte weise bitfehler die allerdings auf dem Oszilloskop wie ein gutes Signal aussehen(widerspruch!). |
|||
| Zeile 27: | Zeile 28: | ||
==Status== |
==Status== |
||
* Bus Protokoll verifiziert. |
* Bus Protokoll verifiziert. |
||
* Bus Protokoll fuer den N64 ist identisch |
|||
* USB wird auf dem OLIMEX stm32-h107 evalboard in betrieb genommen |
* 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. |
|||
| Zeile 34: | Zeile 37: | ||
* GUI Software schreiben |
* GUI Software schreiben |
||
* Firmware 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]] |
|||
|} |
|||
| Zeile 41: | Zeile 71: | ||
==Files== |
==Files== |
||
[[Category:Projekt]] |
[[Category:Projekt]] |
||
{{Abgeschlossen}} |
|||
Aktuelle Version vom 4. Februar 2018, 02:52 Uhr
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 livestreams verwenden.
- Erkennen welche tasten gedrueckt wurden
- Erkennen wie schnell tasten gedrueckt werden (mashing meter)
- Visuelles feedback wie zeitgenau bestimmte Eingaberhythmen eingehalten werden.
Optisches Vorbild: Der PS3 Controller visualiser oder 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.
ToDo
- 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.
| GameCube | N64 Controller |
Artikel
Files
Dieses Projekt ist abgeschlossen.
Keine Sorge, wir haben noch einen Haufen anderer Projekte, an denen du dich beteiligen kannst ;)