Gamecube Controller Sniffer: Unterschied zwischen den Versionen
HKay (Diskussion | Beiträge) (weiteres beispiel video) |
HKay (Diskussion | Beiträge) (pictures of the protocol) |
||
Zeile 20: | Zeile 20: | ||
==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!). |
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 27: | ||
==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 |
||
Zeile 34: | Zeile 35: | ||
* 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" |
|||
| N64 Controller |
|||
| GameCube |
|||
|- |
|||
| [[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 69: | ||
==Files== |
==Files== |
||
[[Category:Projekt]] |
[[Category:Projekt]] |
Version vom 14. September 2013, 01:47 Uhr
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
- Erkeinnen 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( Das kabel hat einen Wackelkontakt und erzeugt auf ungeklaerte weise bitfehler die allerdings auf dem Oszilloskop wie ein gutes Signal aussehen(widerspruch!).
Status
- Bus Protokoll verifiziert.
- Bus Protokoll fuer den N64 ist identisch
- USB wird auf dem OLIMEX stm32-h107 evalboard in betrieb genommen
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.
N64 Controller | GameCube |