[gPXE] int 10h problem
Gene Cumm
gene.cumm at gmail.com
Sat Apr 2 10:06:46 EDT 2011
2011/4/2 何闯 <justhechuang at 163.com>:
> Hi all,
> As Gene suggested, I browsed vesamenu code and found nothing useful.
> However, I figured out how to use the 640X480 mode in mode 12h. It turns out
> that one pixel takes one bit place. Codes are:
> //////////////////////////////////////////////////////////////////////////////////////
> void setvga() { __asm__ __volatile__ ( REAL_CODE ( "movw $0x12, %%ax\n\t"
> "int $0x10\n\t")::); }
> void putpixel(int x,int y, int c __unused ) { char v; char idx; if(vediobuf
> == NULL) { vediobuf = (unsigned char*)phys_to_user(0xa0000); } v =
> *(vediobuf+x/8+80*y); idx = x % 8; //One byte divided into eight bits for
> pixels switch(idx) { case 0: *(vediobuf+x/8+80*y) = (1<<7)|v; break; case 1:
> *(vediobuf+x/8+80*y) = (1<<6)|v; break; case 2: *(vediobuf+x/8+80*y) =
> (1<<5)|v; break; case 3: *(vediobuf+x/8+80*y) = (1<<4)|v; break; case 4:
> *(vediobuf+x/8+80*y) = (1<<3)|v; break; case 5: *(vediobuf+x/8+80*y) =
> (1<<2)|v; break; case 6: *(vediobuf+x/8+80*y) = (1<<1)|v; break; case 7:
> *(vediobuf+x/8+80*y) = (1<<0)|v; break; } }
> ////////////////////////////////////////////////////////////////////////////////////////////
>
> And this works, I finally entered 640X480 mode!!! Nevertheless, one bit can
> only hold two colors(black and white),
> but document says that video mode 12h will enter 640X480X16 resolution,
> which means 4bit for one pixel,
> this conflicts with my practise. I am confused again..............
Your video card might not know mode 12h and used 11h instead.
Also, I'd advise against writing the video buffer directly unless
you've asked your video card where its buffer is. See also INT 10h
AH=0Ch, AH=0Dh and AH=0Fh.
> 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.
>
>
>
--
-Gene
"No one ever says, 'I can't read that ASCII(plain text) e-mail you sent me.'"
More information about the gPXE
mailing list