naomiのガンコン対応ゲームをお家で遊ぶぞい

IONA-USを作ったので、USBのコントローラさえ存在すれば、あとはファームウェアなんとかするだけでJVSの特殊コントローラとして動作させる事ができる。そんなわけで、今回はアーケードゲームを家庭で遊ぶ上でやっかいなガンシューに対応してみようと思います。

まず肝心なのは、液晶環境で動作する汎用ガンコンを見つけるところ。調べたところ、どうやらPS3のタイムクライシス4に付属していたガンコン3が液晶でも遊べるとのこと。ヤフオクなどで5,000円前後くらいで入手できそうです。同時期に同じような仕組みでPC向けなどに出ていたガンコン（TopGun III、Single Arcade Guns、ArmTrak）もあるようなのですが、10年前、20年前ならまだしも、今は入手が難しいですね。Cabela's Top Shot Elite Firearm ControllerってのがWii/PS3/Xbox 360のバリエーションがあって辛うじてebayで手に入るかな。playasiaにあったので注文したら「ごめん、やっぱなかった」って払い戻し面倒でした。って事で日本ならガンコン３が入手性の面でもオススメ。現実的な値段で入手するならガンコン3がレア化するギリギリ前の今が最後のチャンスなのかもしれません。おそらくFPS勢は既にVRに行っちゃってますからね。モニタの座標をとる必要のあるUSBデバイスとかPS4世代以降は需要がないんだと思います。Switchのジョイコンのセンサーにアタッチメントってあたりならワンチャン……って感じなのかな。

ガンコン3の設置はそこまで難しくなくて。USBから電源だけとってる2つのマーカーLEDがあり、これをモニタの左上、右上に正面を向けて置くだけ。電源もらってるだけなので、このUSBは充電アダプタとかに繋げるのでもOK。一方でガンコン側のUSBとしての挙動は少し複雑。期待してたのは標準的なPS3互換のレポートでアナログ部分に座標が入ってくるってくらいだったんだけど、完全に独自クラスどころか、表向きは1ポートのUSB Hubで、その向こうにベンダー固有クラスを使ったデバイスが仮想的に接続され、データをシャッフルして通信する独自プロトコルになってます。これ、先行して調べてくれてる人がいなかったら面倒で投げ出してましたね。ちなみにこの人が調べてるのはHubの向こうに仮想的にぶら下がってるデバイスのプロトコルのみ。ハブ部分は標準通りなので一般的なOSならシステムが処理してくれて、ハブ越しに現れるデバイスのドライバさえ書いてやれば動く。という事で、IONA-USにはハブの簡易対応コードを追加し、その上でこの独自デバイスを仮想HIDとして扱い、そこからJVSにマップしてやるコードを追加しました。

JVSへのマップについてはnaomiのDeath Crimson OXに対応してみました。アナログ0と1が1PのX座標とY座標、アナログ2と3が2PのX座標とY座標になってます。それぞれボタン1がショットという素直な配置。スタートボタンも必要だったのでA1っていうボタンをアサインしました。

こいつ、動くぞ！
という事でデス様OX@naomiです。 pic.twitter.com/7twF9bCIrC

— とよしま (@toyoshim) October 31, 2021

画面内・外の判定はキャリブレーションをやればゲーム側で勝手に判定してくれます。最初、キャリブレーションをIONA側でやるとしたら大変だなーって思ってたんですよ。マイコン的にはクロックはそこそこ早いとは言えアーキテクチャは8051ですから。ホモグラフィ変換行列の計算（プロジェクションマッピングとかと同種の計算ですね）とか、自前で浮動小数点と三角関数を用意しないとかなーって。でもゲーム側でキャリブレーションするなら生のデータを送ってやれば最低限はOK。デバイス的には見える世界を二次元の投影で理解して、マーカーの位置から向いてる方向を計算しているだけの値が上がってきます。各地点で奥行きの距離とか考えて歪補正したりはしてません（そこまで自動でやるにはマーカーは4つ必要だし）。

ただ、ゲーム側のキャリブレーションもそこまで真面目な計算はやってないんですよね。なので、基本的にはモニタの真正面から、投影に歪みの出ない位置関係で遊んでやるのが望ましい。という事で、本当はIONA側でホモグラフィ変換かけてやれば追跡精度も上がるんだろうなぁ。キャリブレーションが2重になってわかりにくくなっちゃうけど、設定モードつけて画面4隅をマークさせればホモグラフィー行列も求められて、斜めから撃ってもゲーム側では補正された正方形とかで判定できます。まぁ、今の所そこまでやる予定はないですが、興味ある方の改造をお待ちしております（笑）。ただ、ファームウェアサイズ的にはメインに取り込むにはキツイとは思ってるのでマージできるかはサイズ次第かな。

という事で、実際に遊んでみた動画がこちら。

Play DeathCrimson OX with iona-us + guncon3 pic.twitter.com/OSGB6k9Vxk

— とよしま (@toyoshim) November 3, 2021

1.31から正式に対応してます。 

SDCC for PIC Tips

PIC18F14K50でUSBデバイスを作るのにSDCCを使ってみた。PIC18F2550系とは互換性がないという事前情報だったけど、レジスタ並びやUSB用RAMのアドレスが違うくらいで、基本的にUSB周りのコードはほぼそのまま動きそう。

むしろハマったのはSDCC周辺。このあたり、やっぱり非公式ツールチェインは辛い。大きくハマったのは次の2点。

1. bootloaderを使おうとすると色々細工が必要で、信頼できるコードが書けない
2. USB用RAMのポインタをアドレスから普通に作ると動かない

bootloaderについて、まずtext領域を後ろ（0x800以降）にずらすために専用のリンカスクリプトを用意する必要がある。コンパイラオプションにもそれっぽい--code-locというのがあるが、指定しても動かなかった。また、割り込みベクタはbootloader側がトラップして後ろのアドレスにフォワードしてくれるので、後ろのずれた位置に割り込みベクタを配置する必要がある。こっちはコンパイラオプション--ivt-loc=0x800が正しく動く。また、crtが通常の配置を想定したコード（割り込み周りかな？）を持っているようで、ふとしたタイミングで暴走する。stdio/stdlib使ってなくても、例えばcharをやめてintでforループを回すと暴走、とか悩ましい問題が普通に起きる。海外サイトでcrtを同じフラグでコンパイルし直せば安定する、という話も見かけたけど、どこまで信じていいかわからない状態で実験を続けたくなかったので、bootloaderは諦めた。回路側でバランスをとったら、なんとかICSP指しっぱなしで書き込みしつつ、USBバスも安定ドライブできた。

USB用RAMについてはコンパイラの問題とは思わずに長時間悩んだ。いわゆるBuffer Descriptor Tableを構成するコード。コンパイラの仕様が変わったのか、バグなのか、2550の時のコードからアドレス変えただけでは動かなかった。具体的にはstruct bd* bdt = (struct bd*)0x0200;的な事をやってアドレスを作ってたんだけど、今回はこのポインタで読み書きしても値が変わっていなかった。起動すれば一応USBはしゃべるんだけど。アドレスリセットとパワーセーブ関連の割り込みだけ届いて、その後はだんまり。トランザクションが届かないってことはエンドポイントが正しく初期化できてないのかなぁ・・・というあたりから問題の目星をつけた。結局コンパイル結果を眺めながらの間違い探し。原因が判明してからは、正しい出力を出せそうな表記を勘を頼りに探すお仕事。通らないと承知で間違ったキャストをコンパイラにかけると、内部的な秘密の型がエラーメッセージを通して推測できるのでオススメ。

__at(0x0200) struct bd BD0;static struct bd __near* const bdt = &BD0;

あと、やっぱり配列でアクセスしたくなるUEP0, UEP1, ...なんかもchar *uep = (char*)&UEP0; uep[0] = ...とか書くと正しくアクセスできない。

static __sfr* uep = &UEP0;static __UEP0bits_t* uepbits = &UEP0bits;uep[0] = 0;uepbits[0].EPHSHK = 1;

って感じの__sfr*という特殊な指定が必要。特定用途レジスタの略だと思う。こっちはシステムヘッダを眺めて予想。

HIDじゃないSPX

とりあえず手元のAKI-PICで焼けるPIC18F2550で作ったpic18spx（オリジナルそのまま版）と、それを使ってPIC18F14K50に焼いて作った非HID化改造版pic18spx。

非HID化によりOS Xでも動くようになりました。あと、次にbuildしようとした時にbuildできる環境が作れる気がしないのでhexをウェブ上に置きました。必要になったらここからダウンロードして焼くべし＞未来の自分。

あと、昔tcl/tkで書いたhidspx用のGUIが昔の記事にあります。開発中はもっぱらmakeを叩くんだけど、デバイスを確認する時とか、FUSEの値を確認する時、今でも使ってます。

しかし、環境乗り換えの時間的コストは高いな、やっぱり。

pic18spx/mac

HIDクラスを使ってるとOS Xで標準ドライバから制御が奪えない問題。HIDをやめれば解決するかな、と思って試したら解決した。具体的にはUSBデスクリプタのインタフェースクラスをHIDからベンダ固有値0xffに変えるだけ。picmonとか特に修正しなくても、そのまま利用できる。

むしろpic18spxのファームのbuild環境を整えるのに苦戦した。mcc18向けに書かれてるんだけど、現在はmcc18は配布されておらずMPLABXとXC8が標準。いっそXC8かSDCCに移植しようかと思ったけど、そこまで時間かけても仕方ないかな、と思って大昔のディスクを漁ってmcc18をインストール。持ってたのはMPLAB-C18-Academic-v3_30.exeとかいう古めのバージョンだったので、そのままではリンクできない。とりあえず$(TARGET).cofのビルドルールを以下のように変えて凌いだ。

$(LD) /l$(MCC18)/lib /k$(MCC18)/lkr rm$(DEVICE).lkr $(OBJS) \
/u_CRUNTIME /z__MPLAB_BUILD=1 /m$(TARGET).map /o$(TARGET).cof

とりあえず、自分のファーム作るときは最初からSDCC考えた方が良さそうだなぁ・・・。

18F2550 -> 18F14K50

本日14K50が届いたので準備の続き。先日ブレッドボードで組んだpic18spxはリセットボタンを付けて基板に載せました。部品点数少なすぎて基板がスカスカ。配線ガシャガシャしててもUSB側は安定してるんでリセットボタンいらなかったかも。書き込み用のピンは手元の機材ですぐに実験できるAVR用の2×3タイプのみ。

右が2550。TINY2313の読み出しを確認した後、左の14K50を使った2台目の書き込みに。書き込みにはpic18spx-2010-0416に付属のpicwriter.exeを利用。hidspxでいけるもんだと思い込んでて-rが成功せずにしばらく悩んだ。

新たにブレッドボードで動作確認。リセットをプルアップしてる以外はクロックと配線のみの超手抜き状態。ですが、安定動作してます。水晶は秋月で28.6円のSG531PAP。水晶のOUTをCLKINに繋げてCLKOUTは開放。設定変更くらい必要かと思ったけど、そのままで動いてる。こっちは基板では2×3と1×6両方付けるつもり。
と、ここまででようやく開発の準備が完了です。
そう言えば、フルスピードになると我が家のオシロでは対応できないので、ハード側でハマると死にそうです。