Alexraptor wrote on 2026-10-28, 15:27:

Now this would definitely completely overkill, but I'm curious and have to ask anyway: Is it at all in the realm of possibility to backport SLI support for Pascal/Maxwell GPU's?

Pascal was the last Nvidia GPU chip to support SLI in hardware, so possibly, though I doubt it would be a worthwhile thing, unless it could be implemented and significantly improved for XP.

Shagittarius wrote on 2026-10-28, 01:55:

Installed my 1080ti to my XP and Win10 dual boot today. Everything seems hunky dory so far.

I should have said in my post - I'm using PAE (physical address extension) patches to allow upto 4GB RAM. Maybe this is the source of my issues? I'll try a copy of Windows XP without this and report back.

A potentially silly question, but still something I'm curious about - is it similarly possible to backport one of the late 2000's card's drivers to Win98? Or even to fix some issues that unofficial NVidia 7xxx drivers give on Win98?

RedCharles wrote on 2026-10-26, 20:57:

No problem, I've been hammering it with Claude and ChatGPT working together. 19th try running right now. Claude says we've got a 50% chance of getting it working 🤣.

Worst case, I buy a quadro P4000, and carefully use an angle grinder to make it fit.

I'm on driver 31 now. Still going. Should know in a day or two if it will work.

Any luck?

ChatGPT is building the 49th driver right now.

I had Claude generate a report for you.
Quadro P2200 on XP: Progress Report for SupraGSX
Summary
With three secure-boot fixes to your Forceware 382.69 miniport, the Quadro P2200 (DEV_1C31) completes NVIDIA's full GPU init on XP SP3. A hard boot freeze remains after that.
Fixes
• ACR version check (0x23): swapped in the 431.02 ACR.
• SEC2 dependency check (0x17): used 384.94's alternate SEC2, which needs only v1 PMU, FECS and GPCCS.
• WPR region field 0 reads 12, expects 15: accepted that pair only.
Freeze
With all three fixes, XP hangs at boot: black screen with signal, no event log, no dump. Test builds run to a checkpoint, then fail cleanly to Code 10 and log. Every checkpoint from Driver 28 to 48 boots, covering SEC2 readiness, init and load of all 42 engines, master init (returns TRUE) and the start of the HwFindAdapter tail.
Untested
The rest of HwFindAdapter (mostly registry reads), HwInitialize and the first mode set. We suspect display bring-up.
Questions
1. Did the 1080 Ti port hang at HwInitialize or the first mode set?
2. The P2200 is DisplayPort-only. Any known DP issues on the 368.81 base?
3. Does region field 0 reading 12 instead of 15 mean anything to you?

RedCharles wrote on 2026-10-31, 19:00:

ChatGPT is building the 49th driver right now. […]
Show full quote

ChatGPT is building the 49th driver right now.

I had Claude generate a report for you.
Quadro P2200 on XP: Progress Report for SupraGSX
Summary
With three secure-boot fixes to your Forceware 382.69 miniport, the Quadro P2200 (DEV_1C31) completes NVIDIA's full GPU init on XP SP3. A hard boot freeze remains after that.
Fixes
• ACR version check (0x23): swapped in the 431.02 ACR.
• SEC2 dependency check (0x17): used 384.94's alternate SEC2, which needs only v1 PMU, FECS and GPCCS.
• WPR region field 0 reads 12, expects 15: accepted that pair only.
Freeze
With all three fixes, XP hangs at boot: black screen with signal, no event log, no dump. Test builds run to a checkpoint, then fail cleanly to Code 10 and log. Every checkpoint from Driver 28 to 48 boots, covering SEC2 readiness, init and load of all 42 engines, master init (returns TRUE) and the start of the HwFindAdapter tail.
Untested
The rest of HwFindAdapter (mostly registry reads), HwInitialize and the first mode set. We suspect display bring-up.
Questions
1. Did the 1080 Ti port hang at HwInitialize or the first mode set?
2. The P2200 is DisplayPort-only. Any known DP issues on the 368.81 base?
3. Does region field 0 reading 12 instead of 15 mean anything to you?

1. 1080 Ti: did it hang at HwInitialize or the first mode set?
No my blockers were earlier: ACR version rejection, VPR/WPR state, then SEC2 readiness caused by a 56-byte XP boot descriptor versus an 84-byte descriptor expected by the newer bootloader. After correcting those, HwFindAdapter returned success and hardware Direct3D worked.

I also needed two nv4_disp.dll changes to select the existing Pascal display-object paths. Those are already included in Forceware; you should verify you retained the matching display DLL while replacing the miniport.

2. Known DisplayPort issues in 368.81?
Yes: link-rate selection, bandwidth/color-depth handling and scaling could produce blank or garbled output. I corrected several of these.

Start with one directly connected monitor at 1024×768/60 or standard 1080p/60. Trace entry and exit of:

- The remaining HwFindAdapter path.
- HwInitialize.
- Display-driver initialization and the first IOCTL_VIDEO_SET_CURRENT_MODE.

Your checkpoints establish substantial progress, but deliberately returning Code 10 before the remaining code runs cannot identify where the unrestricted boot hangs.

3. Does 12 instead of 15 mean anything?
Very much so, if “field 0” is the WPR read-permission mask. We observed this exact pattern:

Firmware policy Read mask Write mask

Older XP expectation 0xF 0xC
Newer ACR result 0xC 0xC

Supported Windows 7 comparison also used C/C. Thus, 12 can represent an intentional newer firmware policy rather than corruption. Accepting that pair only lets verification continue; it doesn’t change the hardware permissions or prove subsequent accesses are compatible.

If you can provide the exact comparison instruction and complete expected/actual region record, then compare that same state with a stock P2200-supported driver. Final 1080 Ti solution retained its original checks; changing F to C alone wasn’t the complete repair.

The strongest next step is locating the first operation that never returns, while checking that WPR compatibility change against the supported P2200 control. Display bring-up is a reasonable lead, but remains unproven.

Cool, so now full 4k (3840x2160 at 60 Hz) is possible on GTX 970? Both HDMI and DP?
I was hunting this for over 2 years after I found Yas patch that unlocked HDMI bandwidth to 600MHz (no DP) but I was still somehow limited to 1600p @89Hz in nvidia drivers (any custom resolution over 1600p was immediatelly rejected).
Also nice to see even newer GTX 10xx works...

Thanks SupraGSX for your effort making this possible. My Titan XP is one the way hoping to use it on my multi boot XP beast machine. So, reading this thread still not sure if it's fully functional yet with XP 32 and 64 bit?

RayeR wrote on Yesterday, 07:36:

Cool, so now full 4k (3840x2160 at 60 Hz) is possible on GTX 970? Both HDMI and DP?
Also nice to see even newer GTX 10xx works...

Note : DP may require firmware upgrade (on both GTX 900 and 1000), for modern monitors to work properly.

OK, is there also 32b version of NVIDIA DisplayPort Firmware Updater.exe?
BTW what it exactly do? Does it flash something to video BIOS ROM? or somewhere else? Maybe the flashrom is divided to multiple sections separate for vbios and for DP FW?

I've ran 4k 60hz on a 750 Ti with these drivers.

P2200 works. Took 69 Drivers. Edit: And just so you understand, the turn around on these was about an hour each.

Just played Far Cry, Doom 3, CS 1.5 and FEAR.

Still trying to get 4k 120hz to work. Once I have that worked out, I'll share.

Claude's summary of Codex's work.
1. Secure boot failed (Code 10). The card’s security chain rejected the driver’s firmware three times:

An old security loader: swapped for the one from NVIDIA 431.02.
A security-processor version mismatch: used an alternate SEC2 from 384.94, with its startup descriptor converted from 56 to 84 bytes.
A memory-permission value that was 12 instead of 15: newer firmware’s intended setting, so we accepted it.

2. XP froze at boot, leaving no logs. We built about 40 test drivers, each stopping cleanly at a later point, until the hang narrowed to one command-channel request in HwInitialize.

3. Skipping that request caused a blue screen instead. NVIDIA’s display driver hit a deliberate “fatal error” trap. We made later builds show the graphics firmware’s status on the blue screen: error 0x18. The firmware read a factory setting (“level 2”) it didn’t recognize.

4. The fix: graphics-engine firmware (FECS/GPCCS) from 431.02, which accepts level 2, with matching 84-byte descriptors. The error cleared, the 4K desktop appeared, and Far Cry ran with hardware 3D.