フォントファイル（２）
フォントを扱うプログラムは、実に7年ぶりぐらい。
当時作ったフォント変換のプログラムを発掘して、
再度読み直してみる。
DOS窓で、フリーになったBorlandC++でコンパイルしていた形跡まで
全部残ってた。
あの時は、PICからAVRへと移りつつあった時期で、それでもまだ
PICでモノクロLCDパネルを表示して、その過程でフォント変換のシステムを
書いていた。
AVRの第一弾はLEDマトリックス。今みたいにキットがあったわけではなく
モジュールだけが簡単な資料とともに売られてた。
ゲーム業界からハードウェア設計に業種を変えたばかりで、
コードは書けても回路は描けない、そんな駆け出しにとって
その制御法は複雑怪奇なものでした。
それでもまあ、現場のボスに教えを乞い、タイミングチャートの読み方から始まった。
今にして思えば、たとえ制御できても、PC上での経験がなければ
文字の表示すら出来なかっただろう。
ゲーム業界、PCでの開発経験があったからこそ、今の自分がある。
まあ、絶対に無駄にはならないことは分かってたんだがｗ
で、フォントの変換システム。
単純な文字列からフォントデータを集めてアセンブリ形式のデータ定義ファイルに出す。
そんなものでも、いまだに役に立つのだから、これほど面白いことはない。
UnicodeとJISコードの変換テーブルを元にコードを取り出し、SJISに変換、その上でFONTXファイルから
データを探し出して、とりあえずファイルに。
16bitをUnicodeと見なして変換し、フォントのないところはダミーで埋めて・・・
そんなことをしたら2Mbyteになってしまった、なんてことがどこかに書いてあったな。
・・・・同じことを考えた人がいるんですねｗ
ファイルを分割してやれば何とかなるんじゃないかと思ってたんですが
予想以上に歯抜けというか、隙間が多い。
これだと分割の仕方が面倒になる。
というか、分割しきれない。
それよりも、SPIのシリアルROM、2MByteぐらいを積んで、
あとはテーブル引きしたほうが、断然速い気が・・・・・。
少なくとも、FATを辿っていくよりも、テーブルで一段引いて、それをオフセットにして
データ読み出ししたほうが、速いわな。。。
アドレスによる読み出し速度の違いはないんだし。
とはいえ、またSPIに頼るのも何だかな・・・
そんなことを考えながら、まだ画面には何も出てませぬ。。。
