[thezedman]

I am very pleaseed to find this workaround for full screen on Windows 7; however, I am having difficulty accessing the video graphics modes, particularly 13h.

NTVDM can enter full-screen in text mode without issue. However, whenever I try to run a mode 13h VGA graphical program, the sound of the program is audible, but NTVDM continues to display the dos prompt and does not switch to the 13h video mode. The sound for the program will play and it will respond to input, so it seems the issue may be purely with regard to changing which video mode is displayed on screen.

(The DOS programs I'm trying to run all used to work perfectly on Windows 2000 and XP using NTVDM.)

Currently, I have compatch, ntvdmpatch, and comhostf installed.

I am using a Bay Trail Mobile laptop with WDDM Intel HD Graphics drivers on 32-bit Windows 7, so I've tried both of the Intel VGA patchs (16-bit and 32-bit versions) without success. I have also tried the videoprt.zip patch once, which crashed the system.

Since you have had a lot of success with NTVDM text mode, I'm hoping that you may know of a way to get NTVDM to work with VGA video modes, or be able to point me in the right direction.

Many thanks in advance.

[leecher]

Hi,

As you said that it worked fine with NTVDM in Windows 2000 and XP, are we speaking about running it in Win 2k/XP on the same machine or on a different machine?
NTVDM normally passes through all I/O directly to the underlying Video Hardware, when in fullscreen mode, so there is the possibility that there is a compatibility issue there.
It would also be interesting HOW the DOS application changes the Video mode.
This can either be done via directly programming the IO registers of the video card or by just using the BIOS INT 10h service for it. As the NTVDM usese the real BIOS of the PC for BIOS calls, it could be that the functions fo switching video modes implemented there do not work as expected.
Did you try the 32bit IO fix for the NTVDM? Modern BIOSes may want to use 32bit I/O, so the calls won't work correctly as NTVDM doesn't support the calls without the fix:
https://www.waldbauer.com/vb/showpos...2&postcount=14

[thezedman]

Different machine with Win 2K/XP.

That being said, before I discovered your tools, I tried installing the Ivy Bridge XP drivers on Windows 7 by modifying the INF file. Although the XP drivers failed to install and would crash the display forcing me to reboot, when I rebooted the computer in Safe Mode I was briefly able to run some EGA and CGA video programs on Win 7 on the same machine.

However, since then, I've updated my drivers and have been unable to replicate the brief Safe Mode success.

I've checked my Intel HD Graphics VBIOS version and it is exactly the same as before the update (1022.0).

Could it be that the Safe Mode VGA driver is different and/or handles video output somehow differently than the default VGA fallback driver?

I've also tried both intelvidfix.zip and 32biofix.zip, both separately as well as together. In all cases, Windows 7 just displays the command prompt without changing video modes or displaying any graphics.

I've also tried the videoprt.zip patch; however, it crashes the system. From reading a couple of different forums, I discovered that Windows XP changed their videoprt.sys export functions in SP3. So, I then checked Windows 7's videoprt.sys file and found it also has a slightly different export symbol table.

As a result, I edited lnk.c to match Windows 7's videoprt.sys export table, and recompiled, although no success. On the one hand, the patch no longer crashes, however on the other hand, it prevents NTVDM from even displaying even text mode, in full screen. I've also tried both versions with intelvidfix and 32biofix, but still no success.

One additional lead which may or may not be helpful: while searching for information about videoprt.zip, I came across a modified version of the videoprt patch source code floating about on a Russian forum, updated for Windows Sever 2003 and the new Windows XP SP3 symbol table: https://forum.ru-board.com/topic.cgi...30840&start=20. This version contains some commented out code in reg.c for a particular NVIDIA video card which doesn't seem to play well with videoprt.sys:

#if 0 // Use standard GTX750Ti ports if no display adapter ports found in registry (note: using standard VGA ports only does not help in case of GTX750Ti)
if (status == FALSE) {
static VIDEO_ACCESS_RANGE vgaports[] = { {{0x3B0},12, 1,1,1,0}, {{0x3C0},32, 1,1,1,0}, {{0xBC00},128, 1,1,1,0} };
memcpy(ranges, vgaports, sizeof(vgaports));
numRanges = sizeof(vgaports) / sizeof(*vgaports);
status = TRUE;
}
#endif

The above commented out C code makes me wonder whether HD Graphics may fall in the same category and need special treatment with the videoprt patch. However, this may also be a red herring since NTVDM's full screen text mode currently works and the video modes did briefly work in Safe Mode, albeit not in regular mode with the Intel HD Graphics driver disabled.

Overall, I'm not sure whether the problem is with the port I/O or with some other componenet or even a combination, and I'm unsure what can or should be done next to debug and/or fix it.

[leecher]

As you said, the NTVDM continues to show the prompt instead of switching the video mode:
I guess it doesn't prompt you, you just get the last state of the screen before switching the video mode, correct?
And you switch to full screen using ALT+RETURN and then you are in textmode and from fullscreen textmode, you start your application and it starts, but doesn't change video mode, is this correct?
I'm asking, because a blinking cursor in a window without displaying anything is normal NTVDM-behaviour, if you i.e. switch back from fullscreen to windowed with graphics mode on, because the 32bit NTVDM doesn't have compiled in video emulation for windowed mode (that's why it usually forces fullscreen as soon as entering graphics mode).

[leecher]

Regarding your question about the safe mode video driver: It should be the same as the fallback driver that gets activated when disabling video output, so the observation with safe mode is quite interesting. I don't really have an explanation for it.

To further diagnose the issues, you may want to debug your video BIOS to find potentially problematic code.
For that I first recommend to dump the video BIOS to have a copy of it for urther research.
I did my debugging with the enhanced DEBUGX from Freedos (for just dumping, the normal debug.com that ships with Windows is also enough):

-r cs
CS 15EF
:c000
-r cx
CX 0000
:ffff
-n video.bin
-w 0
0FFFF Bytes werden geschrieben.
-q

Afterwards, you may want to debug the mode switch to mode 13h with debugx.
First, let's get the BIOS entry point for mode switch:

-a
17A2:0100 mov ax,3516
17A2:0103 int 21
17A2:0105
-p
DPMI entry hooked, new entry=10C0:0128
AX=3516 BX=0000 CX=0000 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000
DS=17A2 ES=17A2 SS=17A2 CS=17A2 IP=0103 NV UP EI NG NZ NA PO NC
17A2:0103 CD21              INT     21
-p
AX=3516 BX=09C4 CX=0000 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000
DS=17A2 ES=0214 SS=17A2 CS=17A2 IP=0105 NV UP EI NG NZ NA PO NC
17A2:0105 0000              ADD     [BX+SI],AL                       DS:09C4=00

Now depending on your Windows version, you need to dump the appropriate address. I'm currently on Windows XP, so I have es:950, but on Windows 7, you need ES:969 !
Here for illustration purposes, I show mine on XP, you should issue a "d es:969" instead!

-d es:950
0214:0950  EA C9 17 00 C0 56 57 55-BA 46 00 52 0E BB 6C 09 .....VWU.F.R..l.
0214:0960  53 BB 07 00 B4 0E 26 8A-05 47 EB E4 E2 EA 5D 5F S.....&..G....]_
0214:0970  5E B8 01 00 EB 9F 2E 80-3E A7 08 02 75 05 E8 85 ^.......>...u...
0214:0980  FE 72 F1 2E 80 3E A7 08-01 74 06 C4 C4 10 E9 BB .r...>...t......
0214:0990  FC 80 FC 13 75 04 3C FF-74 BB EA 65 F0 00 F0 CD ....u.<.t..e....
0214:09A0  10 C4 C4 FE C4 C4 11 E9-A2 FC C4 C4 12 E9 9C FC ................
0214:09B0  C4 C4 14 E9 96 FC 87 DB-00 00 00 00 18 00 00 00 ................
0214:09C0  32 00 00 00 1E 53 BB 40-00 8E DB 80 FC 10 E8 E8 2....S.@........

As can be seen, there is a JMP (EA) followed by a segment : offset address, (C000:17C9 in my example).Now we know the entry point in video bios, take note of this address!

Now try a mode switch to mode 13h and trace it:

-a
17A2:0105 mov ax,13
17A2:0108
-p
AX=0013 BX=09C4 CX=0000 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000
DS=17A2 ES=0214 SS=17A2 CS=17A2 IP=0108 NV UP EI NG NZ NA PO NC
17A2:0108 0000              ADD     [BX+SI],AL                       DS:09C4=00
-t =C000:17C9 
AX=0013 BX=09C4 CX=0000 DX=0000 SP=FFFC BP=0000 SI=0000 DI=0000
DS=17A2 ES=0214 SS=17A2 CS=C000 IP=17CA NV UP EI NG NZ NA PO NC
C000:17CA 50                PUSH    AX

Continue tracing with just pressing return or use t <Number of instructions>
to trace multiple instructions at once (Makes sense, as video BIOS
normally is huge and you may need to isolate the point where it possibly
fails or at least see where it tries to write to).
i.e.: t 1000

Maybe you can spot the issue by tracing the call. I still think, it may be a port access issue, but as you already patched the VIDEOPRT driver in the same manner as I would have done it (correcting redirected exports) and it still doesn't pass through the ports, you may need to check with windbg kernel debugger if it gets called properly and unlocks the correct ports.
What you can do is verify the "AllocConfig" key in registry (enum HKEY_LOCAL_MACHINE/CurrentControlSet/Enum/PCI and check for device with Class=Display and a "Control" subkey where there is the AllocConfig key which can be clicked on and then it displays the port ranges.
Verify that this key is present and maybe verify with kernel debugger that patched videprt.sys really exposes all these ports).

[leecher]

I managed to reproduce the problem on one of my machines.
From what I can see, Intel BIOS needs 32bit I/O AND also passthrough of F000-F004.
So at least, it needs combination of VIDEOPRT.SYS driver AND 32bit IO fix.
As you already patched VIDEOPRT.SYS to work on Win 7, can you upload your copy (ideally source + compiled version) so that I can test with it?
Thanks.

[thezedman]

(Edit: realized upon a more carful examination that the section of VBIOS that looked similar has some important differences than I dnoticed at first glance, but still it may be a clue.)

First off, I want to say a huge thank you, as I really appreciate your help so far.

Attached is my updated videoprt patch, based on the most recent Windows 7 32-bit version of videoprt.sys (January 2, 2020, MD5: b5298dc0d4e5f52d30bb992043d33cbf), which is also included in the root of the zip file. I compiled the patched videoprt.sys file using Visual C++ Express 2010 from the command line through the make.bat file.

With regard to my video card, HKLM\SYSTEM\CurrentControlSet\Enums\PCI\VEN_8086&D EV_0F31...\Control\AllocConfig seems to report the following:

For ports it lists:
0x3B0 (length 0xC)
0x3C0 (length 0x20)
0x3050 (length 0x8)

And for physical addresses, it lists:
0x0A0000 (length 0x20000)
0x80000000 (length 0x10000000)
0x90000000 (length 0x400000)

From what I can tell from OSDev.org, it seems that the 3B0h-3BCh & 3C0h-3E0h ports are part of standard VGA hardware protocol, as is the memory address range of 0x0A0000-0x0BFFFF. However, the other ports (3050h-3058h) and memory addresses seem to be specific to the videocard.

Interestingly, my card does not seem to list F000h-F040h in the registry, and 3050h-3058h is a much narrower port range.

Further attached is a zip file of video.bin from the first set of debug steps.

Doing the second set of debug steps below, it seems my entry point is C000:0014

13BB:0103 int 21
13BB:0105
-p

AX=3516  BX=0000  CX=0000  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000
DS=13BB  ES=13BB  SS=13BB  CS=13BB  IP=0103   NV UP EI PL NZ NA PO NC
13BB:0103 CD21          INT     21
-p

AX=3516  BX=0A00  CX=0000  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000
DS=13BB  ES=020E  SS=13BB  CS=13BB  IP=0105   NV UP EI PL NZ NA PO NC
13BB:0105 0000          ADD     [BX+SI],AL                         DS:0A00=00
-d es:969
020E:0960                             EA 14 00 00 C0 56 57            .....VW
020E:0970  55 BA 46 00 52 0E BB 85-09 53 BB 07 00 B4 0E 26   U.F.R....S.....&
020E:0980  8A 05 47 EB E4 E2 EA 5D-5F 5E B8 01 00 EB 9A 9C   ..G....]_^......
020E:0990  0E 68 96 09 EB D3 3D 4F-00 75 18 26 F7 05 40 00   .h....=O.u.&..@.
020E:09A0  75 11 26 81 25 7F FF 26-C7 45 28 00 00 26 C7 45   u.&.%..&.E(..&.E
020E:09B0  2A 00 00 CF 2E 80 3E BB-08 02 75 05 E8 5B FE 72   *.....>...u..[.r
020E:09C0  CC 2E 80 3E BB 08 01 74-06 C4 C4 10 E9 90 FC 80   ...>...t........
020E:09D0  FC 13 75 04 3C FF 74 96-EA 65 F0 00 F0 CD 10 C4   ..u.<.t..e......
020E:09E0  C4 FE C4 C4 11 E9 77 FC-C4                        ......w..

Also attached is the trace through the mode 13 switch, following the third set of debug steps.

During the trace, at offset C000:52B2, I noticed that my VBIOS is trying to do port I/O to port 3050h and 3054h, and getting FFFF as a result. The surrounding instructions do look somewhat similar to your October 15, 2016 Intelvidfix trace, but without the comparison to EAX:

C000:52B2 24FC              AND     AL,FC
AX=1414 BX=1313 CX=0015 DX=3050 SP=FFC0 BP=FFE0 SI=1415 DI=0000
DS=0000 ES=020E SS=14F2 CS=C000 IP=52B4 NV UP DI PL NZ NA PE NC
C000:52B4 66EF              OUT     DX,EAX
AX=1414 BX=1313 CX=0015 DX=3054 SP=FFC0 BP=FFE0 SI=1415 DI=0000
DS=0000 ES=020E SS=14F2 CS=C000 IP=52BB NV UP DI PL NZ NA PE NC
C000:52BB 66ED              IN      EAX,DX
AX=FFFF BX=1313 CX=0001 DX=3054 SP=FFC0 BP=FFE0 SI=1415 DI=0000
DS=0000 ES=020E SS=14F2 CS=C000 IP=52C0 NV UP DI PL NZ NA PO NC
C000:52C0 C0E103            SHL     CL,03
AX=FFFF BX=1313 CX=0008 DX=3054 SP=FFC0 BP=FFE0 SI=1415 DI=0000
DS=0000 ES=020E SS=14F2 CS=C000 IP=52C3 NV UP DI PL NZ NA PO NC
C000:52C3 66D3E8            SHR     EAX,CL
AX=1FFF BX=1313 CX=0008 DX=3054 SP=FFC0 BP=FFE0 SI=1415 DI=0000
DS=0000 ES=020E SS=14F2 CS=C000 IP=52C6 NV UP DI PL NZ NA PE CY
C000:52C6 6692              XCHG    EAX,EDX
C000:52C8 6658              POP     EAX
AX=0013 BX=1313 CX=0008 DX=1FFF SP=FFC4 BP=FFE0 SI=1415 DI=0000
DS=0000 ES=020E SS=14F2 CS=C000 IP=52CA NV UP DI PL NZ NA PE CY
C000:52CA 8AC2              MOV     AL,DL
AX=00FF BX=1313 CX=0008 DX=1FFF SP=FFC4 BP=FFE0 SI=1415 DI=0000
DS=0000 ES=020E SS=14F2 CS=C000 IP=52CC NV UP DI PL NZ NA PE CY
C000:52CC 80FD00            CMP     CH,00
C000:52CF 740A              JZ      52DB
C000:52DB 665A              POP     EDX
C000:52DD 59                POP     CX
C000:52DE 665E              POP     ESI
C000:52E0 C3                RET

However, the trace is with the driver still enabled, in windowed mode, so it is possible that I/O may be different with the driver disabled.

Also, as you say, it does seem odd that I was briefly able to get the graphics mode to work by using the Safe Mode driver when I tried to install the Ivy Bridge XPDM ones.

I haven't yet been able to generate a good test script to verify that videoprt.sys is reporting the correct ports through its VideoPortGetAccessRanges function (although all the functions themselves remain unchanged), since there are very few examples on the Internet of VideoPortGetAccessRanges, particularly on how to set the HwDeviceExtension input variable.

[thezedman]

As an update, I just checked Volume 2 - Registers and Volume 3 - Overview of my Intel Graphics Card's manual, and while it has information about the VGA ports, it does not seem to contain any reference to port 3050h or 3054h. I did a quick Ctrl-F on the other volumes and similarly have found no reference to what this port range does or why it may be important to the VGA functions.

As well, I re-ran the trace through the VBIOS with the driver disabled and got the attached seemingly complete trace all the way to the IRET instruction. There seems to be a lot of access attempts to port 3054 on the video card.

[leecher]

Hi,

I found a bug in your patched version, you always forgot the comma for the ordinal leading to bad forwards:

#pragma comment(linker,"/export:ScsiPortNotification=vidprt0.ScsiPortNotification@4")
#pragma #pragma comment(linker,"/export:VideoPortDbgReportComplete=vidprt0.VideoPortDbgReportComplete@22")
#pragma comment(linker,"/export:VideoPortDbgReportCreate=vidprt0.VideoPortDbgReportCreate@23")
#pragma comment(linker,"/export:VideoPortDbgReportSecondaryData=vidprt0.VideoPortDbgReportSecondaryData@24")
#pragma comment(linker,"/export:VideoPortIsNoVesa=vidprt0.VideoPortIsNoVesa@55")
#pragma comment(linker,"/export:VideoPortNotification=vidprt0.VideoPortNotification@63")
etc.

You forgot comma, should read:

#pragma comment(linker,"/export:ScsiPortNotification=vidprt0.ScsiPortNotification,@4")
...

I attached a fixed version of videoprt.sys driver that has corrected forwards, to be sure, better use the fixed version.

Using this version of VIDEOPRT.SYS, I was able to get my Mode 13h running flawleassly, as can be tested with my litte test program TESTVGA.COM which I also attached. It switches to mode 13h, displays a text string, waits for a keypress and switches back.

Now as it doesn't work for you, I found a simple method to verify if the IO port range got passed through or not.
I extended my 32BITIOFIX with a logging function that also logs other in/out commands, not only 32bit I/O to Debugview console. When an IO port gets passed through, it doesn't get handed off to the NTVDM Monitor but gets directed directly to the hardware, so no log entry should be created in this case.
If it is a blocked port, it gets passed to the Monitor and therefore a log entry should be created.

Frem what I saw from my machine, it tries to access the PCI Config registers without success (therefore gets back FFFF). This isn't a problem for my BIOS here, as this generally is a valid state (PCI bus not present/supported), but maybe your BIOS is picky about it?

So as a next step in diagnostics:
1) Install the supplied VIDEOPRT.SYS driver
2) Install the supported 32bit IO fix using INSTALL.BAT
3) Open DebugView as administrator
4) Run the test program TESTVGA.COM and check its results
5) If it fails, check the ouput from DebugView if I/O ports are still blocked and which IO ports it tries to access.
6) You can try to manually unblock the required ports in the VIDEOPRT.SYS driver and check the results, however I'm not sure if Windows is happy with unblocking PCIe bus ports, but it can be tried.

Hope that helps.

[thezedman]

Many thanks! Manually unblocking the ports did the trick and now it works!

Using that commented-out GTX750Ti-specific code as a reference, I replaced the RegLoad function in reg.c with the following:

BOOLEAN RegLoad()
{
	    static VIDEO_ACCESS_RANGE vgaports[] = { {{0x3B0},0xC, 1,1,1,0}, {{0x3C0},0x20, 1,1,1,0}, {{0x3050},0x8, 1,1,1,0} };
	    memcpy(ranges, vgaports, sizeof(vgaports));
	    numRanges = sizeof(vgaports) / sizeof(*vgaports);
	    return TRUE;
}

It also seems to work well both with and without the 32-bit I/O patch on my card. However, I'm not too sure why RegLoad failed to find the ports, or what ports it was previously returning.

Attached is my log file from steps 1-5, before hard-coding the ports into reg.c