ゲームボーイエミュレータの作成、パート2

こんにちは



このシリーズの記事の前のパートでは、DMGのプロセッサーとメモリーについて調べました。 次の論理的なステップは、DMGが画像を表示する方法をエミュレートすることです。



ゲームボーイエミュレータの作成、パート1

ゲームボーイエミュレータの作成、パート2

ゲームボーイエミュレータの作成、パート3

目次

ディスプレイ

• LCDコントローラー。 理論
• LCDコントローラー。 実装
• グラフィックス 理論
  
  
  • 背景
  • 窓
  • スプライト
• グラフィックス 実装

タイマー

運営管理

すべてをまとめる

テスト中

おわりに

ディスプレイ

この段階で、DMGが画面に画像を表示する方法をエミュレートする必要があります。 すべてがCookieboy :: GPUクラスにあります（cookieboyソースコードへのリンク ）。 タスクは2つの大きな部分に分けられます-DMGが絵を描く方法の詳細のエミュレーション。 画面を制御するロジックのエミュレーション。

LCDコントローラー。 理論

いつから何を描くかは彼女が決めるので、ロジックから始めましょう。 いつものように、実装の前に、コンポーネントの動作を理解する必要があります。



DMGは、画面に1行ずつ画像を表示し、CRT画面に典型的な状態をエミュレートします。 各状態は、厳密に定義された数のメジャーが続きます。 これは、メモリへのアクセスを提供するために必要です。 グラフィックを描画するには、ビデオメモリとOAMへのアクセスが2つの場所で同時に必要です。画面にすべてを表示するLCDコントローラー。 必要なフレームを表示するためにメモリを変更するゲーム（CPU）。 この問題を解決するために、グラフィックス出力のタスク全体を間隔に分割し（それぞれが特定の状態に対応）、画面またはゲームのロジックがメモリにアクセスできる時間を決定しました。 合計で4つの状態があります（数値はランダムではありませんが、DMGに対して厳密に定義されています）。

• 0. Hブランク。 CRT画面の場合、この時点で、走査ビームは次の行の先頭に移動します。 もちろん、DMGには光線がありません。 この状態は2つのことを意味します。 最初に、1行が出力されました。 次に、ビデオメモリとOAMはLCDコントローラで使用されず、CPUが使用可能です。
• 1. Vブランク。 CRTの世界の別の状態。これは、光線が最後の行の終わりに到達し、最初の行の先頭に行く瞬間を意味します。 私たちにとって、それは2つのことを意味します。 最初に、144の可視行すべてが表示されました。 次に、ビデオメモリとOAMはLCDコントローラで使用されず、CPUが使用可能です。
• 2. OAM。 この状態は、LCDコントローラーがOAMメモリーを使用することを意味します。 CPUは使用できませんが、ビデオメモリは使用できます。
• 3. OAMRAM。 このステータスは、LCDコントローラがOAMとビデオメモリを使用することを意味します。 CPUは使用できません。

LCDコントローラーは、各ラインを描画するときに、2、3、0の順序で状態を通過します。最後のラインを描画した後、状態1になります。その後、最初のラインからすべてが新たに始まります。



1行は正確に456サイクル続きます。 この時間は、状態2、3、0の期間で構成され、常に456クロックサイクルに等しくなりますが、状態自体の期間は異なる場合があります。 画面には144行あるため、出力には65664クロックサイクルかかります。 状態1の場合、正確に4560クロックサイクル続きます。この数から、この時間は10行であることがわかります。 これは事実です-状態1では、あたかもさらに10行描画するようです。 行カウンタ（レジスタLY）は143で停止しませんが、153に達します。その結果、全画面の更新には70,224サイクルまたは456サイクルの154行がかかります。



有効になっている場合、状態遷移には割り込み要求が伴います。 3番目を除く4つの状態のそれぞれへの移行には、LCDC割り込み要求が伴います。 さらに、LYとLYCが等しい場合、この割り込みが要求されます。 この状態のLCDC割り込みがSTATレジスタで有効になっている場合にのみ、要求が行われます。 その構造は次のとおりです。

ビット	予定
6	LYおよびLYCレジスタが等しい場合、LCDC割り込みを許可
5	状態2への移行時にLCDC割り込みを許可
4	状態1への移行時にLCDC割り込みを許可
3	状態0に入るときにLCDC割り込みを許可する
2	LYとLYCが等しい場合、ビットが設定されます。 そうでなければリセット
0-1	現在の状態

重要な詳細-LCDC割り込みは1行に1回しか要求できません。



これの多くはCPUマニュアルから収集できますが、ここに1つのことがあります-これは、それをエミュレートするLCDコントローラーの操作について知る必要があるすべてからは程遠いです。 私はすべての詳細には触れませんでした（実際、それらは見つかりませんでした）が、テストしたゲームでグラフィックを正しく表示し、同時にLCDコントローラーテストに合格できるという事実に落ち着きました。



コントローラーを少なくともほぼエミュレートするには、別の一連の状態を導入する必要があります-内部、エミュレーターでのみ使用可能です。 それらの8つがあります。

enum InternalLCDModes { LCDMODE_LY00_HBLANK, LCDMODE_LYXX_HBLANK, LCDMODE_LYXX_HBLANK_INC, LCDMODE_LY00_VBLANK, LCDMODE_LY9X_VBLANK, LCDMODE_LY9X_VBLANK_INC, LCDMODE_LYXX_OAM, LCDMODE_LYXX_OAMRAM };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

名前から、それらが実際の状態に対応していることは明らかです。 次の順序で渡されます。

ひも	州
0	LYXX_OAM-> LYXX_OAMRAM-> LYXX_HBLANK-> LYXX_HBLANK_INC
1	LYXX_OAM-> LYXX_OAMRAM-> LYXX_HBLANK-> LYXX_HBLANK_INC
...	...
143	LYXX_OAM-> LYXX_OAMRAM-> LYXX_HBLANK-> LYXX_HBLANK_INC
144	LY9X_VBLANK-> LY9X_VBLANK_INC
...	...
152	LY9X_VBLANK-> LY9X_VBLANK_INC
153	LY00_VBLANK-> LY00_HBLANK

中間状態は、さまざまなイベントのより正確な同期に必要です。 各状態をより詳細に検討してください。



LCDMODE_LYXX_OAM 。 この状態に移行すると、STATレジスタの状態を2（OAMの読み取り）に変更します。 LCDC割り込みが有効になっているかどうかを確認します。 成功した場合、それを要求し、LCDC割り込みを要求できなくなったことをマークします。



この状態では、DMGの1つの機能を考慮します。 SCXレジスタがビット2に設定されている場合（たとえば、レジ​​スタが4である場合）、次の状態が4メジャー分だけ持続時間を変更する必要があることに注意する必要があります。 この状態は正確に80クロックサイクル続きます。



LCDMODE_LYXX_OAMRAM STAT状態を3に変更します。LCDCは中断されません。 これまでのところ、スプライトのトピックについては触れていませんが、ここで関数呼び出しが配置されます。これは、後でこの行に表示されるスプライトのキューです。



これはDMGのもう1つの機能です。 スプライトの出力は、状態の持続時間を変更します。 それらの数が多いほど、状態3が長く続き、状態0が短くなります（456クロックサイクル以内に維持する必要があるため、すべてが比例します）。 DMGは1行で最大10個のスプライトを出力できるため、状態の継続時間の変化を示す値を持つ11個の要素の配列が十分にあります。 次の値が必要です。

スプライトの数	0	1	2	3	4	5	6	7	8	9	10
バー	0	8	20	32	44	52	64	76	88	96	108

この状態は、172サイクル+ SCXレジスタによるサイクル数+スプライトによるサイクル数で続きます。 たとえば、前の状態のSCXレジスタが4で、6つのスプライトが表示されている場合、状態の持続時間は172 + 4 + 64サイクルになります。



LCDMODE_LYXX_HBLANK ここで、LYレジスタから学習できる現在の線を描画します。 STATレジスタで状態0をマークし、LCDC割り込みを要求します（まだ要求されていない場合）。



小節の長さは次のように計算されます。200小節-SCXによる小節-スプライトによる小節。 したがって、ここでは、LCDMODE_LYXX_OAMRAM状態で発生した期間のシフトを補正します。



LCDMODE_LYXX_HBLANK_INC ここで、レジスタLYを1つ増やします-これは行カウンタです。 フラグをリセットします。これは、LCDC割り込みが既に要求されていることを示しています（次の行に進みます）。 ここで、レジスタLYとLYCの等価性をチェックする必要があります。 擬似コードの例を次に示します。

  LY == LYC   2   STAT    2   STAT  LCDC ,       2   STAT
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

LYCレジスタは、LYが特定の値に達すると追跡するためにゲームで使用されます。 彼には他の予定はありません。



この状態は4メジャー続きます。 遷移が行われる状態は、LYの値によって異なります。 上記の表にすべてが示されています。



LY9X_VBLANK この状態になり、LYが144の場合、Vブランク状態になったことを何らかの方法でキャンセルする必要があります。 状態をSTAT 1に設定します。割り込みVブランクを要求します。 有効になっている場合、ここでLCDC割り込みを再度要求する必要があります。 したがって、2つの割り込みをここで要求できます。 LYが144に等しくない場合、何もする必要はありません。 すでにVブランクになっています。



この状態は、正確に452メジャー続きます。



LY9X_VBLANK_INC ここで、前に行ったように、LYをインクリメントし、LYとLYCの等価性をチェックする必要があります。 ここでは、LYが153の場合、別の状態に切り替え、LY9X_VBLANKでやり直さないことを考慮に入れる必要があります-表を参照してください。



この状態は4メジャー続きます。



LY00_VBLANK ここで、LYをリセットする必要があります。



この状態は452サイクル続きます。



LCDMODE_LY00_HBLANK これはフレームの最後であり、かなり奇妙な状態です。 4メジャーのみ持続し、STATレジスタを0に設定します。その後、すべてが新たに始まります。



すべて、状態サイクルが終了しました。 さて、小さいが非常に重要な詳細。 LCDCレジスタの説明を読んだ場合、ビット7がディスプレイのオン/オフの切り替えを担当していることに気づいたかもしれません。 これを州に何らかの形で反映させる必要があります。



ゲームがディスプレイをオフにした場合、次にLYレジスタをリセットし、STATレジスタで状態を0に設定する必要があります。ゼロ、LYはゼロ、現在の状態は2です。つまり、 状態のサイクル全体を最初から開始します。 多くのゲームは、これらの操作なしでは機能しません。 そのようなゲームの例は、Bomb Jackです。 彼女はスタートメニューに行くことさえ拒否します。



偶然ゲームの例を挙げません。 テストROMは優れていますが、それらに合格してもゲームが正しく動作することを保証するものではなく、すべてがチェックされるわけではありません。 可能な場合は、エミュレータで確認することが推奨されているゲームの名前を指定します。 ボムジャックをチェックする必要があります-画面をオフにするようなトリックは多くのゲームをします。

LCDコントローラー。 実装

最後に、検討した理論の実装を開始できます。 先ほど言ったように、エミュレーターでは、プロセッサーと他のすべてのコンポーネントを同期する必要があります-LCDコントローラーも例外ではありません。 これを行うには、Cookieboy :: GPUクラスで関数を作成します。これは、入力として過去のティックの数を取ります。 ここでは、状態の変化に関連するすべてを実行します。



すべてのコンポーネントで、同期はほぼ同じに見えます。 メジャーカウンターを開始し、これに過去のメジャーを追加します。 値が必要な値に達するとすぐに、この値からこの数値を減算し（必要以上のメジャーが通過した可能性があるため、リセットしません）、必要な処理を行います。



cookieboy :: GPU同期関数は次のようになります。

 void Cookieboy::GPU::Step(DWORD clockDelta, Interrupts &INT) { ClockCounter += clockDelta; while (ClockCounter >= ClocksToNextState) { ClockCounter -= ClocksToNextState; if (!LCD_ON()) { LY = 0; //  ClocksToNextState = 70224; continue; } switch (LCDMode) { case LCDMODE_LY00_VBLANK: LY = 0; LCDMode = LCDMODE_LY00_HBLANK; ClocksToNextState = 452; break; } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

当然、これはほんの一部ですが、それで十分です。 したがって、ClockCounterはカウンターとして機能します。 次に、カウンタが目的の値に到達したかどうかを確認するwhileコンストラクトがあります。 ClocksToNextState変数は、新しい状態が発生する前に通過する必要があるメジャーの数を格納するために使用されます。 カウンタからそれらを減算して、次の状態までカウントダウンし続けるようにします。



なぜここにいるの？ これは重要です。 一部の条件は4メジャーしか続かないため、この条件がすぐに発生する可能性があります。 つまり ClocksToNextStateを4に設定し、カウンターに4つのメジャーがあります。 同期関数への余分な呼び出しを待たないために、ループの次の反復で新しいイベントをすぐに処理します。 このアプローチは、状態（イベント）の間隔が小さすぎて、1つのプロセッサ命令の持続時間よりも短い場合があるというルールとして採用する必要があります。



次に、マクロLCD_ON（）で条件を確認します。 ここでは、ディスプレイがオフになっているかどうかを確認します。 そうである場合、状態のサイクル全体を実行しません。 画面をクリアするだけで、70224クロックサイクルが1回画面全体に更新されるまで待機します。



ディスプレイがオンの場合、スイッチの構築を利用して、現在の状態に必要なアクションを実行します。 私の実装の詳細は、次の状態ほど最新ではなくLCDModeに保存するようなものです。 必要なアクションを完了した後、LCDModeで次の状態を設定し、その前のクロックサイクル数を示します。 はい、LCDModeは単なる補助変数であり、ゲームには存在しません。 実際の状態は、STATレジスタに保存されます。

グラフィックス 理論

DMGはピクセルではなく、タイルで動作します。 当然、グラフィックスはピクセルごとに表示されますが、プログラマーの単位はタイルで、サイズは8x8ピクセルです。 したがって、メモリにはピクセルの色は保存されず、タイル番号が保存されます。 これらの数値は、タイルに関する情報が配置されている別のメモリ領域を表します-タイルがどの色ピクセルで構成されているか。 このアプローチの明確な目標は、メモリを節約することです。 インデックス付き色の実装のように見えます。



グラフィックス出力は、次の順序で3段階で実行されます。

1. 背景
2. いわゆる「ウィンドウ」（ウィンドウ）
3. スプライト

背景

DMGの背景のサイズは32x32タイルまたは256x256ピクセルで、DMG画面よりも明らかに大きいです。 SCXおよびSCYレジスタを使用して、次の図に示すように、表示するパーツを指定できます。



ご覧のとおり、背景の境界を越えた場合、反対側にいることがわかります。 よく言われるように、背景はあいまいです。



タイルとそのコンテンツに関するすべての情報は、ビデオメモリにあります。 その構造は次のとおりです。

セクション	予定
0x8000-0x87FF	タイルセット1：タイル[0、127]
0x8800-0x8FFF	タイルセット1：タイル[128、255] タイルのセット＃0：タイル[-128、-1]
0x9000-0x97FF	タイルのセット＃0：タイル[0、127]
0x9800-0x9BFF	タイルマップ№0
0x9C00-0x9FFF	タイルの地図№1

タイル自体が最初に保存されます。 DMGは、最大384タイルを256タイルの2セットに分割して保存できるため、それらの半分はセットで共通です。 1つのセットは0〜255の番号を使用してタイルを示し、もう1つのセットは-128〜127の番号を使用します。背景自体は、選択したタイルマップに従って描画されます。 それらの2つもあります。 サイズは1024バイト-タイル番号ごとに1バイトです。



タイルのセットとタイルマップの選択は、LCDCレジスタを使用して行われます。 オン/オフで背景を表示するフラグもあります。 ここで、ところで、その構造：

ビット	予定
7	LCDコントローラ管理： 0：オフ（画面は空白です） 1：オン
6	「ウィンドウ」のタイルマップの選択： 0：タイルNo. 0のマップ（0x9800-0x9BFF） 1：タイルNo. 1のマップ（0x9C00-0x9FFF）
5	ウィンドウ表示フラグ： 0：オフ 1：オン
4	背景と「ウィンドウ」用のタイルのセットを選択します。 0：タイルNo. 0（0x8800-0x97FF）のセット 1：タイルNo. 1のセット（0x8000-0x8FFF）
3	背景のタイルマップを選択する： 0：タイルNo. 0のマップ（0x9800-0x9BFF） 1：タイルNo. 1のマップ（0x9C00-0x9FFF）
2	スプライトサイズ： 0：8x8 1：8:16
1	フラグ表示スプライト： 0：オフ 1：オン
0	バックグラウンド表示フラグ： 0：オフ 1：オン

タイル自体はメモリで16バイトを占有します。 2バイトごとに1行が処理されるため、8x8のタイルが提供されます。 以下に示すように、メモリ内のタイルの構成はかなり奇妙です。



ピクセルの色は2ビットで構成され、最下位ビットは最初のバイトから取得され、最上位ビットは2番目のバイトから取得されます。 結果は、0〜3の4つの値を持つことができるカラーインデックスになります。これらのインデックスは、BGPレジスタのパレットから色を選択するために使用されます。 その構造は次のとおりです。

ビット	カラーインデックス
7-6	3
5-4	2
3-2	1
1-0	0

つまり、ピクセルカラーが2の場合、BGPレジスタでビット5〜4の値を検索します。これにより、0〜3の4つの値を持つ色が得られます。これにより、変換用の別のパレットが必要になりますDMGパレットの色を、後で出力するために実際のRGB色に変換します。 これは、スケジュール全体に適用されます。



白黒のパレットを使用して、次の色を使用できます。

パレットの色	RGB値
0	0xFF、0xFF、0xFF
1	0xAA、0xAA、0xAA
2	0x55、0x55、0x55
3	0x00、0x00、0x00

または、実際のDMGの画面上の色に近い色を使用します。

パレットの色	RGB値
0	0xE1,0xF7,0xD1
1	0x87,0xC3,0x72
2	0x33,0x70,0x53
3	0x09,0x20,0x21

画面のクリアには、0（最も明るい）の色が使用されます。 したがって、画面をきれいにする必要がある場合、または背景をオフにする場合は、すべてをインデックス0の色で塗りつぶしてください。

窓

背景を表示した後、「ウィンドウ」を表示する必要があります。 背景とほぼ同じ方法で表示されます-LCDCから、使用するカードとタイルのセットを学習します。 オン/オフ出力のフラグがあります。 レジスタWYおよびWXで指定された座標に従って表示されます。 ただし、画面の左上隅に「ウィンドウ」を表示するには、座標WX = 7およびWY = 0を指定する必要があります。つまり、 「ウィンドウ」の左上隅のX座標とY座標は、それぞれWX-7とWYです。



次の図は、WX = 87およびWY = 70の「ウィンドウ」出力の例を示しています。





出力の前に、LCDCの「ウィンドウ」出力フラグだけでなく、座標も確認する必要があります。

• WXが166より大きい場合、「ウィンドウ」は画面の外側に隠されます。
• WYが143より大きい場合、「ウィンドウ」も非表示になります。

重要な詳細。 WXおよびWYは、出力プロセス中に変更できます。 WXへの変更は次の行が表示されるとすぐに有効になりますが、WYへの変更は次の画面更新でのみ有効になります。



前述したように、多くの点で「ウィンドウ」の出力は背景の出力と同じですが、重大な違いが1つあります。



これを表示するには、「ウィンドウ」の現在の行への非表示ポインターが使用され、次の行の出力後に増分されます。 WX / WY座標のために「ウィンドウ」が無効または非表示になっている場合、そのラインカウンターは増加しません。 したがって、「ウィンドウ」の出力が途中で無効になった場合、出力がオンになると、出力は中断したところから継続します。 これは、1画面の更新に当てはまります。 Vブランクの終わりに、「ウィンドウ」ラインカウンターはゼロにリセットされます。



さらに、LCDCが変更されると、カウンター値が変更されます。 「ウィンドウ」がオフになり、LCDCを介してオンになっている場合、その出力は最初の行からの次の画面更新でのみ開始されます。



少なくとも1つのゲーム、DMGのこの機能を使用しています-Ant Soldiers。 起動後すぐに、ゲームの作成者が画面の下部に表示されます。 「ウィンドウ」を表示するときに上記の機能が考慮されない場合、画面の下部は空になります。 さらに悪いことに、ゲームインターフェースも表示されないため、通常のゲームは不可能になります。

スプライト

今ではスプライトの番です。 また、タイルで構成されていますが、まったく異なる方法で表示されます。



スプライトのサイズは8x8または8x16、つまり LCDCレジスタのフラグによって制御される1つまたは2つのタイル。 スプライトに関する情報は、OAMメモリ領域にあります。 スプライトごとに4バイトあり、OAMに最大40個のスプライトを保存できます。 これらのバイトには、次の情報が含まれています。

バイト	予定
0	Y座標
1	X座標
2	タイル番号（0-255）
3	ビット7：優先度 ビット6：1の場合、垂直ミラーリング ビット5：1の場合、水平鏡像 ビット4：1の場合、OBJ1パレットを使用、それ以外の場合-OBJ0

スプライトの座標は、右下隅です。 左上隅の座標はX-8とY-16です。 スプライトのサイズはここでは関係ありません。



タイル番号については、スプライトのサイズを考慮することが非常に重要です。 8x16に設定されている場合、タイル番号の最下位ビットをリセットする必要があります。リセットしないと、一部のゲームのグラフィックス出力が正しくなくなります。



優先度が1に設定されている場合、スプライトは背景と「ウィンドウ」の背後にあるかのように描画されます。 スプライトピクセルは、値がゼロの色の上にのみ描画されます。 これを行うには、背景と「ウィンドウ」を表示してから、スプライトを表示するピクセルの色を確認します。 スプライトは、いわば、ゼロ色のピクセルを「貫通」します。 優先度が0に設定されている場合、スプライトは背景と「ウィンドウ」の上に描画されます。



リフレクションを使用すると、すべてが明確になります。 スプライト用の2つのパレット（OBP0およびOBP1）がありますが、カラーインデックス0（パレットのビット0-1）は透明ピクセルを意味し、パレット内の色は重要ではないことを除いて、同じ役割を果たします。



スプライトを表示する前に、表示する必要があるものと順序を確認する必要があります。 スプライトには、画面に表示される順序を決定する優先順位があります。 このように計算されます-スプライトは、X座標の順序で、大きいものから小さいものへと表示されます。 つまり X座標の値が小さいスプライトは、X値が大きいスプライトの上に表示されます。X座標が等しい場合、優先順位はOAMの順序に従って計算されます-OAMのアドレスが低いスプライトは高くなります。



スプライトを表示するかどうかを決定するには、OAMのY座標を確認する必要があります。 スプライトが現在の行に収まるようにする必要があります。



ここで、LYは画面の現在の行で、SpriteHeightはスプライトの高さ（8または16）です。 これは非常に重要な公式です。誤ったスプライトキューイングは、一部のゲームで微妙なバグを引き起こします（多くのゲームは、私が持っていたようにうまく動作します）。 最初に、Y座標を転送します。すでに述べたように、スプライトの座標は右下隅を示します。 繰り返しますが、スプライトの高さはこれらの計算に特に影響しませんが、現在の行の値が存在できる間隔を形成するために、スプライトの高さを考慮する必要があります。



X座標は、スプライトが画面に表示されないという事実につながる場合でも、任意の値にできます。それでも、リストに追加されます。



スプライトは優先順位に従って表示されますが、1行に10個以下です。 したがって、X座標が原因で不可視のスプライトがリストに含まれ、画面の特定の行でスプライトの可能な数が制限されます。 したがって、スプライトを画面に表示するときは、スプライトがその外側にある可能性があるという事実に備える必要があります。



10個の制限については、この制限を考慮する方法に関する信頼できる情報がまだ見つかりません。 次の2つの論理ソリューションがあります。

• Y座標に応じて表示されるすべてのスプライトからのキューイング（OAMコンテンツの通過）-10を超える可能性があります。その後、ソート後、余分なスプライトを破棄します。 より低い優先度でスプライトを投げることは論理的です。
• 10個のスプライトが入力されると、キューは停止します。 したがって、OAMにはさらに優先度の高い目に見えるスプライトが存在することが判明する場合がありますが、到達しませんでした。

他のエミュレーターが使用するため、2番目のオプションを選択しました。 ゲームでのテストは解決に役立ちませんでした-実装のいくつかは目に見えるバグが観察されませんでした。

グラフィックス 実装

そこで、エミュレーターの作成における別の重要な段階に進みます。 ここでの小さな間違いは、画面にひどい結果をもたらす可能性があります。 これらの記事を書く過程でのみいくつかのエラーを見つけました。 その前に、私はいくつかのゲームで画面上の完全な混乱を観察しなければなりませんでした。



問題のほとんどは、おそらくGameboy Wars Turboというゲームをもたらしました。 このシリーズの記事を書いているときだけ、私はその中に正しい構図を達成することができました。 他にも優れたテストゲームがあります。 私がすでに言及したアリの兵士。Kirbys Pinball Landは、スプライト出力のテストに適しています。紹介ビデオでは、さまざまなサイズのスプライトを使用しています。



通常どおり、必要なすべてのレジスタを宣言し、外部からアクセスできるようにします（具体的には、Cookieboy :: Memoryクラスの場合）。ビデオメモリとOAMでは、もう少し複雑です。



覚えているように、以前はこのメモリは常に利用可能ではなく、STATレジスタの現在の状態に依存すると言われていました。問題が発生します-必要に応じて実装する（適切なタイミングでメモリへのアクセスをブロックする）か、どれほど簡単か（メモリは常に使用可能です）。それはすべて、状態から状態への遷移のエミュレーションの精度に依存します。間隔の長さを守らないと、メモリが利用可能になったときに読み書きができなくなるという事実につながる可能性があります。私の実装では、アクセスをブロックすることが可能であることが判明しました-私がテストしたゲームは、そのような条件で正常に動作します。私のプロジェクトの初期段階では、LCDコントローラーのエミュレートはまばらで（Gameboy CPUマニュアルで説明されているようにすべてを行いました）、アクセスをブロックすると画面にゴミが表示されました。すべてのエミュレータがこれを行うわけではありませんが、それはあなた次第です。



私がしたように、フレームバッファ、または2つも必要です。 1つのフレームバッファーはカラーインデックスで構成されます-同じバッファーは正しい出力のためにその下の色をチェックする必要があるため、このバッファーが必要です。 2番目のバッファーには、最初のバッファーにあるもののコピーが含まれていますが、色は既に表示するためにRGB値で既に表されています。



グラフィックを表示するには、2つの機能が必要です。背景、「ウィンドウ」、スプライトで構成される現在の行（LY）を画面に表示するための1つ-void Cookieboy :: GPU :: RenderScanline（）。後続の出力のスプライトキューイングのもう1つの例は、void Cookieboy :: GPU :: PrepareSpriteQueue（）です。 LCDコントローラーのロジックのセクションで、これらの関数の呼び出し先を既に述べました。



実際、これらの関数の実装について話すことは何もありません-からとへのすべてを言うため（もちろん、それは興味深いものではありません）、何も言わないためです。ここでは、行動の自由があります-あなたの仕事は、画面上で正しい画像を取得することです。どの方法でこれに到達するかは問題ではありません。さまざまなエミュレーターのソースコードによると、これは顕著です-他のコンポーネントの実装はほぼ同じですが、アプローチはどこでも完全に異なります。



まとめると。現時点では、エミュレーターはコードを実行し、画面に画像を表示することさえできます。これはすべて良いことですが、テストROMを実行して実行された作業を評価することはできません。ほとんどのテストは時間をカウントするため、DMGの別のコンポーネントであるタイマーを実装する必要があります。

タイマー

タイマーは、特定の周波数で動作する2つのカウンターの形式で実装されます。



DIVと呼ばれる最初のカウンターは、16384 Hzの周波数で動作します（つまり、カウントダウンは256プロセッサーサイクルごとに発生します）。原則とその実装はどちらも非常に簡単です。示された頻度で、値はDIVレジスタで増分されます。 DIVは0から255までループされます。値が255の場合、次のサンプルでは0に設定されます。DIVに自分で何かを書き込もうとすると、その値はリセットされます。



2番目のカウンタTIMAはもう少し複雑で、より多くの機能があります。合計で、3つのレジスタが予約されています。

• TIMA . , 255 , DIV. , TIMA 0, TMA.
• TMA TIMA 255.
• TAC . .

	予定
2	: 0 – 1 –
0-1	: 00 – 4096 01 – 262144 10 – 65536 11 – 16384

実装は、前述の機能のみを考慮して、DIVとほぼ同じです。ここでは、LCDコントローラで行われたように、whileの使用を覚えておく価値があります（ところで、ループを使用せずに、より高速で精度の低いアプローチを使用できます）。 262144 Hzの周波数では、周期は16サイクルしかないため、一度に複数のサンプルを作成する必要がある場合に状況が発生する可能性があります。カウンターが2つ以上の期間に等しい場合、単純な条件はエラーの蓄積につながり、これがタイマーが正しく機能しない理由です。最初の段階では、同様の問題がありました。



そのため、現時点では、テストROMを使用してエミュレータをテストする準備ができています。この前に、別のトピック-管理について触れます。

運営管理

写真でわかるように、DMGには8つのボタンがあります。4方向の十字、AボタンとBボタン、開始ボタンと選択ボタンです。ゲームが現在どのボタンが押されているかを確認できるように、DMGはユーザー入力を登録してP1を登録します。その構造は次のとおりです。

ビット	予定
5	P15
4	P14
3	P13
2	P12
1	P11
0	P10

表を見ると、ここのすべてのボタンに十分なビットがないことがわかります。実際、ボタンの状態はP13、P12、P11、P10にのみ記録されます。ビットP15とP14は、レジスタP1を介して読み取る4つのキーの状態を選択するために、ゲームのROMによって変更されます。以下が対応表です。

P15	P14	P13	P12	P11	P10
1	0	ダウン	上へ	左へ	右へ
0	1	開始する	選択してください	B	A

このレジスタでは、値が0のビットはキーが押されたことを意味します。キーが押されると、対応する割り込みが要求されます。 STOP命令の実行によりDMGを停止状態から復帰させるのは、この割り込みです。この状態では、メインコンポーネントは機能せず、割り込みは要求されません。ボタンを押すだけでリクエストできます。私のエミュレーターでは、STOP命令は無視されます-ゲームは正常に動作しますが、テストROMはチェックしません。



実装では、DMGボタンをエミュレートするキーの状態をポーリングし、P15およびP14の値に従って対応するビットを設定します。しかし、いくつかのニュアンスがあります。



物理的なキー（キーボード、ゲームパッド、毎回）を問い合わせても機能しない可能性が最も高く、パフォーマンスはこれまでになく悪化します。実際、これは必須ではありません。測定カウンターを開始し、キーが特定の値に達したときにのみキーの状態を確認することをお勧めします。どっち？自分で決めて、全画面更新の期間-70,224サイクルを使用しました。これは快適なゲームに十分です。カウンターがキーの次のポーリングまでの時間を測定する間、以前に取得したキーの状態に従ってP1レジスタのビットを設定します。

すべてをまとめる

最後の仕上げは、エミュレータの必要なペースを維持することです。 1つの全画面更新は70,224サイクル続き、プロセッサ周波数は4194304 Hzであるため、DMGは約59.73 Hzの周波数で画面を更新します。これは60 Hzです。



まず、エミュレーターが画面の更新を完了したか、70224サイクルを完了したことを示す必要があります。次に、更新サイクルを開始します。このサイクルでは、エミュレーターが各画面更新を完了する必要があります。これと並行して、PCがこの画面更新をエミュレートするのにかかる時間を測定する必要があります。ほとんどの場合、それは非常に小さく、しばらくの間アプリケーションを「安楽死」させる必要があるため、結果としてサイクルの1回の反復には1000/60ミリ秒かかります。時間内にキーボードに問い合わせることだけを忘れないでください。



エミュレータを可能な限り最高速度で動作させる場合、エミュレータで一般的な加速エミュレーションを実装できます。



そして、私たちが持っているもの。現時点では、エミュレータにはゲームの実行に必要なすべての機能が含まれています。他のすべての機能はオプションですが、後で説明します。ここで、テストROMを使用してエミュレーションの正確性を確認することが重要です。

テスト中

DMGには、プロセッサ、メモリ、サウンド、LCDなどのさまざまなDMGコンポーネントをテストする一連のテストROMがあります。テストに合格するには、エミュレータでROMを実行するだけです。最も便利な形式のテスト結果が画面に表示されます。現時点では、プロセッサ命令の正しい動作のテスト、プロセッサ命令の継続時間のテスト、プロセッサとメモリの同期テスト、LCDテストを実施できます。元のテスト



へのリンクともう1つ念のため、作成者のサイトに何が起こるかわからない場合、テストは非常に便利です。テスト自体に加えて、リンクからソースコードを見つけることができます。アセンブラーを理解することを強くお勧めします。テストの方法と内容を理解することは、バグの修正に大いに役立ちます。これはそれほど重要ではないかもしれませんが、健全なテストでは、ソースコードを理解しないと、エラーを修正できないことがあります。



プロセッサテストは、各命令が実行された後に結果とフラグをチェックします。エラーの場合、不正な命令のオペコードが画面に表示されます。このテストパッケージは、さまざまな命令グループの11のテストで構成されています。どの特定の命令が誤って実装されているかを示すのは個々のテストです。ほとんどの場合、この段階では、主にフラグに関連する多くのエラーが発生します。私が個人的にPOP AF、DAA、HALTを持ち込んだ問題のほとんど。 POP AFの正しい実装については既に述べましたが、同じレーキに再び足を踏み入れることは意味がありません。時間と興味を失うだけです。このような取るに足らない命令についての私のdigりには限界がありませんでしたが、F。レジスタの未使用ビットをリセットするだけでした。HALTについても詳しく説明しました。 CPUマニュアルを盲目的にたどると、別の一連のdigりにつながりました...



当然、テストに完全に依存するべきではありません。誤って実装された命令またはその期間のために、テストROM自体が正しく動作しない場合があります。 DMGのあらゆる側面の最も正確な実装をすぐに処理する必要があります。そうすることで、テストの助けを借りて、気づかなかったものだけを特定したり、作成者がドキュメントで示すのを忘れたりすることができます。



これは、メジャーに関連するメジャーにとって特に重要です。プロセッサ命令の期間のテストでは、条件付き分岐命令の期間の違いを考慮に入れて、各命令の期間をサイクルでチェックします。このテストのReadmeには、メジャーを含む表があります。



起動時のテストで255のエラーが発生する可能性があります。このエラーはテストのソースコードには含まれていないため、既にinした状態に戻りました。さらに測定するためのタイマー。合格しないのはこれらの内部チェックです。これを行うには、Readmeのテーブルを用意する必要がありました。その後、テストは正常に機能し、まだエラーが発生した場所を示しました。条件分岐命令が事実であり、他のほとんどすべてが真実でした。



メモリプロセッサ同期テストは、プロセッサ命令の実行中にメモリステータスをチェックします。命令の実行後にのみ同期関数を呼び出すと、テストは失敗します。既に正しい方法を説明したので、このテストに合格することはもはや難しくありません。どちらかといえば、テストは必要なすべてのデータを画面に表示します。それがどのように機能するか疑問に思うなら、すべてが初歩的です。すべての操作は、最大周波数に設定されたタイマーカウンターで実行されます。タイマーとテスト命令の実行を正しく同期すると、プロセス（つまりプロセス）でカウンターが増加することがわかりました。実行後、これらの値がチェックされます。



最後に、LCDテスト。 LCDコントローラーの状態の期間がどの程度正確に考慮され、さまざまなイベント（たとえば、ラインカウンターLYの増加）がいつ発生するかをチェックします。このテストに合格しないと、さまざまな状態でビデオメモリとOAMのブロックをエミュレートすることさえ考えるべきではありません。また、LCDCレジスタの7ビットを使用して、正しいオン/オフ表示を検証します。このビットを使用したROM操作には、特定のアクションが必要であることを既に述べました。

おわりに

おめでとうございます-架空のエミュレーターの準備ができました。すべての重要な機能が含まれていますが、残りは実装する必要はありません-ゲームは今では正常に動作します。



プレイすることはできますが、音が出ない場合、エミュレータはまだ劣っています。サウンドについては、次の記事で説明します。このトピックは大きく、比較的複雑で、落とし穴がたくさんありますが、非常に興味深いものです。