変換後そのままなので、ほとんど意味不明ですが原文と照らし合わせれば ニュアンスくらいはわかるかもしれません。
秘密のほのめかしLibdream 0.95/プログラマーがマニュアルである (c) 2000ダンポッター \tableofcontents{} 法律 Dreamcast''は、 「Sega''」 「および」 セガ・エンタープライゼス，Ltd．これのパ ッケージの登録商標であり セガまたはその支店のうちの誰との交際でも全然持っていな い 、さらに、それらのハードウェアに取り組む。 すべての他の商標はそれらの個々の商 標ホルダーにより所有されている。 libdream（c）2000ダンポッター、ヨルダンDeLong。 他の部分（c） それらの個々の作者 ； どうぞ、使うことおよび／またはそれらのコードをdistriburingすることについての 情報のための作者に連絡してください。 Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the ``Software''), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: 上記の著作権注目と以下の許可注目は、ソフトウェアのすべてのコピーに含められている こととする： ソフトウェアはどのような種類の保証なしで提供される 急行である または 暗示されている 含むけれども、それ、市販性、特定の目的と不侵害のための適 切の保証に制限されない。 どのイベントにおいても、版権所有者保持がしないようにしよ う 損害 どのような主張にでも責任がある または、他の責任 契約の行動、不法行為、またはさもなければ ソフトウェアについて 、またはソフトウェアまたはソフトウェアの他の取引の使用に関連してそれのため起きる 。 事前の書かれた認可なしで版権所有者から使用またはこのソフトウェアの他の取引を促進 するために宣伝または違った形で版権所有者の名前が用いられないであろうこの注目にお いて含まれているそれゆえを除いて。 はじめに Libdream 0.95 へようこそ！ この新しく、改善されたバージョンは、人々がよくと長時間 要求しているたくさんの特別ないいものを持っている。 どんなLibdreamがであるかのよりよい説明のために、どうぞ、パッケージディレクトリの ルートのREADMEファイルをちらりと見てください。 したい最初の物はであり、Libdreamをコンパイルする。 プリコンパイルされたライブラリ がデフォルトオプションでパッケージに含められて、例をコンパイルするために、これを 使用できる。 しかし、もしプログラムのためにそれらが必要ならば、ライブラリ自身をコ ンパイルすることは、コンパイラ環境が適切にセットアップであり、それが、変化を起こ すことを可能にすることを確かめるのに役立つであろう。 私達は、ランタイムでほとんど のプログラムのために必要なすべてが入手可能であることを確かめようとしたけれども、 私達はいつもすべてについて考えるわけではない。 従って： オープンソース！ もし適切なSH-4コンパイル環境を持っていないならば、たぶん、そのセットアップを得て 出発する必要があるであろう。 それはこのlibdream文書のための機会の外のビットである 。従って、ちらりと見たいこと例えば、それを得ることの詳細についてのHitMenのDCサイ ト。 開始するためには、ファイルを編集する libdreamルートのMakefile.config 。 私のシ ステムとマッチしているデフォルトコンパイラパスのセットを見つける。 システムと適切 にマッチするように、これらを変更するべきである。 もしすべてがよいならばMakefile.config一度が編集される 『作る』をタイプし、すべて を築かせることができるはずである（例を含む）。 BSDにおいてgmakeを使う必要があること、または潜在的 "MAKE=gmake gmake'' （強打語 法において）。 Cygwinユーザーは、"make''を使い、それにokをコンパイルさせることが できるはずである。 もし編集したく まさに例 、libdreamステップを、， そして、それ"に前のようなMakefile.config と変化を編集する で省略し examples'' 、それから、するならば 制作／gmakeステッ プ 。 これは例のうちのすべてを築き、貯蔵箱とsrecだけを個々のディレクトリに置いて いく。 これらは、直流-ツール/DDHまたはマーカスComstedtの連続したスレーブ（各）を 使ってロードできる。 個々の例プログラムは、それを実行する前に見るべき操作に注を持っている。 それらのほ とんどは、デフォルトで、連続したアウトプットを持っている。従って、もしCDRを使って それらを動かしたいならば、dc_setupの前にserial_disableを追加する必要があるであろ う。 あなた自身のlibdream-ベースのプログラムをコンパイルするために、付け加えて 適切が 含むおよび 必要がある CCとLDラインへのlibパス 。 これらは、 「include''」 「 および」lib''である libdream根のサブディレクトリ 。 さて、それが邪魔にならないところに（希望的）であるので、私達は、onにおいて、libdream プログラムを書くことに進む。 基本的なLibdreamプログラム A libdream program is pretty simple and straightforward -- you should have a ``main'', which is called ``main'' if you're using a default crt0, or ``dc_main'' if you use my (Dan's) crt0. この主要なルーチンの中では、2つの物のうちの1つをする： libdreamのほんのわずかのサ ブシステムを初期設定し、それらを使うか、または、dc_setupによって完全な初期設定を し、そこから行く。 もし少しを使うだけの非常に簡単なプログラムを持っているならば、サブシステムの小さ い部分だけを初期設定する主要な有利は、それらにより持たれている。 例えば、ユーザーにシリアルポートの上のメニューを表示する予定をしたいかもしれず、 それらにVMUファイルを管理させる。 このケースにおいてした カエデサポートおよび連続したサポートが必要であるだけであ る 。従って、終了したプログラムのバイナリのコードの8kについて保存できた。 これは 、本当は、重要な利点 けれども 一般に、libdreamのうちのすべてを含んで以来20kにつ いてかかり、手動のinitializaingがうつ伏せのエラーと買手危険負担である ではない； たとえどのように望んでも、それをする。 ドキュメンテーションの残りのために、私は、完全な初期設定をしていると想定しようと している。 この完全な初期設定によりその上、2つのフォームが取られうる： 正常および 静かなフォーム。 それが、あなたに、それが生きていると言っているスタートアップ、お よびカエデバスに取り付けられるものについてのいくらかの情報を与えるので、普通の形 は、デバッグするのに良い。 もし連続したプロトコルを実装する何かをしたく、従って、 完全に連続しているので、使用不可にしたくないならば、静かなフォームは有益であるけ れども、あなたもごみを正面に望まない。 基本的な正常な呼び出しはこれのような何かと思われている： dc_setup（DM_640x480、PM_RGB565）； 640x480モードを持つこの呼び出し意志セットアップビデオ、R／G5/6/5のピクセルフォー マットを持つ色深さ16。 他の選択は、秒の間最初のパラメータ、およびPM_RGB555とPM_RGB888 のためのDM_320x240とDM_800x608である。 いつも最も最新の情報についてdream.hをチェ ックするべきである。 dc_setup一度は呼ばれて、すべてのハードウェアは初期設定されて、タイルアクセレータ の主要な例外と一緒に行くために用意されるべきである。 それが、正常なビデオセットア ップが作るというたくさんの仮定をなぐり倒すことをだいたい必要とするという点でTAは 特別で、それは少し長い間取る。 コードはまた、他のサブシステムに比べてかなり大きい 。 これらの理由のために、ta_initはデフォルトで呼ばれないけれども、TAライブラリの どのような部分でも使う前に、それを呼ばなければならない（テクスチャーロード、ポリ ゴンなど）。 おめでとう！ 現在最初のlibdreamプログラムに書いた（＾＾）／。 種々のサブシステムの詳細について、どうぞ、章がそのシステムに捧げられるのを見てく ださい。 例のために、theを見る libdreamルートからの"examples''ディレクトリ 。 サブシステム 基本的なlibdreamプログラムが何のように見えるかを知っているので、たぶん、理解し、 どのようにライブラリの様々な部分を使い始めたい。 以下の章は、私が最初に意図したも ので親切なチュートリアルより参照マニュアルの方法の多くである。 ^_^； 3.1 データ型 個々のシステムにおいて私達がスタートする前に、私はデータ型についての小さい言葉を 描いた 注文である 。 libdreamのほとんどすべてはデータ型.dream.hのための以下の会 議を使い ビットの適切な数.uint8、uint16、uint32のサインされた整数とマッチするよ うに、タイプint8、int16、int32、およびint64を定義する 、uint64は同じであるけれど も、未契約である。 ブーリアンまたは計算は、しばしば、「int' ' 『と計算は、通常 そうである」uint32'』 ' として蓄えられる。 0のint.ストリングが「雑用*」として蓄 えられると、エラーを戻すことができる機能は一般にネガティブなintとしてのそれら、お よび成功を戻す。 Indivudualキャラクタは一般に"int''である。 3.2 連続している（serial.c） 連続したシステムはtheにアクセスする SH-4CPUの"SCIF''（シリアル通信インタフェースw/FIFO ） 。 CPUのこのポートは、ドリームキャストの外部"連続I/O''ポートに取り付けられる 。 連続したモジュールの様々な機能はかなり直接的である。 ここにはそれぞれの短い説明がある： 3．2．1について空のserial_身体障害() 連続したモジュールを通して、連続したアクセスを使用不可にする； すべての連続したア ウトプットは処分であり、連続したインプットによって、いつもキャラクタavailable''は 全然戻らない。 これは、一般に、連続したアウトプットが完成することを待つことが、不 開発マシンに依存しないようにプログラムをCDRに燃やす前に使われる。 3．2．2について空のserial_init（intボー） 与えられたボーレートによってSCIFインタフェースを初期設定する。 割込みは消されて、FIFO によるフロー制御は可能である。 3．2．3について空のserial_write（int c） 単一のキャラクタをSCIFアウトプットに書く。 キャラクタが、送るFIFOの状態に依存して 送られえないことに注意する。 もし即時のアウトプットを望むならば、serial_フラッシ ュ()を呼ぶ必要があるであろう。 3．2．4について空のserial_フラッシュ() 送るFIFOにとどまるフラッシュすべてのデータ。 実際すべての列を作った連続したアウト プットが送られることを保証するために、これを使用する。 3．2．5について空のserial_write_buffer（uint8 *data、int len） （潜在的に）バイナリのデータの全体のバッファをSCIFアウトプットに書く。 この機能はserial_フラッシュ()を自動的に実行する。 3．2．6について空のserial_write_str（雑用*str） データの零ターミネートされたストリングをSCIFに書く。 serial_write_バッファ()を使 う。従って、すべてのアウトプットはimmidiatelyに勢いよく水洗される。 ()読まれた3．2．7 int serial_ もしそれが待っているならば、SCIFインプットFIFOから1つのキャラクタを読む -1を違っ た形で戻す 。 3．2．8 int serial_printf（雑用*fmt 、…） libcからプロセスフォーマットargsにvsprintf()を使う そして、serial_write_str()を 使ってデータをSCIFに送る 。 dream.hでは、printf()はこの機能のためのエイリアスで ある。 3.3 基本的なビデオ（video.c） libdreamの基本的なビデオサブシステムは、フレーム・バッファセットアップとアクセス を容易にするようにデザインされる。 それは３Ｄ加速を処理せず、それはtheにおいて処 理される "TA'' モジュール 。 ビデオシステムの基本的な用法は、要求されたパラメ ータによってvid_initを呼ぶ必要があり、それから、theのうちの1つを使う ビデオメモ リにアクセスする"vram''ポインタ 。 以下の変数と機能は、基本的なビデオで入手可能である： 3．3．1 uint32 *vram_l 32ビット未契約整数配列としてのビデオメモリ（0xa5000000）へのポインタ。 RGB888モードの時にビデオメモリにアクセスするために、これを使用する。または大きい 領域をコピーする時（推奨されない）。 3．3．2 uint32 *vram_s 16ビット未契約整数配列としてvram_lとアクセスと同様である。 RGB555またはRGB565モードの時にビデオメモリにアクセスするために、これを使用する。 3．3．3 int vram_config ピクセルフォーマットであるvid_initへの店最初のパラメータ。 3．3．4 int vram_size 1ページのビデオフレーム・バッファの店全体のサイズ（ピクセルの）。 3．3．5 int vid_cable_type 店 下のビデオinit機能へのcable_typeパラメータ 。 3．3．6 int vid_check_ケーブル() チェックおよびリターン 取り付けられたビデオケーブルタイプ ； 帰りの値とマッチし ている3つの定数は、CT_VGA、CT_RGB、およびCT_COMPOSITEである。 3．3．7 int vid_init（int cable_type、int disp_mode、int pixel_mode） 要求されたケーブルタイプ、ディスプレイモード、およびピクセルモードによってする 完全なフレーム・バッファ初期設定 。 あなた.のために最初のパラメータ.dc_セットア ップ()がこれをすることとしてvid_check_ケーブル()から帰りの値を合格させるべきであ る disp_mode定数は、DM_320x240、DM_640x480、およびDM_800x608である。 pixel_mode定数は、PM_RGB555、PM_RGB565、およびPM_RGB888である。 3．3．8について空のvid_set_start（uint32開始） "開始address''を課する。 レジスター それは、フレーム・バッファにアウトプット写 真が来る所で制御する。 これはそれ"のために使われえて double buffering'' けれど も、それは最も一般的に３Ｄ加速の間に使われる。 3．3．9について空のvid_border_color（int r、int g、int b） 境界絵の具をセットする。 境界は標準の展望エリアの外でエリアである。 NTSCには、た いていこれについて上でおよび写真の下にある。 私は、何でそれがPALにあるかを確信し ない。 一般に、していない限り、何人かの奇妙なデバッグあなたが、黒くするために、こ れを設定したい（vid_initはあなたのためにこれをする）。 3．3．10について空のvid_clear（int r、int g、int b） 与えられた色によって現在のビデオモードに基づくフレーム・バッファの空所最初のペー ジ。 これは、３Ｄアクセスではなくフレーム・バッファアクセスを使う時に、最も有益で ある。 ()空の3．3．11について空のvid_ 0を使ってビデオメモリの完全をクリアする。 longwordsを使うのでそれがかなり迅速であ ることによってこれはされる。 もう一度、主に、３Ｄセットアップによって使われる。 3．3．12について空のvid_waitvbl() 垂直のブランクの期間を待つ。 ブランクの垂直線は、走査ビームがスクリーンの底に到着 するという時刻とそれがトップに到着し、再び引き始めるという時刻の間の期間である。 これが、"tearing''または他の人工物を起こさずにフレーム・バッファに引くのに最も良 い時間であるので、これは適切である。 開始アドレスを切り替えたい時には、それは一般 的でもある。 3.4 BIOSフォント（biosfont.c） BIOSフォントは、ドリームキャストのブートマネジャーにおいて会う人である。 これらはロムに蓄えられて、従って、どのようなプログラムにでも利用可能である。 公式 な製品においてそれらが至る所に使われるので、たぶん、それらをimmidiatelyに認める。 BIOS フォントは、ヨーロッパLatin-1キャラクタ（私達はどれをサポートするか）と漢字を含ん でいる（私達はどれをまだサポートしていないけれども、するか）。 Latin-1キャラクタ はサイズ12x24のビットマスクである。従って、個々のキャラクタは36バイトを使う。 私 は、漢字キャラクタが24x24であるのに感付いているけれども、私はこれをまだテストして いなかった。 彼らが16ビットピクセルサイズを予期する以外これらの機能はフレームバッ ファ不可知論者である。 以下の機能は入手可能である： 3．4．1 void* bfont_find_char（int ch） BIOSフォントにマッピングされた後の与えられたキャラクタのロムでのリターンアドレス 。 3．4．2について空のbfont_draw（uint16 *buffer、int bufwidth、int c） 『バッファ』の与えられた位置の引きLatin-1キャラクタ『c』および『バッファ』がピク セルの幅の'bufwidth'であると想定する。 例えば、20および640x480フレームバッファ、 あなたの20で『a』を引くことによりbfont_drawは使われる（vram_s+20*640+20、640、『a 』）。 3．4．3について空のbfont_draw_str（uint16 *buffer、int bufwidth、雑用*str） 正確に、bfont_drawとそれのようにストリングを取り、個々のキャラクタを次々引く。 3.5 PCフォント（font.c） PCフォントシステムハンドルは、ある 幅8ピクセルであることのおよび フォントをbitmapped する 高いピクセルのどのような数でも 。 モジュールはBIOSフォントモジュールを支持 して抗議されている。従って、私はここにそれを説明しない。 もしより多くの情報を望ん でいるならば、参照font.c自身を喜ばす。 3.6 サウンドのプロセッサユニット（spu.c） サウンドのプロセッサユニット（READMEにおいて言及されるような）は、ヤマハ（tm）AICA サウンドシステムである。 プロセッサを使うために、ARM7RISCコアにおいて動き、AICAの 自身のレジスターを使うseperateプログラムを書く必要がある。 これはこの文書によりカバーされない（または、私の知る限りではどこでも）。 しかし、いくつかのきちんとした例のために、暗号ほのめかしDCDevサイトで"s3mplay''を ちらりと見る（READMEを見る）。 以下が定義し、機能する サウンドのプロセッサを使うことを補助するために入手可能で ある： 3.6.1 SMP_BASE AICAにロードされたすべてのサンプルは、サウンドのRAMと関連するこの位置のため生じる はずである（どの SH-4の0xa0810000へのマップ ）。 これは主に、S3Mプレーヤーにお いて使われるけれども、それは、それがあなたにサウンドのプログラムのためのスペース の64kを与えるので一般に続いているのに良いガイドラインである（一般にどれが豊富であ るか）。 3．6．2について空のsnd_ram_write_待機() SH-4というよりもAICAのRAMがチップ自身に取り付けられて、従って、アクセスはASICを通 して取りかかる。 ASICのFIFOが追いつくことができるように、この機能を、書かれたサウ ンドのメモリーのすべての8回の長い間言葉と呼ばなければならない。 もししないならば 、データは正確に書かれないであろう。 3．6．3について空のsnd_load_arm（空の*src、intサイズ） ロード ARM7プログラム およびそれによる実行を取りかからせる。 プログラムはオフセ ット0でロードされる。従って、それはリセット／例外ベクトルから始まる必要がある。 3．6．4について空のsnd_stop_アーム() ARM7での停止実行およびすべてのAICAシンセサイザーチャンネルを使用不可にする。 これは、SPUに進んだものが何でも完全に止められることを保証する。 3．6．5について空のsnd_init() SPUを初期設定する： ARM7を使用不可にし、サウンドのメモリーをクリアする。 3．6．6について空のsnd_load（空の*src、int dest、int len） SPUのRAMに雑多なデータをロードする。 『src』はどこでそれからロードすることになっ ていて、'dest'は、基づくSPUと関連する（従って、通過できたこと例えばここのSMP_BASE ）。 『len』はバイトにあるけれども、長い間言葉に集められる。 3.7 CD-Rom アクセス（cdfs.c） Libdreamは、GD-Romドライブにおいて、このモジュールを使って、CDを使う機能とCDRディ スクを提供する。 それがセガのGDディスクにアクセスできるようにこのファイルが特に損われたこと（とい うよりもで、私達は決してそれをたった今書き込んだところではなかった）に注意する。 これは、どのような商業用のゲームのデータにでもアクセスできないのを意味している。 著作権侵害を補助するために砲火をあびることを避けるために、これをするので私達が機 能を使用不可にしたことのほんのわずかの合法な理由が本当にある。 もし， 私が、それを理解できると確信している で本当に知り どのように たいなら ば。 以下の機能は入手可能である： 3．7．1 uint32 iso_open（const雑用*path、int oflag） 絶対のパスを使って「path'『開いているフラグを持つ」oflag'』 CDのファイルを開く。 現在のシステム、 「path''は、seperators（しかし、トラブルなしで上部と小文字を自 由に混ぜることができる）パスのための前のスラッシュを使わなければならない」 「お よび」oflag''でO_RDONLYであるにちがいないことに注意する または（O_RDONLY|O_DIR） 。 ファイル記述子が戻されること、またはエラーの0。 3．7．2について空のiso_close（uint32 fd） 近く、与えられたファイル記述子によって参照を付けられるファイル。 3．7．3 int iso_read（uint32 fd、空の*buf、int計算） 『バッファ"buf'への』を、「過ぎることに参照を付けられるファイルからのnbyte''バイ ト」fd'に読んで聞かせる。 望んでいる部分を取り出す前にいつもこの機能が周辺の2048 バイトセクタを読むことに注意する。従って、それすべてがあなたでない限り、決して2048 バイト未満を読むべきではない 望んでいる 。 2048より多くを読むことは働く。 読ま れたバイトの数は戻される。 3．7．4長いiso_lseek（長い間がオフセットしたuint32 fd int 所 ） ファイルにおいて「それの近くのfd''」offset''を求める バイト それ"と関連する whence'' 。 "whence''は標準のSTDIO定数のうちの1つである： SEEK_SET、SEEK_CUR、SEEK_END。 "offset''はポジティブか、または用法に依存するのでネガティブであるかもしれない。 新しいファイル位置は戻される。 3．7．5長いiso_tell（uint32 fd） リターン 中の現在のファイルポインタ "fd'' 。 3．7．6 dirent_t *iso_readdir（uint32 dirfd） 開かれたディレクトリから次の入力（もしあれば）を読む。 リターン 成功（dirent_tの 詳細についてfs_iso9660.hを見る）またはNULLにおけるdirent_tへのポインタ 何も残さ れない 。 3．7．7 int cdrom_init() int iso_init() CD/CDRメディアを読むためのGD-Romドライブを初期設定し、ファイルシステムドライバー を初期設定する。 3.8 タイマーカウンター（timer.c） このモジュールは、SH-4's内部のタイマーperhipheralsをサポートする。 サポートはTMU0 からTMU2までに提供される。 WDT（番犬）は定義されるけれども、まだサポートされてい ない。 TMU0からTMU2まで独立してすべて使われうることおよび種々のレートでの計算。 以下が定義し、機能する 入手可能である： 3.8.1 TMU0、TMU1、TMU2、WDT これらは、どのタイマーで、オンにおいて動作するように望んでいて識別するために用い られた定数である。 3．8．2 int timer_prime（int which uint32スピード ） 素数タイマーとそれを始めない。 「which''はタイマー定数のうちの1つである」 「およ び」speed''は、その外においてカウンターがする 底 秒あたり倍レートである。 従っ て、もしスピードをそれ"に設定し 1'' ならば、タイマーは1秒の後に底に当たり、再び カウントし始める。 成功のためのリターン0。 3．8．3 int timer_start（int which ） 開始要求されたタイマーカウント（起爆剤の後で それ ）。 3．8．4 int timer_stop（int which ） 停止要求されたタイマー。 3．8．5 uint32 timer_count（int which ） リターン 現在のタイマー計算 。 これを本当に利用できる唯一の方法は、外面的に、起 爆剤の後でけれども開始の前にタイマー計算を得ることであり、リアルタイムを縮尺する 結果として生じている 。 3．8．6 int timer_clear（int which ） 空所 タイマーアンダーフロービットおよびリターン その価値がであったもの 。 タイ マーがカウントダウンする時には、アンダーフローは設定される。 従って、例えば、タイ マーを1 1HZサイクルに取りかからせることができて、それが正常を戻すまで、この機能に 投票する。 そのポイントで、ちょっと待ち、タイマーはすでに再びカウントダウンしている。 3．8．7について空のtimer_sleep（int ms） 数ミリ秒の与えられた数で眠るために、TMU0を使用する。 3．8．8 int timer_init() セットアップタイマー（可能にし、すべて停止する）。 3.9 カエデアクセス（maple.c） Libdream 0.7は、ヨルダンDeLongの書き直されたカエデアクセスコードを含む。 これはたいそうモジュール式のであり、それは、複数のフレームとDMA完成割込みをqueueing している未来の拡張のためのセットアップである。 今のところ、それは、基本的に、マー カスの古いカエデルーチンとよりクリーンなコードと同じをする。 カエデバスを使っている一般には、周辺装置（DEVINFOを使うことは問う）を見つけて、こ のアドレスを蓄えることから成っている； 周辺装置を使いたい時には、条件質問メッセー ジをそれに送り、周辺装置の状態を説明してフレームを戻す。 maple.cの輸出された機能 のほとんどは、単なる人=)に有益ではないけれども、それはそこで以来よい物である 私 達がアクセスできた主要な周辺装置のうちのそれぞれのための具体的なサポートモジュー ルである 。 以下の機能は入手可能である： 3．9．1について空のmaple_init（int静寂） カエデバスを初期設定する； もし"quiet''が不 0であるならば、バス調査により少しのア ウトプットもは生産されないであろう。 3．9．2について空のmaple_シャットダウン() すべてのカエデバス操作を閉鎖する。 3．9．3 uint8 maple_create_addr（uint8ポート、uint8ユニット） 与えられたポートとユニットのためのカエデアドレスを作成する。 3．9．4 int maple_docmd_block（…） トピック簡潔さのために省略されたパラメータ： int8 cmd、uint8 addr、uint8 datalen 、空の*data、maple_frame_t retframe。 これは、カエデシステムのメイン"仕事horse'' である。 "cmd''はmaple.hのカエデコマンド定数のうちの1つであるはずである； "addr'' はmaple_create_addrによって作成されるべきである（または、maple_*_addrのうちの1つ は下で機能する）； 「datalen''は特別なデータの長さである（何がフレームヘッダーに あるか）」data''が、フレームヘッダーを追いかける特別なデータ（もしあれば）にポイ ンタである； そして、"retframe''は、帰りのデータによって埋められるように中に通過するべきmaple_frame_t である。 0は、成功、およびエラーにおいて戻された-1に戻される。 docmd_blockを直接 使うことのいくつかの例のために、どうぞ、カエデ周辺装置モジュールのうちの1つをチェ ックしてください。 3．9．5 int maple_rescan_bus（int静寂） リスキャンカエデバス。 もしユーザーがどのようなコントローラまたはメモリーカードで もスワップアウトするならば、これはneccessaryであるであろう。 それは、また店 that 後の方の用法のための情報 で決定する 何がである 所 および 。 もし"quiet''が 不 0であるならば、それはアウトプットを全然生産しない。 3．9．6 uint8 maple_device_addr（intコード） カエデ機能コードを通過する。それは、それとマッチしている最初のもののアドレスを戻 す。 3．9．7 uint8 maple_*_addr() これらは現在コントローラ、マウス、kb、lcd、およびvmuを含む。 個々のものは、周辺装 置の中で最初のマッチしているタイプを見つけるために、カエデバスを捜し、アドレスを 戻す。 3.10 カエデ周辺装置サポートモジュール サポートモジュールは、標準のコントローラ、キーボード、VMUs、およびマウスのために 含まれる。 ほとんどの周辺装置はこれらの型に適合している。 結局、私達は、たぶん、purupuru パック（力フィードバック）のようなより多くの物のサポートを追加するけれども、私達 はそれをまだ持っていない。従って、私達はすることができない。 =) それがたった今出 たところであったので、このリストの間の名士はマウスである。 ワーオ、セガがチャンス を得る前にそれを使うソフトウェアを書くことによる友人！ =) たいていこれらが同じで（名前と構造価値を除いて）ので、私はそれらを詳細に入念に調 べない。 個々のモジュールは、一般に、周辺装置の状態をチェックし、機器具体的な構造 を埋める投票機能を含んでいる。 具体的な構造情報のためのヘッダーファイルを見る。 私は、convienence けれども のためにここで投票機能の外でリストする。 3．10．1 int cont_get_cond（uint8 addr、cont_cond_t *cond） コントローラステータスをチェックする。 ボタンが押されることおよび様々なアナログコ ントロールの状態のリターン。 3．10．2 int kbd_get_cond（uint8 addr、kbd_cond_t *cond） キーボードステータスをチェックする。 すぐに押されている最高6つのキーへのリターン 。 もしそれを重大に使いたいならば、keyboard.hにおいて探すべきキーボードに他のサポー ト機能がある。 これらはあなたのためのqueueingと緩衝をする。 もしこの機能を望んで いるならば、キープレスを得るために、kbd_poll（uint8 addr）と、そしてkbd_get_キー() を使用するであろう。 3．10．3 int vmu_draw_lcd（uint8 addr、空の*bitmap） 引き LCDスクリーンへの与えられたビットマップ 。 一般に、これらは、VMUs（どれが 、それがvmu.cの一部である理由であるか）にあるけれども、それは必要ではない。 ビッ トマップは48x32ビット配列であるはずである。 写真はVMU自身において上に右側を際立た せている。従って、それがコントローラに挿入した時には、個々の方向にそれをはじく必 要がある。 3．10．4 int vmu_block_read（uint8 addr、uint16 blocknum、uint8 *buffer） VMUのフラッシュラムの要求されたブロックを読み、それを入れる "buffer'' 。 3．10．5 int vmu_block_write（uint8 addr、uint16 blocknum、uint8 *buffer） 取る。 "buffer'' 何がインで、書くか VMUのフラッシュラムの要求されたブロックへ のそれ 。 3．10．6 int mouse_get_cond（uint8 addr、mouse_cond_t *cond） マウス周辺装置の条件を指定させる。 リターンボタン状態とデルタx、y、およびz（ロー ラー）。 3.11 タイルアクセレータ（ta.c） The Tile Accelerator (3D acceleration) really deserves its own book, but for completeness (and my hands are getting tired =) I'm just going to go over the basics of setting it up and the functions you use to do so. より具体的な情報のために、例において、TAを説明している様々な文書のためのウェブで 見回り、見る。 うまくいけば、このセクションはむしろ、未来のバージョンにおいて外で 肉付けできる。 TAは、正確に、それが言うことである： PVR３Ｄチップのスクリーンは32x32ピクセルタイ ルに解体される。 従って、640x480には、640x480ピクセルフィールドではなく、20x15タ イルフィールドを本当に持っている。 PVRの３Ｄ魔法は、これらのタイルのうちのそれぞ れが、何がスクリーンに表示されることになっているかを記述し、内部のz-緩衝をしてい る"ディスプレイlist''かかることによって起こる。 これは、個々のポリゴンがほんの1回引かれるのを意味している。たとえ従って、標準のz- バッファプレゼントがなくても、終わり結果はそこのように見える それである 。 不透 明なポリゴン、不透明なボリューム変更者（霧など）、半透明なポリゴン、半透明な変更 者、およびつきぬけ現象のポリゴン（どの 缶"cut'' 外の他のポリゴンの断片 私が考 えるか）が、TAにその注文に送られなければならない。 その上、個々のリストがその注文 によりゆっくり表現される the プロセスは到着し、個々のタイルとより多くのリストの ために送る。 不透明なポリゴンは、明らかに パンチ-throughs，半透明なポリゴンが続 くことと、そしてボリューム変更者 最も速い。 タイルシステムのため、ユーザーを切り取っているneccessaryが全然ない： TAは、個々の タイルでポリゴンと巻を表現の前を横切っていて後ろに作動する。 The end result of all of this is that all you have to do as a user is cull out the completely useless polygons (if you feel like it), arrange things in polygon ``strips'' as much as possible, and then throw the various lists to the TA. そして、ゆったり座り、それがその仕事をすることを待つ。 PVRチップは魔法ではない： それは強力で、驚異的な程度に、引いているプロセスを促進 できるけれども、それはまだスクリーン座標について引いている。 従って、それは、本当 に、テクスチャーのパースペクティブ訂正サポートを持つ装飾的な2Dアクセレータ、およ びz-緩衝である。 PVRの座標は、0および0（すべての座標はポイント数をフロートする）で始まり、640480に 正常なモードに行く。 これの外のどのような座標でも働くけれども、切り取られる。 Z座 標は0で始まり、スクリーンからビューアに動く。 私が話すことができる限り、正常なモ ード、それにおいて1/Z（W）ではなく、Zを望んでいる。 私はもちろん悪いかもしれない 。 私はいいえである ３Ｄハードウェアエキスパート。 すべて that いわれていて、基本的な操作が行く これのような何か ： 1. セットアップTA（ta_init）； バックグラウンド飛行機構造を初期設定する 2. 使いたいかもしれないどのようなテクスチャーでもロードする 3. 個々のフレームのために： * プロセスを初期設定する呼び出しta_begin_render。 * それぞれ0以上のvertecesが続いている不透明なポリゴンのための1つ以上のポリゴンヘ ッダーを組み立てて、送る； 個々の頂点ストリップは、anによってlist'' マーカー の" 終わりを終えなければならない。 * 不透明なリストを仕上げる呼び出しta_commit_eol。 * 半透明なポリゴンのための1つ以上のポリゴンヘッダーを組み立てて、送る（上記の同じ プロセス）。 * 半透明なリストを仕上げる呼び出しta_commit_eol。 * プロセスを終えて、垂直の空白がページをはじくことを待つ呼び出しta_finish_frame。 ここには、これらの物をするために必要な構造と機能がある： 3．11．1 struct pv_str ta_page_values［2］ ページひれ足とrendererのためのすべての内部の表現データを保持する。 主にもし取るような何かのためにスクリーンショットをしたいならば、これは有益である （現在のフレーム・バッファを見つけることができる）。 3．11．2 bkg_poly ta_bkg バックグラウンド飛行機ポリゴン。 バックグラウンド飛行機は一般に自動的である 640x480 、3ポイント不透明体ポリゴン 。 私は、これを変更できるかどうかを確信しさえしない 。 値がこれにロードするように、３Ｄ例プログラムのうちの1つをちらりと見る。 もしあ なたをシフトすることを着色したいならば、これを直ちに変更できるであろう。 3．11．3 poly_hdr_t ポリゴンヘッダー； これは、いつも4回のフラグ長い間言葉および4回のダミーの言葉であ る。 4回のダミーの言葉は実際、明暗法とボリューム変更者の種々のタイプによって使わ れるけれども、これらはlibdreamにおいてまだサポートされていない。 （もし何をしてい るかを知っているならば）直接この構造に充填するか、またはta_build_poly_hdrを使うべ きである。 3．11．4 vertex_oc_t フローティングポイント座標とARGB価値によって、単一の不透明な／着色された頂点を表 している。 実際、それは半透明なポリゴンのための罰金も作動させるけれども、命名会議 は付いた。 3．11．5 vertex_ot_t フローティングポイント座標とARGB価値によって、単一の不透明な／織られた頂点を表し ている。 実際、それは半透明なポリゴンのための罰金も作動させる。 3．11．6 int ta_curpage 現在の作動ページ（上のta_page_valuesの外で）。 3．11．7について空のta_init() TAを初期設定し、ページはじかれた３Ｄの準備をする。 3．11．8について空のta_send_queue（空の*sql、intサイズ） データでいっぱいの1つ（または2）の店列（s）をTAに送る。 3．11．9について空のta_begin_下塗り() フレームを引き始める前に電話する。 3．11．10について空のta_commit_poly_hdr（poly_hdr_t *polyhdr） 1つのポリゴンヘッダーをTAに送る。 引いているモードを変更したい時には、これはされ る必要がある； 例えば、不透明な色、不透明は、織られるので、半透明なので織った ， 半透明な色 。 3．11．11について空のta_commit_vertex（空の*vertex、intサイズ） 1つの頂点をTAに送る； これはvertex_oc_tまたはvertex_ot_tであるかもしれない。 頂点のsizeof()の結果に沿って通過する。 3．11．12について空のta_commit_eol() list''の"終わりをtheに送る TAへのマーカー 。 すべての不透明なポリゴンが送られた 後にこれが使われるべきであること、およびすべての半透明なポリゴンが送られたことの 再び。 3．11．13について空のta_finish_フレーム() すべてのデータを送り終わった後に電話する。 これは交替のスクリーンバッファのプロセ スを完成し、それから、垂直の空白が新しいページに切り換えることを待つ。 3．11．14について空のta_build_poly_hdr（poly_hdr_t *target 、…） 簡潔さのために省略されたパラメータ： 半透明なint、int textureformat、int tw、int th 、uint32 textureaddr、int濾過。 あなたのためにこれがポリゴンヘッダーを建てるので 、ビットフィールドによって早く上下に動く必要がない。 TA_OPAQUEまたはTA_TRANSLUCENT のうちの1つが半透明であるはずであるべきであろう。 Textureformatはテクスチャーフォ ーマット定数またはTA_NO_TEXTUREのうちの1つである必要がある。 それがいじったかどう かにかかわらずこれは含む（いじられたテクスチャーについての情報のために、PVR E3プ レゼンテーションをオンラインで捜す）。 もしtextureformatが、TA_NO_TEXTURE.twおよ びthがテクスチャー幅と高さであり、2で8から1024までの能力であるにちがいないことで はないならば、パラメータの残りは適切であるだけである。 Textureaddrは、テクスチャ ーをロードしたPVR RAM内のアドレスであり、それは8バイト境界で位置合わせされなけれ ばならない。 濾過はTA_NO_FILTERまたはTA_BILINEAR_FILTERであるはずである。 テクス チャーを、いじられたフォーマットのPVR RAMに蓄えない限りバイリニアの濾過がかなり高 価な操作であり、その場合、である 自由であることに注意する。 3．11．15について空のta_load_texture（uint32 dest、空の*src、intサイズ） ロード 与えられたオフセットのPVRラムへのテクスチャー 。 "size''は4の倍数である にちがいなく、もしそれがすでにそうではないならば集められるであろう。 PVRが、すべ てのテクスチャーデータを0xa5000000ではなく、0xa4000000に送るのをあなたに要求する ので、seperate機能が必要である。 これはまた、ta_initの後にされなければならない。 3．11．16について空の*ta_texture_map（uint32 loc） 与えられたPVRがテクスチャースペースにオフセットしたマップ。 もしテクスチャーラム に直接書きたいならば、これを使うであろう。 もう一度、それはta_initの後にされなけ ればならない。 この文書について この文書は株によって書かれた LyX 1．0．0配布 装飾的なアドオンを全然使わない （ 従って、もしそれを試したいならば、それはあなたのためのokをロードするべきである） 。 PostScriptは、Debian 2.2によって来るTeXツールを使って生成された。 HTMLアウトプ ットは、LyXからラテックスファイルを輸出し、結果においてlatex2htmlを使うことによっ て生産された。