This project started out as a product design for a customer. The objective of this project was to design a cheap CD player for phone systems. This device would connect to a cheaply available computer CDROM via the ATA/ATAPI interface. It would command the CD player to detect and then play a CD. The audio output of CD player would then be fed into a telephone system. Whenever somebody would ring up the business and get "put on hold", they would hear the CD.
Yes, I know this sounds like a common old CD sound system, but my client wanted something very cheap, and something that used a cheap ATAPI CDROM drive. The client also wanted some custom features you couldn't get with an off-the-shelf product; he wanted the device to play the CD over and over again, and the customer only wanted *his* CDs to be played (Nb/ My customer was one of those voice over guys that do commericals).
A year after I finished development, the customer failed to keep his side of the agreement, and so this commercial development failed. I then revised this project to include an 16x2 LCD display and fix some bugs. After discussions with the Silicon Chip Magazine to perhaps publish Onhold in their magazine, I posted them a unit. However, they were not impressed by it, and sent it back with a standard rejection letter (Looking at the returned packaging, they didn't even bother running it up).
The project was then released as open source in 2002. It gained a lot of interest.
* * * *
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.
The device is very simple in operation. The device will detect a CD disk in the drive. If one is inserted, 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.
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). The hard part for me was working out the semantics of the signalling. Once I sussed that out, everything else was fairly smooth sailing.
The diagram below is the R2 schematic:
Building Notes
The following is discussions of problems I counted. Nine months passed before I documented this page, and unfortunately forgot 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.
- 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 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 ;).
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 BSY 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 funny one as well. 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 emphasized 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 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, because I was expecting a description about them at the start of the spec (one would expect). After consulting 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.
- R2 Notes: A few CDROM devices refuse to work with Onhold. There are some funny signalling requirements with certain CDROM lines that can't be done with the open collector pins of the micro and therefore could be minor impedance mis-match (change pullup resister values on Port 0, or buffer all pins). The devices I've had problems with were the Matsushita CR-585 devices. These devices wouldn't even reset. This is probably due to the poor quality of the published standards, and has caused variability in implementations cross manufactures.
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) Other Acknowledgements: - Special thanks to Erik Nordin (erik.nordin@mailbox.swipnet.se), and and Szakats Zoltan (szakats_zozo@yahoo.com) for submitting bug reports. their fixes have been incorporated into this code.
Nb/ Leo Lau has continued to revise the
"Onhold R2" project. He has done a great job of compacting and improving
the design. For those that are interested, please go to his website-- http://hk.geocities.com/leo8597/