Emulation -> compilation - Page 1

(je tiens à préciser avant tout que je n'y connais pas grand chose en émulation, veuillez donc excuser si il y a des erreurs de raisonement)

En ce moment je suis frustré de ne pas pouvoir faire tourner un émulateur DS sur mon netbook à pleine vitesse- mon processeur est quasiment 10 fois plus puissant, il y'a 100 fois plus de RAM, ce n'est pas acceptable

Si je comprends bien, de manière schématisée, l'émulation fonctionne de la manière suivante:

- une ROM contient des instructions en langage machine pour une architecture donnée
- un émulateur simule cette architecture au sein d'un environement x86 (typiquement) et exécute ces instructions en temps réel.

Du coup, la principale raison pour laquelle un ordinateur actuel ne pourrait pas émuler une PS3 en temps réel (ou que mon netbook ne peut émuler une DS) réside dans cette étape d'interprétation des instructions qui se fait en temps réel.

N'y aurait il pas un moyen de "recompiler" une ROM pour obtenir du code natif sur notre architecture x86?

Par exemple pour la DS, on aurait une librairie d'équivalence des instructions ARM -> x86 et chip 3D DS -> openGL/directX, on passe la ROM dans le mixer, et bam on a un joli exe qui tourne en natif.

Techniquement, c'est faisable? Ca a déjà été fait?

Oui, ça s'appelle la recompilation statique. Le principal problème est de séparer ce qui est du code (à traduire) de ce qui est des données (à laisser tel quel). Ne parlons même pas du code qui se modifie lui-même.

Mais il y a mieux : la recompilation dynamique. En gros ça marche comme un interpréteur normal au début, mais une fois que l'émulateur détecte qu'un bout de code a été exécuté un nombre suffisant de fois pour considérer qu'il est important, il génère à la volée du code natif équivalent qui prendra sa place. Du coup, les perfs augmentent fortement au cours du temps (en pratique, ça semble efficace au bout de quelques secondes).

Sauf que la recompilation dynamique n'as de sens que pour du code qui est executé régulierement, et sur des archi complexes (et ou souvent le code est en language de haut niveau a la base) ie un de la recompilation dynamique sur un jeu NES n'auras que tres peu d'impact, alors que sur une Nintendo64 ça apporte beaucoup.

La recompilation statiques pourrait etre possible en théorie, en pratique, c'est limite impossible, et ce pour plein de raisons, il n'y as pas que les instructions a tranformer, il faut simuler aussi tout le hardware autour du CPU, et une simple recompilation du code ne suffit pas. D'ailleurs dans certains cas, ce n'est la partie "execution" du code non natif qui prend le plus de CPU, mais tout le reste qui est autour...

(pour la recompilation statique, je pensais transcription des opcodes + inlining de l'émulation hardware, hein ^^)

ce qui est d'autant plus complexe

Et bon courage pour faire un recompilateur statique pour un code qui fait du comptage de cycle & co et dont tout dépend de ce genre d'astuces

Donc d'après mes rapides recherche google, aucun ému DS actuel ne pratique de recompilation dynamique/statique.

C'est parce que ça marche correctement sans ou parce que c'est trop casse tête à intégré? Quid de la complexité de la plateforme de la DS? Ca se rapproche de la N64 ou de la GBA?

la nDS est comme une GBA en plus puissant, et je pense que ça doit se rapprocher de la N64 sur certains points, mais le CPU n'a vraiment rien a voir (la N64 a un *vrai* cpu 64bit (MIPS64), ce qui est plus chiant a gerer sur une machine 32bit alors que la nDS a un ARM 32bits plus classique (ARM7 il me semble, mais c'est peut-etre un AMR9)

La recompilation c'est nettement plus difficile à programmer qu'un simple interpréteur (et ça ne me surprend pas qu'il n'en existe pas, j'ai l'impression que les auteurs sont devenus plus paresseux ces dernières années : ils se contentent souvent de simples portages à la va-vite d'émulateurs existants, n'optimisent pas des masses, et l'émulation laisse à désirer...)

Pour la DS, Orion_ pourrait donner des détails, mais à priori ça doit être pas loin de la N64 question complexité...

EDIT : cross

Et dire qu'on peut jouer aux jeux de NES sur 68k.

ben le problème de la recompilation statique (voir dynamique) c'est que tu obtienra jamais un resultat a 100% fidele, ce que l'execution dynamique est elle capable. (je prend l'exemple que je connais le mieux, mais au moins 80% des jeux NES sont tres tres sensible au timings d'execution de chacune des instructions, et il faut peut de choses pour rendre un jeu injouable, et autant en execution a la volée c'est faisable sans trop de difficultée (enfin sil y en a plein) alors que recompiler statiquement/dynamiquement, c'est deja plus discutable, et d'autant plus dur

La NDS a 2 arm, un ARM7 à 33 mhz et un ARM9 à 67 mhz il me semble.

Et du coup, coder un émulateur DS pour iPhone (ARM aussi) serait donc plus faisable si on veut du real time (serait-ce un émulateur d'ailleurs, ou une machine virtuelle?) ?


(Petit parallèle: si je veux coder un émulateur pour apprendre comment ça marche, vous recommendez quoi? NES, ou alors c'est déjà trop hardcore?)

Je te conseillerais pas la NES, mais plutot une machine un poil plus carré genre la sms ou la gamegear (post pavé a prévoir si tu veux savoir pourquoi )

./12 > Le pavé m'intéresse :P (on s'embête le soir, à Oxford, quand on a pas de sous à dépenser )

Par ailleurs, vis à vis du sujet initial, quelqu'un saurait quels émulateurs implémentent les méthodes discutées?

Godzil : pour l'émulation au cycle près, c'est vrai, mais les machines suffisamment puissantes pour que le recompilation dynamique soit intéressante sont généralement assez puissantes pour que les jeux n'utilisent pas d'astuces qui demandent une émulation ultra précise*... exemple, les émulateurs Nintendo 64 se contentent d'une émulation haut niveau, et ça fonctionne très bien

(* au milieu, il reste les machines bien chiantes à émuler, genre Saturn ou Jaguar )

Godzil (./3) :
La recompilation statiques pourrait etre possible en théorie

Bah non en theorie c'a m'a tout l'air indecidable comme probleme, en toute generalite.

Godzil (./12) :
Je te conseillerais pas la NES, mais plutot une machine un poil plus carré genre la sms ou la gamegear (post pavé a prévoir si tu veux savoir pourquoi )

bah t'es pas obligé de lui mettre un pavé, juste lui expliquer que la NES a une architecture archaïque très puissante cependant.

Et pour l'émulateur DS sur Iphone, euhhh... comment dire c'est pas aussi simple. Même si tu as le même proc, après tu as des astuces sur DS que tu ne peux utiliser sur Iphone (les fameux registre, les rotations, etc etc) qui sont quasi natif sur DS. Pas sur Iphone (et rajoute à cela que sur DS tu as 2 proc, et pas de proc 3D, alors que sur Iphone il me semble bien que oui, enfin je connais pas bien l'archi Iphone)

Bon, je laisse les calés en parlé, je suis pas assez doué dans ce domaine.

Mais d'accord avec Godzil, SMS me parait plus simple pour commencer. (même la Gameboy est pas évidente)

Zerosquare (./14) :
Godzil : pour l'émulation au cycle près, c'est vrai, mais les machines suffisamment puissantes pour que le recompilation dynamique soit intéressante sont généralement assez puissantes pour que les jeux n'utilisent pas d'astuces qui demandent une émulation ultra précise*... exemple, les émulateurs Nintendo 64 se contentent d'une émulation haut niveau, et ça fonctionne très bien

(* au milieu, il reste les machines bien chiantes à émuler, genre Saturn ou Jaguar )

Ha mais c'est exactement ce que j'ai dit

Et c'est le cas car, la majoritée du code est écrit en C, donc n'utilisant pas d'astuces (ou peu) que l'on ne peux faire qu'en ASM

Godzil (./12) :
Je te conseillerais pas la NES, mais plutot une machine un poil plus carré genre la sms ou la gamegear (post pavé a prévoir si tu veux savoir pourquoi )

Ben écoute moi ça m'intéresserait vu que j'ai choisi la GB et j'ai quand même l'impression qu'elle est sacrément plus light que la GG

Fuck, j'avais un pavé, et mon navig a planté, j'ai tout perdu


En gros,

la NES est tres simple au niveau hard le CPU (un 6502) est plutot simple, le PPU (Picture Processing Unit, la "carte video" de la NES) est plutot simple, bref, on peux faire un emulateur assez rapidement qui semble donner des resultats, mais on se rend tres vite compte que derriere cette "simplicitée" il y a en fait beaucop de choses, le hard est plutot limité question possibilitée, et pour contourner tout ça, les devs on usé de plein d'astuces qui font que l'émulation de la NES est très sensible aux timings CPU/PPU (par exemple) (il est courant que le code compte exactement le nombre de cycle et il faut que le PPU soit a un état bien précis a un instant T dans le programme pour que tout marche etc...)

Sans compter que la NES est peut-etre une des consoles ou il reste (restait? la derniere fois que j'ai mis ma doc a jour, c'était il y a quelques mois) des points d'ombre ou le comportement exact du hardware est pas très bien connu.

Pour ceux qui se rapelle, le premier emulateur de NES "grand publique" NESticle est en fait un des pire emulateur NES existant, et des emulateur "précis" n'existent que depuis peu, et encore tout n'est pas parfait...

La GameBoy doit etre plus ou moins dans la meme veine, mais un poil mieux définie malgrès tout (les mappers mémoire sont tous connu par exemple)

Pour ce qui est de la SMS/GameGear, le hard est (d'apres mes recherches) au premier abord plus complexe, mais en meme temps toute la machine est beaucoup plus carré, car le hard permet "nativement" de faire plus de choses que la NES, donc on devrais s'attendre a moins de surprises du coté des devs a faire des astuces dans tout les sens pour pallier au limitation du hardware..


Tiens, rien a voir (enfin si un peu) mais ça me fait penser, les deux gros Flop de Nintendo etait du hardware plus puissant que la concurence (N64/GC), alors que leurs gros succes sont des machines moins puissante (NES/SNES/Wii)... A méditer

Ah tiens, je savais pas que la GC était plus puissante que la ps2. J'avais toujours pensé l'inverse. (Faudrait que je m'en trouve une ^^)

La gamecube est clairement supérieure a la PS2 bien qu'inférieure a la XBox 1. Un bon exemple est Resident Evil 4 qui bien moins beau sur PS2.

Godzil (./19) :
Fuck, j'avais un pavé, et mon navig a planté, j'ai tout perdu

Arf...

Godzil (./19) :
La GameBoy doit etre plus ou moins dans la meme veine, mais un poil mieux définie malgrès tout (les mappers mémoire sont tous connu par exemple)
Pour ce qui est de la SMS/GameGear, le hard est (d'apres mes recherches) au premier abord plus complexe, mais en meme temps toute la machine est beaucoup plus carré, car le hard permet "nativement" de faire plus de choses que la NES, donc on devrais s'attendre a moins de surprises du coté des devs a faire des astuces dans tout les sens pour pallier au limitation du hardware..

Hmm en fait sur GB j'ai pas l'impression que les jeux soient si dépendants du timing en fait. Le souci c'est surtout l'accès à la mémoire vidéo qui est interdit lorsque le LCD y accède aussi. Et comme le polling du registre serait trop coûteux, genre un:

    ld hl, $ff41        ; stat
loop:
    bit 1, (hl)
    jr nz, loop

(un truc qui serait bcp plus difficile à faire sur le 6502 )
Amène déjà un délai potentiel de 12+8 cycles (+12 en prélude) sur temps accessible d'à peine ~284 cycles sur 456 au total par ligne. Du coup je sais que certains jeux comptent les cycles pour pouvoir copier des trucs pendant la HBLANK. Mais le problème peut être facilement masqué en autorisant en tout temps l'accès à la VRAM. Théoriquement ça peut poser des problèmes si un jeu compte sur le fait qu'une écriture en VRAM sera rejetée pendant cette période, mais en pratique ça n'a pas l'air d'être le cas.
Sinon la GG a techniquement plus ou moins la même chose que la GB, mais le Z80 est complet et les accès au VDP se font via un port comme sur Mega Drive si mes souvenirs sont bons. Donc c'est peut être un peu plus difficile à se représenter la chose

La GameCube, say trop bien (j'ai pas compris le reste du topic)

Brunni (./22) :

Godzil (./19) :
Fuck, j'avais un pavé, et mon navig a planté, j'ai tout perdu

Arf...

Godzil (./19) :
La GameBoy doit etre plus ou moins dans la meme veine, mais un poil mieux définie malgrès tout (les mappers mémoire sont tous connu par exemple)
Pour ce qui est de la SMS/GameGear, le hard est (d'apres mes recherches) au premier abord plus complexe, mais en meme temps toute la machine est beaucoup plus carré, car le hard permet "nativement" de faire plus de choses que la NES, donc on devrais s'attendre a moins de surprises du coté des devs a faire des astuces dans tout les sens pour pallier au limitation du hardware..

Hmm en fait sur GB j'ai pas l'impression que les jeux soient si dépendants du timing en fait. Le souci c'est surtout l'accès à la mémoire vidéo qui est interdit lorsque le LCD y accède aussi.

En fait, quand j'ai codé mon émulateur GB, c'était dans le but de faire un recompilateur [statique]... Il me fallait un truc pour pouvoir être sur de bien comprendre le fonctionnement de la GB. Et oui, la GB est (nettement) sensible au timing, même si dans beaucoup de jeu ça n'aura qu'une importance légère (le plus important est le timing vidéo) et ce n'est pas forcément si difficile à émuler. Ce qui pose problème (et la raison de pourquoi j'ai fait un émulateur standard avant) c'est la gestion des différents mappers possibles, car un saut à 0x4nnn en MBC-machin tu sais jamais précisément où ça va atterrir. C'est presuqe la seule chose qui rend la recompilation statique vraiment difficile, et éventuellement impossible (à priori non mais bon). Ça et le code [posiblement] copié et éxécuté en RAM... en fait ^^ (Le code généré dynamiquement on peut de toutes façons pas l'émuler à 100% sans inclure un interpréteur et/ou recompilateur dynamique en plus)

d hl, $ff41 ; stat loop: bit 1, (hl) jr nz, loopEt comme le polling du registre serait trop coûteux, genre un: l
(un truc qui serait bcp plus difficile à faire sur le 6502 )
Amène déjà un délai potentiel de 12+8 cycles (+12 en prélude) sur temps accessible d'à peine ~284 cycles sur 456 au total par ligne. Du coup je sais que certains jeux comptent les cycles pour pouvoir copier des trucs pendant la HBLANK. Mais le problème peut être facilement masqué en autorisant en tout temps l'accès à la VRAM. Théoriquement ça peut poser des problèmes si un jeu compte sur le fait qu'une écriture en VRAM sera rejetée pendant cette période, mais en pratique ça n'a pas l'air d'être le cas.
Sinon la GG a techniquement plus ou moins la même chose que la GB, mais le Z80 est complet et les accès au VDP se font via un port comme sur Mega Drive si mes souvenirs sont bons. Donc c'est peut être un peu plus difficile à se représenter la chose

Oui, et le "Z80 complet" (le Z80 quoi...) est beaucoup plus difficile/chiant à émuler que le CPU de la GB pour commencer
Je sais pas si les jeux font usage des "hacks" dégueu offerts mais bon tu te dois à priori de les gérer et...

Ce développeur de 14 ans prétend avoir développé un ému N64 natif pour le 3GS.

http://www.youtube.com/watch?v=dgJqXqZUZtU&feature=player_embedded

Le problème c'est qu'à part cette vidéo, il n'y a aucun détail dispo.

Je suis tenté de crier au fake, mais sait on jamais. Je sais qu'il y'a des spécialistes de l'émulation et du dév iPhone ici- c'est quoi la faisabilité de ce truc, indépendamment de la crédibilité de la vidéo? (je suis surpris car pas mal de gros sites style Engadget relayent l'information qui n'est que dépend que d'une vidéo...)

Perso je n'y connais rien en émulateur, mais sur la vidéo il y a de grandes variations dans le délai entre l'appui sur une touche et la réaction correspondante de Mario (des fois c'est simultané, d'autres il y a un gros écart). Comme l'animation reste toujours étonnement fluide, soit c'est lié à un bug quelconque de son émulateur (qui serait vraiment impressionant pour le coup), soit c'est juste un gros fake, perso je miserais sans trop d'hésitations sur la 2eme possibilité ^^

(en plus de tout ça, vous avez vu comme son émulateur démarre instantanément et en plein milieu du jeu, sans l'écran d'accueil et l'intro ?)

Ah oui tiens j'avais même pas tilté là-dessus alors que c'est encore plus gros

C'est ce que j'ai tendance à me dire, je voulais juste l'avis de développeurs s'y connaissant.

Je suis surpris que des gros sites ( http://www.engadget.com/2009/12/07/iphone-3gs-emulates-n64-blows-minds-in-the-process/ ) relaient l'information sans plus de détails que ça.

Zerosquare (./27) :


(en plus de tout ça, vous avez vu comme son émulateur démarre instantanément et en plein milieu du jeu, sans l'écran d'accueil et l'intro ?)

Ptêt parce qu'il le lance depuis la dernière sauvegarde ?