test-gameboy, memory access

test-gameboy, memory access

by Sophie Sarah Ammann -
Number of replies: 4

Bonjour,

On n'arrive pas à comprendre l'exécution de notre programme car lorsqu'on arrive au cycle 2159439 de gameboy_run_until, cette dernière appelle timer_bus_listener qui elle-même appelle timer_state pour déterminer l'ancien état. 

Dans timer_state, nous nous assurons que timer->cpu et timer->cpu->bus ne soient pas NULL, mais en appelant bus_read à l'adresse TAC, on ne peut pas accéder au contenu pointé par bus[REG_TAC]. 

On a les commentaires suivants dans le gdb :

112         *data = (bus[address] == NULL) ? 0xFF : *bus[address];

(gdb) p address

$1 = 65287.  (= REG_TAC)

(gdb) p bus[address]

Cannot access memory at address 0x800000ffffd448

(gdb) p bus

$2 = (data_t * const *) 0x800000fff7dc10

(gdb) p *bus[address]

Cannot access memory at address 0x800000ffffd448

In reply to Sophie Sarah Ammann

Re: test-gameboy, memory access

by Cédric Viaccoz -

Avez vous bien fait attention de donner accès par le bus aux registres du timer (i.e. donner le pointeur sur ces variables) de manière prolongée? Vu ce que je vois de votre débugging, le pointeur sur le registre TAC existe, mais son accès est interdit. Faites attention à ne pas pas simplement déclarer les registres du timer comme des variables statiques dans une fonction quelque part car une fois l'exécution de cette fonction terminée, vous ne pouvez plus avoir accès au contenu de ces variables.

In reply to Cédric Viaccoz

Re: test-gameboy, memory access

by Sophie Sarah Ammann -

Bonjour,

Merci pour la réponse mais ce n'est pas ça le problème. Nous sommes allés plus en profondeur et avons constaté que cpu_dispatch_alu_ext changeait l'adresse du bus de notre cpu. Par conséquent, notre timer accède au bus d'un autre (???) bus qu'on ne connaît pas. 

Détails : 

C'est le 49370e cycle de game_boy_run_until , durant l'appel de cpu_cycle, on obtient l'instruction suivante :

{kind = DIRECT, family = XOR_A_N8, opcode = 238 '\356', bytes = 2 '\002', cycles = 2 '\002', xtra_cycles = 0 '\000'}

qui finalement sera passée à cpu_dispatch_alu_ext, qui change le bus. Voici la sortie de gdb avant et après l'appel : 

268             M_EXIT_IF_ERR(cpu_dispatch_alu_ext(lu, cpu));

3: cpu->bus = (bus_t *) 0x7ffffff7dc10

(gdb) n

269             break;

3: cpu->bus = (bus_t *) 0x800000fff7dc10

(gdb) 


On a aussi remarqué que c'est la première fois qu'on appelle cpu_dispatch_alu_ext.

Nous ne comprenons pas ce comportement, nous n'avons aucune idée de comment le résoudre, y a-t-il un problème avec la librairie, avons-nous fait une erreur quelque part ? 

Au secours 

Merci pour votre aide 

In reply to Sophie Sarah Ammann

Re: test-gameboy, memory access

by Jean-Cédric Chappelier -

avant tout : est-ce que les tests unit-test-cpu-dispatch et unit-test-alu_ext passent chez vous ?
et avez-vous vu : https://moodlearchive.epfl.ch/2019-2020/mod/forum/discuss.php?d=34084#p69880

In reply to Jean-Cédric Chappelier

Re: test-gameboy, memory access

by Sophie Sarah Ammann -

Merci beaucoup pour votre aide ! C'était exactement le même problème que le post que vous avez mentionné :)