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.

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

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

コメントの見落としが多いというか、ほとんどチェックしてなかったので、何かあればTwitter等のソーシャルメディアで突いてもらえれば捕まるかと思います。

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


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


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


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


際どい技術情報について


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

2019年9月8日日曜日

基板修理:達人

いかにも良くありそうなスプライト化けの基板。


ぱっと見でアトリビュートRAMかその周辺の配線切れなら楽勝かなー、と思えるくらいには慣れてきました。TOAPLAN系の基板では疾風魔法大作戦の調査をしているので、ぱっと見でおおよその流れはわかります。

A4に陣取っているFCU-2がスプライト制御用のカスタムチップなので、こいつを中心に調査します。すぐ近くのA1/C1にあるSRAM 2KBx2がスプライトアトリビュート用のSRAMですね。アドレス共通、データはパラで16-bitsの構成。前のオーナーが修理済でソケット化されてたので片方ずつ抜いて動作確認できたので助かりました。A1が奇数アドレス、C1が偶数アドレス担当かと思われます。データは直接FCU-2に繋がっていました。CPUからの書き込み時や表示スプライトの選定時にFCU-2からアクセスされるようです。とりあえずCPUからは正常読み書きできてるようだし、配線は全部繋がっていたので、こっち側は問題ないと判断。一応SRAM故障時のオブジェ化けパターンを一通り調べてみたけど基板とは一致せず。となると論理かデータが怪しい。

データに関してはB65-01から04のマスクROMからの読み出し。28pinで128KBというEPROMにはないタイプですが、27C512の/GをA16に読み替えれば大丈夫。自分は27C010に変換する下駄を作って読み出してみました。


で、読んでみるとB65-04がなんか既知の物とは若干違う。ただ、読ませて見ても別段問題あるデータではなかったので原因ではない様子。そうそう、ちなみにB65-01-04はアドレス共通、データはパラで32-bitバス。8ピクセルで4プレーンに分かれてるって予想をしてるけど確信もつまでは調べてない。ただ、そういった事情もありデータ故障の可能性は低い。

データは大丈夫そうなのでROMから逆に辿ってアドレスバスを調べていく事にした。下位3-bitsはA13の74LS175に繋がっていたので、おそらくY方向の8ライン分のアドレス生成結果が出てくるのかな。だとすると連続8Bx4プレーンで8x8サイズのスプライトのデータを構成。A[15:3]は14-bitsで指定するオブジェクト番号のはずで。これらはMSBから順にA15/A14/A17/A16の位置にある72LS163のカウンタに繋がってた。C14/C16のSRAM出力をLOAD時に取り込み、クロックでインクリメント。キャリーも順番どおりに上位のENに入っている。SRAMにソート済みスプライト情報が入っていて表示期間には読み出しながらスプライトを合成する感じか。カウンタの制御信号はSRAMより手前のロジックIC郡が作ってる模様。

ここまで論理が絞れてくると、壊れてる可能性があるのは74LS163のうちのどれか。エミュレーションで適当に壊してみると上位ビットが怪しいかなぁ……という事でロジアナで観測。どうもA14の74LS163が出力も弱く、出力論理も不安定。出力AとDがなんとなくHIGHに張り付いている事が多い。

そんなわけでスプライト番号に0x0900を被せてエミュレーションしてみたのがこれ。


静止画だとそこまではっきりわからないかもしれないけど、動いている様子を見るとだいたい化け方は一致したと思って良さそう。

って事で秋葉にて部品調達。たまたま大試遊祭に遊びに行こうと思ってたので丁度良い。というか、順番が逆で、それまでに故障部品を特定しようと思って作業してた。しかし、ツイッターでも書いたけどロジックICもだいぶ入手が難しくなってきた気がします。自分はマルツ、秋月、千石くらいしかお店を知らないですが、どこが品揃え良いってわけでもなく、たまたまそのお店が在庫多く持ってたやつが残って今も売られている感じで。今回の163は千石にしか置いてありませんでした。161だったら他でも見かけたしロジアナで見た感じ/CLEARは積極的に使ってなかったから161でも動くかも。でもまぁ、本来のやつを使うに越したことはない。ちなみに最上段に並んでる163のうちA15のやつだけは4-bits中2-bitsしか使ってなくて、未使用品は浮いてます。なので74LS163じゃないと駄目。CMOS版使うなら5ピンと6ピンをpull-up/pull-downどちらかで処理する必要がありそうでした。参考まで。


そして交換後の基板なんですが……ありゃー、まだ不完全でした。再びエミュレーションで確認したら、bit3が0に張り付いているようです。


そんなわけでA16にあった163も交換。


無事に完治です。

参考までにB65-[01-04]のアドレスバスについて調査中に作った表を残しておきます。


自分用のメモなので意味不明だと思うのでざっくり参考にできる程度に説明しておくと、FUC-2がスプライトのコントローラ。この表にはない近くのSRAMx2と反対側で繋がっていて、それを読みながら各ラインに表示するスプライトを決定してTC5565の方に格納してくれます。一方でTC5565の下にあるロジック郡が画面表示のタイミングに合わせてSRAMから最上段にある74LS163郡に表示スプライト番号を送り出してくれる。あとはスプライトサイズに合わせて適切な桁の加算機にクロック送って8x8ブロック単位でスプライト番号がインクリメントされるような制御もしてくれてる。そんなわけで74LS163はSRAMが裏で使われてる際にスプライト番号を保持する役目と、サイズに合わせて次の番号を計算する2つの役目を持ちます。GP9001とかが載ってる基板だと、おそらくこの計算までの論理がカスタムチップ内部に入ってます。
で、最後にこの出力がマスクROM01-04のアドレスに入り、32-bitsバスで4-bitsパレット番号×8ピクセルのデータを出します。パレットに関しては前の方にも書いた通り、ROM毎に1-bitでプレーン方式のはず。出てきたデータはシフタで1pixel毎に送り出され、パレット展開・他の面との合成ののち、DACからアナログRGB信号として外に、という流れですね。

2019年9月1日日曜日

基板修理:続続・タンブルポップ

前回はPALで作ってると思われる/DTACKに課題を残して終了となったわけですが。

とりあえずTG-1、TG-4あたりの論理を読み解いてみました。TG4はバスタイミング系の信号とメモリの参照クラスFC[2:0]をとって、より細分化されたタイミングを作る組み合わせ回路の詰め合わせでした。一部はTG-1でも入力に使ってる(ので調べた)。

TG-1はまさに/DTACKを作る回路そのもの。A21が立ってないとメモリアクセスだと思って、/AS、/*DS、Rに連動して即時/DTACKをアサートする。A21が立ってるとI/Oへのアクセスだと思って、8番からの入力に連動してWRITEなら次サイクル、READなら2サイクル後に/DTACKをアサートする。プログラムはIOアクセスまで進むのでメモリ側は問題ないんだな。そっちが動かなければプログラムがそもそも動かないから。そうなると8番の入力が怪しい。

で8番からの入力を追ってみたら15AのDFFと繋がってる。Dは/ASを2サイクル遅延させたもの、CLKがChip 56のPin 151に繋がってる。となるとChip 56が応答しないのが問題に思える。Chip 56は全体的に静止状態に見えるため、そもそもクロックが入ってない気がする。Pin 153が他のFFのクロックと繋がってるためクロック入力か出力に思えるんだけど、こっちの信号も動いてない。

ところでこの基板、クロックは21.4772MHz、32.220MHz、28MHzの3系統あるんだけど、32.220MHzはYM2151用、21.4772MHzはメインCPUとOKI、で最後の28MHzはスプライト制御のChip 52に直接入ってるところまでは確認してる。Chip 52には発振回路を通さずに正弦波で直接入れてるので、中で発振させた後、クロック出力でChip 56に供給してる可能性は高いかな。どっかで断線とかなら良いけど、クロック出力が壊れてるとかだと面倒。いや、面倒という意味ではこれら2つのカスタムは128ピンと160ピンのチップなので何をするにも面倒。

TG-1周辺のロジアナ観測結果はこの通り。


予想通り、最初にIOに書き込みに行ったままだんまり。/DTACK生成周りは理解の通りに動いてる様子。となるとChip 56の入力クロック探しか……これは面倒。もし情報をもっている方がいたら提供して頂けると助かります。最悪、入力ピンと分周比さえわかれば外で作って入れても良い気はする。

そうそう、某エミュのCPUクロックはもう直ってる。

追記:まずは28MHzが入ってる97-128ピン面だけでも……と調査してみた。112-126,127がすぐ隣のRAMと8-bits x2で繋がってました。RAMのアドレスはセレクタに繋がってたからいわゆるspriteram、アトリビュートRAMみたいです。MSBのA10がGNDに繋がってたので容量半分潰してる……リッチだな。故障時はVCCに釣り上げれば交換せずに直る可能性ありですね。電源は簡単に調べられるとして、それ以外で調べきれてないのは、98-102, 108-110だけです。111が2分周で14MHzのクロックを出力してました。B16にある7404の3番に入ってるので、とりあえず問題はChip 52の外っぽい気がしてきました。よかった。

2019年8月31日土曜日

基板修理:タンブルポップ番外編

DECO製の基板はDATA EASTのロゴの入ったカスタムチップが色々と使われてるんだけど、ちょっと気になってたのが45番。チップはなんか黒塗りしたような跡があり、刻印代わりに銀色のシールで番号と社名が入っていて少し味気ないやつ。


これ、実は中身はHuC6280っぽい。基板長い人には知られた事実なのかもしれないけど、アーケード基板にPC-Engineの石が載ってるのはちょっと胸アツ。しかし、ハチ助さん隠すのに黒塗りしてたのかー。
下のはWikipediaより素の状態のHuC6280の写真。

Wikipedia HuC62のページより
あと、そうそう。mameのメインCPUに入ってるクロック、間違ってるなぁ……。14MHzが入ってるけど、CPUに来てるのは21.4772の2分周です。まぁ、すぐ直るだろう。

基板修理:続・タンブルポップ

前回の調査で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あたりで組んでいるだろう、と踏んでおり、次回はその辺の接続関係の確認と論理の理解かな。

という事で、見えない進展ばかりだけど今回はここまで。西遊降魔録の件でかなり基板設計の気持ちがわかってきた気がする。

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箇所って事になります。



しっかし悪役ヅラな主人公。デーモン閣下みたいな孫悟空。

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側はタイル側の回路ではなくスプライト側の回路で処理されている気がする。文字とかステータス表示に使われてる部分です。