A7N8X-E Deluxe as an alternative for socket 462

[I.nfraR.ed]

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?

Edited April 17, 2020 by I.nfraR.ed

[digitalbath]

@InfraRed

Good job! I will use your latest version for my tests. I would like to see two seperate drive strength per dimm (if there is enough room for it). I don't think it will change our overclocking ability that much. But it is nice to have.

 

@Tzk

something like this? ?

still testing though. I will try get a higher result.

Edited April 18, 2020 by digitalbath

[I.nfraR.ed]

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

Edited April 19, 2020 by I.nfraR.ed

[Tzk]

I see where your issue lies.. I just tried to use 3 columns, but that just doesn't work out... Here's my paint.exe mockup. I'd rather not do it like this... but the window at least has a bit less height.

[I.nfraR.ed]

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

Edited April 19, 2020 by I.nfraR.ed

[subaruwrc]

every time I read in this topic, I feel my whole OC knowledge is equal to a potato. sickest thread ever !  

[digitalbath]

I tried also to make a mockup with paint. I am not sure if this is possible. Dividing romsips in two parts maybe helps to get them in the second column? Using two tabs (one for DRAM timings, one for chipset) should be not a problem for me.

[I.nfraR.ed]

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.

 

    

Edited April 20, 2020 by I.nfraR.ed

[cbjaust]

compact with tabs looks the goods.

[digitalbath]

I vote for the compact one. ?

[Tzk]

+1 for the one with tabs. As long as all memory timings are shown on a single page everythings fine. I like it!

[I.nfraR.ed]

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?

Edited April 23, 2020 by I.nfraR.ed

[digitalbath]

I checked it on my A7N8X-E. It has no options for PCI Latency or AGP controller Lantency in its BIOS. My Delta2 neither.

Using nf2tweaker and 8rdvacore, the PCI Latency should be in b0/d8/f0 (as you already figured it out), offset 18h [bits 27:31]. Every change in bits [24:26] and it resets. So it is only possible to set it in steps of 16 (10=16; 20=32; 30=48; 40=64...)

AGP Controller Latency should be in b0/d1E/f0 offset 0Dh? [bits 8:15].

AGP Bus Latency should be in b0/d1E/f0 18h

 

I'm sorry, i have no other way to help you as using the same tools. It seems that you are on the right way...

[I.nfraR.ed]

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.

Edited April 23, 2020 by I.nfraR.ed

[alexmaj467]

Sorry for my English.

You all do a great job. I have a hope this year to get to socket 462, and select the accumulated processors and can take 280 over the bus.

[digitalbath]

@I.nfraR.ed

Now, i've got it. You're right.? You meant with 0Ch the start of the 32bit register. [8:15] is the 0Dh part.

On my ASUS A7N8X-E VGA controller is b3/d0/f0; nf2tweaker changes nothing here.

Edited April 23, 2020 by digitalbath

[I.nfraR.ed]

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

Edited April 26, 2020 by I.nfraR.ed

[Tzk]

I just tried the newest Tweaker and it crashes on WinXP... Does it need any extra library the older build didn't need? 20200416 works, 20200426 doesn't. It shows the splash screen and that's it. Afterwards there's the usual crash screen by windows, nothing else.

Nevermind. Download was broken... It works as expected

Edited April 27, 2020 by Tzk

[I.nfraR.ed]

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.

[Tzk]

I believe it was not related to .net or your code. seemed like the download itself (or the extracted files) were broken. i downloaded it another time and now it works flawlessly.

@digitalbath started to have a look at efficiency... I now get why you were so concerned about that with the romsip tweaks... Seems like his DDED romsips are very loose, which results in a 10-20sec penalty on 32M. That's a huge loss! We chose 9x240 and a barton cpu as test setup, because every romsip and almost any barton should be able to run at that speed on aircooling. Interestingly my system is a lot faster per clock...  (his 32M: 39m 38s, mine: 39m 21s)

Have you compared APIC on/off and using the SIL SATA controller vs. a IDE/sata converter on the IDE ports? Is there any difference in performance? I'm running APIC on and IDE hdd.

Besides that we're running exact same settings. Both Bartons, both 2x256mb Infineon 6A, same Romsips, same BPL, identical clocks.

Edited April 27, 2020 by Tzk

[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.

Edited April 27, 2020 by I.nfraR.ed

[digitalbath]

I will retest my benchmark results with a new Windows installation and a new harddrive. Maybe my results are more comparable then. A SSD drive should make a diffrence in my opinion.

Merlins [ED] romsips seems to be almost perfect to me. They are fast and with Interface optimal a good FSB is possible. I will give Mantarays 6/19XT for DFI Lanparty B a try. It should be faster than ED romsips. I haven't done a high FSB test yet.

 

Edited April 28, 2020 by digitalbath

[Tzk]

I'm currently testing my xp-m with L12 hardmod. Interestingly it performs differently when i set the L12 bridges to 166MHz. Even when the romsips are completely identical... And i don't get why. How big is the usual margin of error on 32M? I got a difference ofseveral seconds on my runs.

results: https://www.hardwareluxx.de/community/threads/amd-sockel-a-thread.584473/page-76#post-27462451

 

14 hours ago, I.nfraR.ed said:

No 32M at 260MHz yet, though.

I've been able to complete a 32M at 258MHz with Merlin EBED romsips. My board is not able to achieve that with ED romsips though. ED seems a little faster than EBED, but i lose about 3-5Mhz max. fsb. So i guess 253-255Mhz with ED sips is possible on my Asus. No way i could get this running at 260 as that'd require >1.9V VDD and better (probably below ambient) cooling on the nb. Watercooling doesn't seem to be enough for this or i need to lap the nb as it is nowhere near flat.

Here's the result: https://hwbot.org/submission/4249058_tzk_superpi___32m_athlon_xp_m_2600_(barton)_31min_45sec_984ms

Edited April 28, 2020 by Tzk

[Sparks.nl]

Quick reply to follow news in the thread.

[Antinomy]

That's some terrific job you've done. Took me a while to follow you studies. I'll check my disk - remember having some AMD NDAs that might help. One file is in archive - does anyone know a tool to crack password fast enough?

 

Oh, BTW - how about testing these regs for Multiplier-on-the-fly for Nforce2? Guess I'll put to keep all NF2 stuff in one place.

Quote

nVidia: nForce 2 (reg. E7, bit 4 = FID_Change Detect; reg. 6F, bit 4 = Halt Disconnect)

 

Edited May 19, 2020 by Antinomy