Don't use VDMSound. Use DOSBox.

Thx for the reply - Y dosbox is ok but VDMS is far simpler and also the only way to run glidos applications - I was hoping there might be a simple solution. Thx again for the help.

Chances are it's because of the video card. You could try using nolfb but I wouldn't keep your hopes up.

I have a very similar setup, an Intel core 2 duo E6600 and nVidia GTX 7900 and I've got a very similar problem - Glidos 1.33 will actually work but dgVooDoo does not. If I try and run Tomb Raider 1 using VDMsound's .VLP shortcut it crashes to desktop.

Does anyone have a clue whats going on? I have heard that limiting NTVDM.EXE to one processor core sometimes works, but not in my case it seems.

For those of you having the "Black Screen of Death" when using the NTVDM on WinXP with Intel HT or Dual Core system - I have something for you to test.

Try the follow steps - exactly. Don't just NOT DO THEM but then say you did! 😳 Do the following without leaving your PC workstation, even for a moment...

1.) Turn your WinXP system OFF.

2.) Turn your WinXP system ON.

3.) Login under a User ID which has is an Account type of Administrator.

4.) NOW search the \Windows\system32\drivers sub-directory for any files which might give direct hardware access to the PC workstaiton hardware. Possible culprits are DIRECTIO.SYS, GIVEIO.SYS and OSAIO.SYS driver files. If you find any of these files, rename them from *.SYS to *.BAD and then repeat this procedure from step 1.) above.

5.) Open an MS-DOS prompt (ie COMMAND.COM) not a WinXP command prompt (CMD.EXE).

6.) Run the file attached to this message: SVGATEST.EXE with the following command-line option: "SVGATEST 4" (without the quotes). You will probably only get VESA modes 0x100 (640x400) and 0x101 (640x480) to display properly in full-screen mode on your display. Continue to hit the ENTER key until you get back to a DOS prompt. Close the MS-DOS prompt by typing EXIT then use the ENTER key.

7.) Now attempt to run your DOS application/game via the WinXP NTVDM. Please report any success or failures.

I will explain what I believe is happening after some feedback from your reports.

Thanks again,

dvwjr

Edit: Updated VgaTest.exe with SVgaTest.exe

Hi dvwjr. I'm out of my depth on this one but I'll try anyway.

First of all I'm already signed in under an Admin account so I'll skip that bit if thats OK.

I can't find any of the files in \windows\system32\drivers that you listed - I don't honestly have a clue which other ones might give direct hardware access and which don't so I havn't touched any.

I copied the VGATEST.EXE file to C:\ and ran COMMAND.COM like you said and entered: "C:\VGATEST 4" without the quotes like you said.

The screen went black for a second and then it crashed to Desktop and the following error message popped up:

Sorry I can't help you any more than that.

Thx for the help dvwjr
I guess it must be a video card issue - I could not find any of the.sys files that you listed. But i ran the vgatest on both old and new pc's. As expected on the old pc the test ran for the first 2 modes and then signal out of range.
With the new pc i get a black screen straight away and can only exit with alt-tab.
I have used a vgafix.exe before which allows vga modes in higher resolutions- but when trying to run this patch on my new pc it says:" could not determine version of file C:\windows\system32\drivers\vga.sys"
I have run an sfv file check on the vga.sys and i have the same version in both pc's (msoft file version 5.1.2600.2180) .
I suspect a modified vga.sys would solve the problem but not sure where to get this or even if there is one.
Thx again for any help.

Chug a Bug wrote:

First of all I'm already signed in under an Admin account so I'll skip that bit if thats OK.

It's not OK. The problem with remote problem solving is that certain checkpoints HAVE to be followed to allow for a possible solution to be implemented. I could take the time to explain exactly WHY I want you to perform a certain step, however on-line time constraints mean that I would take more time explaining and convincing you to perform each suggested step. Even though this entails just giving you what appears to be a simplistic set of procedures that seem a bit un-necessary and maybe in their brevity condesending in attitude towards your technical knowledge. It is natural to be a bit miffed when it appears that is just rudeness by asking you to do something EXACTLY as was stated - however, you attempt to enter the problem solving arena yourself when you wish to 'shortcut' a few steps that you "know" won't matter anyway. At that point you have interfered with the problem resolution/information steps being followed since your "common sense" and familiarity with most PC hardware/software problems gives you the confidence that a certain step is not really necessary - so that it can be skipped or said to be peformed when in reality it was never done.

Not to bore you but an example illuminates: Guy went to a auto service department of Caddillac. He stated that when his wife started the car it would fail to start or start with difficulty. However, when HE started the car everything was just fine. Service tech said go home and have your wife start the car exactly as she always did when the car would exhibit starting problems and report back the results. The guy goes home and does what he thinks the service tech just asked him to do. Gets his wife to sit in the seat of the car and start it. Everything worked just fine. Calls the service tech and tells him it seems OK. Next day his wife again has problems starting the car. Guy calls the service tech and the tech suggests to the guy to again have his wife start the car EXCACTLY as she always did when it failed to start. The now perplexed guy complies and again the car starts perfectly for his wife. She is frustrated since the car only seems to fail to start for her when her husband is NOT present. Well, the next day the wife has the same problem, tells her husband - who again calls the service tech. The service tech now sets up an appointment for the car but requests both the man and his wife to be present. The customer agrees and shows up the next day with his wife. They service tech has the guy get into his car and attempt to start it. Car starts just fine. Guy turns off the car, gets out but leaves his keys in the ignition for his wife's attempt. The service tech stops his wife from entering the car and asks if she normally used her husband's keys when she used the car. She said no, she had her own set of car keys. So the tech removed the husbands's set of keys, the wife then opened her purse, got her keys out, sat down and inserted the ignition key. She then attempted to start the car - IT FAILED TO START! It turned out that the key-chain that the wife used had many more keys and ornamental hanging jewelery attached. It was much HEAVIER that the three keys on her husband's keychain. This extra weight pulled on the interlock mechanism of the ignition inside the steering wheel and caused an electrical short which prevented the starter motor from getting an electrical current. Problem solved. The lesson here is that the husband innocently inserted himself into the problem resolution by substituting his judgement as to what EXACTLY was involved in re-creating the steps used by his wife when SHE started the car by using his keys instead of letting his wife actually use the keys in her purse.

If you substitute your judgement for mine by ignoring a step in a suggested process - or even worse say you did a step when you did not perform it will negate the problem resolution process because I (or others) are working in the blind with faulty information. So help me out and try the steps as suggested. If they work I'll be glad to explain why I think they worked - if they don't I'll suggest another approach without explanation.

Chug a Bug wrote:

I can't find any of the files in \windows\system32\drivers that you listed - I don't honestly have a clue which other ones might give direct hardware access and which don't so I havn't touched any.

If you did not find any of the problem SYS driver files you have eliminated them as a possible source of the problem. Do not worry about what other rogue driver files might be allowing direct hardware IO - unless you have an intermediate port driver monitor or are using kernel-mode debug you won't know.

Please try the steps I outlined above EXACTLY as stated. Do not leave the PC even for a second while you attempt these steps. I need to know that the above listed steps occurred sucessfully and had your eyeballs on the screen the whole time. I am trying to make sure that no screen-saver/blanking or power-save operations happen from the time the PC is TURNED on to the time you attempt to execute the "VGATEST 4" command at a WinXP NTVDM "Ms-Dos" COMMAND.COM prompt as an ADMINISTRATOR type user ID.

Let me know your results...

Help me help you, 😁

dvwjr

jjim wrote:

Thx for the help dvwjr. I guess it must be a video card issue -

Not necessarily a video card issue... My system was built last year - an Intel 925XE motherboard supporting a P4 model 640 HT CPU. The Video adapter is a PCIe Nvidia 6600GT. Your system Core 2 Duo system and Nvidia PCIe 7900GT system is the next logical iteration of the Intel system I built. The Nvidia BIOS and Dual CPU core/HyperThreading core are presented to WinXP in much the same manner.

What Nvidia driver version are you using for your 7900GT? I am using the 91.47 release for my 6600GT. The only problem with Nvidia drivers for HT or dual-core systems is they tried to get cute and multi-thread their video driver in a clumsy way. There is a WinXP registry entry to turn restrict the driver to a single CPU core to get around some problems this may cause. This is NOT for legacy DOS applications or games but for Direct3D or OpenGL applications - like most Windows games or say DOSBOX. Applications that use the Nvidia video driver to function. The use of the VGA.SYS driver and the Nvidia VESA 3.0 compliant BIOS for "Full-Screen" DOS games/applications do not fall in this display application catagory. Check the Nvidia release notes PDF file for driver version 91.47 about HKey_Local_Machine\SYSTEM\CurrentControlSet\Control\Video\{GUID}\0000\OGL_ThreadControl and WTD_EXECMODEL for more information.

With your dual core Intel CPU and WinXP you might also wish to check out the information/fixes for WinXP (SP2) from Microsoft at this Microsoft support link.

jjim wrote:

I could not find any of the.sys files that you listed.

There could be other *.SYS driver files which are poking holes in the hardware I/O protection of WinXP - but don't knock yourself out looking for them. Just look for the obvious and a future revisit for such a file can just be added to the resolution checklist.

jjim wrote:

But i ran the vgatest on both old and new pc's. As expected on the old pc the test ran for the first 2 modes and then signal out of range. With the new pc i get a black screen straight away and can only exit with alt-tab.

Since WinXP (SP2) version is running on your "old" PC that successfully ran the "VGATEST.EXE 4" VESA modes 0x100 and 0x101, what video card model, driver version and finally the video BIOS version? What is the driver version for your 7900GT and video BIOS version?

jjim wrote:

I have used a vgafix.exe before which allows vga modes in higher resolutions- but when trying to run this patch on my new pc it says:" could not determine version of file C:\windows\system32\drivers\vga.sys". I have run an sfv file check on the vga.sys and i have the same version in both pc's (msoft file version 5.1.2600.2180) .I suspect a modified vga.sys would solve the problem but not sure where to get this or even if there is one.

I suspect that modifying the VGA.SYS file of WinXP (SP2) would not help the "Black Screen of Death" problem at all. Your boot screen on WinXP is already running at 640x480 - the unpatched VGA.SYS allows this SVGA video mode to function. To check the functionality of a video adapter BIOS in "full-screen" DOS video all we need to test is VGA mode 0x13 and VESA mode 0x101. The patched VGA.SYS file is just a way to get to VESA modes above 0x101 under WinXP(SP2) to function by relaxing the WinXP control of certain legacy video adapter I/O ports.

Now to the heart of the problem. The only reason that I even give a rat's ass about the WinXP video driver version is for any possible effect on the NTVDM environment - unlike DOSBOX where the video driver version and bugs are quite important in the emulated DOS video environment since that display uses the WinXP video driver for all video output. When the video driver version is known one can determine how the driver/video adapter combination supports legacy video operation in the NTVDM 'full-screen' environment. That is, did the programmers who wrote the video driver rely completely on the stock Microsoft VGA.SYS or did they write and support their own custom replacement of VGA.SYS? Did they save all video registers themselves before giving exclusive control to VGA.SYS - or did they count on VGA.SYS saving and restore said video adapter registers?

I could not determine from your posting if you actually followed every one of the seven steps that I outlined in my first message on this thread? Please try the steps I outlined above EXACTLY as stated. Do not leave the PC even for a second while you attempt these steps. I need to know that the above listed steps occurred sucessfully and had your eyeballs on the screen the whole time. I am trying to make sure that no screen-saver/blanking or power-save operations happen from the time the PC is TURNED on to the time you attempt to execute the "VGATEST 4" command at a WinXP NTVDM "Ms-Dos" COMMAND.COM prompt as an ADMINISTRATOR type user ID.

If still no luck in getting a view of the VGATEST VESA mode 0x100 or 0x101 then we have to go to pure DOS mode on your WinXP(SP2) PC workstation to see how your Nvidia 7900GT reacts to VGATEST.EXE under MS-DOS v8.00 - if it works there then it should function under WinXP(SP2) as well...

If your PC workstation has a 3.5" floppy disk drive you could attempt the following: Place a blank 3.5"diskette in the floppy diskette drive. Go to "MY COMPUTER" and right click on the 3.5" floppy disk ICON. You should see a "Format" option. Select it and then at the FORMAT screen choose the "Create a MS-DOS startup disk". This will format your blank floppy diskette and place MS-DOS v8.00 system files and COMMAND.COM on the floppy diskette. It will be a real bootable MS-DOS v8.00 disk. Now copy VGATEST.EXE to this floppy diskette. Find the boot option in your PC workstation BIOS so that the 3.5" floppy disk drive becomes the FIRST bootable device for this test.

Now re-boot your PC workstation with the just made 3.5" bootable floppy diskette and then run the "VGATEST 4" at the MS-DOS "A:\>" prompt. Note just how many of the VESA video modes you can actually appear on the screen. This will tell us if the Nvidia video BIOS on your 7900GT still has DOS VESA 3.0 support. Now remove the floppy diskette, re-boot and set you PC workstation BIOS back to the previous Boot configuration. Re-boot again, login to WinXP and post on this thread your data.

We will go from there...

Help me help you, 😁

dvwjr

Thanks for all your comprehensive help.
I retried your steps for vgatest 4 within windows exactly as outlined - still with only a black hanging screen on my new PC ( NOW using 93.71 Drivers - also tested with 91.47) vid card bios string is version 5.71.22.42.06.
Old pc is a p4 2.66 with sblive 5.1 soundcard and a geforce 6600 video card.
A glimmer of hope though- I made the boot disk and ran as you suggested vgatest 4. All tests ran perfectly ( 5 in total - the last one being at 1280x1024 resolution which is the max for my lcd monitor). Btw just to eliminate the monitor being the problem i ran my new pc on 2 other monitors in windows with the same black screen result.
So it seems that the video card can output the vga signals - now how to get this happening in win xp???
Thanks again for your time and help

Ok, on to the next steps.

jjim wrote:

A glimmer of hope though- I made the boot disk and ran as you suggested vgatest 4. All tests ran perfectly ( 5 in total - the last one being at 1280x1024 resolution which is the max for my lcd monitor). Btw just to eliminate the monitor being the problem i ran my new pc on 2 other monitors in windows with the same black screen result.

Since NVidia decided to lock any VESA output to 60Hz your LCD monitor should have been able to display the five VESA 256 color resolutions. My problem is my nice Lacie Electron22Blue IV can not do a solid 85Hz except via DosBox v0.65 until I decided to hack the VESA portion of the 6600GT video BIOS. 😀

The problem is not with your Nvidia 7900GT, it is all in the Microsoft stock VGA.SYS file of WinXP. Please re-execute the seven steps outlined above except try "VGATEST 3" instead. This will test the standard IBM VGA screen modes up to mode 0x13. Just trying to make sure this portion of VGA testing is getting past the standard VGA.SYS - it should. If it does not then we are wasting our time.

If equipment grew on trees the next step would be to test an NVidia 6600GT PCIe on your Intel Core 2 Duo based new PC workstation. The test would discount any possibility that the dual core CPU/WinXP is the cause of any problems. However, we will have to assume that combination this would function properly. So the next thing is for you to send me a copy of your NVidia 7900GT video BIOS. This may be accomplished by going to this link at MVKTech and downloading the BiBiTor v3.1 utility. Download this file, install it and the perform the following simple operation to create a copy of your 7900GT video BIOS. From the main NiBiTor v3.2 menu bar select Tools/Read Bios/Select Device/(your PCI-E 7900 GT)/OK followed by Tools/Read Bios/Read into File.../(7900GT)/Save. Then take that just created 7900GT.ROM file and attach it to your reply along with the "VGATEST 3" results.

I have a suspicion that your Nvidia 7900GT might not be seen as an NVidia adapter by VGA.SYS, however I will not know that until I get a look at your 7900GT video BIOS. This is not rocket science - anyone can see that the 7900GT VESA support is just fine in DOS therefore we just have to be like the proverbial 10 million monkeys: if we keep beating on the keyboard, something will happen... 😳

Thanks for your continued interest,

dvwjr

Thanks for the help again.
Since we last spoke i had a bit of trouble with my 7900GT - ( the fan was sticking ) so as it is still new i returned it to my pc shop. Fortunately they no longer make the 7900GT so It was replaced with a 7950GT . I hoped that this might solve the vga problem but after performing all tests I still get the same results ( black screen on vgatest 4 ) I have alsao tried vgatest 3 - ahhhhhh same result . In fact i have tried all the vga tests available and only vgatest 2 works within windows. All tests work fine when running from the msdos boot disk.
I hope I am not wasting your time - I appreciate your help.
I have attached the bios as instructed together with the system32/drivers/vga.sys file and my system32/vga.drv in case these help.
Thanks again.

jjim wrote:

I hope I am not wasting your time - I appreciate your help.

No, no. You are not wasting my time. What I was referring to was possible changes by NVidia to their BIOS which might copy the Matrox BIOS idea of preventing protected-mode access to portions of the BIOS if not directly supported by protected-mode video drivers.

Please check back after Thanksgiving Holiday - I have to scare up an older GeForce 2 model to check with VGA.SYS - can not put it off any longer. The programmer who produced the two byte patch for the Microsoft WinXP version of VGA.SYS, which 'allowed' the NVidia video adapters to function with VESA modes greater than mode 0x101 (640x480x256color) really was not patching for NVidia. It seems it just worked out that way. Now I have to really understand the VGA.SYS structure before I can try to patch it my way...

Thank you for your BIOS file, it will help in running down a possible solution. Don't give up - just check back every few days. I won't give up if you don't... 😁

Thanks again,

dvwjr

Thanks again for the help and support - I'll keep watching every few days. 😀

jjim wrote:

Thanks again for the help and support - I'll keep watching every few days. 😀

Just scrounged up a GeForce2 MX400 for testing yesterday. I'll use that to compare VGA.SYS with the GeForce2 video BIOS. Now I could use some additional information from you about your Nvidia 7950GT. If you could go to your WinXP registry and look for the following key:

1REGISTRY\Machine\System\CurrentControlSet\Enum\PCI\{Vendor PnP_ID}\[4&.......}\
2
3Look for:
4Device Description: NVIDIA GeForce 7950 GT

Once you find your Nvidia GeForce 7950GT registry entry among the many listed in the Registry list of PCI devices, look at the .\Control\AllocConfig key. If you right-click on the \AllocConfig key you will have a choice of 'MODIFY'. Select this option and then select the Bus Number/Interface Type choice and chose 'Display'. You should have the registry information displayed as does the GIF file I attached to this message: RegistryPCI_2.gif. If you could take an identical screen-shot from your WinXP PC workstation and post it with your reply that would be of assistance.

Keep checking back, I'm juggling more than a few tasks that I need to keep 'in the air' - this might take a while. But you will know if I give up on this matter because I would post any such action on my part in this message thread. We need to get to the bottom of this since it seems that the new VISTA x86 (32-bit) version will not have full-screen NTVDM support. So WinXP (Sp?) looks to be the last way to support VGA/VESA apps with the NTVDM.

Work continues,

dvwjr

Edit: Changed image file.

Here is a screenshot of the registry corresponding to the Device Description: NVIDIA GeForce 7950 GT.
Thanks again.

I had this problem with my GF7900GS.
This fixed it (without touching vga.sys

http://www.volny.cz/martin.sulak/

.

^Thanks! It works great!^

BTW the link in that page doesn't work, the actual download link is here:

http://www.volny.cz/martin.sulak/videoprt.zip

Reportedly the file has moved again. New link:

http://archive.dukertcm.com/knowledge-base/do … xp/videoprt.zip