2019年10月5日から2019年10月1日までの日記を表示中
2019年10月 5日 (土)
■夢をみる島
夢をみる島、やり残しを進めています。とりあえず赤い服取って、フィギュア終わらせて(キャンキャンの台座がどこにあるかわからず、そこから進んでいなかったw)、ダンペイのダンジョンをちょっと進めたくらい。
うーん、しかし、この感じ、やっぱり裏とかないのかな。だいぶ物足りない・・・(´・ω・`)
2019年10月 4日 (金)
■テトリス99
超今さらながら、Tスピンとはどういうものかを理解w。ダブルは本番でも割と普通に出せるけど、トリプルは超頑張らないと無理っすな(汗)
[コメントを書く]
■移動
スマホの機種変サポート的な用事で実家へ。ばっちりSIMフリースマホを用意して行ったのに、まずauの4桁の暗証番号がわからず、結局近所のauショップに行く羽目にw。まあ、ついでに無駄に高いデータプランを脱却てきたのは良かったですが。
[コメントを書く]
2019年10月 3日 (木)
■夢をみる島
夢をみる島、とりあえずエンディングに到達。全体的にボス戦が緩いというか、他のシリーズ作品に比べて弱点がわかりにくい一方で、攻撃自体は割と単調な印象だったんで、このまま裏に突入するのかなと思ったら、そのまま終わっちゃったみたいな。まあ、何かまだやり残したことあるみたいなんで、もう少し遊んでみる予定ですが・・・。
[コメントを書く]
2019年10月 2日 (水)
■基板
IONA-JSでは、サービススイッチのピン(基板上のTXD)をシリアルのデバッグ出力に使えるようなので、クレジットの処理がおかしなコナミ80'sアーケードギャラリーで何が起きているのか、デバッグメッセージを出力させるようにして調べてみることに。
デバッグメッセージ出力自体は、MakefileのCFLAGSから「-DNO_DEBUG」を消してmakeし直せば有効になるようです。また、シリアル出力は、Arduino Unoで受けて表示することができます。こちらで紹介されているArduino Uno同士のシリアル通信の受信側のプログラムを下記のようにいじって、PCからArduino Uno側に書き込み、そのままArduino IDEのシリアルモニタを開いておきます。
void setup(){ Serial.begin(115200); Serial.println("Start reading."); } void loop(){ while(Serial.available()){ char inChar = char(Serial.read()); Serial.print(inChar); } }
で、IONA-JSとArduino UnoのGNDを繋いだ上で、IONA-JSのTXDをArduino UnoのRXに接続。
これで、IONA-JSのデバッグ出力が、PCのシリアルモニタに出てきます。さて、気になる基板側の挙動はと言うと・・・。何と、起動直後、リセットを打ち込んだ後で「コインスロットのindexに0を指定してクレジットを0減らす」という、謎の空コマンドを打ち込んで来ていることが判明。
ということは、これをトリガとして、indexに0を指定してくる規格違反(?)の基板ということを検出 → この基板は「コインスロットのindexが0ベースの変な基板」として扱う・・・ということをやってやれば、今回の問題はシンプルに解決できそうですね。
ちなみに、実際、1P側のクレジットを叩くとindex = 0のコイン減算コマンドが、2P側のクレジットを叩くとindex = 1のコイン減算コマンドが、それぞれ基板から送られてくることは確認済みです (「SubCoin」の次の行に表示されている3文字の1文字目がindexで3文字目が減算するコイン数)。
しかしこの挙動、何なんでしょうね。ソフトが悪いのか、マザーボードのBIOS (?) が悪いのか、あるいは単に初期のJVS規格だとこれが普通だったのか・・・。後で、他の573のソフトと入れ替えるとか、他の573マザーにコナミ80'sギャラリーを入れてみるとかして、調べてみましょう。
ちなみに、IONA-JSのシリアル出力、あっさり認識できたように書いていますが、実は当初、何も考えずにDsub9ピン経由でPCのUSB-シリアル変換アダプタを通してPCに接続してしまい、全然データが拾えずに超ハマっていたりしますw (信号レベルがRS232Cと全然違うはずなんで、拾えるわけないんですよね・・・恥ずかしい・・・)
[コメントを書く]
2019年10月1日 (火)
■基板
IONA-JS 1.10のソースコードのクレジット回りの処理部分を、JVSの規格書と合わせて眺めてみました。
JVS規格では、JVS IOがコインをカウントしており、ホスト(基板)からの問い合わせに対して回答するようになっているようです。また、これとは別に、JVS IOで数えているクレジット数を減算させる命令も用意されています。
とりあえず、クレジット加算の処理は、既にチャタリング対策っぽいものが入っていて、特に問題なさそうな感じでした。普通に動く分には、クレジットが入りっぱなしになるようには見えません。
一方で、減算の方は、基板側でクレジット投入を検出した後の、JVS IOに対するクレジット減算の指示が正しく処理できないと、無限にクレジット投入を検出し続けることになりそうです。
JVS規格によると、クレジットはスロットごとにカウントされていて、減算処理では対象スロットをindexで指定するようになっているんですが、このときのindexは1ベースで指定するようになっていて、1を指定すると最初のスロット(1Pのクレジット)が、2を指定すると2番目のスロット(2Pのクレジット)がそれぞれ減算されるようです。一方で、indexに0を指定した場合の挙動については特に記載がありません。IONA-JSのソースを見ると、もちろんJVS規格に従ってindexは1から始まるものとして書かれています。もし、基板側が、indexに0を指定していたら・・・。
そこで試しにIONA-JS側のクレジット減算処理を、indexを無視して減算を行うようにいじってみたところ、見事にクレジット無限投入問題が解消しました。やはり基板側からの減算対象指示が変みたいです。そしてさらにいじった結果、1Pのindexが0、2Pのindexが1となっていることがわかりました。基板側からは、0ベースで指定してきていることになりますね。
というわけで、無限クレジット投入問題の要因自体はわかりました。が、他の基板はindexは1ベースなわけで、これをどうやって解消すりゃいいのかがよくわかりませんね。当然、セガのJVS I/Oボードでは、このゲームのクレジット投入も正しく処理できているので、何かしらの方法で規格に違反していることを検知して対応していると思われるんですが、一体どうやっているのか・・・。もう少し調べてみましょう。
[コメントを書く]
■テトリス99
[コメントを書く]
2019年10月5日から2019年10月1日までの日記を表示中
[コメントを書く]