クローズ。この質問は
意見ベースです。現在、回答を受け付けていません。
コメント
。
ただし、'は技術的な理由ではなく、暗黙の使用例であり、ここではその他の'ハードウェア。これには常に更新が必要なため（実際のハードウェアでも、'エミュレーションに固有の問題ではありません。
@Raffzahn：FPGAデバイスを使用する場合ハードウェアレベルで元の動作を正確に模倣しているため、FPGAプログラマーが何も知らないハードウェアで動作するために更新は必要ありません。
回答
FPGAエミュレーターがビンテージハードウェアと一般的に共有する利点は、タイミングに非常に依存する方法でハードウェアと相互作用するデバイスを使用できることです。たとえば、NES用のゲームカートリッジがある場合特定のスプライトのデータの最初の行がフェッチされるたびに割り込みがトリガーされ、カートリッジの内容を読み取ってエミュレートするコンソールは、カートリッジが何であるかを認識できた場合にのみ、ゲームを正しくプレイできます。
FPGAベースのハードウェアは、一般的には同様に機能しますが、それ以上ではありません。ヴィンテージのハードウェアよりも確実ですが、覚えておくべき奇妙な癖がいくつかあります。たとえば、Atari 2600の一部のプロトタイプ拡張カートリッジは、NMOS 6502がデータバスをハイに引き上げようとしている場合でも、外部デバイスを圧倒するのに十分な努力をすることができないという事実に依存していました。ラインを低く引っ張ったり、試みでそれ自体を損傷したりしないでください。逆は当てはまらないことに注意してください。外部デバイスがラインをハイにプルしているときにラインをローにプルしようとするNMOSデバイスは、その試みでそれ自体に損傷を与える可能性があります（RIP2600jr）。バスワイヤをオーバードライブする機能に依存するNMOSデバイスを最新のレクリエーションシステムに接続し、システムが「これらのワイヤのハイサイド駆動電流を制限しなかった場合、外部デバイスに損傷を与える可能性があります。私はしません」。それが実際にどの程度問題になるかはわかりませんが、そのような技術に依存するデバイスはおそらくまれであるため、損傷した場合は非常に残念です。
もう1つの潜在的な問題は、ビンテージの電子機器が多くの場合、信号への応答がかなり遅いため、デバイスがワイヤ上で非常に短時間信号を出力する場合、無視される可能性があります。一部のビンテージ電子機器は、入力の組み合わせが、出力を低くする必要がある1つの状態と、出力を低くする必要がある別の状態の間で変化した場合に、短いグリッチパルスを出力することがありました。 FPGAレクリエーションがそのようなパルスを無視するように設計されていない場合、元のハードウェアでは問題が発生しなかったとしても、再作成されたハードウェアで誤った動作を引き起こす可能性があります。
個人的には、FPGAが最善の方法だと思います。ヴィンテージハードウェアはかっこいいですが、信頼性に問題があることがよくあります。ソフトウェアエミュレーションはかなりうまく機能するかもしれませんが、エミュレータ設計者が知っているハードウェアとのインターフェースに限定されます。優れたFPGAベースのレクリエーションは、ほぼすべての種類のヴィンテージとインターフェースできます。ハードウェア。 FPGAデザイナーが何も知らないデバイスを含む一方で、ビンテージハードウェアよりも優れた信頼性を提供します。
回答
はじめに：誰かがエミュレーションを受け入れた場合の意見であるため、質問は意見を求めるために継ぎ目があります。 CPUまたはFPGA上のソフトウェアが、本物と同じであるかどうかに関係なく。
自問してみてください。見た目が良くなった現代のテクノロジーカーを運転しています。本物を運転するのと同じSSKのように？ 1950年代のBMWにすべての音、匂い、振動（そしてそれを続けるために必要なすべてのいじくり回し）で乗りたいですか、それとも2020年の電気バイクを1つのように見せて、iPodのビルドからクラシックなサウンドを提供しますか？ ？
実際のハードウェア、MiSTerなどのFPGAベースのハードウェアエミュレーター、および大量のソフトウェアを使用する場合の違いは何ですか。最新のWindows、MacOS、およびLinuxコンピューターで実行されているさまざまなシステム用のエミュレーター。
ユーザーだけの場合は、最新のキーボードと最新のマウスを使用することに納得してください。 4k画面で640x 400のような画像を処理すれば、必要なのはソフトウェアだけです。FPGAバージョンは、同じ最新のデバイスを使用しているため、すでにやり過ぎです。
一方、 、イメージングだけでは不十分であるが、かさばるAtariマウス、波打つAmigaキーボード、またはかさばるC64ジョイスティックをすべて実際のCRTグレアで表現したい場合は、他に方法はありません。
私の頭に浮かんだことの1つは、ソフトウェアエミュレータとハードウェアエミュレータの両方が十分に正確ではない可能性があるということです
今ではそうです。細部に至るまで。最新のハードウェアは、HLLソフトウェアを使用してサイクルの正確なタイミングを取得できるほど高速です。特に、オールインとアウトプットがエミュレートされ、最新のデバイスにマッピングされている場合。
しかし、これは実装の品質に応じて、次のことができるもののように思えます。エミュレーターによって異なり、バグ修正のために時間の経過とともに改善されますが、基本的な問題ではありません。
遅延プログラミングとメンテナンスによってアプローチが無効になることはありません。実際のハードウェアを除いて、すべての目的で違いはありません。
また、ソフトウェアエミュレーターの遅延の問題について聞いていますが、私は「このようなことが、エミュレートされたマシンよりもおそらく数百万倍速いコンピューターで実際に感じられることに少し驚かされます。
おそらく100倍、覚えておいてください。ほとんどの主要なコンポーネントはそれほど速くはなりませんでした。そのほとんどは、より大きなサイズのデバイスとデータのニーズによって使い果たされています。
遅延の問題はいつものようにそれ以来存在しています。彼らが違いを見て/感じることができるといういくつかの発言が常にあります。これはいくつかの非常に専用の状況では当てはまるかもしれませんが、ほとんどの場合ゴミです。ジョイスティックをテストするときにすでに数マイクロ秒かかると主張するのは、単なる空想です。
ソフトウェアエミュレーションよりも実際のハードウェアまたはFPGAベースのエミュレーションを好む技術的な理由は本当にありますか
技術的な理由を構成するもの完全に異なる実装を比較する場合、用語自体は明確ではありません。
または、これは単なる懐かしさであり、あなたのように埋めたいという願望によって引き起こされます。本当に80年代または90年代に戻っていますか？
古いマシンの前に座ったことはありますか？驚くべき方法です。今日の標準化された機器を離れるとき、さまざまなキーボードが感じます。
もちろん、ハードウェアをいじくり回すこともあります。ここでインターフェイスを追加すると、次の数行が追加されるだけなので、エミュレータを実際に楽しむことはできません。コード-または単にconfigurati場合によってはオンになります。レイアウト、エッチング、はんだ付け、特にそれが機能するまでの呪いやパッチはありません。
回答
やりたい質問で言及されている「FPGAエミュレーション」という用語を明確にします。
まず、もちろんソフトウェアエミュレーションなどがあります。例として、6502 CPUの（多かれ少なかれ）正確なソフトウェアエミュレータをいくつか取り上げます。 。これらは、各コマンドあたりのサイクル数、メモリアクセスのアドレス、さらには「内部状態」（ソフトウェアで表示されるレジスタの状態のみ）など、実際のCPUのすべての外部アーティファクトをエミュレートしようとします。それでも、ハードウェアデバイスではなく、純粋なソフトウェアの問題であるという点から、実際のCPUとは何も似ていません。
実際の6502の新しい機能が発見されたとき（新しい文書化されていないオペコードやフラグ、実行の詳細など） ）、「実装する別の機能」のようにソフトウェアエミュレータに挿入されます。実装者が知らない場合、本物の機能はソフトウェアエミュレーターに組み込まれません。
次に、6502互換のHDLコアを見てみましょう。これらは実際には実際のデジタルロジックデバイス、またはそのモデルを表しています（HDLがシミュレートされている場合、FPGAやASICなどの実際のハードウェアには実装されていません）。現在、CPUレジスタ用の実際のフリップフロップ（またはラッチ）ストレージがあり、実際のCPUバス信号を実装し、元の6502の代わりにレトロコンピュータに挿入することもできます。それでも、（多かれ少なかれ）「ゼロから」作成されます。内部構造ではなく、交換する予定のCPUの仕様を使用します。それでも、実際のレトロCPUには存在するが、実装者にはまだ知られていない、その仕様に記載されていない機能が欠けています。
再構築の別のレベルは、次の方法で構築されたHDLデザインである可能性があります。
- 実際のレトロCPUのキャップを外して写真を撮ります
- 次に、ネットリストとトランジスタレベルの回路図を（手動または多かれ少なかれ自動化されたツールで）再作成します
- netlistはゲートレベルの回路図に変換されてからHDL記述に変換され、FPGAまたはASICに実装されます。
以前の場合とは異なり、実際のCPUのほとんどすべての機能が結果として得られるHDLの構造は、（論理ゲートおよびフリップフロップレベルで）実物の構造とほぼ同等であるため、「ネイティブに」実装されます。
それでも、たとえば6502などの問題が発生する可能性があります。不規則に動作するいくつかの命令があり、そのような動作はHDLでは自然に現れないように感じます。
一般的に言って、私は考えます「リバースエンジニアリングしてからHDLを再作成する」より上のすべては、実際にはソフトウェアまたはハードウェアのいずれかでエミュレーションですが、後者の方法は ではありません。
言い換えれば、古いソフトウェアの保存を考えてみましょう。最新のハードウェアで実行することもできますが、利用できない場合は、ソフトウェアエミュレーターが機能します。それでも、実行に使用される古いソフトウェアはまったく同じです。
今度は古いハードウェア（CPU）は保持されますが、本物の実装は利用できないため、新しいテクノロジーを使用して再作成しますが、CPUの論理構造はまったく同じです。
回答
エミュレータの作成者として、レイテンシの質問のみに回答を提供するには：
例外はたくさんありますが、「80年代以降の元のハードウェアに関する一般的なルール」 「90年代初頭」では、ジョイパッドとキーボードの入力の変更は、ハードウェアで発生直後に検出でき、ビデオとオーディオがマシンから出力されると、ほぼすぐにユーザーに届きます。たとえば、従来のCRTテレビの場合、ラスターのレベル現在ペイントしているのは、マシンのライブ出力に非常に近いです。
ハードウェアを使用すると、入力は通常トラバースします。 es BluetoothまたはUSBスタック。これは、ホストOSによって特定の間隔でのみ検査される可能性があり、何かが発生した場合は、特定のスケジューラーに応じてすぐに発生する場合と発生しない場合がある、対象のプロセスにそれ以降を通知します。
多くのエミュレーターは、ゲームの設計方法のように見えるメインループも実装しています。
- 最新の入力をすべて収集し、エミュレートされたマシンに転送します。
- マシンを1フレーム実行します。
- 出力の次のフレームを非表示のバッファにペイントします。
- 次のvsyncとブロックで表示するためにキューに入れます。
- 繰り返します。
議論のために、最新のマシンが非常に高速で、ステップ2と3が瞬時に行われると想像してください。次に：
- 入力レイテンシの平均半分のフレームに加えて、Bluetooth / USBシグナリングと追加されたOSがあります—フレームの先頭の直後に発生する入力は転送されません。次の開始まで、最後に発生したものはほぼ適切なタイミングで伝達され、その間の待機時間の範囲は線形であるため、平均はその中間になります。
- 次のvsyncでプレゼンテーション用のフレームを投稿し、表示される時間になるまで待機するため、出力レイテンシの追加フレームが修正されました。
したがって、理想的なハードウェアでは、その単純なループでは、平均して、何かを押してから画面が反応するまでの遅延は、実際のハードウェアよりも約1.5フレーム長くなります。これは、ホストマシンとエミュレートされたマシンが同じフレームレートで実行されている場合のみです。 。
純粋主義者は、元のゲームの中には、1日のテストと調整に適切な時間をかけた後、非常に細かく調整されているため、1.5フレームで検出できないほど不利になると主張しています。
FPGAは通常、販売方法に関係なく*エミュレーションです。これは、通常、高レベルのハードウェア記述言語で仕様を再実装する人だからです。しかし、彼らはその待ち時間を可能な限り省略しようとしています。高品質のものは、ビデオバッファリングを完全に省略し、システムの残りの部分をリアルタイムで実行し、最小限の遅延で入力をプッシュします。
*資格以下の@lvdによって提供される修正に従って追加されました。より多くの色については彼の答えを参照してください。
もちろん、ソフトウェアのソフトウェアの問題のほとんどを修正するのは難しいことではありません。
- 入力をより頻繁に転送します。
- しないでください。 vsyncを使用して、vsyncへの新しい出力をトリガーします。
- ダブルバッファを使用しないでください。
極端な場合、FPGAと同様の出力レイテンシでラスターを競合させることもできます。 -頻繁な入力のための周波数ループ。ベースハードウェアが画面のティアリングを生成する可能性のあるあらゆる種類の出力をサポートしている場合は、「ツールがあります。
残念ながら、このようなアプローチは通常、エミュレータで採用されていませんでした。過去、特にレイテンシがこのように広く議論されるトピックになり、ネガティブなイメージの何かが立ち往生する前に。
コメント
回答
HWとSWの多くの側面は、ここで他の投稿で取り上げられているので、それらに触れないでください。代わりに、 LATENCY の問題を、さまざまなプラットフォーム用のエミュレーターのコーディング中に取得した経験とともに、私の観点から説明したいと思います。 …
最新のマシンでSWエミュレーターを作成することは、直接I / Oアクセス時間に戻ったときよりも、レイテンシーの観点からはるかに困難です。家庭用コンピューターやゲーム機の場合、サウンド、ビジュアル出力、ユーザー入力をできるだけ正確にシミュレート/エミュレートする必要があります。最大の問題は音です。これは、私たちの聴覚が他のどの感覚よりもはるかに優れており、音が少しでもずれている場合でも違いを感じたり聞いたりできるためですmsまたはHz。画面が1または2フレームずれている場合、違いはわかりません。また、入力が少し遅れても問題ありません（ほとんどの人にとって）。
最新のマシンアーキテクチャでは、すべてがバッファリングされます（特に音）。したがって、サウンドを出力するには、 PCM データを作成する必要があります。このデータは、サウンドチップに送信され、
DMA + DAC 。これを行うために、通常、2つの円形または多くの小さな線形バッファが使用されます。グリッチのないサウンドを生成するには、バッファが十分に大きくなければなりません。たとえば、前回Windowsで WAVEOUT をチェックしたときは少なくとも20-80ミリ秒が必要です。 DirectSound 必要>400 ms
エミュレートされたプログラムが調整される場合サウンド出力すでにエンキューされたサウンドが再生された後にのみ出力されます。
一部のプラットフォームのI / O入力にも同じことが当てはまるため、遅延が加算されます。
<を使用する場合div id = "9acf87b885">
たとえば、シミュレーションがエミュレートされたコンピューターの元の速度の100倍速く実行できると仮定します。つまり、シミュレーションが何かを実行している時間は1％のみで、残りはSleep()です。スリープ中、エミュレーションは何にも応答できません。そのため、キーストローク、ファイアクリックなどを見逃す可能性があります。一部のエミュレーターが入力を無視する代わりに、バッファーを再度使用してレイテンシーを引き起こす可能性があることを修正します。この問題を完全に取り除く時間制御のさまざまなスタイルもあります。このテーマの詳細については、以下を参照してください。