多忙を極めたスケジュールの中、 普段は全く使わないはずの PDA のスケジューラが、 妙に頼もしく思えたりするものです。 環境が変わると必要な機能も変わります。
最近話題の PocketPC 搭載 PDA である COMPAQ の iPAQ。 さんざん品切れでもはや入手不可能とまで周りでささやかれていました。 確かにオンラインサイトは先の先の予約までいっぱいだったりするのですが、 発売日以降、ふと立ち寄ったショップで「在庫残りあと何個」 とか書かれていたりすると、あれこれ迷う時間もなかったりするわけです。 長年 SHARP 系の電子手帳から Zaurus まで使い続けてきましたが、 ついつい買ってしまいました iPAQ を。
iPAQ は StrongARM の 206MHz を搭載しているといいます。 異なる CPU 間ではクロック周波数だけで性能比較できないのですが、 それでも MobileGearIi MC/R530 の 168MHz MIPS よりは速そうな予感がします。 FPU 搭載非搭載の違いはあるものの、 通常の使用状況においては実際速いらしいのです。そんなに速いのでしょうか。
ARM の CPU といえば、かつてのゲーム機 3DO に使われていたり、 PDA としては Newton に入っていたりしました。 最近でも Dreamcast のサウンドCPU のコアだったり、 PocketStation に使われていたりと 主に組み込み系で広い用途に用いられています。
もともとの ARM 自体は組み込み向けで消費電力の低さが特徴です。 速度的にはそれほど強い印象はありませんでした。 DEC が開発した StrongARM は、ARM のコアを採用した完全互換 CPU ながら その動作クロックを一気に 100MHz over まで引き上げています。 にもかかわらず低消費電力を実現しているので、 バッテリー駆動の PDA ながら十分な高速化の恩恵を得られるようになったわけです。
非力な CPU ながらハードウエアに見合ったバランスとセンスの良い アプリケーションで大成功を納めた Palm の CPU は 68000 系のものです。 ちょうど Macintosh が 68系から PowerPC へ移行したように、 Palm も 68系から StrongARM へと CPU の以降が行われるようです。
かつては SH3 が WindowsCE 機種や Zaurus など非常に多く使われていました。 その後 WindowsCE 機種では MIPS 機の占める割合が非常に多くなりました。 そして今後は StrongARM 搭載機種がかなり増える時代になるのかもしれません。
PalmSize PC は全く使ったことがなかったので、 このサイズの WindowsCE 機種は初めてです。 (ちなみに Palm 機は持ってます) ちょっと驚いたのが非常にシンプルな飾りのないウィンドウ画面で デスクトップがないこと。 メニューもインデックスもシンプルで、 搭載アプリも必要最小限です。 本体搭載機能だけでひたすらゴージャスなザウルスとはどうやら偉い違いです。
スケジュール画面の一覧性や使い勝手などは、 別の置き換えソフトを導入することがほとんど前提になりつつあるのでしょうか。 手書き入力の精度やレスポンスは、やっぱりザウルスに慣れた身にはちょっと酷です。 さらに MI-E1 で内蔵キーボードに慣れた手には、 もう手書きですら入力することすらつらいものでした。
ところがびっくり素直に感心するのが、PC 上の Outlook との連携であり、 確かに普段クレードルにさしておけば勝手にシンクロされています。 いちいち PC 上でメールやスケジュールを確認しなくても、 クレードルからはずして携帯した PocketPC を、 電車の中で開くだけで全部入ってるんですから便利なものです。
標準搭載アプリにしろシンクロ性能にしろ、 このあたりあくまで PC と連携させてはじめてわかる便利な使い方。 そう、本体でデータ入力する必要がほとんど全くないわけです。
単体で全部できる操作や内蔵機能にその性能はザウルスの利点であり、 逆に PC とのシンクロや連携においては PocketPC は非常に良くできています。
強力な連携に惹かれて MI-E1 と共に持ち歩くようになった iPAQ です。 ちょっと重いけど CFジャケット付きのままポケットに入れたり、 ファイルと一緒に手に持ったり。 机の前でいすに座ってうっかり手が滑ったら iPAQ がそのまま床に落ちてしまいました。 あらら、仕方ないなあと絨毯敷きのの床から拾い上げた iPAQ の画面を見て びっくり。
購入時に見たような Windows の設定画面になってます。 まさかと思ってペンでそのまま操作してみたら、 音を OFF にしていたはずなのに 部屋中に響くウィンドウズの起動音。 ひょっとしてひょっとして、メモリ内容は完全に消えて 完全初期化されていました。 こんな時に限って、CF にバックアップしたデータのリストアが 失敗してしまうものです。ふう。
電子手帳時代から PDA はよく胸ポケットに素のまま入れて持ち歩いていたので、 落とすことなんてしょっちゅうです。 電子手帳 PA-X1 は、雨の日浅い水たまりに落としたことがあります。 PI ZAURUS は、胸ポケットに入れてかがんだ瞬間コンクリートの床に落ちました。
そして MI Zaurus MI-110M の時は、胸ポケットに入れたまま自転車に乗っていて、 信号で急ブレーキをかけた瞬間宙を飛びました。 アスファルトにこすれて バラバラになった液晶カバーや電池のふた、電池、メモリーカード類を拾い集めて 慎重に組み立ててみたら、きちんと電源が入りメモリ内容は無事でほっとした覚えが あります。
MI-C1 は買ってすぐ、胸ポケットに入れたままジャンプしたら落ちました。はい。 カバーが割れたので秋葉で予備のカバーを買いました。 MI-E1 も手が滑って何度も何度も、でもメモリが消えたことはありませんでした。
MI Zaurus の本体メモリはフラッシュメモリです。 DRAM も搭載されていますがこちらはプログラム動作用なので 基本的に内容は保持されていません。 フラッシュメモリは電源が無くても消えず、また衝撃に強いことでも知られています。
MI Zaurus は 32bit RISC ですが、昔の PI ZAURUS は 8bit CPU でした。 こちらは WindowsCE 同様本体メモリは RAM でした。 しかしながら SRAM であり、メモリー保護用の電池も搭載されています。 消費電力も動作クロックも小さかったので、ちょっと一瞬電池を抜いただけでは メモリは消えません。 これは Palm も全く同様です。
iPAQ の場合、落とした瞬間衝撃で一瞬バッテリーがずれて、 瞬間的にメモリへの電源供給が途絶えたのではないでしょうか。 あくまで PDA であり、手帳のような使い方をされる Zaurus や Palm と違い、 PocketPC はやっぱり小型のポケットに入る PC なのです。 強力なハードは PC に近く、デリケートであることを実感させられました。
メモリが消えたショックよりも、落として壊れなかったことを喜ぶべきなのでしょう。 そして単体で使うザウルスではないので、きちんとシンクロと同様 PC で バックアップするべきなのですね。
これまで蓄積した大量のデータはやはり Zaurus に載っています。 iPAQ が結構よさげなので本当は PocketPC 一本化でという線も考えたのですが、 よくよく考えると個人的なことなど、仕事と無関係の膨大なデータが満載です。 これってうかつに仕事で使う PC 上でシンクロされては困ります。 きちんとデータの項目を分類すればいいのでしょうが、 今から整理するのは大変です。 というわけで、とりあえず仕事で使う情報は Outlook とシンクロして PocketPC で、 プライベートで使う情報はこれまで通り Zaurus で、 という棲み分けを行うことにします。
iPAQ はジャケットを付けたり変えることで、メモリーカードや PC カードを使用することができます。 標準でついてるのは CF TypeII 対応の CFジャケットです。 手持ちの CF が使えるので便利ですが、iPAQ の本体も結構巨大化してしまいます。 iPAQ 本体だけではつるっとした触感で、ストラップ用の穴も無いため もってて不安になることがあります。 なのでむしろ、 CF ジャケットをつけた方が手にしっくりとくる感じで持ちやすく なってしまうのは喜ぶべきでしょうか。
本体だけでは通信手段が無く、何らかのカードタイプの通信機器やアダプタを 用いる必要があります。 MI-E1 では、SDカードにCFカードもつけた状態で、 PHSケーブルによる通信ができました。 ただ実際は、メールの送受信は全部携帯に移行していたので、 通信に使うことはほとんどまれです。 iPAQ での通信は当分行わないことになりそうです。
iPAQ の入手を後押しした要因として、やっぱり Linux が動くという点も 大きかったといえます。 もともと MI Zaurus 用の zxLinux の開発も行っていましたが、 その動作形態においてメモリや速度などの制約が大きかったのも事実です。 また、興味を持ってくれるユーザーはそれなりに多かったものの、 実際の zxLinux の開発となるとさすがにそこまでできる方は減り、 ユーザーコミュニティが育たなかったのも事実。 開発していても単純なインストールや動作方法の質問ばかりという 状態がほとんどでした。
WindowsCE 動作時は、本体メモリ 32M のうち 16M がファイルシステムとなり、 残り 16M が動作用メモリとなります。 Linux 動作時は 32M RAM まるごとメモリとして使われ、 ストレージとしてフラッシュメモリなどの外部メモリが必要です。 さらに本体 OS が入っているフラッシュメモリの書き換えもできて、 Linux をそこに納めることができるらしいのです。
たださすがに日本語版 iPAQ は登場したばかりであり、 Linux を上書きしてしまったあとの日本語版 WindowsCE のリストアに 不安もあるのでもうちょっと手を出さないでおこうかと思ってます。 先に WindowsCE 上で試したいこともあるからです。
WindowsCE の開発キットはもともと VisualStudio に組み込んで使うものであり、 有料販売されていました。 ところがいつの間にか WindowsCE 専用開発キットとして 「eMbedded Visual C++」というものが登場し、無料で手に入れることが可能です。 CD 郵送の場合は手数料がかかるものの、勇気を出してダウンロードすれば 300Mbyte 程度ですが一応オンラインで手に入れることも可能です。
使える言語は VisualC++ と VisualBasic 。 動かしてみて驚いたのは、使い勝手も機能もなんら VisualStudio まんまで 変わらないということ。 これが無料だなんて 普段 VisualStudio を使ってる身としては、ちょっと WindowsCE ってずるいなあ と思ってしまいます。
WindowsCE といっても同じ Windows ファミリーなので、使える API は WIN32API であり MFC もあります。 筆者は普段 DirectX 系プログラム 専門なので、MFC はほとんど使いません。 WIN32API だけで構築したライブラリの蓄積があるわけで、 それらはほとんどそのまま使うことができそうです。
MI Zaurus の開発環境も SZAB が事実上無料になり、 無料の環境でアプリケーション開発ができるようになりました。 ( Zaurus の開発環境については このへん や このへん で解説しています。) これによって、ユーザー製ソフトの数が急激に増えています。 ただし唯一不満だったのが C++ が使えないことです。 市販の環境である CodeWarrior を使えばいいのでしょうが、 すでに Windows 上では C++ でライブラリ構築を行っていたため、 Zaurus 用には完全に新たにライブラリ等をそろえる必要がありました。 WindowsPC と同時にアプリケーション開発をする場合などは 結構不便していました。 WindowsCE では最初から Windows なので、互換性や同時開発などもなんら 問題なくいけそうです。
WindowsCE は、NT や 2000 同様クリーンな 32bit OS です。 そして多国語化も最初から考えられており、API に渡す文字は全部 UNICODE となります。 普段書いているアプリケーションは、文字列を扱うために char 型を使い、 常に 1byte と見なしてしまうことがあります。 WindowsCE 用アプリケーションではアルファベットにしろすべて 2byte で 表現するので short 型を用いなければなりません。
この違いを吸収するために Windows では TCHAR 型が用意されています。 TCHAR 型はコンパイル環境に応じて 1byte 型、2byte 型にそれぞれ アサインされるため、どちらの環境でも動くコードを記述することができるわけです。 このとき文字列定数はそのまま書くと常に 1byte 型になってしまうため、 どちらでも動くようにするためには TEXT() というマクロで囲って宣言する必要があります。
TCHAR *strValue= TEXT( "WindowsCE PocketPC" ); //等
最初は面倒ですが、慣れるとそれほど苦になるものではありません。 当然ながら TEXT() マクロは、文字列定数の byte 型を変更するだけであり、 ソースコードに埋め込まれた日本語コードを勝手に UNICODE に変換して くれるわけではありません。 そのうちテキストファイルやソースコードも全部 UNICODE で記述するようになる時代が来るのでしょうか。
筆者は こちら で、 Zaurus 用のベンチマークソフトとその結果一覧を公開しています。 まずはちょっとした興味本位から、このベンチマークテストのプログラムを そのまま iPAQ 上で走らせてみることにしました。 描画関係はさておいて、試したのは CPU テストのみです。
| 機種 | CPU TEST | MEMORY TEST |
| MI-E1 | 32 | 49 |
| iPAQ | 9 | 28 |
MI-E1 は、現在ほぼ最速と思われる MI Zaurus です。 値の小さい方が高速です。 速度差は一目瞭然で、クロック差以上の結果を引き出してしまいました。 さすがといいますか最強最速の PDA であることを証明した形になります。
MI-E1 が搭載している CPU は SH3 の 120MHz あたりであり、 外部に汎用 DSP を搭載しています。 上記の結果は Zaurus と WindowsCE の差というよりむしろ CPU の差といった方がいいでしょう。 というのも、WindowsCE にも SH3 搭載マシンは数多く存在するからです。 それだけ WindowsCE がパワーを食う重い OS であるといえるのかもしれません。
描画アクセス用には、PocketPC の場合 gapi というものが存在することがわかりました。 H/PC 系には無いようです。なぜでしょう。 これで DirectX とまではいかなくても、ほぼダイレクトに VRAM にアクセスすることができそうです。 もちろん、リアルタイム系の描画はバックスクリーンへのレンダリングが基本なので、 結局は高速にプリマリスクリーンへイメージ転送できればどんな API でも実際のところ困りません。
調べたところ iPAQ の画面は縦画面ながら VRAM は横に並んでおり、 ピクセルフォーマットは RGB565 で 320x240dot が完全に連続しているようです。 この構成は MI-C1 等の Zaurus と完全に同一です。 メモリ情報上は 65536 色分のハイカラーであり、4096色しか 表示できないのは液晶の制約のようです。
なんにせよ偶然 Zaurus とピクセルフォーマットが同一だったので、 色演算系は GA 3D Engine のコードをそのまま(アセンブラからCに戻すだけで)、 流用することができそうです。 (その代わりこのままでは完全に iPAQ 専用になります。)
演算系のコードや周辺インターフェースは、PC 用のライブラリ構造を持って きました。 ただし中身は Zaurus 版同様固定少数演算が基本の GA 3D のコアです。 描画とエンジン部分は実にあっさり実装できてしまいました。 一通りコンパイルを通しただけできちんとポリゴンが表示され、 三角の板がくるくる回っています。
ためしに 3D IM-Clock を移植します。 描画は一応できるものの、むしろ面倒なのが WindowsCE の挙動がまだよくわかっていないことで、 他のウィンドウやアプリケーションとの協調のし方や全画面の乗っ取り方です。 単純な文字列描画ですら、裏のウィンドウが見えてしまいなかなかうまくいきません。 フルスクリーンさえ乗っ取れば、 あとは全部自前の描画ですませられるだけに 勝手に他のウィンドウが上に出てきてしまうのは結構苦労するところです。
IM-Clock は思った通り予想以上にパワーに余裕があったので、 レンダリングサイズを大幅に増やしてかつ背景に BG を貼って、 さらに別のポリゴンモデルも表示させてしまいました。 それでも速度は速すぎるくらいです。 これでもまだ演算系はさっぱり最適化をかけていないわけです。
GA 3D Engine を使った MI Zaurus 用のポリゴンシューティングゲームです。 残念ながら GA 3D Engine は、Zaurus の MOREソフトコンテストでは 2年連続 表彰式に呼ばれることはありませんでした。 Zaurus においては、 3D のポリゴン系はさほど興味を持っていただけなかったようです。
ライブラリインターフェースが Zaurus 版と PocketPC 版で全然違うわけですが、 その差を吸収しつつ一通りコンパイルを通したら、なんと iPAQ 上でいきなり デモ画面が走ってしまいました。 あとはペンによる入力系や、文字列描画、 ファイルセーブ関係などを補ってやれば完成です。 というわけで、iPAQ 版 ChiRaKS は、昼頃からぽちぽちと移植を はじめたら夕方すぎにはしっかり動いてしまっていた最速(手抜き? フレームレートは速すぎるので、30fps で落ち着くように タイミングをとってウエイトを入れていあります。
| [メニューに戻る] | [ZAURUS総合] | [Direct3D] | [Ko-Window] | [Win32] | [WinCE] | [携帯電話] | [その他] |
| フルパワー全開 | Hyperでんち |