ラベル 電子工作 の投稿を表示しています。 すべての投稿を表示
ラベル 電子工作 の投稿を表示しています。 すべての投稿を表示

2025年4月26日土曜日

SG-1000II コンポジット化

RF→HDMI変換器をしまい込んで出てこなかったので、先人の知恵を借りてSG-1000IIのコンポジット化をしたので簡単なメモ。

参考にした先人のページはこちら……なんだけど、goo blogサ終のアナウンスが出ていて、最終更新から数年経ってるし、近々消えてしまうのかなぁ……とりあえず今回参考にしたページについてはarchive.orgに拾ってもらえました。

で、同じ旧型だし、これを参考にやれば良いんだな……ってバラしてみたら、このページで扱ってる基板は「171-5141 ©SEGA 1984」の刻印、一方で手元の基板は「171-5168 ©SEGA 1984」で同じ年でもレイアウトがだいぶ違う。ただ、幸いな事に改造に影響する[C16][R41][R42]の部品番号は同じに見えたので、基本的には同じ修正を適用する事でコンポジット化できました。

元記事の説明に出てくる端子がどこに相当するか写真で残しときます。

音声についてはRFスイッチを外しても、すぐ横にICが並んでいてあまりスペース取れそうになかったので元記事みたいなミニジャックを綺麗に取り付けるのは諦めて、RFスイッチの位置にRCAを外にせり出す形で無理やり取り付け。そのままだと蓋が閉まらないので少し削りました。こちらは端子周辺のレイアウト・配線はほぼ同じでわかりやすい。追記にあったノイズ対策はやってません。フィルタはまだしも直流カットはやったほうが良いかもしれないけど。



2024年3月23日土曜日

ついにNew City Heroが実機で遊べた

前回のNew City Hero @ j80/macの続き。

エミュレータで動作確認してから実機で〜という事で奮闘しておりました。

まずは搭載メモリの確認からです。

そしてM.K WorkshopさんのPSA基板を利用してボードを作成しようと思ったのですが……上のスレッドでも書いているように、どうにも世の中は半導体不足。表面実装の74ロジックICが思うように手配できません。指定ではLSになっている部品もやむを得ずHCを使う事に……そしておそらくこれが敗因。HCだと出力弱いからファンアウト大きくできないし遠くに飛ばすには不向きってあたりが怪しいのかな、と。

ハンダ周りを見直して気になるとこは盛り直したり、色々とチェックしてみたんだけど改善せず。タイミング周りを調査するのは手間だし、頑張ってもあまり得るものも無い気がしたので、元々の最終ゴールだった完全自作へと踏み出します。 

基本はPSAベースなのでI/O 1981年6月号の記事を読み解いていきますが、論理はCPLDに全部収める方針。また、NCHが3chサウンド対応なので、その部分の拡張も取り込んでいきます。またこのPSAではPCG-8100同様に文字コードの半分の128キャラ分を任意パターンに置き換えられるようになっていますが、256キャラ全部を置き換える拡張にも対応させました。

この辺りの回路も同期回路で置き換え。Verilogで100行ちょっとくらいの論理です。Z80からのI/Oを受けて、かつキャラクタージェネレータ側のアドレスバスとデータバスに繋げる必要がありピン数は70くらいは必要。またピン数多い=レベル変換したくないので5Vトレラントなデバイスが良い……という事で現行チップから候補を見つけるのは難しく、骨董品のMAX7000(7128STC100)

ミキサーとアンプはM.K.Workshopさんの回路を追ってこんなもんかなーって書き起こした回路図を眺めて、増幅回路の教科書的なものと見比べて怪しいと思ったところを手直し。たぶん回路を追いそびれたり読み間違えたりしてる。

そして届いたのがこれ。

表面実装のコンデンサは綺麗につけるの難しいし、確実に線が繋がってるかの自信が持ちにくい。ただでさえ回路に自信がないから不確定要素を減らすために工場で実装してもらっちゃってます。CPLDとかSRAM、ボリュームなんかはあちらで手に入らないものだから自分の方で実装。

最初のテストはこんな感じでCPLDの書き込みをして、次はZ80とキャラクターROMだけ載せた状態でCPLDには信号をほぼほぼパスするーするだけの本体基板相当の回路を書き込んで通常モードの動作を確認します。ここまで動けば基板の方は問題ないからCPLD側の論理のデバッグに集中できる。

んでまぁ、ここでCPLDの論理も一通り出来てたんだけど、検証してからじゃないと本体壊しても嫌だし……と2週間くらい渋るわけですが(笑)とりあえず最低限のテストをして最終動作確認へ。この辺り、趣味でやろうとすると大した環境がなくて辛い。仕事でやってた頃はQuestaでOVM使ってSystemVerilogで書いたテストをぶん回してたんですが、手頃にCI回せる選択肢となるとiverilogになってしまう。でも環境についてはVS Codeで新たにいくつか拡張を導入して試してみました。Verilog-HDL/SystemVerilog/Bluespec SystemVerilogとかWaveTraceとか。後者はライセンス購入しないと8chまでしか信号見れないので購入しちゃった。gtkwaveと比べて何が良いって全てCodeで片付くってだけではあるんだけど、まぁ高くはないし。

という事で出来た成果物はここに置いてあります。実はサイズを図って作ったにも関わらず、Z80とキャラROMの位置が少しずれてて、幅が2.5ピン分くらい狭くなってしまっています。何かしら不具合あるだろうし、この基板で確認できるとこだけでも確認しよう……とソケットの下駄を履かせ、ピンが少し外側に出るように折り曲げて2.5ピン分を補正してます(汗)もしこれを参考に自作する際には、基板は作り直してくださいませ。あとSRAMもこれはもう秋月に売ってないので別のやつに差し替えるなり。そもそもMAX7000ありますか?って話でもありますけど。

こんな感じでばっちり動作、安定してます。NCHクリアまで遊び倒したいと思います。ちなみに実装スペース的には下に一段下駄を入れて上下ちょうど収まる感じですね。下駄がないと下側で他のチップとぶつかるかもしれないし、上もこの状態でキーボード基板に接触しないスレスレでした。接触してもショートしそうな部分がないのは安心ですが、放熱的に少し心配ではありますね。Z80やROMはそれなりに熱くなりますし。

2024年2月28日水曜日

X68000 EXPERT SASIポートの修理

昨年にX68000 修理にて復活!という投稿をしました。

電源をATX電源化、電池はケース化したうえで交換、VRAMが1つ故障していたので交換したところまでが修理の内容でした。ハードディスクはXVIを使って吸い出したもののEXPERTのSASIポートではうまく動作しないままでした。今回はその残るSASIポートの修理についてのメモです。

SASIポート周りについてはOutside X68000付属の初代機の回路図が参考になります。各ポートの制御はIX0909というカスタムチップが1つ鎮座しており、ソフトに見えるレジスタはおそらくその中に入っています。SASIはハードでは制御らしい制御はなく、このカスタムがレジスタアクセスに応じて直接SASIバスの信号を出し入れし、その外にある回路はバッファ程度なので、壊れるとしたらカスタムかバッファに使われているロジックIC、後者なら交換で簡単に直せるはずです。

初代機とEXPERTではカスタムチップの型番とピン配置が少し違います。ロジックICも使っているピンが違ったりはするのですが、基本的には同じ構成です。データバスは74LS642で出し受けしており、双方向バッファの方向は外から入ってくるI/Oで決まりますが、開放時は出力方向になっています。制御信号のうち入力は74LS19がシュミットトリガーで受け、出力は74LS38でオープンコレクタ。すべての信号がロジックの内側は5V、外側は約3Vで動いており、抵抗で分圧したうえでpull-upされてます。

場所的には底面基板に各種IOやFM音源がいます。CPU側のメイン基板から来てるケーブルにバスが全部載っており、電源側の基板からは電源と各ポートの入出力が繋がってます。Sと書かれた2本線がサウンド出力で内蔵スピーカーに向かっているようです。

投稿でカスタムと642の場所を説明してますが、さらに38は642の右に2つ並んでる38のうち左側のものがSASIとカスタムの間にあるやつです。今回は642にあたりを付けて交換しましたが、制御がおかしい場合にはこの38を交換する必要があるかもしれません。他にはアレイ抵抗が壊れてショートしていないかなども注意した方が良いと思いますが、底面基板なので電源入れて直接電圧を確認するのは難しいです。もし怪しいと思ったら、外に出てるSASIポートの電圧で確認するのが良いと思います。

データバスに関してはソフトでレジスタ叩いて出力の変化を見るのが良いかもしれません。

カスタムは出力中でもピンの電位を読み出せるようです。つまり、書いた後に読んだ値が実際にカスタムと642の間のデータバスの電位になります。ここで値がおかしいようなら642が外向きになっていなかったり、バッファが死んで常にGNDやVCCに張り付いているような状況が疑われます。一部張り付いているなら642を、全部張り付いてるなら38から入ってるI/Oを疑うのが良いかもしれません。またこの値は反転した形でSASIのデータバスに出ますから、ポートの電圧を測る事で642経由で期待通りの信号が出てるか確認できます。bitの値が0なら約3V、1なら約0Vですね。

今回は交換するまでは良かったんですが、交換時にソケット化したせいでICの位置が高くなってしまいシールドに接触するという大失態を侵しました。場所的にまさにシールドが出っ張っている位置なので要注意です。C1とか81あたりしか書けなかったら同じことをやらかしてる可能性大(笑)

という事でSASIポートが直ったのでSxSIを使ってBlueSCSIを接続するわけですが、それはまた別のエントリで詳しく書こうと思います。

ちなみにSASIのバスを3Vで駆動しているけど、これは何もバスが3V論理だという事ではないようです。SCSIの仕様書をみると5Vも許容範囲ですし、EXPERTや初代の回路的にも5Vを受けられるように設計されてます。3Vでpull-upしているのはターミネーターの推奨値だからかな?初代機の抵抗値はSCSIリファレンスの分圧でターミネートする時の推奨値でした。EXPERTはもう少し小さい値で近い比率で分圧してたように思います(具体的な数字はメモしてなくて忘れてしまった)。

2023年2月6日月曜日

CPLDでシリアル扱うの難しいね、という話

この件について、反省文ですw 

もともとやろうとしてたのは、シリアル伝送の18bit PCMデータをI2Sに変換すること。んで、想定してた元PCMの周波数が8MHzのクロックが入ってるので分周して半端なサンプリングレートだろうと思っていた。そうなるとなるべく高い周波数で非同期で変換してやるしかないかな、という事で96kHzのI2Sで読み出すことを考えていた。

この際、ハードで実装するならFF打つ回数を限界まで減らさないと無理だと思っていたので、内部には18bit x 2chの36個のFFを用意して、元の信号で順次更新、I2Sで非同期に読みだし。元信号がMSBから出てくるし、倍速以上で読み出せば誤差はLPF通せばほぼ消えると思ってた。

この時の間違ってた想定は「MSBから更新してけば、どのタイミングで読み出しても更新中の値は更新前と更新後の値の間にあるだろう」で、これは完全な誤り。例えば16bitで考えると、0から-1へ更新が入る時は、MSBが入った瞬間に-32768へ値が飛び、徐々に大きなビットが落ちて-1へ近づく。なので、たまに大きなノイズが入る。

もう1つの誤算は元の信号が半端な周波数ではなかった事。きっちり48kHzで出ていたので96kHzで読み出すと、ノイズの載る位置が固定化されて、クロックドリフトでゆっくりノイズの載るビットがズレていく。これがTweetで見ていた現象でした。

最初はメタステーブルかと思って、入力側のクロックを一桁速い出力側のクロックで取り込んで2段くらいFF打ってから使ってみたんだけど関係なかった。

で、これを真面目に対処しようとすると、18bitのシフトレジスタで更新していって値が確定時に別の18bit FFに取り込み。で、これをI2Sから直接出すと、やっぱり出力中に値が変わっちゃうことがあるので、I2Sもフレームの最初のタイミングで18bit FFに丸々コピーして、そこから読み出し。結局3段のバッファが必要なんですね。ステレオだからバッファだけでFFが108個かな?EPM3064だとFFは64個しか無いので、一気に3倍になったFFを実装するのは無理で、結局2枚のチップに分けて入れました。I2Sの出力に6bitカウンタが必要だし、他にもタイミング作るのにいくつかFFが必要なので、分けてもギリギリでした。はぁ……材料不足つらいですね。

それと、Qiitaに雑なI2Sの理解として軽くメモ書きを残しました。

2023年1月30日月曜日

X68000 修理にて復活!

はじめに

X68Z ハッカーズエディションを試せる事になったので、それに先立ってずっと故障したままだったX68k EXPERTの修理をし、無事元気になったのでその報告です。

壊れた経緯は例にもれず電源です。ただ大学のサークルの部室に置き去りにしてたのが、煙を吹いて動かなくなったという連絡があって。それを回収してそのまま20年近く放置してたのかな?それ以来、ハードディスクも火を入れずにずっとしまい込んでた。

ちなみに他にcompact XVIというかredzoneも所有していて、あとはサンデーネットが閉じる時にもらったXVIを所有してますが、両方とも電源が理由で死んでました。XVIも電源修理であっさり直ってますが、特に新しい話題はないのでEXPERTの修理の話を発掘しやすいようにまとめとこうと思います。

まずは電源から

という事で、まずは電源交換の本スレがこちら。

BEEPさんで購入した、同人サークルさんがセットで用意してくれたPico PSU換装キット。今回は日和ってまずは確実に動く状態にしようと安全側に倒しました。キットがなくても12V、5V、-12Vを拝借できれば良いので、この手のがなくなっても最悪どうにでもなるのかな、と思いました。今なら修理方法も世の中に出回ってるし、ヤフオクで交換部品のセットを安くまとめてくれてる人もいるので、そういうのを利用すれば数千円くらいで直せるんじゃないかな?Pico PSUだと5Vの供給が足りないかもアドバイスもあったので、Phantomで強力なラズパイを使うとか、拡張ボードを挿してるなんて場合は電源を修理した方が良いのでしょうね。

エラーが発生しました。リセットして下さい。

電源は入ったものの最初みたメッセージはこれ。やっぱり何か壊れてる?

って事で、この時点で一番怪しいのはSRAMのデータが飛んでる事態。まぁ、長年放置してたわけで、当然バックアップの電池は死んでますね。SRAMの内容が壊れてるとブートデバイスの情報も消えてるので、結果としてさっきの画面に飛ぶのかな。なのでOpt.1を押してFDから強制起動を試すことで先に進めます。まぁ、普通はここでFDDが死んでて起動できない気もしますが。しまい込んでたと言っても、ずっとマンション内で空調の効いた仕事部屋に安置されてたので状態は良かったようです。

電池交換

続けて電池交換はこちら。EXPERTだと+側の2端子のうち1つはN/Cなので、パターンを見て繋がってるほうにハンダしてあげて下さい。使ったのはCR2450だけど3Vならなんでも良いのかな?

電池が入ればOpt.1でHumanなりを起動してswitch.xで設定してやればエラーは出なくなります。

テキストVRAMの交換

何事もなければこれで修理完了だったんでしょうけど、残念ながら他にも壊れてました。

こんな感じで画面の上の方に点線が現れます。これだけなら少しノイズがあるだけで我慢できますが、テキスト面で画面上方となると、スクロール等で画面中にコピーされまくります。特にテキストはピクセル単位じゃなくプレーン方式なので、特定のプレーンだけゴミが撒き散らされて。用途によってはパレットをうまく使ってマスク用プレーンにしてたりするんで文字がまったく見えなくなっちゃったりします。

という事で奮闘開始したのがこのスレ。

まずはメモリーテストでテキストVRAMでエラーするのを確認。M51C262相当品は新品入手は難しそうだったのでAliExpressでリサイクル品を探して発注。HM53461ZPを見つけて購入しました。ワードアクセスと平行してシフトしながらビット読み出しもできる感じのマルチポートなのかな?こういうタイプのメモリは初めてだったので、変換ボード組んで載せ替えるとかは避けました。

メモリが届いてからは実際に壊れてるチップの特定作業。XVIとかはサービスマニュアルが公式から公開されてるけどEXPERTにはないんですよね。ただまぁ、そこまで変わってる部分じゃないだろうって事でXVIの回路図は確認しました。それでテキストVRAMはこの4bitのチップを4つ並べて16bitにし、各チップのメモリ空間がちょうど1プレーン分ある事がわかります。なので、それをx4で4プレーン分載せて合計16枚でテキストVRAMを構成してる。シルクで書かれてるIC番号は当然XVIとは違うけど、まぁ同じような順番だよねっていう想像もできるので、若い番号からプレーンごとに並んでるんだろうな、という予想もできます。

実際に壊れた箇所は自分でテストプログラムを書いて詳細に調べました。$00e60e00 - $00e60fff にかけてbit 10-11の2bitがhighにならなくなってたので、最終プレーンでbit 8-11を担当してるチップを交換すれば良い事になります。プレーン内の並びは回路図の信号名で当たりをつけてLSB側から並んでると判断。という事で、16個中の15番目のメモリが怪しい。

VICONから配線を追うことができればEnableがどこに繋がってるかで並びは確定できるんですが、拡張スロットの下にあって調べられませんでした。拡張スロットって外せるんですかね?

そんなわけでメモリ交換はシュッ太郎の出番。ただ電源ピンはかなり苦戦します。昔は原因理解してなかったんだけど、これって当時の基板はthermal reliefとか考えてなかったからですよね。ベタで繋がってるんで熱が逃げちゃうから基板全体を温めるか火力を上げるか、みたいな。この辺はベテランの人のノウハウを知りたいところなんですが、自分はわりと細いドリルで掘りがち。今回もチップは抜けたけどGNDの穴は再び塞がっちゃって。グリグリやって穴を確保しました。

という事で、EXPERTは左からplane 1の3:0、7:4、11:8、15:12、plane 2の同じく、plane 3、4って順に並んでるので、もしテキストVRAMが壊れて交換が必要って人がいましたら参考まで。

ハードディスク

SxSIでSCSI読めてたはずなんですが、どうもsusieで認識しない。ハードディスクも怪しいし、68も怪しいし、加えてPhantomを載せてたから問題の切り分けが難しい。という事で、ハードディスクはXVIを直してそっちで救出しました。SCSIボードも持ってたはずなんだけど、誰かにあげた記憶もあって見つからず。本体にSCSIついてるXVIで面倒だけど確実にチェックする方法を選びました。

ハードディスクのサルベージに関してはPhantomさんが本当にスグレモノで。SDカード上に仮想ディスクを作ってくれるので、ハードディスクが無事認識したらmintで仮想ディスクに全部コピーしました。奇跡的にも全部読めたんですよ、もうびっくりです。吸い上げたディスクイメージはクラウドとバックアップストレージに入ったので、たぶんもう僕の命より堅牢。

吸い出し後はPhantomを今回修理した長年の相棒でもあるEXPERTに戻し本格的に再運用を開始しました。

SxSIはおそらく自作で追加したパリティ回路の74が壊れてるんじゃないかと予想。バスリセットとかは飛んでディスクは反応してるんですよね。パリティエラーでネゴれてない印象でした。

2021年11月6日土曜日

naomiのガンコン対応ゲームをお家で遊ぶぞい

IONA-USを作ったので、USBのコントローラさえ存在すれば、あとはファームウェアなんとかするだけでJVSの特殊コントローラとして動作させる事ができる。そんなわけで、今回はアーケードゲームを家庭で遊ぶ上でやっかいなガンシューに対応してみようと思います。

まず肝心なのは、液晶環境で動作する汎用ガンコンを見つけるところ。調べたところ、どうやらPS3のタイムクライシス4に付属していたガンコン3が液晶でも遊べるとのこと。ヤフオクなどで5,000円前後くらいで入手できそうです。同時期に同じような仕組みでPC向けなどに出ていたガンコン(TopGun III、Single Arcade Guns、ArmTrak)もあるようなのですが、10年前、20年前ならまだしも、今は入手が難しいですね。Cabela's Top Shot Elite Firearm ControllerってのがWii/PS3/Xbox 360のバリエーションがあって辛うじてebayで手に入るかな。playasiaにあったので注文したら「ごめん、やっぱなかった」って払い戻し面倒でした。って事で日本ならガンコン3が入手性の面でもオススメ。現実的な値段で入手するならガンコン3がレア化するギリギリ前の今が最後のチャンスなのかもしれません。おそらくFPS勢は既にVRに行っちゃってますからね。モニタの座標をとる必要のあるUSBデバイスとかPS4世代以降は需要がないんだと思います。Switchのジョイコンのセンサーにアタッチメントってあたりならワンチャン……って感じなのかな。

ガンコン3の設置はそこまで難しくなくて。USBから電源だけとってる2つのマーカーLEDがあり、これをモニタの左上、右上に正面を向けて置くだけ。電源もらってるだけなので、このUSBは充電アダプタとかに繋げるのでもOK。一方でガンコン側のUSBとしての挙動は少し複雑。期待してたのは標準的なPS3互換のレポートでアナログ部分に座標が入ってくるってくらいだったんだけど、完全に独自クラスどころか、表向きは1ポートのUSB Hubで、その向こうにベンダー固有クラスを使ったデバイスが仮想的に接続され、データをシャッフルして通信する独自プロトコルになってます。これ、先行して調べてくれてる人がいなかったら面倒で投げ出してましたね。ちなみにこの人が調べてるのはHubの向こうに仮想的にぶら下がってるデバイスのプロトコルのみ。ハブ部分は標準通りなので一般的なOSならシステムが処理してくれて、ハブ越しに現れるデバイスのドライバさえ書いてやれば動く。という事で、IONA-USにはハブの簡易対応コードを追加し、その上でこの独自デバイスを仮想HIDとして扱い、そこからJVSにマップしてやるコードを追加しました。

JVSへのマップについてはnaomiのDeath Crimson OXに対応してみました。アナログ0と1が1PのX座標とY座標、アナログ2と3が2PのX座標とY座標になってます。それぞれボタン1がショットという素直な配置。スタートボタンも必要だったのでA1っていうボタンをアサインしました。

画面内・外の判定はキャリブレーションをやればゲーム側で勝手に判定してくれます。最初、キャリブレーションをIONA側でやるとしたら大変だなーって思ってたんですよ。マイコン的にはクロックはそこそこ早いとは言えアーキテクチャは8051ですから。ホモグラフィ変換行列の計算(プロジェクションマッピングとかと同種の計算ですね)とか、自前で浮動小数点と三角関数を用意しないとかなーって。でもゲーム側でキャリブレーションするなら生のデータを送ってやれば最低限はOK。デバイス的には見える世界を二次元の投影で理解して、マーカーの位置から向いてる方向を計算しているだけの値が上がってきます。各地点で奥行きの距離とか考えて歪補正したりはしてません(そこまで自動でやるにはマーカーは4つ必要だし)。

ただ、ゲーム側のキャリブレーションもそこまで真面目な計算はやってないんですよね。なので、基本的にはモニタの真正面から、投影に歪みの出ない位置関係で遊んでやるのが望ましい。という事で、本当はIONA側でホモグラフィ変換かけてやれば追跡精度も上がるんだろうなぁ。キャリブレーションが2重になってわかりにくくなっちゃうけど、設定モードつけて画面4隅をマークさせればホモグラフィー行列も求められて、斜めから撃ってもゲーム側では補正された正方形とかで判定できます。まぁ、今の所そこまでやる予定はないですが、興味ある方の改造をお待ちしております(笑)。ただ、ファームウェアサイズ的にはメインに取り込むにはキツイとは思ってるのでマージできるかはサイズ次第かな。

という事で、実際に遊んでみた動画がこちら。

1.31から正式に対応してます。 

2021年8月16日月曜日

IONA-USが(製造的な意味で)できるまで

なんとなく製作記事です。

KVClab.さんでの販売が始まりましたが、どんな過程で製造してるのか簡単に紹介。前作のIONA-JS以上に部品が細かくなっているので作るのも大変。テスト含めて色々と工夫してます。

一番最初はまず裏面のmicro USB端子から始めます。このハンダ付けが一番難しく、また電源なのでショートしてたら大惨事なので、このようにテストボードに繋いでショートしてないか、GNDと電源が正しく繋がっているか、テスターで確認しています。

次のステップではマイコンと周辺のチップ抵抗、チップコンデンサをハンダ付けし、JVSのコネクタを実装します。抵抗やコンデンサはこの時点で必要ないものも含まれています。というのも、コネクタを付けてしまうと後からハンダ付けするのが難しくなってしまうからですね。

続けて、ファームウェアの書き込み。ここでPCと接続し、サポートページにあるファームウェア更新ページを使って出荷用のファームウェアを書き込みます。ファームウェアを書き込むまではサービスボタンを押さずに電源を入れてもファームウェア更新モードになるため、ボタンを実装している必要はありません。これによりマイコンの基本的な動作確認とJVSコネクタ、電源コネクタのテストができた事になります。

次にLEDの実装。電源を入れて点滅すればファームウェアは無事に起動しています。あとLEDを逆向きに挿してないことの確認にも(笑)

ここまで来たら、あとはボタンとUSBコネクタのハンダ付けをして完成させます。

最後に最終動作テスト。右側の白い基板がIONA-USのテスト用に作った基板で、JVSホストの機能を持つUSBデバイスです。PCに繋ぐと2つのゲームパッドとして認識され、JVS側に繋いだI/Oからの入力を反映させる事ができます。これにより、JVSバスで正しく通信できる事、テストとサービスボタンが正しく反応する事が確認できます。またUSBコネクタにゲームパッドをそれぞれ繋げ、入力が正しく伝達する事を確認します。対応パッドを繋げばLEDが点滅するのでUSBバスの動作は確認できるし、ボタンについても同時押し2回で保存データの初期化を行えばLEDが点滅するため、実はこのボードがなくても確認はできるんですけど。やっぱりあると色々と便利で開発効率があがります。

IONA-JSの場合は最後のテストがもう少し大変で。ボタン毎に断線・ショートがないか確認しなければならないため、このフェーズでボタンを1つずつ押して個別に反応するか調べなければなりません。

実は最初の頃は1枚1枚naomiとJAMMA環境に繋ぎ、ボタンを1つずつ確認をしていましたが、あまりにも面倒なので途中でこのボードを作りました。このボードはJAMMAの入力をマイコンから制御し、右側に出ているJVSホストを使い、JAMMAからの入力がJVSを通して正しく返ってくるか確認する事ができます。これを使って自動的に個別のパターンを送ってテストしています。テストに失敗したらどのピンに異常があるかわかるので、該当ピンを虫眼鏡で見ると浮いてたりブリッジしてたりするので修正するって感じです。だいぶ手間が減りました。最後にnaomiに繋いで認識されるかだけは確認しています。これはVer 1系のボードで本番環境だと電源との相性なのか、クロックがうまく入らずに動作しないケースが稀にあったためです。Ver 2系のマイコンは内蔵クロックで動くため、この辺の心配はなさそうです。あと最近はテストボードでSENSE信号の電圧も測定するようにしているので、その辺も相性問題が出そうな個体を事前に識別するのに役立ってるかもしれません。

まぁ、そんなわけで、ありがたいことに同人ハードとしては結構な人気商品になりました。アーケード環境維持のために少しでも役立っていれば嬉しいです。

おまけ:筐体を置く場所もなく今までDYIでアーケード環境を作ってきた結果生まれてきた同人ハードでしたが、新居を構えるに際し、ついに筐体を購入しました。シューティング好きという事もあり、モニタの回転が比較的簡単にできるイーグレット2です。なかなか中古市場にも出てこないため、引っ越しまでずっと張り付いてないとかなーって思ってましたが、探し始めてすぐ「近日入荷」のお知らせを見つけ、連絡して契約成立。今はまだ新居に近い妻の実家に置いてありますが、来年春には新居も完成し、自分の仕事部屋に基板格納庫とともに設置されます。楽しみ:)



2020年8月13日木曜日

基板修理:続・ムーンクレスタ

以前、メインボードだけの状態からサブボードを全部自作して復活させたムーンクレスタですが、追加で少し直した場所があるので記録。

1つ目はこれで。まぁ、ぶっちゃけマルチになってるんだけど。 

で、最後の修理はショット音。ざっくり信号の流れを書くと、9Lで0xA805へのアクセスを受けてショット音のトリガの一方はそのままダイオードとコンデンサを使って徐々に減衰する信号となり、他方は8LのNANDの1番、2番へ入り、要はINVとして使って反転した出力が3番から外へ出て7SのNE555へ。この555からの出力と先程の減衰信号が7Rにある4066へ入りショット音を形成し、最終的には7Tのオペアンプを通った後に他のサウンドと合成されてボリューム回路部分へ流れていく。で、最初はサウンドの要であろう555を疑ったんだけど、それは間違いで。よくよくオペアンプの入力を圧電ブザーに繋げてみたら、それっぽい効果音が作られてた。そんなわけで7Tのオペアンプを交換したら無事にショット音も鳴るようになりました。

これで一応、自分で気づける範囲ではすべて正常動作するようになりました。めでたし。 

2020年8月12日水曜日

IONA-MJ

 IONA-JSの別バージョンの基板としてスーチーパイ対応の基板を作ってみた。

下のJAMMA端子に繋げばIONA-JSと同等の機能、上の麻雀端子に麻雀ハーネスを繋げばスーチーパイに対応したJVSの信号に変換します。スーチーパイについては以前の投稿で調べた情報を使いました。Arduino版では無理やり入力組み合わせで遊べるようにしてあったんだけど、今回のでまともなコントローラ繋げられるようになりました。めでたし。

端子判定については、レバーで同時入力できない組み合わせの信号を麻雀端子側ではGNDになる端子にそれぞれ割り当ててあり、起動時にレバー同時入力が発生していたら麻雀モードって感じになってます。たいした需要もないはずなので販売の予定はありません。

基板修理:鉄拳3

久しぶりの基板修理。あまり精神的な余裕がなくて……と思ってやってなかったけど、違うな。修理した方が気分がスッキリした。

という事で、起動しないSystem12の鉄拳3の修理。まずはどのボードに不具合があるのか調べるためにSONYの基板COH-700を同じくSystem12のワースタ99と交換。これであっさり起動してくれました。

COH-700に関してはあまり個人でできる事はないような気がしてたんだけど、とりあえず電解コンデンサの交換は海外の掲示板でそれなりに見かけたので練習がてら実施。表面実装のところを敢えてリードタイプに置き換え。表面実装は古くなってから載せ替えるとパターン剥がしちゃいそうだし。

画面の同期信号は来ていたのでCPUまわりかなぁ……と右下のやつから交換してったのですがハズレ。下のがCPUで真ん中がGPU、上の2枚がGPUフレームバッファ用のメモリかな。一番上のnamcoロゴの横のやつが天井に穴っぽいのが空いていて容量が半分くらいになってました。ここまで交換した時点でたまに起動したり、起動しなくても最初に画面周りの初期化が走る際に画面が点滅したり。他のコンデンサは「念の為のノイズ対策」で動作に大きく影響しなさそうだったんだけど、今回は経験値上げるって事で一通り交換。やっぱり変化なし。

その後、接触の悪いICがないか調査。大きなやつの足がきちんとハンダ付けされてるか、オシレータとかも含めて表面実装の小さいやつが欠けてないかとか目視で確認したんだけど気づくような問題はなし。各チップを押したり基板に少し力を加えたりすると不安定になるのはわかる。止まるときは画面も音楽も固まってしばらくしたらリセット、という動作。クロックとかリセットを疑ったんだけど違う。CPUのバス化けかなぁ……とメモリのハンダ付けをし直してみたけど効果なし。


触ると不安定になる事は多かったんだけど関係ないだろうと思ってた左上のMC44200FTを最後に確認。基板の中央側に当たるチップ右側の足をハンダ補強したところ……安定しました。うーん、このチップについてはデータシートが見当たらなくて、でもまぁ見てわかるようにRGBのDACなんですよね。不具合あっても画面でなくなるくらいでCPUやサウンドは動くと思ってたんですけど、そうでもないんですね。基板むずかしい。

2020年6月30日火曜日

AVR JTAG ICE

AVRに関してはIDEやデバッガを使った開発はしてこなかったし、世間的にもあまり普及してる気はしないんだけど、最近だと1万円も出してATMEL-ICE-BASICとか買うのが正解なのかな?ARMはどこも統合開発環境が整備されてるんで、ARMのラインも含めるとこういうのないと戦えないってのはわかりみだけど、AVRのサポートも継続してるのは素直に喜ぶべきか。

手軽にデバッガ試すなら太古のJTAG ICE互換のデバイスが数百円程度で売ってたりはするのだけど、対応してるのはAVR Studio 4.18まで、かな?古いデバイスしか使えなかったりはするけど、まぁ使えなくはないので試してみた。

JTAG ICE互換デバイス自体はシリアルポートとしてアクセスされるだけ。自分が入手したのはCH340使ってたので、それ系のドライバを入れる必要はあった。

Windows 10だと色々と問題があって大変なんだけど、Windows 7とかなら(サポート切れててアレだけど)WinAVR-20100110との組み合わせで苦労なく動く。Windows 10の場合は32-bitと64-bitで起きる問題が違ったかも。32-bitだとDocuments以下にプロジェクト作ろうとしてもセキュリティ機能にブロックされてディレクトリ作成に失敗したりファイル作成に失敗したり。自分の場合、この問題は64-bit環境では起きなかった。

一方で共通で起こった問題としては、まずはインストーラが起動しない問題。これはシステムのセキュリティ機能にブロックされての事。ダウンロードされた実行ファイルにつく例のフラグを属性変更で落としてあげても起動できない。4.19だと属性落とせば起動するので謎だけど、何かブロックリストに入る理由があるんだろうか。これに関しては管理者権限で動いてるcmd.exeから実行する事で回避できた。AVR Studioに限ったことではないので、この最終手段は覚えておいて損はないかも。

インストール後の問題としてはWinAVR内に含まれるmsys環境のコマンドの大半が起動しないこと。これによりビルド開始後にだんまりとか、makeが動かない、depsが作られない、などなど変な問題が沢山発生した。これはWinAVR-20100110\utils\binをMinGW最新のmsysで置き換える事で一通り問題なく動くようになった気がする。これはセキュリティが関連してるのか、メモリ配置ができなくて怒られてるのか微妙。forkでこけるやつもいたし。mingw-get-setup.exeからmsys-base-binだけインストールして、msys\1.0\binをutils\binと置き換えてやればOK。

WinAVRの代わりにいっそのことと新しいのgcc使ってみたりもしたけど、デバッグ開始と同時にIDEが落ちた。たぶんデバッグ情報とかのフォーマット違いに対応できずに死んでる気がするので、こっちは諦め。

2020年2月11日火曜日

XC9536の開発環境

5V動作で安く入手できるCPLDって事で、基板を日常的に起こすようになると一定の需要がある。もともとは大昔に買い溜めてたXCR3032あたりを使ってたんだけど入手性が悪くなってるので……まぁXC9536も趣味を超えて使うには厳しい感じですが。

開発に関してはISE14.7最終版にもサポートが残ってるので問題は少なめ。ただ書き込みに少々難ありで。自分はUSB環境だとPlatform Cable USB/II互換を謳う中華品を使っていたんですが、どうにもiMPACTでも動作が怪しい。XCR3032ではうまく動作してたんだけど、XC9536に関してはJTAGでデバイス検出まではできるもののProgramしてもVerifyで失敗、Blank CheckするとOKが返って来てしまう。Get Device Checksumでも不一致エラーで、そもそも特定の操作順を守った時のみAvailable Operationsに操作が表示されるという変な状況でした。

で、エラー情報で色々と調べてみたらDIGILENTのフォーラムで似たような話が。そう言えば今まで見落としてたけど、この中華装置はDigilent JTAG-HS2として認識されていたのでした。という事で、このケーブルでは9500シリーズは未対応らしい。Platform Cable USB/IIの人はたぶん大丈夫?

そうなると家にあるのは15年以上前にSpartan3 Starter Kitで使っていたパラレルポート用のダウンロードケーブルのみ。幸い以前必要になった事があって自宅サーバーになってるキューブ気にはパラレルポート拡張用のPCIボードが刺さってたりISEがインストールされてたり。という事で試そうと思ったんだけど、ドライバーのwindrvr6がloadできない。以前使ってた時から何度もUbuntuのinplace upgradeをしてるのでそりゃそうかっていう。という事で、

% cd /opt/Xilinx/14.7
% cd ISE_DS/common/bin/lin64/install_script/install_drivers
% ./install_drivers
って感じでインストールしようとしたら……
linux_common.h:29:4: error: #error "This kernel is too recent: not supported by this file"
 #  error "This kernel is too recent: not supported by this file"
    ^
linux_common.h:51:2: error: #error "unsupported linux kernel version"
 #error "unsupported linux kernel version"
あぁ……。ソースみたらKernel 2.2, 2.4, 2.6しか対応してない。確かにそんな時代の産物でした。これしか選択肢がなければドライバいじりを始めたんだと思うけど、僕にはこんな時のためにレガシーCAD用のVMがある!(あるいはVivadoの配布パッケージから最新版のドライバだけ抜き出すこともできたかも)

という事でVirtualBoxにプリンタポートを直接見せることができないかテスト。ちなみにGUIからは設定できないので面倒。
% vboxmanage modifyvm CentOS5 --lptmode1 /dev/parport1
% vboxmanage modifyvm CentOS5 --lpt1 0x378 7
そう、CentOS5の環境がまだ生き残っているのです。このままだと通常の環境だとVM起動時に/dev/parport1が開けなくて怒られるはず。これはlpがデバイスを専有してるため。なので、マニュアルで一時的に外すなら
% rmmod lp
が必要。あとパーミッションも0666にしてあげる必要あり。 このあたり、永続化させたいなら/etc/modulesからlpをコメントアウトすればOK……と思ってたんだけど、これだけじゃ今どきは駄目っぽい。おそらくcupsが起動時になんかやってるのかなーってinit.dをみたらinsmodしてたので、こいつを外す必要あり。で/etc/defaults/cupsを見たら、この辺りの設定は/etc/modules-load.d/cups-filters.confに移行した、とあるので見たらここにもlpが居たのでコメントアウト。たぶんこれでOKかな?パーミッションはudevでよしなに。

ちなみにCentOS5の環境を維持するのは難易度高めです。なにせシステムで使ってるTLSが世の中からbanされた太古のバージョンなので、そのままでは通信が軒並み動かない。セキュリティー系のチェインを一通りソースからbuildして、その上でgitやらなんやらの開発環境を作り直す必要がありました(これは結構前の作業で詳細はマシンのログにしか残してない)。

それと番外編的な話題として、9536のリビジョンが2じゃないと更に苦労があるようです。このあたりはFramさんのCPLD(XC9536無印)の書き込み環境を構築するまでの紆余曲折に書いてありました。9536使おうとすると一度は目に入って怖気づく or やる気がでる記事。

ちなみに、パラレルのケーブル刺そうとした時にマシンの電源コネクタが抜けてサーバ落ちて「ギニヤー」ってなりました。その後VMWare Playerとどっちが楽だっけなぁ……と一瞬起動したのちにVirtualBoxを起動したらネットワークが繋がらなくて、VMWareのドライバとコンフリクトしたかなぁ……と調査したりもしてたんですが、実はパラレルのケーブル刺す時にLANケーブルも抜けかけてブリッジネットワークに使ってたNICがdownしてただけでした。

作ったやつはこれ。


以前作ったこいつを1 chipで置き換えようかと思ってたんだけど、I/Oがpullupをサポートしていないタイプのシリーズだったと気づきボツに。SMD network register使った基板を作り直しますorz


2020年1月25日土曜日

基板修理:ムーンクレスタ


っていう。結局、サブボード一通り作って動作確認したら、やっぱり動かなくて調査したところメインRAMが死亡。交換して修理できました、という話。

手始めにまず面倒なコネクタをJAMMAに変換するところから。


合致したコネクタを探すのも面倒なので、直接ハンダ付けで済ませようと、こんな基板を用意しました。


裏側からこんな形でハンダ付けする事もできますし、表面からピンをホールに通してハンダ付けする事もできます。今回、表でハンダ付けすると変換基板にミスがあった時に取り外すのが難しくなりそうだったので、炙れば剥がせる裏面から攻めました。


表はこんな感じになるので、万が一オリジナルのO/P/Q端子が必要になっても大丈夫。

で、サブボード系のうちまずはメモリ。同じチップが入手できればボード起こす必要はなかったんだけど、探す手間とコスト、今後のメンテナンス性を考えたら基板を起こした方が早かったので。


一番右上に並ぶ1ビットx5のRAM。これらは全部同じアドレス、同じタイミングでアクセスされるので普通の8ビットSRAMで置き換えました。4044ではデータ入力と出力それぞれが別ピンになっているため、入出力共通の今どきのSRAMに繋げるにはtri-stateで受けてR/Wで出力を切り替えてあげる必要があります。本来の挙動を忠実に再現するためには、書き込み中にZを出力するためにもう1つtri-stateが必要なのですが、書き込み値をそのまま外に垂れ流しても外部回路的にOKだったため省略しています。


もう1つはこれ。VRAMに使われているメモリだった気がする。うっかりtri-stateに繋ぐ信号を間違えて基板を作ってしまったため、パッチで直してます。下をくぐってる3本の線は関係ありません。元々ムーンクレスタで使ってるオブジェクトのバンク切り替え用の配線です。本来(ギャラクシアンが)coin lockの出力に使っていたレジスタの値をバンク指定に流用しているようです。


これはオブジェクト用のROM。16bit幅で元々は複数の8-bit ROMに分割されていました。サイズも小さいので16-bit幅のEPROMを使用。それでも容量あまりまくりなので、とりあえずDIPSWで4面分データを入れられるようにしてあります。接続されてる3本の線は先程の説明の通り、coin lockから。バンク制御はDIPSWの値を見ながらGALで制御できるようにしてあります。


これはPROMの置き換え。PROMは入手はできるけど書き込み環境を揃えるのが困難なので……。ちなみにパレット用です。


最後にこれはプログラム用のROM。本来はEPROMが8枚ささった大きめのサブボードになってるやつです。Enable信号のANDを取るために74の論理が1枚載ってます。また、このメインのROMは暗号化されてるのが普通なのかな?アドレスとデータで軽くシャッフルされていて、CPU側の周辺回路でdecryptしながら実行するようです。今回は面倒なのでdecrypt済みのデータを置くことに。ちなみにムーンクエーサーはM1サイクルのみdecryptするのかな?なのでdecrypt済みのデータを作るのは実行時データが必要なのでちょっと面倒そう。そのうち実験がてらdecrypt側の論理を入れたCPUボードを起こすかも。あと、もしギャラクシアンとの共通化を考えるなら、CPUボードでI/Oのアドレス変換までやっちゃうのが楽かな。

ここまで作って起動してみた状況はこちら。


SYNCはちゃんと取れてるけど、横長のドットがちょろちょろっと表示されるだけの画面。音もたまにぴーひゃららーと鳴ったり鳴らなかったり。この段階でCPUから出てるアドレス線の観測をして、正しそうな順序でリクエストが出ている事を確認。最初のリターン命令で壊れたスタックから戻りアドレスを読みだして暴走している、と予想。

という事でメインボードからメインRAMを交換。プログラムROMに近くにある2枚の2114がメインRAMです。こいつもサブボード起こしても良かったんだけど、たまたま秋葉行く用事があったし、若松通商に在庫があるようだったので、今回は2114そのままで置き換えました。



これで基本ロジックはほぼ動作する事が確認できた。オブジェクトが読めてない気がしたので作ったサブボードのGALを確認したら……論理書き込み忘れてたorz


という事で、論理を入れたら絵もでました。ただ、16ビットの上下を焼き間違えていたみたいで色がちょっと変、という事にあとから気づきましたが……。

あと、現状で気づいた問題は自機のショット音が鳴っていない点。サウンド周りはディスクリートなので難しい。後で追ってみます。

最後に基板全体像をパシャり。


備考:ここまで大規模な修理になると、お前はその破れた一万円を交換するにあたり本当に一万円札の2/3を持っていたのか?的な気分になります……特に今回はソフトウェア部分が丸々欠落していましたし。ただ、この点に関しては過去の裁判の判例をいくつか踏まえた上で、現状でエミュレーションベースの移植版を正式に保有しているので、そこからの私的複製という立場をとらせて頂きます。

備考2:コメント欄で質問があったので2枚目のVRAMボードの回路図を載せておきます。J1とJ2の名前に2101って書いてあるけど5101だな。


SOPをDIPで置き換える基板

1.27mmピッチのSOPを置き換えたい事がわりとある。ROMの類いだとパッケージ互換のEPROMが存在しなかったり、近い形状のフラッシュとかあっても若干ピン配置が違ったり。修理に際してはちょっとしたリスクだったりします。

巷でみる方法では、同サイズの基板を作り周辺にスルーホールをはみ出す形で配置、スルーホールを二分する形で基板をカットする事で足の代わりするのが一般的でしょうか。より小さい表面実装部品で代用できる場合にはこの手の基板を作るのも手です。特定のハード限定の改造などではCPUの上からソケットを被せて信号を引き出す荒業とかもみかけるけど……汎用性はいまいち。追加のパッチワークが必要な事も多いです。

で、思いついた方法があったので試してみました、という記事。


作った基板はこんな感じ。2.54mmピッチを入れ子にしたようなホールを打ってあるのですが、ここに写真のタイプのL字型ピンヘッダを使います。


こんな形で入れ子にして二列ずつ。外に向けて出して……


最後に足の長さを揃える。これで1.27mmピッチの足のできあがり。あとは表側にDIPソケットを実装して、裏に出たこの足を基板にハンダ付け。


この1.27mmピッチの部分に載せます。ハンダ面は基板の影に隠れるのでやや作業難易度が高い。最低限、となりのピンとショートしてない事は電源投入前にテスターで確認したい。


で、こんな感じ。がっつりハンダ付けされるので安定性は抜群。問題があるならば、影に入ってしまう部分の修理がしづらくなる事と、高密度な部分だと連続して何枚も置き換えるのが難しい事。でもまぁ、追加の選択肢としてもっていると安心。

基板修理:がんばれギンくん

ぱっと見、問題なさそうなものの、実はオブジェが表示されてなかった基板。遊べそうでいて、いざミニゲームが始まると何も表示されてなかったりと難易度が高いw

で、最初は曲がって刺さってるROMがあったので、これが原因かな、と思ったんだけど違った。ただ故障原因は関連してそうで。


このカスタムチップ、4辺のうち3辺で足が浮いていました。実際にピンセットとかで動かしてみないと分かりにくいのだけど。この写真で言うと右側160ピンから左に3ピン分くらいが少しずれてるのがわかるかと。

また、左のTECMO-5って書いてあるチップにも傷、すぐわきの基板面にも引っかき傷って事で、曲がってたROMも含めて物理的なダメージが入っていた可能性が大。


この辺もダメージでショートしちゃってる。

でまぁ、修理後は無事に動いております。ありがたや。


しかしギンくんもそうだけど、大学のサークルで流行ってたやはり線画で書かれたWindowsのゲームなんだっけ……としばらく考えこんだんだけど、そうそう「まさしくんハイ!」でした。懐かしい。って作者ABAさんだったのか……相変わらず世界は狭い。

2019年12月23日月曜日

基板修理:マグマックス

まったく起動しないやつ。数ヶ月くらい気分がのってる時にチョコチョコと思いつきで捜査を進めてました。この基板はマニュアルに回路図が載ってたみたいで資料は探せば見つかるので助かります。

起動しない時に最初に疑うのはメインCPU周り……とすぐに調査を開始したらリセットが入りっぱなしになっていました。リセットに関してはD3/R11/C21でPON後のリセット解除信号を作っており、1Eのシュミットトリガ・インバータを2段経由して68000の/RESETと/HALTに入る、という流れ。HALTは双方向なのでロジックの出力が直で入ってるのは危険な気もするけど、ダブルバスフォールトは絶対に起きない、という設計なのかな。/BERRがpull-upされてるのでそれで良い気がするけど、たくさんの信号が束ねられた上で共通のレジスタでpull-upされてるので、ぶら下がってるチップのどれかが壊れると入力が不安定になりそうではある。その辺が今回の故障部分の原因かもしれない。故障はこの1Eのシュミットトリガ・インバータでした。

1Eの交換後はバスが動き始め、メインCPUはそれっぽく動いている模様。余裕の修理かな?と期待してたんだけど、画面はまだでません。音も確認したけど無音。


しばらく放置したのち、音が出てないのと電圧がやや下がり気味なのもあり試しに電コンの全交換。よくタイムラインで電コン交換修理の報告をみかける岩崎さんからアドバイスをもらえたからってのもあった。


同じ故障基板を買い漁る系なんだけど、なぜか今まで自分が引いてるのはロジック系の故障が多い。そして今回もこれだけでは状況は改善しませんでした。

画面がでないと気持ちが高まらないので画面周りの信号の確認を進めます。画面は故障のヒントになる情報も多いし。で、まずはCSYNCを観測してみたら、なんと7.791kHzという半端な信号が出ていました。期待では15.58kHzと59.5Hzの混合が出てるので15.58kHzが観測されるはずなんだけど。という事で同期信号合成回路を遡って確認。SYNC生成部はCPU(2)の図面にあって、11EのNANDがV_SYNCとH_SYNCの合成、V_BLANKとH_BLANKの合成をやってます。負論理のORで書かれてるけどチップは等価なNANDなので紛らわしい(けど、意味は負論理のORの方が素直)。で、確認したらこの時点でV_SYNC/V_BLANKの入力が壊れていました。V_SYNCが7.791kHzだったため、7.791kHzと15.58kHzのORでデューティー比1:3の7.791kHzが出力されるわけですね。

そのままV_SYNCの生成を追いかけます。VIDEO BUSを通って裏ボードに回ります。VIDEO BUSの裏ボードで見た際の33ピンがV_SYNCです。34ピンがV_BLANK、31/32がH_*です。回路図で見るとMAGMAX_VSCで、/V_SYNCと表記されてるのが出力。CPUボード側の図面ではバーなし表記だったので紛らわしいけど、同一信号。

V_SYNCのタイミング生成では、裏ボードの3A、4A、5Aの3つの4-bitsカウンタを使って9-bitsのカウンタで表示ラインを数え、最上位桁がV_SYNCとして出力される。カウンタの初期値が12'b1110_1111_1010に固定されているので、最後の繰り上がりでカウンタが初期値に戻る事を考えると262カウント。15.58k/262=59.5Hzになります。この論理が壊れているわけですね。

信号を確認すると3Aに入る前段からの入力が中間電位に浮いています。4Aの出力を見ると全て中間電位を出しているようなので交換。手元に74*161の在庫がなかったけどリセットはpull-up固定だったので、リセットしない限り機能的な差はないはずの74*163を使って実験。


お、モニタが同期を拾った……けど何か変。BGMが早巻きで鳴っているので、これはおそらくV_SYNCが4倍の速度で出ているのではないか……と想像。画面も4分割だし、V_SYNC割り込みで演奏してる演奏も4倍速になっているのでは、という推測から。

4倍速になってるなら下位ビット担当がおかしいのかな、と5Aを確認したら出力がやはりおかしいのでこいつも交換。やはり高速に回ってるカウンタは壊れやすいのかな。達人のスプライト周りのカウンタも壊れやすいみたいだったし。



おっしゃ、直った!!

と思ったのも束の間、この体たらくです(笑)



あちゃー。スクロール値とBGパタンの読み出しラインがうまくライン毎にインクリメントされていないような感じですね。それと不定期にメインCPUにリセットがかかる。

もうしばらく修理は続きそう……って事で数日後にラスタースクロール周りの調査。まずは前回見たV_SYNC生成回路の後ろでデータが壊れていないかの調査。ここはINV線を見て通常画面と反転画面用の回路が選択されるようになっているので、2Pで動かしてみて画面反転時に結果が変わるかの確認でスキップ。同じ問題が出てました。なので次はスクロールと画面縮小のパラメータを格納してる表基板18B/20BのEPROMを確認。データは壊れてないけど、どうやら入力アドレスのA7(pin 3)が浮いている模様。


こんな感じで中途半端な電位をフラフラ……と他の入出力に影響されながら。典型的な故障パタンですね。追いかけると19Aと20Aでスキャン中のオフセット付きライン番号にスクロール値を加算してEPROMのアドレスに入れる、となっており19AのΣ3が該当出力ピン。という事で交換してみたところ……


正常動作するようになりました。この手の283も壊れやすいなぁ。

ただこの子、実はメインの68000が少し不安定で。電圧あげないと頻繁にリセットがかかってしまう。裏面の電源とか見てるとノイズも多く、電圧も4.6Vくらいまで下がってるので、他にも壊れた素子があって大きめのリーク電流が流れているか、そもそも電源容量が心もとないのか。安定して動かすにはもう少し調査が必要。ボタン2で早送りした時にノイズがいっぱい載るんだけど、これはこういうモノ?

→その後、自作じゃない環境で試したら低い電圧で安定動作。改めて確認してみたら、むしろ電圧低い方が安定する様子。


こんな感じで普通に遊べたので良しとする。

2019年12月15日日曜日

基板修理:五月陣戦

タイトル不明・起動不可のジャンク1000円。ROMのシールから五月陣戦だってのはわかってたけど。

 電源入れるとこんな感じ。これだけみると表示系のロジックが死んでるような気もするんだけど。
基板をチェックしたら傷跡が。傷の部分を洗浄して拡大鏡で見ると一番太い傷になってる部分でパターンが切れてそう。テスターで確認したらやっぱり切れてました。ここはROMが載ってる部分なのでバスが切れてた感じですね。なのでプログラムが化けて初期化できずに画面が出てなかっただけの模様。
真っ暗な時間が長くて直らなかったかな?って思ったけど、少ししたらチェック画面が出てきた。
んで、無事に起動。今回はとても簡単に修理できたケースでした。
とりあえず傷の部分が錆びると嫌なのでパッチだけじゃなくレジスト塗布も。