test-gameboy interruption VBLANK

test-gameboy interruption VBLANK

par Gil Christian Tinde,
Number of replies: 6
Bonjour, 

En lançant test-gameboy avec fibonacci.gb et 2165183 comme arguments (comme indiqué dans les instructions de l'étape 7), le contenu du registre A est 0x87 lorsqu'on ne fait pas la demande (artificielle) d’interruption VBLANK tous les 17556 cycles dans gameboy_run_until(). Si la demande d'interruption est faite, le registre A contient la valeur désirée 0x59. 
Cependant, sans la demande d'interruption, les tests de blargg ne se plaignent pas, ce qui est normal vu que c'est le contrôleur d'écran qui gère l'interruption. Mais l'executable test-gameboy qu'on lance avec fibonacci.gb et les tests de blargg est le même. Est-il possible que l'interruption n'est pas levée par le contrôleur d'écran en lançant avec fibonacci.gb ?  

Une deuxième question: dans notre makefile on compile gameboy.c avec le flag -DBLARGG pour pouvoir lancer les tests de blargg. De plus, dans gameboy_run_until(), à l'intérieur d'un "#ifdef BLARGG" on écoute le bus avec blargg_bus_listener(), comme indiqué dans l'énoncé de l'étape 7. Lorsqu'on lance gbsimulator avec tetris (où l'édition de liens a été faite avec le gameboy.o compilé avec -DBLARGG), il y a une sortie sur la ligne de commande ("UUUUU...") produite par blargg_bus_listener() en tapant "START" au début. Sera cette sorties pénalisée ? Existe il moyen pour que le gameboy.o utilisé pour créer gbsimulator soit compilé sans -DBLARGG (mais que celui de test-gameboy soit compilé avec) ?

Merci,
Gil Tinde


In reply to Gil Christian Tinde

Re: test-gameboy interruption VBLANK

par Jean-Cédric Chappelier,

je ne comprends pas vraiment votre première question car ce VBLANK artificiel n'a rien avoir avec fibonacci.gb ou les tests de blargg mais avec le fait de sortir de la bootrom ou non. Etes vous sûr de vos conditions de tests ? N'avez vous pas, soit testé avec/sans la bootrom, soit testé (par erreur) avec un .o contenant quand même/pas la boucle en question ?

Pour la 2e question : -DBLARGG ne doit être « allumé » que pour lancer les tests de blargg (en mode texte). C'est tout.
Et donc pour répondre à votre 3e question (qui est contenu dans la 2e) : il suffit de REFAIRE le .o en question.
Une autre solution, en effet, est d'avoir 2 cible, une avec et une sans le -DBLARGG : par exemple une cible gameboy.o normale et une autre gameboy-blargg.o et de n'utiliser le résultat de cette seconde cible que dans le link fait pour lancer les tests de blargg.

In reply to Jean-Cédric Chappelier

Re: test-gameboy interruption VBLANK

par Gil Christian Tinde,

Merci pour votre réponse. 

Concernant l'interruption VBLANK, l'énoncé de la semaine 7 (page 12) nous demande d'ajouter une "requête d’interruption VBLANK tous les 17 556 cycles" à l'intérieur de gameboy_run_until(). Pour cela nous faisons un appel à cpu_request_interrupt() (lorsque cycles est un multiple de 17 556) à l'intérieur de notre boucle principale déjà existante dans gameboy_run_until() (sans ajout de boucle supplémentaire). Peut-être avons nous mal interprété l'instruction car, d'après votre réponse et l'énoncé de l'étape 9 où il est indiqué qu'il faut supprimer "la boucle artificielle de demande d’interruption VBLANK tous les 17 556 cycles", il semble qu'il s'agit-il d'une deuxième boucle. (1) Est-ce le cas ?

L'énoncé de l'étape 7 (page 14), dans la partie sur les tests de blargg, nous demande aussi d'ajouter une requête d'interruption VBLANK, mais à l'intérieur du #ifdef BLARGG–#endif. (2) S'agit-il ici d'un appel à cpu_request_interrupt() distinct de celui demandé à la page 12 ? (3) S'agit-il d'une boucle supplémentaire comme à la page 12 ? 

In reply to Gil Christian Tinde

Re: test-gameboy interruption VBLANK

par Jean-Cédric Chappelier,
  1. je vous laisse réfléchir à l'impact qu'aurait une 2e boucle dans gameboy_run_until()
  2. il s'agit en effet bien de la même chose ; ce paragraphe dans les tests de blargg date d'avant l'ajout du paragraphe précédent sur le test de Fibonacci où l'explication sur cette interruption VBLANK a été déplacée puis complétée ; désolé pour notre inattention et la confusion.
    Je viens de corriger le sujet.
In reply to Jean-Cédric Chappelier

Re: test-gameboy interruption VBLANK

par Gil Christian Tinde,

Merci, je pense avoir compris maintenant. 

Notre version de gameboy.c de la fin de l'étape 7 (donc sans joypad et lcdc) fonctionne comme attendu sur fibonacci.gb et on obtient 0x59 après 2'165'183 cycles. Cependant, notre version de gameboy.c correspondant à la fin de l'étape 9 (l'ajout du lcdc + joypad et leurs fonctions) nécessite maintenant 2'178'249 pour obtenir 0x59 dans le registre A. Est-ce un résultat normal que plus de cycles sont nécessaires ?

In reply to Gil Christian Tinde

Re: test-gameboy interruption VBLANK

par Aurélien Clergeot,

Même question pour moi,

J'imagine que ça vient des interruptions plus longues/fréquentes à cause du lcdc, mais j'aimerais bien une confirmation...