かなり昔にＡＶＲマイコンで、データロガーを作成した時、既に漢字の表示
は対応していたが、ＲＬ７８でも漢字に対応した。

表示フォントは１２ピクセルを使う。
これは、表示の限界（難しい漢字は、判読出来ないが・・）少しでも情報量
を多くしたいのが理由としてある、１６ピクセルの方が判読しやすいが、表
示のバランス的には１２ピクセルの方が好みな感じ。

但し、いくつか制限がある、漢字のビットマップフォントを置く容量が無い
為、どこか別途、配置する必要がある。
※ＲＬ７８（２５６Ｋデバイスなら、Ｆｌａｓｈに置く事が可能）
・１２ピクセルフォントで、１３６キロバイト程の容量が必要。
・１ＭビットのＥＥＰＲＯＭにも入らない。
・ＳＤカードを接続するシステムなら、ＳＤカード上に漢字ビットマップを
置く事で、描画が可能。
・キャッシュを設ける事で描画パフォーマンスを最適化。

１２ピクセルのフリーフォントは色々あるけれども、今回は、蕨１２を使った。
フォントデータはＢＤＦ形式なので、展開して、バイナリーデータにする。
この際、ＳＪＩＳ形式の並びとした、そうする事で、効率良く配置でき、無駄
が比較的少ない。
ＳＪＩＳのコードから、漢字のリニアアドレスを得る関数として、以下のコード
を使う。

static uint16_t sjis_to_liner_(uint16_t sjis)
{
    uint16_t code;
    uint8_t up = sjis >> 8;
    uint8_t lo = sjis & 0xff;
    if(0x81 <= up && up <= 0x9f) {
        code = up - 0x81;
    } else if(0xe0 <= up && up <= 0xef) {
        code = (0x9f + 1 - 0x81) + up - 0xe0;
    } else {
        return 0xffff;
    }
    uint16_t loa = (0x7e + 1 - 0x40) + (0xfc + 1 - 0x80);
    if(0x40 <= lo && lo <= 0x7e) {
        code *= loa;
        code += lo - 0x40;
    } else if(0x80 <= lo && lo <= 0xfc) {
        code *= loa;
        code += 0x7e + 1 - 0x40;
        code += lo - 0x80;
    } else {
        return 0xffff;
    }
    return code;
}

ＢＤＦ形式を展開して、バイナリーデータを作成するアプリケーションは、以前に
作成した「bmc」を使う。
ビットマップ変換
この変換プログラムをコンパイルするには、mingw64 か、OS-X（Linux）で行なう必
要がある、詳細は、glfw3_app を参照して欲しい。

また、バイナリーデータは、蕨１２フォントＳＪＩＳバイナリーに置いてある。

漢字表示のアプリとして、ファイラーを作成した。
RL78/G13 SD カード LCD ファイラー

ＳＤカード上のファイル選択の様子：
・ＬＣＤの横幅を超えるファイルは、自動でスクロールする。
・選択中は、反転表示。
・ディレクトリーの移動が可能。

ＬＣＤに表示するプログラムを実装するようになって、何か、正しく動かない事
が、頻発してきた。
※実際は、以前から、あったのだが、何かの拍子に直ったりする為、原因を究明
出来ないでいた。
よくよく調べると、最適化オプション「-Os」を使う場合に、起こる事がある事が
判った。
-O1、-O2 では発生しない為、とりあえず、-O2 を使っていたのだが、プログラム
の容量が増してくると、そうもいかなくなってくる。

そこで、コードを簡単に追ってみると、スタック領域に配置された変数にアクセス
する場合に、スタックのアドレス計算を間違っているような挙動だった。

これは、コンパイラの問題のように思うが、ＲＬ７８のコード生成部分を追って、
修正するには、スキルと時間が足りないように思う。
それと、コンパイラのバグと思っていた事が、実際には、実装の問題である事は、
良くある話でもある。
そこで、回避策を色々試してみた結果、コンパイラオプション「-flto」を追加す
る事で回避出来ているように思う。

詳細に調べた結果、ＲＡＭの初期状態に依存していただけだった。
通常「.bss」セクションは「０」クリアするが、「.data」セクションは、何かの
値をロードするので、そのままな状態になっている、これが、問題のようで、
ロードしない場所は「０」クリアする必要がある。
そこで、リセット時、全てのＲＡＭを全て「０」クリアするコードを追加した。

;; clear all RAM
    sel     rb0    ; bank 0
    movw    hl, #__datastart
LC0:
    movw    ax, #0
    movw    [hl], ax
    incw    hl
    incw    hl
    movw    ax, hl
    cmpw    ax, #__stack
    bnz	    $LC0

※レジスタ・バンクは触らない。
この変更で、怪しい挙動は、無くなったようではある。

ただ、コンパイラを作りなおす必要がある。
コンパイラは作り直さなくても大丈夫と判った、でも、4.9.4 の方が、ほんの
少しは、最適化が良いのかもしれないので、4.9.4 にするのはやぶさかでは無い。

※最近、gcc-4.9.3 から、gcc-4.9.4 に移ったので、その過程で、ビルドオプシ
ョンを精査した。

--enable-multilib --enable-lto

を追加する。
※「multilib」は以前は「disable」であったが一応「enable」とした。

「-flto」は、LTO(Link Time Optimization)を有効にするオプションで、これによ
り翻訳単位を超えた最適化が可能になる。
これは、gcc-4.8.x から、追加された機能のようだが、RL78 と、gcc-4.9.4 の場
合は、常に「有効」にする必要があるのかもしれない。
※指定しないと、「有効」になっているようである。

とりあえず、現状で、これで回避できているようではある・・・