Just a log

http://www.mediafire.com/download.php?itv4jzzt3dl
http://www.mediafire.com/download.php?jfjminzimmk(src)

gpsp/SDL for ZAURUSをベースにさせていただきました。

なんでスローかというとC言語なCPUを使っているからでして。
ダイナミックリコンパイラを動かそうと、PSPにしかない命令は置き換えたりしたのですが、
キャッシュのクリアが必要だけど、Linuxの通常プログラムは特権じゃないから
cache命令が使えないという。

色々工夫すれば動くようになるのかもしれませんが…。

「Tegraが…Tegraが…」と待っていたのですが、一向に製品化せず、
気がついたら巷では謎の中国製ハイビジョンメディアプレイヤーが続々登場しているので、
どんなものかと、手に入れてみました。
なお、ハードウェアには個体差がある可能性もありますので、参考程度に。
レビュー時のファームウェアは1.4でした。(現在アップデートして1.8に)

* 動作雑感
ファームウェアはdingooのそれと似ています。ChinaChipなメディアプレイヤーです。
CPUの能力はHD動画を再生できるぐらいですから結構あるようで、スムーズに動作します。
タッチパネルではなく、ボタンによる操作ですが、慣れれば問題なく操作できます。

* ファイルシステム
　フラッシュメモリのファイルシステムがNTFSでフォーマットされていました。
大きいサイズには便利だけど、Windowsに特化してしまうというデメリットも。
なお、Snow LeopardではHD8800を経由してのmicroSDへの書き込みは失敗します。

* 音楽再生機能
まず音質が良すぎる。ヘッドホン出力が普通にいい。
この手の製品は非常にノイジーなものだと思うのですが、
HD8800はiPod 5Gと比べても謙遜ない感じです。(DACが別途乗ってるようです)
タグ管理機能付き音楽プレイヤーではあるものの、
iTunesからのMP3は何故か認識されないような…。

* TV-Out
dingooと同じケーブルが利用できます。画質もdingooと同等。
具体的に言うと白飛び、微妙に解像感のない画面です。
HDMIはケーブルがなく、まだ試してません。
(HDMIはデジタルなので普通に綺麗だと思われます)

*動画再生
早送り、巻き戻しが可能なのはdingooより優れている部分です。
以下はファイル形式とその挙動です。

m2ts
http://av.watch.impress.co.jp/docs/20080220/zooma346.htm
からダウンロードできるezsample.m2tsが再生可能でした。
通常再生で若干ブロックノイズらしきものがでます。
設定でzoom 50%にするとブロックノイズがでないものの、音声が怪しくなります。

flv
残念ながらvp6は再生出来ず。他は再生できました。

mp4
youtubeなどからダウンロードできる一部の動画は画面がでないという不具合があります。
解像度かと思いましたが、HD画質のものでも発生したので、H.264のデコードに問題がありそうです。

vro
非プロテクトなMPEG2ファイルです。
DVDレコーダで昔録画したものですが、本体のフラッシュメモリに転送してリネームしたら再生できました。

mov(h.264 : 1920x1080)
http://www.bigbuckbunny.org/index.php/download/からのファイルです。
画像は問題なし。音声が同期しなくなるようです。デコードが間に合ってないのでしょうか…。

avi(mp4 : 1920x1080)
同じく、http://www.bigbuckbunny.org/index.php/download/からのファイルです。
音声は同期するものの、シークができません。

＊まとめ
　高解像度ファイルは本当に再生できるようです。
ファイルによっては処理落ち？して音声と同期できなくなったり、
最悪の場合はハングアップしたり、まだまだな部分もありますが、
それは今後のアップデートに期待ということで。
(dingooとは異なり、ハングアップ時にも電源OFFは有効です)
H.264が改善されればメディアプレイヤーとしてもっと使えそうかなと。
今後に期待したい。

hwinit_2_bin_100122.zip
hwinit_2_src_100122.zip

cp0_src_100122.zip
cp0_bin_100122.zip

なんだか忘れたり、このままロストしてしまうとあれなので、
ちょっとまとめておきます。

dingoo A320において、
dinguxが一部の新しい機種で動かないのはリセット時にほぼ必ず「ある特殊なレジスタ」も初期化されるからです。
そのレジスタ、CP0_CAUSEは初期化された段階で例外が発生するようにセットされます。

その例外とはCP0_STATUSに何らかの値を書き込んだ時点で発生するもので(おそらくは例外フラグのクリア)
例外が発生すると、アセンブラで書かれたLinuxの起動コードの最初の段階で停止します。

旧来のA320では電源OFF->USB接続による電源ON時を除いて、
リセット時にレジスタまでは初期化されないためその例外は発生しません。

調べた所、0x00400000(bit22)がその要因になっているようです。

mfc0 a0,CP0_CAUSE
and a0,~(0x00400000)
mtc0 a0,CP0_CAUSE

それで作られたのが、このフラグをクリアするためのhwinit_2です。
おそらくこれはjz4740が持つ機能であると推測できるので、この方法は広範囲に有効だと思われます。

http://www.mediafire.com/?gdzjzz0zz2t

こんな風にすればrootfsに依存せずにアプリを作れるよという見本にどうぞ。

Elta's rootfsが少し早い訳を探っておりました。

結果わかったのは、やはり色深度の8ビット化が出来るのが大きいかなと。
公式rootfsではビデオモード指定に16ビット指定が必須なので。

回転させたり、画像処理をさせたりするには8ビットであった方が
容量が少なくて、うまくすると高速に処理できるかなと。

回転パティシエでは画像データをディスプレイに直接転送できるフォーマットに変換して保持するので、
16ビットサーフェスだとどうもメモリが足りなくなる感じが。

多分、画像データを8bitにコンバートして保持、
最後にディスプレイフォーマットに変換しながらの転送でも
同様の効果が得られると思います。
しかし、まだ試してない…。

SDL_mixerに関しては謎。何か違う気も…。

あと、これは両方のrootfsに共通することとして、
SDLのビデオモード指定は変なフラグを入れると落ちます。

あと、回転パティシエ。

bpp = surface->format->BytesPerPixel;
if(bpp <= 8){
pal = surface->format->palette;
if(pal){
SDL_SetPalette(bitmap[setbmpindex], SDL_LOGPAL|SDL_PHYSPAL, pal->colors, 0, 256);
}

微妙にバグな気がします。
bppにBitsPerPixelの方を期待しているようなので…。
しかし、palは8bitでなければ常にNULLなので、まったく影響はないんですが…笑