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

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

2019年6月16日日曜日

ラジルギスワッグ(SW)

出たら買おうと思ってたんだけど、気づいたら発売日過ぎてた。他の人のツイートみて気づいてゲット、一先ずクリアまで。



視点が今までみたいな真上じゃなくて斜め上のレイストームタイプになってたけど、レイストームみたいな避けにくさはなかった。最初は普通に遊んでて3面で躓いてて。しばらくしたら3面スタートするアイテムが貰えたので3面やってたら4面行ける事も出てきて。そうこうしてたら5面行った事ないのに4面スタートと5面スタートのアイテムが貰えたので5面で遊んでみる事に。で、普通に遊べるレベルじゃないのでアブソネット入れっぱなしにしたりスピードアップ取ったり試行錯誤してるうちに遊び方見えてきた。スピード全開にしてるとアブソネットゲージの回復も早いので、あとはひたすら速と充を集めながらアブソネット展開して無敵時間に特攻&チャージ。後半面のほうが敵が多いからチェーン繋げやすい。だからいきなり未達の後半面まで開放するとかいう思い切ったデザインになってるのかー。

最初は5面スタートでクリア。徐々にスタート位置を手前にしていくっていう通常の攻略とは逆パターン。繋げるのに慣れてきたら1面で速を2つ取ったら、あとは最後までずっとチェーンで俺のターン。って感じで普通にクリアして1.3億点くらい。ランキングで100位前後ですが、遊んでる人多いみたいでグングン下がる(笑)ちなみに、タイムラインで見た方々は2億点のラインで楽しんでるようで……5位圏内の戦いでした。しばらくやってクリアは安定したけどスコアは最初が1番良くて以降は1.3億届かないくらい。まぁ、普段から稼がない・稼げない人なので、この辺で。


そう言えば上達したプレイヤーほど進行を速くさせてインカムを……みたいな試みは疾風とか、まもるクンとか、あまりうまくいった話を聞きませんが、こやつ家庭用の癖にうまくまとまってるような。あと1プレイ10〜15分ってのは楽しみやすくて好き。

2019年6月7日金曜日

カラドリウス(PS3 / PS4 / AC)

たぶん昔にPS Plusでフリープレイ対象だったのをダウンロードしたんだと思うんだけど、PS3とPS4両方にインストールされてまして。ランク格付けだと0とかなってるけど、いくら水の防御ESつけててもそれはない。普通に7くらいあると思う。ALL.Net P-ras MULTIに入ってるおかげで今でもわりと多くのゲーセンで遊べます。脱衣シューティングってのがアレだけど、ゲーム自体は面白いし特にボス戦はテンポが良く、形態変化に合わせて攻撃方法を選んでいくのが楽しいです。


3年くらい前からやってるんですが、久々にオリジナルモードをやってみたらするっとラスボス倒せまして……と思ってたら、コンティニューせずに倒した時だけ6面に進むんですね。

6面道中は近くから自機狙い撃たれまくりでヒヤヒヤ。特に難しいとかではないけどR-TYPEの最終面みたいに神経をすり減らされる。で真ボスと初対面なわけですが、さすがに勝てなかった。


けど、だいぶ惜しかったので、もう1プレイ。今度はもう少し余裕を持って6面に入れ、そのまま無事にクリア。


わーい。これで今年9本目です。ここのところ調子が良い!


そう言えばランキングの入力、昔は「T.T」を使ってたんだけど、これ始めたころに「TAK」を使うようになって……でも最近ちゃんたけ大先生が「TAK」と入力してるのを目撃してから、恐れ多くなって「T.T」に戻しました……が、このゲームではとりあえず「TAK」に統一。

今回はまさかクリアまで行くとは思ってなかったから録画してなかったー。アーケードモードとかボスラッシュモードはまだ続けるつもりなので、どっかのタイミングで攻略法を忘れないうちに録画できたら、と。

(2019.06.18追記) 近所のゲーセンでAC版のアーケードモードをクリアしました。

2019年6月1日土曜日

疾風魔法大作戦(SS / AC)

とりあえず日和ってクリア優先で1周しました。



もちろんチッタでプレイ。ずっと右側のステージを選び、最後は一番右のCを選択。他のコースはあまりやってないけど、たぶん一番簡単なコース。レースで1位になると「魔法娘はおとしごろ」を経て2周目。この展開から2周目入るとコースは選択無しで左側ってのは確認したけど、これは1周目選ばなかったコースになるのか、常に左なのかは未調査。レース2位でもチッタに「こんどはあなたと1位とりたいな♥」と言われるので満足度高い。

クリア優先だと前作よりはだいぶ簡単な気がする。右コースを取る限りは特訓が必要になる類の道中やボスは存在しないし、1周15分くらいだから気軽に楽しめ練習も捗る。ただ各面ノーミスでクリアできるようになるまではすぐなんだけど、レース要素のせいでなかなか安定はしない。それでも某格付けサイトのランクで言えば、たぶん1桁後半くらいの難易度じゃないかなぁ……実際には14とかついてるけど。もちろん他のコースや2周目入りを考えるとぐっと難しい。



あ、基板の修理はまだ完了していません。M2が移植するまでには直すぞー。

2019/06/04追記:サターン版の隠しモードでレース要素を落とした「シューティングモード」なるものがあるらしいので試してみました。ちなみに公式サイトでは「オプションのサウンドにカーソルを合わせて「上上下下左右左右BA」と入力することで、項目が増える。 」とありますが、実際には「オプションで上上下下左右左右と入力した後、サウンドにカーソルを合わせてスタートボタン」かな?
いざ遊んでみると、やっぱりバランスとかレベルデザインはレースモードでとられてるんだなぁ、という当たり前の感想。レース要素が消えた事で緊張感が足りなかったり、空白地帯ができちゃったり。左コースはそれでも難しいですが。クリアできるようになったコースだと物足りない感じはしますね。
あと、このモードはクリアさえすればレース1位と同じ扱いなので、へっぽこプレイでも2周目に入れる。ので、左コースを選ぶとどうなるかの確認ができました。2周目は1周目で選択してないコースに自動的に進むんですね。となると1周目は左を選ぶのが2周クリアへの最短の道か……。

2019年5月29日水曜日

LIFE FORCE(SS / PSP)

大阪にでかけている間に少し遊んでクリアできるようになったので、PSPの録画環境のテストも兼ねて記録を残してみました。

前回の沙羅曼蛇は敢えて処理落ち制御を外して1周13分ほど。今回のPSP版はM2のエミュレーションベースなのでアーケードと同程度かと思いますが、18分くらいで1周しました。

しかし沙羅曼蛇、名作とは言え、どっちのバージョンもお茶目なバグが多め。でも、そういう細かいとこは無視して〜と言えるくらい惹きつける何かがあるのかな。個人的には音楽もそうだけど効果音がね。レーザーやミサイルの音はやっぱり凄い。



沙羅曼蛇ポータブル、まだアーカイブスでダウンロード販売ありますので。PSP/VITA/PS3でしか動かないので現行ハード向けじゃないですが。そっちはアケアカで。でもXEXEXやスムーズスクロール版GRADIUS 2が遊べるのは沙羅曼蛇ポータブルだけ!M2のねじ込み力!

2019年5月21日火曜日

沙羅曼蛇(X68k / SS / PSP / Xbox One X / AC)

例によって表題の中の括弧内に書かれてるのはボク個人が遊んだ環境。名作すぎてあちこちに移植が出てるから、今までのゲームよりプラットフォーム数が圧倒的に多い。

沙羅曼蛇は子供の頃にX68kで散々遊んでたんだけど。なにぶんredzone使いだったのでサウンドドライバには自分でパッチ当てて24MHzで遊んでおりました。なんかOh!Xとかに「10Mショック」みたいな事が書いてあったので、処理落ちはX68k版の問題なのかなー、と思って。たぶんめちゃくちゃ難しい設定で遊んでたんだと思います(笑)

んで、大人になってアーケード版やってみるとこっちも結構な処理落ち。そんなわけでアニバーサリーコレクションにも収録されてて再び火がついたので、ミカドの動画を参考にしつつ(最近知り合ったKRGさんが出てて「おぉ?!」ってなった)1周だけ攻略してみました。録画するにあたりなぜかサターンでプレイ。せっかくなので処理落ち制御をオフにして遊んでます。たぶん当時のX68k版に近い状況なんじゃなかろうか。一番美しい思い出に近い形でのプレイです。

動画の方にも書いたんだけど、モニタの都合でワイドモードにした方が本来の縦横比に近かったのでワイドで遊ぼうと思ったんだけど、どうもスコアの位置がずれる。4面の隕石避けるのに1Pスコアと"HI"の間では爆死するようです。


この爆死前の絵面からわかる通り、1の位と10の位の間くらいがワイドモードの安置っぽい。別のこと覚えるのも紛らわしいので結局ノーマルでプレイしました。

あと、よくわからないけど3面の不死鳥って高解像度化されてるのかな?アーケードもっとカクカクな感じで拡大されてると思うんだけど。でも、1面の細胞は明らかに荒いままなので気のせいかも。



これで今年6本。なんとか月1ペースを挽回です。

2019年5月18日土曜日

シスターズロワイヤル(switch)

発売と同時に買って、熱出して寝込んでる時にやりこんでEASYはすぐクリアできたんだけど、NORMALはラスボスでしばらく止まってて。気づけば1年近く経っていたわけですが。ラスボス止まりのシューティングが増えてきたので、再び集中してクリアしてみました。



アルファ・システムさんによる式神IIIから12年ぶりの新作STGって事で、基本的には式神の城シリーズのシステムを踏襲してるそうです。「そうです」というのは、式神は積んだまま、まだやり込めてないから。

順当にいけばラーレを選ぶところなんだけど、なんかソナイがめちゃくちゃ強いと気づいてしまって……しかたなく年増キャラを使っております。

家庭用らしく遊びやすく調整されてますね。3ダメージ制でボムのストックも3から始まって最大5個。ダメージ受けるとボムストックが1つだけ増えるようになっているため、抱え落ちをそこまで気にする必要がない。満タンで死ぬともったいないかなぁ……って程度。あとは稼ぎでダメージとボムが回復していく仕様で。そこそこ稼いで進めば毎ステージ1つ回復する感じ。1ダメージで1ボム増えることを考えると、うまく調整すればステージあたり実質3ミス相当が帳消しできます。回復するタイミングもわかるので、回復前にボム減ってるなーと思ったら敢えてミスしてボム回収、すぐにゲージ溜まってダメージとボムも再回収、とか。常時、危なくなったらボムを使うかミスを選ぶかを考えておくだけで、だいぶ有利に進められます。そんなわけで前半でポカミスしても軽々と挽回、終盤で連続ミスしなければ、わりと順当にクリアできるのではないでしょうか。

もうね、最近はクイックセーブ付きのアーケード移植ばかりやってるから。こういった最初から通しでプレイしないと後半の練習ができないゲームは、このくらい遊びやすいバランスになってないとなかなかクリアできません(汗

2019年5月16日木曜日

ブレイジングスター(MVS / NEOGEO mini)

アケアカでも出てますがそっちでは未購入。NEOGEO miniで保存できるから部分練習とかそっちでやって、最後はMVSで仕上げました。

去年あたりから時々やってたんですが難易度高いと思ってやりこみは避けてたんですけど……ミカドさんで遊んでわりと先に進めたのと(確か難易度下げてあるか、残基増やしてあるかだったような気が)、シューティング祭りの解説がめちゃくちゃ面白かったのとで。最近集中して遊んでました。



これ。某格付けサイトだと難易度は24と高めなんだけど、稼がずパタンを作ればラスボスまでの難易度は一桁クラスなんじゃないかなぁ。3面ボス最終形態で少し気をつけて避ける必要がある程度で、それ以降の後半面はすぐに安定した。ある程度稼ぎ始めると6面の奥行き方向にスクロールする場面の安置が無効になるので、稼いだ場合の6面後半からラスボスにかけては詳しく確認できてない。そこまでの道中は稼いでもランクの違いを意識する事はほぼなかったかなぁ。

ラスボスはまだ安定しなくて、最終形態でミニ赤ちゃんと追いかけっ子するあたりでだいたい1ミス、最後のバラマキで左上のほぼほぼ安置に逃げ込んでもやっぱり1ミス、みたいな感じで。基本ノーミスで辿り着かないとチャンスない感じだったので集中力の消耗が激しかった。

ただ、基本は稼ぐと楽しいゲームなので、もう少しクリアにこだわらずに遊んだほうが良いのかな、と。奥方向スクロール地帯さえなんとかなればラスボスまでは行けそうだし。そんなわけで、これからもまだボチボチ遊ぶかと思います。いつかPulstarもなんとかしたいんだけどね。

コントローラ設定的にはボタン3にショットのシンクロ30連をあててます。なんとなくシンクロ連の方が火力が高い気がしてたんだけど、ラスボスの最終形態序盤とか手連セミオートでも同じタイミングで破壊可能だったので、おそらく連射なくても大丈夫。むしろボス戦処理落ち時に安定して弾が出る気がする。

2019年5月12日日曜日

チェルノブ

某基板屋さんに顔を出したら「どうですかー」って感じで出てきたジャンク基板。軽傷っぽいし破格だったので。

症状的にはこんな感じで全体が黄色く表示されるパレット化け。


問題となってるのはこの箇所。


本来はMB7132っていう1024 x 8-bitsのPROMが刺さってるんだけど、互換品とか入手できそうになかったので、手持ちのEPROMに小細工して修理する事に。使ったのは27C32です。ピン配置はおおよそ同じ。ただサイズが4倍なのでA10とA11が余分に出ていて、MB7132だとCE3と/CE4になってる。まぁ、入力なら気にする必要はなくて。同じデータを4回入れて焼いておけば実質A10とA11はdon't careになる。問題は18番ピンで、EPROMでは/CEだけどPROMではCE2と極性が反対。そもそも/OEと/CEだけは使われ方を確認しとかないと……という事で基板側を確認したら、CE2とCE3はVCCに固定、/CE1と/CE4は同じ信号が入っていてVCCにpull-upされていました。となれば、EPROM側は/CEをソケットから抜いて/OEとショートさせておけば良さそうです。


うまく動いたのでEPROMは空中配線はやめて、直接加工しちゃってこの基板専用にしちゃいます。


めでたし、めでたし(^^ゞ

ちなみに、この故障モードはmameで1つ目のPROMを0xFFで塗りつぶしてやれば再現するので、アタリはつけやすいです。調査・修理ともに簡単だった久々のケース。

2019年5月3日金曜日

SYSTEM 16C/B

SEGA AGES 2500版ファンタジーゾーンIIがSYSTEM 16Bを改造した基板(通称16C)にて実機動作可能、という事はわりと有名かと思うのですが。


マザーボードを改造するのはちょっと気がひける……という事でメインボードはいじらず、サブボード側に追加メモリを載せる方法を思いついたので作ってみました。もちろんハードの変更に追従するようソフト側にもバイナリパッチを当てる必要があります。PS2版は今でも持ってますよ、念の為。

既に解析されているSYSTEM16Bの仕様とサブボードのピン配置をテスターで追う気力、さらに回路と機械語の知識があれば思いつくレベルの話ではありますが、詳細は非公開とさせてください。ただ、マッパーの挙動を正しく理解せずに単純にRAM追加したりすると、データバス競合で壊れたりしますよー、とだけは不要なトラブルを避けるために言っておきます。



色々な権利を無視したシルクの入った基板ですが……個人の趣味制作ですのでw


この手の電解コンデンサとか個人で遊ぶ分にはおおよそ関係ないんですよね、実際問題として。電圧が不安定だったり瞬断したりした際に問題なく動作する事を保証するために載ってるだけのはずです。が、まぁオリジナルのサブボードのデザインに準じて。


大きな基板作るとお金かかるので。なるべく小さく作るように心がけましたが、コネクタの位置が決まってるので、これ以上は小さくできない。



これ、実は凄いポカミスで。BG面用のROMが左上の方にSCR0-2と並んでるんですが、並びが左右逆順だった。シルク文字の入れ間違いです。


でまぁ、元々載っていたサブボードがテトリスだったので、まずはテトリスをそのまま置き換えるテスト。CPUも暗号解除機能のついたオリジナルの羊羹CPUなので、単純に配線があってるかの確認がしやすい。容量も小さくバンク切り替えとか使ってないので基本機能のテストとしては適したタイトルだったのです。念の為、ここでCPUを素の68Kに置き換え、ROMも暗号解除した物に差し替え。素の68Kでも動く事は確認しました。



という事でファンタジーゾーンのTime Attack Modeです。PS2版からのイメージコンバート。タイルのバンク切り替えも使ってるので、その辺も追加で確認できた。Z80側のバンク切り替えは少し面倒で、元々のサブボードはコードとデータを別ROMで扱ってたりしたんだけど。同時にアクセスする事はないので1つのROMにまとめて、バンドとセグメント合わせて、論理回路で空間を切り替えてます。

ちなみに同時にアクセスされないROMは全部まとめているので、載っている6個のROMは全部同時にアクセスされる可能性のあるROMになっています。SCR0-2とかBG面用で3つとも常時読み出し、他にスプライト用の1枚、残りはZ80と68Kに1つずつですね。拡張RAMは当然68Kのバスを共有してますし、マッパー経由できちんと制御できます。


サブボード上のDIPスイッチでゲームを切り替えられる。タイトル増やすのは簡単だけど、別にそれが目的ではないので。


Z80側は回路追いきれてなくて、やや手探りだったんです。あと、Time Attack Modeは本来171-5704タイプのサブボードを想定しているので、この拡張RAM付きのサブボードで動かすために本来不要なパッチを当ててます。


旧セガ端子からJAMMAに変換するボードも一緒に作ったよん。こっちはまぁ希望あれば配っても平気な気がする(ロゴがあれだけど)。