NADK is the NAND Application Development Kit.
NAND applications can import to and be run from the Wii console NAND memory. For optical disc applications that used NDEV, files were placed below DvdRoot and read from there. But for NAND applications, the files are used as content files, and must be collected into a NAND application file format called a WAD file.
NADK contains the CNT API to access content files, makeWad.exe to create WAD files, and an Nmenu to import and run WAD files.
These are outlined below. For further detail, see the appropriate page. In addition, see NAND API Introduction for information about Wii console NAND memory.
[Revision History up to NADK 2.2 Patch 3]
As mentioned above, for NAND applications, the read-only files similar to those used in optical disc applications (such as text files and music files) must be collected and packaged into a WAD file to be used as a content file. The CNT API provides access to these content files.
In the CNT API, the NANDAPP compile switch is provided to easily change between disc applications and NAND applications. See the Function List for details on the CNT API. The CNT API can only access content files that are in the format of archive files, which can be handled by the archive utilities (ARC library and darchD.exe) in the SDK.
Use of the CNT API's disc access feature is limited to NAND application development only. Do not develop disc applications using the CNT API.
makeWad.exe and make
makeWad.exe is a tool to create WAD files.
In addition, several make command options have been provided to automatically call makeWad.exe to create WAD files during build. See make Option Command for details on these options.
The Nmenu (RVL/bin/tools/Nmenu.elf) is a simple menu to manage applications such as NAND application import, execution, and deletion. You can perform auto import and auto run by applying options when executing Nmenu.elf. For details on Nmenu, see Nmenu.
In addition, a WAD file for Nmenu (dvddata/viewer/Nmenu.wad) has been included to simplify Wii Menu operations.
Refer to the Sample Demos page for examples of development procedures for NAND applications using the sample demos, as well as for information on how to use the CNT API.
The shared content files include the strap usage screen and the archive file for Wii bitmap fonts.
By using NADK and the separately provided ECDK (the E-Commerce Library) you can develop data titles for such uses as the marketing of add-on data, as well as developing applications that utilize those data titles. For more information on data titles, see "About Data Titles" on this page.
For disc applications, mastering was done from development programs (ELF and RPF) and converted to master data (RVM file) format. For NAND applications, the WAD file is already master data without any conversion. However, to allow the program to display and run correctly on the Wii Menu, the following items must be configured correctly in addition to the program. For information about how to create WAD files that have these settings configured, refer to the "Example WAD File Creation" section of makeWad.
To allow NAND applications to display on the Wii Menu, you must embed a banner file that has been created with the Icon and Banner Creation Tool (IconBannerTools), which is distributed separately. Banner files are embedded using the -m option of makeWad.
To run a NAND application from the Wii Menu, the correct country identifier code must be configured in addition to embedding a banner file as mentioned above. With disc applications, it was possible to change the country identifier code with the Master Editor. However, with NAND applications it is not possible to change this code after the WAD file is created, so it must be set in advance. The country identifier codes are set in the disc application and with the common script setncountrycode.
With NAND applications, Parental Controls information must be set before creating the WAD file, just like the country identifier code. It cannot be changed after the file is created. Parental Controls information is set with setnparentalcontrol.
A NAND application's version is managed by a 16-bit value (0x0000-0xFFFF) called the game version. The upper 8 bits of the game version are the major version, and the lower 8 bits are the minor version. The appropriate game version must be configured when creating WAD files.
Set the game version to 0.0 (major version of 0, minor version of 0) for the first submission of WiiWare or Virtual Console master data.
The game version must be incremented when master data is resubmitted. This is known as a version update. There are two ways to update the version number, according to the reason for resubmitting.
| Reason | Version Update | Version to Increase | Post-Update Downgrade |
| Resubmitted as a different version because a bug was discovered by customers | Major update | Major version | Impossible |
| Resubmitted because a bug was discovered by Lotcheck | Minor update | Minor version | Possible |
The game version is also affected when a WAD file is imported in Nmenu, overwriting an earlier WAD file. The error message "Cannot import older version." will be output if you attempt to use Nmenu to import and overwrite a WAD file configured with a game version that cannot be downgraded. You can then import normally by first deleting the application.
Note: You cannot even downgrade a minor update using a Wii Menu prior to version 3.0, or an Nmenu contained in the NADK prior to version 2.0.
Shared content files are particular content files that are decided and distributed by Nintendo, and that can be accessed and used by multiple NAND applications.
Because shared content files are all saved in the system region of Wii console NAND memory, you can reduce the size consumed by the application in the application region of Wii console NAND memory.
For an application to use a shared content file, an archive file distributed as a shared content file must be embedded in the application's WAD file.
The method of embedding the file is almost identical to that used when embedding a regular content file prepared by the application itself.
Specifically, specify a content file using the -l option of makeWad when creating a WAD file, and then specify 1 with the -T option to clarify that the content file is a shared content file.
The following is an example of a command that generates a file named SampleApp.wad from a program code file named SimpleApp.dol, a regular content file named user1.arc, and a shared content file named shared.arc.
|
The first two values of the 0, 0, 1 specified using -T are specifications for SampleApp.dol and user.arc. Because 0 was specified, these files are set with regular attributes.
On the other hand, 1 is specified for shared.arc, so this file is set with shared attributes.
A special API function is not necessary to access a shared content file from an application program.
In this example, the index for the shared content file is 3, so if you initialize CNTHandle as shown below, you can access shared.arc via the CNTHandle structure.
|
When installing a NAND application on a Wii system, content files with regular attributes are saved unchanged in the application region, but content files with shared attributes are saved in the system region of Wii console NAND memory, as long as an identical content file does not already exist there. If an identical content file already exists, nothing is saved.
Since a shared content file is not saved in the application region under any circumstances, it will not affect the storage capacity limit on the Wii console NAND memory.
(When using the master data creation tool "Revolution Master Editor for NANDApp," a value from which the size of shared content files has been subtracted is displayed as the application size.)
If shared attributes are specified for a content file prepared by an application, or if modifications are made to an archive file provided as a shared content file by Nintendo, files outside the control of Nintendo will be saved in the system region of the Wii console NAND memory.
Because the size of the system region is limited, this is extremely risky because there is a possibility that it may become impossible to allocate memory for saving official shared content files due to the accumulation of such files.
In order to prevent such incidents, the Revolution Master Editor For NANDApp is equipped with a function for checking whether the content files with shared attributes inside a WAD file have been approved by Nintendo. Because of this, invalid shared content files will never be saved on retail Wii consoles. However, since this does not apply to the development stage before master data is created, be very careful when specifying shared attributes for content files.
Note: Currently, the method for deleting files saved as shared content files in the system region of NDEV or other development tools has not been made public.
In the matter of what files are included in the archive files for the various shared content files, the formats of these files, and so on, be sure to read and follow the documentation and cautions for each shared content file.
Support for compression of programs has been added from NADK Version 2.2. DOL files compressed using the compression tool ntcompress provided with Revolution SDK are automatically expanded by the startup program.
-A32 option to ensure 32-byte alignment of the file size.Returned result codes will differ because the internal processes are different for disc applications and NAND applications. In addition, fatal errors in the file system can be detected in the same manner as with the NAND API, because NAND applications use the Wii console NAND memory file system. The following is a list of result codes returned for NAND applications.
| Return Values | Description |
| CNT_RESULT_OK | Function completed successfully. |
| CNT_RESULT_ACCESS | There are no permissions or access privileges to access content files. This code is returned when the content files for a data title have not been purchased, or access has been restricted by specifying the -E option to makeWad.
|
| CNT_RESULT_ALLOC_FAILED | Allocation of FST memory from the allocator failed in CNTInitHandle. |
| CNT_RESULT_AUTHENTICATION | Data authentication failed. Indicates that the data in the Wii console NAND memory might have been altered illegally. |
| CNT_RESULT_CORRUPT | Wear in the FAT region has caused irreparable damage to the Wii console NAND memory. |
| CNT_RESULT_ECC_CRIT | 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 has severely deteriorated because the number of write and delete cycles has far exceeded the device's guaranteed performance. |
| CNT_RESULT_INVALID | An input parameter, or the function call itself, is invalid. This code is returned in situations such as when an incorrect argument is passed to CNT API, or an attempt is made to open a nonexistent file or directory. |
| CNT_RESULT_MAXFD | No more files can be opened because all of the file descriptor entries have been used. Since these file descriptors are common to those used by the NAND API, decrease the number of simultaneously opened NAND files and/or content files. |
| CNT_RESULT_OUT_OF_MEMORY | Allocation of memory within the library failed. |
| CNT_RESULT_UNKNOWN | Unknown error. When this code is returned, there is a high probability that there is a problem with the SDK or NADK. If possible, report the issue to Nintendo. |
| CNT_RESULT_FATAL | This is a program design error code. |
Respond to these errors according to the following guidelines:
| Response | Errors |
| Items that applications must support | CNT_RESULT_AUTHENTICATION CNT_RESULT_CORRUPT CNT_RESULT_ECC_CRIT |
| Items that applications must support for which a bug report to Nintendo is expected (if possible) | CNT_RESULT_OUT_OF_MEMORY CNT_RESULT_UNKNOWN |
| Must be removed at the development site or hidden from the player. | CNT_RESULT_ACCESS CNT_RESULT_ALLOC_FAILED CNT_RESULT_INVALID CNT_RESULT_MAXFD CNT_RESULT_FATAL |
Perform the same process with CNT_RESULT_OUT_OF_MEMORY as with NAND_RESULT_ALLOC_FAILED.
Perform the same process with CNT_RESULT_CORRUPT as with NAND_RESULT_CORRUPT.
Perform the same process with CNT_RESULT_UNKNOWN as with NAND_RESULT_UNKNOWN.
A fatal error for Wii console NAND memory is not returned when building a disc application, but the following drive errors may be detected while loading. The following result codes may be returned when loading files in the case of disc applications.
| Return Values | Description |
| CNT_RESULT_READ_ERR | A fatal error occurred while loading a disc. |
| CNT_RESULT_DVD_CANCELED | Disc load was canceled. |
Beginning from NADK Version 2.2, the specifications of CNTRead have been changed so that the behavior and calling method are the same as NANDRead. Points that have been changed are as follows.
offset argument has been eliminated.
To ensure backward compatibility after these changes to specifications, the CNTReadWithOffset function, which has the same behavior as the previous version of CNTRead, has been added.
In addition, the macro CNT_READ_BACKWARD_COMPATIBLE for replacing CNTRead with CNTReadWithOffset has been prepared. Applications created using versions of NADK earlier than NADK Version 2.2 can be ported to this version by defining this macro before the includes in the header file.
The CNTShutdown function was added to NADK Version 1.3 onward for safe device shutdown. Be sure to always call this function before executing OSShutdownSystem.
Makefile (modified as needed to match your development environment), and link the CNT library.
|
obj/RVL without being differentiated. In the future, this may be changed so that they are output to different targets.darch.exe) are supported for the file format of content files. See darch for details on the archiver.CNTHandle structure for each new thread.CNTInitHandle must be 32-byte aligned.Support for MEM2 size simulations has been added from NADK version 2.0 However, the MEM2 size may not be set by a script as it is with the SDK. By default, NAND applications run with a MEM2 size of 64MB; this is done to prevent the corruption of master data. An option must be specified when starting up Nmenu to set the MEM2 size to 128 MB. See Nmenu for details on the specification method.
Support for debugging NAND applications in CodeWarrior has been added from NADK version 2.0. However, NAND applications created by a NADK package before version 2.0 cannot be used. The Sample Demos show an example of debugging a sample demo in CodeWarrior; refer to this page for more information on debugger settings.
A data title is a WAD file saved in Wii console NAND memory so that its content can be referenced by other applications. You can use NADK to develop data titles and to develop NAND applications that access data titles.
To develop applications that make use of data titles you need to have ECDK (the E-Commerce Library), which is provided separately.
Data titles are handled in basically the same way as normal NAND applications.
darch.exe) in the Revolution SDK.makeWad.exe (refer to makeWad for information on the options to specify).Data titles differ from NAND applications in the following ways.
CNTInitHandleTitle must be used to access a data title.Just like normal NAND applications, you can use a compile switch for data titles that switches them between disc access and Wii console NAND memory access.
For disc access, place the data in the following directory, with the game code of the data title to access filled in for game code and the index of the content file in index.
|
CNTInitHandleTitle function and open the data title's content file.
Note the following points regarding data title disc access.
Be aware of the following points when running an application using the ECDK.
0000" when they are run, so you must allow access from "0000" for these programs to access data titles.OSExecv and OSExecl functions cannot be used. There are no plans to add support.OSSetSaveRegion cannot be used to protect a specified region when a reset occurs. There are no plans to add support.0001" (0x30303031), so the application is always overwritten when importing. When you want to avoid this, use the makeWad options to specify a game code.
2009/01/15 Changed darchD to darch.
2008/10/02 Added that program size restrictions differ from those for disc applications.
2008/07/09 Added the Nmenu WAD file to the package.
2008/07/03 Added information on processing CNT_RESULT_UNKNOWN.
2008/06/17 Added the explanation for disc emulation of data titles. Added to the CNT API note the fact that the number of simultaneously opened files during disc access is unlimited.
2008/06/05 Added mention of the game version's effect on overwrite-imports in Nmenu.
2008/05/28 Added notes concerning data title access from programs in the ELF and RPF file format.
2008/05/21 Changed Revision History to [Revision History up to NADK 2.2 Patch 3] because this was integrated with the SDK.
2008/05/09 Added a note concerning disc applications that use the CNT library.
2008/04/30 Added support for accesses performed by disc emulation for data titles.
2008/04/22 Added a note on data title development when using the ECDK.
2008/03/27 Added explanations for the game version and version updates.
2008/03/14 Revised the description of CNT_RESULT_ACCESS.
2008/02/20 Moved the description of shared content files.
2008/02/15 Consolidated information on data titles. Added a description of the Strap Usage Screen.
2008/02/13 Added a description of data titles and a link.
2008/01/15 Added information about changes to CNTRead specifications and backward compatibility. setncountrycode has been been integrated with setcountrycode.
2008/01/08 Added a description of compression of programs. Revised the description of CNTShutdown.
2007/12/11 Revised the description of shared content files.
2007/12/06 Added a note on the limit on program size. Added a link to the revision history.
2007/11/20 Added information about errors that may occur with disc applications. Standardized the use of the term "content file." Standardized the use of "Nmenu."
2007/10/17 Added a note about OSSetSaveRegion.
2007/09/12 Added information about the game version. Corrected typos.
2007/08/07 Added caution about the shared content deletion feature that is no longer being publicly disclosed.
2007/08/06 Added a description about master data settings. Deleted supported and corrected issues from the limitations.
2007/07/11 Added text noting the support for CNT_RESULT_CORRUPT. Added text noting that the CNT API can only handle files that are in the form of archive files.
2007/05/10 Added a description on debugging in CodeWarrior.
2007/04/26 Added guidelines for responding to result codes. Added and deleted some notes.
2007/03/27 Added a description about the 32-byte alignment of memory allocators.
2006/12/12 Corrected typos.
2006/12/04 Revised the list of result codes. Revised some terminology.
2006/10/26 Added country code and Parental Controls checks to Nmenu. Added result code descriptions.
2006/10/25 Added a caution regarding shared content.
2006/10/20 Added sections about shared content and device shutdown. Made some additions and revisions.
2006/09/08 Made some revisions.
2006/08/15 Initial version.
CONFIDENTIAL