C'est un problème extrêmement complexe mine de rien... mais je vais essayer de te faire une réponse à peu près compréhensible et complète (tant que faire se peut).
1) Emuler, c'est quoi donc?
Le principe général de faire de l'émulation, c'est de faire croire à un programme (ton jeu par exemple) qu'il fonctionne dans l'environnement où il est prévu de s'exécuter. En l'espèce, cela comprend donc deux couches distinctes, qui sont la partie logicielle (très schématiquement l'OS de la console) et la partie matérielle (le processeur, la carte graphique...).
De ce fait: émuler, cela veut donc dire qu'on fait croire au jeu que ton processeur serait un Cell, que ta carte graphique est celle de la console, et que l'OS est celui de la PS3.
2) Est-ce simple d'émuler?
Globalement... non, et loin de là même.
Schématisons: chaque système a des "instructions" qui sont intégrées soit au matériel (instructions de la carte graphique par exemple), soit à l'OS. Bien entendu, ton OS et celui de la console n'ont généralement rien à voir (si l'on excepte les OS Microsoft, mais c'est un autre débat). Dans ces conditions, émuler les instructions, cela revient à faire ceci
Le jeu demande : affiche moi l'objet 3D
La console répond : OK, j'utilise l'instruction AAABBBZZZ pour ça
Or ton Windows, pour faire la même chose, il fera l'instruction AADDERGCE
Donc, il faut une couche logicielle pour transformer toute demande de la manière suivante:
Le jeu demande : affiche moi l'objet 3D
L'émulateur gère ainsi: OK, j'utilise l'instruction AADDERGCE pour que Windows comprenne, à la place de AAABBBZZZ qu'il ne comprend pas
Le PC répond : AADDERGCE? Ok, je réponds alors "objet affiché par AADDERGCE
L'émulateur intercepte et fait : Il faut que je dise au jeu que l'instruction AAABBBZZZ s'est bien exécutée, parce que AADDERGCE a fonctionné
Tu vois donc que le programme intermédiaire doit non seulement recomposer les demandes logicielles, et donc les transcrire pour que l'OS local comprenne, mais également renvoyer les retours de l'OS (par exemple les ordres de la manette), de sorte à ce que le jeu fonctionne correctement.
3) quels sont les soucis de l'émulation?
Tout d'abord, et en première ligne: le code! C'est assez simple à comprendre, et très difficile à contourner. Schématiquement, comme je l'ai dit précédemment, chaque instruction est codée pour une action donnée. Cela va depuis une simple addition mathématique, jusqu'aux traitements complexes de textures.
Mais il arrive (souvent) que nombre d'instructions ne soient pas intégrées de la même manière! Explication:
une carte graphique console peut intégrer un traitement spécifique (disons l'éclairage dynamique). Côté PC, c'est une partie du pilote logiciel qui gère cela, pour le transformer en ordres simples pour la carte 3D. Tu comprendras donc qu'un ordre "simple" côté console peut amener à beaucoup de code côté émulation.
Mais ça n'est pas tout! La puissance de traitement d'une console moderne s'appuie sur des architectures totalement différentes de celles de nos PC. Le Cell est une architecture propriétaire, puissante, ce qui imposerait une surcouche logicielle très complexe, gourmande... par conséquent peu performante.
4) Mais pourtant, il y a plein d'émulateurs!
Oui, mais de quelles générations de consoles? Jusqu'à, en gros, la PS1, cela peut fonctionner, tant l'écart réel de puissance entre un PC et une console reste gérable. En effet, les processeurs PC ont tellement de capacité que faire tourner un programme d'émulation, même très lourd, n'est plus trop un souci. Cela en devient un pour des environnements autrement plus récents et modernes.
5) Et l'émulation... pourquoi parle-t-on de Roms mémoires et jeux?
Parce qu'il y a (souvent) besoin de deux types de ROM
- La Rom machine, qui est une "image" mémoire de l'OS de la machine source. En gros, c'est un clone de l'OS, de manière à ce que l'émulateur soit au plus près du comportement d'origine. C'est ce que tu as avec les Rom des Atari ST, et pour certains émulateurs consoles.
- La Rom jeu, c'est une copie conforme (ISO) du jeu, de sorte à ne pas avoir à disposer d'un équipement complémentaire. C'est essentiellement une résultante du format console cartouche, parce qu'il est très rare de trouver un PC auquel on a adossé un port de connexion spécial pour ces cartouches.
Dans tous les cas, l'émulation, c'est un défi technique majeur, qui revient à créer un traducteur dynamique entre un OS console, et un OS PC. C'est complexe, délicat, sensible au codage, et aussi bien fait qu'il soit, il existera toujours des programmes qui ne fonctionneront pas. Pourquoi? Parce que les dits émulateurs sont développés hors du périmètre original, par des fans, donc sans documentation précise du processeur/langage d'origine. En gros, il font ce qu'on appelle du reverse engeenering, soit, en clair "j'ai constaté que le programme fait ci ou ça quand on lui demande un truc spécifique, j'en déduis donc que l'instruction c'est ça"... or, cette méthode ne couvrira pas tous les cas d'utilisation existants, loin de là même.
Donc émuler... oui, mais pas si simple!