Discussion :

[ABandApart]

Bonjour,
Je vous rassure tout de suite je ne vais pas vous demander : "Comment qu'on fait un émulateur???".

Revenons a nos moutons :
J'aimerais bien comprendre comment marchent ces émulateurs donc le mieux est d'en coder un: une game boy de première génération.
J'ai déjà fait quelques recherches, et d’après ce que j'ai compris il s'agit de simuler le comportement d'un processeur (ARM dans ce cas ci il me semble), un peu comme un korewar.

Voici les technologies que je compte utiliser.
- C / C++ (encore a décider)
- SDL

Voila un document que j'ai trouvé?
http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf

Donc voila mes questions:

• - Déja suis-je sur la bonne voie?
• - Le graphique se passe t'il également en asm?
• - Combien de temps en moyenne pour coder quelque chose de basique?
• - Auriez vous de la documentation?

Merci d'avance pour vos réponses.

[Obsidian]

L'idée est effectivement d'émuler le fonctionnement de l'ordinateur lui-même (Game Boy, Amstrad CPC, TO8D ou autre…) et c'est un travail passionnant. Mais c'est long, et il faut avoir la documentation.

Une fois que tu as écrit un programme qui recrée toutes les fonctions du micro-processeur, tu n'as plus qu'à prendre les ROMs originales de la machine émulée et les soumettre à ton programme, qui va les exécuter.

C/C++ et SDL sont effectivement de bons points de départ, surtout que la différence de puissance entre un Game Boy de 1989 et une machine récente est considérable, donc tu ne seras pas trop pénalisé par les coûts de fonctionnement des libs que tu utilises. Par contre, ré-implémenter un micro-processeur, ça nécessite de savoir comment il fonctionne, et donc d'avoir en soi de bonnes bases en assembleur.

Tu vas alors rencontrer deux difficultés : la première et la plus petite, c'est qu'implémenter le processeur ne suffira pas : il faudra recréer tout l'environnement de ta machine. La seconde et la plus importante : sur ces machines, la durée d'exécution des instructions en langage machine, en nombre de cycles, occupe une place très importante. Se contenter d'accomplir l'opération décrite par chaque instruction ne suffit pas. Si tu ne t'en soucies pas, au mieux les logiciels seront inutilisables sur ta machine parce que trop rapide, au pire ils ne fonctionneront pas du tout.

Cela dit, cela ne t'empêche pas de commencer. Même s'il y aura des tâtonnements à faire, voir ces vieux logiciels reprendre vie à travers ton produit est quelque chose de magique.

[ABandApart]

Tu vas alors rencontrer deux difficultés : la première et la plus petite, c'est qu'implémenter le processeur ne suffira pas : il faudra recréer tout l'environnement de ta machine.

C'est a dire plus exactement. Les entrées sorties : clavier / écran?

La seconde et la plus importante : sur ces machines, la durée d'exécution des instructions en langage machine, en nombre de cycles, occupe une place très importante. Se contenter d'accomplir l'opération décrite par chaque instruction ne suffit pas. Si tu ne t'en soucies pas, au mieux les logiciels seront inutilisables sur ta machine parce que trop rapide, au pire ils ne fonctionneront pas du tout.

J'ai pas super bien compris ce que tu voulais dire. Si tu parles de la vitesse d’exécution, un simple timer devrai suffire entre chaque cycle non?

[Obsidian]

C'est a dire plus exactement. Les entrées sorties : clavier / écran?

Oui. Mais également le processeur sonore. S'il y a des routines dédiées et que tu peux les reconnaître, tu pourras tenter d'appeler les fonctions de ton O.S. chaque fois que le programme Game Boy y fait appel, mais comme il y a de fortes chances pour que le programme en question le pilote directement, tu auras plus vraissemblablement à ré-émuler la circuiterie sonore de la même façon que tu auras réécrit le micro-processeur.

Ce n'est pas forcément difficile mais ça demande du temps. Et encore, estime-toi heureux. Sur les ordinateurs 8 bits personnels ou familiaux, il fallait aussi gérer le lecteur de disquettes. Et là, pas d'interface ATA comme sur les disques durs modernes. On pilotait tout à la main et la durée des cycles était critique.

J'ai pas super bien compris ce que tu voulais dire. Si tu parles de la vitesse d’exécution, un simple timer devrai suffire entre chaque cycle non?

Oui, parce qu'aujourd'hui il y a un gap énorme entre les fréquences des micro-processeurs modernes et celui d'un Game Boy (il me semble que c'était un Z80 modifié, n'est-ce pas ? Je m'y suis penché jadis, mais je ne me souviens plus). Mais même là, il faudra un timer très précis, et être interrompu si souvent risque de te coûter cher en temps CPU (ce qui n'est pas bien grave).

Il y a aussi la manière dont tu vas implémenter ce CPU. Si c'est avec un bête alarm() ou équivalent, il y a de fortes chances pour qu'il ne soit ni assez rapide, ni assez précis, et qu'il passe de toutes façons trop de temps en mode noyau ou autre. Enfin, ce sera à toi de faire ces expériences. Après tout, c'est bien pour cela que tu écris un émulateur (si ton but est seulement de disposer d'un émulateur Game Boy, il en existe déjà).

[ABandApart]

Ok! Merci beaucoup pour tes réponses qui m'ont beaucoup aidé.
En tout cas si quelqu'un a de la doc je suis preneur.

[huit_six]

Bonjour,
Comme je traine par là, j'essaye d'apporter ma maigre contribution.
Peut-être que jeter un œil aux sources d'un émulateur déjà existant pourrait t'être utile. Personnellement, je suis en train d'essayer de comprendre le fonctionnement de javaboy (émulateur java dont le développement est arrêté et qui bugge pas mal d'ailleurs), mais il y en a certainement d'autres qui fonctionnent mieux à étudier.