Come funzionano gli emulatori per PlayStation, Xbox, Windows...?

Cos'è un emulatore? Un programma che "traduce" un dispositivo in un altro, come quando si converte un file da .docx a .pdf? Se fosse così semplice, avremmo un emulatore il giorno stesso dell'uscita di ogni console, ma non è così. Dobbiamo aspettarlo per anni o non averlo mai. È una delle imprese più difficili nella storia della programmazione.

Un emulatore non è un semplice convertitore, ma una versione software dell'intero dispositivo. Il processore, la scheda grafica, la memoria, il chip audio e il sistema operativo, tutti elementi che devono funzionare insieme in armonia, in tempo reale e con una precisione tale che il gioco o il programma non si accorgano nemmeno della differenza.

Dove inizia lo sviluppo? Da dove traggono ispirazione gli sviluppatori per lo sviluppo?

Gli sviluppatori di emulatori raramente hanno accesso alla documentazione tecnica ufficiale del produttore della console. Sony, Microsoft o Nintendo non condividono le loro specifiche interne. Al contrario, proteggono queste informazioni come segreto commerciale. Ecco perché ogni progetto inizia con quella che nel settore viene chiamata "ingegneria inversa". Ciò significa che gli sviluppatori prendono l'hardware reale, lo smontano, analizzano i circuiti elettronici, intercettano i segnali tra i chip e ricostruiscono gradualmente il funzionamento del processore in risposta a ciascun comando, a partire dal codice hardware del firmware (ovvero il software integrato direttamente nel dispositivo).

Questo processo spesso richiede un approccio "a camera bianca". Un gruppo analizza e documenta il funzionamento del dispositivo, mentre un altro gruppo utilizza questa documentazione, senza mai vedere il codice originale del produttore, per scrivere un nuovo programma che ne emuli il comportamento. Questa separazione non è solo una formalità tecnica, ma anche una garanzia legale, poiché l'emulazione in sé non è illegale, mentre la copia del codice proprietario di un produttore lo è. Inoltre, gli sviluppatori necessitano del BIOS o del firmware originale della console, ovvero il programma di avvio di base che controlla l'hardware. Gli utenti di solito devono procurarselo autonomamente, spesso direttamente dalla propria console, poiché non è legalmente consentito distribuirlo insieme all'emulatore.

Cosa deve sapere uno sviluppatore?

Se avete mai letto o leggerete i diari di sviluppo di emulatori come RPCS3 per PlayStation 3 o Eden per Nintendo Switch, vi renderete subito conto che uno sviluppo di questo tipo richiede un team più ampio, non solo un singolo individuo. È necessario padroneggiare una vasta gamma di competenze.

Richiede la comprensione dell'architettura del processore, che si tratti di PowerPC (il processore dell'Xbox 360), ARM, MIPS o x86, comprese tutte le sue istruzioni, i registri e le specifiche di temporizzazione. Richiede inoltre la padronanza del funzionamento della GPU e la traduzione delle sue istruzioni in interfacce grafiche moderne come Vulkan o DirectX. Ciò include l'emulazione del chip audio, dei controller, della gerarchia di memoria e del sistema operativo della console, che gestisce file, thread e diritti di accesso.

La sfida tecnica più grande è spesso la ricompilazione dinamica, nota anche come compilazione just-in-time (JIT). Invece di interpretare ogni comando dalla console originale uno per uno, il che sarebbe troppo lento, l'emulatore traduce i comandi nel codice macchina del processore host in tempo reale, eseguendoli a una velocità quasi nativa. Ciò richiede una conoscenza estremamente precisa di entrambe le architetture contemporaneamente, e il risultato deve rimanere identico bit per bit all'originale, altrimenti il gioco si bloccherà, si arresterà in modo anomalo o visualizzerà una grafica errata.

Perché lo sviluppo richiede anni, a volte decenni?

La risposta risiede in gran parte in un singolo esempio: la PlayStation 3. Il suo processore Cell, sviluppato congiuntamente da Sony, Toshiba e IBM, non era un processore multi-core convenzionale, bensì una singola unità di elaborazione principale (PPU) combinata con otto unità di elaborazione ausiliarie speciali (SPU), ognuna delle quali disponeva di una propria piccola memoria locale e non aveva accesso diretto alla memoria di sistema principale. I programmatori di videogiochi dovevano suddividere manualmente il lavoro tra queste unità, poiché nessun compilatore lo faceva automaticamente, il che significava che un emulatore non poteva semplicemente compilare il codice come avrebbe fatto per un processore più convenzionale.

Deve comprendere lo scopo reale del codice estremamente specifico e ottimizzato manualmente. Gli sviluppatori di RPCS3 hanno dovuto creare un processore che infrangesse quasi tutti i presupposti dell'architettura x86 in materia di memoria, coerenza dei dati e thread, per costringere i loro programmi a funzionare su un hardware che condivide poche caratteristiche con Cell. Il primo prototipo dell'emulatore disponibile al pubblico è apparso nel 2011 e ancora oggi, a più di dieci anni di distanza, il team annuncia occasionalmente progressi nell'ottimizzazione che solo ora velocizzano significativamente parti di giochi che prima non funzionavano o presentavano seri problemi.

L'Xbox 360 presenta una sfida simile, seppur leggermente diversa. Lo sviluppo dell'emulatore Xenia è iniziato nel 2013 ed è riuscito a lanciare il suo primo gioco commerciale in tempi relativamente brevi, ma nel 2018 gli sviluppatori si sono trovati in difficoltà nell'emulazione accurata della GPU Xenos, il che ha richiesto quasi tre anni di riscrittura completa del codice grafico prima che le prestazioni migliorassero significativamente. La ragione di cicli di sviluppo così lunghi non è la pigrizia o la mancanza di competenza, ma il fatto che l'emulatore deve comprendere migliaia di casi limite, comandi speciali, bug nell'hardware originale che gli sviluppatori di giochi hanno sfruttato inconsapevolmente o intenzionalmente, e peculiarità di temporizzazione che non sono descritte in nessuna documentazione perché semplicemente non esiste una documentazione ufficiale.

Un altro fattore è la pressione legale. Nintendo è particolarmente nota per la sua abilità nel far valere i propri diritti. Nel febbraio 2024, ha intentato una causa contro gli sviluppatori del popolare emulatore Yuzu, sostenendo che quest'ultimo avesse aggirato illegalmente la protezione crittografica di Switch, come dimostrato dal fatto che Zelda: Tears of the Kingdom aveva raggiunto un milione di download prima della sua uscita ufficiale.

Tropic Haze, la società dietro Yuzu, ha accettato un risarcimento di 2,4 milioni di dollari e ha chiuso definitivamente l'emulatore. Poco dopo, anche Nintendo ha contattato personalmente lo sviluppatore principale del progetto concorrente Ryujinx per interrompere lo sviluppo, rimuovere l'organizzazione e tutte le risorse associate. Casi come questo dimostrano chiaramente perché molti sviluppatori di talento preferiscono rimanere fedeli alle console più "sicure" e datate, mentre i progetti più recenti spesso rimangono anonimi o dispersi in diverse versioni parallele dello stesso progetto originale.

Perché alcune console sono più difficili da violare rispetto ad altre?

In linea generale, più l'architettura interna di una console assomiglia a quella di un PC standard, più è facile emularla. PlayStation 1 e 2 utilizzano processori relativamente convenzionali, quindi sono state emulate piuttosto presto e oggi funzionano senza problemi anche su hardware meno performante. Tuttavia, quando i produttori integrano soluzioni proprietarie non standard, come Cell sulla PS3, la complessità aumenta esponenzialmente. Allo stesso modo, Nintendo Switch si basa su un chip Tegra personalizzato di Nvidia e presenta delle peculiarità nella gestione della memoria e della grafica.

La situazione è ancora più complessa con l'ultima generazione, PlayStation 5 e Xbox Series X/S, poiché si tratta di sistemi la cui architettura è più vicina a quella dei computer moderni (processori AMD Zen e grafica RDNA), ma al contempo protetti da meccanismi di sicurezza molto più avanzati rispetto a quelli disponibili per le generazioni precedenti. Attualmente, non esiste praticamente alcun emulatore funzionante per nessuna delle due console, poiché gli sviluppatori sono ancora impegnati a decifrare i livelli di sicurezza di base, un'impresa ben diversa e più lenta rispetto alla classica emulazione hardware.

Ci sono differenze tra l'emulazione su telefono e quella su computer?

L'emulazione sui dispositivi mobili presenta un ulteriore ostacolo che gli utenti spesso non percepiscono. Si tratta della differenza tra l'architettura del processore ARM, che alimenta quasi tutti gli smartphone, e l'architettura x86, standard sui PC. Pertanto, quando si esegue un emulatore di console basato su x86 o PowerPC su un telefono, il programma deve tradurre simultaneamente le istruzioni dall'architettura originale ad ARM, il che rappresenta un ulteriore livello di elaborazione non necessario su un PC, dove il processore host è spesso già x86.

Inoltre, fino a poco tempo fa Apple aveva praticamente vietato gli emulatori sugli iPhone. Solo nell'aprile del 2024 Apple ha esplicitamente consentito per la prima volta gli emulatori di console per videogiochi retrò nelle linee guida dell'App Store, che ora possono anche offrire il download di giochi. Prima di allora, l'unico modo per ottenere un emulatore su un iPhone era tramite jailbreak o un complicato bypass attraverso applicazioni web.

Anche dopo questa modifica, permangono delle limitazioni. Per motivi di sicurezza, iOS limita rigorosamente la cosiddetta compilazione JIT, ovvero la generazione dinamica del codice macchina durante l'esecuzione del programma, che è la tecnica principale per ottenere una velocità accettabile per gli emulatori più esigenti. Di conseguenza, molti emulatori su iPhone risultano significativamente più lenti rispetto agli stessi progetti su Android, dove tali restrizioni sono in gran parte assenti e dove gli sviluppatori hanno avuto per molti anni un accesso più libero alle risorse di sistema.

Esiste un emulatore di Windows? Winlator, GameHub, GameNative...

Se leggete le mie recensioni di telefoni, avrete notato che spesso includo test di vari giochi per Windows, oltre a quelli per Android e Nintendo Switch. In questo caso, il termine "emulatore" non è tecnicamente il più preciso. Si tratta piuttosto di un insieme di livelli di compatibilità sovrapposti.

Winlator è un'applicazione gratuita e open-source sviluppata da BrunoSX (brunodev85) che permette di eseguire applicazioni e giochi Windows (x86_64) direttamente su dispositivi Android basati su architettura ARM, senza BIOS, senza avviare una vera e propria copia di Windows e senza utilizzare un'immagine disco. Winlator combina due tecnologie distinte, ognuna delle quali risolve una parte specifica del problema. La prima è Wine, un progetto ben noto che da decenni traduce le chiamate API di Windows (comandi per aprire file, accedere al registro di sistema, disegnare grafica tramite Direct3D o riprodurre audio) in comandi comprensibili al kernel Linux su cui Android gira in background.

La seconda tecnologia è Box86 o Box64, che svolge un compito ancora più fondamentale. Traduce le istruzioni del processore dall'architettura x86 all'architettura ARM in tempo reale, poiché nessun telefono possiede fisicamente un processore x86. A ciò si aggiunge un livello grafico. Winlator utilizza il driver Mesin Turnip per le GPU Adreno e gli strumenti DXVK e VKD3D, che traducono le chiamate DirectX in Vulkan, in modo simile a quanto fa Proton su Linux.

L'utente crea un cosiddetto container all'interno dell'applicazione, una sorta di ambiente virtuale isolato in cui imposta separatamente la risoluzione, la quantità virtuale di VRAM, il numero di core del processore e i driver per ogni gioco o programma.

Poiché sono necessarie due traduzioni consecutive (prima le chiamate API, poi i comandi del processore), il carico sull'hardware del telefono è molto maggiore rispetto all'emulazione classica delle console. Questo è anche il motivo per cui Winlator esegue i giochi più vecchi o meno impegnativi relativamente bene, ma con i moderni giochi AAA con motori grafici complessi come Unreal Engine, si verificano spesso rallentamenti nella compilazione degli shader e un notevole surriscaldamento del dispositivo. Finora, il RedMagic 11S Pro è quello che ha gestito meglio il calore, ma per farlo ha dovuto utilizzare una ventola e un sistema di raffreddamento a liquido.

GameHub e GameNative sono diversi?

Quando Winlator raggiunse una certa popolarità, iniziarono a emergere dei concorrenti che utilizzavano sostanzialmente la stessa formula tecnologica (Wine, Box64, Vulkan), ma si differenziavano per il modo in cui il tutto veniva confezionato.

GameNative si è evoluto dal progetto Pluvia, un client Steam non ufficiale che permetteva agli utenti di accedere al proprio account Steam tramite Winlator e avviare direttamente i giochi dalla propria libreria senza dover cercare manualmente i file di installazione online. GameNative è nato come spin-off del progetto Pluvia e attualmente viene sviluppato più rapidamente e attivamente rispetto al progetto originale.

GameHub ha origini leggermente diverse. L'app, precedentemente nota come GameFusion, è prodotta da Gamesir, azienda cinese produttrice di controller per videogiochi, e il suo principale vantaggio risiede nella praticità. Supporta l'accesso tramite Steam, funzionalità non disponibile di default nell'app ufficiale Winlator, e supporta anche la vibrazione dei controller. Essendo un prodotto di un'azienda cinese produttrice di hardware, sono sorte preoccupazioni in materia di privacy all'interno della community, pertanto è stata creata una versione chiamata GameHub Lite, priva di sistemi di tracciamento integrati.

È meglio emulare il risultato o l'intero dispositivo?

Gli emulatori non sempre hanno bisogno di ricreare ogni singolo transistor del sistema originale. Spesso utilizzano un approccio di emulazione di alto livello (HLE). Invece di emulare in dettaglio un intero componente hardware o software di sistema, l'emulatore riconosce ciò che il gioco vuole ottenere e svolge la stessa funzione con una propria implementazione.

L'opposto è l'emulazione a basso livello (LLE), in cui lo sviluppatore cerca di avvicinarsi il più possibile al comportamento effettivo dell'hardware o del firmware originale.

HLE può essere notevolmente più veloce. Il problema sorge quando il gioco non utilizza una funzionalità come previsto. Se uno sviluppatore di giochi scopre una peculiarità non documentata del sistema reale e la sfrutta intenzionalmente, un'implementazione HLE elegante potrebbe fare la cosa "logicamente corretta", mentre la console originale faceva qualcosa di completamente diverso.

Perché un gioco funziona perfettamente mentre un altro non si avvia affatto?

Se un emulatore è in grado di emulare una PlayStation 2, perché dovrebbe importarmi quale gioco per PS2 eseguo? Perché non esistono due giochi che utilizzino la console esattamente allo stesso modo.

Un gioco potrebbe utilizzare solo le funzionalità grafiche più comuni, mentre un altro potrebbe ricorrere a una "fusione" insolita. Uno si basa su calcoli in virgola mobile convenzionali, un altro su uno schema di arrotondamento molto specifico. Uno utilizza un controller standard, un altro un microfono o un accessorio speciale. Un terzo potrebbe contenere un motore di gioco di corse il cui funzionamento dipende inavvertitamente dalla tempistica precisa di un evento del processore.

Pertanto, testare un emulatore non è la stessa cosa che testare un'applicazione normale. Un test di regressione davvero valido è una libreria di centinaia o migliaia di giochi.

E poi arriva una patch che finalmente fa funzionare correttamente un gioco, ma ne manda in tilt altri tre.

Ironicamente, la "copia" è spesso migliore dell'originale.

Quando un emulatore è sufficientemente preciso, può capitare che il gioco emulato abbia un aspetto e prestazioni migliori rispetto all'originale.

Un gioco creato per 480p può essere renderizzato in 1440p o 4K da un emulatore. Quest'ultimo è in grado di renderizzare la geometria a una risoluzione nativa superiore, migliorare il filtro delle texture, utilizzare l'anti-aliasing moderno, correggere il rapporto d'aspetto e, in alcuni casi, rimuovere il limite di frame rate originale. L'emulatore può offrire salvataggi rapidi, riavvolgimento del tempo, texture alternative, correzioni e modifiche che non erano mai esistite sulla console originale.

A volte l'emulatore funziona meglio su Linux che su Windows.

Molti emulatori e layer di traduzione, come Proton, offrono prestazioni migliori su Linux. La spiegazione risiede principalmente nel modo in cui il sistema operativo comunica con l'hardware. Vulkan, un'interfaccia grafica moderna e aperta, offre un minore utilizzo della CPU e un controllo più diretto sulla scheda grafica rispetto agli approcci più datati, ma ancora comunemente utilizzati su Windows, e i driver Linux per Vulkan sono maturati negli ultimi anni al punto da avere spesso un overhead di sistema inferiore rispetto a Windows.

Inoltre, lo strumento DXVK, che fa parte di Proton, traduce le chiamate DirectX in Vulkan in tempo reale, il che è sorprendentemente spesso più veloce rispetto all'esecuzione diretta della chiamata DirectX nativa da parte di Windows, poiché evita alcuni livelli del sistema operativo che semplicemente non esistono su Linux. Linux consente anche una latenza inferiore nella comunicazione tra processi e una pianificazione dei thread più prevedibile all'interno del kernel di sistema, il che rappresenta un vantaggio prezioso per gli emulatori che devono coordinare decine di attività parallele in ogni frame.

Per entrare nel mondo dello sviluppo di emulatori, devi essere un maestro e un pazzo allo stesso tempo.

Mentre ti destreggi tra comandi della CPU, chiamate API, meccanismi di sicurezza e speri silenziosamente che Sony e Nintendo non bussino alla tua porta, devi anche sopportare le elevate aspettative della community per cui stai sviluppando un emulatore senza alcun tornaconto finanziario. Una minoranza, tuttavia, molto rumorosa, nutre spesso aspettative eccessivamente alte e infondate, credendo che sviluppare un software del genere sia relativamente facile. Se esiste un emulatore per Nintendo Switch, svilupparne uno per Nintendo Switch 2 non dovrebbe essere così difficile, giusto?

Ogni nuova scoperta in realtà significa mesi di ricerca di bug, lettura di dump esadecimali di codice macchina e tentativi di comprendere le decisioni degli ingegneri di oggi e di quelli del passato che hanno scritto il codice vent'anni fa senza pensare che qualcuno avrebbe mai provato a ricrearlo su hardware completamente diverso.

La combinazione di testardaggine, curiosità e amore per la preservazione del patrimonio videoludico è ciò che ha reso possibile l'emulazione e il motivo per cui la lotta per ogni nuova generazione di console ricomincerà quasi completamente da capo.