Media Status Notification Support Specification, Version 1.03

Microsoft Corporation
March 1996

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft does not make any representation or warranty regarding specifications in this document or any product or item developed based on these specifications. Microsoft disclaims all express and implied warranties, including but not limited to the implied warranties of merchantability, fitness for a particular purpose and freedom from infringement. Without limiting the generality of the foregoing, Microsoft does not make any warranty of any kind that any item developed based on these specifications, or any portion of a specification, will not infringe any copyright, patent, trade secret or other intellectual property right of any person or entity in any country. It is your responsibility to seek licenses for such intellectual property rights where appropriate. Microsoft shall not be liable for any damages arising out of or in connection with the use of these specifications, including liability for lost profit, business interruption, or any other damages whatsoever. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages; the above limitation may not apply to you. 
Microsoft is a registered trademark of Microsoft Corporation.
© 1995 – 1996 Microsoft Corporation. All rights reserved.
Please send feedback to ihv@microsoft.com.
For additional copies of this specification please contact:
Microsoft Corporation
Windows Hardware Programs Group
1 Microsoft Way
Redmond, WA 98052
(206) 882-8080

Revision Record	
Edition	Date Published	Revised Comments	
1.0	December 1995	Original Release.	
1.01	January 1996	Amended final paragraph of “ATA Compatibility Considerations”	
1.02	February 1996	Added multiple LUN support for ATAPI devices, removed RD_PT definition	
1.03	March 1996	Modified disclaimer on first page	

Introduction
A major shortcoming of removable media devices on PC platforms is their inability to report to the host when the user attempts to eject the medium. Currently most removable media devices just eject the medium when the user presses the Eject button, and potentially any data the operating system has not saved to the device is lost. Various volume tracking and locking schemes reduce this risk, but do not eliminate it. Ideally, devices will have a means of communicating to the host that the user wants to eject the medium or has inserted a new medium. 
This specification defines a protocol for providing this function for ATA and ATAPI devices. The support is enabled using a SET FEATURES command, and the media status is retrieved using a new command, GET MEDIA STATUS. 
Because it is difficult for an ATA drive to asynchronously interrupt the host when it is not the active drive, this scheme is implemented by the host polling the device for status.
Drive Indication of Media Status Notification Support
Because some older ATA hard disk drives and some caching controllers fail when they receive nonstandard commands, ATA and ATAPI devices must return a “1” in bit zero and a “0” in bit one of word 127 of the data returned from the IDENTIFY DRIVE or ATAPI IDENTIFY DRIVE commands. The operating system uses this bit in this word to determine whether media status commands are supported. Note that it is necessary to return the “0” in bit one of the data (as well as the “1” in bit zero) as some controllers return 0FFFFh in the unused words of the ID drive data, which would be falsely detected as support for Media Status Notification without the “0”.
Enabling and Disabling Media Status Notification Support
To maintain compatibility with existing BIOS implementations and operating systems, the drive shall not enable Media Status Notification until a SET FEATURES command is issued, as described in this section.
When the host enables the support using the SET FEATURES command, the drive shall respond as described in this specification. When the host disables this feature, the drive must default to normal operating modes. A hard or soft reset must also cause the drive to return to normal operating modes. The host is required to re-enable Media Status Notification after any reset condition has occurred. This includes Power On Reset, SRST, RESET DEVICE command (08h) or ECECUTE DRIVE DIAGNOSTICS commands.
Note that the normal SET FEATURES option to enable/disable reverting to power on defaults has no effect on the Media status notification support.
The protocol of the command is as defined in the ATA Attachment Interface, version 3.3 for the SET FEATURES command. Media Status Notification support is enabled and disabled using SET FEATURES as defined in the following sections.
Enabling Media Status Notification
COMMAND register = 0xEF
FEATURES register = 0x95
When the command is completed successfully:
•	CYLINDER LOW register will contain the version of the support (currently 0x00). 
•	CYLINDER HIGH register will be set as follows.

Bit 7	Bit 6	Bit 5	Bit 4	Bit 3	Bit 2	Bit 1	Bit 0	
RSRVD	RSRVD	RSRVD	RSRVD	RSRVD	POWER_EJ	LOCK	PRV_ENAB	

These bits are defined as follows:
PRV_ENAB
This bit is set to “0” if Media Status Notification support was not enabled previously in the drive, and set to “1” if the support was enabled earlier (presumably by a lower level device driver). This indication allows the device driver to know whether it must disable the support after it unloads and returns control to a lower level device driver.
LOCK
This bit is set to “1” if the drive is capable of inhibiting a hardware eject action (that is, when the Eject button is pressed by the user) from ejecting the medium. For example, traditional PC floppy disk devices would set this bit to “0,” because the Eject button is usually just a lever that cannot be locked, and the drive cannot control when the medium is ejected. Drives that can lock the Eject button must set this bit to “1.” 
POWER_EJ
This bit is set to “1” if the drive has a power eject mechanism that is functional when a software EJECT command is sent to the drive. This bit must be set to “0” if the drive unlocks the media only when an EJECT command is received.
RSRVD 
This bit shall be zero.
Disabling Media Status Notification
COMMAND register = 0xEF 
FEATURES register = 0x31
After Media Status Notification is disabled, the drive must return to normal operating modes, such as ejecting the medium immediately when the user presses the Eject button.
Returning Media Status
The media status information is returned when the host issues the GET MEDIA STATUS (0xDA) command. The command protocol is as follows:
	1.	GET MEDIA STATUS (0xDA) command is written to the Command Register.
	2.	The drive asserts BSY.
	3.	After the drive has completed processing the command, it clears BSY and sets INTRQ.
	4.	The host reads the Status Register.
	5.	The drive clears INTRQ.

If the state of the drive is normal (that is, medium in the drive, medium not changed, Eject button not pushed, medium not write protected), the GET MEDIA STATUS command must return good status. If the command fails due to a hardware fault, the command must be failed with the ERROR bit set in the status register, and the ABORT bit set in the error register.
If the state of the drive has changed (or no medium is in the drive), the GET MEDIA STATUS command must be failed with the ERROR bit set in the status register, and the appropriate bits set in the ERROR register as follows.
Bit 7	Bit 6	Bit 5	Bit 4	Bit 3	Bit 2	Bit 1	Bit 0	
RSRVD	WT_PT	MC	RSVD	MCR	RSRVD	NOMED	RSRVD	

These bits are defined as follows:
RSRVD 
This bit shall be zero.
NOMED
This bit indicates there is currently no medium in the drive. This bit must be set for each invocation of the GET MEDIA STATUS command until the user inserts a medium in the drive.
MCR
This bit indicates that the user has attempted to eject the medium. Usually this bit will be set when the user presses the Eject button on the drive. If the drive is capable of preventing removal of the media, the drive shall not allow the medium to be ejected until an EJECT command is received from the host. This bit shall not be set again in response to the GET MEDIA STATUS command until the user subsequently releases the button and presses it again. The drive must take no action with regard to the user’s attempt to eject the medium other than setting this bit, except in the case that the ELECT_EJ functionality is not reported in the CYL HIGH register from the ENABLE MEDIA STATUS SET FEATURES command, which means that the drive cannot control when the medium is ejected.
MC
This bit indicates that a medium has been newly inserted in the drive. The bit must not be set for more than one invocation of the GET MEDIA STATUS command, until the user removes or reinserts the medium. In other words, when the user inserts a new medium in the drive, and a GET MEDIA STATUS command is issued, the drive will set this bit. The next GET MEDIA STATUS command must not result in this bit being set again unless the medium has been removed and reinserted.
WRT_PT
This bit indicates that a medium is currently write protected. 
Performance Notes
Get Media Status. The GET MEDIA STATUS command must be completed within the next I/O cycle (or as soon as possible) in order to facilitate drivers that, for performance reasons, poll BSY rather than waiting for an interrupt. Therefore, the drive’s firmware implementation might need to determine the drive status periodically, rather than having to determine it (if necessary) when the GET MEDIA STATUS command is issued. 
ATA Compatibility Considerations
Lock/Unlock/Eject. The LOCK and UNLOCK ATA commands or the equivalent PREVENT/ALLOW ATAPI commands, have no function when Media Status Notification support is enabled. Any Lock or Prevent that was in effect when Media Status Notification is enabled will be cleared. If supported, these commands must be completed, but must have no effect on the state of the drive. The EJECT command must always eject the medium, regardless of any pending lock commands. 
Acknowledge Media Change. The ACKNOWLEDGE MEDIA CHANGE ATA command must not be required when Media Status Notification support is enabled. However, if the host issues the command, it must be completed without error if supported. Note that this command is obsolete and is no longer supported in ATA-3.
ATA drives must fail any READ, WRITE, VERIFY, LOCK, UNLOCK, or EJECT command when Media Status Notification support is enabled and no medium is in the drive. Also, as defined in the “Returning Media Status” section earlier in this specification, the NOMED bit must be the error reported if these commands are received with no medium. This behavior differs from that of some currently available ATA removable devices, which will “virtualize” certain commands and return “fake” data when no medium is in the drive.
A problem arises if the drive wants to report the TK0NF error, because the NOMED bit replaces this error bit when Media Status Notification is enabled. This type of error should be reported using one of the other ERROR bits. 
Also, if Media Status Notification is enabled and the state of the drive changes (that is, the user inserts a medium or presses a button) and an ATA command other than the GET MEDIA STATUS command is received by the drive before the GET MEDIA STATUS command is received, the drive must return the status change in the ERROR register just as it is defined for the GET MEDIA STATUS command. The drive must also clear the condition just as defined for the GET MEDIA STATUS command. Only changes in the state of the drive with respect to the bits MC, MCR, and NOMED (as defined in the GET MEDIA STATUS command) must be handled in this manner. The WRITE PROTECT bit, of course, must not be reported as errors except from the GET MEDIA STATUS command or WRITE request. 
ATAPI Compatibility Considerations
ATAPI commands must be processed exactly the same as they would be if Media Status Notification was not enabled. For example, CHECK CONDITION with UNIT ATTENTION must be returned for ATAPI commands under the same conditions that would cause the MC bit to be set.
When the GET MEDIA STATUS command is received by the ATAPI drive, the MCR, NOMED, MC, and WRT_PT bits must be reported as described in “Returning Media Status” earlier in this specification. However, the state of the bits must not be cleared by any ATAPI command. The insertion of a new medium must be reported independently with both the GET MEDIA STATUS and ATAPI commands. For example, if the user inserts a new medium and the drive is accessed with an ATAPI command, the CHECK CONDITION with UNIT ATTENTION must be reported, but the drive must also report the MC error when it receives the next GET MEDIA STATUS command. The behavior must be the same if, after the medium is inserted, the GET MEDIA STATUS command is received before the next ATAPI command.
When the user presses the Eject button on the drive, the ATAPI commands must not be affected, but the MCR status must be reported when the first GET MEDIA STATUS command is received after the button is pressed (it is reported only once after each button press). The ATAPI drive must continue to operate as normal. If the operating system determines that it is safe to eject the medium, an ATAPI EJECT command must be issued to the drive.
ATAPI devices that support multiple LUNs shall honor the LUN field in the ATAPI Drive Select register for the GET MEDIA STATUS command. For example, if the medium is inserted in LUN 2 of a device, a GET MEDIA STATUS command issued for LUN 2 shall report the change, but a GET MEDIA STATUS command for LUN 0 shall not. The ENABLE and DISABLE MEDIA STATUS SET FEATURES commands are not LUN based. These commands shall be applicable for the entire device, and shall enable Media Status Notification on all LUN’s present. The protocol for reporting and accessing multiple LUN’s is defined in SFF-8020i version 2.6 and higher.