本発明に係る好ましい実施の形態について図面を参照しながら説明する。ここで、本発明の実施の形態となる携帯用電子機器は、親機となるビデオゲーム装置等のエンタテインメントシステムに用いられるメモリカード装置として、また、単体で携帯用小型ゲーム機としても使用できるものである。なお、親機は、ビデオゲーム機に限定されるものではなく、また、子機となる携帯用電子機器は、メモリカード機能を必ずしも有していなくともよい。
以下の説明においては、まず、本発明の実施の形態となる携帯用電子機器が子機として用いられる親機の一例のビデオゲーム装置について説明する。
第1図は、本発明の実施の形態となる携帯用電子機器が装着される親機としてのビデオゲーム装置の外観を示している。このビデオゲーム装置1は、例えば光ディスク等に記録されているゲームプログラムを読み出して、使用者(ゲームプレイヤ)からの指示に応じて実行するためのものである。なお、ゲームの実行とは、主としてゲームの進行、及び表示や音声を制御することをいう。
ビデオグーム装置1の本体2は、ほぼ四角形状の筐体に収容されており、その中央部にビデオゲーム等のアプリケーションプログラムを供給するための記録媒体であるCD−ROM等の光ディスクが装着されるディスク装着部3と、ゲームを任意にリセットするためのリセットスイッチ4と、電源スイッチ5と、上記の光ディスクの装着を操作するためのディスク操作スイッチ6と、例えば2つのスロット部7A,7Bを備えて構成されている。
なお、アプリケーションプログラムを供給するための記録媒体は光ディスクに限定されるものではなく、また、通信回線を介してアプリケーションプログラムが供給されるようにしてもよい。
スロット部7A,7Bには、2つの操作装置20を接続することができ、2人の使用者が対戦ゲーム等を行なうことができる。また、このスロット部7A,7Bには、前述したメモリカード装置や本発明の実施の形態となる携帯用電子機器を挿着することもできる。なお、第1図では2系統のスロット部7A,7Bを設けた構造を例示しているが、その数は2系統に限定されるものではない。
操作装置20は、第1、第2の操作部21,22と、Lボタン23L、Rボタン23Rと、スタートボタン24、選択ボタン25とを有し、さらに、アナログ操作が可能な操作部31,32と、これらの操作部31,32の操作モードを選択するモード選択スイッチ33と、選択された操作モードを表示するための表示部34とを有している。さらに、操作装置20の内部には、図示しない振動付与機構が設けられている。
第2図は、上記のビデオゲーム装置1の本体2の前面に設けられているスロット部7A,7Bの様子を示している。
本実施の形態では、スロット部7A,7Bは、それぞれ2段に形成されており、その上段には前述したメモリカード10や、後述する携帯用電子機器100が挿着されるメモリカード挿入部8A,8Bが設けられ、その下段には操作装置(コントローラとも呼ばれる)20の接続端子部(コネクタ)26が接続されるコントローラ接続部(ジャック)9A,9Bが設けられている。
メモリカード挿入部8A,8Bの挿入孔(スロット)は、横方向に長い長方形状に形成し、その下側の両端のコーナーを上側の両端のコーナーに比べて丸みを多くして、メモリカードが誤った向きに挿入されない構造になっている。また、メモリカード挿入部8A,8Bには、その内部に設けられている電気的接続を得るための接続端子を保護するシャッタが設けられている。
一方、コントローラ接続部9A,9Bは、横方向に長い長方形状をした挿入孔の下側の両端のコーナーを上側の両端のコーナーに比べて丸みを多くした形状にして、コントローラ20の接続端子部26が誤った向きに接続されない構造になっており、かつメモリカードが誤挿入されないようにメモリカード挿入部8A,8Bとは挿入孔の形状を異にした構造にされている。
第3図は、ビデオゲーム機1の前面のスロット部7Aのメモリカード挿入部8Aに、後述する本発明の実施の形態となる携帯用電子機器100が挿入された状態を示している。
次に、第4図は、上記のビデオゲーム装置1の主要部の概略的な回路構成の一例を示すブロック図である。
このビデオゲーム装置1は、中央演算処理装置(CPU:Central Processing Unit)51及びその周辺装置等からなる制御系50と、フレームバッファ63に描画を行なう画像処理装置(GPU:Graphic Processing Unit)62等からなるグラフィックシステム60と、楽音,効果音等を発生する音声処理装置(SPU:Sound Processing Unit)71等からなるサウンドシステム70と、アプリケーションプログラムが記録されている光ディスクの制御を行なう光ディスク制御部80と、使用者からの指示が入力されるコントローラ20からの信号及びゲームの設定等を記憶するメモリカード10や、後述する携帯用電子機器100からのデータの入出力を制御する通信制御部90と、上記の各部が接続されているバスBUS等を備えて構成されている。
上記の制御系50は、CPU51と、割り込み制御やダイレクトメモリアクセス(DMA:Direct Memory Access)転送の制御等を行なう周辺装置制御部52と、ランダムアクセスメモリ(RAM:Random Access Memory)からなるメインメモリ(主記憶装置)53と、メインメモリ53,グラフィックシステム60,サウンドシステム70等の管理を行なういわゆるオペレーティングシステム等のプログラムが格納されたリードオンリーメモリ(ROM:Read Only Memory)54とを備えている。なお、ここでいうメインメモリは、そのメモリ上でプログラムを実行できるものをいう。
上記のCPU51は、ROM54に記憶されているオペレーティングシステムを実行することにより、このビデオゲーム装置1の全体を制御するもので、例えば32ビットのRISC−CPUからなる。
そして、このビデオゲーム装置1は、電源が投入されると、上記の制御系50のCPU51がROM54に記憶されているオペレーティングシステムを実行することにより、CPU51が、上記のグラフィックシステム60、サウンドシステム70等の制御を行なうようになっている。また、オペレーティングシステムが実行されると、CPU51は、動作確認等のビデオゲーム装置1の全体の初期化を行った後、上記の光ディスク制御部80を制御して、光ディスクに記録されているゲーム等のアプリケーションプログラムを実行する。このゲーム等のプログラムの実行により、CPU51は、使用者からの入力に応じて上記のグラフィックシステム60、サウンドシステム70等を制御して、画像の表示、効果音、楽音の発生を制御する。
また、上記のグラフィックシステム60は、座標変換等の処理を行なうジオメトリトランスファエンジン(GTE:Geometry Transfer Engine)61と、CPU51からの描画指示に従って描画を行なうGPU62と、このGPU62により描画された画像を記憶するフレームバッファ63と、離散コサイン変換等の直交変換により圧縮されて符号化された画像データを復号する画像デコーダ64とを備えている。
上記のGTE61は、例えば複数の演算を並列に実行する並列演算機構を備え、上記のCPU51からの演算要求に応じて座標変換、光源計算、行列あるいはベクトル等の演算を高速に行なうことができるようになっている。具体的には、このGTE61は、例えば1つの三角形状のポリゴンに同じ色で描画するフラットシェーディングを行なう演算の場合では、1秒間に最大150万程度のポリゴンの座標演算を行なうことができるようになっており、これによって、このビデオゲーム装置では、CPU51の負荷を低減するとともに、高速な座標演算を行なうことができるようになっている。
また、上記のGPU62は、CPU51からの描画命令に従って、フレームバッファ63に対して多角形(ポリゴン)等の描画を行なう。このGPU62は、1秒間に最大36万程度のポリゴンの描画を行なうことができるようになっている。
さらに、上記のフレームバッファ63は、いわゆるデュアルポートRAMからなり、GPU62からの描画あるいはメインメモリからの転送と、表示のための読み出しとを同時に行なうことができるようになっている。このフレームバッファ63は、例えば1Mバイトの容量を有し、それぞれ16ビットの、横が1024画素、縦が512画素からなるマトリックスとして扱われる。また、このフレームバッファ63には、ビデオ出力として出力される表示領域の他に、GPU62がポリゴン等の描画を行なう際に参照するカラールックアップテーブル(CLUT:Color Lock Up Table)が記憶されるCLUT領域と、描画時に座標変換されてGPU62によって描画されるポリゴン等の中に挿入(マッピング)される素材(テクスチャ)が記憶されるテクスチャ領域が設けられている。これらのCLUT領域とテクスチャ領域は、表示領域の変更等に従って動的に変更されるようになっている。
なお、上記のGPU62は、上述のフラットシェーディングの他にポリゴンの頂点の色から補完してポリゴン内の色を決めるグーローシェーディングと、上記のテクスチャ領域に記憶されているテクスチャをポリゴンに張り付けるテクスチャマッピングを行なうことができるようになっている。これらのグーローシェーディングまたはテクスチャマッピングを行なう場合には、上記のGTE61は、1秒間に最大50万程度のポリゴンの座標演算を行なうことができる。
さらに、画像デコーダ64は、上記のCPU51からの制御により、メインメモリ53に記憶されている静止画あるいは動画の画像データを復号してメインメモリ53に記憶する。
また、この再生された画像データは、GPU62を介してフレームバッファ63に記憶することにより、上述のGPU62によって描画される画像の背景として使用することができるようになっている。
上記のサウンドシステム70は、CPU51からの指示に基づいて、楽音,効果音等を発生するSPU71と、このSPU71により、波形データ等が記録されるサウンドバッファ72と、SPU71によって発生される楽音,効果音等を出力するスピーカ73とを備えている。
上記のSPU71は、例えば16ビットの音声データを4ビットの差分信号として適応予測符号化(ADPCM:Adaptive Differential PCM)された音声データを再生するADPCM復号機能と、サウンドバッファ72に記憶されている波形データを再生することにより、効果音等を発生する再生機能と、サウンドバッファ72に記憶されている波形データを変調させて再生する変調機能等を備えている。
このような機能を備えることによって、このサウンドシステム70は、CPU51からの指示によってサウンドバッファ72に記録された波形データに基づいて楽音,効果音等を発生するいわゆるサンプリング音源として使用することができるようになっている。
上記の光ディスク制御部80は、光ディスクに記録されたプログラムやデータ等を再生する光ディスク装置81と、例えばエラー訂正符号(ECC:Error Correction Code)が付加されて記録されているプログラム,データ等を復号するデコーダ82と、光ディスク装置81からのデータを一時的に記憶することにより、光ディスクからのデータの読み出しを高速化するバッファ83とを備えている。上記のデコーダ82には、サブCPU84が接続されている。
また、光ディスク装置81で読み出される、光ディスクに記録されている音声データとしては、上述のADPCMデータの他に音声信号をアナログ/デジタル変換したいわゆるPCMデータがある。
ADPCMデータとして、例えば16ビットのデジタルデータの差分を4ビットで表わして記録されている音声データは、デコーダ82で復号された後、上述のSPU71に供給され、SPU71でデジタル/アナログ変換等の処理が施された後、スピーカ73を駆動するために使用される。
また、PCMデータとして、例えば16ビットのデジタルデータとして記録されている音声データは、デコーダ82で復号された後、スピーカ73を駆動するために使用される。
さらに、通信制御部90は、バスBUSを介してCPU51との通信の制御を行なう通信制御機91を備え、使用者からの指示を入力するコントローラ20が接続されるコントローラ接続部9A,9Bと、ゲームの設定データ等を記憶する補助記憶装置としてメモリカード10や後述する携帯用電子機器100が接続されるメモリカード挿入部8A,8Bが上記の通信制御機91に設けられている。
上記のコントローラ接続部9A,9Bに接続されたコントローラ20は、使用者からの指示を入力するために、例えば16個の指示キーを有し、通信制御機91からの指示に従って、この指示キーの状態を、同期式通信により、通信制御機91に毎秒60回程度送信する。そして、通信制御機91は、コントローラ20の指示キーの状態をCPU51に送信する。
これにより、使用者からの指示がCPU51に入力され、CPU51は、実行しているゲームプログラム等に基づいて、使用者からの指示に従った処理を行なう。
ここで、上記のメインメモリ53、GPU62、画像デコーダ64及びデコーダ82等の間では、プログラムの読み出し、画像の表示あるいは描画等を行なう際に、大量の画像データを高速に転送する必要がある。そこで、このビデオゲーム装置では、上述のようにCPU51を介さずに周辺装置制御部52からの制御により上記のメインメモリ53、GPU62、画像デコーダ64及びデコーダ82等の間で直接データの転送を行なういわゆるDMA転送を行なうことができるようになっている。これにより、データ転送によるCPU51の負荷を低減させることができ、高速なデータの転送を行なうことができる。
また、上記のCPU51は、実行しているゲームの設定データ等を記憶する必要があるときに、その記憶するデータを通信制御機91に送信し、通信制御機91はCPU51からのデータを上記のメモリカード挿入部8Aまたはメモリカード挿入部8Bのスロットに挿着されたメモリカード10や携帯用電子機器100に書き込む。
ここで、上記の通信制御機91には、電気的な破壊を防止するための保護回路が内蔵されている。上記のメモリカード10や携帯用電子機器100は、バスBUSから分離されており、装置本体の電源を入れた状態で、着脱することができる。従って、上記のメモリカード10や携帯用電子機器100の記憶容量が足りなくなった場合等に、装置本体の電源を遮断することなく、新たなメモリカードを挿着できる。このため、バックアップする必要があるゲームデータが失われてしまうことなく、新たなメモリカードを挿着して、必要なデータを新たなメモリカードに書き込むことができる。
また、パラレルI/Oインターフェース(PIO)96、及びシリアルI/Oインターフェース(SIO)97は、上記のメモリカード10や携帯用電子機器100と、ビデオゲーム装置1とを接続するためのインターフェースである。
次に、本発明の実施の形態となる携帯用電子機器について説明する。以下では、本発明に係る携帯用電子機器100について、前述した親機のビデオゲーム装置1に挿着されて子機として使用される場合を前提として説明する。
すなわち、この子機となる携帯用電子機器100は、親機となるビデオゲーム装置1のスロット部7A,7Bに設けられたメモリカード挿入部8A,8Bに挿着されるものであり、接続された複数のコントローラ20に対応する固有のメモリカードとして使用できるようになっている。例えば、2人の使用者(ゲームプレイヤ)がゲームを行なう場合には、2つの携帯用電子機器100に、各自のゲーム結果等をそれぞれ記録するという機能を有している。
なお、メモリカード挿入部8A,8Bに上記メモリカード10や携帯用電子機器100を挿入する際に、電源端子やグランド(接地)端子が先に電気的に接続状態となるように、上記メモリカード10や携帯用電子機器100のコネクタの電源用やグランド(接地)用の接続端子の導体を他の端子よりも長めに形成している。これは、電気的な動作の安全性や安定性を確保するためであり、ビデオゲーム装置1のメモリカード挿入部8A,8Bの接続導体を長めに形成したり、両者を長めに形成するようにしてもよい。また、誤挿入防止のために、コネクタ部の左右の形状を非対称に形成している。
第5図乃至第7図は、本発明の実施の一形態としての携帯用電子機器100の外観を示し、第5図は携帯用電子機器100の平面図を、第6図はコネクタ部を保護するための蓋部材110を閉じた状態の斜視図を、第7図は蓋部材110を開いた状態の斜視図をそれぞれ示している。
これらの第5図乃至第7図に示すように、本発明に係る携帯用電子機器100は、ハウジング101を有して構成され、イベント入力や各種選択等を行なうための1個又は複数の操作子121,122を有してなる操作部120と、液晶表示装置(LCD)等からなる表示部130と、後述するワイヤレス通信手段により例えば赤外線によるワイヤレス通信を行なうための窓部140とが設けられている。
ハウジング101は、上シェル101aと下シェル101bからなり、メモリ素子等を搭載した基板151を収納している。このハウジング101は、ビデオゲーム装置1の本体のスロット部7A,7Bに挿入され得るものであり、その一端側の側面には長方形状の窓が形成されたコネクタ部150が設けられている。
窓部140は、略々半円形状に形成されたハウジング101の他端部分に設けられている。表示部130は、ハウジング101の上面部において、この上面部の略々半分の領域を占めて、窓部140の近傍に位置して設けられている。操作部120は、ハウジング101の上面部において、この上面部の略々半分の領域を占めて、窓部140の反対側となる部分に設けられている。この操作部120は、略々四角形状に形成されハウジング101に対して回動可能に支持されるとともに一または複数の操作子121,122を有する蓋部材110と、ハウジング101上の該蓋部材110によって開閉される位置に設けられたスイッチ押圧部102,103とから構成されている。
操作子121,122は、蓋部材110の上面側より下面側に亘ってこの蓋部材110を貫通して配設されている。そして、これら操作子121,122は、蓋部材110の上面部に対して出没する方向に移動可能となされて該蓋部材110によって支持されている。
スイッチ押圧部102,103は、ハウジング101の上面部に対して出没する方向に移動可能となされて該ハウジング101に支持された押圧子を有している。この押圧子は、上方側より押圧されることにより、ハウジング101内の基板151上に配設された、例えばダイヤフラムスイッチの如き押圧スイッチを押圧する。
これらスイッチ押圧部102,103は、蓋部材110が閉蓋された状態において、各操作子121,122の位置に対応する位置に設けられている。すなわち、蓋部材110が閉蓋された状態においては、各操作子121,122を上方側よりこの蓋部材110の上面部に対して没入する方向に押圧操作すると、この操作子121,122は、対応するスイッチ押圧部102,103の押圧子を介して、ハウジング101内の対応する押圧スイッチを押圧する。
コネクタ部150の窓内には、第8図に示すように、電源用及び信号用の端子152が基板151上に配設されて臨んでいる。
なお、コネクタ部150の形状や寸法等は、ビデオゲーム装置1に用いられる通常のメモリカード10と共通にされている。
第9図の(a)は、上記の携帯用電子機器の主要部の構成例を示すブロック図である。
携帯用電子機器100は、前述した通常のメモリカード10と同様に、その動作を制御するための制御手段41と、情報機器等のスロットに接続するためのコネクタ42、及びデータを記憶するための素子である不揮発メモリ46を備えている。
制御手段41は、例えばマイクロコンピュータ(図中ではマイコンと略記する。)を用いて構成され、その内部にはプログラム格納手段であるプログラムメモリ部41aを有している。また、不揮発メモリ46として、フラッシュメモリのように電源を切っても記録されている状態が残る半導体メモリ素子が用いられる。なお、本発明に係る携帯用電子機器100は、後述するように電池49を備えて構成されるため、不揮発メモリ46としてデータを高速に入出力できるスタティックランダムアクセスメモリ(SRAM)を用いることもできる。
携帯用電子機器100は、上記の構成に加えて、格納されたプログラムを操作するための操作ボタン等の操作(イベント)入力手段43、上記のプログラムに応じて種々の情報を表示する表示手段である液晶表示装置(LCD)等の表示手段44、他のメモリカード等との間で赤外線等によりデータを送受信するワイヤレス通信手段48、上記の各部に電源を供給する電池49を備えている点が異なっている。
また、携帯用電子機器100は、電源供給手段として小型の電池49を内蔵している。このため、親機のビデオゲーム装置1のスロット部7A,7Bから抜き取られた状態でも単独で動作することが可能である。なお、電池49として充電可能な2次電池を用いてもよい。子機の携帯用電子機器100が親機のビデオゲーム装置1のスロット部7A,7Bに挿入されている状態では、親機のビデオゲーム装置1から電源が供給されるように構成している。すなわち、電池49の接続端には、電源端子50が逆流防止用ダイオード51を介して接続されており、上記ビデオゲーム装置1等の親機のスロットに挿入接続した際には、親機から子機側への電源供給がなされ、また、2次電池が用いられている場合には2次電池への充電も行われる。
この携帯用電子機器100は、さらに、時計45、上記プログラムに応じて発音する発音手段であるスピーカ47等も備える。なお、上記の各部は、いずれも制御手段41に接続しており、制御手段41の制御に従って動作する。
第9図の(b)は、制御手段41の制御項目を示している。通常のメモリカード10では、情報機器への本体接続インターフェースと、メモリにデータを入出力するためのメモリインターフェースのみを備えていたが、本実施の形態の携帯用電子機器100では、上記のインターフェースに加えて、表示インターフェース、操作入力インターフェース、音声インターフェース、ワイヤレス通信インターフェース、時計管理、及びプログラムダウンロードインターフェースを備えている。
このように、携帯用電子機器100は、従来機能である本体(親機)接続インターフェースと不揮発メモリ管理とは独立に、本実施の形態により追加された機能を管理するためのインターフェース(ドライバ)を、制御手段(マイクロコンピュータ)41に持たせるようにしたため、従来機能との互換性を保つことができる。
また、この携帯用電子機器100は、実行されるプログラムを操作するためのボタンスイッチ等の入力手段43や、液晶表示装置(LCD)等を用いる表示手段44を備えて構成されているため、ゲームアプリケーションを動作させると携帯型ゲーム装置としての応用が可能である。
しかも、この携帯用電子機器100は、アプリケーションプログラムを、ビデオゲーム装置1の本体からダウンロードされるプログラムをマイクロコンピュータ41内のプログラムメモリ部41aに格納する機能を有しているため、携帯用電子機器100上で動作するアプリケーションプログラムや各種のドライバソフトを容易に変更することができる。
以上説明したように、本発明に係る携帯用電子機器100は、ビデオゲーム装置1とは独立に動作を制御できる。従って、携帯用電子機器100側では、プログラム格納手段であるプログラムメモリ部41aに格納されたアプリケーションによるデータを、ビデオゲーム装置上側のアプリケーションソフトとは独立に作成できる。また、このデータをビデオゲーム装置1とやりとりすることにより、携帯用電子機器100とビデオゲーム装置1との協調動作(リンク)が可能となる。
さらに、携帯用電子機器100は、時計45を備えていることにより時間データをビデオゲーム装置1側と共有することも可能である。すなわち、互いの時刻データを一致させるだけでなく、それぞれが独立に実行するゲームの進行を、実時間に応じて制御するためのデータも共有することができる。
なお、上述したビデオゲーム装置1と携帯用電子機器100の間の協調動作の具体例については後述する。
第10図は、本発明に係る携帯用電子機器100どうしの間で、ワイヤレス通信を行なう様子を模式的に示している。このように、携帯用電子機器100は、ワイヤレス通信手段48において赤外線等によりワイヤレス通信を行なうためのワイヤレス通信窓となる窓部140を介してデータを送受信することにより、複数のメモリカード間で内部データをやりとりすることができる。なお、上記の内部データは、例えばビデオゲーム装置等の情報機器側から転送されてメモリカード内部の記憶手段に記憶されたデータをも含むものである。
なお、上記の実施の形態においては、携帯用電子機器100をビデオゲーム装置の補助記憶装置として使用されるものとして説明したが、適用対象はビデオゲーム装置に限定されるものではなく、例えば種々の情報の検索等にも適用可能であることはもちろんである。
次に、上記の携帯用電子機器100と前述した親機となるビデオゲーム装置1との間の協調動作について説明する。
前述したように、携帯用電子機器100は、制御手段であるマイクロコンピュータ41で生成されたゲームデータ、メモリカード内の時計45で得られた時間データ、ワイヤレス通信手段48を介して得られる他のメモリカードで生成されたデータ等を、ビデオゲーム装置1の本体と共有することができる。
第11図は、親機となるビデオゲーム装置1と子機となる携帯用電子機器100の間で、協調動作を行なう様子を模式的に示している。
以下では、このような協調動作の例として、親機のビデオゲーム装置1に、アプリケーションソフトウェアのプログラムが記録された記録媒体である光ディスク(CD−ROM)が装着されており、そこから読み出されたプログラムが、ビデオゲーム装置1の本体のスロット7A,7Bに挿着された子機の携帯用電子機器100にダウンロードされる場合について説明する。
まず、協調動作についての具体的な説明に先立って、協調動作を行なうための前提となるプログラムのダウンロードについて説明する。
第12図は、親機のビデオゲーム装置1のディスク装着部3に装着された光ディスク(CD−ROM)等から供給されるビデオゲームのアプリケーションプログラムが、ビデオゲーム装置1の制御手段であるCPU51を介して、子機の携帯用電子機器100の制御手段であるマイクロコンピュータ41内の、プログラム格納手段であるプログラムメモリ部41aに直接転送(ダウンロード)される場合のデータの流れを示している。
第13図は、上記第12図のダウンロードの手順を示している。
ステップST1では、まず、親機としてのビデオゲーム装置1(以下、単に「親機」ともいう。)のディスク装着部3に装着されたCD−ROMから、子機としての携帯用電子機器100(以下、単に「子機」ともいう。)内のマイクロコンピュータ41で動作するビデオゲームのアプリケーションプログラムが、データとして読み出される。なお、前述したように、このアプリケーションプログラムは、一般に、親機のビデオゲーム装置1上で動作するものとは別のものである。
次に、ステップST2で、親機の制御手段であるCPU51は、子機の携帯用電子機器100の制御手段であるマイクロコンピュータ41に対して「プログラムダウンロード要求コマンド」を発行する。そして、CPU51はマイクロコンピュータ41から「プログラムダウンロード許可ステータス」を受け取るためにポーリングを行なう。なお、ここでいうポーリングとは、サービス要求の有無を問い合わせてサービスを行なう方法をいう。
ステップST3では、子機の携帯用電子機器100側のマイクロコンピュータ41が、親機のCPU51から「プログラムダウンロード要求コマンド」を受け取る。
そして、ステップST4で、子機側のマイクロコンピュータ41が、現在処理中のルーチンを終了してプログラムダウンロードを実行できる状態になると、親機のCPU51に対して「プログラムダウンロード許可ステータス」を返送する。
次に、ステップST5では、親機のCPU51が、子機側のマイクロコンピュータ41から「プログラムダウンロード許可ステータス」を受け取ると、ステップST1でCD−ROM等から読み出されたプログラムを、携帯用電子機器100のプログラム格納手段であるプログラムメモリ部41aに転送(ダウンロード)して書き込む。そして、CPU51はマイクロコンピュータ41から「プログラムスタート許可ステータス」を受け取るためにポーリングを行なう。
このとき、ダウンロードされたデータが書き込まれるプログラムメモリ部41aのアドレスは、マイクロコンピュータ41により管理される。また、上記の説明では、親機からダウンロードされるプログラムが、マイクロコンピュータ41内のプログラムメモリ部41aに格納される場合を例としているが、高速にデータを入力できるSRAM等の記憶素子に記憶されるようにしてもよい。
ステップST6では、メモリカードのマイクロコンピュータ41が、親機から転送されたプログラムをデータとして受け取り、プログラムメモリ部41aに書き込む。このとき、親機のCPU51からは、プログラムデータを子機の携帯用電子機器100のプログラムメモリ部41aに直接書き込んでいるように見える。また、上述したように、プログラムメモリ部41aのアドレスはマイクロコンピュータ41により管理される。
そして、ステップST7では、子機の携帯用電子機器100のマイクロコンピュータ41が、親機から最終のプログラムデータを受け取って実行できる環境にすると、「プログラムスタート許可ステータス」を本体のCPU51に返送する。
ステップST8では、親機のCPU51が、携帯用電子機器100のマイクロコンピユータ41から、「プログラムスタート許可ステータス」を受け取り、「プログラムスタートコマンド」を発行する。
そして、携帯用電子機器100のマイクロコンピュータ41は、親機のCPU51から「プログラムスタートコマンド」を受け取ると、予め決められた所定のアドレスからプログラムを動作させる。
以上の手順により、親機のビデオゲーム装置1から、それに挿着された子機の携帯用電子機器100のマイクロコンピュータ41内にあるプログラムメモリ部41aに、アプリケーションプログラムが直接転送(ダウンロード)される。
なお、前述したように、アプリケーションプログラムを供給する手段は、光ディスク等の記録媒体に限定されるものではなく、また、通信回線を介して供給されるようにしてもよい。その場合には、上記の手順についてステップST1のみが異なる。
ところで、上記のダウンロード手順は、親機のビデオゲーム装置1から、それに挿着された子機の携帯用電子機器100の制御手段であるマイクロコンピュータ41内のプログラムメモリ部41aに、アプリケーションプログラムが直接ダウンロードされる場合のダウンロード手順について説明したものである。
これに対して、親機のCPU51が、アプリケーションプログラムのデータを子機の携帯用電子機器100内の不揮発メモリ46にダウンロードした後に、そのデータをマイクロコンピュータ41内のプログラムメモリ部41aにコピーして実行する場合もある。
第14図は、このような場合のデータの流れを示している。すなわち、親機のビデオゲーム装置1のディスク装着部3に装着された光ディスク等から供給されるビデオゲームのアプリケーションプログラムは、ビデオゲーム装置1の制御手段に転送(ダウンロード)された後に、制御手段であるマイクロコンピュータ41内のプログラムメモリ部41aにコピーされて実行される。
第15図は、上記のダウンロードの手順を示している。
ステップST11では、まず、親機のビデオゲーム装置1のディスク装着部3に装着されたCD−ROMから、子機の携帯用電子機器100内のマイクロコンピュータ上で動作するビデオゲームのアプリケーションプログラムが、データとして読み出される。
そして、ステップST12で、親機の制御手段であるCPU51が、CD−ROMから読み出されたプログラムデータを、子機の携帯用電子機器100の不揮発性メモリ46に転送(ダウンロード)する。この手順は、従来のビデオゲーム装置においてデータのバックアップを行なう場合等と同様である。
次に、ステップST13で、携帯用電子機器100の制御手段であるマイクロコンピュータ41が、従来のデータバックアップと同様の手順で、親機のCPU51から転送されたアプリケーションプログラムをデータとして受け取り、不揮発メモリ46に書き込む。
次に、ステップST14及び15で、携帯用電子機器100のマイクロコンピュータ41が、親機のCPU51から「プログラムスタート要求コマンド」を受け取ると、不揮発メモリ46の上記コマンドにより指示されたアドレスから、指示されたサイズのデータをマイクロコンピュータ41内のプログラムメモリ部41aにコピーする。
そして、携帯用電子機器100のマイクロコンピュータ41は、プログラムメモリ部41aにコピーされたプログラムをそのスタートアドレスから実行を開始する。
以上の手順により、親機のビデオゲーム装置1から、それに挿着された子機の携帯用電子機器100のマイクロコンピュータ41内にあるプログラムメモリ部41aに、不揮発メモリ46を介してアプリケーションソフトウェアのプログラムがデータとして転送(ダウンロード)される。
なお、親機のビデオゲーム装置1から子機の携帯用電子機器100にダウンロードされるアプリケーションプログラムは、一般に、親機のビデオゲーム装置1上で動作するものとは別のものである。もちろん、上記のダウンロードされるアプリケーションプログラムは、ビデオゲーム装置1上及び携帯用電子機器100上の両方で動作するものであってもよい。ただし、この場合には、ビデオゲーム装置1側のCPUと、携帯用電子機器100側のマイクロコンピュータが、同じプロセッサであるという制約が生じる。
次に、親機のビデオゲーム装置1から、前述した手順でダウンロードされたアプリケーションソフトウェアのプログラムを、子機の携帯用電子機器100上で独立に実行して、その実行結果を再びビデオゲーム装置1との間でやりとりしながら行われる協調動作について説明する。
ここでは、親機のビデオゲーム装置1上で動作する、いわゆるロールプレイングゲーム等に登場する人物やキャラクタの属性データが、子機の携帯用電子機器100にダウンロードされる。なお、上記の属性データとは、成長度や性格等を表すデータである。
そして、子機の携帯用電子機器100内のマイクロコンピュータ41で実行されるプログラム上で、その登場人物やキャラクタを育てることにより、それらの属性を親機のビデオゲーム装置1の本体で実行されるプログラムとは独立に変化させる。
このような、本発明に係る実施の形態となる携帯用電子機器100は、単独で動作するように構成されており、しかも小型で携帯に便利である。
このため、使用者(ゲームプレイヤ)は、この携帯用電子機器100上で実行されるプログラムにより登場させる人物やキャラクタをいつでも持ち込んで育てることができる。また、使用者は、手元で育てた登場人物やキャラクタの属性を、携帯用電子機器100からビデオゲーム装置1の本体に転送(アップロード)することもできる。この場合には、属性が変化した登場人物やキャラクタを親機のビデオゲーム装置1上で実行されているプログラムに取り込んで動作させることもできる。
以上説明したように、親機のビデオゲーム装置1と子機の携帯用電子機器100のそれぞれにおいて、登場人物等の属性データを共有し、かつ変化させ合うことにより、協調動作を行なうことができるビデオゲームを構成できる。
次に、上述の親機のビデオゲーム装置1及び子機の携帯用電子機器100にて行われる動作を具体的に説明する。なお、以下では簡単のために、ビデオゲーム装置1を単に親機と、携帯用電子機器100を単に子機と呼ぶことにする。
続いて、子機におけるイベントの発生について内部デバイスとなることのできるような電気系について説明する。
子機では内部デバイスにイベントが発生するとイベント発生という事象を記憶しておき、親機からの要求によりイベント発生を子機に伝えることができるので、操作の起源が親機だけでなく、内部デバイスとなることもできる。
また、外部デバイスも、赤外線通信という内部デバイスを介することにより、動作の起源となることもできる。
例えば、子機の赤外線受光部が受光すると、それを検出するプログラムであるいわゆる常駐部が検出し、その対応をステータスとして親機に送る。
子機側としても、イベントが発生したらそのステータスを親機に返したいところであるが、親機からステータス要求のコマンドがないと、ステータスを返すことはできないので、子機と親機間も常時ステータス要求コマンドを使って監視し続けている必要がある。しかし、外見上では自動的にステータスが送られるような形になっている。
子機にはイベントが発生したかどうかを調べるためのコマンドが用意されており、そのコマンドを繰り返し呼ぶことでイベントの発生状況を監視することができる。イベントが発生していればイベントを取得して、イベント内容によって様々な動作を行なう。
このコマンドにより、今までは親機のコマンドに反応するだけであったものが子機側から何らかの動作を開始させることができるようになる。
子機の中で、イベントの発生するものは、赤外ブロック、スピーカ、マイク、時計などの付属のデバイス、及び子機上のプログラムがある。これら付属のデバイス及びプログラムが何かを起こしたい旨を親機に伝えることができるようになる。
例えば、「何時何分になったら・・・をしたい」とか、「音声を検出したら・・・」とか「他の子機からの赤外線通信で・・・が受信されたら・・・」とかいったような使い方ができる。
上述のような関係を、第16図に示すブロック図を参照して説明する。
外部デバイスである外部リモコンのデータは、子機において受光部からの受信データとなり、親機へのデータとなる。また、子機内部のイベント発生も親機へのデータとなり、親機により読み出される。
すなわち、これらのイベントが発生すると、親機においてはイベント発生が"YES"としてイベント発生の工程を実行する。そして、子機に対して読み出し要求を発して子機における親機へのデータを読み出しデータとして読み出す。
一方、上記のようなイベントが発生しない場合には、親機においてはイベント発生"NO"としてイベント発生の処理を実行しない。
ここで、イベント発生要因との関連におけるプロトコルについて、第17図を参照して説明する。
ここでは、イベントの発生要因として、リモコン、時計及び音声が挙げられている。これらは、子機のファームウエアに通信される。
すなわち、リモコンはリモコン送受信部を、時計はアラームを、音声はマイクを、それぞれ介して子機側のファームウエアに送られる。
続いて、子機のファームウエアの工程の一例について、第18図に示すフローチャートを参照して説明する。
最初のステップS111においては、イベント発生要因との通信によりイベントを監視する。次のステップS112においては、イベントの発生を監視する。
そして、イベントの発生があった場合には"YES"としてステップS113に進み、イベントの発生がなかった場合には"NO"としてステップS111に戻る。
ステップS113においては、イベントを蓄積する。そして、ステップS111に戻る。
続いて、子機のファームウエアの工程の他の例について、第19図に示すフローチャートを参照して説明する。
最初のステップS121においては親機からの通信について通信ポートを監視する。そして、次のステップS122に進む。
ステップS122においては、親機からの通信に応じて分岐する。すなわち、親機からの通信がイベント要求の場合には"YES"としてステップS125に進み、そうでない場合には"NO"としてステップS123に進む。
ステップS125においては、イベント蓄積情報を親機に送信し、この一連の工程を終了する。
ステップS123においては、親機からの通信がイベント取得要求であるか否かに応じて分岐する。すなわち、親機からの通信がイベント取得要求である場合には"YES"としてステップS124に進み、そうでない場合には"NO"としてステップS121に進む。
ステップS124においては、イベント内容を親機に送信し、この一連の工程を終了する。
続いて、親機側における一連の工程について、第20図を参照して説明する。
最初のステップS131においては、子機との通信によりイベント調査を行なう。そして、次のステップS132に進む。
ステップS132においては、イベントの有無により分岐する。すなわち、イベントがある場合には"YES"としてステップS133に進み、イベントがない場合には"NO"としてステップS131に戻る。
ステップS133においては子機との通信によりイベントを取得し、次のステップS134においてはイベントに対して反応する。そして、ステップS131に戻る。
ここで、上述の形態との比較のために、従来のプロトコルによる通信について簡単に説明する。子機側の工程については、第21図に示すように、最初のステップS141においては、親機からのデータについて通信ポートを監視する。そして、次のステップS142に進む。
ステップS142においては、親機から読み出し要求があったか否かについて分岐する。すなわち、読み出し要求があった場合には"YES"としてステップS144に進み、読み出し要求がなかった場合には"N0"としてステップS143に進む。
ステップS143においては、親機から書き込み要求があったか否かによって分岐する。すなわち親機から書き込み要求があった場合には"YES"としてステップS145に進み、書き込み要求がなかった場合には"NO"としてステップS141に戻る。
ステップS144においては、親機にデータを返送する。そして、ステップS141に戻る。
ステップS145においては、親機からのデータを受信する。そして、ステップS141に戻る。
続いて、親機側におけるプロトコルの通信について、第22図を参照して説明する。
データ読み出しの場合には、第22図中のAに示すように、子機にデータ要求を送り、このデータ要求の結果として子機から送られたデータを受信する。
データ書き込みの場合には、第22図中のBに示すように、子機にデータ通信許可を問い合わせる。そして、データ通信が許可された場合には、子機にデータを送信する。
次に、上述のような親機と子機との間の通信との関連において用いられるプロトコルについて、具体的に説明する。
最初に、プロトコル名を定義する。親機と子機との通信に用いるプロトコルをコントローラ・プロトコルと呼び、CPと略すことにする。また、4バイト目の親機コマンドとして00しか受け付けないプロトコルをCPI.0と呼び、00に加えて01〜03のコマンドも解釈できるプロトコルをCP2.0と呼ぶ。
リード時のCP1.0は、次の表1に示すようになる。
表1
CP1.0
リード時
ライト時のCP1.0は、次の表2に示すようになる。
表2
CP1.0
ライト時
ここで、"zz"はハイインピーダンス又は不定を、"Stat"はメモリカードステータスを、"SecH"及び"SecL"はセクタ番号high及びlowをそれぞれ表している。
続いて、CP2.0の専用プロトコルは、次の表3に示すようになる。
表3
CP2.0
専用プロトコル
表3においては、親機の2バイト目の値である"52"は読み出し、"57"は書き込みをそれぞれ表している。
ここでは、コマンド毎にメモリカードが準備しているデータ長を"Size"で返し、tx(n)/rx(n)が〔size〕バイト続いて通信が終了する。
コマンド"Cmd"としては、"01"はメモリカードインフォメーション、"02"は待避コンテキストの読み書き、"03"はメモリカードに付属のデバイス情報取得、"04"はメモリカード付属デバイス読み書き、が用いられる。
次に各区コマンド実行時の通信内容を示す。子機の情報としては、次の表4に示すようになる。この内容は、読み出し専用である。
表4
read only
ここで、"rev"は子機のファームウエアリビジョンコードを表している。
例えば、CP2.0rev1.0については"01"である。
また、"sn3"〜"sn0"はメモリカードシリアル番号、"blk1"〜"blk0"は記憶可能ブロック数をそれぞれ表している。なお、1ブロックは8kbyteである。
そして、"alt1"〜"alt0"は代替セクタ数、"dev"はメモリカード付属のデバイス数をそれぞれ表している。
続いて、待避コンテキストの読み書きについて説明する。待避コンテキストに関するプロトコルは、読み出し時には次の表5に示すように、書き込み時には表6に示すようになる。
表5
read時
ここで、"run"は、親機モードになる直前の状態または親機モードを抜けた後に移行する状態を表している。すなわち、"0"はスリープ、"1"は時計表示、"2"は親機モードの直前状態への"resume"、"3"は指定アドレスからのメモリカードアプリケーション実行を示している。
また、"top"は実行された又は実行するアプリの先頭が格納されているブロック番号、"start"は親機モードを抜けた後に実行を開始する、すなわちメモリ管理ユニット(memory management unit;MMU)で再配置されたあとのアドレス、"arg1"〜"arg4"はアプリケーション実行開始時に渡す引数をそれぞれ示している。なお、上記引数は、引数として使うレジスタに代入される。
続いて、子機に付属のデバイス情報取得に用いるプロトコルを、次の表7に示す。このデバイス情報取得に用いるプロトコルは、読み出し専用である。
表7
read only
ここで、"dev"はデバイス分類番号、"size"はデバイスに読み書きするデータサイズを示している。すなわち、"0"は128バイト固定、"1"〜"127"はsizeバイト固定、"−1"〜"−128"は1〜(−size)バイト可変をそれぞれ表す。
続いて、デバイスの名称と、そのデータ構造を、次の表8に示す。
表8
すなわち、番号"1"は時計、"2"は赤外線リモコン"3"はスピーカ/マイクの4ビットのPCMデータ、"4"はブザー用のDTMF、"5"はLCDバックライト、"6"は電池電圧LOW検出にそれぞれ対応している。
続いて、子機の付属デバイスの読み書きに用いられるプロトコルについて、次の表9及び表10に示す。
表9
read時
ここで、"dev"はデバイス分類番号、"rx1"〜は読み出しデータ、"tx1"〜は書き込みデータ、"size"は書き込み希望データサイズをそれぞれ表している。この書き込みデータサイズは、可変調データのときのみ有効である。
上述のプロトコルの実際の通信には、赤外線を伝達媒体として用いる、いわゆる赤外線プロトコルを利用することができる。この赤外線リモコンプロトコルについて説明する。
データ送受信のために用意するコマンドとしては、送信中フラグ及び受信中フラグがある。
この赤外線プロトコルに用いられるInfo要求、すなわち情報要求は、使用形態や、装置種類、シリアル番号でマスクをかけてInfo要求コマンドを発行すると、そのマスクに該当する装置が一斉に応答して情報を返す。
このとき応答される情報としては、単体で使用されているか、親機のコントローラ端子に接続されているか、親機のメモリカード端子に接続されているか、親機のSIO端子に接続されているかといった使用形態、親機、子機、赤外受光機のいずれであるかという装置種類、シリアル番号、ファームウエアリビジョン番号、付属デバイス相当等がある。
ここで、先に応答が始まっている装置がある場合には、その応答が終了するまで新たな応答を待つ。
動作中に信号が途絶えて、音が鳴りっぱなしにならないように自動的に停止しないデバイスについては必ず動作時間を設定できるようにする。
続いて、プログラムとデータの識別について説明する。
実行プログラムはデータと同じようにコマンド"00"で読み書きする。ではデータと、プログラムをどのように区別するかというと、メモリカードの最初のブロックがFATになっており、各ブロックについて128バイトのデータ領域があるが、現状では32バイトしか使っていないので空いている領域に新しい情報をつけ加える。
現行のライブラリでは32バイトを越えた部分の読み書きはできないのでゲームディスクから直接書かれたデータ以外(OSDでコピーしたもの)にはプログラム識別フラグを立てることはできない。
フラッシュメモリの部分にMMUが付いていると仮定した場合、追加する情報は、実アドレス情報、プログラム/データ識別フラグである。
MMUが付けられない場合は、実行できるのはブロック1から始まる連続のプログラムのみになるので、「実アドレス情報」は不要だが、ブロック1からの領域を空けるために、ゴミ集め(Garbage collect)的な機能をファームウエア的内に用意する必要がある。これは、親機との通信によってデータ転送をすると遅いためである。
代替セクタが使われていると、アプリケーションのコードが連続しなくなるのでアプリケーションのアクセスする領域としては使えない。そのブロックにはアプリケーションのコードは書き込めないし、それによる容量不足で書ききれないときにはその音を表示などしなくてはいけない。アプリケーションが書き込まれたままの状態でも、フラッシュメモリの耐用回数による書き込み不良を防ぐため定期的にデータ領域の書き込みチェックを必要とする。
上述のように、子機においては、イベントが発生したかどうかを調べるためのコマンドが用意されており、そのコマンドを繰り返し呼ぶことでイベントの発生状況を監視することができる。
イベントが発生していなければ、そのイベント監視用コマンドを再度呼び、イベントが発生していればイベントを取得して、イベントの内容によってさまざまな動作を行なう。
このコマンドにより、今までは親機のコマンドに反応するだけであったてものがメモリカード側から何らかの動作を開始させることができるようになる。
子機の中で、イベントを発生するものは、"赤外通信ブロック、スピーカ、マイク、時計"などの"付属のデバイス"及びメモリカード上でのプログラムがあるが、これら自身が何かを起こしたい旨を親機に伝えることができるようになる。
例えば、"何時何分になったら・・・をしたい"とか、"音声を検出したら・・・"言ったような使い方ができる。
次に、アドレスマッピングされているFATシステムを用いた、記録デバイス上におけるプログラムの直接の起動について説明する。
この記録デバイス上におけるプログラムの直接の起動は、第23図に示すように、CPU201からメモリ203を操作する際に、ファイル管理テーブル(file allocation table;FAT)システムを用いるアドレス変換202を行なうことにより、メモリ上で不連続なアドレスを連続に見せるものである。
アドレス変換部202においては、メモリ上にて不連続に並んだブロック1、ブロック2及びブロック3を、アドレスを変換することにより、連続に並んだブロック1、ブロック2及びブロック3としてCPU201に見せかけている。
ここでブロックとは、メモリ203における記憶情報の所定の単位である。
このようなFATシステムを用いたアドレス変換により、従来にはプログラムを実行する際には、第24図中のAに示すように、bに示す不連続に並んだブロックをaに示すように連続に並べ換えていたのを、第24図中のBにおけるaに示すように、見かけ上は連続に並んでいるのでそのまま実行することができる。
続いて、このアドレス変換についての一連の工程について、第25図に示すフローチャートを参照して説明する。
最初のステップS11においてはファイルを指定し、ステップS12においてはアドレスを指定し、ステップS13においては先頭セクタ情報を取得し、ステップS14においてはセクタの先頭アドレスを保存する。そして、ステップS15に進む。
ステップS15においては、セクタが最終アドレスであるか否かに応じて分岐する。すなわち、セクタが最終アドレスである場合には"YES"としてステップS17に進み、セクタが最終アドレスでない場合には"NO"としてステップS16に進む。
ステップS16においては、次のセクタの情報を取得する。そして、ステップS14に進む。
ステップS17においてはn=0と設定し、ステップS18においてはMMUにアドレスKnをアドレスMとして設定する。そして、ステップS19に進む。
ステップS19においては、nが最終アドレスであるか否かに応じて分岐する。すなわち、nが対象ファイルの最終アドレスの場合には、"YES"としてステップS22に進み、そうでない場合には"N0"としてステップS20に進む。
ステップS20においてはn=n+1と設定し、ステップS21においてはM=M+Sと設定する。そして、ステップS18に進む。
ステップS22においては、プログラムを実行する。そして、この一連の工程を終了する。
なお、上述したようなFATにおけるアドレス変換によるメモリ上におけるプログラムの直接の実行は、通常は子機において行われるが、本発明はこれに限定されない。例えば、一般の情報機器に対しても利用することができる。