(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
Code:
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:
Code:
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.