日記みたいな何か

CPS1で起動時のキー書き込みによるROM改変不要な電池レス化を、基板の高さを出さずに (Cボードに下駄をつけずに) 実現する方法をずっと考えていたんですが (高さが出ちゃうと以下のVARTHやカプコンワールド2のケースに基板を収められなくなってしまうため)、ここへ来てようやく実現可能性の高い案を思いつきました。一応基板のパターンカットもないやつです。色々と新しいことに挑戦する必要がありそうですが、うまくいけばもう一つのやりたかったことも実現できる可能性もあったり。来月はこの辺を攻めてみましょう。

ちなみにこのケース、Cボードの電池をこんな感じでソケット化しただけで蓋が閉まらなくなるくらい高さがシビアです。風通しも悪いし、何でわざわざこんなの作ったのか、謎ですね・・・ｗ

従来のCPicSKの基板に92636D-3のためのプルアップ抵抗を取り付けるパターンを追加し、合わせて配線やLEDの配置などを微修正した Rev1.0cを作成。そのままElecrowに製造を発注しました。CPicSKのリファインはこれを最後にしたいですね・・・。

今回は基板の厚みも1.6mmから1.2mmに減らしてみました。これでピンヘッダのハンダ付けが少しやりやすくなるのが期待ですが、効果はあるかな。

先日書斎的な部屋のエアコンの水漏れがあったばかりですが、今日は去年水漏れを起こしたリビングのエアコンがまた水漏れを起こしました。

慌ててエアコンを止めた後、先日届いたドレンホース用のポンプで外のドレンホースを吸ってやったところ、この前水漏れした別のエアコンのときと同じように結構な勢いで水が流れ出てきました。例によって何らかの理由で排水が適切にできていなかったようです。うーん。

いやしかし、今回もちょうど気がつくことのできるタイミングで漏れたお陰ですぐに止められたのは不幸中の幸いでした。というか、エアコンの排水機構って、内部に水が一定以上に溜まったら警告を出したり緊急停止したりするとかできないもんなんですかね。節電とか快適性とかもいいけど、Fail Safeな機構がついたモデルがあれば、次はそれを最優先で選びたい感じ・・・。

ちなみに、先週土曜にエアコンから漏れた水を軽く被ってしまったことで稼働停止させていたREGZAは、今日試しに通電してみたところ、特に問題なく動作しました。一安心です。

少し前にフリマっぽいところで100円で買ったおもちゃに電池を入れるところがあることに気が付いたため、開けてみたところ、何と中から単4のエネループが出てきました。

普通に充電できたので、再び元のおもちゃに装着ｗ

CPicSK + 92636D-3 + D9K1 の組み合わせでも、キーを書いている間、強制的にDボード側のCPUリセットをLに固定しておけば、ゆっくりキーを書いたとしても起動してくれるんじゃないかと思い、Dボード側のCPUリセットを手動解除するためのスライドスイッチを追加して実験してみました。写真だと見えませんが、BUSREQのプルアップ抵抗は調整済みです (CPicSKのハンダ面に抵抗を追加してある)。

残念ながら結果はNG。300msec経過後も強制的にDボードのCPUリセットをLにしてみましたが、キーを書き終えたと思われる時間が経過した後、手動でリセットを解除してもゲームは起動してくれませんでした。

ただ、ここで、D9のPALをD9K1からD9K2に載せ替えてやると、Dボード側のCPUリセットタイミングと関係なくキーを数秒かけて書き込んでも起動するようになります。D9K2凄いｗ

これまでの実験結果から考えると、メインCPUが動き始めた状態で漏れ出てしまうBUSACKやM1が、PALでのバス切り替えのロジックに影響している可能性が高そうです。D9K2では、これら信号の影響を抑え込んでいるのかもしれません。以前作った、キー書き込み中、外向きの信号を74HC02でH固定にするバージョンを使えばその辺の検証もできそうですが、まあ、それがわかったところで基板に部品を追加するわけにもいかないので、調査はこの辺で終わりでいいかな・・・。

ちなみに、スーパーパンなんかも、キーを数秒かけて書き込むデバッグ版で普通に起動します。デバッグ版が使えないのは 92636D-3 だけって感じかな。

前々から手元の環境でEmacsでバッファをrevertするとuim-el-agentがほぼ確実に落ちるという問題があったりしたんですが、気になって別環境で確認してみたところ、現象がまったく再現しないことが新たに判明しました。両環境を比べると、uimやEmacsのバージョン自体は同じなので、差があるのは .emacs での設定と考えられます。というわけで、.emacsを調べてみたところ、以下がトリガとなっていることが判明。

(defadvice uim-change-im (around uim-custom-change-im activate)
  (progn
     ad-do-it
     (uim-do-send-recv-cmd
      (format "%d HELPER prop_update_custom anthy-use-with-vi? #f"
	       uim-context-id))))

ロードしていないAnthy関連の値を参照しようとしてクラッシュしているとかそういう感じですかね。何のためのものかまったくわからなかったので、情報が残っていないかと過去のエントリを検索したら出てきましたｗ。 14年以上前に追加した、vi協調モードを切るためのもののようです。もはやさっぱりわかりませんが、必要なさそうなので消しちゃいましょうｗ

また久しぶりに会社に行ってきました。暑くてしんどい・・・。

CPicSKのキー書き込みをゆっくりにして、リセット解除を秒単位で遅らせた場合、Dボードが92636D-3だとBUSREQのプルアップ抵抗を小さくした状態でもゲームが起動しなくなりますが、92636D-5だと問題なく起動することがわかりました。この辺はPALのロジックの修正が関係しているのかな？ 92636D-3 + D9K2 の組み合わせでの実験はまた後日。 追記: 92636D-3 + D9K2だと動きました。

あと、PICの中身が概ね固まったので、CPicS2と同じように、PICプログラムのテンプレートのキーを外から与えたものに置き換えるジェネレータ (cpicsk_gen) を作ってみました。特にはまることもなく、ソースからコンパイルした結果とまったく同じものができることを確認。後はマニュアルが用意できれば頒布できる状態になりますかねｗ

水漏れが起こる前にドレンホースを定期的に清掃するようにしようと考え、ドレンホースの詰まりを解消するためのポンプを買ってみました。週末にでも各部屋のエアコンのドレンホースをチェックしてみましょう。

CPicSKのキー書き込みのシーケンスをちょっと整理してみました。また、LEDの点滅で進行状況を確認できるようにしたデバッグ版でのトグル間隔を15msecにしてみました。これくらいまで遅くしておくと、LEDの点滅で今どの辺の処理をしているか、肉眼でも確認できるようになりますｗ

ちょっと前にマッスルボマーのCボードに書き込んだキーが、MAMEのソースから作ったやつなのに、CHECK1/CHECK2の照合に引っかからずに正しく動いていておかしいみたいなことを書きましたが、Arduinoのソースを読み返してみたら、このとき書き込んだキーはMAMEのソースから作ったものそのままではなく、CHECK1やCHECK2などにアクセスしないよう対策をしたものになってました。ただ、CHECK1やCHECK2を逃がす先を 0x800140ではなく、0x80017E としている点がCPS Desuiciderと異なります。何でこんなことしたのかまったく記憶にないｗ

数日前からダイソンの掃除機のヘッド部分のブラシが回転しなくなってしまったので、分解して原因を調べてみました。

よくある症状の一つに断線があるらしいんですが、分解してもモーター本体との間で断線しているところは見当たりません。また、モーターの電極に安定化電源を繋いで5V程度の電圧をかけてもピクリともしません。こりゃモーター自体がダメな感じですかね。しかしそれにしてもホコリが凄いｗ

モーターの周囲も中もホコリが酷かったので、ホコリの塊をピンセットでつまんで除去しつつ、モーターの背面の側面の縁の爪を起こして背面の蓋を取り外し、モーターのブラシ部分を綿棒等で掃除したら、ようやくモーターが回るようになりました。ブラシ部分が汚れて電気が流れない状態になっていたようです。

分解していたら、モーターをヘッドに固定するパーツの一部が割れているのが見つかったので、ここはプラリペアで接合。

再度組み立てて、無事ヘッドのブラシ部分が回転するようになりました。よかったよかった。

作業を始める前に机の周辺の整理をしていたら、突然ババババ・・・という感じの異音が。音のする方を見てみると、なんとエアコンから大粒のしずくがぼたぼたとしたたり落ちているではないですか。

エアコンの真下にはXAC-1があり、モニタ (REGZA) やその上に置いてあったたころんのポップ、モニタの下あたりにあったメガドラミニ2やサイバースティックあたりが濡れました。

慌ててエアコンを止め、REGZAは電源を抜き、水を被った機器を拭き取り。サイバースティックはスティック部分を外して乾かします。簡単に外せるのは便利で助かりますｗ。ちなみにスティックを外したら、中もちょっと濡れてて焦りました・・・。

中の方が一段落したところで、続いて原因調査と対処に。ペットボトルを2本接合して掃除機と組み合わせた簡易ドレンホース吸引器を作成しましたｗ。去年も作ったなぁ・・・

外に出てドレンホースを見たところ、ポタポタと水がしたたり落ちており、割と普段と変わらない様子。

が、吸引器で吸ってみると、コップ一杯分くらいの水が一気にペットボトルに溜まり、吸引器を外した後もしばらくの間ドレンホースから水がちょろちょろと流れ出続けました。内部に何かの詰まりがあって、それが取れたってことなのかな・・・。

膿が出たのでしばらくは大丈夫でしょうけど、念のためエアコンはしばらくこんな状態で稼働させることにしますｗ

水を被ったREGZAはしばらく稼働させられないため、基板環境も移設。しばらくはこちらのKVC液晶で動かす感じですね。

昨日発見した、92636D-3 でKABUKIに基板側の信号を直結した状態でBUSREQにロジアナのプローブを当てたりするとCPicSK接続時と似た感じでゲームが起動しなくなる現象 & 92636D-3と92636D-5でBUSREQについてるプルアップ抵抗の大きさが全然違う点に着目し、試しにBUSREQに470Ωの抵抗をプルアップ抵抗として追加してみました。元のプルアップ抵抗 10KΩと並列に入るので、合わせると約450Ωになるはずです。

仮説が正しければ、これでBUSREQにロジアナのプローブを当てた状態でも92636D-3でゲームが起動するようになるはず・・・。起動した！

もしCPicSKだと起動しないことの要因がこれと同じなら、CPicSK接続時にもプルアップ抵抗を下げてやることで起動するようになるはず・・・。というわけで、まずはキー書き込み中にM1とBUSACKが漏れ出ないように改造した方で実験。

CPicSKを装着し、ROMを元の1Mbit品に戻して・・・。

おおお、こちらも成功！初めて 92636D-3 + D9K1 + CPicSK の組み合わせで起動に成功しました。

続いて本命です。キー書き込み中、M1やBUSACKを外に垂れ流しにする版でもやってみました。

起動した！というわけで、92636D-3でもBUSREQのプルアップ抵抗を下げてやることで、今のCPicSKでも起動時キー書き込みが可能になるようです。ああ、基板再設計にならなくて本当に良かったｗ

ただ、キー書き込み時間を400msec (理論値) くらいに長くすると起動しなくなりますね。200msec程度で終わらせるようにすると大丈夫だったので、プルアップ抵抗で最初の問題を解消した後も、システム側がKABUKIにリセットを掛けている間にPICからのキーの書き込みを終わらせられるかどうかで成否が決まるということなのかな。

92636D-3のDボード、従来型の電池レス化により D9K1 を装着したまま起動するようになったので、この状態でKABUKIのBUSACKやM1の信号がどういう動きをするのかをロジアナで見てみることにしました。

って、ロジアナ繋ぐとゲームが起動しなくなるんですけど・・・？いや、観測する信号を減らせば起動しますね。どの信号が悪さをしているんだ・・・と一本ずつ繋いでいったところ、BUSREQをロジアナで観測しようとすると起動しなくなる (逆にBUSREQ以外はロジアナを繋いでいても問題なく起動する) ということがわかりました。

これは、つまり、BUSREQの信号線に何か電気的な問題があるということなのでは・・・。回路を追ってみると、BUSREQは6Mの位置にある74LS07の出力が来ています。74LS07はオープンコレクタのバッファなので、信号自体はプルアップされていて、プルアップ抵抗はR23で、抵抗値は10KΩですね。・・・む、他の似たような信号線は470Ωでプルアップされてるのに、なんでこれだけ10KΩなんだろう。

というか、92636D-5だと、R23が470Ωの抵抗に置き換わっていますね。

ひょっとして、これのせいでタイミング的な問題とかが起きていたりする？

Emacs 29.1だと、Emacs 26系でうまく機能していたeaw.elによるEAWな文字の幅設定が反映されない模様。29.1のEmacsのソースを真似して.emacs内で直接設定してみたら反映されるようになりました。どちらもchar-width-table に設定しているだけのはずなんですが、何で従来手法だと無視されるのかはよくわからず・・・。

まあしかし、これをやってもTermux内でEmacs-29.1を上げると、Unicodeの合字がある場合にカーソル位置がずれたり表示が崩れたりするのは相変わらず。ファイルを開いた時点で表示がおかしかったりするレベルです。Xでウィンドウとして開くと問題ないので、ターミナル内で動作しているときに正しく処理できない感じなんですかね。

Vimでは正しく処理できるのに・・・というところはちょっと悔しいですが (嘘)、正直普段の使い方では合字が表示できなくてもまったく問題なく、Mozcが変換候補に混ぜてきたときにuim-elの表示が崩れるのが嫌なだけなので、.emacsに以下を記載して、ターミナルで動く際は常時合字をオフにすることにしました。フォントとしては表示できるのでちょっともったいないけどｗ

  (if (not window-system)
	(global-auto-composition-mode 0))

この設定にしておけば、Emacs-26をTermux内で上げた場合でも問題なさそうです。

CPicSKが CPS1.5の92636D-3 + D9K1の組み合わせだと正常動作しない問題、あまりに原因がわからないので、一旦従来方式の電池レス (2MbitのROMに置き換えて、Kabukiを通常のZ80として動かすやつ) に戻して、信号の観測や実験なんかを行ってみることにしました。

とはいえ、また基板ガワを改造するのは嫌なので、ポン付けで従来型の電池レス化を実現するセットを作成。ROM側は、先日マッスルボマーから外した4Mbit ROM用の基板を手直しして再利用していますｗ。また、Kabuki側の配線入れ替えには、CPicSKの基板に手を加えたものを使用。

KABUKI側に入るリセット信号については、プルダウンしつつ、基板からのリセット信号の入力との間にスライドスイッチを入れてみました。これでリセットを手動で解除する実験が可能になります。

ひとまずスライドスイッチはオンにしたままの状態で電源ON。92636D-3で普通に起動しました。

続いて一旦電源を切って、スライドスイッチをオフ (リセット信号をLow固定) にした状態で起動し、数秒後にスライドスイッチをオンにしてリセットを解除 (厳密には基板側から来ているリセット信号をKABUKIに接続) してみたところ・・・

これも問題なく起動しました。つまりリセット解除が遅いこと自体は、92636D-3での起動に何の影響もないようです。そうであるなら、むしろシステム側の起動が終わってから、信号が漏れ出ないようにした上でKABUKIをコンフィギュレーションし、その後KABUKIのリセットを解除する、という流れでも良いのかも？

今度は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してくるところに何のレジスタもマップしていないものになっていました。うーん、自分で作ったものだと思うけど、全然記憶にないですね・・・（汗）

電池切れして起動しなくなってしまったマッスルボマー、電池交換せずにCボードにArduinoでキーを書き込んでみたら普通に起動しました。コンデンサのお陰で、電池がなくてもそこそこの時間はキーを保持できるんですな。というかこれ、意図して試そうとしたわけでなく、完全なうっかりミスの結果です。ゲームが起動してから何か間違ったことをしたということに気が付きました。いやー、大きな事故につながるようなミスでなくて良かった・・・（汗）

あらためて切れた電池を外してソケットを取り付けて新品の電池を装着。キーを書き込んで無事起動することが確認できました。

一方、ついでに実験で使おうと思っていた別のCボード (92631C-6を電池ありに改造したもの) は、Arduinoからキーを書き込んでも全然動作してくれませんでした。まあ、元々壊れかけていたやつ (起動せず超高温に→その後縦線が出る状態になったやつ) だったんで、いつ壊れても不思議はないですね。せっかくなので、別の壊れたCボード (90631C-5) と合わせてCPS-B-21を剥がし、いつでも配線を直接観察できるようにしましたｗ

AliExpressで買ったコネクタが届きました。今度はちゃんと間違えずに40ピンを買えましたｗ

なかなか手を付けられなかったCPicS2のキットの袋詰めを終わらせました。今回の出荷先はBEEPさんになります。

パトリシアちゃんに水の実を捧げたら座標っぽい数字を教えてくれたので、行ってみたらまだやってないチャレンジが。既に条件を満たしていたので、始まると同時に終わったんですが、これはやってないチャレンジの場所を教えてくれるってことなのかな。

CPS1のCボードのCPS-B-21の103番ピンに入っているリセット信号がどこから来ているのかを追ったりしていました。マザーボードのCPS-A-01の105番ピンから出たのが、BボードのE4ピンを経由して来ているっぽいですね。なるほど・・・。

コントローラーを欲しがるお子様向けのデコイの市販品が届きましたｗ。先日のXbox 360のコントローラーのジャンクで作ったデコイも結構活躍してくれていますが、ちゃんとしたのも評価してみようかと思いｗ

これ、結構いい音が鳴りますね。アナログスティックが噛み心地の良い歯固めになっていないところが惜しいｗ

火炎グリオークに再び挑戦。今回は肝を手に入れることができました。その後は、余りまくっているお金をつぎ込んでマイホームを拡張しまくってみたり。部屋をたくさん置いてみたけど、特に何かがあるわけでもないのかな・・・？

プールに行ってきました。多分四半世紀ぶりｗ。しんどすぎるｗ

コントロールボックスの電源取得に使っているATXコネクタの接触がイマイチなせいで基板の電圧が不安定になってしまっているため、いい加減ATXコネクタを取り払って、JVSの電源コネクタをコントロールボックスに直結することにしました。

コネクタ用に穴を加工し直すのは大変なので、当分このままで使いますｗ。普段移動させたりケーブルが引っ張られたりするようなものでもないので、まあ大丈夫でしょう。

CPicSKの基板装着確認のために出してきたマッスルボマーの基板、通電してみたら起動しなかったので、開けて調べてみたらCボードの電池が切れていました。まあいい機会とも考えられるかも？

実家から帰宅しました。帰りも渋滞なしでスムーズ。

今日はマップ南方の海岸沿いを中心に探索。あんまり成果なし・・・。

0歳のお子様にSwitchのホリのワイヤレスパッドを渡したら、アナログスティック部分を思いっきり噛まれてしまいました。ここ数日、渡しても大人しく遊んでいたので大丈夫かと思ってたんですが、ちょっと目を離したスキにこれですよｗ

当初、部品を取り寄せるなり何なりして修理しようかと考えたんですが、試しにそのままティアキンを遊んでみたらまったく気にならなかったので、何かもうこのままでもいいのかなという気にもなりつつありますｗ

しかし、今後も同じような被害が発生する可能性が非常に高いことから、デコイは用意しておきたいところ。デコイの要件としては、1) アナログスティックがあること、2) ケーブルが出ていないこと (出ているとケーブルの先を噛みそうなのと、首に絡まったりしたら危ないので)、3) 細かな部品が簡単に外れたりしないことって感じですかね。もちろん、噛まれても良い、あまり大事ではないものというのも重要ですｗ

まあでも、そんな都合の良いもの、そうそうないよね・・・とジャンク箱を漁ったら、ありました。昔基板を乗っ取り用に頂いたXbox 360の有線コンの抜け殻と、乾電池が液漏れして認識されなくなってしまったXbox 360の無線コンです。

無線コンの方は、そのままだと背面に電池ボックスがあり、これが外れると細かい部品が出てしまうため危ないですが、背面パネルを有線コンのものと交換することでこの問題を解消することができそうです。問題は、有線コンの背面パネルと無線コンの背面パネルにネジ穴などの互換性があるかどうかなんですが・・・

交換してみたら、まったく問題なく取り付けられました。ネジ穴の位置などは互換性があるようです。凄い。ありがたい。

(見た目だけは) 完璧なものができました。

ついでにアナログスティックに残っているゴムは削り取っておきましょう。元々劣化気味だったので簡単に除去完了。これで完成ですｗ。この時点でご就寝だったので、どれくらい有効かは明日の確認ですねｗ

ちなみに、Xbox360のコントローラーでデコイを作る前に、同じジャンク箱から出てきたメガドライブのコントローラー (ケーブル切断済み) をそのまま渡してみたんですが、見向きもしませんでしたｗ。アナログスティックがないのがダメなのかｗ

先日バッテリーの再膨張を発見してしまったジョイコン左の互換バッテリーを、元々右のジョイコンに入っていた純正バッテリーに交換しました。

無事電源が入りました。しばらくはこっちを本体につけておきますかね。

CPicSK Rev1.0bの基板をCPS1.5向けに組み立ててみました。CPS1.5に取り付ける場合、通常版と異なり、ピンヘッダを部品面側から差し込んでハンダ面側でハンダ付けすることで高さを抑える必要があります。このとき教科書通りピンの根元に立派な富士山を作ってしまうとソケットへの刺さりが悪くなるので、ピンの根元の山も極力低めにするのがポイントなんですが、これが結構大変だったり・・・。

CPS1.5のDボードに取り付けてみました。狙い通りオシレータ付近のフィルタやタンタルコンデンサと干渉しなくなっています。よしよし。

動作確認はまた後ほど。

Mozcをuim経由で使った際に、Ctrl-Shift-V (変換候補を前のページに戻すキーバインド) が効かないことに気がつきました。gedit + ibusで試してみた際も効かないんですが、EmacsではC-S-vと認識されていて、Mozcのコンフィギュレーションでもキーキャプチャできます。ということは、X11的には通っているようです。うーん、そうなると、Mozc自体が入力を拾えてない可能性・・・？ Mozcの中を見るのは流石に大変そうなので避けたいところですが、そもそも正直今まで使えていないことに気が付かなかったくらいなので、とりあえず空いてる C-] にバインドしてお茶を濁すことにしておきますｗ

去年の12月に膨らんだバッテリーを互換品に交換したSwitchのジョイコンですが、何かまた左側の方のガワが歪んでいるような気がしたので分解してみたら見事にバッテリーが膨らんでいました。交換した後もほとんど使っていなかったからか・・・。うーん、どうせ使わないなら、膨らんだのは処分しつつ、もう新しいのは取り付けなくても良いんじゃないかという気もｗ

実家に移動。渋滞もなくスムーズに到着することができました。

EAWな文字をきっちり全角表示にするよう対策したEmacsでも、GNU screen内で使うと一部の文字を表示した際にずれが起こることに気づいて調査してみました。screenではオプションにcjkwidth onを記載しているんですが、これでずれるってことは、Emacsと同様に全角表示の対象となる文字のセットに差があるものと推測されます。というわけでソースを見てみたら、encoding.cにセットがありました。そしてやっぱり何か全然足りてなさそう。

早速これをTermuxのパッチで適用したのと同じセットに置き換えてビルドしてやったら見事に表示が崩れなくなりました。TermuxからリモートホストにSSH接続して、そこでscreenを上げてEmacsを上げて、その中でUnicodeの絵文字を表示しつつMozc + uim-elでEAWな文字を含む変換候補を表示しても全然崩れることはありません。素晴らしい。

何かもうクリアする以外メインシナリオ的にやることなさそうな感じなので、早々に探索モードに戻りましたｗ。今日はヘブラ山の方を探索。

これまで何となく欲しくなっては「やっぱりいいか」を繰り返していたD端子切替器ですが、また何となく欲しくなったので探してみたら、ちょうどお安い中古品が出ていたので購入してみました。ビクターのJX-D77というやつです。

D端子で映像出力させたい機材はWiiとPS2、あとはPSPくらいかな？コンポーネントケーブルに変換してRetroTINK-5X Proに繋ぐのがいいのかな。

ちょっと前に箱買いしたサッポロラガーが間もなく終わるので、今度はサントリー生ビールを箱買い。今はこっちのほうがうまい感じ。

いい加減話を進めることにして、リトの村の地底のコーガ様を撃破。あと、祠の方もようやく最後の1個を発見。闇祓いの島にありました。前に来た際は、お宝をゲットして満足してしまい、祠を素通りしてしまっていたようです。

クイズ殿様の野望の基板の86S105の跡地をソケット化して、良品の86S105を載せ、さらに電池レス化改造を戻してオリジナルのROMに交換した上で、CPicSKで動かしてみました。

結果はバッチリ。キャラ化けが解消しました。86S105がおかしいと、タイトルロゴが表示されなかったりします。

また、同様に最近キャラ化けが発覚したドカベンも、怪しさ120% の86S105を外してソケット化して、良品の86S105を載せたらキャラ化けの問題が解消しました。やっぱりこれだったかー。

ちなみに、当初、ソケットのハンダ不良をなかなか見つけられなくて、良品でもキャラ化けしてしまい若干ハマりました。ほんとソケット取り付けはなかなか安定しませんな（汗）

CPicSKのRev1.0b (サイズ調整版) が上がってきました。

今回は角を丸めていますｗ

早速組み立て。とりあえずデバッグ用のLEDも全部実装ｗ

クイズ殿様の野望でチェック。問題なく動作してくれました。

また、縦横に数mmずつ削ったのが効いて、クイズ系の基板に装着した際にメイン基板からせり出さなくなりました。よしよし

昨日届いたPixel 5a (5G)の交換品上での環境構築を継続。モバイルSuicaやらPayPay銀行のトークンやらを移行して、大物は概ね終わった感じです。ふぅ。いやしかし、ほんとPixel 3 XLが繋いでくれたお陰でこの辺の移行はスムーズでした。繰り返しになりますが、バッテリーを交換しておいて本当によかったです。

Pixel 5a (5G)の交換品 (再生品) が届いたので環境構築を開始。何かこのところ毎日のようにやってますねｗ

元の個体は指定の方法で発送。結局最後まで画面が復活することはありませんでした。

スーファミ本体を改造するにあたり、問題がある際にすぐ判別できるよう、電源投入後即座に絵や音が出るソフトを募集したところいくつかご紹介頂いたので色々と試してみました。

絵だけならグラディウスIIIとマリオカートが圧倒的に早いですね。電源投入とほぼ同時です。

あと、紹介があったわけではないんですが、何となく早そうな気がしたドラッキーのパズルツアーも凄かったですｗ

絵だけでなく音も含めてとなると、紹介頂いた中ではボンバザルがピカイチでした。次点はパネルでポンとかストIIあたりですかね。というわけで、当面はボンバザルでチェックしたいと思いますｗ

昨日PPU2を移植して色がおかしい問題が直った初期型本体にSHVCビデオ改善キットv1.2を取り付けてみました。

早速ボンバザルで確認します。頼む、動いてくれ・・・

ふぅー。無事起動しました。もちろん、絵はくっきり。

これでようやく土曜日のピークの状態にまで戻ってくることができました。そのときからまともな本体が1台減ってしまいましたが・・・

あと、ついでにこの本体のヒューズを、適当なポリスイッチ (以前オリジナルのヒューズを飛ばしてしまった際に暫定で取り付けていた) から交換可能なガラス管のヒューズに置き換えてみました。何とか収まりましたが、パターンがあるわけではないため、面ではんだ付けしなければならず、ホルダーの位置合わせが非常に難しかったです・・・ｗ

今日も行ったことのない道を中心に探索してました。そしてまた録画がうまくいかなくなってしまった模様・・・。

AliExpressで買ったコネクタが届いたんですが、何か思ってたのと違うぞ・・・って、20ピン x 2段の40ピンのものを注文したつもりが、10ピン x 2段の20ピンのものを注文してるじゃないですか。おおぅ、不覚。

TermuxとかでキーボードのAltキーを押すと、絵文字を入力するためのソフトキーボードみたいなのが出てくる場合があり (出てこないときもある) 超うざかったんですが、これはGboardの絵文字とかの設定のところで切れるんですな。わかりにくい・・・。

あと、Termux越しのEmacsでAltとCtrl を両方使うキーバインドが効かないという問題もあったんですが、こちらは .termux/termux.properties の disable-hardware-keyboard-shortcuts = true をアンコメントして Termuxを上げ直したら解消。諸々、さらに一段と良くなってきた感じです。

昨日突如復活したPixel 5a (5G)、朝になっても元気に動き続けていたんですが、アプリの再設定をポチポチしていたらまた突然画面がブラックアウトして戻らなくなってしまいました。例によってデバイス自体は生きているようで、メールが来ると通知音が鳴るし、別のスマホから「デバイスを探す」を利用して音を鳴らすこともできます。復活は一時的なものだったか。はぁ。

今日は、昨日電解コンデンサを交換した初期型本体にSHVCビデオ改善キットv1.2を取り付けようと思います。まずは、作業前の起動確認。F-ZEROが無事起動しました。ここでちょっとサウンドモジュールの下の電解コンデンサの高さが気になり、一旦サウンドモジュールを外して電解コンデンサの角度を変えてサウンドモジュールを戻したところ・・・なぜかさっきまで起動していたF-ZEROがまったく起動しなくなりました（汗）。というか、F-ZEROに限らず、他のタイトルも起動しません。な、何で・・・

本体のLEDは点灯しているんで、ヒューズ切れとかではないはずです。電源を入れるとFramemeisterやRetroTINK-5X Proは同期信号を検出してくれます。ただ、真っ黒な画面のまま、絵も音も一切でない状態。最初にSHVCビデオ改善キットv1.2を取り付けた個体と同じような症状です。うむむ。

カートリッジのガワを外して本体に装着し、ROMのCE信号をロジックプローブで見てみると、何も信号が来ていないように見えます。CEの生成元はS-CPUのようですが、CPUが立ち上がっていない？ 海外有志の公開している情報によると、リセットは50番ピンのようですが、ここは電源投入直後はLで、すぐにHに変化するようです。ということは、リセット自体は解除されていると考えられます。うーん、そうなるとCPUがちゃんと動いていないということか？というか、電源を入れているとCPUがかなり熱くなりますね。画面の色がおかしい (緑色が出ない) ながらも立ち上がる状態の初期型本体でも確認してみましたが、こちらはこんなに熱くなりません。こうなると、CPUが壊れている可能性が高そうです。

正常動作する個体からCPUを移植すれば立ち上がるかな・・・と思ったけど、よく考えたら、以前PPU2を壊してしまい、画面の色がおかしくなってしまった個体に、立ち上がらない個体からPPU2を移植した方が早くて確実そうです。

というわけでこれをやってみることに。善は急げと言わんばかりに、きっかり1時間で移植完了ｗ

さあ、どうだ。・・・あああ、これも起動しなくなった・・・と思ったら来た！Framemeister、心臓に悪いよｗ

というわけで、とりあえず1台起動する初期型本体を確保することができました。他の初期型本体2台が立ち上がらなくなった理由はまったくわかりませんが、もしかしたら下に敷いていたエアキャップに何か問題があったのかもしれません。出処不明だし。これは捨てよう・・・。あと、今後、初期型本体については、改造途中でも動かす際は必ずシールドをつけるようにします。

ちなみに、今回復活させた本体は、元々スーファミ現役当時にうちで動いていた個体のはずです。無事復活してくれたのはちょっと感慨深いですねｗ

不調のPixel 5a (5G)、ちょこちょことブートローダーを立ち上げてからの起動 (昨日サポートの人からこれで上がるか試してくれと言われたやつ) を繰り返したりしているんですが、相変わらず起動途中で画面が消えたり、たまに起動しても少しアプリを操作したりすると即元の状態に戻ったりと、全然ダメな感じです。

それでも懲りずに繰り返していたら、珍しく起動後数分経っても画面が消えない状態に。ここぞとばかりにUSBデバッグをオンにしてadbでデータを吸い出せるようにした上で、写真などのバックアップを取ったり、いつ修理に出すことになっても大丈夫なようにデバイスを初期化したりしたんですが、それでもまったく落ちません。もしかして問題解消したのか・・・？

土曜のスーファミの改造失敗が尾を引いてもやもやするので、別の初期型の個体にSHVCビデオ改善キットを取り付けてスッキリしたいところです。というわけで、手付かずの初期型を引っ張り出してきたわけですが・・・ああ、これ、普通にRGBが映らないやつだった。何か前にテストした際、LM1881を通してやらないとFramemeister相手でも映像が出なかったんですよね。

再度確認してみましたが、やはりFramemeisterやRetroTINK-5Xに繋いでも映像が出ません。こりゃ、キットを取り付ける前に、まずコンデンサの交換が必要ですな。というわけで開けてみました。超汚いｗ

ビデオ絡みのコンデンサまわりは、何かしっとりした感じです。

前回は外した後に容量を測りたくて律儀にハンダごてを2本使って外したんですが、これだとパターンが剥がれやすいので、今回はねじ切ることに。やはりこうやって外してから残骸を除去するようにした方が、圧倒的に早い上に、基板のパターンを傷めずに済むようです。

一通り付け替え完了。

無事にFramemeisterで普通に映るようになりました。キットの取り付けはまた後日ですね。

地底の根っこをすべて解放したようです。根っこに対応する地上の祠は全部解放済みなので、残りは空にあるということか。

Pixel 5a (5G) が相変わらず不安定で、画面が消えまくります。急ぎ同等の環境をPixel 3 XL 上に構築し、画面が点いている間にモバイルSuicaやらPayPay銀行のトークンやらを移行。並行してGoogleのサポートにチャットでコンタクトして相談。どうも保証の対象らしく、交換対応ということになりそうです。不幸中の幸いですね。そしてPxiel 3 XLのバッテリーは、交換しておいて本当に正解でした。

カバンダを探すべく、足跡機能を活用してこれまで全然歩いたことのない街道を歩いたりしてました。

SHVC Video Improvement Kit v1.2が本日到着予定なので、それに先立って初期型スーファミの方で取り付け準備を始めました。ターゲットは、以前いじっていて壊してしまったものとは別の正常品ですｗ

ケースを開けて基板を取り外そうとしたら、ガワの一部が劣化によりバキバキに割れてしまいました・・・。家庭用ゲーム機でここまで酷いのは初めてかもｗ

とりあえずトランジスタやチップコンデンサ、チップ抵抗なんかを外して、跡地をハンダ吸い取り線で清掃。

PPU2の電源につながるパターンについては、周囲を削って孤立させます。

と、ここまで作業をしたところでSHCP Video Improvement Kit v1.2が到着。

早速取り付けます。

動かしてみます。ドキドキ。

よし、絵が出た！

マリオペイントで改造前の絵およびRGB化したスーパーファミコンJr.の絵と比較してみました。改造前に見られた右側に出るにじみがほぼ消えており、Jr.にかなり近い状態になっています。これは素晴らしい。

せっかくなので、追加で縦縞対策の改造もしておきます。

って、なんかゲームが起動しなくなったんですが・・・（汗）。電源自体は入って、画面の同期も取れているのに、ゲームが一切立ち上がらない状況です。音も出ません。

念のため電解コンデンサを交換してみましたが、状況は変わらず。追加改造した場所を戻してもNG。うおお、本体が死んでしまったのか・・・？あああ、何ということだ。

ビデオ改善キットを外して確認してみましたが、下にも特に異常は見られませんでした。作業中も通電前も、テスターで慎重にショートなどがないことを確認していたのに、一体どこで問題が起きたのか。辛い・・・。

起動しなくなってしまったスーファミの写真をPixel 5a (5G)で撮っていたら、突然Pixel 5a (5G)の画面が消えてしまい、全然復活しない状態に。電源ボタンを長押しして強制的に再起動してやったら復活しましたが、その後も同様の現象が何度か発生しました。うーん、壊れかけているのかな・・・？何かもう今日は最悪ですね。

地底で闘技場を巡っていたらライネルとの連戦に。瘴気に効く回復アイテムを全然持っていなかったため5体目でギブアップ。

再びnon-JEDECな1Mbit EPROMを使う機会が生じたので、Xgecu T56によるソニーのCXK27C1000DQへの書き込みの追試をしてみました。まあ追試と言ってもHN27C301AGの設定でVDDをどれくらい下げたら書けるようになるのかというのを調べただけですが。結果、5.75V以上にしていると書き込みが始まらないということがわかりました。やはり5.5Vにする必要があるようです。

そういえば、逆に低い方はどうなのかは調べてなかったですね。また次の機会に調べてみましょう。

先月電池レス化改造を元に戻したブロックブロックの基板を、ROMまで含めてオリジナル相当の状態に戻しました (先月の時点では別の未改造の基板からROMを借りて動作確認していた)

CPicSKで無事起動。

ちなみに当初、「SCROLL RAM ERR」なる見たことのないエラーが出て焦ったんですが、+5Vの電圧が低過ぎたのが原因だったようです。コントロールボックスの電源コネクタ部分の接触がよろしくないようで、たまに異常に電圧が下がったりすることがあるんですよね。これもそのうち何とかせねば・・・。

mlterm内でEmacsを立ち上げた際にもEAWな文字の幅を適切に処理できるように設定してみました。設定ウィンドウ (mlconfig) でUnicodeのどの範囲を倍幅にするのか1個ずつ入力するのは流石に無理過ぎるので、.mlterm/main をエディタで直接開き、unicode_full_width_areas に、以下のような感じで範囲情報を記載。

unicode_full_width_areas = U+00a1,U+00a4,U+00a7-00a8,U+00aa,U+00ad-00ae ... 

長々とルールを適用したところ、mlconfigでエラー表示されるようになってしまいましたが、ちゃんと認識されているようです。さらに、.mlterm/emojiにtwemojiのファイルをごっそり置いてやったところ、一部の絵文字も出るようになりました。なかなか凄い。

ついでに、これを機に、mltermのフォントもビットマップの東雲をやめてTrueType (VL Gothic) にしてみました。文字が結構暗くなっちゃうのがちょっと気になるところですが、そのうち慣れるかな。

今日は空の島々を巡ったり、女神像を復活させたりしました。

お子様のリクエストでサンリオピューロランドに行ってきました。空いていれば車で1時間くらいの距離なんですが、朝は道が混んでいることもあってか、1時間半ほどかかり、ちょうど開館するくらいのタイミングでようやく到着。これくらいの時間だと施設内の駐車場にはまず停められないみたいな情報をいくつか目にしていたので近隣の提携駐車場に停める覚悟でいたんですが、何か普通に地下の駐車場に入れました。ラッキーなのか、最近はまた事情が違うのか。

完全な屋内施設なんですね。このご時世、外に出なくてよいのはだいぶ助かる感じですｗ

ショーを見たり、ご飯食べたり、お土産を選んだりで、気がつけば閉館時刻に。お疲れ様でした。

CPicSKの基板が何かに干渉したりしないか確認すべくドカベンを引っ張り出してきました。写真の右下あたりにあるのがKABUKIですが、電池を外せばまったく問題なさそうです。というか基板自体はスーパーパンとほとんど同じですね。

が、そんなことより何かキャラ化けしてるんですけど・・・。

またか？またお前 (86S105) なのか・・・？

同じく引っ張り出してきたポンピングワールドはキャラ化けもなく正常動作してくれました。ふぅ。

ちなみに、これら2タイトルはいずれも 89125Aという基板のシリーズのようです。ポンピングワールドの方は型番が「A-2」でドカベンの方は「A」で終わっています。基板を見るに、Aにあった多数の回路のバグがA-2 で修正されたみたいですね。ついでにいうと手元のスーパーパンは 89125A-3C だったので、さらに修正が入っている？

この他、寄せられた情報によるとA-1というリビジョンもある模様。こちらはAにあった不具合のうち一部は直っているものの、相変わらず同様のジャンパが飛んでいる箇所もあるようで、番号からも推測されるように、AとA-2の間に位置するリビジョンと考えられそうです。まあ何にせよ、89125AシリーズにはCPicSKが問題なくつきそうだということがわかりました。よしよし。

今日も上空を中心に探索。闇祓いの島や星見の島を終わらせました。