en_US/card/intro.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=windows-1252">
<META name="GENERATOR" content="IBM WebSphere Studio Homepage Builder Version 6.5.0.0 for Windows">
<META http-equiv="Content-Style-Type" content="text/css">
<LINK rel="stylesheet" type="text/css" href="../CSS/revolution.css">
<TITLE>CARD API Introduction</TITLE>
</HEAD>
<BODY>
<H1>CARD API Introduction</H1>
<H2>Introduction</H2>
<P>The Revolution supports GameCube Memory Cards (4 Mb, 16 Mb, and  64 Mb). This API has nearly the same specifications as the CARD API for the GameCube.</P>

<P>The CARD API provides file level access to these Memory Cards. A 4-Mb Memory Card can have up to 59 files. Larger capacity Memory Cards can hold up to 127 files. The file size must be a multiple of the Memory Card sector size obtained with the <CODE><a href="CARDGetSectorSize.html">CARDGetSectorSize</a></CODE> function. The file size is fixed at the time the file is created and does not change.</P>
<p>With the Revolution, Memory Cards can be used for loading data--for example, handing over game software data used by past GameCubes. For this reason, be sure to only use read related APIs in applications. Although write related APIs are also prepared for debugging, they should not be used in an application. (Contact Nintendo if write processing is required in the application.)</p>
<P><STRONG>Note:</STRONG>
The APIs that you cannot use in applications are described in the API Reference Manual.</P>
<P><STRONG>Note:</STRONG>

Be sure to use the flash memory built into the system to save Revolution programs.</P>
<H2>Initialization</H2>
<P>The <CODE><A href="CARDInit.html">CARDInit</A></CODE> function must be called only once before using any other CARD API functions.</P>
<H2>Detecting Memory Cards</H2>
<P>The <A href="CARDProbeEx.html"><CODE>CARDProbeEx</CODE></A> function checks whether a memory card (of any type) is inserted in the specified Memory Card slot.</P>
<P><STRONG>Note:</STRONG>
After a card is detected in a Memory Card Slot, it is recommended that the program should wait for the player's input response before proceeding to the next process (e.g., the <A href="CARDMount.html"><CODE>CARDMount</CODE></A> function).</P>
<H2>Mounting and Unmounting</H2>
<P>Before a Memory Card is accessed, the card must be mounted using the <CODE><a href="CARDMount.html">CARDMount</a></CODE> or <CODE><a href="CARDMountAsync.html">CARDMountAsync</a></CODE> function. As a best practice, if the game program does not use the Memory Card, it should be unmounted. This best practice is to ensure that the Memory Card is removed safely from the Memory Card slot. The <tt><a href="CARDUnmount.html">CARDUnmount</a></tt> function unmounts the Memory Card.</P>
<P><B>Note:</B>

Memory Cards must be probed before mounting.</P>
<H2>Verifying and Repairing Memory Cards</H2>
<P>The CARD API is carefully designed to maintain the consistency of the file system during normal processing. However, the file system may remain inconsistent because of a power supply problem or under unusual circumstances (for example, when the Memory Card is removed from the slot intentionally).</P>
<P><CODE><a href="CARDCheck.html">CARDCheck</a></CODE> or <CODE><a href="CARDCheckAsync.html">CARDCheckAsync</a></CODE> checks the consistency of the file system and repairs it if possible. Although these functions are unable to repair all data damage, one of the them must be called just after mounting a Memory Card (regardless of whether the return value of the mount operation returned <tt>CARD_RESULT_READY</tt> or <tt>CARD_RESULT_BROKEN</tt>). The game program can call other CARD functions after the <CODE><a href="CARDCheck.html">CARDCheck</a></CODE> function completes processing.</P>
<P><B>Note:</B> The <CODE><a href="CARDCheck.html">CARDCheck</a></CODE> and <CODE><a href="CARDCheckAsync.html">CARDCheckAsync</a></CODE> functions only checks the consistency of the file system. These function can't verify the contents of each user file in the file system. Each game program is responsible for verifying the contents of a file. For example, if a power failure occurred while saving game data to a file, the data would be lost, but the file system may remain consistent.</P>

<P><strong>Note:</strong>
 After mounting a Memory Card, the <code><a href="CARDCheck.html">CARDCheck</a><a href="CARDCheckAsync.html">[Async]</a></code> function must be used for verification.</P>

<H2>Format Processing</H2>
<P>The <CODE><A href="CARDFormat.html">CARDFormat</a></CODE> or <CODE><a href="CARDFormatAsync.html">CARDFormatAsync</a></CODE> function can format a Memory Card for access. If the Memory Card is not formatted or the system blocks of a Memory Card are broken, the <CODE><a href="CARDMount.html">CARDMount</a></CODE> function will return <tt>CARD_RESULT_BROKEN</tt> (the same way other functions do). In these cases, be sure to display an error message on the screen.</P>
<P><B>Note:</B> For programs that perform write processing, if <CODE>CARD_RESULT_BROKEN</CODE> has been returned, be sure to reformat after checking game players on the screen.</P>
<P><STRONG>Note:</STRONG>

Memory Cards must be mounted before they can be formatted.</P>
<H2>Text Character Sets</H2>
<P>Memory Cards use one of the two text character set encoding standards that depend on the type of console used for formatting. Japanese version consoles format Memory Cards to use the Japanese Shift-JIS text character set. Other versions of the console format Memory Cards to use the ANSI 8-bit text character set. The <tt><a href="CARDGetEncoding.html">CARDGetEncoding</a></tt> function returns the text character set of the current Memory Card.</P>
<P><STRONG>Note:</STRONG> For programs that perform write processes, if the text character set of the Memory Card and the system do not match, the <CODE><a href="CARDMount.html">CARDMount</a></CODE> and <CODE><a href="CARDMountAsync.html">CARDMountAsync</a></CODE> functions return <CODE>CARD_RESULT_ENCODING</CODE>. In these cases, after the player reconfirms on screen, the Memory Card should be reformatted.</P>
<H2>Synchronous and Asynchronous Functions</H2>
<P>Several CARD API functions provide both synchronous and asynchronous access to the Memory Card. Synchronous functions block the current thread until the process is completed and control is transferred to other executable threads. In contrast, asynchronous functions return immediately and call the specified callback when the process is completed. Asynchronous functions have the suffix <b><CODE>Async</CODE></b>, as shown in the table below.
</P>
<TABLE>
  <TBODY>
    <TR>
<TD bgcolor="#C0C0C0">Synchronous Functions</TD>
<TD bgcolor="#C0C0C0">Asynchronous Functions</TD>
    </TR>
    <TR>
<TD><A href="CARDCheck.html"><CODE>CARDCheck</CODE></A></TD>
<TD><CODE><A href="CARDCheckAsync.html">CARDCheckAsync</A></CODE></TD>
    </TR>
    <TR>
<TD><A href="CARDCreate.html"><CODE>CARDCreate</CODE></A></TD>
<TD><A href="CARDCreateAsync.html"><CODE>CARDCreateAsync</CODE></A></TD>
    </TR>
    <TR>
<TD><A href="CARDDelete.html"><CODE>CARDDelete</CODE></A></TD>
<TD><A href="CARDDeleteAsync.html"><CODE>CARDDeleteAsync</CODE></A></TD>
    </TR>
    <TR>
<TD><A href="CARDFastDelete.html"><CODE>CARDFastDelete</CODE></A></TD>
<TD><A href="CARDFastDeleteAsync.html"><CODE>CARDFastDeleteAsync</CODE></A></TD>
    </TR>
    <TR>
<TD><A href="CARDFormat.html"><CODE>CARDFormat</CODE></A></TD>
<TD><A href="CARDFormatAsync.html"><CODE>CARDFormatAsync</CODE></A></TD>
    </TR>
    <TR>
<TD><A href="CARDMount.html"><CODE>CARDMount</CODE></A></TD>
<TD><A href="CARDMountAsync.html"><CODE>CARDMountAsync</CODE></A></TD>
    </TR>
    <TR>
<TD><A href="CARDRead.html"><CODE>CARDRead</CODE></A></TD>
<TD><A href="CARDReadAsync.html"><CODE>CARDReadAsync</CODE></A></TD>
    </TR>
    <TR>
<TD><A href="CARDRename.html"><CODE>CARDRename</CODE></A></TD>
<TD><A href="CARDRenameAsync.html"><CODE>CARDRenameAsync</CODE></A></TD>
    </TR>
    <TR>
<TD><A href="CARDSetAttributes.html"><CODE>CARDSetAttributes</CODE></A></TD>
<TD><A href="CARDSetAttributesAsync.html"><CODE>CARDSetAttributesAsync</CODE></A></TD>
    </TR>
    <TR>
<TD><A href="CARDSetStatus.html"><CODE>CARDSetStatus</CODE></A></TD>
<TD><A href="CARDSetStatusAsync.html"><CODE>CARDSetStatusAsync</CODE></A></TD>
    </TR>
    <TR>
<TD><A href="CARDWrite.html"><CODE>CARDWrite</CODE></A></TD>
<TD><A href="CARDWriteAsync.html"><CODE>CARDWriteAsync</CODE></A></TD>
    </TR>
  </TBODY>
</TABLE>
<P><STRONG>Note:</STRONG>
While accessing the Memory Card using the functions in the above table, specific errors that can occur related to missing data (for example, the Memory Card is removed from the system) must be displayed on screen until the function completes its task.</P>
<P><STRONG>Note:</STRONG>
A call to an asynchronous function returns <tt>CARD_RESULT_READY</tt> if the specified process has been initiated successfully. Otherwise, the function returns an error code and the specified callback function is not called.</P>
<P><STRONG>Note:</STRONG>
If there are no corresponding asynchronous functions, the API completes immediately after the call (for example, as with the functions <CODE><a href="CARDOpen.html">CARDOpen</a></CODE>, <CODE><a href="CARDClose.html">CARDClose</a></CODE>).</P>
<P><STRONG>Note:</STRONG>
 Unlike the Optical Disc (DVD) API, the CARD API can issue only one process at a time per Memory Card slot (for example, while the process of a synchronous/asynchronous function is in progress, a call to another CARD API function simply returns <tt>CARD_RESULT_BUSY</tt>). A game program should wait for the previous CARD function to complete processing before invoking the next one. The <CODE><a href="CARDProbeEx.html">CARDProbeEx</a></CODE>, <CODE><a href="CARDProbe.html">CARDProbe</a></CODE>, and <code><a href="CARDGetXferredBytes.html">CARDGetXferredBytes</a></code> functions are exceptions and can be called while the current memory card process is in progress.</P>
<H2>Polling Access</H2>
<P>Instead of using a callback function with an asynchronous function, you can specify a <CODE>NULL</CODE> function as a callback and inspect the process completion by repeatedly calling <CODE><a href="CARDGetResultCode.html">CARDGetResultCode</a></CODE> function. This function returns <CODE>CARD_RESULT_BUSY</CODE> until the process completes.</P>
<P>Even while a memory card read/write process is in progress, you can check the total number of read/write bytes by calling the <CODE><a href="CARDGetXferredBytes.html">CARDGetXferredBytes</a></CODE> function. The <CODE><a href="CARDGetXferredBytes.html">CARDGetXferredBytes()</a></CODE> function can be used to implement a  progress bar, etc. to show on screen while data saves.</P>
<H2>Memory Card Life Span</H2>
<P>Each Memory Card has a life span like any type of flash memory device. If a CARD API function returns <tt>CARD_RESULT_IOERROR</tt>, the Memory Card may have reached the end of its life span. Alternatively, the Memory Card connector may be dirty. For this case, cleaning the connector may help.</P>
<P><STRONG>Note:</STRONG> Once the <CODE>CARD_RESULT_IOERROR</CODE> error is returned, the current Memory Card must be unmounted. <strong>Do not retry</strong> the CARD function that returned the <tt>CARD_RESULT_IOERROR</tt>  error. Otherwise, an unexpected error may occur. Because the CARD API returns the <CODE>CARD_RESULT_IOERROR</CODE> error after several internal retries, there is no doubt that the Memory Card that generated this error is defective.</P>
<H2>Directory</H2>
<P>The CARD API does not support hierarchical directories. Only 127 flat file entries are supported. Call the <CODE><a href="CARDGetStatus.html">CARDGetStatus</a></CODE> function to check each file entry by specifying the file entry number (from 0 to 126). Files can be opened/deleted by specifying either a file entry number or a file name. Functions that take a file entry number have the prefix <CODE>CARDFast</CODE> (for example, <CODE><a href="CARDFastOpen.html">CARDFastOpen</a></CODE> and <CODE><a href="CARDFastDelete.html">CARDFastDelete</a></CODE>).</P>
<P>The <CODE><a href="CARDCreate.html">CARDCreate</a></CODE> and <CODE><a href="CARDCreateAsync.html">CARDCreateAsync</a></CODE> functions create new files.</P>
<P>The <CODE><a href="CARDDelete.html">CARDDelete</a></CODE>, <CODE><a href="CARDDeleteAsync.html">CARDDeleteAsync</a>, <a href="CARDFastDelete.html">CARDFastDelete</a></CODE>, and <CODE><a href="CARDFastDeleteAsync.html">CARDFastDeleteAsync</a></CODE> functions delete files.</P>
<P>The <CODE><a href="CARDRename.html">CARDRename</a></CODE> and <CODE><a href="CARDRenameAsync.html">CARDRenameAsync</a></CODE> functions rename an existing file.</P>

<h2>File Attributes</h2>

<p>Each file can set the following file attributes.</p>

<table border="0" width="100%">
  <tr>
<td bgcolor="#C0C0C0"><b>Define Name</b></td>
<td bgcolor="#C0C0C0"><b>Value</b></td>
<td bgcolor="#C0C0C0"><b>Description</b></td>
  </tr>
  <tr>
<td><code><CODE>CARD_ATTR_PUBLIC</CODE></code></td>
<td>0x04</td>
<td>Any program can read the file.</td>
  </tr>
  <tr>
<td><code><CODE>CARD_ATTR_NO_COPY</CODE></code></td>
<td>0x08</td>
<td>IPL can't copy the file.</td>
  </tr>
  <tr>
<td><code><CODE>CARD_ATTR_NO_MOVE</CODE></code></td>
<td>0x10</td>
<td>Cannot move the file using IPL.</td>
  </tr>
  <tr>
<td><code><CODE>CARD_ATTR_GLOBAL</CODE></code></td>
<td>0x20</td>
<td>No program can read the file.</td>
  </tr>
</table>

<P>By default, only the <code>CARD_ATTR_PUBLIC</code> bit is set to a Memory Card file created by the <code><a href="CARDCreate.html">CARDCreate</a></code> or <code><a href="CARDCreateAsync.html">CARDCreateAsync</a></code> functions. <strong>The <code>CARD_ATTR_PUBLIC</code> must not be cleared by a game program.</strong></P>
<P>A game program can set a <code>CARD_ATTR_NO_COPY</code> bit and/or <code>CARD_ATTR_NO_MOVE</code> bit if required. <strong>A game program must not modify any other bits.</strong></P>
<P><code>CARD_ATTR_GLOBAL</code> is set to a file created by a utility program (for example, network setup program) that all games share.</P>
<P><b>Note:</b> <code>CARD_ATTR_GLOBAL</code> is a reserved bit: <code>cardedit.elf</code> will display error messages.</P>
<P><b>Note:</b> Both <code><em><strong>gameName</strong></em></code> and <code><em><strong>company</strong></em></code> are zero in the file with the <code>CARD_ATTR_GLOBAL</code> bit enabled: <code>cardedit.elf</code> will not display game code (<code><em><strong>gameName</strong></em></code>) and company code (<code><em><strong>company</strong></em></code>) for the file.</P>
<p>The <CODE><a href="CARDGetAttributes.html">CARDGetAttributes</a></CODE> function gets the file attributes.<br>The <CODE><a href="CARDSetAttributes.html">CARDSetAttributes</a></CODE> and <CODE><a href="CARDSetAttributesAsync.html">CARDSetAttributesAsync</a></CODE> functions set file attributes.</p>

<H2>Filename Space for Each Game</H2>
<P>Each game has its own separate filename space on a Memory Card. Each filename space is stored in the boot block of a Game Disc and separated by <b><i><CODE>gameName</CODE></i></b> and <b><i><CODE>company</CODE></i></b>. A game program can make a file name identical to files created by other games.</P>
<P><b>Note:</b> A game program can't write or delete files that are not in its own filename space.</P>
<H2>Read/Write</H2>
<P>Before performing read/write processes, the file must be opened with the <CODE><a href="CARDOpen.html">CARDOpen</a></CODE> or <CODE><A href="CARDFastOpen.html">CARDFastOpen</a></CODE> function (the <CODE><a href="CARDCreate.html">CARDCreate</a></CODE> and <CODE><a href="CARDCreateAsync.html">CARDCreateAsync</a></CODE> function open newly created file). The <CODE><a href="CARDOpen.html">CARDOpen</a></CODE> function can open only the current game files because of the filename space for each game. The <CODE><a href="CARDFastOpen.html">CARDFastOpen</a></CODE> function can also open other game files that have the <code>CARD_ATTR_PUBLIC</code> attribute.</P>

<P><strong>Note:</strong> When using the <CODE><a href="CARDFastOpen.html">CARDFastOpen</a></CODE> function, the game program should check the <code><b><i><font face="Courier New">gameName</font></i></b>, <b><i><font face="Courier New">company</font></i></b>, and <em><strong><code>fileName</code></strong></em> members of the <a href="CARDStat.html">CARDStat</a></code> structure using the <CODE><a href="CARDGetStatus.html">CARDGetStatus</a></CODE>.</P>

<P>The <CODE><a href="CARDRead.html">CARDRead</a></CODE> and <CODE><a href="CARDReadAsync.html">CARDReadAsync</a></CODE> functions read data from the file. <CODE><a href="CARDWrite.html">CARDWrite</a></CODE> and <CODE><a href="CARDWriteAsync.html">CARDWriteAsync</a></CODE> functions write data to the file. The read process to a file must be performed in multiples of <tt>CARD_READ_SIZE</tt> (512 bytes). The write process to a file must be performed in multiples of the card sector size that the <CODE><a href="CARDGetSectorSize.html">CARDGetSectorSize</a></CODE> function returns. The main memory data buffer to read/write data must be on a 32-byte boundary.</P>
<P>The current read/write process can be canceled using the <CODE><a href="CARDCancel.html">CARDCancel</a></CODE> function.</P>

<P>Files should be closed using the <CODE><a href="CARDClose.html">CARDClose</a></CODE> function before unmounting the Memory Card.</P>

<P><B>Note:</B>
 Memory Cards must be mounted before read/write to files.</P>
<P><B>Note:</B>
 Memory Card files must be opened before read/write.</P>
<h2>Memory Card 1019 Fast Mode</h2>
<P>Memory Card 1019 meets the needs of games that must save a large volume of data. Using fast mode reduces the wait time during large file saves; Memory Card 1019 has a fast mode, which saves files much faster than Memory Card 59 and Memory Card 251.<br>For backward compatibility, because potential programming errors related to latent timing may surface, the high-speed mode is disabled by default. To enable fast mode, call <code>CARDSetFastMode(TRUE)</code> before mounting a Memory Card. Use the <code>CARDGetFastMode</code> function to retrieve the current operation mode. To check the current mode of a Memory Card inserted in a Memory Card slot, call the <code>CARDGetCurrentMode</code> function.<br>Note that fast mode doesn't do anything for Memory Card 59 and Memory Card 251.</P>
<H2>Error Code List</H2>
<TABLE>
  <TBODY>
    <TR>
<TD bgcolor="#C0C0C0">Result Code</TD>
<TD bgcolor="#C0C0C0">Value</TD>
<TD bgcolor="#C0C0C0">Description</TD>
    </TR>
    <TR>
<TD><CODE><CODE>CARD_RESULT_READY</CODE></CODE></TD>
      <TD><CODE>0</CODE></TD>
<TD>Ready to start the next process.</TD>
    </TR>
    <TR>
<TD><CODE><CODE>CARD_RESULT_BUSY</CODE></CODE></TD>
      <TD><CODE>-1</CODE></TD>
<TD>Busy.</TD>
    </TR>
    <TR>
<TD><CODE><CODE>CARD_RESULT_WRONGDEVICE</CODE></CODE></TD>
      <TD><CODE>-2</CODE></TD>
<TD>A device is detected but it is not a Memory Card.</TD>
    </TR>
    <TR>
<TD><CODE><CODE>CARD_RESULT_NOCARD</CODE></CODE></TD>
      <TD><CODE>-3</CODE></TD>
<TD>Memory Card is not detected (or not yet mounted).</TD>
    </TR>
    <TR>
<TD><CODE><CODE>CARD_RESULT_NOFILE</CODE></CODE></TD>
      <TD><CODE>-4</CODE></TD>
<TD>Specified file was not found.</TD>
    </TR>
    <TR>
<TD><CODE><CODE>CARD_RESULT_IOERROR</CODE></CODE></TD>
      <TD><CODE>-5</CODE></TD>
<TD>Memory Card has reached the end of its life span.</TD>
    </TR>
    <TR>
<TD><CODE><CODE>CARD_RESULT_BROKEN</CODE></CODE></TD>
      <TD><CODE>-6</CODE></TD>
<TD>File system is broken.</TD>
    </TR>
    <TR>
<TD><CODE><CODE>CARD_RESULT_EXIST</CODE></CODE></TD>
      <TD><CODE>-7</CODE></TD>
<TD>The filename that is going to be created or renamed already exists.</TD>
    </TR>
    <TR>
<TD><CODE><CODE>CARD_RESULT_NOENT</CODE></CODE></TD>
      <TD><CODE>-8</CODE></TD>
<TD>No free directory entries.</TD>
    </TR>
    <TR>
<TD><CODE><CODE>CARD_RESULT_INSSPACE</CODE></CODE></TD>
      <TD><CODE>-9</CODE></TD>
<TD>Insufficient free space in data block.</TD>
    </TR>
    <TR>
<TD><CODE><CODE>CARD_RESULT_NOPERM</CODE></CODE></TD>
      <TD><CODE>-10</CODE></TD>
<TD>No file access permission.</TD>
    </TR>
    <TR>
<TD><CODE><CODE>CARD_RESULT_LIMIT</CODE></CODE></TD>
      <TD><CODE>-11</CODE></TD>
<TD>Tried to read/write over the file size limit.</TD>
    </TR>
    <TR>
<TD><CODE><CODE>CARD_RESULT_NAMETOOLONG</CODE></CODE></TD>
      <TD><CODE>-12</CODE></TD>
<TD>The filename that is going to be created or renamed is too long.</TD>
    </TR>
    <TR>
<TD><CODE><CODE>CARD_RESULT_ENCODING</CODE></CODE></TD>
      <TD><CODE>-13</CODE></TD>
<TD>Text character set encoding is mismatched.</TD>
    </TR>
    <TR>
<TD><CODE><CODE>CARD_RESULT_CANCELED</CODE></CODE></TD>
      <TD><CODE>-14</CODE></TD>
<TD>The read/write process is canceled.</TD>
    </TR>
    <TR>
<TD><CODE><CODE>CARD_RESULT_FATAL_ERROR</CODE></CODE></TD>
      <TD><CODE>-128</CODE></TD>
<TD>Error caused by program design (for example, parameter range error, etc.).</TD>
    </TR>
  </TBODY>
</TABLE>
<H2>Appendix: Memory Card Size and Sector Size</H2>
<P>Although the CARD API supports 4, 8, 16, 32, 64, and 128 Mb Memory Cards and 8, 16, 32, 64, 128, and 256 KB sector sizes, only Memory Cards with 8 KB sectors are sold. The Memory Card size and sector size can be checked at runtime by calling the <CODE><a href="CARDGetMemSize.html">CARDGetMemSize</a></CODE> and <CODE><a href="CARDGetSectorSize.html">CARDGetSectorSize</a></CODE> functions, respectively. <b>All game programs must support Memory Cards that have a sector size of 8 KB.</b></P>
<P>
<B>
Note:
</B>
Nintendo officially discourages the current development of game programs that support Memory Cards that are not 8 KB sector memory cards. A game program should call the <CODE><a href="CARDProbeEx.html">CARDProbeEx</a></CODE> or <CODE><a href="CARDGetSectorSize.html">CARDGetSectorSize</a></CODE> function to verify whether the Memory Card is an 8 KB sector Memory Card before proceeding. [as of 5/30/2001]</P>
<H2><b>Appendix: Icons, Banners, and Comments</b></H2>
<P>The Revolution system menu includes a Memory Card screen that displays memory card files. Please refer to the <a href="icons.html">Icons and Banners</a> page for more details about creating icons, banners, and comments.</P>
<H2>Revision History</H2>
<P>2006/03/01 Initial version.</P>
<hr>
<P>CONFIDENTIAL</p>
</BODY>
</HTML>