IONAのデイジーチェーン対応

さっそくJVS I/O Monitorを使ってデバッグしてみた。

正常動作、ionaはシリアルログも存在する

って事で、naomi → SEGA I/O → iona（ターミネート）って構成での動作テストとデバッグ。今までこの構成だとnaomiが2台のデバイスを認識しつつもSEGA I/Oは反応なし、ionaは2番目のデバイスとして動作してた。この状況証拠だけでも気づけばバグの原因がわかったんだけど、残念ながらピンと来なくてモニター作りに精を出してしまいました。まぁ、便利な技術は色々と身についたから良しとする。

ちなみに、上の雑な基板がNEOGEO mini解析した時に作ったやつ。単純にUSBの信号を引き出すだけでパススルーするもの。下のやつがSTM32ベースの自作基板で、今回はJVSIOを監視してUSBシリアルとしてホストにデータ転送するファームを入れたもの。4端子だけフリーにしてあったのでGNDとD+に接続するヘッダを取り付け、D+を分圧してGPIOに入力。STM32は3.3V IOの子なんだな。大丈夫だろーと最初は適当に直結してたんですが、2個目を壊した所で現実を直視しました。石はいっぱい在庫あったので載せ替えるだけ、1つ130円くらいの損失です（人件費除く……面倒だった）。

合体！

ログを見て判明したのは、リセットからNode 1、Node 2のアドレス設定までは正常、その後のNode 1に対するクエリは全部応答がなく、Node 2宛てのGet I/O IDでionaが応答を返し始める事、後半の入力取得時には大きめのパケットをやり取りするんだけど、ここでチェックサムエラー出まくりな事。たぶん2台で応答返して信号衝突が起きてる。で、改めて考えてみたらionaがNode 2なのはおかしい。JVSは基本共有バスを張ることになるんだけど、SENSE信号だけはホップ毎に分離されており、このSENSE信号の取り決めに従い末端から順にアドレスを確定していく。なので最初のNode 1のアドレス設定がiona、次のNode 2がSEGA I/Oにならないとおかしい。

で、気づいたのがBroadcastの扱い。リセットやアドレス設定はBroadcastアドレス宛てに飛んでくるので各デバイスは設定済みアドレスかBroadcast宛てのパケットを受信しないといけないんだけど、アドレスに関しては設定済みの時は無視しないといけない。この部分がマルチデバイス対応のコード入れた時に落ちてしまった。って事で、ここを直したら無事に2台ともに正常認識されるようになりました。

こんな感じですね。ionaはJVS最初期のnaomiより上位のバージョンを返します。機能は存在の有無は別としてnaomiタイトルのチェックをパスするように選んでるのでSEGA I/Oの上位互換。

という事で、正常時の起動シーケンスはこんな感じ。定常モードに入ったら約60fpsで入力取得になります。なのでシンクロ連射入れたければ、ビデオのSYNCを見るよりこのタイミングに連動させた方が簡単で確実です。コインだけは120fpsなので60連射できそうです。