Bochs/VMWare VBE Modes

[Geometrian]

Hi,

I am trying to get VBE modes to work properly with Bochs and VMware. The host is Windows. Bochs 2.6.2 and VMware Player 5.0.2 are installed (to date, the latest).

Bochs:
The internet suggests altering the Bochs configuration file. I tried this; the file looks like:

Code: Select all

ata0-master: type=disk, path="C:/dev/C++/MOSS/0.6/build/moss-disk.bin", cylinders=100, heads=16, spt=63
boot: disk, cdrom

mouse: enabled=0, toggle=ctrl+f10

romimage: file=$BXSHARE/BIOS-bochs-latest

vga: extension=vbe
vgaromimage: file=$BXSHARE/VGABIOS-lgpl-latest

Bochs happily loads this and runs without any messages concerning the VGA/VBE. When my kernel switches to a VBE mode, Bochs resizes to the correct resolution, but nothing I draw shows up. Bochs's log looks like:

Code: Select all

00018703133i[BIOS ] Booting from 0000:7c00
00019283246i[BIOS ] int13_harddisk: function 41, unmapped device for ELDL=81
00019286931i[BIOS ] int13_harddisk: function 08, unmapped device for ELDL=81
00019290593i[BIOS ] *** int 15h function AX=00c0, BX=0000 not yet supported!
00021587431i[MEM0 ] allocate_block: block=0x1 used 0x3 of 0x20
00022161404i[MEM0 ] allocate_block: block=0x2 used 0x4 of 0x20
00022198814i[KBD  ] keyboard: scan convert turned off
00044205193i[KBD  ] identify keyboard command received
00044218813i[KBD  ] reset-enable command received
00044220221i[KBD  ] Switched to scancode set 1
00066679202i[KBD  ] wheel mouse mode request rejected
00089127883i[KBD  ] keyboard: scan convert turned off
00089364333i[BXVGA] VBE set bpp (32)
00089364352i[BXVGA] VBE set xres (1024)
00089364394i[BXVGA] VBE set yres (768)
00089364431i[BXVGA] VBE enabling x 1024, y 768, bpp 32, 3145728 bytes visible
00089364431i[WGUI ] dimension update x=1024 y=768 fontheight=0 fontwidth=0 bpp=32
00089366491i[MEM0 ] allocate_block: block=0x5 used 0x5 of 0x20
00089368114i[MEM0 ] allocate_block: block=0x8 used 0x6 of 0x20
00089538777i[MEM0 ] allocate_block: block=0x4 used 0x7 of 0x20
00127578603i[MEM0 ] allocate_block: block=0x3 used 0x8 of 0x20

WMware Player:
Similar to Bochs, starts up, resizes correctly, and nothing appears.

The same kernel works perfectly on VirtualBox and on real hardware.

Thanks,

[Kazinsal]

Are you making assumptions about the location of the LFB or are you getting it from VBE modeinfo calls?

[Geometrian]

Are you making assumptions about the location of the LFB . . .

Nope. My VESA controller lists the graphics modes, chooses one, and then uses the base pointer that that struct defines for all rendering.

[Combuster]

Did you set the LFB bit during modesetting? Some real hardware needs it, some real hardware doesn't. Haven't made sure for Bochs though...

[Geometrian]

Did you set the LFB bit during modesetting?

Not sure what you mean by this. When choosing an acceptable mode, I added:

Code: Select all

//Only use linear frame buffer modes
if (!(mode->info.ModeAttributes&0x90)) continue;

It didn't seem to help.

[Kazinsal]

OR the mode number with 0x4000.

[Geometrian]

OR the mode number with 0x4000.

That fixed it (both on Bochs and on VMware)! I'm . . . not sure exactly how (e.g. a doc), but I'm assuming it forces LBA to be used?

On Bochs, it's cripplingly slow (I'm not optimizing drawing, but still). I'm assuming that's to be expected?

Thanks,

[Kazinsal]

OR 0x4000 sets the "Use LFB" bit in the mode number. VirtualBox lets you access video memory via the LFB without it, which is against the VBE standard.

It's to be expected that your code is slow in Bochs, especially if it's unoptimized. Frankly, Bochs is just slow.

[Geometrian]

OR 0x4000 sets the "Use LFB" bit in the mode number.

Mmmppfh. I wish I had run into that somewhere. I updated a wiki page for people of the future.

VirtualBox lets you access video memory via the LFB without it, which is against the VBE standard.

Shame. Apparently the hardware wasn't fully compliant either.

It's to be expected that your code is slow in Bochs, especially if it's unoptimized. Frankly, Bochs is just slow.

Meh--my drawing code is pretty slow even in VirtualBox/real hardware. Not only are the algorithms it uses not optimized, the algorithms themselves are suboptimal. Per-pixel blending is also pretty costly, no matter how it's rolled.