Your board seems to be based on an Intel chipset. Based on available documentation, the board is supposed to be based on the Intel 865 chipset. I mean *8*65, combined with ICH5. Yet it has LGA775 and claims to support FSB clock of 1066 MHz, and claims support of Core2Duo and even Core2Extreme CPU's... That seems odd, with that spec I'd expect an Intel *9*65 chipset, maybe combined with ICH7. Heh - you should know better. Initially I thought that this was merely a case of incredibly poor documentation writing (copy+paste from an old motherboard model, don't bother to correct the chipset numbers) - but later I've actually found a comment that the board indeed uses the ages old chipset (seated firmly in the times of the PGA478 pinned socket and P4 Northwood/Prescott) to allow for its super-low cost, and that the chipset is run slighly out of spec (overclocked) and with CPU's that it officially shouldn't support... And indeed even the other figures in the manual hint at ICH5, rather than a newer ICH (SATA 1.5 Gbps vs. SATA2/3Gbps, DDR266/333/400 rather than DDR2 etc.)
For a sata driver, go to the Intel support website and search it for an "F6 floppy". Or go through the selector tree, starting from chipsets, select i865, then XP, then the F6 floppy.
You'll need an empty floppy, formatted under W2k or XP (not Windows 98, not DOS). Unzip the contents of the downloaded F6flpy.zip to the root of the floppy - there should be a txtsetup.oem, an .inf file and maybe a .sys file.
When formatting the drive in the Windows installer, choose the option to format the partition with NTFS "fast" - means that it only creates the necessary metadata of an initial empty filesystem, but does not search the whole drive for bad sectors (which is not necessary, and certainly doesn't improve the "quality" of the "format" in any way). It's the bad sector search that takes ages. The basic NTFS init takes just a few seconds.
As for the disk drive: although Seagate Barracuda's with 3Gbps SATA have never had a problem to run on the old ICH4/ICH5, only offering 1st-gen SATA at 1.5 Gbps, be aware that connecting a newer-gen SATA disk drive to an older-gen SATA HBA may cause trouble. I recall having this kind of problem with SATA2/3Gb drives connected to a SATA1 3ware controller (the good old 8006-2). Barracuda's used to have a jumper that allowed you to force the drive to only ever try SATA1 1.5 Gbps. Umm... the problem with the 3ware presented itself early during POST, during drive detection. Sometimes the HBA just didn't detect the drive. Once detected, the drive would work just fine until the next power-cycle. Your problem seems different: based on the symptoms, your drive fails at random during routine operation. That's weird. Anyway: the recent generation of Barracuda's are capable of SATA3@6Gbps. I would sure expect some trouble when trying to connect that to a SATA1 HBA. Try to test the drive in a computer which has at least SATA2@3Gbps and preferably an Intel chipset (ICH6 and above, if memory serves - definitely an ICH7). And, try to take a look into the Barracuda's manual, if the drive can possibly be jumpered (forced) to a lower bitrate at the SATA interface.
Even if the board was released for the 65nm C2D CPU's, it must be pretty old by now - 4 or 5 years at work maybe? Are you sure it's not the board, or maybe the PSU, that's trying to say goodbye? Both the mobo and the PSU contain electrolytic capacitors that wear out over time. 4 years of runtime seem like a pretty old age for some very cheap stuff... depends also on the % of daily uptime, but still. Look for capacitors bulging on top or leaking, but even if you don't see those signs, be wary - a dried-out electrolyte doesn't have to be visible on the outside. I don't believe a super-cheap mobo of that time would have proper solid-polymer capacitors in the VRM, let alone elsewhere across the board. Also, a sharp new Barracuda could have higher requirements on the health of your PSU's output filtering capacitors, than an old Caviar.
I happen to have a simple homebrew Linux live CD which I'm using for basic hardware debugging and stress-testing:
http://www.fccps.cz/download/adv/frr/bootcd.tgz
The download is a targzipped ISO image - WinZip or 7zip should open that.
It's a little spartan and text-only, and also quite dated - but it does the job just fine for me, even on new hardware.
Once you get past the bootloader and into the "main menu", you'll be presented the option to "run tests from this CD". This is perhaps not exactly what you want. This is our burn-in stress-test suite. If you want to test specifically the disk drive, you don't want CPUburn to trash your CPU and RAM (and maybe cause unstability of the old motherboard).
So I suggest that you flip to a free console (Alt+F5 or Alt+F6) and type some of the following:
hddtest -d /dev/sda
hddtest --help
smartctl -a /dev/sda
Try to let hddtest read the whole harddrive - maybe let it run overnight and look for any "garbage" on screen in the morning (kernel complaining about drive timeouts or some such). Next, if there's no data you can lose on the drive, try over-writing it with "all zeroes", e.g. using "hddtest -w -d /dev/sda" (though there are other ways in Linux). Both when reading and when writing, look for any sudden slow-downs. Those hint trouble, even if the disk still manages to come back with a response soon enough to avoid a timeout.
Smartctl will provide a dump of the S.M.A.R.T. stats - look at the raw figures of reallocated sectors and offline uncorrectable, and check if there are any errors in the error log (and what kind - not all errors logged there mean an error on part of the drive, a particular sort of checksum errors mean a cabling problem).
To test the theory that maybe it's the motherboard or PSU going south, try the full stress-test (and look for freezes / kernel panics over some period of time), or reboot and choose Memtest86 in the bootloader (it's a stand-alone bootable piece of code, not running from Linux).
While you're in Linux, you can always check what has happend inbetween, such as display some history of the kernel panic messages that have scrolled away, by typing "dmesg | less" (that character is a "pipe", obtained using "shift+backslash" on your keyboard) - this will dump the kernel message log and allow you to scroll it up and down using arrow keys.
To get out of any util under linux, you can always use CTRL+C, sometimes just "q" or ":q" works as well.
And, you can rewind any listing scrolled past either with "| less" or just using Shift+PgUp / Shift+PgDown.
You can do a number of other things in Linux, such as mount a floppy or a flash drive and redirect the output of dmesg or smartctl into a file on the removable media - but that's perhaps your homework, if you've got this far... Maybe try "lspci" while you're in there
I'm keeping my fingers crossed for your interesting hardware. And don't be sad if the board is indeed going south
Maybe keep the CPU (is that a Core2 something?), and buy a new entry-level board with maybe G41 or some other 3/4 series chipset - it will work for you for several more years ;-) Those new boards have solid-polymer caps in the VRM... If you buy a board capable of DDR3 (which the G41 maybe isn't), you have a chance to buy a couple GB of dirt-cheap RAM to make your windows fly.
As for a PSU (if that's the culprit), try buying something that has active PFC - goes hand in hand with a "full-range input", from 100V to 240V AC, without a mechanical switch - and it isn't the cheapest variety in the retail stores. PFC is an attribute of a "not entirely shitty" power supply. For a sane CPU+motherboard and a single HDD, a 400W PSU is plenty good enough. Many trustworthy "industrial" power supplies are just fine with 300W or less. Unless you add a hungry graphical board. Which is a waste of money for office work anyway.