まだあった、こんな初歩的なバグ・・・

以下のコードは、「format.hpp」にある、二進表記関数だ。
しかし、致命的なバグがある・・

void out_bin_(int32_t v) {
    char* p = &buff_[sizeof(buff_) - 1];
    *p = 0;
    uint8_t n = 0;
    do {
        --p;
        *p = (v & 1) + '0';
        v >>= 1;
        ++n;
    } while(v != 0) ;
    out_str_(p, 0, n);
}

バグの存在に気がついただろうか?

引数「v」が「負」の場合、「v」の右シフトは、符号が消えない為、「0」判定が正常
に機能しない為無限ループとなり、配列を超えて不正なアクセスが起こる。
※通常、プログラムはクラッシュするだろう・・

void out_bin_(uint32_t v) {

それで、上記のように、関数の引数を「int32_t」から「uint32_t」にすれば解決する。

「format.hpp」は、以前に、かなり広範囲にチェックしていたが、テストケースが抜けて
いた。
十分チェックしたつもりで、頑丈だと思っていたので、こんな危険なバグがあった事はショ
ックだが、仕方ない、よりよいテストを行う事と、危険な橋を避ける必要があるようだ。

format による二進表現は現在まであまり使わなかったので、この大きなバグによる弊害は
無かったが、危ない瞬間だった・・

カテゴリー: ソフトウェアー・エンジニアリング, 電子工作な日々 | コメントする

KIT-RX65N、レイ・トレーサー

ESP32やArduino系で走る「レイ・トレーシング」プログラムがある。

これを、RX65Nで、どのくらいのパフォーマンスなのか知りたくて、ポートしてみた。

元プログラムはC++で書かれたもので、良くできている。
※ソースコードは、ココから拝借したが、多少修正してある。
※ポーティングは極めて簡単だった。
RXマイコンは、浮動小数点の演算には定評があるので、少し期待していた。

結果は7.7秒と、まずまずの値ではある。
※速度比較の為、解像度320×240でレンダリングしている。

コンパイラのバージョン:

rx-elf-gcc (GCC) 6.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

最適化は「O3」

——-

Raytracing with ESP32
上記リンクには、各マイコンのレンダリングにかかる時間が載っている。
ESP32(160MHz)は、13秒みたいなので、それより低速(120MHz)のRXマイコン
はそれなりに優秀なのだと思う。
ただ、「STM32F7 (200MHz) 0.62 秒」に比べると、かなり見劣りする結果かもしれない・・
※クロックを差し引いても、かなり遅い・・・

全ソースは、GitHub にある。

——-
macsbug, cbm80amiga さんありがとう~

追記:
gcc の最適化によってどのくらい違うのかを確認しておいた。
・古い gcc-4.9.4 も確認したかったが、constexpr 関係がコンパイルできずにエラーとなったので、
コンパイラは gcc-6.4.0 のままだ。
・ベンチマークは「目安だ」プログラムの性質により大きく異なる場合が多いし、ほんの少し条件が変
わるだけで、結果が逆転する場合もある。
・ルネサス純正Cコンパイラでも評価したいところだが、環境を揃える事が難しいので、実験をしてい
ないが、ネットの情報を見ると、浮動小数点が多い場合は、gcc の方が優秀な場合があるようだ・・
※コメント欄のリンクを参照

コンパイラ 最適化オプション レンダリング速度 実行サイズ
gcc-6.4.0 -O3 7.7 140568
gcc-6.4.0 -O2 7.7 128180
gcc-6.4.0 -Os 13.2 106584

・O2、O3 でほとんど差が出ないが、バイナリーサイズは多少異なっている。

追記:(2018年、11月3日)
RX65のハードウェアーマニュアルを眺めていたら、RX65にはROMキャッシュ制御ビットがあり、通常「Disable」になっている事が判った。
※「フラッシュメモリ」、「59.3.2 ROM キャッシュ許可レジスタ( ROMCE )」
このビットを有効にして、レンダリングをしてみた、そうすると「6.8秒」と10%くらい速度改善している。
一応、標準で「有効」にするように設定したが、「キャッシュ」有効により、正常動作しない「実装」もあるかもしれないので、少し評価を徹底したい・・
※「volatile」キーワードが適切にあれば問題無いと思う。
※他のプロジェクト(ファミコンエミュレーター、音楽再生など)も確認したが問題ない。

カテゴリー: ソフトウェアー・エンジニアリング, 電子工作な日々 | 5件のコメント

RX65N Envision Kit で実現するオーディオプレイヤー

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

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

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

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

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

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

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

オーディオ出力は、RX65NのDA0、DA1から出力する(量子化は12ビットだ
が)、無音は、3.3VとGNDの中間電圧、1.65Vとなっている。
バイパスコンデンサと抵抗だけで直にラインに繋げるのは心苦しいので、自分は以下の
回路を組んでいる。


※アンプの参考回路(以前にRL78で実装したWAVプレイヤーのもの)

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

現在DMACでD/Aに出力している部分をRSPIに変更して、多少改造すれば、外
部D/Aで鳴らせると思う。(いずれ、それも対応する予定でいる)
※SCIを使った簡易SPIだと、クロックを高速に出来ないので難しいかもしれない。
RX64Mだと、I2Sインターフェースがあるので、もっと簡単なのだが・・・
※自作音楽プレイヤーを前から作りたかったので、丁度良い。

GitHub AUDIO sample

カテゴリー: ソフトウェアー・エンジニアリング, 電子工作な日々 | コメントする

RXマイコンSCIにおける簡易I2Cを実装する

SCIで簡易I2Cを実装している。

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

SCIの簡易I2Cでは、STI(I2Cアクノリッジ待ち)で、送信終了割り込みを使う
のだが、「sci.hpp」に定義をしていない。
定義を追加するのに、しばし問題があった、送信終了割り込みは、グループ割り込みとなっ
ていて、SCIのチャネルによってグループが異なっていたり、RX64MとRX65Nで
異なっていたりと、場合別けをしなければならない・・

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

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」とした。
※RXマイコンのソースコードは、第三者を交えたレビューを行っていないので、意外と、
基本的な部分に問題がある事が多い・・・
※多分、コードレビューを行うと、かなり厳しく突っ込みを入れられる部分があるものと思
う、コードレビューを経験した人なら解ると思うが、最初は、厳しい駄目だしをされると、
不快に思ってしまう、だが、人間「慣れ」るもので、回数を重ねると、ありがたく思うよう
になり、真摯に助言を受け入れる度量と分析力が育つ。

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

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

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

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

{  // 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");
    }
}

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

sci_i2c_io.hpp
FT5206.hpp

カテゴリー: ソフトウェアー・エンジニアリング, 電子工作な日々 | コメントする

KIT-RX65N、AUDIOプレイヤー更新

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

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

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

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

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

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

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

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

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

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

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

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

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

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

カテゴリー: ソフトウェアー・エンジニアリング, 電子工作な日々 | コメントする

KIT-RX65N、ファイラーの実装

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

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

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

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

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

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

今回のファイラーは、SDカードの操作クラス(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);
}

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

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

カテゴリー: ソフトウェアー・エンジニアリング, 電子工作な日々 | コメントする

KIT-RX65N、漢字表示

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

以前は、128×64の白黒液晶用として、6×12、12×12のフォントを使って
いたが、480×272の液晶には小さすぎなので、8×16、16×16のフォント
を用意した。
※8x12アスキーフォントは自分でデザインしたもの、12×12は東雲12。

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

変換は以下のように行う。
(1) 「東雲16フォント」をダウンロード
(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;
}

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

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

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

とりあえず、東雲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 GRAPH;
    GRAPH       graph_(reinterpret_cast(0x00000000), kfont_);

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

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

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

カテゴリー: ソフトウェアー・エンジニアリング, 電子工作な日々 | コメントする

KIT-RX65Nでnesemu(≒ファミコンエミュレーター)の動作に成功

最近はESP32のM5Stackが流行っているようですがー、日本人なら、
ルネサスの「ENVISION KIT-RX65N」 ですよ!

Space Invaders は、元々、モノクロで、8080の2MHzくらいのシンプルなハード
なので、まぁ動くと思っていたが、nesemu は、カラーで、スプライトや、BGなど、
CPU(6502、1.7MHz)以外にも、かなり多くのハードウェアーをエミュレ
ーションする必要があるので、正直、普通に動作するとは思っていなかったが、駄目元
で、一応動作テストをしてみた。

—–

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

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

前から判っていた事ではあるが、STLを使うと、非常に多くのメモリーを消費する。
「vector だけならまぁいいか」と思っていたが、実際には、vector を使うには、他の
クラスも必要で、何だかんだ100K近くのRAMを消費して、ROMも250K程余
分に消費する・・・
※I/Oストリームなどを入れると500K近く消費する・・・
なので、vector を諦め、malloc で実装して、余分なメモリーをダイエットした。

RX65Nは二つのメモリーブロックがある。
一つは256K(0x00000000から始まる)、もう一つは384K
(0x800000から始まる)、以前は、RX64Mなどと同等に最初のブロックを
メインメモリにしていた。
LCDのフレームバッファとして16BPPなら255K(480×272×2)のメモ
リーはどうしても必要なので、これを、先頭の256Kに割り当て、メインRAMは後
半の384Kを使うようにリンクローダのスクリプトを修正した。
※この過程で、「start.s」のRAMクリアルーチンにバグがある事が判り修正した。
※RAMは0番地から始まる前提だった・・・

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

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

現状のコードでは、D/A出力用のコードが追加された為1Mビットのカートリッジは、
音無でも動作しない。

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

Dragon Quest
GRADIUS

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

—–
ファミコンのパッドは、C-MOS4021B、シフトレジスターを使ったもので、
簡単に繋げる。
自分は互換ファミコンのパッドを流用した、5本のコードで接続する。
赤:VCC(本来は5Vだが、3.3Vでも動作する)
黄:GND
青:P/S(P60に接続)
茶:CLK(P61に接続)
白:OUT(P62に接続)

※良く考えたら、ファミコンパッドで使っているICはCMOSで電流をほとんど消費し
ないと思うので、配線を簡略化する為、ポートから供給する事にしたので、ピンアサイン
を変更。
赤:VCC(P60に接続)
黄:GND(P61に接続)
青:P/S(P62に接続)
茶:CLK(P65に接続)
白:OUT(P73に接続)

※このポートは、CN2を使う。

—–
将来的には、「.NES」ファイルを選択したり、ステートのセーブなど、必要な GUI を揃
えたりする予定だが、まだ色々パーツ(ソフト)が揃っていない為、少し時間がかかると
思う。
なので、現状、どのように動作させるか、簡単に記しておく。
・SDカードのインターフェースが必要。(NESファイルを読み込む為)
・D/Aコンバーター出力をアンプに繋ぐ必要がある。(音が欲しいなら)
※ファミコンはモノラルだが、ステレオ出力にしてある。
・ファミコン互換のジョイパッドを接続する必要がある。
・「.NES」ファイルを用意する必要がある。(ぐぐって欲しい)
現在、どのNESファイルを起動するか、「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");
         }
     }
.
.
.

ソースコード

カテゴリー: ソフトウェアー・エンジニアリング, 電子工作な日々 | 2件のコメント

KIT-RX65N、LCDの初期化まで出来た。

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

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

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

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

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

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


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

YouTube

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

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

追記:
・GLCDCのVPOS割り込みを設定して、画面更新の同期を行った。
・LCDの表示タイミングを調整して、画面の更新レートを60Hz近くにした。

追記:
・ファミコンパッド接続で、操作できるようにした。
※「SELECT」でコイン、「START」1Pスタート、左右キー、Aボタン

カテゴリー: ソフトウェアー・エンジニアリング, 電子工作な日々 | コメントする

KIT-RX65NでもMP3再生の確認

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

「ENVISION KIT-RX65N」では、D/A出力は、それぞれ、
JoyStick、SW2に接続されているので、仮に配線して音出しの確認
をしてみた。
全く問題なくMP3の再生が出来た。
※将来的には、SPI通信とかで16ビットのD/Aをに出力する予定。

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

このボードは「E2-Lite」オンボードなので、プログラムの書き込みは
多少大きいサイズでも、短い時間で書けるのが良い。(Windows 環境のみだけ
ど・・)

D/A出力には、オペアンプによるボルテージフォロワを入れてある、3.3V
の中間の電圧が0Vとなっている。
参考回路
写真の物はPWM出力のRCフィルターが付いているが、まぁ問題無い。

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

カテゴリー: ソフトウェアー・エンジニアリング, 電子工作な日々 | コメントする