VESA Help

[cheapskate01]

Hi, I am trying to write a vesa vga driver for my OS and I've hit a little snag: I don't even know where to start. COuld somebody who has done this before walk me through this? I'm not looking to simply take somebody else's code; I want to use this as a learning experience. Is there anybody that can help me? I have already seen every page on vga in this site and can't wrap my head around it.

EDIT:
If you think my priorites are wrong, it's probablybecause they are. While I do need helpwith this, I also need help with interupts. I've been almost completely unable to understand the page on this. Can anyone help on either of those?

[Octocontrabass]

Getting stuff to show up on the screen is a good place to start. You'll need to locate the video memory, map it somewhere in your address space, and write to it.

Before you can put stuff on the screen, you have to set an appropriate video mode. Doing this without help from the firmware can be pretty difficult, so you should leave this to your bootloader for now.

So, what bootloader are you using?

While I do need helpwith this, I also need help with interupts.

You don't need interrupts to put pixels on the screen, so you can stick with graphics for now if that's what you want to do.

[SpyderTL]

The VESA page was rather hard to find in the wiki, so I renamed it. You can now simply search for "VESA", and it will bring you to a page that describes how to find a specific VESA video mode and how to enable that mode.

Keep in mind that this only works from 16-bit code, so you'll probably want to do this in your boot loader, and then switch to 32-bit before you start drawing anything to screen.

If you still have any questions after reading this page, let us know.

[cheapskate01]

So, what bootloader are you using?

While I do need helpwith this, I also need help with interupts.

You don't need interrupts to put pixels on the screen, so you can stick with graphics for now if that's what you want to do.

I'm using GRUB2, but in the distant future I want to make my own bootloader for the OS. Also, I just need interrupts in my sstem. Not for graphics, for input.

[cheapskate01]

The VESA page was rather hard to find in the wiki, so I renamed it. You can now simply search for "VESA", and it will bring you to a page that describes how to find a specific VESA video mode and how to enable that mode.

Keep in mind that this only works from 16-bit code, so you'll probably want to do this in your boot loader, and then switch to 32-bit before you start drawing anything to screen.

If you still have any questions after reading this page, let us know.

I am confused as per the contents of the page. The code doesn't work for me; I'm using meaty skeleton as a base. I have seen the page before. I need somebody to walk me through it, step by step, and explain it to me. I know it is a lot to ask but I hope someone is nice enough to take time to help me out. Thanks for the link, It shed a little light on the subject.

[Octocontrabass]

I'm using GRUB2

Unfortunately, I'm not very familiar with using GRUB. However, I know you can specify the graphics mode you want in the multiboot header, and GRUB2 will give you all the information you need to access the frame buffer.

I am confused as per the contents of the page.

That code is written assuming you're still running in real mode, with the BIOS. You aren't in real mode, so it doesn't apply to you.

When you're writing your bootloader, you'll want to look at that page to see how to set the video mode before you switch the CPU to protected mode or long mode and start your kernel.

If you want to set the video mode outside of the bootloader, things get a lot more complicated. You either need to drop back into real mode (which requires loads of ugly hacks) or run the video card's ROM inside some sort of emulator.

[SpyderTL]

When I get some time, I'll add some simplified text to the wiki article, but basically, the first step is to ask the BIOS what version of VESA is installed, if any.

Next, you ask the BIOS for a list of available video modes supported by the video card. Then you have to ask the BIOS for details about each of those video modes (Resolution, Bits Per Pixel, etc.)

Now you can pick which video mode you want to use from this list. Then you call a BIOS method to switch to that video mode, by its video mode number. You can also request to be given access to the entire screen in a single "linear" buffer. This is highly recommended, because by default, you only have access to part of the screen, and you have to move the access window to different areas of the screen before you can read/write from/to those areas. I also recommend using a 32-bit color mode, because it will give you the best visual quality and make the math to change pixel colors extremely simple.

When you make this call to change the video mode, you will get back the starting address that you can use to directly change pixel colors. Simply write all ones (0xFFFFFFFF) starting at this address to start setting pixels to all white.

If you decide to keep using GRUB2, then you can just let GRUB do all of the work, and it will set the video mode for you and give you the address to the video screen pixel buffer.

[cheapskate01]

Okay, thanks for thetip. I've found this forum post. I got the code in my multiboot header, but it still shows my stuff in text mode as if nothing changed.

I'm working from the meaty skeleton code (plus like 7 extra functions). Can you walk me through how to plot a pixel? I don't work too well with wiki pages; I'm certainly a visual learner, but I can follow instructions. Do you think you can walk me through the steps and give me some example code to learn from? I'm confused as per implementation. Thank you.

[azblue]

Can you walk me through how to plot a pixel?

Plotting pixels:
Write color to address: linearFrameBuffer + x*BytesPerPixel+y*BytesPerLine

Note that you want your pointer to be volatile.

One thing I like to recommend is mode 13h.

From Real Mode:

Code: Select all

mov ax, 13h
int 10h

I'm not familiar with GRUB but I'm sure it's simple enough

It's 320x200x8; SpyderTL recommended 32-bit color modes, and indeed 32bit is easy. However, this mode has the advantage that "Bytes Per Line" is what you'd expect(200) and you know ahead time where the video buffer is (0xA000); you can skip the step where you get info from the BIOS.

So you would plot pixels to: linearFrameBuffer + x*BytesPerPixel+y*BytesPerLine
Which is: 0xA000 + x*1+y*200

Note that eventually you want to do it the proper way, (SpiderTL's way) where you get info about the video mode and such. This simpler way is just to get you started if you're having trouble with all the correct steps; as soon as you get this to work, ditch what I've said and go do the more complete method Spider showed you.

[cheapskate01]

From Real Mode:

Code: Select all

mov ax, 13h
int 10h

Do you think you can walk me through it in a chat program or something?I'd love to know more, but I need assistance. You think you're up for that?

[FallenAvatar]

From Real Mode:

Code: Select all

mov ax, 13h
int 10h

Do you think you can walk me through it in a chat program or something?I'd love to know more, but I need assistance. You think you're up for that?

If that is not enough info for you, maybe you need to brush up on your Google skills, and/or pick a new hobby that you are "more ready" for.

- Monk

[cheapskate01]

From Real Mode:

Code: Select all

mov ax, 13h
int 10h

Do you think you can walk me through it in a chat program or something?I'd love to know more, but I need assistance. You think you're up for that?

If that is not enough info for you, maybe you need to brush up on your Google skills, and/or pick a new hobby that you are "more ready" for.

- Monk

Lol
Not what I meant; I want to know all about this code; what it does, why it works; how to invoke; How to plot pixels where to put these lines in my code; etc.

[intx13]

From Real Mode:

Code: Select all

mov ax, 13h
int 10h

Do you think you can walk me through it in a chat program or something?I'd love to know more, but I need assistance. You think you're up for that?

The "int" instruction, as documented here (from this good reference on the x86 instruction set) asks the CPU to trigger an interrupt. If the CPU is in real mode it will look in the IVT for the address of code intended to handle that interrupt. (In protected mode and long mode it will look in the IDT.)

Before your bootloader/OS is launched, the BIOS will have installed some code to memory and created a real-mode IVT containing code for different interrupts. This provides a simple API that a real mode bootloader/OS can use to do things like print text or plot pixels. You can read about many of the different functions that different BIOSs provide on this site. BIOS-provided interrupts are intended to be handy functions that you can use until your OS loads its own drivers, but they only work in real mode.

Many BIOS provided functions (accessed via interrupts) use the AH register to determine what specifically to do, and use AL to hold related information. You can use that previous link to look at individual interrupts. In this case, you can see that INT10H, AH=00H, AL=13H changes the video mode to 320x200.

Does that explain azblue's code sufficiently?

[cheapskate01]

From Real Mode:

Code: Select all

mov ax, 13h
int 10h

Do you think you can walk me through it in a chat program or something?I'd love to know more, but I need assistance. You think you're up for that?

The "int" instruction, as documented here (from this good reference on the x86 instruction set) asks the CPU to trigger an interrupt. If the CPU is in real mode it will look in the IVT for the address of code intended to handle that interrupt. (In protected mode and long mode it will look in the IDT.)

Before your bootloader/OS is launched, the BIOS will have installed some code to memory and created a real-mode IVT containing code for different interrupts. This provides a simple API that a real mode bootloader/OS can use to do things like print text or plot pixels. You can read about many of the different functions that different BIOSs provide on this site. BIOS-provided interrupts are intended to be handy functions that you can use until your OS loads its own drivers, but they only work in real mode.

Many BIOS provided functions (accessed via interrupts) use the AH register to determine what specifically to do, and use AL to hold related information. You can use that previous link to look at individual interrupts. In this case, you can see that INT10H, AH=00H, AL=13H changes the video mode to 320x200.

Does that explain azblue's code sufficiently?

Yes it does thank you.

[cheapskate01]

So, rather than make 1000 forum threads for questions, can I just turn this one into a place to ask all my questions that probably dont deserve their own topic? Is that within the forum rules?