Re: [gPXE] int 10h problem
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(0xa); } 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) = (17)|v; break; case 1:
*(vediobuf+x/8+80*y) = (16)|v; break; case 2: *(vediobuf+x/8+80*y) =
(15)|v; break; case 3: *(vediobuf+x/8+80*y) = (14)|v; break; case 4:
*(vediobuf+x/8+80*y) = (13)|v; break; case 5: *(vediobuf+x/8+80*y) =
(12)|v; break; case 6: *(vediobuf+x/8+80*y) = (11)|v; break; case 7:
*(vediobuf+x/8+80*y) = (10)|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(0xa); //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
Re: [gPXE] int 10h problem
2011/4/2 何闯 justhechu...@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(0xa); } 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) = (17)|v; break; case 1:
*(vediobuf+x/8+80*y) = (16)|v; break; case 2: *(vediobuf+x/8+80*y) =
(15)|v; break; case 3: *(vediobuf+x/8+80*y) = (14)|v; break; case 4:
*(vediobuf+x/8+80*y) = (13)|v; break; case 5: *(vediobuf+x/8+80*y) =
(12)|v; break; case 6: *(vediobuf+x/8+80*y) = (11)|v; break; case 7:
*(vediobuf+x/8+80*y) = (10)|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.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(0xa); //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.'
___
gPXE mailing list
gPXE@etherboot.org
http://etherboot.org/mailman/listinfo/gpxe
Re: [gPXE] int 10h problem
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(0xa); //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
___
gPXE mailing list
gPXE@etherboot.org
http://etherboot.org/mailman/listinfo/gpxe
Re: [gPXE] int 10h problem
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
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(0xa); //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
Re: [gPXE] int 10h problem
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(0xa); //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
Re: [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.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(0xa); //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
