Informations

que j'inaugure donc de suite avec 3 modifications / compléments du sujet 04.alu (qui vient donc d'être remis à jour dans ce sens : nouvelle version Rev. 2020.03.12 / 5) :

1. la fonction `bit_rotate()` applique les mêmes conventions que `bit_get()` etc. ; voici la phrase ajoutée :
   Comme pour `bit_get()` et autres, `bit_rotate()` forcera la valeur de `d` à 0 s'il n'est pas compris entre 0 et 7.
   
   
2. comme mentionné ici : https://moodlearchive.epfl.ch/2019-2020/mod/forum/discuss.php?d=26379#p52198, il y a malheureusement eut une confusion sur le type de retour de `get_flag()`: le type de retour de `get_flag()` doit être `flag_bit_t` et non pas `bit_t`.
   Il faut donc aussi corriger ce type de retour dans alu.h.
   
   
3. Le comportement de `get_flag()` et `set_flag()` en cas d'erreur a été spécifié :
   

   si le `flag` reçu n'est pas valable, `get_flag()` retourne 0 ;
   

   si le `flag` reçu n'est pas valable, `set_flag()` ne fait rien.

Une correction du sujet 05.bus (nouvelle version Rev. 2020.03.18 / 3) :

Pour la fonction bus_remap(), il était écrit :

cette fonction vérifie donc la validité de ses arguments (start + offset inférieur ou égal à end ; end - start + offset plus petit que la taille de la mémoire du composant) ;

Cette première condition d'erreur est inutile (et fausse ; et n'est d'ailleurs pas testée). La bonne version de la phrase est :

cette fonction vérifie donc la validité de ses arguments (p.ex. end - start + offset plus petit que la taille de la mémoire du composant) ;

Une correction du sujet 06.memories (nouvelle version Rev. 2020.03.25 / 3) :

Le prototype de `gameboy_create()` est bien :

comme donné dans le .h.

J'ai modifié comme suit la donnée (parties ajoutée en rouge) :

`int gameboy_create(gameboy_t* gameboy, const char* filename)`, qui construit une Game Boy en créant le
    composant décrit ci-dessus (*work RAM*) et en l'attachant au bus aux adresses indiquées ci-dessus (ignorez le `filename` pour le moment) ;

Remarque générale : c'est toujours le fichier .h qui fait foi.

Une correction du sujet 05.bus (nouvelle version Rev. 2020.04.01 / 4) :

Certains m'ont fait remarquer que l'explication de la fonction bus_forced_plug() pouvait être mal interprétée. Je l'ai donc reformulée (parties vertes ajoutées, parties rouges supprimées) :

[...] « connecte » à la plage d'adresses indiquée en paramètre, la zone mémoire du composant donné commençant à la position `offset` (en clair : appelle `bus_remap()`) ; puiset les champs début et fin d'adressage du composant sontdoivent être modifiés en conséquence [...]

Pour faire suite à une question, je viens de compléter le sujet 06.memories (nouvelle version Rev. 2020.04.01 / 4) :

dans la description de la fonction `gameboy_create(), j'ai ajouté une marche à suivre plus précise :

• créer la mémoire de travail (*work RAM*) et la connecter au bus ;
• partager sa mémoire (`component_shared()`) avec l'« _echo RAM_ » ;
• connecter l'« _echo RAM_ » au bus ;
  

juste une correction mineure sur le sujet 08.cpu_instructions.md (nouvelle version 2020.04.08 / 8) :

la ligne

dans le tableau des instructions de chargement n'a juste rien à faire là (à supprimer) car elle est contenue dans la ligne située plus bas :

Encore une correction sur le sujet 08.cpu_instructions.md (nouvelle version 2020.04.14 / 10) :
au sujet de la famille « ROT_R8 », comme remarqué par au moins deux d'entre vous (https://moodlearchive.epfl.ch/2019-2020/mod/forum/discuss.php?d=32116), la donnée a été sur-simplifiée ; on peut en effet très facilement gérer les DEUX instructions de cette famille (au lieu d'une seule comme initialement indiqué). Le nouveau texte est :

Rotations

Nous ne vous demandons de n'implémenter que les deux opérations de rotation à travers la retenue (rotate through carry) listées ci-dessous.

Ces deux instructions sont préfixées et travaillent sur un registre 8 bits quelconque. Comme ce sont des instructions préfixées, la valeur donnée dans la colonne Opcode est celle du second octet de leur encodage, le premier étant toujours égal au préfixe (0xCB).

Pour récupérer le sens de rotation (gauche ou droite), utilisez la macro extract_rot_dir() fournie dans opcpde.h.

   Famille       Assembleur    Opcode     Effet                  ZNHC
  ------------- ------------- ---------- ---------------------- ------
   ROT_R8        RL r8         00010rrr   r = rot(LEFT , r, C)   Z00C
   ROT_R8        RR r8         00011rrr   r = rot(RIGHT, r, C)   Z00C

====
Pour tous ceux qui ont déjà fait ce code, normalement il suffit simplement de changer un LEFT par un extract_rot_dir(lu->opcode) et c'est tout !

je viens d'ajouter les consignes de rendu au sujet 07.cpu_registers.md, nouvelle version : Rev. 2020.04.17 / 4.

Cet ajout est également répété dans mon message précédent.

Une correction mineure (typo) dans le sujet 08.cpu_instructions.md (nouvelle version : Rev. 2020.04.22 / 11), mais je la signale tout de même car j'ai eu une question là dessus ce matin :
Dans la section « Addition » de « Instructions à coder » :
l'instruction « INC [HL] » fait bien partie de la famille « INC_HLR » et non pas « INC_HL » (qui, d'ailleurs, n'existe pas en tant que famille) :

  INC_HLR     INC [HL]      00110100   BUS[HL] += 1       Z0H-

indication fausse dans 09.cpu_control.md (nouvelle version : Rev. 2020.04.22 / 4) :
comme remarqué par votre camarade, dans la description de la fonction « cpu_request_interrupt() » dans la section « Lever d'interruption », il n'y a pas du tout lieu de mettre IME à 1 contrairement à ce qui était initialement indiqué :
void cpu_request_interrupt(cpu_t* cpu, interrupt_t i), qui lève l'interruption donnée, c.-à-d. met à 1 le bit correspondant dans le registre IF (et, bien sûr, met `IME`à 1).

juste une modification mineure sur le sujet 10.cartridge_timer.md (version Rev. 2020.05.04 / 6) :
levé de l'ambiguité au sujet du « tour » du compteur secondaire, comme discuté ici : https://moodlearchive.epfl.ch/2019-2020/mod/forum/discuss.php?d=34493#p70853

Dans 09.cpu_control.md (nouvelle version Rev. 2020.05.12 / 5), le nombre de cycles pour terminer l'exemple de calcul de la suite de Fibonacci n'est pas 5308, mais 5739. cf https://moodlearchive.epfl.ch/2019-2020/mod/forum/discuss.php?d=35678#p73359

10.cartridge_timer.md (nouvelle version : Rev. 2020.05.13 / 7) :
section « Cartouche » :
0x7FFF est bien INCLUSE dans la place couverte (et non pas exclue).
cf https://moodlearchive.epfl.ch/2019-2020/mod/forum/discuss.php?d=35994#p73770

Dans le sujet 11.bitvector.md (nouvelle version : Rev. 2020.05.14 / 4) :
j'ai clarifié que bit_vector_extract_wrap_ext() doit retourner NULL s'il reçoit un vecteur nul.
cf https://moodlearchive.epfl.ch/2019-2020/mod/forum/discuss.php?d=36051#p74111

Suite aux questions de ce matin (liens ci-dessous), je viens de modifier le sujet 11.bitvector.md (nouvelle version : Rev. 2020.05.20 / 6) pour clarifier plusieurs points :

• les 32 bits de taille (multiple) sont un détail d'implémentation pas une contrainte d'interface : en clair, les bit_vectors peuvent être (conceptuellement / interface) de n'importe quelle taille :
  
  L'idée consiste simplement à utiliser un tableau de n/32 uint32_t pour représenter un vecteur de n bits, si n est un multiple de 32, et n/32 + 1 uint32_t si n n'est pas multiple de 32, les bits de poids les plus forts du dernier élément de ce tableau n'étant pas utilisés dans ce cas (mais les mettre à 0 peut aider l'implémentation de certaines fonctions).
  
  
• nous avons renforcé les hypothèses sur les arguments de bit_vector_join() : les deux vecteurs doivent être de même taille et l'argument size doit être compris entre 0 et cette taille :
  
  [...] combine deux vecteurs de même taille en un seul nouveau vecteur de la façon suivante : de 0 à shift (exclu), le vecteur prend la valeur de pbv1, et de shift (inclus) jusqu'à la fin, il prend la valeur de pbv2 ; shift doit donc être compris entre 0 (inclus) et la taille des vecteurs ;
  

Sur le sujet 13.simulator.md (nouvelle version Rev. 2020.05.22 / 4), je viens d'ajouter une remarque de compilation pour les fonctions de sys/times.h :

Notez que si vous imposez un standard à votre compilateur (option `-std=...`), il faudra alors définir (`_DEFAULT_SOURCE`, c.-à-d. ajouter l'option `-D_DEFAULT_SOURCE`) pour avoir accès à cette bibliothèque.

(cf https://moodlearchive.epfl.ch/2019-2020/mod/forum/discuss.php?d=36836#p75951)

Je viens de modifier le sujet 13.simulator.md (nouvelle révision : Rev. 2020.05.26 / 6) afin d'y intégrer la modification effectuée sur la libcs212gbfinalext.so (cf https://moodlearchive.epfl.ch/2019-2020/mod/forum/discuss.php?d=32096#p77329) : il vous faut donc compiler image.c en image.o et faire l'édition de lien avec image.o ET -lcs212gbfinalext.

10.cartridge_timer.md Rev. 2020.05.27 / 8 :
mineure :
suite à une question (https://moodlearchive.epfl.ch/2019-2020/mod/forum/discuss.php?d=37091#p77452) j'ai clarifié la levée de l'interruption VBLANK dans le paragraphe sur les tests de blargg.