An die Bastler: PS2 Controller Protokoll

[Perfect007]

Meine Projektarbeit im Studium befasst sich mit einem Mikrocontroller (MSP430) und dem Playstation 2 Gamepad. Der Mikrocontroller soll die Signale der Konsole verstehen und darauf anworten, sprich Soft- und Hardwaremäßig soll ein Gamepad mit diesem Mikrocontroller emuliert werden.

Ich habe zwar Infos zum seriellen Datenrahmen etc. aus dem Internet und werde mich am Dienstag ins Labor begeben, um mittels eines Logic-Analyzers die Datenübertragung noch zu messen, aber vielleicht kennen sich hier zusätzlich einige in dieser Richtung aus. Ich meine mal, das Scorpion hier schon Erfahrungen gesammelt hat.

Alles, was mir bei diesem Projekt weiterhelfen kann, ist hier stets willkommen - Hinweise auf das Protokoll, C-Programme, Schaltungen - einfach alles hier bitte posten ... VIELEN DANK

[Schmichel]

Schau dir das mal an: http://www.gamesx.com/controldata/psxcont/psxcont.htm

An einem uC, der sowas kann und der evt auch noch einen Inkrementalgeber auswerten kann wäre ich sehr interessiert - leider kann ich nicht programmieren.

Michael

[Perfect007]

Jupp genau, diese Informationen haben Kollege und ich heute mittag ausgewertet und werden diese am Dienstag mal im Labor nachvollziehen. Das Protokoll ist nicht gerade einfach, aber sollte für einen Mikrocontroller machbar sein.

Frage: Was meinst du mit Inkrementalgeber?

Hier mal meine bisherigen Informationen für das Projekt:

Playstation 2
http://www.gamesx.com/controldata/psxcont/psxcont.htm
http://sophiateam.undrgnd.free.fr/psx/index.html
http://www.lynxmotion.com/Product.aspx? ... egoryID=44

Was ich zum GameCube noch gefunden habe:
http://www.int03.co.uk/crema/hardware/g ... ontrol.htm

[Perfect007]

So, heute gab es die ersten wirklichen Ergebnisse! Die mir aus dem Internet vorliegenden Fakten und Angaben bezüglich der seriellen Kommunikation zwischen der Playstation 2 Konsole und dem Gamepad haben sich bewahrheitet, was sich in einem Praxistest an einem Logic-Analyser gezeigt hat. Wer Interesse hat, kann sich folgende Kommunikationsbeispiele mal anschauen. Diese präsentieren alle nötigen Daten- und Steuerleitungen, die man für eine Verbindung braucht.

Dieses Schaubild stellt einen kompletten Datenrahmen dar, welcher 9 Byte sendet und somit alle Tasten und Werte des Pads an die Konsole überträgt - der PS2 Controller wurde dabei im Digitalmodus betrieben, was sich hier aber nur in dem zweiten Byte wirklich ablesen lässt. PS: Keine Taste wurde hier gedrückt.



Folgender Teilausschnitt zeigt das zweite Byte, in dem über Data der Controller der PS2-Konsole mitteilt, dass er im Digitalmodus betrieben wird (0x41 wird gesendet).



Und als letztes nur ein Beispiel von vielen. Das 5te Byte wird dargestellt, wobei hier die Dreiecktaste noch gedrückt wird - zu erkennen an dem Low-Signal in den Daten.



Das waren die ersten Ergebnisse .. nun kann es ja an die Prorgammierung des Mikrocontrollers gehen.

[Scorpion]

Hm, sieht sehr interessant aus!
Kenn mich mit dem Thema nicht wirklich aus, hab aber ein aehnliches Projekt in Vorbereitung in ferner Zukunft (USB Controller fuer Stepmania mit Anschluessen fuer Buttons + Cabinet Lights).

Weisst du mit welcher Taktrate der Status des PS2 Controllers abgefragt wird? Afaik hat Roxor mal erwaehnt es sollen nur 60Hz sein und hat die Timewindows der PS2 deswegen etwas vergroessert.

[Rodent]

Roxor hat nicht die TimingWindows vergrössert, sondern nur verschoben.

Es ist von einem Global Offset von +0.04 bei der Ps2 Version auszugehen, im Vergleich zu AC/ SM

LG
Alex

[Schmichel]

Roxor hat nicht die TimingWindows vergrössert, sondern nur verschoben.

Nein, sie haben das Window auch minimal (genau 2ms) wegen der geringeren Abfragerate vergrößert, es hat aber auf das Spielergebnis keinen nennenswerten Einfluss (wurde durch mehrere Tests ermittelt).

Michael

[Perfect007]

Die CLK-Frequenz liegt bei etwa 166 kHz, gemessen hatten wir ein T von 6 µs. Die Messung war aber sicherlich nicht genau!

Was das Timing anging, bezüglich zwei Abfragen, kann ich später noch ein Bild einer Messung online stellen, da sieht man eine relativ LANGE Pause zwischen zwei Datenrahmen! Ich weiß nicht, ob dies nun am SmartJoy liegt oder bei dem Protokoll generell üblich ist. Gemessen wurde der Datenrahmen und alles weitere mittels einer SmartJoy Verbindung und original PS2 Pad am PC.

EDIT:
Im Folgenden nun zwei Datenpakete, der Abstand beträgt grob gesagt 10 ms

[_bla_]

Ich hätte da noch verbuggten Code für einen Atmel Leider hab ich keinen Logikanalyser und damit wird das Debuggen dann doch sehr schwierig.
Eine vielleicht ganz nützliche Information hätte ich da aber noch für dich: Das serielle Protokoll wird auch gerne SPI genannt und die meisten Microcontroller haben Hardwareunterstützung dafür. Falls du das Protokoll komplett per Software implementierst wirst du vermutlich den Controller höher takten müssen. Bei 166 khz SPI Takt und 1 Mhz Kontrollertakt hast du nur 6 CPU Takte pro Bit, das wird nicht klappen schliesslich musst du auf die fallende und steigende Flanken pollen, per SPI Hardware dürfte das locker klappen.

[Perfect007]

Oh, da ist wahrlich ein sehr guter Hinweis! Dachte nicht, das dies einem weit verbreiteten Protokoll entspricht, bzw. Datenübertragung. Na dann schaue ich doch mal nach, was das Handbuch / Datenblatt meines MSP430 hergibt. Der Mikrocontroller hat auf jeden Fall eine SPI Schnittstelle, nur muss ich mich dann dort mal einarbeiten. Aber das ist wirklich ein sehr guter Hinweis! Vielen Dank!

PS: Ich habe einen normalen 32 KHz Quarz drauf, welcher aber nicht für dem MCLK verwendet wird (wäre ja schön blöd). Neben dem intern erzeugten Takt von 800 MHz kann bei Bedarf aber die CPU auch mit 8MHz getaktet werden (externer Quarz).

[themartin]

Hoi minasan.

Ich finde dein Projekt ja sehr interessant. Da ich ja schon einige Erfahrung mit Microcontroller habe, habe ich mich gleich mal rangesetzt und so einen Versuchsaufbau gebaut.

Heute habe ich dann den halben Tag programmiert und ein funktionierendes "Gamepad" hingekriegt. Ich habe den Microcontroller an meinen PSX to USB converter angschlossen und er erkennt das "Gamepad". Ich hab auch schon die Schalter implementiert, das heißt, ich kann Sschalter drücken und im Computer leuchten die Lampen für den Schalter auf.

Als Microkontroller nutze ich den ATMega8, welcher aber total überdimensioniert ist. (Ich habe ihn nur verwendet, weil er auf meiner Entwicklungsplatine ist). Ein 2313 oder ähnlicher reicht.
Der MC wird mit 8 Mhz getaktet, 4Mhz habe ich auch schon hingekriegt, da müsste ich aber meinen Code noch ein bisschen optimieren.

Der Quellcode ist in Assembler geschrieben und komplett Dokumentiert. Du kannst ihn hier runterladen.

Das Programm ist schon mehrmals getestet, mit Oszilloskop u.a.

Wenn Fragen sind, einfach fragen

Hinweis:

Bei den ganzen Information über das PSX Protokoll ist es ja eindeutig, dass alle Leitungen Low-Aktiv sind. Aber dann lese ich, dass z. B. der "start command" Befehl 0x01 ist. Das stimme aber nur, wenn die Leitungen High-Aktiv wären. Eigentlich ist der Wert 0xFE. Ich hab aber ein Programm angepasst, dass jemand, der das ließt, nicht verwirrt ist.

mfg, Martin

[_bla_]

Jo, Fragen sind da, warum benutzt du nicht die SPI Hardware des ATMega8? Mit der sollte eigentlich ein SPI Takt von bis zu 1/4 des MCU Taktes möglich sein, da würden für die 166khz also schon 1 Mhz reichen.

[_bla_]

Hinweis:

Bei den ganzen Information über das PSX Protokoll ist es ja eindeutig, dass alle Leitungen Low-Aktiv sind. Aber dann lese ich, dass z. B. der "start command" Befehl 0x01 ist. Das stimme aber nur, wenn die Leitungen High-Aktiv wären. Eigentlich ist der Wert 0xFE. Ich hab aber ein Programm angepasst, dass jemand, der das ließt, nicht verwirrt ist.

O.O Das war DER Hinweis, ich hab mein altes Programm angepasst und die Werte invertiert, und schon klappt es. Ist übrigens auch für einen ATMega8, aber nutzt die SPI Hardware. Ich werde jetzt noch etwas experimentieren und den ganzen Debugcode rausschmeissen, und dann landet es auch hier.

[Perfect007]

Ey, finde ich cool, dass dieses Projekt hier so viel Aufmerksamkeit erregt

Den Assambler Code werde ich mir dann die Tage wohl mal anschauen und bin auch schon auf den anderen Code gespannt. Persönlich muss bzw. möcht ich das mit einem MSP430 zum Laufen bringen. Habe einen 1611er, der wohl insgesamt auch etwas Überdimensioniert ist. Aber das ist der einzige Controller, den ich nun daheim rumfliegen habe und daher wird auch dieser genommen. Bin mal gespannt, ob ich das Ganze dann auch entsprächend hinbekomme. Wenn das zu schnell geht, muss ich mir mal überlegen, ob ich nicht auch noch weiteren Schnick-Schnack einbaue

Verwendete Mikrocontroller-Platine:
http://www.tecnotron.de/msp4_cm1611.htm

[themartin]

Jo, Fragen sind da, warum benutzt du nicht die SPI Hardware des ATMega8?

Stimmt, ich kannte die nur noch nicht aber das geht ja viel einfacher als meine Variante (aber sie geht auch rein Softwaremäßig)

Hab mich dann wieder gleich rangesetzt und die gleiche Sache mit SPI programmiert. Link hier.

mfg, Martin