Tested: Generic “Sintechi” FC1307A-based SD to IDE Adapter (SD35VC0)

If you’re the type to have a few older “semi-retro” computers lying about, you’ve probably got a few old interfaces that are becoming difficult to use. For floppy drives, there are USB-floppy emulators, for PCI you can potentially fit a USB 2.0 card and a Gigabit Ethernet card to get some modern interfaces on board, for serial ports you could use a null-modem cable and a USB-to-serial adapter on a modern computer, for the AT-supply and AT DIN keyboard plug there are ATX/PS2 adapters, for VGA you could use an HDMI converter and if you have floppy disks/CD-ROMs you can also use USB floppy/optical drives.

But what about hard drives? Being the mechanical beasts that they are, they’re now starting to succumb to age and have various subtle capacity barriers along the way which can impact on the compatibility of replacements (528MB, 2.1GB, 4.2GB, 8.4GB, 32GB, 128GB to name a few). As no new IDE hard drives are made, any drive available is (by necessity) old stock or second hand. While some are now on SATA, we’ve started a migration away from spinning drives to solid state and from SATA to NVMe/PCIe based interfaces.

Wouldn’t it be nice if we could use some commodity low-cost flash memory to replace IDE drives? After all, performance of microSD cards have skyrocketed to levels which could easily best many IDE drives (whose interface often topped out at 100MB/s for reliability reasons, depending on the controller and the drive, with very few to no mechanical drives saturating the interface).

After a little searching on eBay, I found some generic SD to IDE adapters for around AU$11 a piece and I thought I’d give them a try.

The Adapters

As there were two types of adapters for around the same price, I decided to buy one of each. The left-hand side one is intended for use with regular PCs, sporting regular Molex power connectors, whereas the unit on the right is intended for use as a substitute for 44-pin IDE hard drives in laptops. Both come packaged in a sealed anti-static shielding bag with no other accessories or instructions.

The unit itself is built on a black PCB with yellow silkscreen. All components are mounted to the top, with only the connectors being through-hole mounted. Conveniently, the QC Passed label is applied over the converter IC to “hide” the markings from view. Aside from that, there are a number of resistors, capacitors, LEDs, a voltage regulator, an unmarked microcontroller (?) and the flash memory containing the firmware. The only identification appears to be the SD35VC0 marking in the left corner. The PCB has four mounting holes and is probably available with a mounting option, but the lowest-cost versions omit this making it slightly less convenient.

Removing the label reveals the adapter is based on the FC1307A.

Following a similar design motif, the 44-pin version also hides its identity behind the QC label. The anonymous chip in the previous is marked STCA1 in this version. All of the circuitry is placed on one side with no card detect LED.

The slot is placed on the other side.

With no surprises, the unit also uses the same FC1307A chipset, thus I didn’t test this unit any further.

Initial Detection & Set-Up

Testing was performed using a Gigabyte K8VM800M motherboard based on a VIA chipset with an AMD Sempron 3300+ CPU, 1Gb Geil DDR 400 memory and Windows XP SP3. This platform was chosen as it was conveniently available but also because it has “native” IDE ports but is still modern and fast enough to achieve full IDE-throughput without being the bottleneck. For testing, the adapter was given its own IDE channel (secondary) with no slave device attached, using an 80-conductor cable for maximum speed. The system was booted from a traditional 80Gb WD IDE hard drive on the primary channel. The system was shut down in-between card changes as IDE devices are not designed to be hot-swapped.

For initial testing, the 32GB Toshiba Exceria card was inserted with the converter left hanging outside the machine and then powered up.

It was good to see the converter was detected upon power-up without any additional intervention. It uses a very absurdly long description of “SINTECHI HighSpeed SD to CF Adapter V1.0 Rev 1.2”. Note that it is “to CF” rather than “to IDE” which suggests where the heritage of this adapter may have been from. (Yes, I also need to change the CMOS battery …)

This actually led to a fascinating discovery – indeed, it seems that Sintech are responsible for a number of SD to CF adapters which I have tested before. Accordingly, they also make a variety of SD to IDE converters for desktops and laptops which look vaguely similar. They differ in having a parallel Flash interface, CE/FCC logos, either one of the Molex type power adapters, the use of tantalum electrolytic capacitors,  white silkscreening on some, less LEDs and angled connectors etc. As a result, I suspect the SINTECHI name is deliberate to indicate these may be clones or counterfeited units based on the original.

The upside, however, is the dual power connection options does make this clone more versatile than the original, and serial flash is cheaper than parallel flash so there may be a cost reduction motive there.

The next screen shows it has been detected in LBA mode with ATA 100 transfer rate. SMART is disabled, as per the “default” BIOS options on this board.

Capabilities and SMART Data

Testing with the 32GB Toshiba Exceria card installed reveals that the drive advertises only the SMART feature with no other capabilities. Note the lack of 48-bit address capability which could be a problem with cards larger than 128GB. As I don’t have any of these cards on hand, I couldn’t confirm if 48-bit LBA is supported. TRIM is also not supported, although as far as I’m aware, only some eMMC devices are able to utilise this. The converter advertises UDMA5 (100MB/s) capability and indeed has linked at the promised rate via an 80-conductor IDE cable. It does claim an 8KB buffer … very small, perhaps implemented in internal RAM?

Looking at the SMART attributes, however, does not list any information at all. This is not surprising. I decided to get a second opinion …

With the Toshiba Exceria 64GB Type II card inserted, CrystalDiskInfo seems to suggest some SMART attributes are available. The values, however, appear to remain static and do not seem to be properly formatted with no threshold. As a result, I’d have to say that the SMART is not useful at all on the converter. I did notice, however, that the Serial Number does change for each of the cards I insert – it could be relaying something based on the SD card’s own CID/CSD fields.

Performance & Compatibility

As the performance of the converter cannot exceed that of the card inserted, I decided to do the most thorough benchmarking with the Toshiba Exceria Type 2 64GB SDXC card rated for 95MB/s read and 60MB/s write and shown previously to achieve very similar figures in testing. However, it is also important to check for compatibility, so I also tested a variety of SDSC, SDHC and SDXC cards in my possession.

Toshiba Exceria Type 2 64GB SDXC

While the host card is capable of higher speeds, it seems that the converter is only capable of communicating with the card at “SD High Speed” bus rates which top out at 25MB/s. Sequential writes averaged 23.6MB/s.

Sequential reads topped out at 24.3MB/s. Despite not being able to take full advantage of the card’s speed, it seemingly had no problems with the capacity and access times were “acceptable”.

Additional Extra Tests were also run, which seem to show that the converter is no IOPS monster, being quite severely penalised in write performance.

This is backed in the Random Access tests which showed that read IOPS were at most 1780IOPS at 512 bytes, 1457 IOPS at 4kB and 24 IOPS at 1MB.

The Write IOPS fared significantly worse with just 252, 293 and 2 IOPS respectively. This combined with the low amount of cache suggests that the unit could be quite slow and “stuttery” when using for OS booting.

CDM reflects the poor scores from before with random access write performance falling through the floor to very low levels. Mechanical hard drives are not great at small-block random access, however, with the benefit of cache and a mixed workload, could perhaps still perform better than the SD card in the adapter.

Sandisk Ultra 128GB microSDXC in Adapter

Using the 128GB card didn’t seem to cause any problems, although now the write speed is limited by the card’s own performance rather than that of the converter. Note how the write access time has increased slightly probably due to the poorer performance characteristics of the card.

Toshiba Exceria 32GB SDHC

The 32GB SDHC card caused no problems either, again, the write speed is limited by the card but the access time is more reasonable.

Strontium Nitro 16GB microSDHC in Adapter

Using a smaller 16GB SDHC card in an adapter also caused no issues, although the “borderline” Class 10 abilities of the card before apparent – it is a card that “just meets” requirements. Access time is slightly worse.

Kingston 2GB SDSC

Taking out a more vintage 2GB SDSC card shows us why older cards may not be appropriate – they’re slower. So you’d probably be better off using a newer card and only using part of the drive rather than using an older card. The read speed average is 13.7MB/s and the write speed average is 5.4MB/s with the card being the limiting factor in both cases. Access time for reads is even lower than before, but write access times are through the roof! The one upside to some older cards is possibly the better (more enduring) form of Flash memory (MLC) but this might be offset by the controller’s lack of sophisticated wear levelling management.

 Kingmax 1GB SDSC

Finally, I grab an even older 1GB SDSC card, which shows 10.7MB/s average read and 8.1MB/s average write. While it is slow sequentially, the access times are the best in the category – so not every card is made equal.

Firmware

I dumped the firmware from the onboard Flash chip for examination to see if there are any clues. It was a small 64kB chip, with a few text strings of interest but otherwise with some empty areas and blobs of binary code.

There is a reference to Key Technology Corp. FC1307, and a number string ‘76823170’. There is also the string “FC-1307 2012_07_19-BANK CF_V1.5B15” which shows the age of the firmware and the fact it was possibly also used in a CompactFlash card product at one stage with a different version number.

Further on in the firmware, there is the strings which are presented by this unit mixed with other strings including “Rev 1.2 FC-1307 SD to CF Adapter BACKUP V1.2”, “SINTECHI HighSpeed SD to CF Adapter V1.0” “SINTECHI SD to CF Adatper SPEED V1.0” and “FC-1307 SD to CF Adapter JBOD V1.2”. I wonder if there is a multi-card version of this for a larger capacity that does use the SD cards in JBOD – after all the SD bus can be operated “multi-drop” but not at the highest speeds. Maybe this is represented by the “dual-slot” CF to IDE adapter which I’ve seen but not purchased.

Conclusion

The SD-to-IDE adapter appears to be a modified generic clone of a product originally from Sintech. Based around an FC1307A chipset, the unit does operate as expected with SD cards that I tested, ranging from 1GB through to 128GB. While it is faster than the old SD to CF adapters I’ve tested, their performance tops out in the 20-25MB/s territory due to the use of a “high speed” SD bus rather than a UHS bus capable of 104MB/s. As the unit lacks cache, write performance and interleaved reads/writes are not expected to be fast, although the 44-pin unit may be fast enough compared to older 4200RPM 2.5″ drives which are slowly becoming unreliable. It is rather handy to have as an inexpensive way to substitute an old IDE drive for some cheap commodity SD-card based storage for a lower-power, silent and potentially more reliable solution, but it’s not going to be fast.

I did not test the ability of the unit to operate in CHS mode (necessary for DOS-mode operation under 528MB and below situations) and did not have a <1GB SD card to hand to test its behaviour. I was not able to test whether the unit supports 48-bit LBA addressing (it doesn’t claim support), thus using SD cards >128GB is unadvisable. You’d probably not want to do this due to the slow speeds regardless.

Compared to the old method of using CompactFlash cards in IDE adapters, this does have a number of benefits as CF cards are starting to become expensive and rare. Older and cheaper CF cards only operated in PIO mode in True IDE mode which resulted in CPU-crippling transfers to and from the card. UDMA-capable cards can indeed be fast and low-burden, but typically cost more without any clear indication as to which UDMA rates they support. I’ve encountered some cards unhappy to operate in CHS mode, with smaller cards typically older and lower performance. Being able to use more common SD/microSD (via adapter) is an advantage, as is having a steady UDMA-100 capable interface on the IDE side.

Your other option which might be more preferable is to find a type of IDE to SATA adapter that allows you to use SATA drives on IDE interfaces. The downside is that a number of these are designed with female IDE ports to plug directly into the motherboard which could be a clearance issue, but also means you’re not able to use the slave position on that channel. While my experience is that they operate SATA-I rates, the upside is that you’d likely be able to achieve full IDE-saturation performance.

Update – Here’s my old Techway Endeavour Pentium 100Mhz machine booting from the SD-IDE adapter which has a 16GB microSD card with the original Windows 95a 2GB image written to it and the BIOS has been manually configured with appropriate size parameters to handle it (1024/64/63) due to its inherent 2.1GB barrier. It boots quicker than the Fujitsu MPA-series hard drive I’ve put in there as a replacement for the original (failing) WD Caviar drive.

About lui_gough

I'm a bit of a nut for electronics, computing, photography, radio, satellite and other technical hobbies. Click for more about me!
This entry was posted in Computing and tagged , , , , , , . Bookmark the permalink.

2 Responses to Tested: Generic “Sintechi” FC1307A-based SD to IDE Adapter (SD35VC0)

  1. Hi. Thanks, a good write up. Some RF test equipment use a IDE HD to boot MS-DOS or Windows then to the application. Often the HD is very old. The SD adaptor may work with them. Did you try booting from it? I have tried an IDE SSD with no success. I have made a DVD image of the HD so I at least have backup. I have successfully imaged onto another IDE HD, but they are hard to get. The instruments are still very useful and capable, so it is a real need. Details in my blog.

    https://vk4zxi.blogspot.com/2018/07/rohde-schwarz-cmu200.html

    Regards Drew VK4ZXI

    • lui_gough says:

      Dear Drew,

      Hard to say whether it will or it won’t work, but it’s cheap enough that it might be worth trying anyway.

      If it’s modern enough to recognise and operate in LBA mode (>528MB or >1024/16/63) it should work just fine. The problem normally boils down to either timing (some drives take a little too long to become ready on the bus), a mode incompatibility (e.g. needs to operate only on older PIO/MWDMA modes rather than UDMA), drive size being too big (e.g. capacity barrier) or having LBA-only mode support (e.g. with some CF cards I’ve tried). Perhaps failing this, an industrial CF card in an adapter is probably the best solution as some of them clearly advertise their DMA mode support and CHS geometry.

      I’ve had no problems with it booting on my Techway Pentium 100Mhz machine running Windows 95a based on the original image and based on configuring it on a manual LBA mode geometry but note that this was originally imaged from a 2GB hard drive. Pure CHS mode access (1024/16/63 (528MB) or less) is not something I’ve tested and older MS-DOS + BIOS based disk access will mandate the use of CHS for such drives (especially 486-or-earlier based systems). I’ve uploaded an image to the end of the post showing the machine booted using the SD adapter.

      As a result, I hesitate to provide any concrete guarantees whether it will or it won’t work – it’s just a matter of BIOSes, drive controllers and what their code/compatibility is like.

      – Gough

Error: Comment is Missing!