Sil0680 is probably the best add-in PCI IDE controller, at least when it comes to CD Drives.

Is your card using BIOS 3.4.0.0?

Looking in the driver foler, I see four files:
CMD64XX2.SYS
CMD680.SYS
SII680.SYS
SII680CD.SYS

You might try experimenting with each seperate driver file.

If you'd like, I can upload the drivers and BIOS for you.

It also occurs to me that you might want to give Promise controllers a shot. Those cards are too outdated for modern Windows use, but might be better suited for DOS.

mockingbird wrote:

Sil0680 is probably the best add-in PCI IDE controller, at least when it comes to CD Drives.

I'm actually looking to run my harddrives from an IDE controller card. The 440BX IDE controller only supports UDMA2, and I'd like get full UDMA6 speed from my SSDs. (still waiting for the 44-pin adapters to arrive, so I'm testing with normal HDDs now.)

mockingbird wrote:

Is your card using BIOS 3.4.0.0?

No, it's 3.2.10. If you could upload 3.4, that would be great!

mockingbird wrote:

Looking in the driver foler, I see four files: CMD64XX2.SYS CMD680.SYS SII680.SYS SII680CD.SYS […]
Show full quote

Looking in the driver foler, I see four files:
CMD64XX2.SYS
CMD680.SYS
SII680.SYS
SII680CD.SYS

You might try experimenting with each seperate driver file.

Got those, but I'm not sure which one to use. Guessing from the example CONFIG.SYS file, I think SII680CD.SYS and CMD64XX2.SYS are for CD drives only. SII680.SYS identifies itself as "IDE Driver" and CMD680.SYS is a "Bus Mastering IDE driver".

Now when I load DOS with UMBPCI->XMGR->UIDE, without using the drivers, XMGR hangs with the PCI card installed. HIMEMX->UIDE->JEMM386 does not crash, but both UIDE and JEMM fail to load.
The example CONFIG.SYS loads the driver (low!) after HIMEM.SYS, and only uses SII680.SYS. CMD680.SYS is referenced multiple times, but REM-ed out.
When using only SII680.SYS, loaded before XMGR, it detects only the first disk (which takes AWFULLY long). Same with CMD680.SYS. UIDE also throws some errors, says "BAD Controller at B800h, chip ID 808667111h" (I think that's the 440BX controller), and "DPTE data BAD, unit 81h".
Loading CMD680 after SII680, however, seems to detect both drives, but it throws an error about some partition mismatch (and a warning "DO NOT WRITE TO DISK NOW"). I don't think that's supposed to happen, either.

Ok, here are the relevant files.

The DOS readme looks pretty interesting.

You have to be careful when using Shadow RAM for UMBs instead of XMS if it is DMA capable.

The onboard BIOS of Promise cards will enable the fastest speed supported by the drive. I have a Promise Ultra 100TX2 that runs everything in UDMA mode, no drivers needed. Surprisingly it has 32-bit and 64-bit drivers for Vista/7/8! If you are using a SSD on a DOS machine, why not go for one of the many PCI SATA controllers? They don't have the PIO mode issue to begin with.

mockingbird wrote:

Ok, here are the relevant files.

The DOS readme looks pretty interesting.

Thank you, will update the BIOS soon and report back!
The drivers you included appear to be the same ones I found. Readme is not very helpful, it explains SII*.SYS but there's no mention of the CMD*.SYS files. These appear to have more options, as seen in the included CONFIG.SYS... But what do they do? And what is the difference between the SII and CMD drivers, anyway?

elianda wrote:

You have to be careful when using Shadow RAM for UMBs instead of XMS if it is DMA capable.

Do you mean the controller can write into UMBs directly during DMA transfers? Or did you mean, I shouldn't allocate UMBs in the controller's ROM area? (UMBCHK says they're free to use)

NJRoadfan wrote:

The onboard BIOS of Promise cards will enable the fastest speed supported by the drive. I have a Promise Ultra 100TX2 that runs everything in UDMA mode, no drivers needed. Surprisingly it has 32-bit and 64-bit drivers for Vista/7/8! If you are using a SSD on a DOS machine, why not go for one of the many PCI SATA controllers? They don't have the PIO mode issue to begin with.

Sounds like I need to try one of those, then. Thanks!
I bought IDE SSDs because I intuitively assumed IDE controllers would have better DOS support, compared to SATA controllers. But then I may have been wrong about this.

jwt27 wrote:

elianda wrote:

You have to be careful when using Shadow RAM for UMBs instead of XMS if it is DMA capable.

Do you mean the controller can write into UMBs directly during DMA transfers? Or did you mean, I shouldn't allocate UMBs in the controller's ROM area? (UMBCHK says they're free to use)

I think he meant that loading the drivers into UMBs might cause problems because DMA (and probably other things) do not work properly within the shadow RAM area (depends on the chipset). Uwe Sieber mentions problems like this on his UMBPCI page.

Don't think DMA is a problem with PCI IDE controllers (or even ISA ones), that note applies only for stuff that uses classic ISA DMA like floppy drives. Don't load Smartdrv high and enable floppy caching.... it doesn't work!

jwt27 wrote:

The 440BX IDE controller only supports UDMA2, and I'd like get full UDMA6 speed from my SSDs. (still waiting for the 44-pin adapters to arrive, so I'm testing with normal HDDs now.)

I read somewhere that these Sata->IDE adapters suck and make your disks terribly slow. It would be nice if you could get some measurements once the adapter arrives 😀

Tried upgrading the BIOS but it failed at first. The card I have must be the extra-cheap version, as the ROM chip on the card is... actual ROM. Not flash, not even EEPROM. I had to desolder it, and flash a BIOS chip I pulled from a socket 7 board, with the external EEPROM programmer I ordered a few weeks ago (and which, by coincidence, arrived only yesterday!)

So, I have the v3.4.0.0 ROM now, but I can't really say it's an improvement in any way. First of all, when booting from a harddrive attached to the SIL0680 controller, the Freedos kernel loads but it hangs for about two minutes at the InitDisk part, with the HDD LED flashing occasionally. The CHS parameters it shows seem completely wrong. Then it fails with "COMMAND.COM not found".
I received the SSD adapters now, so I also tried booting with the HDD attached to the mainboard, and two SSDs on the PCI card. Booting without drivers crashes instantly (endless "Interrupt divide by zero"). Booting with drivers (either SIL, CMD, or both) seems to work but the drivers don't detect any harddrives. Trying the HDD test in Speedsys crashes right away.
Funny thing I noticed, when both HDD and SDD are connected to the mainboard, even without the PCI card inserted, the SIL0680 drivers DO actually detect the SSDs and will attempt to control them. Needless to say, this fails.

So, umm, unless anyone can tell me I'm doing something completely wrong, I don't look forward to using this unreliable controller in my mission-critical time machine. I ordered a Promise Ultra133 TX2 card now, and until it arrives, I guess I can live with UDMA2 for now.

5u3 wrote:

jwt27 wrote:

elianda wrote:

You have to be careful when using Shadow RAM for UMBs instead of XMS if it is DMA capable.

Do you mean the controller can write into UMBs directly during DMA transfers? Or did you mean, I shouldn't allocate UMBs in the controller's ROM area? (UMBCHK says they're free to use)

I think he meant that loading the drivers into UMBs might cause problems because DMA (and probably other things) do not work properly within the shadow RAM area (depends on the chipset). Uwe Sieber mentions problems like this on his UMBPCI page.

Only AMD platforms have issues with PCI bus mastering in UMBs, not 440BX. I don't use any UMBs that don't work with ISA DMA either.

devius wrote:

jwt27 wrote:

The 440BX IDE controller only supports UDMA2, and I'd like get full UDMA6 speed from my SSDs. (still waiting for the 44-pin adapters to arrive, so I'm testing with normal HDDs now.)

I read somewhere that these Sata->IDE adapters suck and make your disks terribly slow. It would be nice if you could get some measurements once the adapter arrives 😀

I actually have IDE SSDs, not SATA 😀 One Adtron SLC 32GB with UDMA5, and a Kingspec MLC 64GB with UDMA6. These are 2.5" with a 44-pin small pitch (laptop) connector, so I have to use a passive adapter to connect it to a 40-pin cable.

jwt27 wrote:

I actually have IDE SSDs, not SATA 😀 One Adtron SLC 32GB with UDMA5, and a Kingspec MLC 64GB with UDMA6.

Ha! I didn't even knew such a thing existed since SSDs showed up when SATA was already the standard for some years. Makes sense though.

Reporting back, I got one of those Promise controllers and have been using it for a while now. It works great right out of the box at full speed, no drivers required! Only Windows requires a driver in order to boot from a drive attached to the card.

BUT. Even though you don't have to load a driver, it automatically claims 6 kB (!!!) of conventional memory for itself. That's kinda sneaky.

Unfortunately the performance I'm getting from the SSDs is... nothing to write home about. 🙁

I did a comparison a while ago using a PCI SATA controller with SSD vs. my current storage method which is a modern 2 TB SATA drive with capacity set to 32 GB and a SATA to IDE adapter.

I couldn't really tell much of a difference. The Slot 1 system / platform is likely what is holding things back. This was on the top of the line Pentium III 1.1 GHz with lots of RAM.

So I stopped using PCI SATA cards and using SATA to IDE adapers across the board.

When you say conventional, is it below 640KB or 1MB?
The IDE controller needs to map it's ROM code somewhere, but it should be in the upper area (above 640KB and below 1MB).

AFAIK IDE SSDs are kind of old, so their performance is probably not comparable to modern SSDs. Also, they only really shine when there is a lot of random reads or writes. Depending on how bare is your Windows setup (not loading a lot of stuff all at once), that SSD might have little advantage (most of the time) compared to a non-fragmented HD

Well the read speeds I'm seeing are as advertised. Problem is, I got both second-hand from ebay and they were already filled up to capacity, so the write speed is way down.

I more or less expected this of course, and I've tried to "reset" them by issuing a Secure Erase command. But somehow I couldn't get that to work. After messing around for several days I just gave up and copied everything over from my HDDs. Sure they're used, but they're SSDs, performance couldn't be that bad, right?
Copying files took quite a while, but then I was copying from some ancient HDDs so I assumed that would be the bottleneck. WRONG. After finally getting Windows to boot, I ran a benchmark, and got around 10MB/s linear write, and 0.1MB/s random write from both drives...

And it's quite noticable, too. Windows boots up much quicker now, but things like web browsing are markedly slower than before.

alexanrs wrote:

When you say conventional, is it below 640KB or 1MB?
The IDE controller needs to map it's ROM code somewhere, but it should be in the upper area (above 640KB and below 1MB).

Below 640k. If you run MEM with the IDE controller installed, it'll say 634k total conventional memory instead of 640k.

IDE SSDs are old, and early SSDs had terrible issues with performance degradation. Also, Win9x/XP don't support TRIM commands (then again, neither does your driver probably). You'd be better off with a PCI SATA + a modern SSDHD. The SSD cache in those are managed entirely by the drive's firmware transparently so you don't have to worry about TRIM commands and performance degradation. Using your current PCI card with a Sata to IDE adapter should be fine too.

Is it properly aligned, if misaligned, that would degrade random writes, as a 4k write becomes 8k of read modify write.

Matth79 wrote:

Is it properly aligned, if misaligned, that would degrade random writes, as a 4k write becomes 8k of read modify write.

I aligned the partitions to 1MB offset, using the default cluster size for FAT32 (4k? not sure). Read speed does not seem affected so I don't think that's the issue.

I'm thinking though, if you were to set the FAT32 cluster size equal to the flash block size (or a multiple thereof), wouldn't that help with write speed degradation? A single cluster write would then only take an erase->write cycle, instead of read->erase->modify->write, so to the flash controller, there shouldn't be any difference between linear and random writes. That is, assuming the flash controller is "smart" enough to understand the extra cycles are not necessary anymore.

Flash block sizes can be anywhere from 16-256k though so that would waste a considerable amount of space if you have a large number of small files (as on my DOS partition). It's also difficult (impossible?) to determine the block size without physically taking the drive apart.

Some partitioning tools have the option to take care of the aligning for you. You'll have better luck partitioning it with a recent Linux live CD than with Windows 2000 or 98 partitioning tools