Non, en gros ca marche comme ca mais sache que tous les émulateurs n'utilisent pas tous la recompilation dynamiques, tout simplement parce que le besoin ne s'en fait pas sentir (pour un émulateur Chip8 par exemple).
Il faut soulever les contraintes des gpu qui ont, pour certains, leur propre codage de la palette, pixels (cf la pc engine, la saturn), il faut donc adapter ca.
Pour le cpu, pour chaque mnémonique (terme définissant une action comme ADD pour l'addition, MUL pour la multiplication ...) correspond une opération de code (opcode). Pour cela, en terme de programmation, il y a plusieurs méthode mais la plus simple consiste à faire des macros pour chaque mnémonique.
Chaque macro appelant une fonction se chargeant d'éxécuter l'opcode et enfin, de se faire un tableau de pointeur sur fonction.
De la, on est pres à se faire une API pour initialiser, arreter, mettre à jour (le compteur de cycle par exemple), brancher (les fonctions) via un switch ...
Pour le son, il n'y a pas trop de difficulté technique si ce n'est le manque de doc précise (c'était le cas pour le scsp qui manque d'ailleur de quelques instructions).
Il faut savoir que programmer un émulateur comme la PS2 est un travail tres ardu car d'une part, les docs dispo son mal faite voire fausse (cf le forum d'ngemu), il faut travailler sur des variables de 128 bits donc consommatrices en ressources (en fait une structure de 2 variables 64 bits). Il faut aussi émuler les appels système issus du BIOS (les fameux syscalls), gérer les DMA, le SIF, les différents services propres à la console (tout comme pour la GameCube) et surtout, les fameux vectors GPU, extrêmement consommateur en ressources système.
Voila ce qui me vient à l'esprit, j'ai surement oublié des choses de mon coté
Il faut soulever les contraintes des gpu qui ont, pour certains, leur propre codage de la palette, pixels (cf la pc engine, la saturn), il faut donc adapter ca.
Pour le cpu, pour chaque mnémonique (terme définissant une action comme ADD pour l'addition, MUL pour la multiplication ...) correspond une opération de code (opcode). Pour cela, en terme de programmation, il y a plusieurs méthode mais la plus simple consiste à faire des macros pour chaque mnémonique.
Chaque macro appelant une fonction se chargeant d'éxécuter l'opcode et enfin, de se faire un tableau de pointeur sur fonction.
De la, on est pres à se faire une API pour initialiser, arreter, mettre à jour (le compteur de cycle par exemple), brancher (les fonctions) via un switch ...
Pour le son, il n'y a pas trop de difficulté technique si ce n'est le manque de doc précise (c'était le cas pour le scsp qui manque d'ailleur de quelques instructions).
Il faut savoir que programmer un émulateur comme la PS2 est un travail tres ardu car d'une part, les docs dispo son mal faite voire fausse (cf le forum d'ngemu), il faut travailler sur des variables de 128 bits donc consommatrices en ressources (en fait une structure de 2 variables 64 bits). Il faut aussi émuler les appels système issus du BIOS (les fameux syscalls), gérer les DMA, le SIF, les différents services propres à la console (tout comme pour la GameCube) et surtout, les fameux vectors GPU, extrêmement consommateur en ressources système.
Voila ce qui me vient à l'esprit, j'ai surement oublié des choses de mon coté
Commentaire