Pandora menuとPXML

そういえばcpasjuste氏が製作しているPandora menu(最小メニュー)ですが順調に開発が進んでいるようです。少し前のビデオですが公開されていますね。これが以前予想したシンプルメニューになるのかな。その時は確かこんな予想でした。

#DE/WM
Simple Mode(Launcher?) Matchbox #NAND
Advance Mode(PDA?) Matchbox #NAND
Desktop? XFCE #SDカード

シンプル、アドバンスともにMatchboxかもと思っていたのですが、これだけシンプルで機能的なランチャーが開発されているとなると、他OS(Angstrom以外)への移植性も考えて、こちらのメニューがゲームコンソール・メニューとしては相応しいでしょうね。GTK+とかの依存も無いでしょうし。理想的な感じです。

linpndの解説でちらっと書きましたが、もしも将来的にAngstrom環境から他の環境、例えばMaemoやGentooにベースシステムが変更されたとしても、libpndと関係しているライブラリー等を一緒に移植してあげればゲームコンソールとしての機能は損なわれることはないですからね。まぁPDA関係はガラッと変更になる可能性が高いですが。

ちなみにこのメニューですが、現在のところはアドバンスモードでの1アプリケーションとして機能しているみたいです。メニュー自体はブート時に選択出来るように設計されているみたいですが、今のところ選択性になるかまでは決まっていないらしい。私としてはブート時にシンプルモード（PSPやDSみたいな感じで）とアドバンスモード（ザウルスみたいなPDAとして）を選択して起動できるようにしてもらいたいですね。

空き時間にサッとゲームで遊びたいのに、一々PDAモードから選択なんて面倒くさいですし。まぁ基本的に一度Pandoraを起動させたら、一々シャットダウンさせるよりも、サスペンドやハイバネート状態にした方がいろいろと楽そうですけどね。何かまとまってない気がしますが、もう少ししたらこの辺りについて、まとめ直してみようかと思っています。

#YouTube
Pandora menu and applications running together - YouTube
http://youtu.be/AF0P7onjKLo

ドリームキャストがやってきた？

今週はいろいろと情報が出て来ます。まずはQuakeの話題。Quake1,Quake2と続いたら今度はQuake3が動いたそうです。しかもなかなか速い。まだデモしか動いていませんがFPSはおおむね30-40くらいみたいです。さすがに60までは出ませんが初っ端にしては十分過ぎるスピードです。素晴らしい。

そして今日の目玉。何とPandoraでドリームキャストのエミュレーターが動くかもしれません。詳細はまだ掴んでいませんが、どうやらnullDCの作者自らがARM向けに移植作業を行っている模様。って実は去年からこの話は聞いていたのですけど。ただ作者の方があんまり期待されちゃうのも困るような事を某フォーラムやブログで書いていたので動向を黙って見守っていたのです。今回YouTubeにビデオも公開されたし、もう書いても大丈夫そうですね。

ちなみにこのnullDCの移植版は、通常のnullDCではなく「nullDCe」というバージョンで主に組み込み（というかメモリやCPUが通常より乏しい環境向け）に設計されたスペシャル版みたいです。ですのでnullDCよりも再現度や性能は落ちるそうです。仕方がないですね。動かないよりはずっとマシですし。

今のところ、ドリキャスのBIOS画面までしか公開されていませんが、以前行っていたPSP向けのビデオと比べると格段に速くなっています。といっても、まだまだゲームが出来るスピードではないようです。ちなみに移植したのはPandoraではなくBeagleboardです。作者の方の話だとPandoraが発売されたら移植したいそうです。実際のところ最適化が進んでも実機並みのスピードが出る事はないと思いますがゲームによっては音無しでゲーム可能なレベルになるのではないかと素人ながら考えております。PowerVR SGXの奇跡に賭けてみるのも悪くないかも。ドリキャス的な意味で。

何にせよ、楽しみなニュースではありますね。まるでGP2Xにおけるプレステエミュレーターを見ている感じです。プレステもGP2Xじゃ厳しかったですが、後継機的なPandoraでは十分可能なレベルになりそうですし、そう考えるとPandora2辺りではメインに躍り出てくる可能性はありますね。具体的にはOMAP4ですか（笑）。まぁ数年後までのお楽しみって所ですね。

#追記
nullDCのPSP移植版を追加。最初の方にBIOS画面が出てきます。比べてみるとどのくらい速いか分かりますね。

#YouTube
Pandora Quake 3 with nanoGL - YouTube
http://youtu.be/mW6CAD2UVek



nullDCe for arm running bios - YouTube
http://youtu.be/1wIYfutx1ZI



nullDC PSP Build 7-27-08 -=Shenmue=- - YouTube
http://youtu.be/Ix9huu4k5Qo



#外部リンク
Any possibility of a build for the Pandora? - Emuforums.com
http://forums.ngemu.com/showthread.php?t=118039

UnionFS on Pandora

昨日の続きです。今UnionFSについて調べているのですが、どうやらEEE PCにて使われているみたいですね。Windows版じゃなくてLinux版のXandrosで。某巨大掲示版からの引用。

以前、Xandrosを701にインストールしたことがあったが、（isoはネット上に公開されている）インストール先は指定できなかったと思う。SSDに別のOSが入っていようと問答無用にSSDにインストールされる。（今の901用のはインストール先を指定できるかもしれないが未確認）SSD４Gのうち２Gにインストールされて残りの２Gは更新データ用に取られる。

ちょっと特殊なことをやっていて、OSエリアのすべての更新（ファイルの修正、削除、追加）は後ろの２Gの更新エリア（パーティション）に保存される。２GのOSエリアはインストールされてままでまったく変化がないが、unionfsという仕組みであたかも更新されているようにみえる。

また更新エリアにすぐ保存されるのなくて、RAM上にキャッシュされていて、あるタイミング（詳細は不明）でまとめて保存されるようだ。unionfsはCDブートLinuxが使用していて、CDのOS領域が更新できるようにみせているのと同じ仕組みである。
なんでこんなことをしているのかというと、SSDへの書き込み回数の軽減（まとめて保存される）と高速化（一時的にRAMにキャッシュされる）のためである。

しかしファイル削除も実際削除されるのではなく保存領域に保存されるので常にサイズが増えていく。いつか2Gの領域を使いきってしまうのではないかと心配。システムアップグレードしてみてどのくらい使うのはみてみたいものだ。

どうやらSSD4GBのうち、2GBをシステム用としてリードオンリーでマウント（/dev/sda1）、残りの2GBをユーザー用としてリードライトでマウント（/dev/sda2）してUnionFSで重ね合わせて、1つのファイルシステムに見せているみたいですね。実際のシステム変更（ファイルの修正、削除、追加）はユーザー用のみで行って、システム用には一切変更を加えないと。何かあったら、すぐに初期状態に戻れるようになっているのとNANDの書き込み制限緩和の意味合いがあるらしい。

初期状態への復帰というメリットは理解できますがNANDへの負荷緩和はいまいち掴めないです。そんなに気にするなら、NANDは全部リードオンリーにしてSDカードを必ずシステム用に割いて、そちらにパッチ更新用のパーティションを区切った方が分かり易いかもと思いました。

また、更新エリアにすぐ保存されるのなくて、RAM上にキャッシュされていて、あるタイミング（詳細は不明）でまとめて保存されるようだ。

なんでこんなことをしているのかというと、SSDへの書き込み回数の軽減（まとめて保存される）と高速化（一時的にRAMにキャッシュされる）のためである。

まぁこういったコメントがあるので、それなりには効果があるのかもしれません。専門家の意見を聞いてみたいところです。というか、一番気になるのはこの部分。

しかし、ファイル削除も実際削除されるのではなく保存領域に保存されるので常にサイズが増えていく。いつか2Gの領域を使いきってしまうのではないかと心配。

Pandoraの場合はNAND512MBですからね。そこに余計な保存領域を確保するとなると少々心配です。まぁPandoraの場合、そうそう頻繁にソフトウェアのアップグレードが行われるかわかりませんし、更新としてはセキュリティ関係とかバグ関係とかが中心の小規模なものだけかもしれませんしね。

それに半年に一度くらいの割合でファームウェア全体のバージョンアップ（Ubuntuみたいな感じで)か、大きな変更が加えられた時点でバージョンアップ(iPhoneみたい？)が行われるかもしれませんし。それまでの繋ぎと考えれば、そうそう大きな変化はあり得ないかも。全くの妄想ですけどね（笑）。

#追記
EEE PCはtmpfsというのも併用しているのかな。これを併用すると無駄な書き込みが減る？　解らない事だらけです。

CNCケース完成

ようやくPandoraのCNCケースが完成したみたいです。何人かの開発者に届けられる予定みたいです。今週中にハードウェア担当のMWeston氏が受け取るらしいので、上手くいけば今週中に組み立てられたPandoraのビデオが公開されるかもしれません。待ち遠しいですね。

#Picasa

Pandoraのファームウェア

これはいつもよりいい加減な考察なので、鵜呑みにしないで下さい。あくまで素人が適当に考えた結果です。技術的に私の理解の範疇を越えていますので。この前PXMLとlibpndというのについて書きました。それと関係がある話なのですが、どうやらPandoraのファームウェア構成も野心的なモノになりそうです。

まず、Pandoraにおける「ファームウェア」ですが、これはLinuxカーネル、諸々のドライバー、LinuxOS(デフォルトではAngstrom準拠)、必須ライブラリー(SDL等)、必須ソフトウェア(MatchboxやFirefox等？)になるのではないかと私は思っています。これらがインストールされる場所は勿論NANDですね。ただNANDは512MBしかない上に、アップグレード等の処理に幾分空き領域が必要になるらしいので、実際に使えるスペースは512MBより少なくなりそうです。そこでいくつか疑問点が出てきます。例えば「ユーザーがNANDに別のアプリケーションやライブラリーを自由にインストール出来るの？　」とか。答えはYESでありNO。基本的には何の制約もなく自由にインストールする事が出来るようです。

アプリの追加どころか、OSそのものを別のモノに入れ替えることも可能です。ただ、上にも書いた通り、NANDの領域は限定されており、ユーザーが不用意にアプリ等をインストールしてしまうと、開発チームが想定している空き容量を圧迫してしまい、後々のファームウェアのアップグレードが不可能になってしまう可能性が出てきてしまいます。ですので、通常はNANDへの追加インストールは禁止にしたいようです。

ただ日本語環境で使いたい場合は、どうしてもデフォルトの環境にいろいろ追加（IMや仮名漢字変換、日本語フォント等）しないといけませんからね。ある程度はユーザーが自由に出来る領域を開けてくれるかもしれません。まだ何とも言えませんけど。まぁ基本的にはNANDは禁止で、PXML形式のアプリをSDカードにインストールする形になると思います。

またNANDの使い方ですが、なかなかおもしろい事になりそうです。どうやらNAND領域を「firmware」部分と「user homedir」部分に分割して収納するみたいです。それを実現させる為にUnionFS、あるいはAUFSというファイルシステムを使用するみたいです。はっきりいって、私には理解できるレベルを越えてしまっていますが調べて見たところ、どうやら、KNOPPIX等で使用されている技術らしいですね。以下ウィキペディアから抜粋。

KNOPPIX では、CD-ROM や DVD 上のファイルシステムと、（USB メモリスティックのような）書き込み可能なドライブ上の knoppix.img と呼ばれるイメージファイルを含むファイルシステム間の結合を作ることができ、そこでは書き込み可能なドライブは読み込み専用ドライブよりも優先される。これにより、新しいファイルをイメージに保存し、CD 上のファイル代わりに透過的に使って、ユーザがシステム上のどのファイルも変えることができるようになる。

分割したファイルシステムを結合して、1つのファイルシステムとして扱うことが出来るって事なんですかね。何となく理解（苦笑）。深入りは止めときます。ボロが出ますから。ついでに開発者の方のコメントも引用。

The nitty gritty ideas we had were to divide NAND up into a couple regions; a firmware chunk and a user homedir chunk. The trick is we could use unionfs (or aufs, a newer union-fs style system). We'd make te union setup so that writes to the firmware filesystem are actually written to the user section in your homedir somewhere, an the unionfs proprerties make it so the system doesn't see this. ie: You write to /usr/foo and it ends up in your homedir in NAND, but reading /usr/foo works still. This way if you overwrite stuff in the firmware and blow it up, you just wipe your homedir and reboot, and bam, you're back to a fully working stock firmware. For OS patches we can mount the real NAND fs instead of the union, update the filesystem, remount he union, and poof. Seems brilliant to me, and allows normal packagers to just work, reasonably risk free.

オリジナルのファームウェア環境を汚さないで、ユーザーファイルもNANDに収納するって事なのかな？　何かあってもすぐにデフォルトの状態へ戻すことが出来るって感じで。違うかも。

.pndファイルについても説明されてます。こちらもFUSEという技術を使うみたいです。.pndファイルをISOファイルとしてマウントするって事なのかな？　難しすぎて私には理解出来ませんが。とにかく環境を汚さずに使用出来るって事なのでしょうか？　ふぅもう少しちゃんと読まないとわからないな。誰か説明お願いします。

#外部リンク
UnionFS - Wikipedia
http://ja.wikipedia.org/wiki/UnionFS

Aufs - Wikipedia
http://ja.wikipedia.org/wiki/Aufs

Filesystem in Userspace - Wikipedia
http://ja.wikipedia.org/wiki/Filesystem_in_Userspace

Pandoraの最新スナップショット

ドイツで開催されているOlymptronicaというイベントの写真らしいです。残念ながらケースがまだ到着していなかったので、丸裸ですが新しい要素としてボタン周りが追加されています。といってもD-Pad部分はWizのやつをぶっこ抜いて付けているだけみたいですけど。アナログスティック部分とD-Pad、ABXYボタン部分の台座が付けられてますね。思っていたよりいい仕上がりみたいです。早く完成形を見せてもらいたいですね。

#Picasa

Pandora Quake 1

早速Pickle氏がPowerVR SGXのクロックを110Mhzに上げたビデオを公開してました。でもQuake2じゃなくてQuake1ですね。ちなみにPickle氏がテストした結果を引用すると、現在の状態で以下のような感じらしいです。Quake1です。

500 mhz 55 mhz no neon = 36 fps
750 mhz 110 mhz no neon = 58 fps
750 mhz 110 mhz w/ neon = 64 fps

ふむ。思ったよりも伸びませんね。特にNeon。まぁ58から64になってますから効果はあるみたいですけど。これには秘密があって現在のNeon最適化がまだ不十分なようなのです。まだ新しい技術ですから仕方がないのかもしれません。それにNanoGLはあくまでOpenGLを無理やりOpneGL ESに変換するものなので多少のオーバーヘッドがあるような気もします。

素人的に見てですが今回のデモの見どころはPandora実機でPowerVR SGXのOpenGL ES機能が実際に働いているという事実でしょうね。しかも特定のアプリケーションだけに有効という訳ではなく、誰にでも（生かせる技術は必要ですが）使用可能になるっていうのが大きいです。

うろ覚えですがリナザウの初期型に搭載されていたATIのIMAGEON 100が結局あんまり使われること無く後期型では外されていたりしてましたよね。詳しくはわかりませんが、あれも結局はユーザーが自由に使用出来なかったのが原因なような気がしますし。それでも最後の方は有志のお陰でだいぶ解析されていた気もしますけど。他にもEM・ONEのNVIDIA GoForce5500とか。意外と使われてたりするのかな……。調べて見ないとわかりませんが。

#YouTube
Pandora Quake 1 with nanoGL - YouTube
http://youtu.be/q5qtvD-MJ9E

Quake2 Nanogl

今日のフォーラムはこの話題で持ち切りですね。PandoraでQuake2がかなりのスピードで動いたって話題。今までもQuake2のデモはありましたが、それはソフトウェア処理されたものでしたし、しかも大半が320x240という解像度のものでした。更にサウンドも無効でしたし。今回公開されたのは解像度もPandoraの最大値である800x480で、サウンドも有り。何といってもOpenGL/ESのハードウェア処理されたものです。ちなみにCPUの速度はデフォルトらしいので多分600Mhzですね。

少し調べてみましたが、今回のデモはOpenGL/ESとはいえ、純粋なOpenGL/ESという訳ではなく、NanoGLというSymbian OS S60用のOpenGLをOpenGL/ESに変換するラッパーを、Linux用に改造したモノを使用しているみたいです。ですから、多少安定度には欠ける部分がまだありそうです。といっても作者のPickle氏はPandoraのデベロッパー・ボードを2日前に入手したばかりで（元々はGP2X Wiz用に製作していたモノ）、まだまだ手を加えなくてはいけない事があるみたいです。例えばOmap3最適化（NEON）や、いざとなったらCPUのクロックアップ等も。

そして、驚くことなかれ、PandoraのPowerVR SGXのドライバーは元々のクロックスピードの半分しか活用していない状態らしいのです！　ちなみに今のクロックスピードは55Mhz。最高速度は倍の110Mhzらしいです。これはまだ有効になっていないので、もしかしたらこれだけで倍近い増速が得られるかもしれません。まぁそこまで単純な構造ではないでしょうが（笑）。

余談ですが今まで公開されたPowerVR SGXのデモも半分の55Mhz版らしいです。これからが期待できる情報ですね。下のビデオですが、最初が今回公開されたビデオ。2番目が以前公開されたソフトウェア処理のビデオ。最後がPickle氏がWiz用に調整しているNanoGL版ですね。Wizの方は安定するまでもう少し時間がかかりそうですね。Thanks.Pickle!

#YouTube
Pandora Quake2 with nanoGL - YouTube
http://youtu.be/HysmLjxGXP4



Quake2 on Pandora devboard - YouTube
http://youtu.be/TGz52EIVN8s



wiz q2 - YouTube
http://youtu.be/2LT5oRRfudk

PXML&libpnd #02

この前の続き。といいたいところなのですが、まだ何を書こうか決まっていないまま適当に書き始めました。多分タイトル通りの内容にはならないかもしれません。例によって素人の駄文ですので内容的に間違いが多いかもしれません。ネタだと思って下さい。前回はPandoraのパッケージ管理システムが「PXML」と「libpnd」を使用した既存ではない新規のシステムになるらしいという事を書きました。今日はこの続きから。

結論から書きますが、どうやらPandoraのパッケージ管理システムは「2つ」あるらしいのです。1つは先程書いた「PXML」系、そしてもう一つが、前回も書いた「OPKG」。これはAngstromの標準パッケージ管理システムですね。つまりPandoraのファームウェア（ここではNANDに最初から収納されているLinuxカーネルを含んだAngstromベースのソフトウェア群）の管理をOPKGで、NANDではなく、ユーザーがSDカードを使用するコミュニティ配布アプリ（エミュレーターや自家製ゲーム等）の管理をPXML系で別々に管理するという事らしい。

何で2つに分けるのかは前回書いた通り。NANDはNAND、SDカードはSDカードと分けた方が結果的に管理しやすいからですね。例えばSDカードを入れ忘れてブートしてしまったり、あるいは途中でSDカードを入れ替えてしまったりした場合、既存のパッケージ管理システムでは処理が難しいらしい。それとユーザーの負担軽減の意味合いもあります。間違っているかもしれませんが、SDカードのフォーマットをLinux環境に合わせたモノにしないといけなかったり。日頃Linuxを使用している人なら難しくはないでしょうが、Pandoraを使用する人全てがそういった人たちばかりではないですからね。基本的にウィンドウズユーザーでしょうから。

そういった技術的な側面と、もう一つの理由があったりするようです。それはPandoraアプリ（ここではPXML準拠の.pndファイル）の移植性についてです。ご存知の方もいるでしょうがPandoraはオープンハード的な側面も持ち合わせています。オープンハードウェアの定義自体が諸説ありますが、少なくともPandoraのソフトウェア部分に関しては、ほぼ100%に近い状態でオープンになっています。（今のところ、無線LAN/BTデバイスのファームウェア部分と、PowerVR SGXの3Dドライバー、もしかしたらDSP部分辺りはオープンでは無いそうです）

ですのでデフォルトのOS環境であるAngstrom以外のOSを入れる人たちもいたりします。例えばUbuntuとか、既に動き始めているグループとしてGentoo Linuxチームが居たりします。更にはAndroidやMaemo辺りも将来的には有り得ると私は思っています。そうなると、Pandoraの華であるエミュレーターや自作ゲーム等は余計な移植作業を強いられる事になりかねません。

ソースコードが公開されている場合がほどんどなので、それぞれのチームがビルドすれば問題はないのですけど、それじゃ無駄な労力を使うだけですからね。それに基本的にPandoraアプリは一つのアーカイブにて公開される事になっていますから。デフォルトのAngstrom用に合わせてしまうと、他のディストリではそのままでは使用出来ない場合が多いですし。

そこで出てくるのがPXML系の.pndファイル。このファイルをlibpndというライブラリーが管理する事によって、各ディストリ間の互換性を埋めてくれる訳です。要するに、.pndファイル毎に互換性を取るのではなく、libpndで互換性を取ればいいという事です。これで、1つのアーカイブだけで互換性が取れるという訳ですね。無論、各ディストリはlibpndを移植しなくてはなりませんが、基本的にPandoraの各ライブラリー（SDL等）はオープンソースなので移植性は問題ないと思います。長々書きましたが素人の考察なので基本的に穴があるかもしれません。あしからず。

PXML&libpnd #01

最近Pandoraの話題が無いので寂しいのですが、おもしろそうな話題を一つ。毎度ながら素人の戯れ言なので、記事の信憑性については保証出来ません。フォーラムを覗き見していると最近上記の単語が話題になっているようです。「PXML」と「libpnd」。PXMLは以前にもちらっと書きましたね。アプリケーション管理の為のXML形式ファイルです（多分）。libpndは、このPXMLを読み込んでPandoraで実際のパッケージ管理を担当するライブラリー？　だと思います。

さて、ここで問題になってくるのが「何故Linuxなのに、既存のパッケージ管理システムであるapt-get(Debian系)やOPKG(Angstrom)を使用しないのか」って事です。私も最初はそう思いました。以前の考察でPandoraのベースシステムがAngstromになるだろうと予想した時に必然的にパッケージ管理システムはOPKGになるのかなぁと。以下は私なりの考察です。

Pandoraがデフォルトで使用するNANDは512MB。通常のPDAやスマートフォンなら十分な容量なのですが、幸か不幸かPandoraはそれらのデバイスよりも、よりパソコンに近いシステムになる可能性が大です。そうなるとNANDだけでは容量が足りずに必然的に2つあるSDカードスロットの1つをシステム領域として使う事になります。基本的に既存のパッケージシステム（apt-get等)は、HDDやNANDといった固定された保存領域を前提とした作りとなっており、SDカードといったリムーバブルメディアを併用する使用方法は想定されていないみたいです。

一応、OPKGは将来的に混在しても使用できるように改良される「可能性」はあるらしいのですが、残念ながらPandoraのリリースまでには間に合いそうもありません。ですので、Pandoraチーム自らが、この難問を解決しなければならなかったのだと思います。長くなったので一度終わります。