Windows 95 mostrato in esecuzione su Nintendo 3DS: è il sogno dei retrogamer?

Windows 95 mostrato in esecuzione su Nintendo 3DS: è il sogno dei retrogamer?

Un utente del forum GBATemp è riuscito ad eseguire Windows 95 su un Nintendo 3DS. Sebbene possa sembrare un esercizio di stile e poco altro, l'operazione potrebbe avere parecchi risvolti interessanti

di pubblicata il , alle 17:01 nel canale Videogames
Nintendo
 
16 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Ton90maz08 Gennaio 2016, 21:29 #11
Originariamente inviato da: cdimauro
Vero, ma è pur sempre un ARM11 a 268 MHz...
In realtà...no, occhio a wikipedia e altre fonti, scrivono solo cazzate. Hanno raddoppiato il numero di core (come scritto), ma hanno anche triplicato la frequenza e aggiunto 2 MB di cache L2 assente sul 3ds normale. Praticamente hanno fatto il 3ds come doveva uscire nel 2011, in compagnia di una gpu più decente magari.
E con quella cache l2 potrei azzardare che rivaleggi o superi la ps vita, che ha un cortex a9 a 333-444 MHz e non 1-2 GHz come dicono i siti per boccaloni
cdimauro08 Gennaio 2016, 23:37 #12
Originariamente inviato da: walter sampei
spannometricamente, mettendo che il rapporto emulato tra potenze dei processori sia 10:1 (non so come spiegarlo!!!) sarebbe un processore da 27 mhz. nella migliore delle ipotesi, un 486 da 33 mhz circa, se no come un 386.

non credo ci giri molto, se non roba dos o per windows 3.1

Esattamente.
Originariamente inviato da: Ton90maz
In realtà...no, occhio a wikipedia e altre fonti, scrivono solo cazzate. Hanno raddoppiato il numero di core (come scritto), ma hanno anche triplicato la frequenza e aggiunto 2 MB di cache L2 assente sul 3ds normale. Praticamente hanno fatto il 3ds come doveva uscire nel 2011, in compagnia di una gpu più decente magari.
E con quella cache l2 potrei azzardare che rivaleggi o superi la ps vita, che ha un cortex a9 a 333-444 MHz e non 1-2 GHz come dicono i siti per boccaloni

Beh, se le altre fonti dicono cazzate, non è che tu ne abbia portato qualcuna a tuo sostegno.

L'unico dato concreto è che dovrebbe essere un quad core, ma per emulare un processore x86 non te ne fai proprio nulla degli altri core, e il tallone d'Achille di un PC da emulare è rappresentato proprio dal processore.

Poi rimane pur sempre un ARM11, che non è certo un campione di efficienza/prestazioni, e un x86 è un processore CISC abbastanza complesso, per cui non è facile da emulare quanto potrebbe essere un RISC.

Vuoi un esempio pratico? Guardati le slide di un talk (Writing an 8086 emulator in Python) che ho tenuto lo scorso anno alla PyCon 6. In particolare la slide 39 che mostra come calcolare i flag del processore a seguito di un'operazione aritmetica.

E stiamo parlando di un semplicissimo 8086: immagina quanto sia incasinato emulare un 386 o superiore, specialmente in modalità protetta...

Dimenticavo: la cache L2 è importante (ma è da verificare se ci sia o meno) e contribuisce alle prestazioni, ma non fa certo miracoli.
walter sampei09 Gennaio 2016, 00:26 #13
Originariamente inviato da: cdimauro
Esattamente.

Beh, se le altre fonti dicono cazzate, non è che tu ne abbia portato qualcuna a tuo sostegno.

L'unico dato concreto è che dovrebbe essere un quad core, ma per emulare un processore x86 non te ne fai proprio nulla degli altri core, e il tallone d'Achille di un PC da emulare è rappresentato proprio dal processore.

Poi rimane pur sempre un ARM11, che non è certo un campione di efficienza/prestazioni, e un x86 è un processore CISC abbastanza complesso, per cui non è facile da emulare quanto potrebbe essere un RISC.

Vuoi un esempio pratico? Guardati le slide di un talk (Writing an 8086 emulator in Python) che ho tenuto lo scorso anno alla PyCon 6. In particolare la slide 39 che mostra come calcolare i flag del processore a seguito di un'operazione aritmetica.

E stiamo parlando di un semplicissimo 8086: immagina quanto sia incasinato emulare un 386 o superiore, specialmente in modalità protetta...

Dimenticavo: la cache L2 è importante (ma è da verificare se ci sia o meno) e contribuisce alle prestazioni, ma non fa certo miracoli.


domandone immane: premesso che io ne capisco piu' o meno zero, ipotizzando di avere un arm con almeno due core disponibili per l'emulazione, non si potrebbe usare un core per fare i calcoli e in parallelo un core per impostare i flag del finto 8086? o come sono associate le due cose?

edit: se non erro, la cpu originale del raspberry pi dicevano che era equivalente a spanne a un p2 300 (con grafica pompata), escludendo ovviamente l'overhead dell'emulazione

riedit: dopo aver visto la slide, ho capito che 1)l'architettura x86 e' un casino immane 2)e' stato scelto aros perche' kitty e' sempre kitty
cdimauro09 Gennaio 2016, 06:49 #14
Originariamente inviato da: walter sampei
domandone immane: premesso che io ne capisco piu' o meno zero, ipotizzando di avere un arm con almeno due core disponibili per l'emulazione, non si potrebbe usare un core per fare i calcoli e in parallelo un core per impostare i flag del finto 8086? o come sono associate le due cose?

Assolutamente no, perché l'emulazione di un processore/singolo core/singolo thread hardware è un processo/algoritmo intrinsecamente, irrimediabilmente seriale, che fa e può fare uso soltanto di un singolo core/thread hardware.

Puoi avere migliaia di core, ma sempre e soltanto uno ne sarà usato per l'esecuzione delle istruzioni del processore. Ovviamente a meno che il processore emulato abbia più core e/o thread hardware, e in questo caso a ognuno di essi può essere assegnato un core/thread hardware che ne esegue le istruzioni (e sto semplificando molto, perché non ho nemmeno parlato dei problemi di sincronizzazione che ci sono fra i diversi core/thread hardware del processore emulato. Per maggiori informazioni in merito c'è un interessante articolo sul blog dell'emulatore PCSX2, che entra nel dettaglio).
edit: se non erro, la cpu originale del raspberry pi dicevano che era equivalente a spanne a un p2 300 (con grafica pompata), escludendo ovviamente l'overhead dell'emulazione

Sì, ma il paragone è fra il codice ARM che gira nativamente sul Raspberry, e il codice altrettanto nativo che gira(va) sul Pentium-II. Quindi non c'è nessuna emulazione di mezzo: si tratta di confrontare i due processori col normale codice che macinano.

Da questo si può vedere quanto poco performante sia un ARM11 (anche il vecchio Raspberry ne usa uno), anche perché non dotato di superpipeline (al contrario del P-II, che può eseguire fino a due istruzioni per ciclo di clock, sebbene "in-order", e può contare su una buona FPU).
riedit: dopo aver visto la slide, ho capito che 1)l'architettura x86 e' un casino immane 2)e' stato scelto aros perche' kitty e' sempre kitty

Hai capito tutto.

x86 è un casino, ma da emulare. Per il resto la sua complessità è ormai relegata a qualche milionata di transistor utilizzati per il decoder delle istruzioni e, in misura minore, per l'FPU x87.
Ton90maz09 Gennaio 2016, 11:38 #15
Originariamente inviato da: cdimauro
Esattamente.

Beh, se le altre fonti dicono cazzate, non è che tu ne abbia portato qualcuna a tuo sostegno.

L'unico dato concreto è che dovrebbe essere un quad core, ma per emulare un processore x86 non te ne fai proprio nulla degli altri core, e il tallone d'Achille di un PC da emulare è rappresentato proprio dal processore.

Poi rimane pur sempre un ARM11, che non è certo un campione di efficienza/prestazioni, e un x86 è un processore CISC abbastanza complesso, per cui non è facile da emulare quanto potrebbe essere un RISC.

Vuoi un esempio pratico? Guardati le slide di un talk (Writing an 8086 emulator in Python) che ho tenuto lo scorso anno alla PyCon 6. In particolare la slide 39 che mostra come calcolare i flag del processore a seguito di un'operazione aritmetica.

E stiamo parlando di un semplicissimo 8086: immagina quanto sia incasinato emulare un 386 o superiore, specialmente in modalità protetta...

Dimenticavo: la cache L2 è importante (ma è da verificare se ci sia o meno) e contribuisce alle prestazioni, ma non fa certo miracoli.
Basta andare su 3dsbrew e trovi tutto quanto, in rete c'è anche un homebrew per far andare i giochi del 3ds originale a 804 MHz.
cdimauro09 Gennaio 2016, 12:03 #16
804Mhz è un valore che porta il New 3DS a essere comparabile al vecchio Raspeberry Pi (che gira a 700Mhz, ma che viene overclockato anche 900Mhz).

Per cui le prestazioni in emulazione saranno molto simili, con un leggero vantaggio per il New 3DS, rispetto al R-Pi con clock standard.

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^