┌────────────────────────────────────────────────────────────────────────────┐ │░▒▓█ Doc. technique pour GrafX 2.00 - Version 1.08 (5 octobre 1997) █▓▒░│ └────────────────────────────────────────────────────────────────────────────┘ Ce fichier traite: - du format d'image PKM - des valeurs à envoyer au CRTC pour avoir accès à tous les modes vidéos incroyables disponibles dans GrafX 2.00 ┌────────────────────────────────────────────────────────────────────────────┐ │ ░▒▓█ Le format d'image PKM - par Karl Maritaud █▓▒░ │ └────────────────────────────────────────────────────────────────────────────┘ Tout d'abord, je tiens a dire que j'ai créé ce format il y a déjà quelques années, à l'époque où je ne savais pas comment charger les meilleurs formats (GIF par exemple) et que je voulais également avoir mon propre format. Le format PKM a été conçu pour être très simple, facile à encoder et à décoder. De plus, son header est très simple (court) et evolutif. Le seul vrai défaut que je puisse y trouver est que l'on ne peut sauver des images qu'en 256 couleurs. Je sais que vous allez vous dire: "Oh non! Encore un nouveau format à la con! J'm'en servirai jamais! En plus le taux de compression est naze! Je prefère le GIF!". Et je répondrai: "Ouais! T'as raison. Mais si tu ne sais pas comment charger du GIF et que tu veux un format simple avec une compression correcte (du moins sur les images simples), il peut être utile." Donc, voici la documentation de ce format... Le HEADER: ══════════ Le header est la structure de 780 octets suivante. (Ne vous inquiétez pas à propos de la taille. C'est tout simplement parce que la palette fait partie du header). ┌─────┬───────────┬──────┬──────┬──────────────────────────────────────────┐ │ Pos │ Champ │ Type │Taille│ Description │ ╞═════╪═══════════╪══════╪══════╪══════════════════════════════════════════╡ │ 0 │ Signature │ char │ 3 │ Chaîne constante "PKM" (SANS délimitation│ │ │ │ │ │ de taille '\0' ou autres...) │ ├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤ │ 3 │ Version │ byte │ 1 │ Pour le moment, ce champ ne peut prendre │ │ │ │ │ │ que la valeur 0. │ │ │ │ │ │ D'autres méthodes de compression pourront│ │ │ │ │ │ la modifier mais pour l'instant il n'y en│ │ │ │ │ │ a qu'une seule. │ ├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤ │ 4 │ Pack_byte │ byte │ 1 │ Valeur de l'octet de reconnaissance pour │ │ │ │ │ │ les répétitions de couleurs codées sur 1 │ │ │ │ │ │ Octet. (Voir la section sur la méthode de│ │ │ │ │ │ compression pour plus d'informations) │ ├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤ │ 5 │ Pack_word │ byte │ 1 │ Valeur de l'octet de reconnaissance pour │ │ │ │ │ │ les répétitions de couleurs codées sur 2 │ │ │ │ │ │ Octets. (Voir la section sur la méthode │ │ │ │ │ │ de compression pour plus d'informations) │ ├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤ │ 6 │ Largeur │ word │ 2 │ Largeur de l'image (en pixels) │ ├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤ │ 8 │ Hauteur │ word │ 2 │ Hauteur de l'image (en pixels) │ ├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤ │ 10 │ Palette │ byte │ 768 │ Palette RGB (RGB RGB ... 256 fois) avec │ │ │ │ │ │ des valeurs de 0 à 63. Je sais que le │ │ │ │ │ │ standard dans les fichiers d'images est │ │ │ │ │ │ de 0 à 255 mais je trouve ça crétin! │ │ │ │ │ │ C'est tellement plus simple d'envoyer la │ │ │ │ │ │ palette toute entière dans le port 3C9h │ │ │ │ │ │ avec un REP OUTSB sans avoir à convertir │ │ │ │ │ │ la palette. │ ├─────┼───────────┼──────┼──────┼──────────────────────────────────────────┤ │ 778 │ Taille_PH │ word │ 2 │ Taille du Post-header. C'est le nombre │ │ │ │ │ │ d'octets entre le header et les données │ │ │ │ │ │ de l'image. Cette valeur peut valoir 0. │ └─────┴───────────┴──────┴──────┴──────────────────────────────────────────┘ Les données du type "word" sont stockées selon les conventions d'Intel: c'est-à-dire l'octet de poids le plus faible en premier. Le POST-HEADER: ═══════════════ Le post-header a une taille variable. Il a été conçu pour supporter les nouvelles fonctions de ce format sans avoir a changer complètement le format. Il est constitué d'identificateurs de champ suivis par leur taille et leur contenu. Un identificateur de champ est codé sur 1 octet ainsi que sa taille. Ces identificateurs de champ sont: (cette liste peut être rallongée...) ────────────────────────────────── 0 : Commentaire sur l'image 1 : Dimensions de l'écran d'origine 2 : Couleur de fond (couleur de transparence) Si vous rencontrez un champ inconnu par votre routine de chargment, sautez simplement au delà. Mais, par contre, si un champ vous dit de sauter à une position qui tombe après le début théorique des données de l'image, alors c'est qu'il y a une erreur dans le fichier. Les champs: ─────────── * Commentaire: Grâce à ce champ, les artistes vont pouvoir commenter leurs dessins. Notez que GrafX 2 a une taille limite de commentaire de 32 caractères. Mais vous pourrez avoir des commentaires allant jusqu'à 255 caractères si vous créez votre propre viewer puisque GrafX 2 ignorera simplement les caractères en trop. Exemple: [0],[15],[Dessin de X-Man] Cette séquence signifie: - le champ est un commentaire - le commentaire a une taille de 15 caractères (il n'y a pas de caractère de fin de chaîne puisque vous connaissez sa taille) - le commentaire est "Dessin de X-Man" * Dimensions de l'écran d'origine: Puisque GrafX 2 propose un énorme choix de résolutions, il a semblé pratique d'ajouter un champ indicant quelles étaient les dimensions de l'écran d'origine. Exemple: [1],[4],[320],[256] Cette séquence signifie: - Le champ décrit les dimensions de l'écran d'origine - Les dimensions sont 2 words (donc cette valeur doit être égale à 4) - La largeur de l'écran d'origine était de 320 pixels - La hauteur de l'écran d'origine était de 256 pixels Notez que les words stockés dans les champs sont écrits à la manière Intel. La BETA-version 90% ne respectait pas cette norme (désolé). Ce n'est pas bien grâve mais les images sauvées avec la version 90% et rechargées avec une version postérieure (91% et plus) ne passeront pas dans la bonne résolution. * Couleur de fond: Enregistrer la couleur de fond (couleur de transparence) se révèle particulièrement utile lorsque vous voulez sauvegarder une brosse. La taille de ce champ est 1 octet (indice de la couleur entre 0 et 255). Exemple: [2],[1],[255] Cette séquence signifie: - le champ décrit la couleur de fond - la valeur prend 1 octet - La couleur de transparence est 255 La METHODE DE COMPACTAGE DE L'IMAGE: ════════════════════════════════════ La méthode de compression PKM est une sorte de "Run-Length-Compression" qui est très efficace sur les images comportant de longues répétitions d'une même couleur horizontalement. En fait la compression commence à être efficace s'il y a souvent plus de 3 fois la même couleur consécutivement. Je pense qu'il est préférable de vous donner directement l'algorithme plutôt que de nager dans des explications incomprehensibles. DEBUT /* fonctions: Lire_octet(Fichier) Lit et retourne 1 octet à partir de Fichier Dessiner_pixel(X,Y,Couleur) Dessine un pixel d'une certaine Couleur à la position (X,Y) Taille_fichier(Fichier) Retourne la taille totale d'un Fichier en octets variables: le type de Taille_image est dword le type de Taille_donnees est dword le type de Compteur_donnees est dword le type de Compteur_pixels est dword le type de Couleur est byte le type de Octet_lu est byte le type de Word_lu est word le type de Compteur est word le type de Fichier est */ /* A cet endroit, le header et le post-header ont déjà été lus. */ Taille_image <- Header.Largeur * Header.Hauteur Taille_donnees <- Taille_fichier(Fichier) - (780+Header.Taille_PH) Compteur_donnees <- 0 Compteur_pixels <- 0 /* Boucle de décompression: */ TANT QUE ((Compteur_pixelsHeader.Pack_byte) ET (Octet_lu<>Header.Pack_word)) ALORS { Dessiner_pixel(Compteur_pixels MOD Header.Largeur, Compteur_pixels DIV Header.Largeur, Octet_lu) Compteur_pixels <- Compteur_pixels + 1 Compteur_donnees <- Compteur_donnees + 1 } SINON /* Est-ce que le nombre de pixels à répéter est codé... */ { /* ... sur 1 octet ? */ SI (Octet_lu = Header.Pack_byte) ALORS { Couleur <- Lire_octet(Fichier) Octet_lu <- Lire_octet(Fichier) POUR Compteur ALLANT DE 0 A (Octet_lu-1) PAR PAS DE +1 Dessiner_pixel((Compteur_pixels+Compteur) MOD Header.Largeur, (Compteur_pixels+Compteur) DIV Header.Largeur, Couleur) Compteur_pixels <- Compteur_pixels + Octet_lu Compteur_donnees <- Compteur_donnees + 3 } SINON /* ... sur 2 octets ? */ { Couleur <- Lire_octet(Fichier) Word_lu <- (word) (Lire_octet(Fichier) SHL 8)+Lire_octet(Fichier) POUR Compteur ALLANT DE 0 A (Word_lu-1) PAR PAS DE +1 Dessiner_pixel((Compteur_pixels+Compteur) MOD Header.Largeur, (Compteur_pixels+Compteur) DIV Header.Largeur, Couleur) Compteur_pixels <- Compteur_pixels + Word_lu Compteur_donnees <- Compteur_donnees + 4 } } } FIN Par exemple, la séquence suivante: (on suppose que Pack_byte=01 et Pack_word=02) 04 03 01 05 06 03 02 00 01 2C sera décodée comme: 04 03 05 05 05 05 05 05 03 00 00 00 ... (repéter 0 300 fois (012Ch=300)) Les répétitions qui tiennent sur un word doivent être écrites avec leur octet de poids le plus fort en premier. Je sais que ça va à l'encontre du standard Intel mais puisque je lis les octets du fichier au travers d'un buffer (franchement plus rapide), Je me fous complètement de l'ordre (Désolé :)). Mais les words du header et du post-header doivent être écrits et lus à la manière Intel! Conseils de compactage: ─────────────────────── * Comme vous pouvez le constater, il pourrait y avoir un problème lorsque vous devriez compacter un pixel brut de couleur égale à Pack_byte ou à Pack_word. Ces pixels doivent toujours être codés comme des paquets même s'il n'y a qu'un seul pixel. Exemple: (supposons que Pack_byte=9) 9 sera encodé 9,9,1 (Le 1er 9 dans la séquence... 9,9 sera encodé 9,9,2 ... encodée est Pack_byte) etc... * Il semble évident de trouver des valeurs pour Pack_byte et Pack_word qui ne sont jamais (ou presque) utilisées. Donc, une petite routine qui trouve les 2 couleurs les moins utilisées dans l'image devrait être appelée avant de commencer la compression. Ceci peut être réalisé presque instantanément en Assembleur. * Quand vous voulez écrire une séquence de 2 couleurs identiques, écrivez simplement ces 2 couleurs l'une après l'autre (Couleur,Couleur) puisque ça ne prend que 2 octets au lieu de 3 si vous aviez écrit un paquet (Pack_byte, Couleur,2). * Si vous compressez une image extrêmement simple qui comporte une séquence de plus de 65535 fois la même couleur consécutivement, vous devez "casser" la séquence et continuer avec un nouveau paquet. Exemple: vous devez compacter les 65635 mêmes octets consécutifs (de couleur 0 par exemple) (On suppose que Pack_byte=01 et Pack_word=02) Vous devrez alors écrire: 02 00 FF FF 01 00 64 (FFFFh=65535, 64h=100) ┌────────────────────────────────────────────────────────────────────────────┐ │ ░▒▓█ Passer dans les modes vidéos de GrafX 2.00 █▓▒░ │ └────────────────────────────────────────────────────────────────────────────┘ Toutes les procédures d'initialisation de mode sont écrites en ASM 386. De toutes façons, si vous ne comprenez pas une ligne d'ASM, je ne vois vraiment pas à quoi pourront vous servir ces procédures. Elles ont été conçues pour être utilisées dans le modèle de mémoire FLAT. Mais cela ne devrait pas vous prendre trop de temps de les adapter au modèle que vous souhaitez utiliser puisqu'il n'y a que les manipulations de mémoire que cela affectera (utilisez donc DS:SI au lieu de ESI, ES:DI à la place de EDI et faîtes attention à l'adresse 0A0000h qui se transforme en l'adresse 0A000h:0000h). MCGA: (Mode VGA standard) ═════ Y-a-t'il quelqu'un sur cette planète qui ne sache toujours pas comment on passe en mode MCGA 320x200 en 256 couleurs ??!? Bon... Je suppose que vous êtes un novice si vous lisez les 2 lignes suivantes :) mov ax,0013h int 10h Modes X: (Modes VGA étendus) ════════ Bon... Il me semble que le Mode X original était en 320x240, mais maintenant tout le monde appelle "Modes X" (ou X-Modes, ou Tweaked modes) tous les modes VGA qui utilise plus de 64Ko de mémoire vidéo et la structure "Unchained". Afficher un pixel dans n'importe quel Mode X peut être effectué par la même et unique fonction (mais je ne vous expliquerai pas comment faire, il vous suffit d'indiquer à la fonction la taille des plans (Largeur/4)). Si vous ne comprenez rien à ce que je dis, (Unchained, plans...) il vous suffit de lire n'importe quelle bonne documentation sur le Mode X. Nous tenons à remercier les auteurs de XLIB2 pour nous avoir économisé du temps en ayant écrit cette fonction. Nous l'avons légèrement optimisée en fonction de nos besoins, mais l'essentiel en a été conservé. mov ax,13h ; Oui! Encore le mode MCGA! Tous les Modes X doivent int 10h ; commencer à partir du mode VGA standard, mais bien des ; choses changent par la suite. mov dx,3C6h ; Pour la durée de l'initialisation, on va éteindre la xor al,al ; palette de façon à ce que l'utilisateur ne subisse pas out dx,al ; nos triturations. mov dx,3C4h ; Nous allons demander au registre TIMING SEQUENCER de mov ax,0604h ; passer dans le mode "Unchained" (mode X), sans gérer de out dx,ax ; parité, et un accès aux 256Ko de la carte vidéo. mov ax,0100h ; On va ensuite enclencher le reset synchrone du registre out dx,ax ; TS car on s'apprête à jouer avec les registres. mov al,01h ; De la même façon que pour la palette, on demande à la out dx,al ; carte vidéo de ne plus scruter la mémoire pour inc dx ; afficher son contenu. Ainsi, c'est une façon de plus in al,dx ; d'éviter l'affichage parasite qui arrive le temps que mov ah,al ; le mode soit totalement initialisé et stabilisé. mov al,01h ; De plus, on peut espérer qu'en demandant un arrêt de push ax ; la lecture de la mémoire, le système s'en voit un peu mov al,ah ; accéléré, et ainsi accélérer l'initialisation du mode or al,20h ; graphique (l'espoir fait vivre :)) out dx,al ; mov esi,X_ptr ; Pointeur sur la liste des constantes à envoyer au CRTC. cld lodsb ; Ceci charge dans AL une valeur qui nous dira quoi faire ; avec le registre MISCELLANEOUS, et incrémente ESI. ; La valeur est égale à ZERO => Rien à faire ; sinon => Envoyer AL au reg. MISC. or al,al ; Devons nous modifier le mode vidéo de base ? jz NonMerci ; Non?─┐ En fait, la réponse est toujours "Oui". mov dx,3C2h ; │ Sauf pour quelques modes tels que le out dx,al ; │ 320x200 en Mode X NonMerci: ; <────┘ (mais notre mode 320x200 est en MCGA...) mov dx,3C4h ; On en a terminé avec les manipulations du registre mov ax,0300h ; MISCELLANEOUS, on peut maintenant désenclencher le out dx,ax ; reset synchrone du registre TIMING SEQUENCER. ; Et maintenant, si on jouait avec le CRTC? mov dx,3D4h ; Dans le 18ème registre du CRTC, on va désenclencher le mov al,11h ; bit de protection. Sans cela, les valeurs que nous out dx,al ; aurions envoyées aux registres du CRTC auraient été inc dx ; ignorées. in al,dx and al,7Fh out dx,al dec dx ; DX pointe à nouveau sur "l'entrée" du registre CRTC. lodsb ; Ceci met dans AL le nombre de registres CRTC à changer xor ecx,ecx ; On doit nettoyer ECX avant de commencer à répéter... mov cl,al ; ...CL (AL) fois OUTSW rep outsw ; On peut envoyer la sauce aux registres du CRTC! ; Juste au cas où le 20ème registre CRTC aurait été oublié dans la table ; d'initialisation, on peut le calculer nous-mêmes (Ouaip, on est des ; braves gars). mov ax,Screen_width ; Vous devez indiquer à la routine quelle est la shr ax,3 ; largeur de l'écran mov ah,al mov al,13h out dx,ax mov dx,3C4h ; Maintenant vous avez la bonne résolution mais il peut mov ax,0F02h ; y avoir des pixels pourris à l'écran à cause de zones out dx,ax ; non nettoyées de la mémoire vidéo. mov edi,0A0000h ; Donc on va nettoyer la mémoire à partir de 0A0000h xor eax,eax ; avec la valeur 0 (qui est le noir standard) et sur une mov ecx,4000h ; longueur de 4000h dwords (256Ko). rep stosd ; Allez, liquidez-moi tout ça! mov dx,3C4h ; On peut redemander à la carte VGA de relire la mémoire pop ax ; pour afficher l'écran... out dx,ax ; mov dx,3C6h ; ... et rétablir la palette pour que l'image soit mov al,0FFh ; visible à l'utilisateur. out dx,al ; La table de constantes que vous devez employer est l'une des suivantes: (Ces tables sont au format C, mais elles peuvent facilement êtres employées dans d'autres langages) word X320Y224[] = { 0x0BA3, 0x6F06, 0xBA07, 0x0008, 0x4109, 0x0810, 0x8A11, 0xBF12, 0x0014, 0xC715, 0x0416, 0xE317 }; word X320Y240[] = { 0x0AE3, 0x0D06, 0x3E07, 0x4109, 0xEA10, 0xAC11, 0xDF12, 0x0014, 0xE715, 0x0616, 0xE317 }; word X320Y256[] = { 0x0CE3, 0x2306, 0xB207, 0x0008, 0x6109, 0x0A10, 0xAC11, 0xFF12, 0x2013, 0x0014, 0x0715, 0x1A16, 0xE317 }; word X320Y270[] = { 0x0BE7, 0x3006, 0xF007, 0x0008, 0x6109, 0x2010, 0xA911, 0x1B12, 0x0014, 0x1F15, 0x2F16, 0xE317 }; word X320Y282[] = { 0x0CE3, 0x6206, 0xF007, 0x6109, 0x310F, 0x3710, 0x8911, 0x3312, 0x2F13, 0x0014, 0x3C15, 0x5C16, 0xE317 }; word X320Y300[] = { 0x0DE3, 0x4606, 0x1F07, 0x0008, 0x4009, 0x3110, 0x8011, 0x2B12, 0x2013, 0x0014, 0x2F15, 0x4416, 0xE317 }; word X320Y360[] = { 0x09E3, 0x4009, 0x8810, 0x8511, 0x6712, 0x2013, 0x0014, 0x6D15, 0xBA16, 0xE317 }; word X320Y400[] = { 0x03E3, 0x4009, 0x0014, 0xE317 }; word X320Y448[] = { 0x0BA3, 0x6F06, 0xBA07, 0x0008, 0x4009, 0x0810, 0x8A11, 0xBF12, 0x0014, 0xC715, 0x0416, 0xE317 }; word X320Y480[] = { 0x0AE3, 0x0D06, 0x3E07, 0x4009, 0xEA10, 0xAC11, 0xDF12, 0x0014, 0xE715, 0x0616 , 0xE317}; word X320Y512[] = { 0x0CE3, 0x2306, 0xB207, 0x0008, 0x6009, 0x0A10, 0xAC11, 0xFF12, 0x2013, 0x0014, 0x0715, 0x1A16, 0xE317 }; word X320Y540[] = { 0x0BE7, 0x3006, 0xF007, 0x0008, 0x6009, 0x2010, 0xA911, 0x1B12, 0x0014, 0x1F15, 0x2F16, 0xE317 }; word X320Y564[] = { 0x0CE7, 0x6206, 0xF007, 0x0008, 0x6009, 0x3E10, 0x8911, 0x3312, 0x2013, 0x0014, 0x3C15, 0x5C16, 0xE317 }; word X320Y600[] = { 0x0BE7, 0xBE06, 0xF007, 0x0008, 0x6009, 0x7C10, 0x8C11, 0x5712, 0x0014, 0x5815, 0x7016, 0xE317 }; word X360Y200[] = { 0x09E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x2D13, 0x0014, 0xE317 }; word X360Y224[] = { 0x12A7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x6F06, 0xBA07, 0x0008, 0x4109, 0x0810, 0x8A11, 0xBF12, 0x2D13, 0x0014, 0xC715, 0x0416, 0xE317 }; word X360Y240[] = { 0x11E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x0D06, 0x3E07, 0x4109, 0xEA10, 0xAC11, 0xDF12, 0x2D13, 0x0014, 0xE715, 0x0616, 0xE317 }; word X360Y256[] = { 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x2B06, 0xB207, 0x0008, 0x6109, 0x0E10, 0xAC11, 0xFF12, 0x2D13, 0x0014, 0x0715, 0x1A16, 0xE317 }; word X360Y270[] = { 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x3006, 0xF007, 0x0008, 0x6109, 0x2010, 0xA911, 0x1B12, 0x2D13, 0x0014, 0x1F15, 0x2F16, 0xE317 }; word X360Y282[] = { 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x6206, 0xF007, 0x6109, 0x310F, 0x3710, 0x8911, 0x3312, 0x2D13, 0x0014, 0x3C15, 0x5C16, 0xE317 }; word X360Y300[] = { 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x4606, 0x1F07, 0x0008, 0x4009, 0x3110, 0x8011, 0x2B12, 0x2D13, 0x0014, 0x2F15, 0x4416, 0xE317 }; word X360Y360[] = { 0x0FE7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x4009, 0x8810, 0x8511, 0x6712, 0x2D13, 0x0014, 0x6D15, 0xBA16, 0xE317 }; word X360Y400[] = { 0x0AE7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x4009, 0x2D13, 0x0014, 0xE317 }; word X360Y448[] = { 0x12A7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x6F06, 0xBA07, 0x0008, 0x4009, 0x0810, 0x8A11, 0xBF12, 0x2D13, 0x0014, 0xC715, 0x0416, 0xE317 }; word X360Y480[] = { 0x11E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x0D06, 0x3E07, 0x4009, 0xEA10, 0xAC11, 0xDF12, 0x2D13, 0x0014, 0xE715, 0x0616, 0xE317 }; word X360Y512[] = { 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x2B06, 0xB207, 0x0008, 0x6009, 0x0E10, 0xAC11, 0xff12, 0x2D13, 0x0014, 0x0715, 0x1A16, 0xE317 }; word X360Y540[] = { 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x3006, 0xF007, 0x0008, 0x6009, 0x2010, 0xA911, 0x1B12, 0x2D13, 0x0014, 0x1F15, 0x2F16, 0xE317 }; word X360Y564[] = { 0x12EB, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0x6206, 0xF007, 0x0008, 0x6009, 0x3E10, 0x8911, 0x3312, 0x2D13, 0x0014, 0x3C15, 0x5C16, 0xE317 }; word X360Y600[] = { 0x12E7, 0x6B00, 0x5901, 0x5A02, 0x8E03, 0x5E04, 0x8A05, 0xBE06, 0xF007, 0x0008, 0x6009, 0x7C10, 0x8C11, 0x5712, 0x2D13, 0x0014, 0x5815, 0x7016, 0xE317 }; word X400Y200[] = { 0x09E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x3213, 0x0014, 0xE317 }; word X400Y224[] = { 0x12A7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x6F06, 0xBA07, 0x0008, 0x4109, 0x0810, 0x8A11, 0xBF12, 0x3213, 0x0014, 0xC715, 0x0416, 0xE317 }; word X400Y240[] = { 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x0D06, 0x3E07, 0x0008, 0x4109, 0xEA10, 0xAC11, 0xDF12, 0x3213, 0x0014, 0xE715, 0x0616, 0xE317 }; word X400Y256[] = { 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x2B06, 0xB207, 0x0008, 0x6109, 0x1310, 0xAC11, 0xFF12, 0x3213, 0x0014, 0x0715, 0x1A16, 0xE317 }; word X400Y270[] = { 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x3006, 0xF007, 0x0008, 0x6109, 0x2010, 0xA911, 0x1B12, 0x3213, 0x0014, 0x1F15, 0x2F16, 0xE317 }; word X400Y282[] = { 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x6206, 0xF007, 0x6109, 0x310F, 0x3710, 0x8911, 0x3312, 0x3213, 0x0014, 0x3C15, 0x5C16, 0xE317 }; word X400Y300[] = { 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x4606, 0x1F07, 0x0008, 0x4009, 0x3110, 0x8011, 0x2B12, 0x3213, 0x0014, 0x2F15, 0x4416, 0xE317 }; word X400Y360[] = { 0x0FE7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x4009, 0x8810, 0x8511, 0x6712, 0x3213, 0x0014, 0x6D15, 0xBA16, 0xE317 }; word X400Y400[] = { 0x0AE7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x4009, 0x3213, 0x0014, 0xE317 }; word X400Y448[] = { 0x12A7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x6F06, 0xBA07, 0x0008, 0x4009, 0x0810, 0x8A11, 0xBF12, 0x3213, 0x0014, 0xC715, 0x0416, 0xE317 }; word X400Y480[] = { 0x11E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x0D06, 0x3E07, 0x4009, 0xEA10, 0xAC11, 0xDF12, 0x3213, 0x0014, 0xE715, 0x0616, 0xE317 }; word X400Y512[] = { 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x2B06, 0xB207, 0x0008, 0x6009, 0x1310, 0xAC11, 0xFF12, 0x3213, 0x0014, 0x0715, 0x1A16, 0xE317 }; word X400Y540[] = { 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x3006, 0xF007, 0x0008, 0x6009, 0x2010, 0xA911, 0x1B12, 0x3213, 0x0014, 0x1F15, 0x2F16, 0xE317 }; word X400Y564[] = { 0x12EB, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0x6206, 0xF007, 0x0008, 0x6009, 0x3E10, 0x8911, 0x3312, 0x3213, 0x0014, 0x3C15, 0x5C16, 0xE317 }; word X400Y600[] = { 0x12E7, 0x7100, 0x6301, 0x6402, 0x9203, 0x6604, 0x8205, 0xBE06, 0xF007, 0x0008, 0x6009, 0x7C10, 0x8C11, 0x5712, 0x3213, 0x0014, 0x5815, 0x7016, 0xE317 }; La structure: (exemple) ┌────Ceci est le nombre de valeurs à envoyer aux registres CRTC. C'est │ en fait le nombre de words dans la table moins 1 (à cause du 1er │ word de la table qui n'est pas envoyé au CRTC mais qui contient │ une valeur à envoyer au registre MISCELLANEOUS et le nombre de │ valeurs à envoyer aux registres CRTC ;) ). │ │ ┌──Ceci est la valeur à envoyer au registre MISCELLANEOUS (ou 0 si │ │ aucune valeur ne doit y être envoyée). │ │ │ │ ┌───Ceci est une valeur à envoyer dans un registre du CRTC. │ │ │ │ │ │ ┌─Ceci est le numéro du registre du CRTC qui recevra la │ │ │ │ valeur citée précédemment. ├┐├┐ ├┐├┐ { 0x0AE3, 0x0D06, 0x3E07, 0x4109, 0xEA10, 0xAC11, 0xDF12, 0x0014, 0xE715, 0x0616, 0xE317 }; Vous pouvez remarquer que les registres 0 à 5 (et le 13h) du CRTC définissent la largeur de l'écran, alors que les registres 6 à 17h (à l'exception du 13h) definissent la hauteur de l'écran. Nous avons plus de modes en poche que les quelques-uns :) que nous avons inclus dans GrafX 2.00, mais ils ne sont ni vraiment utiles ni vraiment stables. Nous pourrons toutefois décider de les inclure dans une prochaine version. S'il manque certains de vos modes préféres, envoyez nous simplement la liste des constantes que l'on doit balancer au CRTC à la manière de la structure utilisée ci-dessus. IMPORTANT! Les valeurs des constantes citées plus haut ne sont pas supportées par tous les moniteurs ou les cartes vidéos. Nous avons testé GrafX2 avec différentes configurations et avons constatés que certains modes ne marchent pas du tout avec certaines cartes vidéos, alors que d'autres débordent de l'écran, sont décentrés, assombris, trop clairs, ou tassés. Toutefois, ils marchent tous correctement avec notre pauvre petite Tseng Labs ET4000... Si vous avez déjà une bonne connaissance à propos du CRTC, et avez des valeurs différentes des notres pour certains modes, merci de nous en informer. Nous nous en servirons s'ils marchent mieux sur une majorité d'ordinateurs. VESA: (Un "pseudo-standard" pour les modes Super-VGA) ═════ Nous nous servons du VESA pour des modes qui nécessitent une largeur de 640, 800 ou 1024 pixels. Mais il existe un moyen de combiner la hauteur des Modes X avec les modes VESA, il est ainsi possible d'avoir des modes aussi timbrés qu'en Mode X. mov ax,4F02h mov bx,Video_mode int 10h Les modes VESA 256 couleur VESA sont: 100h : 640x400 101h : 640x480 103h : 800x600 105h : 1024x768 107h : 1280x1024 (non disponible dans GrafX2 parce qu'uniquement supporté par des cartes vidéo avec 2 Megaoctets ou plus de mémoire vidéo) Comme avec les Modes X, vous pouvez modifier les registres CRTC pour accéder aux modes "VESA-X"! (Notez que certaines cartes vidéo ne supportent pas les modifications des registres du CRTC VGA dans les modes VESA.) Pour passer dans ces modes étendus, passez dans un mode VESA standard ayant la bonne largeur, puis appelez Modif_registres_CRTC avec la bonne table de hauteur. Exemple (640x512) : VESA_Set_mode(101h) // On passe dans un mode qui a la même largeur Modif_registres_CRTC(Y512) // On modifie la hauteur * Tables des hauteurs: word Y224[] = { 0x09A3, 0x6F06, 0xBA07, 0x0008, 0x4109, 0x0810, 0x8A11, 0xBF12, 0xC715, 0x0416 }; word Y240[] = { 0x09E3, 0x0D06, 0x3E07, 0x0008, 0x4109, 0xEA10, 0xAC11, 0xDF12, 0xE715, 0x0616 }; word Y256[] = { 0x0900, 0x2B06, 0xB207, 0x0008, 0x6109, 0x0A10, 0xAC11, 0xFF12, 0x0715, 0x1A16 }; word Y270[] = { 0x09E7, 0x3006, 0xF007, 0x0008, 0x6109, 0x2010, 0xA911, 0x1B12, 0x1F15, 0x2F16 }; word Y282[] = { 0x0AE3, 0x6206, 0xF007, 0x0008, 0x6109, 0x310F, 0x3710, 0x8911, 0x3312, 0x3C15, 0x5C16 }; word Y300[] = { 0x09E3, 0x4606, 0x1F07, 0x0008, 0x4009, 0x3110, 0x8011, 0x2B12, 0x2F15, 0x4416 }; word Y350[] = { 0x09A3, 0xBF06, 0x1F07, 0x0008, 0x4009, 0x8310, 0x8511, 0x5D12, 0x6315, 0xBA16 }; word Y360[] = { 0x07E3, 0x0008, 0x4009, 0x8810, 0x8511, 0x6712, 0x6D15, 0xBA16 }; word Y400[] = { 0x01E3, 0x4009 }; word Y448[] = { 0x09A3, 0x6F06, 0xBA07, 0x0008, 0x4009, 0x0810, 0x8A11, 0xBF12, 0xC715, 0x0416 }; word Y480[] = { 0x09E3, 0x0D06, 0x3E07, 0x0008, 0x4009, 0xEA10, 0xAC11, 0xDF12, 0xE715, 0x0616 }; word Y512[] = { 0x0900, 0x2B06, 0xB207, 0x0008, 0x6009, 0x0A10, 0xAC11, 0xFF12, 0x0715, 0x1A16 }; word Y540[] = { 0x09E7, 0x3006, 0xF007, 0x0008, 0x6009, 0x2010, 0xA911, 0x1B12, 0x1F15, 0x2F16 }; word Y564[] = { 0x09E7, 0x6206, 0xF007, 0x0008, 0x6009, 0x3E10, 0x8911, 0x3312, 0x3C15, 0x5C16 }; word Y600[] = { 0x09E7, 0xBE06, 0xF007, 0x0008, 0x6009, 0x7C10, 0x8C11, 0x5712, 0x5815, 0x7016 }; Modifier les registres CRTC: (inspiré de l'init. des Modes X... voir plus ──────────────────────────── haut pour de plus amples détails) mov esi,XVESA_Ptr cld lodsb or al,al ; Devons nous modifier le mode vidéo de base ? jz NonMerci ; Non?─┐ La réponse peut être "Non" car les initialisations mov dx,3C2h ; │ de certains modes VESA mettent directement la out dx,al ; │ bonne valeur pour le registre MISCELLANEOUS. NonMerci: ; <────┘ mov dx,3D4h mov al,11h out dx,al inc dx in al,dx and al,7Fh out dx,al dec dx lodsb xor ecx,ecx mov cl,al rep outsw Si vous êtes suffisament astucieux, vous pourrez combiner les constantes utilisées dans les Modes X pour obtenir plus de modes "VESA-X" tels que le 640x200, 800x480, etc... (mais je ne pense pas que ça marche convenablement avec les largeurs de 1024 pixels puisque ce mode est généralement entrelacé... Mais qui sait?...) Je pense que le plus difficile est de trouver la bonne valeur du registre MISCELLANEOUS.