I.nfraR.ed

APIC off is a little more stable at high FSB and voltages for me, especially with high CPU voltage. I'm running APIC off and SSD connected to the integrated SATA on my NF7 with the images I've posted on your forum. Haven't noticed a negative effect by turning APIC off, but SATA SSD might make a difference, haven't tested. I'm currently testing the modded NF7 bios (NF7_[ED]_A6, I believe) from @digitalbath and it seems faster than mine, but it also requires a bump in VDD (chipset voltage), but I'm down to 38 27.xxx. So it seems ED is one of the fastest overall, allowing a good FSB as well. With my tweaked ROMSIP values it now runs on the lower VDD, but it would also be a little slower. These are the current ROMSIP values I'm using for 260MHz and tight BH-5 timings. It's a little bit slower, but not much, while allowing the run to complete. No 32M at 260MHz yet, though. PS: I don't see a dramatic difference in aida numbers, except Write speeds. But even with similar aida numbers one ROMSIP can be much faster that another one. We're probably hitting some nForce2 throughput, that's why aida shows similar numbers with many of the ROMSIP tables. Pi 32M tells a different story, though.

I have experienced the crash myself and it seems to sometimes happen if you try to open the app immediately after boot. It's not related to reading timings, because I've tried without reading anything, it's related to loading and compiling the .net code to native. Maybe something is not completely ready after boot and there's some conflicting code that crashes the system. Maybe I need to have some check in place, but I don't have an idea about it. It is not that light as a native program, but can't avoid it at the moment. It only happens on first start after a fresh boot, because .net framework compiles it once. Subsequent app launches are then faster and lighter to the system. That's how .net works. There's a workaround - I can provide a mechanism to "install" that compiled native code in the cache, but this means I will have to make sure every new version of the app uninstalls it and installs the new one. If something crashes there are additional troubles.

First beta is up. Everything should be functional, except profiles and items in the File menu. Latencies are now the same as in other apps, but I will have to check more boards. I'm not convinced the current mapping is right. Will work on profiles next. Had some issues with the latencies, since they are not in device #0 and write command was not working, so I had to rewrite a big part of the application and switch to other method. Don't mind the broken second image. My windows XP is really broken from some time - chkdsk is running every boot. The XP-M 2500+ I'm using is also the worst one - this is my test cpu used to check motherboards fro function and installing XP. Update: Uploaded a new version today (26 April). I've removed disabling of settings for empty slots, because it seems they get detected differently on the DFI and there's a chance you get a populated slot disabled in the app. Rendering glitch on first startup should be finally fixed. nForce2XT_1.0_beta_20200426.zip

It should be 0C for the AGP Controller, since I'm always reading in DWORDs (4x8 bytes, 32bits). That's how they write registers in the official documents as well. So everything in [0F:0C] range - 1st line, last column in rweverything/wpcredit in DWORD mode, is the 32bit register starting from 0xC offset. dword = double word = uint 32bit (unsigned int). 0xC, bit 0 is the least significant bit in the 32bit register. I've checked another tool - PCI Latency Tool and it lists AGP Controller Latency in the same 0xC [15:8] - 0xD portion (2nd byte) of the register, but in b2/d0/f0 - VGA Controller. So which tool/bios is right, I'm even more confused.

I need a little help. Checking several apps and comparing with bios. According to nf2Tweaker and 8rdavcore, PCI Latency Timer is b0/d8/f0 offset 18h [31:24], although only [31:27] bits can be changed According to bios, the setting changes register b0/d1E/f0 offset 0Ch [15:8] which is AGP Controller Latency according to the other 2 apps. Could you check on Asus which register is changed?

Two variants with tabs and everything in one page. Don't mind the reverse order of some of the timings timings on the first one, they somehow switched places. As a good news, I've solved the glitch in the rendering. It now waits until the whole layout is ready. I've also added a splash screen to show until main window pops up. I'm leaning towards the first version with tabs, although it is a little more complicated, since I'll have to check which tab is selected on Apply. Might have the rest of the controls working today.

Yes, I'm thinking the original idea with 2 tabs might be a better one. Perhaps it won't hurt if the chipset settings (without ROMSIP presets) is moved to the second tab. That would save some vertical space and keep things more compact. I could probably put the romsip offset labels next to each text input, saving another line, although current one looks cleaner. Another idea I had is to change all boolean settings to on/off, instead of Enabled/Disabled, which will allow to reduce dropdown width. There are 2 exceptions though - Burst Mode and Drive Strength Mode. As you have put the columns, I can shorten the dropdowns to the default width in the second one, since they are only 2 digits. Tref is the only setting in the first one that requires 4 digits, otherwise I could shrink first column even more. I've created a discord channel to make communication easier, if anyone wants to share thoughts: https://discord.gg/hYQjbG5

Most of the things are already working. Disabled items are read only or not implemented yet, but getting there. DLL item seems to be unchangeable and I'm not 100% sure how it works anyway. A64 Tweaker has it, but I've never used it. Other things seem to work ok - at least they are set successfully. Adding more components made the app slower with the initial load. You might see dropdowns not fully initialized on app open, since they are all custom components. I've externalized the custom components in a separate dll and also tried to reduce memory footprint - from 14MB down to ~7MB. The plan is to also add several options to exclude things from the interface, e.g. leave just primary timings if someone doesn't want the advanced settings. If I remove DLL item, then there will be 2 empty rows in the right column, so maybe I can move something else there? It barely fits 1024x768 screen now on the vertical, but I can't really optimize the space much more than what I have currently. PS: I'm not really sure about Data Scavenged Rate, have to check on the DFI board again - might have it reversed. Not sure if Burst Mode makes sense, too. I would think you want it set to "Interleave" all the times and that seem to be the default option. nForce2XT_Debug_20200419.zip

Unfortunately I haven't found any other method that works currently. I have a 240GE here, which is basically the same thing. Although you can change P0 I don't think you're using the new frequency. Have you monitored it under load? The only method I know is to reduce DID of P0 and adjust FID and VID accordingly. This allows you to go above turbo frequency, but also makes P1 and P2 useless. Example 1 - Fresh boot, stock P-States. I've adjusted P0 FID to set target frequency of 3725MHz. Although P0 changes are programmed successfully, the state is not respected. Maximum voltage is around ~1.1V and frequency doesn't go higher than stock 3500. 1.1V is the generic VID of Zen. Example 2 - P0 is changed, but this time I've dropped DID below stock, which forces some sort of a OC mode. You can now set FID and VID to desired values and overclock it as high as your CPU and cooling allows you. Once entering this state, there's no going back, you have to restart to get P1 and P2 working again. This time P0 is respected, but the CPU stays close to that P0 parameters - mine goes down to 3.6GHz when not loaded, but that's it. Screenshot is done under load. When idling the power consumption looks to be ok and unused CPU cores are probably sleeping, so that might be a good enough method, although monitoring programs still read full vCore.

Yes, that's what I'm thinking - placing everything on a single page. Will probably move the alpha timings beneath the main ones and use the second column for the rest of the options. The options I plan to include: Drive Strength A, Drive Strength B, Slew Rate, for each DIMM DLL [Enabled/Disabled] Burst Mode [Sequential/Interleave] Drive Strength Mode [Normal/Weak] Super Bypass Data Scavenged Rate AGP/PCI Latencies AGP Fast Write Romsip registers Not sure all of them make sense or work, but want to try anyway. Do you think 2 separate drive strengths per dimm makes sense or to include just one setting for both?

First usable version. It's still a debug build, but you can use it for setting all the usual timings + tREF. I've disabled CAS and will remain that way, unless I found a reliable way to set it. No vendor and device check yet, so you can run even on your shiny new Ryzen under Windows 10 System requirement is .NET Framework 2.0. nForce2XT_Debug_20200416.zip

I've implemented a temp function which sets all these based on the selected CAS dropdown value and made some tests: Maybe we need a different sequence or set even more registers in order to make it work for all cases. Or it's just not possible. PS: 9Ah and F9h depend on the FSB as well.

Yes, I have the same values as you. Only 2.5 -> 2.0 worked. Offset 70 and 74 (dword) bit 13 in each is Half Latency toggle. A0, A8, B0 and B8 bits 6, 5 and 4 are CAS - nforce2 supports 4 DIMMs, but B8 gets ignored in most of the boards since it's not connected. There's at least one Gigabyte board with 4 memory slots, though.

CH sticks work with CAS3, BH are the ones that don't. I've tried to set 3.0 with a BH-5 stick and it didn't freeze. There's no difference in Pi, so I can probably only use it to detect current CAS. Changing CAS requires setting 3-4 other registers as well, I think. Will keep digging.

You can try if it reads correct timings. Currently I've only implemented read and refresh which re-reads the timings again. I'm mostly getting these by changing a value on a running system and detecting changes in rweverything. As for Command Rate I'm not 100% sure it is correct, have to check it on a DFI board. It's read-only anyway. Yes, 90-9F is some sort of a "sensor" - values go up and down. Perhaps some voltages readings. You can actually set vdd, vdimm and FID with 8rdacore app on the fly, since it has ATXP1 control implemented. PS: Btw, I'm able to change CAS on the fly! Not sure how effective it is, but at least cpuz detects the change. Debug.zip

Yes, I follow that thread on your forums We (me and @TerraRaptor) were commenting your progress behind the scenes . I've even tried your modded NF7 bios and it works, but didn't see a difference in maximum stable clocks with my setup. Currently working on "documenting" all known registers. Take a look if you want and report back if you see some errors. https://docs.google.com/spreadsheets/d/1ZDST3XGq0oE7YtQxAME29RtopA8QcePCaHa2NBRHaB8/edit?usp=sharing PS: Second table, reg 94, bits [2:0] could possibly be another timing, however it might be a reserved value. AFAIK I've tried it before and it didn't accept the changed value. Also uploaded the nf7 files to my github: https://github.com/irusanov/nForce2-bios-mod

A new tweaker coming into town ? Primary and secondary (alpha) timings read done. Will implement apply action soon. Every control reports if the value has changed and the Apply button would only set changed values.Those values are marked with yellow background. If the app reads a value (still in the defined range) that doesn't match any value in the dropdown, it will be automatically inserted in the list as a new option. For example - the default TREF on my board at 200MHz FSB seems to be 1562, while I only have a predefined 1560 in the dropdown list. Here's what I've planned DRAM primary and secondary timings drive strengths and slew rate per DIMM data scavenged rate, autoprecharge, superbypass, sync mode memory bypass Chipset AGP and PCI latencies, Side Band Addressing, CPU Disconnect, AGP Fastwrite Tweakable ROMSIP registers Profiles Predefined chipset profiles for different RAM ICs (same as @digitalbath's approach) Maybe some predefined profiles for DRAM timings as well Save/Load custom profiles Good to have SMBus control of the integrated nForce2 PLL - don't have experience there The Bad It will need .NET 2.0 framework and would have a little higher memory footprint than e.g. NF2Tweaker. Hit me with other ideas.

There's a syntax error thrown in console. You guys are using very outdated jQuery version (1.7 from 2011) when the current one is 3.4.1? I know there's no dev resource and this is a tedious task, because they are incompatible and many deprecated jQuery events need to be replaced. But all old versions have many known vulnerabilities and as you can see they stop working on modern browsers.

Never had a problem running CB20 on Windows 7.

Blind testing is not recommended, since it can kill the chip. You can run the SMU scanner from SMUDebug Tool though and save the report. Sorry for the late answer. Added a screenshot button to the ZenTimings app, per popular request. Download: ZenTimings v1.0.4 (Google Drive)

Great one. What is the difference between ambient and LN2 CPU?

You can try one of my tools. ZenStates: https://zenstates.protonrom.com/ SMUDebugTool: https://github.com/irusanov/SMUDebugTool/releases Due to the changes in firmware, you need to always set some values for the PBO limits. 0 was used as "auto" before, but it's now possible to set 0 as well. I'm not ready with the new version yet. You can also use SMUDebugTool if you only need to change the multiplier in OS. You can do almost everything with it, but it's all manual. First tab allows to set the multiplier easily though. It had been tested by the top US guys and it works.

Yes, I've tested half of these, but can't confirm them all, since I stopped testing. 14h, 23h and 27h seem in line with what I've found (just from memory, I might be wrong). I have changed most of them in wpcredit and the one with most impact was the 14h, but others need thorough testing as well.

Glad to see it is working! I'm going to update the main app, but no ETA.

I've tried the patcher before and have it in my archive, but I don't think it does anything interesting for our modded and newer bioses.