JPH09506201A - マルチプラットフォームインタプリタを含むアプリケーションプログラムを有する与えられたマスデータを受けるマルチメディアシステムと、マルチプラットフォームインタプリタとの相互作用のために配されるプラットフォーム副システムと、このようなシステム又はこのような副システムで用いるためのマスメモリ - Google Patents

Abstract

(57)【要約】 マルチメディアシステムは、アプリケーションプログラムタイトルを有し、またマルチプラットフォームインタプリタをも有する。前記アプリケーションプログラムは、スクリプト言語とマルチメディアデータとの両方で述べられるアプリケーションを含む。プラットフォーム副システムは、前記アプリケーションプログラムタイトルと相互作用し、前記アプリケーションプログラムとインタプリタとをアクセスする。ユーザ入力手段の制御の下、アプリケーションプログラムを実行する。またユーザ用表示とオーディオ副システムとは、前記アプリケーションプログラムにより制御される。前記アプリケーションプログラムは、前記マルチプラットフォームインタプリタを使って、処理手段により翻訳される命令セットに基づく。前記プラットフォームは、量的な最小の要件に従ってあらかじめ定められた命令セット、データタイプセット及びリソース設備を持ってあらかじめ特定されたアブストラクトマシンの例である。

Description

【発明の詳細な説明】 マルチプラットフォームインタプリタを含むアプリケーションプログラムを有 する与えられたマスデータを受けるマルチメディアシステムと、マルチプラット フォームインタプリタとの相互作用のために配されるプラットフォーム副システ ムと、このようなシステム又はこのような副システムで用いるためのマスメモリ 技術分野 本発明は、データがマルチプラットフォームインタプリタを含むアプリケーシ ョンプログラムを有する与えられたマスデータを受けるマルチメディアシステム に関し、さらにプラットフォーム副システムを持ち、前記マルチプラットフォー ムインタプリタとの相互作用のために配され、ユーザ入力手段の制御下前記アプ リケーションプログラムにより駆動される前記マルチプラットフォームインタプ リタを実行するための処理手段を有し、さらにまた前記マルチプラットフォーム インタプリタにより制御可能なユーザ出力手段を持つマルチメディアシステムに 関する。 背景技術 マスデータは、光学ディスクのような完備されたマスメモリ上に物理的にあっ てもよい。他に、それは離隔接続又はチャネルを介して対話構造内にあってもよ い。マルチメディアは、前記副システムが一つ以上のカテゴリの信号を受け、処 理し、出力してもよく、このようなカテゴリは例えば英数字テキスト、図形、ス ピーチ、音楽、及び他の可能性あるものであることを意味する。アプリケーショ ンプログラム又は略してアプリケーションの主題は、ビデオゲーム、百科事典の ような教育又は情報の項目、個人のファイリングシステムのための概要等のよう にいろいろあってもよい。各種のこのようなプラットフォームは、ＣＤ−Ｉマシ ン及びパーソナルコンピュータのように商業化されている。一般にＣＤ−Ｉ標準 及びコンパクトディスク標準に関して、１９９４年のACM/Springer Multimedia System，Vol.2，No.4,１５７頁から１７１頁、Jan Korst，Verus Pronk著の論文 ”Compact Disc Standards”を参照されるべきであり、この論文はこのような標 準の以前に出版された各種の仕様書のレビューである。 前記アプリケーションプログラムは、従来タイトルと呼ばれ、各種のこのよう なタイトルは、タイトルが副システムの特別の（他のものではない）タイプ又は ブランド上でプレイされるやり方で、副システムハードウェアの製造業者又は他 の者により提供される。これらは、このように特別のプラットフォームである。 潜在的に大きな顧客ベースとして、各種の異なるタイプのプラットフォーム上で プレイできるアプリケーションプログラムのニーズが感じられてきた。 発明の開示 従って、本発明の目的は、蓄積された情報の適当な部分がデータ形式と調和し 、各種の異なるプラットフォーム副システム上で翻訳可能にして、特定のプラッ トフォームを少なくするアプリケーションプログラムをつくることである。本発 明は、特には、ある環境下で引き渡しプラットフォームによりいくつかの実時間 変換を必要とするけれども、多くのプラットフォームによりプレイ可能なマルチ メディアデータのための形式を定めることにより、異なるプラットフォーム上で 翻訳可能なプログラムを作ることが可能であることを見い出した。さらに、たと えバルクのマルチメディアデータが一度だけタイトル内にあるとしても、プラッ トフォーム特別の形式内のいくつかのデータを持つことが利益があることがわか る。本発明の付加の目的は、創作プラットフォームと再生プラットフォームとの デカップリングである。今、この観点に従うと、本発明は、前記アプリケーショ ンプログラムが実行のための処理手段により翻訳されるあらかじめ決められた命 令セットに基づくということを特徴とし、これにより前記プラットフォーム副シ ステムは、前記あらかじめ決められた命令セット、あらかじめ決められたデータ タイプセットを持ち、さらに量的な最小の要件に従うリソース設備を有するあら かじめ特定されたアブストラクトマシンである。特に、マルチプラットフォーム マルチメディアタイトルの創作は、プラットフォーム独立のマルチメディアタイ トルに対して意図される。上記のように、各種の実際の表現又は実現化の例があ る。 各例は、各種の最小の設備を持つが、各種の例は適当に異なってもよい。 本発明はまた、プラットフォーム依存のプリミティブの位置アドレスを有する ディスパッチテーブル（Ａ）と、実行可能であり翻訳可能であるコードを蓄積す るための前記位置アドレスにより番地付け可能な全ての位置を含むカーネル領域 （Ｂ）と、プラットフォーム独立及びタイトル独立であるコードを含む第１の領 域（Ｃ）とタイトル依存のコードを含む第２の領域（Ｄ）とを持つ拡張カーネル 領域（Ｃ＋Ｄ）とを有するシステムでの使用のためのマルチプラットフォームイ ンタプリタを有する完備されたマスメモリに関係する。要素のこの配置は、真っ 直ぐに、容易にアクセスでき且つ規定誤差を少なくすることがわかった。 本発明はまた、このようなタイトルを有し、前記マルチプラットフォームイン タプリタをローディングするためのロード手段を持ち、マスデータとの相互作用 に対して配されるプラットフォーム副システムに関する。 図面の簡単な説明 本発明のこれらのこと及び他の観点と利点とは、これ以降好ましい実施例の開 示と、特に図を参照して詳細に述べられるだろう。第１図は各種のプログラムタ イプの機能的位置の図であり、第２図は翻訳アプローチの図であり、第３図はＣ ＰＦ引き渡しプラットフォームを示し、第４図はＣＰＦランタイムシステムを示 し、第５図はＦＯＲＴＨインタプリタのためのメモリレイアウトを示し、テーブ ル１から８までは種々の典型的プログラムモジュールを与える。 発明を実施するための最良の形態 第１図は本発明における好ましい実施例での使用のための種々のプログラムタ イプの機能的位置の例示である。異なるやり方で明瞭に述べられる本発明の目的 は、いわゆる共通の発行形式（Common Publishing Format）を達成することであ るので、発行されるタイトルは、異なるプラットフォーム副システム又はハード ウェア装置上で実演されるこれらを許容するために最小の束縛条件だけを付ける ことを必要とする。種々の、いわゆる価値あるもの（アセット）、例えばあらか じめ決められたマルチメディア形式及び独立処理プログラムコードでともに表さ れる画像、音、構成、キャラクタフォント等は、タイトルを形成する。本発明に より、各異なる想像されたプラットフォームのために個別に全ての材料を単一の マスメモリに蓄積する必要性が避けられる。タイトルのアセットは、ユーザは見 たり聞いたりしてもよい要素である。前記プログラムコードは、特定の要件に応 じるプラットフォーム副システムで翻訳可能である。前記コードは、各々が明ら かな意味を持つ短い形式の命令又はトークンを含む。これらが書き込まれる言語 は、ＣＰＦ−Ｓｃｒｉｐｔ（スクリプト）と呼ばれ、これは１９９４年オランダ においてフィリップス・エレクトロニクス・エヌ・ヴィが著作権を有するOSMOSE プロジェクトのESPRITプロジェクト6788出版バージョン1.0のレポートに開示さ れている。これらのトークンのいくつかは、コンピュータ及び関係するハードウ ェアでの高い処理速度と比較して、人間の知覚及び表現の相対的緩慢さのため、 特に処理の実行と比較して相対的に多くの時間を費やす視聴側の効果を生じる。 全ての要件を特定するために、いわゆる「アブストラクトマシン（abstract mac hine）」が定義される。このようなアブストラクトマシンは、あらかじめ決めら れた命令セット、データタイプセット及び量的な最小の要件にあうリソース設備 を持つ。少なくともこれらの設備を持つどんな真の装置又はプラットフォームも 、問題となるタイトルを実行する。このような設備は、操作速度、メモリ容量、 Ｉ／Ｏ（表示、音）、操作システム特徴及び対応する多くの他のもので表される 。第１図において、円２０はＣＰＦスクリプトへ翻訳する全てのプログラムを象 徴する（当該円の大きさは、これらのプログラムの数及び大きさとトータル的に は無関係である）。これらのプログラムの実際の書き込みは、わずかに狭い機能 を代償として、ＣＰＦスクリプトのプログラムの著者に対してより容易にする公 認された言語の使用を通じてなされる。プログラム結果は円２２により表される 。円２０内のプログラムの編集及び配置を、アブストラクトＣＰＦマシン（Abst ract CPF Machine）により実行できる全ての可能なＣＰＦスクリプトプログラム を含む円２６内になす。この周りの円２４は、プログラムがＣＰＦスクリプト内 にあるべきであるという束縛条件なしに、この装置により実行できる可能性ある 全てのプログラムを象徴する。円の組２８／３０と３２／３４とは、二つの任意 の異なるプラットフォーム副システムと関連する。内側の円３０、３４は円２４ か らの配置を表す。外側の円２８、３２は、内側の円が前記アブストラクトマシン により実行できない外側の全ての実行可能なプログラムのセットを象徴する。再 び、示されるように各円の直径は好ましくは任意的である。その上、種々のプラ ットフォーム副システムに対する内側の円の内容が識別性があるにもかかわらず 、前記外側の円の内容は識別性がある必要はない。 本発明のメインゴールは、前記アブストラクトマシンの導入を通じて効果的で ある真の又は物理的プラットフォームから抽象化することをタイトル開発者に許 容することである。このアブストラクトマシンは、プログラムを実行するときの プラットフォーム副システムの最小限の振る舞いと同様に、例えば音とビデオの 出力能力、ＣＤ−ＲＯＭ／ＸＡのインタフェース性、Ｋｏｒｓｔ等による参考文 献を参照して、タイマ機能、ユーザ入力装置、その命令セット、サポートされる べきデータタイプ、に関する最小限のリソース要件を定める。真のプラットフォ ームは、前記アブストラクトマシンの命令セットの実行を通じていわゆるＣＰＦ スクリプトプログラムを再生可能にすべきである。ＣＰＦスクリプト内の正しい プログラムと間違ったプログラムとの間の区別は、そのようなプログラムに適合 テスト（conformance test）を与えることによりなされる。同じ理由で、正しい プラットフォームと間違ったプラットフォームとの識別のためにハードウェア開 発者に供与される有効性テスト（validation test）がある。これは、プラット フォームの能力が充分であるかどうかのテストである。このような有効性テスト の実際的な実現化は、一組の適切なプログラムを規定することであり、問題とな るプラットフォーム上での再生可能なものとそうでないものとのテストである。 第２図は、翻訳アプローチの図である。本発明により採られるアプローチは、 データ形式を調和させることであり、異なるプラットフォーム上で翻訳可能なプ ログラムを作ることである。一般に、引き渡しプラットフォームで実時間でのい くつかの変換を必要とするかもしれないけれども、多くのプラットフォームで実 演できるマルチメディアデータ形式を定めることが可能である。いくつかのデー タは、二つ又はそれ以上のデータ形式内にまだなければならないかもしれない。 さらに、実際のアプリケーションプログラムは、高レベルの表示内にあるべきで あり、それから前記引き渡しプラットフォームにより翻訳される。特別のプラッ トフォームに特定される（使用するかこれらの設備により使用される）設備に属 するような数個の特別な機能は、当のプラットフォームに対する特定のやり方で コード化されなければならない。第２図のセットアップにおいて、ブロック３８ はＣＰＦプログラムを象徴する。レベル４０は、各引き渡しプラットフォームに 対する一つの特定のカーネルインタプリタを示す。これらカーネル４０は、（各 プラットフォームに対して同じプログラムである）当該ＣＰＦプログラムをプラ ットフォームに独立なインタフェースコールへ翻訳する。この実行は、ＣＰＦア ブストラクトマシンを形成する。 プラットフォーム独立のＣＰＦタイトルに次いで、各プラットフォームタイプ は、その特別なプラットフォームのために特定される一つ又はそれ以上のタイト ルを持ってもよい。これらのプラットフォームの利点は、これらの専念された又 は特定のハードウェアによるかもしれない。従って、プラットフォームの独立性 を得るために、前記プログラムは低レベルのシステムの機能から抽象化する。こ れはある程度まで前記ＣＰＦ機能が、それらによりとられた各プラットフォーム のそれよりいくらか劣るということを意味する。インタプリタ４０の出力は、各 々は異なるプラットフォーム、特にパソコン４６、ＣＤ−Ｉプレーヤ４８を表す コラム４２から４８の適当な一つに与えられる。現実的には、当のプラットフォ ームは、ライブラリ（ＣＰＦ．ＤＬＬ，ＣＰＦ．ＬＩＢ）、操作システム（マイ クロソフトウィンドウズ、ＣＤ−ＲＴＯＳ：米国Microware,Des Moines,Iowa,に より出ているコンパクトディスクリアルタイム操作システム（Compact Disc Rea l-Time Operating System））及び適切なハードウェア（マルチメディアＰＣハ ードウェア、ＣＤ−Ｉハードウェア）を持つ。上記場合には、ＤＬＬはウィンド ウズ下のダイナミックリンクライブラリ（Dynamic Link Library under Windows ）であり、ＬＩＢはＣＤ．ＲＴＯＳライブラリである。左の方のプラットフォー ム４２、４４に対して、各副システムの中のシーケンスが、対応する。 第３図は、ロードされ操作されるアプリケーションプログラムを持つＣＰＦ引 き渡しプラットフォームを示す。各形態（コンフィグレーション）は、ハンドラ レベルで利用可能な現在のプラットフォーム能力のダイアグラムの次の高いレベ ルを通る。レベル６０は前記アプリケーションプログラム自身を含み、これは前 記アブストラクトマシンの識別例の間だけでなく、第２図で説明されたように識 別されない例の間でもポータブルである。プログラム又はタイトルは、ＣＰＦス クリプトで明瞭に表され、レイヤ６０は物理的ディスクの抽象的概念である。次 のレベルは、インタプリタ６２とプラットフォーム特定であるランタイムライブ ラリ６４とを含む。次の低いレベルに対して、これらはマルチメディアハンドラ インタフェースを持つ。当該次の低いレベルは、６８から７４の一組のハンドラ と、当のレベル内にある効果的組織を次の高いレベルへ通すための小さな形態機 能とを含む。前記ハンドラのセットアップは、特別の形態であり例示のようにデ ータ及び装置ハンドラ６８と、ディスクハンドラ７０と、音及び／又はビデオ表 示との相互作用のための提示ハンドラ７２と、ユーティリティハンドラ７４とが ある。現在のコンテキストにおいて、これらのユーティリティは、図式入力機構 のような他の設備により実現されてもよい。次の低いレベルに対して、前記ハン ドラは、装置の駆動インタフェースを持つ。それ自身従来のものなので、このよ うなハンドラは各々、一つ又はそれ以上のソフトウェアモジュールを有し、入力 の各種の一般的目的のための制御ステートメントとして受け、当該装置のレベル 上に要素的操作を定める各シーケンスの表示内にこれらを翻訳する。次の低いレ ベルに対して、ハンドラは、前記装置駆動器へのインタフェースを持つ。前記次 の低いレベル自身は、装置駆動器７８、及びそのレベル内にある組織化を前記次 の高いレベルへ通すためのコンフィギュレーション機能を持つ。当該装置は、そ れ自身従来のものであり、各々は前記次の高いレベルにより発生される前記表示 に応答し、電気機械的に、電気的に、及び当の装置の可能性ある大きさ決めによ り決められるように、前記装置上の動作へこれらを翻訳する。前記次の低いレベ ルに対して、ハードウェアプラットフォームは、ハードウェアシステムバスを有 する。制限のない例により、各種の装置は、指示装置のようなユーザインタフェ ース装置と相互作用を許容するアナログ装置８０と、上記Korstらの文献で定め られ、前記アセットのローディング、当のタイトルの実時間での再生を許容する ためにロードされたＣＤ−ＲＯＭからの可能なアプリケーションを許容するCD-R OM/XA装置８２と、データベース又は信号処理のような各種の機能を実行する一 般の目的の処理装置８４と、光ディスクのような局地的に存在する単一のメモリ 媒体 のかわりに、離れた場所に行くようにテレコミュニケーションチャネルを介して マスデータを受けるために用いられてもよい（テレ）コミュニケーション装置８ ６とを知るために、次の低いレベル上に示される。このようなデータは、自主的 にあるか又は前記プラットフォーム副システム又は副装置による命令上にあって もよい。最終の要素は、音響装置、ビデオ表示装置、又はそれらの副システムの ようなプレゼンテーション装置８８である。示された装置は、直接物理的リンク により相互接続されてもよい。 第４図は、ＣＰＦランタイムシステムを示し、実際本発明によるアプリケーシ ョンプログラムを処理し、オーディオ、ビデオ及び制御レベルでの相互作用を含 んで前記ＣＰＦ形式に準じる実行モデルである。示されるように、制御チャネル は、制御信号Ｃを運び、データチャネルはデータ信号Ｄを運び、そしてタイミン グチャネルはタイミング信号Ｔを運ぶ。中央の命令及びデータのメモリボックス １００は、アプリケーションプログラムを表し、翻訳プログラム１０２と直接相 互作用し、後者はアプリケーションプログラム自身と同じタイトルの部分として プラットフォームへも与えられる。ボックス１００へ入る外部のＣ＆Ｄ入力１０ １は、インタプリタにより発行された命令からその低いレベルのハードウェアへ の結果として、低いレベルのプラットフォームハードウェアから発するマルチメ ディアアセットをとりわけ表すパラメータに従って、ＣＰＦスクリプトの言語構 造を表す。当該図のシェードされた中心部は、当該システムのプラットフォーム に依存した部分を表し、一方で外側のブロックは当該システムのプラットフォー ムと独立した部分を表す。特筆すべきは、当該図はＣＤ／ＲＯＭ（ＸＡ）ソフト ウェアブロック１０８、ＣＤ／ＲＯＭ（ＸＡ）ハードウェアブロック１１６、Ｃ Ｄ／ＲＯＭ（ＸＡ）ドライブ１２２、オーディオソフトウェア１０６、オーディ オハードウェア１１４、オーディオバッファ１０４、及びオーディオ出力構造１ ２０と、ビデオソフトウェア１１０、ビデオハードウェア１１８、ビデオバッフ ァ１１２及びビデオ出力構造１２４とを有する。明瞭にするために、ユーザ制御 行為は、この図内には示されていない。特に、オーディオ及びビデオデータの流 れは、前記ボックス１００を通らない、なぜならばこれはオーバヘッド且つ関連 する遅い操作を生じるからである。実時間でない操作モードにおいて、タイトル はオーディオ、ビデオ及び制御ファイルを持ち、当該制御ファイルは他の装置へ 転送すべきファイルがどれかを知るための充分な情報を含む。他方、実時間操作 モードにおいて、オーディオ、ビデオ及び制御のインタリーブ化された組を含む 実時間ファイルがある。前記インタプリタ内のハンドラは、所望の位置への転送 のためにこれらの組の中から選択処理するだけでなく、同時に正しいオーディオ 及びビデオ関連機能をこれらの組へ割り当てる。当該図内に示されるタイミング 情報は、下にあるハードウェアの機能レベルに依存して各種の操作を同期化でき る。 プラットフォーム独立のＦＯＲＴＨ辞書 これ以降、よくドキュメントされた（言語をプログラムする各種のテキストブ ック）言語ＦＯＲＴＨのための一組のインタプリタが、入力から出力へのマッピ ングを基に述べられる。簡潔にするため、ＦＯＲＴＨ言語自体は、表現的には考 慮されない。インタプリタは、命令を翻訳し、それらの中で呼ばれるアセットを フェッチし、ライブラリからの関連項目を呼ぶ。各異なるプラットフォームに対 して、命令の同じソースファイルのセットがあり、これはアセットをなさせる。 原則として、少なくとも二つのこのようなインタプリタが必要であり、一般に一 つは操作システムＤＯＳ／Ｗｉｎｄｏｗｓ３．１下のＰＣのためであり、もう一 つはＣＤ−ＲＴＯＳ下のＣＤＩプレーヤのためのものである。他の現実的プラッ トフォームは、アップルのマッキントッシュ装置かもしれない。第５図は、この ようなＦＯＲＴＨインタプリタのためのメモリレイアウトを示す。この操作は、 これ以降述べられる。前記メモリレイアウトは、メモリ配置のコラムとして示さ れる。第５図のメモリマップに関して、前記インタプリタは、間接的にスレッデ ッドされるとする。この後者の特性は、最初に辞書の中で利用可能な直接スレッ デッドコードへポイントを供給する間接の又はディスパッチテーブルがアクセス されなければならず、それから翻訳が直ぐに開始することを意味する。前記メモ リ内において、部分１４０は、呼び出し可能なＦＯＲＴＨアドレスのテーブル又 は機械（プラットフォーム）依存のプリミィティブ（Ａ）のｃｆａ’ｓ又は当の マシン上で実行するのに可能な要素的操作を含む。部分Ａは、ディスパッチのテ ーブルであり、ローディング中に部分Ｃ＋Ｄ内の規定と部分Ｂ内の機械依存命令 との間の間接的番地付け特徴を通じて束縛を供給する。部分Ｃ＋Ｄ内の紹介は、 部分Ｂ内の関連機械依存命令を見つけるために部分Ａ内のこのテーブルを使う。 部分１４０の各要素はメモリ部分１４２のそのセグメントにポイント付けし、そ れは各種の機械依存プリミィティブ（Ｂ）の実行を含む。これは、前記インタプ リタの心臓部であり、全てのコード（CODE）（実行可能なアセンブリコード）と 、コード（CODE）（Ｆｏｒｔｈの翻訳可能なコード）、番地のためのインタプリ タ及び初期化コードを含む。このテーブルは、前記タイトルの機械的独立部分を ローディングするとき、また前記タイトルの作成中、前記辞書のこの部分を保存 する（蓄える）とき、用いられる。部分Ａ及びＢは、タイトルの機械的依存部分 を表す。従って、タイトルの相対的最小量の実現化は、少なくとも二つの異なる ハードウェアプラットフォームに対するマルチプラットフォームタイトルを構成 するために、部分Ａ及びＢの二つのバージョンを含む。部分Ｃ及びＤは、前記タ イトルの前記機械的独立コードを含む。ここに、部分Ｃは、各タイトル内にある タイトル独立且つ機械的独立コードを含む。部分Ｄは、タイトル依存コードを含 み、当該タイトル依存コードが作られるとき全体の作成工程の一部として発生さ れるだろう。 前記辞書を保存するとき、部分Ａ＋Ｂは、サポートされなければならない各異 なるプラットフォームに対する一つのバージョンとともに、最初のシングルファ イル内に蓄積される。次に、部分Ｃ＋Ｄは第２のシングルファイル内に蓄積され る。それは、プラットフォームの独立的命令の共通部分と、プラットフォームの 依存的命令、各プラットフォームのための一つの区分及び既述の束縛メカニズム のマルチ区分とを持ちながら、各種の異なるプラットフォーム上にタイトルを実 行することを許容するこのメカニズムである。これは、より詳細にこれ以降述べ られる。 部分Ａ内のエントリが部分Ｃ＋Ｄが蓄積されているところのプラットフォーム 上のディスパッチテーブルと合うとして、部分Ｃ＋Ｄの蓄積組織は、部分Ｂの現 在選択されたプラットフォーム変化へ部分Ｃ＋Ｄ内の全てのｃｆａ’ｓをリンク させるため、異なるプラットフォーム上にローディングすることを許容する。タ イトル部分Ａの再生の間もはや効果的でないことに注意されたい、その束縛効果 がそれを不必要となすからである。小さな不利益は、ＦＯＲＴＨインタプリタが もはや直接スレッデッドされないことであり、もはや各辞書のエントリは、機械 命令を含まない。また、ローディング及び再配置は、わずかに少し複雑になる。 間接的スレッデッドのこのメカニズムは、またプラットフォーム操作システム から独立する部分Ｃ及びＤの内容を作るように用いられる。これは、インタプリ タ（例えばファイルＩ／Ｏのため、起こりうるバイトスワップ問題を解決するた め）により用いられるシステムコールを作ることにより、及び前記機械的依存コ ードの間接コールの同じメカニズムをアプリケーションすることにより効果的で ある。カーネル部分Ｂ内のシステムコールは、部分Ａ内の前記ディスパッチテー ブルを介してカーネル部分Ｃ＋Ｄにのびる部分内の機械的独立コードから呼ばれ る。 実行が以下の三つの機能上で利用される： ・forth_loader() この機能は、カーネルＢ及び拡張カーネルＣ＋Ｄの名前を伴って呼ばれる。テー ブルＡは、カーネル機能に依存したシステムを前記拡張カーネルへ束縛するため に用いられる。 ・load_context() この機能は、適切なルートコンテキストの名前を伴って呼ばれる。当該ルートコ ンテキストは、前記アプリケーションのスタート区分であり、初期設定操作後次 のload_context()コールを伴って他のコンテキストを呼ぶ。 ・forth_execute() この機能は、実際の翻訳工程を始め、前記ルートコンテキスト内の第１のトーク ンの番地をパラメータとして持つ。当該機能は、二つの値を返すことができる。 返されたゼロは、コンテキスト内容内の全てのFORTHワードが翻訳されたわけで なく、（そのかわり）FORTH命令ワード”スリープ”が実行されたという信号で ある。このFORTHワードの実行は、ユーザ領域内の実行状態を保存し、前記forth _execute()機能の呼び出しを返す。当該スレッドは、同じパラメータを持っても う一度前記機能forth_execute()を呼ぶことにより再起動されてもよい。コンテ キストの 全内容が翻訳されたときだけ、前記機能forth_execute()はゼロでない値を返す だろう。そのとき、スタック、リターンスタック及びユーザエリアとして用いら れた領域は、放棄され、他の目的のため再び用いられてもよい。 プログラムの実施例の説明 付録（テーブル）は、どのように共通の発行形式が効果的に用いられるかを例 示し、当業者が本発明を実行することを可能にするために、各種の例示的プログ ラムモジュールを与える。当該例は、マルチメディアアプリケーションのほんの 一部であり、工程を通じてこの開発はエンドユーザのプラットフォームでの実際 の再生を実現するために述べられる。 表示されるべきアプリケーションは、以下の通りである。第１に、暗いスクリ ーンから始まって、標準ｄｙｕｖ色形式内で定められた画像は、ビデオのエフェ クトワイプクロックにより喚起される。その中で、あらかじめ定められた原点で 始まって、掃引ラインが回転し、一方効果的に表示されたフィールドが、掃引に よりカバーされた領域に与えられる。次に、ユーザがカーソルをフィールド、ホ ットスポットのある領域に移動させ、マウスのような指示機構で右の動作ボタン を押す（buttonl Down）まで、前記アプリケーションは待つ。これが起こったな らば、現実の画像から、他のビデオ効果（wipeBTにおいて、掃引動作は画像内の 下から上へ動く直線ラインである）を介して、異なる標準形式（clut7形式）内 にコード化される次の画像へ表示を変えることにより、前記アプリケーションは 進む。結果として画像は、タイマにより制御されるあらかじめ決められた特定さ れた時間示される。それから、アプリケーションは中断する。 CPF-Talkと呼ばれる公認の言語で、全てのアプリケーションはプログラムされ る。この言語で、それは、図形的設計ツールで出力を表すのに用いられてもよく 、前記アプリケーションを形成する当該出力はいわゆるコンテキスト内に分割さ れ、各々は独自の特定の振る舞いを示す。各種のコンテキストは、一つのコンテ キストから他のコンテキストへ転送するいわゆる行動を通じて、相互接続される 。前記アプリケーションにおいて、３個の異なるコンテキストが区別される。st art_contextは、第１の画像を示すことに関係し、next_contextは、次の画像を 示すこ とに関係し、stop_contextは、前記アプリケーションの中断に関係する。前記ホ ットスポットに位置されるとき前記動作ボタンをユーザが押すと、制御は、star t_contextからnext_contextへ移動する。タイマは、next_contextへ移動する先 行する制御で始まり、タイマ出力信号の制御下、制御は、next_contextからstop _contextへ移動する。 これら３個のコンテキストに加えて、他の３個のコンテキストにより必要とさ れる各種のグローバルなオブジェクトを定める共通のroot_contextがある。当該 root_contextは、前記アプリケーションが始まるとき呼ばれるべき最初のもので ある。前記root_contextの全ての命令が実行されたとき、この場合start_contex tである第１のnon_root_contextへ自動的に制御を通す。テーブル１から４は、 既述のアプリケーションのためのこれら４個のコンテキストの内容を与える。テ ーブル１において、最初にroot_contextが二つの変数、時間間隔と効果的量とと もに示される。さらに、２個の色パレット、２個の表面が定められる（これらは 異なっていてもよい）。当該表面は、平面上に定められ、適合されるならば、こ れらの定められた色コーティング、ピクセルサイズ、始めの色及びフェード後の 色を得る。最後に、前記root_contextは、次に何をなされるべきかを特定する。 テーブル２において、start_contextは、初期の画像をアクセスするところ、 次のカーソル形状、ホットスポット位置及び少なくともあらかじめ定められた間 隔dur50の間、前記ホットスポット位置でボタンが動作されるとき何がなされる べきかの動作を特定する。最後に、このコンテキストを入れるとき実行されなけ ればならない操作が特定される。テーブル３において、next_contextの構造は、 比較可能である。特別な特徴は、タイマの仕様である。テーブル４において、st op_contextは、自明である。 エンドユーザプラットフォームで実際の再生に向かう工程内の次のステップは 、これらの４個のコンテキストをForth言語に翻訳することである。結果は、ま たCPFスクリプト形式と呼ばれる。当該翻訳結果は、付録５から８内に特定され る。ボキャブラリは増加する、なぜならば標準Forth辞書内に許容されているも のより多くのワードが利用できるからである。この拡張は後で説明されるだろう 。テーブル１から４とテーブル５から８それぞれにあるものの間の対応は、自明 である。 テーブル５から８に従う表現は、インタプリタがアプリケーションの構築の間 使用する言語及び形式内にあるということである。ユーザプラットフォーム上の 実際の再生の間、もっと効率的形式が用いられる。このコンパクトな形式は、操 作を決定する翻訳及びアドレスがCPFスクリプト形式内で表されたコンテキスト 上で実行された後、インタプリタ内のコンテキストの内部表現である。このコン パクトな形式は、バイナリモジュール形式と呼ばれる。その中で例えば、参照シ ンボルは、辞書内の実際のアドレスオフセットにより置き換えられる。これらの バイナリモジュールは、人が読みとれない形式であり、そのため、明確のために 前記付録から省略された。これらのバイナリモジュール、アセットを参照し、全 ての必要な標準サポート機能は、前記構築工程を完全にするマスメモリ上におか れる。 これ以降、ランタイムでのインタプリタの操作が説明される。前記インタプリ タは、三つの部分からなる。第１の部分又はカーネルは、全プラットフォーム及 び全タイトルに対して同じである。エクステンションカーネルとしばしば呼ばれ る第２の部分は、アプリケーションに依存するが、特別のアプリケーションは全 プラットフォームに対して同一である。カーネルとエクステンションカーネルと の両方は、プラットフォームに依存する機能を含む第３の部分を利用し、参照す る。エンコードされたフォーム内のこれらの機能は、同じ物理的長さを持つ必要 はなく、従って、辞書内のオフセット値は、プラットフォームからプラットフォ ームヘ変化してもよい。それにより生じる問題を解決するために、ローディング の間だけ第４のコンポーネントがインタプリタに加えられ、これは実行がなされ ているところの実際のプラットフォームに対して辞書内のプラットフォームに依 存する機能に対するオフセットを含む。ローディングのとき、カーネル及びエク ステンションカーネルからプラットフォームに依存する辞書への紹介は、このテ ーブルからとられる紹介により置き換わる。 翻訳工程の上記部分を説明するために、命令"copy START_image to surface1" が詳細に述べられる。第１に、読み取りのため、形式がテーブル５から８に従っ て既に示されたことが理解される。インタプリタカーネルは、'START_image〜su rface〜000 copy_obj'に従う命令を得、スタック上の全該当変数（000 surface1 〜 and START_image〜）を持つ前記エクステンションカーネルからモジュールco py_objを発する。ここに、tildeは変数を示す。今の場合、前記エクステンショ ンカーネルは、二つの変数だけ、即ちobject surface1〜とSTART_imageとを必要 とする。前記エクステンションカーネルは、画像をコピーするためにメモリ空間 を持たねばならず、その目的のため前記操作システムからこのメモリを要求する ためのプログラムモジュールを発する。この段階で、操作システムに依存するシ ステムは、上述のように前記エクステンションカーネルとインタプリタのローデ ィングがリンクされた間は、発せられるだろう。前記メモリの保存の後で、他の 操作システムに依存するモジュールは、前記マスメモリ上のファイルを開くため 、当該ファイルの内容を前記保存されたメモリ空間へコピーするため、そして前 記マスメモリ上の当該ファイルを閉じるため発せられる。後者のシステムコール は、メモリハンドラに対して述べられたのと同様に、前記エクステンションカー ネルとリンクされる。 このやり方で、コンテキスト内にある'copy START_image to surface1'のよう な命令は、各異なるプラットフォーム副システムに対して、多くの他のプラット フォームに依存する機能に対してと同様に例えばメモリ操作及びファイルI/Oに 対する各異なる機能を発する結果となる。他の命令は、同様なやり方でこのよう に異なる機能の結果となる。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＪＰ，ＫＲ (54)【発明の名称】 マルチプラットフォームインタプリタを含むアプリケーションプログラムを有する与えられたマ スデータを受けるマルチメディアシステムと、マルチプラットフォームインタプリタとの相互作 用のために配されるプラットフォーム副システムと、このようなシステム又はこのような副シス テムで用いるためのマスメモリ

Claims (1)

1. 【特許請求の範囲】 １．与えられたマスデータを受けるマルチメディアシステムであり、前記データ はマルチプラットフォームインタプリタを含むアプリケーションプログラムを有 し、当該システムはさらにプラットフォーム副システムを持ち、前記マルチプラ ットフォームインタプリタとの相互作用のために配され、ユーザ入力手段の制御 下前記アプリケーションプログラムにより駆動される前記マルチプラットフォー ムインタプリタを実行するための処理手段を有し、さらにまた前記マルチプラッ トフォームインタプリタにより制御可能なユーザ出力手段を持つマルチメディア システムにおいて、前記アプリケーションプログラムは、前記実行のために前記 処理手段により翻訳されるあらかじめ決められた命令セットに基づいていて、こ れにより前記プラットフォーム副システムは前記あらかじめ決められた命令セッ トとあらかじめ決められたデータタイプセットとを持つあらかじめ特定されたア ブストラクトマシンの例であり、さらに前記副システムはあらかじめ決められた 量的な最小の要件に従うリソース設備を有することを特徴とするマルチメディア システム。 ２．単一のメモリ媒体上に前記マスデータを受けるための物理的インタフェース 手段を持つ請求項１に記載のマルチメディアシステム。 ３．離れた供給チャネル手段を介して前記マスデータを受けるために物理的な取 り付け手段を持つ請求項１に記載のマルチメディアシステム。 ４．前記プラットフォーム副システムがパーソナルコンピュータ及びＣＤ−Ｉ機 械のどれかである請求項１、２又は３に記載のマルチメディアシステム。 ５．マルチプラットフォームインタプリタを有し、プラットフォームに依存する プリミィティブの位置アドレスを有するディスパッチテーブル（Ａ）と、実行可 能であり翻訳可能なコードを蓄積するための前記位置アドレスにより番地付けで きる全位置を含むカーネル領域（Ｂ）と、プラットフォームとは独立の且つタイ トルとも独立のコードを含む第１の領域（Ｃ）とタイトルに依存するコードを含 む第２の領域（Ｄ）とを持つ拡張カーネル領域（Ｃ＋Ｄ）とを有する請求項１乃 至４の何れか１項に記載のシステムと共に使用するための完備されたマスメモリ 。 ６．前記マルチプラットフォームインタプリタをローディングするためにロード 手段を持ち、請求項１乃至４の何れか１項に記載のマルチメディアシステム内に 含まれるか、又は請求項５に記載の完備されたマスデータメモリと相互作用する ために配されるプラットフォーム副システム。