OSDev.org

hi all,
in the baby step 5, the codes write to the 0xb800,

http://www.osdev.org/osfaq2/index.php/BabyStep5

is there any info about it? thanks

In 80x25 text mode, the video memory at 0xA0000 - 0xBFFFF (IIRC) can be written to to draw to the framebuffer. The text mode framebuffer is at 0xB8000.

AR wrote: In 80x25 text mode, the video memory at 0xA0000 - 0xBFFFF (IIRC) can be written to to draw to the framebuffer. The text mode framebuffer is at 0xB8000.

what 's for 0xa0000-0xb7fff?

can you give me more details? thanks

mode 13h graphics (320x200x64 good for stater gui)
after that if you put data in that memory a pixel will apere acording to where and what number you put in

"what's for" has no specific meaning in English, what are you talking about? Why is it there? How to use it? What is it?

you should google for a tutorial on VGA programming. There are plenty of them in various game-developing website.

It's 320x200x256 for mode 0x13.. Not 64 colors.

Hey I have a prob writing in frame buffer for 640x480x16 mode. Frame buffer starting address is 0xA0000 but i dont know how to write in it to glow a pixel?

I have used int 10h in BootLoader to initialize graphics.

unsigned char *VGA = (unsigned char *)0x0A0000;
void pixel(int x, int y, unsigned char color)
{
VGA[ ( y * 640 ) + x ] = color;
}

P.S. (VGA[(y<<8)+(y<<6)+x] = color;) is much faster

Hi,

GLneo wrote:VGA[ ( y * 640 ) + x ] = color;

That won't work for 16 colour modes (e.g. 640*480*16 colour, which is standard VGA mode 12).

In these modes you've got 4 bits per pixel, where each bit is seperated and placed into one of 4 bit planes.

In this case (starting from a black screen), "VGA[0 ] = 0xFFFF" could result in 16 pixels at the top left of the screen, which would be either blue, green, red or dark grey depending on which plane was selected.

Drawing a single pixel is a complex and slow operation. The general idea goes like this:
The "select_plane()" function writes to a VGA IO port to select which plane is being operated on. I can't remember the exact details (I'll have a look when I get home).

This isn't the only way it can be done - in the video card there's about 4 different IO ports that control how reads/writes to video memory behave, with a few different masks and things to make it more confusing .

Regardless of how it's done it's slow. For this reason I use double buffering so that I can draw each pixel into a memory buffer and then blast the 4 planes to the video card using 4 "rep stosw" instructions, each preceded by the "select_plane()" corresponding to the plane. This can be improved (depending on what your drawing) by keeping track of which planes are "dirty" so that if you add some blue pixels you only need to update the blue plane, or if you're using white text on a green background you don't have to change the green plane.


Cheers,

Brendan

GLneo wrote: unsigned char *VGA = (unsigned char *)0x0A0000;
void pixel(int x, int y, unsigned char color)
{
VGA[ ( y * 640 ) + x ] = color;
}

P.S. (VGA[(y<<8)+(y<<6)+x] = color;) is much faster

It is not in any way faster, any form of decent compiler will rewrite that for you.

the bottom of:
www.brackeen.com/home/vga/basics.html
says it is faster but i've never seen a difference

Any C compiler that passed it's 0.01 release can do that optimization..
Maybe he's talking about using it in asm instead of "mul"?

Here is what GCC give me:
Seems to me the compiler does a better job optimising the original code!

wow, i did not know that, and all that time i spent optimizing might be making things slower, mabey i should trust gcc optimizers on simple things, thx