Darkside（https対応しました）

　MOが何枚が出て来たので、内容を読み出そうとしてそれほど簡単ではないと気づいた。
　手元のMOドライブは、SCSI 接続なのだ。

　いま SCSI 機器を使おうとすると、想像より遥かに困難なことになっていた。
　普通に考えれば SCSI を USB に変換する機器が最も汎用だが、遺憾なことにそういう製品がないのだ。僅かにロジテックのものが話題に出るだけで、それも２万円ぐらいする。更に、同じロジテックの MO ドライブを認識しないらしい。自分の手元にあるのも、運悪くロジテックの MO ドライブなのだ。
　ならば大袈裟になるが、パソコンに SCSI ボードを取り付ける？
　だが、適切な空きスロットの確保という厄介な話があり、それをクリアしても恐ろしく高価なのだ。安くても、５万円ぐらいする。

　そうなると、確実な方法としては USB 接続の MO ドライブを新たに買うことだ。
　しかし MO というメディアが使われなくなって久しいので、そんな都合の良い製品もまた絶滅危惧種。１万５千円ほども払って、中古ドライブを入手した。今後ますます入手困難になる一方だと判断したからである。ドライブの新製品が出ない以上、ドライブが壊れたら MO にアクセスできなくなる。早急にデーターを引き上げねばならない。
　だが、大金を払った価値はあったようだ。自分も過去のデーターは適宜新しいメディアに複写して生き長らえさせているが、未発見だったデーターが MO に眠っていたのだ。パソコン通信時代のログ。

　ほぼ一杯まで容量が使われていたが、それでも０．５ギガバイト。今の感覚からすると、雀の涙みたいなサイズでしかない。だが、大半がシフトJIS形式のテキストデーターである。つまり、２〜３億字ぐらいあるのだ。０．５ギガバイトは、無尽蔵にも感じられる超大容量である。
　パソコン通信がインターネットと最も異なったのは、SNS の前身とも言える掲示板でさえ、当時は企業でないと開設困難だったこと。つまり、情報発信の大衆化が行われていなかったこと。昭和時代のテレビがそうだったように、ネットメディアも寡占状態だったのだ。パソコン通信では PC-VAN と NIFTY が２大メジャーだった。一方の雄である NIFTY に存在し、パソコンの改造で知られた FEXT というフォーラムがあった。そこに自分が書き込んだログを１件、紹介しておきたい。
　スーパーπというプログラムをベンチマークテストとして使用することを提唱したのは、たぶん↓これが初です。　

- FEXT  MES(12):HARDWARE-Extender の部屋 95/10/10 -
11110/11117 QGA02256  ＩＤＫ           MEGA-PI】新・安定動作試験
(12)   95/10/09 23:57                     コメント数：1
　以前、メモリーの信頼性テスト用と称して円周率計算ソフトをアップしました。
今回も同様の趣旨でライブラリ＃１２に新しいソフトを転載してあります。
　円周率計算の世界記録を持つ東大金田研が記録達成に使用したスパコン用のソフトを
じきじきに Windows に移植したという最強ソフトです(^_^)
　ＣＰＵやメモリーはもちろん、ＨＤＤも酷使するため、改造によって少しでも
不安定要因が残っていると途中でエラーが出ます。
　負荷はそこらのＯＳやアプリ真っ青で、他のあらゆるソフトが正常に動くシステム
でもエラーです。果たして最もキツいアプリとされているナスカとどっちがキツい？
　うちの環境では外部 66MHz でアウト。60MHz でも TRISET でウエイトを抜くと
アウトという始末です。セカンドキャッシュを切ると 66MHz でもＯＫなので、どうも
PB-SRAM モジュールに不安ありですね。
　試験は１０４万桁で行って下さい。120MHz から 133MHz だと２０分前後です。
途中でエラーが出ずに計算が無事終了すれば、多分何を走らせても大丈夫でしょう。
　実はビデオキャプチャーに備えて手間のかからない安定動作マシンを組むべく、
マザーボード買ってきたけど、外部 66MHz でさえ円周率試験が通らないので唖然と
しています。果たしてエクステンダーの面々の限界クロックアップマシンが、この
超キツいテストにどこまで耐えられるか・・・
　ベストな記録を狙うなら、最高速区画に放り込む必要があります。Windows 3.1 と
Win32s の環境なら４ＭＢほどライトバックキャッシュを確保するとかなり効きます。
　こんな感じで・・・まずは凡マシン２つを例にしてみます。

　右端の受信 dsPIC を256版に交換し、書き込む。問題なく、一発で成功。

　基板を車体に戻し、主要なコネクターを接続する。

　主電源を入れるが、相変わらずテレメトリーが返って来ない。
　送信機に表示される車体側バッテリー電圧は、ゼロのままだ。

　受信 dsPIC に再度書き込みを行うと、エラーが出た。射撃管制 PIC とは接続していないし、車体にはラジコンバッテリーも接続していない。新品の dsPIC が壊れるわけがないのだが？

　繰り返しても、不穏なエラーが出るだけだ。ＵＳＢケーブルを変えても、PicKit 4 のファームウェアをアップデートしても、症状は変わらない。

　何度書き込みしようとしても、成功しない。

　ふと思い立って、受信 dsPIC の隣に鎮座している走行制御 dsPIC に書き込んでみる。一発で、正常に書き込めた。
　どうやら、問題はメイン基板の受信 dsPIC 周りにあるようだ。書き込みに関係するピンへの配線か、電源配線に問題がある。基板を取り出した最初の書き込みが成功したことと言い、そもそも突然テレメトリーが途絶したことと言い、書き込み系ではなく電源系に接触不良か再現性のあやふやな短絡が生じているのではなかろうか？

　MCCには重大な欠点があり、プロジェクトを作った後からPICの機種変更ができない。新しいＰＩＣでプロジェクトを作り直し、ＭＣＣで設定し直さねばならない。しかも、X IDE は２つ同時に起動できないので、新旧比較しながら設定して行くこともできない。
　すべての設定を、画面コピペして画像保存しておく。面倒臭い！
　せめてメモリー容量が違うだけの機種は、自動設定して欲しいのだが。

　そんな文句を言いつつプロジェクトのプロパティーを開くと、なぜか Device が選択可能になっている。

　試しに、dsPIC33EV32GM102 から dsPIC33EV256GM102 に変更してみる。

　ＯＫボタンを押すと、警告らしき文言が表示された。しかし、逆に言えば機種変更を認識できている。

　以前はできなかったので、X IDE のバージョンが 5.5 に上がってから出来るようになったのかもしれない。
　いずれにしろ、警告に従って設定が適切にされているかどうかを確認する必要がある。結果は、問題なし。メモリー容量が変わっただけで、自動設定が失敗するようでは困る。

　コンパイルも問題なく通り、書き込みもエラーなく終了。やはり、元の dsPIC は壊れていたのだろう。

　基板の改造に関しても、テスターで最低限の確認は済ませておいた。

　メモリー容量には充分な余裕があり、あえて機種変更する必要はない。それなのに機種変更したのは、３２キロ機種の在庫が尽きたからだ。メモリー容量が違うだけの機種に簡単に乗り換えできるとなれば、かなり助かる。

　受信 dsPIC が、復活しない。書き込めない。

　もはやこうなると、偶然では済まされない。受信 dsPIC だけ突出して壊れ易い。ならば、固有の問題がある。
　３つ並んだ dsPIC のうち、受信用に固有として疑わしいのが射撃管制 PIC との通信である。射撃管制 PIC は電圧降下による誤動作を防ぐため、電気二重槽コンデンサーによる独自電源を抱えている。そのため、主電源を落とした場合でも１０秒以上動き続ける。すると、射撃管制 PIC の出力信号が受信 dsPIC の電源より高電圧になるのではないか？

　該当するのは、ＳＰＩ送信用の１本。電位逆転を防ぐためのダイオードを入れるべきだ。
　だが、基板に手を加えるために取り外そうとすれば、例によって大騒ぎとなる。メカボックス・ステイも外さねばならない。

　メイン基板を外したら外したで、この大量のコネクターをまたセットし直さねばならない。車体内部は配線の濁流であり、元通りに通し直すことを考えただけで頭が痛い。

　幸いにして、逆電位になる可能性がある信号は１本だけだ。

　ショットキーバリアダイオードを１本、配線の根元を切断して割り込ませる。

　主砲エアガンのトラブルは以前なら時々発生していたが、酷くなったのはシリンダーを交換してからである。
　フルサイズのシリンダーに替えたのは、エアー容量を過剰にすることで将来の重量弾使用に備えようと考えたからである。しかし、入手性が良く品質が安定し価格も安い０．２５グラム弾の使用で妥協するのもアリだ。
　ここは、元の加速シリンダーに戻してみよう。

　メカボックスの分解＆組み立ては、面倒臭いこと甚だしい。これでもクラシックアーミー製はメインスプリングを独立して交換できるだけマシなのだ。オリジナルのマルイ製なんて、更に分解したくない。

　加速シリンダーに戻したが、これだけでは試射できない。なぜか、受信 dsPIC が死んでいる。

　受信 dsPIC にプログラムを書き直そうとしたところ、これまで見たことのないエラーが発生した。

　もう一度繰り返す。エラーの出方は一定しないのが普通である。やっているうちに成功することもある。
　２度目は見慣れたエラーになった。デバイスIDが０という、ありふれたパターン。ならば、３度目だ。同じように、デバイスIDが０だ。

　メイン基板には３つの dsPIC が搭載されているが、なぜか受信 dsPIC だけ突出してこの手のトラブルが多い。