Hvad er fordele / ulemper ved at bruge retro-hardware vs. FPGA-emulering versus software-emulering? [lukket]

Forord: Spørgsmålet sømmer sig for at bede om meninger, da det er en mening, hvis nogen accepterer en emulering, ligegyldigt om software på en CPU eller på en FPGA, som den samme som den rigtige ting eller ej.

Spørg dig selv, kører en moderne teknologibil pimped op for at se som en SSK det samme som at køre den rigtige ting? Ønsker du at køre på en BMW fra 1950erne med alle dens lyde, lugte og vibrationer (og alt det tinkering, der er nødvendigt for at holde det i gang) eller en elektrisk cykel i 2020, der er lavet til at ligne en, hvilket giver dig den klassiske lyd fra en indbygget iPod ?

Jeg vandrer, hvad er forskellen mellem at bruge en ægte hardware, FPGA-baserede hardwareemulatorer som MiSTer og den store mængde software emulatorer til forskellige systemer, der kører på moderne Windows-, MacOS- og Linux-computere.

Hvis du bare er bruger, overbevist om at bruge dit moderne tastatur og moderne mus håndtering af et billede, der ligner 640 x 400, på din 4k-skærm, så er software alt hvad du behøver. Allerede en FPGA-version vil være overdreven, da den bruger de samme moderne enheder.

På den anden side , hvis billeddannelse ikke er nok, men du vil føle den store Atari-mus, det wiggly Amiga-tastatur eller det store C64-joystick, alt sammen præsenteret med ægte CRT-blænding, så er der ingen anden måde at en rigtig ting.

En ting, der kom til mig, er, at både software- og hardwareemulatorer ikke kunne være præcise nok

Nu er de det. i hver eneste detalje. Moderne hardware er hurtig nok til at tillade brugen af HLL-software til at opnå cyklus nøjagtig timing. Især når all in og output emuleres alligevel, kortlagt til moderne enheder.

Men det ser ud til at være noget afhængigt af kvaliteten af implementeringen, som kan varierer mellem forskellige emulatorer og forbedres over tid på grund af fejlrettelse, men ikke som et grundlæggende problem.

Dovedannelse og vedligeholdelse ugyldiggør ikke fremgangsmåden. Til alle formål, undtagen ægte hands on hardware, er der ingen forskel.

Jeg hører også om latensproblemet med softwareemulatorerne, men jeg “lidt overrasket over, at noget som dette virkelig kan mærkes på en computer, som sandsynligvis er millioner gange hurtigere end den emulerede maskine.

Måske hundrede gange, hvis overhovedet. Husk, at de fleste hovedkomponenter ikke er kommet så meget hurtigere – og det meste er spist op af enheder i større størrelse og behov for data.

Latency-problemet er noget, der har eksisteret siden som altid. Der vil altid være nogle, der siger, at de kan se / føle forskellen. Selvom dette kan være tilfældet i nogle få, meget dedikerede situationer, er det skrald det meste af tiden. At hævde at føle et par mikrosekunder, når det allerede er muligt at teste et joystick, er simpelthen fantasi.

Er der virkelig en teknisk grund til at foretrække ægte hardware eller FPGA-baseret emulering i forhold til softwareemulering

Hvad udgør en teknisk årsag for dig? I sig selv er udtrykket ikke klart, når man sammenligner komplette forskellige implementeringer.

eller dette er bare en nostalgi-ting, der skyldes ønske om at fylde som dig er virkelig tilbage i 80erne eller 90erne?

Har du nogensinde siddet foran en af de gamle maskiner? Det er overraskende, hvordan forskellige tastaturer føles, når man forlader dagens standardudstyr.

Og så er der selvfølgelig hardware-tinkering – ikke rigtig sjovt med emulatorer, da tilføjelse af en grænseflade kun tilføjer et par linjer med kode – eller bare konfigurere tændt i nogle tilfælde. Intet layout, ikke ætsning, ingen lodning og især ingen forbandelse og patch, indtil det fungerer.

Jeg vil gerne afklar “FPGA-emulering”, der er nævnt i spørgsmålet.

Først er der selvfølgelig sådan noget som softwareemulering. Lad os tage et eksempel på nogle (mere eller mindre) nøjagtige softwareemulatorer til 6502 CPU . De forsøger at efterligne alle eksterne artefakter fra den virkelige CPU, såsom antal cyklusser pr. Kommando, adresser på hukommelsesadgangene og endda “intern tilstand” (snarere kun tilstanden til softwaresynlige registre). Alligevel har det intet ens med den rigtige CPU, startende fra det punkt er det rent softwaremateriale, ikke hardwareenhed.

Når en ny funktion i real 6502 opdages (som nye udokumenterede opkoder eller flag eller udførelsesdetaljer ), indsættes den i softwareemulatoren som “en anden funktion, der skal implementeres”. Ingen funktioner i den ægte vare vil emegre i softwareemulatoren, hvis de er ukendte for implementøren.

Lad os så se på 6502-kompatible HDL-kerner.De repræsenterer nu faktisk en ægte digital logisk enhed – eller en model af det (i tilfælde af at HDL er simuleret, ikke implementeret i den rigtige hardware som FPGA eller ASIC). De har nu ægte flipflop (eller latch) -lagring til CPU-registre, de kunne implementere ægte CPU-bussignaler og endda blive indsat i retro-computeren i stedet for den originale 6502. Alligevel er de lavet (mere eller mindre) “fra bunden”, med specifikationerne for CPUen, de er beregnet til at erstatte, ikke dens interne struktur. Og alligevel mangler de funktioner, der ikke er beskrevet i disse specifikationer, der findes i ægte retro-CPU, men som endnu ikke er kendt for implementøren.

Et andet niveau i genopbygningen kunne være HDL-designet bygget på følgende måde:

1. ægte retro-CPU afkobles og fotograferes
2. så genskabes netlist- og transistor-niveau-skemaer (enten manuelt eller med nogle mere eller mindre automatiserede værktøjer)
3. netlist konverteres til gate-niveau-skemaer og derefter til HDL-beskrivelse, der igen implementeres i FPGA eller ASIC.

I modsætning til tidligere sager er nu næsten alle funktioner i den virkelige CPU blive implementeret “indbygget”, fordi strukturen af den resulterende HDL er mere eller mindre ækvivalent med strukturen af den virkelige ting (ved logiske porte og flipflops-niveau).

Stadig kunne der være problemer, for eksempel 6502 har nogle instruktioner, der opfører sig uretmæssigt, og jeg har lyst til, at sådan opførsel ikke ville komme frem i HDL naturligt.

Generelt set overvejede jeg alt over “reverse engineer, derefter genskabe HDL” er faktisk en emulering enten i software eller hardware, mens den sidstnævnte måde er ikke .

Med andre ord, lad os overveje at bevare den gamle software. Vi kunne køre det på moderne hardware, men hvis det ikke er tilgængeligt, kommer softwareemulatorer til spil, men det gamle softwarestykke, de bruges til at udføre, er stadig nøjagtigt det samme.

Nu vil vi gerne bevar gammelt stykke hardware (CPU), men den autentiske implementering er ikke tilgængelig, så vi genskaber det ved hjælp af nyere teknologi, men logikstrukturen i CPUen forbliver nøjagtig den samme.

At kun tilbyde et svar på latensspørgsmålet, som emulatorforfatter:

Undtagelser findes der, men den generelle regel om original hardware fra “80erne og ind de tidlige 90ere er, at ændringer af joypad og tastaturindgang kan detekteres af hardware næsten umiddelbart efter, at de sker, og at når video og lyd udsendes fra maskinen, når den næsten øjeblikkeligt til brugeren – f.eks. for et klassisk CRT-fjernsynsniveau maling lige nu er næsten maskinens live output.

Med hardware nu traver input generelt er en Bluetooth- eller USB-stak, som kun kan inspiceres med et bestemt interval af værts-OSet, og hvis der er sket noget, kommunikerer det videre til den interesserede proces, som måske eller måske ikke sker med det samme afhængigt af den specifikke planlægger.

Mange emulatorer implementerer også en hovedsløjfe, der ser ud til, hvordan du kan designe et spil:

1. indsamle alle nyeste input og videresende det til den emulerede maskine;
2. kør maskinen efter en ramme;
3. mal den næste outputramme til en usynlig buffer;
4. kø, der vises til næste vsync og blok;
5. gentag.

For argumentets skyld, forestil dig, at din moderne maskine er meget hurtig, og at trin 2 og 3 er øjeblikkelige. Derefter:

• der er en gennemsnitlig halv ramme af inputlatens plus uanset Bluetooth / USB-signalering og OS tilføjet – ethvert input, der opstår lige efter toppen af en ramme, bliver ikke videresendt indtil begyndelsen af det næste vil ethvert, der sker lige ved slutningen, blive kommunikeret næsten på det rigtige tidspunkt, og intervallet af latenstider imellem er lineært, så gennemsnittet er halvvejs imellem; og
• der er en fast yderligere ramme med outputforsinkelse, fordi du sender en ramme til præsentation ved næste vsync og derefter venter, indtil det er tid til at blive vist.

Så med den enkle sløjfe, på ideel hardware, er forsinkelsen mellem dig at trykke på noget og skærmen, der reagerer, i gennemsnit ca. 1,5 billeder mere end ægte hardware. Og det er kun hvis værts- og emulerede maskiner kører med samme billedhastighed .

Purister hævder, at nogle originale spil er så finjusteret efter det passende antal timer, der er testet og justeret tilbage på dagen, at 1,5 billeder sætter dem i en ulempe, som de kan opdage.

FPGAer er som regel * -emulering, uanset hvordan de sælges, fordi de normalt er en person, der genimplementerer en specifikation på et hardwebbeskrivelsessprog på højt niveau. Men de forsøger at udelade så meget af den ventetid som muligt – en god kvalitet vil udelade videobufferen fuldstændigt, køre resten af systemet i realtid og skubbe input ind med minimal forsinkelse.

* kvalifikation tilføjet i henhold til korrektionen leveret af @lvd nedenfor. Se hans svar for mere farve.

Selvfølgelig er det ikke svært at løse de fleste softwareproblemer i software:

• videresend input oftere;
• don t brug vsync til at udløse nyt output til vsync; og
• brug ikke en dobbeltbuffer.

I extremis kan du endda køre rasteren om lignende outputlatens til en FPGA – hvis du allerede har en høj -frekvenssløjfe til hyppig input, og hvis basehardwaren understøtter nogen form for output, der kan producere skærmrivning, har du værktøjerne.

Desværre blev sådanne tilgange normalt ikke taget af emulatorer i fortid, især før latens blev et så vidt diskuteret emne, og noget af et negativt billede sidder fast.

Kommentarer

• FPGA er ikke altid en emulering, i det mindste i dine vilkår for " en person, der genimplementerer en specifikation på et harddiskbeskrivelsessprog på højt niveau "
• @lvd med det formål at forbedre svaret, kan du være mere specifik? Jeg ' er opmærksom på et eksperiment, der brugte en netliste, der blev ekstraheret af VisualChips fra en reel (hvis hukommelsen tjener ) TIA, men lidt ud over det. EDIT: nej, Vent, jeg ser dig ' har sendt et separat svar. Tak!

mange aspekter af HW vs SW er blevet dækket af andre indlæg her, så jeg vil ikke røre ved dem. I stedet vil jeg gerne forklare LATENCY fra mit synspunkt sammen med erfaring, jeg erhvervede under kodning af mine emulatorer til forskellige platforme …

At lave SW-emulator på moderne maskiner er meget sværere i forhold til latenstid, end det var tilbage i de direkte I / O-adgangstider. For hjemmecomputere og spilkonsoller er vi nødt til at simulere / emulere lyd, visuel output og brugerinput så præcist som vi kan. Det største problem er med lyd. Det er fordi vores hørelse er meget meget bedre end nogen anden af vores sanser, og vi kan mærke / høre forskellen, hvis lyden er slukket med få ms eller Hz. Hvis skærmen er slukket med 1 eller 2 rammer, kan vi ikke se forskellen. Også hvis input er forsinket en lille smule, er det ok (for de fleste mennesker).

I moderne maskinarkitektur er alt bufret (især lyd). Så for at kunne udsende lyd skal vi oprette en PCM data, der sendes til lydchippen og afspilles gennem DMA + DAC . For at gøre dette bruges normalt 2 cirkulære eller mange små lineære buffere. Nu for at producere glitchfri lyde skal bufferne være store nok. For eksempel i Windows sidste gang jeg tjekker WAVEOUT har brug for mindst 20-80 ms. DirectSound har brug for >400 ms

Nu hvis det emulerede program justeres lydoutput udsendes kun, efter at den allerede forespurgte lyd er afspillet.

Det samme gælder for I / O-input på nogle platforme, så forsinkelserne tilføjes.

Når du bruger FPGA så har du direkte adgang til lydoutputtet uden buffering. Det samme gælder for input.

Dog har spil input-latenstid (tastatur, joystick) normalt intet at gøre med værtssystemets latency . Den sædvanlige årsag er, at størstedelen af emulatorerne bruger ur-tics til at opretholde emulerede hastigheder. Så de simulerer CPUen eller hvad som helst og når en gang det ønskede antal simulerede ure pr. Gang de sover, indtil næste timer udstedes eller hvad som helst. Jo hurtigere værtscomputeren er, jo mindre tid har den brug for at efterligne, og derfor reagerer simuleringen ikke det meste af realtid.

Lad os for eksempel antage, at vores simulation kan køre 100 gange hurtigere end den oprindelige hastighed på den emulerede computer. Det betyder kun 1% af tiden, at simuleringen gør noget, og hvile er bare Sleep(). Under søvn kan emuleringen ikke reagere på noget. Så det kan gå glip af nøgleslag, ildklik osv … For at afhjælpe, at nogle emulatorer muligvis bruger buffering igen, hvilket fører til latenstiden i stedet for at ignorere input. Der er også forskellige former for kontrol af tid, der fuldstændigt fjerner dette problem. For mere information om dette emne se:

• Spørgsmål om nøjagtighed ved cykeltælling ved emulering af en CPU

Vintage NTSC-maskiner (og CRT Macer osv.) kan ændre deres grafikoutput midt i CRT-skærmopdatering (delvist) nedad i den lodrette raster) og dermed rive billedet som reaktion på input i realtid.

Emulatorer, der bruger ikke-CRT-skærme, kan ikke gøre det i realtid og kan kun falske en revet raster den næste ramme eller felt.

Og den eneste måde at teste, om en emulering er nøjagtig i forhold til den, sammenlignet med faktisk (jordens sandhed) vintage hardware. Se om der er udokumenterede skjulte logiske fælder (defusion osv.) Eller analoge layoutfejl under de forskellige ASIC-chiplag.

Kommentarer

• _ " .. kan kun falske … " _ Var forskellen? Er ' ikke en emulering, der handler om at falske det hele?
• Ikke på et ikke-CRT-display. En LCD (et.al.) opdateres ikke ' i 2 sammenflettede felter på 30 billeder, hvor skiftende linjer og toppen og bunden af et vindue vises på forskellige tidspunkter over 10 mS fra hinanden i realtid. Måske ville en FPGA, der fodrer en gammel CRT-skærm, være mere præcis end en emulator.
• Intet stopper emulatorsoftware for at gøre det samme. og nogle gør. Når alt kommer til alt er 60 Hz-skærme standard nu, hvilket gør det muligt at overføre den samme flimmer som en CRT. Intet behov for FPGA-baseret software eller en CRT her.