Using ATAPI in an embedded environment

vbimport

#1

I am really not sure if this post is relevant in this forum but im sure it is technical enough. The question concerns my current university project. My studygroup an I are to control an ATAPI based CD-ROM drive (not necessarily CD-RW or DVD-ROM). For some weeks we have been able to eject the tray, play tracks, reading the TOC and Sub-channel data while playing. Some basics functions are working - though the problem is that this only works on two of our collected arsenal of 8 drives.

New drives from plextor, ASUS and philips refuses to hear (and talk) to us. A new DVD-ROM drive from pioneer is almost working (cannot read Sub-channel) and a an old pioneer 40x CD-ROM drive is working very well (being the only one). The common thread seems to be pioneer?

This is all controlled using a microcontroller (TI MSP430) with an external clock source of only 4MHz. Is this too slow to communicate properly through the ATA interface (we are only using PIO transfers, mode 0 is fine)??

Please report back if anyone has experience with the ATA/ATAPI interface - and I will try to elaborate further on the problems we face.

Intel4004


#2

Welcome aboard.

I’ve seen a website some time a go where some people already had achieved this, but i’ve forgotten the link. Anyone knows the link to this?

By the way, what CDROM codes are you using?

Anyway, it could be the way you’ve set up the MMC codes that you’re using to send to the drives. To confirm whether your codes are working on those newer drives, try them out in plscsi (obviously you will have to connect the drive to a PC):
http://members.aol.com/plscsi/

As a first test, you should try it out on a working drive first. I havn’t really used plscsi before, but it can send raw MMC codes to any attached drive.

I hope he doesn’t mind, but we could ask spath he knows more about this tool than me.

If it turns out to be the codes, then I may be able to help.


#3

Thanks for replying was not sure my post would be relevant (it appears to be very important on this forum).

Anyway I am not suspecting the method of issuing ATA commands and CDB’s to the device. But perhaps it is in the protocol implementation of ATA? We are trying to follow the statecharts of the ATA/ATAPI-6 working draft from t13. Perhaps the problems are more native. We are not sure we are using the read/write strobe signals DIOR-/DIOW- properly, perhaps we are too slow to control some devices (4MHz)? The real essence of the problem is that we usually hang in a loop waiting for the BSY bit of the device Status register to become zero. But some device makes this loop hang before we have issued any ATA command (we are tjecking BSY before sending, ussing the Bus Idle protocol).

It should be noted that the devices not working with our implementation works normal connected to a PC.

Intel4004


#4

How should one send the MMC commands?

The MMC CDBs are 12 bytes long and we are transmitting the bytes on DD0-DD15 in little endian order. The returned SCSI-datastructure (if any) is comming back in big endian order (so the bytes in every word needs to be swapped before use).

This is working with three drives now (pioneer 40x, pioneer DVD-ROM, Philips CD-RW). Though it is not much reply this thread is receiving. Does onyone know where to find information about this?

Technical problem: usually a TJECK CONDITION with status sensekey 0x5 (ILLEGAL REQUEST) arises just before PACKET protokol transition HP1:HP2 (DRQ never asserts even when it should). When this happens we send REQUEST SENSE CDB (from SPC) and usually receive SK=0x6 and ASC=0x29. This means that a device reset occured? Actually one some drives the device registers reset to standard power-on signature when issuing any CDB. And on one drive (pioneer DVD-ROM) the byte count registers does not decrement when reading the data register.

Does this make sense to anyone?

Most ATA command do work - hence IDENTIFY PACKET DEVICE returns usefull data.

This is technical and one must come forward and tell if I am likely to find the help we need in this forum. Somebody must have worked with this before?

Sincerely Intel4004


#5

I’ve PM’d this to Intel4004 already but he’s already sort out his problems himself. Since the articles are quite insteresting I’ll post them for others:

http://private.addcom.de/KeithWilson/Projects/mucop.htm
http://www.jmargolin.com/project/cdrom2.htm