Hi Fernando,
I sincerely hope I did not miss something important to read on the forum. Actually I just would like to write something about what I have unsuccessfully been trying to do for many days (rather nights)… hoping it might help some others having the same idea / problem. Of course I also would be interested to have your opinion / confirmation about this. 
So I had the good idea to buy a brand new Intel SSD 530 Series drive, in the hope of seriously boosting my old XP SP3 running on an Asus A8N32-SLI Deluxe mainboard. Well after all the mess it caused I’m not sure I would do that again… but anyway.
2 main problems:
1) SSD performance limited to 125MB/s with the onboard controller(s) (NB: Silicon Image controller not a better option for both problems)
2) No TRIM support from any of the onboard controller drivers I could find so far.
1) Performance limitation: Of course it’s quite a joke given the fact that the board should support SATA 2 (3Gbit/s) :(( In short I tried every possible SATA (and RAID) driver to get a better performance but I had only BSOD and other nice experiences. AHCI? For sure not possible with this board, one reason being already that you cannot even enable it in the BIOS! Still I tried all I could but had finally to abandon this idea. The only driver which seems to work more or less ok is the legacy v6.99 one from your packages. But whatever the drive version, the sequential transfer performance is not changing at all, though the bus could clearly do (at least a little) better.
2) TRIM adventure: Forget about having a NVIDIA driver supporting the TRIM command (Intel Toolbox). I ended up having to manually force an MS XP legacy driver installation (the one coming with XP or a SP, v. 5.1.2600.5512). At least this old one is supporting that correctly. 
Finally I even tried the alternative way: buying an PCIe–SATA card with an ASMEDIA 1601 chipset. Apart of some pleasant BSOD from time to time with the latest driver version I could manage to find (what a big hassle on that one!!) e.g. v2.0.3.2, forget also about TRIM support! Still at least there the throughput increases a bit up to fantastic 185MB’s 
for the SSD (which of course could itself deliver probably up to 500MB’s).
I guess for all the hours I lost messing around like crazy (hundreds of reboots necessary) I should rather have kicked the board and the dual core CPU… 
As little end note: Don’t play around (like me) with the 32 bit transfer setting in the BIOS… 
It cost me 2 nights of horror trying to repair something with chkdsk ($I30 index stuff and “second NTFS boot sector is unwriteable”) which actually was not broken at all… Well that’s the risk when you try to tweak the performance on a sh**** old board I assume… 
@ BlueDragon:
Welcome at Win-RAID Forum and thanks for your detailed report.
I totally understand your frustrations regarding the performance you got with a comnbination of a very old nForce4 mainboard, which has only SATA2 ports and doesn’t support AHCI, with a good SATA3 supporting SSD.
That is clear, because Windows XP doesn’t send any TRIM commands to the on-board SATA Controllers.
Question:
Have you ever tried to run Win7 or Win8 using the generic MS IDE driver named PCIIDE.SYS?
I am pretty sure, that you would get a better SSD performance this way (and TRIM support).
What do you mean with "32 bit transfer setting in the BIOS"? Which BIOS settings/modules have you tried to change?
Regards
Fernando
32-bit Transfer Mode
This BIOS feature allows you to command the IDE controller to combine two 16-bit hard disk reads into a single 32-bit data transfer to the processor. This greatly improves the performance of the IDE controller as well as the PCI bus. Therefore, it is highly advisable to enable 32-bit Transfer Mode. If you disable it, data transfers from the IDE controller to the processor will only occur in 16-bits chunks.
32-bit mode with respect to IDE refers to transfers that occur over the PCI bus to the host system memory. PATA is limited to reading 16-bit chunks of data at a time from a drive. If you enable 32-bit mode, the controller will be set to temporarily store the data from one read until the data is available from the next read before mastering a transfer over PCI. So it can collapse two transactions on the IDE side of the controller to one transaction on the PCI side of the controller. SATA doesn’t require a mode like this. It could be said that it’s always running in 32-bit mode, I guess – basically SATA transfers data in serialized packets across the interface to the drive and the controller will just buffer the data until it has enough to send across the PCI bus. There is no need to enable this specifically with a SATA controller.
Sources:
http://www.dslreports.com/forum/r8057444…able-or-Disable-
http://hardforum.com/showthread.php?t=1287459
Thanks Fernando for your reply!
Well I’m not at all specialist in this TRIM story but I don’t think it has directly something to do with Windows XP OS. Actually it has rather to do with the IDE / SATA driver (which of course will support any OS or not) and as a matter of fact the native XP IDE driver atapi.sys (v. 5.1.2600.5512) does pass over the TRIM command. I have no way (no knowledge) how to actually verify if this is really happening, but in any case the Intel Toolbox is happy and behaves like if that would work correctly.
I never tried to install Win7 or Win8 but maybe I could try to get this pciide.sys driver from there and somehow force XP to use it, but I rather doubt that will be easily feasable…
BTW I wanted to add that first I connected my Intel SSD to a PCIe-SATA2 adapter with the ASMEDIA 1601 chipset. Besides the hassle to get a recent driver, finally it seemed not to work at all proberly with the v2.0.3.2 (most recent I could find "working"). The SSD is regularly freezing during a couple of sec the whole system and it’s a real nightmare. After I connected the SSD back to the onboard controller everything was fine again (but of course only with 125 MB/s instead of around 180MB/s with the ASMEDIA chipset). Other conventional SATA2/3 HDDs are working well with the PCIe-SATA though (up to around 145MB’s for a recent 2TB WD green drive).
Thanks plutomaniac for your post!
That was an interesting reading. In the sources you quoted I read that some said that a change from 16 bit (e.g. “not enabled” in BIOS) to 32 bit transfer would not create any problem. As a matter of fact it does create a huge problem, at least for 2TB drives formatted in NTFS!
So it remains a bit a mystery to me if really that does not impact the SATA performance?! If it’s not then at least it’s totally changing the way the controller accesses the filesystem on bigger drives. I guess that would be something to test live. But that means having to backup the whole 2TB partition, then change the BIOS setting to 32 bit and copy the whole backed up partition (or content) back. After that running a chkdsk would quickly show if it’s ok at filesystem level or not. Then a benchmark to check if there is a change of sequential reading performance. If I have nothing to do (and 2TB free space, which I actually do not have) I might give it a try… 
Hi,
Funny, I was looking for a BIOS mod enabling my Sabertooth Z77 to boot with an intel SSD750 NVME and found Fernando’s modified NF drivers.
Call it nostalgia but I still have two perfectly running PCs based on NF4 boards (DFI Lanparty NF4 SLI-DR and Asus A8N32-SLI Deluxe)
Based on my experience with these two boards your issue is that the SATA controller connects in SATA1 mode (1.5Gbit/s) and not SATA 2 (3Gbit/s).
This can partially deducted from your relatively low throughput which is in line with SATA1 performances
The issue is not depending on drivers or BIOS setup, the transmission mode is negotiated during the HW initialization process and is really depending on the controller of the SSD.
With the DFI Lanparty NF4 SLI-DR I had a similar experience with a Crucial m4 SSD (Marvell 88SS9174 -> negotiated interface mode is SATA 1) and a better luck with an Intel 320 SSD (negotiated interface SATA2).
However the Crucial m4 SSD connected in SATA2 mode with the Asus A8N32-SLI Deluxe but the NF4 chipset of the ASUS MB is not the same as the DFI (SL X16 vs SLI).
If I have time I will try to connect SSD from two other manufacturers (256GB Plextor M5 Pro (Marvell 88S9187) & SAMSUNG 840 Pro) and post results.
Note also that I unsuccessfully tried different BIOS but my guess is that the BIOS has no influence during the initial determination of the SATA mode.
I also tried to connect my SSDs via a SATA3 board (PCIe x4 SATA3/USB3 Asus U3S6). I never could start the DFI system with this extension card and I spent at least one week trying to debug the issue.
The card worked well with the Asus A8N32-SLI Deluxe and the reached speed was around 450MB/s but I switched back to NVidia SATA2 connector after two Crucial m4 mysteriously stopped working (exchange under warranty each time).
Since then (2012) the m4 in my Asus showed no issues.
From a practical point of view and as long as you do not have huge I/O tasks you won’t notice a difference between SATA3 and SATA2.
For fun reasons I’m actually trying to install Win 10 (x86) on my old the DFI PC but face many compatibility issues.
The system is now perfectly stable but I had to deactivate following option in the BIOS
• Ethernet NV
• RAID NV (SATA/IDE)
• AC97
• FDC
• IRDA
Because of the missing CompareExchange128 command my old systems DFI & ASUS with Athlon (FX-60) will never be able to support Win 10 (x64) so I will probably switch back to Win 7 (x86 and x64).
@Elchi :
Welcome at Win-RAID Forum and thanks for your contributiuon!
It woiuld be interesting to get your feedback after having tried my new NForce Driverpacks for Win7-10.
Regards
Dieter (alias Fernando)
Hi Fernando,
A little funny and quite unknown story not related to the NF4 drivers but related to the FX-60 and the NF4 chipset based ASUS A8N32-SLI Deluxe motherboards.
Just for the fun I recently upgraded my old Home Cinema computer based on a OC FX-60 ASUS A8N32-SLI Deluxe motherboard with 16GB of ECC registered DDR1 RAM !..yes 16GB with a 939 and a NF4 chipset!
A key point behind this story is that memory manufacturers at that time never produced DDR1 with more than 1 GB memory. However they produced up to 4GB ECC registered DDR1 sticks for servers.
Around 2005 motherboards like the ASUS A8N32-SLI Deluxe or DFI NF4 SLI-DR were the fastest solutions we could buy and made primarily for gamers and over-clockers and not servers. Only negative point, they were limited to 4GB.
So how did we end up with having the ASUS A8N32-SLI Deluxe supporting ECC registered DDR1 RAM even if it was never written in the specs?
In fact you have to look at the history of the Athlon64. Only the Sledgehammer with Socket 940 was officially supporting registered memory (in fact it was the only memory supported, unbuffered was not supported) ( https://en.wikipedia.org/wiki/Athlon_64 )
The socket 940 was primarily reserved for the Opterons, the CPU used in servers which typically use ECC and registered memory. However AMD did deliver some Opterons with 939 sockets supporting logically buffered ECC memory https://en.wikipedia.org/wiki/Opteron and some of these Opterons have been absolutely identical to some FX serie (by example the Opteron and FX-60 are identical except the unlocked clock multiplier).
Based on that even if it was not specified officially by AMD some desktop socket 939 CPU like the FX-60 shared the same memory controller as the Opterons and in fact could handle ECC buffered memory.
In fact according to this old datasheet ( https://support.amd.com/TechDocs/31684.pdf page 10 ) a normal socket 939 FX should support up to eight registered DDR DIMMs PC3200 with max 4GB per DIMM (see page 29).
The other funny thing is because of the memory buffer of the ECC registered RAM you can configure 1 T tact with 4 memory sticks!
But having the right HW doesn’t solve the issue, the memory controller still needs to be correctly initialized by the BIOS. Even if the memory type doesn’t appear clearly in the BIOS setup, the ASUS MB can initialize correctly the memory controller of the 939 when you plug in ECC registered memory, it doesn’t work with other performances MB of that time like DFI MB.
My guess is that ASUS making also servers based on the NF4 chip set at that time shared the basic libraries of their NF4 BIOS among all other MB and that’s how the ASUS A8N32-SLI ended up supporting ECC registered memory.
Today you can find cheap 2GB or 4GB ECC registered DDR1 RAM on eBay so if somebody has an old PC based on a ASUS NF4 939 solution he can easily upgrade his PC up to 16GB and use Win 7 64 without problems.
As mentioned the story is not well known but you can find some references on the net (https://www.youtube.com/watch?v=ggJfb81zd7g)
The funny thing would be to find a modded DFI BIOS initializing the memory controller for ECC registered memory.
Elchi the nostalgic Elk