続：美咲フォント

昨日に続き、美咲フォントを利用する作戦です。

昨日はｐｎｇ画像をｂｍｐ画像にしたモノを、
ＨＳＰを使ってａｖｒ用アセンブラのソース形式
にするところまでやりました。

で、実際にＡＶＲｓｔｕｄｉｏ上でｍｅｇａ１２８
用にアセンブルしてみたら…上手く行きました。
まぁ、容量さえ足りるなら特に難しいところは
ないでしょう…


次。インテルｈｅｘ形式用のＨＳＰスクリプトも
書いてみました。昨日のを流用してチョイチョイと。

で、吐き出したｈｅｘファイルを秋月のｅｅｐｒｏｍ
ライター用ソフト（ＰＩＣライターに付属のソフト）
で読み込んでみたところ、エラーも無く上手く読み
込めました。
容量としては６０ＫＢを超えているので５１２ｋビット
タイプ（６４ＫＢ）以上のｅｅｐｒｏｍじゃないと
入りきりません。

買い置きのｅｅｐｒｏｍを漁ったら、約１０個全部が
２５６ｋビット（３２ＫＢ）タイプだったので、
書き込み確認は出来ませんでしたが…

そうそう、秋月とかで売っているSG12864Aのような
ＬＣＤの場合、ビット列が横じゃなく縦方向で
用意しないといけないので、そういう用途の場合は
ハードにあわせてスクリプトを直す必要が
あるかもしれません。

まぁ、直すのはチョイチョイだから後回し。


次。Ｃ言語ソース形式にもしてみたいな。
ＡＶＲであればＷＩＮ－ＡＶＲ（ＡＶＲ－ｇｃｃ）
で使えるようにしたいところ。

以前デカイデータをプログラム領域（.cseg）に
押し込んでｇｃｃのプログラム組もうとした時に
散々トラブった記憶があるので、ちょっといやな
予感ですが…

とりあえず方針的にはchar型の２次配列にして、
１バイト単位でメモリ上に配置されるように
考えてみます。

で、スクリプトはすぐに出来ました。

実行して、出来たＣソースをＡＶＲｓｔｕｄｉｏ
のＣプログラム中に取り込んでコンパイル…。

でかすぎるというエラー。あ、.dsegに配置しようと
してるな。間違えた。入る訳無い。ＳＲＡＭは
４ＫＢしかありませんからね。
あらためて.cseg上に配置するようにソースを修正…。

またしてもでかすぎるというエラー。うーん、
今回は間違えは無いはずなんだけどな…

でかいというのなら、極端に削ってみよう…
３行程度（２４バイト分）にしてみた。
コンパイル通った。（あたりまえ）

これをシミュレーションに掛けてみて、プログラム
メモリ、ＳＲＡＭ、ＥＥＰＲＯＭ、レジスタの
それぞれをメモリダンプ取ってみると…
うん。やっぱりプログラムメモリにしか配置
されてないよな。（以前の実験ではプログラムと
ＳＲＡＭの両方にメモリを確保に行ってしまい、
全然ダメだったんですが、今回はそれは大丈夫
みたい）

うーん、方針は合ってるのか。

データ量を半分くらいに削ってみる…
お、コンパイル通った！

うーん、３０ＫＢくらいならＯＫか…
オリジナルは６０ＫＢくらいになっちゃう
ので、ここから少しずつ削りながらコンパイル
を繰り返してみると…

およそ３２ＫＢを割ったところでコンパイルが
通るようになるみたい。


うーん、ＡＶＲ－ｇｃｃって、３２ＫＢの壁
なんて有ったんだったっけなぁ？記憶に無いな…
あとで調べなおしてみよう…
（１６ＦシリーズのＰＩＣは面倒くさいのが
　イロイロあった気がするけど…）

いずれにしても、このままでは８ビット版ＡＶＲ
には載せられそうに無いな。


というわけで、スクリプトを書きまくったので、
あとでサイトに纏めておきたいと思います。


ちなみにｅｅｐｒｏｍに格納しておけば、メモリが
ちっちゃいマイコンでも充分使い物になるかと
いう気がします。Ｉ２Ｃで読み出してＬＣＤに転送
みたいに…。

SG12864Aみたいな１２８×６４ドットＬＣＤだと
１ドット＝１ビットでも１０２４バイトが必要に
なるはずなんですが、テキスト文字表示だけに
特化するならマイコン側にグラフィックＶＲＡＭ
を持つ必要は無いので、マイコン側に必要なのは
テキストＶＲＡＭと変換処理ロジックだけ。

１２８×６４ドットを１キャラクターあたり
８×８ドット単位とすれば１２８バイトで済んで
しまいます。
ｔｉｎｙ２３１３じゃぁ厳しいけど、もうちょっと
大きいマイコンなら何の問題も無いでしょう。

忘れてはならないのは、ｊｉｓとｓｈｉｆｔ－ｊｉｓ
の変換とか、その辺りに待つわる文字化けとか、
そのあたりかな。

ハヤニエＬＣＤを工作に引っ張り出すか、
もしくはＭＥＧＡ１２８のオンメモリに組み込んで
リアルタイムのビデオ表示に使うか…

イロイロ使い道は有りそうな予感。
（￣ー￣）