日記みたいな何か

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Ωの抵抗に置き換わっていますね。

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