int 10h AX = 4F00h
in [ASM]
|
Prev: Atmel AVR assembler
Next: Beginner Learning Assembler
From: wolfgang kern on 17 Aug 2005 05:46 Hi Frank, | > For the field "06h DWORD pointer to OEM name", it contains a very | > high memory address, such as 0xc0000048 for my notebook, when i access | > this memory location, my computer restart. Why and how to get the right | > information of this field? | | Hi Peter, | | I'm just guessing, but that looks like a segment:offset address to me. | C000:0048 would be a reasonable place to find an oem string for the | video bios. Once again your and my reply looks as from one person. Seems we already mutated to the 'ASM-answer-twins' :) I don't believe in 'repetitive coincidence', ... there must be something more explainable. __ wolfgang
From: Frank Kotler on 17 Aug 2005 06:02 cmk128(a)hotmail.com wrote: > And i think this web is wrong > http://www.inversereality.org/tutorials/graphics%20programming/videomodesVESA.html > > > It said : "Notice that we are filling in vesainfo.VESASignature with > "VESA" before calling the interrupt. This tells the BIOS that we are > requesting VESA information, VESA 2.0 items WILL NOT BE FILLED IN! That's in agreement with what RBIL says... > The > new standard is to fill in the signature with "VBE2" so that all VESA > 2+ information will be filled in!" , I don't know i have vesa 1.0 or > 2.0, how can i fill in before calling the interrupt, First, make sure you've got a buffer big enough for the VBE2 info - 512 bytes. Then call it with "VBE2". If it fails, call it with "VESA". I haven't tried this, but that's what I'd try. Or call it with "VESA" first, and then with "VBE2" if the version number's high enough... if you need that information. > and i have > tested, even i don't fill in the signature field before calling the > interrupt, i still get the correct information, except the OEM name > field problem as above. That's interesting... but I'd still fill in something. The way in which that site handles the oem string (if I comprehend their C++) confirms my guess and Wolfgang's information that the address returned is in segment:offset form. I don't think VESA/VBE2 has anything to do with that problem... Best, Frank
From: Frank Kotler on 17 Aug 2005 07:21 Hi Wolfgang, > Once again your and my reply looks as from one person. Except that I was guessing... > Seems we already mutated to the 'ASM-answer-twins' :) > I don't believe in 'repetitive coincidence', ... > there must be something more explainable. Maybe just that it's the right answer? We're a couple of the "lingering dead" that hang around this NG, hoping to discuss assembly language once in a while. We're willing to answer questions, if we know the answer. We're interested in things besides "apps for Windows". I don't think there's too much more to it than that. Best, Frank
From: wolfgang kern on 17 Aug 2005 08:17 Hi Peter, | And i think this web is wrong | http://www.inversereality.org/tutorials/graphics%20programming/videomodesVESA.ht ml I couldn't make it work from PM either, so I get all the vital mode info things during boot and use the here found mode-numbers to call the PM-VESA mode-set then. With the following I get a table with my preferred modes added by the VESA-number and some more info for the modes available. my comments may be terse, but I think the code talks for itself. __ wolfgang REAL16 ; all values in hex ! ; uses: es,ds,di,si,bx,ecx,eax,flg ; nothing preserved nor optimised here. ;get and list usable VESA-modes: push 9f00 pop es xor di,di ;9f00:0000 (my 'temporary' buffer 4KB) mov ax,4f00 int 10 cmp ax,004f jnz noVESA ldds:si, es:[di+0e] ;far pointer to info block mov ax, es:[di+12] ; sll eax,10 ;move it to high-word and clear low-word mov cs:[vesa_var#..],eax ;global-sys vars movzx eax, word es:[di+08] movzx ecx, word es:[di+06] sll eax,04 add eax,ecx mov cs:[vesa_var#..],eax ;linear address of OEM-string mov eax,es:[di+0a] mov cs:[vesa_var#..],eax ; push 9f20 pop es ;just use the remaining buffer xor di,di ;for 'details on mode' L1: mov cx,[si] ; we got ds and si above add si,02 cmp cx,-01 jz end_of_list ; go out a'here mov ax,4f01 ;cx= number of vesa-mode in list int 10 cmp ax,004f jnz some_error_in_here mov al,es:[di] and al,93 cmp al,93 ;I will use only certain modes jnz L1 ;so skip the not wanted mov bx,7800 ;my prepared table of modes I'll support L2: mov al,es:[di+19] mov ah,es:[di+1b] cmp ax,cs:[bx+8] ;check if this is a wanted resolution jnz L3 mov eax es:[di+12] cmp eax cs:[bx+4] ;check if colour-dept matches my needs jz fine L3: add bx,20 ;next in my table cmp bx,7c00 ; end of my table jc L2 jmp L1 ;get next mode fine: mov cs:[bx],cx ;store the 'good' VESA# in my list mov ax,es:[di] mov cs:[bx+02],ax ;store some values of interest too mov ax,es:[di+10] mov cs:[bx+0a],ax ; mov eax,es:[di+28] mov cs:[bx+0c],eax ; ..... ; calculate and store page-size/limits.. jmp L1 ; next mode errors: noVESA: .... end_of_list: ; done now ....
From: wolfgang kern on 17 Aug 2005 08:29
Yes Frank, nothing mystic on it :) just similar targets in mind. but this time we snipped identical and answered like a chorus :) __ wolfgang | Hi Wolfgang, | | > Once again your and my reply looks as from one person. | | Except that I was guessing... | | > Seems we already mutated to the 'ASM-answer-twins' :) | > I don't believe in 'repetitive coincidence', ... | > there must be something more explainable. | | Maybe just that it's the right answer? | | We're a couple of the "lingering dead" that hang around this NG, hoping | to discuss assembly language once in a while. We're willing to answer | questions, if we know the answer. We're interested in things besides | "apps for Windows". I don't think there's too much more to it than that. | | Best, | Frank |