-----ここまで図表-----
--
名古屋工業大学大学院 Ｍ２ 情報工学専攻 林研究室 朝生良教
yasou@maple.elcom.nitech.ac.jp
1995年12月、fj.rec.games.video.home.saturn と playstation に、 当時名工大の朝生氏によって相次いで二つの記事がポストされました。 当時は殆どフォローも付かず、あまり話題は盛り上がらなかった様です。
その後、少しづつゲーム機の構成などの情報が知られて来るに従い、 朝生氏の予想の当っていた部分や、外れていた部分なども出て来ています。 ですが、ユーザサイドの予想としては非常に優れた出来の物で、 未だに参考になる部分の多い、是非とも多くの人に見て貰いたい記事です。
Web 上の BBS などでハード関係の議論になる事もありますが、 こういった記事を見た事も無い人も少なくない様です。 Web と Netnews のユーザ層に差があるのかもしれませんし、 当時はまだ Web も News も読めなかったのかもしれません。
という訳で、ここにその全文を引用して紹介します。
文中にありました uuencode 部に入っていたブロック図は、
元が ps ファイルでしたので gif にコンバートして張っておきました。
From: yasou@camphor.elcom.nitech.ac.jp (yoshinori Asou)
Newsgroups: fj.rec.games.video.home.playstation
Subject: Play Station no Hardware
Date: 15 Dec 1995 08:06:02 GMT
Organization: Nagoya Institute of Technology, Nagoya, Japan
Distribution: fj
Message-ID: <YASOU.95Dec15170612@camphor.elcom.nitech.ac.jp>
NNTP-Posting-Host: camphor.elcom
朝生＠名工大です。
Play Stationのハードウェアの解説です。飽くまでも想像の域を出ない
ものではありますが公表します。ただしPlay Stationはかなり完成され
たアーキテクチャなため、あまり好奇心を刺激されず気合いも入ってい
ないので参考程度に受け止めて下さい。
以下の解説は文末に添付したハードウェアのブロック図(ポストスクリ
プトファイルでlha + uuencodeしてあります)を捕捉説明するに過ぎな
いため、読むに際しては予めブロック図を参照した方が良いでしょう。
なおブロック図では実際の基板上の構成を多少変更してあります。
-----ここから解説-----
Play Stationは一枚のシステム基板のみからなるようです。この基板上
にCD制御関連等のアナログ部まで実装されているためか、SEGA SATURN
に比べてコンデンサの数が半端ではありません。
●システム基板
便宜上システムをいくつかに分けて解説します。
★演算部
シミュレーションの思考ルーチンや3Dの座標変換、周辺の制御といった
主に演算を行なう部分です。御存知SONYカスタムのCPUはおそらく最も
高コストなチップで、R3000CPUコア、GTE(座標変換エンジン)、MDEC
(画像伸長エンジン)、キャッシュ(ダイレクトマッピングの命令キャッ
シュ4KBとデータメモリ1KB)と多チャンネルDMA等を集積しています。
CPUにはワークとして2MBのEDO DRAMが32bitバス接続されており、連続
的な読み出しであれば毎クロック読み込めます(135MB/Sの帯域幅)が、
書き込みでは数クロックのウェイトが入るそうです(ただしストアキュー
により軽減していると聞きます)。CPUが(ライン構成の)データキャッシュ
を持たないためプログラマはデータ転送について、なるべく連続的に読
み出す事とデータメモリ(スクラッチパッド)を活用して、書き込みを減
らすよう配慮する必要があると思われます。
GTE(Geometry Transfre Engine)は行列演算を高速に行なう高度に最適
化されたDSPでCPUコアにコプロセッサ接続されます。ただし一般にDSP
がパイプライン処理をするのに対し、GTEは遅延削減のため可能な限り
並列処理をするように設計されているそうです。使い方は引数レジスタ
に値を設定して専用命令を実行すると暫くの後に値が結果レジスタに戻
るそうです。更にこの間に他の命令の実行も可能であり性能を引き出す
鍵であるように思われます。性能は1秒で450万頂点の演算を実行でき、
また33回の積和演算と3回の除算を22クロックで処理するとされます。
GTEの性能の高さは特筆ものですが、欠点として精度の低さがあり、GTE
の演算結果を利用し続けるとポリゴンが変形していくそうです。故に中
間結果をワークに確保する必要があるらしく、メモリ容量に余裕のない
Play Stationでは辛い事実と思われます。なおGTEはその使途について
自由度が高いそうですが、SCEからは公開されていないそうです。
MDEC(Motion JPEG Decoder)は文字通りJPEG画像を伸長するもので、CPU
コアとは独立して動作可能です。性能は80MIPS相当で320×240の画像を
30コマ/秒で、640×240なら15コマ/秒で伸長するという事です。ただし
ソースによって可変であり内部の詳細は不明ですが、既存のソフトウェ
アからその性能の高さはどう目に値すると言えます。基本的にテクスチャ
等の画像を圧縮する目的で用意したそうですが、非可逆圧縮(完全には
復元不可能)であるためアニメ絵やドット絵の圧縮には向かないように
思われます(オーサリング次第なのでしょうが)。
DMAは重要な役割を果たすものと考えられます。Play StationではCPUに
何本(多分4本)もバスが継っており、このDMAが一手に集配を行なってい
ると思われます(司令部と集配部が一致するので速やかな転送を行なえ
理想的と思われます)。よってDMAはバスの空きをうまく利用して命令や
データを効率良く転送するのでしょう。
命令キャッシュは4KBとそれなりの容量があります。ただしR3000は命令
語長が32bit(＝4bytes)なのでSEGA SATURNのSH2の16bitに比べれば勿体
無いといえなくもありません。また命令のメモリ占有率も大きいでしょ
う。データメモリはアドレスの指定によりアクセスする高速なメモリで
あり、C言語レベルでも十分活用可能です。この使い方次第で性能が大
幅に向上するそうで、メモリアクセスの遅延もしくは書き込みのウェイ
トをかなり補えるようです。
ASCIIの開発者インタビューで、ZソートはGTEが行なうと説明されてい
ますが、これは正確には異なります。実際にはGTEが演算した結果のZ値
に従ってCPUコアがリオーダテーブル(Z値を添字とするポインタ配列)に
ポリゴンを登録する時点で自動的にソートされるのであって、コプロセッ
サであるGTEが自立的にメモリをアクセスしてソートする訳ではありま
せん。また座標変換した結果(つまりポリゴン)はリオーダテーブルによ
り管理されるリスト構造のパケットとしてワークに格納され、このため
の領域をダブル(描画参照用と演算格納用の2つ)バッファで用意します。
なおリスト構造であるため、パケットの挿入や削除が容易であり、「何
階層でも階層化」や「入れ子構造になるようなものも」できます。Zソー
トを基盤としたこの方法はハードウェアにより支援されています。
Play Stationは演算や処理の形式に関してとても洗練されていると言え
ます。しかしその形式の良さと性能の高さに比して、ワークの容量が不
十分ではないかと思われます。またR3000がリトルエンディアンである
ためか画像データの規格(TIM)がそれに合わせたものとなっており非常
に分かり難く感じられます。
★描画部
CPUによる演算とは並列に描画をする部分です。描画エンジンであるGPU
はCPUと32bitバスで接続され、また1MBのフレームバッファであるデュ
アルポートVRAMとも32bitバスで接続され、共に帯域幅は135MB/Sとされ
ます。フレームバッファには表示用のダブルバッファ、テクスチャと
CLUT(自由配置パレット)を混在させる構成が採られ、1024×512×16bit
＝1MBのイメージ領域中にそれぞれ確保します。ただしダブルバッファ
用の最小256×448〜最大704×488領域は左上固定でピクセル当り16bit
である事も(基本的に)固定です。よってPlay Stationではフルカラー
(24bit)表現は基本的に32768色(15bit)によるディザによって実現され
ます。
Play Stationでは色データは基本的に15bitであるという事は断ってお
くべきでしょう。残りの1bitはテクスチャ等においてα(半透明)フラグ
として利用されます。例えば半透明色を持つポリゴンをあるポリゴンの
上に上書きするとすると、その色(フラグの立った色)を書き込む場合に
は書き込むピクセルの色を拾って双方の色から半透明色を計算してから
書き込みます。
上記の説明から分かるようにGPUはZ値に従って画面の奥のポリゴンから
描画します。ASCIIにおいて「手前から描画する」と注釈されています
がそれは間違いです。よってGPUはポリゴンを奥から上書きしていくの
で、無駄な描画をしない事がより多くのポリゴンを描画する秘訣になり
ます。なお半透明処理はリードモディファイライト(読み出して加工し
て書き込む事)なので転送量は通常の倍になります。
テクスチャの種類は4bit CLUT、8bit CLUT、15bit Directが選択可能で
す。32bitバスで読み出す場合はそれぞれ8、4、2ピクセル分に相当し速
度とメモリ容量を重視すると4bitのCLUTを選択することになります(シ
ステム11からの移植は主にこのテクスチャの減色によると思われます)。
なお24bit Directも用意されてはいますがこの場合ポリゴンを1面しか
表示できないそうなので、おそらくは静止画用か将来の拡張(フルカラー
動画デコーダかフルカラーアクセラレータ)を考えての仕様と思われま
す。CLUTは4bit CLUTの場合16bit×16個、8bit CLUTの場合16bit×256
個が横一列に並びます。
処理の流れとしてはGPUがCPUワークのパケットを参照し(SEGA SATURNで
はCPUからのコマンドを要するそうですがGPUは勝手に行ないます)、描
画座標やシェーディングのための輝度情報、CLUTやテクスチャの場所等
をGPU内のプリプロセッサが解釈します。その後はシェーディング(陰影
付け)と同時にクリッピング(画面をはみ出すポリゴンの処理)を行ない、
必要に応じてCLUTやテクスチャを読み出してテクスチャマッピング(絵
貼り)や、半透明処理等を行なうという事です。
ハードウェアのクリッピング機能は高いらしくクリッピングによるテク
スチャの歪みは目に付かないように思います(SEGA SATURNは目に付く)。
しかし基本描画プリミティブが三角形であり、テクスチャマッピングで
パース変形を行なわないため四角形のポリゴンを表示させると三角形同
士の接合部の不整合が非常に気になります(基本プリミティブが四角形
のSEGA SATURNはそれほど気にならない)。
フレームバッファには読み書きが共に32bitバスにより連続的に可能で、
特に書き込みをクロック当り2ピクセル行なえるため、SEGA SATURNより
は遥かに高い描画能力(ピクセルフィルレートは67Mピクセル/秒)を持っ
ています。またフレームバッファにあるもの全ては画像であり自由に材
料として利用可能で、ムービーをテクスチャとしてポリゴンに貼ったり、
フレーム(描画結果)をテクスチャにする(闘神殿のカインステージのTV
のように)事が可能で表現の自由度は高いと言えます。
ここで1MBのダブルバッファの画面モードを考えてみると、横320では
320×240×16bit×2＝300KB
で724KBがテクスチャ等に使用可能ですが、横640では
640×240×16bit×2＝600KB
で324KBになってしまう事が分かります(これは640×480のインタレース
でも同じ)。通常は背景を1枚は表示するでしょうからテクスチャ等の領
域が非常に厳しい事が分かると思います。また画像は2次元として扱わ
れる為に大きくて置けない事や隙間ができる事も考えられます。なお
640×240の60コマ/秒と640×480の60コマ/秒(インタレース)とはフレー
ム構成は基本的に変わりませんが、インタレースの場合は演算と描画が
確実に秒間60コマで完結しなければ画面が乱れてしまいます。よって処
理落ちは許されません。
GPUは3Dポリゴン描画専用のプロセッサとの認識が一般的と思われます
が実際は完全な2D設計で、この点SEGA SATURNのスプライト描画プロセッ
サのVDP1と(基本的に)変わらないと思われます。ただしGPUはレンダリ
ング機能はすべからく使用されるものとして充実している点が設計思想
(経緯)の違いを際だたせていると言えましょう。
★音源部
音楽関連の処理を担う部分です。音源チップSPU(Sound Processing
Unit)は16bitのサブバスに接続され、その帯域幅は17MB/S(4クロック単
位でアクセスする？)です。またSPUにぶら下がる形でサウンドバッファ
0.5MBがあります。SPUの扱うデータはADPCM(量子化方向に非可逆圧縮す
る方式)データであるため0.5MBのバッファ容量とその帯域幅をPCM方式
のSEGA SATURNよりも効率的に利用すると考えられます。最高24チャン
ネルを管理し、またADPCMデータをSPU内部でPCMデータに展開してから
加工するのでしょうから高い処理能力を有すると思われますが、機能的
にはSEGA SATURNほど凝っていないようです。またSPUの制御はCPUが行
ないます。
★拡張部
PIO(拡張コネクタ)です。端子数は68と少なく、これだけでは将来フル
カラーの映像出力が可能なグレートなアクセラレータが登場するか疑問
です。配線から読み取る限りではSPU等が継る16bitのサブバスへの接続
とCPUへの12本の接続が確認されます。アクセラレータのフルカラーの
映像出力であれば最低でも秒間704×488×24bit×60/2≒30MBの帯域幅
が必要で、音声出力も合わせれば17MB/Sのサブバスでは絶対的に足りま
せん。以上から想像するに、PIOをアクセスする場合のサブバスの帯域
幅は16bit×33.8MHz≒67MB/Sであり、17MB/SはSPUのバッファDRAMのサ
イクルタイムによる値ではないでしょうか。こう仮定すると先の12本の
接続は制御用バスではないかと思われます。
★通信部
パッド、メモリカード等のPlay Station本体前部の端子との同期シリア
ル通信と後部の端子との非同期シリアル通信を行なう部分です。パッド
には十分な通信速度が確保されているようですがメモリカードとの転送
には甚だ役不足と言わざるを得ません。Play Stationにケチを付けられ
る数少ない部分でしょう。なおブロック図では1チップのSIOが集中して
処理するように見えますが、実際には2つのチップから構成されている
ように思われます(インタフェース側の基板にある？)。
★CD-ROMドライブ制御部
CD-ROMドライブとその機械的な制御を行なうCD DSP、論理的な制御及び
バッファ管理を行なうCD-ROM DEC.、バッファ用のSRAM32KB、CD DSPと
サブバスとの橋渡しを行なう(らしい)SYSCONから構成されるようです。
基板上で非常に分かり難く信ぴょう性が高いとは言えません。読み込み
バッファが32KBと小さい(SEGA SATURNは0.5MB)のは「誤り訂正が解けれ
ばいい」とい程度で良いとの考え方によります。よってCD-ROM DEC.の
インテリジェント制御はSEGA SATURN程ではないでしょう。またCD-ROM
ドライブの読み取り精度随分低いようで改善が望まれます(この点SEGA
SATURNは優秀です)。ブロック図ではCD DSPからDACへの出力バスがあり
ますがこれは定かではなく意味があるとも思えません。
★表示部
さっぱり分かりません。デュアルポートのフレームバッファからラスタ
データを良み出すASICがありますが、GPUからもこのASICに出力されて
いるようにも見えます。しかしこれはASICのピン数(64ピン)から考えて
無理があります。またASICからの出力も判然としません。最終的には
NTSCのチップに行くのでしょうが、その経路はバスが見当たらない事か
らアナログではないかと思われます。よって完全に想像ですが、ASICか
らはRGB各5bitずつがそれぞれDACに入りまたGPUからの出力も専用のDAC
に入り、R、G、Bのアナログ信号としてNTSCのチップに入るのでしょう
か(何とも間抜けですが)？こう仮定するとフルカラー(24bit Direct)出
力は専用の経路を通るという事で、フレームバッファのデータはGPUが
読み出し、PIOからはCPUを経由するという事になりあまりすっきりとし
ません。なお以上の想像に基づいてブロック図は描かれています。
●総合
Play Stationは非常に完成度の高いハードウェアだと言えます。適切な
処理分散と徹底的な並列処理、要する帯域幅に見合ったバス構成、コス
トを考え抜いた無駄のない実装(精度は最適化され、部品点数は少なく
実装密度は高い)と感心させられます。しかしメモリ容量やCD-ROMドラ
イブ等に関してはもう少し贅沢に造って欲しかったという気がします。
この辺りが良くも悪しくも「SONYらしい割り切りの良さ」なのでしょう
が。
-----ここまで解説-----
飽くまでも予断と推測の産物である事は宜しく承知下さい。特に断定調
の表現を用いていても必ずしも確かではありません。また横文字や専門
用語の氾濫は避け難く、不明瞭な筆致と併せて勘弁願います。
-----ここから図表-----
-----ここまで図表-----
--
名古屋工業大学大学院 Ｍ２ 情報工学専攻 林研究室 朝生良教
yasou@maple.elcom.nitech.ac.jp
From: yasou@fir.elcom.nitech.ac.jp (yoshinori Asou)
Newsgroups: fj.rec.games.video.home.saturn
Subject: SATURN no hardware'
Date: 5 Dec 1995 07:34:56 GMT
Organization: Nagoya Institute of Technology, Nagoya, Japan
Distribution: fj
Message-ID: <YASOU.95Dec5163417@fir.elcom.nitech.ac.jp>
NNTP-Posting-Host: fir.elcom
朝生＠名工大です。
前にポストしたSEGA SATURNのハードウェアの解説の改定版です。飽く
までも想像の域を出ないものではありますが公表します。
以下の解説は文末に添付したハードウェアのブロック図(ポストスクリ
プトファイルでlha + uuencodeしてあります)を捕捉説明するに過ぎな
いため、読むに際しては予めブロック図を参照した方が良いでしょう。
またSH2の仕様表(同じファイルにアーカイブしてあります)を巻末に添
付しました。
-----ここから解説-----
SEGA SATURNの基板はメインシステム基板とCDサブシステム基板とに分
けられます。CDサブシステムは文字通りCD-ROMドライブ関連部及び外付
け(つまりオプション)のムービーカードからなり、それ以外がメインシ
ステムになります。
●メインシステム
便宜上メインシステムをいくつかに分けて解説します。
★演算部
シミュレーションの思考ルーチンや3Dの座標変換、周辺の制御といった
主に演算を行なう部分です。周知の通りSH2のツインCPU構成で、ワーク
として1MBのSDRAMのみがぶら下がった32bitのデータバス一本を共有し
ていると思われます。SH2のキャッシュはライトスルー(ストアでは必ず
メモリをアクセスする方式)ですからストアの競合が懸念されます。よっ
てツインCPUのプログラミングは、短期局所的には定期的なバスの解放
を、長期大域的にはデータ転送量の減少と均等な処理分散を心掛けるの
でしょうか？キャッシュが分散処理に不向きとはいえ、ワークメモリは
リード/ライト共にバースト転送可能であり、また「レイテンシ(アドレ
スを与えてからデータを読み書きできるまでの遅延)は非常に小さい」
そうで、非常に優秀なメモリシステムではあります。
ワークのSDRAMは多チャンネルDMAであるSCU(System Control Unit)にも
共有されます。SCUは分散したプロセッサにコマンドやデータを効率良
く転送するために多く(多分５本)のバスを管理するASICでその1つに残
りのメインメモリでバッファとしての1MBのDRAM、ROM、バックアップ用
SRAMをぶら下げた16bitバスがあります。ただし1MBのDRAMを16bitでア
クセスするのは考えにくいので間違っているかも知れませんが、後述す
るASICのピン数から考えるとこうなってしまいます。このバスにはCPU
バスも継っていますがASIC(100ピン)を間に挟んでいるため、CPUがワー
クをアクセス中ならSCUが独立してバッファ等をアクセスできると考え
られます。開発者の言う「バスは何本もある」とは主に、2MBのメイン
メモリの内ワーク1MBをCPUがバッファ1MBをSCUが独立してアクセス可能
である事を指しているのでしょう。またこの場合プログラムにおける基
本的なメモリ配置は頻繁にアクセスする領域をワークに当て、それ以外
はバッファにという事になります。
それにしても1MBのワークにバーストアクセスできるという点はやはり
特記すべき点だと思われます。Play Stationではバーストリード(連続
読み込み)は出来てもライト(＝ストア)は数ウェイト入るそうで(ストア
キューにより軽減しているそうですが)、独自ルーチンによるムービー
の展開などの大量のメモリアクセスを伴う処理はSEGA SATURNに向いて
いるといえそうです。
またCPUであるSH2の演算能力は既成のソフトを見る限りでは以外に高い
ように思われます。DSP機能が強力な事がその主因と考えられ、これは
行列演算に威力を発揮します。行列演算で行なう配列どうしの
積＋積＋…
つまり積和演算の基本単位を1命令で実行可能で、連続的に実行する場
合は32bit×32bitで(理想的には)2クロック毎に効率良く処理できるの
でしょう。これは他の多くのプロセッサにない特徴です。とはいえ、
Play StationのGTEは更に強力で33回の積和演算、3回の除算を22クロッ
クで処理するそうです。
他にも16bit固定長命令であるため命令のメモリ占有率が低く、キャッ
シュのヒット率も高いものとなります。Play StationのR3000の4KBの命
令キャッシュ相当のヒット率を半分の2KBで得られる訳です。またキャッ
シュは1KB単位でメモリとしても扱うことが可能で、混在型キャッシュ
であることも併せて自由度は高いようです。更にPlay StationのR3000
はデータキャッシュを持たない(かわりにスクラッチパッドという1KBの
データメモリがあるらしい)ため、キャッシュ再補填で行なわれるバー
ストリードの恩恵に浴し得ない(かもしれない)のに対し、SH2ではそれ
が可能です。ただしヒット率が高くないと効果は期待できませんが。
後は選択可能な遅延分岐、68000に似た命令体系等によりアセンブラで
開発し易い事が挙げられます。弱点は汎用レジスタが16本(R3000は32本)
と少ない事、分岐やメモリアクセスのオフセットが短くプログラマが注
意や技術を要すること、動作クロックが低い事等でしょうか。
★描画部
CPUによる演算とは並列に描画をする部分です。ポリゴン・スプライト
用のVDP1と背景用のVDP2で構成され、VDP1は32bitバス接続のスプライ
トパターン(テクスチャ)メモリ0.5MBと16bitのフレームバッファ0.5MB
を、VDP2は32bitのBGパターンメモリ0.5MBとおそらくチップ内に
2KB(704×24bit)前後のラインバッファと4KB(1024×32bit or 2048×
16bit)程度の統合パレットをそれぞれ専有すると考えられ、チップ外の
メモリは皆SDRAMによる実装です。このSDRAMの内訳の根拠はVDP1とVDP2
に共通するパターンメモリ0.5MBが2Mbit(×16bit)×2であることにより
ます。特にわざわざ2Mbitという半端なサイズを選択するのは×16bit×
2で32bitアクセスを実現するためだと思われます。
パターンメモリにはパターンのみでなくプログラム(おそらくはスプラ
イト座標等)も格納するとの事で、Play Stationがワークにパケットと
して置くのとは好対象といえます。ただし0.5MBに座標データ全てを入
れるとは考え難いので間違っているかも知れません。パターンの転送は
SCUからの16bitバスによって行なわれ、その帯域幅は50MB/S(16bit×
28.7MHzで57.4MB/Sだと思われるが…)とされ、多少物足りなさを感じま
す。
大まかな挙動を追うと、VDP1はパターンを読み出しながら並列にフレー
ムバッファへ書き込み、一定期間毎に前フレームのラスタデータをVDP2
に送出します。VDP2は読みだしたパターンデータによりラスタ単位に描
画する背景と、VDP1からのラスタデータ、そして後述するムービーカー
ド等からのラスタデータを優先度に応じてラスタ単位に合成しビデオ出
力に送ります。
ここで特に言及しておきたいのは、VDP2はラインバッファに毎ラスタ描
画する性質上、処理落ちはしてもコマ落ちはしない事です。これはライ
ンバッファのみからなるスーファミがちらつきはあってもコマ落ちはし
ないことから分かると思います。よってSEGA SATURNにやたらとフレー
ムレート(表示コマ数)の低いソフトが多い理由はフレームバッファ方式
のVDP1に求めるべきでしょう。VDP1ではパターンは32bitバスにより読
み出され、しかもフレームバッファへの書き込みと並列に(少なくとも
ある程度オーバーラップして)行なわれるため、処理のボトルネックは
16bitバスのフレームバッファへの書き込みと断じて良いでしょう。な
お開発者の言う「テクスチャを貼ろうが貼るまいが変わらない」のは上
記の並列処理によると思われます。
ボトルネックの要因は、バスが16bitであるためクロック当り1ピクセル
しか転送できない画面モードがあること(Play Stationでは通常16bitで
クロック当り2ピクセル)、VDP2へのラスタデータ転送のためにピクセル
フィルレート(単位時間当り何ピクセル描画できるかの指標)が一画面×
60コマ分だけ低下することが挙げられます。試算してみると、1ピクセ
ル/クロックで解像度が320×224として
1ピクセル×28.7MHz - 320×224×60＝24399200 ピクセル/S
≒406653.3 ピクセル/フレーム
が得られ、開発者の言う「純粋なピーク値でフレーム当り40万ピクセル」
に近い値であることが分かります。参考までにPlay Stationは67Mピク
セル/Sですが、テクスチャ等の読み出しによって何割か減少するはずで
す。またこの発言から、ピクセルフィルレートは8bitピクセルの画面モー
ドにおいても倍にはならず、この値が上限であることが伺えます(つま
りこの場合1バイト単位で書き込むのだろうか？)。またスプライトを背
景に合成する都合上、未描画領域は透明化する必要があり、合成の優先
度等によっては描画に先だって画面を消去すると考えられます。この場
合、更に一画面×コマ数分の転送能力が失われるため、SEGA SATURNで
60コマ/秒を実現する事はなかなか難しいように思われます。
ここで0.5MBのダブル(表示用と描画用の2つを用意して切替える)フレー
ムバッファの画面モードを考えてみると、横352では
352×240×16bit×2＝330KB
で16bit/ピクセル、横704では
704×240× 8bit×2＝330KB
で8bit/ピクセルになることが分かります。おそらく16bitの場合は256
個を越えるパレットかハイカラー(65536色)を、8bitの場合は256個まで
のパレットを指定するのでしょう。よってハードウェアで用意されたシェー
ディング、特にグーロは16bitのハイカラーでなければ困難であると思
われます。なおVF2では上記の704×480(または448?)の画面モードを使
用しているようですが、この場合も1フレームは704×240ですからフレー
ムバッファを330KBしか使用しません。つまり0.5MBの内182KBは常に使
用されない事に？
VFでは8bitモードでフラットが(ソフトウェアで)実現されていたのでしょ
うが、Remixでテクスチャが貼られたらフラットは廃止されてしまいま
した。これはテクスチャを貼られたポリゴンにシェーディングを施すと
テクスチャの各色に階調差が加わるため、パレット方式ではその色数を
網羅し切れないことが問題となるのでしょう。故にVF2でもフラットは
実現されませんでした。不可能ではないと思いますが困難ではあるでしょ
う。
VDP1では描画に関してパターンメモリは読み出すもの、フレームバッファ
は書き込むものとして扱われるため、フレームバッファからの読み出し
を必要とするスプライト・ポリゴン間の半透明処理は実現できないと思
われます。よってこれはメッシュによって代用されます。また同様に前
フレームの画像をテクスチャにするような(TVによる実況中継のような)
表現も出来ません。よってこういった半透明などの特殊効果はVDP2にお
いての合成時にしか出来ないのでしょう。
VDP2のラインバッファは背景の描画と、VDP1とムービーカードからの入
力の合成に利用されます。VDP1からの入力データは最高16bitでありフ
ルカラー表現できないため、VDP2保有のカラーパレットで24bitに変換
されて書き込まれるものと思われます。この合成がスプライト、背景と
いった入力単位に行なわれるため、例えば背景1と背景2の間にスプライ
トを挟む事はできてもスプライト1とスプライト2の間に背景を入れると
いう事は理論的にできません。またVDP1(スプライト)の横の解像度が低
い(背景の半分の)場合でも背景は高解像度を保つことが可能です。つま
り低解像度のスプライトと高解像度の背景が混在し得る事になります。
これは多分ムービーについても言える事でしょう。
また背景に施す特殊効果にスクロール機能や軸回転機能があります。背
景の同時表示面数の詳細は定かではありませんが、軸回転背景に関して
はレイヤーセクションから2軸回転が2面、VF2から3軸は1面が現在のと
ころ上限を示していると思います。この見解を打破すべくパンツァード
ラグーン2では空も3軸回転背景で実現して欲しいものです。
★音源部
私は音楽関係には疎いのであまり詳しくは触れません。
音楽関連の処理を担う部分です。SCUからの16bitバスに継る音源チップ
SCSP(Sega Custom Sound Processor)と、それにぶら下がる形で制御用
の68000とサウンドバッファ0.5MBがあります。SEGAのハードウェアの伝
統により音源制御専用のサブCPUとして68000を用意したそうですが、
SH2にとって音源制御が68000を必要とする程重い処理とは思えません。
音楽が処理落ちしなくなるとはいえ、専用のプログラムも組まねばなら
ない事でしょう。またSCSPが扱うデータはPCMなので0.5MBのサウンドバッ
ファは非常に狭いものと思われます。なお68000による制御の一例とし
て3D空間の音像定位があり、この場合68000が定位座標の計算を行なう
そうです。このようにメインのCPUとは独立して「自由に動ける」事が
特徴だそうです。
またマルチメディア端末絡みでかなり凝った作り(ボイスキャンセル機
能など)のようでカラオケでも活躍しているそうです。
★拡張部
SEGA SATURNの特徴でもある拡張スロットです。非常に多くの端子数(67
×2)があり、その配線は良く分かりません。一見するとスロットの端子
が左36、右31の間で分かれており、意味有りげではあります。想像では
SCUと16bitのバスで接続され(右側か？)、パワーメモリなどが利用する
のでしょう。また将来登場するかも知れないグレートなアクセラレータ
のフルカラーの映像出力をVDP2に送るための24bitの単方向バスが接続
されているように思われます。これはムービーカードのフルカラー出力
にも利用されると考えられ、共に未接続であれば使用されないはずのバ
スです。また通信端子が接続されているらしく、それを利用するための
カートリッジを挿すことで通信を実現するのではないかと想像されます。
端子数から考えればまだなんらかの接続があるかも知れません。
★入力部
パッド等のSEGA SATURN本体の前部の端子からの入力を処理する部分で
す。SMPC(System Manager and Peripheral Controller)が2つの端子か
らの入力をSCUへ送出するという程度しか分かりません。
★SCU
既に何度か触れている多チャンネルDMAのASICです。SEGA SATURNの肝と
も、影の功労者ともいうべきチップと思われます。本来バスやメモリへ
のアクセス競合があるといずれかが待たねばなりません。これは複数の
主体が単一の資源を利用する事に起因します。SEGA SATURNのような分
散処理を行なうハードウェアでは処理すべき材料の獲得や処理した結果
の配送と、各所に双方向で転送する必要があり、このために生じる待ち
が全体の性能を大きく落す要因になりかねません。よってSCUでは各チャ
ンネルについて要求を受けたら転送の責を負い(つまり要求元はすぐ次
の処理に移る)、バスの空きを利用して転送を行ない、終了したら通知
するというように働くと思われます。またSCUではDSPを内蔵しており、
使い方次第では強力なものとなるかも知れません。
●CDサブシステム
★CD-ROMドライブ制御部
CD-ROMドライブ、SH1、0.5MBのCDバッファ、DMAのASICから構成されま
す。CD-ROMドライブの制御やデータの読み出し、バッファ管理をサブ
CPUであるSH1が与えられたコマンドに従って行ないます。制御プログラ
ムはSH1の内部ROMに格納され、コマンド一つでインテリジェントな制御
を行なえるのでしょう。ただしチップ内のROMで動くのだとすると、SH1
用のプログラムを書くことで、例えばADPCMデータをPCMデータに変換し
て転送させるなどということは出来ないかもしれません。しかしSH1の
オンチップROMの容量は64KBと大きく16bit固定長命令とも相まって、複
雑なプログラムが組み込み済みとも考えられます。CD-ROMドライブから
のデータは内蔵DMA用のバスから受けとり、通常のバスでバッファに格
納するのでしょうか。バッファの0.5MBという容量はかなり大きく(Play
Stationは32KB)データの先読みなどに威力を発揮することでしょう。レ
イヤーセクションのローディングを感じさせない点はこの御蔭かも知れ
ません。メインシステムのSCUとのコマンドやデータのやりとりのため
のASICは16bitのバスを有します。なおメインシステムとの接続端子数
は100(50×2)です。
★ムービーカード部
オプションで接続する、MPEGデータを展開する部分です。CD-ROMドライ
ブ制御部のASICとの接続端子数は100(50×2)です。インタフェースとし
てはCDバッファからデータを読み出すための16bitバスとフルカラーの
画像を送り出す24bitの単方向バスがあるように思われます。16bitバス
はASICに接続され、24bitのバスはそのまま拡張スロットのバスと合流
しVDP2に直接入るようです。
カードは1MBのデュアルポートのVRAMとMPEGデコーダ(Photo CDデコーダ
などもあるそうです)、及びROMから構成され、352×240のムービーなら
ダブルバッファ方式で秒間30コマで展開しつつ1/60秒毎にVDP2に送り出
せるのでしょう。704×480でフルカラーの場合画像1枚が1MBのVRAMをほ
ぼ占有してしまうのでダブルバッファ構成を採れないため静止画のみの
表示となります。また特殊機能としてムービーの画像の背景を透明化し
てVDP2でBGやスプライトと合成させるといったことが可能です。更に
SCUを経由する場合はVDP1やVDP2のパターンメモリに転送することでムー
ビーの変形や拡縮といった効果も実現可能です。ただしこの構成(特に
デコーダとデュアルポートVRAMの1MB)で￥19800はかなり無理があると
思われますので、異なる可能性は高いでしょう。
●総合
SEGA SATURNは徹底した分散処理指向のマシンといえます。対抗機であ
るPlay Stationが主に演算用CPUと描画用GPU、音源用SPUにそれぞれメ
モリを与えて分散処理するのに対し、SEGA SATURNでは演算用にツイン
CPU、描画用ツインVDP(しかもVDP1ではパターン用とフレームバッファ
用にメモリを分割)、音源用SCSPに制御のための68000、CD-ROMドライブ
用SH1という分散ぶりです。ここまで徹底していると構造としては面白
いのですが、分散すれば効率が落ちたり融通が利かなくなるのが道理で…
プログラマは大いに苦労することでしょう。
個人的にはSEGA SATURNの身上は3軸回転可能な背景を持つ事にあると思っ
ています。パンツァードラグーンの地平線が破綻なく見える辺りに幸せ
を感じますね。
-----ここまで解説-----
飽くまでも推測と予断の産物である事は宜しく承知下さい。特に断定調
の表現を用いていても必ずしも確かではありません。また横文字や専門
用語の氾濫は避け難く、不明瞭な筆致と併せて勘弁願います。
-----ここから図表-----
-----ここまで図表-----
--
名古屋工業大学大学院 Ｍ２ 情報工学専攻 林研究室 朝生良教
yasou@maple.elcom.nitech.ac.jp
基本的に、趣味でコンピュータ触ってるだけのシロウトのタワゴトです。
間違い等の御指摘やアドバイス等ありましたら、
dmizuno@geocities.co.jpか、
dai@synnet.or.jpまで
mail して頂けると有難いです。
このホームページのホストは
です。無料ホームページ
をどうぞ