Cartouche et minuteur
Gameboj – Étape 6

La principale différence existant entre les types de cartouches est la taille de la mémoire morte et la complexité du contrôleur mémoire, les deux étant liés.

Dans les cartouches les plus simples, comme celles que nous simulerons, le contrôleur mémoire est très simple car il y a une correspondance directe entre les adresses de la plage 0 à 7FFF₁₆ et les octets de la mémoire morte.

Dans les cartouches plus complexes, le contrôleur mémoire permet d'accéder à une mémoire morte de plus de 32 768 octets en rendant visible différentes tranches de la mémoire dans la plage allant de 4000₁₆ à 7FFF₁₆, en fonction de commandes qu'on lui transmet. On dit alors que la mémoire morte est organisée en banques (banks).

Pour cette raison, le contrôleur de la mémoire morte de la cartouche est généralement appelé contrôleur de banque mémoire (memory bank controller ou MBC) et pas simplement « contrôleur mémoire ». Nous conserverons cette terminologie ici, même si notre « contrôleur de banque mémoire » n'a en réalité aucune notion de banque.

Une particularité de la mémoire morte stockée sur la cartouche est qu'elle ne contient pas seulement le code et les données du jeu, mais également un en-tête situé entre les adresses 104₁₆ et 150₁₆ (exclus). Cet en-tête contient différentes informations sur le jeu contenu dans la cartouche. La table ci-dessous résume les parties les plus intéressantes (pour nous) de cet en-tête, une description plus complète étant disponible sur ce site Web.

Pour l'instant, seul l'octet à l'adresse 147₁₆ nous intéresse, car il décrit le type de cartouche, donc le type de contrôleur mémoire qu'elle contient. La seule valeur que notre simulateur acceptera à cette adresse est 0, qui représente une cartouche dotée d'une mémoire de 32 768 octets.

Le simulateur Game Boy développé dans le cadre de ce projet étant un programme, il n'est bien entendu pas possible de lui donner une cartouche physique en paramètre.

Au lieu de cela, on lui fournira un fichier ROM (ROM file). Comme son nom l'indique, un fichier ROM contient les données de la mémoire morte d'une cartouche. Nous mettrons à votre disposition différents fichiers ROM au fil des étapes, afin que vous puissiez tester votre simulateur. Certains sont d'ailleurs fournis à la fin de cette étape-ci.

Pour illustrer la structure d'un fichier ROM, les 352 premiers octets de celui contenant le jeu Tetris sont présentés ci-dessous. Chaque ligne donne d'abord la position dans le fichier du premier octet de la ligne, puis la valeur des 16 octets suivants, et finalement leur représentation textuelle lorsqu'on les décode avec l'encodage ASCII — les caractères de contrôle ou invalides étant remplacés par des points. Notez que toutes les valeurs sont en base 16.

000  c3 0c 02 00 00 00 00 00  c3 0c 02 ff ff ff ff ff  |................|
010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
020  ff ff ff ff ff ff ff ff  87 e1 5f 16 00 19 5e 23  |.........._...^#|
030  56 d5 e1 e9 ff ff ff ff  ff ff ff ff ff ff ff ff  |V...............|
040  c3 7e 01 ff ff ff ff ff  c3 be 26 ff ff ff ff ff  |.~........&.....|
050  c3 be 26 ff ff ff ff ff  c3 5b 00 f5 e5 d5 c5 cd  |..&......[......|
060  6b 00 3e 01 e0 cc c1 d1  e1 f1 d9 f0 cd ef 78 00  |k.>...........x.|
070  9f 00 a4 00 ba 00 ea 27  f0 e1 fe 07 28 08 fe 06  |.......'....(...|
080  c8 3e 06 e0 e1 c9 f0 01  fe 55 20 08 3e 29 e0 cb  |.>.......U .>)..|
090  3e 01 18 08 fe 29 c0 3e  55 e0 cb af e0 02 c9 f0  |>....).>U.......|
0a0  01 e0 d0 c9 f0 01 e0 d0  f0 cb fe 29 c8 f0 cf e0  |...........)....|
0b0  01 3e ff e0 cf 3e 80 e0  02 c9 f0 01 e0 d0 f0 cb  |.>...>..........|
0c0  fe 29 c8 f0 cf e0 01 fb  cd 98 0a 3e 80 e0 02 c9  |.).........>....|
0d0  f0 cd fe 02 c0 af e0 0f  fb c9 ff ff ff ff ff ff  |................|
0e0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
100  00 c3 50 01 ce ed 66 66  cc 0d 00 0b 03 73 00 83  |..P...ff.....s..|
110  00 0c 00 0d 00 08 11 1f  88 89 00 0e dc cc 6e e6  |..............n.|
120  dd dd d9 99 bb bb 67 63  6e 0e ec cc dd dc 99 9f  |......gcn.......|
130  bb b9 33 3e 54 45 54 52  49 53 00 00 00 00 00 00  |..3>TETRIS......|
140  00 00 00 00 00 00 00 00  00 00 00 01 01 0a 16 bf  |................|
150  c3 0c 02 cd e3 29 f0 41  e6 03 20 fa 46 f0 41 e6  |.....).A.. .F.A.|

En examinant ce fichier, on constate qu'à la position 147₁₆ — qui correspond à la même adresse dans l'espace d'adressage du Game Boy — se trouve la valeur 0, indiquant qu'il s'agit d'une cartouche simple ne comportant rien d'autre qu'une mémoire morte de 32 768 octets. Bien évidemment, le fichier ROM lui-même fait également cette taille.

D'autre part, entre la position 134₁₆ et 143₁₆, on trouve les octets

54 45 54 52 49 53 00 00 00 00 00 00 00 00 00 00

qui représentent la chaîne de caractères TETRIS encodée en ASCII, visible dans la colonne de droite, suivie de 10 octets nuls.

Finalement, à la position 40₁₆ — adresse du gestionnaire d'interruption 0 (VBLANK) — on trouve les octets

c3 7e 01

qui ne sont rien d'autre que l'encodage de l'instruction JP 17E. Cela signifie que le code chargé de gérer l'interruption VBLANK de Tetris se trouve à l'adresse 17E₁₆. Et ainsi de suite.

Le minuteur du Game Boy n'échappe pas à cette règle puisque sa composante principale est un compteur 16 bits dont la valeur est incrémentée de 1 unité à chaque battement d'horloge, donc de 4 unités à chaque cycle. Ce compteur « boucle » une fois la valeur maximale atteinte. Cela signifie que si sa valeur vaut FFFF₁₆ à un battement d'horloge donné, elle vaudra 0 au suivant. Etant donné que l'horloge du Game Boy a une fréquence de 2²² Hz, le compteur du minuteur revient à zéro 64 fois par secondes (2⁶).

En plus de ce compteur 16 bits, appelé ci-après compteur principal, le minuteur du Game Boy possède un compteur secondaire nommé TIMA. Il s'agit cette fois d'un compteur 8 bits, dont la valeur est déterminée selon une logique plus complexe que celle utilisée pour le compteur principal.

En gros, l'idée est que le compteur secondaire est incrémenté chaque fois qu'un bit donné du compteur principal passe de 1 à 0. Le bit du compteur principal utilisé dépend d'une configuration, et peut être celui d'index 3, 5, 7 ou 9. Par exemple, si le bit 3 est utilisé, alors le compteur secondaire est incrémenté chaque fois que les 4 bits de poids faible du compteur principal passent de 1111 à 0000, ce qui se produit tous les 16 coups d'horloge, donc tous les 4 cycles. Si le bit 5 est utilisé, alors le compteur secondaire est incrémenté chaque fois que les 6 bits de poids faible du compteur principal passent de 111111 à 000000, ce qui se produit tous les 64 coups d'horloge, donc tous les 16 cycles. Et ainsi de suite.

Lorsque le compteur secondaire est à sa valeur maximale (FF₁₆) et qu'il est incrémenté, deux choses se passent :

• le minuteur lève l'interruption TIMER du processeur,
• plutôt que d'être réinitialisé à 0 comme le compteur principal, le compteur secondaire est réinitialisé à la valeur stockée dans un de ses registres, nommé TMA.

Ce comportement peut paraître compliqué et arbitraire, mais il permet au programme utilisant le minuteur de configurer assez finement la fréquence à laquelle l'interruption TIMER est levée, en choisissant judicieusement le bit du compteur principal utilisé pour incrémenter le secondaire, ainsi que la valeur de TMA.

Le minuteur du Game Boy possède un total de quatre registres qui sont tous au moins partiellement « mappés en mémoire », c-à-d exposés sur le bus :

1. le compteur principal, 16 bits, dont les 8 bits de poids fort uniquement sont exposés à l'adresse FF04₁₆,
2. le compteur secondaire, 8 bits, nommé TIMA et exposé à l'adresse FF05₁₆,
3. la valeur de réinitialisation du compteur secondaire, nommée TMA et exposée à l'adresse FF06₁₆,
4. la configuration du minuteur, nommée TAC et exposée à l'adresse FF07₁₆.

Seuls les 3 bits de poids faible du registre TAC sont utilisés pour configurer le minuteur. Le bit d'index 2 détermine si le minuteur est activé (lorsqu'il vaut 1) ou désactivé (lorsqu'il vaut 0). Les deux bits de poids faible, d'index 1 et 0, déterminent quant à eux quel bit du compteur principal est utilisé pour savoir quand incrémenter le secondaire, selon la table suivante :

Ces registres peuvent à la fois être lus et écrits via le bus. Notez que l'écriture d'une valeur quelconque à l'adresse FF04₁₆ provoque la remise à zéro de la totalité des bits du compteur principal.

La manière dont le compteur secondaire est incrémenté est en réalité légèrement plus complexe que celle décrite ci-dessus.

Pour la décrire, appelons l'état du minuteur la conjonction (et) logique entre :

1. le bit 2 du registre TAC (qui [dés]active le minuteur), et
2. le bit du compteur principal désigné par les 2 bits de poids faible du registre TAC.

L'état est une valeur booléenne qui peut changer pour différentes raisons : soit parce que l'un des 3 bits de poids faible du registre TAC change, soit parce que le bit du compteur désigné par les 2 bits de poids faible de TAC change. Et c'est justement lorsque cet état passe de vrai à faux que le compteur secondaire est incrémenté.

Notez que cela implique le comportement simplifié décrit plus haut. Par exemple, admettons que les 4 bits du compteur principal valent 1111 et que les 3 bits de poids faible du registre TAC valent 101. A ce moment, l'état du minuteur est vrai (car le bit 2 de TAC est vrai, de même que le bit 3 du compteur). Lorsque le compteur est incrémenté, ses 4 bits de poids faible deviennent 0000, et l'état passe alors à faux. En raison de cette transition de vrai à faux, le compteur secondaire est incrémenté.

Toutefois, il existe aussi des cas dans lesquels le compteur secondaire est incrémenté mais qui ne sont pas couverts par la description simplifiée plus haut. Par exemple, admettons que les 4 bits du compteur principal valent 1000 et les 3 bits de poids faible de TAC valent 101. A ce moment, l'état du minuteur est vrai, pour les mêmes raisons que celles décrites plus haut. Or si la valeur de TAC est changée à ce moment, via une écriture sur le bus, pour faire passer ses 3 bits de poids faible à 001, alors l'état du minuteur devient faux et le compteur secondaire est également incrémenté !

La principale difficulté rencontrée lors de l'écriture de la classe Timer est celle de la mise à jour du compteur secondaire. En effet, celui-ci doit être incrémenté selon la règle relativement complexe décrite plus haut.

Pour ce faire, nous vous suggérons de procéder ainsi :

1. définissez une méthode privée nommée p.ex. state et retournant ce que nous avons appelé l'état du minuteur, c-à-d la conjonction logique du bit 2 du registre TAC et du bit du compteur principal désigné par les 2 bits de poids faible de ce même registre,
2. définissez une méthode privée nommée p.ex. incIfChange prenant en argument une valeur booléenne représentant l'état précédent et incrémentant le compteur secondaire si et seulement si l'état passé en argument est vrai et l'état actuel (retourné par state) est faux.

Ensuite, chaque fois que vous écrivez du code modifiant soit le contenu du registre TAC, soit celui du compteur, procédez ainsi :

1. obtenez l'état courant, appelons-le s0, et stockez-le dans une variable,
2. effectuez le changement de la valeur,
3. appelez incIfChange avec l'état s0.

De la sorte, le compteur secondaire sera géré correctement.

En plus du fichier de vérification de signatures, nous mettons à votre disposition une dernière archive Zip contenant 12 fichiers ROM, à importer dans votre projet. Ces fichiers ROM contiennent des programmes testant le comportement du processeur, et sont connus sous le nom de « tests de blargg », d'après le pseudonyme de leur auteur. Le fichier instr_timing.gb vérifie que les instructions prennent le bon nombre de cycles pour s'exécuter, tandis que les 11 autres testent que le résultat qu'elles produisent est correct.

Ces programmes de test affichent normalement leur résultat sur l'écran du Game Boy, que vous ne simulez pas encore. Heureusement, ce résultat est aussi envoyé sur le port série du Game Boy, caractère par caractère. Vous ne simulez pas non plus ce composant — et ne le simulerez pas dans le cadre de ce projet — mais il se trouve qu'il est très facile d'écrire un minuscule composant interceptant les caractères qui y sont écrits et les affichant à l'écran :

public final class DebugPrintComponent implements Component {
  @Override
  public int read(int address) {
    return NO_DATA;
  }

  @Override
  public void write(int address, int data) {
    if (address == 0xFF01)
      System.out.print((char)data);
  }
}

Ce composant ne fait rien d'autre qu'intercepter les écritures faites à l'adresse FF01₁₆, interpréter les octets qu'on y écrit comme des caractères, et les afficher à l'écran.

Une fois ce composant défini, il reste à écrire un programme principal simulant le Game Boy complet. Une petite difficulté se pose alors : les tests de blargg dépendent de l'interruption VBLANK, levée par l'écran à la fin du dessin d'une image. Heureusement, il suffit de la lever périodiquement pour que tout fonctionne. C'est ce que fait le programme ci-dessous, qui la lève tous les 17 556 cycles car c'est le temps que met effectivement l'écran du Game Boy pour dessiner une image.

public final class DebugMain {
  public static void main(String[] args) throws IOException {
    File romFile = new File(args[0]);
    long cycles = Long.parseLong(args[1]);

    GameBoy gb = new GameBoy(Cartridge.ofFile(romFile));
    Component printer = new DebugPrintComponent();
    printer.attachTo(gb.bus());
    while (gb.cycles() < cycles) {
      long nextCycles = Math.min(gb.cycles() + 17556, cycles);
      gb.runUntil(nextCycles);
      gb.cpu().requestInterrupt(Cpu.Interrupt.VBLANK);
    }
  }
}

Une fois ce programme écrit, il est possible de l'exécuter en lui passant en premier argument le nom du fichier ROM à utiliser, et en second argument le nombre total de cycles à simuler. Pour ces fichiers ROM, vous pouvez utiliser systématiquement 30 000 000 (30 millions de cycle), ce qui suffit à exécuter tous les tests jusqu'à la fin. Notez que si vous ne savez pas comment exécuter un programme depuis Eclipse en lui passant des arguments, vous pouvez lire notre guide à ce sujet.

Si votre simulateur fonctionne, les tests devraient afficher leur nom sur la console Eclipse puis, au bout d'un temps plus ou moins long, le résultat du test. Par exemple, en exécutant le programme DebugMain en lui passant les arguments suivants :

01-special.gb 30000000

vous devriez voir apparaître le texte suivant dans la console Eclipse au bout de quelques secondes :

01-special


Passed

et de même pour les autres tests. Sur un ordinateur relativement récent, l'exécution d'un test devrait prendre environ 2 secondes¹.

Si un test échoue, un message d'erreur est affiché. Par exemple, en introduisant volontairement une erreur dans la gestion de l'instruction DAA et en relançant le test ci-dessus, on obtient le message suivant :

01-special

BD9BF11C 
DAA

Failed #6

Si votre simulateur est capable d'exécuter tous les tests sans erreur, félicitations !