美咲フォントをマイコンで使ってみようという
作戦です。
http://www.geocities.jp/littlimi/misaki.htm
美咲フォントは8×8ドット、しかも隣り合った
文字同士でドットがぶつからないように実質
7×7ドットに収めた日本語のビットマップフォント
で、もともとポケコンにも組み込まれていた恵梨沙
フォント(8×8)を7×7ドットに詰め込んだもの
だそうです。
で、このフォントは商用/非商用、改変の有無に
関わらず利用可能とのことなので、マイコンに
流用できないかな?と思っていました。
詳しくは
http://www.geocities.jp/littlimi/font.htm#license
ライセンス情報をご参照。
こんな役立つものを公開してくれていることに感謝!
で、JIS第1水準、JIS第2水準とも登載
しているこのフォント。メモリサイズさえなんとか
なるならマイコンに詰め込んでしまいたいという
欲望が沸いてくるわけです。ひとまずAVRの
アセンブラソース中に取り込める形式への変換
に挑戦。挑戦って言っても、単にデータ変換ですが。
美咲フォントは、フォントデータ(各種バイナリデータ)
に加えて、png画像ファイルも公開されているので、
このpngファイルを使い、ツールを使って
1ドットずつ読み出してはデータ変換、
読み出してはデータ変換という泥臭いことを
やってみます。
まず公式サイトのダウンロードコーナーからpng
ファイルのアーカイブをダウンロードしてきます。
今回使うツールとしては久々にHSPに白羽の矢を
立てたので、HSPで扱いが出来るBMPに変換
します。(適当なグラフィックツールを使って
misaki.bmpという名前で保存しなおしてください)
752×752ドットの画像ファイルになるはずです。
で、適当なスクリプトを組んでみます。
こんな感じ。
screen 0,752,752,,0,0
picload "misaki.bmp"
dim hx,16
hx(0) = "0"
hx(1) = "1"
hx(2) = "2"
hx(3) = "3"
hx(4) = "4"
hx(5) = "5"
hx(6) = "6"
hx(7) = "7"
hx(8) = "8"
hx(9) = "9"
hx(10) = "A"
hx(11) = "B"
hx(12) = "C"
hx(13) = "D"
hx(14) = "E"
hx(15) = "F"
notesel note1
for yy,0,84,1
for xx,0,94,1
cc = " .db "
for dy,0,8,1
pp = 0
for dx,0,8,1
x = xx * 8 + dx
y = yy * 8 + dy
pget x,y
p1 = ginfo(16) ;R
p2 = ginfo(17) ;G
p3 = ginfo(18) ;B
if (p1
(preタグはイマイチの表示になっちゃうな、
このブログ…)
HSPのスクリプトエディタ上から実行をすると、
bmpファイルのフォント一覧を表示して、
それを1ドット1ドット読み出しながら10秒前後
かけて変換が行われます。
とりあえずゴシック体だけやってみましたが、
明朝もファイル名を弄るだけで動くはずです。
process ended.というダイアログボックスが
出てきたら変換終了。
misaki.inc というファイルが出来あがります。
出来上がりはこんな感じ。
.db 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ;0
.db 0x00,0x00,0x00,0x00,0x00,0x80,0x40,0x00 ;1
.db 0x00,0x00,0x00,0x00,0x40,0xA0,0x40,0x00 ;2
.db 0x00,0x00,0x00,0x00,0xC0,0x40,0x80,0x00 ;3
.db 0x00,0x00,0x00,0x00,0x00,0xC0,0xC0,0x00 ;4
.db 0x00,0x00,0x00,0x30,0x30,0x00,0x00,0x00 ;5
.db 0x00,0x30,0x30,0x00,0x30,0x30,0x00,0x00 ;6
(中略)
.db 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ;7064
.db 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ;7065
この1行1行が1文字1文字のデータに相当します。
ちなみに行番号1(上から2行目)はカンマの
ビットマップデータです。フォント一覧の該当個所
と見比べていただけばこのデータ形式の意味が
おわかりいただけるかと。
要は、1文字を8×8ドットとして順々に切り出し、
8ドットを1バイト(=1ライン)にまとめて出力
…8ラインで1文字分を構成しています。
細かいことはスクリプトを解読してください。
右側に表示されている数字は文字コードではありません。
念のため。
さて、ここで問題になるのはデータ量。
6~7000文字ほどあるので、1文字8バイト
としても50kBくらいになります。
mega128くらいになれば、そのままプログラムコード中
に押し込んでしまっても半分程度の容量しか食いません。
mega64だと結構微妙かな…
それ以下のマイコンとなると、プログラムコード中に
押し込むことが出来ません。
ってことで、そういう場合はI2Cメモリなどに
入れておいて必要な時に取り出せば、arduino程度
でも容量を気にせず使えるだろうと目論んでます。
ってことで、スクリプトをちょっと弄りなおして
インテルhex形式にしてしまえば秋月ライター
でI2Cメモリに書き込めるようになるから、
あとでスクリプトを見直しておきたいところ。
あとは、マイコンと繋いで使うとすると、
なんとなくshift-jisに対応させた方が使いやすそう
だなという予感。AVRstudioのエディタ上
でshift-jisで書いておけばそのまま表示できる、
みたいな。
昔から、jisとshift-jisの変換式とかちょっと苦手
なんだよな…いまだに…
苦手って言うか、やったこと無いから勘所が無い
ってだけなんだけど。
shift-jisって確か2バイト目の扱いが厄介なんだ
よな…。2バイト目が制御コードに重なると
化けたりとか。
うーん、漢字in、漢字outを使った方が楽なのか、
それとも2バイトですべて済んじゃうshift-jisの方が
楽なのか… 用途によるのかな?
内部的にはjis形式で良いとして、アプリ側との接続
にはshift-jisくらいは考えたおきたいな。EUCや
UFT-8までは対応しなくてもいいだろう…
HSPって簡単でとっつき易いのはいいんだけど、
ビット操作とか色々細かいことやり始めると
ちょっと困るね。今回の10進→16進変換とか。
べき乗計算に「^」を使ったら、実はHSPでは
排他的論理和だったそうで…なかなかバグが
見つからなくて困った…
でもグラフィックデータを簡単に扱えるのは
さすがだな。