On 22 Sep 2004 07:28:39 -0700, larwe@larwe.com (Lewin A.R.W. Edwards)
wrote:

>Floppy drives in the main use a 34-pin interface which is unrelated to
>IDE. They require a special controller IC. It's very hard to find
>suitable controllers these days, because the only mass-market
>application for them is PCs

SMSC is makeing a dedicated floppy controller. I used it in one of my
last projects. Writing the low level IO routines was a bit of a pain
cause these controllers leave quite some burden up to the processor
controlling them.

I fully agree with you that if there is not a VERY strong requierement
for floppy access, there are - as you mentioned - much better
solutions possible these days.

Basically I just wanted to give a hint for a source of floppy
controllers if one really absolutely must have one.

Markus

> embedded devices, I was curious about determining the identity of e.g.
> 1.44" diskettes - not that I ever intended using diskettes!

Floppy drives in the main use a 34-pin interface which is unrelated to
IDE. They require a special controller IC. It's very hard to find
suitable controllers these days, because the only mass-market
application for them is PCs (so the easiest way to get a floppy
controller is to buy a super I/O chip containing 2S 1P FDD etc - and
these are HARD to find in easy-to-interface flavors now). While it's
possible to have a dedicated micro doing the floppy control, it's a
bit of a pain. Embedded applications these days tend to prefer
removable flash media. The main reason for using floppy disks was data
interchangeability with PCs. PCs are often not shipped with floppy
drives any more.

There is no really hard-and-fast way to identify what kind of media is
in the drive; part of the required information is user-supplied (CMOS
settings). This is kind of a good thing, because it allows you to do
hybrid disk formats, e.g. 19spt instead of 18 on a 1.44 disk.

larwe@larwe.com (Lewin A.R.W. Edwards) wrote in message news:<608b6569.0409211047.2ba39ae9@posting.google.com>...
> > My question relates to the Identify command (0xEC) with which one can
> > check out the CF device's intrinsic parameters.  Does one always have
> > to use this command to electronically determine what the capacity (max
> > number of sectors) of the CF device is?
> 
> Yes. How else were you planning to identify the card's
> characteristics?
> 
> > And is this same command also
> > used to interrogate other storage devices' capacity, such as HDD's,
> > diskettes, CDROM's(?)
> 
> HDDs - yes (though note that the situation is much more complicated
> with HDDs - for instance, only a very few very old "XT-IDE" drives
> support 8-bit mode, so you MUST use 16-bit data bus with those drives.
> Also, HDDs are not guaranteed to support LBA mode, and there are a
> host of other archaeological oddities that may or may not be
> important).
> 
> CD-ROM drives are not IDE, they are ATAPI. The command set is totally
> different (it is SCSI commands encapsulated in IDE transactions).
> 
> Floppy drives - it depends. I assume you're talking about
> IDE-interface drives, not 34-pin drives. Modern floppy drives that
> have a 40-pin interface are probably ATAPI, but some older flopticals
> behaved like a hard disk. IDE(ATAPI) floppy drives are not at all
> common. But why do you care about them anyway - the floppy disk is
> practically obsolete.

Thank you for the response & explanation Lewin.  Since it is my first
venture into the world of integration of mass storage devices into
embedded devices, I was curious about determining the identity of e.g.
1.44" diskettes - not that I ever intended using diskettes!

> My question relates to the Identify command (0xEC) with which one can
> check out the CF device's intrinsic parameters.  Does one always have
> to use this command to electronically determine what the capacity (max
> number of sectors) of the CF device is?

Yes. How else were you planning to identify the card's
characteristics?

> And is this same command also
> used to interrogate other storage devices' capacity, such as HDD's,
> diskettes, CDROM's(?)

HDDs - yes (though note that the situation is much more complicated
with HDDs - for instance, only a very few very old "XT-IDE" drives
support 8-bit mode, so you MUST use 16-bit data bus with those drives.
Also, HDDs are not guaranteed to support LBA mode, and there are a
host of other archaeological oddities that may or may not be
important).

CD-ROM drives are not IDE, they are ATAPI. The command set is totally
different (it is SCSI commands encapsulated in IDE transactions).

Floppy drives - it depends. I assume you're talking about
IDE-interface drives, not 34-pin drives. Modern floppy drives that
have a 40-pin interface are probably ATAPI, but some older flopticals
behaved like a hard disk. IDE(ATAPI) floppy drives are not at all
common. But why do you care about them anyway - the floppy disk is
practically obsolete.

I have managed to access a Sandisk CompactFlash device using an 8051
micro, and am able to read its identity, and also read and write
sectors in this device.  Next task is to tackle FAT16...

My question relates to the Identify command (0xEC) with which one can
check out the CF device's intrinsic parameters.  Does one always have
to use this command to electronically determine what the capacity (max
number of sectors) of the CF device is?  And is this same command also
used to interrogate other storage devices' capacity, such as HDD's,
diskettes, CDROM's(?)

Thanks
Jack