日記みたいな何か

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と異なります。何でこんなことしたのかまったく記憶にないｗ