理屈が分かったので、考えは大体まとまった。
要は、一定時間ごとに、スイッチ押したのと同じ状態になればいいのさ。
・・・当然かｗ
とりあえず、AVRと小さな表示機を選定。
表示機は、SPI制御が出来て、バックライトがある奴。
当然グラフィック表示。
またもやaitendoで128×64ドットのちっこい液晶、しかもSPI制御という
ぴったりのAD-12864を買ってきた。
AVRは適当。
多分そんなに容量いらないんだけど、
表示用にFONTを積むと思えば、大きいに越したことは無い。
かと言ってピン数が少ないのも困る。
よく調べもせず、秋月電子の店頭で見つけたATmega328あたりにしようと思ったんだけど
ウチの書き込みソフトが対応してないっぽくて
イロイロやって、結局書けなくなっちゃいました（てへっ
とりあえず、今は手元にあったATmega8で作ってるけど
8KBは少ないべ。ASCIIを背負ったら2KBはいるしね。
とりあえず、その辺は後で考えよう。
あとは、実際のスイッチはPhotoMosで。
これならマイコンからも駆動できるし、電気的にも問題にならんだろう。
極性のあるフォトカプラとは違うのだよｗ
（ダイオードが入ってたことを考えると、フォトカプラの方がいいのか？）
あとは、末端のコネクタだね。
これは今も調査中。
ZHRかと思ったら違ってた。
とりあえず今回は、ぶった切っていつものコネクタに付け替えたけど。
ということで。
つづく(笑
とりあえず、リモコンをバラしてみた。
写真は差し控えますが(笑)
ひどい。
こんなの部品点数的には両手以下の数だし、なんかの基板と兼用だし。
1600円だって高いわ(笑
まあ、いいか。
恐らく韓国メーカーのを輸入販売してるだけだから。
で、サクっと解析。
結局、2段押しのスイッチがあるだけ。
逆流防止機構搭載！とか謳ってる割には、ダイオード入ってるだけだし(笑
一番恐れてたのは、３線で高度なシリアル通信とかしてたらどうしようってとこだが
それもなさそう。
感心したのは、ケーブルと基板がちゃんとコネクタ使ってること。
これのおかげで基板とケーブルの切り離しが確実にできる。
機能的なものさえ間違えなければ、本体側のピン配置は関係ない。
基板側のコネクタのピン番号だけで済む。
まあ、このリモコンが使えない系列（EOS Kiss系）とか、他社カメラへの対応を考えると
コストアップになったとしても、これはアリだね。
そんな感じで。
リクツは分かった。
つづく(笑)
三脚つながりで、場外乱闘中(謎)
いきなり、ケーブルがないのは何故かって？(笑
先日の、MTM4で、とある方が出してた「マルチインターバルタイマリモコン」というものに
えらく感動したので、いろいろ考えていたのですが。
あちらは赤外線リモコンの代用品ですが、EOS40Dには赤外線ポートは無いので
(当然、そのリモコンは使えないわけで)
とりあえず、同等のことをしようと思って
純正品を調べると
むやみに高い。
単純に言うと、シャッターボタンをケーブルで外に出すだけなのに
平気で5500円とかする。
タイマー機能付だとさらに倍以上。
ついでに、１０ｍの延長ケーブルが９８００円（ぉぃぉぃ・・・
とはいえ、本体を見ると
コネクタは３ピン。
たいそうな機能がついてるとも思えない。
じゃあ、互換品を探してバラすしか。
とりあえず、コネクタの仕様を調べるところから、と思って
検索したら、１６００円ぐらいで出てきたので
手始めにソレを買ってみました。
つづく(笑
MouserでAT45DB161D-SU-2.5 が・・・なくなってる（T_T)
外堀すら埋められないとは ○|￣|＿
あーあ・・・・・
XMEGA64がいつになるか分からないのに、注文しちゃった（てへっ
・・・・・・ダメ人間・・・
ツールの手直しをして、とりあえずテキストでデータを吐かせてみたけど・・・
ちょっ、ちょっと、考えさせてくださいｗ
とりあえず、方向としては
このまま行くか、
シリアルROM載せるか、
ですが。
なんの当てもなく、MouserでAT45DB161D-SU-2.5 あたりを
発注しようか迷ってる自分がいる・・・・・
どうしても、外堀埋めたいのね・・・
とはいえ、XMEGA64A4も入荷待ちになってるし・・・
しばらく停滞かもな～
フォントを扱うプログラムは、実に7年ぶりぐらい。
当時作ったフォント変換のプログラムを発掘して、
再度読み直してみる。
DOS窓で、フリーになったBorlandC++でコンパイルしていた形跡まで
全部残ってた。
あの時は、PICからAVRへと移りつつあった時期で、それでもまだ
PICでモノクロLCDパネルを表示して、その過程でフォント変換のシステムを
書いていた。
AVRの第一弾はLEDマトリックス。今みたいにキットがあったわけではなく
モジュールだけが簡単な資料とともに売られてた。
ゲーム業界からハードウェア設計に業種を変えたばかりで、
コードは書けても回路は描けない、そんな駆け出しにとって
その制御法は複雑怪奇なものでした。
それでもまあ、現場のボスに教えを乞い、タイミングチャートの読み方から始まった。
今にして思えば、たとえ制御できても、PC上での経験がなければ
文字の表示すら出来なかっただろう。
ゲーム業界、PCでの開発経験があったからこそ、今の自分がある。
まあ、絶対に無駄にはならないことは分かってたんだがｗ
で、フォントの変換システム。
単純な文字列からフォントデータを集めてアセンブリ形式のデータ定義ファイルに出す。
そんなものでも、いまだに役に立つのだから、これほど面白いことはない。
UnicodeとJISコードの変換テーブルを元にコードを取り出し、SJISに変換、その上でFONTXファイルから
データを探し出して、とりあえずファイルに。
16bitをUnicodeと見なして変換し、フォントのないところはダミーで埋めて・・・
そんなことをしたら2Mbyteになってしまった、なんてことがどこかに書いてあったな。
・・・・同じことを考えた人がいるんですねｗ
ファイルを分割してやれば何とかなるんじゃないかと思ってたんですが
予想以上に歯抜けというか、隙間が多い。
これだと分割の仕方が面倒になる。
というか、分割しきれない。
それよりも、SPIのシリアルROM、2MByteぐらいを積んで、
あとはテーブル引きしたほうが、断然速い気が・・・・・。
少なくとも、FATを辿っていくよりも、テーブルで一段引いて、それをオフセットにして
データ読み出ししたほうが、速いわな。。。
アドレスによる読み出し速度の違いはないんだし。
とはいえ、またSPIに頼るのも何だかな・・・
そんなことを考えながら、まだ画面には何も出てませぬ。。。
長い前フリでしたが（？）
やっと本題。
絵が出たので、次は文字列ですかね。
そーいうわけで、FONTファイルを探してたのですが
結局SJISの$FONTX2形式しか見つからなかったので
UnicodeからSJISへ変換しながら使うか、
それとも
フォントファイルをUnicodeで再構成してしまうか、ですが。
その前に、過去の経験からの話。
家庭用ゲーム機と呼ばれるものは、パソコンとは違って性能は
基本的に一定なわけです。
当然、使えるメモリサイズも一度決まってしまえば変わりませんね。
ここでは、各機の詳細は抜きで書きますけど
CPUから見えるメモリー範囲は一定であり、その時々によって中身が書き換わって、
ゲーム機のプログラムってのは動いています。
CD-ROMから読み込む、っていうのが、その書き換え行為そのものなのですが。
メモリが限られているわけですから、当然持てるデータが限られます。
たとえばRPGで、メッセージを出すために、すべてのフォントデータを常に丸ごと
メモリに置いてるか、といえば、そんなはずはありませんよね。
そのマップで、そのシーンで、必要な最低限をメモリにロードします。
メッセージ（文字列）は、開発過程で確定しますので、必要な文字はどれとどれか、ってのは
既に決まってるのです。
だから、そのフォントデータを抜き出して、番号を振りなおして、決まった場所に置いて、
メッセージはその再生順序を示すコードの列に置き換えられています。
たとえば
に 1
わ 2
に 1
は 3
に 1
わ 2
、 4
に 1
わ 2
と 5
り 6
が 7
い 8
る 9（振りなおした番号）
１４文字が、9文字分のデータに圧縮されます。
このデータをメッセージ表示の際に再生すれば、この文字列は再現できるわけです。
さて。
今回やってるマイコンでの画面表示ですが。
マイコンでも、同じようにメモリサイズは決まってますし、ROMサイズも決まっています。
ただ救いなのは、CD-ROMよりも大容量な（！）MicroSDが味方についてます。
たとえば、作ろうとしているものが、MP3プレイヤーだとしたら。
プレイリストをPC上で作らせて、その際にタグを解析して必要な文字列を全部洗い出して
必要な文字のフォントだけを集めて再構成し、文字列も全部プレイリストの中に持ってしまうのが
おそらく一番レスポンスよく動いてくれると思います。
その代わり、リストにないファイルについては、表示できなくなります。
まあ、最終的にどこを目指すかによるけど、とりあえずは、そうではなく。
もっと一般的に文字列を表示することを考えます。
そうすると、先の
Unicodeでフォントファイルを再構成する、という案が浮上してくるのです。
問題なのは、コードが飛び飛びになってること。
その辺をうまく使って、ファイルを分割するようにすれば、多少は速くなるんじゃないかと
思ったりもするのですが。
書き方次第、かな。
とりあえず、$FONTX2は、いつか来た道、なので。
まずはFONTの再編成から。
ここ数日、FONTを探してました。
WindowsがLFNでUnicodeを使うというので、
その配置で使える、$FONTX2形式を。
･･････････････････・・・・・・・・・・・・・・・・
そんなもん、ありませぬ ○|￣|＿
それよりも、
「文字コード、この乱立っぷりは一体何！何なの！」
英語圏は確かにASCIIコードで事足りるのかもしれないけど、
我々漢字圏は数万文字を持つわけで
確かに、昔から頭痛の種ではあったのですが。
日本には恐らく元々JISコードというものがあり、漢字にコードが振られていたのに
それをなぜかMicrosoftを含む数社が再マッピングしたShift-JIS、
ここ20年で国際化が進み、２バイトコードの標準化の過程で出てきた
EUC、そして、Unicode。
ややこしいのは、日本の漢字コードの規格化の過程において、幾度となく追加と修正が
行われ、そのたびにJISの規格番号が追加されていること。
その辺も含めないと、表示できない文字が出てきたりする。
・・・・・コード体系についてはかなり深いいきさつの元で成立してるようなので、
これ以上は突っ込みたくないな。
それ以上に、フォントファイルの形式がいっぱいありすぎて、
その殆どは仕様が公開されていない。
それらの相互変換を完璧にこなすようなツールもない。
Windowsで使われるttf形式とPostScript形式の変換は出来るようだが
旧来の$FONTX2形式にはならないらしい。。。
・・・・FatFsの説明書きをつらつらと読んでたら
どうも、SJISとUnicodeの変換テーブルを持ってるらしい。
使うにはcc932_avr.cをリンクしなさい、と。
ソースを覗いてみると・・・まあ、確かにあるね。
これでとりあえず、誤魔化せるのかしら。
じゃあ、変換するためのテーブルを探すか！と
検索すると・・・
ここでも、テーブルの内容にいくつものローカルなものが存在するらしい。
まぢですか～ ○|￣|＿
Unicodeの文字をSJISのどの文字のコードに変換するか、というのは
実はそうそう簡単な話ではないらしい。
この辺の話も、掘り下げればかなり深いのかもしれないけど
ここでは書きません。
スルーして、じゃあどの変換テーブルが当面安全なのか、というと
JAVA 1.4.0以降のテーブルと同じだ、というテーブル表に行き着いた。
とはいえ、こんなデカイテーブル、マイコンのメモリに納まるわけがないのは
明白なわけで。
どうしますかねぇ・・・
と、言うわけで（？）
書き込みコマンドの使い方も分かったので
とりあえず、画像でも出してみますか。
まあ、ここに載せるにあたり、人様の著作物を無断で使うわけには行かないので
自分の写真から何枚か。
当然、こんなデカイデータ、ROMにもRAMにも入りませんから、
MicroSDとFatFsを使っています。
元画像はJPEGですけど、とりあえず24bitカラーのBMPに変換してからトリミング、
最終的には16bitカラーBMPに変換しています。
その割には、ここに貼ってる写真はトリミングしてねーじゃないかってのは
突っ込んじゃダメですからね。
ROMから再生するためにデータ変換してBMPのヘッダ削ってC言語の配列にして・・・なんて
やってましたが、さすがに飽きたので(笑
FatFsを有効にして、とりあえずファイル名はテーブルに持って。
BMPファイルは、いつか来た道ですから。
画像サイズの情報を取り出して矩形を設定後、
1ラインづつ読み出して一度RGBに分解。
フェードイン/アウトの演算後、Gのみ６ビット、あとは５ビットの計16bitフォーマットに再構成、
バッファに書き戻した後でバースト転送。
やろうと思えば、24bitカラーでも変換しながら描けるんですけどね～
ちなみに、16bitカラーのBMPってのは規格外ですからね。
BMPの仕様には正式に含まれていないらしいです。
まずは、予定通りバックライトのＰＷＭ制御を。
適当にタイマー割り込みにＰＷＭ動作の設定をして、カウントアウト時に
割り込み処理内で次のＰＷＭ時間の値を更新する。
メインループ側では、とりあえず一定時間経過ごとにカウンタを更新してみる。
・・・・動画もあるのだが、昔のデジカメで取ったのでは小さすぎて
何がなんだか分からないので割愛。
挙句の果てに携帯電話のカメラの方が解像度も高いし焦点距離も短いので
ここ最近の接写は全部携帯電話ですわ。
次。
フェードイン/フェードアウトをソフトウェアで。
データに演算をして輝度が変わったように見せかける。
さすがにリアルタイムで全画面書き換えるほどの能力はないらしい。
まあ、これはＣＰＵの問題なので、クロックとI/Oポートの性能によってしまう。
したがって、今のATmega128では限界ということで。
・・・・動画は(以下略 なので省略。
最後に、表示コマンドの仕様について。
他では、だれも何も書いてくれないようなんだけど。
内部バッファに於けるカレントのRow Address と Column Address を設定するコマンドと
メモリーに書き込むコマンドがあるけど、
この３つって、よくよく仕様を見ると、そんなに自由じゃないのね。
というか、カレントのアドレスを設定する、っていうより
転送先の矩形を設定するって感じかな。
アドレスといってるけど、実際は座標だし
要は左上座標と右下座標を設定するコマンドなわけ。
その上で書き込みコマンドは
「設定された矩形にデータを書き込む」感じ。
だから、矩形を満たすだけのデータを送らないと
次の書き込みコマンドを受け付けない。
最初に自分が書いたコードが動かないのは、ここに理由があって
毎回 コマンド→データ のセットで書いてた。
サンプル見ると、バースト転送してるわけだから
そりゃ気づくよな。
こんな仕様になってるメリットを考えてるんだけど・・・・
文字とかアニメーションのように、決まった矩形領域を書くときには、
こっちのほうが有利なのか？ぐらい・・・かな。
イメージは、カーソルのある位置に文字を書く、って感じ。
うーん。
