atapi.txt

A MP3 Player Source Code, Enjoy it!

UPDATE: the work these guys did is at this page:

http://www.pjrc.com/tech/mp3/gallery/cs580/



>I am currently looking through your code and
>finding that there is a significant ramp-up time involved in understanding
>it.  I am writing you to ask if I could use you as a resource to address
>some of the questions I have?

Sure, ask away.  I'll write a bit of explaination about how the ide
driver stuff works.


There is a section that begins with these lines:

    ;*************************************************************
    ;**                                                         **
    ;**              IDE Disk Drive Driver Code                 **
    ;**                                                         **
    ;*************************************************************

That is where you'll need to do most of the work to add ATAPI support.
It is currently arranged as a state machine, where several states are
used to complete an operation to the disk drive.

The basic idea is that the FAT32 code generates requests for 4k blocks
of data to be read.  It always makes a request for 4k, even if it needs
less, and if it needs more than 4k, it will create multiple requests for
4k sections.  This makes the IDE code simpler, since all transfers are
4k.  If you look at the file "structs.txt", you'll see some C-sytnax
descriptions of the structures of data that are used.  The only one
you really need to worry about is:

    struct read_request {
            uint32  lba_to_read;
            int16   block_to_read_into;
            int16   unused;
    };

A read request will always be 8 bytes.  There are two arrays of these
requests, a high priority queue and a low priority queue.  The 32 bit
"lba_to_read" gives the LBA sector number to start reading (a 4k chunk
is always eight 512 byte sectors).  The 16 bit "block_to_read_into" is
the block number of a 4k block of memory that has already been allocated
by the FAT32 code.  It's the IDE code's job to check for any requests
in either of these queues, and actually perform the read operation of
the data into that block of memory that was allocated by the FAT32 code.

I said that the "read_request" struct was the only one you needed to
worry about, but that's actually a bit of a lie.  After the 4k of data
is transfered, you need to find the "block_info" struct that
corresponds to the 4k block you just filled, and clear the bit that
indicates that a read is pending.  This is what tells the FAT32 code
that you've finished transfering the data.  It won't allow that block
to be used until you clear that read_pending bit.  Fortunately, this
doesn't require getting into all the complexities of the "block_info"
structs, as there is already a chunk of code in the IDE driver that
does this.  You should just copy that existing code and not worry too
much about the many complex details of the block_info struct.

So, for ATAPI from a cdrom... from what little I know about it... my
understanding is that cdrom drives always use 2k sectors (extents)
instead of 512 byte sectors like hard drives.  That means you'll need
to read two 2k sectors to complete the 4k request issued from the
FAT32 driver.  Perhaps the cdrom command set has a way to read multiple
consecuitive sectors in one command?  If not, you'll need to issue and
process two commands, which would mean adding several states to the
state machine.

Of course, this is all assuming you manage to make some non-standard
cdroms with a FAT32 filesystem burned onto them instead of ISO9660.
This ought to be fairly easy with a program like "cdrecord", that
I believe has a command line option to set the image length, instead
of parsing it from a field in the iso9660 headers.  It ought to be
possible to mount such a non-standard cdrom in linux with a command
line option to the mount command.

One other minor detail about the "read_request" struct is that the
"unused" part isn't actually unused anymore (I should update the file).
The first byte is now used to indicate the nature of the request.  A
zero is a normal 4k block read request.  I believe I defined 1 to
mean putting the hard drive in full sleep mode.  If it becomes necessary
to define other commands besides reading a 4k block and shutdown,
that's the place to do it.

Now, about those read request queues... there are two, a high priority
and a low priority.  The code beginning at "ide_next_cmd" examines
both queues and removes the next pending requests and ultimately
jumps to "ide_next_cmd2" with DPTR pointing to the 8-byte read_request
struct (or it just returns if no requests are pending).  You'll see
the first things ide_next_cmd2 does it grab the requests and shove it
into the registers.  The non-sleep requests just to "ide_next_norm".
After printing a debug message, it starts doing the dirty work of
actually writing the request to the IDE drive.  I would imagine that
you'll define a global variable to know if the device is a hard drive
or cdrom (or for now just hard code a jump to always use cdrom commands),
right at the spot where the comment ";now we actually get to work on
executing this command" appears.  After the existing code finishes
commanding the drive to fetch the data, it changes the state variable
to cause the IDE code to wait for the read to complete.  It also maps
the 4k block from the read_request into the 0xA000 page.  Even though
it's not absolutely necessary to map the block until the drive has the
data ready to xfer, it's done here for a couple good reasons.. the
main one being that there's no variable allocated to remember that
block number for a later ide state (remember, the read_request was
removed from the queue and the FAT32 code may overwrite it before we
get to run in the next state).  This is also a time when the drive is
busy, so it makes sense to do work here instead of when the drive is
not doing useful work.  There's a lengthy comment about a future
optimization... don't try that yet, as I want to convert to using
interrupts before doing that sort of heavy optimization work.

The last point, which hopefully is pretty obvious by now, it that
you must not wait within the ide driver code.  While the drive is
busy executing your command, you must set the state variable to
run another state later on, which will check if the xfer is done
and do the next action.  In the case of a hard drive, that is starting
the dma transfer of the data, which again sets to another state that
waits for the dma to be complete, and so on until the state is
finally set back to the idle state.

I hope this doesn't seem like massive information overload... there
are quite a number of details, but keep in mind that all of the
higher level work, like deciding what blocks to read and allocating
and managing the memory is all handled by the FAT32 and the main
program.  All you have to do is build code, as a sequeuce of state
machine steps, that responds to those requests from the FAT32 code
and stuffs the data into the 4k blocks it allocates for you.  There
is the issue of detecting the partition and fat32 volume id... when
you get farther into this, I can help you hard-code some values into
the necessary variables for your particular cdrom image.  I think
that for the scope of a student project (where you'll want to show
some success before the end of the academic year), it's best to
just plan on a dirty hack of hard coding the fat32 initialization
values for your particular cdrom image, and if there is time at the
end you could try to auto-detect those settings.  The main thing is
to get the low-level device driver code working to get playback from
a cdrom.  Even if it's a non-standard cdrom (FAT32 instead of ISO9660)
and the initialization is hard-coded for your particular cdrom image,
you'll have definately have a successful project and you'll be able
to give a cool demonstration.


Well, I hope this clears things up a bit for you.  Please forward it
to your other team members.  The project itself is GPL'd (with a clause
to handle inclusion of the hardware initialization data).  I hope you'll
share your success with others, in the spirit of the GPL.  If you only
manage to get the driver code going, I'll add the autodetect code
and ISO9660 filesystem support later on.



Paul