日記みたいな何か

今度はuim-elでMozcが合字 (リガチャ) を含む変換候補を出すと表示がずれてしまうということに気がついてしまいましたｗ。で、Emacsを29.1に上げるとX上では大丈夫そうですが、ターミナル内だとTermuxでもやっぱりだめ。Termux上でもVimだとずれることなく合字を処理できるので、Emacs固有の何かがありそうです。

ちなみに、Emacsを29.1に上げたらuim-elで使っている関数が廃止されてしまったようで、process-kill-without-query と set-face-underline-p でエラーが出るようにｗ。ひとまず .emacs に以下を書いておけば大丈夫そうですね。

  (when (>= emacs-major-version 27)
    (defun process-kill-without-query (process &optional flag)
      (set-process-query-on-exit-flag process nil)
      t))

  (when (>= emacs-major-version 27)
    (defun set-face-underline-p (face underline &optional frame)
      (set-face-underline face underline frame)
      t))

さて、どうしよう。正直、IMEで合字を平然と変換候補に出しちゃうのはどうなんだという気もしなくもないですが (しかも「どうぶつ」みたいな普通の単語で)、まあ今日日、まともに合字を表示できない環境の方がおかしいか・・・。

今日はゲルド地方を中心に洞窟巡り。

92636D-3 + D9K1 の組み合わせだとCPicSKでゲームが起動しない問題、ROMボードをつけずに電源投入直後の信号変化などをロジアナで観測したりしていますが、特に新たな発見があるわけでもなく・・・。うーん。

ちなみに、もう一枚ある天地を喰らうIIを開けてみたところ、こちらのDボードは92636D-5でした。92636D-3が手元に合ったのは結構ラッキーだったのかも・・・。

今日は北西の雪山を中心に洞窟を巡ってました。

92636D-3 + D9K1 の組み合わせだとCPicSKでゲームが起動しない問題を追っています。よく考えたら、キーの書き込みでトグルさせるM1信号も、基板上で引き回されていて、別のPALの入力になっていたりするんで、これもフィルタしておかないと内部的におかしいことになるのかもしれませんな。というわけで、同じようにキー書き込み時に漏れ出ないように対策。

が、相変わらず起動してくれませんでした。もちろん、PALをD9K2に交換すると起動します。

ロジアナで信号を確認してみたところ、基板側がKABUKIのリセットを解除するよりもずっと早くPICがキーを書き終えていました。つまり、KABUKI側の立ち上がりが遅いのが問題というわけでもないということに。うーん、何だ。

南の方を中心に洞窟を探して回って終わり。最近こんなのばかりですねｗ

CPicSKが92636D-3で動かない問題、キーを書き込む際にトグルするBUSACKが何か悪さをしているのかもみたいな話があったので、汎用ロジック (74HC02) を使ってキーを書き終えるまでの間、外からはBUSACKがHに張り付いているように見えるような対策をしてみました。

が、結果はNG。92636D-3 + D9K1 の組み合わせでは起動してくれませんでした。うーん、そう簡単にはいかないか。

マッスルボマーのDボード (Qサウンド基板) の電池レス化改造を戻し、CPicSKでの動作確認を行ってみます。

マッスルボマーでは、メインCPUがKabukiのプログラムROMを (変なことしてないかのチェックのために) 頻繁に読みに来るという他のCPS1.5にない挙動をするため、その対策として、KabukiをZ80互換モードで動かす電池レス改造でも、復号したデータに加えて復号前のオリジナルのデータもROMに残しておき、メインCPUからアクセスがあった際には後者を見せるようにする必要があります。そんな事情もあって、2Mbitではなく4MbitのROMを使っているんですね。

そして、ROMから復号済みのデータを出すか、復号前のデータを出すかは、Dボードやマザーボードから信号をいくつか引き出して判定することになります。まあ、そんな面倒な改造も今日で過去のものとなるわけですがｗ。というわけで、アドレスデコーダ用の信号を引き出すための配線を撤去します。

次にKABUKIのM1からプログラムROMの30番ピンへの配線を撤去し、31番ピンと合わせてHighに固定されるよう32番ピンと短絡させます (30番ピンは1Mbit ROMだとNCなので、もしかしたら31番ピンだけ処理しておけば十分なのかもしれませんが)。

続いて、Z80互換モードになっているKABUKIを、復号機能が有効になった本来のモードに戻します。これはC12の短絡を解除して代わりにコンデンサを入れ、R33に抵抗を戻すことで、KABUKIの28番ピンをGNDから切り離して、電圧がかかるようにすればOKのはず。過去に撮った写真を見るとR33は1Ωらしいですが、さすがに手元にこの大きさのものはありません。まあ、ここは電圧がかかっていればいいはずなんで、KABUKIがメインCPUの基板と同様に1kΩを入れておくことにします。一方、C12については、オリジナルの容量は不明ですが、用途的にはパスコンだと思うので、0.1μFとかで良いと思われます。というわけで、修正してみました。0.1μFのチップコンデンサの手持ちが見つからなかったので、C12にはラジアルリードのものを取り付けていますｗ

あとはROMをオリジナルの1Mbitのものに戻して、キーを書き込んだPICを搭載したCPicSKをCPUソケットに装着。

Bボードとの干渉もありません。

いざ起動・・・動きました！やったね！CPicSKはCPS1.5でも問題なしです。

と思ったら、Dボードが初期のバージョンだと相性問題か何かがあってInfiniKeyは動かないらしいとの情報が。Dボードにバージョン違いなんてあったのか・・・。調べてみると92636D-3というのがあるようですね (今回確認したマッスルボマーのDボードは 92636D-5)。

Qサウンド基板の初期Ver(92636D-3)は癖があるようなのですが、CPicSKなら行けるのでしょうかね？

— ヒマニト (@himanito_) August 20, 2023

まあしかし、そんなレアそうなもの、きっとうちにないだろうから確認のしようがないよなぁ・・・と思いつつ念のため2個ある天地を喰らうIIの片方を開けてみたら、何と92636D-3が入っていました。凄いｗ

早速こちらも電池レス化改造を戻してCPicSKを搭載してみましたが、ゲームは起動してくれませんでした。なるほど、CPicSKもダメということか・・・。

何かタイミングが合ってないとかなのかな。システムが先に起動しちゃうとか。それならPICによるキー書き込み速度を上げてやれば・・・と、可能な限り高速化してみたんですが、まったく上がる気配はありませんｗ

ググったところ、openkey-kabukiなる起動時キー書き込み装置を作っている方による調査の話が出てきました。 ここを見るに、openkey-kabukiでも同様に起動しなかったらしいですが、D9のところのPAL (D9K1) を92636D-5に搭載されているD9K2に交換することで起動するようになったとのこと。試しにマッスルボマーからD9K2を移植してみましょう。

おおお、確かにPALを交換するとCPicSKでも起動するようになりますね。

そして先程のページをよく読むと、BUSACKなどのキー書き込み時に動いてしまう信号が影響しているのではないかみたいなことも書かれていますね。ふーむ。

チンクルの装備が揃いました。その後もサトリの光を頼りに洞窟を巡ったり。

WH-1000XM3のイヤーパッドがだいぶボロボロになったので、Amazonで買った互換品と交換してみました。YOCOWOCOというところのやつです。

ここまでバラさないとだめなんですね。付属のピック的な工具で余裕でしたが。

無事交換完了。普通に使えています。臭いや皮脂とお別れできてスッキリ。

盗賊ラムダの財宝を探したりしてました。

新たに調達したジャンクのスーファミ本体 4台が到着。動作確認や改造は今手を付けている基板関係が落ち着いてからかなｗ

海外有志が解析したCPS-B-21のドキュメントや回路図を見たりしてました。若干キーについての理解が深まった (気がする) のでメモとして残しておきます。

• MAMEのCPS1のソースで用途不明となってるCボードのレジスタ3個のうち、2個はプロテクション用で、1個は乗算器の入力をunsignedからsigned (2の補数) 扱いにするフラグ用
• プロテクション用のレジスタの一方 (CHECK1) に16bitの値を書き込んでも、その瞬間はなにも起きないが、内部でレジスタに保持される
• プロテクション用のレジスタのもう一方 (CHECK2) に16bitの値を書き込むと、キーに含まれるCHECK2の期待値との比較が行われる。また、同時に、過去にCHECK1に書き込んだ値についても、キーに含まれるCHECK1の期待値との比較が行われる。
• CHECK1もしくはCHECK2で期待値との不一致があった場合、CPS-B-21は一定フレーム後に描画系の機能を停止する。外から見ると、画面がブラックアウトした状態となる (昔電池レス化で何度もはまった現象)
• キーの期待値は、Arcade Hacker氏の解説で用途不明となっていたフィールド16bit x2に含まれる
• 期待値との比較はCHECK2へのWriteがトリガとなるので、CHECK2へのWriteがなければ、キーの期待値が何であろうとブラックアウトは起こらない
• CPS1 Desuiciderでは、プログラムがCHECK2と思ってWriteしているレジスタ位置に何のレジスタもマップしないようにコンフィギュレーションすることで、プログラムの改変なしにブラックアウトを回避している
  • 回路的に、CPUがWriteしてきたアドレスに何のレジスタもマップされていなければ何も起こらない
  • CHECK2などのレジスタは、プログラム中で誰も触らない、安全なアドレスに置いておく
• 同じくArcade Hacker氏の解説で用途不明となっていた後ろの方のフィールドはラスタ割り込み関連の設定用のレジスタのアドレスを決めるもの。CPS1では使われていないっぽい
• CPS-IDのbit 6からbit 9の4bitはReadされた回数を示す (それ以外はキーに含まれるIDの値)

と、ここでふと疑問が。昨日自分がマッスルボマーのCボードに書いたキーは、MAMEのソースから作ったキーで、プログラムがアクセスしてくるCHECK1・CHECK2のアドレスに対して、律儀に実際のCHECK1・CHECK2をマップしてあります。一方でキーには正しい期待値を入れていません。そしてマッスルボマーは、動作中にCHECK1やCHECK2に対してWriteを行います。なのにブラックアウトせずに動き続けているのはなぜなんでしょう・・・。 追記: 後日、改めてArduinoのコードをよく見てみたところ、マッスルボマーに書いたキーは、CPS1 Desuicider 由来のものではないにしても、プログラムがCHECK1やCHECK2と思ってWriteしてくるところに何のレジスタもマップしていないものになっていました。うーん、自分で作ったものだと思うけど、全然記憶にないですね・・・（汗）