OSDev.org

Well, Bochs Graphics Adapter uses the BGRA pixel format in true color modes. So simply swap blue and red channel in the original putpixel.

http://wiki.osdev.org/BGA

WeirdEdEdison wrote:Well, Bochs Graphics Adapter uses the BGRA pixel format in true color modes. So simply swap blue and red channel in the original putpixel.

http://wiki.osdev.org/BGA

Wrong. Bochs Graphics Adapter uses RGBA in 32-bit modes. I didn't look through the code, but something is wrong with it because it uses RGBA.

omarrx024 wrote:Wrong. Bochs Graphics Adapter uses RGBA in 32-bit modes. I didn't look through the code, but something is wrong with it because it uses RGBA.

Well, that's what the OSDev Wiki says:

In 24 BPP each pixel is 3 bytes. There is one byte for each component. The colour components is blue first, then green, then red.


In 32 BPP each pixel is 4 bytes and easiest accessed as longwords (32 bits). The fourth byte is ignored. The colour components is layout like in 24 BPP. Accessing pixels as longwords the colour should be defined as 0x00RRGGBB.

WeirdEdEdison wrote:In 32 BPP each pixel is 4 bytes and easiest accessed as longwords (32 bits). The fourth byte is ignored. The colour components is layout like in 24 BPP. Accessing pixels as longwords the colour should be defined as 0x00RRGGBB.

Well, you should keep in mind that x86 is a little-endian architecture. The value 0x00RRGGBB will be layed out in memory as BB, GG, RR, 00. That doesn't mean Bochs uses BGRA; it uses RGBA.

Remember also that there are many more variations in real PC hardware out there than there are emulators, so being able to detect and work with many different hardware configurations rather than trying to distinguishing between three emulators specifically might be a more appropriate approach.

omarrx024 wrote:

WeirdEdEdison wrote:In 32 BPP each pixel is 4 bytes and easiest accessed as longwords (32 bits). The fourth byte is ignored. The colour components is layout like in 24 BPP. Accessing pixels as longwords the colour should be defined as 0x00RRGGBB.

Well, you should keep in mind that x86 is a little-endian architecture. The value 0x00RRGGBB will be layed out in memory as BB, GG, RR, 00. That doesn't mean Bochs uses BGRA; it uses RGBA.

What? That's the definition of BGRA. Blue channel first, then green, then red, then alpha (which is ignored by BGA, so it's actually BGRX). RGBA pixel format would have the red channel first, then green, then blue, then alpha.

That said, I second onlyonemac's thought. You should design your code to able to deal with a variety of pixel formats (and other hardware specifics) in the long run. You could still implement fast paths for specific formats anyway.

You can take advantage of VESA since it has services to return the frame buffer address and other data for each video mode, so you could query each video mode.

You could then emulate the BIOS and thus use VESA either by using V86, writing an emulator or using an x86 emulator engine like x86emu or the one from Bochs.

See it to see how to get VESA information:
http://forum.osdev.org/viewtopic.php?f=2&t=30186

x86emu source code (for 64-bit mode or if you want to use software emulation for the BIOS -in a separate process- instead of V86):
http://devel.archefire.org/en/tmp/x86emu.zip