More on CF Cards

This is a follow-up to an earlier post. Some interesting information turned up in reader comments and elsewhere. To recap, certain operating systems (notably Windows) behave unreasonably when using and especially when installed on CF drives that report themselves as removable.

CF cards were designed to be electrically and logically compatible with both PCMCIA (PC Cards) and IDE. Cheap and largely mechanical adapters exist for both CF to PCMCIA and CF to IDE applications.

The CF+/CompactFlash specification 2.0 (2003), and I believe earlier versions as well, mandates that the first word (Word 0) of IDENTIFY DEVICE response is 848Ah. That (specifically bits 6 and 7) indicates a removable device, which causes CF cards to be identified as such by operating systems, and generates interesting problems.

The CF+/CompactFlash specification 3.0 (2004) is the first to recognize the problem. Although 848Ah is still the recommended value, the specification says: Some operating systems require Bit 6 of Word 0 to be set to 1 (Non-removable device) to use the card as the root storage device. The Card must be the root storage device when a host completely replaces conventional disk storage with a CompactFlash Card in True IDE mode. To support this requirement and provide capability for any future removable media Cards, alternate handling of Word 0 is permitted. We’re looking at you, Microsoft.

This explicitly gives CF cards the option to report different values in True IDE mode (i.e. using the ATA electrical and logical protocol) and in I/O or memory mode (designed for PCMCIA).

Vendors were obviously aware of the problem. Some solved it by reporting different values in Word 0 of IDENTIFY DEVICE response, regardless of what the specification said. Intriguingly, some vendors provided tools which allow changing the response for individual cards after manufacturing.

ATCFWCHG

Readers pointed at one such utility, ATCFWCHG.COM (yes, a DOS utility). The full name is “NAND Athens ID Drive Config Word (Fixed/Removable) Change Utility”. What Athens stands for in this case is anyone’s guess (code name for some NAND controller?), but the utility appears to have been distributed by SanDisk in the early 2000s. Nowadays SanDisk pretends the problem doesn’t exist, but the utility may still work.

I had a quick look at the utility. It was clearly hand-coded in assembler, which makes analysis both harder and easier. The utility appears to use vendor-specific commands 89h, 8Ah, and 8Bh to do its job. I could not find any information whatsoever what these commands might do… then again they’re vendor specific, so they don’t have to be documented in any kind of publicly available document.

The utility can access the disk through standard IDE ports (primary or secondary, device 0 or 1), through an I/O window at a specified address, or through a memory region at a specified address. The latter two methods are suitable for PC Card interfacing.

Although the ATCFWCHG utility does not give the option, it looks like the vendor-specific commands allow programming much if not all of the IDENTIFY DEVICE response. It might be possible to change the model name, serial number, etc. Note that it is common for vendors to provide utilities which OEMs can use to set the serial number before shipping.

The ATCFWCHG utility did not work on a recently purchased SanDisk Ultra 32GB card (SDCFHS-032G, firmware version HDX13.04). However, it did work on an older SanDisk Extreme III 2GB card (SanDisk SDCFX3-2048, firmware version HDX 4.03). So that’s something.

An utility called NDCFWCHG reportedly exists for a different generation of SanDisk devices, but appears to be unavailable online.

A sister utility to ATCFWCHG was also available at some point, and could enable or disable the reported UDMA modes. It was available as dmaonoff.zip, but I have been unable to locate a copy. Anyone?

Hardware

A completely different approach involves using an “intelligent” CF to IDE adapter with its own logic, such as this one. That sort of adapter can change the IDENTIFY DEVICE response (it will typically have its own) and should behave consistently regardless of the CF card. Unfortunately it’s much more expensive than a simple CF to IDE adapter, roughly 40 Euro vs. something in the 4 Euro range for a dumb adapter.

Given the current trends, the future almost certainly lies with SD to IDE (or whatever) converters and a completely different set of problems.