This message is from the T13 list server. Sorry for delay of this reply. C/DVD device has 4 different way to notify the media status to host. 1. Unit Attention notification 6/28/00 "NOT READY TO READY CHANGE, MEDIUM MAY HAVE CHANGED" error is reported from device to host. SPC defines this 1st way. And all host software use this way on any removal devices that supports SAM. 2. Media Class Events MMC device (packet based removal media device other than SBC) reports and controls its own eject key with GET EVENT/STATUS NOTIFICATION command. Some major OSs use this 2nd way. The relationship with the 1st way is described. Then the 1st way and the 2nd way do not have any conflict. This is designed to improve user experience of multimedia device and multimedia application with OS help. 3. Removable Media feature set ATA specification has this 3rd way. ATA device (removal ATA HDD) uses this 3rd way. Unfortunately, the relationship of 3rd way with 1st and 2nd way is not described in any document. Anyway, in MMC2, member understood that 3rd way is not necessary for Packet device. 4. Asynchronous Notification SATA defines this 4th way. It seems that this may be subset of 3rd way. And this 4th way works only SATA interface. STAT says that the use of Asynchronous Notification is not described in this document. It should be described command specification. (What name does the document have?) The 1st way works well. The 2nd way improves multimedia application problem with OS help. How 3rd and 4th work with other physical interface layer? Well.. multimedia device should work with any transport layer, IP, USB, UWB, IEEE1394, Parallel SCSI, Serial SCSI, ATA, SATA and [EMAIL PROTECTED] I think T13 should explain the relationship between 1&2 and 3, between 3 and 4. Who will be volunteer? Best regards, Keiji Katata PIONEER CORP. Pat LaVarre <[EMAIL PROTECTED]>@t13.org on 2004/04/03 05:26:12 送信者: [EMAIL PROTECTED] [EMAIL PROTECTED](B: [EMAIL PROTECTED] cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] bcc: 件名: [t13] Re: Removable Media Status Notification feature set This message is from the T13 list server. > Removable Media Status Notification feature > set of ATA. Here I suppose we mean the ATA ops x EF 95, x EF 31, and xDA. I remember WHQL sometimes required the device to support those ops, but last I checked the relevant WHQL test erroneously required op xA0 03 Packet/ Request Sense to leave the x3F6 & x01 ERR bit unchanged, ouch, e.g. even in the presence of a UDMA CRC failure. > I believe that this function is overlapped to SBC/MMC command set > (Packet) Yes redundant with PDT x05 MMC op x4A GPCMD_GET_EVENT_STATUS_NOTIFICATION. Massively distributed as legacy for PDT x 0E/ 07/ 04/ 00 RBC/ SBC ... I mis/remember mostly I studied this in the Win 95 B ATAPI that couldn't copy odd lengths of bytes per cdb. Rumour, be it truth or slander, says Win XP/ 2K didn't bother with these ATA ops. Are you saying someone is trying to revive them? Please no? > and is incomplete to use in product. Incomplete as you describe below, yes. > So in MMC/Fuji discussion we were > concluded that Packet device and its host software does not use this > feature set in ATA. Yes please. > MMC has embedded changer model. SBC/MMC have many different write > protects > or similar media and device combination status. Removable Media Status > Notification feature set of ATA cannot cover these items. > ATA layer persistent prevent, C/DVD class layer persistent prevent and > application layer prevent may conflict each other. Yes. > I think if T13 group needs to keep this feature in ATA, someone must > explain this feature in MMC WG. Accurate doc would be nice, sure. The design element I maybe most enjoyed was having the host conclude that an SBC op x2B Seek was an MMC op x2B Seek Immediate which completed not when x3F6 Status & x40 DRDY rose but instead prematurely when op xDA set x3F6 Status & x01 ERR rose because the disk was write-protected. > And T13 group may need to add some > descriptions to keep compatibility with SBC/MMC command set. Can you say more about what you have in mind? > I'm waiting for any commnet. Hope this helps. Pat LaVarre
