Jump to content
LaptopVideo2Go Forums
OlGeezer

Win10 on oooold discontinued hardware

Recommended Posts

OlGeezer

  So I got this Precision M90 on eBay for less than $100 incl S&H.  I have a few much newer laptops, but I keep coming back to these M90 / Inspiron 9400/E1705 models.  GREAT speakers, spectacular display, and touchpads smooth as glass that don't lean on the CPU.  I knew when I bought it there was some problem with the display, but thought I could fix it in a day or two.  After all, Best Buy sold hundreds of these with Win10 and "upgraded" hardware.  I eventually had to write my own INF file. to get it working at the native 1440x900 resolution.  Spent almost a month trying everything else under the sun. ;-Q
 
  Looking at the hard drive, it seems a previous owner -- after some really expert hardware upgrades -- tried half a dozen drivers and couldn't get anything to work.  It's Windows 10 Pro x64 with a GeForce Go 7900 GS GPU.  One was Vista driver 179.48 -- the latest nVidia recommends for this card -- which Win10 accepts, but then the display locks up after a half hour of heavy use (one hour even on a light load).  Can't be sure, but it looks like a memory leak.  Several other drivers from that era behave the same way.
 
  I eventually turned to "Pieter's modded INF file" with 341.81, as suggested on komeil.com .  (I think the page is down now.)  I tried six different ways from Sunday to get that working (yes, I know how to disable signature enforcement), but the BEST result -- when I force it down Windows throat -- is code 43.  The GPU reports a problem to Windows and shuts down.  I know laptopvideo2go can't test every OS/GPU combination.
 
  I'm now on 309.08.  I want everyone to tell me I'm a GENIUS to get a 2015 driver working when the mnfr  recommends nothing later than 2009. 😉  It's actually the Win7 section that works best for me so far.  I just copied the hardware IDs everywhere the ID for the desktop 7900 GS appears in the INF file.  Got the Control Panel working and the whole shebang -- no leaks.  But I still have a nagging feeling there might be something better.  Maybe something written after Win10 was born.  10 was really MADE for old hardware, if you can get the drivers for it.  It's an amazing thing to see!
 
  There are two apparently contradictory statements that appear in several places on nVidia's site:
  "After Release 340, any subsequent Windows driver release starting with Release 343 will cease to support the products listed in this section below. / The Release 340 drivers will continue to support these products until April 1, 2016, and the NVIDIA support team will continue to address driver issues for these products in driver branches up to and including Release 340. However, future driver enhancements and optimizations in driver releases after Release 340 will not support these products. [Go7900 GS is listed]"
  - And -
  "GeForce 6-series and GeForce 7-series GPUs have moved to legacy support with the GeForce R304 drivers. These products are no longer supported beginning with the GeForce R310 drivers."
 
  Confusion about the numbers?  Pieter's INF file that I tried actually has "... Go 7900 GS" in the [Strings] group.  It's numbered 341.88 and it has a Win10 section.  There are no 340.xx drivers dated later than 2014.  341.95 is marked "legacy" on laptopvideo2go.  It does NOT have support for the Go 7900 GS, but I could certainly write it in.
 
  Suggestions?  Should I keep looking for a later driver, or should I concentrate on tweaking some internal settings in 309.08??  Am I just spinning my wheels at this point???
 
TIA,
Rick
 

Share this post


Link to post
Share on other sites
mobilenvidia

The i7400 that brings back memories, quiet a few INFs where written on that machine.

Not dealt with these older drivers for a couple of years now.
Very last driver released in the 340 series was 342.01
It comes with security fixes has a modded INF but I had already long given up on Pre-Fermi GPUs by then
Older drivers in here support GPU's from 6000 series and up
Add in the PCI_ID things manually and see how you get on, you may need to also copy in the i7400/M90 specific section, as Dell has a tonne of OEM specific settings 
But you are probably better off with the 30x drivers

Good luck with this, keep in touch,  I'll try and help out where I can, form distant memories
GPU is probably over heating, I had to Oven bake mine quite a few times, a story about that in forums somewhere

Share this post


Link to post
Share on other sites
OlGeezer

Hi mobi,

  Got to be honest, I have no clue what is a i7400.  Was that an early Inspiron?  Mine is a Precision M90 with a T7600 core 2 duo processor running at 2.33Ghz.  It's closely related (same chasis and 17" screen, but  M90 is a little more advanced) to the Inspiron 9400 which  is identical to an Inspiron E1705.  These are all 2006 models, I think.  Heck, at's only 12 years ago!  Bill Cosby just got convicted for something he did FOURTEEN years ago. 😉😉 

  Maybe I can pick your brain a little.  I was a programmer in another life, so I'm a little skeptical this UDA(sp?) architecture PROVES that a modded INF file can make ANY driver sys file work with ANY nVidia GPU.  For example, a sys file might lack the ability to send signals SLOW ENOUGH for an older GPU.  It could have very similar architecture, but the hard coded table of clock frequencies could just be cropped off below a certain point.  That's just one example.  Are you privy to some internal documents at nVidia that GUARANTEE modding always works?  Despite "legacy" non-support statements??

  On the 342.01, my thought was they warned of no support after 340.xx .  True, they also said "starting with 343" but there's no law they have to make the numbers sequential.  And there are different dates to look at beside just release dates ... getting a headache just thinking about it. {;-q  Whaddya think?

  Would grappling with this PCI_ID thing really make a 342 driver viable?

  No worries on the heat front.  Previous owner (not the seller) upgraded the CPU, the GPU, the RAM and the entire keyboard.  I reasoned if he went to all that trouble, he'd have enough sense to put 50 cents worth a thermal paste in there, and I was right.  GPU hasn't gone over 85°C with a heavy load.  I don't do games, but for testing these drivers, I open 13 windows, including 3 Chrome, 3 IE and 3 Edge browsers, each browser with one YouTube video playing, and what I call "Google driving" where I bum around town at 40 MPH from my recliner, plus 4 other random programs, madly jumping from window to window.  It's Win10's system of memory compression in place of disk virtual memory swapping, that makes this possible on my ancient hardware.

Best,

OG

 

Share this post


Link to post
Share on other sites
mobilenvidia

340 series = 340.00 - 342.99
343+ =343.00 and beyond

Trust me all Pre-Fermi GPU's will fail with 343+, stick with 342.01 and below
Possibly best with older WDDM drivers as 
The drivers will only go as fast the GPU can go, but as the CPU is not mush faster there is not too much finger tapping going on

I ofcourse meant i9400 = inspron 9400, M90 cousin, I had a C2D7400, one of the very first to have one (as I got hold of an engineering sample)
Ah the memories

The GPU has a monster heatsink, remove this, Arctic silver the GPU, thin as you can get and even
85deg is gettting right up there especially as you say you don't game.

Share this post


Link to post
Share on other sites
OlGeezer

Mobi,
 
  Thanks for all the help.  So we've established it's not true that any nVidia driver will work with any nVidia GPU.  Now will try to see if anything >=310.xx will work with my particular GPU.  I'll see if I can learn about this PCI_ID business and give 342.01 the old college try.
 
  Dang, I thought I had the trademark on "I9400"!  Please note correct usage with a capital I. 😉
  
  I've had three (3) I9400s.  Put thermal paste on one, but it's long been closeted in pieces.  Only one still working I got on eBay for $49.  It's only 1.7ishGhz and Intelgrated (good word, eh?) GPU.  BUT it has the high res display, so I use that in the bedroom as a fancy DVD player.
 
  Also did a copper shim job on a Latitude E6400.  They invented the term "throttlegate" for the E6400/6500, ya know.  Thing is faster than snot now, but lousy sound, HORRIBLE touchpad, and a so-so display.  I greatly prefer my new M90.
 
  You may be thinking the locked up displays on this M90 were due to throttling, but I know what that is, and this ain't it.  In fact, my memory is that the fan kicks in right at 85°C, and that's exactly how it looks on the graph produced by HWiNFO64.  It nudges up to 85 for half a second, then immediately floats back down to 75.  That's only during heavy stress, which I have NO reason to do normally.  I have to turn everything off in the apartment to hear the fan on low.  I've NEVER yet heard it go into high!  It came with the latest BIOS installed.  I know for sure the hardware upgrades were done.  Dell never sold an M90 with a 2.33Ghz CPU -- that's the highest that will go into an M socket.  And the keyboard design is very tasteful, but not original spec.  Yesterday, after 12 hours of normal use, the GPU was at 56°C, and CPU a lot lower (can't remember ezackly).  I really think I could do more harm than good, tearing off the heat sink at this point.
 
  I'm really curious to know if anyone with Win10 has experienced these apparent memory leaks with old drivers (2009 or earlier).  My theory is that Win10 jostles memory around a lot more (to keep from using the disk VM), so leaks become apparent much more quickly.  Someone with Win7 or earlier might never notice.
 
  Thanks again.  I might have a few more questions when I look into 342.01
 
OG
 

Share this post


Link to post
Share on other sites
OlGeezer

Well, I gave it the old college try.  So unless you have a specific suggestion, I'm about ready to throw in the towel.
 
I'll try to retrace my steps, so you can see where I'm at...
 
Obviously I had done the PCI_ID thing at least a dozen times before my first post here.  I just didn't know what it was called.  Google told me there's no particular magic in that -- just a lot of copying and pasting and fiddling with the Section0xx numbers.  I know I have that right, cause I got 309.08 to work.  That's wasn't based on anything I found on this site, or anywhere else -- that was just me.  (More accurately, 95% nVidia + 4% me + 1% dumb luck.)
 
I didn't remember, but I tried 342.01 before a few weeks ago.  Probably tried over a dozen drivers.  BUT, I'm sure I didn't give it enough attention at that point.  So I had a copy on the HD.  I wasted an entire day sloooowly realizing, then PROVING, that nvdmi.inf was the only INF file Windows was refusing to read to get the list of cards you can select.  Eventually I downloaded a fresh copy and found the reason: a missing bracket in one line caused Windows to reject nvdmi.inf, no matter how I renamed it, or changed attributes or ownership, yadayadayada.  ONE WHOLE DAY wasted, but I guess I did it to myself somehow, when I messed with it a few weeks ago.
 
During that debacle I downloaded the 342.01 driver as it appears on Microsoft's update catalog.  It looks a little different, but maybe just on the surface.  Anyway, I wanted to concentrate on nvdmi,inf, since you mentioned OEM specific stuff.  I read that nvdmi.inf is for Dell, and I think that's correct, because there are references to two Dell programs in there, and nothing like that in the other INFs.
 
Once I got Windows to "see" nvdmi.inf, I tried 9 or 10 different things to get it working.  Three times, I got aborted installs with "invalid service section" messages.  Rest of the time, it installed, but gave code 43 either immediately, or after a required restart.
 
I tried Section numbers 001, 002, 003 and 004, one at a time.  In other words, I used the same section number for all four [NVIDIA_SetA_Devices.NTamd64.6.x] groups.  (There is no amd64.10 group.  I don't THINK that would make a difference...)  The lower numbers seem to be associated with older / more primitive cards, and 1, 2, 3, 4 goes with 6.1, 6.2, 6.3 and 6.0 respectively, in this particular INF.
 
There's little difference between the four sections, and I eventually concentrated on Section001.  The INF file also looks very similar to the INF I got working from 309.08, so I pulled them up side by side, and tried copying various parts from [Section001_sec] in nv_dispi.inf from 309.08 (what's  working now, as I type this) over to [Section001] in nvdmi.inf in 342.01 .  Like I say, I got a couple "invalid service" halts before I knew what I was doing, and then half a dozen "successful" installs (so says Windows) but code 43 -- i.e. no 1440x900 res and no Control Panel.
 
Here is my [Section001] in its last UNsuccessful incarnation. Some of the comments I added just now:
 
[Section001]
AddReg = nv_DRS_addreg
AddReg = nv_FTS_addreg
AddReg = nv_commonBase_addreg__01 ;This was my last change.  There was no __01 at the end...
;... I copied the entire [nv_commonBase_addreg__01] group from 309.08.  I thought it looked...
;... like the original in 342.01 was asking the GPU or CPU to do some fancy threading etc. ...
;... This one caused a black screen, followed by code 43 after a hard reboot.  Best I can ...
;... tell, [nv_commonBase_addreg__01] doesn't reference anything unavailable to 342.01
AddReg = nv_commonDisplayModes_addreg__01 ;Also tried null here at the end
AddReg = nv_controlPanel_addreg
AddReg = nv_global_addreg
AddReg = nv_miscBase_addreg__01
AddReg = nv_opengl_addreg
AddReg = nv_timingRestrictions_addreg
CopyFiles = nv_Drs_copyfiles
CopyFiles = nv_cplSetup_copyfiles
CopyFiles = nv_license_copyfiles
CopyFiles = nv_nvsmi_copyfiles
CopyFiles = nv_opencl_copyfiles
CopyFiles = nv_sysDrivers_copyfiles__01
CopyFiles = nv_system32_copyfiles__01
CopyFiles = nv_syswow64_copyfiles__01
DelFiles = nv_nvsmi_delfiles
DelFiles = nv_sysDrivers_delfiles
DelFiles = nv_system32_delfiles
DelFiles = nv_system64_delfiles
DelReg = nv_clearRegistrySwitches_delreg
FeatureScore = E0
;NVDefaultBPP = 32
;NVDefaultHorizontal = 1400
;NVDefaultVertical = 1050
;^^ I Tried with and without these three Defaults, which aren't in the 309.08 INF that's working
;NVSupport3DVision = 1
; Tried with and without 3D too, though internet tells me my card can't support 3DVision
NVSupportDisplayUpdate = 1
NVSupportNVwmi = 1
; The two above are harmless, and probably useless.  Left in for uber-safety.  Can ...
; ... be deselected in the setup.exe prog anyhow.
;NVSupportPhysx = 1
;^^ Tried with and without again.  Card doesn't support Physx
RegisterDLLs = nv_common_registerdll__01
;AddReg = nv_HDAudioInstall
;HDAudio was a dumb mistake which I realized and commented out.  No such group in this INF...
;... Don't need it anyway -- that video port doesn't exist on an M90.

[Section001.CoInstallers]
AddReg = nv_commonCoinstaller_addreg
CopyFiles = nv_coinstaller_copyfiles

[Section001.GeneralConfigData]
;Two settings below were 80 and 2 respectively in the original.  Tried the change ...
; ... for an uber-safe match with working 309.08
MaximumDeviceMemoryConfiguration = 128
MaximumNumberOfDevices = 4

[Section001.Services]
AddService = nvlddmkm, 0x00000002, nv_nvlddmkm_serviceInstall
 
Uncommented lines were unchanged, and match both the original 342.01 nvdmi.inf and the working INF from 309.08 .
 
You know, this is a little more important than just improving someone's gaming experience.  This actually gets old hardware WORKING with Windows 10, where it didn't work at all before!  (Unless you call 1024x768 "working" with this display.)  And WORKING BETTER than ever before, per earlier Windows version, IMHO.
 
But unless you have a magical suggestion, Obi-Wan 2GObe, I'll probably call it a day on this.  I could spend another month on it, with less than a 50/50 chance of making any contribution.

May the GeForce be with you!
OG
 

Share this post


Link to post
Share on other sites
OlGeezer

  OK, I'm a glutton for punishment.  Got another idea. I'll get 309.08 working with nvdmi.inf, instead of nv_disp.inf, then copy the whole working nvdmi.inf file into 342.01 .  Try to check and make sure this new nvdmi.inf doesn't reference any external programs unavailable to 342.01, and fire away.  The AddReg and CopyFiles groups in 342.01 are generally much longer than from 309.08, so unless the new sys file is LESS CAPABLE, in a sense (e.g. if it NEEDS some registry values that the old does NOT need),  than the old one, this should work.  If not, I can take one external file after another and replace new with old until EVENTUALLY, we wind up with 342.01 being an exact replica of 309.08 .
 
  Whaddya think?  Crazy enough??
 
OG

Share this post


Link to post
Share on other sites
OlGeezer

  OR....  I could take nvlddmkm.sy_ from 342.01 and stick it in the Display.Driver folder of 309.08 .  Then re-install 309.08 .  This would be a proof of concept kind of thing.  Not to get an optimal setup, but just to see if my approach in last post above has any chance to succeed.  I could also do same with the other two sy_ files.  The fact that they're named the same in both drivers, and of similar size, gives me some hope.  But I would change one at a time.

  Doing it this way (instead of just copying over the extracted files into Windows guts using Safe Mode) might avoid some problems with the registry.

  I'm awaiting your input, Obi-Wan.  I'm taking a day off.  Maybe two.  😉 

OG

Share this post


Link to post
Share on other sites
OlGeezer

YABU (Yet Another Boring Update):

  I did try supplanting the three *.sy_ files from 342.01 to 309.08, but of course that didn't work because the new sys files need some newer .dll files in 342.01.  Anyhow, got nvdmi.inf working instead of nv_dispi.ing in 309.08.  That was no problem.  So now the two INF files look even more similar.  So I pulled up nvdmi.inf from both drivers and did a pretty thorough comparison.  There's only six or seven things (total of maybe two dozen lines) that I think might be causing a problem in the newer INF, so if I try those changes in some kind of organized fashion, and it doesn't work, it almost proves the problem is in the .exe's or dll's direct handling of the old card.  And that I won't touch.  That WOULD take a month, just to get the background to START tinkering.  I don't have that much interest.

  Too tired to do any more today.  Will likely have news of utter failure in a day or two.  ;-}

OG

 

Share this post


Link to post
Share on other sites
mobilenvidia

Try the attached INF or 342.01 Fujitsu version

NVFM.inf

Share this post


Link to post
Share on other sites
OlGeezer

8 tries with Pieter's NVFM.inf:
 
  I now have three versions of 342.01 on my desktop.  The notebook version from nVidia's site, the desktop version from nVidia's site, and the Fujitsu version from Microstuff's Update Catalog.  I noticed you have 06A0 in the PCI-ID's in place of 0298, which is the actual hardware ID.  I thought that might be the reason setup.exe says it "cannot find the hardware" so I prepared a "0298Mod" INF file identical to yours except with 0298 replacing 06A0.  I tried your original, as well as my 0298Mod in various combinations with the three versions of 342.01 on my desktop, and either the setup.exe program, or the Device Manager "have a disk" manual method.  Here are the results:
 
-- Cleaned with DDU from SafeMode, and sig enforcement disabled on reboot --
1) Original with Notebook setup: Cannot continue / Cannot find hardware
2) 2098Mod  with Notebook setup: Cannot continue / Cannot find hardware
3) Original with Notebook manual: Cannot find file specified
4) Original with Desktop manual: Cannot find file specified
5) Original with MSUpdate setup: NVIDIA Installer failed
6) Original with MSUpdate manual: Cannot find file specified
-- Cleaned with DDU from SafeMode, and sig enforcement disabled on reboot --
7) 2098Mod with MSUpdate setup:  NVIDIA Installer failed
-- Cleaned with DDU from SafeMode, and sig enforcement disabled on reboot --
😎 2098Mod with MSUpdate manual: Cannot find file specified
 
  So I asked myself: "Self?  What file is Windows unable to find?"
- Everything in the [SourceDisksFiles] group appears to be in the folder along with setup.exe
- However, the following, from [SignatureAttributes], are not in the folder:
nvEncMFTH264.dll
nvEncMFTH264x.dll
nvEncMFThevc.dll
nvEncMFThevcx.dll
nvmcumd.dll
 
  These files are not referenced in the original NVFM.inf file from Microsloth / Fujitsu.  I'm assuming I have the right version.  What I refer to above as "MSUpdate" is marked:
"DriverVer   = 11/14/2016, 21.21.13.4201
CatalogFile = NVFM.CAT"
in the NVFM.inf file.  I tried going through fujitsu.com and then fujitsupc.com to get the driver, but there's no reference on either of those sites to 342.01, and they ultimately refer people to Microsoft Update.
 
  One question, if I may: Windows does seem to swallow your 06A0 substitution (you do use 0298 elsewhere), so was 06A0 deliberate, or was it smart to change all the IDs over to 0298?  I'm not trying to be cute, I really don't know if you had a reason for this.
 
  Thanks for trying!  You're welcome to take another shot at it, or else you can let me pillage and pilfer all your great ideas. 😉 
 
OG
 

Share this post


Link to post
Share on other sites
mobilenvidia

Yes change 06A0 to 0298 my bad, was in a hurry

If that iNF doesn't work with Fujitsu (MSupdate) driver then you are pretty well doomed
DOn't mix INFs with different driver files as you may get the files not found issue

Share this post


Link to post
Share on other sites
OlGeezer

  "DOn't mix INFs with different driver files"  Yes, and I'm afraid we're dealing with several different versions.  The five files I listed above are missing in the current Fujitsu 342.01 on MS site, but they were apparently in there at one time, since you have them in the 342.01 64bit INF file in the 342.01 thread, as well as the one you linked above,  On the other hand, there's a [nv_nvgsync_copyfiles] group referenced in BOTH of those INFs, but it only exists in the 342.01 thread INF, not the one above.

  So I'll go back to studying my modded 309.08 nvdmi.inf (which works) versus the 342.01 nvfmi.inf from nVidia (which at least installs to a code 43 --- no file, nor invalid section errors).  Just scanning for HINTS as to registry settings that MIGHT cause problems for the old card.  Also seems possible the newer version of OpenGL requires some minimum specs that my old card lacks.  So I could try moving over those DLLs.  Course if the 342.01 .sys files call APIs that don't exist in the older DLLs, then I'm done.

  I'd say the odds are about 3 to 1 against me, and at least 6 to 1 against actually IMPROVING on 309.08 .   But still worth a shot...

Share this post


Link to post
Share on other sites
mobilenvidia

Most important thing in modding INFs is to make sure that files it wants to copy exist
Some drivers have more features and need more files, then if you use that INF with lesser featured drivers you get the File not found error

This is how I started all those years ago, chugging away at INFs till they worked, a bit easier now with practice 🙂

Share this post


Link to post
Share on other sites
OlGeezer

  I'm summarizing what I've done, in the interest of science, in case anyone is crazy enough to want to duplicate my failure -- or point out where I've gone astray.
 
  So I searched 21.21.13.4201 on Microsoft's Update Catalog and got over a THOUSAND matches for one driver!  Maybe some are just different pointers to duplicate files, but I dunno, I looked at half a dozen, and while they were of similar sizes, each had a different set of INF files.  We might be looking at THOUSANDS OF PETABYTES of wasted space on that server!
 
  Anyhow, I decided to look at one that had three dozen INF files, so it has several different treatments for any one specific card.  I looked for an INF file that was short, relative to the the size of the [Strings] group, meaning the addreg groups would be fairly concise.  I found one that has 26 cards I can choose for "emulation", yet the addreg groups contain very little that looks "foriegn" to me, vs the 309.08 driver which is working.  For instance it doesn't have any of the "transforms" that take up a lot of space in the [nv_miscBase_addreg...] groups in Pieter's 342.01 mod, and it  doesn't have the "paneXXX" system you see in many other 342.01 INF files. 
 
  I could only find a few glaring differences between nvdmi.inf from 309.08 vs. nvmiwu.inf from 342.01 20966874_316b0dd6e70e6850097029320a77cf183dbae81d.cab as follows:

- There are no [IncludedSubPackages...] groups in 309.08 (neither nvdmi.inf nor nv_dispi.inf).  Could those files be "hurting" my old card?
 
- The [nv_miscBase_addreg...] sections are generally shorter in nvmiwu.inf, but 01 through 06 contain this line:
HKLM,"Software\NVIDIA Corporation\Global\NVTweak",NvCplEnableAdvancedTimingPage,%REG_DWORD%,0x0
nowhere to be found in nvdmi.inf (nor in nv_dispi.inf).  The vast majority in nvmiwu do NOT contain this.
 
- Does my old card REQUIRE some of the missing settings, such as PanScanSelection...2, RmEnableAcpiRom or PMMClockClone?  Several like this are in all the [nv_miscBase_addreg...] groups in nvdmi.inf, but don't exist in nvmiwu.inf .
 
- Apparently not, because NONE of these extra settings occur in nv_dispi.inf in 309.08, and that worked fine, and also supports the desktop 7900 GS.  (The [nv_miscBase_addreg...] groups are SHORTEST in nv_dispi.inf .)
 
- [nv_opengl_addreg] is longer in nvmiwu.  I assume it needs the extra settings because of a more advanced OpenGL version in the newer driver.
 
- Might be a good idea to take the one line in [nv_timingRestrictions_addreg] of 309.08, missing in 342.01, and add it in.
 
  Based on that analysis, I decided on this plan of attack:
 
- Use nvmiwu.inf.  Put in the Go 7900 GS string and ID, associated with Section001, 002, 003, and 004, for amd64.6.0, 6.1, 6.2, and 6.3, as these are associated with the primitive 8400M GS here.  (I figure emulating a "simple" card -- few cores, small VRAM etc. -- will give my Go 7900 GS less cause to complain.)

- If those four don't work, try 9, 10, 11, 12, as associated with the 9800M GS, which is a little closer to my card in capability.
 
- If no luck thus far, try commenting out the 12 [IncludedSubPackages...] groups.  Check for other occurrences of the files in those group.  (Nope -- no pitfalls there.)
 
- If still no luck, try removing this line in the 6 pertinent [nv_miscBase_addreg...] groups, with and without [IncludedSubPackages...]:
HKLM,"Software\NVIDIA Corporation\Global\NVTweak",NvCplEnableAdvancedTimingPage,%REG_DWORD%,0x0
 
- Try copying following the line into [nv_timingRestrictions_addreg] :
HKR,,NV_R&T,%REG_SZ_APPEND%,"R&T0000=-*,721-1079,*,*,*,MEL31C4,NONE"
 
  After doing several of these in haphazard fashion, I wrote out a binary chart of the 16 possible combinations, and tried them all:
 
1, 2, 3, 4    [IncludedSubP    AdvTimingPage line    721-1079 line   X
1, 2, 3, 4    [IncludedSubP    AdvTimingPage line  no721-1079 line   X
1, 2, 3, 4    [IncludedSubP  noAdvTimingPage line    721-1079 line   X
1, 2, 3, 4    [IncludedSubP  noAdvTimingPage line  no721-1079 line   X
1, 2, 3, 4  no[IncludedSubP    AdvTimingPage line    721-1079 line   X
1, 2, 3, 4  no[IncludedSubP    AdvTimingPage line  no721-1079 line   X
1, 2, 3, 4  no[IncludedSubP  noAdvTimingPage line    721-1079 line   X
1, 2, 3, 4  no[IncludedSubP  noAdvTimingPage line  no721-1079 line   X
9,10,11,12    [IncludedSubP    AdvTimingPage line    721-1079 line   X
9,10,11,12    [IncludedSubP    AdvTimingPage line  no721-1079 line   X
9,10,11,12    [IncludedSubP  noAdvTimingPage line    721-1079 line   X
9,10,11,12    [IncludedSubP  noAdvTimingPage line  no721-1079 line   X
9,10,11,12  no[IncludedSubP    AdvTimingPage line    721-1079 line   X
9,10,11,12  no[IncludedSubP    AdvTimingPage line  no721-1079 line   X
9,10,11,12  no[IncludedSubP  noAdvTimingPage line    721-1079 line   X
9,10,11,12  no[IncludedSubP  noAdvTimingPage line  no721-1079 line   X
 
  Each X in the chart means a code 43 result.  There were no missing files or invalid section errors.  I generally used the setup.exe program, but a few times I tried the manual force-feed through Device Manager.  I also used the DDU "Device Driver Uninstallation" program from Safe Mode a few times.   Since I'm overwriting the same driver each time, the "clean install" from setup.exe should be just as good.  And it didn't seem to make any difference.
 
- Then I decided to copy the entire [nv_miscBase_addreg...] group from nv_dispi.inf into nvmiwu.inf .
  - I Left in the 721-1079 line -- I don't think it can hurt anything.
  - I tried the remaining 4 combos with the [nv_miscBase_addreg...] group copied over.  I just copied 001 over to 001, 002, 003 and 004 -- the four involved with Sections 1, 2, 3, 4 and 9, 10 11 12.  No need to chart the AdvTimingPage line -- no longer a factor.

  1, 2, 3, 4  no[IncludedSubP   X
  9, 10,11,12 no[IncludedSubP   X
  1, 2, 3, 4    [IncludedSubP   X
  9, 10,11,12   [IncludedSubP   X
 
  Again, these are all code 43's.  I'm about out of ideas.
 
- A last desperate attempt might be to mod the [nv_opengl_addreg] group, but that would probably require the updated OpenGL DLLs to be replaced by the old ones, and that isn't exactly in the spirit of INF file modding.  And it makes any potential performance boost even more remote. I'll have to sleep on that...
 
  But I think I can say with 90+% probability that nVidia's statement about the legacy status of group 7 and earlier cards, starting with the 310 series, has real teeth.  The later statement, about 343 and above. was redundant -- typical result of "programming by committee."
 
  There may be a hard coded chart of ROM entry points for series 7, and another for series 6 etc., that was simply dropped after 309.08 .
 

Share this post


Link to post
Share on other sites
OlGeezer

  Huston, we may have a problem.  😞  I tried swapping in some individual files, and small groups of files (such as nvapi.dl_ , nvapi64.dl_ , nvencodeapi.dl_  and nvencodeapi64.dl_) over from 309.08 .  Got my head handed to me, but at least I didn't fry the computer (yet).  So then I copied some version numbers from this site and elsewhere...

Some driver version numbers:
300.99 --  8.17.13.0099
302.80 --  9.18.13.0280
309.08 --  9.18.13.0908
340.43 --  9.18.13.4043
340.46 --  9.18.13.4046
340.52 --  9.18.13.4052
340.62 --  9.18.13.4062
340.65 --  9.18.13.4065
340.66 --  9.18.13.4066
340.76 --  9.18.13.4076
340.82 --  9.18.13.4082
340.84 --  9.18.13.4084
341.05 --  9.18.13.4105
341.21 --  9.18.13.4121
341.95 --  9.18.13.4195
341.98 --  9.18.13.4198
342.01 -- 21.21.13.4201
344.00 --  9.18.13.4400
344.11 --  9.18.13.4411
344.48 -- -9.18.13.4448
344.80 --  9.18.13.4480
347.09 --  9.18.13.4709
354.74 -- 10.18.13.5474
359.57 -- 10.18.13.5937
361.43 -- 10.18.13.6143
364.51 -- 10.18.13.6451
368.71 -- 10.18.13.6871
372.70 -- 21.21.13.7270
387.92 -- 23.21.13.8792
397.51 -- 24.21.13.9751
 

  Somehow, 342.01 jumps out as something not to try, if the object is to rehabilitate old hardware.  341.98 was written over a year after Win10 was released.  I may have to give that a shot  before I give up.  Hell, I've come THIS far ...

OG

 

Share this post


Link to post
Share on other sites
zipper

I suppose it's a legacy driver for NVIDIA GeForce 8600M GT,NVIDIA GeForce 8700M GT,NVIDIA GeForce 9800M GT,NVIDIA GeForce 8800M GTX,NVIDIA Quadro FX 3600M etc.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×