Blank screen under vmware workstation 17.5.2 (WfW 3.11)

[namtik98]

Using vbesvga.drv (Wfw 3.11) results in blank screen under VMWare workstation 17.5.2. WfW seems to be running as ALT-F4 and Enter allows exiting windows.

[robinhood2014]

I'm having the same problem, except I'm using 86Box.

[PluMGMK]

I must add an option to force-disable double-buffering, to see if that helps in these cases…

[PluMGMK]

Can you try with the latest release (v0.2.2) using DoubleBufRefreshRate=0 in SYSTEM.INI? That should indicate whether or not it's a problem with double buffering…

[robinhood2014]

No change -- still a black screen. As namtik98 observed, I can get out of Windows with Alt-F4 then Enter.

[namtik98]

Same here, attached are also system.ini and output of vidmodes.com
SYSTEM.zip

[namtik98]

I tested version 0.2.2 with Bochs 2.8 and it works - however there are some graphical glitches (e.g. the background image has few short horizontal white bars). Version 0.2.2 does not work with Vmware workstation 17.5.2 or Dosbox (shows only black screen instead of Windows desktop).

[PluMGMK]

I managed to get VMware Workstation up and running, and debug the driver within – it seems there are two layers to the problem:

1. VMware's VBE implementation is version 2.0 compliant. However, it sets byte 1Eh to 1 in the mode info structures, which vbesvga.drv mistakenly takes to mean that fields 32h-3Eh are filled in, when in fact they are not (because the VBE version is less than 3.0). Because of this mistaken assumption, it ignores linear modes and falls back to bank-switching modes. This is easy to fix, and should make the problem "go away" in most cases.
2. This is trickier: when the driver is in bank-switching mode in VMware, "something" is causing the swcursor_save_screen function to be entered in the wrong place, with wrong segment registers. This results in a crash, and hence a blank screen…

(Btw, it was hard enough to figure out how to attach to the serial console in VMware – with the help of this old article I found out that the way to do it is to use a named pipe as the serial port in VMware, then use socat to attach the pipe to a PTY, and then I use picocom to attach to the latter just like I do with QEMU.)

[PluMGMK]

Please try v0.2.3 and see if it solves the problem. Note that Double Buffering should work, so please remove DoubleBufRefreshRate=0 from SYSTEM.INI to get the best performance!

[PluMGMK]

OK, another update:

1. The crash in the cursor function was caused by the VMware firmware's bank-switching routine not preserving the ES register, which is easy to work around.
2. But even then if I force it (using the debugger) to use a bank-switching mode, I get stuck with a blank screen – this is because the firmware doesn't update the miscellaneous graphics control register to indicate that memory at segment A000h (rather than B800h) is mapped, which means VDDVBE doesn't map those pages properly. This is also a solvable problem, but probably an edge-case of an edge-case since in reality VBESVGA.DRV should never need to use a bank-switching mode when Windows is in 386 Enhanced Mode anyway…

[robinhood2014]

Progress made. It works to some degree, but everything is painfully slow to draw onto the screen.

[robinhood2014]

Got something! Re-introducing DoubleBufRefreshRate=0 was a good workaround.

[PluMGMK]

Got something! Re-introducing DoubleBufRefreshRate=0 was a good workaround.

You're saying the performance is better with double-buffering disabled? I guess the swap-buffers routine uses a lot of CPU cycles, so maybe it's too much for the emulated CPU of 86box… (I had been meaning to look into ways of reducing the CPU usage, so this gives me a reason to keep that on the TODO list!)

[namtik98]

I can confirm version 0.2.3 works with VMware 17.5.2!! Couple of oddities still:

• DoubleBufRefreshRate=0 works, but some screen draw operations result in garbled graphics or are painfully slow. See attached Wintach -testing program which can be used to test graphics speed and functions
• DoubleBufRefreshRate>4 results in memory errors in WfW 3.11 under Vmware. For example: icons are corrupted or black, or PROGMAN caused a General Protection Fault in module user.exe at 000C:0B47
  wt.zip

[PluMGMK]

How much memory is allocated to your VM? If Double Buffering is enabled, it has to allocate twice the size of the framebuffer, which is 8 MiB 6 MiB (sorry, I forgot that 768 scanlines is only ¾ of a meg!) for the default 1024×768×32 mode…

EDIT: And thanks for the testsuite, it'll probably be more useful than what I have been doing, which is basically trying random programs and seeing how well they work!

[robinhood2014]

I have 128MB of RAM. Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: PluMGMK ***@***.***> Sent: Saturday, January 11, 2025 8:20:51 AM To: PluMGMK/vbesvga.drv ***@***.***> Cc: Brandon Taylor ***@***.***>; Comment ***@***.***> Subject: Re: [PluMGMK/vbesvga.drv] Blank screen under vmware workstation 17.5.2 (WfW 3.11) (Issue #23) How much memory is allocated to your VM? If Double Buffering is enabled, it has to allocate twice the size of the framebuffer, which is 8 MiB for the default 1024×768×32 mode… — Reply to this email directly, view it on GitHub<#23 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABVGAST3WLKGKA2NIAQKESD2KESEHAVCNFSM6AAAAABUZKOJZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBVGI4DIMZWGU>. You are receiving this because you commented.Message ID: ***@***.***>

[namtik98]

I have 16Mb for VM - I tried with 32Mb and it does not make any difference. Changing memory manager from QEMM386 to HIMEM + EMM386 changes the second issue (progman faults with double buffering on) and windows just hangs.

[PluMGMK]

The latest release, v0.2.4, may fix the hanging because I removed the int 3 instructions.

Other than that I'm not sure what could be wrong, because on my end Program Manager seems to work fine under WfW3.11 on VMware, with or without Double Buffering enabled… 😕

[namtik98]

actually the second issue (progman faults) was result of too large bitmap background. Once I removed background image from desktop it now works with both, double buffering enabled, and disabled!

@PluMGMK : can you share your wintach results, paint seems to revert to some really slow screen write methods, see below my results (under vmware workstation 17.5.2), guest using 102476816
Word processing : 394
CAD / Draw: 2201
Spreadsheet : 321
Paint : 14

[robinhood2014]

I am FURIOUS with this stupid thing. It's back to a darn black screen again!

[PluMGMK]

actually the second issue (progman faults) was result of too large bitmap background. Once I removed background image from desktop it now works with both, double buffering enabled, and disabled!

I guess this is another bug that I should work on… What size bitmap, and how many colours?

@PluMGMK : can you share your wintach results, paint seems to revert to some really slow screen write methods, see below my results (under vmware workstation 17.5.2), guest using 1024_768_16 Word processing : 394 CAD / Draw: 2201 Spreadsheet : 321 Paint : 14

Here:

WinTach v1.0: Performance Report

System Information:

System Processor         : 486
Display Driver           : VGA
Display Type             : Frame Buffer
Display Resolution       : 1920 x 1080
Display Colors           : 16.7 Million
Test Resolution          : D32 (1280x1024)
Cursor Stability         : Not tested

Benchmark results:

RPM - Word Processing    : 314.36 / D32
RPM - CAD / Draw         : 2449.40 / D32
RPM - Spreadsheet        : 388.09 / D32
RPM - Paint              : 13.31 / D32

RPM - Overall            : 791.29 / D32

I saw the same thing with Paint, it seems to slow to a crawl when drawing thick lines with a pattern. I'm not sure which GDI routines are being used for that, but obviously the way I'm servicing those GDI calls leaves a lot to be desired… And yes, it puts garbage all over the screen, because of the assumption inherited from the V7 driver that scanlines never cross a bank boundary (same underlying problem as #13). I fixed the logic in a lot of places that previously made that assumption, but obviously there are a lot more codepaths that still need fixing…