Reprise du message précédent :
avec OpenWatcom, l'asm il vaux mieux l'utiliser comme ça:
 

#pragma intrinsic (Show_Mouse)  
  void Show_Mouse(void);  
  #pragma aux Show_Mouse = "mov ax,1" \  
                           "int 33h"  \  
                           modify [ eax ];  
Ca veut dire koi tout ca?

   
  #pragma intrinsic (Show_Mouse)  
  void Show_Mouse(void);  
  #pragma aux Show_Mouse = "mov ax,1" \  
                           "int 33h"  \  
                           modify [ eax ];  
Ca veut dire koi tout ca?

dsl pour le double message, fausse manip...

c'est un exemple ou le driver souris est appellé pour afficher la souris.

et pour ajouter simplement de l'assembleur du style
mov ax,4f02h
mov bx,103h
int 10h
?

lire la doc

ça peut être plus chiant.
comme dit à la fin de http://bbs.ee.ntu.edu.tw/boards/Programming/10/19.html
 
le Watcom est une brute en optimisation (à l'époque il sortait vraiment du lot), et le compilo n'utilise pas un asm/_asm, et préfère une déclaration du code asm séparée, avec un placement explicite des variables passé, et des registres modifiés, afin d'optimiser le code C/C++ autour de la routine asm.
 
pour ton 4f02h: ce serait un truc du genre:
 
short VBE_SetMode(short Mode, short CRTC_Seg, short CRTC_Offset);
#pragma aux = "mov ax,4f02h" \
              "int 10h"
              parm [ebx][es][edi] value [eax];
 
parm défini les registres mappés par pour chaque paramètre
Mode => BX de EBX
CRTC_Seg => ES
CRTC_Offset => DI de EDI
 
modify peut définir les registres altérés par le code (par exemple modify [ecx]).
 
et value [eax] indique que la valeur de retour est passé par AX de eax.
 
 
 

Après bien des complications, j'ai réussi a creer un prog en assembleur mode protégé mais maintenant, quand je défini mon mode vidéo 800*600*8 je ne peux pas obtenir l'adresse de la mémoire vidéo parceque la fonction 4f01h de l'int 10h demande que es:[di] pointe sur un buffer de 256 octets, or je n'ai plus de segments... et l'int ne marche pas!...

hé ouiiiiiiiiii
 
- welcome to the real world -
 
il faut que tu alloues un buffer dans l'espace mémoire < 1 Mo, attends je regarde ce que j'avais codé à l'époque et je te dis quelle appel DPMI permet de faire ça.

valà c'est ça:
 
http://www.tenberry.com/dpmi/09.html#01
 
tu as les decriptions de l'api DPMI, api renforcé par le Dos Extender que tu utilises (DOS4G(W) PMODE(W))

autant pour moi l'asm en ligne a été rajouté à la version 11 !!!

Merci bien, je vais voir ce que je peux en tirer...

Ok l'interruption 31h fonctionne, j'obtient bien un segment en retour mais des que je modifie es, le programme plante sauf si je modifie es comme ca:
mov ax,es
mov es,ax
ce qui ne sert pas à grand chose...
sinon, au moindre mov es,... ca plante
quand je debug avec soft ice, au moment de l'instruction mov es,... je me retrouve avec un changement de segment de code (comme un call far)et mon prog s'arrète après m'avoir affiché le contenu des registres...

mov es, <val> ?
Normalement c'est pas possible.
C'est soit comme t'as fait, soit push <val>, pop es

ouais mais  
mov ax,<val>
mov es,ax
ca plante (pas a la compilation, pendant l'execution)
mov es,<val> ca plante a la compilation
je vais tenter push/pop

en mode protégé, les registres de segments sont des sélecteurs: des pointeurs sur une table décrivant le segment, qui sera chargé dans un cache spécialisé au moment de la modification du registre.
 
contrement au mode réel, il faut obsolument que ce que tu vas mettre dans un ds/es... ayes une "consistance". (ie tu peux pas mettre n'importequoi)
 
donc y'a deux manières:
 
soit tu mets dans ES ce que te retourne le DPMI dans le registre DX.
 
soit tu linéarise le segment du mode réel retourné dans AX. (soit un shift de 4 bits).
 
perso pour ma librairie vesa 2.0 de l'époque, je faisait une linéarisation des segments réels pour y accéder en mode protégé. (je passais po par le sélecteur PM)

En mode protégé modifier un registre de  segment est une instruction privilégiée aussi.

exact, mais comme avec un DosExtender, l'appli est en ring 0

C'est cool ça marche j'ai obtenu une zone de mémoire que je peux remplir, je l'ai rempli avec des caractères que j'ai affichés avec l'int 21h. Le seul prob c'est que la fonction 4f01h de l'int 10h me renvoie tjs une opération non conforme meme avec le bon es et le bon di (j'ai vérifié avec soft-ice)
Merci pour tout ce ke vs avez deja fait, ca avance petit à petit.

-je suis con-
 
j'ai oublié de te dire un truc, attends je vérifies...

bon blague que j'ai totallement zappé:
 
bon:
 
en mode protégé, tu dois absolument avoir dans DS/ES... des selecteurs existants.
 
oki.
 
problème:
 
quand tu appelles le BIOS VESA, il te faut un segment : offset du mode réel ( < 1Mo).
 
conséquence:
 
si tu mets un SEGMENT : OFFSET dans ES : DI pour que le VESA te retourne ta structure remplie, le mode protégé te gueule dessus au moment de la modification de ES.
 
logique.
 
donc pour tous les appels VESA nécessitant un passage de segment : offset dans ES : DI par exemple tu dois utiliser la fonction DPMI 300h.
 
http://www.tenberry.com/dpmi/1101.html

tiens la librairie que je m'étais faite à l'époque:
 
http://site.voila.fr/bjone/vesa.7z
 
pas de critiques, j'aimais bien tout coder en ASM, et c'était l'époque de nioubage avec du C dans des CPP

Moi aussi j'aime bien tout coder en asm c'est plus rigolo pour debugger!
oups c'est plus dur a digérer ca...
Je m'y met tt de suite!

Euh...
Tu pourrais m'expliquer un peu plus stp?

par rapport à l'appel DPMI ?

delete ton autre topic http://forum.hardware.fr/hardwaref [...] 3440-1.htm

comment je fais pour le virer?
Oui pour l'appel DPMI j'ai pas bien compris ce qu'il falait envoyer et ce que la fonction retournait...

tu l'édites, et tu as une case à cocher pour le supprimmer.
 
pour l'appel DPMI, tu as une structure à remplir, cette structure contiens l'état des registres qui seront utilisé lors de l'appel de l'interruption en mode réel.
 

la description de la structure est là:
http://www.tenberry.com/dpmi/11.html

Je n'ai aucun problème pour "émuler" (je c pas si ce mot peux s'employer) en mode réel certaines interruption (choix du mode 800*600*8, affichage d'une chaine de caractères).
La fonction 4f01h de l'int 10h qui doit mes renvoyer des infos dont l'adresse de la mem écran ne fonctionne tjs pas! A la fin de l'int 31h je me retrouve avec mes registres "virtuels" modifiés et _ax=4f c'est à dire que la l'int 10h à fonctionné mais la zone es:di est tjs remplie avec des 0...

dsl pour le smiley je voulais dire es: di

attention, avec la fonction 4f01h, c'est toi qui défini le ES:DI avant l'interruption mode réel (donc la structure).
 
le bios ne modifies pas ES:DI après 4f01h !!!

lol

j'ai dans mes données des variables
_edi dd ?
_esi dd ?
...
en respectant l'ordre donné sur la page dont tu m'as filé le lien et avant de lancer int 31 je fais pointer es:edi sur _edi (le début de la structure).
Dans cette structure j'ai mis dans _es et _edi les valeurs pour que ça pointe sur la zone de mémoire qui me sert de buffer pour les données que me renvoie la fonction 4f01h. Zone mémoire qui est remplie de zéro et qui le reste malheureusement.
J'ai aussi essayé de mettre la structure dans un segment de la mémoire <1Mo (int 31h ax,100h) mon buffer est aussi dans cette mémoire. Meme résultat: 00000000000000000000...

dans la structure contenant le contexte de registre, dans ES : DI, tu dois mettre le segment : offset (mode réel) du buffer pour la fonction 4f01h.
 
cette structure n'a pas besoin d'être allouée < 1 Mo.

Ca commence a faire un bout de tps que je m'arrache les cheveux la dessus...voila mon code, je capte pas pourquoi ça marche pas:
.386
 
.model flat
 
.stack
db 20000 dup(?)
 
.data
segment_reel dw ?
 
_edi dd 0
_esi dd 0
_ebp dd 0
     dd 0
_ebx dd 0
_edx dd 0
_ecx dd 0
_eax dd 0
_flags dw 0
_es dw 0
_ds dw 0
_fs dw 0
_gs dw 0
_ip dw 0
_cs dw 0
_sp dw 0
_ss dw 0
                   
.code
start:
mov ax,100h            
mov bx,300h
int 31h
mov segment_reel,dx
 
push es      
mov es,dx   ;on met ts les octets du futur buffer à 0
xor di,di
mov cx,300h
mise_a_zero:
mov es:[di],0
inc di
dec cx
jnz mise_a_zero    ;ya des zeros partout
 
 
mov _eax,4f01h        ;contexte de registre
mov _ecx,103h    ;mode 800*600*8=103h
mov _edi,00
mov ax,segment_reel
mov _es,ax
 
push ds             ;info pour l'int 31
pop es
mov ebx,10h
lea edi,_edi
mov eax,300h
int 31h
 
mov ax,segment_reel    ;maintenant on va voir dans le buffer
mov es,ax
xor di,di
mov ax,word ptr es:[di]
pop es
test ax,ax
jz fin                   ;si c'est encore 0, y'a une erreur
xor eax,eax     ;attend une touche si le buffer est rempli
int 16h
fin:
mov ax,4c00h
int 21h
end start

stop.
 
après l'int 31h / 100h, le segment en mode réel c'est dans AX qu'il est.
 
ce que tu peux mettre dans ES en mode protégé c'est le sélecteur retourné dans DX.
 
pour effacer ton buffer, fais plustôt un REP STOSD
 
de +, ton mov es:[di],0 on sait pas quelle est la taille de ton opérande.

quand je mets ce qu'il y a dans ax dans es, j'ai une opération non conforme pas avec ce qu'il y a dans dx
Je peux lire et modifier sans problème le segment de mémoire obtenu ainsi.  
pour es:[di], mon assembleur me met byte ptr par defaut donc je le met jms

AX, le segment réel du buffer alloué, c'est dans ES de la structure qu'il faut le mettre.
 
le ES courant, le vrai, c'est DX qu'il faut mettre pour accéder au buffer alloué, mais plus tard.  
 
lors de l'appel au service de simulation d'interruption en mode réel, tu copies DS dans ES et l'offset du premier élément de ta structure dans DI pour que le service prennent bien ta structure de contexte.
 
après, pour accéder aux infos du mode:
 
soit tu remets le DX de l'étape d'allocation du buffer dans ES.
 
soit tu linéarise le segment mode réel du BUFFER en le shiftant de 4 bits vers la gauche, ce sera l'adresse linéaire & physique du buffer en mode réel. (vu qu'en mode protégé sous DOS, via un Dos Extender comme DOS/4G & PMODE, le segment de donné est basé en 0)

perso je prefère avoir ES&DS qui sont au même sélecteur, et de linéariser les segment mode réel en adresse linéaire/physique.