日記みたいな何か

5日前に32bit版Windows環境を64bit版Windows環境から分離して、Fedoraとのデュアルブートにしたばかりなわけですが、やっぱりデュアルブートは不便なんで、再び64bit版Windows環境と同じPCに戻すことにしました。ただ、今度はネイティブ起動ではなく、VMware Workstation Player上で動かします。

実は、これ、半年前の環境と同じ構成なんですよね。元々、VMware Player上で動作する32bit版Windows上のMax Loaderからは、ホストOS上のパラレルポートにつながったChipMaxを触れることは確認済みだったんですが、何かがあって、いまいち信用ならんという理由でネイティブ動作させるように変更したんだった気がします。今試してみると、普通に安定しているように見えます。

というか、ほんと最初からこうしておけばよかったって感じですね。SSD化の時点で、VMwareで動かすと決めておけば、Windows 10とFedoraのデュアルブート環境構築ではまったりしなかったわけで。というか、何でVirtualBox上でChipMax認識しようと頑張ったんだろう、1週間前の自分・・・(´・ω・｀)

某基板のROMをソケット化したりしてました。注意深く進めていたはずなのに、気がつけばなぜか2個も逆向きに・・・orz

契約後最初の打ち合わせ。

夕方には帰宅。毎度のことながら、短い帰省ですｗ。

gnupackのターミナルでscreenを使う場合のメモ。とりあえずターミナルを開いて、apt-cyg でscreenを入れて、screen起動。何もしないと多分以下のメッセージが出て動かないので・・・

Directory /tmp/uscreens/S-nosuke must have mode 700.

chmodして権限与えればOKでした。

chmod 700 /tmp/uscreens/S-nosuke

うーん、以前は何かもっと色々設定ファイルいじったりして大変だったような気がするんだけど、簡単にできるようになったのかな・・・。

実家に行ってバーベキューしたり。お天気良くて最高でした。

久しぶりに基板を修理したり。とりあえず電池切れのワンダー3。電池レス化済みのROMだけは焼いてあるって話だったんで、とりあえずPANG3のCボードを載せて動かしてみたら、画面に変な縦線が入ったり、デモ画面で背景が表示されなかったりと変な感じ。

一瞬、基板がおかしいのかと思ったんですが、焼いてあるデータを吸い出してMAMEで動かしてみたら、同じように変な症状が再現したので、プログラムROM側がおかしいということでほぼ確定。

自前で作った電池レスのプログラムに書き換えたら、問題解消しました。焼いてあったのは、どうもDead Battery Societyで配布されてるワンダー3電池レスデータみたいです。うーん、クオリティ低いな・・・。

その後、キャプテンコマンドーも電池レス化。こちらもさくっと完了したんですが、何か変だと思ったら、サンプリング系の音声が鳴っていませんでした。マザーボードを交換したら、正常に鳴ったので、元のマザーが怪しい感じ。M6295まわりかな・・・。