• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

How To: Enable SLI on pre-i7/i5 hardware

im alittle confused ...

im on win7 32bit , i was playing around with the dstd table , but i cant find the correct place to inject the slic and the rest of the code.

And assuming i pached the dstd , do i need a modified driver ? or just install a normal driver ?

is somone working on a guide ?

is it possible on win7 32bit ?

can somone help me out ?
 
Yes, you'll still need a modified driver. You'll also need the SLIC string that you put into your DSDT table to read that it's an ASUS board. Send me a PM with an email, and I'll send you the driver.

I'm still working on making the driver easier to install, but with a little work, it's currently possible under every current OS (except for XP 64 bit and Server 2003). TiN made a guide, but it's in Russian. If you read back through the thread a few pages, you should be able to get some answers. Feel free to ask questions though, we're willing to help out.

On Vista, you also need to disable diver signing (http://www.killertechtips.com/2009/05/05/disable-driver-signing-windows-7/) since the driver is modified. Eventually, there may be a way around this (and just load the WHQL driver).
 
if we get the BIOS modders over at MDL in on this, couldnt they patch a BIOS to read as if it were x58 for SLI purposes, yet still work with its original drivers?
 
Mussels said:
if we get the BIOS modders over at MDL in on this, couldnt they patch a BIOS to read as if it were x58 for SLI purposes, yet still work with its original drivers?
Click to expand...

Yen, from MDL, is actually taking a look. Hopefully he's interested, and can do something with it
 
To be honest, I'm not sure if the hardware ID is stored in the BIOS or not... If so, that'd be a really easy thing to change. It might cause some odd compatibility problems though.

The driver uses a function that tells windows to "ask" the device what its ID is (I think). Whether or not that's stored in the BIOS or the chipset, I'm not sure.
 
sveetsnelda said:
To be honest, I'm not sure if the hardware ID is stored in the BIOS or not... If so, that'd be a really easy thing to change. It might cause some odd compatibility problems though.

The driver uses a function that tells windows to "ask" the device what its ID is (I think). Whether or not that's stored in the BIOS or the chipset, I'm not sure.
Click to expand...

The BIOS carries SLIC tables. That's how OEM copies of Vista/7 activate on Dells and HP's and such.
 
I understand that part very well, but it takes more than just adding the SLIC string and method to get it to work (unless we're not talking about the same thing). Someone mentioned modding the BIOS to change the hardware ID of the MB chipset. Modding the bios to have a different DSDT table should be pretty easy. The Hackintosh guys have been doing this for quite some time.
 
sveetsnelda said:
Once you've done all that, install the 190.62 drivers. After they are done installing, run a command prompt and copy the file I sent you (after unpacking it) to C:\windows\system32\drivers (overwrite the old driver)

Run the Driver Signature Enforcement Overrider
(http://www.ngohq.com/home.php?page=dseo)

Select "Sign a System File"
type in C:\windows\system32\drivers\nvlddmkm.sys

Reboot, and enable SLI.

:D

(Make sure you are using an ASUS SLIC)
Click to expand...

Should there have been a old driver to overwrite?
Wasn't a nvlddmkm.sys in C:\windows\system32\drivers\ when I copied it there.
You also didn't say if I should enable test mode when I ran dseo13b.exe.
I did choose to enable test mode, so I hope that was correct?
 
Test mode would have already been enabled if you ran the bcdedit commands I posted (I posted a link to a page that shows you how to do it). Picking "test mode" in DSEO wont hurt though... It'll just do the same thing again.

There should have been an old driver to overwrite. It wont show up in Windows Explorer, but you'll see it in the command prompt.

Did you disable UAC? Did you sign the driver (with DSEO)?
 
If the driver doesn't load at all (you can't even get to the Nvidia control panel), you've got a problem with just getting the driver to load in the first place.

If the driver loads (and you've verified that the file in C:\windows\system32\drivers is actually the *modified* one) but you can't enable SLI, you have a problem with your SLIC string.

If you want to temporarily disable all of the signing checks so you can troubleshoot further, you can push F8 before windows loads and choose "Disable driver signature enforcement" and see if it loads.
 
sveetsnelda said:
Test mode would have already been enabled if you ran the bcdedit commands I posted (I posted a link to a page that shows you how to do it). Picking "test mode" in DSEO wont hurt though... It'll just do the same thing again.

There should have been an old driver to overwrite. It wont show up in Windows Explorer, but you'll see it in the command prompt.

Did you disable UAC? Did you sign the driver (with DSEO)?
Click to expand...

Oh ok I had already ran bcdedit. copying the file over to the fold may have been the problem then since I used TOTAL COMMANDER to copy the file into the folder.

If you want to temporarily disable all of the signing checks so you can troubleshoot further, you can push F8 before windows loads and choose "Disable driver signature enforcement" and see if it loads.
Click to expand...

I'll give the F8 a quick try to see if the correct driver is loading.
 
i recall something about driver signing that may help.


You can sign your own drivers for free, they just dont get recognised - but there was a manual method to adding accepted signatures to the OS.

I cant recall specifics, but it may help you guys locate it.
 
After talking to him in PM, it sounds like he was just having a hard time copying the driver and having it "stay" afterwards (Vista likes to overwrite it with the signed version from the driver cache). I think he's just about got it.
 
I learned a lesson, DON'T take short cuts.
The short cut copy of the driver was the problem.
So you others take note.. lol

Screen shot to follow...
 
TheWolf said:
I was thinking you was working on or done with the hal.dll for 64bit.
Click to expand...

I'm still working. I already got how to inject code to the certified driver. Now i'm writing code which is intended to inject. Actually I already injected code and test, hal.dll works. I did hook of HalGetBusDataByOffset, but there is no check for bus=0 and slotnumber=0 yet. And on it i'm working
 
Windows 7 64bit SLI enabled.

SLI-W7-64bit.gif
 
how do you plan on handling the multiple hal.dll versions that are out there?

afaik windows xp ships with several ones and only one is installed. right click -> properties -> original filename to see which file you are using

w7 has several hal.dll's with similar names, any idea if all of those have to be patched?
 
W1zzard said:
how do you plan on handling the multiple hal.dll versions that are out there?

afaik windows xp ships with several ones and only one is installed. right click -> properties -> original filename to see which file you are using

w7 has several hal.dll's with similar names, any idea if all of those have to be patched?
Click to expand...

if i remember correctly the drivers come with their own version or at anyrate only access one spacific file. in which case that will be the only one needing modification.
 
are you saying that a modded uni processor hal.dll should just be copied over a smp acpi hal.dll ?
 
You must log in or register to reply here.
Back
Top