Writing a pixel value in C++ Kernel

Question

I recently got interested in writing a simple kernel. I did some searching on the internet and came across OSDev Wiki. I set up the basic kernel (and after some frustration, the cross-compiler). Now I wanted to take it a step further: I want to start writing values to individual pixels. The only satisfactory and understandable answer I came across was the one on the Wiki, Drawing in Protected Mode. I want to use the functions provided, but still can't seem to understand what I need to pass as the arguments. Below is the code for the function I am using, I can't understand what I need to pass for the first argument. Is there some memory buffer (similar to the terminal_buffer used for text) I need?

/* only valid for 800x600x32bpp */
static void putpixel(unsigned char* screen, int x,int y, int color) {
    unsigned where = x*4 + y*3200;
    screen[where] = color & 255;              // BLUE
    screen[where + 1] = (color >> 8) & 255;   // GREEN
    screen[where + 2] = (color >> 16) & 255;  // RED
}

This is probably a stupid question since I'm very new to OS development.

Thanks in advance,

Javax

BTW: I am doing x86 code. I also saw this question and tried inlining it in C++. This code compiles, but if I call the function, the OS refuses to boot. It only gets to this stage:the stage it boots to before returning to the GRUB menu screen. This may be beside the point, however, if I can find an alternative solution. This is the alternative option:

void setPixel () {
    asm ("mov %ah, 0x0C");
    asm ("mov %al, 0x13");
    asm ("int $0x10");

    asm ("mov %ah, 0x0C");
    asm ("mov %bh, 0");
    asm ("mov %dx, 5");
    asm ("mov %cx, 5");
    asm ("mov %al, 0x04");
    asm ("int $0x10");
}

Answer 1

I did not code in protected mode but if I remember correctly in protected mode the interrupts are handled differently and needed some bridge to access so the second interrupt example code will not work (but I might be wrong). Try to google how to access VGA/VESA/VBE BIOS functions from protected mode.

The first example is assuming you got VESA/VBE card present in the system and configured to video mode 800x600x32bpp in LFB mode starting at far pointer screen. I also never did such thing but when you set video mode of VGA/VESA it switch to page mode by default.

So if you just switch to 800x600x32bpp than you got page mode (natively). So the VRAM is mapped at 0xA000:0000 - 0xA000:FFFF in real mode. As you are in protected mode you need to translate/map that to 32 bit space somehow.

Also as you got 32bit mode you should use DWORD for colors and store the pixel with single operation (stosd for example or have DWORD *screen and do not use the 4* from address computation where = x + y*800; ).

so you got 2 options:

1. LFB linear frame buffer

   VESA/VBE gfx cards has a capability to use LFB (I think from version 1.2 or 2.0) that means you can map VRAM to specified memory space linearly. So in this case the screen is that address you mapped the VRAM to. On how to do it you should consult with VESA and VBE documentation. Without proper configuration your example will never work.

2. page mode

   In page mode you got only access to 64 KByte of VRAM. for video modes above 320x200x8bpp is this not enough and you need to chose which 64KByte segment of memory you want to work with. that is called paging. Look here #2 VGA GFX mode there is real mode VESA example too. The idea is to compute address and page from the coordinates. In your case (for BYTE pointer):

   BYTE far screen=(BYTE far*)0xA0000000;
   DWORD adr = 4*x + 4*800*y;
   DWORD page = adr>>16; adr &= 0xFFFF;
   VESApage(page);
   screen[adr]=r; adr++;
   screen[adr]=g; adr++;
   screen[adr]=b;
   

   or:

   DWORD far screen=(DWORD far*)0xA0000000;
   DWORD adr = x + 800*y;
   DWORD page = adr>>14; adr &= 0x3FFF;
   VESApage(page);
   screen[adr]=rgba;
   

   The VESApage() source is in the link above. So in this case the screen is fixed VRAM address but as I mentioned before in order to work in protected mode this could change quite a bit. You should also take a look at Graphics mode in assembly 8086

As the link you provided confirms my suspicions that you can not access BIOS functions from protected mode directly so I would go for LFB as it is way faster and does not require any further BIOS function access after the video mode configuration. So you have to set your video mode before switching to protected mode !!!.

Hope parameters color,x,y are clear to you. Also in case you do not know what BYTE and DWORD is than they are unsigned ints 8 and 32 bit wide.