OSDev.org

Hi everyone
I've searched quite a bit, but I'm not sure what's causing this.

I'm working on VESA graphics for an OS class, on top of a simple kernel we put together. In the bootstrap, I set the controller to mode 0x411b, which it reports as 1280x1024x32. Later on, in protected mode, I initialize the framebuffer to my VC_BG value, the background color for the screen. I do double buffering, so I have:
(more stuff goes on, and the _memcpy is in a different function, but this looks to be the important bit)

This works fine when I set VC_BG to, say, 0xFFFFFFFF. However, if I set VC_BG to 0xFFFFFFFE, for instance, only a couple rows of pixels at the top of the screen get filled in. This is reproduceable and seems to happen when the last bit of the color is 0.

Am I missing something really fundamental to the way VESA is supposed to work?

Thanks in advance

Do screen and fb overlap? Does screen overlap with something else? Is screen completely contained within valid RAM?

Is screen / framebuffer made of integers or it is another data structure?

Combuster wrote:Do screen and fb overlap? Does screen overlap with something else? Is screen completely contained within valid RAM?

I don't think they overlap, but I'll have to check. I use a simple malloc function to allocate space for screen.

bontanu wrote:Is screen / framebuffer made of integers or it is another data structure?

*fb points to the memory location returned by the int10/0x4f01 call. Since the video mode is reported as 32-bit, I thought an int* would be ok. As I said above, screen is just a pointer to a chunk of memory allocated of x_res*y_res ints.

Have you checked the success of VESA FB setup?

Have you checked the reported video_pitch value for this video mode on your video card? Sometimes the video_row_size is not equal to video_dx*pixel_size, instead it is equal to this "video_pitch".

Is the number_of_rows = 65536 / (1280 * 4) or close enough?

bontanu wrote:Have you checked the success of VESA FB setup?

Have you checked the reported video_pitch value for this video mode on your video card? Sometimes the video_row_size is not equal to video_dx*pixel_size, instead it is equal to this "video_pitch".

Is the number_of_rows = 65536 / (1280 * 4) or close enough?

Regarding the success of the FB setup, I have not tested that, yet it seems to me that if the VESA mode changes it *should* be a success. I can try checking it.

The video_pitch is 5120, aka 1280*4.

I'm not sure about the "number of rows"; I don't see that in any definition for the mode info structure.

I'm seeing 0x6 reported as my "mem_model"; going to try and figure out what that corresponds to. What should the "direct color mode info" item be?

Thanks

So, if I try to write, say, 0xEEEEEEEE directly to the framebuffer, there is no problem. Something is going on either in the copying to the double-buffer or in the flushing of the double-buffer to the framebuffer.

Hi,

slawmaster wrote:So, if I try to write, say, 0xEEEEEEEE directly to the framebuffer, there is no problem. Something is going on either in the copying to the double-buffer or in the flushing of the double-buffer to the framebuffer.

While you've probably made at least half of the mistakes described in
"VBE: Common Mistakes"; I'm tempted to think the bug is in your memory management code - for e.g. allocating a buffer that is only partially RAM, allocating the same RAM for different things, messing up the paging structures, or forgetting about A20.


Cheers,

Brendan

Brendan wrote:Hi,

slawmaster wrote:So, if I try to write, say, 0xEEEEEEEE directly to the framebuffer, there is no problem. Something is going on either in the copying to the double-buffer or in the flushing of the double-buffer to the framebuffer.

While you've probably made at least half of the mistakes described in
"VBE: Common Mistakes"; I'm tempted to think the bug is in your memory management code - for e.g. allocating a buffer that is only partially RAM, allocating the same RAM for different things, messing up the paging structures, or forgetting about A20.


Cheers,

Brendan

I am working on a specific set of hardware, so I'm not aiming for global compatibility--I'd rather hard-code a single mode than fiddle around in the real-mode bootstrap reading every mode and then prompting. The card reports that the mode I chose is 1280x1024x32 and that the bytes per line is the same as 1280*4. I thought about the memory management problem, but why would it work when the blue component is xxxxxxx1 but not xxxxxxx0? I have tested by changing *only* the color value, and everything works fine with LSB = 1, but breaks with LSB = 0.


John

try to use
unsigned long int *scr.
unsigned long int *framebuffer;
instead.