ジャガーを1000時間で復活させる方法は？

時々彼らは私に尋ねます-どうやってエミュレータを書くのですか？ 失敗したコンソールの例で答えようとします。

エミュレーションはほとんど無限のタスクであり、不正確さは常に残ります。3DOエミュレーションにどれだけ費やしたかと聞かれたら、肩をすくめますが、3DOエミュレーションですべてが非常に良いことは確かです。 それで、新しい犠牲者を見つける時が来ました、そして、それはアタリ・ジャガーであることが判明しました。 1000時間- フェニックスプロジェクトでこのコンソールをエミュレートするためのカーネルの開発にほぼ多くの時間を費やし、現在の95％から99％に互換性を上げるにはおそらくさらに多くの時間がかかり、残りの1％には別の、おそらく1000時間ではなく、しかし、これらはすでに微妙なグリッチのデバッグに関する別の退屈な話です。




なぜジャガーなのか？ まず、既存のエミュレーターではエミュレートが不十分でした。 第二に、それはよく「文書化」されており、そのチップの仕様、回路図、そしてHDLコードさえあります ！

最初の段階は、敵に関する情報の収集です（300時間）

以下の画像は、お気に入りのゲームコンソールのエミュレーターを作成するために必要な主要情報を収集するための簡略化されたアクションプランを示しています。



ご覧のように、この段階は常に「google」という言葉に限定されるものではなく、本格的で最も重要な開発段階であり、これは研究全体です。 「グーグル」については、まず、コンソールのサブシステムの特許、チップのマーキングのデータシートを検索し、コンソールの技術面に関連するリソースの情報を読むことをお勧めします。 さらに、見つかったものに基づいて、計画に従ってデータ収集に焦点を当てます。

誰かが、別の知識源-他の人々のプロジェクト-があることを正しく指摘しています。 プロジェクトに参加したい場合、これは正しい考えですが、そうでない場合、少なくとも他の人の間違いを繰り返さないために、少なくともあなた自身のリリースまで、そのような情報源に依存することはお勧めしません。 ジャガーの場合、 仮想ジャガープロジェクトがあります。それを改善したかったのを覚えていますが、コード自体を見るとすぐにこのアイデアを破棄しました 。

回路の取り外しは、要素の動作モード、タイヤ、およびドキュメントを見つけることができなかったチップの結論の少なくとも一部の目的に関する有用な情報になる可能性があるため、最初に必ず実行する必要があるタスクです。 可能であれば、回路基板のコンピューター断層撮影を行うことができますが、古いコンソールには通常2つの層があり、ダイヤルで回路図を作成するには単純なマルチメーターで十分です。

エミュレートされたプラットフォーム用のソフトウェアの検索は、将来エミュレートされるソフトウェア自体（ダンプ-BIOS、ROM、ISO）と、このプラットフォーム用の開発ツールの両方を対象としています。 後者は、要素ベースの内部構造を特定するのに役立つテストを作成するために特に重要です。さらに、これらのテストの結果は将来役立つ可能性があり、将来のエミュレータが実際のハードウェアに準拠しているかどうかを確認できます。 多くの場合、元のSDKは最新のOSと互換性がないため、これらのSDKを最新のコンパイラに適合させるか、古いPCエミュレーターを使用してテストを記述する必要があります。 開発ツールが本当に悪い場合は、独自のアセンブラー、または単純なコンパイラーを作成することも意味があります。 私を信じて、開発ツールの準備は将来何回も報われるでしょう、それは多くの時間を節約するのに役立ちます。

ダンプについては、誰かが以前に作成したことがない場合、ROMを取得するための最も簡単な方法は、チップをはんだ付けせずにプログラマでその内容を読み取ることです、より複雑ですが、デバッグインターフェイスまたは何を介してコンソールをコンピュータに接続する方法を見つけることですいくつかの拡張ポートを使用して、PCとデータを交換するための特別なプログラムを作成します。 たとえば、3DOでARMプロセッサのJTAGに接続してROMをダンプし、コンソールのファクトリデバッグポートにも接続してコードを実行しました。このため、コントローラーとFPGAを備えた小さなデバイスを作成する必要がありました。

元素ベースの決定は、この段階のタスクの中で最も重要です。 すべてのコンポーネントについて十分な詳細なドキュメントを見つけることができた場合、すべてが正常であり、エミュレータの作成を開始できますが、主要なコンポーネントの中で実際のブラックボックスに遭遇した場合はどうでしょうか。 いくつかのオプションがあります。 あなたは額で行動することができます（スキル、時間、お金が許せば）-それはチップを開くこと、言い換えれば-チップ全体を顕微鏡で撮影し、デバイス回路を復元することです。 私はそのようなことをやったことはありませんが、こうして得られた情報の処理を自動化する忍耐力または才能があれば、これはwin-winソリューションです。

トポロジに応じて、ブラックボックスのインサーキットテストとオフサーキットテストを適用または組み合わせることができます。 どちらの場合も、デジタル信号アナライザーとオシロスコープは適切な場所に配置されます。 インサーキットテストが望ましいと高速です。このアプローチでは、コンソール内で目的のデバイスをテストする特別なコードを記述します。 SDKのデータまたはその他の考慮事項に基づいてビデオプロセッサをテストしている場合、レジスタに書き込むためのさまざまなオプションを作成し、画面上の結果を分析して、発生する中断と遅延を修正します。

たとえば、中央処理装置と直接連動しない場合など、インサーキットテストに基づいてコンポーネントの動作を判断することが難しい場合があります。 この場合、オフサーキットテストを実行するのが合理的です。このため、PCに接続するための特別なプリント回路基板を作成し、テスト済みのチップをそこに転送してから、信号を入力に送信して出力を読み取りますが、それはすべてあなたの精神的能力に依存します。 唯一のことは、この超小型回路のどこでどのような入力と出力を正確に知る必要があるということです。これは、コンポーネントの相互接続によって、特に深刻な場合はトラックを切断することによって部分的に決定できます（脚を上げることはお勧めしません-壊れます）。 パズルを解いた場合、チップ自体を交換する必要はありませんが、最終的に結論が正しいことを最終的に確認するためにエミュレーションをFPGAに接続することは簡単な手順ではありませんが、FPGAにプレフィックスを付けたい場合は-あなたはすでに傷ついています。

ジャガーはどうですか？ 私が言ったように、 チップ 、仕様、回路図にはソースHDLコードがあります 。 もちろん、動作するプレフィックスも欲しいのですが、上記のすべてを持っているので、それなしで完全に実行できると言っても安全です。 したがって、私はすぐにドキュメントを印刷会社に持ち込みました。

1. テクニカルリファレンスマニュアルトムとジェリー （これらは有名な漫画のヒーローではありませんが、コンソールのメインチップは、一般的な3DOスタイルをすぐに見ることができます。アタリ）;
2. Motoroll M68000 Famalyプログラマーズリファレンスマニュアル -コンソールのCPUに関するドキュメント。
3. プレフィックスの概略図 -何が何とどのように相互作用するかを理解することは非常に重要です。

もちろん、これはすべてのドキュメントではありませんが、主要部分のみです.EEPROMやクォーツなどのあらゆる種類の小さなもののデータシートを探す必要がありました。ライブコンソールとカートリッジがない状態でそれらの写真を実際に見つけ、電子部品にマークを付けて検索する必要がありました。

しかし、HDLコードはクラックするのが非常に難しいことがわかりました。 東芝のあまり知られていないHDLで書かれており、現代のVerilogまたはVHDLに関連して、C ++に関連してアセンブラーに似ており、100個のファイルに散らばっており、コンポーネントを念頭に置くことはできません（少なくとも私にとって）。 このコードから、私はahem ... "book"を作成する必要がありました-それでは-翻訳者を書きましょう！ コードをgithubに配置します （突然、誰でも必要です）が、コードは1回の使用に必要だったため、Virtual Jaguarの作成者から例を取り上げ、許容可能な結果を​​最短時間で達成することにのみ焦点を当てることに決めました-つまり、このコードは非常に理解しにくいです。

東芝のHDLは、構文が緩い非常に特殊な言語であることが判明しました。たとえば、その中の回路の記述は緩いです。 各回路のビット深度は、すべてのモジュールをリンクして分解することによってのみ明らかになるようであるため、チェーンのビット深度と幅を決定するために、多数のヒューリスティックを記述する必要がありました。 しかし、回路のビット深度をコンテキストから確立できなかった孤立したケースがまだあったため、この回路は単一であると仮定しました（これは正当化されました）。 簡単な例を示します。

/*2 input nand gate */ DEF ND2 (z:OUT; a,b:IN); 

この要素は非常に異なる方法で使用できます。

 //    : label := ND2 (z, a, b); label := ND2 (z[2], a[0..1]); //a[0..1] –    label := ND2 (z[2], a[0-1]); //  label := ND2 (z[1], a{5}, b[2]); //{} -          //     : label[0-4] := ND2 (z[0-4], a{9-13}, b); // b , label[0-4] := ND2 (z[0-4], a{9-13}, b[9-13]); //   label[0..4] := ND2 (z[0..4], a{9..13}, b[9..13]); //  label[0..4] := ND2 (z[0..4], a[0..4], b[0-7]); // b    8-  label[0-4] := ND2 (z[0-4], a[0-4], b[0..7]); //  

この全体の動物園は、たとえば、チェーンz、aまたはbをどこかで宣言する必要がなく、最初に使用するときに宣言されると見なされ、チェーンの束に穴がある場合もあります。たとえば、z [0..5]およびz [10..12]-zがないことは正常です[6..9]、FPGAの個々の信号のレベルですべてが壊れて最適化されている場合、コンパイルにとって確かに重要ではありませんが、利用可能なすべての構造情報を保存する別のタスクがあります、したがって、分解には興味がありません。 これが通常のプログラムコードではなくハードウェア記述言語であるという事実は、火に少し油を追加するため、すべてのブロックが並行して実行され、コード内の順序は完全に重要ではないため、翻訳者はリンクを別の文章で分析する必要があります。

字句解析器および構文解析器の開発の最後に、すべてのチェーンが統合されたときに、コードから一種の本を作成する、つまり、より便利なプレゼンテーションに変換する時が来ました。 これを行うには、コードのブロックにそれらをバインドしてコメントを抽出する必要があり、上から順にすべてのモジュールをネストしましたが、ブロックの接続レベルでチェーンが連結および分解されるため、完全なインラインを作成することは常に可能ではありませんでした、そのような場合たとえば、接続マップを含める必要がありました。

 R1count := R1COUNT( count[0..5] = reghalf/*OUT*/ @ sysr1[0..4]/*OUT*/, /// counter clk = clk[1]/*IN*/, /// system clock cnten = sromold/*IN*/, /// counter enable cntld = mmult/*IN*/, /// counter load mr1[0..4] = preinstr'16'{5..9}/*IN*/, /// value to load ) 

これらすべてのメカニズムの準備が整ったら、たとえば、ND2（z、a、b）をz <=〜（a＆b）に置き換えるなど、結果の「書籍」の読みやすさを改善する必要がありました。 約100個のプリミティブが作成され、機能しないブロックが削除され、最終的にエミュレーション自体を開始することができました！

何がありますか？ 5プロセッサのシステム（OB-ビデオDACへのデータの準備と供給を提供、DSP-サウンドを担当、GPU-グラフィックシーンの構築を担当、Blitter-ポリゴンの塗りつぶしを担当、m68k-このすべての経済を制御）これらのプロセッサには共通のメモリ空間があり、したがって、実質的に制限なしに互いのI / Oレジスタに書き込むことができます。つまり、この混乱を最適化することは困難です。

2番目の段階は、仮想プラットフォームの作成（500時間）です。

Phoenixプロジェクトはもともとマルチプラットフォームエミュレーターとして設計されました。これは、過度の実行が正当であることが判明した場合にまさに当てはまります。 各プラットフォームは、基本プラットフォームのクラスから継承され、デバイスの基本クラスから継承される要素をツリー構造で作成および構成することにより形成されます。 つまり、C ++言語のOOP機能が使用されます。 ほとんどのエミュレーターはスタイルCで記述されており、私の意見では、開発プロセスが非常に複雑になっています。 基本クラスは、デバッガーを含むエミュレーターのフロントエンドへの統合アクセスを提供します。



プラットフォームクラスでは、通常、コンソールメモリカードを実装し、そのすべてのコンポーネントを接続します。 デバイスのクラスでは、その機能がエミュレートされ、保存された変数とデバッガーのフォーマットが書き込まれます。また、デバイスがプロセッサーである場合- 分解およびデバッグ機能が実装されている場合、エミュレートされた命令が誤って実装されても、デバッガーはエラーの検索を大幅に簡素化するため、 すぐにこれを行うことをお勧めします

また、ダンプローダーについても言及する必要があります。そのタスクは、ダンプの正当性を確認し、エミュレータで使用される形式に変換することを確認することと、ディスク上のストレージの形式に依存しないチェックサムを抽出することです。 チェックサムは、ゲームプレイの保存とのユニークな接続、および問題のあるゲームでの松葉杖の使用という2つのことに必要です。 たとえば、ジャガーのアマチュア開発の一部は 実際のハードウェアでテストされたことはなく 、一部のエミュレーターで動作するのはこれらのエミュレーターでのみテストされているためです。したがって、エミュレーターを作成するときは注意してください。または読書。

そのため、プラットフォームのスケッチを理解することは、ある夜の仕事であり、その後、主な作業が始まります...

CPU M68000

私たちの中央処理装置は当時非常に人気のあるM68000であり、プロジェクトコードを開く必要のない適切なライセンスがあっても、非常に優れたドキュメントと非常に多くの既製のエミュレータを備えています。 しかし、私にとっては、手作業で書かれた新しいプロセッサーは、コレクターのようなものです。新しいユニークなものなので、他の誰かを連れて行くことはありません。私たちが独自に作成します。さらに、 成功するには、プロセッサーを「理解」する必要があります。彼自身で。

プロセッサエミュレータはどのように書かれていますか？ こだわり続ける価値のある最も単純なバージョンでは、それらは普通の通訳として書かれています。 PCのアドレスでコマンドを読み取り（レジスターは命令カウンター）、そのタイプを判別し、実際のプロセッサーで実行する必要があるレジスターでアクションを実行します。 割り込み処理は、外部デバイスクラスから渡される呼び出しデリゲートの形式で実装できます。 すぐにあらゆる種類のクールな最適化を行うべきではありません。コードが不明瞭になるため、パフォーマンスの低下によりユーザーがトマトを投げたとしても、開発の最後に最適化する方が良いためです。

コマンドインタープリターと逆アセンブラーを作成した後、結果のプロセッサーをテストするのが理にかなっています。ここで、利用可能なエクスペリエンスを活用できます。 多くの既製のテストがあります-間違いなくそれらを実行して、命令の実装のエラーを見つけてください。 あなたが鉄を持っているなら、あなたは間違いなくあなたのテストを書くべきです、しかし、私はCD-iのために、同様のプロセッサとほとんどの命令が一致するものでしたが。 テストは将来非常に重要です。最適化を実行し、何も壊れていないことを確認する必要があるとしましょう。

ブリター

このトリッキーなことは、ジャガーでポリゴン、より正確には、ポリゴンのスキャンラインを描画します。また、四角形を塗りつぶし、画面の平面でそれらを回転させ、シェーディングを行い、Zバッファーを操作する方法も知っています。 私が始めたのはこの部分であり、残念ながらハードウェアなしで健全なテストを行うことはできませんでしたが、HDLコードの存在は本当に役立ちました。 実際、Cに似たこのコードのトランスレーターをすでに作成しているため、異なるブロックを分析しながら、必要に応じて、コードと元のHDLコードを比較するテストを行うことができました。 たとえば、HDLブロードキャストのコードは次のとおりです。

 lowen <= width[4] | width[5]; ya[0] <= lowen ? 0 : {ytm[2],ytm[1],ytm[0],0}[width[2..3]]; ya[1] <= lowen ? 0 : {ytm[3],ytm[2],ytm[1],ytm[0]}[width[2..3]]; ya[2] <= width[5] ? 0 : {ytm[4],ytm[3],ytm[2],ytm[1],ytm[0],0,0,0}[width[2..4]]; ya[3] <= width[5] ? 0 : {ytm[5],ytm[4],ytm[3],ytm[2],ytm[1],ytm[0],0,0}[width[2..4]]; ya[4] <= width[5] ? 0 : {ytm[6],ytm[5],ytm[4],ytm[3],ytm[2],ytm[1],ytm[0],0}[width[2..4]]; ya[5] <= width[5] ? 0 : {ytm[7],ytm[6],ytm[5],ytm[4],ytm[3],ytm[2],ytm[1],ytm[0]}[width[2..4]]; ya[6] <= {ytm[8],ytm[7],ytm[6],ytm[5],ytm[4],ytm[3],ytm[2],ytm[1],ytm[0],0,0,0,0,0,0,0}[width[2..5]]; ya[7] <= {ytm[9],ytm[8],ytm[7],ytm[6],ytm[5],ytm[4],ytm[3],ytm[2],ytm[1],ytm[0],0,0,0,0,0,0}[width[2..5]]; ya[8] <= {ytm[10],ytm[9],ytm[8],ytm[7],ytm[6],ytm[5],ytm[4],ytm[3],ytm[2],ytm[1],ytm[0],0,0,0,0,0}[width[2..5]]; ya[9] <= {ytm[11],ytm[10],ytm[9],ytm[8],ytm[7],ytm[6],ytm[5],ytm[4],ytm[3],ytm[2],ytm[1],ytm[0],0,0,0,0}[width[2..5]]; ya[10] <= {ytm[12],ytm[11],ytm[10],ytm[9],ytm[8],ytm[7],ytm[6],ytm[5],ytm[4],ytm[3],ytm[2],ytm[1],0,0,0,0}[width[2..5]]; ya[11] <= {ytm[13],ytm[12],ytm[11],ytm[10],ytm[9],ytm[8],ytm[7],ytm[6],ytm[5],ytm[4],ytm[3],ytm[2],0,0,0,0}[width[2..5]]; ya[12] <= {ytm[14],ytm[13],ytm[12],ytm[11],ytm[10],ytm[9],ytm[8],ytm[7],ytm[6],ytm[5],ytm[4],ytm[3],0,0,0,0}[width[2..5]]; ya[13] <= {0,ytm[14],ytm[13],ytm[12],ytm[11],ytm[10],ytm[9],ytm[8],ytm[7],ytm[6],ytm[5],ytm[4],0,0,0,0}[width[2..5]]; ya[14] <= {0,0,ytm[14],ytm[13],ytm[12],ytm[11],ytm[10],ytm[9],ytm[8],ytm[7],ytm[6],ytm[5],0,0,0,0}[width[2..5]]; ya[15] <= {0,0,0,ytm[14],ytm[13],ytm[12],ytm[11],ytm[10],ytm[9],ytm[8],ytm[7],ytm[6],0,0,0,0}[width[2..5]]; /// bits 16-19 use MX8G enabled for shifts 4-11, the low four and ///high four must be swapped mid8en\ <= ~(width[4] ^ width[5]); ya[16] <= mid8en\ ? 0 : {ytm[10],ytm[9],ytm[8],ytm[7],ytm[14],ytm[13],ytm[12],ytm[11]}[width[2..4]]; ya[17] <= mid8en\ ? 0 : {ytm[11],ytm[10],ytm[9],ytm[8],0,ytm[14],ytm[13],ytm[12]}[width[2..4]]; ya[18] <= mid8en\ ? 0 : {ytm[12],ytm[11],ytm[10],ytm[9],0,0,ytm[14],ytm[13]}[width[2..4]]; ya[19] <= mid8en\ ? 0 : {ytm[13],ytm[12],ytm[11],ytm[10],0,0,0,ytm[14]}[width[2..4]]; tm4en\ <= ~(width\[4] & width[5]); ya[20] <= tm4en\ ? 0 : {ytm[14],ytm[13],ytm[12],ytm[11]}[width[2..3]]; ya[21] <= tm4en\ ? 0 : {0,ytm[14],ytm[13],ytm[12]}[width[2..3]]; ya[22] <= tm4en\ ? 0 : {0,0,ytm[14],ytm[13]}[width[2..3]]; ya[23] <= ytm[14] & width[2] & width[3] & width\[4] & width[5]; 

そして、これはC ++で機能する同等物です。

 int ya=0; if(width<48) { if((width>>2)<2)ya=ytm>>(2-(width>>2)); else if((width>>2)>2)ya=ytm<<((width>>2)-2); else ya=ytm; ya&=0xffffff; } 

比較テストにより、Tom＆Jerryのすべてのコンポーネントを構築することが可能になりましたが、最初の操作で操作性が期待されました。もちろん、実現しませんでしたが、考えられるエラーの数は根本的に削減されました。

よく私に聞かれます-Jaguarが3DOでやったのと同じことをすることは可能ですか？ハードウェアは任意の解像度でレンダリングしますか？ 簡単な答えはノーです。 ただし、GPUコードを逆コンパイルすると、おそらく各ゲームで個別に可能です。その理由は、ブリッターが線で描画され、線からのポリゴンがGPUプログラムによって形成され、各ゲームに固有であり、残念ながら、GPUはスペースに完全にアクセスできる本格的なRISCプロセッサーですコンソールメモリ。シェーダー内には実装できません。

2人の楽しい友人GPUとDSP

彼らは本当に面白いです-彼らは非常に多くのハードウェアエラーを持っています！ そして、それらは非常に似ており、いくつかの指示が異なるだけです。 したがって、1つのプロセッサがある場合、別のプロセッサがあります。 ここでのプロセスはもっと楽しかったです。なぜなら、私はすでにブリッターに乗っていて、HDLブロックの一部が一致していたため、作業が少なくなりました。

Jaguarの最も不快なハードウェアエラーの主な原因は、 スコアボードブロックでした。これは、ある種のスーパースカラー性の原因です。これを見ると、おそらく、理解しようとせず、それに関連する問題をデバッグ段階に延期した理由がわかるでしょう。 このコードはコンソールの作者にとっては難しいようで、そこで何が起こっているのかを理解するのはかなり難しいですが、その目的は非常に明確ですが、1から1を繰り返すだけで間違いを繰り返すことができ、当然、エミュレーション速度が致命的に低下します。 たとえば、LOAD命令は、同じレジスタに書き込む次の命令の実行後に、宛先レジスタの内容を上書きできます。 また、主な奇跡はドキュメントに記載されていますが、記載されていない奇跡を見つけることができました。 一般に、ルールのない命令のレースはジャガーにとって普通です。

プロセッサを扱う場合、ドキュメントに記載されているよりも正確に算術サブシステムのすべてのフラグの計算を正確に再現することが非常に重要であり 、成功しましたが、互換性にプラスの影響を与えましたが、パフォーマンスが大幅に低下しました。 実際、これらのプロセッサのALUとシフトユニットは常にフラグを形成します。 （マニュアルによると）未定義のフラグ状態の命令については、フラグの形成を除いて、サブシステムが結果を使用しないようにする必要があります。 クロックサイクルごとに1つの命令を持つ26 + MHzの周波数と同様のオーバーヘッドを持つ2つのプロセッサ-これはパフォーマンスに大きな打撃を与えますが、互換性が最も重要です！

オブジェクトプロセッサ（OB）

このフルーツは非常に珍しいもので、DACのスキャンラインを描画するだけでなく、スプライトをスケーリングしてこれらのラインに書き込むこともできます。また、GPUを起動することもできます。順番に、オブジェクトプロセッサに割り込みを送信する必要があります。オブジェクトプロセッサは、ラインを描画し、GPUを起動し続ける必要があります。

このブロックは、おそらく最も複雑なステートマシンであり、とりわけ、そのようなものをスケッチすることをお勧めし ます 。 少なくとも数百行のリッチコードがより明確になります。



一般的に、回復可能なアルゴリズムのスケッチに大量の紙を使い、メモ、計画、仮説リストにいくつかのノートを費やしました。 彼らが言うように- 悪い鉛筆は良いメモリ （コンピュータを含む） よりも優れています 。

第三段階-カブトムシの狩り（200時間）

そのため、すべてのブロックは準備ができて組み立てられていますが、マーフィーの法則によれば、彼らは働きたくありません あなたは精神的にこれに備えていないので、黒い画面を観察したり、アーティファクトがまだらになったりするのはまだ不快です。 ただし、便利なデバッガーを作成するのが面倒ではない場合は、最初の命令で大量のエラーが表示されることがすぐにわかります。 作成していない場合は、開発環境のデバッガーとprintfを使用してデバッグできますが、デバッガーの作成ははるかに簡単です。



逆アセンブラーと単純なコンソール出力以外に何を使用しますか？ たとえば、どのサブシステムがこのメモリ領域に書き込んだか、特に5つのジャガープロセッサを示すソースマップは、誰がいじめっ子であるかを追跡するのに非常に役立ちました（多くの場合、Blitterでした）。

デバッガーでの実行、読み取り、または書き込みのための単純なブレークポイントに加えて、コードからオンデマンドの一時停止機能を実装すると便利です。たとえば、GPUまたはDSPが内部メモリを超えているかどうかを確認し、そうであれば、シャットダウンしてデバッガーに制御を転送します。 したがって、たとえば、ジャガーで重大なハードウェアエラーを特定しました。 切り替えバンクを使用してフラグレジスタにエントリが作成された場合、次の命令がレジスタの内容を読み取る場合、実際のハードウェアでは古いバンクからのものである必要があります。 このエラーを実装する必要がありました。そうしないと、Wolfenshtainと多くのゲームが機能しませんでした。 はい、エミュレーションでは、機能だけでなくバグを実装する必要があります！



彼らは多くのエラーを修正し、すべてが機能しているように見えますか？ いいえ、これは終わりではなく、これは狩りの始まりに過ぎません！ 次に、利用可能なすべての方法ですべての利用可能なゲームのテストを開始する必要があります！ そしてここでの主なことは、エラーを見つけることだけでなく、原因を簡単に見つけられるようにエラーを再現可能にすることでもあります。 フォーラムのメンバーはこれを手伝ってくれます。古いゲームをプレイするのは楽しいですが、100ゲームだけをテストするのは非常に難しいので、とても感謝しています。

結論として

エミュレータのパフォーマンスを向上させるための基本的なテクニックについて少しお話します。

1. 前処理 再利用されるデータ（主にテクスチャー）がある場合、最も処理されたオプションを再利用のために覚えて保存するのは理にかなっています。
2. インターロック検出 。 プロセッサが特定のイベントを予期していると判断できる場合、イベントが発生する前にその命令をエミュレートする必要はありません。
3. ランタイム量子化 。 キャッシュの観点からは、複数のコードを厳密に順番に何度も実行するよりも、複数のコードをそれぞれ何度も実行する方が適切です。 つまり、可能であれば、すべてのデバイスをエミュレートするのではなく、メジャーの可能な限り最大の部分で各デバイスを実行することをお勧めします。
4. 再コンパイル 。 再コンパイルは動的でも静的でもかまいません。 静的は最速ですが、エミュレートされたデバイスコードの種類が少ない場合にのみ可能です。 たとえば、3DO SDKのDSPコードには数百のツールがあるため、通常は静的再コンパイルを実行します。通常、CPUコードは多様すぎるため、ここでは動的再コンパイルが必要です。
5. サブシステムの並列エミュレーション 。 これは互換性を損なうことなく常に可能であるとは限りません。古いマルチプロセッサシステムは、最も信頼性の高い同期技術を使用していないことが多く、エミュレーションストリームの非同期はフリーズやその他のエミュレーションエラーにつながる可能性があり、その修正によりマルチスレッドによるゲインを完全に無効にできるためです。

エミュレーターを正常に作成するには、最終的に何が必要ですか？ 正確性と忍耐力には特別なものはないと思います。スキルはスキルとともに発達します。 特別で魔法的な方法はありません。