It works perfectly for me. Running under WinXP with a GF4 Ti4200 and VDMSound. The only difference is that I'm using VBEPLUS instead of NOLFB. Here. It's just 11KB.

Originally posted by Nicht Ser Gut:

Just to be sure I'm understanding you properly...You're saying that the video card has no relativity to this problem?

Absolutely. The many 'stuck mouse' problems that most WinNT4 and Win2k users have described on this forum were puzzling to me at first... My main PC runs WinXP (SP1) and another older PC is a WinNT4EE/Novell/Linux test server. I was able to recreate the 'mouse problems' with certain applications on the WinNT box and assumed that Win2K has the indentical NTVDM mouse driver problems, since my WinXP box has fewer 'problems' than most Win2K posters have described.

This all started last year when I was attempting to get all of my brother-in-law's twenty or so older DOS games working on his new Dell Pentium IV (WinXP) PC for both he and my little nephew. So with the help of VDMSound, NoLFB, etc, I got Silent Hunter working, wrote up the procedure and gave it to two Silent Hunter Subsim websites. Casual observation led to fixes, but not to really recognizing the basic underlying NTVDM problems which were affecting particular DOS/VESA applications. There are many. (puts on best preaching to the choir look) Over time my reading of messages on this and other forums indicate that many individuals believe that the VESA support of WinNT4/Win2K/WinXP (or lack thereof) causes or contributes to most of the reported mouse/screen problems found with many (but not all) DOS games which users attempt to execute on the two families of Microsoft NTVDMs.

Not so...

In the Microsoft NTVDM "families", there is the WinNT4/Win2K NTVDM family, and the WinXP/Win2003 NTVDM family. Sure, each successive NTVDM build on its previous version, but there is a clear division between the two as of WinXP. In relation to VOGONS, the main problems which draw questions are NTVDM sound support, SVGA/VESA video support, mouse support, EMS/XMS/DPMI memory configuration and speed/timer issues. NTVDM inadequecies which present themselves as technical problems are actually the result of marketing decisions which were made by Microsoft. (I know that this is obvious to many here.) Ubercoder Vlad (et al) has solved most of the DOS sound emulation requirements with both his execellent VDMSound and LaunchPad products. Microsoft made a weak DOS sound emulations effort, but face it - they could have done something on the order of VDMSound 2.1.0 and incorporated it into their WinXP NTVDM code base if they has wanted to do so... Since they are trying to get folks to live in their proprietary Win32/Win64/DirectX API world, support of the old DOS/DOS Extender code base is not in their best interest... Let's look at the other areas of Microsoft's NTVDM marketing/technical deficiency.

Next up is the 'support' for SVGA/VESA in the Windows NT family codebase. The 'support' that Microsoft put in the Windows NT family codebase was to configure the video device drivers to allow direct access to a few more hardware I/O ports in the 'full-screen' video mode vs 'windowed' mode so that the standard VGA graphics modes could be displayed with sufficient speed and so that the video adapter BIOS could handle the setup details for each requested VGA/VESA video modes. Windows XP added a gate/monitor on Int 10h, sub-functions 0x4FXX to switch from windowed to full-screen mode so as to allow the video card VBE 2.0/3.0 compliant BIOS to be 'seen' by the DOS VESA application, depending on how the vendor written video drivers were coded. The LaunchPad "VESA support" checkbox just puts both WinNT4/Win2K into full-screen mode via the PIF setting to accomplish roughly the same function. There is no explicit support for VESA in WinNT4, but the 1996 VESA/DOS Extender game Silent Hunter which uses VESA mode 101h works fine on a 1MB S3-864 SVGA under WinNT4. Why? Because WinNT gives most of the video hardware responsibility directly to the video adapter BIOS in fullscreen mode. In previous threads on this forum many (including myself) have used various video test utilities to see what VESA support may be had with various video adapters under WinNT4/Win2K/WinXP. I think that I put up VGATEST.EXE since it actually tries to execute and display each video mode, unlike some utilities which just read and enumerate the video BIOS capabilities. So on my Matrox G-450 PCI (16MB) video adapter it seems that only VESA modes 100h (640x400x256 color) and 101h (640x480x256) were working, every other mode drew a 'blank'. I just accepted the results as the "lack of VESA support" issue with my Matrox WinXP video drivers at the time, but as I went back and thought about it a bit more I suddenly realized that the Matrox video drivers were not really to blame and that all of the VESA video modes which worked under DOS v6.22 were actually working under WinXP, it was just that I couldn't see them...

Well, it doesn't do me much good if I can't see those VESA modes on my 21" Sony monitor, but it is reassuring to know that the Matrox G-450 BIOS was not the problem. OK, so I hook up a borrowed (large) Mitsu multi-frequency display monitor which supports horizontal frequency range of 15kHz-85kHz and I see the VESA video mode 103h (800x600x256 colors) flickering on the screen. Well that confirms it. The only problem with VESA support is... the dot clock. Even when the video driver gets mostly out of the way, the NT/2K/XP video driver continue to hook and perform validation of the VGA sequencer and miscellaneous output registers to prevent an application from issuing instructions which might 'hang' the NT/2K/XP OS. Now my surmise is that upon entrance to full-screen mode that WinXP sets the dot clock to 25.175 MHz, or it uses the video BIOS default of 25.175 MHz and furthermore prevents any changes to such via the VGA sequencer by hooking out any attempt to access same.

Typical Pixel clock frequencies:

1H res   V res   V refresh [Hz]  Pclk [mHz]      Video mode 
2******************************************
3  640    480         60          25.175     VGA graphics mode  #
4  720    400         70          28.322     VGA text mode      *
5  800    600         85          56.250    SVGA graphics mode  #
6 1024    768         85          94.500    SVGA graphics mode  #
7 1280   1024         85         157.500    SVGA graphics mode  #
8 1600   1200         85         229.500    SVGA graphics mode  #
9
10 # = Pclk1
11 * = Pclk2

Now for an easy way to see what is probably happening, take a look at this nice Video Timing Calculator. Choose any of the video modes in the drop-down list and scroll down the page until you see the 'Calculate' button and press it to get the horizontal and vertical frequencies which are output by the video adapter. Now go back up to the 'General Parameters' box and in the 'Pixel clock frequency' input field set it to 25.175 MHz, no matter what SVGA/VESA mode you select and what value is placed in that field. Now with all of the horizontal and vertical timing parameters changed for any requested video mode, hold the pixel clock frequency to 25.175 MHz and press the 'Calculate' button and get the frequency results. This is what I believe is happening when any of the VESA modes are requested under Microsoft's NTVDMs in WinXP/Win2K/WinNT4. Since most multi-sync monitors do not support at all a horizontal frequency less than 30 kHz and a vertical frequency less than 50 Hz, most VESA video modes beyond 640x480x256 colors will not display on the multi-sync monitors, hence the blank screen.

Why a Windows NT family video driver can not restore the pixel clock value if a DOS/VESA application would change said value I do not know. I am not a device driver writer, but like to figure things out... After all, the Windows display may be at 1600x1200x32bpp @ 85 Hz when a DOS VESA mode 101h application is execute in fullscreen mode. That means that we are now at 640x480x256 color @ 60 Hz. Why the video driver cannot restore the pixels and pixel clock no matter what a full-screen DOS appliction does I do not know at this time. That would require a WinXP DDK and some study. There may be a good reason, or it could be an easy marketing answer to lessen WinXP complexity and support requirements. I intend to satisfy my curiousity. I am reminded, however of users who report corruption of their Windows video display when returning from a DOS/VESA application who have Radeon 9700 and some other model video adapters. Seems as if VGASAVE (or the vendor's own video driver code) does not catch all the hardware register settings to allow a successful restoration of the Windows desktop video configuration.

Now as to the NTVDM mouse driver. Quite simply put, Microsoft did not implement an NTVDM mouse driver VDD/stub which provides the same functionality as their own v8.20 DOS version. It has nothing to do with VESA support in the Microsoft WinNT/Win2K/WinXP NTVDMs. If Microsoft had done this fairly trivial task properly then none of their WinNT4 or Win2K customers would be reporting the 'stuck' or 'slow' mouse problems which frequent many Internet forums. Marketing rears its ugly head again... I found that MouseCTL.com helped to mask the 'slow mouse' problem for Silent Hunter but I did not understand exactly why it was necessary to do so. I do now. I have noted that Peter's Mouse2KV.exe spawn process utility solved some, but not all of the 'stuck' and 'slow' mouse symptoms in certain applications. Some of the most obvious NTVDM mouse driver deficiencies can be demonstrated straight away in the Int 10h video text modes 0h, 1h, and 7h. Microsoft did recognize one of their NTVDM mouse driver errors which they corrected in the WinXP release NTVDM mouse driver. This correction is why many more games execute with proper mouse support in WinXP, whereas WinNT4 and Win2K fail with the 'stuck mouse' syndrome. Now I have read your replies to the folks who post on this forum when they describe their mouse problems with games such as Fantasy General, Ascendancy, or even Silent Hunter when executed under either WinNT4 or Win2K. You are familiar with those games and note that the mouse performs properly in those games for you when running Windows XP. While I can not write a fix for the NT/2K/XP mouse driver problems that quickly, I can best demonstrate the typical symptoms for the improper 'stuck mouse' NTVDM mouse behavior in the above listed games by causing the same problem in WinXP. I have included a trivial TSR/ISR by the name of STOP33H.COM which is attached to this message as a Zip file. Run one of the above mentioned games under WinXP as normal, but run the STOP33H.COM TSR before the main game executable is activated. Now you too can have the 'stuck mouse' symptom under WinXP. You have just enabled the WinNT4/Win2K mouse emulation mode in WinXP. Fun, huh?

I have decided to attempt to write a rollup true TSR/ISR fix for the mouse driver and some of the other non-mouse related NTVDM errors which can be corrected from within the WinNT4/Win2K/WinXP NTVDM environment in the next five months, time allowing. It's been quite a few years since I've done any serious 80x86 assembler, so it's time to knock off the rust.

Between the excellent DOSBOX emulation product and the WinNT4/Win2K/WinXP NTVDM environments reinforced by Vlad's VDMSound/LaunchPad products, an NTVDM fix TSR (and a little luck) perhaps most all but the VCPI based DOS or the DOS/Extender/VESA games will be playable on the current Windows NT/2K/XP family of operating systems.

That's all for now...

dvwjr

Wow, dvwjr, that was an excellent write-up. I'm impressed. Keep this up and... well, we'll see. 😉

IMPRESSIVE to say the least, but I disagree on one thing. If video bios has nothing to do with VESA support under NTVDM, how can you explain that GF3 cards can do higher than 640x480 and my GF4 Ti4200 cannot?

Originally posted by eL_PuSHeR:

If video bios has nothing to do with VESA support under NTVDM, how can you explain that GF3 cards can do higher than 640x480 and my GF4 Ti4200 cannot?

I think that you have misread the thrust of my post, as my point was that the video adapter BIOS has EVERYTHING to do with VESA support in the Microsoft WinNT/Win2K/WinXP NTVDMs. Without the video BIOS there would be NO support for VESA video modes in the NTVDMs of the Windows NT family of operating systems, since Microsoft has never written a "VESA" device driver for any of their operating systems.

The 'support' that Microsoft put in the Windows NT family codebase was to configure the video device drivers to allow direct access to a few more hardware I/O ports in the 'full-screen' video mode vs 'windowed' mode so that the standard VGA graphics modes could be displayed with sufficient speed and so that the video adapter BIOS could handle the setup details for each requested VGA/VESA video modes.

The problem with VESA support in the Windows NTVDM environment is that the retrictions put on the video BIOS routines in accessing the hardware registers on the video adapter itself. If your GF3 can do higher than 640x480x256 colors than a GF4 Ti4200 I would have to know the differences (if any) between in VESA video mode support in a pure DOS environment first. Once a baseline of VESA support for each video adapter is established, the differences in the Windows NTVDM environment for each video adapter can then be assessed. It may be that the video device driver writers for the GF3 allowed the GF3 video BIOS to access and modify the SVGA hardware registers which control the refresh rate, but the video device driver team did not allow the same level of hardware access in the GF4 Ti4200 video device drivers.

This is the question to be answered. Why do certain video device drivers seem to allow the video adapter BIOS to change the refresh rate in fullscreen NTVDMs? Most implementations seem to lock down a 60 Hz refresh rate, to the sorrow of Windows NT/2K/XP users.

dvwjr

So, do you think it could be a good a idea to try another driver release, maybe an older version? or it is just a bios issue?

Originally posted by dvwjr Over time my reading of messages on this and other forums indicate that many individuals believe that the VESA support of WinNT4/Win2K/WinXP (or lack thereof) causes or contributes to most of the reported mouse/screen problems found with many (but not all) DOS games which users attempt to execute on the two families of Microsoft NTVDMs.

Not so...

Well, at first blush, I think of my results with "Future Shock", where I was using different hardware with identical software (worked fine with XP on the "old" hardware, but it choked on my "real" PC). If anything the video capacity of that setup's monitor was far less than the one I have now...

In any case, I'll probably have to re-read your post a few times and ponder for a while. Been really busy with real-world events, so I'm not as tuned-in to the minutae of things nowadays...