VBE Modes causes weird behaviour in Bochs

[wichtounet]

Hi,

I've a strange problem. I've added basic support for VESA/VBE. In the 16bits part of my kernel I'm iterating through VBE modes to find the most adapted to me, like that:

Code: Select all

        for(uint16_t mode = 0; mode != 0xFFFF; ++mode){
            asm volatile ("int 0x10"
                : "=a"(return_code)
                : "a"(0x4F01), "c"(mode), "D"(&vesa::mode_info_block)
                : "memory");

            //Make sure the mode is supported by get mode info function
            if(return_code != 0x4F){
                continue;
            }

            //Check that the mode support Linear Frame Buffer
            if(!bit_set(vesa::mode_info_block.mode_attributes, 7)){
                continue;
            }

            //Make sure it is a packed pixel or direct color model
            if(vesa::mode_info_block.memory_model != 4 && vesa::mode_info_block.memory_model != 6){
                continue;
            }

            if(vesa::mode_info_block.bpp != DEFAULT_BPP){
                continue;
            }

            one = true;

            auto x_res = vesa::mode_info_block.width;
            auto y_res = vesa::mode_info_block.height;

            auto size_diff = abs_diff(x_res, DEFAULT_WIDTH) + abs_diff(y_res, DEFAULT_HEIGHT);

            if(size_diff < best_size_diff){
                best_mode = mode;
                best_size_diff = size_diff;
            }
        }

(I know that testing all the modes is not a good solution, but for now I haven't been able to use the far ptr to the modes memory in C++)

It works well under Qemu, but under Bochs it seems that it screws interrupt somehow. The keyboard interrupt are not caught or perhaps not even thrown, which means I got errors regarding internal buffer full. But the PIT interrupts are caught correctly, it seems that it is only the keyboard interrupts.

Only the listing screws Bochs, it is not necessary to enable it to see this behavior.

May that be a bug in Bochs ? Is there something wrong with my code ?

Thanks

[Nable]

> auto
> int 0x10
Do you want to say that you have compiler that supports both recent C++ standard and 16-bit code generation?

[Owen]

> auto
> int 0x10
Do you want to say that you have compiler that supports both recent C++ standard and 16-bit code generation?

I assume the ".code16gcc" hack

[Nable]

I assume the ".code16gcc" hack

Thanks a lot, I should have been more attentive while studying wiki.

[wichtounet]

> auto
> int 0x10
Do you want to say that you have compiler that supports both recent C++ standard and 16-bit code generation?

I assume the ".code16gcc" hack

That is right, I'm using the .code16gcc hack. As it works perfectly in Qemu, I don't think that it is a compilation problem.

[Combuster]

Code: Select all

for(uint16_t mode = 0; mode != 0xFFFF; ++mode)

I'd suggest you at least stop touching reserved bits before making any further bets.

[wichtounet]

Code: Select all

for(uint16_t mode = 0; mode != 0xFFFF; ++mode)

I'd suggest you at least stop touching reserved bits before making any further bets.

Excellent idea, thanks.

I tried going from 0x4100 to 0x41FF, but it didn't change the problem in Bochs. Although it makes the boot much faster.

[Nable]

Excellent idea, thanks.

I tried going from 0x4100 to 0x41FF, but it didn't change the problem in Bochs. Although it makes the boot much faster.

I think that Combuster wrote about wider meaning of word "bits", i.e. pieces (parts of some set) and not binary digits.
I'm somehow afraid of doing so-called spoon-feeding (i.e. giving information that can easily be found and beginners should try to find this basic things themselves) but here's a more exact answer:

http://wiki.osdev.org/VBE#VESA_Defined_Mode_Numbers -> http://wiki.osdev.org/VBE#How_to_pick_t ... I_wish_.3F

VESA stopped assigning codes for video modes long ago -- instead they standardized a much better solution: you can query the video card for what modes it supports, and query it about the attributes of each mode.

VESA gives you the way to determine exact set of supported modes (0x4F00, if I understood correctly) -> one shouldn't try modes that are not in this set, because result is undefined.

[wichtounet]

I tried again to use the videomodes ptr and this time I suceeded, unfortunately, it didn't fix the problem.

This time, Bochs is starting in 1024x768 mode, but I still have keyboard problems.

By the way, is there a way to use bigger modes in Bochs ?

[Nable]

By the way, is there a way to use bigger modes in Bochs ?

Common, there's so much to find on the wiki, just try doing it: http://wiki.osdev.org/BGA#Setting_displ ... _bit_depth (NOTE: you may need to update Bochs to get higher resolution. Btw, it seems to be a good practice to use Bochs version from SVN trunk, because new commits mostly bring fixes and new features; bugs are rarely introduced).

[wichtounet]

By the way, is there a way to use bigger modes in Bochs ?

Common, there's so much to find on the wiki, just try doing it: http://wiki.osdev.org/BGA#Setting_displ ... _bit_depth (NOTE: you may need to update Bochs to get higher resolution. Btw, it seems to be a good practice to use Bochs version from SVN trunk, because new commits mostly bring fixes and new features; bugs are rarely introduced).

Thank you, but I already found this page... It explains how to program the BGA using Bochs extension instead of VBE. I want to use only VBE. When I use VBE, the maximum resolution that is proposed in the list of the modes is 1024x768.