ゲームコンソールエミュレーターの開発がなぜ難しいのですか？

エミュレータはかなり魅力的だといつも思っています。古いganerationコンソールまたはハンドヘルド用のエミュレータを真剣に作成したいと思います。ハードウェアと、そのハードウェア用に作成されたゲームをより深く理解するのに役立ちます。しかし、人々はいつもそれがどれほど難しいか、そして私も試してはいけないと言っています。その理由を知りたい。

また、出発点として適切な場所に関する提案や、必要な情報はどこで入手できますか？

そう質問

これは、それらがどのように機能するかについての一般的なリソースのようです。

TL; DR-アーキテクチャはまったく異なり、元のアーキテクチャを実現するには多くの並列リソースが必要です。

ゲーム機のCPUアーキテクチャは、平均的なデスクトップマシンと比較して、ややエキゾチックです。エミュレーションとは、元のハードウェアが実行したすべてをソフトウェアで実行することを意味します。つまり、元のコンソールには専用のグラフィックス、オーディオなどのチップと、異なる命令セットを持つCPUが搭載されている場合がありますが、エミュレーターはこれらの並列リソースのすべての機能を高速で実行する必要があります。

コンソールのGPUが古い場合を除き、最新のグラフィックスカードは、たとえ安価なものであっても、最も高価なマルチコアCPUの何倍ものスループット（グラフィックスワークロードの場合）を持っているため、ほぼ確実にホストマシンのGPUでエミュレートする必要があります。この困難をさらに悪化させているのは、CPU、GPU、その他のオンボードDSP、およびメモリ間の通信がハードウェア構成の特性を活用するためにコンソールでおそらく高度に最適化されているため、これらのリソースもレートを一致させる必要があるという事実です。

これらすべての困難をさらに複雑にしますが、通常、コンソールのハードウェアの仕様についてはほとんど知られていないため、これは設計上非常に困難になっています。リバースエンジニアリングは、愛好家がやることがますます少なくなっています。

物事を把握するために、アーキテクチャシミュレーター（たとえば、x86マシンでPowerPCプログラムを実行し、それに関するあらゆる種類の統計を収集できるプログラム）は、リアルタイムよりも1000倍から100000倍遅く実行されます。最新のCPUのRTLシミュレーション（チップを構成するすべてのゲートとフリップフロップのシミュレーション）は、通常10Hzから数百Hzの間でのみ実行できます。非常に最適化されたエミュレーションでさえ、ネイティブコードの10〜100倍遅くなる可能性が高いため、今日特に説得力をもってエミュレートできるものは制限されます（特に、ゲームコンソールエミュレータが意味するリアルタイムインタラクティブ性を考慮すると）。