ゲームキューブインタフェース解析(キーボードだけね)



ここにある情報は確かなものではありません。
この情報を使用した人が何らかの不利益を受けても知りません。
自己責任で。

キーボード変換アダプタはこちら



GCは双方向シリアルの半二重通信。通信に必要な信号線は1本だけ。
クロックは無し。というか信号と一緒。信号の立ち下がりがビットの先頭になる。
立ち上がるタイミングが早い(1)か遅い(0)かで1と0を区別している。
GC、キーボード共に、出力データの最後にはストップビット(1)が付加される。
スタートビットは無い。



電源投入(機器接続)から、同期までの部分の波形はこんな感じ



1.なにも接続していないとき
GCからは周期的に8bitの0が出力される。
周辺機器はこれを元に動作を開始する。

2はとりあえず、周辺機器内部で1.の信号の境目を検出したところ。
1bit分の時間以上Hが持続したらそこが境目かと。

3.なにか接続したとき(ここではキーボード限定)
周辺機器が接続されると、GCが出している8bitの0に続けて、
周辺機器が3Byteの応答を返す。
キーボードの場合は0x08、0x20、0x00の3Byte。
もしかしたらこの3Byteがデバイス種別とかを表してるかもしれないけど不明。
キボコン付属のコントローラを繋ぐと、ここがきちんと見られなかった。
純正コントローラは未確認。

3.キーボードが最初の応答を返すと、次にGCは8bitの1を出力する。
これに対するキーボードの応答は、8bitの0が出力されたときと同じ。
0x08、0x20、0x00と出る。

4.この後は実際の入力データ処理になる。
まずGCから3Byteが出力される。
これに続けるようにしてキーボードからは8Byte出力される。これが延々と続く。

この一連のやりとりは、周期的(1/60程度)に行われるのだが、
計11Byteの一連の信号が出力されてから、次の11Byteが出力されるまでは
短い間隔と長い間隔が存在している。
キーボードの出力データの中には、カウンタと思われるデータがある(下記参照)のだが、
そこを見る限り、長い間隔を挟む2つの信号の組み合わせが1セットのように見える。
カウンタの変化は、0→(長い)→0→(短い)→1→(長い)→1→(短い)→2→…
となっている。ちょっとあやふや。どっちでも動作にはあんまり関係ないようだ。

同期完了後の波形はこんな感じ
これはキーボードの[A]を押したとき。



GCの出力フォーマットは常に固定。
色々ためしてみたが、変化しなかった。

キーボードのデータフォーマットは以下の通り。

1Byte目の下位4bitはカウンタ。2回に1回変化してる。
接続して同期が取れてから、7回ぐらいは0のままになってる。
上位4bitは0固定みたい。

2〜4Byte目は常にALL0が出力されている。
おそらく使っていないのだろう。

5〜7Byte目は現在押されてるキーのキーコードが入る。
キーを複数個押している場合は、先に押されたキーが5Byte目、次に押されたキーが6Byte目、
というふうに同時に送信される。
ただ、押されるキーの組み合わせによっては、3個まで送れるパターンと2個
または1個しか送れないパターンがあるみたい。
押されているキーの数が一定数以上になると、キーコードが表示されずに
3Byteとも同じ値で、あふれているキーの個数が出力される。
5個押してたら0x02が3カ所に出る。
このあたりは少々複雑で、あふれ表示のトリガは数パターンあるみたい。

8Byte目は、1Byte目と5〜7ByteのXOR。おそらくパリティだろう。



キーコードのマップはこんな感じ。

上位4bit
0123456
下位4bit0(未使用)AQ7F1BS(未使用)
1BR8F2TABEnter
2CS9F3(未使用)(未使用)
3DT0F4CAPS
4EU-F5L_Shift
5FV^F6R_Shift
6HOMEGW\F7CTRL
7ENDHX@F8ALT
8PageUpIY[F9無変換
9PageDownJZ;F10Space
AScrLockK1:F11前候補
B(未使用)L2]F12ローマ字
CM3,ESC
DN4.INS
EO5/DEL
FP6半角/全角

[Fn]キーだけ押してもキーコードは出力されない。
[\]の刻印があるキーを押しても¥は表示されない。[\]になる。






CREMA.CO.UKさんのところにコントローラの解析結果があるようです。




back