[gPXE] int 10h problem

[何闯]

Thanks for the clue, I will check the code in vesamenu.c32 and find why. ：）



At 2011-04-02，"Gene Cumm" <gene.cumm at gmail.com> wrote:

>On Fri, Apr 1, 2011 at 15:15, Vaza gpxe <vaza.gpxe at gmail.com> wrote:
>> I'd suggest you find out how many bytes there are per pixel. I guess
>> you have 4 (not 1 you are using) and the resolution you think you see
>> is actually 640x120. You may also have limited video memory that makes
>> different resolutions use different pixel sizes
>
>I believe there should be only 4 bits at that video mode.
>
>Soforth, I'd suggest examining http://www.ctyme.com/intr/int-10.htm
>for starters.  I believe INT 10h AX 4F00h is the start of VESA related
>info that Syslinux uses for vesamenu.c32 (and possibly gfxboot.c32)
>
>-- 
>-Gene
>
>> In Reply to:
>> 2011/4/1 何闯 <justhechuang at 163.com>:
>>> Deal all,
>>> I just tested int 0x10 BIOS interrupt to draw some pictures.
>>> However, when I coded the follow to enter 640X480 video mode, it seems
>> that
>>> the actual video mode is 640X100,
>>> I draw a rectangle with range(0,0, 640, 480) to verify, and it resulted in
>>> range(0,0, 640,100), about a quarter square of a rectangle.
>>> And I noticed that 320X200 video mode is OK, and 320X200 == 640X100, is
>> that
>>> mean my machine can hand only 64000 pixels?
>>> Can anyone tell me why?
>>>
>> ////////////////////////////////////////////////////////////////////////////
>> ///////////////////////////
>>> void setvga()
>>> {
>>> __asm__ __volatile__ ( REAL_CODE ( "movw $0x4f02, %%ax\n\t"  //ax=0x0012
>>> here seem stay in the text mode
>>> "movw $0x0101, %%bx\n\t"
>>> "int $0x10\n\t" )::);
>>> }
>>> void putpixel(int x,int y,int c)
>>> {
>>>     if(vediobuf == NULL)
>>> {
>>>    vediobuf = (unsigned char*)phys_to_user(0xa0000);  //physic address of
>>> graphic mode
>>> }
>>>     *(vediobuf+x+640*y)=c;
>>> }
>>>
>> ////////////////////////////////////////////////////////////////////////////
>> /////////////////////////
>>>
>>>
>>> yours,
>>> soforth
>>
>> I'd suggest looking at other boot loaders and how they write to the
>> screen (including Syslinux's vesamenu.c32 and gfxboot.c32).  64,000
>> sounds like the 16-bit limit of 65,536 per segment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://etherboot.org/pipermail/gpxe/attachments/20110402/2e782795/attachment-0001.html>