2019年7月22日月曜日

IONA JVSIO 近況

最近また自作JVSIOをいじってます。



こんなツイートしてたんで想像つくかとは思いますが、近々店頭で頒布できるかと。当初は可能な限り安くキットの形で〜とか思ってたんだけど、表面実装でキットは厳しいかな……という事で完成品として。

Arduinoで試してくれた方もボチボチ国内外にいらっしゃり、動作情報も集まってきましたが、特殊な入力装置を使ってない限りは大手の主要システム基板で問題なく動いているようです。具体的に確認されてるのは

  • SEGA naomi
  • namco System 12/245/256
  • TAITO Type X2
あたりになります。

売りは
  • 低遅延（SEGA IOより2フレーム前後低遅延なのは動画解析により確認済み）
  • シンクロ連射内蔵（毎フレーム発行される入力取得コマンドに同期）
  • 省スペース
  • 安価かつ新品
ってあたりです。アケコンに埋め込んだりもできるサイズ。逆に欠点は
  • 入力以外は未対応（音声・映像等の変換はせず、パススルー用端子のみ搭載）
  • 複数のIOをデイジーチェーンで繋ぐことはできない（常に1台でターミネート）
通常の用途で問題になるような事はないかなぁ、とは思っていますが。

それはともかくとして、Type X2を試した時にクレジットが減り続けるバグがありまして。

こんなの。で、調べてたら面白い事に気づきました。JVSはIO側でクレジットの残数を管理していて、ゲーム側が問い合わせて残りのクレジット数を確認し、画面に表示するという仕組みになってるんだけど、この扱いがメーカー毎に全部違った。

一番素直なのはナムコ。クレジット数を問い合わせて画面に表示、クレジットを使った時にIOにクレジットを1減らすように依頼。次に問い合わせた時は減ったクレジット数が返ってくるのでそれを素直に表示する。仕様が求めてる動作に思える。このメリットはゲーム側が落ちてもIO側で管理してるクレジット数は維持できる点。

TAITOはクレジット数を問い合わせて0でなければ即時クレジットを1減らすように依頼。ゲーム側で管理するクレジット数を内部的に増やし、そちらの数字を画面に表示。つまりはゲーム側で完全に管理しています。メリットはIOが落ちても……ってなりますけど、普通に考えるとIOの方が堅牢かな。しかもこの作りのせいでNESiCAとかゲーム間でクレジット持ち越せなくなってるのでわ疑惑。

最後のSEGAが一番トリッキーで。クレジット残数を問い合わせはするんだけど、クレジットを減らす依頼は一切なし。前回読んだ数字より増えていればゲーム側で管理するクレジットを増加、使ったらゲーム側で管理するクレジットのみ減らす作りらしい。内部で累積クレジット数の差分だけ見て動いてる。メリットは……あるのか不明。IOそのままでゲームが再起動すると、累積クレジット数を見ていきなりクレジットMAXになったりします。ロケでの運用考えるとリスクでしかないのでわ？！

という事で、後者になるほどソフトウェアの安定性に自信がある、と（笑）

で、件のバグですが、クレジット減算依頼の際、対象とすべきユニットがずれてました。なんとなく0スタートだと思ってたんですが、正しくは1P側クレジットはユニット1、2P側クレジットはユニット2でした。問題のケースでは

  1. コイン投入、IO内のユニット1のコインカウントが1に
  2. ゲーム側でコイン数を読み出し、クレジットの存在を確認
  3. 即時コイン回収のためユニット1のクレジット減算を依頼
  4. バグのためユニット2のクレジットを減算してしまい-1枚（255枚）になる
  5. ゲーム側でコイン数を読み出し、クレジットが合計で256枚もある！
  6. 即時コイン回収のためユニット1とユニット2のクレジット減算を依頼
  7. バグのためユニット2のクレジットのみ減算して-2枚（254枚）になる
  8. ゲーム側でコイン数を読み出し、クレジットは合計でまだ255枚…
  9. 以下、6へ戻り繰り返しながらクレジットは256→1→256→…とループ
これがnamcoだとクレジットが減らないだけ、SEGAだと減算依頼しないので問題なし、という結果になっておりました。標準化って難しいですね。
投稿者 時刻:
ラベル: , ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)