日記みたいな何か

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協調モードを切るためのもののようです。もはやさっぱりわかりませんが、必要なさそうなので消しちゃいましょうｗ