Yes. I discovered previous problems with a Hitachi 60Gb deskstar which I
investigated. Sorry the below stuff is a bit techy; you should be able
to extract information to the depth you're interested in though!

I had a long chat with the Hitachi (well, IBM as-was) firmware team
about the problem, who were extremely friendly.

To demonstrate the age of our equipment, the ADFS bus is using a legacy
feature from before the ATA-1 specification (that spec was written
1990ish IIRC, don't quote me; pretty much BC in hard disc terms anyway,
and significantly pre-dating the RISC PC!) The feature determines
whether to perform 16-bit, or 32-bit transfers. If the RISC PC can't
detect the difference, it uses 16-bit transfers.

Oddly enough, that was deprecated 16 years ago, but we still use the
feature, and we're reading a now 'unallocated' pin, which may be high or
low. As a result, it fluctuates, but is usually set to mean 16-bit
transfers.

Why is this techy stuff important? Well, if you try and format it on
HForm, it will read the drive size as a 16-bit value, and then gets the
size wrong and that's as far as you get. Yay.

However, if it correctly does identify the drive in 32-bit transfer
mode, or worse still you move a drive across which has been
pre-formatted, you can get a drive which works intermittently, and then
causes data corruption when it flips back to 16-bit mode mid-transfer. Erk.

Newer interfaces (ie the third-party ones), don't do this - they will
happily correctly work with the 60Gb Deskstar drive I've got. What I
cannot tell is whether this is a hardware issue (because of the
motherboard chipset,) or whether it's due to behaviour of ADFS itself.

 From what I've seen, fairly recent (~20Gb) Maxtors and Seagates appear
to work correctly on the ADFS bus. However, the sensible alternative
would of course be a Unipod, which adds lots of other things as well and
will give you noticeably better hard disc access performance ;-).

Best wishes,

Drew