Jaké jsou výhody / nevýhody použití retro hardware vs. emulace FPGA vs. emulace softwaru? [uzavřeno]

Výhodou, kterou emulátory FPGA obecně sdílejí s klasickým hardwarem, je schopnost používat zařízení, která s hardwarem interagují způsoby, které jsou velmi časově závislé. Například pokud má někdo herní kazetu pro NES který spustí přerušení pokaždé, když se načte první řádek dat pro konkrétní sprite, konzole, která přečte obsah kazety a poté emuluje, bude schopna správně hrát hru, pouze pokud bude schopna rozpoznat, co kazeta dělal s přerušovací linkou.

Hardware založený na FPGA by obecně fungoval stejně dobře, ne-li víc spolehlivě než starý hardware, ale je třeba mít na paměti několik podivných vtípků. Některé prototypové rozšiřující kazety pro Atari 2600 se například spoléhaly na skutečnost, že i když se NMOS 6502 snaží vytáhnout datovou sběrnici vysoko, není schopna se dostatečně snažit přemoci externí zařízení, které se snaží vytáhněte vlasec nízko a při pokusu se nepoškozujte Zpětná vazba není pravdivá: zařízení NMOS, které se pokouší vytáhnout linku nízko, zatímco externí zařízení ji táhne vysoko, se může při pokusu poškodit (RIP 2600jr). Pokud by bylo možné zapojit do moderního rekreačního systému zařízení NMOS, které se spoléhalo na schopnost přetěžovat vodiče sběrnice, a systém by „neomezil proud pohonu vysoké strany na těchto vodičích, mohlo by to poškodit externí zařízení. Nevím, do jaké míry by to vlastně byl problém, ale protože jakákoli zařízení, která se spoléhají na takové techniky, jsou pravděpodobně vzácná, bylo by velmi nešťastné, kdyby byla poškozena.

Další potenciální problém je, že klasická elektronika byla často poměrně pomalu reagovat na signály, což znamenalo, že pokud by zařízení mělo velmi krátce vydat signál na vodiči, bylo by to pravděpodobně ignorováno. Některá klasická elektronika by někdy vydávala krátké závady, pokud by se změnila kombinace vstupů mezi jedním stavem, kde by měl být výstup nízký, a jiným stavem, kde by měl být výstup nízký. Pokud rekreace FPGA není navržena tak, aby takové impulsy ignorovala, mohou způsobit chybný provoz na nově vytvořeném hardwaru, i když by na originálu nezpůsobily žádný problém.

Osobně si myslím, že FPGA jsou nejlepší způsob znovuvytváření systémů. Vintage hardware je skvělý, ale spolehlivost je často problematická. Softwarová emulace může fungovat docela dobře, ale bude omezena na propojení s hardwarem, o kterém návrhář emulátoru ví. Dobrá rekreace založená na FPGA může komunikovat s téměř jakýmkoli druhem ročníku hardware včetně zařízení, o kterých designér FPGA nic neví , a zároveň nabízí lepší spolehlivost než klasický hardware.

Předmluva: Otázky se ptají na názory, protože jde o názor, pokud někdo přijme emulaci, bez ohledu na to, zda je software na CPU nebo na FPGA stejný jako skutečný, nebo ne.

Zeptejte se sami sebe, řídí moderní technologie, které jsou připraveny hledat jako SSK stejné jako řídit skutečnou věc? Chcete jezdit na BMW z 50. let se všemi jeho zvuky, pachy a vibracemi (a veškerým drobením potřebným k udržení jeho chodu) nebo na elektrickém kole 2020 vyrobeném tak, aby vypadalo jako jedno, dává vám klasický zvuk z vestavěného přehrávače iPod ?

Putuji, jaké jsou rozdíly mezi používáním skutečného hardwaru, hardwarových emulátorů založených na FPGA, jako je MiSTer, a velkým množstvím softwaru emulátory pro různé systémy běžící na moderních počítačích se systémem Windows, MacOS a Linux.

Pokud jste jen uživatel přesvědčený o používání moderní klávesnice a moderní myši manipulace s nějakým obrázkem, který vypadá jako 640 x 400, na obrazovce 4k, pak je vše, co potřebujete. Verze FPGA již bude přehnaná, protože používá stejná moderní zařízení.

Na druhou stranu , pokud zobrazování nestačí, ale chcete cítit objemnou myš Atari, vrtivou klávesnici Amiga nebo objemný joystick C64, vše se skutečným odleskem CRT, pak neexistuje jiný způsob, jak získání skutečné věci.

Napadla mě jedna věc, že softwarové i hardwarové emulátory nemusí být dostatečně přesné.

Nyní již jsou. v každém detailu. Moderní hardware je dostatečně rychlý, aby umožnil použití softwaru HLL k získání přesného načasování cyklu. Obzvláště když je emulace všech vstupů a výstupů stejně mapována na moderní zařízení.

Ale zdá se mi to jako něco v závislosti na kvalitě implementace, která může lišit se mezi různými emulátory a časem se vylepšovat kvůli opravě chyb, ale nikoli jako zásadní problém.

Líné programování a údržba přístup nezruší. Pro všechny účely, kromě skutečných handwarů, neexistuje žádný rozdíl.

Také slyším problém latence u softwarových emulátorů, ale já „Trochu mě překvapilo, že něco takového lze skutečně cítit na počítači, který je pravděpodobně milionkrát rychlejší než emulovaný stroj.

Možná stokrát, pokud vůbec. Mějte na paměti, že většina hlavních komponent se nezískala mnohem rychleji – a většinu z toho pohltily větší zařízení a potřeby dat.

Problém latence je něco, co je tu jako vždy. Vždy bude existovat nějaká tvrzení, že vidí / cítí rozdíl. I když to může být pravda v několika málo specializovaných situacích, je to po většinu času nesmysl. Získání pocitu několika mikrosekund, když už testování joysticku může stát víc, je prostě fantazie.

Existuje opravdu technický důvod, proč upřednostňovat emulaci založenou na skutečném hardwaru nebo FPGA vs. emulaci softwaru

Co představuje technický důvod pro vás? Pojem sám o sobě není jasný, když porovnáváme úplné různé implementace.

nebo se jedná pouze o nostalgii způsobenou touhou vyplnit jako vy jste opravdu zpět v 80. nebo 90. letech?

Už jste někdy seděli před jedním ze starých strojů? Je překvapivé, jak různé klávesnice pociťují, když opouštějí dnešní standardizované vybavení.

A pak je tu samozřejmě hardwarové vrtání – s emulátory to není skutečná zábava, protože zde přidání rozhraní je pouze přidání několika řádků kód – nebo jen konfigurovat v některých případech zapnuto. Žádné rozložení, neleptání, žádné pájení a hlavně žádné proklínání a záplatování, dokud to nefunguje.

Chtěl bych objasněte v otázce výraz „emulace FPGA“.

Nejprve samozřejmě existuje něco jako softwarová emulace. Vezměme si jako příklad některé (víceméně) přesné softwarové emulátory CPU 6502. . Snaží se napodobit všechny externí artefakty skutečného CPU, jako je počet cyklů na každý příkaz, adresy přístupů do paměti a dokonce i „interní stav“ (spíše pouze stav softwarově viditelných registrů). Přesto to nemá nic podobného se skutečným CPU, počínaje tím, že jde o čistou softwarovou záležitost, nikoli o hardwarové zařízení.

Když je objevena jakákoli nová vlastnost skutečné verze 6502 (například nové nezdokumentované operační kódy nebo příznaky nebo podrobnosti provedení) ), je vložen do softwarového emulátoru jako „další implementovaná funkce“. V softwarovém emulátoru by se nepromítly žádné vlastnosti skutečné věci, pokud by implementátorovi nebyly známy.

Pak se podívejme na HDL jádra kompatibilní s 6502.Nyní skutečně představují skutečné digitální logické zařízení – nebo jeho model (v případě, že je HDL simulován, není implementován v reálném hardwaru, jako je FPGA nebo ASIC). Nyní mají skutečné úložiště flipflop (nebo západku) pro registry CPU, mohou implementovat skutečné signály sběrnice CPU a dokonce je lze vložit do retro počítače namísto původních 6502. Přesto jsou vyráběny (víceméně) „od nuly“, se specifikacemi CPU, které mají nahradit, nikoli s jeho vnitřní strukturou. A přesto by jim chyběly funkce, které nejsou popsány v těchto specifikacích, které existují ve skutečném retro CPU, ale implementátor je zatím nezná.

Další úrovní rekonstrukce by mohl být design HDL vytvořený následujícím způsobem:

1. skutečné retro CPU je odříznuto a vyfotografováno
2. poté je znovu vytvořeno schéma seznamu netlistů a tranzistorů (buď ručně, nebo pomocí více či méně automatizovaných nástrojů)
3. netlist je převeden na schémata na úrovni brány a poté na popis HDL, který je zase implementován v FPGA nebo ASIC.

Na rozdíl od předchozích případů jsou nyní téměř všechny funkce skutečného CPU stávají se implementovány „nativně“, protože struktura výsledného HDL je víceméně rovnocenná struktuře skutečné věci (na úrovni logických bran a flipflops).

Stále se mohou vyskytnout problémy, například 6502 má nějaké pokyny, které se chovají nevyzpytatelně a mám pocit, že takové chování by se v HDL neobjevilo přirozeně.

Obecně řečeno, domnívám se Všechno nad „reverzním inženýrstvím, pak znovu HDL“ je ve skutečnosti emulace , ať už v softwaru nebo hardwaru, zatímco druhý způsob není .

inými slovy, pojďme zvážit zachování starého softwaru. Mohli bychom to spustit na současném hardwaru, ale pokud není k dispozici, vstupují do hry softwarové emulátory, ale stará část softwaru, kterou používají, je stále úplně stejná.

Nyní bychom chtěli zachovat starý hardware (CPU), ale jeho autentická implementace není k dispozici, takže jej znovu vytvoříme pomocí novější technologie, ale logická struktura CPU zůstane přesně stejná.

Chcete-li nabídnout odpověď pouze na otázku latence, jako autor emulátoru:

Výjimek je mnoho, ale obecné pravidlo pro původní hardware 80. let a do počátkem 90. let je to, že změny vstupu joypadu a klávesnice mohou být hardwarem detekovány téměř okamžitě poté, co k nim dojde, a že když se obraz a zvuk přenáší ze stroje, dostane se k uživateli téměř okamžitě – např. pro klasickou televizi CRT úroveň rastru právě malování je téměř živým výstupem stroje.

S hardwarem nyní vstup obecně prochází Jedná se o zásobník Bluetooth nebo USB, který může hostitelský OS kontrolovat pouze v určitém intervalu, a pokud se něco stalo, sdělí to dále zainteresovanému procesu, který se může nebo nemusí okamžitě stát v závislosti na konkrétním plánovači.

Mnoho emulátorů také implementuje hlavní smyčku, která vypadá, jak byste mohli hru navrhnout:

1. shromáždit všechny nejnovější vstupy a předat je emulovanému stroji;
2. spusťte stroj na snímek;
3. namalujte další snímek výstupu do neviditelné vyrovnávací paměti;
4. umístěte frontu, která se zobrazí na další vsync a zablokujte;
5. opakovat.

Představte si, že váš moderní stroj je velmi rychlý a kroky 2 a 3 jsou okamžité. Pak:

• je průměrná polovina rámce vstupní latence plus jakákoli signalizace Bluetooth / USB a přidán operační systém – žádný vstup, který se objeví hned po horní části rámce, nebude přeposlán do začátku příštího budou všechny, které se vyskytnou hned na konci, sděleny téměř ve správný čas a rozsah latencí mezi nimi je lineární, takže průměr je mezi nimi; a
• je opraven další rámec výstupní latence, protože na další vsync pošlete rámec pro prezentaci a poté počkáte, než se zobrazí.

Takže s touto jednoduchou smyčkou na ideálním hardwaru je v průměrném případě prodleva mezi tím, co něco stisknete, a reakcí obrazovky přibližně o 1,5 snímku více než skutečný hardware. A to pouze v případě, že hostitelské a emulované stroje běží se stejnou snímkovou frekvencí .

Puristé tvrdí, že některé původní hry jsou tak jemně vyladěny, že po příslušném počtu hodin testování a vyladění v průběhu dne je 1,5 rámce znevýhodňuje, což mohou zjistit.

FPGA jsou obvykle * emulace, bez ohledu na to, jak jsou „prodávány, protože jsou obvykle osobou, která znovu implementuje specifikaci v jazyce popisu hardwaru na vysoké úrovni. Snaží se ale co nejvíce z této latence vynechat – kvalitní vypustí video do vyrovnávací paměti úplně, spustí zbytek systému v reálném čase a zasune vstup s minimálním zpožděním.

* kvalifikace přidáno podle opravy poskytnuté @lvd níže. Další barvy naleznete v jeho odpovědi.

Samozřejmě není těžké vyřešit většinu softwarových problémů se softwarem:

• předávat vstup častěji;
• nedělat použít vsync ke spuštění nového výstupu do vsync; a
• nepoužívejte dvojitou vyrovnávací paměť.

V extrémech můžete dokonce závodit s rastrem pro podobnou latenci výstupu jako FPGA – pokud již máte vysokou -frekvenční smyčka pro častý vstup, a pokud základní hardware podporuje jakýkoli druh výstupu, který může způsobit trhání obrazovky, pak máte nástroje.

Bohužel takové přístupy obvykle emulátory v minulost, zejména než se latence stala tak široce diskutovaným tématem, a něco negativního obrazu se zaseklo.

Komentáře

• FPGA není vždy emulace, alespoň z hlediska " osoby, která znovu implementuje specifikaci v jazyce popisu hardwaru na vysoké úrovni "
• @ lvd z důvodu zlepšení odpovědi, můžete být konkrétnější? Jsem si ' vědom jednoho experimentu, který používal netlist extrahovaný VisualChips ze skutečného (pokud paměť slouží ) TIA, ale málo za tím. EDIT: ne, počkejte, vidím, že jste ' zveřejnili samostatnou odpověď. Děkujeme!

mnoho aspektů HW vs SW zde bylo pokryto jinými příspěvky, takže budu nedotýkat se jich. Místo toho bych rád vysvětlil problém LATENCY z mého pohledu spolu se zkušenostmi, které jsem získal při kódování svých emulátorů pro různé platformy …

Vytváření SW emulátoru na moderních strojích je z hlediska latence mnohem těžší, než tomu bylo v době přímého přístupu I / O. U domácích počítačů a herních konzolí musíme co nejpřesněji simulovat / emulovat zvuk, vizuální výstup a vstup uživatele. Největší problém je se zvukem. Je tomu tak proto, že náš sluch je mnohem lepší než kterýkoli jiný z našich smyslů a my můžeme cítit / slyšet rozdíl, pokud je zvuk vypnut už o několik ms nebo Hz. Pokud je obrazovka vypnutá o 1 nebo 2 snímky, nevidíme rozdíl. Také pokud je vstup trochu zpožděn, je to v pořádku (pro většinu lidí).

V moderní architektuře stroje je vše ukládáno do mezipaměti (zejména zvuk). Abychom mohli vydávat zvuk, musíme vytvořit PCM data, která se odesílají na zvukový čip a přehrávají se přes DMA + DAC . K tomu se obvykle používají 2 kruhové nebo mnoho malých lineárních vyrovnávacích pamětí. Nyní, aby mohly vydávat zvuky bez závad, musí být vyrovnávací paměti dostatečně velké. Například v systému Windows naposledy zkontroluji WAVEOUT alespoň 20-80 ms. DirectSound potřeba >400 ms

Nyní, pokud se emulovaný program upraví zvukový výstup bude vydán až po přehrání již načteného zvuku.

Totéž platí pro vstupně-výstupní vstup na některých platformách, takže se zpoždění sčítají.

Když použijete FPGA máte přímý přístup ke zvukovému výstupu bez ukládání do vyrovnávací paměti. Totéž platí pro vstup.

Latence vstupu (klávesnice, joystick) však obvykle nemá nic společného s latencí hostitelského systému . Obvyklou příčinou je, že většina emulátorů používá taktiky hodin k udržení emulovaných rychlostí. Takže simulují CPU nebo cokoli jiného a jakmile dosáhnou požadovaného počtu simulovaných hodin pokaždé, když spí, dokud není vydán další časovač nebo cokoli jiného. Čím rychlejší je hostitelský počítač, tím kratší čas potřebuje k emulaci, proto simulace nebude reagovat na většinu reálného času.

Předpokládejme například, že naše simulace může běžet stokrát rychleji než původní rychlost emulovaného počítače. To znamená, že pouze 1% času simulace něco dělá a zbytek je jen Sleep(). Během spánku emulace nemůže na nic reagovat. Může tedy chybět stisknutí kláves, výstřely atd. K nápravě, že některé emulátory mohou místo opětovného ignorování vstupu použít opětovné ukládání do vyrovnávací paměti, což vede k latenci. Existují také různé způsoby řízení času, které tento problém zcela odstraní. Další informace o tomto tématu naleznete na:

• Otázka přesnosti počítání cyklů při emulaci CPU

Klasické stroje NTSC (a počítače CRT Mac atd.) mohou měnit svůj grafický výstup uprostřed obnovy zobrazení CRT (částečně) svislý rastr), čímž trhá obraz v reakci na vstup v reálném čase.

Emulátory používající monitory jiné než CRT to nemohou dělat v reálném čase a mohou následující falešný rastr pouze předstírat rám nebo pole.

A jediný způsob, jak otestovat, zda je emulace přesná, ve srovnání se skutečným (základní pravdou) starým hardwarem. Zjistěte, zda v různých vrstvách čipů ASIC existují nějaké nezdokumentované skryté logické pasti (defúze atd.) Nebo chyby analogového rozložení.

Komentáře

• _ " .. může jen předstírat … " _Je v tom rozdíl? Nejde ' o emulaci o předstírání celé věci?
• Ne na displeji bez CRT. Displej LCD (et.al.) se ' neaktualizuje ve 2 prokládaných polích po 30 snímcích, kde se střídavě zobrazují střídavé řádky a horní a dolní část okna, přes 10 mS odděleně v reálném čase. Možná by FPGA napájející starý monitor CRT bylo přesnější než emulátor.
• Nic nezastaví software emulátoru, aby udělal totéž. a některé ano. Koneckonců, 60 Hz obrazovky jsou nyní standardem, což umožňuje přenášet stejné blikání jako CRT. Zde není potřeba žádný software na bázi FPGA ani CRT.