AdvModDev

0D is Controller and 1B is Bus...according to hasw. I used his 8rdavcore (the latest development version) to find the registers. If you change the Controller setting in any post-1/21 BIOS, this value should be the same as what 8rdavcore shows as well as 0D in WPCREDIT. None of the Oskar BIOS has a Bus Latency setting. To confirm whether tictacs tweaker app is setting the correct register value, compare with hasw and 1B in WPCREDIT. @tictac: good work buddy

I tried that already...spent several hours trying to get this board back but it's dead. All I could do was salvage the BIOS chip, jumpers, DIMM slot handles, battery, and throw the rest in the trash. Christ, I spent so much time and energy modding and tweaking this board (the GF swore I took better care of this board than her ) I still can't believe my utter stupidity. Now, I'm trying to decide whether I should use my laptop until 939/64 prices drop, buy another Infinity, go back to Abit, or try something new like the Albatron.

Sorry Tictac...I won't be able to help you because my mobo has died:( I was trying to solve my high Vcore instability problem and decided to remove my Vcore mod. Well, in my haste and frustration, I did not do the sensible thing and desolder but instead just ripped out the wire from Pin 7. This was a big mistake because also ripped the pin's base pad completely off the board. I tried to solder everything back but it was useless. Had a lot of good and bad times with this board. Guess I'll just use my laptop until 64/939 drop in prices. Good luck with your tweaker app. I'm sure uwackme, SAE, and others are perfectly capable of helping you out. Later DFI, it was nice.

I also have a UI that suffers from peripheral drops and this is pretty much what happens when the LAN dies. But sometimes the LAN drops are immediately followed by the OS completely hard-locking, with no way of checking device manager or doing anything except killling power. BIOS 6/19 is especially prone to these drops and is the reason I can't use it. Similiar to mong (and many others), BIOS 1/21 is the cure. Because 1/21 works and others do not, one can conclude that the problem is BIOS - related. The problem is not ROMSIP, heat, voltage, driver, settings, or hardware related. The culprit is the BIOS. Otherwise, with all else being equal, why does using 1/21 "magically" eliminate the problem? mong, the 1/21 RS inserted into the 6/19 BIOS will not solve our problem. I have tried to do this with 4/29 and 5/5 and while it seemed to lessen the frequency, the drops still occurred. One guy at XS PMed me about a 6/19 w/ 1/21 RS. I thought if it didn't work before why would it work now. But I did it anyway because 6/19's RS structure (but not size) is more similar to the old-style RSes then either 4/29 or 5/5. In fact, the method I used was the exact same method as Hellfire is using (modding Tables 5-12 in the 6/19 RS alternately with Table 5-6 in the 1/21 RS). This is the most logical way to do it with respect to the old structure of pre-4/29 RSes and the new structure of the 6/19 RS. But the result produced no change because, again, the problem is not RS-related. RGone, I think Oskar was suggesting that the cold boot = no post bug might have been RS-related. And some testers requested that the 1/21 BIOS should be implemented with the fix. However, if the RS is responsible, then it cannot be inserted into the 1/21 BIOS (probably) due to the size difference. Now whether or not the 6/19 (or 4/29 or 5/5) BIOS can truly accept an RS from a pre-4/29 BIOS can only be answered by Oskar. As you know, I have always doubted whether it could be done. Again, the 4/29 RS and the 5/5 RS are totally different in size and structure than any other. But the 6/19 RS is now very similar to the pre-429 RSes with respect to the first and last 4 Tables in the structure. So modding the 6/19 RS could very possibly be more "valid" than either the 4/29 or 5/5. But having said that, there still is the uncertainty of the 8 additional tables in the 6/19 RS that prevent a "good fit". Perhaps it can be better explained this way: 1/21 ROMSIP (or any pre-429 RS) Table 1 ABC Table 2 DEF Table 3 GHI Table 4 JKL Table 5 MNO (1) Table 6 PQR (1) Table 7 ABC Table 8 DEF Table 9 GHI Table 10 JKL 6/19 ROMSIP (or any post-429 RS) Table 1 ABC Table 2 DEF Table 3 GHI Table 4 JKL Table 5 MNO (1) Table 6 PQR (1) Table 7 MNO (1) Table 8 PQR (2) Table 9 MNO (3) Table 10 PQR (3) Table 11 MNO (4) Table 12 PQR (4) Table 13 ABC Table 14 DEF Table 15 GHI Table 16 JKL Hope that makes it clear what's going on. What Hellfire has done is taken Tables 5-6 from the (12/18 and 1/31) RS and inserted them alternately into Tables 5-12 of the 6/19 RS. This seems like the logical thing to do since it looks like Oskar just expanded that middle section. But if one takes a closer look, Tables 5-12 in the orginal 6/19 RS are not the same alternating Tables. There is a single bit value change when going from Tables 5-6 to 7-8 to 9-10, etc. What this bit value is supposed to identify, I don't have a clue. But apparently it has no adverse affects, since soundx98 and others are having no problems. The truth is only Oskar can enlighten us about what is going on and either refute or verify. But I suspect he's under NDA with NV.

tictac, sorry for the late reply...of course I will help you out. But my system is totally disassembled at the moment...had to reinstall my loop, accidentally knocked out my Vdimm mod, long story. Anyways, I should have the time to get everything back to gether today and will find those mem settings in the next couple of days. BTW, the "NF2 Tweaker" app is a great idea...especially for those who are "WPCR - challenged". WPCR is definitely not user-friendly...I was planning on posting a guide on how to use WPCRSET w/ pics...hehehehe. Anyways, for best functionality, your NF2 Tweaker should also be able to Save and Load at startup (like WPCRSET).

cantank, "CPU Disconnect" has always been enabled by default on every single Oskar BIOS. Some of them use 1F and some use 9F. Like tictac said, either one will work...but nvidia has recommended that 9F be used with the NF2 Ultra 400 chips. You might also want to read up on "Tromoto's Halt Fix" thread concering the time out value. I'll see if I can dig it up but if you're using BIOS 6/19, then the fix has already been implemented. Concerning PCI Latency, listen to RGone. Concerning ISA ROMs, I don't know man. This makes the tweaks rather permanant...quite a hassle. Why not use just use WPCRSET?

Greets tictac. I was planning on tackling the Alpha mem settings next but you worked it out alread. Saves me alot of reboots...thanks;) I do see one error -> AGP Latency. Neither AGP Controller Latency nor AGP Bus Latency are accessed via Bus 2, Dev 0, Func 0 (VGA Compatible Device). These latencies are actually accessed via Bus 0, Dev 30, Func 0 (PCI-PCI Bridge).

You're right uwackme, Abit was the one who leaked them and they're newer than the ones that were originally found. Abit's version is 442 and is WHQL. The ones found before were version 435 and don't know if they're WHQL or not. I edited my post to link to the newest from Abit. Note: a lot of the other drivers in Abit's 5.03 package are older than the package from OCW. So basically just take the audio folders from Abit and put them into OCW's package and you'll have all the latest leaked goodies:D

You sure it wasn't the 1/21 release notes you were looking at Viper? I'm certain that 1/21 is the only one that defaults AGP Latency to FF.

Some more good news...a couple guys over at nforcers found the new audio drivers that OCW did not include. They are actually "leaked by Abit". Audio Drivers and NVmixer v4.42 ftp://ftp.abit.com.tw/pub/download/driver....03_win2kxp.exe Shout out to Frazor, Jahara, and MaD at nforcers. Enjoy!

The good folks at OCW have leaked some new drivers for all to try: http://www.ocworkbench.com/downloads/NFref_440.zip Password to unzip package: ocworkbench rules GART v4.4.0 Ethernet v4.4.0 Memory Controller v4.4.0 SMBus v4.4.0 IDE v4.4.5 (v2.6) Thanks to WinterX, garikfox, and Bucephallus at nforcers for giving the heads up. Enjoy! Edit: the link may be slow (understandably), try later if it is.

Here are a couple WPCREDIT/WPCRSET register tweaks (these may be helpful for those using a BIOS that doesn't have these options): AGP Controller Latency Bus 0, Device 30, Function 0 Offset (Register) 0D AGP Bus Latency Bus 0, Device 30, Function 0 Offset (Register) 1B PCI Latency Bus 0, Device 8, Function 0 Offset (Register) 1B Here are some data (values) that can be set: 16 (clocks) = 10 (data) 32 = 20 this is the default for every BIOS except 1/21 64 = 40 96 = 60 128 = 80 160 = A0 192 = C0 224 = E0 255 = FF default AGP Controller Latency for BIOS 1/21 Note: if you set AGP Bus Latency to 128 clocks or higher, it is advisable to leave PCI Latency at the default 32 clocks.

I always thought the China plant was only responsible for end assembly of DIMM, AGP, and other slots. But the primary reason for China boards at all was cheaper overall production costs. @SAE: maybe the color is irrelevant? Have you meausured them?

The problem with your method is that you have altered the "Voltage.ini" file directly. This file would be overwritten everytime a reinstall or update to a newer version of MBM took place and you would lose your mods. This is why you should take your block of code and put it into your "Voltage custom.ini" file - MBM will never overwrite this file. Also, I noticed you changed the compensation multiplier for the 3.3, 5, and +12 rails to suit your system. That's fine but this may not be valid (accurate) for other people's systems. This is why I left my "custom" code the same as the "standard" code (with the exception of the -12) so people can decide what works for them.

I totally agree but to get accurate readings will also require advanced measurement tools. We (who are not EEs) will have to settle for less accuracy.