9999年12月31日金曜日

当ブログにおける注意点

全般的な注意点

Basically, all articles are written in Japanese, but please feel free to ask me to translate or explain it via Twitter, etc. At GitHub, I'm using English usually.

本ブログは個人の意見を発信する場となっています。ここで記述された情報、意見は所属する組織とは一切関係ありません。

また、記述された情報を利用する事で発生した問題についても当方では一切責任は負えません。自己責任でお願いします。


電子工作・アーケード基板系の記事について


趣味で書いてる記事のため、わりと軽い感じで書いてたりはしますが、当方一応は電子工学学士、情報理工学修士です。元LSIの論理設計者でもあり、現役のソフトウェアエンジニアでもあります。適当にやってるようで実は難しい・あるいは危険を伴う事もあるので、専門的な知識、記事の理解なしに見よう見真似で試すのはやめて下さい。ソフトと違って不可逆な失敗のリスクはいたるところに転がっています。最悪、命を脅かすような事故にも繋がりますのでご留意下さい。不明な点はTwitter等で気軽に話しかけてもらえればアドバイスできる事もあるかもしれません。


ソフトウェア系の記事について


ソフトウェアに関しても低レイヤーの情報は一歩操作を誤るとデバイスの文鎮化、データの消失など重大な被害に繋がります。こちらも十分な知識なく、記事を鵜呑みにして実行するのはやめて下さい。


際どい技術情報について


特にメーカー保証の終了した基板の修理などは、修理・調査の過程で本来開示されていなかった技術情報、あるいは守秘義務によって守られるべき技術情報を偶発的に知ることが多々あります。調べた事は可能な限り共有しあう文化で育ってきたため、自分で調べた事は積極的に発信しています。その際、関係各所には配慮するなり、不利益がないよう考えてはいますが、所詮こちらの立場しか見えておらず、権利者からみたら不都合があるかもしれません。その際には連絡頂ければ直ちに双方にとって良い状況になるよう対処したいと考えています。よろしくお願いします。権利を持たない方からの警告等は対応いたしかねますが、個人的に妥当と思える場合には対処します。例えば権利は昔在籍した会社が所有するが、実際にその製品に関わっていた、といった人からの連絡などは間違いなく配慮します。

2019年8月20日火曜日

基板修理:タンブルポップ(進展なし)

完全無反応系ジャンク。カスタムばかりでCPUがどこにあるのかも分かりにくい。

タンブルポップとは直接関係ないけど、deco16ic.cppを見るとデータイースト製のカスタムについて一覧がある。これによれば上方にある52番はスプライト用の画像処理チップ、中央の56はタイル用の画像処理チップ、んで肝心のCPUは少し小さい59番らしい。

横長のQFPって事で標準的な68Kとはピン配置が違うのかなぁ、と思って調べる前に検索してみたら、Porchyさんが主要なピンは調べてくれてた。

CLKが57番って事で確認したら正しく入ってた。この基板、オープンだと中間電位取るみたいでCMOSから入った人間としてはギョッとなるんだけど、バスはきっちり0に張り付いてたのでHALTが入ってるわけでもなさそう。/RESETはPorchyさんの資料にはないんだけど、今回はわかりやすくPST518Aっていうリセット用トランジスタが近くにいたので、それを追いかけてみたらフィルタ→シュミットトリガINV→INVって流れで60に入ってたので、/RESETは60番で確定で良いと思う。となりの59にもHIGHが入ってたから並びの傾向的にここがHALTの可能性は高いかな。というかこれ、DIPの23→64→1→22って並びかも。ならHALTも確定。んー、そうなるとDTACK待ちか、バス解放待ちか、残りのピンを調べてみないとか。

ボード全体で見るとカスタム52はそれっぽく信号が流れてるけど、56と59は動いてない。PALも中間電位で浮いてるピンがあって怪しいなーって思ったんだけど、論理を展開して覗いてみたら未使用入力ピンだった。この辺りを壊してCMOSのGALでreproするって時は気をつけないと怖い。

2019年8月19日月曜日

基板修理:西遊降魔録(不完全)

今日手を付けようと思っていたまったく起動しない基板3枚のうちの1つ。

電源を入れると


こんな感じの画面で固まりっぱなし。映像系が最低限生きてる事は確認できるんだけど。

ひとまずCPUが動いてないか暴走してるのは確かだろうから、その辺から確認。まずはクロックを調べたんだけど、入ってないかなぁ……って事で、しばらくクロックを追いかけてました。12MHzを分周した1.5MHzで動いてるはずなので12MHzを探すと、なんか下ボードに。Double Dragonの回路図は探すと見つかったりするんだけど、チップ番号とか使ってる74は微妙に違う。けど論理はわりと似てるようなので参考にする事にしました。ボード繋いでるJ1、J2の端子とか、信号の並びが同じかも。少なくともタイミング系の信号は同じ。HCLKっていう6MHzがコネクタ通って上ボードに来ていて。ただ、このクロックがどこを通ってHD6809まで辿り着いてるのかなかなか追えない。

6809はハード側はあまり詳しくないので、気分転換がてら資料を漁っていると……どうやら同じHD6809でもEがつくやつはピン配置とクロックの扱いが違うらしい……って見るとHD6809Eって書いてあるし!通常の6809はXTAL/EXTALにクロック繋いで発振させ、EとQのクロックを外に出す事になってるんだけど、6809EはXTAL/EXTAL端子がなくて。外部で作ったEとQに合わせて動く仕様らしい。で、見たらEは1.5MHzが入ってた。

んじゃクロックは良いのかなって事で他の端子を見ていて/NMIが下がりっぱなしなのが気になっちゃって。調べたらVSYNC割り込みが入ってるらしいんだけど、これが下がりっぱなし。しばらく回路図見てたら、DFFの/Qが繋がってて、VSYNC来たら5Vに釣り上げられてるDを拾って/QがLOWになって割り込み。近くのデコーダ出力の1つがCLRに入ってて、同じく5Vに釣り上げられた/PREを拾って/QがHIGHに戻って割り込み解除。たぶんCPUからアドレス叩いて解除とかかな?ってなると、これはこれで正しそう。

って事でもう1度CPUに戻ってクロック周りみたら、Eは入ってるけどQが中間電位でフラフラしてた。あれ?なんでこんなに露骨に怪しいのに気づかなかったんだろう……。やっぱり慣れてない物をデバッグしてると決定的な状況証拠があってもスルーしがち。気づくと当たり前すぎて「なんで気づかないの?!」とか思っちゃうけど、やっぱり難しい。

で、Qはやっぱり下ボードから来てる。見た目じゃ全然わからないけど、テスターで追ってたら基板上のパタンで断線してました。パタンというか、たぶんビアですね。ガチガチに錆びてて半田も寄せ付けない状況だったので、ビアを補強で復活させる事はあきらめ、出力元チップの足からパッチしました。


ホコリだらけなのも気になるけど、下手に洗うとパタン壊しそうで……。これで電源を入れたら……


わーい、起動したけど化け化け(笑)背景パタンが崩れてスプライトは表示されず画面端でチラチラしてる物がある。起動時テストは通ってるのでCPUから見える範囲ではエラーないはずなんだけど。スプライトアトリビュートとかタイルマップ保存用のRAMあたりが死んでるかなぁ。ひとまず進展ありなのでメモだけとって、あとは次回のお楽しみ(?)

2019年8月18日日曜日

基板修理:ガンバード

詳細不明の彩京基板って事で手に入れたガンバード。基板の外見からガンバードだってとこまではわかってたんだけど基本ジャンク。起動してみたら一部のオブジェクトが化けていました。数ライン置きに黒く横ラインが入る感じ。それ以外は正常なので怪我として小さい。


この症状だと考えられるパタンは大きく2つあって。1つはオブジェ面やスプライトを合成する論理の故障。古めのタイトルなら基板上に汎用ロジックで組まれているので、面倒だけど流れる信号をモニタして出力間違ってるやつを探せばなんとかなる。新しめでカスタムチップの中だとお手上げ。もう1つはデータ格納してるROM周り。この手の化け方だとアドレス線かデータ線で断線がある可能性が濃厚だけど、メモリの故障パタンも同じような症例になる。

という事で、最初の切り分けは合成論理なのかデータなのか、という点。前者はキャラ化けが表示面についてくる、後者はパタンについてくる、という特徴がある。この辺はエミュレータ使って切り分けると楽で、画像系のROMを1つずつオール0の空ROMと置き換えて様子をみてやると良い。


こんな感じで、化けてたパタンのみが豆腐になった。って事でデータ側を疑う事に。一通り調べた限り、他のROMは正常のようです。

次はROMなのか配線なのか確認。本当なら外して読んでみるのが早いんだけど、今回対象だったu25はSOPのマスクROM。画像系はわりとマスクROMで基板に直半田って事が多いし、外すことを考えると実はSOPの方がDIPより楽、かな。でも、まずは配線の確認。u14、u15、u24、u25の4枚が並んでおり、ペアではなくそれぞれが16-bitsデータバスでリニアに配置されてるのがpsikyo.cppからわかります。ただ、故障のu25だけサイズが半分。だから他のがOKI製なのに、こいつだけSHARP製で仲間外れなのね。そこだけ気をつけて配線の確認に入ります。マスクROMのピンアサインは見つからない事も多いんですが、今回はOKIのM531602のデータが手に入りました。

NC1M53160244NC
A18244 PIN SOP43A19
A17342A8
A7441A9
A6540A10
A5639A11
A4738A12
A3837A13
A2936A14
A11035A15
A01134A16
/CE1233/BYTE
GND1332GND
/OE1431D15/A-1
D01530D7
D81629D14
D11728D6
D91827D13
D21926D5
D102025D12
D32124D4
D112123VCC

アドレスとデータは全部共有バスに繋がってるはずなので、u25とu24の対応する足の導通チェックをしていきます。調べたところ全部問題ありませんし、どうやらSHARPのLH538BNTとOKIのM531602は、サイズは違うけどピン配置は完全に同じようです。A19も繋がっているので、他のROMと同様に倍サイズ載せることもできるようです。

このサイズのROMを置き換えようとするとフラッシュしかなくて、フラッシュはだいたい3.3Vだったりするのですが、このサイズだとギリギリ5Vのフラッシュがありますね。AMDのAM29F800Bを使う事にしました。配置もほぼ一緒。ここでフラッシュを手配して、届くまでしばらくは修理はおあずけ。

届いてから修理再開です。



ヒートガンで綺麗に剥がれる。というか自作基板で表面実装を散々こなしてきたので、既存基板をいじるのも怖くなくなりました。外したROMを読んでエミュレータに突っ込んでみます。


化け方、完全一致。という事でフラッシュを焼いて半田付けします。

この際、フラッシュはピン配置が若干違うので注意が必要。


RY//BY1AM29F800B44/RESET
A18244 PIN SOP43/WE
A17342A8
A7441A9
A6540A10
A5639A11
A4738A12
A3837A13
A2936A14
A11035A15
A01134A16
/CE1233/BYTE
GND1332GND
/OE1431D15/A-1
D01530D7
D81629D14
D11728D6
D91827D13
D21926D5
D102025D12
D32124D4
D112123VCC

1番、43番、44番の3つ。

1番はBUSY出力でマスクROMではNCだった箇所なので特に対処しなくても良いのかもしれません。が、基板上でGNDや5Vにターミネートされてる可能性もあるので、安全のため足を上げておきます。

43番は書き込み制御。A19が来ているピンなので0になったり1になったりしますし、この石を読みに来た時は確実に0になってるのでアウトです(笑)。足を上げて電源に繋ぐ必要があります。

44番はリセット。これもNCでふらついていると動作しないので、同様に足を上げて電源に。


こんな感じで。見た目はイマイチだけど基板側にダメージ残すよりはこっちの方が好み。


はい、ばっちり。ってことで

大儲け〜♪

(ただし、人件費については考えない事とする)

2019年8月17日土曜日

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連射できそうです。

2019年8月16日金曜日

JVS I/O Monitor

しばらく前に海外からionaでマルチクライアントに対応できないかって相談があって。JVSIOってUSBケーブルでSCSIみたいにデイジーチェーン接続できる仕様なんですよね。今作ってる基板的には1台で2P対応できるし、特に必要な機能ってわけじゃないんだけど、コントローラ以外に特殊なI/Oが必要な時もあるかな、って。ソース状は対応しておいて、しばらくテストせずにいたわけですが、SEGA I/Oを1台目、ionaを2台目って構成ならすぐテストできる。というか、ionaの後ろに別のデバイスを接続するのはMP01-IONA-JSを使う限り口がないからできないんですが、こっちならできちゃう。そうなると動作確認はしておかないとまずいかな、と。

で、確認したら2台ともnaomiには認識されて、個別にアドレスは振られた模様。でもなぜかSEGA I/Oはアドレス持って認識されてはいるもののIDも空だし入力も送信できてない。なんか動作してないっぽい感じ。下流にいるionaはきっちり動作してるので電気的な問題じゃなさそう。となるとSEGA I/Oがなんらかの自粛モードに入ってるのか、ionaが通信を邪魔しちゃってるのか。これを調べるとなるとプロトコルアナライザーが必要だなー、と。

そこで作ることにしたのがJVS I/O Monitor。基本、D+に流れる信号をモニタしてやれば良いので難しくはありません。

こいつの出番

去年作った基板を使えばSTM32を使ってお手軽にUSBデバイスが作れますので、D+をモニタして解析した通信内容をログとしてUSBシリアルとしてホストに流してやるデバイスを検討。一晩もあれば作れるだろう……と思っていたのですが。

トラブルいっぱい。

USB側は慣れてたけど、USARTの扱いが色々といけてない。ログ解析をしながらUSBでデータを流しだし、USARTを取りこぼしなく処理する、というのはどうやら無理っぽいです。




という事で悲鳴の声。どうにも処理が安定しないので、デバイス側はログ収集に専念させ、ホスト側で解析をするよう方針を変えました。で、どうせホストでやるならWireshark使うよね?って事でざっくり調べてできそうな事を確認、方針を固めました。



しかしまた、いっきに遠回りに……。ホスト側の処理は正確にはシリアルから読んだ物をpcap形式にして名前付きパイプに書き込むって物でした。Wiresharkはデバイスだけじゃなくパイプを開いてログとる事もできるんですね。Linuxのシリアルも罠いっぱいで初めての人は色々とハマる(主にmodem周りのdaemonさんがATコマンド勝手に投げつけたり、ttyをrawにしなきゃいけなかったり)んだけど、それはまた別の話。慣れないLuaとドキュメント足りてないWiresharkのAPIと戦う事数日、なんとか動くようになるも、なんかまだ取りこぼしがある。リクエストの後にUSBにデータ送り出すと常にレスポンスのデータ間に合わずに見逃してる感じ。



って事でファームウェアをもう少し頑張るわけだけど……なんで取りこぼしなくデータ読むためだけに「俺SUGEEEE」みたいなバッファ回すコードかかなきゃならんのか。

そうこうしてるうちにLuaも少しはわかって来たので全体を少し手直し。綺麗になったのか良くわからないけど、まぁいっか。って事でようやくテスト環境が整ったのでした。


こんな感じに通信内容が赤裸々になってしまうSEGA I/Oさんなのでした。


例によって色々とこちらに。

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だと減算依頼しないので問題なし、という結果になっておりました。標準化って難しいですね。