L’émulateur

Développement de BriXen: épisode 6

En tant qu’utilisateur macOS, le choix de l’émulateur est assez facile: Arnold ou Retro Virtual Machine (RVM).

Malgré que Arnold soit un très bon émulateur, niveau developpement RVM reste plus pratique avec toutes ses options de debugging et sa possibilité d’être appelé via la ligne de commande.

Retro Virtual Machine

Comme vu dans l’épisode 3, j’utilise une tâche pour lancer rapidement mon binaire dans Visual Studio avec la commande suivante

/Applications/Retro Virtual Machine 2.app/Contents/MacOS/Retro Virtual Machine 2 -w -b=cpc6128 -i brixen.dsk -c=run"main

J’utilise principalement les 3 vues suivantes:

  • la première affiche une vue d’ensemble du processeur Z80
Vue du CPU en temps réél
  • la seconde qui affiche la mémoire
Vue de la mémoire
  • et enfin, la 3ème qui affiche une vue du code désassemblé.
Désassembleur

SDCC étant assez verbeux et créant des fichiers .map et .lst du code qu’il a compilé, il est assez facile de faire la correspondance entre le code désassemblé de RVM et votre code C.

CrocoDS

En plus de RVM, ayant quand même notre propre émulateur (CrocoDS, vous connaissez ?), j’ai aussi ajouté quelques fonctions dans celui-ci qui m’aide régulièrement:

Redirection de l’imprimante.

CrocoDS redirige le port imprimante vers un fichier log. J’ai donc deux fonctions qui me permettent d’envoyer du texte à partir du CPC vers la console

void cpc_out(u8 b)
{
    (void)b;

    __asm
    ld hl, #2 + 0
    add hl, sp
    ld c, (hl)
    ld b, #0xEF
    out(c), c

    ld a, #0x80
    xor c
    ld c, a
    out(c), c
    __endasm;
}

void cpc_Debug(const char *str)
{
    char *a = (char *)str;

    while (*a != 0) {
        cpc_out(*a);
        a++;
    }
}

Capture d’écran

Un opcode spécial (ED FD) me permet de demander une capture d’écran à partir de l’Amstrad. Je l’utilise pour sortir la liste des 32 niveaux de BriXen en fichier pdf. Plus facile à consulter pour l’équipe.

__asm
.db #0xED
.db #0xFD
__endasm;

Comptage de FRAME

Autre opcode (ED FE) qui me logge le compteur de frame et le compteur de cycle:

F4 - T123/80000
F4 - T3153/80000

Cela me permet facilement de voir le temps que prend une routine et de l’optimiser si nécessaire.

Conclusion

Comme d’habitude, ces outils correspondent à mes besoins. Beaucoup ne jure que par WinAPE pour développer sous Windows (Certains jeux ont même été entièrement réalisé à partir de son assembleur intégré).

Et puis, n’oubliez pas: testez aussi sur vos vraies machines ! (et restez couvert)

A suivre pour un prochain épisode dimanche prochain

Mode démo

Développement de BriXen: épisode 5

Quand j’étais petit, j’adorais le mode démo dans les jeux. Cela permettait d’avoir une musique et une animation qui tourne en fond. 

Pour BriXen, il en fallait donc un.

Niveau développement, c’est assez simple. En gros, on joue à un niveau, chaque modification de touche est sauvée avec un compteur de frame et dans le mode démo, le programme utilise la séquence pour simuler le joueur qui joue.

J’ai donc deux fonctions à faire:

  • une qui enregistre (que je pourrais supprimer dans la version finale)
  • une qui joue.

Pour cela, j’ai crée une scène SC_DEMO qui est appelé après 30 secondes (soit 1500 frames).

Un chaine de replay se ressemble à ça (pour le level 1)

const u8 seq_level0[] = {22, 2, 18, 0, 14, 2, 10, 0, 17, 2, 9, 0, 14, 2, 9, 0, 10, 2, 11, 0, 14, 2, 17, 0, 21, 2, 8, 0, 78, 2, 11, 0, 36, 2, 8, 0, 51, 1, 84, 0, 15, 1, 5, 0, 16, 2, 16, 0, 21, 2, 19, 0, 23, 1, 7, 0, 11, 2, 24, 0, 10, 2, 17, 0, 19, 2, 21, 0, 37, 2};

Cela se traduit par:

  • 1er octet: nombre de frame avant d’executer la commande
  • 2éme octet: commande à executer (1: gauche, 2: droite, 0: on relache)

Arrivé à la fin de la chaine, j’aurai pu crée une commande 3… Mais vu que je ne fais que de la lecture et que cela n’influence qu’une simulation d’appui de touche, je laisse aller le pointeur au-delà de la chaine. De toute façon, il ne lira que quelques octets avant de compléter le niveau…

A suivre pour un prochain épisode très bientôt…