Stengt . Dette spørsmålet er meningsbasert . Det aksepteres for øyeblikket ikke svar.

Kommentarer

  • Er det ikke ' t som bare ber om meninger? Tross alt er alle måter nå i det vesentlige like i hva de kan produsere som brukeropplevelse.
  • For det må du definere hva du anser som en teknisk grunn. Det er ikke noe svar uten en klar definisjon hva som blir spurt.
  • @Raffzahn Utdrag fra et annet svar: " Programvareemulering kan fungere ganske bra, men vil være begrenset til grensesnitt med maskinvare emulatordesigneren vet om. En god FPGA-basert rekreasjon kan grensesnitt med nesten alle slags vintage-maskinvarer, inkludert enheter FPGA-designeren ikke vet noe om, samtidig som det gir bedre pålitelighet enn vintage-hardware. " Dette er et godt eksempel av teknisk grunn. Jeg tror ikke ' at " teknisk årsak " er uspesifisert. Det er alt som er objektivt sant snarere enn noen ' s egen oppfatning av virkeligheten som kan beskrives som " meninger ".
  • Bortsett fra at ' ikke er en teknisk grunn, men en underforstått brukssak, her for å legge til ' annen ' maskinvare. Siden dette alltid trenger en oppdatering (selv med den virkelige maskinvaren, er det ' heller ikke et problem spesifikt for emulering.
  • @Raffzahn: Når du bruker en FPGA-enhet som nøyaktig etterligner den opprinnelige oppførselen på maskinvarenivå, vil ingen oppdatering være nødvendig for å jobbe med maskinvare som FPGA-programmereren ikke vet noe om.

Svar

En fordel som FPGA-emulatorer generelt deler med vintage-maskinvare, er muligheten til å bruke enheter som samhandler med maskinvaren på måter som er veldig avhengig av tid. For eksempel hvis man har en spillkassett for NES som utløser et avbrudd hver gang den første datalinjen for en bestemt sprite blir hentet, vil en konsoll som leser ut innholdet i en kassett og etterligner den bare kunne spille spillet riktig hvis den kunne gjenkjenne hva patronen gjorde med avbruddslinjen.

FPGA-basert maskinvare vil vanligvis fungere så godt som, om ikke mer pålitelig enn, vintage hardware, men det er noen rare rare å huske på. Noen prototype-utvidelseskassetter for Atari 2600, for eksempel, stolte på det faktum at selv når NMOS 6502 prøver å trekke databussen høyt, er den ikke i stand til å prøve hardt nok til å enten overmanne en ekstern enhet som prøver å trekk linjen lavt, eller skad deg selv i forsøket. Merk at det motsatte ikke er sant: en NMOS-enhet som prøver å trekke en linje lavt mens en ekstern enhet trekker den høyt, kan skade seg selv i forsøket (RIP 2600jr). Hvis man kobler til et moderne rekreasjonssystem en NMOS-enhet som er avhengig av muligheten til å overdrive bussledninger, og systemet ikke begrenser høystrømstrømmen på disse ledningene, kan det skade den eksterne enheten. ikke vite i hvilken grad det faktisk ville være et problem, men siden alle enheter som er avhengige av slike teknikker sannsynligvis er sjeldne, ville det være veldig uheldig hvis de ble skadet.

Et annet potensielt problem er at vintage-elektronikk var ofte ganske tregt til å svare på signaler, noe som betydde at hvis en enhet veldig kort skulle sende ut et signal på en ledning, ville det sannsynligvis bli ignorert. Noen vintageelektronikk ville noen ganger sende korte feilimpulser hvis en kombinasjon av innganger endret seg mellom en tilstand der utgangen skulle være lav, og en annen tilstand der utgangen skulle være lav. Hvis en FPGA-rekreasjon ikke er designet for å ignorere slike pulser, kan de forårsake feil operasjon på den gjenskapte maskinvaren, selv om de ikke hadde forårsaket noe problem på originalen.

Personlig tror jeg FPGAer er den beste måten. av gjenskape systemer. Vintage-maskinvare er kult, men påliteligheten er ofte problematisk. Programvareemulering kan fungere ganske bra, men vil være begrenset til grensesnitt med maskinvare som emulatordesigneren vet om. En god FPGA-basert rekreasjon kan grensesnitt med nesten alle slags vintage hardware, inkludert enheter FPGA-designeren vet ingenting om , samtidig som den gir bedre pålitelighet enn vintage hardware.

Svar

Forord: Spørsmålet sømmer for å be om meninger, da det er mening hvis noen aksepterer en emulering, uansett om programvare på en CPU eller på en FPGA, som den samme som den virkelige tingen eller ikke.

Spør deg selv, kjører en moderne teknologibil pimped opp for å se som en SSK det samme som å kjøre den virkelige tingen? Ønsker du å kjøre en BMW fra 1950-tallet med alle lydene, luktene og vibrasjonene (og alt det flimring som trengs for å holde det i gang) eller en elektrisk elsykkel fra 2020 som er laget for å se ut som en, og gir deg den klassiske lyden fra en innebygd iPod ?

Jeg vandrer hva er forskjellene mellom å bruke en ekte maskinvare, FPGA-baserte maskinvareemulatorer som MiSTer og den store mengden programvare emulatorer for forskjellige systemer som kjører på moderne Windows-, MacOS- og Linux-datamaskiner.

Hvis du bare er en bruker, overbevist om å bruke ditt moderne tastatur og moderne mus håndtering av noe bilde, som ser ut som 640 x 400, på 4k-skjermen din, så er programvaren alt du trenger. Allerede en FPGA-versjon vil være overkill, siden den bruker de samme moderne enhetene.

På den annen side , hvis bildebehandling ikke er nok, men du vil kjenne på den store Atari-musen, det wiggly Amiga-tastaturet eller den store C64-joysticken, alt presentert med ekte CRT-gjenskinn, så er det ingen annen måte en virkelig ting.

En ting som kom til meg er at både programvare- og maskinvareemulatorer ikke kunne være presise nok

Nå er de det. i hver eneste detalj. Moderne maskinvare er rask nok til å tillate bruk av HLL-programvare for å oppnå nøyaktig timing. Spesielt når all inn og utgang emuleres uansett, kartlagt til moderne enheter.

Men dette virker for meg som noe avhengig av kvaliteten på implementeringen som kan varierer mellom forskjellige emulatorer og forbedrer seg over tid på grunn av feilretting, men ikke som et grunnleggende problem.

Lat programmering og vedlikehold ugyldiggjør ikke tilnærming. For alle formål, bortsett fra ekte maskinvare, er det ingen forskjell.

Jeg hører også om forsinkelsesproblemet med programvareemulatorene, men jeg «litt overrasket over at noe slikt virkelig kan kjennes på en datamaskin som sannsynligvis er millioner ganger raskere enn den emulerte maskinen.

Kanskje hundre ganger, hvis i det hele tatt. Husk at de fleste hovedkomponentene ikke har blitt så mye raskere – og det meste har blitt spist opp av større enheter og behov for data.

Latency-problemet er noe som har eksistert siden som alltid. Det vil alltid være noen som sier at de kan se / føle forskjellen. Selv om dette kan være sant i noen få, veldig dedikerte situasjoner, er det søppel det meste av tiden. Å hevde at du føler noen få mikrosekunder, når det å teste en joystick allerede kan koste mer, er det bare fantasy. >

Er det virkelig en teknisk grunn til å foretrekke ekte maskinvare eller FPGA-basert emulering kontra programvareemulering

Hva utgjør en teknisk årsak for deg? I seg selv er begrepet ikke klart når du sammenligner forskjellige implementeringer.

eller dette er bare en nostalgi ting, forårsaket av ønske om å fylle som deg er egentlig tilbake på 80-tallet eller 90-tallet?

Har du noen gang sittet foran en av de gamle maskinene? Det er overraskende hvordan forskjellige tastaturer føles når man forlater dagens standardutstyr.

Og så er det selvfølgelig maskinvaren som tinker – ikke veldig gøy med emulatorer, da det å legge til et grensesnitt bare legger til noen få linjer med kode – eller bare konfigurer på i noen tilfeller. Ingen layout, ikke etsning, ingen lodding og spesielt ingen forbannelse og lapping før den fungerer.

Svar

Jeg vil gjerne klargjøre «FPGA-emulering» som er nevnt i spørsmålet.

Først er det selvfølgelig noe som heter programvareemulering. La oss ta et eksempel på noen (mer eller mindre) eksakte programvareemulatorer av 6502 CPU . De prøver å etterligne alle eksterne gjenstander fra den virkelige CPUen, for eksempel antall sykluser per kommando, adressene til minnetilgangene og til og med «intern tilstand» (snarere bare tilstanden til programvaresynlige registre). Likevel har det ingenting likt med den virkelige CPU-en, fra det punktet er det ren programvare, ikke maskinvareenhet.

Når noen nye funksjoner i ekte 6502 blir oppdaget (som nye udokumenterte opkoder eller flagg eller utførelsesdetaljer) ), blir den satt inn i programvareemulatoren som «en annen funksjon å implementere». Ingen funksjoner av den virkelige tingen vil komme seg ut i programvareemulatoren, hvis de er ukjente for implementøren.

La oss se på 6502-kompatible HDL-kjerner.De representerer nå faktisk en ekte digital logisk enhet – eller en modell av det (i tilfelle HDL er simulert, ikke implementert i den virkelige maskinvaren som FPGA eller ASIC). De har nå ekte flipflop (eller latch) lagring for CPU-registerene, de kan implementere ekte CPU-bussignaler og til og med bli satt inn i retro-datamaskinen i stedet for originalen 6502. Likevel er de laget (mer eller mindre) «fra bunnen av», med spesifikasjonene til CPUen de er ment å erstatte, ikke dens interne struktur. Og likevel mangler de funksjoner som ikke er beskrevet i spesifikasjonene, som eksisterer i ekte retro-CPU, men som ennå ikke er ukjente for implementøren.

Et annet nivå av rekonstruksjonen kan være HDL-designet bygget på følgende måte:

  1. ekte retro-CPU blir avkoplet og fotografert
  2. så blir netlist- og transistornivåskjemaer gjenskapt (enten for hånd eller av noen mer eller mindre automatiserte verktøy)
  3. netlist konverteres til portnivåskjemaer og deretter til HDL-beskrivelse, som igjen er implementert i FPGA eller ASIC.

I motsetning til tidligere tilfeller, nå nesten alle funksjonene til den virkelige CPUen bli implementert «naturlig», fordi strukturen til den resulterende HDL er mer eller mindre ekvivalent med strukturen til den virkelige tingen (på logiske porter og flipflops-nivå).

Det kan fremdeles være problemer, for eksempel 6502 har noen instruksjoner som oppfører seg uberegnelig, og jeg føler at slik oppførsel ikke ville dukke opp i HDL naturlig.

Generelt sett vurderte jeg alt over «reverse engineer, then recreate HDL» er faktisk en emulering , enten i programvare eller maskinvare, mens sistnevnte måte er ikke .

La oss med andre ord vurdere bevaring av den gamle programvaren. Vi kan kjøre den på moderne maskinvare, men hvis den ikke er tilgjengelig, kommer programvareemulatorer til spill, men det gamle programvarestykket de brukes til å utføre er fortsatt nøyaktig det samme.

Nå vil vi bevare gammel maskinvare (CPU), men den autentiske implementeringen er utilgjengelig, så vi gjenskaper den ved hjelp av nyere teknologi, men logikkstrukturen til CPUen forblir nøyaktig den samme.

Svar

For å tilby svar på latensspørsmålet bare, som emulatorforfatter:

Unntak florerer, men den generelle regelen om original maskinvare fra 80-tallet og inn i tidlig på 90-tallet er at joypad- og tastaturinngangsendringer kan oppdages av maskinvare nesten umiddelbart etter at de har skjedd, og at når video og lyd sendes ut fra maskinen, når den brukeren nesten umiddelbart – for eksempel for en klassisk CRT-TV, nivået raster maling akkurat nå er nesten live-utgangen fra maskinen.

Med maskinvare nå krysser input vanligvis er en Bluetooth- eller USB-stabel, som bare kan inspiseres med et bestemt intervall av verts-operativsystemet, og hvis noe har skjedd, kommuniserer den videre til den interesserte prosessen, som kanskje eller ikke kan skje umiddelbart, avhengig av den spesifikke planleggeren. p>

Mange emulatorer implementerer også en hovedsløyfe som ser ut som hvordan du kan designe et spill:

  1. samle alle de nyeste inngangene og videresend den til den emulerte maskinen;
  2. kjør maskinen for en ramme;
  3. mal neste utgangsramme til en usynlig buffer;
  4. kø som vises til neste vsync og blokkering;
  5. gjenta.

For argumentets skyld, forestill deg at din moderne maskin er veldig rask og at trinn 2 og 3 er øyeblikkelige. Så:

  • det er en gjennomsnittlig halv ramme med inngangsforsinkelse pluss hva Bluetooth / USB-signalering og operativsystemet som er lagt til – enhver inngang som oppstår like etter at toppen av en ramme ikke blir videresendt. til begynnelsen av den neste, vil alt som skjer rett på slutten bli kommunisert nesten på riktig tidspunkt, og rekkevidden av ventetid i mellom er lineær, så gjennomsnittet er halvveis mellom; og
  • det er en fast tilleggsramme for utgangsforsinkelse fordi du legger ut en ramme for presentasjon ved neste vsync og deretter venter til det er på tide å vises.

Så med den enkle sløyfen, på ideell maskinvare, er forsinkelsen mellom å trykke på noe og skjermen som reagerer i gjennomsnitt ca. 1,5 bilder mer enn ekte maskinvare. Og det er bare hvis verts- og emulerte maskiner kjører med samme bildefrekvens. .

Purister hevder at noen originale spill er så finjustert, etter riktig antall timer med testing og justering tilbake på dagen, at 1,5 bilder gir dem en ulempe at de kan oppdage.

FPGA er vanligvis * emulering, uansett hvordan de selges, fordi de vanligvis er en person som implementerer en spesifikasjon på et høyt nivå språk for maskinvarebeskrivelse. Men de prøver å utelate så mye av den ventetiden som mulig – en god kvalitet vil utelate videobufferen helt, kjøre resten av systemet i sanntid og skyve inngangen inn med minimal forsinkelse.

* kvalifisering lagt til i henhold til rettelsen gitt av @lvd nedenfor. Se svaret hans for mer farge.

Det er selvfølgelig ikke vanskelig å fikse de fleste programvareproblemene i programvaren:

  • videresend input oftere;
  • don t bruk vsync for å utløse ny utgang til vsync; og
  • ikke bruk en dobbel buffer.

In extremis kan du til og med kjøre rasteren for lignende utgangsforsinkelse til en FPGA – hvis du allerede har en høy -frekvenssløyfe for hyppig inndata, og hvis basismaskinvaren støtter noen form for utdata som kan produsere skjermrivning, så har du verktøyene.

Dessverre ble slike tilnærminger vanligvis ikke tatt av emulatorer i fortid, spesielt før ventetid ble et så mye diskutert tema, og noe av et negativt bilde har sittet fast.

Kommentarer

  • FPGA er ikke alltid en emulering, i det minste når det gjelder " en person som reimplementerer en spesifikasjon på et høyt nivå språk for maskinvarebeskrivelse "
  • @lvd for å forbedre svaret, kan du være mer spesifikk? Jeg ' er klar over ett eksperiment som brukte en netliste hentet av VisualChips fra en ekte (hvis minnet tjener ) TIA, men litt utover det. EDIT: nei, vent, jeg ser deg ' har lagt ut et eget svar. Takk!

Svar

mange aspekter av HW vs SW har blitt dekket av andre innlegg her, så jeg vil ikke ta på dem. I stedet vil jeg forklare LATENCY fra mitt synspunkt sammen med erfaring jeg tilegnet meg under koding av emulatorene mine for forskjellige plattformer …

Å lage SW-emulator på moderne maskiner er mye vanskeligere fra latens enn det var tilbake i direkte I / O-tilgangstider. For hjemme-datamaskiner og spillkonsoller må vi simulere / etterligne lyd, visuell utgang og brukerinngang så presist vi kan. Det største problemet er med lyd. Det er fordi hørselen vår er mye mye bedre enn noen annen av våre sanser, og vi kan føle / høre forskjellen hvis lyden er slått av med noen få ms eller Hz. Hvis skjermen er av med 1 eller 2 rammer, kan vi ikke se forskjellen. Også hvis inngangen er forsinket en liten bit, er det ok (for de fleste mennesker).

I moderne maskinarkitektur er alt bufret (spesielt lyd). Så for å kunne sende lyd må vi lage en PCM data som sendes over til lydbrikken og spilles gjennom DMA + DAC . For å gjøre dette brukes vanligvis 2 sirkulære eller mange små lineære buffere. Nå for å produsere feilfri lyder, må bufferne være store nok. For eksempel på Windows forrige gang jeg sjekker WAVEOUT trenger minst 20-80 ms. DirectSound trenger >400 ms

Nå hvis emulert program justeres lydutgang, vil den bare sendes ut etter at den allerede forespurte lyden er spilt ut.

Det samme gjelder for I / O-inngang på noen plattformer, slik at forsinkelsene blir bedre.

Når du bruker FPGA så har du direkte tilgang til lydutgangen uten buffering. Det samme gjelder inngang.

Imidlertid har spill inngangsforsinkelse (tastatur, joystick) vanligvis ikke noe å gjøre med vertssystemets ventetid . Den vanlige årsaken er at flertallet av emulatorene bruker clock tics for å opprettholde emulerte hastigheter. Så de simulerer CPU eller hva som helst og når en gang ønsket antall simulerte klokker per gang de sover til neste tidtaker er gitt eller hva som helst. Jo raskere vertsdatamaskinen, jo mindre tid det trenger å etterligne, og simuleringen vil derfor ikke reagere mesteparten av sanntid.

La oss for eksempel anta at simuleringen vår kan kjøre 100 ganger raskere enn den opprinnelige hastigheten til den emulerte datamaskinen. Det betyr at bare 1% av tiden simuleringen gjør noe, og hvile er bare Sleep(). Under søvnen kan ikke emuleringen svare på noe. Så det kan gå glipp av tastetrykk, brannklikk osv … For å avhjelpe at noen emulatorer kan bruke buffering igjen, noe som fører til ventetid i stedet for å ignorere input. Det er også en annen måte å kontrollere tid på som fjerner dette problemet. For mer info om dette emnet, se:

Svar

Vintage NTSC-maskiner (og CRT-maskiner osv.) kan endre grafikkutgangen midt i CRT-skjermoppdateringen (delvis) nedover den vertikale rasteren), og dermed rive bildet som svar på sanntidsinndata.

Emulatorer som bruker ikke-CRT-skjermer, kan ikke gjøre det i sanntid, og kan bare falske et revet raster neste ramme eller felt.

Og den eneste måten å teste om en emulering er nøyaktig i forhold til den, sammenlignet med faktisk (jordens sannhet) vintage maskinvare. Se om det er noen udokumenterte skjulte logiske feller (defusjon osv.) Eller analoge layoutfeil under de forskjellige ASIC-brikkelagene.

Kommentarer

  • _ " .. kan bare falske … " _ Var forskjellen? Er ikke ' ikke en emulering som handler om å forfalske hele greia?
  • Ikke på en ikke-CRT-skjerm. En LCD (et.al.) oppdateres ikke ' i 2 sammenflettede felt med 30 bilder, hvor vekslende linjer og toppen og bunnen av et vindu vises på forskjellige tidspunkter, over 10 mS fra hverandre i sanntid. Kanskje en FPGA som mater en gammel CRT-skjerm ville være mer nøyaktig enn en emulator.
  • Ingenting stopper emulatorprogramvaren for å gjøre det samme. og noen gjør det. Tross alt er 60 Hz-skjermer standard nå, slik at de kan overføre samme flimmer som en CRT. Du trenger ikke FPGA-basert programvare eller CRT her.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *