== onhold- an ATA/ATAPI CDROM application using a 8051 based Micro controller (Aug-Oct 2000) == this is a project i designed for a customer. it would have become a full on commercial project, but the client never went ahead and so it become GPL. the objective was to design a cheap CD player for phone systems- a device that plays CD's with recordings of music and people. the signals from this device would be fed into a telephone system. whenever somebody would ring up the business and get "put on hold" (and behold !- the name !), they would hear the CD. yes, i know this sounds like a common old CD sound system, but my client wanted something very cheap, something that used a simple ATAPI CDROM that could be acquired very cheapy. also, the client wanted some custom features you couldn't get with an off-the-shelf product- he wanted the device to be mobius (a fancy latin word meaning play the CD over and over again), and the customer only wanted *his* CD's to be played (the idea here was that the CD would have a digital preamble.. and my device would only play CD's with this preamble). 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 2000, 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. the finished program itself is very simple in operation. it has 3 LED flags that tell you status of the device. the program will 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. 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). 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 (zorinsn@rs-pribor.ru)). .. 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. 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 (csapuntz@stanford.edu) http://www.stanford.edu/~csapuntz/ide.html http://www.stanford.edu/~csapuntz/blackmagic.html - 8052 Basic project page (IDE logger section) by Sergey Zorin (zorinsn@rs-pribor.ru) 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) Availability- Locally (onhold-atapi-0.zip) main web site- jsno.arafuraconnect.com.au email: jsno@arafura.net.au (C) Copyright 1997 - 2008 by Vault Information Services LLC. All Rights Reserved. Information provided "as-is" without warranty. Please see details. Contact us for usage and copy permission.