IDE DOM Recommendations?

[lyonadmiral]

Does anyone have recommendations for DOM's that work well with your IDE in retro solutions such as XT-IDE?

 

[shirsch]

I've had great luck with the PQI 128MB modules. YMMV, however, since there's no way of knowing how many are marketed under that name.

 

[Plasma]

I have an Apacer DOM in a thin client. Seems to work fine. For anything slower than a 486, I'm not sure you would see an improvement over a CF card.

 

[Eudimorphodon]

For anything slower than a 486, I'm not sure you would see an improvement over a CF card.

Many DOMs literally are CF cards, IE, they use the same flash controller/interface ICs, just soldered to a 40 pin header instead.

 

[Timo W.]

I've had great luck with the PQI 128MB modules. YMMV, however, since there's no way of knowing how many are marketed under that name.

I'm using these as well, they work very reliable. They are also inexpensive.

Many DOMs literally are CF cards, IE, they use the same flash controller/interface ICs, just soldered to a 40 pin header instead.

Show a proof, please, as that is non-sense. It's like saying most SSDs are just USB sticks because they may use the same or very similar components.

Unlike CF cards, a DOM does not compromise the ATA standard. Also, they always use SLC flash cells (like industrial-grade CF cards normally do, but unlike any consumer-grade CF card).

 

[Eudimorphodon]

Show a proof, please

Okay. Here’s a picture of a 44 pin PATA DOM:

ICOP EmbedDisk 512MB 44 Pin IDE Flash (CD) Horizontal Left (Micron)

DetailsICOP EmbedDisk, 512MB 44 pin IDE flash (Micron NAND), "CD" Horizontal Left, 90 Degrees. Compatible with eBox 2300/2300J/2300SX, 3300, 3800, 4300, 4800/4800T/4850/4850T. MPN: DDOM-MN-512M-44P-H *Call for pricing*Obsolete, available while supplies last

www.wdlsystems.com

(40 pin DOMs usually have plastic cases on them.)

And here’s a link to manufacturer’s page about the controller clearly visible on it, touting its primary application, CF cards. (While also noting it’s applicable to other purposes, such as IDE DOMs.)

F9 | CF PATA NAND Flash Controller

Reliable NAND Flash Memory Controllers for highly reliable CompactFlash™, IDE & Parallel ATA SSD solutions. State-of-the-art NAND Flash Technology enables this NAND Flash Controller to support 3D as well as SLC NAND based Storage Solutions. High performance and a robust design guarantees...

www.hyperstone.com

Yes, most DOMs do use SLC(*), but so do industrial CF cards. You might have some hope a DOM manufacturer is a little more careful about firmware compatibility, etc, with IDE mode, sure, but DOMs at a hardware level are not going to be any more “performant” than an equivalent CF. Same guts.

*Edit: Take that “most” with a big grain of salt. There are plenty of MLC DOMs out there, especially if you’re looking at ones over a gig or two that aren’t freakishly expensive.

 

[Eudimorphodon]

It's like saying most SSDs are just USB sticks because they may use the same or very similar components.

... And no, just to make this clear, this is *not* a like situation, because unless the maker of the USB stick did something really goofy like stuff both a SATA FLASH controller and a USB-SATA bridge into his device the only components likely to be shared here are the flash chips. The controller chips I'm referring to as being the same between CFs and DOMs are the component that directly bridges the interface wires sticking out of the (CF|PATA) slot in the computer to the flash memory. You can claim all you want that DOMs universally (magically) "do not compromise the ATA standard" by whatever measure you believe CF cards *do* compromise it, but in those two classes of devices you're going to find exactly the same component with, very likely, the same OEM firmware, implementing whatever version of the ATA standard the chipset claims to support.

I've been finding it fairly difficult to find sufficiently detailed datasheets from 40 pin DOM manufactures to *really* grind this in (it seems like the people making them are understandably not keen on revealing exactly who's bridge chipset they're using), but for laughs/light reading Here's a *pretty decent* sheet for Amtron-brand DOMs. They never come right out and tell you that they're using a CF/PC-Card flash controller, but if you read the signal tables and footnotes you'll see multiple references to "True-IDE Mode" and mentions to PC Card signals that reveal very clearly that's what they're using. Here's another datasheet from OEM Fortasa, also making it clear they're using a CF card controller in their 40 pin DOM.

So... sure, turnabout is fair play if we're going to be flinging accusations of nonsense: Do you have proof that even one single manufacturer of DOMs is in fact using a "bespoke" IDE-only-because-that's-better-and-more-compatible-somehow chip instead of a CF controller?

The one place I'll yield here is, sure, the nice thing you get with a DOM is it's a plug-and-play one-piece unit that the manufacturer at least claims works in the slot you're plugging it into and you also don't have to worry about a sketchy CF-IDE converter creating mystery problems. But the comment I was replying to wasn't about that, it was if you could reasonably expect a DOM to perform better than a CF card. Performance as in speed. And that's clearly no, unless you're comparing DOM X with fast flash memory to CF card Y with slow memory. But considering that both very fast CF cards and dog-slow DOMs exist this is a different issue.

 

[Plasma]

Ok, but are most people using industrial CF cards in their vintage PCs? There are a lot of less than stellar CF cards out there.

 

[Eudimorphodon]

Ok, but are most people using industrial CF cards in their vintage PCs? There are a lot of less than stellar CF cards out there.

There are also a lot of MLC DOMs out there, or tiny DOMs using antique, slow controllers and flash chips. The primary application for DOMs is embedded computers and network appliances where bad performance and limited write durability isn’t a huge problem, so I would very much question the assumption that your “average” DOM is more performant that your “average” CF card. (I mean, a very typical application for CF cards is high pixel count digital SLR cameras, where write performance *is* a serious consideration.) Are there benchmarks you’re thinking of that demonstrate a consistent difference?

 

[Plasma]

I disagree about "limited write durability", and performance is relative. A modern SSD with a SATA/IDE adapter will wipe the floor with both. But that's overkill for a lot of vintage gear.

I seem to recall you heavily promoting SD to IDE adapters over CF cards a couple of years ago, due to your bad experience with CF ("In my jaded experience CF cards are junk.")

So I find it odd that you're now a CF proponent...

 

[mbbrutman]

I wouldn't bother with an IDE disk-on-module at this point; they are too small for the value.

Go with a StarTech SATA to IDE bridge (adapter) and a low end SATA SSD. The total solution costs less than $50 new and you get an SSD which is far larger than any CF card or disk-on-module for the same money. And SSDs have proper wear leveling.

 

[Eudimorphodon]

So I find it odd that you're now a CF proponent...

I'm not, but I also think people should be fully informed when evaluating the various options. People keep repeating like it's gospel that DOMs are fundamentally different and "always better" than CF cards. And that's technically not true; they're just CF cards in a funny package.

To be clear, here, I'm not saying that packaging difference is "worthless", mind you: it if of at least some value that the manufacturer is willing to mostly guarantee the unit work when plugged into an ATA controller that doesn't specifically know anything about the PCMCIA flash extensions, and bad/cruddy PATA/CF adapters are definitely a thing that can ruin your day. With a CF card you *are* technically rolling the dice whether the manufacturer of either your card or the adapter screwed up somehow, there are also some other edge case considerations, like the "removable" flag that's going to be set on most cards causing issues with specific OSes and whatnot.

But on the flip side, new DOMs usually cost significantly more than the same amount of CF, new DOMs, especially in larger sizes, are likely to have the same compatibility issues as large/new CF cards (bad support for CHS addressing, for instance), and, again, the *interface* is exactly the same in terms of speed and transfer mode support, so it's delusional to assume that a DOM will always perform better. People should know what they're really paying for.

I seem to recall you heavily promoting SD to IDE adapters over CF cards a couple of years ago, due to your bad experience with CF ("In my jaded experience CF cards are junk.")

To clarify this, and it's a big clarification, my beef with CF cards is specifically with how scattershot their compatibility is with 8-bit XTIDE subsets (XT-CF) is. At one point I when through a box of two dozen industrial CF cards in various sizes between 128MB and 2GB, pulled from old network appliances testing them for compatibility with my particular XT-CF cards (of two different designs, one a straight rip of the lo-tech one, the other a homebrew I designed using GALs) and only about a third of them from two specific OEMs reliably passed a data corruption stress test.

*Every* SD-IDE adapter I've tried, both 40 pin and 44 pin, I've tried in this same situation, has worked flawlessly. Thus I'm firmly convinced that whatever you think of the concept of PATA-SD as a general purpose solution for old IDE adapters in this particular edge case the chip used in the Sintech-style adapters is a safer choice for supporting this particular protocol variation than any random CF card, and thus why I recommend them.

Here's the thing, though: every single one of the CF cards I tried from that box of failures tested *flawlessly* when connected via the same PATA-CF adapters I was using with the XTIDE card to one of those universal USB-to-PATA adapters. IE, they all formatted perfectly and showed no sign of data corruption when exercised via a full 16 bit IDE port in "True-IDE" mode. Thus I actually have no gripe against them for use in the sort of "486 or better" computer you mentioned, and I would guess (and there's some threads on Vogons that support my suspicions here) that on these newer computers any performance difference you see between a CF and "DOM" is going to be entirely up to the attributes of that particular device.

... And that's the irony here, isn't it? The OP is asking about DOMs for use with XTIDE class adapters. XT-CF subsets fall into that category, so... I dunno, have you tried a 40 pin DOM with an XT-CF card? I actually have no idea if it works, either sometimes or always, because I haven't tried that myself. My vague guess would be that they *might* work, since as I've explained, they're using CF chipsets and 8-bit support is part of the CF standard, but I also highly doubt they've tested it because these devices are, after all, specifically designed to be used in standard 16 bit IDE ports.

So, sure, my recommendation to the OP would actually be to use a PATA-SD card adapter for this class of machine because, in my experience, the performance of these adapters is excellent, as is the compatibility, which I cannot say for random old CF cards. And then everyone can flame over that again.

I disagree about "limited write durability", and performance is relative.

Everything I've ever pulled a DOM out of (and I do have a small collection of them, but they're all useless 44 pin ones with reversed connectors; I could technically try one using my homebrew XT-CF that I designed to direct-plug 44 pin PATA-SD or PATA-CF sleds into, but I'd have to solder a different connector onto one and it's not worth it for a tiny DOM that may or may not work) is the sort of thing that the only processes that that ever touch the DOM are booting, firmware updates, and a little light logging. So, no, performance doesn't matter.

A modern SSD with a SATA/IDE adapter will wipe the floor with both. But that's overkill for a lot of vintage gear.

Yes, probably, although with the fastest CF cards (and, sure, there might be PATA DOMs just as fast) the limiter will probably be the speed of the IDE port anyway. Also, don't forget, even today there are *really cruddy* modern SSDs in circulation (dirt-cheap little MLC M.2 or MSATA modules you'll find in some chromebook-level machines) that aren't going to blow the doors off of anything. But again, given the OP is asking for something compatible with XTIDE, who cares. Even the slowest flash device will do the job...

And for laughs, I did try, and no, the PATA-MSATA bridge I bought to stick in a Powerbook G4 didn't work with my 8-bit XT-CF card.

 

[Plasmo]

Some of my vintage computer designs can use either 44-pin CF adapter or DOM interchangeably without software changes. Physically DOM pin assignments are mirrored from CF, so I either plug in from the top or from the bottom to compensate for the mirrored pinout. From software driver point of view, they are the same. From price point of view, they are about the same as well. CF and DOM are very similar from my point of view. Here I’m talking about older DOM and CF of 1 Gbytes or smaller.
Bill

 

[mbbrutman]

In case this helps anybody, here is a picture of the Startech SATA to IDE bridge connected to a Kingston SSD. The IDE adapter is the jrIDE that is on my PCjr web server.



The Kingston SSD is a 2.5" device and it's sitting above the 3.5" floppy drive. You can fit this solution nearly anywhere.

 

[Eudimorphodon]

Go with a StarTech SATA to IDE bridge (adapter) and a low end SATA SSD. The total solution costs less than $50 new and you get an SSD which is far larger than any CF card or disk-on-module for the same money. And SSDs have proper wear leveling.

FWIW, if you do have an 8-bit XT-CF setup that won't get along with a 16 bit PATA-SATA bridge what I use is a $15 PATA-SD bridge fitted with a currently $11 64GB Samsung Pro Endurance (video rated) memory card. (So $26 in total.) The price per gig is worse than the SATA setup with the 64GB card, but looks to be about even with it if you bought a 256GB one for $35. Not that it really matters, unless you jump through weird hoops you can't use more than 8GB with conventional DOS anyway.

Anyway. These cards are rated for continuous overwrite operation in video surveillance systems and according to my math against Samsung's performance claims the 64GB card should last over 32 years before hitting its write limits if, the entire time, all the computer was doing was running a tight assembly-language program that did nothing but pound on the disk at the ~400KB/s rate that James Pearce's DISKTEST.EXE benchmarks the disk's write performance at. (This becomes 120+ years if I'd bought the 256GB card.) No actual program running on an XT class computer is going to be able to do anything meaningful with the disk at a rate even approaching this number. But, nonetheless, if we want to compare this to a cheap SSD like the Kingston (I went with the A400 series, they're the cheapest and the current price of the 240GB model aligns with the $50-for-drive-plus-bridge number), their TBW for the 240GB drive is only 80TB. That seems shockingly low, but it actually aligns with with the claim in this post that the wear-out counter on the poster's 240GB A400 went down 4% after only about 2TB's worth of writes.. So...

Wow. I'm actually not sure what to think of this result, because when I do the math on Samsung's performance claims for the Pro Endurance card I pencil out the TBW for the 64GB card as:

35,040 hours x 3600 seconds in an hour x 3.25 MB/s = 409,968,000 megabytes = 409 TBW

If this is to be believed the *smaller* SD card is claiming to last five times longer than the Kingston SSD. Some guy on Reddit did the same math and his numbers line up with mine. Even Kingston's own high-endurance SD cards have better TBW than what they warranty for their cheapest SSDs? In said Reddit thread there are people who argue that this comparison might be invalid because of random vs. sequential writes or caching or whatever, but the A400 doesn't appear to have a dedicated cache and I'm not even sure that argument pencils out in the case of anything but a swap file-type situation, but... huh.

At this point all I'm going to toss out here is that maybe automatic assumptions about thing X being better/more durable than thing Y might not necessarily be valid? I'm not saying that the TBW of the cheapest SSD you can lay your hands on is ever going to be a problem in a vintage computer, far from it. (I've heard good things about the jrIDE, but I'm going to guess it'd take a while to spit out 80TB of data.) But it does seem like there's a lot of claims out there essentially boiling down to "every SSD has better wear leveling/durability than any SD card" that don't appear to be very well supported.

And, yeah, I'll be eating crow if the SD card or adapter in my Tandy 1000 melts tomorrow. But it has been running for like four years now and it's my retro "daily driver". (Not a webserver, though, I'll grant that.) So I'm not terribly worried. (And if it does blow up... it's $11. You can't even go to McDonalds for that anymore.)

 

[mbbrutman]

I stand by it. It's a generalization or a rule of thumb. If we start diving into the specifics of individual model numbers of parts then we don't have enough time in the universe to spell it out all out.

The generalization is that SSDs are designed to replace hard drives, and therefore have wear leveling algorithms and features that match their intended uses. SD cards are not designed as hard drive replacements, so while they might work that is not the intended usage pattern. (Hard drives used on OSes tend to pound certain LBAs harder than others, hence the need for good wear leveling. SD cards are probably designed for more sequential usage patterns.

One can also generalize and say that any modern high capacity SD Card from a reputable manufacturer is probably good enough. Let's talk again in 30 years to see which devices are still working.

 

[Eudimorphodon]

I stand by it. It's a generalization or a rule of thumb. If we start diving into the specifics of individual model numbers of parts then we don't have enough time in the universe to spell it out all out.

If you don't have anything to support it other than statements like "SD cards are probably designed for more sequential usage patterns" doesn't that essentially just reduce "generalization" to blind faith/FUD?

Only other thing I'm going to say here is the difference between paying $50 for an SD card verses an SSD is in one instance you're getting a positively gold-plated example of the breed while with the other you're getting the absolute bottom of the barrel. Seems a little odd to assume you're getting everything you get with the $200 SSDs with the $50 one just because it comes in a similar box. If you're buying a dirt-cheap SSD with no writeback DRAM might it be a reasonably good assumption that it's using a wear algorithm very similar to any other device that lacks it... like, say, your typical SD? But hey, without looking at secret data sheets I suppose that's also FUD.

Anyway, sure. Gotta say, though, I kind of suspect the rest of my Tandy 1000 will be dust before 30 years has passed, especially if I go through the trouble of keeping it powered on 24/7/365 explicity to try to wear out a flash device that is known to last at least a few years in much more modern devices that run many orders of magnitude faster.

 

[mbbrutman]

I think we have a misunderstanding here. There is no intent to spread FUD, and I don't see anybody trying it.

I pointed out that SSDs provide proper wear leveling because they are designed as hard drive replacements. I also pointed out that they are generally cheaper per gigabyte than current CF cards or disk-on-modules. That statement was made in the context of CF cards and disk-on-modules.

You brought up SD Cards, and you pointed out that the high endurance ones might be comparable. I have no argument with that. SD cards were designed for cameras and cell phones; it's a different use case from being the primary storage device for an operating system. All SD cards are not created equal, which is why the "industrial" class of cards has to highlight their write endurance and wear leveling properties. Which kind of proves my point that that in general SD cards are not designed for that use case.

Yes, a gold plated version of one thing can be better than the lower end version of another thing. But once again, if we're going to try to catalog every device and exception we'll never have enough time or space. Which is why generalizations are useful.

We've done our job here; the OP is aware of additional factors and options.

 

[mbbrutman]

One other note ...

Looking for actual research papers or white papers on SD card requirements for wear leveling I came up with zilch. But in my digging the following themes emerged:

• Early SD cards did not do wear leveling because the size of the FLASH cells was fairly large at the time, giving each cell 10s of thousands of write cycles.
• As smaller FLASH cells came into use some sort of wear leveling was required, because as FLASH cells shrink in size they have less write endurance.
• CF and SD cards often were optimized for FAT filesystems, choosing algorithms that made the first parts of the card more durable than the other parts knowing that is where the FAT updates would be happening.

Anyway, a modern SD Card is probably fine given that all of the good manufacturers were probably forced to implement good wear leveling by this point.

 

[Eudimorphodon]

We've done our job here; the OP is aware of additional factors and options.

Agreed.

FWIW, I mostly just wanted to give a concrete example of the setup I use with an 8-bit-only “XT-CF” variant. (They’re pretty common these days, and I have yet to find an SSD bridge that supports 8-bit IDE. Granted I’ve only tried… 3?) Inadvertently fell down the MTBF/TBW rabbit hole because, well, it is pretty crazy just how much variation there is across the industry.

(I always specify the name brand “endurance“ SDs because it‘s very true that old and/or cheap SDs, like old/cheap/knockoff other flash devices, can be just horrible. You do get what you pay for.)