Ｉ２Ｃの実装が、まともになったので、タッチパネルの操作を反映して、ファイラー
にも対応した。
これで、画面タッチでファイルを選択して、音楽を再生するガジェットがまともにな
った。

また、曲の再生では、一時停止や、次の曲などをタッチ操作対応にした。

本来ボタンを描画して、ＧＵＩで操作させるべきなのかもしれないが、それは、又後
で考える。
ＧＵＩに関しては、このボードの正規なサンプルプログラムとして既に公開されている
が（SEGGER）、ＧＵＩのような複雑な動作をＣで書くのは、自分的にはありえない。
また、ＧＵＩの見た目や、操作の動作をエミュレーションする環境も必要な事を考える
と、少し複雑なＧＵＩを作ろうとすると、この環境だけではかなり厳しいと思う。

以前に実装したリソースとして、Windows、OS-X で動作する Open-GL ベースの GUI
フレームワークがあるので、それをマイコン用にダイエットしてポートする予定でいる。
その時に、ＰＣ上で、見た目やリソースを作成するアプリなども作る予定でいる。
※その前にＤＲＷ２Ｄのエンジンを何とかしないと駄目なんだけど・・・
※ＤＲＷ２Ｄエンジンの操作は、他のデバイスとは異なっていて、ライブラリーで提供
される、また、このエンジンに関係すると思われるレジスター群は、読み出し専用か、
書き込み専用レジスターとなっており、詳しい説明は省略され、ライブライーを使う事
を前提としている。

話がそれたが、オーディオプレイヤーのタッチ操作は以下のようになっている。
- ３点タッチ（離れた時）で、ファイラーが有効になる。
- 上下のドラッグで、ファイルフォーカス
- 右ドラッグでファイル選択（ディレクトリーの場合、そのディレクトリーへ移動）
- 左ドラッグで、一つ手前のディレクトリーへ移動
- 再生中、右へドラッグで次の曲
- 再生中、左へドラッグでリプレイ
- 再生中、２点タッチ（離れた時）で一時停止
- 再生中、３点タッチ（離れた時）で再生中断
- 再生中は、曲の再生が終了したら、次の曲を再生

現在、ＭＰ３、ＷＡＶ形式のファイルをサポートしてあり、タグの表示にも対応してい
る。
タグは、ＩＤ３Ｖ２に対応しているが、Ｖ１タグは過去の物であり、あっても無視され
る。
タグは、曲名、タイトル、アーティスト、トラック、リリース日付、などの対応になっ
ている。
※ＷＡＶ形式のタグも同じように対応している。

ジャケット画像をサポートする予定で、ＪＰＥＧライブラリーをＲＸ用にポートしたが、
一般的な方法では、メモリ不足で、デコードする事が出来ないので、こちらはそのうち
対応する事にする。（多分、一時メモリを使わず、直接フレームバッファに描画するよ
うにすれば可能なハズだが、リアルタイムにスケーリングもする必要があり、少しハー
ドルが高い）

オーディオ出力は、ＲＸ６５ＮのＤＡ０、ＤＡ１から出力する（量子化は１２ビットだ
が）、無音は、３．３ＶとＧＮＤの中間電圧、１．６５Ｖとなっている。
バイパスコンデンサと抵抗だけで直にラインに繋げるのは心苦しいので、自分は以下の
回路を組んでいる。


※アンプの参考回路（以前にＲＬ７８で実装したＷＡＶプレイヤーのもの）

量子化は１２ビットだが、自分の耳では、そんなに悪い音に感じない。
※ブラインドテストで１６ビットとの違いを聞き分けるのは難しいと思う。

現在ＤＭＡＣでＤ／Ａに出力している部分をＲＳＰＩに変更して、多少改造すれば、外
部Ｄ／Ａで鳴らせると思う。（いずれ、それも対応する予定でいる）
※ＳＣＩを使った簡易ＳＰＩだと、クロックを高速に出来ないので難しいかもしれない。
ＲＸ６４Ｍだと、Ｉ２Ｓインターフェースがあるので、もっと簡単なのだが・・・
※自作音楽プレイヤーを前から作りたかったので、丁度良い。

GitHub AUDIO sample

ＳＣＩで簡易Ｉ２Ｃを実装している。

前回、ポーリングによる実装を行い、動作する事を確認した。
動作周波数が遅いＣＰＵなら、それでも良いのだが、１２０ＭＨｚで動作するＲＸマイコン
だと、話が変わってくる。
さすがに、１００ＫＢＰＳ程度の通信速度をポーリングで行うのは、マシンサイクルを無駄
に消費してしまうので、許容できないと思う。
そこで、割り込み処理にするのだが、ＲＸマイコンで、Ｉ２Ｃを本格的に扱うのは今回が初
めてとも言えるので、あまりよく考えていなかった。
※ＩＩＣＡの専用インターフェースの実装も、いまだにポーリングのみの実装になっている。
これもそのうち手を入れないといけない・・・

ＳＣＩの簡易Ｉ２Ｃでは、ＳＴＩ（Ｉ２Ｃアクノリッジ待ち）で、送信終了割り込みを使う
のだが、「sci.hpp」に定義をしていない。
定義を追加するのに、しばし問題があった、送信終了割り込みは、グループ割り込みとなっ
ていて、ＳＣＩのチャネルによってグループが異なっていたり、ＲＸ６４ＭとＲＸ６５Ｎで
異なっていたりと、場合別けをしなければならない・・

グループベクターは、icu.hpp に定義をしているが、グループが異なると、全く別の型とな
るので、そのままでは、定義が出来ない。
そこで、SCI の基底クラスを継承させ、チャネルでグループが異なる場合を別けて実装する
ように修正した。

ＳＣＩ定義：

typedef scig_t<0x0008A000, peripheral::SCI0, ICU::VECTOR::TXI0, ICU::VECTOR::RXI0, ICU::VECTOR_BL0::TEI0> SCI0;

 typedef scig2_t<0x0008A100, peripheral::SCI8, ICU::VECTOR::TXI8, ICU::VECTOR::RXI8, ICU::VECTOR_BL1::TEI8> SCI8;

※SCI1 の TE0 はグループ BL0 だが、SCI8 はグループ BL1 になっている。

クラス定義：

template <uint32_t base, peripheral t, ICU::VECTOR txv, ICU::VECTOR rxv, ICU::VECTOR_BL0 tev> struct scig_t : sci_t {

};

template <uint32_t base, peripheral per, ICU::VECTOR txv, ICU::VECTOR rxv, ICU::VECTOR_BL1 tev> struct scig2_t : sci_t {

};

※基底クラス sci_t は、そのままに、グループ別に異なったクラスを定義した。

また、SCI を使った簡易 I2C は、SCI の制御と根本的に異なるので、純粋な SCI の制御と
クラスを別け、新規に「sci_i2c_io.hpp」とした。
※ＲＸマイコンのソースコードは、第三者を交えたレビューを行っていないので、意外と、
基本的な部分に問題がある事が多い・・・
※多分、コードレビューを行うと、かなり厳しく突っ込みを入れられる部分があるものと思
う、コードレビューを経験した人なら解ると思うが、最初は、厳しい駄目だしをされると、
不快に思ってしまう、だが、人間「慣れ」るもので、回数を重ねると、ありがたく思うよう
になり、真摯に助言を受け入れる度量と分析力が育つ。

よく、趣味でマイコンをやっている人で、コードが汚いので公開をしない人がいるが、他の
人に添削してもらえる可能性があるのなら、是非自分のコードを見てもらい、正しい道に修
正してもらった方が良い。（くれぐれも、指摘された事を自分に対する「否定」と思わない
事、冷静に何が最善なのかを考える事）
プロジェクトだと、他人に駄目だしされる事を不快に思う人種はいて、リーダーの手腕が重
要となるのだが・・

ポーリング動作で、全体の見通しがついていたので、割り込み動作に関しては、それなりに
順調に実装できた。
ＦＴ５２０６、Ｉ２Ｃの定義は以下のように行う。
※ＦＴ５２０６のリセットを制御するので、ポートを定義。

// FT5206, SCI6 簡易 I2C 定義
typedef device::PORT<device::PORT0, device::bitpos::B7> FT5206_RESET;
typedef utils::fixed_fifo<uint8_t, 64> RECV6_BUFF;
typedef utils::fixed_fifo<uint8_t, 64> SEND6_BUFF;
typedef device::sci_i2c_io<device::SCI6, RECV6_BUFF, SEND6_BUFF, device::port_map::option::FIRST_I2C> FT5206_I2C;
FT5206_I2C  ft5206_i2c_;
typedef chip::FT5206<FT5206_I2C> FT5206;

割り込みで処理するのは簡単で、以下のように、Ｉ２Ｃのインスタンスを起動する時に、割
り込みレベルを設定するだけで良い。（ポーリングの場合は「０」を設定）

{  // FT5206 touch screen controller
    FT5206::reset<FT5206_RESET>();
    uint8_t intr_lvl = 1;
    if(!ft5206_i2c_.start(FT5206_I2C::SPEED::STANDARD, intr_lvl)) {
        utils::format("FT5206 I2C Start Fail...\n");
    }
    if(!ft5206_.start()) {
        utils::format("FT5206 Start Fail...\n");
    }
}

割り込みでは、データ転送が非同期になるので、同期を行うメソッドを追加し、非同期にデ
ータが来ても誤動作しないように、ＦＴ５２０６の実装も見直した。

sci_i2c_io.hpp
FT5206.hpp

ファイラーがそれなりに動くようになったので、オーディオプレイヤーを更新、
ＰＣＭファイルのサポートも追加した。

操作は、ファミコンパッドで行うのだが、もうそろそろ、タッチスクリーンを有効
にしないと駄目な感じだ・・・
タッチスクリーンで使用しているＩＣはＦＴ５２０６という物らしい。

Ｉ２Ｃは、専用ポートしか考えていなかったので、専用のドライバーが既に動作し
ているが、ＦＴ５２０６はＳＣＩ６に接続されている。
なので、ＳＣＩの簡易Ｉ２Ｃを実装するしかない。
一応、ハードウェアーマニュアルを見て、実装してみたけど動作しない・・・
※ルネサス提供のドライバーは設定が面倒で、使いたくないし、読みにくいので参
考にするのも億劫だ。

割り込みでやるのは、設定が複雑になり、ハードルが高いと思ったので、とりあえ
ずポーリングでやってみたが、どうにも動作しない。
波形を見たいところだが、このボードでは、プローブを接続するのが難しいので、
他のボードで確認してみる事にしようか・・・
と思ったけど、ソフトＩ２Ｃで動作の確認だけしてみたー
動いたー（当たり前だけど）
※最初、動かないなぁーって思ったけど、とあるレジスターの応答が自分が思って
たのと違うだけで、ちゃんと動作してた（最近、こんな、早とちり的な事が多い）

ソフトＩ２Ｃで動作し、ＦＴ５２０６のマネージメントもそれなりになったので、
ＳＣＩの簡易Ｉ２Ｃをもう一度詳細に確認。
どうも、ポーリングの場合、受信動作は問題無いが、送信動作では、送信レジスタ
ーがバッファされているので、フラグを見る場合は、多少の工夫が必要な事が判っ
た。

while(SCI::SSR.TDRE() == 0) {
    sleep_();
}
while(SCI::SSR.TEND() == 0) {
    sleep_();
}

それを修正して動作するのかと思ったが、受信動作がどうも、うまくない・・・
よくよくレジスターのダンプを見ると、１バイトずれて読めてるような・・・
ルネサスのハードウェアーマニュアルの説明に沿って実装したものの、どうやら
本家の説明に間違いがあるようだー、ＳＣＩをＩ２Ｃとして使う場合、送信と受
信は連結されている、Ｉ２Ｃのスレーブアドレスを送信後に、受信レジスタを空
読みしないと、スレーブアドレスが残っている。

SCI::TDR = (adr << 1) | 1;  // R/W = 1 (read)
while(SCI::SSR.TDRE() == 0) {
    sleep_();
}
while(SCI::SSR.TEND() == 0) {
    sleep_();
}
volatile uint8_t tmp = SCI::RDR();  // ダミーリード

if(SCI::SISR.IICACKR() != 0) {
    utils::format("I2C Recv: Ack fail...\n");
    i2c_stop_();
    return false;
}

空読みするコードを追加したら正しく受信動作した、ヤレヤレ。

Ｉ２Ｃのドライバーは、全体的に考え直す必要のあるデバイスだ（ＳＰＩもそうだ
が・・）特に１２０ＭＨｚで動作しているプロセッサの場合は、ポーリングでデー
タを取得するような低速ドライバーは問題外と思う。（もったいない）
ただ、デバイスによって、通信の手順が色々なので、単純に割り込みにしただけで
は駄目で、柔軟性のある機能を提供する必要がある。
また、手順が面倒で、新規のＩ２Ｃデバイスドライバーを実装する手間が大変だと、
それはそれで、痛いので、よくよく考えて、全体を設計しておく必要がある。

とりあえず、受信と送信データはバッファリングして、それぞれの終了で設定した
コールバックを呼び出すようにすれば良さそうだ。

割り込み対応のＩ２Ｃドライバーは、次の機会に紹介する。

ソフトＩ２Ｃドライバー
SCI/I2C ドライバー
タッチスクリーンテストサンプル

-----
C++ に関するコラム：
C++ で C のキャストを使う人が多い・・・
以前に理由を聞いたら「冗長」だからーとか言ってた人がいるが、機能が違うので、
そんな理由で、使っては駄目だ。
前提として、キャストは、なるべく使わないように設計する必要がある。
「const」を取り除くような方法もいけない。
C 言語ベースの人はこの辺りを全く気にしない人が多いので困る。

文字表示が出来たところで、基本中の基本、ファイル選択を実装してみた。

「ファイル選択」は、ＮＥＳエミュレーター、オーディオプレイヤーなど、
使用頻度が高いものなので、汎用性を高く実装する必要がある。

C++ の使いどころの一つに「テンプレート」がある。
C++ を始めたばかりの時は、テンプレートは難解で、とっつきにくく、敬遠
していた事や、簡単なシンプルなものに限られていたものの、馴れてくると、
利用範囲が広がり、最近は、テンプレート無しではプログラムが作れなくな
っている。
・便利すぎて、Ｃでプログラムする気がおきなくなる。

C++ の良いところは「型」に忠実である点がある。
但し、「より厳密な方法で実装」していない場合、細かいエラーが出て、先
に進めない。
この辺りは経験的な部分が大きいものの、反復する事で、考えなくても自然
に厳密な書き方が行えるようになると思う。
※Arduino のスケッチが駄目だと思うのは、C++ なのに、未だに「#define」
を多様していたり、C++11 以降の構文を使っていない部分、そんなスケッチ
が氾濫している。（動けば良いという考え方は良くないと思う）
※及第点を付けられるような、見本になるソースコードが少ないと思う。

※テンプレートプログラムの推薦書籍

使い始め、エラーが出た時に、そのエラーの意味や解消法、どうしてエラー
になるのかなど、意味不明が続くが、エラーが出なくなるまで、より簡単で
シンプルな構造にして、エラーの原因を見極めると、より複雑な構造に対処
できるようになる。
ネットにあるサンプルプログラムは、ある程度参考になるが、コピーペース
トだけでは限界がある、自分で考えて、実装する必要があると思う。
また、boost などの便利なテンプレートや STL を利用したいところでもある
が、メモリーの少ないマイコンでは、それも使える場合と使えない場合があり、
やはり、その場合は自分で何とかするしかない。
独学で勉強するには限界があると思える、勉強会などに参加して、誰かに習う
のが、やはり習得するには必要かと思える。
※この辺り、ある程度Ｃなどでプログラムが組める人には大きなハードルなの
かと思う。

今回のファイラーは、ＳＤカードの操作クラス（SDC）、グラフィックス描画
クラス（RDR）の型が必要なので、テンプレートとなっている。

template <class SDC, class RDR>
class filer {

    SDC&    sdc_;
    RDR&    rdr_;

 public:
    filer(SDC& sdc, RDR& rdr) noexcept : sdc_(sdc), rdr_(rdr),
        ctrl_(0), open_(false),
        rdr_st_(rdr_)
    { }

...
};

これらクラスは、参照のコピーを内部に置いておくので、コンストラクター
で参照を渡す必要がある。

    typedef utils::sdc_man SDC;
    SDC     sdc_;

    typedef graphics::font8x16 AFONT;
    typedef graphics::kfont<16, 16, 32> KFONT;
    KFONT   kfont_;

    typedef graphics::render<uint16_t, 480, 272, AFONT, KFONT> RENDER;
    RENDER      render_(reinterpret_cast(0x00000000), kfont_);

    typedef graphics::filer<SDC, RENDER> FILER;
    FILER    filer_(sdc_, render_);

上記のように、型の定義が複雑なので、途中に反故があると、コンパイルは全く
機能しない、その場合に出るエラーは「意味不明」な場合が多く、対処にはコツ
が必要となる場合が多い。

「graphics::render」クラスは、ピクセルの型「uint16_t」、横幅、高さ、アス
キーフォント、漢字フォントをテンプレートパラメーターとしている。
又、コンストラクターでは、フレームバッファのアドレス、漢字フォントクラス
の参照を渡す必要がある。
「graphics::kfont」クラスは、フォントサイズと、フォントキャッシュの数を
テンプレートパラメーターとしている。

※ディレクトリーは青で表示される、又、左端に「/」を表示している、通常は
右終端に表示すべきであるが、ディレクトリー名が長い場合に、画面の外に表示
されてしまう為。
上下スクロールはできるが、左右スクロール機能は無いので、画面に表示しきれ
ない場合がある。
また、操作はファミコンパッドで操作するようになっている、今後画面タッチで
も操作出来るようにする予定。

if(chip::on(data, chip::FAMIPAD_ST::UP)) {
    graphics::set(graphics::filer_ctrl::UP, ctrl);
}
if(chip::on(data, chip::FAMIPAD_ST::DOWN)) {
    graphics::set(graphics::filer_ctrl::DOWN, ctrl);
}
if(chip::on(data, chip::FAMIPAD_ST::LEFT)) {
    graphics::set(graphics::filer_ctrl::BACK, ctrl);
}
if(chip::on(data, chip::FAMIPAD_ST::RIGHT)) {
    graphics::set(graphics::filer_ctrl::SELECT, ctrl);
}

ファイラーの制御は、制御ビットで行うので、上記のようにファミコンパッドの
操作をファイラーの制御ビットに変換している。

-----
漢字フォントのビットマップデータは、２５０Ｋ程あるので、現在は、ＳＤカード
上に置いて、キャッシュ機構を設けてあるのだが、ＲＸ６５Ｎの場合、２Ｍバイト
のプログラムフラッシュがあるので、そこに置いても良いと思い、rx-elf-objcopy
を使い、「kfont16.bin」をオブジェクトに変換してアクセスしてみた。
しかしながら、何故か、fread 関数が正常動作しなくなった・・・
原因に思い当たる部分がなく、とりあえず、ＳＤカード上に置くようにしてある。

「ENVISION KIT-RX65N」の液晶は４８０×２７２サイズもある。
これだけ大きいと、フォントもある程度の大きさが必要だ。

以前は、１２８×６４の白黒液晶用として、６×１２、１２×１２のフォントを使っていたが、４８０×２７２の液晶には小さすぎなので、８×１６、１６×１６のフォントを用意した。
※８ｘ１２アスキーフォントは自分でデザインしたもの、１２×１２は東雲１２。

用意したのは、「東雲（しののめ）１６」フォントで、フリーなビットマップフォントとして知名度が高い。
ただ、ＢＤＦ形式で配布されている為、組み込み系で使うには、何らかの加工が必要となる。
これらの目的で、「ｂｍｃ」（ビットマップコンバーター）を公開しているが、コンパイルするには、MSYS2 に色々とツールをインストールしなければならない為、ハードルが高いかもしれない。
※コンパイルの方法は、GitHub のREADME を参照。
※「bmc」は基本、コマンドラインだが、「-pre」オプションを付けるとプレビュー表示できる。

変換は以下のように行う。
(1) 「東雲１６フォント」をダウンロード
(2) ASCII フォントのテキストへの変換：

./bmc -bdf -text fonts/japanese-bitmap-fonts-0.4.5/shinonome16/shnm8x16a.bdf fonts.txt

(3) 漢字フォントのバイナリー変換：

./bmc -bdf fonts/japanese-bitmap-fonts-0.4.5/shinonome16/shnmk16.bdf kfont.bin

変換したバイナリーコードへのアクセスは以下のコードを使って行える。

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;
}

※返った値は正規化されているので、１６×１６フォントなら３２倍すれば、アドレスを得る事が出来る。
※-1（0xffff）が返った場合は範囲外のコード

アスキーフォントは、容量も大きく無いので、コード上に展開しているものの、漢字フォントは１６ピクセルだと２５５Ｋもあるので、ＳＤカード上に置き、キャッシュしながら描画するようにしている。
※将来的には、ボード上の EEPROM（３２Ｍバイト）に置いておくのが良いだろう。
また、fatfs には、SJIS と UTF-16 の変換テーブルを内臓しているので、通常のコード体系は UTF-8 を使って統一している。
※昨今、SJIS のコード体系を使うのは色々な意味で痛い。

しかしながら、漢字フォントを扱うには SJIS コードの方が、都合が良い部分もある、SJIS だと、フォントをリニアに並べて、アクセスしやすい特性がある。
SJIS のコードを正規化して、簡単に目的のアドレスを計算出来る。
※これが UTF-16 とかだと、広範囲に散っているので、難しい。

とりあえず、東雲１６フォントを SJIS 並びにしてまとめたバイナリーファイルを用意してあり、アスキーフォントは、ソースコードに直接展開してある。
※これらは、GitHub にプッシュ済み。

漢字フォントは、テンプレートライブラリになっていて、「typedef」する必要がある。

 typedef graphics::kfont<16, 16, 64> KFONT;
    KFONT       kfont_;

※「64」は、キャッシュ数

現在、フォントの描画はソフトで行っているが、RX65N の場合、将来的には、drw2d を使う事になると思うが、ソフトの描画は簡単（速度を気にしなければ）なので、一応必要そうな物をまとめてある。

    typedef graphics::font8x16 AFONT;
    typedef graphics::kfont<16, 16, 64> KFONT;
    KFONT       kfont_;

    typedef graphics::base<uint16_t, 480,="" 272,="" afont,="" kfont=""> GRAPH;
    GRAPH       graph_(reinterpret_cast<uint16_t*>(0x00000000), kfont_);</uint16_t*></uint16_t,>

ＲＸマイコン・グラフィックス関係

アスキーフォントは、ビットマップの実態が必要なので、必要なフォントのソースをリンクする必要がある。
アスキーフォントも「東雲１６」だが、プロポーショナル表示用に幅テーブルを用意してあり、それなりに表示出来る。
ただ、元々「等幅」用にデザインされているので、幅の調整は、
「I: -1, i: -2, l: -2」
だけになっているが、無いよりは「マシ」だと思える。

Renesas ENVISION KIT-RX65N 漢字表示サンプル

最近はＥＳＰ３２のＭ５Ｓｔａｃｋが流行っているようですがー、日本人なら、
ルネサスの「ＥＮＶＩＳＩＯＮ ＫＩＴ－ＲＸ６５Ｎ」 ですよ！

Space Invaders は、元々、モノクロで、８０８０の２ＭＨｚくらいのシンプルなハード
なので、まぁ動くと思っていたが、nesemu は、カラーで、スプライトや、ＢＧなど、
ＣＰＵ（６５０２、１．７ＭＨｚ）以外にも、かなり多くのハードウェアーをエミュレ
ーションする必要があるので、正直、普通に動作するとは思っていなかったが、駄目元
で、一応動作テストをしてみた。

-----

以前に、ＥＳＰ３２をやろうと思い、ソースコードのアーカイブを観ていたら、nesemu
のコードがあり、興味を持った。
とりあえず、nesemu 部分のソースを取ってきて、実験的に、Windows 上の OpenGL 環境
で動作試験を行った。
※その過程で、nesemu 関係のコードで、ポーティングに不都合な部分を色々修正した。
当然ながら、Windows 環境では問題無く動作するようになり、ＯＳ－Ｘでも試したが、
どうにも、サウンドストリームを適切に流す事ができず（ノイズが入る）に、中途な状
態で放置してあった。

nesemu のソースはＣなので、丸ごと持ってきて、追加してコンパイルが通るまでは直ぐ
出来た、また、カラーテーブル付インデックスカラーを、ＲＸ６５Ｎのフレームバッファ
にレンダリングする部分も一瞬で出来たが、動作するにはそこそこの時間が必要だった。
その過程で、ＰＯＳＩＸのファイル操作関数にバグがある事が判り、修正したら、直ぐ
に走る事が判った。
※ファイルのシーク関数のステート判定に誤りがあった。

前から判っていた事ではあるが、ＳＴＬを使うと、非常に多くのメモリーを消費する。
「vector だけならまぁいいか」と思っていたが、実際には、vector を使うには、他の
クラスも必要で、何だかんだ１００Ｋ近くのＲＡＭを消費して、ＲＯＭも２５０Ｋ程余
分に消費する・・・
※Ｉ／Ｏストリームなどを入れると５００Ｋ近く消費する・・・
なので、vector を諦め、malloc で実装して、余分なメモリーをダイエットした。

ＲＸ６５Ｎは二つのメモリーブロックがある。
一つは２５６Ｋ（０ｘ００００００００から始まる）、もう一つは３８４Ｋ
（０ｘ８０００００から始まる）、以前は、ＲＸ６４Ｍなどと同等に最初のブロックを
メインメモリにしていた。
ＬＣＤのフレームバッファとして１６ＢＰＰなら２５５Ｋ（４８０×２７２×２）のメモ
リーはどうしても必要なので、これを、先頭の２５６Ｋに割り当て、メインＲＡＭは後
半の３８４Ｋを使うようにリンクローダのスクリプトを修正した。
※この過程で、「start.s」のＲＡＭクリアルーチンにバグがある事が判り修正した。
※ＲＡＭは０番地から始まる前提だった・・・

次に、サウンドのバインドを行った。
ファミコンのサウンドをソフトでエミュレーションするのは、そこそこ大変で、処理負
荷も高くなる。
サウンドのエミュレーションを有効にしたら、処理落ちする・・
また、１ＭビットＲＯＭのカートリッジはメモリー不足で動作しなくなった・・
※これは、サウンド関係でメモリを多く消費する為のようだ・・

            if(nesrom_) {
                apu_process(audio_buf_, audio_len_);
                nes_emulate(1);
            }
// nesemu.hpp の apu_process をコメントアウトすると、１Ｍカットリッジのゲームが走る（音無）

現状のコードでは、Ｄ／Ａ出力用のコードが追加された為１Ｍビットのカートリッジは、
音無でも動作しない。

「処理落ち」を解消する為、一番処理負荷が高そうな部分に見当を付け、最適化してみ
た・・
本来、ファミコンエミュレーターは８ビットのインデックスカラーなので、ＬＣＤコン
トローラーの設定をそうすれば良さそうだが、ドライバーを手直しする必要があり、時
間がかかりそうなので、とりあえず、ビデオのコピー処理を最適化した。
それだけで、サウンドも大体スローダウンする事なく鳴るようになった。

Dragon Quest
GRADIUS

まだ、ソフトの完成度はあまり高く無いが、とりあえず、動作する・・

-----
ファミコンのパッドは、Ｃ－ＭＯＳ４０２１Ｂ、シフトレジスターを使ったもので、
簡単に繋げる。
自分は互換ファミコンのパッドを流用した、５本のコードで接続する。
赤：ＶＣＣ（本来は５Ｖだが、３．３Ｖでも動作する）
黄：ＧＮＤ
青：Ｐ／Ｓ（Ｐ６０に接続）
茶：ＣＬＫ（Ｐ６１に接続）
白：ＯＵＴ（Ｐ６２に接続）
※良く考えたら、ファミコンパッドで使っているＩＣはＣＭＯＳで電流をほとんど消費し
ないと思うので、配線を簡略化する為、ポートから供給する事にしたので、ピンアサイン
を変更。
赤：ＶＣＣ（Ｐ６０に接続）
黄：ＧＮＤ（Ｐ６１に接続）
青：Ｐ／Ｓ（Ｐ６２に接続）
茶：ＣＬＫ（Ｐ６５に接続）
白：ＯＵＴ（Ｐ７３に接続）
※このポートは、ＣＮ２を使う。

-----
将来的には、「.NES」ファイルを選択したり、ステートのセーブなど、必要な GUI を揃
えたりする予定だが、まだ色々パーツ（ソフト）が揃っていない為、少し時間がかかると
思う。
なので、現状、どのように動作させるか、簡単に記しておく。
・ＳＤカードのインターフェースが必要。（ＮＥＳファイルを読み込む為）
・Ｄ／Ａコンバーター出力をアンプに繋ぐ必要がある。（音が欲しいなら）
※ファミコンはモノラルだが、ステレオ出力にしてある。
・ファミコン互換のジョイパッドを接続する必要がある。
・「.ＮＥＳ」ファイルを用意する必要がある。（ぐぐって欲しい）
現在、どのＮＥＳファイルを起動するか、「nesemu.hpp」に直接記述してあるので、それ
を修正する。

void service(void* org, uint32_t xs, uint32_t ys)
{
    if(delay_ > 0) {
        --delay_;
        if(delay_ == 0) {
            open("GALAXIAN.NES");
//          open("GRADIUS.nes");
//          open("DragonQuest_J_fix.nes");
//          open("Dragon_Quest2_fix.nes");
//          open("Solstice_J.nes");
//          open("Zombie.nes");
         }
     }
.
.
.

ソースコード

ずいぶん長い間放置されていたが、最近、ようやくＬＣＤの初期化が出来た。

画像は出ているようだが、「赤」、「青」、「緑」、「白」、「チェッカー」、
「ストライプ」などと、数秒おきに画面が自動で切り替わるナゾ動作が続く。
ＲＸ６５ＮのＧＬＣＤＣ関係の部分を読んでも、この「現象」に対するヒント
は見つけられなかった。
この動作は、ＧＬＣＤＣの何かの機能なのだと思って、それを「ＯＦＦ」にす
る方法をひたすら探したが、それらしい記述はどこにも載っていない。

結局、ＢＧＥＮレジスタを設定したら、このテストモードのような状態を抜け
て、想定した表示が得られた・・・
※ＢＧＥＮレジスタの設定が抜けていただけだった・・・

とりあえず、フレームバッファに適当に書いて、表示してみた。

ちゃんと表示するようだが、ガンマ補正がちゃんとしていない為か発色が少し変
な感じがする。（これは、これから解析するとして・・）
また、ＬＣＤは、そこそこコントラストがあるが、視野角が狭いようだ・・

もっとダイナミックな表示が欲しくなり、スペースインベーダーのエミュレータ
ーを動かしてみた。（あまりにあっさり動作したので拍子抜けだ・・）
このエミュレーターは「side」と言うオープンソースで、８０８０ＣＰＵと、
スペースインベーダーのアーケード基板をエミュレーションするもので、メモリ
ーも、内蔵メモリで足りるので動作の確認に便利だと思う。
※動作には、スペースインベーダーのＲＯＭデータが必要。
・invaders.h, invaders.g, invaders.f, invaders.e (invaders.zip)
今回は、それを、ＳＤカードに書き込んで、ＳＤカードから読み出している。
・inv_roms/
※コンパイルは「-O3」で最適化してある。
・エミュレーションにかかる処理負荷を計測したら、およそ６０％程度を消費し
ているようだ、８０８０、２ＭＨｚ程度でこの負荷は思ったより大きいが、その
気になって最適化すれば、２０％くらいは下げられる感じはある。

現状では、音も無いし、操作も出来ないが、今後、それらを実装したい。
少し苦労したけど、音は鳴るようにした。

YouTube

ソースコードは、GitHubへコミット済み。

-----
このボードは５０００円くらいで買えて、非常に使い勝手が良い、これから、
グラフィックス関係を強化して、色々なガジェットを作ってみたい！

追記：
・ＧＬＣＤＣのＶＰＯＳ割り込みを設定して、画面更新の同期を行った。
・ＬＣＤの表示タイミングを調整して、画面の更新レートを６０Ｈｚ近くにした。
追記：
・ファミコンパッド接続で、操作できるようにした。
※「SELECT」でコイン、「START」１Ｐスタート、左右キー、Ａボタン

動作は確実だろうけど、一応、確認だけしてみた。
※ＬＣＤの動作はまだもう少し・・
※ＳＤカードを使えるようにする必要がある。

「ＥＮＶＩＳＩＯＮ　ＫＩＴ－ＲＸ６５Ｎ」では、Ｄ／Ａ出力は、それぞれ、
ＪｏｙＳｔｉｃｋ、ＳＷ２に接続されているので、仮に配線して音出しの確認
をしてみた。
全く問題なくＭＰ３の再生が出来た。
※将来的には、ＳＰＩ通信とかで１６ビットのＤ／Ａをに出力する予定。

ソースコードは GitHub にプッシュ済み。

このボードは「Ｅ２－Ｌｉｔｅ」オンボードなので、プログラムの書き込みは
多少大きいサイズでも、短い時間で書けるのが良い。（Windows 環境のみだけ
ど・・）

Ｄ／Ａ出力には、オペアンプによるボルテージフォロワを入れてある、３．３Ｖ
の中間の電圧が０Ｖとなっている。
※参考回路
写真の物はＰＷＭ出力のＲＣフィルターが付いているが、まぁ問題無い。

-----
libmad のライセンスは、GPL なので、多少注意が必要と思う。
まぁ、自分のコードはそれより緩いＭＩＴライセンスなので、問題は無いと思
うが・・

ＷＡＶファイルの再生は出来た、しかしこれは当たり前すぎて、面白みが無い。

既に、ＲＸマイコンでＭＰ３ファイルの再生は実装した人がいたと思うのだが、
自分も確認の意味も含めて、実験してみた。

ＭＰ３のデコードには、libmad ライブラリを使う（これも先人と同じ）。
このライブラリ、かなり低負荷でＭＰ３のデコードが出来るので、色々なプラ
ットホームで使われている。
※凄く昔に、ｉ４８６ＤＸ１００とかで、ＭＰ３をデコードするのがカツカツだ
ったように思う、それから考えると、ワンチップマイコンでデコードできるのは
かなり画期的な事だと思う。

ＤＭＡＣの制限により、１０２４ワード以上のバッファを転送するには別の工夫
が必要な事から、ＭＰ３デコーダーとＤ／Ａのバッファの間にもう一つバッファ
を設ける事にした。
※そうしないと、ＭＰ３デコード処理の遅延により、バッファオーバーランが発
生して、再生が途切れてしまう。
それ以前に、１２０ＭＨｚのＲＸマイコンで、ＭＰ３をデコードした場合の処理
負荷を検証してみる。
ＭＰ３デコーダーにＭＰ３ファイルを食わせて、回してみた、約４分くらいのフ
ァイルを１／２くらいの時間でデコードした、これなら、十分実用になる。
ただ、ビットレートやＭＰ３をエンコードした条件により、処理負荷はかなり変
動するので、その変動時間を吸収できる量のバッファが必要と思われる。
簡単な実験では４０９６ワードでオーバーランが微妙に発生する感じなので、倍
の８１９２ワード設けるようにした。
※色々な曲を再生して聴いていたら、それでも怪しいファイルがあったので、さ
らに倍にした。

ＭＰ３の別の問題として、タグの問題がある。
ＭＰ３のタグは、ＩＤ３Ｖ１、ＩＤ３Ｖ２など複数のフォーマットがあり、ファ
イルの先頭にある場合（Ｖ２、可変長）、ファイルの終端にある場合（Ｖ１、固
定長）、バージョンの違い、文字コードの種類など、かなり面倒な仕様となって
いる、オープンソースのタグのパーサーはいくつかあるのだが、組み込みマイコ
ンのような少メモリの設計では無いのが痛い、結局は、「車輪の再発明」となる。

libmad はタグには感知しないので、もしＩＤ３Ｖ２タグが先頭にある場合、デコ
ーダーに食わせる前に、タグを見つけ出して、その部分を飛ばす必要がある。
以前にＯｐｅｎＧＬのアプリで音楽プレイヤーを作った経験があり、その時に、
ＭＰ３のＩＤ３タグを色々とサポートした、その時は、libtag を利用したが、
やはり、組み込みマイコンにポートするには大掛かり過ぎる。
※とりあえず、ＩＤ３Ｖ２を見つけて、スキップするだけの実装を行った。
内部のフレームをパースするのは、暇なときにでも進める事とする・・

残念と思うのは、ＲＡＭの使用量が意外と大きい（現在８１Ｋくらい）ので、
ＲＸ６２１、ＲＸ６２ＮなどのＲＡＭが少ない（確か６４Ｋ）マイコンでは使え
ないと思う。（外部メモリーを実装すれば問題無いだろうか）
※プログラムサイズは、２８０Ｋ程度。
※gcc-6.4.0

-----
☆　自作ＲＸ６４Ｍボード

☆　ＧＲ－ＫＡＥＤＥ

自作のＲＸ６４Ｍボードは、プログラムの書き込みをシリアル経由で行う為、
３６０Ｋのプログラムを書くのがかなり遅い、Ｅ１を持っている（借り物だけど）
のだから、Ｊ－ＴＡＧインターフェースを配線した方が良さそうだ・・・

必要なソースコードは、GitHub にプッシュしてある。
※libmad は、gcc-6.4.0 でコンパイル、ライブラリとヘッダーを上げてある。

ＤＭＡＣを使い、Ｄ／Ａ出力に気を良くして、ＷＡＶファイルの再生も行って
みた。

以前にＲＬ７８／Ｇ１３を使い、８ビットＰＷＭ変調を使った、ＷＡＶファイ
ルの再生を行った事があり、その時のリソースを使ったので、とても簡単だっ
た。
ＲＸ６４ＭはＲＬ７８／Ｇ１３より桁違いに強力なので、処理負荷的には全く
問題無い。

ＳＤカードの読み込みは、ＳＤＨＩのポートに接続しているけれども、ＳＤＨ
Ｉの無いＲＸマイコンなので、ソフトＳＰＩで読み込みをしている、イマイチ
パフォーマンスが悪い（読み込み速度が遅い）が、それでも、１２０ＭＨｚ動
作は伊達ではない。

各種サンプルレートに対しては、単純にサンプリングレートを変化させて行っ
た。
ＲＸ６４Ｍにはサンプリングレート変換のハードウェアーがあるのだが、ＲＸ
６５Ｎには無いので、それも踏まえている。
※ＲＴＫ５＿ＲＸ６５Ｎでオーディオプレイヤーを作るのが本命。

ＤＭＡＣのトリガーとなる、ＴＰＵタイマーのクロック（６０ＭＨｚ）では、
４４．１ＫＨｚは割り切れないので正確ではない。（４４．１１８ＫＨｚ）
※４８ＫＨｚは割り切れるので、正確なタイムベースとなっていると思う。
※２２．０５ＫＨｚや３８ＫＨｚもやはり割り切れないので正確では無い。
まぁ、１２ビットのＤ／Ａを使った簡易再生なので、多少の事は妥協する。
それでも、聴いた感じは、そんなに悪くは無い。（８ビットのＰＷＭでもかな
り良い音がする事に驚く）
４４．１ＫＨｚを４８ＫＨｚにアップコンバートするのは、簡易的な方法なら
そんなに難しく無いので、４４．１から４８へソフトでアップコンバートする
のでも良いかもしれない。

コンソールのコマンドは
・dir
・cd [directory]
・pwd
・play file-name
・help

「play *」で、ディレクトリーの WAV ファイルを順番に再生する。
※ＷＡＶ形式では無いファイルは無視する。

再生が始まる時、コンソールにヘッダー情報を表示し、時間経過をコンソール
に出力する。

ISFT: Lavf57.3.100
File:  '03 愛Dee.wav'
Size:   50807808
Rate:   44100
Chanel: 2
Bits:   16
Time:   00:04:48
00:04:47

IART: minato (流星P) Feat. 初音ミク
ICRD: 2010
IGNR: Pop
INAM: FAIRYLAND -mintia mix-
IPRD: magnet -favorites plus-
IPRT: 4/15
ISFT: Lavf57.3.100
ITCH: iTunes 9.0.2.25
File:  '04 FAIRYLAND -mintia mix-.wav'
Size:   39518208
Rate:   44100
Chanel: 2
Bits:   16
Time:   00:03:44
00:01:27

再生中は、
・「Space」：一時停止
・「>」：次の曲
・「<」：曲の先頭
で、プレイヤーを制御できる。

ＷＡＶファイルは、４８ＫＨｚ、４４．１ＫＨｚ、３８ＫＨｚ、２２．０５ＫＨｚ、
８、１６ビット、モノラル、ステレオのＰＣＭ形式ファイルに対応する。
※８ビットやモノラルはあまり実験していないので不具合があるかもしれない。
※ＧＲ－ＫＡＥＤＥでも簡単な修正で動かす事ができる、方法を知りたい場合
は、コメント欄にどうぞ。
※ＧＲ－ＫＡＥＤＥは、ＳＤカードのハードウェアーに致命的な問題がある、
回避方法はあるのだが・・
「main.cpp」で、「GR_KAEDE」を有効にしてコンパイルすれば、GR-KAEDE でも
動作すると思うが、いくつか問題がある。
・ＳＤカードのハードウェアー「ＤＯ」端子のプルダウン問題を回避する必要がある。
※色々な解決策があると思うが、「main.cpp」に具体的な回避策を載せてあるので参考
にして下さい。
・Ｄ／Ａ出力０がＬＥＤ４に接続されているので、ジャンパーを飛ばす必要がある。

GitHub AUDIO Player