You haven’t looked at the source code for the floppy driver that comes with
2000/XP/2003 very much. You can do anything with the FDC’s NEC PD765A
controller using the FDC driver.
“Richard Cartwright” wrote in message
news:xxxxx@ntfsd…
>
> Thanks again Phil for your advice. My RTOS needs to support floppies
(using
> a standard UPD765-like controller) and hard disks/CDROMs/Zip disks/CFMs
etc
> over both SCSI and ATAPI and hard disks using the ATA task file. In other
> words, as you assumed I’m not interested in USB.
>
> I assume if Windows has no passthrough interface for the ATA task file it
> also has no passthrough interface to send UPD765 commands direct to the
> floppy controller? Nothing obvious jumped out at me looking at the DDK’s
> source code for the floppy driver, so I’m assuming no. After all, under
> normal circumstances none of these things are really safe to do in a
> multitasking OS.
>
> I was originally planning to prototype as you suggest (ie CreateFile on
the
> drive letter and let Windows handle the raw sector reads) but if I can
debug
> it at the CDB level before I move to the target hardware I’ll be one level
> better of. Then I only have to debug the task file “twiddling” on the
target
> hardware.
>
> I might also look at prototyping on Linux or BSD as you suggest.
>
> Thanks again,
> Richard
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Phil Barila
> > Sent: Friday, 27 June 2003 2:00 AM
> > To: File Systems Developers
> > Subject: [ntfsd] Re: Sending SRBs to ATAPI devices from user mode
> >
> >
> > “Richard Cartwright” wrote in message
> > news:xxxxx@ntfsd…
> > >
> > > I understand the difference between standard ATA devices which use
only
> > the
> > > AT task file and the ATAPI devices which you send SCSI-like CDBs to
> > through
> > > the ATA PACKET command. One of the main media I want to support are
FAT
> > > formatted ZIP disks, which I understand do everything using
> > ATAPI packets.
> > > (Or have I misunderstood? Do they use ATAPI packets only for media
eject
> > > commands or something?)
> >
> > Is this Zip drive attached to ATA, or to USB? I assume ATA for
> > the rest of
> > this message, but it’s a legitimate question, and most of what
> > I’m going to
> > say doesn’t apply to USB. As far as whether the Zip is ATA or ATAPI, I
> > don’t know. I’ve always assumed it’s ATAPI, but I don’t have one
> > available
> > to test that assumption. There aren’t any hybrid devices, they’re
either
> > ATA or ATAPI. If it’s ATAPI, everything execpt IDENTIFY (and a
> > few others)
> > is a packet command. If I were you, I’d get myself a bus
> > analyzer, such as
> > a Bus Doctor. You can determine which it is in less than a
> > minute with one
> > of those. More importantly, the analyzer will be immeasurably valuable
in
> > debugging your code that twiddles the registers on the device.
> >
> > > So now I know how to talk to ATAPI devices, is there perhaps
> > also a way to
> > > directly read/write non-packet mode ATA devices from user mode at the
> > > Cylinder/Head/Sector level? Is there, for example, a device I can open
> > from
> > > user mode which will give me access to ATA devices near the AT task
file
> > > level? If so, can I do it safely without upsetting the drivers sitting
> > above
> > > too much?
> >
> > Nope. Unless you can use Windows Server 2003, you don’t have a way to
> > directly access the registers. Ask Microsoft to port the
ATA_PASS_THROUGH
> > interface to XP & 2000. Until then, you can use Read/WriteFile
> > to do direct
> > sector access, so you can write some wrappers to isolate your FS code
from
> > the underlying OS implementation. Program your FS to that wrapper
> > interface, then implement that interface in your RTOS. Then you
> > don’t care
> > whether you are talking to an ATA or ATAPI device, you solve that
> > problem in
> > your interface layer. The normal modes of ATAPI are pretty easy to deal
> > with, it’s the exceptional stuff that’s messier. Just like every other
> > programming problem, I suppose. 
> >
> > You might be able to forget CHS, it’s a fictional abstraction in today’s
> > drives. If you really think you need it, the standard way of contriving
a
> > geometry is to take the maximum sectors/track value & multiply by the
> > maximum number of heads, and divide the maximum LBA by that number.
That
> > gives you the number of virtual cylinders. FAT & NTFS do this,
> > but I don’t
> > think they need to, I think it’s a legacy thing. Then again,
> > there might be
> > some useful function to it that I haven’t imagined.
> >
> > Again, study the disk sources in the DDK, and if you are
> > intending to access
> > a FAT partition, use the FAT source from somewhere, such as the
> > IFS Kit, or
> > one of the open source OSes, to make sure you understand what you need
to
> > do. FAT’s pretty well documented, so that part shouldn’t be too hard.
> >
> > You are actually making it harder to do your prototype by trying to use
> > Windows as it’s available today, unless you use Server 2K3. Either use
a
> > BSD or Linux (retch) and you can lift the FAT code directly from them
and
> > use it, more or less, as is.
> >
> > Phil
> > –
> > Philip D. Barila
> > Seagate Technology, LLC
> > (720) 684-1842
> > As if I need to say it: Not speaking for Seagate.
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@spherical.com.au
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
>
>
>