TESTEUR DE COMPATIBILITTÉ VESA (SUPER VGA)
cs_patatalo
Messages postés
1466
Date d'inscription
vendredi 2 janvier 2004
Statut
Modérateur
Dernière intervention
14 février 2014
-
19 août 2007 à 22:58
cs_patatalo Messages postés 1466 Date d'inscription vendredi 2 janvier 2004 Statut Modérateur Dernière intervention 14 février 2014 - 10 janv. 2009 à 12:18
cs_patatalo Messages postés 1466 Date d'inscription vendredi 2 janvier 2004 Statut Modérateur Dernière intervention 14 février 2014 - 10 janv. 2009 à 12:18
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/43816-testeur-de-compatibilitte-vesa-super-vga
https://codes-sources.commentcamarche.net/source/43816-testeur-de-compatibilitte-vesa-super-vga
10 janv. 2009 à 12:18
vous passez les parametres que VOUS voulez a VOS handlers d'interruption. la partie Hi de eax ne devrait pas etre modifié par le BIOS ( a verifier pour chaque fonction bien sur... passages mode PM par le bios,...). Si votre handler est en tete de liste, plus de problemes, vous pouvez vous envoyer des registres 32 bits.
@++
10 janv. 2009 à 01:07
par contre les registres d'adresse en 32bit ne sont pas uttilisable car en 32bit la taille des segment est limité a 64Ko; si on les uttilise au dela de la limite ça déclenche l'exeption 0Ch (enfin je croit) qui en mode protégé fait planter le dos
y'as des bidouille pour pouvoir uttiliser les adresses 32bit en mode protégé (je les uttilise dans mon mini-os mortimer qui est en source sur le site) mais c'est pas une méthode officiel donc pas vraiment conseillé (les constructeur préfère que l'on uttilise le mode protégé)
9 janv. 2009 à 21:59
Mais dans ce cas c'est inutile vu que les interruptions utilisent la partie 16 bits ...
9 janv. 2009 à 19:47
le mode réel c'est comme un segment en mode protégé avec une préselection 16bit
ça reste aussi possible qu'une instruction 16bit en mode 32bit
8 janv. 2009 à 20:01
20 oct. 2007 à 15:36
j'ai refait entièrement le programme car a l'origine il s'agissait de deux programmes indépendants qui ont été fusionné,l'un testait la compatibilité vesa et l'autre servait a tester les modes supporté.
j'espère avoir fait des progrè dans la clareté du code
25 sept. 2007 à 15:42
"il y a aussi une sous fonction qui permet d'afficher un nombre entier contenu dans un registre(deci32 il me semble)"
c'est pas un peu bizarre comme commentaire ? c'est toi qui l'a fait ce code ou pas ? sinon, ça serait sympas de dire d'ou tu l'as tiré voir meme de donner un lien. D'ailleurs, c'est pas deci32 mais dec32.
je vais pas te jeter la pierre quand au nombre de commentaires, je suis pareil mais essai au moins de donner des noms de labels explicites, de creer des structures et des equates dans ce cas. Ca te serviras quand tu reprendras ce code dans quelques mois et que tu seras le premier à le mettre à la corbeille car illisible. L'assembleur que tu utilise est soit mal utilisé soit mauvais, trouve t'en un avec la possibilité de faire des symboles locaux.
@++
1 sept. 2007 à 15:56
c'es vrai que je vien de la relire et je voit tout les db.. etc et ça vient du fait que je comile avec A86 et qu'il ne reconnait pas certaine instruction (notament les sauts conditionnel)
je vait essayer de corriger le tir,voir retire la source
mon autre compilateur c'est FASM je vait transformer la source pour lui
merci de vos remarque!
30 août 2007 à 13:51
je suis assez d'accord avec patatalo, surtout quand on ne voit aucun commentaire avec des opcodes comme suit :
# db 66h
# xor ax,ax
-> 66h - operand size override prefix as it was in 32 bit x86
d'habitude quand je code, je préfère écrire "xor eax,eax" ... c'est un peu plus lisible !!
19 août 2007 à 22:58
pourquoi utiliser les registres 32 bits mais pas les jump conditionnel near puisque la compatibilité est abandonnée ?
ça ressemble étrangement a un code désassemblé avec tout ces db !! notement db 0h,0h ??
le niveau initié me parait un peu surévalué. (après, tout est relatif...)
@++