AppleSauce wrote on 2024-02-07, 14:54:

Also are you sure that the star tech ones are all right , I've read about some people having issues with them?

I've ordered and used over a dozen CF-IDE adapter (mostly Startech models) and never had an issue with any of them.

Since CF cards can use IDE natively, the adapters are basic devices usually with a handful of components at most. There is little that can go wrong on these devices.

George Razvan wrote on 2024-02-08, 19:02:

CF cards never had trim because they were never inteded to replace hard drives. I don't see CF as a solution, unless used with Dos and Windows 3.11,and for 486 or below only.

Pretty sure Western Digital’s “silicon drive” line of CF’s was designed to replace hard drives, even if they were pretty slow. And if we go farther back, IBM micro drives actually had little spinning platters inside the CF.

TRIM has been part of the standard for almost 14 years. Now whether or not it was implemented on your device, and if it was, whether or not it is accessible from your OS, those are harder questions to answer.

https://en.m.wikipedia.org/wiki/CompactFlash# … ation_revisions

CompactFlash Revision 6.0 (November 2010) added UltraDMA Mode 7 (167 MB/s), ATA-8/ACS-2 sanitize command, TRIM and an optional card capability to report the operating temperature range of the card.

stanwebber wrote on 2024-02-06, 22:02:

consider sata ssd with ide adapters instead of compact flash. it will likely be faster and considerably cheaper than the premium cf equivalents. even moderately priced brand-name industrial cf cards can underperform 20yr old mechanical hdd models (at least with seq read/writes).

Why are SATA drives faster than CF cards? They are both bottlenecked by the PATA interface. Do CF cards just use slower flash memory?

demiurge wrote on 2024-02-11, 16:03:

Why are SATA drives faster than CF cards? They are both bottlenecked by the PATA interface. Do CF cards just use slower flash memory?

Thats a good question. Some of it might be slower flash, but I think the age of the device internals and the design optimizations also played a big role.

Here are my thoughts:

• The oldest CF devices had been around since the mid 90’s, ATA2. If you get a device with a controller design thats older than your retro computer, the device could be at a protocol disadvantage.
• Most 40 pin doms wont go faster than ATA 33 unless they have a hardware mod or a special cable.
• I did a survey of the firmware on some Industrial CF’s & DOM’s and the firmware on the CF’s and Dom’s was <= 2008, except for hyperdisk which had 2014&2015.
• There are newer PATA CF’s that do ATA-8 / UDMA7 but they are often optimized for guaranteed thoughputon intensive write operations like recording video instead of read/write random file access latency
• Sata devices have controller’s designed to work with 150MB/s to 600 MB/s speeds, so they likely have newer controllers made on better CMOS processes with better buffers, capacitor backed write buffers, etc.
• Did CF & Doms have more restrictive power and heat requirements? Cant find a citation, but it seems likely that heat and power constraints played against performance in the design process.

Edit: But all of this sorts of blurs away f you are using an ISA drive controller.

demiurge wrote on 2024-02-11, 16:03:

stanwebber wrote on 2024-02-06, 22:02:

consider sata ssd with ide adapters instead of compact flash. it will likely be faster and considerably cheaper than the premium cf equivalents. even moderately priced brand-name industrial cf cards can underperform 20yr old mechanical hdd models (at least with seq read/writes).

Why are SATA drives faster than CF cards? They are both bottlenecked by the PATA interface. Do CF cards just use slower flash memory?

SSDs tend to use multiple flash chips in... basically a RAID-like... parallel way. So, if you are writing to eight separate chips or reading from eight separate chips at once, you're going to get much higher performance than if you're only writing/reading from one chip. This is essentially the job of these SSD controller chips - to combine the inputs/outputs from multiple flash chips and provide the system with a unified storage device that hides all those little implementation details.

I might be wrong, but I don't think most removable media (whether they are flash drives, CF cards, SD cards, etc) use any kind of parallel architecture like that...

VivienM wrote on 2024-02-11, 17:59:

SSDs tend to use multiple flash chips in... basically a RAID-like... parallel way. So, if you are writing to eight separate chips or reading from eight separate chips at once, you're going to get much higher performance than if you're only writing/reading from one chip. This is essentially the job of these SSD controller chips - to combine the inputs/outputs from multiple flash chips and provide the system with a unified storage device that hides all those little implementation details.

I might be wrong, but I don't think most removable media (whether they are flash drives, CF cards, SD cards, etc) use any kind of parallel architecture like that...

I forgot about that, yes. I had 2 hyperdisk DOMs, a 4GB device with a single flash chip and an 8GB with two. They both had the same firmware and controller and had about the same latency, but the 8GB device did 65MB/s read, 16MB/s write, while the 4GB device only did 31MB/s, 11MB/s write. If your Sata device has room for 8 chips, I could see that helping throughput. But sata devices almost always win on latency too. Sata devices usually measure between 0.15 and 0.25ms, while my CF devices measured out in two distinct groups, one between 0.27 to 0.79 ms, and others were an order of magnitude worse at 4 to 5 ms latency but higher throughput.

Turns out the slow CF is mostly down to the fact that "most CF cards only support IDE mode up to PIO4" and they just don't support fast IDE mode.

demiurge wrote on 2024-02-13, 01:29:

Turns out the slow CF is mostly down to the fact that "most CF cards only support IDE mode up to PIO4" and they just don't support fast IDE mode.

That's true if you have really old CFs, but pretty much all of the CF's made since 2008 support at least UDMA5.

Are you using an 80 pin cable ?

I started exploring such options a long time ago as an alternative to IDE hard drives, and ran into various issues. While some CF-IDE adapters do have issues of their own, more of the time the issue comes from the CF cards themselves.

Most cards mark themselves as removable in firmware and often crippled for out-of-scope use cases including as hard disks, leading to some strange behaviors when installing or booting OSes. For cards that really work as expected you need to look for industrial ones which tend to be very rare and expensive when it comes to relatively higher capacity.

It was not until a while ago that I found out it was possible to MP a SM2236-powered CF card into a state that can correctly function as a HDD. I'm not sure of other CF flash controllers or their respective MP tools but you'll probably need one if you want the card to behave correctly.

LSS10999 wrote on 2024-02-13, 05:16:

Most cards mark themselves as removable in firmware and often crippled for out-of-scope use cases including as hard disks, leading to some strange behaviors when installing or booting OSes. For cards that really work as expected you need to look for industrial ones which tend to be very rare and expensive when it comes to relatively higher capacity.

Which OS’s are you talking about? The removable flag has not caused problems for me in DOS or Win9x.

The Topram brand and the generic blue&white CF’s perform similarly to 40pin DOM’s for me and still have good availability on Ebay.

douglar wrote on 2024-02-13, 11:34:

Which OS’s are you talking about? The removable flag has not caused problems for me in DOS or Win9x.

The Topram brand and the generic blue&white CF’s perform similarly to 40pin DOM’s for me and still have good availability on Ebay.

Well, it's only Windows 2000/XP and onwards that being removable would cause issues. DOS, Win9x and even Linux do not have any issue with that.

If you don't ever boot them you'll be fine as long as the card has no issue with LBA or other stuffs.

There indeed are cards whose only problem is being removable, while otherwise uncrippled and work fine.

LSS10999 wrote on 2024-02-14, 05:29:

Well, it's only Windows 2000/XP and onwards that being removable would cause issues. DOS, Win9x and even Linux do not have any issue with that.

Some older IDE controllers (most notably Multi-I/O cards based on UMC 82C83x) do not work well with CF cards that identify as removable. Frankly these cards do not work at all from my experience, system hangs during POST or, eventually, throws HDD controller error. I'm not exactly sure why this happens - Prime2C and IDE controllers built into chipset on Pentium and later mobos don't seem to care. I think cards that exceed 1024 heads during BIOS detection also trip the UMC chip because I have two 4G cards that HWiNFO reports as fixed/magnetical and these work well with other IDE controllers. Possibly those cards would work when CHS values are set by hand and below the limit.

And then there are CF cards that cause even Prime2C to give up. It's so bad that the BIOS also reports FDD controller error (some I/O decoding issue on the card side?). Also, based on the CF cards in my "collection":
- cards below 1G only support PIO4 at best
- cards below 4G support MW DMA2, but not SW DMA at all (which might upset some early DMA-capable IDE controllers/mobos)
- 4GB cards support UDMA5 but also not a single SW DMA mode

I mostly care about older systems (286-486) and DOS so I don't have any cards bigger than 4GB, and of these I only have two for my Pentium systems (one for DOS, 2x FAT16 partitions, one FAT32 for Win98). I'd probably pick a mechanical drive for P2 or later system, since AFAIK the SSD drives need to be powered or else can start loosing data. I don't use all of my machines that frequently so I'd rather have reliable storage on HDD (which, even if old, will not see all that much use) than risk SSD corruption and all that work spent installing OS and programs would be wasted. And would only be discovered when I need to use the machine ASAP.

I have a few older PATA drives (2,5G to 10GB) and some newer ones. I figure that I could use the newer drives, with manually set CHS values, to emulate smaller HDDs on older mobos/OSes if need be. It's a waste of space but these HDDs are still cheap and pretty quiet (and reliable if not used for a 10000h+ already).

Deunan wrote on 2024-02-14, 11:16:

Some older IDE controllers (most notably Multi-I/O cards based on UMC 82C83x) do not work well with CF cards that identify as re […]
Show full quote

Some older IDE controllers (most notably Multi-I/O cards based on UMC 82C83x) do not work well with CF cards that identify as removable. Frankly these cards do not work at all from my experience, system hangs during POST or, eventually, throws HDD controller error. I'm not exactly sure why this happens - Prime2C and IDE controllers built into chipset on Pentium and later mobos don't seem to care. I think cards that exceed 1024 heads during BIOS detection also trip the UMC chip because I have two 4G cards that HWiNFO reports as fixed/magnetical and these work well with other IDE controllers. Possibly those cards would work when CHS values are set by hand and below the limit.

And then there are CF cards that cause even Prime2C to give up. It's so bad that the BIOS also reports FDD controller error (some I/O decoding issue on the card side?). Also, based on the CF cards in my "collection":
- cards below 1G only support PIO4 at best
- cards below 4G support MW DMA2, but not SW DMA at all (which might upset some early DMA-capable IDE controllers/mobos)
- 4GB cards support UDMA5 but also not a single SW DMA mode

I mostly care about older systems (286-486) and DOS so I don't have any cards bigger than 4GB, and of these I only have two for my Pentium systems (one for DOS, 2x FAT16 partitions, one FAT32 for Win98). I'd probably pick a mechanical drive for P2 or later system, since AFAIK the SSD drives need to be powered or else can start loosing data. I don't use all of my machines that frequently so I'd rather have reliable storage on HDD (which, even if old, will not see all that much use) than risk SSD corruption and all that work spent installing OS and programs would be wasted. And would only be discovered when I need to use the machine ASAP.

I have a few older PATA drives (2,5G to 10GB) and some newer ones. I figure that I could use the newer drives, with manually set CHS values, to emulate smaller HDDs on older mobos/OSes if need be. It's a waste of space but these HDDs are still cheap and pretty quiet (and reliable if not used for a 10000h+ already).

Thanks for those data points. CF's have a fairly old family tree, dating back to 1994. And as pointed out, any solid state device is likely going to need to get power periodically or it will lose its data, so if you expect your system to be powered off for a long time, magnetic storage is the way to go.

From my experience, if you're using CF cards, it's better to spend a bit more money on industrial grade versions.

Saves you a lot of potential headaches in the long run.

what is the most accessible way to check if a cf card is reporting itself as removable in either dos, win9x or linux? is there a tool?

stanwebber wrote on 2024-02-14, 12:49:

what is the most accessible way to check if a cf card is reporting itself as removable in either dos, win9x or linux? is there a tool?

There is a bunch of info in the comments at the end of this post: https://www.os2museum.com/wp/removable-cf-card-or-not/ People have developed firmware and hardware work arounds.
The article links to this post about the removable bit on USB devices: https://woshub.com/removable-usb-flash-drive- … k-in-windows-7/ that is also interesting.

The easiest way is in the drive properties in Windows. Look at the second line there.

People who report problems that gets solved by changing the CF removable flag are usually having trouble attempting installing XP on a blank CF. That's a repeatable, known issue. Seems like you can work around it by creating the partitions in advance on another device.

But I don't want to underestimate the a number of potential issues with late VLB & early PCI IDE controllers and storage, anachronistic or otherwise. It was an awkward period for IDE and there are plenty of gotchas in that area involving specific controllers, drives, bios, drivers, and transfer modes. Not surprised by much from that period anymore.

Personally, I've never run into compatibility issues that were solved by changing the CF removable flag, but then I've never tried to use CF's for anything newer than Win98, so I've got a serious case of self selection bias going on.

CF seems to be a great option but my problem is that all of the proper hardware to use it seems to be too expensive. I have plenty of old SATA HDDs that are 80 to 120GBs from various laptops and whatever else that work great with my StarTech SATA to IDE adapter. I even have 2 so I can use a DVD-ROM ODD on my PIII machine, despite the fact i don't entirely need to, it was just the only black ODD drive I had so it could match the black case and black FDD.

Judging by the use of a new 500 GB SSD from WD in my slim PS3 for about a year or two, I fail to see how it could be any worse in a retro PC because it's worked perfectly fine on the PS3 which has no support for TRIM and is limited to SATA 1 speeds. It also makes a swap partition on it most games use to a varying degree (I believe Minecraft and GTA 5 are the most heavy users).

bobsmith wrote on 2024-02-14, 14:34:

CF seems to be a great option but my problem is that all of the proper hardware to use it seems to be too expensive. I have plenty of old SATA HDDs that are 80 to 120GBs from various laptops and whatever else that work great with my StarTech SATA to IDE adapter. I even have 2 so I can use a DVD-ROM ODD on my PIII machine, despite the fact i don't entirely need to, it was just the only black ODD drive I had so it could match the black case and black FDD.

Judging by the use of a new 500 GB SSD from WD in my slim PS3 for about a year or two, I fail to see how it could be any worse in a retro PC because it's worked perfectly fine on the PS3 which has no support for TRIM and is limited to SATA 1 speeds. It also makes a swap partition on it most games use to a varying degree (I believe Minecraft and GTA 5 are the most heavy users).

I've not had problems with the price of CF's. I bought a bag of 50 pin-->40 pin IDE adapters @ $5 each a while ago. I had to touch up some of the soldier points, but they work. I recently bought a some 512MB CFs for DOS builds ($6 each) , 2GB CFs for Win98 builds ($7 each). I like CF's for workbench stuff because it's easy to move them between computers and they are cheap enough that I don't feel like I'm burning a pile of cash when I beat on them. But they have their limits.

If the Motherboard BIOS is 1997 or newer, I'm usually considering a Sata SSD or a Sinitechi SD of some sort, especially if I'm going to put screws in the case. Even a good CF can make the system feel sluggish next to those options if the controller supports UDMA-4 or faster. And if I'm doing an older build that I plan to sell, I'm looking at DOM's because they make for a clean looking build and are the best at surviving a shipping event.

If you really want to use a Sata SSD in a retro PC with a BIOS older than 1994, just remember 1) you are likely going to need to add LBA support to your system, and 2) you want to keep your partitions at a manageable size . My rule of thumb is <=256MB for an 8088, <= 512MB for a 286, <=2GB on a 386, <= 32GB on a fast 486. That's roughly 10x larger than those systems had at the end-of-life. If you go bigger than that, you might find that your file system response time can be unpleasantly sluggish. The old beasts just don't enough power to work big file allocation tables.

Hokay so the CF card works pretty great with DOS 6.22 and Win 3.1 and the speed is pretty decent.

Problem is drive number 2 which is a msata to 44 pin wont work with the 44pin to 40 pin adapter.
I connected the drive to a unitek usb transfer thing and it works fine and i did transfer the 95 install with the 44 pin connector but when I connect the 40 pin adapter it struggles to find the drive.

AppleSauce wrote on 2024-02-23, 03:13:

Problem is drive number 2 which is a msata to 44 pin wont work with the 44pin to 40 pin adapter.
I connected the drive to a unitek usb transfer thing and it works fine and i did transfer the 95 install with the 44 pin connector but when I connect the 40 pin adapter it struggles to find the drive.

Glad you got the CF running.

Two quick questions:

Are you trying to run the MSATA device on its own channel? Trying to run it as a slave next to a CF master would require that both drives get along with each other, which is not guaranteed when one of your devices come from a time periods where people rarely ran IDE devices in a master/slave configuration anymore.

What is the date on your BIOS? Computers with a BIOS older than Jun 1994 almost never speak LBA28. They only speak CHS. It wasn't until after Feb 1997 that you can really count on a BIOS to be able to speak LBA28. Your msata device, like most sata devices built after 2010, likely doesn't speak anything older than LBA28. So they can't find a common addressing scheme to use. If this is your issue, you can probably correct this by adding an option rom to your system like XTide Universal BIOS or Promise EIDE or something like that. I don't know if you can even get far enough to load a drive overlay off of the MBR if you have an LBA only device and a BIOS that doesn't speak LBA at all. USB IDE bridges didn't come out until after 1999, so I'd expect that it would speak LBA28 & LBA48 just fine.