VOGONS


First post, by oz_pete

User metadata
Rank Newbie
Rank
Newbie

I have a 640x480x16 DOS application rather critical to my work. As our systems have upgraded I have had a dream run with no problems at all as we migrated over the years through: 3.11, 95, 96, NT4, Win2k, XP SP1. At XP SP2 I've stuck a hitch. Its not really a problem with the application which runs as well as ever but on exit, many of our XP SP2 machines of
1999 - 2001 vintage have about a 50-50 chance of going "black screen".
Our later hardware does not suffer from this although recovery of the original video state and data seems to a few tens of milliseconds longer compared with earlier OS versions we used to run.

Seems Windows is still running, but "in the dark". The monitor tells me that the original higher resolution signal has been restored (H and Y syncs ok), but all pixels are "pure black". Winding up the brightness allows the raster lines to be seen, but it seems like the video DACs have been disabled.

The problem is not dependent on the DOS app and can occur whenever a
command window is changed to a low res mode. ie. When a normal command window is expanded to "full screen" text mode (720 x400 i think),
using the properties menu on cmd.exe, a "black screen" on exit can occur.

My tech people here acknowledge it is a problem, probably in the XP images they distribute, but they won't put rescources into tracking it down as "who uses DOS stuff these days?" They do assure me that their tests in loading the lastest card drivers doesn't make it go away. The problem seems to afflict quite a range of 1999-2001 hardware with various video cards. None of these machines had problems last year with XP SP1.
Suggestions plese, I'm really on my own with this one and rapidly getting out of my league.

Reply 2 of 4, by Snover

User metadata
Rank l33t++
Rank
l33t++

I would suggest use of DOSBox. It'll be the only way to fly soon. 😀

Yes, it’s my fault.

Reply 3 of 4, by oz_pete

User metadata
Rank Newbie
Rank
Newbie

Thanks for the help so far......... but.
The vga.sys patch doesn't help. (my reading of the history of that patch is that it is for certain video cards that had trouble in setting certain modes). My probblem seems a little different in that it involves the incorrect recovery of the video state & data after a mode switch. I am (reasonably) sure that video adapter has switched back to the original desktop resolution but is disabled in someway that prevents it issuing non black pixels. Mind you I'll soon check with a CRO to see that a properly formatted video (black) signal is emerging. The monitor seems happy with it and doesn't "go to sleep" or complain of "no signal".

What I really need to help debug this is some 32-bit code that can simply make some VESA calls to establish what the current state of the card is. I can't do this in 16-bit code as any attempt to get info via a VESA extended video bios call (say even an int 10h (ax=004Fh) call) causes NTVDM (I think?) to switch to full screen mode first, - and that defeats my purpose of making the call which is to find out what state the card is in during the "black screen" mode.

Unfortunately while I can hack out 16-bit assembler code and know the DOS calls well enough, I don't have the means or knowledge to do a 32-bit windows environment version of doing this.
Could anyone help here? I'm sure it would need only a few lines to make
a vesa call and say write the returned buffer to a disk file that can be examined later, after the computer is restarted and is useable again. (By very carefully positioning the cursor before triggering a "blackout", it is possible to launch other code from the "blackout" state.)

As for DOSbox, yes its a great product and I do use it often. The problem of course is performance. My DOS application is a digital logic simulator. While the "virtual logic ciruits" made with it have only a few dozen parts and a hundred or less connections, you hardly notice the emulation overhead. When the virtual circuit complexity climbs up to a couple of hundered components and a thousand or more "tracks" (say a very elementary CPU), the simulation speed through DOSbox is an unusable crawl, whereas the straight code still runs quite crisply. (It seems that the performance ratio of normal:DOSbox is somewhere between 5:1 and 10:1)

For those without an Intel CPUs based machine, DOSbox must be a real blessiing. However if you already have a CPU that's quite capable of running (conventional memory)16-bit code and needs only the DOS calls (and vga interface) emulated, its a little frustrating to suffer the large performance hit involved with emulating the actual CPU instructions as well.

Reply 4 of 4, by Snover

User metadata
Rank l33t++
Rank
l33t++

I would suggest not believing their 'tests', and download and install the latest video drivers yourself. 😜

Yes, it’s my fault.