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.
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?
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.
“Athens” is definitely the name of a Sandisk CF controller: http://alte-hp.altec-cs.com/media/news-presse/2003-08-19/PCN-Athens.pdf
Dumb adapters are that expensive now? I remember buying what I thought were 3 adapters for $3 off eBay years ago, only to actually receive 3 sets of 4 CF-IDE adapters (12 adapters for $9). Still have most of them somewhere.
High speed SD cards are as expensive as high speed industrial CF cards. Even high end SD cards tend to have poor random write speeds, i.e. about 10 MB/second. Good enough to replace an MFM hard drive but rather sluggish for actually using XP.
Thanks! I thought it was but couldn’t find any halfway official information.
I have not new seen adapters that cheap, but maybe I wasn’t looking hard enough. They are at any rate considerably cheaper than the CF cards themselves.
i did run a xp embedded/2009/pos from a industrial CF.it boots equally slow as with a hdd.
the problem is not on the disk-is xp fault.
when a first put xp on a k6/2 it was like new blood after 98…..a rocket no less.
with xp/sp3 i was disturbed to see the k6/2 go like a 386,no more.
if you want performance just use xp gold/orig.
how else would microevil bear xp for 18 years?(end to wepos/2009 in 2019)?
if you really want an update from wepos/2009 just disable system file protection,pluck the dll’s from the update package and throw ’em in the system….no mercy…edit registry by hand and whatever…
utility dmaonoff you can find in AdvantechTools.zip
dmaonoff and atcfwchg are both in the AdvantechTools.zip mentioned by janych: