en_US/nand/intro.html

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<LINK rel="stylesheet" type="text/css" href="../CSS/revolution.css">
<base target="main">
<title>NAND Function Introduction</title>
</head>

<body>

<h1>NAND Function Introduction</h1>

<h2>Introduction</h2>
<p>
The NAND library provides functions to access the NAND flash memory built into the Wii console. NAND flash memory has the following characteristics:
<ul>
<li>Nonvolatile memory
<li>Fast read, but slightly slow write
<li>Random access
<li>Concept of bit error
<li>Concept of bad blocks
<li>Concept of wear and tear because of writing
</ul>
</p>

<p>
The NAND memory capacity of the Wii console is 512&nbsp;MB. However, not all of the 512&nbsp;MB space can be used by the application program, as some of the space will be taken by the system files written at the factory or for permanently reserved system needs.
</p>

<p>
The NAND library provides a file system with the following characteristics.
<ul>
<li>Similar architecture to UNIX file systems.
<li>Hierarchical file system.
<li>Access control with three permission levels (Owner/Group/Other). (Group is a permission that corresponds to a company. It can be used when you want to allow access for titles from the same company.)
<li>Single-bit error correction is done in the file system.
<li>Bad block processing is done in the file system.
<li>Ability of the file system to withstand sudden power shutdown. (The entire file system will not be damaged even if power is shut down while writing data or updating the FAT.)
<li>Up to twelve characters for the file name/directory name.
<li>Supports both absolute path specification and relative path specification.
<li>The path delimiter text character is &quot;<CODE>/</CODE>&quot;.
<li>The maximum path length is 64 characters (including the NULL character).
<li>A directory structure up to eight levels deep can be created.
<li>The size of the file system block (FS block) is 16 KB. (In other words, even a 1-byte file takes a region of 16 KB.)
<li>Maximum number of files/directories to be created is approximately 6000.
</ul>
</p>

<p>
We have prepared sample demo programs that demonstrate how to use the NAND library under the path <code>$REVOLUTION_SDK_ROOT/build/demos/nanddemo/</code>. Function declarations are in the <code>$REVOLUTION_SDK_ROOT/include/revolution/nand.h</code> header file.
</p>


<h2>Banners</h2>
<p>
You must create a banner file in order to create an application save file in the Wii console NAND memory. In the Wii Menu, home directories without a banner file are deleted. <font color=#ff0000>If creating multiple files that include a banner file, be sure to create the banner file last. </font>If the banner file is created first, and then an accident such as a power interruption occurs, the home directory would have a banner file, but some of the save files might not be there. This could confuse players because it would appear from the save data screen in the Wii Menu that the application had no problem creating the save files, when in fact there was a problem. See the <I>Guidelines For Creating Wii Save Data</I> for details.<br>
</p>
<p>
The structure <a href="./NANDBanner.html"><CODE>NANDBanner</CODE></a> and functions <a href="./NANDInitBanner.html"><CODE>NANDInitBanner</CODE></a>, <a href="./NANDGetIconSpeed.html"><CODE>NANDGetIconSpeed</CODE></a> and <a href="./NANDSetIconSpeed.html"><CODE>NANDSetIconSpeed</CODE></a> have been prepared to simplify the process of creating banners. Also, reference the banner sample demo program.
</p>

<h2>Function which determines whether the file/directory can be newly created</h2>
<p>
As mentioned before, the Wii console NAND memory has the capacity of 512MB, but not all can be used by the application program. The memory will include system programs such as system feature applications, reserve area for bad blocks, and free space reserved for system use. Do not conclude whether a new file/directory can be created solely based on free space in the file system (Use of <CODE>NANDFreeBlocks[Async]</CODE> is not recommended).<br>When the application attempts to create files/directories in the home directory, based on the responses from the functions below, determine whether to go ahead and create the new files/directories or to perform some process such as displaying a message indicating insufficient memory space.
</p>

<h3>NANDCheck[Async]</h3>
<p>
<a href="./NANDCheck.html"><CODE>NANDCheck</CODE></a> and <a href="./NANDCheckAsync.html"><CODE>NANDCheckAsync</CODE></a> function &quot;reports&quot; the number of file system blocks and inodes that the application is about to consume. If the application is creating a new file/directory under the home directory, call the <a href="./NANDCheck.html"><CODE>NANDCheck</CODE></a> or the <a href="./NANDCheckAsync.html"><CODE>NANDCheckAsync</CODE></a> function first. The total number of file system blocks and inodes for the file/directory that the application will create is passed to the <a href="./NANDCheck.html"><CODE>NANDCheck</CODE></a> and the <a href="./NANDCheckAsync.html"><CODE>NANDCheckAsync</CODE></a> functions. The system will calculate whether a sufficient space to fulfill the request is available in the file system, and gives the verdict to the application program.
</p>

<h3>Determining whether multiple files/directories can be created</h3>
<p>
If the application requires multiple files/directories, sum the total number of file system blocks and i-nodes consumed by each, and then branch to either Create file/directory group or Create no files/directories, based on the result from a call to <CODE>NANDCheck[Async]()</CODE>. Do not call <CODE>NANDCheck[Async]</CODE> for each file/directory to be created. If you call <CODE>NANDCheck[Async]()</CODE> multiple times to create multiple files/directories, you may not be able to create all of the required files/directories, depending on the available space in Wii console NAND memory.
</p>

<dl><dd><pre><code>
// Correct sequence (pseudo-code)
NANDCheck(FileA+FileB+FileC);    // Check A &amp; B &amp; C at once.
if(success){
createFileA();
createFileB();
createFileC();
}
</code></pre></dd></dl>

<dl><dd><pre><code>
// Incorrect sequence (pseudo-code)
NANDCheck(FileA);   // Check A
if(success){
createFileA();
}

NANDCheck(FileB);   // Check B
if(success){
createFileB();
}

NANDCheck(FileC)    // Check C
if(success){
createFileC()
}
</code></pre></dd></dl>

<p>
The number of file system blocks (FS blocks) consumed by a given file is rounded up to be an integer value of the file size divided by 16 KB. Thus, an 8 KB file consumes one FS block, and a 40 KB consumes three FS blocks. Accordingly, if an application needs to create two files, one 8 KB and one 40 KB, that file group consumes four KS blocks (1 + 3 = 4). Do not calculate this as (40+8)/16 = 3 and call <CODE>NANDCheck[Async]()</CODE> with the assumption that three FS blocks will be consumed.
</p>

<h2>Function that obtains available space for an application</h2>
<p>
The <a href="./NANDCheck.html"><CODE>NANDCheck</CODE></a> and the <a href="./NANDCheckAsync.html"><CODE>NANDCheckAsync</CODE></a> functions determine whether files/directories can be created, but they are not suited to determine exactly how much free space is available. If you want to inform the player how much free space is available for the application to use in Wii console NAND memory, use the <a href="./NANDGetAvailableArea.html"><CODE>NANDGetAvailableArea</CODE></a> or the <a href="./NANDGetAvailableAreaAsync.html"><CODE>NANDGetAvailableAreaAsync</CODE></a> function. These functions obtain the number of file system blocks and inodes that the application can consume.
</p>

<h2>Process Flow</h2>
<p>
First, call <a href="./NANDInit.html"><CODE>NANDInit</CODE></a> function to initialize the NAND library before using NAND functions (<B>Note:</B> Starting with RevolutionSDK2.1, the NANDInit function is automatically called from the system). If the application is creating a new file/directory apart from <CODE>/tmp</CODE>, first call <a href="./NANDCheck.html"><CODE>NANDCheck</CODE></a> or <a href="./NANDCheckAsync.html"><CODE>NANDCheckAsync</CODE></a> to verify that the file system has sufficient free space and i-nodes for the application program before calling <a href="./NANDCreate.html"><CODE>NANDCreate</CODE></a> functions.
</p>
<p>
Refer to <a href="./sequence.html">NAND Processing Sequence</a> for an example of process flow including the error processing.
</p>

<h2>Directory Structure</h2>
<p>
Although a number of directories are available for the file system in the Wii console NAND memory, the application programmer should be aware of the following:
<table border="1">
  <tbody>
    <tr>
<td bgcolor="#C0C0C0">Path</td>
<td bgcolor="#C0C0C0">Description</td>
    </tr>
    <tr>
<td>/title/&lt;title-id(Hi)&gt;/&lt;title-id(Low)&gt;/data</td>
<td>This is the application home directory. The home directory is provided automatically by the system. Save application save data and others in this directory.</td>
    </tr>
    <tr>
<td>/tmp</td>
<td>Temporary directory. Files and directories stored under this directory are deleted when the system starts up.</td>
    </tr>
    <tr>
<td>/tmp/sys</td>
<td>This directory is reserved for use by the system as a temporary directory. Avoid having application programs access this directory directly. Doing so can lead to system instability.</td>
    </tr>
  </tbody>
</table>
</p>

<h2>Application Save Data</h2>
<p>
Use the NAND library to save application data. For programmers, the NAND flash memory is simpler to use than the CARD library, as it is built into the Revolution console. Refer to the gamesave sample demo program for more information on saving data.
</p>
<p>
When the NAND library is initialized, the current directory is automatically set as the home directory. This directory is hardwired in software in the development device environment and is common to all applications. However, a unique home directory is provided for each application on the production units.
</p>

<h2>Synchronous and Asynchronous Functions</h2>
<p>
Certain NAND functions provide both synchronous and asynchronous access to the Wii console NAND memory.<br>Synchronous functions block the current thread until the process completes and control is transferred to other executable threads. Asynchronous functions return immediately. If a request starts normally, a callback function is called at the completion of the process, and a result code and a command block are passed. The callback function and the command block are specified when the asynchronous function is called. If the asynchronous function call ends in an error (that is, if the result code is other than a normal exit), the specified callback function will not be called. Asynchronous functions contain the suffix <B><CODE>Async</CODE></B>.
</p>

<h2>inode</h2>
<p>
File management is done through inodes in the NAND library file system. To create a new file or a directory, one available inode is required for each file/directory. The number of available inodes can be checked using the <a href="./NANDFreeBlocks.html"><CODE>NANDFreeBlocks</CODE></a> function or the <a href="./NANDFreeBlocksAsync.html"><CODE>NANDFreeBlocksAsync</CODE></a> function.<br>However, the values obtained by these functions are the available inode counts for the entire file system. In actuality, there are free inodes which needs to be always reserved for the system, so please do not determine whether a new file/directory can be created solely based on the value obtained by these functions. When creating a new file/directory apart from /tmp, please follow the result of <a href="./NANDCheck.html"><CODE>NANDCheck</CODE></a> and <a href="./NANDCheckAsync.html"><CODE>NANDCheckAsync</CODE></a> functions.
</p>

<h2>Result Code List</h2>
<table>
  <tbody>
    <tr>
<td bgcolor="#C0C0C0">Return Values</td>
<td bgcolor="#C0C0C0">Description</td>
    </tr>
    <tr>
<td>NAND_RESULT_OK</td>
<td>Function completes successfully.</td>
    </tr>
    <tr>
<td>NAND_RESULT_ACCESS</td>
<td>The are no permission/access privileges for accessing files or directories.</td>
    </tr>
    <tr>
<td>NAND_RESULT_ALLOC_FAILED</td>
<td>The library failed internally to secure the memory needed for receiving a large volume of requests at one time. However, if you wait some time and call the NAND function again, the process might succeed.</td>
    </tr>
    <tr>
<td>NAND_RESULT_AUTHENTICATION</td>
<td>Data authentication failed. Data may have been destroyed due to a hardware problem, or data in the Wii console NAND memory may have been falsified in some illegal manner.</td>
    </tr>
    <tr>
<td>NAND_RESULT_BUSY</td>
<td>Busy state (the queue holding requests is full). If you wait some time and call the NAND function again, the process might succeed.</td>
    </tr>
    <tr>
<td>NAND_RESULT_CORRUPT</td>
<td>Wear in the FAT region has caused irreparable damage to Wii console NAND memory.</td>
    </tr>
    <tr>
<td>NAND_RESULT_ECC_CRIT</td>
<td>Indicates that a fatal ECC error has been detected (that is, data error correction is not possible). This code might be returned when the Wii console NAND memory is severely worn because the number of write/delete cycles has exceeded the device guaranteed performance.</td>
    </tr>
    <tr>
<td>NAND_RESULT_EXISTS</td>
<td>File or directory with the same name already exists.</td>
    </tr>
    <tr>
<td>NAND_RESULT_INVALID</td>
<td>Input parameter or the function call is invalid. This code is returned when an incorrect argument is passed to a NAND function, an attempt is made to close a file twice, or an attempt is made to use NANDSimpleSafe[Close] to close a file that was opened by NANDOpen[Async] (or visa-versa).</td>
    </tr>
    <tr>
<td>NAND_RESULT_MAXBLOCKS</td>
<td>All of the FS blocks in the file system have been used, so there is no free space. This code is also returned when, due to device wear, the number of bad blocks has reached the upper limit.</td>
    </tr>
    <tr>
<td>NAND_RESULT_MAXDEPTH</td>
<td>A directory structure deeper than this cannot be created (8 levels maximum).</td>
    </tr>
    <tr>
<td>NAND_RESULT_MAXFD</td>
<td>No more files can be opened because all of the file descriptor entries have been used. Reduce the number of files you open at one time.</td>
    </tr>
    <tr>
<td>NAND_RESULT_MAXFILES</td>
<td>No more files/directories can be created as the file system's inodes are used up.</td>
    </tr>
    <tr>
<td>NAND_RESULT_NOEXISTS</td>
<td>The specified file or directory does not exist.</td>
    </tr>
    <tr>
<td><S>NAND_RESULT_NOTEMPTY</S></td>
<td><S>File is not empty.</S></td>
    </tr>
    <tr>
<td>NAND_RESULT_OPENFD</td>
<td>The file descriptor has been left open. This code is returned when an attempt is made to delete a file that has not yet been closed. (The NANDSafeClose[Async] function may potentially return this code to execute a Delete operation internal to the function.)</td>
    </tr>
    <tr>
<td>NAND_RESULT_UNKNOWN</td>
<td>Unknown error. When this code is returned, there is a high probability that there is some problem with the SDK.  If possible, report the issue to Nintendo.</td>
    </tr>
    <tr>
<td>NAND_RESULT_FATAL_ERROR</td>
<td>The error code for program-design flaws (for example, the library is not initialized, etc.).</td>
    </tr>
  </tbody>
</table>

<p>
Of these, the following are result codes that might be returned by asynchronous function calls. Also, with the exception of certain asynchronous functions (<a href="./NANDSafeOpenAsync.html"><CODE>NANDSafeOpenAsync</CODE></a>, <a href="./NANDSafeCloseAsync.html"><CODE>NANDSafeCloseAsync</CODE></a>), the specified callback function will not receive <CODE>NAND_RESULT_ALLOC_FAILED or NAND_RESULT_BUSY</CODE>.
<ul>
<CODE>
<li>NAND_RESULT_OK
<li>NAND_RESULT_ACCESS
<li>NAND_RESULT_ALLOC_FAILED
<li>NAND_RESULT_BUSY
<li>NAND_RESULT_INVALID
<li>NAND_RESULT_FATAL_ERROR</CODE>
</ul>
</p>

<p>
<font color=#ff000000>Starting from SDK Version 2.3 (firmware Version 12.0.2), most synchronous NAND functions can return <CODE>NAND_RESULT_ALLOC_FAILED</CODE> and <CODE>NAND_RESULT_BUSY</CODE>. These result codes may be returned when a synchronous NAND API is called while the queue for receiving requests is full (for example, due to a succession of calls to asynchronous NAND functions over a short period of time).</font>
</p>

<h2>Result Code Handling</h2>
<p>
The following table indicates the guidelines for handling result codes. Also refer to the <a href="./sequence.html">NAND Processing Sequence</a> page.
</p>
<table border="1">
  <tr>
<th ROWSPAN="3">A. Items that applications must support</th>
<td>NAND_RESULT_AUTHENTICATION</td>
  </tr>
  <tr>
<td>NAND_RESULT_CORRUPT</td>
  </tr>
  <tr>
<td>NAND_RESULT_ECC_CRIT</td>
  </tr>
  <tr>
<th ROWSPAN="5">B. Items that applications must support for which a bug report to Nintendo is expected (if possible)</th>
<td>NAND_RESULT_ALLOC_FAILED</td>
  </tr>
  <tr>
<td>NAND_RESULT_BUSY</td>
  </tr>
  <tr>
<td>NAND_RESULT_MAXBLOCKS</td>
  </tr>
  <tr>
<td>NAND_RESULT_MAXFILES</td>
  </tr>
  <tr>
<td>NAND_RESULT_UNKNOWN</td>
  </tr>
  <tr>
<th ROWSPAN="9">C. Must be removed during the development or hidden from the player</th>
<td>NAND_RESULT_ACCESS</td>
  </tr>
  <tr>
<td>NAND_RESULT_EXISTS</td>
  </tr>
  <tr>
<td>NAND_RESULT_INVALID</td>
  </tr>
  <tr>
<td>NAND_RESULT_MAXDEPTH</td>
  </tr>
  <tr>
<td>NAND_RESULT_MAXFD</td>
  </tr>
  <tr>
<td>NAND_RESULT_NOEXISTS</td>
  </tr>
  <tr>
<td>NAND_RESULT_NOTEMPTY</td>
  </tr>
  <tr>
<td>NAND_RESULT_OPENFD</td>
  </tr>
  <tr>
<td>NAND_RESULT_FATAL_ERROR</td>
  </tr>
</table>
<p>
Result codes that are classified as (A) are the codes that may be caused by issues such as wear to the Wii console NAND memory.<br>Result codes that are classified as (B) are the codes that should not appear as long as the Wii system is running normally. If result codes in this category appear, please send a bug report to Nintendo if possible, as there is a chance of a defect in either RevolutionSDK or the Wii console/Wii development console.<br>Result codes that are classified as (C) are the codes that mainly suggest coding errors by the application programmers.<br>
</p>

<h2>Notes</h2>
<h3>Precautions when Writing Data</h3>
<p>
The file system used to manage the Wii console NAND memory has been designed to survive unexpected power shutdowns. There is no worry of the entire file system crashing even if the power shuts down in the middle of FAT update in the internal NAND memory. The system will instead restart from a FAT state immediately before the update. However, care must be taken regarding write timing. Assume that the following operations have been performed on a given file.
</p>
<ol>
<li>Open()
<li>Read()
<li>Write()
<li>Write()
<li>Write()
<li>Close()
</ol>
<p>
Write() alone does not update the FAT in the built-in flash memory. (The FAT in memory is updated.) Even if power shuts down midway through the execution of Write(), file contents will start from the state in effect before Write() was invoked. However, if an operation that involves updating the FAT in built-in flash memory occurs between instances of Write(), the data written by Write() up to that point will be reflected in built-in flash memory. For example, if another thread or process executes Create() immediately after the Write() on line three has finished executing, the FAT in built-in flash memory will be updated. If the power goes out immediately after this Create() function has finished executing, only the data written due to the Write() in line three will be reflected in the file. Although even this behavior may not be a problem depending on the data structure recorded for the file, if any of the of Write() on lines three, four or five are left out, problems will result if data consistency is lost.
</p>
<p>
One method of avoiding inconsistency of data due to this type of FAT update timing is to use a temporary file. First, copy the target file to /tmp and then perform all subsequent reads and writes on the file copied to /tmp. Finally, after the copied file is closed, Move() can be used to overwrite the original file, thus avoiding inconsistency of data described previously. This algorithm is implemented using the functions <a href="./NANDSimpleSafeOpen.html"><CODE>NANDSimpleSafeOpen</CODE></a>/<a href="./NANDSimpleSafeOpenAsync.html"><CODE>NANDSimpleSafeOpenAsync</CODE></a> and <a href="./NANDSimpleSafeClose.html"><CODE>NANDSimpleSafeClose</CODE></a>/<a href="./NANDSimpleSafeCloseAsync.html"><CODE>NANDSimpleSafeCloseAsync</CODE></a>. The sample demo &quot;safe&quot; is provided to demonstrate the atomic nature of updating files using these functions.
</p>

<h3>About the NANDSimpleSafe Functions</h3>
<p>
The NANDSimpleSafe functions have been prepared to resolve problems with the NANDSafe functions. (There was no recovery method if a function call terminated in an error.) If a NANDSimpleSafe type function ends in an error, call NANDSimpleSafeCancel[Async]. This function will try to release resources used by the NANDSimpleSafe type function.
</p>
<p>
Although <code>NANDSimpleSafeOpen[Async]</code> and <code>NANDSimpleSafeClose[Async]</code> guarantee the atomicity of file updates, to achieve it they incur a higher cost than the ordinary <code>NANDOpen[Async]</code> and <code>NANDClose[Async]</code>. When using these functions, note the following points:
<ul>
<li>Unlike the NANDSafe functions, <font color="ff0000">when the NANDSimpleSafe functions are used it is no longer possible to open multiple files that have the same file name at the same time.</font> (NAND_RESULT_EXISTS will return.) Careful attention is required when an application manages save files by creating directory structures such as <CODE>~/userA/save.dat, ~/userB/save.dat</CODE>.
<li>Compared to the NANDSafe functions, <font color="ff0000">there are stricter restrictions on the buffer size required to copy files. Be sure to specify a size that is a multiple of <code>NAND_FSBLOCK_SIZE</code>(16KB).</font>
<li><font color="ff0000">Do not use NANDSimpleSafe functions in combination with NANDSafe functions. </font> If these functions are used in combination, operations are not guaranteed .
<li>A buffer for copying files must be allocated.
<li>The <CODE>/tmp/sys</CODE> directory is created when <code>NANDSimpleSafeOpen[Async]</code> is executed for the first time.
<li>Because <code>NANDSimpleSafeOpen[Async]</code> copies original files, it consumes time as well as the storage space under <code>/tmp</code> corresponding to file size.
<li>When copying files, <code>NANDSimpleSafeOpen[Async]</code> will use one inode in <code>/tmp</code> to create a copy of the original file under <code>/tmp/sys</code>. Furthermore, it generates one FAT update.
<li>When <code>NANDSimpleSafeClose[Async]</code> executes, it generates two file closures and a file move. (However, <code>/tmp/sys</code> is not removed once it is created.) The function thus generates three FAT updates.
</ul>
</p>

<h3>Disadvantages of NANDSafe Functions</h3>
<p>
(Use of NANDSafe functions is not recommended. Instead, use the new <code>NANDSimpleSafe</code> functions instead.)<br>
</p>
<p>
<SPAN STYLE="text-decoration: line-through">Although <code>NANDSafeOpen[Async]</code> and <code>NANDSafeClose[Async]</code> guarantee the atomicity of file updates,  to achieve it they incur a higher cost than the ordinary <code>NANDOpen[Async]</code> and <code>NANDClose[Async]</code>. Note the following when using these functions.
<ul>
<li>A buffer for copying files must be allocated.
<li>The directory <code>/tmp/sys</code> is created when <code>NANDSafeOpen[Async]</code> is executed for the first time.
<li>Because <code>NANDSafeOpen[Async]</code> copies original files, it consumes time and storage space under <code>/tmp</code> in accordance with file size.
<li><code>NANDSafeOpen[Async]</code> will use two inodes for copying because first a unique directory will be created under <code>/tmp/sys</code>, and next the copied file will be created under the directory. Furthermore, it generates two FAT updates.
<li>When <code>NANDSafeClose[Async]</code> executes, it generates two file closes, a file move, and deletes a created directory. (However, <code>/tmp/sys</code> is not removed once created.) The function therefore generates four FAT updates.
</ul>
</SPAN>
</p>

<h3>Allowable Characters in File and Directory Names</h3>
<p>
The characters that can be used in file and directory names are limited to the alphanumeric characters <code>[0-9a-zA-Z]</code> and a few symbols <code>[-_.]</code>.
</p>

<h3>Buffer Alignment</h3>
<p>
The buffers used for reading and writing data and the buffers used for getting directory lists must be 32-byte aligned. Furthermore, the buffer for data read/directory list retrieval must be a multiple of 32 bytes.
</p>
<p>
<font color=#ff0000>Performance is slightly enhanced by using 64-byte alignment for the buffer used to read/write data.</font>
</p>

<h3>File/Directory Properties</h3>
<p>
You can set properties for files/directories. However, as of 2006/06/16, no decision has been made regarding what type of properties to provide. Although arguments for specifying attributes are included with functions that create files/directories and functions that change properties, at present, do not specify any value other than zero for these arguments.
</p>

<h3>Prohibition on Frequent Read Access</h3>
<p>
As a characteristic of NAND flash devices, <font color=#ff0000>if read access is repeated frequently several hundred thousand times or more on a given region without performing an erase or write operation, data may become corrupted in the periphery of that region.</font>If it is necessary to read data saved in Wii console NAND memory repeatedly, first load a good chunk of data in MEM1 or MEM2, and then read data from MEM1 or MEM2 to reduce the number of read access operations on Wii console NAND memory.<br>                                           For example, the following types of Read access are prohibited.
<ul>
<li>Performing a Read access to Wii console NAND memory every time data for a single character of a font is required
<li>Periodically performing a Read access to Wii console NAND memory at an interval of every frame or every second
<li>Performing Read access to Wii console NAND memory every time a character moves
</ul>
</p>

<h3>Wear on the Wii console NAND memory</h3>
<p>
Write operations will wear out the Wii console NAND memory, so please avoid frequent writing (do not use as virtual memory). When performing auto-save, please limit its frequency to less than once per minute. If you use the NANDSimpleSafe functions to perform auto-save, you must increase the interval between auto-saves (less than once every four minutes on average) to avoid wear and tear on the FAT, because the process of opening and closing files generates four FAT updates. The limitations become even more severe when performing auto-save using the (unrecommended) NANDSafe line of functions. Because the NANDSafe functions perform six FAT updates during the process of opening and closing files, you need to increase the interval between automatic saves (less than once every six minutes on average) to avoid wear and tear on the FAT.
</p>

<h3>Fluctuations in Access Time</h3>
<p>
Due to the characteristics of the NAND flash device, the time required to access data may vary even though the amount of data being read/written is the same. For this reason, do not write game programs that depend on access time.
</p>

<h3>Reset/shutdown processes</h3>
<p>
We recommend the reset/shutdown function to not be called until all Wii console NAND memory operations issued by the application program is completed.<br>The reset/shutdown function will execute without waiting for the NAND function issued by the application to close. The file system managing the Wii console NAND memory will guarantee the security of the entire file system against accidents (such as power outage), but will not guarantee for the data that was in the middle of write operation. Also refer to <a href="../os/Reset/intro.html">Reset Function/Shutdown Function</a> regarding reset/shutdown operations.
</p>

<h3>Regarding Data Tampering</h3>
<p>
The file system managing the Wii console NAND memory is strong by design against data tampering or prying. For this reason, there is no need to perform any special encryptions from the application program side when storing data into the Wii console NAND memory.
</p>

<h3>Periodic Access from the System</h3>
<p>
<font color="ff0000">Starting with SDK 2.1 patch 1 (2006/08/30), the system now periodically accesses the Wii console NAND memory. </font>There will be a file write once per minute, and a file open/close once every five minutes (FAT will also be updated at the close). For this reason, a single file descriptor will always be consumed. Also, when the system access timing and the application access timing overlaps, it may take longer than normal for the process to complete.
</p>

<h2>Limitations on Use</h2>
<p>
The following restrictions will apply regarding the use of Wii console NAND memory. Note that the files/directories created under <code>/tmp/sys</code> will also be subject to these restrictions. If the application is updating 1MB save file using NANDSafe type function, the upper limit of the file capacity that can be freely created in /tmp by the application will decrease to 39MB.
<table border="1">
  <tbody>
    <tr>
<td bgcolor="#C0C0C0">Coverage</td>
<td bgcolor="#C0C0C0">Upper Limit</td>
    </tr>
    <tr>
<td>Maximum file storage capacity of the home directory</td>
<td>16 MB</td>
    </tr>
    <tr>
<td>Number of files/directories that can be created in the home directory</td>
      <td>32</td>
    </tr>
    <tr>
<td>Maximum storage capacity of file that can be created in <code>/tmp</code></td>
<td>40 MB</td>
    </tr>
    <tr>
<td>Number of files/directories that can be created in <code>/tmp</code></td>
      <td>64</td>
    </tr>
  </tbody>
</table>
</p>

<H2>Revision History</H2>
<p>
2007/05/E Added a note about guidelines for handling result codes.<br>2007/05/M Added a brief explanation about the Group permission.<br>2007/05/M Added a note about the frequency of calls to the <CODE>NANDSimpleSafe</CODE> functions.<br>2007/05/09 Noted that a callback function is not called when an asynchronous function call ends in an error.<br>2007/05/09 Added a description of the <CODE>NANDSimpleSafe</CODE> line of functions. Noted that the use of <CODE>NANDSafe</CODE> functions is not recommended.<br>2007/02/xx Added the result code <CODE>NAND_RESULT_MAXDEPTH</CODE>.<br>2007/02/xx Added a supplement about the <CODE>NAND_RESULT_OPENFD</CODE> result code.<br>2006/12/18 Added a description of the prohibition on frequent Read access.<br>2006/11/30 Added text about result codes.<br>2006/11/30 Added text mentioning that many synchronous functions can return <CODE>NAND_RESULT_ALLOC_FAILED</CODE> and <CODE>NAND_RESULT_BUSY</CODE>.<br>2006/11/30 Deleted text about <CODE>NANDGetAvailableArea[Async]</CODE> as an alternative to <CODE>NANDCheck[Async]</CODE>.<br>2006/11/10 Supplemented the information about banner files and <CODE>NANDCheck[Async]</CODE>.<br>2006/10/25 Explained NANDGetAvailableArea[Async].<br>2006/10/25 Standardized terminology.<br>2006/10/25 Added information about periodic access from the system.<br>2006/09/28 Explained implementation details about the <CODE>NANDSafe</CODE> type function. Clarified the operational restrictions.<br>2006/09/25 Specified the home directory location.<br>2006/09/19 Added details about the result code that <CODE>NANDSafeOpenAsync</CODE> and <CODE>NANDSafeCloseAsync</CODE> function callbacks may receive.<br>2006/09/19 Added information about banner files.<br>2006/08/30 Added information that <CODE>NANDInit</CODE> is now automatically called from the system.<br>2006/08/30 Added information about <CODE>NANDCheck</CODE>.<br>2006/08/30 Fixed spelling errors in the result code.<br>2006/08/15 Revised the table on operational limitations.<br>2006/08/15 Added a description of the <CODE>NANDSafe</CODE> line of functions.<br>2006/08/15 Described the maximum allowable depth of the directory hierarchy.<br>2006/08/15 Deleted the <CODE>NAND_RESULT_INIT_FAILED</CODE> result code.<br>2006/08/15 Added description of characters allowed in file/directory names.<br>2006/08/15 Revised description of /tmp/sys.<br>2006/08/15 Revised description of maximum path length.<br>2006/08/15 Added precautions regarding writing data.<br>2006/08/15 Added a description of the <CODE>NAND_RESULT_AUTHENTICATION</CODE> result code.<br>2006/06/16 Initial version. <BR>
</p>


</body>
</html>