Zerosquare (./4) :
Au fond, si le fonctionnement du hardware est connu avec précision, écrire un émulateur précis n'est pas si difficile : on émule brutalement cycle par cycle, et vogue la galère. Optimiser ça pour ça tourne vite... c'est déjà nettement plus dur.

C'est sûr que toute la difficulté réside dans la vitesse, jusqu'à un certain point quand même. Comme il l'a dit la plupart des émulateurs ont un timing off, et ce fut par exemple le cas également de mon ému GB, pourtant je me suis appuyé sur les specs les plus précises que je pouvais avoir, sans penser à l'opti du tout dans un premier temps (c'était un projet d'école).

Qu'est-ce à dire? Une fois que tu vois que c'est faux, après c'est simple d'améliorer la vitesse, à la limite tu n'as pas besoin de faire des tests stricts pour t'assurer que ça n'a aucun effet de bord, tant que rien n'est visible. Puis comme ton timing est off certains jeux qui avaient tendance à ralentir légèrement deviendront encore pires (d'autres iront peut être plus vite au contraire). Une solution est d'augmenter la fréquence du CPU virtuel, mais c'est crade.

C'est ce qui arrive dans ~tous les émulateurs actuels. Vouloir faire un truc vraiment précis est très difficile, certainement largement plus que faire un truc rapide car la plupart des jeux ne sont que des applicatifs, qui ne présentent pas d’exigence élevée pour tourner. Le combo ultime c'est bien sûr de faire précis et rapide, et c'est très difficile car le coût des hacks type calcul du prochain événement nécessitant une inspection détaillée de telle ou telle partie peut se révéler dans certains jeux ou certaines démos largement supérieur à celui d'une implémentation naïve, et c'est justement ce type de softs qu'on peut souhaiter vouloir faire tourner puisque les autres émus n'en sont pas capables. Donc au lieu de demander 1 GHz pour Mario World et 4 pour Yoshi's Island on préférera un émulateur qui en demande constamment 2-3, car on sait quel hard il faut acheter