readme

8051控制CDROM驱动

onhold- an ATA/ATAPI CDROM application using a 8051 based Micro controller 
                                             Copyright (C) 2000 Jason Nunn
                                                      Darwin NT, Australia
                                                     [e-mail]
                                                       [e-mail]
                                              http://jsno.downunder.net.au
--------------------------------------------------------------------------

Synopsis-

on about 10:00pm on Saturday 15th April 2000, my Unreal Tournment game i
was playing got rudely interrupted by a friend who paid an unannounced
visit. he told me about a friend of his who wanted me to design a cheap CD
player for phone systems. his friend was a radio announcer, people paid
for his voice to be on their phone announcement systems. the idea was that
he would record his "voice" onto a CD, and then have a device that played
that CD, feeding his audio recording into a telephone system. whenever
somebody would ring up the business and get "put on hold" (and behold !-
the project name), they would hear him talking about the company etc..

i did eventually go on to design the project for him, and i submitted it
on the 25th of october 2000, but due to various complications (possibly a
lack of customer interest, possibly unfeasible to design), it never went
ahead. so, i chose to turn this project into a GNU GPL project.
	
this distribution contains two programs. the first one called
"cdrom_controller" which is a prototype program- an aid i used to learn
about ATAPI. the second one is "onhold"- this is the actual finished
application.

a few other programs you might want to grab are-

la51-0.1.tgz- is an assembler i wrote a while go. you will need it if you
do any mods to my programs.

burn-1.19.tar.gz is an eeprom/flash writer (co-developed by me and terry
porter).  if you don't want to fork out a few hundred on a burner, then
you can design one using this dist.

ihex2bin.tar.gz is an intel hex to binary converter. la51 produces a ihex
file. burn requires a bin file. this program will do the conversion.

these programs are developed for linux. but, you should be able to port
them quite easierly. you can find these on my web site-
http://jsno.downunder.net.au


a word to those seeking help...
-------------------------------

if you are a hobbyist with non-profit intentions (ie you will be giving
your project away like me), i am happy to help you with any aspect of this
project. please don't hesitate to email if you have any questions ;).

however, if you are a commercial body seeking help, then you will get no
help from me unless you PAAAAAYY. are you authorised to sign cheques ?,
big cheques ??.  if so, then my rates are $200 per hour under "written"
contract. if not, then please don't waste my valuable time like my
ex-client did. i'm beginning to tire of companies and other assorted
'suits' rooting me around. i am not a charity for profit organisations.
you want something, you paaaayy... just like you expect to be paaaaid.


cdrom_controller/cdrom_controller.a51
-------------------------------------

when i went about researching ATA/ATAPI. i didn't know anything about it
at all. it was a bit of a grey area to me. i've always been hidden from it
by drivers or an operating system. as i discovered, you don't need a flash
processor to talk to an ATAPI device. a simple $4 8051 can do the job.

for about 4 months, i researched the problem on and off. i discovered that
the ATAPI SFF-8020i specification is a big mess. if you look at the
literature on the net, there is alot of noise on how shocking this
document is. "ATAPI references & Black magic in ATA/ATAPI by Constantine
Sapuntzakis" is one such document that discusses flaws in the spec and how
to get around certain problems.

On Saturday the 26th of August, the real work on the project began. i had
just acquired a development board (DARMICON development board SAB80C537)-
a prize given to me by my local university for scoring 5 straight high
distinctions for a course i did the previous year. with this, i set about
designing the project. after two weeks of work, cdrom_controller.a51 was
produced.

cdrom_controller.a51 is a simple prototype program. it was a gradual
learning aid that helped me slowly learn to talk to an ATAPI device....  
in operating systems theory, we call this boot strap development. the ATA
(T13/1321D R3) and ATAPI (SFF-8020i) specs are f**** big. if you were to
print both these specs out, they would make a handy monitor raiser ;), or
if you had a hostage, you could perhaps beat them with the T13/1321D specs
to get them to talk ;). both specs are very confusing in places. writing
this prototype was needed to slowly work out how to talk to the device.
grey areas in the spec was left to experimentation and learning from that.
this was the purpose of cdrom_controller.a51.

all cdrom_controller.a51 does is initialise a CDROM device, and send and
receive various command "ATAPI packets" to identify what it is (which it
prints via the Darimon development board stdio facility), read the CD's
table of contents (TOC), play a CD (that's in the CDROM device) and
finally report play status of the device.

now, this program itself is very adhoc... but in understanding the program
and using other ATAPI packets, you will be able to make a whole range of
controllers that do different things with ATAPI devices. particularly the
really nifty stuff you can do with the newer ATA/ATAPI revisions.. or even
the MM2 spec (a really cool application is password protection for
harddisks etc).

simple_cdrom_controller.a51 has been written to run on the Darimon
Development board. If you want to use it on any other development system,
then the program will need modifying slightly.

if you do get a Darimon board, then usage instructions go like this-

print out cdrom_controller/simple_cdrom_controller.sch (or just print the
*.ps file), and configure the board according to my diagram. using la51,
assemble cdrom_controller.a51. this will produce an intel hex file. using
the instructions that come with the darimon board, upload the hex file to
the Darimon. power on the attached CDROM drive and then run program. it
should now run. insert CD into drive, and the program will then start
playing the CD.


onhold/onhold_dev.a51
---------------------

onhold was a refinement of cdrom_controller.a51. it's been cut down. all
the printing information has been removed, replaced with basic LED flags,
and the program has been modified so that it can detect a CD disk in the
drive. if there is one there it will play it's contents. if there's no CD
in the drive, then it just sits in a loop until one is inserted. if it has
finished playing a CD, then it starts playing it again from the
beginning... in other words, it's stateful.


onhold/final_target.a51
-----------------------

same as onhold_dev.a51, accept the line references and memory references 
have been changed for the Amtel at89c51 IC. this is the final target code 
that was burnt into the 5 or so prototypes i submitted to my customer.

to build image, assemble using la51. if you are going to use the burn
project to flash your IC's, then use ihex2bin to convert the hex file
(produced by la51) into a binary file.

final_target.a51 is really made for the Amtel at89c51 IC. if you want to 
use a different flavour of 8051, then modification may be needed.

Amtel at89c51 IC's, are readily available from atmel.


                             o   o   o   o   o


i have done the ground work here. finding examples of an implemented
controller was.... very rare indeed. there was only one documented example
i could find (8052 Basic project page (IDE logger section) by Sergey Zorin
<[e-mail]>). .. and thank you very much for that to sergey. i
talked with sergey last year... a very friendly fellow. so, for you it
will just be a matter of understanding my work and recycling my code ;).

the hard part for me was working out the semantics of the signalling. once 
i sussed that out, everything else was fairly smooth sailing.


building
--------

the following is discussions of problems i counted.. and talk about my
experiences etc. it's been almost 9 months since of touched the code, and
i have forgotten some of the things i wanted to talk about. but anyway,
here goes-

- one question i was confused about in the early stages of design, was can
you talk to an ATA device using 8 data lines ?. if so, this would make
design very simple. as i discovered, very old specs of ATA (ie ATA-1), did
have provisions for 8 bit communication. however, in later iterations of
the spec, this was phased out. so, in other words, NO, you can't talk to
modern ATA devices using 8 bit data bus.

- ah... also, all timing is assumed to be 12 mhz. that is the clock speed
of your micro you design must be 12 mhz. if this isn't the case, then
you're going to have to modify the timing of my code... which shouldn't be
too hard. i've put comments in the code of how long certain timing should
be. it's a simple matter of recalculating the loop waits etc.

- in the spec, it mentions that DD7 (of the data bus) should be pulled
down by a 10k resister. i discuss this in the source code, but basically i
found that certain devices, the resistor pulls down this line a bit too
well. this causes data loss. the idea behind the pull down is to determine
if a device is attached. when the ATAPI device is first powered, DD7 is
high. so, if the line is high, then you have a device attached. the code
in simple_cdrom_controller.a51 is uncommented out. but you can comment
this back in if you like.

- the documentation i found can be confusing in places. they talk about
asserting and deasserting. you can have asserted signals (1's) that have a
Vss state, and assertions that have a Vdd state. the only thing that
indicates this in the spec is a '-' minus sign in the front of the line
names in the "interface signal names assignment" table (page 28 of the
ATA/ATAPI-5 spec). it took me a day to figure this out. it didn't click
until i looked at Sergey Zorin's project before i worked out where i was
going wrong.

- looking at the init_ata_device: routine in the
simple_cdrom_controller.a51 file--

hard reset i had a bit of a problem with. if i did it the way the specs
told me to do it, then the busy flag would assert falsey, and my code
would go charging full steam ahead without the device initing... so to get
around this, i put in a 2 second delay. this hack seemed to fix the
problem... and the state of the busy flag is correct after 2 seconds.

the device signature was a bit of a haha funny one too. device signatures
are the initial values held in the various register's of an ATA device.  
these values can tell you if the device is ATAPI packet command capable. i
had to comment out a part of the code due to suggestions by Con
Sapuntzakis (ATAPI references & Black magic in ATA/ATAPI). i didn't
experience any problems, but i did it just incase.

- another little thing that had me stumped for a while was the ATAPI
identify packet device command. i discovered that this command is
mandatory for CDROM (and like) devices, as it will enable the DRDY flag.
without this command, you won't be able to issue any commands (ATA or
packet).  for a while, i couldn't figure out why the device wouldn't
respond to any commands.  i think i remember a small print in the spec
(SFF-8020i) mentioning this.

- also, another area i got into trouble was the byte count register. this
register is used when the device sends variable or fitted length data to
your controller. it limits the amount it sends before asserting DRQ. if
this wasn't set, then the ATAPI device wouldn't send any packet data. this
wasn't really emphasised in the spec. the funny thing is that the
'identify packet device' command sets the byte count register (well, i
found this to be the case anyway), yet other packet commands don't.

a strategy i used when i issuing commands that send me data was simply to
set this register to ffffh before sending the command, and then detect end
of packet data with the DRQ flag.

- the SFF-8020i talks about ASC (Additional Sense Key) and ASCQ
(Additional Sense Key Qualifier) error codes. this had me scratching my
head for a while because, if you look in the spec, it doesn't actually
mention what they are until you get to the REQUEST SENSE command which is
nearly at the back of the manual ;). and i couldn't for the life of me
work out what they were, becuase i was expecting a description about them
at the start of the spec (one would expect).

after i consulted the linux 2.2 source code, i discovered that these were
SCSI error codes. as ATAPI is based on SCSI, this seems to be a throw back
thing from when the ATAPI protocol was adapted from SCSI.

i don't use these codes in my implementations. all my simple applications
need to know is if the command failed or not (determined by ERR flag in
the status register), but for your information, if you issue a command,
and you get an ERR flag, then you can issue the REQUEST SENSE command to
get these codes.


                            o   o   o   o   o


well, that's about it really. i have exhausted all of the things i
remembered to talk about ;) haha.



design references
-----------------

 - ATA/ATAPI-5 (T13/1321D R3) (www.t10.org)
 - ATA packet interface for CDROM's (SFF-8020i) (fission.dt.wdc.com)

other references used:

 - linux 2.2.x source code (/usr/src/linux/drivers/ide*)
   (had to be referred to seens that the SFF-8020i spec is so shitty)

 - ATAPI references & Black magic in ATA/ATAPI
   by Constantine Sapuntzakis <[e-mail]>
   http://www.stanford.edu/~csapuntz/ide.html
   http://www.stanford.edu/~csapuntz/blackmagic.html

 - 8052 Basic project page (IDE logger section)
   by Sergey Zorin <[e-mail]>
   http://www.nomad.ee/micros/8052bas.html
   (nb/ very very helpful)

 - General ATAPI info (including some source code)
   Hale Landis's ATAPI pages http://www.ata-atapi.com
   (a good introduction to it all, as i knew nothing when i first started
   this project)


                                 ooo0ooo