新しい技術、テクノロジについていくのはなかなかに大変なことです。 開発者にとって、新しいプラットフォームが増えるということはすなわち、 ゼロから ある程度の開発のノウハウやそれぞれの OS が持っているくせまで、すべて覚え直さなければなりません。
Microsoft が携帯情報機器向け OS として提唱する WindowsCE も、メリットとしてこの点に強く強く訴えています。 「すべての API が Win32 で統合されれば、 悩むことなんて無く、みんな幸せになれますよ」 確かにその通りで、API 統合はライブラリの蓄積も可能になり、 開発側としてはものすごい魅力的なことこの上ないのです。
筆者はたまたま ひょーんプロジェクト で DirectX を使ったアプリケーション等、 Windows アプリの開発も行っているせいというのもありますが、 開発する立場としては確かに WindowsCE に魅力を感じています。
さて、Zaurus はどうでしょう・・。 偶然というべきか SHARP の小型情報機器には10年を超える長い付き合いであり、 それもかなり深いレベルでソフトウエアを作る立場で使ってきました。
しかしながら MI Zaurus の MORE ソフトは、 当初個人向けに一般販売して無かったこと、 SZAB の価格が高いことをいいわけに、 これまで完全に 使うだけのユーザーに徹しています。 (いました)
使うだけのユーザーなら幸せだったのに、作る立場になってしまうと 視点が完全に変わってしまいます・・。
さて、SZAB による Zaurus の MORE ソフトはどうなのか、 体験版をちょっとだけ使ってみた、その雑感を書いてみたいと思います。
MI Zaurus に、あとから追加できるソフトのことです。 パソコンで言うアプリケーションソフトに相当します。
本体に内蔵されている スケジューラや電話帳などの機能(プログラム)は ROM に入っています。 これは書き換えたり消してしまうことはできません。 (フラッシュメモリでできるかもしれない)
MOREソフトはデータと同じように あとから機能を追加したり、自由に消したり、 必要に応じてカスタマイズすることができます。
この MORE ソフトを作るには、SHARP から出ている SZAB という開発キットが必要です。 これは PC (Windows) で動くソフトであり、WindowsCE のように PC 上でクロス開発をします。 MI Zaurus 単体でプログラムが作れるわけではありません。
古くからの ZAURUS ユーザーの方なら、 PI 系の ZAURUS に Addin 機能がこれまでもあったことをご存知でしょう。
Addin 機能も目的は MORE ソフトと一緒で、 機能をあとから追加できる文字通りの代物です。 なら MORE ソフトと何も変わらないのではないか・・いや違うのです。
この Addin のプログラムの正体は BASIC です。 PI-5000/4500 以降の PI ZAURUS に BASIC インタプリタが内蔵され、 その BASIC で動くプログラムが Addin 機能だったのです。
本体に内蔵されている、電話帳、スケジューラ、レポートに手書きメモなど、 これらの機能の一つに「BASICインタプリタ」がありました。 その下で動くのが Addin です。 どんなにがんばってプログラムを書いても BASIC インタプリタの範囲から 抜け出すことはできません。他の機能と横並びに位置することはできません。
WORD のマクロだけで Windows のシステムを作れないのと同じように、 Addin のプログラムでは、本体機能と同じクラスの機能やアプリケーションを 実現することは不可能でした。
注釈: この PI ZAURUS における Addin の制約を突破しようとした試みとして ザウルスパソコン化計画の ZauSH があります。 詳しくは こちら へ。
Addin 機能と MORE ソフトの決定的な違い、 それは、MORE ソフトの開発環境はほとんどそのまま 本体内蔵アプリケーションの開発環境と等しいと考えられることです。
MORE ソフトは本体機能と同列のクラスに位置します。 プログラム次第では何でもできるわけで、 本体内蔵機能にとって代るようなプログラムやツールも作れるかも知れません。
もちろん、何でもできる反面 Addin BASIC のように お気楽なプログラムを書くことはできません。 それなりに敷居は高く、BASIC インタプリタのようにシステムから保護されていないので、間違えば プログラムは暴走します。 でも 32bit のしっかりした OS がいるので、暴走で本体メモリが消える可能性は むしろ PI ZAURUS より減っているのかもしれません。
さて、そんなアプリケーション開発はパソコンではあたり前のことですが、 Zaurus のこれまでの進化からすると画期的でした。 なにせ、この他に類を見ない超高性能かつ超小型超軽量の凝縮されたボディで パソコンと同じようなことが可能になるわけです。 それも普及台数がばかにならない汎用機の上で。
SHARP の電子手帳はもともと、単体で完成された代物ながら、 ICカードによって好きなように機能拡張できる点が売りの一つでした。 本体の機能は基本的な PIM だけでも、さまざまな辞書カードや メモリカード、ゲームカードなど、豊富なアプリケーションがカタログを 占めています。ユーザーは必要な機能の組み合わせで使うことができます。
このような拡張性に優れた仕様は、企業向けカスタムの需要から生まれてきたものと 言われています。 SHARP の電子手帳はポケットコンピュータの時代から、 個人一般向けの店頭販売のほかに、 専用のソフトを組み込んで、企業向けに大量に納品するケースが多かったのです。 過去の経緯を見ると、SHARP 開発側の意図としては、個人向け一般市場よりも 重視していたことも少なからずあったようにみうけられます。
最初の電子手帳は SHARP のポケコンアーキテクチャを使っていたため、 ポケコンで培われたソフトウエア資産や BASIC をそのまま利用していました。 それは PI ZAURUS も同じで、 PI-5000/45000 以降はついに、カスタム機能の追加機能が Addin として本体に標準で付くようになったのです。
SHARP の電子手帳や ZAURUS は、もともと SHARP のポケコンと深い関係にありました。 システムアーキテクチャが同一であっただけでなく、 BASIC カードと言う形で SHARP の電子手帳(DB-Z)や ZAURUS は、 プログラムが書けるポケコンとしても使うことができました。
MI Zaurus になって、この図式は一変します。 ポケコンといった土台が無く、完全新規のシステムに変更され、 CPU パワーは一気に数十倍(数百倍?)もアップしました。 ポケコンとして「も」使える電子手帳ではなくなり、 パソコンのように本格的なアプリケーションが動くマシンに生まれ変わりました。
このアプリケーションである MORE ソフト開発は、 本体アプリの開発同様敷居が高く高価な代物なので、企業向けにのみ発売されました。 また、すべての本体データにアクセスできることから、 無制限に公開してしまうと、完成された電子手帳としての完成度が落ちる、 すなわちセキュリティ的な懸念がメーカー側にあったのかもしれません。
MI Zaurus が登場した 1996年から実に 2年間もの長い間、 MORE ソフト開発キットは企業向けのみリリースされました。 その情報は一般向けには一切公開されませんでした。 そのため MI Zaurus には、個人が作ったフリーソフトウエアも無く、 また多くのユーザーが熱望してやまなかった関数電卓すら存在しない 状態が長く長く続いたのです。
MORE ソフトウエア開発キット SZAB が、個人でも手に入るようになってからまだ 1年も経っていません。 さらに、いくら個人で手に入るといってもその値段は実売で 10万もする代物で、 よほどの覚悟無いと手に入れようとは思わないでしょう。 それでも果敢にキットを入手し、MORE ソフトをフリーソフトウエアとして 公開してくれていた先人には頭が下がります。
SZAB は個人には高すぎた。 空前のモバイルブームの中、他の PDA がどんどん普及してくるに従い、 個人の作ったフリーソフトの価値も次第に認められるようになりました。
しかし MI Zaurus の MORE ソフトを開発するには SZAB が高すぎる。
その折衷案として体験版の配布が登場します。 昨年(1998年)末に告知された MORE ソフトコンテストを機に、 体験版ユーザーへもアプリケーション識別子を公布し、 体験版で作ったプログラムもフリーソフトとして公開を認めたこと。 これによって、ようやく個人の作った MORE ソフトがフリーソフトウエアとして インターネット上にちらほらと姿が見えてくるようになりました。
SZAB 体験版は一種のシェアウエアのようなものです。 配布開始から一定期間内は、制限無く使用することができます。 今配布されているものは 1999/08/31 までの期間制限付きになっています。 入手先は こちら 。
筆者は SHARP 製の携帯マシンと10年以上もの付き合いがあります。 それがすべて、プログラミングの対象として使用してきました。 PC-1250/60系のポケコンから PC-E500 を経て PI Zaurus へ。
これらのマシンは 8bit CPU ながら、 ハードに密接にかかわるマシン語レベルのプログラミングが可能です。 使いこなせば本体の能力を存分に引き出すことができます。 しかしそのほとんどが SHARP 未公認の隠し機能でした。 (E500を除く)
マシン語が使える事実の未公開どころか、 マシン語そのもののインストラクションセットが未公開のものもあります。 それでも当時のパワフルなユーザーは独自解析で次々と解明していったのでした。 もちろん開発のためのツールなど無く、アセンブラやコンパイラであろうと、 自分で作るのが当たり前でした。
SHARP 製の公認ツールで、一切解析などせずに、マニュアルも完備で、 満足のいく開発環境が与えられたのはこれが・・初めてです。
SZAB による MORE ソフトの開発は C言語です。 残念ながら C++ ではなく、無印の生粋の C言語です。 マニュアルには一見クラスライブラリとか書いてあるので一瞬期待しますが、 本当に C++ のコードで通るのはコメントの「//」だけです。
クラスライブラリというのは、Zaurus 本体に内蔵されている Window GUI を サポートする API 群のことです。 Macintosh でいう ToolBox だと思って下さい。
32bit RISC の恩恵たっぷりの C言語は、当然フラットなメモリ空間で C言語としての面倒な制約はありません。 一度 32bit のフラットな開発をしてしまうと、 制約だらけの 16bit DOS には戻れないと思います。 MI Zaurus は本当にパワフルな 32bit マシンであると実感できるのは、 MORE ソフト開発のときかもしれません。
欲を言えば C ではなく C++ を使いたいところです。 SH のような組み込み系のハードに近いところの CPU 開発では、 C++ はそれほど使われていないのかもしれません。
筆者はこれまで、開発ツールでは統合環境を全く使っていませんでした。 Microsoft VisualC++ にしろ、スクリーンデバッガは使わないし直接 make しています。 RAD は BorlandC++ Builder を使ってますが、開発のメインではありません。
正直、統合環境をまじめに使ったのは SZAB がほとんど初めてに近い状態でした。 SZAB は Builder のように画面上にボタンなどパーツを並べ、 いくつかのプロパティ(設定項目)をダイアログに書きこんで、 必要なイベントにはコールバックルーチンを書くだけで アプリケーションができあがります。
プロパティやコールバックルーチンも、その場で起動したヘルプに詳細な説明から サンプルコードまで載っているので、ほとんどコピーしてはりつけるだけで 動いてしまいます。
想像した以上になかなか(・・かなり)良くできているといわざるをえません。 入門用と思われるプログラミングマニュアルもこれが(意外にも)わかりやすく できています。 敷居が高いといいつつ実は、機能が限られている分だけ Windows アプリより ある程度はわかりやすいのかもしれません。
フォームを使ったちょっとしたアプリケーションなら、 若干の慣れは必要ですがあっという間に作ることができてしまいます。
作成したアプリを本体に転送して実行するにはどうするのか。
SZAB では、PC と接続するためにケーブルが必要となっています。 このケーブルは CE-150T/CE-170T などの、パソコンリンクに使うものと同じです。 開発のターゲットとなる MI Zaurus には、最初からデバッガ機能が含まれており、 このシリアルケーブル接続により PC からコントロールできるようになっています。
動作確認は実機でしかできません。 エミュレータとかは無いのでこれはしかたないでしょう。
筆者は、MI-110M + CE-150TS(PI-3000用に買った15pin用) + CE-HA15(ACアダプタについてきた 16pin 15pin 変換アダプタ) という組み合わせで使っています。
ケーブルが無ければ全く開発できないわけではありません。 パソコンから MORE ソフトを転送する手段があれば、ビルドすると生成される ????.ZAC ファイルを、普通の MORE ソフトのように転送すれば実行 することができます。 もちろん、デバッガは使えないし転送に手間と時間がかかりすぎるので かなりの根性が必要です。
筆者は外出中にノートマシンから CF カードを使った転送で、 ケーブル無しのプログラム修正を行ったのですが、非常に面倒でした。 (ちょっと電卓 v1.10 はこうやって作った)
開発環境がわかりにくい、または敷居が高いのは、 さっぱり専門用語がわからないせいではないかと密かに思っています。
「統合環境でビジュアル開発でわかりやすくなってます」 Windows のいまどきの開発環境のうたい文句ですが、 肝心のマニュアルが ビルド って何？ プロパティ って何？というくらい 見たことも無い言葉が並んでいては、 その時点で挫折してしまいます。 Windows 系の開発のマニュアルには常々そういう疑問を思っていました。
さて、SZAB の場合は最初から開発経験者をターゲットにしています。 まず、C言語は当然知ってるものとして説明されています。 C言語に関する言語マニュアルは付いていません。コンパイラのマニュアルはあります。 C言語の互換ライブラリに関しても、 互換性の有無のみかろうじて表に記載されており、詳細なリファレンスはありません。
C言語は完全にマスターして自然言語より流暢に話せるくらいだ！、 という人には余計な説明が一切無いので、非常に入りやすくなっています。
それでもやっぱり、他のコンパイラ用でもC言語関数リファレンスくらいは あったほうが便利でしょう。
結論: SZAB にプログラミング経験とC言語知識は必須です。
ZaurusOS は、ウィンドウプログラミングとしてはオーソドックスな、 イベント駆動型のメッセージシステムです。 といってもイベントドリブンだけで動いているわけではなく、 各プロセスはプリエンプティブに動作しマルチスレッドが使えます。
OSとしてはプロセス毎にきちんと仮想メモリ空間が独立しており、 MacOS や Windows3.1 といったシングルマシン、シングルスレッドの昔の ウィンドウシステムとは違って、 わりとモダンなメモリ＆プロセスマネージャを有していると言えます。
内部にはイベントループも存在していますが、 SZAB 上からアプリケーションを作る分にはそれらを全く意識することはありません。
MORE ソフト開発で最も制限としてきついのは、ファイルシステムの弱さです。 厳密なファイル名命名規則などが存在しなければならないほど、 この部分が足かせになっています。 MS-DOS のような 8+3 ファイル名長制限はまず許せるとしても、 ディレクトリの概念がないため、ファイル名の衝突を回避するのに一苦労なのです。 この部分は深いので、機会があったらまたあらためて書くかもしれません。
次に MORE ソフト開発でわりと制限になるのはRAM容量のようです。 現在標準的な MI Zaurus (MI-500/100/600/300等) の RAM 容量は 2M byte です。 MI-10 も RAM 容量は一緒ですが、使えるメモリがさらに少なくなります。 (ちなみに MI-EX1 では RAM 容量は 8Mbyte もあります。)
Zaurus のストレージはフラッシュメモリなので、 頻繁な書き換えには向いているとは言えません。 それゆえ仮想メモリとはいえメモリスワップは発生しません。 よってワークメモリにおいては、物理メモリ量(RAM容量)が そのまま制限となるわけです。
ちなみに起動プロセスのデマンドページングは行われているようです。 そのため、プログラムコードサイズでは制約は起こらないようです。 (メモリマップドファイルは不明)
RAM の次に制限となるのが、あちこちで使われている short 管理のデータです。 MI-EX1 以外の MI Zaurus では、 テーブル個数、データサイズなどのフィールドが 16bit なので、 意外にも個数や容量制限を受けることがあります。 これは物理制限ではなく、ソフト的な API 仕様の問題です。 メモリが少ないので、いろいろと仕様でけちったのかもしれませんが、 ZaurusOS でちょっと残念なところ。
ところで 上にも書きましたが、MI-EX1 アイクルーズでは RAM 容量が一気に増加し、 8Mbyte あります。 物理的には 4倍ですが、OS的にはなんと 6倍以上のメモリ容量差に広がります。 16bit のテーブル個数などの制限もなくなりました。
これは、MI-EX1 ではこれまで本体機能であったものを、 MORE ソフトとして提供する方針に変更したための処置と思われます。 また、画面の解像度が上がったために、必要なワークメモリの容量も増加したものと 思われます。
またテーブル個数制限なども 32bit 化するなど改善されているようです。 MORE ソフト開発においては MI-EX1 の本体スペックは魅力かもしれません。 (CPU 速度もべらぼうに速いらしい)
筆者が使っている MI 系マシンは MI-110M のみです。 Zaurus マニアだからいっぱい集めているのではないかといつも誤解されますが、 本当に一台しか持っていません。
MI-110M は今となっては初期の PowerZaurus に属し、MI Zaurus の中では 遅い部類に入ります。 輪をかけて遅く感じるのはモノクロ液晶の反応速度のせいですが、 本当の実力はどうでしょうか。
MI Zaurus には、HITACHI の SH3 という 32bit の RISC CPU が使われています。 (関連記事) SH3 は WindowsCE 機でも広く使われており、PDA 用としてはポピュラーなものです。 動作周波数機種によって違いますが、Zaurus で使われているものは 30MHz〜120MHz といわれており、 パソコンには劣るものの十分パワフルです。
スペックを信じれば、MI-110M でも 大げさに例えると 10年前のハイエンドワークステーションの能力(FPUを除く) が乾電池で動いているわけです。
WindowsCE 機にも言えますが、 この手の PDA ハードで 動作の足を引っ張ってるのは、どうもほとんどが画面描画のようです。 その次に遅い原因はおそらくフラッシュメモリアクセスでしょう。
CPU単体の演算や動作そのものは非常に高速です。 手抜きで最適化をしないいいかげんなコードを書いても あっさり動いてしまうのはさすが。
対するウィンドウ描画は、 ハード的にも 65536色のハイカラーバッファは 1dot で 2byte ものメモリを消費する実に 負担の大きいもの。 PI ZAURUS のようなモノクロ専用に比較して単純計算で 16倍の負荷になります。 さらにアプリケーションからは仮想化されたカラーや座標空間で アクセスするよう統一管理が行われており、GUI処理も重くなります。
MORE ソフトを作っていても、 描画やパターン転送に関しては、はやはりそれなりに遅さを感じずにいられません。
MI-100シリーズなどのモノクロ Zaurus でも、内部では全部16bitのカラーデータとして 扱います。描画時に OS が 16階調の4bitモノクロ変換して表示してくれるので、 モノクロだから速いってことはありません。(かえって遅い)
SH シリーズの CPU といえば、PDA 以外には SEGA の Dreamcast や SEGA SATURN に使われていることでも有名です。 Zaurus の画面は偶然(?)にも 320x240dot ハイカラーであり、これは SONY PlayStation や SEGA SATURN の一番多く使われている画面モードと 全く同じです。 CPU そのものは PlayStation や SATURN よりも高速な SH3 なのだから、 ゲームもできればそこそこ期待したのですが。 ゲーム用により高速な描画 API の登場をぜひ希望したいところ。
もちろん同じ SH でも Dreamcast には絶対かないません。 あれは 360Mips 1.4GFlops の SH4 という化け物だから。 (画面も 640x480dot だし)
PI ZAURUS は、 こちら で解説していますが ESR-L という 8bit CPU を使っています。 これはもともと SHARP のポケコン PC-E500 シリーズで使用していたもので、 SC62015 等と呼ばれることもありました。
この 8bit CPU である PI ZAURUS 用の本体組み込みアプリケーションも、 やはりC言語で書かれていた らしい ことがわかりました。 SZAB のライブラリの一部のヘッダファイルに、それらしき内容のコメントが 残っています。
この CPU は命令セットに非常に制約が多いのですが、 Cコンパイラをかつて筆者も自分で作ったことがあるので、 かなり興味を覚えました。 思わぬ発見でした。
| [メニューに戻る] | [ZAURUS総合] | [DirectX] | [Ko-Window] | [Win32] | [WinCE] | [携帯電話] | [その他] |
| フルパワー全開 | Hyperでんち |