I found this from a post jaclaz made in bootland
http://www.boot-land.net/forums/I-found-a-...mine-t1697.html

A universal ATA and perhaps SATA driver for windows.
http://alter.org.ua/en/soft/win/uni_ata/

My idea is to add it to the txtsetup.sif as a fallback driver in place of pciide.sys
This should be used if no other drivers you have match the hardware.
What to do if you want to try:
1) Download the uniata driver from the above site.
2) extract the uniata.sys file into a new directory under <your pebuilder directory>\drivers\SCSIAdaptor\UniATA
3) copy the code below into a new txtsetup.oem in that same directory.

What it will do is copy the driver into your i386\system32\drivers folder and modify your txtsetup.sif replacing pciide.sys for standard ide controllers with uniata.sys
The pciid is PCI\CC_0101 which again should only be used if no other drivers match your hardware.
The idea for this came from cdob's post in the generic vga driver thread:
http://www.911cd.net/forums//index.php?s=&...st&p=128156

Here's the modified txtsetup.oem:

At this point I've only tested this idea in virtual machines, where I removed the specific driver it would be looking for, at which point it did fall back to the uniata.sys and was able to read the harddrives.

Ive added a link to this thread at bootland
http://www.boot-land.net/forums/index.php?...amp;#entry11234

This plugin might come in handy.

I hope so.

Has there been any further testing with this? This is a REALLY interesting concept!

If there has, no one has posted about it

Well, I've used it in my builds and I concur that it "falls back" in a virtual machine, but that's about as far as I got.

I'm guilty

First tests resulted in BSOD 0x7b.
Next I added some ideas to a massstorage driver project.
Doing this I learned more about massstorage driver loading. This explained previous BSOD 0x7b too.
Load order is importand sometimes.
Some drivers occupy hardware e.g. UniATA.sys, but are not active.
Later loaded driver can't access hardware and are not active too.

May result a BSOD 0x7b:
[SCSI.Load]
UniATA=UniATA.sys,4
iastor=iastor.sys,4

Does work here:
[SCSI.Load]
iastor=iastor.sys,4
UniATA=UniATA.sys,4

A all working universal ATA driver would be great.

Alexander is a great author and wrote some outstanding applications.

However some drives and controllers behave strange.
These exceptions are the difficult part.

http://alter.org.ua/en/soft/win/uni_ata/compat.php
Devices those should be supported
specified controllers tested under specified OS

http://alter.org.ua/en/soft/win/uni_ata/stddev.php
Widespread deviations from ATA standard and related bugs

BartPE is used for rescue works.
Is uniata.sys a appropiate tool for a rescue environment?

PCI\CC_0101 maps to pciide.sys by default. This is generic Dual PCI IDE.
Pciide.sys is well tested and does work at windows and PE.
Can UniATA usage destroy data?

PCI\VEN_1106&CC_0101 ;VIA IDE - get a higher priority

XP use by default:
PCI\VEN_1106&DEV_0571 = "viaide" ;get a even higher priority


There has to be real benefit to use uniata.sys.

A read only UniATA driver release might come in handy.

What about DMA mode CD drive?
Pciide.sys set PIO mode at CD drives.

BartPE does boot from a uniata.sys v 0.37 driven drive.
Uniata.sys is used and DMA is enabled at CD drive.

CD writing is possible at VIA IDE, full speed at low CPU usage.

This is promising:
CD DMA is possible now, after more than three years.

However different applications dosn't write at Intel IDE.
Drive dosn't respon't anymore: a scsi bus reset occurred.

Currently I don't detect a real benefit to use uniata.sys at BartPE.
A last change solution is F6 and a uniata.sys floppy.
Conditions may change in future.

Hello. great find d4vr0s.
Just tested this driver on a cheap ALI M5283 c/s PCI card, an Adaptec 1210SA and all works fine.

ALI M5283
Test 1: Original build - No hard Drive detected.
Test 2: Added UniAta as discribed - Drive detected. Confirm driver used uniata.sys

Adaptec 1210SA
Test 3: Original build. Existing plugin- Drive detected . Confirm driver used aar1210.sys - Note1
Test 4: Added UniAta as discribed - Drive detected. Confirm driver used uniata.sys, even though above driver still exists.
Test 5: Added UniAta as discribed - Removed 1210 plugin. Drive detected. Confirm driver used uniata.sys.

I have decided to leave this driver in my build and see what happens. I think issues to look for are conflicts and performance.

Note1: even though the drive was detected. Device manager clone showed " No drivers installed for thie device". I had to run HwPnP to show the driver. This is a step I do not normally take for HDD testing etc. I understood this should have been picked up at boot via txtsetup.sif, so perhaps there is something wrong with my "old style" plug-in for the 1210!!! If I were adding it today, I would of course have added it via the drivrers\scsiadapters method but this plugin pre-dated this.

Regrads,
SteveA

Thanks allens
Question:
On test 4 did you confirm that the 1210SA driver had the correct information for the hardware in that system?
Meaning, the Vendor ID and subsys ..

Hello d4vr0s,

My guess is that there is something wrong with my 1210 plugin.
Here is PciScan info:
And here is my inf file
At first glance this looks correct, I now cannot recall where I got "1,,,,,,_3,4,1" from.
Also I am not sure whether I should have added the Subsystem ID. Since the intro of Bart with the Drivers\Scsi directory method has made me rusty on the older install methods.

My first batch of tests was in respect of plug in PCI Sata controllers and I did not have any drives connected to the on-board ide.So, tried on my Hp Compaq dc5100 PC with these results
Test 6: Original build. Drives detected . Confirm driver used pciide.sys
Test 7: Added UniAta - Drives detected. Confirm driver used uniata.sys.
Here is the info for this unit:
The 2 drives are PATA not SATA but I have shown both ide controllers.
Does this mean the fall back is not working?
In view of cdob's comments in repect of load order, I enclose parts of my txtsetup.sif

In all cases I am booting from BartPe via CD, is cdob booting from hdd using uniata.sys and thus the bsod??

Sorry for long post and regards
SteveA

I had a BSOD as well on an intel controller.
It was on a Dell no less.
I had to make it use the pciide.sys instead (it didn't seem to care for either of the intelide drivers I have)
id = "PCI\VEN_8086&DEV_2651","pciide"

Yes, I'm booting from hdd, hence the BSOD 0x7b. Wasn't that obvious
[SCSI.Load] does contain only two entries: UniATA.sys and iastor.sys.

Hard disk is attached to a AHCI ICH7-M VEN_8086&DEV_27C5.
Uniata.sys v 0.37b uata_xp.inf does contain PCI\VEN_8086&DEV_27c5.

Harddisk is not available.
Neither [HardwareIsDatabase] connected to iastor.sys nor uniata.sys. Both fails.

Even [SCSI.Load] with UniATA.sys only and adjusted [HardwareIsDatabase] fails.

when i first tried the uniata driver i got also an BSOD on an intel controller

i got it working with the following steps:

1. copy uniata driver to the folder drivers\scsiadapter\_uniata (must be first folder), i use the txtsetup.oem from d4vr0s
2. copy all the inf files relatet to ide/ata from infinst_autol.exe to drivers\scsiadapter\intel (e.g. ichxide.inf and ichxid2.inf where x represents a number from 4 to 8 - please check the files for your controller - i use all files)

no further work was nessessary

I have some additional info. My intention was to rebuild and use uniata for named devices ie remove id = "PCI\CC_0101","uniata"

I connect three drives to an IBM Think Centre PC (82845 C/S- ICH4 EIDE). One to the on board ide controller, one to an Adaptec AAR1210 and finally one to an Ali M5281.
I disabled my old style plugin for the M5281 made a new image and booted the PC via CD.
The drive connected to the M5281 could not be seen.

So, I enabled the M5281 plugin altered the uniata txtsetup.oem to not load uniata.sys for this controller.
(This stage I obviously got wrong!!) Made a new image and CD.

Booted the PC again, all drives now seen but when I used Device Manager Clone, I found that the driver used by controller m5281 is uniata.sys not m5281.sys as I expected ( as it used to be prior to uniata).

So the uniata.sys driver can work with the M5281, and if I am not using m5281.sys surely the only reason it is working is due to some setting in the manufacturers m5281.inf? I am going to try korale idea for _uniata - perhaps install order is the key? Perhaps this also explain some of the bsod even when the device id is listed in the uata_xp.inf?

Hoping for some views on this.

Just to recap:
-The integrated ide controller is now using pciide.sys but the other two controllers are using uniata.sys.
-The uniata driver is installed via Drivers\ScsiAdapter\UniATA but the m5281 via an older style plugin.

Here is my inf file for m5281 plugin:
And this is my doctored txtsetup.oem for uniata:
Finally, in view of my original testing is the "falls back" technique working as hoped?
I did not want my integrated IDE to use uniata.sys but pciide.sys (which is how I got into this new loop!)
Regards,
SteveA

I just tried renaming that folder from uniata to _uniata, the only difference it seemed to make in the txtsetup.sif was it's position under the [SourceDisksFiles] section?


I had already done this and forgotten.
However, I just extracted the .inf files from the XP subfolder of that archive.

@d4vr0s:
you're right, the order of the folders doesn't matter
but after i copied all the intel inf files to the drivers\scsiadapter folder i successfully got rid of the BSOD on an toshiba tecra s2

Thanks korale & d4vr0s

The inf file idea would also explain my test results.
As soon as I get time, I will disable the m5281 plugin but add a new directory of drivers\scsiadapter\m5281 and only install the manufacturers m5281.inf here, not the sys file.

I think it will work!

Hello,
Fustrating afternoon!
Cannot get PeBuilder to add the inf file, as is (Directory of drivers\scsiadapter\m5281\m5281.inf):


Everything with a class of "SCSIAdapter" is accessed via the txtsetup.oem. Added the manufacturers txtsetup.oem and the builder obviously compalined of m5281.sys missing, m5281.inf was still not added.

Should I try changing the class value in the inf? I will in the meantime.
Perhaps I should generate a custom txtsetup.oem just to add the inf file?
Any ideas??

Regards,
Steve

I'm fairly certain the inf files aren't processed during boot.
You should use the txtsetup.oem to add the pci id and the driver file.

After some time I made a decision:

BartPE is a rescue environment.
I'll prefer manufacturer drivers in general.
These drivers are well tested, a data loss is less likely.

At the other hand, BSOD 0x7b is a kind of safety feature.
Windows refuse to boot at a device failure, a data loss is not to be expected.

I like DMA CD writing too.

To combine both:
use Uniata.sys at well tested machines only


Given a ICH7-M chip and uniata.sys 0.37b:

BIOS Compatibility mode:
BSOD 0x7b in both cd and hd booting.

BIOS AHCI mode:
Does boot from cd and hd. Uniata.sys used for cd only. DMA CD read possible, writing fails.
BSOD 0x7b if uniata.sys is connected to AHCI harddisk.


Given a ICH-2 chip and uniata.sys 0.37b:
BartPE boot from CD and DMA CD writing is possible.
However there is a delay at each single file access.
This delay disappear if uniata.sys is removed at a new BartPE, the same CD-RW used.

Current test version
Well, "Enable=0" is my current opinion to 0.37b and BartPE.


@allens
Booting BartPE, driver *.inf is not required.
For massstorage drivers use drivers\scsiadapter\*\txtsetup.oem, a classic pebuilder plugin, winnt.sif or winpeoem.sif.
Remember, drive load order is importand. Uniata.sys may grab device, but fail to load driver.
Load uniata.sys at end of txtsetup.sif [SCSI.load].

Hello,
Will after three years these problems have been resolved?
Note: If I use "DP_MassStorage_wnt5_x86-32_901.7z" the windows can not load all the drivers related to the mass storage...
Strange... so what to do?

Joao, you need to be FAR more explicit.
On WHICH hardware does uniata.sys (now at version 0.39j since alot of time):
http://alter.org.ua/en/soft/win/uni_ata/#uniata_beta
does not work (if you tested it)?

On WHICH hardware does "DP_MassStorage_wnt5_x86-32_901.7z" (whaterver it is and wherever you downloaded it from does not work ?
Current DP Mass storage are 10.06:
http://driverpacks.net/driverpacks/windows...s-storage/10.06


What to do for WHAT?
Please state your expected goal.

Compare with:
http://homepages.tesco.net/J.deBoynePollar...ard-litany.html

jaclaz