[gPXE] int 10h problem

[Gene Cumm]

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.