これ、実は中身はHuC6280っぽい。基板長い人には知られた事実なのかもしれないけど、アーケード基板にPC-Engineの石が載ってるのはちょっと胸アツ。しかし、ハチ助さん隠すのに黒塗りしてたのかー。
下のはWikipediaより素の状態のHuC6280の写真。
 |
| Wikipedia HuC62のページより |
2019年8月31日土曜日
基板修理：タンブルポップ番外編
DECO製の基板はDATA EASTのロゴの入ったカスタムチップが色々と使われてるんだけど、ちょっと気になってたのが45番。チップはなんか黒塗りしたような跡があり、刻印代わりに銀色のシールで番号と社名が入っていて少し味気ないやつ。
これ、実は中身はHuC6280っぽい。基板長い人には知られた事実なのかもしれないけど、アーケード基板にPC-Engineの石が載ってるのはちょっと胸アツ。しかし、ハチ助さん隠すのに黒塗りしてたのかー。
下のはWikipediaより素の状態のHuC6280の写真。
あと、そうそう。mameのメインCPUに入ってるクロック、間違ってるなぁ……。14MHzが入ってるけど、CPUに来てるのは21.4772の2分周です。まぁ、すぐ直るだろう。
これ、実は中身はHuC6280っぽい。基板長い人には知られた事実なのかもしれないけど、アーケード基板にPC-Engineの石が載ってるのはちょっと胸アツ。しかし、ハチ助さん隠すのに黒塗りしてたのかー。
下のはWikipediaより素の状態のHuC6280の写真。
基板修理：続・タンブルポップ
前回の調査でCPUがどのチップなのか、ピン配置はどんな感じなのか把握できたので調査の第一ステップの基盤は整った感じ。クロックやリセットの確認はできたものの、ビデオ信号も出ずに一切だんまり状態なので今回ばかりは観測を進めるしかありません。
ひとまずバスの状態を確認して手がかりを探します。
確認したところ、/AS、/UDS、/LDS、Rは全てLOW、/DTACKはやや電圧低め（3.6V）で気になるもののHIGHの範疇でした。/BERRはしっかりとHIGHを維持しているので、CPUからの書き込み完了待ちで固まっているようです。/ASがアサートされているのでアドレス値を確認したところ、0x30_0000でした。中央のChip 56（背景のタイル処理をしているカスタム）へのアクセスですね。ここより先のChipはアクティブに動作していた事を考えると、Chip 56へのアクセスに対して/DTACKを返す論理が故障なり断線なりしている、と考えるのが良さそうです。エミュレータ上でCPUの動作を確認したところ、確かに最初にI/Oに出ていく際のアドレスは0x30_0000でした。
少しCPU周りの配線を整理すると、データバスはEPROMやChip 56に直結している様子。アドレスバスはE10/11にある74245で分離されているようです。B面がCPU、A面がEPROMやChip 56に繋がっていました。デバイス側からのバスへのアクセスなら/BRを使えば良いはずなのですが、本来の並びだと/BGACKや/BRが存在するはずのピンがVCCとなっているため、もしかしたらこの68カスタムは外部からのバス開放が要求できないのかな？その代替として外部でバスを切り離せるようにしているのかも。にしてもHALTとか他にも代替方法ある気がするので、いまいち必要性が理解できていません。
/DTACKについてはTG-1とタグの打たれたPALに繋がっていました。タンブルポップに関して言えばPALの論理は全部解析済みなので、万が一壊れてても問題なさそう。おそらくアドレスデコーダとバス応答をTU-1/2、TG-1/4あたりで組んでいるだろう、と踏んでおり、次回はその辺の接続関係の確認と論理の理解かな。
という事で、見えない進展ばかりだけど今回はここまで。西遊降魔録の件でかなり基板設計の気持ちがわかってきた気がする。
ひとまずバスの状態を確認して手がかりを探します。
確認したところ、/AS、/UDS、/LDS、Rは全てLOW、/DTACKはやや電圧低め（3.6V）で気になるもののHIGHの範疇でした。/BERRはしっかりとHIGHを維持しているので、CPUからの書き込み完了待ちで固まっているようです。/ASがアサートされているのでアドレス値を確認したところ、0x30_0000でした。中央のChip 56（背景のタイル処理をしているカスタム）へのアクセスですね。ここより先のChipはアクティブに動作していた事を考えると、Chip 56へのアクセスに対して/DTACKを返す論理が故障なり断線なりしている、と考えるのが良さそうです。エミュレータ上でCPUの動作を確認したところ、確かに最初にI/Oに出ていく際のアドレスは0x30_0000でした。
少しCPU周りの配線を整理すると、データバスはEPROMやChip 56に直結している様子。アドレスバスはE10/11にある74245で分離されているようです。B面がCPU、A面がEPROMやChip 56に繋がっていました。デバイス側からのバスへのアクセスなら/BRを使えば良いはずなのですが、本来の並びだと/BGACKや/BRが存在するはずのピンがVCCとなっているため、もしかしたらこの68カスタムは外部からのバス開放が要求できないのかな？その代替として外部でバスを切り離せるようにしているのかも。にしてもHALTとか他にも代替方法ある気がするので、いまいち必要性が理解できていません。
/DTACKについてはTG-1とタグの打たれたPALに繋がっていました。タンブルポップに関して言えばPALの論理は全部解析済みなので、万が一壊れてても問題なさそう。おそらくアドレスデコーダとバス応答をTU-1/2、TG-1/4あたりで組んでいるだろう、と踏んでおり、次回はその辺の接続関係の確認と論理の理解かな。
という事で、見えない進展ばかりだけど今回はここまで。西遊降魔録の件でかなり基板設計の気持ちがわかってきた気がする。
2019年8月30日金曜日
基板修理：西遊降魔録・完
SRAM待ちかと思ってたんだけど、画面の壊れ方を考えてたらSRAM出力のbit1がHIGHに張り付いてる気がしてきて。とりあえずエミュレーションで試してみたところ……
うん、壊れ方は完全に一致だ。パタンが2個毎に繰り返してたのは、パタンがループしてたわけじゃなくて、元データでたまたまインクリメンタルに並んでたはずのタイル番号がbit1がHIGHに張り付くことで0,1,2,3....となるはずのデータが2,3,2,3,...ってなってただけという。
ここまで来て、スクロールがなんかカクカクしてるのは「そういうもんか」と思ってたんだけど、もしかしたら同じ理由なんじゃないかと思えてきて。回路上はスクロールを保持するレジスタはX、Yともに2枚目の基板に並んでる。ちなみにXがIC3、YがIC42だと思います。んで、背景のアトリビュートRAMに入る直前の双方向バッファがIC41、アトリビュートRAMはIC40。さらに追ってないけどスプライト関連も同じデータバスの後段にぶら下がってる。そうなるとSRAMの故障というよりは手前でデータバスが破損してるんじゃないかと思えてくる。
という事で、データバスの破損をエミュレーションしてみたところ、ガクガクのスクロールや画面端でスプライトがチラチラする現象も再現できました。
そんなわけで希望をもって調べたら、ボード間接続のコネクタから出てるデータバスが、2枚目のボードの最初のICに繋がる手前で断線してた。見た目じゃわからないし、それなりに余裕ある配線には見えるんだけど。クロックも同じように断線してたし、flipの多い配線は疲労破壊しやすいんですかね。
そんなわけで、最後はわりとあっさり完動までいきました。結局のところ不具合は2枚目ボードの接続コネクタ付近で断線が2箇所って事になります。
しっかし悪役ヅラな主人公。デーモン閣下みたいな孫悟空。
うん、壊れ方は完全に一致だ。パタンが2個毎に繰り返してたのは、パタンがループしてたわけじゃなくて、元データでたまたまインクリメンタルに並んでたはずのタイル番号がbit1がHIGHに張り付くことで0,1,2,3....となるはずのデータが2,3,2,3,...ってなってただけという。
ここまで来て、スクロールがなんかカクカクしてるのは「そういうもんか」と思ってたんだけど、もしかしたら同じ理由なんじゃないかと思えてきて。回路上はスクロールを保持するレジスタはX、Yともに2枚目の基板に並んでる。ちなみにXがIC3、YがIC42だと思います。んで、背景のアトリビュートRAMに入る直前の双方向バッファがIC41、アトリビュートRAMはIC40。さらに追ってないけどスプライト関連も同じデータバスの後段にぶら下がってる。そうなるとSRAMの故障というよりは手前でデータバスが破損してるんじゃないかと思えてくる。
という事で、データバスの破損をエミュレーションしてみたところ、ガクガクのスクロールや画面端でスプライトがチラチラする現象も再現できました。
そんなわけで希望をもって調べたら、ボード間接続のコネクタから出てるデータバスが、2枚目のボードの最初のICに繋がる手前で断線してた。見た目じゃわからないし、それなりに余裕ある配線には見えるんだけど。クロックも同じように断線してたし、flipの多い配線は疲労破壊しやすいんですかね。
そんなわけで、最後はわりとあっさり完動までいきました。結局のところ不具合は2枚目ボードの接続コネクタ付近で断線が2箇所って事になります。
しっかし悪役ヅラな主人公。デーモン閣下みたいな孫悟空。
2019年8月26日月曜日
基板修理：続・西遊降魔録
タイル化けがわりと簡単かもって事で少し見てたんだけど、実はこいつのタイル周りはあまり解析されていないようでした。背景用のROMも実は正規基板からダンプされた事はないらしく、基板上のどこにデータがあるのか不明、とされている……。
そんなわけで少し調べてみたところ2枚目の基板に載ってるTRJ-100ってやつに入ってるらしい。V'BALLにこれの後継のTRJ-101ってのが載ってるんだけどピン数も少なくて参考にはならなそう。まぁ、周辺回路を調べてDounble Dragonの回路図と見比べれば何かわかるかなー、って事で、ここ数日暇を見つけてばストレス解消にテスターあててました。
ってことでTRJ-100の中身は掌握。タイルの回路もだいたい理解できました。
TRJ-100について先に記録しておくと、これはただのメモリではなく、複数サイクルに分かれてるアトリビュートデータからキャラクタ番号やパレットを取り出し、タイミング信号と合わせてメモリの読み出しアドレスを作ったり、読んだデータをピクセルクロックに合わせてシフトして送り出したり、さらにはキャラ反転や画面フリップなんかを処理したりする回路も込みでワンチップ化されていました。
Double Dragonの回路で言うと、IC38/39, IC58/59あたりの回路がアトリビュートをラッチしてキャラクタ番号やパレット番号を取り出す部分ですね。で、出回ってる回路図でいう2枚目のボードの9ページ目がタイミング情報（生成中のX/Y座標の下位4ビットずつ）を使ってアドレスを作っている部分、メモリ本体、読みだしたデータをタイミングに合わせてシフトしてピクセルデータを作ってる部分、あとはパレット番号を表示期間分に引き伸ばして出力してる部分。あとは細かくフリップ情報見てシフトする向きやらアドレスの回転方向を変えてる部分。これが全部まとまったのがTRJ-100のようです。
という事で、頑張ればアダプター作ってダンプして確認とかできるんですが、間接的な観測しかできないので、期待するデータが外まで出てくる入力条件を作ってやるのちょっと面倒。
そこまでわかった上でキャラ化けを考えてみたいところなんだけど。タイルが2枚とか4枚で変なループができてたりするので、考えられる線でいうとタイミング情報で0か1に張り付いてるビットがいる可能性。これは経路上でスクロールのための加算器とか挟まってるので、壊れ得る箇所は複数ある。あとはアトリビュート用のRAMが壊れてるパタン。これも良くある故障パターンなので説明できる。あとはTRJ-100の中にあるROMのアドレス線が壊れてるパタンかな。化け方的には中で論理が挟まってる場所ではなさそう、という判断。気になるのはX方向、Y方向に似たようなパタンのループが発生する化け方って点。これに関しては1点の故障では説明できなく、たまたま対象的に壊れたとしか思えない。
とりあえずタイミングに関してはIC17/18っていうDouble Dragonと同じ番号の石がHPOSを作っていて、これを見る限りは0〜255、0〜64、191〜255っていうカウントを続けており、最初の256カウントが水平表示期間、それ以外の部分が水平帰線期間で少なくとも表示期間に問題が起きるようには思えない。アトリビュートRAMの入力値も確認したけど途中で壊れてはいなそう。そうなるとメモリ系だなぁ……。という事で、今回は進展がないままSRAMを発注して一時休止。
ちなみにSRAMは2Kx8bitのやつがボード上に点在してるんだけど、IC40がいわゆるbgvideoramで確定。回路図8ページで言うと上がX、下がYの扱いになってて、最初にあるFFがCPUが直接スクロール値を書き込む場所。それを4bitずつに分けて加算、その計算結果がタイル描画用にSRAMを読み出すための情報になります。もう一方でデータバスの値も入ってきていて最集段でアトリビュートRAMへのアクセスかどうかでSRAMの入力を選択。CPUからの書き込みが優先されるので、表示期間中に触ると読み書き時のデータが画像表示系に流入してノイズが表示されるはず。
スプライト側の回路を読めてないので間違っているかもだけど、おそらくfgvideoram側はタイル側の回路ではなくスプライト側の回路で処理されている気がする。文字とかステータス表示に使われてる部分です。
そんなわけで少し調べてみたところ2枚目の基板に載ってるTRJ-100ってやつに入ってるらしい。V'BALLにこれの後継のTRJ-101ってのが載ってるんだけどピン数も少なくて参考にはならなそう。まぁ、周辺回路を調べてDounble Dragonの回路図と見比べれば何かわかるかなー、って事で、ここ数日暇を見つけてばストレス解消にテスターあててました。
ってことでTRJ-100の中身は掌握。タイルの回路もだいたい理解できました。
TRJ-100について先に記録しておくと、これはただのメモリではなく、複数サイクルに分かれてるアトリビュートデータからキャラクタ番号やパレットを取り出し、タイミング信号と合わせてメモリの読み出しアドレスを作ったり、読んだデータをピクセルクロックに合わせてシフトして送り出したり、さらにはキャラ反転や画面フリップなんかを処理したりする回路も込みでワンチップ化されていました。
Double Dragonの回路で言うと、IC38/39, IC58/59あたりの回路がアトリビュートをラッチしてキャラクタ番号やパレット番号を取り出す部分ですね。で、出回ってる回路図でいう2枚目のボードの9ページ目がタイミング情報（生成中のX/Y座標の下位4ビットずつ）を使ってアドレスを作っている部分、メモリ本体、読みだしたデータをタイミングに合わせてシフトしてピクセルデータを作ってる部分、あとはパレット番号を表示期間分に引き伸ばして出力してる部分。あとは細かくフリップ情報見てシフトする向きやらアドレスの回転方向を変えてる部分。これが全部まとまったのがTRJ-100のようです。
という事で、頑張ればアダプター作ってダンプして確認とかできるんですが、間接的な観測しかできないので、期待するデータが外まで出てくる入力条件を作ってやるのちょっと面倒。
そこまでわかった上でキャラ化けを考えてみたいところなんだけど。タイルが2枚とか4枚で変なループができてたりするので、考えられる線でいうとタイミング情報で0か1に張り付いてるビットがいる可能性。これは経路上でスクロールのための加算器とか挟まってるので、壊れ得る箇所は複数ある。あとはアトリビュート用のRAMが壊れてるパタン。これも良くある故障パターンなので説明できる。あとはTRJ-100の中にあるROMのアドレス線が壊れてるパタンかな。化け方的には中で論理が挟まってる場所ではなさそう、という判断。気になるのはX方向、Y方向に似たようなパタンのループが発生する化け方って点。これに関しては1点の故障では説明できなく、たまたま対象的に壊れたとしか思えない。
とりあえずタイミングに関してはIC17/18っていうDouble Dragonと同じ番号の石がHPOSを作っていて、これを見る限りは0〜255、0〜64、191〜255っていうカウントを続けており、最初の256カウントが水平表示期間、それ以外の部分が水平帰線期間で少なくとも表示期間に問題が起きるようには思えない。アトリビュートRAMの入力値も確認したけど途中で壊れてはいなそう。そうなるとメモリ系だなぁ……。という事で、今回は進展がないままSRAMを発注して一時休止。
ちなみにSRAMは2Kx8bitのやつがボード上に点在してるんだけど、IC40がいわゆるbgvideoramで確定。回路図8ページで言うと上がX、下がYの扱いになってて、最初にあるFFがCPUが直接スクロール値を書き込む場所。それを4bitずつに分けて加算、その計算結果がタイル描画用にSRAMを読み出すための情報になります。もう一方でデータバスの値も入ってきていて最集段でアトリビュートRAMへのアクセスかどうかでSRAMの入力を選択。CPUからの書き込みが優先されるので、表示期間中に触ると読み書き時のデータが画像表示系に流入してノイズが表示されるはず。
スプライト側の回路を読めてないので間違っているかもだけど、おそらくfgvideoram側はタイル側の回路ではなくスプライト側の回路で処理されている気がする。文字とかステータス表示に使われてる部分です。
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するって時は気をつけないと怖い。
タンブルポップとは直接関係ないけど、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あたりが死んでるかなぁ。ひとまず進展ありなのでメモだけとって、あとは次回のお楽しみ（？）
電源を入れると
こんな感じの画面で固まりっぱなし。映像系が最低限生きてる事は確認できるんだけど。
ひとまず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のデータが手に入りました。
アドレスとデータは全部共有バスに繋がってるはずなので、u25とu24の対応する足の導通チェックをしていきます。調べたところ全部問題ありませんし、どうやらSHARPのLH538BNTとOKIのM531602は、サイズは違うけどピン配置は完全に同じようです。A19も繋がっているので、他のROMと同様に倍サイズ載せることもできるようです。
このサイズのROMを置き換えようとするとフラッシュしかなくて、フラッシュはだいたい3.3Vだったりするのですが、このサイズだとギリギリ5Vのフラッシュがありますね。AMDのAM29F800Bを使う事にしました。配置もほぼ一緒。ここでフラッシュを手配して、届くまでしばらくは修理はおあずけ。
届いてから修理再開です。
ヒートガンで綺麗に剥がれる。というか自作基板で表面実装を散々こなしてきたので、既存基板をいじるのも怖くなくなりました。外したROMを読んでエミュレータに突っ込んでみます。
化け方、完全一致。という事でフラッシュを焼いて半田付けします。
この際、フラッシュはピン配置が若干違うので注意が必要。
1番、43番、44番の3つ。
1番はBUSY出力でマスクROMではNCだった箇所なので特に対処しなくても良いのかもしれません。が、基板上でGNDや5Vにターミネートされてる可能性もあるので、安全のため足を上げておきます。
43番は書き込み制御。A19が来ているピンなので0になったり1になったりしますし、この石を読みに来た時は確実に0になってるのでアウトです（笑）。足を上げて電源に繋ぐ必要があります。
44番はリセット。これもNCでふらついていると動作しないので、同様に足を上げて電源に。
こんな感じで。見た目はイマイチだけど基板側にダメージ残すよりはこっちの方が好み。
（ただし、人件費については考えない事とする）
この症状だと考えられるパタンは大きく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のデータが手に入りました。
| NC | 1 | M531602 | 44 | NC |
| A18 | 2 | 44 PIN SOP | 43 | A19 |
| A17 | 3 | 42 | A8 | |
| A7 | 4 | 41 | A9 | |
| A6 | 5 | 40 | A10 | |
| A5 | 6 | 39 | A11 | |
| A4 | 7 | 38 | A12 | |
| A3 | 8 | 37 | A13 | |
| A2 | 9 | 36 | A14 | |
| A1 | 10 | 35 | A15 | |
| A0 | 11 | 34 | A16 | |
| /CE | 12 | 33 | /BYTE | |
| GND | 13 | 32 | GND | |
| /OE | 14 | 31 | D15/A-1 | |
| D0 | 15 | 30 | D7 | |
| D8 | 16 | 29 | D14 | |
| D1 | 17 | 28 | D6 | |
| D9 | 18 | 27 | D13 | |
| D2 | 19 | 26 | D5 | |
| D10 | 20 | 25 | D12 | |
| D3 | 21 | 24 | D4 | |
| D11 | 21 | 23 | VCC |
アドレスとデータは全部共有バスに繋がってるはずなので、u25とu24の対応する足の導通チェックをしていきます。調べたところ全部問題ありませんし、どうやらSHARPのLH538BNTとOKIのM531602は、サイズは違うけどピン配置は完全に同じようです。A19も繋がっているので、他のROMと同様に倍サイズ載せることもできるようです。
このサイズのROMを置き換えようとするとフラッシュしかなくて、フラッシュはだいたい3.3Vだったりするのですが、このサイズだとギリギリ5Vのフラッシュがありますね。AMDのAM29F800Bを使う事にしました。配置もほぼ一緒。ここでフラッシュを手配して、届くまでしばらくは修理はおあずけ。
届いてから修理再開です。
化け方、完全一致。という事でフラッシュを焼いて半田付けします。
この際、フラッシュはピン配置が若干違うので注意が必要。
| RY//BY | 1 | AM29F800B | 44 | /RESET |
| A18 | 2 | 44 PIN SOP | 43 | /WE |
| A17 | 3 | 42 | A8 | |
| A7 | 4 | 41 | A9 | |
| A6 | 5 | 40 | A10 | |
| A5 | 6 | 39 | A11 | |
| A4 | 7 | 38 | A12 | |
| A3 | 8 | 37 | A13 | |
| A2 | 9 | 36 | A14 | |
| A1 | 10 | 35 | A15 | |
| A0 | 11 | 34 | A16 | |
| /CE | 12 | 33 | /BYTE | |
| GND | 13 | 32 | GND | |
| /OE | 14 | 31 | D15/A-1 | |
| D0 | 15 | 30 | D7 | |
| D8 | 16 | 29 | D14 | |
| D1 | 17 | 28 | D6 | |
| D9 | 18 | 27 | D13 | |
| D2 | 19 | 26 | D5 | |
| D10 | 20 | 25 | D12 | |
| D3 | 21 | 24 | D4 | |
| D11 | 21 | 23 | VCC |
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を使ってデバッグしてみた。
って事で、naomi → SEGA I/O → iona（ターミネート）って構成での動作テストとデバッグ。今までこの構成だとnaomiが2台のデバイスを認識しつつもSEGA I/Oは反応なし、ionaは2番目のデバイスとして動作してた。この状況証拠だけでも気づけばバグの原因がわかったんだけど、残念ながらピンと来なくてモニター作りに精を出してしまいました。まぁ、便利な技術は色々と身についたから良しとする。
ログを見て判明したのは、リセットから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はシリアルログも存在する |
って事で、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さんなのでした。
例によって色々とこちらに。
で、確認したら2台ともnaomiには認識されて、個別にアドレスは振られた模様。でもなぜかSEGA I/Oはアドレス持って認識されてはいるもののIDも空だし入力も送信できてない。なんか動作してないっぽい感じ。下流にいるionaはきっちり動作してるので電気的な問題じゃなさそう。となるとSEGA I/Oがなんらかの自粛モードに入ってるのか、ionaが通信を邪魔しちゃってるのか。これを調べるとなるとプロトコルアナライザーが必要だなー、と。
そこで作ることにしたのがJVS I/O Monitor。基本、D+に流れる信号をモニタしてやれば良いので難しくはありません。
 |
| こいつの出番 |
去年作った基板を使えばSTM32を使ってお手軽にUSBデバイスが作れますので、D+をモニタして解析した通信内容をログとしてUSBシリアルとしてホストに流してやるデバイスを検討。一晩もあれば作れるだろう……と思っていたのですが。
トラブルいっぱい。
USB側は慣れてたけど、USARTの扱いが色々といけてない。ログ解析をしながらUSBでデータを流しだし、USARTを取りこぼしなく処理する、というのはどうやら無理っぽいです。
マイコンの数だけ落とし穴があると言ったがアレは嘘だ、ペリフェラルの数だけある、というかレジスタの数だけある事すらあるかもしれない— とよしま (@toyoshim) August 11, 2019
（言ってないけど）
stm32f042について新たに得られた知見1)USBとUART1を同時に使うとUSB通信時にUARTが死ぬパタンあり。UART2で回避可能。2)UARTはHAL的には3系統APIあるけどDMA+リングバッファ以外実用的じゃない。3)リングとUSB通信用のバッファを、間でフォーマット変換するのに必要十分なだけ取るとメモリが溢れる。— とよしま (@toyoshim) August 12, 2019
という事で悲鳴の声。どうにも処理が安定しないので、デバイス側はログ収集に専念させ、ホスト側で解析をするよう方針を変えました。で、どうせホストでやるならWireshark使うよね？って事でざっくり調べてできそうな事を確認、方針を固めました。
取り敢えず、ほぼ生のログを転送するだけにして、ホスト上でpcapフォーマットに変換、リダイレクトでwiresharkに食わせて、作ったplugin経由でログ解析して眺めるって形に落ち着きそう。まぁ、これはこれで正しい。作るのも使うのも面倒臭いけど。— とよしま (@toyoshim) August 12, 2019
しかしまた、いっきに遠回りに……。ホスト側の処理は正確にはシリアルから読んだ物をpcap形式にして名前付きパイプに書き込むって物でした。Wiresharkはデバイスだけじゃなくパイプを開いてログとる事もできるんですね。Linuxのシリアルも罠いっぱいで初めての人は色々とハマる（主にmodem周りのdaemonさんがATコマンド勝手に投げつけたり、ttyをrawにしなきゃいけなかったり）んだけど、それはまた別の話。慣れないLuaとドキュメント足りてないWiresharkのAPIと戦う事数日、なんとか動くようになるも、なんかまだ取りこぼしがある。リクエストの後にUSBにデータ送り出すと常にレスポンスのデータ間に合わずに見逃してる感じ。
WiresharkでそれっぽくJVSIOのログをリアルタイムで見られるようになってきた。 pic.twitter.com/U6Rhlue7Mz— とよしま (@toyoshim) August 13, 2019
って事でファームウェアをもう少し頑張るわけだけど……なんで取りこぼしなくデータ読むためだけに「俺SUGEEEE」みたいなバッファ回すコードかかなきゃならんのか。
そうこうしてるうちにLuaも少しはわかって来たので全体を少し手直し。綺麗になったのか良くわからないけど、まぁいっか。って事でようやくテスト環境が整ったのでした。
例によって色々とこちらに。
登録:
投稿 (Atom)