Wat zijn de voor- / nadelen van het gebruik van retrohardware versus FPGA-emulatie versus software-emulatie? [gesloten]

Een voordeel dat FPGA-emulators over het algemeen delen met vintage hardware, is de mogelijkheid om apparaten te gebruiken die met de hardware communiceren op een manier die erg timingafhankelijk is. Als iemand bijvoorbeeld een gamecartridge voor de NES heeft die een interrupt activeert elke keer dat de eerste regel met gegevens voor een bepaalde sprite wordt opgehaald, een console die de inhoud van een cartridge uitleest en vervolgens emuleert, zou het spel alleen correct kunnen spelen als het zou kunnen herkennen wat de cartridge deed met de interrupt-lijn.

FPGA-gebaseerde hardware zou over het algemeen net zo goed werken, zo niet meer betrouwbaarder dan vintage hardware, maar er zijn een paar rare eigenaardigheden om in gedachten te houden. Sommige prototype-uitbreidingscartridges voor de Atari 2600 vertrouwden bijvoorbeeld op het feit dat zelfs wanneer de NMOS 6502 probeert de databus hoog te trekken, hij niet in staat is om hard genoeg te proberen om een extern apparaat te overmeesteren dat trek de lijn laag, en beschadig zichzelf niet tijdens de poging. Merk op dat het omgekeerde niet waar is: een NMOS-apparaat dat probeert een lijn laag te trekken terwijl een extern apparaat deze hoog trekt, kan zichzelf daarbij beschadigen (RIP 2600jr). Als iemand op een modern recreatiesysteem een NMOS-apparaat zou aansluiten dat vertrouwde op het vermogen om busdraden te overdriveren, en het systeem “de hoge aandrijfstroom op die draden niet beperkte, zou het het externe apparaat kunnen beschadigen. Ik don” Ik weet niet in hoeverre dat een probleem zou zijn, maar aangezien apparaten die op dergelijke technieken vertrouwen waarschijnlijk zeldzaam zijn, zou het erg jammer zijn als ze beschadigd zouden zijn.

Een ander mogelijk probleem is dat vintage elektronica vaak nogal traag om op signalen te reageren, wat betekende dat als een apparaat heel kort een signaal via een draad zou uitvoeren, het waarschijnlijk zou worden genegeerd. Sommige vintage elektronica zou soms korte glitch-pulsen uitvoeren als een combinatie van ingangen veranderde tussen een staat waarin de uitvoer laag zou moeten zijn en een andere staat waarin de uitvoer laag zou moeten zijn. Als een FPGA-recreatie niet is ontworpen om dergelijke pulsen te negeren, kunnen ze een foutieve werking op de opnieuw gemaakte hardware veroorzaken, ook al zouden ze bij het origineel geen problemen hebben veroorzaakt.

Persoonlijk denk ik dat FPGAs de beste manier zijn van het opnieuw maken van systemen. Vintage hardware is cool, maar betrouwbaarheid is vaak problematisch. Software-emulatie werkt misschien redelijk goed, maar zal beperkt blijven tot interface met hardware waarvan de emulatorontwerper weet. Een goede FPGA-gebaseerde recreatie kan worden gecombineerd met bijna elke soort vintage hardware, inclusief apparaten waar de FPGA-ontwerper niets van af weet , terwijl ze een betere betrouwbaarheid bieden dan vintage hardware.

Voorwoord: de vraag lijkt te vragen om meningen, aangezien het een mening is als iemand een emulatie accepteert, of het nu software op een CPU of een FPGA is, hetzelfde als het echte werk of niet.

Stel jezelf de vraag, rijdt in een auto met moderne technologie die is gepimpt om eruit te zien zoals een SSK hetzelfde als autorijden in het echte werk? Wil je op een BMW uit de jaren 50 rijden met al zijn geluiden, geuren en trillingen (en al het knutselen dat nodig is om het gaande te houden) of een elektrische fiets uit 2020 die er zo uitziet en je het klassieke geluid van een ingebouwde iPod geeft? ?

Ik dwaal af wat de verschillen zijn tussen het gebruik van echte hardware, op FPGA gebaseerde hardware-emulators zoals MiSTer en de grote hoeveelheid software emulators voor verschillende systemen die draaien op moderne Windows-, MacOS- en Linux-computers.

Als je gewoon een gebruiker bent, overtuigd van het gebruik van je moderne toetsenbord en moderne muis het verwerken van een afbeelding, die eruitziet als 640 x 400, op je 4k-scherm, dan is software alles wat je nodig hebt. Een FPGA-versie zal al overdreven zijn, omdat deze dezelfde moderne apparaten gebruikt.

Aan de andere kant , als beeldvorming niet genoeg is, maar je wilt de omvangrijke Atari-muis, het kronkelende Amiga-toetsenbord of de omvangrijke C64-joystick voelen, allemaal gepresenteerd met echte CRT-schittering, dan is er geen andere manier om en het echte werk krijgen.

Een ding dat bij me opkwam, is dat zowel software- als hardware-emulators niet nauwkeurig genoeg kunnen zijn

Inmiddels zijn ze dat wel. in elk detail. Moderne hardware is snel genoeg om het gebruik van HLL-software mogelijk te maken om de exacte timing van de cyclus te verkrijgen. Vooral als all-in en output toch wordt geëmuleerd, toegewezen aan moderne apparaten.

Maar dit lijkt me iets, afhankelijk van de kwaliteit van de implementatie die kan variëren tussen verschillende emulators en verbeteren in de loop van de tijd vanwege bugfixing, maar niet als een fundamenteel probleem.

Lui programmeren en onderhouden maakt de aanpak niet ongeldig. Voor alle doeleinden, behalve echte hands-on hardware, is er geen verschil.

Ook hoor ik over het latency-probleem met de software-emulators, maar ik “Het verbaast me een beetje dat zoiets echt kan worden gevoeld op een computer die waarschijnlijk miljoenen keren sneller is dan de geëmuleerde machine.

Misschien wel honderd keer, of helemaal niet. Houd er rekening mee dat de meeste belangrijke componenten niet zo veel sneller zijn geworden – en het meeste daarvan is opgegeten door grotere apparaten en gegevensbehoeften.

Het latentieprobleem is iets dat is er al zoals altijd. Er zullen altijd mensen zijn die zeggen dat ze het verschil kunnen zien / voelen. Hoewel dit waar kan zijn in een paar, zeer toegewijde situaties, is het meestal onzin. Beweren dat je een paar microseconden voelt, terwijl het testen van een joystick al meer kan kosten, is gewoon fantasie.

Is er echt een technische reden om echte hardware of FPGA-gebaseerde emulatie te verkiezen boven software-emulatie

Wat is een technische reden voor jou? Op zichzelf is de term niet duidelijk bij het vergelijken van compleet verschillende implementaties.

of dit is gewoon nostalgisch, veroorzaakt door de wens om te vullen zoals jij zijn echt terug in de jaren 80 of 90?

Heb je ooit voor een van de oude machines gezeten? Het is verrassend hoe verschillende toetsenborden voelen bij het verlaten van de gestandaardiseerde apparatuur van vandaag.

En dan is er natuurlijk nog het sleutelen aan hardware – niet echt leuk met emulators, want hier is het toevoegen van een interface slechts het toevoegen van een paar regels code – of gewoon configurati in sommige gevallen. Geen lay-out, niet etsen, niet solderen en vooral geen vloeken en patchen totdat het werkt.

Ik zou graag willen verduidelijk de term “FPGA-emulatie” die in de vraag wordt genoemd.

Ten eerste is er natuurlijk zoiets als software-emulatie. Laten we als voorbeeld enkele (min of meer) exacte software-emulators van de 6502 CPU nemen . Ze proberen alle externe artefacten van de echte CPU na te bootsen, zoals het aantal cycli per commando, adressen van de geheugentoegang en zelfs “interne toestand” (liever alleen de toestand van software-zichtbare registers). Toch heeft het niets hetzelfde met de echte CPU, te beginnen vanaf het punt dat het pure softwarekwestie is, geen hardwareapparaat.

Wanneer een nieuwe functie van real 6502 wordt ontdekt (zoals nieuwe niet-gedocumenteerde opcodes of vlaggen of uitvoeringsdetails ), wordt het in de software-emulator ingevoegd als “een andere functie om te implementeren”. Geen enkele kenmerken van het echte werk zouden in de software-emulator worden geëmegreerd, als ze niet bekend zijn bij de implementator.

Laten we dan eens kijken naar 6502-compatibele HDL-cores.Ze vertegenwoordigen nu eigenlijk een echt digitaal logisch apparaat – of een model daarvan (in het geval dat de HDL is gesimuleerd, niet geïmplementeerd in de echte hardware zoals FPGA of ASIC). Ze hebben nu echte flipflop (of latch) opslag voor de CPU-registers, ze zouden echte CPU-bussignalen kunnen implementeren en zelfs in de retro-computer kunnen worden geplaatst in plaats van de originele 6502. Toch zijn ze (min of meer) “from scratch” gemaakt, met de specificaties van de CPU die ze moeten vervangen, niet de interne structuur. En toch zouden ze functies missen die niet in die specificaties worden beschreven, die wel bestaan in een echte retro-CPU, maar nog onbekend zijn bij de uitvoerder.

Een ander niveau van de reconstructie zou het HDL-ontwerp kunnen zijn dat op de volgende manier is gebouwd:

1. echte retro CPU wordt ontcijferd en gefotografeerd
2. vervolgens worden netlijst- en transistorniveau-schemas opnieuw gemaakt (met de hand of met min of meer geautomatiseerde tools)
3. netlist wordt geconverteerd naar het poortniveau-schema en vervolgens naar HDL-beschrijving, die op zijn beurt wordt geïmplementeerd in FPGA of ASIC.

In tegenstelling tot eerdere gevallen, nu bijna alle functies van de echte CPU worden “native” geïmplementeerd, omdat de structuur van de resulterende HDL min of meer gelijk is aan de structuur van het echte werk (op het niveau van logische poorten en flip-flops).

Toch kunnen er problemen zijn, bijvoorbeeld 6502 heeft enkele instructies die zich grillig gedragen en ik heb het gevoel dat dergelijk gedrag niet van nature in HDL naar voren zou komen.

Over het algemeen ben ik van mening Alles boven de “reverse-engineer, then recreate HDL” is eigenlijk een emulatie , hetzij in software of hardware, terwijl de laatste manier niet is.

Met andere woorden, laten we eens kijken naar het behoud van de oude software. We zouden het op moderne hardware kunnen draaien, maar als het niet beschikbaar is, komen software-emulators in het spel, maar het oude softwarestuk dat ze gebruiken is nog steeds precies hetzelfde.

Nu willen we dat graag bewaar oud stuk hardware (CPU), maar de authentieke implementatie is niet beschikbaar, dus we creëren het opnieuw met nieuwere technologie, maar de logische structuur van de CPU blijft precies hetzelfde.

Om alleen een antwoord te geven op de latentievraag, als emulatorauteur:

Er zijn veel uitzonderingen, maar de algemene regel over originele hardware uit de jaren 80 en begin jaren 90 is dat veranderingen in joypad- en toetsenbordinvoer vrijwel onmiddellijk na het optreden door hardware kunnen worden gedetecteerd, en dat als video en audio wordt uitgevoerd vanaf de machine het de gebruiker vrijwel onmiddellijk bereikt – bijv. voor een klassieke CRT-televisie is het niveau van het raster is aan het schilderen is nu bijna de live output van de machine.

Met hardware nu gaat de invoer over het algemeen door is een Bluetooth- of USB-stack, die alleen met een bepaald interval kan worden geïnspecteerd door het host-besturingssysteem, en als er iets is gebeurd, communiceert het dat verder naar het geïnteresseerde proces, wat al dan niet onmiddellijk kan gebeuren, afhankelijk van de specifieke planner.

Veel emulators implementeren ook een hoofdlus die eruitziet als hoe je een spel zou kunnen ontwerpen:

1. verzamel alle laatste invoer en stuur deze door naar de geëmuleerde machine;
2. laat de machine draaien voor een frame;
3. schilder het volgende frame met uitvoer naar een onzichtbare buffer;
4. zet dat in de wachtrij voor weergave bij de volgende vsync en blokkeer;
5. herhaal.

Stel je voor dat je moderne machine erg snel is en dat stappen 2 en 3 direct zijn. Vervolgens:

• is er gemiddeld een half frame invoerlatentie plus alle Bluetooth / USB-signalering en het toegevoegde besturingssysteem – elke invoer die net na de bovenkant van een frame plaatsvindt, wordt niet doorgestuurd tot het begin van de volgende zal alles dat aan het einde plaatsvindt, op bijna het juiste moment worden gecommuniceerd, en het bereik van de latenties daartussen is lineair, zodat het gemiddelde halverwege ligt; en
• er is een vast extra frame van output latentie omdat je een frame post voor presentatie bij de volgende vsync en dan wacht tot het tijd is om getoond te worden.

Dus met die simpele lus, op ideale hardware, is in het gemiddelde geval de vertraging tussen het indrukken van iets en het reageren van het scherm ongeveer 1,5 frames meer dan bij echte hardware. En dat is alleen als host en geëmuleerde machines met dezelfde framesnelheid werken .

Puristen beweren dat sommige originele games zo nauwkeurig zijn afgestemd, na het juiste aantal uren testen en tweaken in de loop van de dag, dat 1,5 frames ze in een nadeel brengt dat ze kunnen detecteren.

FPGAs zijn meestal * emulatie, ongeacht hoe ze worden verkocht, omdat ze meestal een persoon zijn die een specificatie herimplementeert in een hardwarebeschrijvingstaal op hoog niveau. Maar ze proberen zoveel mogelijk van die latentie weg te laten – een goede kwaliteit zal de videobuffering volledig weglaten, de rest van het systeem in realtime laten draaien en de invoer met minimale vertraging pushen.

* kwalificatie toegevoegd volgens de correctie verstrekt door @lvd hieronder. Zie zijn antwoord voor meer kleur.

Natuurlijk is het niet moeilijk om de meeste softwareproblemen in software op te lossen:

• voer invoer vaker door;
• niet gebruik vsync om nieuwe uitvoer naar vsync te activeren; en
• gebruik geen dubbele buffer.

In extremis kun je zelfs tegen het raster racen voor vergelijkbare outputlatentie als een FPGA – als je al een hoge -frequentielus voor frequente invoer, en als de basishardware een uitvoer ondersteunt die schermscheuren kan veroorzaken, dan heb je de tools.

Helaas werden dergelijke benaderingen gewoonlijk niet gebruikt door emulators in de verleden, vooral voordat latentie zon veelbesproken onderwerp werd, en er iets van een negatief beeld is blijven hangen.

Opmerkingen

• FPGA is niet altijd een emulatie, althans in uw termen van " een persoon die een specificatie opnieuw implementeert in een hardwarebeschrijvingstaal op hoog niveau "
• @lvd Om het antwoord te verbeteren, kun je specifieker zijn? Ik ' ben op de hoogte van een experiment dat een netlijst gebruikte die door VisualChips uit een echte ) TIA, maar weinig verder. EDIT: nee, wacht, ik zie dat je ' een apart antwoord hebt gepost. Bedankt!

veel aspecten van de HW vs SW zijn behandeld in andere berichten hier, dus ik zal raak ze niet aan. In plaats daarvan zou ik het LATENCY probleem willen uitleggen vanuit mijn standpunt, samen met de ervaring die ik heb opgedaan tijdens het coderen van mijn emulators voor verschillende platforms …

Het maken van een SW-emulator op moderne machines is veel moeilijker vanuit latency-aspect dan het was in de directe I / O-toegangstijden. Voor homecomputers en gameconsoles moeten we geluid, visuele output en gebruikersinvoer zo nauwkeurig mogelijk simuleren / emuleren. Het grootste probleem is met geluid. Dat komt doordat ons gehoor veel veel beter is dan onze andere zintuigen en we het verschil kunnen voelen / horen als het geluid zelfs maar door een paar ms of . Als het scherm 1 of 2 frames is uitgeschakeld, kunnen we het verschil niet zien. Ook als de invoer een klein beetje vertraagd is, is het ok (voor de meeste mensen).

In de moderne machine-architectuur wordt alles gebufferd (vooral geluid). Dus om geluid uit te voeren, moeten we een PCM -gegevens maken die naar de geluidschip worden gestuurd en worden afgespeeld via DMA + DAC . Om dit te doen worden meestal 2 cirkelvormige of veel kleine lineaire buffers gebruikt. Om glitch-loze geluiden te produceren, moeten de buffers groot genoeg zijn. In Windows heb ik bijvoorbeeld de laatste keer dat ik WAVEOUT controleerde, minstens 20-80 ms nodig. DirectSound nodig >400 ms

Nu als het geëmuleerde programma zich aanpast geluidsuitvoer zal het alleen worden uitgevoerd nadat het reeds opgevraagde geluid is afgespeeld.

Hetzelfde geldt voor I / O-invoer op sommige platforms, dus de vertragingen tellen op.

Wanneer u FPGA dan heb je directe toegang tot de geluidsuitvoer zonder enige buffering. Hetzelfde geldt voor invoer.

Maar game invoerwachttijd (toetsenbord, joystick) heeft meestal niets te maken met de latentie van het hostsysteem . De gebruikelijke oorzaak is dat de meeste emulators kloktics gebruiken om geëmuleerde snelheden te behouden. Dus simuleren ze de CPU of wat dan ook en eenmaal het gewenste aantal gesimuleerde klokken bereikt per keer dat ze slapen tot de volgende timer wordt uitgegeven of wat dan ook. Hoe sneller de hostcomputer, hoe minder tijd het nodig heeft om te emuleren, vandaar dat de simulatie meestal niet reageert.

Laten we bijvoorbeeld aannemen dat onze simulatie 100x sneller kan werken dan de oorspronkelijke snelheid van de geëmuleerde computer. Dat betekent dat slechts 1% van de tijd dat de simulatie iets doet en rust slechts Sleep() is. Tijdens de slaap kan de emulatie nergens op reageren. Het kan dus toetsaanslagen missen, klikken afvuren enz. Om te verhelpen dat sommige emulators opnieuw bufferen kunnen gebruiken, wat leidt tot de latentie in plaats van invoer te negeren. Er zijn ook verschillende stijlen om de tijd te beheersen die dit probleem volledig wegnemen. Zie voor meer informatie over dit onderwerp:

• Vraag over de nauwkeurigheid van cyclustelling bij het emuleren van een CPU

Vintage NTSC-machines (en CRT Macs, enz.) kunnen hun grafische uitvoer veranderen tijdens het vernieuwen van het CRT-scherm (gedeeltelijk langs het verticale raster), waardoor het beeld wordt verscheurd als reactie op realtime invoer.

Emulators die niet-CRT-monitoren gebruiken, kunnen dat niet in realtime doen en kunnen alleen een gescheurd raster vervalsen in de volgende frame of veld.

En de enige manier om te testen of een emulatie daarin juist is, is te vergelijken met echte (ground truth) vintage hardware. Kijk of er ongedocumenteerde verborgen logische vallen (defusie, enz.) Of analoge layout-bugs zijn onder de verschillende ASIC-chiplagen.

Opmerkingen

• _ " .. kan alleen nep zijn … " _Waar is het verschil? Is het niet ' een emulatie die helemaal draait om het vervalsen van het hele ding?
• Niet op een niet-CRT-beeldscherm. Een LCD (et.al.) wordt ' niet vernieuwd in 2 geïnterlinieerde velden van 30 frames, waar afwisselende lijnen en de boven- en onderkant van een venster op verschillende tijdstippen verschijnen, meer dan 10 mS uit elkaar in realtime. Misschien is een FPGA die een oude CRT-monitor voedt nauwkeuriger dan een emulator.
• Niets houdt emulatorsoftware tegen om hetzelfde te doen. en sommige ook. 60 Hz-schermen zijn inmiddels standaard, waardoor dezelfde flikkering als een CRT kan worden overgedragen. Hier is geen op FPGA gebaseerde software of een CRT nodig.