グーグルストリートビューはもはや日本では問題なく受け入れられた

これだけあーだこーだ言って、結局、「気持ち悪い」「ストカー背高すぎ」「ストカー通り抜け禁止を通った！」ぐらいしか出てこないのだとしたら、

Google Streetview はもはや日本では問題なく受け入れられた
（むしろ、とても愛されている）

と言っても、まあ妥当なのではなかろうか。

ま、イソターネットやemailだって当時は「キモッ」「日本には拝啓・敬具と稟議書の文化があって」って言われてたわけだし。

何ならグーグルを訴えてみるのも良いとは思いますが、日本の場合、良くも悪くも達観した国民性があって、メッセージ性の強い訴訟って衆目の印象がとても悪くなる傾向があって逆効果な気もするし（「ネタにマジレスカコワルイ」「プロ市民？」「売名行為？」「こういうのに訴えられるGoogleStreetviewはいいものに違いない」）、そもそも、それも含めてグーグルの宣伝なわけだし。

っていうか皆さん一律にストリートビューが大好きなのだなと実感します。こんなに愛されるストリートビューは幸せものですね。ここまで含めてグーグルの掌の上（彼らが意図的にやっているかどうかは別として）だとするとさすがだなと思わずにはおれません。

YMZ294に曲データ用EEPROM

YMZ294を使った電子オルゴールですが、PIC内臓のフラッシュ（プログラム領域）を曲データとして使用していました。

Sourceboostの場合、romという組み込みの修飾子があって、これを使うと初期値ありのデータを内臓フラッシュに配置することができます（ここで配列として定義しようとすると.dataへコピーしようとするようでエラーとなるので注意!!）。

rom unsigned char *ymz294_data =
{
25, 193,
5, 65,
0, 192,
64, 190,
128, 183,
...

プログラム領域は3Kワードほど余っているので今作っているようなお遊びの曲は入るさ、と思っていました。ところが、コンパイラの制限だと思うのですが、rom識別子で配置可能なデータサイズの上限が256バイトに制約されていることがわかりました。
最低でもノート、ベロシティ、デルタなどの情報が音符ごとに二つ（ノートオン・ノートオフ）必要なので、お遊びの曲でも256バイトでは入りきりません。

---

ソースブーストコンパイラのrom識別子というのは大したことをやっていなくて、配列の各要素に対してリターン命令を生成しておいて、読み出し時には指定インデックスに対応するリターン命令へジャンプするという単純なものですが、どうもその際に256要素以上を扱えないようです。

RETLW 0x19 /* ymz294_data[0] */
RETLW 0xc1 /* ymz294_data[1] */
RETLW 0x5 /* ymz294_data[2] */
RETLW 0x41 /* ymz294_data[3] */

要は、それと同じことを256要素以上まで手動でコード生成するなりすれば良い訳で、充分にソフトで対応できる話ですが、割り付け位置の計算などが面倒そうだったので、今回はEEPROMを増設して対応することにしました。品種はat24c256というAtmelのi2c接続のEEPROMを使用しました。

前回、RTCとの接続も経験済みでしたので一発完動といいたいところですが、「入力のみのRA3ピンを間違ってSDAに割り当ててしまう」という初歩的かつケアレスなミスをやらかしてしまいました。それを除くと割と簡単にPICと接続することが出来ました。

備忘録: RA2/RA4 を SDL/SDAに接続。SDL/SDAはともに2KΩでプルアップ。