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.............. At 2011-04-02,"Gene Cumm" <gene.c...@gmail.com> wrote: >On Fri, Apr 1, 2011 at 15:15, Vaza gpxe <vaza.g...@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 何闯 <justhechu...@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.
_______________________________________________ gPXE mailing list gPXE@etherboot.org http://etherboot.org/mailman/listinfo/gpxe