Added disk ref for testing sector writes

updated lab
Added 2 guests: guest_disk_phys.bin and guest_disk_pv.bin
Added 2 more guests for sprites validation

labs/lab-virtual_game_machine/lab-virtual_game_machine.md

@@ -62,7 +62,7 @@ Les sous-sections qui suivent décrivent le but et les fonctionnalités de chaqu
 
 **IMPORTANT**
 
-Le binaire du guest OS fourni est généré de sorte à ce qu'il soit chargé à l'adresse physique 0. Il est donc requis que celui-ci soit chargé à l'adresse 0 dans la machine virtuelle, sinon il ne fonctionnera pas correctement.
+Le binaire du guest OS fourni est généré de sorte à ce qu'il soit chargé à l'adresse physique 0. Il est donc requis que celui-ci soit chargé à l'adresse 0 dans la machine virtuelle, sinon il ne fonctionnera pas.
 
 ### Mécanisme d'hypercall
 
@@ -71,11 +71,11 @@ L'espace de mémoire partagée, faisant office de buffer pour les hypercalls, do
 
 ### (1) Console virtuelle
 
-Ce périphérique est uniquement exposé virtuellement (c'est à dire de manière paravirtualisée). Il permet au guest de demander au VMM d'afficher un message (une chaîne de caractères) sur une console virtuelle. Cette console virtuelle est simplement la sortie standard du VMM.
+Ce périphérique est uniquement exposé virtuellement (c'est à dire de manière paravirtualisée). Il permet au guest de demander au VMM d'afficher un message (une chaîne de caractères) sur une console virtuelle. Cette console virtuelle est simplement la sortie standard (`stdout`) du VMM.
 
 **Comportement du VMM**
 
-Le VMM affiche le texte spécifié par le guest sur la sortie standard. Attention, par défaut, la sortie standard (`stdout`) est bufferisée. Le texte écrit sur la sortie standard est *flushé* dans le terminal lorsque le caractère `\n` est rencontré ou lorsque le buffer interne lié à `stdout` est plein. La sortie standard peut être "débufférisée" avec le code suivant\ :
+Le VMM affiche le texte spécifié par le guest sur la sortie standard. Attention, par défaut, la sortie standard (`stdout`) est bufferisée. Le texte écrit sur la sortie standard est *flushé* dans le terminal lorsque le caractère `\n` est rencontré ou lorsque le buffer interne lié à `stdout` est plein. La sortie standard peut être "débufférisée" avec le code C suivant\ :
 
 \small
 ```{.c}
@@ -426,9 +426,9 @@ Le code lié au guest se trouve dans le répertoire `guest`. Voici la descriptio
 
 **Sprites**
 
-Le guest ne possède aucun moyen pour charger des données depuis un support physique. Comment donc charger les contenus utilisés pour les sprites\ ? Un moyen simple pour résoudre ce problème est de simplement intégrer les données des sprites dans le code source du guest.
+Le guest ne possède aucun moyen pour charger des données depuis un support physique. Comment donc charger les contenus utilisés pour les sprites\ ? Un moyen simple pour résoudre ce problème est d'intégrer les données des sprites dans le code source du guest, sous forme de tableaux de bytes.
 
-Le petit programme **`bin2array`**, dont le code source [se trouve ici](https://github.com/thxbb12/bin2array), permet de convertir tout fichier en un tableau de bytes en C. A vous donc de l'utiliser pour convertir des fichiers sprites (images png) en code source C.
+Le petit programme **`bin2array`**, dont le code source [se trouve ici](https://github.com/thxbb12/bin2array), permet de convertir tout fichier en un tableau de bytes en C. A vous donc de l'utiliser pour convertir des fichiers sprites (images au format `png`) en code source C.
 
 ## Consignes à propos de l'implémentation
 
@@ -535,3 +535,48 @@ Using native display driver (phys).
 Display resolution: 600x400 pixels.
 ```
 \normalsize
+
+### `guest_disk_pv.bin`
+\vspace{-.3cm}
+
+Ce guest réalise un test d'écriture de secteurs via un driver paravirtualisé (hypercall n°4). Il écrit, dans 8 secteurs du disque, une suite de valeurs aléatoires connues, donc toujours les mêmes à chaque exécution. Les 8 secteurs sont les suivants, dans l'ordre\ : 307, 71, 511, 17, 147, 31, 219, 0.  
+
+Attention\ : il considère un disque d'une capacité de 256\ KB.
+
+Il écrit sur la console virtuelle les secteurs écrits et produit la sortie suivante\ :
+\footnotesize
+```
+Started disk validation tests...
+Completed disk validation tests.
+```
+\normalsize
+
+Dans `disk_tests/disk_ref.raw` se trouve une image disque de 256\ KB contenant le contenu exact du disque que vous devriez obtenir après l'exécution de ce guest. On part du principe qu'avant l'exéction du guest, le disque est rempli de 0. Ceci vous permettra de valider que votre VMM se comporte correctement.
+
+### `guest_disk_phys.bin`
+\vspace{-.3cm}
+
+Ce guest réalise le même test d'écriture de secteurs que `guest_disk_pv.bin` mais via driver natif (physique). Attention toutefois\ : le code du guest tente de réaliser des écritures sur disque, mais volontairement légèrement incorrectes. Ces tentatives d'écritures ne doivent donc jamais aboutir. Seules les écritures implémentant un code 100% correct doivent mener à un secteur écrit sur disque. Les secteurs réellement écrits sont les mêmes que dans le guest précédent et leurs contenus identiques.
+
+Enfin, l'affichage réalisé par le guest sur la console virtuelle devrait être identique au guest précédent.
+
+### `guest_sprites_pv.bin`
+\vspace{-.3cm}
+
+Ce guest réalise les fonctionnalités suivantes à l'aide d'hypercalls\ :
+
+1. Initialise le mode graphique 600x400
+1. Défini le contenu de 3 sprites, aux dimensions respectives de 64x64, 64x64 et 128x128
+1. Rend les 3 sprites visibles
+1. Dans une boucle infinie\ :
+   - Déplace les 3 sprites aléatoirement
+   - Attends un délai de 10000 micro-secondes entre chaque tour de boucle
+
+L'affichage devrait ressembler à ceci\ :
+
+![Affichage de sprites](images/sprites.png){ width=80% }
+
+### `guest_sprites_phys.bin`
+\vspace{-.3cm}
+
+Ce guest réalise exactement les mêmes fonctionnalités que `guest_sprites_pv.bin`, mais en utilisant des drivers natifs (physiques).
\ No newline at end of file