JP3202283B2

JP3202283B2 - 画像データの再生方法及びその再生回路

Info

Publication number: JP3202283B2
Application number: JP32948391A
Authority: JP
Inventors: 智三安部
Original assignee: Sony Computer Entertainment Inc
Current assignee: Sony Interactive Entertainment Inc
Priority date: 1991-11-18
Filing date: 1991-11-18
Publication date: 2001-08-27
Anticipated expiration: 2016-08-27
Also published as: JPH05145892A

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、画像データの再生方
法及びその再生回路に関する。

【０００２】

【従来の技術】大容量の記憶媒体としてＣＤ−ＲＯＭが
あり、これは、マイクロコンピュータを使用したゲーム
機やパーソナルコンピュータなどにおいて、外部記憶媒
体として使用されている。

【０００３】図１１は、そのようなＣＤ−ＲＯＭも使用
できるマイクロコンピュータの一例を示す。

【０００４】すなわち、図１１は、そのようなマイクロ
コンピュータをゲーム機に適用した場合の一例を示し、
１はそのゲーム機本体、３は副処理部、４はＣＤ−ＲＯ
Ｍ、５はプログラムカートリッジである。

【０００５】そして、ゲーム機本体１は、マイクロコン
ピュータにより構成されているもので、１１はそのＣＰ
Ｕ、１３はワークエリア用及びバッファ用のＲＡＭ、１
４はＰＰＵ（ピクチャ・プロセシング・ユニット）、１
５はビデオＲＡＭである。そして、回路１１〜１４はシ
ステムバス１９に接続されるとともに、ＰＰＵ１４にビ
デオＲＡＭ１５及びＣＲＴディスプレイ６が接続され
る。

【０００６】さらに、本体１において、２０は音声デー
タの主処理部で、２１はそのＡＰＵ（オーディオ・プロ
セシング・ユニット）、２４はＤ／Ａコンバータ、２５
は音声出力端子で、ＡＰＵ２１が、バス１９に接続され
るとともに、Ｄ／Ａコンバータ２４に接続される。

【０００７】また、副処理部３は、ＣＤ−ＲＯＭ４の使
用を可能にするためのもので、ＣＤプレーヤ及びＣＤ−
ＲＯＭデコーダなどを有し、ＣＤ−ＲＯＭ４から読み出
された画像データ及びプログラムは、処理部３において
必要な処理が行われてからバス１９に供給される。

【０００８】さらに、プログラムカートリッジ５は、Ｒ
ＯＭ５１と、ＲＡＭ５２とを有し、そのＲＯＭ５１に
は、プログラムなどが書き込まれている。また、ＲＡＭ
５２は、例えばゲームを途中で一時中断するとき、その
ときの状態に関する各種のデータを次回のゲームの再開
まで保持するために使用されるものであり、電池５３に
よりバックアップされている。

【０００９】そして、このカートリッジ５を、ゲーム機
本体１のスロット２に差し込むと、コネクタ（図示せ
ず）を通じてＲＯＭ５１及びＲＡＭ５２はバス１９に接
続される。

【００１０】そして、プログラムカートリッジ５だけで
ゲームなどが実行できる場合には、そのカートリッジ５
をスロット２にセットし、ゲーム機本体１の電源をオン
にする（あるいはリセットをかける。以下同様）。

【００１１】すると、ＣＰＵ１１によりＲＯＭ５１のプ
ログラムを実行されて画像データが形成され、この画像
データがＰＰＵ１４によりビデオＲＡＭ１５に書き込ま
れるとともに、このビデオＲＡＭ１５の画像データが水
平及び垂直走査に同期して読み出され、この読み出され
た画像データがディスプレイ６に供給されて画像が表示
される。

【００１２】また、ＣＰＵ１１によりＡＰＵ２１に音声
データ及びそのデコード用のプログラムがロードされ、
その音声データがデジタル音声信号にデコードされ、こ
のデジタル音声信号がコンバータ２４によりアナログ音
声信号にＤ／Ａ変換されてから端子２５に出力される。

【００１３】一方、ＣＤ−ＲＯＭ４を使用してゲームな
どを実行する場合には、そのＣＤ−ＲＯＭ４を処理部３
のＣＤプレーヤにセットするとともに、プログラムカー
トリッジ５としてシステムカートリッジ５をスロット２
にセットする。

【００１４】この場合、システムカートリッジ５もＲＯ
Ｍ５１及びＲＡＭ５２を有し、ＲＯＭ５１にはＩＰＬが
用意され、ＲＡＭ５２は、上述のように、例えばゲーム
を一時中断するときに各種のデータを次回のゲームの再
開まで保持するために使用される。また、ＣＤ−ＲＯＭ
４には、このＣＤ−ＲＯＭ４を使用するためのＯＳ及び
ゲームのプログラムなどが用意される。

【００１５】そして、電源をオンにすると、ＣＰＵ１１
がＲＯＭ５１のＩＰＬを実行することによりＣＤ−ＲＯ
Ｍ４からＯＳ及びゲームのプログラムがＲＡＭ１３にロ
ードされ、続いてＣＰＵ１１がＲＡＭ１３にロードされ
たプログラムが実行する。したがって、ゲームができる
ようになる。

【００１６】

【発明が解決しようとする課題】ところで、例えば図５
Ａに示すように、ディスプレイ６に表示される画像の１
フレーム（１画面）が、256 画素（横）×192 画素
（縦）で構成され、その１画素の赤色、緑色、青色がそ
れぞれ５ビットで表されるとすると、１フレームの画像
データのデータ量は、となる。

【００１７】ところが、ＣＤ−ＲＯＭ４の１セクタの容
量は、モード１のとき、２Ｋバイトであり、再生速度は
75セクタ／秒である。すなわち、ＣＤ−ＲＯＭ４のデー
タ伝送レイトは150 Ｋバイト／秒である。

【００１８】したがって、もし、上記の画像データを、
そのままＣＤ−ＲＯＭ４に記録したときには、再生時、
１秒当たりのフレーム数（駒数）は、 150Ｋ／90Ｋ＝1.7 フレーム弱となり、動画を表示しようとしても、フレーム数がまっ
たく不足してしまう。

【００１９】そこで、動画を表示する場合には、ＣＤ−
ＲＯＭ４の回転速度を上げることにより、ＣＤ−ＲＯＭ
４のデータ伝送レイトを大きくし、１秒当たりのフレー
ム数を多くすることが考えられる。

【００２０】しかし、ＣＤ−ＲＯＭ４の画像データを表
示する場合には、ＣＤ−ＲＯＭ４から画像データを再生する。

【００２１】再生した画像データを、いったんＲＡ
Ｍ１３に書き込む。

【００２２】ＲＡＭ１３の画像データを垂直ブラン
キング期間にＰＰＵ１４に送る。という処理を行うこと
になる。

【００２３】ところが、このような処理を行う場合、Ｃ
Ｄ−ＲＯＭ４のデータ転送レイトを大きくすると、項
の再生速度が、項の画像データの転送速度よりも速く
なって、項のＲＡＭ１３があふれることがある。

【００２４】この場合、ＲＡＭ１３の容量をＣＤ−ＲＯ
Ｍ４の容量程度まで大きくすれば、ＲＡＭ１３のあふれ
は生じないが、ＲＡＭ１３をそのように大容量とするこ
とは、コスト的に不可能である。

【００２５】この発明は、以上のような問題点を解決し
ようとするものである。

【００２６】

【課題を解決するための手段】このため、この発明にお
いては、各部の参照符号を後述の実施例に対応させる
と、記録媒体４から再生した画像データRECDをバッファ
メモリBUFMに書き込み、このバッファメモリBUFMに書き
込んだ画像データRECDを表示用の画像データに変換する
場合において、バッファメモリBUFMを、記録媒体４から
再生した画像データRECDの１フレーム分よりも大きな容
量のバッファメモリにより構成し、記録媒体４から再生
した画像データRECDを、バッファメモリBUFMに書き込む
前に、バッファメモリBUFMに１フレーム分の空きがある
かどうかをチェックする回路１１と、このチェックの結
果、空きがあるときには、記録媒体４から再生した画像
データRECDをバッファメモリBUFMに書き込むが、上記チ
ェックの結果、空きがないときには、記録媒体４から再
生した画像データRECDを捨てる回路１１、１２とを設け
る。

【００２７】

【作用】再生した画像データRECDをバッファメモリBUFM
に書き込むとき、１フレーム分の空きがあれば、その画
像データRECDはバッファメモリBUFMに書き込まれるが、
１フレーム分の空きがないときには、その画像データRE
CDは読み捨てられる。

【００２８】

【実施例】《画像データの記録処理》まず、ＣＤ−ＲＯ
Ｍ４に記録されている画像データの一例について、図３
〜図１０により説明する。

【００２９】図３及び図４は、その画像データの記録処
理の過程を示すフローチャートである。また、図５Ａ
は、その記録の対象となる画面の１フレーム（１画面）
を示すもので、この１フレームは、256 画素（横）×19
2 画素（縦）で構成されるとともに、その１画素の赤
色、緑色、青色がそれぞれ５ビットで表される。そし
て、実際は、処理の都合でダミーの１ビットが最上位に
追加され、１画素は１ビット（ダミー）＋５ビット×３
色、すなわち、16ビットとされる。また、この原画像デ
ータは１フレーム単位で記録処理される。

【００３０】すなわち、ステップ８１（図３）におい
て、図５Ａに示す１フレームの原画像データが、図５Ｂ
に示すように、それぞれが８画素（横）×８画素（縦）
の大きさのブロック（以下、このブロックを「キャラク
タ」と呼ぶ）に分割される。したがって、図５Ｂにも示
すように、１フレームの画像は、32×24＝768 個のキャ
ラクタＣ0 〜Ｃ767 に分割され、原画像データはキャラ
クタデータCHR(0)〜CHR(767)に分割される。なお、１つ
のキャラクタデータCHR(i)（i ＝０〜767 ）は、８画素
×８画素×16ビット＝128 バイトである。

【００３１】そして、このキャラクタデータCHR(i)に対
して、ステップ８２において、第１次のベクトル量子化
が行われる。このベクトル量子化は、１つのキャラクタ
Ｃiごとに、そのキャラクタ内の画素の色数が４色以下
となるように、量子化するものである。また、このベク
トル量子化の方法としては、すでに提案されている方法
を採用することができるが、この例においては、赤、
緑、青の色成分を、互いに直交する３本の座標軸にとっ
た３次元の色空間を考え、この色空間において各画素間
の距離を求め、この距離の短い画素同志をまとめること
により、１つのキャラクタＣi 内の画素の色数が４色以
下の「代表色」に収まるように画素データを丸める。

【００３２】さらに、この量子化時、各フレームにおい
て、各キャラクタＣiの量子化誤差（色空間における代
表色と各画素との距離に相当）のうちの最大値をＥmax
としたとき、各キャラクタＣi 内で量子化誤差が最大値
Ｅmax を越える直前までベクトル量子化が行われ、フレ
ームごとに、その全キャラクタＣ0 〜Ｃ767 のＳ／Ｎが
均一化される。

【００３３】また、このように量子化をすると、色の変
化の平坦なキャラクタにおいては、色数が減少するが、
これは色数が減少しても量子化誤差がそれほど増加しな
いためである。

【００３４】こうして、キャラクタデータCHR(i)は各キ
ャラクタＣi 内において４色以下となるように量子化さ
れる。

【００３５】そして、この量子化されたキャラクタデー
タCHR(i)が、ステップ８３において、似た色を持つキャ
ラクタ同志をまとめることにより、８個のグループに分
類される（以下、このグループを「パレット」と呼
ぶ）。すなわち、各キャラクタデータCHR(i)は８個のパ
レットＰ0 〜Ｐ7 のどれかに属するように分類される。
この場合、各キャラクタＣi は分類されるだけであり、
その順序が入れ換えられることはない。したがって、パ
レットＰj （j ＝０〜７）は、連続したキャラクタの領
域である必要はなく、飛び飛びのキャラクタ同志が、１
つのパレットを構成してもよい。例えば、図５Ｃに示す
ように、色調の似た領域Ａ〜Ｅを生じた場合、この領域
Ａ〜ＥのそれぞれごとにパレットＰj が構成されてよ
い。

【００３６】そして、このパレットＰj に分類されたキ
ャラクタデータCHR(i)に対して、ステップ８４におい
て、パレットＰj ごとに第２次のベクトル量子化が行わ
れる。

【００３７】すなわち、各キャラクタＣi の代表色が４
色であっても、そのキャラクタＣiの集まりであるパレ
ットＰj の色数が16色を越えることがあるので、１つの
パレットＰj 内の色数が16色より多ければ、第１次のベ
クトル量子化の場合と同様に第２次のベクトル量子化が
行われてパレットＰj 内の色が最大で16色になるように
丸められ、その結果の16色が新たな代表色とされる。

【００３８】したがって、パレットＰj ごとに、そのパ
レットＰj に属するキャラクタＣiのキャラクタデータC
HR(i)は、そのパレットＰj の持つ16色の代表色のうち
のいずれかの色の色データ（15ビットの色データ）に量
子化される。

【００３９】続いて、ステップ８５において、各パレッ
トＰj に対して色番号変換用のテーブルCOL(j)が作成さ
れる。このテーブルCOL(j)は、図６に示すように、パレ
ットＰj ごとに、その16色の代表色の色データ（15ビッ
トの色データ）と、その色データを指定する４ビットの
色番号（０〜15）とを有する変換テーブルである。した
がって、この時点では、キャラクタデータCHR(i)は、そ
のキャラクタデータの属するパレットのテーブルCOL(j)
の色データのいずれかに等しい。

【００４０】そして、ステップ８６において、図７に示
すように、第２次の量子化の行われたキャラクタデータ
CHR(i)の各色データが、そのキャラクタデータCHR(i)の
属するパレットＰj の色番号変換テーブルCOL(j)を参照
してその色番号変換テーブルの色番号に変換される。し
たがって、このとき、各キャラクタＣi の画素は、その
色が４ビットの色番号と、その色番号が色番号変換テー
ブルCOL(j)のうちのどのテーブルのものであるかを示す
（キャラクタＣi ごとの）データとにより、表現され
る。

【００４１】そこで、ステップ８７において、スクリー
ンテーブルSCR が形成される。このスクリーンテーブル
SCR は、図８に示すように、元の画像データの１フレー
ムに対応して24キャラクタ×32キャラクタ分のアドレ
ス、すなわち、全部で768 番地のアドレスを有する。そ
して、各アドレスは、図９にも示すように、２バイトの
大きさとされ、その２バイトの下位10ビットがキャラク
タＣi の番号Ｃi とされ、その上位の３ビットが、キャ
ラクタ番号Ｃi のキャラクタデータCHR(i)の属するパレ
ットＰj のパレット番号Ｐj とされる。

【００４２】さらに、この例においては、ステップ８８
により、スクリーンテーブルSCR のキャラクタ番号Ｃi
は、大きい方に16だけシフトされ、キャラクタ番号Ｃi
のうちの０〜15は、単色のキャラクタＣi の色番号に割
り当てられる。すなわち、キャラクタＣi によっては、
そのすべての画素の色が等しく、したがって、キャラク
タＣi が単色の場合がある。そして、そのようなキャラ
クタＣi の場合には、そのキャラクタＣi に対して、パ
レット番号Ｐj 及び色番号を与えれば、そのキャラクタ
Ｃi のすべての画素の色を特定できる。

【００４３】そこで、単色のキャラクタＣi について
は、パレット番号Ｐj はそのキャラクタＣi の本来のパ
レット番号Ｐj とされるが、キャラクタ番号Ｃi は色番
号とされる。なお、このとき、その単色のキャラクタＣ
i の、テーブルSCR におけるアドレスがキャラクタ番号
Ｃi を示している。また、このようにしてもキャラクタ
番号Ｃi のシフト前の最大値は767 であるから、これを
16だけ大きい方にシフトしても、キャラクタ番号Ｃi
は、やはり10ビットで表すことができる。

【００４４】以上のようにして、画像データは、１フレ
ームごとに、色番号変換用のテーブルCOL(j)と、スクリ
ーンテーブルSCR と、画素ごとの４ビットの色番号とに
変換される。なお、以下の説明においては、色番号変換
用のテーブルCOL(j)を色番号変換テーブルCOL と呼び、
画素ごとの４ビットの色番号を色番号データDAT と呼
ぶ。

【００４５】そして、これらデータDAT 、SCR 、COL
が、例えば図１０に示すようなフォーマットの記録デー
タRECDに組み立てられ、この記録データRECDがＣＤ−Ｒ
ＯＭ４に記録される。この場合、その記録データRECD
は、エラー訂正コードの付加などモード１で記録するた
めのエンコード処理が行われてからＣＤ−ＲＯＭ４に記
録される。また、そのＣＤ−ＲＯＭ４には、これに記録
された画像データ（記録データ）RECDを表示あるいは使
用するプログラムなども必要に応じて用意される。

【００４６】ここで、記録された画像データRECDの１フ
レーム当たりのデータ量を求めると、これは次のように
なる。すなわち、パレットＰj は１フレームにつき８個
あり、１パレットが16色、１色は16ビット（１ビットは
ダミー）なので、色番号変換テーブルCOL は、合計で、８パレット×16色×16ビット＝256 バイトとなる。

【００４７】また、スクリーンテーブルSCR は、キャラ
クタが768個あり、１キャラクタにつき２バイトである
から、２バイト×768 個＝1536バイトとなる。

【００４８】さらに、色番号データDAT は、１画素ごと
に４ビットなので、１キャラクタあたりのデータDAT の
データ量は、４ビット×64画素＝32バイトとなる。

【００４９】そして、単色のキャラクタＣi のデータ
は、スクリーンテーブルSCR の一部として伝送している
ので、改めて別個に伝送する必要がない。

【００５０】したがって、例えば１フレームの768 キャ
ラクタのうち、その1/4 が単色のキャラクタであるとす
れば、色番号変換テーブルCOL ＝ 256バイトスクリーンテーブルSCR ＝1536バイト色番号データDAT ＝32バイト×768 個×3/4 ＝18432 バイト −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 合計＝ 20224バイトとなる。すなわち、20Ｋバイト弱となる。

【００５１】そして、ＣＤ−ＲＯＭ４を例えば通常の２
倍の回転速度とすれば、そのデータ伝送レイトは、300
Ｋバイト／秒になる。

【００５２】したがって、上記の画像データのデータ量
の場合、 300 Ｋバイト／20224 バイト＝15.2フレーム弱の割り合いで動画を記録あるいは再生できることにな
る。

【００５３】そして、このようなフレーム速度で動画を
再生することができれば、満足のできる動画となる。し
かも、上述のように画像データを記録した場合、再生
時、色番号変換テーブルCOL を参照するだけで色番号デ
ータDAT を元の色の画像データに変換することができる
ので、再生回路の構成が簡単になる。

【００５４】さらに、特別なＩＣを必要としないので、
ローコストに提供できるとともに、記録媒体としてＣＤ
−ＲＯＭを使用できるので、コンピュータゲーム機のソ
フトに適用して効果的である。

【００５５】《再生回路》次に、上述の画像データRECD
の記録されたＣＤ−ＲＯＭ４から、元の画像データを再
生して動画を表示できるようにしたマイクロコンピュー
タについて、その基本的な構成及び動作を、図１により
説明する。なお、一部の回路は、図１１のそれと同じで
ある。

【００５６】図１は、そのようなマイクロコンピュータ
をゲーム機に適用した場合の一例を示し、１はそのゲー
ム機本体、３は副処理部、４はＣＤ−ＲＯＭ、５はプロ
グラムカートリッジである。

【００５７】そして、ゲーム機本体１は、マイクロコン
ピュータにより構成されているもので、１１はそのＣＰ
Ｕ、１２はＤＭＡＣ（ＤＭＡコントローラ）、１３はワ
ークエリアとなるメインＲＡＭ、１４はＰＰＵ、１５は
ビデオＲＡＭである。

【００５８】この場合、ビデオＲＡＭ１５は２フレーム
分以上（２画面分以上）の画面エリアを有し、その１つ
の画面エリアの画像データが、ＰＰＵ１４によりＣＲＴ
ディスプレイ６の垂直及び水平走査に同期して読み出さ
れ、ディスプレイ６により画像として表示されるととも
に、この表示が行われている間に、別の画面エリアに次
に表示される画像の画像データが書き込まれる。なお、
ビデオＲＡＭ１５の一部のエリアは、ＰＰＵ１４のワー
クエリアでもあり、色番号変換テーブルCOL のエリア
（パレット用のエリア）などとしても使用される。

【００５９】また、副処理部３は、ＣＤプレーヤを有し
てＣＤ−ＲＯＭ４の使用を可能にするためのもので、３
１はそのＣＤプレーヤ、３２はＤＳＰ、３３はＣＤ−Ｒ
ＯＭデコーダ、３４はそのワークエリア用のＲＡＭ、３
５はコントローラである。そして、ＣＤ−ＲＯＭ４に
は、上述のように、音声データ、画像データRECD、この
画像データRECDを再生処理するためのプログラム、ゲー
ムのプログラム及びＯＳが記録されている。なお、ＣＤ
−ＲＯＭ４は、画像データRECDのセクタについては、通
常の２倍の回転速度で再生される。

【００６０】さらに、ＤＳＰ３２は、プレーヤ３１の再
生信号に対するエラー訂正を行うとともに、再生信号か
ら画像データRECDなどのユーザ用データと、トラック番
号などの制御データとを分離するためのものであり、コ
ントローラ３５は、そのＤＳＰ３２からの制御データ
と、ＣＰＵ１１からの指示データとに基づいてプレーヤ
３１を制御し、目的とするデータを再生するためのもの
である。また、デコーダ３３は、プレーヤ３１の再生信
号がＣＤ−ＲＯＭ４のモード１の再生信号のとき、その
モード１のエラー訂正などの処理を行うためのものであ
る。

【００６１】さらに、この例においては、処理部３に汎
用のＤＳＰ４４が設けられ、必要なときには、このＤＳ
Ｐ４４によりＣＰＵ１１の処理の一部を負担できるよう
にされている。なお、この処理部３は、この例において
はゲーム機本体１と一体化されているが、ゲーム機本体
１に対してアダプタ形式とされていてもよい。

【００６２】そして、ＣＤ−ＲＯＭ４の画像データRECD
が動画として表示されるとき、その画像データRECDに対
する再生処理の手順は、次のとおりである。

【００６３】すなわち、 (1) ＣＤプレーヤ３１によりＣＤ−ＲＯＭ４から画像
データRECDの１フレーム分が再生され、この画像データ
RECDが、プレーヤ３１からＤＳＰ３２及びデコーダ３３
に順に供給されてエラー訂正などの処理が行われ、その
エラー訂正の行われた画像データRECDが、ＤＭＡＣ１２
によりデコーダ３３からＲＡＭ１３のバッファエリアに
ＤＭＡ転送される。

【００６４】(2) ＲＡＭ１３のバッファエリアにＤＭ
Ａ転送された画像データRECDのうちの色番号データDAT
が、ＣＲＴディスプレイ６の垂直ブランキング期間に、
ＤＭＡＣ１２によりＰＰＵ１４を通じてビデオＲＡＭ１
５にＤＭＡ転送される。

【００６５】(3) (2) の処理を終了すると、ＣＲＴデ
ィスプレイ６の垂直ブランキング期間に、ＲＡＭ１３の
バッファエリアにＤＭＡ転送された画像データRECDのう
ちのスクリーンテーブルSCR が、ＤＭＡＣ１２によりＰ
ＰＵ１４を通じてビデオＲＡＭ１５にＤＭＡ転送され
る。

【００６６】(4) ＣＲＴディスプレイ６の水平ブラン
キング期間に、ＲＡＭ１３のバッファエリアにＤＭＡ転
送された画像データRECDのうちの色番号変換テーブルCO
L が、ＤＭＡＣ１２によりＰＰＵ１４を通じてビデオＲ
ＡＭ１５にＤＭＡ転送される。

【００６７】(5) 以上の処理が行われと、ＰＰＵ１４
は、リアルタイムで色番号変換テーブルCOL(j)を参照す
ることにより、(2) により転送された色番号データDAT
を、実際の色の画素データに変換するとともに、この画
素データを、スクリーンテーブルSCR を参照することに
より、ビデオＲＡＭ１５のうち、元のキャラクタ位置に
対応したアドレスに書き込む。

【００６８】(6) 以上により１フレーム分の画素デー
タがビデオＲＡＭ１５に書き込まれると、ビデオＲＡＭ
１５の表示エリアが切り換えられ、その画素データの書
き込まれたエリアがアクティブとされ、このアクティブ
とされたエリアの画像がディスプレイ６に表示される。

【００６９】(7) 処理は(1) に戻り、以後、１フレー
ム単位で(1) 〜(6) の処理が繰り返される。

【００７０】こうして、ＣＤ−ＲＯＭ４から再生された
画像データは、ＲＡＭ１３からＰＰＵ１４を通じてビデ
オＲＡＭ１５まで次々と送られるとともに、ＰＰＵ１４
により再生処理される。したがって、ディスプレイ６に
は、ＣＤ−ＲＯＭ４の画像データRECDによる画像が動画
として表示される。

【００７１】《ＲＡＭ１３のバッファエリアのあふれの防止》ＲＡＭ
１３を、ＣＤ−ＲＯＭ４から再生された画像データRECD
のバッファエリアとして使用しているが、そのあふれを
防止するため、ＣＤ−ＲＯＭ４からの画像データRECD
は、そのバッファエリアに次のように書き込む。

【００７２】すなわち、上述のように１フレーム分の画
像データRECDは20Ｋバイト程度であり、これはＣＤ−Ｒ
ＯＭ４の10セクタ分に対応する。

【００７３】そこで、図２に示すように、ＲＡＭ１３の
バッファエリアをメモリBUFMとするとき、このメモリBU
FMは、ＣＤ−ＲＯＭ４の例えば32セクタ分の大きさ、す
なわち、64Ｋバイト（＝２Ｋバイト×32セクタ）とされ
る。なお、図２において、#0〜#31 は、メモリBUFMを１
セクタ分（２Ｋバイト）ごとのエリアに区切ったときの
エリア番号を示す。

【００７４】さらに、メモリBUFMはリングバッファとさ
れ、このメモリBUFMに１フレーム分の画像データRECDが
書き込まれるとき、その画像データRECDは、アドレス順
（エリア順）に書き込まれるとともに、その最上位アド
レスの次には最下位のアドレスに書き込まれる。

【００７５】例えば、ＣＤ−ＲＯＭ４からの第Ｑフレー
ムの画像データRECDが、メモリBUFMのエリア#25 から書
き込まれていくときには、図２に斜線で示すように、#2
5 →#26 →‥‥‥→#31→#0→#1→#2のように書き込ま
れていく。

【００７６】そして、ＣＤ−ＲＯＭ４からの次の第(Q+
1) フレームの画像データRECDがメモリBUFMに書き込ま
れるときには、第Ｑフレームの画像データRECDの書き込
まれた最後のエリア#2から10セクタ後ろのエリア#12 が
空いているかどうかがチェックされ、空いていれば、そ
の第(Q+1) フレームの画像データRECDは、エリア#2に続
くエリア#3から順に書き込まれていく。

【００７７】しかし、エリア#12 が空いているかどうか
のチェックの結果、空いていないときには、その第(Q+
1) フレームの画像データRECDはメモリBUFMに書き込ま
れずに捨てられる（読みとばされる）。

【００７８】すなわち、ＣＤ−ＲＯＭ４からの第Ｑフレ
ーム目の画像データRECDをメモリBUFMに書き込んだと
き、その画像データRECDの最後のデータ（データCOL の
最後のバイト）が、バッファメモリBUFMのエリア#0〜#3
1 のうちの第Ｒ番目のエリア#Rに書き込まれたとする
（Ｒは０〜31のいずれか）。すると、 1. 次の第(Q+1) フレーム目の画像データRECDを、バッ
ファメモリBUFMに書き込むとき、このバッファメモリBU
FMのエリア#Rから１フレーム分後ろのエリア、すなわ
ち、平均的には10セクタ分後ろのエリア#(R+10) に、未
処理の画像データRECDが残っているかどうかをチェック
する（R+10≧32のときは、R+10は、32を引いた値とす
る。以下同様）。

【００７９】2. 1.項のチェックの結果、エリア#(R+1
0)に、未処理の画像データRECDが残っていないときに
は、エリア#(R+1)から第(Q+1) フレームの画像データRE
CDを順に書き込んでいく。

【００８０】3. 1.項のチェックの結果、エリア#(R+1
0)に、未処理の画像データRECDが残っているときには、
第(Q+1)フレームの画像データRECDは読みとばし、メモ
リBUFMには書き込まない。

【００８１】4. 以後、同様の処理を繰り返す。とする。

【００８２】なお、1.項の空きエリアのチェックはＣＰ
Ｕ１１が行い、2.項及び3.項の画像データRECDの書き込
みあるいは読みとばしは、ＣＰＵ１１の指示に基づいて
ＤＭＡＣ１２が行う。

【００８３】また、1.項のチェックは、フラグを用意し
ておくことにより実現できる。すなわち、エリア#0〜#3
1 のそれぞれに対してフラグを用意しておき、あるエリ
アにおいて、新しい画像データRECD（１セクタ分）が書
き込まれたら対応するフラグをセットし、その画像デー
タRECDがＰＰＵ１４に送られたら対応するフラグをリセ
ットする。そして、フラグがセットされていれば、対応
するエリアは空いていないが、リセットされていれば、
対応するエリアが空いているとすればよい。

【００８４】このようにすれば、ＰＰＵ１４における画
像データRECDの処理速度が、ＣＤ−ＲＯＭ４からの画像
データRECDの再生速度よりも遅くても、バッファメモリ
BUFMがあふれることがなく、その画像データRECDを正し
く元の画像データに変換することができる。

【００８５】しかも、その場合、上述から明らかなよう
に、バッファメモリBUFMの大きさは、画像データRECDの
数フレーム分の大きさでよく、ローコストである。

【００８６】さらに、バッファメモリBUFMに、新しい画
像データRECDを書き込む空きがあるかどうかをチェック
するとき、１フレーム分の空きがあるかどうかをチェッ
クしているので、処理が簡単になる。

【００８７】すなわち、バッファメモリBUFMに、新しい
画像データRECDを書き込む空きがあるかどうかをチェッ
クするとき、１エリアごとに空きがあるかどうかをチェ
ックし、空きがあれば、そのエリアに新しい画像データ
RECDの１セクタ分を書き込んでいくようにすると、１フ
レームの途中で空きエリアがなくなったとき、それまで
に書き込んだ分を無効にするようにＰＰＵ１４に指示す
る必要があり、これでは処理が複雑になってしまう。

【００８８】しかし、この発明においては、バッファメ
モリBUFMに、新しい画像データRECDを書き込む空きがあ
るかどうかをチェックするとき、１フレーム分の空きが
あるかどうかをチェックしているので、その空きがない
ときの処理が非常に簡単である。

【００８９】

【発明の効果】この発明によれば、ＣＤ−ＲＯＭ４から
再生された画像データRECDをバッファメモリBUFMに書き
込むとき、そのバッファメモリBUFMに画像データRECDの
１フレーム分を書き込む空きエリアがあるかどうかをチ
ェックし、空きがあるときには、その書き込みを行う
が、空きがないときには、その画像データRECDを読みと
ばすようにしている。したがって、ＰＰＵ１４以降にお
ける処理速度がＣＤ−ＲＯＭ４からの画像データRECDの
再生速度よりも遅くても、バッファメモリBUFMがあふれ
ることがなく、その画像データRECDを正しく元の画像に
表示することができる。

【００９０】しかも、その場合、バッファメモリBUFMの
大きさは、画像データRECDの数フレーム分の大きさでよ
く、ローコストである。

【００９１】さらに、バッファメモリBUFMに、新しい画
像データRECDを書き込む空きがあるかどうかをチェック
するとき、１フレーム分の空きがあるかどうかをチェッ
クしているので、その空きがないときの処理が非常に簡
単である。

【００９２】また、画像データRECDは可変長であり、そ
の画像データRECDの表示処理に必要とされる時間が画像
の内容により変化するが、プログラマは、その表示処理
に必要とされる時間を考慮してプログラムを組む必要が
なく、プログラマの負担を軽減することができる。

【図面の簡単な説明】

【図１】この発明の一例の系統図である。

【図２】この発明におけるメモリの使用状態を説明する
ための図である。

【図３】画像データの記録処理過程の一部の一例を示す
フローチャートである。

【図４】図３の続きを示す図である。

【図５】画像データにおける用語を説明するための図で
ある。

【図６】色番号変換テーブルを説明するための図であ
る。

【図７】記録されるデータを説明するための図である。

【図８】スクリーンテーブルを説明するための図であ
る。

【図９】スクリーンテーブルのデータの構造を説明する
ための図である。

【図１０】記録データのフォーマットの一例を示す図で
ある。

【図１１】従来例の系統図である。

【符号の説明】

１ゲーム機本体２スロット３副処理部４ＣＤ−ＲＯＭ５プログラムカートリッジ６ＣＲＴディスプレイ１１ＣＰＵ１２ＤＭＡコントローラ１３ＲＡＭ１４ＰＰＵ１５ビデオＲＡＭ１９システムバス２０主処理部２１ＡＰＵ２４Ｄ／Ａコンバータ３１ＣＤプレーヤ３２ＤＳＰ３３ＣＤ−ＲＯＭデコーダ３５コントローラ５１ＲＯＭ５２ＲＡＭ

Claims

(57)【特許請求の範囲】

【請求項１】記録媒体から再生した画像データをバッ
ファメモリに書き込み、このバッファメモリに書き込んだ画像データを表示用の
画像データに変換する場合において、上記バッファメモリとして、上記記録媒体から再生した
画像データの１フレーム分よりも大きな容量のバッファ
メモリを設け、上記記録媒体から再生した画像データを、上記バッファ
メモリに書き込む前に、このバッファメモリに上記１フ
レーム分の空きがあるかどうかをチェックし、このチェックの結果、上記空きがあるときには、上記記
録媒体から再生した画像データを上記バッファメモリに
書き込み、上記チェックの結果、上記空きがないときには、上記記
録媒体から再生した画像データを捨てるようにした画像
データの再生方法。
【請求項２】ＣＤ−ＲＯＭから再生した画像データを
バッファメモリに書き込み、このバッファメモリに書き込んだ画像データを表示用の
画像データに変換する場合において、上記バッファメモリとして、上記ＣＤ−ＲＯＭから再生
した画像データの１フレーム分よりも大きな容量のバッ
ファメモリを設け、上記ＣＤ−ＲＯＭから再生した画像データを、上記バッ
ファメモリに書き込む前に、このバッファメモリに上記
１フレーム分の空きがあるかどうかをチェックし、このチェックの結果、上記空きがあるときには、上記Ｃ
Ｄ−ＲＯＭから再生した画像データを上記バッファメモ
リに書き込み、上記チェックの結果、上記空きがないときには、上記Ｃ
Ｄ−ＲＯＭから再生した画像データを捨てるようにした
画像データの再生方法。
【請求項３】記録媒体から再生した画像データをバッ
ファメモリに書き込み、このバッファメモリに書き込んだ画像データを表示用の
画像データに変換する回路において、上記バッファメモリを、上記記録媒体から再生した画像
データの１フレーム分よりも大きな容量のバッファメモ
リにより構成し、上記記録媒体から再生した画像データを、上記バッファ
メモリに書き込む前に、このバッファメモリに上記１フ
レーム分の空きがあるかどうかをチェックする回路と、このチェックの結果、上記空きがあるときには、上記記
録媒体から再生した画像データを上記バッファメモリに
書き込むが、上記チェックの結果、上記空きがないときには、上記記
録媒体から再生した画像データを捨てる回路とを有する
画像データの再生回路。
【請求項４】ＣＤ−ＲＯＭから再生した画像データを
バッファメモリに書き込み、このバッファメモリに書き込んだ画像データを表示用の
画像データに変換する回路において、上記バッファメモリを、上記ＣＤ−ＲＯＭから再生した
画像データの１フレーム分よりも大きな容量のバッファ
メモリにより構成し、上記ＣＤ−ＲＯＭから再生した画像データを、上記バッ
ファメモリに書き込む前に、このバッファメモリに上記
１フレーム分の空きがあるかどうかをチェックする回路
と、このチェックの結果、上記空きがあるときには、上記Ｃ
Ｄ−ＲＯＭから再生した画像データを上記バッファメモ
リに書き込むが、上記チェックの結果、上記空きがないときには、上記Ｃ
Ｄ−ＲＯＭから再生した画像データを捨てる回路とを有
する画像データの再生回路。