Mitkä ovat retrolaitteiston käytön edut / haitat verrattuna FPGA-emulointiin vs. ohjelmistojen emulointiin? [suljettu]

Esipuhe: Kysymys saumaa kysyä mielipiteitä, koska mielipide on, jos joku hyväksyy emulaation, ei väliä onko CPU: n vai FPGA: n ohjelmisto, sama kuin oikea vai ei.

Kysy itseltäsi, ajaa modernilla tekniikalla varustettua autoa, jota voi näyttää kuten SSK sama kuin ajaa todellista asiaa? Haluatko ajaa 1950-luvun BMW: llä kaikilla äänillä, hajuilla ja tärinällä (ja kaikilla tarvittavilla leikkauksilla, jotka ovat tarpeen sen jatkamiseksi) tai vuoden 2020 sähköpyörällä, joka on valmistettu samalta, joka antaa sinulle klassisen äänen iPodin rakennuksesta ?

Vaeltelen, mitä eroja on todellisen laitteiston, FPGA-pohjaisten laitteistoemulaattorien, kuten MiSTer, ja suuren määrän ohjelmistojen välillä emulaattorit erilaisille järjestelmille, jotka toimivat nykyaikaisilla Windows-, MacOS- ja Linux-tietokoneilla.

Jos olet vain käyttäjä, olet vakuuttunut modernin näppäimistön ja modernin hiiren käytöstä käsittelemällä jotakin kuvaa, joka näyttää 640 x 400, 4k-näytölläsi, tarvitset vain ohjelmiston. Jo FPGA-versio on ylenmääräinen, koska se käyttää samoja moderneja laitteita.

Toisaalta , jos kuvankäsittely ei riitä, mutta haluat tuntea iso Atari-hiiri, heikko Amiga-näppäimistö tai iso C64-joystick, joissa kaikissa on todellinen CRT-häikäisy, niin ei ole muuta tapaa saada todellinen asia.

Mielestäni tuli yksi asia, että sekä ohjelmisto- että laitteistoemulaattorit eivät voineet olla riittävän tarkkoja

Nyt he ovat. jokaisessa yksityiskohdassa. Nykyaikainen laitteisto on riittävän nopea sallimaan HLL-ohjelmistojen tarkan ajoituksen saamiseksi. Varsinkin kun kaikki sisään- ja ulostulot on joka tapauksessa jäljitelty, yhdistetty nykyaikaisiin laitteisiin.

Mutta tämä näyttää minusta jotain toteutuksen laadusta riippuen, joka voi vaihtelevat eri emulaattorien välillä ja parantuvat ajan myötä virheenkorjauksen takia, mutta eivät ole peruskysymys.

Laiska ohjelmointi ja ylläpito ei mitätöi lähestymistapaa. Kaikessa tarkoituksessa, lukuun ottamatta laitteiden todellisia käsiä, siinä ei ole eroa.

Kuulen myös ohjelmistoemulaattoreiden latenssiongelmasta, mutta olen ”Olen vähän yllättynyt siitä, että jotain tällaista voi todella tuntea tietokoneella, joka on todennäköisesti miljoonia kertoja nopeampi kuin jäljitelty kone.

Ehkä sata kertaa, pidä mielessä, että useimmat pääkomponentit eivät ole saaneet niin paljon nopeammin – ja suurimman osan laitteet ja tietotarpeet ovat syöneet suurimman osan siitä.

Latenssiongelma on asia, joka on ollut olemassa siitä lähtien kuin aina. Aina on joitain ilmoituksia siitä, että he näkevät / tuntevat eron. Vaikka tämä voi olla totta muutamissa, erittäin omistautuneissa tilanteissa, se on roskaa suurimman osan ajasta. Muutaman mikrosekunnin tuntemuksen vaatiminen, kun joystickin jo testaaminen voi maksaa enemmän, on yksinkertaisesti fantasiaa.

Onko todellakin teknistä syytä suosia todellista laitteisto- tai FPGA-pohjaista emulointia vs. ohjelmistomulaatiota?

Mikä on tekninen syy Sinulle termi ei sinänsä ole selvä, kun verrataan täydellisiä toteutuksia.

tai tämä on vain nostalgia, jonka aiheuttaa halu täyttää kuin sinä ovat todella palanneet 80 ”tai 90” s: een?

Oletko koskaan istunut jonkin vanhan koneen edessä? On yllättävää, kuinka erilaiset näppäimistöt tuntevat lähtevänsä nykyisistä standardoiduista laitteista.

Ja sitten on tietysti laitteisto-oikaisu – ei ole todellista hauskaa emulaattoreiden kanssa, koska tässä käyttöliittymän lisääminen on vain muutaman rivin lisääminen. koodi – tai vain configurati joissakin tapauksissa. Ei asettelua, ei syövytystä, ei juottamista eikä varsinkaan kiroamista ja korjaamista, ennen kuin se toimii.

Haluan selventää kysymyksessä mainittua termiä ”FPGA-emulointi”.

Ensinnäkin tietysti on olemassa sellainen asia kuin ohjelmistojen emulointi. Otetaan esimerkkinä eräät (enemmän tai vähemmän) tarkat ohjelmistojen emulaattorit 6502-prosessorista . He yrittävät jäljitellä todellisen suorittimen kaikkia ulkoisia artefakteja, kuten jaksojen lukumäärä kutakin komentoa kohti, muistihakemistojen osoitteet ja jopa ”sisäinen tila” (pikemminkin vain ohjelmistolle näkyvien rekisterien tila). Siinä ei kuitenkaan ole mitään samanlaista kuin todellisessa suorittimessa, alusta alkaen se on puhdasta ohjelmistoa, ei laitteistolaitetta.

Kun todellisen 6502: n uusi ominaisuus löydetään (kuten uudet dokumentoimattomat opcodit tai liput tai suorituksen yksityiskohdat) ), se on lisätty ohjelmistoemulaattoriin, kuten ”toinen toteutettava ominaisuus”. Ohjelmiston emulaattorissa ei tule esiin mitään todellisen ominaisuuden ominaisuuksia, jos ne eivät ole toteuttajan tuntemia.

Katsotaanpa sitten 6502-yhteensopivia HDL-ytimiä.Ne edustavat nyt todellista digitaalista logiikkalaitetta – tai sen mallia (siinä tapauksessa, että HDL on simuloitu, ei toteutettu todellisessa laitteistossa, kuten FPGA tai ASIC). Heillä on nyt todellinen flipflop (tai salpa) tallennustila CPU-rekistereille, he voivat toteuttaa todellisia CPU-väyläsignaaleja ja jopa laittaa retro-tietokoneeseen alkuperäisen 6502: n sijaan. Silti ne tehdään (enemmän tai vähemmän) ”tyhjästä”, CPU: n eritelmien kanssa, jotka on tarkoitus korvata, ei sen sisäistä rakennetta. Ja silti heiltä puuttuisi ominaisuuksissa, joita ei ole kuvattu kyseisissä spesifikaatioissa, jotka ovat todellisessa retro-prosessorissa, mutta joita toteuttaja ei vielä tunne.

Toinen jälleenrakennuksen taso voisi olla HDL-muotoilu, joka on rakennettu seuraavalla tavalla:

1. todellinen retro-keskusyksikkö puretaan ja valokuvataan
2. sitten netlist- ja transistoritason kaaviot luodaan uudelleen (joko käsin tai joillakin enemmän tai vähemmän automatisoiduilla työkaluilla)
3. netlist muunnetaan porttitasokaavioiksi ja sitten HDL-kuvauksiksi, jotka puolestaan toteutetaan FPGA: ssa tai ASIC: ssä.

Toisin kuin aiemmat tapaukset, nyt melkein kaikki todellisen suorittimen ominaisuudet toteutetaan ”natiivisti”, koska tuloksena olevan HDL: n rakenne on enemmän tai vähemmän samanarvoinen todellisen rakenteen kanssa (loogisten porttien ja flipflopien tasolla).

Silti saattaa olla ongelmia, esimerkiksi 6502 on joitain ohjeita, jotka käyttäytyvät virheellisesti, ja minusta tuntuu, ettei tällaista käyttäytymistä esiinny HDL: ssä luonnollisesti.

Yleisesti ottaen olen sitä mieltä Kaiken ”käänteisen suunnittelijan, sitten HDL: n luomisen uudelleen” yläpuolella on itse asiassa emulointi , joko ohjelmistossa tai laitteistossa, kun taas jälkimmäinen tapa on ei .

Tarkastellaan toisin sanoen vanhan ohjelmiston säilyttämistä. Voisimme käyttää sitä nykyaikaisella laitteistolla, mutta jos sitä ei ole saatavana, ohjelmistoemulaattorit tulevat peliin, mutta vanha ohjelmistopala, jota he ovat tottuneet suorittamaan, on silti täsmälleen sama.

Nyt haluaisimme säilytä vanha laitteisto (CPU), mutta sen aito toteutus ei ole käytettävissä, joten luomme sen uudemmalla tekniikalla, mutta suorittimen logiikkarakenne pysyy täsmälleen samana.

Tarjoamaan vastauksen vain latenssikysymykseen emulaattorina:

Poikkeuksia on runsaasti, mutta yleissääntö 80-luvun alkuperäisestä laitteistosta 90-luvun alku on, että laitteisto pystyy havaitsemaan ohjauspaneelin ja näppäimistön syötemuutokset melkein heti niiden tapahtumisen jälkeen ja että kun video ja ääni lähetetään koneelta, se saavuttaa käyttäjän melkein välittömästi – esim. klassisen CRT-television kohdalla rasteri maalaus juuri nyt on melkein koneen reaaliaikainen lähtö.

Kun laitteisto on nyt, tulo kulkee yleensä es Bluetooth- tai USB-pino, jonka isäntä-käyttöjärjestelmä voi tarkastaa vain tietyllä aikavälillä, ja jos jotain on tapahtunut, se välittää sen eteenpäin kiinnostuneelle prosessille, joka voi tapahtua tai ei välttämättä heti tietystä ajastimesta riippuen.

Monet emulaattorit toteuttavat myös pääsilmukan, joka näyttää siltä, miten voit suunnitella pelin:

1. kerää kaikki viimeisimmät syötteet ja välitä ne jäljiteltyyn koneeseen;
2. ajaa kone kehystä varten;
3. maalaa seuraava kehys kehyksestä näkymättömään puskuriin;
4. jono, joka näytetään seuraavassa vsync: ssä ja lohkossa;
5. toista.

Kuvittele argumenttisi vuoksi, että nykyaikainen koneesi on erittäin nopea ja että vaiheet 2 ja 3 ovat välittömiä. Sitten:

• keskimäärin puolet kehyksen tuloviiveestä sekä mitä tahansa Bluetooth / USB-signalointia ja lisättyä käyttöjärjestelmää – kaikki tulot, jotka tapahtuvat heti, kun kehyksen yläosaa ei lähetetä eteenpäin seuraavan loppuun asti kaikki, jotka tapahtuvat lopussa, ilmoitetaan melkein oikeaan aikaan, ja niiden välinen latenssialue on lineaarinen, joten keskiarvo on puolivälissä; ja
• siellä on kiinteä ylimääräinen kehysviive, koska lähetät kehyksen esitystä varten seuraavassa vsync: ssä ja odotat sitten, kunnes on aika näyttää.

Joten tällä yksinkertaisella silmukalla, ihanteellisella laitteistolla, keskimäärin viive jonkin painikkeen ja näytön reagoinnin välillä on noin 1,5 kehystä enemmän kuin todellinen laitteisto. Ja tämä on vain, jos isäntä- ja emuloidut koneet käyvät samalla kehysnopeudella .

Puristit väittävät, että jotkut alkuperäiset pelit on sovitettu niin hienosäätöisesti, kun sopiva tuntimäärä päiviä on testattu ja muutettu päivään, että 1,5 kehystä asettaa heidät epäedulliseen asemaan, jonka he voivat havaita.

FPGA: t ovat yleensä * emulointeja riippumatta siitä, miten ne myydään, koska ne ovat yleensä henkilö, joka toteuttaa spesifikaatiota korkean tason laitteistokuvauskielellä. Mutta he pyrkivät jättämään pois niin suuren osan viiveestä kuin mahdollista – hyvälaatuinen jättää kokonaan pois videopuskurin, suorittaa muun järjestelmän reaaliajassa ja syöttää sisäänmenoa pienellä viiveellä.

* pätevyys lisätty alla olevan @lvd: n antaman korjauksen mukaisesti. Katso hänen vastauksestaan lisää värejä.

Suurinta osaa ohjelmisto-ohjelmisto-ongelmista ei tietenkään ole vaikea korjata:

• eteenpäin syötetään useammin;
• älä Käynnistä vsync käynnistää uusi lähtö vsync: lle; ja
• älä käytä kaksoispuskuria.

Äärimmäisissä osissa voit jopa kilpailla rasterilla samanlaista lähtöviivettä kuin FPGA: lla – jos sinulla on jo korkea -taajuussilmukka usein syötettäväksi, ja jos peruslaitteisto tukee minkäänlaista lähtöä, joka voi aiheuttaa näytön repeämisen, sinulla on työkalut.

Valitettavasti emulaattorit eivät yleensä käytä tällaisia lähestymistapoja menneisyydessä, varsinkin ennen kuin latenssista tuli niin laajasti keskusteltu aihe, ja jotain negatiivista kuvaa on juuttunut.

Kommentit

• FPGA ei ole aina emulointi, ainakin " -tekstisi mukaan henkilö, joka täydentää spesifikaatiota korkean tason laitteistokielellä "
• @lvd vastauksen parantamiseksi, voitko olla tarkempi? Olen ' tietoinen yhdestä kokeesta, jossa käytettiin VisualChipsin avulla todellisesta (jos muisti ei palvele) nettilistaa. ) TIA, mutta vähän sen ulkopuolella. EDIT: ei, odota, näen, että ' olet lähettänyt erillisen vastauksen. Kiitos!

Muut HW vs SW -piirteet on käsitelty muissa täällä olevissa viesteissä, joten aion älä koske heihin. Sen sijaan haluaisin selittää LATENCY -kysymyksen omasta näkökulmastani sekä kokemuksen, jonka hankin koodaamalla emulaattoreitani eri alustoille …

SW-emulaattorin tekeminen nykyaikaisissa koneissa on viivästyskysymyksistä paljon vaikeampaa kuin se oli suorien I / O-yhteysaikojen aikana. Kotitietokoneita ja pelikonsoleita varten meidän on simuloitava / jäljiteltävä ääni, visuaalinen ulostulo ja käyttäjän panos mahdollisimman tarkasti. Suurin ongelma on äänessä. Tämä johtuu siitä, että kuulomme on paljon paljon parempi kuin mikään muu aistimme, ja me voimme tuntea / kuulla eron, jos ääni on pois päältä jopa muutamalla ms tai Hz. Jos näyttö on pois päältä 1 tai 2 kehyksellä, emme näe eroa. Myös jos syötettä viivästytetään vähän, sen ok (useimmille ihmisille).

Nykyaikaisessa konearkkitehtuurissa kaikki on puskuroitu (erityisesti ääni). Joten äänen tuottamiseksi meidän on luotava PCM data, joka lähetetään äänisirulle ja soitetaan DMA + DAC . Tätä varten käytetään yleensä kahta pyöreää tai monia pieniä lineaarisia puskureita. Nyt puskurien on oltava riittävän suuria tuottamaan häiriöttömiä ääniä. Esimerkiksi Windowsissa viime kerralla tarkistan WAVEOUT tarvitsee vähintään 20-80 ms. DirectSound need >400 ms

Nyt, jos jäljitelty ohjelma mukautuu äänentoisto se toistetaan vasta sen jälkeen, kun jo pyydetty ääni on toistettu.

Sama koskee I / O-tuloa joillakin alustoilla, joten viiveet kasvavat.

Kun käytät FPGA silloin sinulla on suora pääsy äänilähtöön ilman puskurointia. Sama koskee syöttöä.

Pelin syötteen viiveellä (näppäimistö, ohjaussauva) ei kuitenkaan yleensä ole mitään tekemistä isäntäjärjestelmän viiveen kanssa . Tyypillinen syy on se, että suurin osa emulaattoreista käyttää -kellotikkuja emuloitujen nopeuksien ylläpitämiseen. Joten he simuloivat prosessoria tai mitä tahansa ja kun he ovat saavuttaneet halutun määrän simuloituja kelloja nukkuessasi seuraavaan ajastimeen tai mihin tahansa. Mitä nopeammin isäntätietokone, sitä lyhyempi aika sen jäljittelemiseen tarvitaan, joten simulaatio ei reagoi suurimmaksi osaksi reaaliaikaa.

Oletetaan esimerkiksi, että simulointimme voi toimia 100 kertaa nopeammin kuin jäljitetyn tietokoneen alkuperäinen nopeus. Tämä tarkoittaa vain 1% ajasta, jolloin simulaatio tekee jotain ja lepo on vain Sleep(). Unen aikana emulaatio ei voi vastata mihinkään. Joten se voi jättää väliin näppäinpainallukset, napsautukset jne. … Sen korjaamiseksi, että jotkut emulaattorit saattavat käyttää puskurointia uudelleen, mikä johtaa latenssiin syötön ohittamisen sijaan. Ajan hallitsemisessa on myös erilainen tyyli, joka poistaa tämän ongelman kokonaan. Lisätietoja aiheesta:

• Kysymys jaksojen laskennan tarkkuudesta suoritinta jäljitettäessä

Vuosikerta NTSC-koneet (ja CRT-Macit jne.) voivat muuttaa grafiikkalähtöään CRT-näytön päivityksen keskellä (osittain) pystysuuntaista rasteria alaspäin), repäisemällä kuvaa reagoimalla reaaliaikaiseen syötteeseen.

Muita kuin CRT-näyttöjä käyttävät emulaattorit eivät voi tehdä sitä reaaliajassa, ja voivat vain väärentää repeytyneen rasterin seuraavassa kehys tai kenttä.

Ja ainoa tapa testata, onko emulointi oikein siinä verrata todelliseen (perustotuuden) vintage-laitteistoon. Katso, onko ASIC-sirukerrosten alla mitään dokumentoimattomia piilotettuja logiikkalukkoa (defuusio jne.) Tai analogisia asetteluvikoja.

Kommentit

• _ " .. voi vain väärentää … " _Onko ero? Eikö ' ole emulaatio, joka koskee koko tuotteen väärentämistä?
• Ei muulla kuin CRT-näytöllä. LCD (et.al.) ei päivity ' t kahdessa lomitetussa 30 kehyksen kentässä, joissa vuorotellen viivat sekä ikkunan ylä- ja alaosa näkyvät eri aikoina, yli 10 mS reaaliajassa. Ehkä FPGA, joka syöttää vanhaa CRT-näyttöä, olisi tarkempi kuin emulaattori.
• Mikään ei pysäytä emulaattoriohjelmistoa tekemään samoin. Loppujen lopuksi 60 Hz: n näytöt ovat nyt vakiona, joten ne välittävät saman värinän kuin CRT. Ei tarvita FPGA-pohjaisia ohjelmistoja tai CRT: tä täällä.