A frustrating VESA problem

[slawmaster]

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:

Code: Select all

int* fb; // this points to the real linear fb
int* screen; // my double buffer, allocated with size x_res * y_res * 4

for (i = 0; i < x_res*y_res; i++) {
  screen[i] = VC_BG;
}
_memcpy(fb, screen, x_res*y_res*4);

(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

[Combuster]

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

[bontanu]

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

[slawmaster]

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.

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.

[bontanu]

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?

[slawmaster]

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

[slawmaster]

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.

[Brendan]

Hi,

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

[slawmaster]

Hi,

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

[digo_rp]

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