[SOLVED] Stange behavior VMware VBE support

[nbdd0121]

For months I am puzzled by a problem: how could my VBE code works perfectly fine on Bochs, QEMU, Virtual Box and real machine proved not to work on VMware? It seems that in VMware, int 10h with ax = 4F01 will fail on modes given by 4F00.

Today, when I re-implement the VBE code in C and an assembly-made bios helper function, which indeed switch back to real mode, call the bios using interrupt, and switch back to protected mode, the VMware VBE started to work again.

Seems that in some way the VMware is not conforming to the VBE spec.

[nbdd0121]

After hours of debugging, I found the answer.

The VBE spec asks a VBE2 BIOS to store memory area that VideoModePtr points to in the reserved area in VbeInfoBlock, or, if 'VBE2' signature is present, store the information within the implementation. However, VMware did not store the video modes within the VbeInfoBlock, but, instead, always in a place around 0xCXXXX. This behavior, to developer (like me) who assumes the VideoModePtr points to somewhere within the 512B block, causes tricky bugs.

I have found other developers who had the same bug with me, so I just leave the post here for a notice.

[gerryg400]

After hours of debugging, I found the answer.

The VBE spec asks a VBE2 BIOS to store memory area that VideoModePtr points to in the reserved area in VbeInfoBlock, or, if 'VBE2' signature is present, store the information within the implementation. However, VMware did not store the video modes within the VbeInfoBlock, but, instead, always in a place around 0xCXXXX. This behavior, to developer (like me) who assumes the VideoModePtr points to somewhere within the 512B block, causes tricky bugs.

I have found other developers who had the same bug with me, so I just leave the post here for a notice.

I use VBE on VMWare but I've never seen this bug. Could you please give some more detail ?

[CrafterMan24]

After hours of debugging, I found the answer.

The VBE spec asks a VBE2 BIOS to store memory area that VideoModePtr points to in the reserved area in VbeInfoBlock, or, if 'VBE2' signature is present, store the information within the implementation. However, VMware did not store the video modes within the VbeInfoBlock, but, instead, always in a place around 0xCXXXX. This behavior, to developer (like me) who assumes the VideoModePtr points to somewhere within the 512B block, causes tricky bugs.

I have found other developers who had the same bug with me, so I just leave the post here for a notice.

Hello, I'm having same problem with you.
My tries with V8086 Monitor and INT32 (Dropping real mode back) is same...

I can get everything in VirtualBox, QEMU, Real hardware, etc... (Video Mode list pointer was 0x202200) but

When i try with VMWare i can't get Video mode list, it is empty, also setting with an old standardized video mode is not working, too... (Video mode list pointer was 0xC00063BE like you said)

Do you know a fix?

[Combuster]

C000:63BE points to the Video ROM, and considering the list of video modes is essentially a constant, there's nothing wrong so far.

So even though it might look unusual, have you actually tried to see what's at 0x000C63BE (the physical address that corresponds to that pointer)?