Închis . Această întrebare este
bazată pe opinie . În prezent, nu acceptă răspunsuri.
Comentarii
Răspuns
Un avantaj pe care emulatoarele FPGA îl împărtășesc în general cu hardware-ul vintage este abilitatea de a utiliza dispozitive care interacționează cu hardware-ul în moduri care depind foarte mult de sincronizare. De exemplu, dacă unul are un cartuș de joc pentru NES care declanșează o întrerupere de fiecare dată când este preluată prima linie de date pentru un anumit sprite, o consolă care citește conținutul unui cartuș și apoi emulează că ar putea juca corect jocul doar dacă ar fi capabil să recunoască ceea ce cartușul făcea cu linia de întrerupere.
Hardware-ul bazat pe FPGA ar funcționa în general la fel de bine ca, dacă nu chiar mai mult fiabil decât hardware-ul vintage, dar există câteva ciudățenii ciudate de care să ții cont. Unele cartușe de expansiune prototip pentru Atari 2600, de exemplu, s-au bazat pe faptul că, chiar și atunci când NMOS 6502 încearcă să tragă magistrala de date la înălțime, este incapabil să încerce suficient de mult pentru a suprasolicita un dispozitiv extern care încearcă să trageți linia jos și nu vă deteriorați în încercare. Rețineți că inversul nu este adevărat: un dispozitiv NMOS care încearcă să tragă o linie în timp ce un dispozitiv extern îl trage în sus se poate deteriora singur în încercare (RIP 2600jr). Dacă cineva ar fi să conecteze la un sistem modern de recreere un dispozitiv NMOS care să se bazeze pe capacitatea de a suprasolicita firele autobuzului, iar sistemul nu „limitează curentul de acționare pe partea înaltă a acelor fire, ar putea deteriora dispozitivul extern. Nu știu în ce măsură ar fi de fapt o problemă, dar din moment ce orice dispozitiv care se bazează pe astfel de tehnici este probabil rar, ar fi foarte regretabil dacă ar fi fost deteriorate.
adesea destul de lent pentru a răspunde la semnale, ceea ce însemna că dacă un dispozitiv ar emite foarte scurt un semnal pe un fir, acesta ar fi probabil ignorat. Unele electronice de epocă ar produce uneori scurte impulsuri glitch dacă o combinație de intrări s-ar schimba între o stare în care ieșirea ar trebui să fie scăzută și o stare diferită în care ieșirea ar trebui să fie scăzută. Dacă o recreere FPGA nu este concepută pentru a ignora astfel de impulsuri, acestea pot provoca o funcționare eronată pe hardware-ul recreat, chiar dacă nu ar fi cauzat nicio problemă pe original.
Personal, cred că FPGA sunt cea mai bună cale de sisteme de recreere. Hardware-ul de epocă este grozav, dar fiabilitatea este adesea problematică. Emularea software-ului poate funcționa destul de bine, dar se va limita la interfața cu hardware-ul cunoscut de designerul emulatorului. O recreere bună bazată pe FPGA poate interfața cu aproape orice fel de epocă hardware, inclusiv dispozitivele despre care designerul FPGA nu știe nimic , oferind în același timp o fiabilitate mai bună decât hardware-ul de epocă.
Răspuns
Prefață: întrebarea pare să ceară opinii, deoarece este opinie dacă cineva acceptă o emulare, indiferent dacă software-ul de pe un procesor sau de pe un FPGA, la fel ca cel real sau nu.
Întrebați-vă, conduce o mașină cu tehnologie modernă pimped pentru a arăta ca un SSK la fel ca și conducerea reală? Doriți să mergeți cu un BMW din anii 1950 cu toate sunetele, mirosurile și vibrațiile acestuia (și toate trăsăturile necesare pentru a-l continua) sau o bicicletă electrică din 2020 făcută să arate ca una, oferindu-vă sunetul clasic dintr-o construcție în iPod ?
Mă rătăcesc care sunt diferențele dintre utilizarea unui hardware real, emulatoarele hardware bazate pe FPGA precum MiSTer și cantitatea mare de software emulatoare pentru diferite sisteme care rulează pe computere moderne Windows, MacOS și Linux.
Dacă sunteți doar un utilizator, convins cu utilizarea tastaturii moderne și a mouse-ului modern gestionarea unor imagini, care arată ca 640 x 400, pe ecranul dvs. de 4k, atunci software-ul este tot ceea ce aveți nevoie. Deja o versiune FPGA va fi exagerată, deoarece folosește aceleași dispozitive moderne.
Pe de altă parte , dacă imagistica nu este suficientă, dar doriți să simțiți mouse-ul voluminos Atari, tastatura Amiga wiggly sau joystick-ul voluminos C64, toate prezentate cu o strălucire reală CRT, atunci nu există altă cale un lucru real.
Un lucru care mi-a venit în minte este că atât emulatoarele software, cât și cele hardware nu ar putea fi suficient de precise
Până acum sunt. în fiecare detaliu. Hardware-ul modern este suficient de rapid pentru a permite utilizarea software-ului HLL pentru a obține ciclul exact al momentului. Mai ales atunci când toate intrările și ieșirile sunt oricum emulate, mapate la dispozitive moderne.
Dar acest lucru mi se pare ceva în funcție de calitatea implementării care poate variază între emulatori și se îmbunătățesc în timp datorită remedierii erorilor, dar nu ca o problemă fundamentală.
Programarea și întreținerea leneșă nu invalidează abordarea. Pentru toate scopurile, cu excepția dispozitivelor hardware reale, nu există nicio diferență.
De asemenea, aud despre problema latenței cu emulatoarele de software, dar „Sunt puțin surprins că așa ceva poate fi simțit într-adevăr pe un computer, care este probabil de milioane de ori mai rapid decât mașina emulată.
Poate de o sută de ori, Rețineți, majoritatea componentelor majore nu au devenit la fel de rapide – și cea mai mare parte a fost consumată de dispozitivele de dimensiuni mai mari și de nevoile de date.
Problema latenței este ceva care a existat de atunci ca întotdeauna. Vor exista întotdeauna unele declarații care pot vedea / simți diferența. Deși acest lucru poate fi adevărat în câteva situații foarte dedicate, acestea sunt „gunoiul de cele mai multe ori. Revendicați că simțiți câteva microsecunde, atunci când testați un joystick deja poate costa mai mult este pur și simplu fantezie.
Există într-adevăr un motiv tehnic pentru a prefera emularea reală sau emularea bazată pe FPGA vs. emularea software
Ce constituie un motiv tehnic pentru dvs.? Termenul în sine nu este clar atunci când comparați diferite implementări complete.
sau acesta este doar un lucru de nostalgie, cauzat de dorința de a umple ca dvs. s-au întors cu adevărat în anii 80 „sau 90”?
Te-ai așezat vreodată în fața uneia dintre vechile mașini? Este surprinzător cum diferite tastaturi se simt atunci când părăsiți echipamentul standardizat de astăzi.
Și apoi există, desigur, jocuri hardware – nu chiar distractiv cu emulatoarele, deoarece adăugarea unei interfețe este doar adăugarea câtorva linii de cod – sau doar configurati în unele cazuri. Fără aspect, fără gravare, fără lipire și mai ales fără blestem și corecție până când nu funcționează.
Răspuns
Aș dori să clarificați termenul de „emulare FPGA” menționat în întrebare.
În primul rând, desigur, există o emulare de software. Să luăm ca exemplu niște emulatori de software (mai mult sau mai puțin) exacți ai procesorului 6502 . Ei încearcă să emuleze toate artefactele externe ale procesorului real, cum ar fi numărul de cicluri pe fiecare comandă, adresele acceselor de memorie și chiar „starea internă” (mai degrabă doar starea registrelor vizibile de software). Cu toate acestea, nu are nimic asemănător cu CPU-ul real, pornind de la punctul în care este vorba de software pur, nu de un dispozitiv hardware.
Când este descoperită orice caracteristică reală a lui 6502 real (cum ar fi noile opcoduri sau steaguri nedocumentate sau detalii de execuție ), este introdus în emulatorul de software ca „o altă caracteristică de implementat”. Nici o caracteristică a realității nu ar apărea în emulatorul de software, dacă acestea sunt necunoscute implementatorului.
Atunci să analizăm nucleele HDL compatibile cu 6502.Acum reprezintă de fapt un dispozitiv logic digital real – sau un model al acestuia (în cazul în care HDL este simulat, nu este implementat în hardware-ul real, cum ar fi FPGA sau ASIC). Acum au stocare reală pentru flipflop (sau zăvor) pentru registrele procesorului, ar putea implementa semnale reale ale magistralei CPU și chiar să fie inserate în computerul retro în loc de originalul 6502. Cu toate acestea sunt făcute (mai mult sau mai puțin) „de la zero”, cu specificațiile CPU pe care sunt destinate să le înlocuiască, nu structura sa internă. Și totuși le-ar lipsi caracteristicile care nu sunt descrise în specificațiile respective, care există în procesorul retro real, dar sunt încă necunoscute implementatorului.
Un alt nivel al reconstrucției ar putea fi designul HDL construit în felul următor:
- procesorul retro real este decapat și fotografiat
- apoi se recreează schemele la nivel de netlist și tranzistor (fie manual, fie cu unele instrumente mai mult sau mai puțin automatizate)
- netlistul este convertit la schemele la nivel de poartă și apoi la descrierea HDL, care este la rândul său implementată în FPGA sau ASIC.
Spre deosebire de cazurile anterioare, acum aproape toate caracteristicile procesorului real să devină implementat „nativ”, deoarece structura HDL rezultată este mai mult sau mai puțin echivalentă cu structura lucrului real (la nivel de porți logice și flipflops).
Totuși ar putea exista probleme, de exemplu 6502 are câteva instrucțiuni care se comportă neregulat și simt că un astfel de comportament nu ar apărea în HDL în mod natural.
În general, consider Tot ce se află deasupra „ingineriei inversate, apoi recreați HDL” este de fapt o emulare , fie în software, fie în hardware, în timp ce ultima variantă este nu .
u alte cuvinte, să luăm în considerare păstrarea vechiului software. L-am putea rula pe hardware-ul contemporan, dar dacă nu este disponibil, intră în joc emulatoarele de software, totuși vechea piesă software pe care sunt folosite pentru a o executa este în continuare exact aceeași.
Acum „ne-ar plăcea să păstrați vechea piesă de hardware (CPU), dar implementarea autentică nu este disponibilă, așa că o recreăm folosind o tehnologie mai nouă, dar structura logică a procesorului rămâne exact aceeași.
Răspuns
Pentru a oferi un răspuns numai la întrebarea de latență, ca autor al emulatorului:
Excepțiile abundă, dar regula generală privind hardware-ul original din anii 80 și în începutul anilor 90 este că schimbările de intrare pe tastatură și joypad pot fi detectate de hardware aproape imediat după ce au avut loc și că, pe măsură ce video și audio sunt transmise de pe aparat, acesta ajunge la utilizator aproape imediat – de exemplu, pentru un televizor CRT clasic, nivelul rasterului pictează acum este aproape ieșirea live a mașinii.
Cu hardware-ul acum, intrarea în general traversează este o stivă Bluetooth sau USB, care poate fi inspectată doar la un anumit interval de timp de către sistemul de operare gazdă și, dacă s-a întâmplat ceva, comunică acest lucru procesului interesat care poate sau nu să se întâmple imediat, în funcție de planificatorul specific.
Mulți emulatori implementează, de asemenea, o buclă principală care arată ca modul în care ai putea proiecta un joc:
- colectează toate cele mai recente intrări și redirecționează-le către mașina emulată;
- rulați mașina pentru un cadru;
- vopsiți următorul cadru de ieșire într-un buffer invizibil;
- faceți coada pentru afișare la următorul vsync și bloc;
- repeat.
De dragul argumentelor, imaginați-vă că mașina dvs. modernă este foarte rapidă și că pașii 2 și 3 sunt instantanee. Apoi:
- există o jumătate de cadru mediu de latență de intrare plus orice semnalizare Bluetooth / USB și sistemul de operare adăugat – orice intrare care apare imediat după ce partea de sus a unui cadru nu va fi redirecționată până la începutul următorului, oricare care apare chiar la sfârșit va fi comunicat aproape la momentul potrivit, iar intervalul de latențe între ele este liniar, astfel încât media este la jumătatea distanței; și
- există un cadru suplimentar fix de latență de ieșire, deoarece postați un cadru pentru prezentare la următorul vsync și apoi așteptați până când este momentul să fie afișat.
Deci, cu acea buclă simplă, pe hardware-ul ideal, în cazul mediu întârzierea dintre apăsarea ceva și ecranul care reacționează este cu aproximativ 1,5 cadre mai mult decât hardware-ul real. Și asta este doar dacă mașinile gazdă și emulate rulează la aceeași rată de cadre .
Puriștii susțin că unele jocuri originale sunt atât de bine reglate, după un număr adecvat de ore de testare și modificări înapoi în zi, încât 1,5 cadre le pun în dezavantaj pe care le pot detecta.
FPGA-urile sunt de obicei emulare *, indiferent de modul în care sunt „vândute”, deoarece de obicei sunt o persoană care implementează o specificație într-un limbaj de descriere hardware la nivel înalt. Dar încearcă să omită cât mai multă latență posibilă – o calitate bună va omite bufferul video în întregime, va rula restul sistemului în timp real și va împinge intrarea cu o întârziere minimă.
* calificare adăugat conform corecției furnizate de @lvd mai jos. Vedeți răspunsul său pentru mai multă culoare.
Desigur, nu este greu să remediați majoritatea problemelor software din software:
- transmiteți mai des intrările;
- nu faceți acest lucru utilizați vsync pentru a declanșa o nouă ieșire la vsync; și
- nu utilizați un tampon dublu.
In extremis, puteți chiar să rasați rasterul pentru o latență de ieșire similară cu un FPGA – dacă aveți deja un nivel ridicat -bucla de frecvență pentru intrări frecvente, iar dacă hardware-ul de bază acceptă orice tip de ieșire care poate produce distrugerea ecranului, atunci veți avea instrumentele.
Din păcate, astfel de abordări nu au fost luate de obicei de emulatori în trecut, mai ales înainte ca latența să devină un subiect atât de larg discutat și ceva negativ s-a blocat.
Comentarii
Răspuns
multe aspecte ale HW vs SW au fost acoperite de alte postări aici, așa că voi face nu le atinge. În schimb, aș dori să explic problema LATENȚĂ din punctul meu de vedere, împreună cu experiența pe care am dobândit-o în timpul codificării emulatoarelor mele pentru diferite platforme …
Realizarea emulatorului SW pe mașinile moderne este mult mai dificilă din punct de vedere al latenței decât a fost înapoi în timpii de acces direct I / O. Pentru computerele de acasă și consolele de jocuri, trebuie să simulăm / emulăm sunetul, ieșirea vizuală și intrarea utilizatorului cât mai precis posibil. Cea mai mare problemă este cu sunetul. Asta pentru că auzul nostru este mult mai bun decât oricare dintre simțurile noastre și putem simți / auzi diferența dacă sunetul este oprit chiar de puțini ms sau Hz. Dacă ecranul este oprit cu 1 sau 2 cadre nu putem vedea diferența. De asemenea, dacă intrarea este întârziată puțin este ok (pentru majoritatea oamenilor).
În arhitectura modernă a mașinilor, totul este tamponat (în special sunet). Deci, pentru a scoate sunetul, trebuie să creăm un PCM date care sunt trimise către cipul de sunet și redate prin DMA + DAC . Pentru a face acest lucru, de obicei se utilizează 2 tampoane liniare circulare sau multe mici. Acum, pentru a produce sunete fără probleme, tampoanele trebuie să fie suficient de mari. De exemplu, pe Windows ultima dată când verific WAVEOUT are nevoie de cel puțin 20-80 ms. DirectSound nevoie de >400 ms
Acum, dacă programul emulat se ajustează sunetul va fi redat numai după ce sunetul deja solicitat este redat.
La fel se întâmplă și pentru intrarea I / O pe unele platforme, astfel încât întârzierile se adună.
Când utilizați FPGA atunci aveți acces direct la ieșirea sonoră fără tampon. Același lucru este valabil și pentru intrare.
Cu toate acestea, jocul latența de intrare (tastatură, joystick) nu are de obicei nimic de-a face cu latența sistemului gazdă . Cauza obișnuită este că majoritatea emulatoarelor utilizează ticuri de ceas pentru a menține viteza emulată. Deci, ei simulează CPU sau orice altceva și, odată ce au atins numărul dorit de ceasuri simulate de fiecare dată, dorm până când următorul timer este emis sau orice altceva. Cu cât computerul gazdă este mai rapid, cu atât timpul de emulare este mai mic, prin urmare, simularea nu va reacționa în cea mai mare parte a timpului real.
De exemplu, presupunem că simularea noastră poate rula de 100 de ori mai rapid decât viteza inițială a computerului emulat. Asta înseamnă că doar 1% din timp simularea face ceva și odihna este doar Sleep(). În timpul somnului, emulația nu poate răspunde la nimic. Deci, poate lipsi loviturile cheie, declanșează clicuri etc … Pentru a remedia faptul că unii emulatori ar putea utiliza din nou buffering-ul, ducând la latență în loc de a ignora intrarea. Există, de asemenea, un stil diferit de a controla timpul care elimină complet această problemă. Pentru mai multe informații despre acest subiect, consultați:
Răspuns
Mașinile NTSC Vintage (și Mac-urile CRT etc.) își pot schimba ieșirea grafică în mijlocul reîmprospătării afișajului CRT (parcurs jos rasterul vertical), distrugând astfel imaginea ca răspuns la intrarea în timp real.
Emulatoarele care folosesc monitoare non-CRT nu pot face acest lucru în timp real și pot falsifica un raster rupt doar în următoarea cadru sau câmp.
Și singura modalitate de a testa dacă o emulație este corectă în comparație cu hardware-ul vintage real (adevărul la sol). Vedeți dacă există capcane logice ascunse nedocumentate (defuziune etc.) sau erori de aspect analogice sub diferitele straturi de cip ASIC.
Comentarii