douglar wrote on 2023-03-13, 02:23:

For the CDRom drive, did you set the master and slave jumpers?

What motherboard, bios, and controller are you using?

Yes I did, obviously cd is slave, while the cf\sd whatever is master, furthermore they are on different channels.
It's a ECS (aka pc chips) P4S5A-DX+, latest bios.
That being said I may have found the issue. Here is what I do, use gparted to partition the sdcard\cf as follow:
1) NTFS partition of 5 gb (WINXP)
2) FAT32 partition of 2gb (WIN98)
3) FAT32 partition of the remaining space (DATA) where I want to install programs and use it as archive of programs I may need.
Windows xp works fine, see all partitions. Dos 7.10\win98 doesn't, all of those are primary partitions (according to the manual you can have 4 of them).
I've read an older topic where some users were having the very same issue and solved it creating 1 primary partition FAT32 where it will be installed WIN98, then and extended partition containing the data and ntfs winxp partition.
I did so and didn't have the chance to test further but in such configuration dos 7.10 was able to see both fat32 partition (didn't test if they worked though), but on my caily computer this configuration didn't allow me to see the partitions, just one was visibile on windows 10.

I will do some further tests.

Edit: create an extended partition which contains the fat32 data partition plus the ntfs (winxp) partition solved the issue, but now windows xp is slow like hell and it hangs. I don't know if it is a problem of the cf card but since with the sd card worked fine and the cf card should be faster, I don't know.

I went back to the sd card and I created a first NTFS partition for windows xp, then a fat 32 primary partition for dos and an extended partition for data (fat32). Another hole in the water, apparently windows98 didn't like this arrangement, nor windows xp, both unable to boot.
So now I created a 2gb partition for windows 98 (fat32), another 4gb primary partition for windows XP (ntfs) and an extended and logical blabla partition for DATA for the rest of the space (around 24gb).
Dos bootdisk is able to see both partitions (not ntfs obviously), but when I proceed to format the extended partition even the first one stops to work.
That being said, i'm going back to an hard drive.

Last post in this thread is more than 1 year old.
Maybe in the meantime things have happened.

I'm searching for a reliable SD->CF adapter to use with my StarTech CF->IDE adapter.
For now I'm using a 32GB Transcend CF and have no issues.

I want to go for the maximum DOS 7.10 is working with and use a 128GB "CF" in the future.
To find a CF 128GB, even new is not a problem. But the price is.
Cheapest price I found is 80€ for a 128GB Transcend CF.
Whereas a good Sandisk 128GB (micro)SD can be found for about 15€.

I have no problem with the 25MB/s limitation of those CF->SD adapters.
If I'm informed right even those CF->IDE adapters have an internal limit of 25MB/s.
As my Board Asus P5A supports ATA33 max. anyway that doesn't matter much.
Otherwise I would be using a SSD with IDE->SATA adapter.
But data transfer with a removable card is much more comfortable so I want to keep this route.

Recently been having more CF woes on the modern side of things, apparently most of the USB to CF adapters you want to use to write stuff from your modern boxes are trash for various reasons. You maybe don't notice for a file or two here and there, but they seem to be overheating and resetting on long writes. Meanwhile I never had so much trouble for writing SD cards for booting android boxes, linux systems etc, so SD writing at the modern machine end seems far less troublesome.

There are few "pro-grade" CF readers left these days and few were ever intended for anything more than quick copying of media files, so you won't get much out of them.

Try these instead.

https://www.addonics.com/product/intro/18

https://www.addonics.com/product/intro/20

https://www.addonics.com/product/intro/34

To make things clear.
In my DOS PC I have this CF->IDE Adapter:

https://www.startech.com/de-de/hdd/35baycf2ide

It works well and I have no problems. Writing data to the CF card on my modern PC also works well.

To avoid buying an expensive 128GB CF I thought of using for example one of those or any other SD->CF adapters.

https://www.delock.de/produkt/61796/merkmale.html

There are also variants for microSD cards.
(micro)SD cards are much cheaper und maybe more futurproof.

But after reading this thread nobody recommends those SD->CF adapters in the past.
Cards are not recognized or not bootable. Speed is limited to 25MB/s etc.

I was hoping things have developed in the meantime and there is a SD->CF adapter on the market that works well like a real CF card without any issues.

I am unsure if it applies to all situations with these SINTECHI adapters, but in at least one deployment of them, I found that UDMA modes just lock up the machine, and that they DO NOT support LBA48 mode.

I have a fujitsu lifebook E series 1050, in which the above problems manifest.

Any kind of UDMA mode locks the laptop up during the detection phase at POST. (Multiword DMA modes work fine though)
Any SDCard bigger than 128gb is NOT SUPPORTED because it does NOT do LBA48.

The laptop itself has been confirmed to not be the culprit, as actual 2.5" IDE drives work just fine. (Hitachi 500gb tested, and works just fine.)

I have it installed in another device at the moment, so I cant get the firmware revision, but I recall that it DOES report as SINTECHI and not as the FC1031.

I **ALSO** have a dual bay CF->IDE Startech adapter, and several SD->CF adapters for use in a now ancient DSLR camera.

I can confirm that even with very recent made adapters, the SD->CF adapters DO NOT PLAY NICE with the Startech adapter. Much to my sadness.

@wierd_w

Thanks for your experience report.
Very sad to hear that even recent SD->CF adapters still not work well for our needs in CF->IDE adapters.

Could it be that this the age old problem of one computer seeing a slightly different geometry than the other? Or could it be cached writes that failed to commit?

douglar wrote on 2024-05-03, 15:38:

Could it be that this the age old problem of one computer seeing a slightly different geometry than the other? Or could it be cached writes that failed to commit?

I am thinking it is more 'why try to present the entire ata protocol, when the camera only actually talks on a specific subset of those features, and never does all the other bits?'

The adapters seem to work just fine with usb readers, and cameras. Do not do anything at all, attached to an ata controller via an adapter.

With the sintechi, trying to write larger/past 128gb, it just silently fails while pretending it succeeds. It reports the correct disk size, but fails to actually write or return sectors. Does this on every device I have tried it on.

Would personally consider the choice to go CF instead of SD a no-brainer, at least for more classic XT-Pentium era hardware. CF was initially intended to closely mirror the IDE bus, and some CF cards are indeed intended for boot drive applications. Hardware such as palmtops, routers, industrial controls and lab equipment. I'd be skeptical of most "industrial" CF cards, but the old Sandisk SD-CFB (and probably SD-CFJ) cards are champ in terms of no muss compatibility and was used in now vintage embedded hardware. For applications where the reader itself isn't vintage, I see there's a good supply of WD Silicon Drive CF cards sold as used pulls on ebay. Probably harvested from ecycled commercial hardware, they're explicitly intended to be used as a small PATA hard drive in embedded applications.

Newer/higher tech cards like the Sandisk Extreme might work. I have no clue. I don't know if useful high capacity CF cards exist. Many high performance throughput cards actually have terrible IOPS, or ability to read and write many small files. They might be very fast in a digital camera, but stutter and lag in a PC filesystem, especially when paging to disk or using a complex OS like Windows 9X or NT. Truth be told, even the old SDCFB is from 25 years ago was much faster than the factory hard disk in a Libretto laptop and easily halved teh Windows 95 startup time.

What comes to mind is that if you need more than a few gigabytes of storage, which would be period correct into the Pentium MMX era, you're probably best served buying a real PATA SSD.

I haven't had trouble with the generic CF card adapters because they're dumb passthroughs and intend upon the IDE controller on the vintage PC to directly talk to the CF card as it would a hard disk. Just used the really cheap unbranded ones.

Haven't had issues with CF card readers .etc. My current cheap one works fine under Windows 11 with sub 2GB cards formatted FAT 16. If you have a vintage laptop, using a PCMCIA adapter would be traditional and works great. My reader is the INDMEM MCR86-U3. Not the very cheapest, but definitely generic and still rather tat.

RetroGamer4Ever wrote on 2024-05-02, 15:31:

There are few "pro-grade" CF readers left these days and few were ever intended for anything more than quick copying of media fi […]
Show full quote

There are few "pro-grade" CF readers left these days and few were ever intended for anything more than quick copying of media files, so you won't get much out of them.

Try these instead.

https://www.addonics.com/product/intro/18

https://www.addonics.com/product/intro/20

https://www.addonics.com/product/intro/34

Thanks!

wierd_w wrote on 2024-05-03, 18:09:

With the sintechi, trying to write larger/past 128gb, it just silently fails while pretending it succeeds. It reports the correct disk size, but fails to actually write or return sectors. Does this on every device I have tried it on.

Interesting. That doesn't match any SD size restrictions that I know of, but it does match the LBA-28 / LBA-48 crossover. Do you know what version of the firmware your sintechi device has? I've seen firmware version 1.2, 1.3 and 1.4. The easiest way to find this might be to generate an RPT file in speedsys. Did the build work past 128GB if you used other storage devices?

The sintechi devices are limited to 25 MBs internally ( SD High speed transfer). It would take 2 hours to fill the volume sequentially. I'm guessing you made multiple partitions or something. What tool did you use to create the partitions?

I made a 256GB sintechi build on a 486 once to see if any of the drive overlay packages supported it. I was able to make a 256GB partition using OnTrack Disk Manager 10.46 and FreeDOS fdisk using a sintechi with Firmware 1.2. The problem I had was that doing a DIR command on the volume took almost a minute to complete with default MSDOS 7.1 settings. I thought my build locked up at first it look so long. I hear it is possible to tweak the DOS buffers and stuff to make it a little better, but it was unpleasant enough that I scrapped the build in short order once I got the DIR command to finish. The moral of the story is that when an old CPU is paired with a FAT volume that is a lot larger that it would have ever seen back in the day, the build can be unpleasantly CPU limited when calculating free space. Generally, I try not to go more than 10x larger than the storage of the day. So 8088 < 128MB, 286 < 256 MB, 386 < 512MB, 486 < 8GB, Pentium I < 128GB. That's just me though. It also helps work around some of the BIOS and OS limitations too.

Also, usually builds that require > 128GB usually have an IDE controller that support transfer rates much higher than the Sintechi devices can manage. That's why as a general rule of thumb, if a build requires > 128GB of storage, I'm going to strongly consider using a bridged sata device.

I will need to pop it back into an actual computer (it is currently living inside a playstation 2, where disk speed is less an issue) to get its firmware version.

The initial application I wanted it for, was that fujitsu lifebook E1050.

Said E1050 currently has a hitachi 500gb in it. LBA48 is deffinately working.

Yes, multiple partitions. Win9x, win2k, and linux. Partitions created using a combination of dos fdisk (primary 1, dos 32bit fat, 10gb), win2k setup (primary 2 and 3, 32gb for system and 100gb for data), then the remainder (using a 400gb card) was going to be linux with zram swap.

I made it through win9x and win2k setup, but when copying game to the data volume, all sorts of stupid started happening. Didnt make it to tge linux portion, before realizing it was 48bit lba support being bogus.

Dug in my bins, and pulled out the hitachi 500. Did the same basic setup on it. Works just fine.

In the PS2 it currently lives in, the system needs specially patched software to do lba48 in the first place, and it works just fine. As a test, I tried enabling 48bit lba mode and writing past 128gb, (256gb card this time), and sure enough, it wrote bogus data silently.