bla bla du début

OK, mais bon ... Je dois connaître quoi pour suivre ce cours ?

Halte, ici le juge, est-ce légal votre truc ?

Soit, mais ... C'est quoi exactement émuler une machine ?

L'interprétation

Tantque (CPU fonctionne)
  je lis l'opcode
  j'interpréte l'opcode
FinTantque

La recompilation statique

La recompilation dynamique

OK, mais je trouve comment des infos sur la machine à émuler ?

Bien, j'ai les infos, mais je commence comment sur ma DS ou ma GBA pour coder un émulateur ?

Bien, coté DS,pour ce premier jour consistant à une prise de contact, nous allons donc juste présenter comment les 2 processeurs de la DS sont exploités pour réaliser notre émulateur.
L'arm7, tout d'abord, comme à son habitude, va se borner à gérer les touches, le stylet et le son que l'on va vouloir produire avec notre émulateur.
Le code de l'arm7 se résume à un simple fichier main.c contenant trois parties :

1) la gestion du son, limité dans notre cas au fait de jouer un fichier de type WAV sans répétition.

2) la gestion du stylet, déclenché par l'interruption VCOUNT (au bout de 80 lignes écrans), permettant de remplir la structure IPC (structure de communication entre l'arm7 et l'arm9).

3) le déclenchement du son, réalisé par l'interruption VBLANK (à chaque fin d'affichage écran donc) , qui se limite à regarder si l'arm9 demande à l'arm7 de jouer un son.

4) le programme principal, qui prépare les interruptions et attend que ces dernières se déclenchent :) !

L'arm9 sera le coeur de notre émulateur et va donc se charger l'émuler le CPU de notre machine ainsi que de mettre à jour le graphisme. Sans rentrer dans les détails pour l'instant, on peut tout de même voir qu'il nous faut un certain nombre de fonctions (contrairement à la version arm7, je détaillerais ces fonctions dans chaque cours, ces dernières allant évoluer au fur et à mesure des cours).

1) l'initialisation de la mémoire, contenant toutes les variables que l'on va utiliser avec leur valeur par défaut.

2) l'initialisation de notre émulateur, contenant l'initialisation de la FATLIB (pour charger les fichiers ensuite).

3) la boucle principale de notre émulateur, qui se borne à rien faire pour l'instant :)

4) le programme principal, qui, si l'initialisation s'est bien passée, réalise l'exécution de notre émulateur.

Le code source complet, avec les répertoires, est disponible en bas de cette page. Il faut mettre ce dernier à la racine de votre disque dur.

Voici le résultat de l'exécution de cet émulateur, qui pour l'instant ne fait rien ^^.

Attention au makefile principal, il contient le chemin vers le devkitarm et demande donc à être modifié suivant votre configuration (dans la mienne, le devkitarm se trouve sur le disque D: de ma machine, dans un répertoire nommé ndsdev).

D'accord, mais , le CPU à émuler, il doit réagir comment ?

Gérer les opérations CPU

• le PC, pour Programme Counter, c'est en fait lui qui garde en mémoire l'endroit où se trouve l'instruction que l'on exécute
• le SP, pour Stack Pointer, est en fait celui qui garde en mémoire l'endroit que l'on appele "la pile", c'est à dire une zone particulière où est sauvegardée les données que l'on utilise pour les restituer ensuite suivant les besoins. La pile est très importante et doit être bien dimensionnée, sinon, il arrive que l'on plante notre programme à cause d'un débordement de pile ;)

Aussi, on a besoin d'un troisième registre, le SR, pour Status Register, qui garde en mémoire l'état des dernières opérations réalisées, pour savoir si une opération donne un résultat nul, on encore une opération qui dépasse le nombre le plus élevé supporté par notre CPU, etc ...

Enfin, nous aurons aussi besoin d'une variable qui va compter le temps que prend chaque instruction exécutée dans une unité de temps que l'on appelle des cycles d'horloge, c'est à dire des temps de bases de notre CPU.
Les cycles d'horloge permettent de faire "battre le coeur" de notre CPU à la vitesse qu'il doit s'exécuter normalement et ainsi de laisser le temps à notre émulateur de raffraîchir l'écran, de gérer les touches, etc ....
Par exemple, un Z80 cadencé à 4Mhz battera donc à 4000000 cycles d'horloge par seconde. Sachant qu'un écran est à 60 Hz, soit 60 fois mis à jour par seconde, nous aurons donc 4000000/60 cycles avant de raffraichir un écran complet et donc de faire un nouveau cycle d'émulation.
Il va de soit que toute la difficulté de l'émulation est d'arriver à tenir cette cadence (à 60Hz ou une autre fréquence suivant le taux de raffraichissement demandé par l'émulateur).
Je me permets donc de vous introduire maintenant (le premier qui rigole sort et va chez le directeur prendre sa punition !) le petit bout de code qui va vérifier que l'on tient bien le rythme par rapport à l'émulation demandée.

Ce code, assez simple, compte le nbre de frames à chaque tour d'émulation, si on dépasse les 60, on compare au compteur mis à jour dans l'interruption VBL de la DS ou de la GBA (qui est déclenchée 60 fois par seconde aussi) et on affiche le pourcentage de perte ou de gain par rapport à ça, simple non ?
Bien entendu, vous verrez qu'en exécutant le code, on ne dépasse jamais les 100% (ou presque ...), pourquoi, tout simplement car on attend l'interruption VBL de la DS après l'affichage !
Cette intruction d'attente swiWaitForVBlank(); (ou VBlankIntrWait(); pour la GBA) peut ^tre mise en commentaire pour voir la vitesse réelle de l'émulateur sans attendre (attention, cela SPEED !!!))
Si on veut raffraîchir l'écran à chaque ligne, on divisera encore ce temps par le nombre de lignes gérées par le processeur graphique de notre machine émulée.
Vous avez donc compris qu'une émulation précise d'un machine oblige à compter le temps que prend chaque instruction émulée, en nombre de cycle d'horloge.

Pour résumer, notre émulation peut se synthétiser à faire les opérations suivantes :

PC = PCInitial;
SP = SPinitiale;
Cycles = 0;
 ...
while(CPUfonctionne) {
  OpCode=LireMemoire(PC++);
  switch(OpCode) {
    case OpCode1:
       ...
      Cycles += temps de l'instruction OpCode1;
      break;
    case OpCode2:
       ...
       Cycles += temps de l'instruction OpCode2;
      break;
  }
  if (Cycles>CYCLESPARTRAME) {
    GereTouches();
    GereEcran();
    ...
  }
}

Gérer les accès mémoires

Donnee=Memoire[Adresse1]; // Lecture de l'adresse Adresse1 
Memoire[Adresse2]=Donnee; // Ecriture à l'adresse Adresse2

Hal8000 Jour 1  (136 fois)	23 Jan 2008 | size: 150 kB