Quali sono i vantaggi / svantaggi dellutilizzo di hardware retrò rispetto allemulazione FPGA rispetto allemulazione software? [chiuso]

Un vantaggio che gli emulatori FPGA generalmente condividono con lhardware vintage è la possibilità di utilizzare dispositivi che interagiscono con lhardware in modi che dipendono molto dal tempo. Ad esempio, se si dispone di una cartuccia di gioco per NES che fa scattare un interrupt ogni volta che viene caricata la prima riga di dati per un particolare sprite, una console che legge il contenuto di una cartuccia e poi la emula sarebbe in grado di giocare correttamente solo se fosse in grado di riconoscere quale sia la cartuccia stava facendo con la linea di interrupt.

Lhardware basato su FPGA generalmente funzionerebbe altrettanto bene, se non di più affidabile rispetto allhardware vintage, ma ci sono alcune stranezze da tenere a mente. Alcuni prototipi di cartucce di espansione per lAtari 2600, ad esempio, si basavano sul fatto che anche quando NMOS 6502 sta provando a portare in alto il bus dati, non è in grado di sforzarsi abbastanza da sopraffare un dispositivo esterno che sta cercando di tirare il filo in basso, né danneggiarsi nel tentativo. Si noti che il contrario non è vero: un dispositivo NMOS che tenta di tirare una linea in basso mentre un dispositivo esterno lo sta tirando in alto può danneggiarsi nel tentativo (RIP 2600jr). Se si dovesse collegare in un moderno sistema ricreativo un dispositivo NMOS che si basasse sulla capacità di sovraccaricare i cavi del bus, e il sistema non limitasse la corrente del drive high-side su quei cavi, si potrebbe danneggiare il dispositivo esterno. Non so fino a che punto questo sarebbe effettivamente un problema, ma poiché tutti i dispositivi che si basano su tali tecniche sono probabilmente rari, sarebbe molto spiacevole se venissero danneggiati.

Un altro potenziale problema è che lelettronica vintage era spesso piuttosto lento a rispondere ai segnali, il che significava che se un dispositivo avesse emesso un segnale molto brevemente su un filo, sarebbe stato probabilmente ignorato. Alcuni dispositivi elettronici vintage a volte emettevano brevi impulsi glitch se una combinazione di ingressi cambiava tra uno stato in cui luscita dovrebbe essere bassa e uno stato diverso in cui luscita dovrebbe essere bassa. Se una ricreazione FPGA non è progettata per ignorare tali impulsi, potrebbero causare un funzionamento errato sullhardware ricreato anche se non avrebbero causato alcun problema sulloriginale.

Personalmente, penso che gli FPGA siano il modo migliore di ricreare i sistemi. Lhardware vintage è interessante, ma laffidabilità è spesso problematica. Lemulazione del software può funzionare abbastanza bene, ma sarà limitata allinterfacciamento con lhardware che il progettista dellemulatore conosce. Una buona ricreazione basata su FPGA può interfacciarsi con quasi ogni tipo di vintage hardware, compresi i dispositivi di cui il progettista FPGA non sa nulla , offrendo una migliore affidabilità rispetto allhardware vintage.

Prefazione: la domanda sembra chiedere opinioni, poiché è opinione se qualcuno accetta unemulazione, non importa se il software su una CPU o su un FPGA, uguale o meno alla cosa reale.

Chiediti, sta guidando unauto tecnologica moderna ottimizzata per guardare come un SSK lo stesso che guidare la cosa reale? Vuoi guidare una BMW degli anni 50 con tutti i suoni, gli odori e le vibrazioni (e tutti i ritocchi necessari per farla funzionare) o una bici elettrica del 2020 fatta per assomigliare a tale, dandoti il suono classico di una build in iPod ?

Mi chiedo quali siano le differenze tra lutilizzo di un hardware reale, emulatori hardware basati su FPGA come MiSTer e la grande quantità di software emulatori per diversi sistemi in esecuzione sui moderni computer Windows, MacOS e Linux.

Se sei solo un utente, sei convinto di utilizzare la tua moderna tastiera e il tuo mouse moderno maneggiando unimmagine, che sembra 640 x 400, sul tuo schermo 4k, il software è tutto ciò di cui hai bisogno. Già una versione FPGA sarà eccessiva, poiché utilizza gli stessi dispositivi moderni.

Daltra parte , se limmagine non è sufficiente, ma vuoi sentire lingombrante mouse Atari, la sinuosa tastiera Amiga o lingombrante joystick C64, tutti presentati con un vero bagliore CRT, allora non cè altro modo per una cosa vera.

Una cosa che mi è venuta in mente è che sia gli emulatori software che quelli hardware potrebbero non essere abbastanza precisi

Ormai lo sono. in ogni dettaglio. Lhardware moderno è abbastanza veloce da consentire luso del software HLL per acquisire la tempistica esatta del ciclo. Soprattutto quando tutto in e output viene emulato comunque, mappato su dispositivi moderni.

Ma questo mi sembra qualcosa che dipende dalla qualità dellimplementazione che può variano tra i diversi emulatori e migliorano nel tempo a causa della correzione di bug, ma non come un problema fondamentale.

La programmazione e la manutenzione lente non invalida lapproccio. Per tutti gli scopi, tranne le mani reali sullhardware, non cè differenza.

Inoltre ho sentito parlare del problema di latenza con gli emulatori software, ma io “Sono un po sorpreso che qualcosa di simile possa davvero essere sentito su un computer che è probabilmente milioni di volte più veloce della macchina emulata.

Forse cento volte, se non del tutto. Tieni presente che la maggior parte dei componenti principali non è diventata molto più veloce e la maggior parte di ciò è stata assorbita da dispositivi di dimensioni maggiori e da esigenze di dati.

Il problema della latenza è qualcosa che esiste da allora come sempre. Ci saranno sempre alcuni che affermano di poter vedere / sentire la differenza. Anche se questo può essere vero in alcune situazioni molto dedicate, è spazzatura la maggior parte del tempo. Affermare di sentirsi pochi microsecondi, quando si prova già un joystick può costare di più è semplicemente fantasia.

Esiste davvero una ragione tecnica per preferire lemulazione hardware o basata su FPGA rispetto allemulazione software

Cosa costituisce una ragione tecnica per te? Di per sé il termine non è chiaro quando si confrontano implementazioni diverse complete.

o questa è solo una cosa nostalgica, causata dal desiderio di riempirsi come te sei davvero tornato negli anni 80 o 90?

Ti sei mai seduto davanti a una delle vecchie macchine? È sorprendente come tastiere diverse si sentono quando si lascia lattrezzatura standardizzata di oggi.

E poi cè ovviamente lhardware che si modifica – non è un vero divertimento con gli emulatori, poiché qui aggiungere uninterfaccia significa semplicemente aggiungere alcune righe di codice – o semplicemente configurati in alcuni casi. Nessun layout, nessuna incisione, nessuna saldatura e soprattutto nessuna imprecazione e patch fino a quando non funziona.

Mi piacerebbe ” chiarire il termine “emulazione FPGA” menzionato nella domanda.

Innanzitutto, naturalmente esiste qualcosa come lemulazione software. Prendiamo come esempio alcuni (più o meno) esatti emulatori software della CPU 6502 . Tentano di emulare tutti gli artefatti esterni della CPU reale, come il numero di cicli per ogni comando, gli indirizzi degli accessi alla memoria e persino lo “stato interno” (piuttosto solo lo stato dei registri visibili dal software). Eppure non ha nulla di simile alla CPU reale, a partire dal punto è pura questione software, non dispositivo hardware.

Quando viene scoperta qualsiasi nuova funzionalità del vero 6502 (come nuovi codici operativi o flag o dettagli di esecuzione non documentati ), viene inserito nellemulatore software come “unaltra caratteristica da implementare”. Nessuna caratteristica della cosa reale sarebbe emersa nellemulatore software, se fosse sconosciuta allimplementatore.

Quindi diamo unocchiata ai core HDL compatibili con 6502.Ora rappresentano in realtà un vero dispositivo logico digitale – o un modello di quello (nel caso lHDL sia simulato, non implementato nellhardware reale come FPGA o ASIC). Ora hanno una vera memoria flipflop (o latch) per i registri della CPU, potrebbero implementare segnali di bus CPU reali e persino essere inseriti nel computer retrò al posto delloriginale 6502. Eppure sono fatti (più o meno) “da zero”, con le specifiche della CPU si intendono sostituire, non la sua struttura interna. Eppure mancherebbero funzionalità non descritte in quelle specifiche, che esistono nelle vere CPU retrò, ma sono ancora sconosciute allimplementatore.

Un altro livello della ricostruzione potrebbe essere il design HDL costruito nel modo seguente:

1. La vera CPU retrò viene decappata e fotografata
2. quindi vengono ricreati schemi a livello di netlist e transistor (a mano o con strumenti più o meno automatizzati)
3. netlist viene convertito negli schemi a livello di gate e quindi nella descrizione HDL, che a sua volta viene implementata in FPGA o ASIC.

A differenza dei casi precedenti, ora quasi tutte le funzionalità della CPU reale diventano implementate “nativamente”, perché la struttura dellHDL risultante è più o meno equivalente alla struttura della cosa reale (a livello di porte logiche e flipflop).

Tuttavia potrebbero esserci problemi, ad esempio 6502 ha alcune istruzioni che si comportano in modo irregolare e ritengo che tale comportamento non emergerebbe naturalmente in HDL.

In generale, considero er tutto al di sopra del “reverse-engineering, quindi ricrea HDL” è in realtà un emulazione , nel software o nellhardware, mentre il secondo modo non .

In altre parole, consideriamo la conservazione del vecchio software. Potremmo eseguirlo su hardware contemporaneo, ma se non è disponibile, entrano in gioco gli emulatori di software, ma il vecchio software che sono usati per eseguire è sempre lo stesso.

Ora ci piacerebbe conserva il vecchio hardware (CPU), ma limplementazione autentica non è disponibile, quindi la ricreamo utilizzando la tecnologia più recente, ma la struttura logica della CPU rimane esattamente la stessa.

Per offrire una risposta solo alla domanda di latenza, come autore di un emulatore:

Le eccezioni abbondano, ma la regola generale sullhardware originale degli “anni 80 in poi allinizio degli anni 90 è che i cambiamenti di input da tastiera e joypad possono essere rilevati dallhardware quasi immediatamente dopo che si verificano e che quando il video e laudio vengono emessi dalla macchina raggiungono lutente quasi immediatamente, ad esempio per un classico televisore CRT il livello del raster sta dipingendo in questo momento è quasi loutput live della macchina.

Con lhardware ora, linput generalmente attraversa es uno stack Bluetooth o USB, che può essere ispezionato solo a un certo intervallo dal sistema operativo host, e se è successo qualcosa, lo comunica in seguito al processo interessato che può o non può accadere immediatamente a seconda dello specifico scheduler.

Molti emulatori implementano anche un ciclo principale che assomiglia a come potresti progettare un gioco:

1. raccoglie tutti gli ultimi input e li inoltra alla macchina emulata;
2. esegui la macchina per un frame;
3. dipingi il frame successivo di output in un buffer invisibile;
4. mettilo in coda per la visualizzazione al prossimo vsync e blocco;
5. ripeti.

Per amor di discussione, immagina che la tua macchina moderna sia molto veloce e che i passaggi 2 e 3 siano istantanei. Quindi:

• cè una media di mezzo frame di latenza di input più qualsiasi segnale Bluetooth / USB e il sistema operativo aggiunto: qualsiasi input che si verifica subito dopo linizio di un frame non verrà inoltrato fino allinizio del successivo, tutto ciò che si verifica alla fine verrà comunicato quasi al momento giusto e lintervallo di latenze intermedie è lineare, quindi la media è a metà tra; e
• cè “un frame aggiuntivo fisso di latenza di output perché pubblichi un frame per la presentazione al prossimo vsync e poi attendi fino al momento della visualizzazione.

Quindi con quel semplice loop, su hardware ideale, nel caso medio il ritardo tra la pressione di qualcosa e la reazione dello schermo è di circa 1,5 fotogrammi in più rispetto allhardware reale. E questo è solo se le macchine host e emulate funzionano alla stessa frequenza di fotogrammi .

I puristi sostengono che alcuni giochi originali sono così finemente sintonizzati, dopo il numero appropriato di ore di test e ritocchi nel corso della giornata, che 1,5 fotogrammi li mette in una condizione di svantaggio che possono rilevare.

Gli FPGA sono di solito * emulazione, non importa come vengono venduti, perché di solito sono una persona che reimplementa una specifica in un linguaggio di descrizione hardware di alto livello. Ma cercano di omettere il più possibile quella latenza: una di buona qualità ometterà completamente il buffering video, eseguirà il resto del sistema in tempo reale e inserirà linput con un ritardo minimo.

* qualifica aggiunto secondo la correzione fornita da @lvd di seguito. Vedi la sua risposta per più colore.

Ovviamente, non è difficile risolvere la maggior parte dei problemi software nel software:

• inoltra linput più spesso;
• don “t usa vsync per attivare un nuovo output su vsync; e
• non utilizzare un doppio buffer.

In extremis, puoi persino competere con il raster per una latenza di output simile a un FPGA, se hai già una -frequency loop per input frequenti, e se lhardware di base supporta qualsiasi tipo di output che può produrre screen tearing, allora hai gli strumenti.

Sfortunatamente tali approcci non erano normalmente adottati dagli emulatori nel passato, soprattutto prima che la latenza diventasse un argomento così ampiamente discusso, e qualcosa di unimmagine negativa è rimasta bloccata.

Commenti

• FPGA non è sempre un emulazione, almeno nei tuoi termini di " una persona che reimplementa una specifica in un linguaggio di descrizione hardware di alto livello "
• @lvd per migliorare la risposta, puoi essere più specifico? Sono ' a conoscenza di un esperimento che utilizzava una netlist estratta da VisualChips da un reale (se la memoria serve ) TIA, ma poco oltre. EDIT: no, aspetta, vedo che ' hai pubblicato una risposta separata. Grazie!

molti aspetti di HW vs SW sono stati trattati da altri post qui, quindi lo farò non toccarli. Vorrei invece spiegare il problema di LATENCY dal mio punto di vista insieme allesperienza acquisita durante la codifica dei miei emulatori per varie piattaforme …

Realizzare un emulatore SW su macchine moderne è molto più difficile dal punto di vista della latenza rispetto ai tempi di accesso diretto allI / O. Per i computer di casa e le console di gioco dobbiamo simulare / emulare il suono, luscita visiva e linput dellutente nel modo più preciso possibile. Il problema più grande è con il suono. Questo perché il nostro udito è molto meglio di qualsiasi altro dei nostri sensi e possiamo sentire / sentire la differenza se il suono è spento anche da pochi ms o Hz. Se lo schermo è spento di 1 o 2 fotogrammi non possiamo vedere la differenza. Inoltre, se linput è leggermente ritardato, va bene (per la maggior parte degli esseri umani).

Nella moderna architettura della macchina tutto è bufferizzato (soprattutto audio). Quindi, per riprodurre il suono, dobbiamo creare un PCM dati che vengono inviati al chip audio e riprodotti tramite DMA + DAC . Per fare questo di solito vengono utilizzati 2 circolari o molti piccoli tamponi lineari. Ora, per produrre suoni privi di glitch, i buffer devono essere abbastanza grandi. Ad esempio su Windows lultima volta che controllo WAVEOUT richiede almeno 20-80 ms. DirectSound need >400 ms

Ora se il programma emulato si adatta luscita audio verrà emessa solo dopo che il suono già richiesto è stato riprodotto.

Lo stesso vale per lingresso I / O su alcune piattaforme, quindi i ritardi si sommano.

Quando usi FPGA quindi hai accesso diretto alluscita audio senza buffering. Lo stesso vale per linput.

Tuttavia la latenza di input del gioco (tastiera, joystick) di solito non ha nulla a che fare con la latenza del sistema host . La causa comune è che la maggior parte degli emulatori utilizza i tic di clock per mantenere le velocità emulate. Quindi simulano la CPU o qualsiasi altra cosa e una volta raggiunto il numero desiderato di orologi simulati per volta, dormono fino allemissione del timer successivo o qualsiasi altra cosa. Più veloce è il computer host, minore è il tempo necessario per emulare, quindi la simulazione non reagirà per la maggior parte del tempo reale.

Ad esempio, supponiamo che la nostra simulazione possa essere eseguita 100 volte più velocemente della velocità originale del computer emulato. Ciò significa che solo l1% delle volte la simulazione esegue qualcosa e il resto è solo Sleep(). Durante il sonno lemulazione non può rispondere a nulla. Quindi può perdere colpi di tasti, clic di fuoco ecc … Per rimediare al fatto che alcuni emulatori potrebbero utilizzare nuovamente il buffering portando alla latenza invece di ignorare linput. Esistono anche diversi stili di controllo del tempo che rimuovono completamente questo problema. Per ulteriori informazioni su questo argomento, vedere:

• Domanda sulla precisione del conteggio dei cicli durante lemulazione di una CPU

Le macchine NTSC vintage (e i Mac CRT, ecc.) possono modificare loutput grafico durante laggiornamento del display CRT (a metà lungo il raster verticale), strappando così limmagine in risposta allinput in tempo reale.

Gli emulatori che utilizzano monitor non CRT non possono farlo in tempo reale e possono solo simulare un raster strappato il successivo cornice o campo.

E lunico modo per verificare se unemulazione è accurata in termini di confronto con lhardware vintage reale (verità di base). Controlla se ci sono trappole logiche nascoste non documentate (defusione, ecc.) O bug del layout analogico sotto i vari strati del chip ASIC.

Commenti

• _ " .. può solo simulare … " _Quale è la differenza? ' non è unemulazione basata sulla falsificazione dellintera cosa?
• Non su un display non CRT. Un LCD (et.al.) non ' si aggiorna in 2 campi interlacciati di 30 fotogrammi, dove le linee alternate e la parte superiore e inferiore di una finestra vengono visualizzate in momenti diversi, oltre 10 mS a parte in tempo reale. Forse un FPGA che alimenta un vecchio monitor CRT sarebbe più preciso di un emulatore.
• Niente impedisce al software di emulazione di fare lo stesso. e alcuni lo fanno. Dopotutto, gli schermi a 60 Hz sono ormai standard, consentendo di trasferire lo stesso sfarfallio di un CRT. Non cè bisogno di software basato su FPGA o CRT qui.