日記みたいな何か

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が手元に合ったのは結構ラッキーだったのかも・・・。