I recently installed an IDE to CF card adapter in my 486 machine. I am still using my NOS Maxtor HDD as my C drive and the CF card as my D drive as a full backup for my C drive. Due to solid state drive failures over the years, I have never been too trustful of SSDs and USB thumb drives, but not much experience with CF cards. I've found mechanical hard drives to be most long term reliable, for example in my home file server. I'm wondering if maybe I should reverse what I'm doing in my 486 and use the CD card as C and the Maxtor on D as my backup? Any opinions about this, as far as reliability? I assume the CF card is faster than the Maxtor HDD, but I don't know that for sure.
| VCF Midwest | Sep 12 - 13, 2026, | Schaumburg Convention Center, IL |
| VCF Montreal V2.0 | Nov 07 - 08, 2026, | Saint-Lambert, Montreal, Canada |
| VCF SoCal | Feb TBD, 2027, | Southern CA |
| VCF East | Apr TBD, 2027, | InfoAge, Wall, NJ |
| VCF Latam | TBD, 2027, | Bahía Blanca, Argentina |
| VCF Pac. NW | TBD , 2027, | Tukwila, WA |
| VCF Southwest | Jun 25 - 27, 2027, | Westin Dallas Fort Worth Airport |
| VCF Southeast | Aug TBD, 2027, | Atlanta, GA |
| VCF West | Aug TBD, 2027, | Mountain View, CA |
-
Please review our updated Terms and Rules here
CF card vs HDD
- Thread starter allenm
- Start date
I would use the mechanical drive as the main drive, as afaik flash memory wears out by writing but not reading.
Or rather have things you only read on the CF card and have any temp stuff and whatnot on the mechanical drive.
For example install DOS and Windows on the CF card but have temp, swap and whatnot on the mechanical disk.
Don't know what type of mechanical disk you have but I think there probably are plenty of PATA/IDE disks available, so as long as you have a backup you can always replace it.
(Anecdote: A while ago I knew people who worked with repair/upgrade of video games, and thanks to that I have a bunch of 10GB Seagate PATA/IDE disks that came with XBox video game consoled (then only the first 8GB was used). These disks might be slow by the standards of that time, but they are super fast as compared to what you'd have in a 486 back in the days, and they are also dead silent. Thus if someone who reads this somehow come across these disks they might be a good buy. Just ensure that you can actually write to them. Afaik there are ways to reset the firmware passwords that wasn't available 10-15 years ago, so disks deemed "locked, unknown password, junk" and ended up in a pile that no one bothered to throw away might have become usable thanks to better password reset tools).
Or rather have things you only read on the CF card and have any temp stuff and whatnot on the mechanical drive.
For example install DOS and Windows on the CF card but have temp, swap and whatnot on the mechanical disk.
Don't know what type of mechanical disk you have but I think there probably are plenty of PATA/IDE disks available, so as long as you have a backup you can always replace it.
(Anecdote: A while ago I knew people who worked with repair/upgrade of video games, and thanks to that I have a bunch of 10GB Seagate PATA/IDE disks that came with XBox video game consoled (then only the first 8GB was used). These disks might be slow by the standards of that time, but they are super fast as compared to what you'd have in a 486 back in the days, and they are also dead silent. Thus if someone who reads this somehow come across these disks they might be a good buy. Just ensure that you can actually write to them. Afaik there are ways to reset the firmware passwords that wasn't available 10-15 years ago, so disks deemed "locked, unknown password, junk" and ended up in a pile that no one bothered to throw away might have become usable thanks to better password reset tools).
Al Kossow
Documentation Wizard
CF is the oldest of the technologies, and unless you are using industrial-grade CFs you need
to worry about them wearing out, especially with software that hits the same sector repeatedly.
I would hope the modern ones do proper wear leveling, but the early ones designed for things
like digital cameras did not.
All NAND based tech is a race to the bottom as far as reliability goes, and you can't even
talk about price any more thanks to large corporations buying up all of the solid-state
storage manufacturing capacity.
It all depends on how much use the 486 will get and what OS you are running. DOS is fine; Win9x is bad, so is Windows 3.1 with virtual memory enabled.
Flash-based memory is not good for long-term data storage when not in use. The data will just fade into oblivion. The more writes are done to the flash cells, the faster the data will fade, as every write will cause damage to the cells. As long as you use the system regularly, this is not much of an issue, as the controller will detect and refresh weak cells. But you may find the CF card wiped or corrupted if you put it into storage for some years...
I use CF cards in many systems as the main drive and simply create an image file once the system has been set up. This way, I can just write the image back to a CF card if any data is lost. I still prefer real hard disks and use them whenever possible, however.
Flash-based memory is not good for long-term data storage when not in use. The data will just fade into oblivion. The more writes are done to the flash cells, the faster the data will fade, as every write will cause damage to the cells. As long as you use the system regularly, this is not much of an issue, as the controller will detect and refresh weak cells. But you may find the CF card wiped or corrupted if you put it into storage for some years...
I use CF cards in many systems as the main drive and simply create an image file once the system has been set up. This way, I can just write the image back to a CF card if any data is lost. I still prefer real hard disks and use them whenever possible, however.
I'm going to leave the Maxtor HDD as C: and just periodically xcopy it to the CF card. I'm not into gaming, just programming, so it's not like these drives are constantly being written to. The CF card in my IBM XT is the main drive, but that's a different story.
CF cards seem to work pretty well. Am using one as the primary hard drive for a PC running NeXTStep and it works really well. I back it up to my Mac or Linux using dd from time to time. Did another for a W2K setup as my IDE drive was failing ... works great for SP3, not so much so for SP4 ( something seems to have changed ). Have yet another with DOS 6.22 on it. For disks that you are going to use sparingly it's a nice answer. As others pointed out, if you were going to be hitting a spot over and over you do run the risk of failure, but a spare CF card and good backups alleviate a lot of that, and having a few CF cards lying about is a lot easier than trying to figure out how to make multiple partitions boot multiple operating systems .......
Plasma
Veteran Member
- Joined
- Nov 7, 2005
- Messages
- 3,148
Well anything can fail. I've had several hard drives and two SSDs fail. IMO the most reliable storage option for regular use would be an SLC SSD (from a reputable brand) with a SATA to IDE adapter. When SSDs fail, you can usually still read from them but not write. SLC SSDs will retain data for 5-10 years without power.
Most CF cards don't have wear leveling, so they aren't ideal for use as operating system drives. But if your OS doesn't use virtual memory, you can get away with a CF card. I don't think they are any more reliable than a good SSD though, and almost always slower.
The most important thing is to keep backups.
Don't know what else you have, but you could also network it with a more modern computer.
In particular if you have a more modern computer that runs Linux you could have an additional network card in the Linux computer (or even configure a single network card to have two different IP addresses, on different subnets, but then you'd need to do some special configuration to get DHCP going for the additional subnet running on the same physical network) and have a separate instance of Samba configured to only bind to the IP that talks to the vintage computer, and configure it so it mostly only has read access except for dedicated "vintage stuff" directory it's allowed to write to, and also configure Samba to allow the older insecure protocol versions/whatnot. That way you can use the old DOS clients and the client built in to Windows for Workgroups 3.11 (which is pretty fast for what it is btw).
bsdphk
Experienced Member
Allow me to lecture for a minute, because there are some things which are important to know about Flash storage:
1. None of the flash technologies are archive-quality.
This is inherent in the physics, flash will forget the bits if you write them, if you dont write them, if you read them, due to cosmic radiation and simply as time goes by.
FLASH IS SIMPLY NOT A SUITABLE ARCHIVE MEDIUM!
2. Flash is not just flash, but you can generally ignore that, because:
3. The most important factor in flash-wear mechanisms, is the "Flash Adaptation Layer" and how good it is at "Wear Leveling"
If you are using raw flash chips, you own that job yourself. If you just write a new firmware once in a blue moon, so you can ignore it entirely.
If you are using CF, SD, SSD, SAS, NVME or any other "cooked" flash, the Flash Adaptation Layer runs on a microcontroller inside the device.
All Flash Adaptation Layers deal with the same basic problem: You erase (much) larger blocks than the desired sector-size, and you cannot overwrite a sector.
Flash Adaptation Layers are therefore for all practical purposes filesystems.
When the computer writes to sector 445, the FAL must find empty space for a new "file", create it, write the data to it, and register the name ("445"), and if a file with that name previously existed, add the space that file occupied to the "to be erased list".
If all sectors in an erase-block are on the "to be erased list", life is wonderful, because the FAL can erase the block and add all the sectors to the "free" list.
The bad case, is that the FAL may run out of free space, in which case it has to find the "optimal" erase-block, copy all still-alive sectors out of it, and then erase the block to free up the previously used, but since retired sectors. (It follows, that some number of erase-blocks must always be held in reserve.)
This is called "write amplification": The computer writes a single sector, but physically many sectors are (erased and) written on the flash chip(s).
That will wear out the flash cells faster than you expect them to.
It is also, obviously, slow.
And fundamentally totally, utterly, stupid - unless optimized.
Imagine you write a single file which takes up all sectors on your CF card, and then you delete it again, and write another file which just needs a single sector.
The FAL does not know that you deleted the huge file, so it has to treat all those sectors as still valid, except for the single one you write.
"Wear leveling" is proprietry algorithms inside the FAL, which attempts to minimize this, while trying to spread the erase and write operations over all the erase blocks, to make the device last longer.
As a rule of thumb: The larger the "hidden" reserve of erase-blocks are, the longer the device will last.
But to avoid the stupidity, in addition to READ and WRITE, we now also have the DELETE primitive.
(Also known as "TRIM" and various other names, because the storage vendors are morons.)
The DELETE operation is used by the operating system to inform the FAL, that the content of a particular sectors are no longer wanted, allowing the FAL to move them directly on the "to be erased" list, vastly increasing the probability that erase blocks can be recycled with minimal write amplification.
In the above example, deleting the huge file should cause the OS to issue DELETE operations for all the file's sectors, and the FAL could start erasing all the blocks right away, without write-amplification, and without waiting for all the sectors to be overwritten.
There are basically three grades of FAL's: "Camera grade", "Consumer" and "Enterprise".
Any flash-media primarily aimed for camera use, CF, SD etc. is (almost) guaranteed to have first one, which is optimized for the single use case, where huge files are written sequentially in a FAT filesystem.
That allows the FAL to cut a LOT of corners, without loosing any performance in that specific application.
But if you stick a regular filesystem on a camera grade FAL, and do lots of single sector random writes, it becomes horribly slow over time.
As in: A single sector write can take tens of seconds.
The primary reason it degenerates so badly, is that Camera grade FAL only has one "open" erase-block at time, due to the limited RAM in the microcontroller, and cannot do anything else, while a block is being erased.
Camera-grade FAL didn't used to understand/support DELETE, but some high-end "Industrial" SD cards seem to do so now.
Some Camera-grade FAL's tried to be smart, by recognizing FAT filesystems, monitoring the cluster-table and creating their own DELETE operations when files were deleted.
If you used such a device for another kind of filesystem, while the FAL thought there was a FATfs on it, life became interesting. (This is what got me into flash 20+ years ago).
Some contemporary camera-grade FAL's seem to recognize a "format" where an empty FATFS is created, and uses the chance to erase everything.
All in all: If you write randomly, camera-grade FAL is not what you want, and the longer you use it that way, the slower it becomes.
(I'm beating up a couple of Kingston "industrial" microSD cards, they are clearly better for random writes than average microSD, but how much better is still TBD.)
Your regular 2.5"/MSATA SSD's and NVME sticks have consumer-grade FAL, to which the vendors added support for DELETE only when Microsoft got shitty about it.
The primary hardware difference is that the embedded microcontroller is faster and has more RAM, so it can keep track of multiple eraseblocks being "open" at
the same time, and usually it can erase one block per flash chip, while still serving traffic from the non-erasing flash-chips, and in high end consumer devices,
also service traffic from flash-chips while they erase block(s).
The quality, number of bugs and available features varies greatly.
Enterprise FAL has lots of bells and whistles, including keeping track of which blocks have been used how much, patrolling all the valid data, and evacuating it if the error correction code gets too unhappy etc.
The devices often also have a lot of DRAM and ultracapacitors, so they can cache things and still shut down safely.
Very interesting stuff, many patents, very expensive, but if your data and performance is important, your data and performance is important.
NVME has started to move in a direction where more of the OS's filesystem is handled by the FAL, so that instead of single sectors, you operate on multi-sector "objects" which, ideally, correspond to the files in the OS's filesystem.
In theory a good idea and, depending on your religion, the right direction architecturally.
In practice it has proven nearly impossible to migrate to. (See also: Intel Optane)
Final bit of advice:
If your SSD vendor tells you to upgrade the microcode in your SSD storage, do so, but only after making a backup of your data first.
Hope this helps, happy to answer questions.
Poul-Henning
Aka: The guy who ported M-Systems's Disk-On-Chip FAL to FreeBSD 20+ years ago.
1. None of the flash technologies are archive-quality.
This is inherent in the physics, flash will forget the bits if you write them, if you dont write them, if you read them, due to cosmic radiation and simply as time goes by.
FLASH IS SIMPLY NOT A SUITABLE ARCHIVE MEDIUM!
2. Flash is not just flash, but you can generally ignore that, because:
3. The most important factor in flash-wear mechanisms, is the "Flash Adaptation Layer" and how good it is at "Wear Leveling"
If you are using raw flash chips, you own that job yourself. If you just write a new firmware once in a blue moon, so you can ignore it entirely.
If you are using CF, SD, SSD, SAS, NVME or any other "cooked" flash, the Flash Adaptation Layer runs on a microcontroller inside the device.
All Flash Adaptation Layers deal with the same basic problem: You erase (much) larger blocks than the desired sector-size, and you cannot overwrite a sector.
Flash Adaptation Layers are therefore for all practical purposes filesystems.
When the computer writes to sector 445, the FAL must find empty space for a new "file", create it, write the data to it, and register the name ("445"), and if a file with that name previously existed, add the space that file occupied to the "to be erased list".
If all sectors in an erase-block are on the "to be erased list", life is wonderful, because the FAL can erase the block and add all the sectors to the "free" list.
The bad case, is that the FAL may run out of free space, in which case it has to find the "optimal" erase-block, copy all still-alive sectors out of it, and then erase the block to free up the previously used, but since retired sectors. (It follows, that some number of erase-blocks must always be held in reserve.)
This is called "write amplification": The computer writes a single sector, but physically many sectors are (erased and) written on the flash chip(s).
That will wear out the flash cells faster than you expect them to.
It is also, obviously, slow.
And fundamentally totally, utterly, stupid - unless optimized.
Imagine you write a single file which takes up all sectors on your CF card, and then you delete it again, and write another file which just needs a single sector.
The FAL does not know that you deleted the huge file, so it has to treat all those sectors as still valid, except for the single one you write.
"Wear leveling" is proprietry algorithms inside the FAL, which attempts to minimize this, while trying to spread the erase and write operations over all the erase blocks, to make the device last longer.
As a rule of thumb: The larger the "hidden" reserve of erase-blocks are, the longer the device will last.
But to avoid the stupidity, in addition to READ and WRITE, we now also have the DELETE primitive.
(Also known as "TRIM" and various other names, because the storage vendors are morons.)
The DELETE operation is used by the operating system to inform the FAL, that the content of a particular sectors are no longer wanted, allowing the FAL to move them directly on the "to be erased" list, vastly increasing the probability that erase blocks can be recycled with minimal write amplification.
In the above example, deleting the huge file should cause the OS to issue DELETE operations for all the file's sectors, and the FAL could start erasing all the blocks right away, without write-amplification, and without waiting for all the sectors to be overwritten.
There are basically three grades of FAL's: "Camera grade", "Consumer" and "Enterprise".
Any flash-media primarily aimed for camera use, CF, SD etc. is (almost) guaranteed to have first one, which is optimized for the single use case, where huge files are written sequentially in a FAT filesystem.
That allows the FAL to cut a LOT of corners, without loosing any performance in that specific application.
But if you stick a regular filesystem on a camera grade FAL, and do lots of single sector random writes, it becomes horribly slow over time.
As in: A single sector write can take tens of seconds.
The primary reason it degenerates so badly, is that Camera grade FAL only has one "open" erase-block at time, due to the limited RAM in the microcontroller, and cannot do anything else, while a block is being erased.
Camera-grade FAL didn't used to understand/support DELETE, but some high-end "Industrial" SD cards seem to do so now.
Some Camera-grade FAL's tried to be smart, by recognizing FAT filesystems, monitoring the cluster-table and creating their own DELETE operations when files were deleted.
If you used such a device for another kind of filesystem, while the FAL thought there was a FATfs on it, life became interesting. (This is what got me into flash 20+ years ago).
Some contemporary camera-grade FAL's seem to recognize a "format" where an empty FATFS is created, and uses the chance to erase everything.
All in all: If you write randomly, camera-grade FAL is not what you want, and the longer you use it that way, the slower it becomes.
(I'm beating up a couple of Kingston "industrial" microSD cards, they are clearly better for random writes than average microSD, but how much better is still TBD.)
Your regular 2.5"/MSATA SSD's and NVME sticks have consumer-grade FAL, to which the vendors added support for DELETE only when Microsoft got shitty about it.
The primary hardware difference is that the embedded microcontroller is faster and has more RAM, so it can keep track of multiple eraseblocks being "open" at
the same time, and usually it can erase one block per flash chip, while still serving traffic from the non-erasing flash-chips, and in high end consumer devices,
also service traffic from flash-chips while they erase block(s).
The quality, number of bugs and available features varies greatly.
Enterprise FAL has lots of bells and whistles, including keeping track of which blocks have been used how much, patrolling all the valid data, and evacuating it if the error correction code gets too unhappy etc.
The devices often also have a lot of DRAM and ultracapacitors, so they can cache things and still shut down safely.
Very interesting stuff, many patents, very expensive, but if your data and performance is important, your data and performance is important.
NVME has started to move in a direction where more of the OS's filesystem is handled by the FAL, so that instead of single sectors, you operate on multi-sector "objects" which, ideally, correspond to the files in the OS's filesystem.
In theory a good idea and, depending on your religion, the right direction architecturally.
In practice it has proven nearly impossible to migrate to. (See also: Intel Optane)
Final bit of advice:
If your SSD vendor tells you to upgrade the microcode in your SSD storage, do so, but only after making a backup of your data first.
Hope this helps, happy to answer questions.
Poul-Henning
Aka: The guy who ported M-Systems's Disk-On-Chip FAL to FreeBSD 20+ years ago.
pbirkel
Veteran Member
What's actually inside one of those?
bsdphk
Experienced Member
The first generation was a propriety controller chip and a variable number of flash chips.
The second generation integrated the controller on the flash-chip, but by then CF cards had taken over.
The "killer-feature" of the Disk-On-Chip was that their pinout matched an EPROM socket, for instance the "boot-prom" socket on ISA network cards, and came out of reset looking like one.
The default code on that "boot-page" munges the BIOS vectors, to register a "harddisk", but given enough money to M-systems, you could have your own code there too.
For the time, they were pretty neat devices, and thanks to a photocopier-manufacturer, the reason FreeBSD was the first operating system with support for flash and the DELETE operation, a decade or more before any other OS saw the need.
M-systems aggressively patented everything they could think of, which is why SanDisk bought them, once the Disk-On-Chip had run out of steam.
They were also a bunch of right assholes, who moved heaven and earth to make me write the driver, only to give me a three month runaround when it came to paying my invoice.
I didn't get my money until I pointed out, that their non-payment violated the entire contract, including the non-disclosure provisions, and that unless my invoice was paid in full by the end of the week, I were free to, and absolutely would, post their entire source-code publically.
pbirkel
Veteran Member
Thank you for the insights. Is the DOM (Disk on Module) approach the same?
bsdphk
Experienced Member
I never worked with those, but I suspect it is the same thing ?
There's a lot of info here: https://www.digital-circuitry.com/MyLAB_IC_PROG_DISKONCHIP.htm
There's a lot of info here: https://www.digital-circuitry.com/MyLAB_IC_PROG_DISKONCHIP.htm
pbirkel
Veteran Member
I think that you're right. Just a different system interface. probably similar to their ISA flash cards in concept. Thank you for the reference!
Eudimorphodon
10k Member
All the PATA DOMs I've seen for sale for *years* are just funny shaped CF cards. I mean, literally, if their datasheet is available and tells you what's in it the flash controller chip will inevitably turn out to be a part that is primarily sold for use in CF cards; all the DOM does is solder it straight onto a 40 pin connector and use the True IDE functionality of the chip.
One big plus for the DoM is that it can, in some situations, like my 386, just plug in right on top of the controller with no cable needed. I like that.
Eudimorphodon
10k Member
They sell CF adapter sleds that can direct plug right into an IDE host connector, but admittedly clearance is often an issue with those.
Modern flash will notice fading data and rewrite it automatically on reading. So having a tool read each sector on the device periodically may be a good thing; we do that professionally because, as Al said, the technology is a race to the bottom.
bsdphk
Experienced Member
No, the flash itself does not, but the microcontroller running the FAL does.
However, that only works if the device is powered up.
Which is why: FLASH IS SIMPLY NOT A SUITABLE ARCHIVE MEDIUM!