Don't know of a utility that can do it off the top of my head, but it would need to use an ATA passthrough command to wrap an ATA identify request (which would return the cylinders/heads/sectors values reported by the card)... and the USB adapter would need to actually know how to handle the passthrough command instead of just returning an error (most do but not all).

Victoria (hdd.by) probably?
There's a port of hdparm but never tried it (as in: support the original not the imitation 😜)

And yup, you'd need an USB-IDE converter that supports UAS or the leading proprietary passthrough methods - which I suspect you won't find in any modern-ish multi card reader nor in a golden age of CF one…

I'm not sure what a passthrough is, I'm afraid. What I am using for CF reader is [this device]

boggit wrote on 2024-03-11, 19:55:

I'm not sure what a passthrough is, I'm afraid. What I am using for CF reader is [this device]

USB-to-storage adapters don't always let the host send any command it wants to the target device, because that's more work, so they just support the basic read/write/etc. stuff. Commands required for SMART are an example of something that often won't work with USB adapters - the documentation for smartmontools describes all the hoops you sometimes have to jump through to tell it how to use some device-specific way to pass through the ATA commands via the USB adapter to the device - and the ATA "IDENTIFY" command that you can use to get a device's geometry probably have similar issues, I would imagine. I assume that part of the issue is that the standard for USB mass storage devices would have standard commands defined for reading and writing, but probably not for getting C/H/S 😁

I think CF readers are much less likely to support those sorts of commands, and my Lexar one certainly doesn't. I got a "professional" one in the hope that it would, but I guess people like photographers probably don't care much about drive geometry or checking SMART monitoring!

USB-to-ATA adapters like this tend to be more of a power user thing, so I think they're more likely to support those commands.

I think the one I linked is the one I have (at least it's the same brand), and when I use that with a passive adapter that lets me attach a CF card to a 44-pin ATA + power connector, I can use the Linux hdparm command, which shows the geometry:

1$ lsscsi
2[...]
3[6:0:0:0]    disk    CF Card                         /dev/sdd 
4$ sudo hdparm -I /dev/sdd
5
6/dev/sdd:
7
8CompactFlash ATA device
9	Model Number:       CF Card                                 
10	Serial Number:      13[................]
11	Firmware Revision:  Ver6.04L
12Standards:
13	Supported: 5 4 
14	Likely used: 6
15Configuration:
16	Logical		max	current
17	cylinders	3872	3872
18	heads		16	16
19	sectors/track	63	63
20	--
21	CHS current addressable sectors:    3902976
22	LBA    user addressable sectors:    3902976
23	LBA48  user addressable sectors:    3902976
24	Logical/Physical Sector size:           512 bytes
25	device size with M = 1024*1024:        1905 MBytes
26	device size with M = 1000*1000:        1998 MBytes (1 GB)
27	cache/buffer size  = 1 KBytes (type=DualPort)
28	Nominal Media Rotation Rate: Solid State Device
29Capabilities:
30	LBA, IORDY(cannot be disabled)
31	Standby timer values: spec'd by Standard, no device specific minimum
32	R/W multiple sector transfer: Max = 1	Current = 1
33	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
34	     Cycle time: min=120ns recommended=120ns
35	PIO: pio0 pio1 pio2 pio3 pio4 
36	     Cycle time: no flow control=120ns  IORDY flow control=120ns
37Commands/features:
38	Enabled	Supported:
39	    	SMART feature set
40	    	Security Mode feature set
41	    	Power Management feature set
42	    	Write cache
43	   *	WRITE_BUFFER command
44	   *	READ_BUFFER command
45	   *	NOP cmd
46	   *	CFA feature set
47	   *	48-bit Address feature set
48	   *	Mandatory FLUSH_CACHE
49		CFA max advanced io_udma cycle time: 80ns
50		CFA max advanced mem_udma cycle time: 80ns
51	   *	CFA advanced modes: pio5 pio6 mdma3 mdma4 io_udma4 io_udma5 io_udma6 io_udma7 io_udma8 io_udma9 *io_udma10 mem_udma4 mem_udma5 mem_udma6 mem_udma7 mem_udma8 mem_udma9 *mem_udma10 
52	   *	CFA Power Level 1  (max 750mA)
53Security: 
54	Master password revision code = 65534
55		supported
56	not	enabled
57	not	locked
58	not	frozen
59	not	expired: security count
60		supported: enhanced erase

61	60min for SECURITY ERASE UNIT. 60min for ENHANCED SECURITY ERASE UNIT. 
62Checksum: correct

As already mentioned, there's a port of hdparm to Windows, but I can't vouch for it either.

Make a bootdisk and put ideinfo on it

OP said they were hoping to use their modern system. I assume that since IDEINFO is from 1991 or so, it might be a challenge.

I know that you can generally boot DOS from a USB device (maybe some firmware is making this difficult now though?) but I assume the BIOS just installs an interrupt 13h handler allowing access to the drive, rather than emulating an IDE/ATA controller, so that might be an issue?

I guess sometimes the onboard SATA controller can be configured to operate in a legacy mode, will it appear as an IDE/ATA controller then? If so maybe using a SATA-to-ATA adapter would help, so long as that adapter passes through the necessary commands. I imagine it should pass through the IDENTIFY command at least since that's how the BIOS figures out the disk capacity, and not passing it through would break disk auto-detection?

Then I wonder if one could make this more convenient by using eSATA?

The thing that I would find less convenient about this setup is the need to supply power to the ATA-to-CF adapter, and possibly the SATA-to-ATA adapter. Using a 44-pin adapter like I suggested above means everything is powered by USB.

doshea wrote on 2024-03-23, 10:14:

OP said they were hoping to use their modern system. I assume that since IDEINFO is from 1991 or so, it might be a challenge. […]
Show full quote

OP said they were hoping to use their modern system. I assume that since IDEINFO is from 1991 or so, it might be a challenge.

I know that you can generally boot DOS from a USB device (maybe some firmware is making this difficult now though?) but I assume the BIOS just installs an interrupt 13h handler allowing access to the drive, rather than emulating an IDE/ATA controller, so that might be an issue?

I guess sometimes the onboard SATA controller can be configured to operate in a legacy mode, will it appear as an IDE/ATA controller then? If so maybe using a SATA-to-ATA adapter would help, so long as that adapter passes through the necessary commands. I imagine it should pass through the IDENTIFY command at least since that's how the BIOS figures out the disk capacity, and not passing it through would break disk auto-detection?

Then I wonder if one could make this more convenient by using eSATA?

The thing that I would find less convenient about this setup is the need to supply power to the ATA-to-CF adapter, and possibly the SATA-to-ATA adapter. Using a 44-pin adapter like I suggested above means everything is powered by USB.

Make a bootdisk and put ideinfo on it