アルゴ算法堂

ＰＩＣ１８Ｆ１４Ｋ５０－Ｉ／Ｐ

sampodo — 2009-07-09T14:35:03+09:00

　秋月のＨＰでＰＩＣ１８Ｆ１４Ｋ５０－Ｉ／Ｐの取り扱いが始まっていました。ＤＩＰでないものは、ちょっと前から扱われていたようですが、今回のものは20ピンＤＩＰ。お値段は@200。

　価格もお手軽だし、ＤＩＰなので扱いやすい。機能は、ROM8KW、RAM768Ｂ。ＡＤ 11 / EUSART 1 / ECCP 1 / MSSP　といったところに、USB（256Ｂバッファつき）搭載。USBを除けば、PIC16F88ぐらいの機能です。クロックは４８Ｍまで可能なようです。
　18Ｆシリーズとしては決して強力なチップではないのですが、何しろ、ＤＩＰで、＠200。よほど天邪鬼でない限り、16F88や16Ｆ648Aなど18ピンクラスのチップは出番がなくなりそうです。

　とはいえ、16Ｆシリーズ。結構な数の手持ちがあるので、しばらく、使い続けそう。消化試合？

熱いＨＤＤ

sampodo — 2009-07-08T01:48:06+09:00

　いよいよ暑い夏に入りそうです。

　プログラムを組んでいるだけならば、それほど、容量が要らないＨＤＤですが、画像やサウンドを扱い始めると、やはり、多い方がいい。
　ということで、リソースバックアップ用にＵＳＢインタフェースのＨＤＤを使っています。３００Ｇぐらいのものが一台だったけれど、さらに、別のプロジェクトで３００Ｇぐらいのものを用意しました。

　この二台、リソースを一度退避すれば、数ヶ月に一度ぐらいしか使わない。ということで、特に冷却性能などは気にしていなかったのです。
　ところが、実際にリソースの転送をすると、ＨＤＤの筐体が、とても、熱くなります。動いているのですが、何か、不安になるほど。結局、心配で、動作中は外から風を送ってしまいました。電池で回るような小さなファンでも、十分に冷えるようです。
　電子工作の手が止まっているのですが、まず、最初に再開するのは、ＨＤＤ冷却用のファン台製作になりそうです。

　この巨大なリソースのバックアップ用のドライブを捜したところ、ポータブルＨＤＤで512Ｇというのがありました。こちらも、熱関係を心配したのですが、それほど、熱くはなりませんでした。ポータブルということで省電力設計されているのが幸いしたのかも知れません。

リュートのロバート・ジョンソン

sampodo — 2009-06-25T21:18:34+09:00

　よく弾くリュート曲の作曲家としてクレジットされているロバート・ジョンソン。どんな人か、気になっていたのですが、調べていませんでした。

　たまたま、眠れぬ夜に、手持ちのヴァージナルの楽譜を眺めていたとき、「Elozabeth Rogers Hir Virginall Booke」の序章で、ロバート・ジョンソンについて書いてありました。

　リュート奏者で、作曲家。シェークスピアの劇音楽を書いた人。同時代の他の舞台音楽も手がけているそうです。王族や貴族のお抱え楽師？。当時のリュート奏者としては、ジョン・ドーランドに次ぐ評価を受けていたらしい。

　どこで誰に仕えたとか、そういう記述があるのですが、これが、ちょっと、問題でした。というのは、おなじみの wiki や、allmusic に書いてあるものと、相当違う。手元の本は1982年版だから、情報が古いのは考えられることです。しかし、wiki や allmusic の記載をそのまま、信じられるものかどうか。

　「Elozabeth Rogers Hir Virginall Booke」の同じところで、ジョン・ウィルソン（John Wilson 1595-1674）という、リュート奏者（作曲家）が紹介されていました。ジョン・ドーランド、ロバート・ジョンソンに続き、「英国一のリュート奏者」と呼ばれていたそうです。この人の曲も、弾いてみたいです。

テキストのコード

sampodo — 2009-06-23T18:32:53+09:00

　パソコンで扱うテキストのコード、大抵の場合、ShiftJisで扱っていました。

　WEB関係は別としても、プログラムに関しては、大体、これで通っていたのですが、新しいツールでは、ソースプログラム自体がUTF-8など、新しい？エンコーディングで書くのが標準になってきています。
　Windows自体、内部はUnicodeで動いているのだから、こっちの方が、自然なのだから、当然の流れとは思うのですが、結構不便。
　過去の遺産のテキストファイル（まさに、テキストや、ソースプログラム）は、殆どが、ShiftJis。新しいファイルは、UTF-8で書いてあるから、テキストファイルの種類がいくつもあることになります。拡張子がtxtだからって、エンコーディングまでは、読んでみないと判らない。

　プログラミング上でも、新しい方ではテキストの扱いが自然になって、バイトの区切りで文字が生き別れになるようなことがなくなり、とても便利なりました。
　が、一方で、過去の遺産のライブラリや、パーツとしてのプログラムでは、文字の扱いが違うので、そのまま、流用できないのは、痛い。

　プログラミング言語の仕様の違いなどよりも、テキストコードの違いの方が、影響が大きい気がします。