November 12, 2001 Volume 1, Issue 6
©2001 Nintendo. All rights reserved. Avoiding Lot Check Pitfalls By Nintendo SDSG bugs or Guideline violations. If your game passes, the same procedure is performed at Nintendo Co. In This Issue: SDSG has been very busy these past few weeks Ltd. assisting developers with the Lot Check process Lot Check Pitfalls 1 and the Nintendo Guidelines. Now that we are Follow the Nintendo GameCube Nomenclature Moving from Dev Kit to over the launch title hump, we thought it would Document Production Console 7 be appropriate and beneficial to share what There are very specific ways of referring to the we’ve learned. This article covers some WAVEBIRD 8 Nintendo GameCube and its assorted components common pitfalls that were encountered by the and peripherals. Make sure you follow the launch title developers. (Names have been guidelines published by Nintendo. Our Legal removed to protect the innocent.) department is very particular about this. A game First, let's provide some background failed Lot Check because they used "Nintendo information. Lot Check is made up of dedicated Gamecube" instead of "Nintendo GameCube" game testers who methodically explore every (among other things). So be careful! possible unwanted scenario that your game may Follow Figure 2 in the Nintendo GameCube encounter. Their purpose is to ensure that Memory Card Guidelines players are satisfied with a consistent, bug-free interface to your game and to the Nintendo- Every launch title had this problem. (Send flame specific features. Lot Check also tests your mail to [email protected].) The flowchart in Figure game on every hardware revision that Nintendo 2 should be followed every time a Memory Card is releases (hence the name “Lot Check”). When mounted, and it’s required at the beginning of your you submit your game to Nintendo of America game (before gameplay). You may change the Inc., Lot Check will test your game to find any (continued on next page)
HOW TO AVOID THE MOST COMMON LOT CHECK PITFALLS: ¾ Follow the Nintendo GameCube Nomenclature Document ¾ Follow Figure 2 of the Nintendo GameCube Memory Card Guidelines ¾ Use Informative Memory Card Error Messages ¾ Use One Memory Card File (if possible) ¾ Handle Hot-Swapping Support ¾ Create Memory Card IDs SDK Version ¾ Make Memory Card Messages Slot-Specific ¾ Handle All Memory Card Configurations The current release is ¾ Avoid Variable-Length Memory Card Files dated Sept. 8, 2001. ¾ Disable the Rumble Feature per the Guidelines Look for Patch 3 at ¾ Manage RESET Button Correctly www.warioworld.com. ¾ Handle Erase Errors and Program Errors (Memory Card Emulator) ¾ Handle Optical Disc Drive Fatal and Retry Errors 2 NINTENDO GAMECUBE™ Development News
Avoiding Lot Check Pitfalls Use Informative Memory Card Error Messages (continued from previous page) When you first read through the Guidelines, you may notice the messages, but all possible Memory Card configurations are lack of very specific error messages for the specific error states circumscribed by the requirements in Figure 2. described above. Lot Check has found that giving specific While the messages may change, the error states will not change messages is often more confusing than not. Messages and display for a given CARD library. Be sure to recognize the various error formats are very game-specific, thus it is difficult to generate a states produced by the CARD library. There is a specific state list of messages that are not subject to change depending on game that applies to every return value for every CARD API, and design. Lot Check’s Memory Card Guidelines serve the most Memory Card issues are due to improper handling of these fundamental purpose of protecting and informing the player of errors. For example, CARD_RESULT_FATAL_ERROR is due any potential problems. Specifically, Lot Check wants to protect to program design or usage error. The CARD_RESULT_BUSY the player from loss of data or hours of gameplay. Your game is error means the current function is busy or waiting for another required to reflect these guidelines with proper, informative function to finish, so your program should call the function messages that alert the player to any possible problems. again. Table 1 provides a list of common error states and their That being said, we have compiled a list of error messages in path through Figure 2. Table 2. Keep in mind that these are only examples provided by (continued on next page) Table 1. A technical view of the current error states and their API path through Figure 2 of the Memory Card Guidelines Error Description Path through Memory Card Guidelines Figure 2 Capacity Your game must be aware of the Memory Card The application must verify card capacity. capacity. This only affects messages and management CARDProbeEx() returns card size in Mbits. screens that describe the number of free files or blocks. Sector Your game (as of this newsletter) must support only The application must verify card sector size. 8KB sector-sized Memory Cards. CARDProbeEx() returns sector size in bytes. Encoding Region encoding enforcement. CARDProbeEx(): CARD_RESULT_READY CARDMount(): CARD_RESULT_ENCODING Program/Erase Program and Erase errors are two scenarios of Will not necessarily show up in Figure 2. Any damaged Memory Cards. CARD API that attempts to write to a block will return CARD_RESULT_IOERROR. For example, CARDWrite(): CARD_RESULT_IOERROR CARDCreate(): CARD_RESULT_IOERROR CARDFormat(): CARD_RESULT_IOERROR Damaged A physically damaged Memory Card. CARDProbeEx(): CARD_RESULT_READY CARDMount(): CARD_RESULT_IOERROR Corrupt Corrupted system area. CARDProbeEx(): CARD_RESULT_READY CARDMount(): CARD_RESULT_BROKEN CARDCheck(): CARD_RESULT_BROKEN Recoverable Recoverable corruption to system area. CARDProbeEx(): CARD_RESULT_READY CARDMount(): CARD_RESULT_BROKEN CARDCheck(): CARD_RESULT_READY Data Corrupt The data portion of file is corrupted. The application must validate its own user data by use of a checksum, CRC, etc. at any data load time. NINTENDO GAMECUBE™ Development News 3
Avoiding Lot Check Pitfalls (continued from previous page) proper messages. Lot Check solely for this article. Lot Check reserves the right to Player options are very important. Lot Check prefers users to have change or refuse these messages if they do not correspond to the the following options for consistency across games: current Memory Card Guidelines. • Continue Without Saving The trickiest message is the “Full” message. Notice that Table 2 • Retry doesn’t give a clear answer in the “Error” column for the • Manage Memory Card “Capacity” entry. You will need to take into account your game’s save structure, including the number and size of the files “Continue Without Saving” has been around as long as the N64 created. There may be times when you can save one or several, and has become a Nintendo standard. Please use this exact phrasing but not all, of your game files to a Memory Card. Generate a where appropriate to meet Lot Check standards. matrix of all possible “Full” scenarios for your particular configuration, and make sure that the user is fully informed with (continued next page) Table 2. Example messages and options that correspond to the errors listed in Table 1 Error Message Options Action Upon Selection Capacity Game-specific. Used for messages relating to space availability Sector The Memory Card in Slot Continue Without Saving Continue Without Saving—proceed with game. A/B is incompatible with No other save opportunities are required. Retry the
Avoiding Lot Check Pitfalls (continued from previous page) Listing 1. Determining the number of files available “Retry” allows the user to insert another // return number of files available card and retry the current option (i.e., call // or return -1 if error accessing card s32 GetNumFilesAvail( s32 chan ) the API in Memory Card Guidelines { Figure 2). u32 numBlocks; u32 filesAvailable; Handling the “Manage Memory Card” s32 filesNotUsed; option is a little tricky. This option only s32 freeBytes; s32 freeBlocks; pertains to the full Memory Card message. u32 sectorSize; When your game is first booted and a full s32 result; card is inserted, we recommend resetting u16 cardSize; the system and forcing the Memory Card s32 totalSize; Menu to be displayed so that the player do can manage his card using the IPL. Since { result = CARDGetSectorSize(chan, §orSize); this must happen at the very beginning of } while (result == CARD_RESULT_BUSY); your game, the player cannot lose any if (result != CARD_RESULT_READY) data. return -1; However, during gameplay, the user may do { lose data if the system is rebooted. If your result = CARDFreeBlocks(chan, &freeBytes, &filesNotUsed); game saves multiple files, then the user } while (result == CARD_RESULT_BUSY); can fill up his or her Memory Card with if (result != CARD_RESULT_READY) your game’s files. Therefore, you should return -1; be responsible for allowing the user to delete them. In this scenario, the “Manage freeBlocks = freeBytes / (s32)sectorSize; Memory Card” option should take the user do to an in-game Memory Card management { interface that allows him or her to delete result = CARDGetMemSize(chan, &cardSize); your game’s files. All games that have } while (result == CARD_RESULT_BUSY); if (result != CARD_RESULT_READY) only one file can simply send the player to return -1; the IPL, but they must display a message that informs the player that “unsaved data // size of card in bytes totalSize = cardSize*1024*128; will be lost.” // number of user blocks available numBlocks = (totalSize / sectorSize) - 5; Use One Memory Card File (if possible) // number of files (max is number of blocks on card) if (numBlocks > 127) The games with the fewest Lot Check numBlocks = 127; issues only used one Memory Card file. This doesn't necessarily mean that you filesAvailable = numBlocks-(127-filesNotUsed); cannot use multiple file-saving schemes. return (s32)filesAvailable; // 4 MBit For example, many N64 games used the } EEPROM to save “multiple files” that were stored in a fixed size memory buffer. Using a multiple hot-swapping introduces complexities to your Memory Card file scheme within one (fixed-length) Memory Card file management state machine. It must recognize that a card has been simplifies Lot Check issues since you have more control over removed and perform all initial error checking (i.e., the API flow in your file system. Figure 2) on the next Memory Card action. Handle Hot-Swapping Support Therefore, it is much easier not to support hot-swapping. In this case, if the player pulls out the Memory Card at any point of the game, then This is a very misunderstood topic. Hot-swapping refers to the your game may demand that he or she put that specific Memory Card removal and insertion of Memory Cards during gameplay. back. If an error has occurred or another card has been detected, the Nintendo GameCube supports hot-swapping, but Lot Check player’s options—at bare minimum—should be to “Retry” (check for doesn't require your game to fully support it. You'll notice that the original card again), or to “Continue Without Saving.” That being hot-swapping is not mentioned in the Guidelines. Support for (continued next page) NINTENDO GAMECUBE™ Development News 5
Avoiding Lot Check Pitfalls (continued from previous page) said, this scenario is not very player-friendly; it leaves him or her with very little information about what went wrong. Games The Memory Card submitted with only this bare minimum may raise questions in Emulator Lot Check, so we advise against this. An acceptable version of this scenario is to add a “Mount new Memory Card” option to your game. This in-menu option would perform the same card-checking logic used at the beginning of the game. This should be a simple addition, so please implement this if you do not wish to support hot- the variable number of blocks that may be available. In other swapping. words, do not hard-code “4 Mbits” as the maximum size of a Memory Card. provides a method for Create Memory Card IDs CARDFreeBlocks() determining available blocks; Listing 1 (see page 4) offers an Another Lot Check requirement is that games inform the user if example of how to determine the number of files available. data will be overwritten when a new Memory Card is inserted. A simple detection method is to flag when a Memory Card has Nintendo will be able to provide a Memory Card Emulator (shown been removed. You can accomplish this by making a unique ID at right) that emulates various configurations of Memory Cards. and storing it in the file on the Memory Card. This device gives you the capability of emulating 4, 16 and 32Mbit- capacity Memory Cards with 8KB and 16KB sector sizes. As of the To create this ID, save the current time in milliseconds into the printing of this newsletter, these devices are in short supply and are data portion of your file any time you write to the file, then on loan to developers who are in the final stages of their title. This remember this timestamp for the duration of gameplay. pressure will be relieved when production versions of the Memory Whenever you want to save or load, you can guarantee that you Card Emulator are available from our Parts department. have the same Memory Card by comparing the timestamp. Avoid Variable-Length Memory Card Files Remember to create a new timestamp ID on any saves so that Memory Cards have unique timestamps when any data is Using variably-sized Memory Card files is risky. The test matrix altered. This helps your game recognize different Memory for this scenario is much larger than for fixed-size files, which Cards, even after the file has been copied to another Memory leaves more room for error. If you must use variable file sizes, then Card in the IPL. Note that until the user actually saves data to we strongly recommend contacting Lot Check to approve your one or the other, both Memory Cards are considered equal. design before submitting your game. Once a file is updated, the two Memory Cards will differ, which Disable the Rumble Feature is why you want to write the timestamp on every save. Games must not use the Rumble feature during non-controlled Make Memory Card Messages Slot-Specific sequences or situations where the game is waiting for user input. Every error message or graphical representation should indicate Specifically, disable the Rumble feature during demos, selectable the current Memory Card slot. Text such as “Slot A or B” is user messages, and when the game is paused (as in a menu). unacceptable. Manage RESET Button Correctly Handle All Memory Card Configurations Your game must properly handle a RESET Button push at every There are two variables that need to be considered when point of your game. Some of the Programming Cautions that are working with Memory Cards: sector size and capacity. easily overlooked are sections 5.2 – 5.4. These are “failable offenses” and must be handled properly. Basically, if the player At launch, Nintendo GameCube Memory Cards will have a holds down the RESET Button, the game must continue as-is until 4Mbit capacity and 8 KB sectors. This sector size may change the player releases the button. Make sure that the game does not in the future, and your game must account for this possibility. stop processing. When the player presses the Controller reset The current CARD API does not support non-8KB sector sizes. command (B Button, X Button and START/PAUSE Button) for Lot Check requires an error message to be displayed when a more than 0.5 second, the game must issue a system reset. The key player attempts to use a non-8KB sector Memory Card. here is that you must not reset unless the button combination has Future Memory Cards may also vary in capacity. Memory been held for 0.5 second. After 0.5 second, the game should Cards with 8KB sectors will still have a 127-file limit, but may automatically reset. have up to 32Mbits of capacity. Your game needs to account for (continued next page) 6 NINTENDO GAMECUBE™ Development News
Avoiding Lot Check Pitfalls Listing 2. Main loop with optical disc error-checking main_loop() { (continued from previous page) switch(DVDGetDriveStatus()) The lead programmer of your game should be fully aware of the { case DVD_STATE_FATAL_ERROR: three reset procedures: message = MESSAGE_FATAL_ERROR; break; • Hot Reset case DVD_STATE_BUSY: • Restart break; • Application-driven Restart case DVD_STATE_NO_DISK: message = MESSAGE_NO_DISK; break; The game should perform a Hot Reset when the IPL Memory case DVD_STATE_COVER_OPEN: Card Screen must be accessed, or when another Game Disc is message = MESSAGE_COVER_OPEN; break; detected during an Application Restart. See section 4.5 case DVD_STATE_WRONG_DISK: “Performing a Game Disc Check (only when performing an message = MESSAGE_WRONG_DISK; application-driven Restart).” All other Reset scenarios are break; case DVD_STATE_RETRY: optional. The Application-driven Restart is preferred. message = MESSAGE_RETRY_ERROR; break; As a reminder, the function OSSetResetCallback() should } not be used in a production game. In fact, we recommend not using this function at all. Having a game fail Lot Check just DisplayMessage(message); because you forgot to go back and change the reset command is SuperCoolGameCode(); not a pleasant experience for the developer or for Lot Check. } We should also mention Memory Card and reset interaction. If the user has pressed the RESET Button or invoked the Controller reset command, your game should wait until all Memory Card Listing 3. Dealing properly with saves have completed. DVD STATE FATAL ERROR int g_doNotUseDataFlag = 0; Handle Erase Errors and Program Errors int g_fatalErrorMessageFlag = 0; This is a common pitfall that is fairly easy to avoid. Just ensure void DVDCallbackFunc(s32 result, DVDCommandBlock* block) that the error CARD_RESULT_IOERROR is handled. This error { can be reproduced using the Memory Card Emulator. if (result == DVD_STATE_FATAL_ERROR) { g_fatalErrorFlag = 1; Handle Optical Disc Drive Fatal and Retry Errors g_doNotUseDataFlag = 1; } For the most part, all optical disc drive errors are handled for you if (result == DVD_STATE_CANCELED) { by the DVD library. For example, if you issue a DVDRead() g_doNotUseDataFlag = 1; } command and the disc cover is opened during the read, the DVD } API will wait until the disc cover is closed. The API will even check to see if the user has changed the Game Disc by checking its ID. Note, however, that the DVD library returns five errors that Conclusion require a message to be displayed. If you use only asynchronous We strongly recommend taking the time to read through the commands, the code to handle these messages should be fairly Nintendo GameCube Guidelines and Programming Cautions easy to implement, as shown in Listing 2. carefully and as early as possible. (The versions of the documents There is one case in which you must be careful when dealing with currently available as of this writing are listed on page 8.) This DVD API errors. A Fatal Error will drop out of the current DVD will significantly decrease the number of problems encountered at command, so you may need to check for the Fatal Error in the Lot Check. Waiting until the last month of a project to incorporate callback and set a flag to not use any of the data read. From that these requirements can prove painful. When you are anxious to point on, every DVD API command will return the Fatal Error. finish a game, the last thing you need is a mountain of Lot Check Listing 3 shows an example. requirements to implement! Emulating optical disc errors is difficult; however, the NPDP- We also recommend submitting your game for “Pre-Check” (a GDEV does offer error emulation. (DDH will support these errors trial run of Lot Check) after implementing the Guidelines. For this in the next DDK). Please see your NPDP-GDEV manual for more to be fruitful, all guidelines must be implemented. We have details. Since very few QA departments will have NPDP-GDEV, seldom seen a developer solve every problem on a long list of bug programmers should be responsible for testing their code. (continued on page 8) NINTENDO GAMECUBE™ Development News 7
Moving Your Game from Dev Kit to Production Console
By Steve Rabin, SDSG and production mode, use the ELF file HW2\bin\tools\bootmode.elf. As you get closer to shipping your game, you'll reach a point where you’ll need to verify that it works on a production console. While this shouldn’t be too painful a process, there are To turn on the IPL loadrun bootmode.elf -a 1 some issues and potential pitfalls of which to be aware. (production mode) Memory Size To turn off the IPL loadrun bootmode.elf -a 0 (development mode) The single biggest difference between a dev kit and a production system is the size of main memory. Dev kits have 48MB and AppLoader Limit production systems have 24MB of main memory. Moreover, remember that you don’t really have a full 24MB to play around When you are running in development mode, there are relaxed with because your code and the File Symbol Table (FST) will limits on the size of your dol file and the size of your data sections also occupy some of that space. (their combined size must be under 18MB). Your program code takes up to 7MB space at the bottom of When you run in production mode, however, the limits are stricter. memory and the FST takes up some space (<1MB) at the top of Specifically, all code and data sections must be below 0x80700000 memory, depending on how many files are on the Game Disc. In (7MB). The generated MAP file will have information about your order to estimate the size of your FST, refer to “Optical Disc section sizes for your particular game. Also realize that it is a Lot Library (DVD)” in the NINTENDO GAMECUBE Programmer's Check guideline for your code and initialized data to be under 4MB Guide (located in (for initial load time reasons). If you exceed the 7MB limit with //Dolphin/docs/Developer/PDF/SDK1.0/Program your code or data sections, then you will need to make adjustments mer’s Guide/DVD.us.pdf on the SDK CD). to compensate.
Once you’re confident that your game can live peacefully within Section Too Large Course of Action 24MB, you should try it out by changing your dev kit setting text (code) Look into using relocatable modules from 48MB to 24MB. Use the BASH shell script or moving some of your game logic “setsmemsize” (note the “s” after “set”). into dynamically loaded scripts. data (initialized data) Move some of the data from code into data files that are explicitly To set dev kit to 24MB setsmemsize 0x1800000 loaded in. To set dev kit to 48MB setsmemsize 0x3000000 bss (uninitialized data) Allocate some of this memory at runtime. For your custom memory allocators, make sure you are getting the proper addresses for the bottom and top of memory Here is a sample memory map where the bss section (uninitialized (arenaLo and arenaHi). Since your FST size will vary data) is too large, thus causing the sum of all the sections to exceed depending on your files, the top of memory (arenaHi) will vary the production mode limits. Note that all sections combined must be as well and must be checked at initialization. You can query below 0x80700000. arenaHi with the function OSGetArenaHi(). Exceeding the 24MB limit Starting Size File address Offset Once you’ve set your dev kit to run in 24MB of memory space, .init 80003100 000023e8 00000180 the GameCube OS will automatically watch for memory extab 800054e8 00000000 00002568 extabindex 800054e8 00000000 00002568 accesses beyond that limit (using OSProtectRange). If your .text 80005500 00104278 00002580 game accesses memory beyond the 24MB limit, it will trigger .ctors 80109780 0000000c 00106800 an OS_ERROR_PROTECTION interrupt. You can capture this .dtors 801097a0 00000008 00106820 .rodata 801097c0 0000c238 00106840 error by registering a callback function via .data 80115a00 0001d1f8 00112a80 OSSetErrorHandler(). .bss 80132c00 00a0c4b8 0012fc80 .sdata 80b3f0c0 000010b8 0012fc80 Initial Program Loader (IPL) .sbss 80b40180 0000044c 00130d40 .sdata2 80b405e0 000009d8 00130d40 On production systems, the Nintendo GameCube logo appears .sbss2 80b40fb8 00000000 00131718 at bootup in what’s called the Initial Program Loader, or IPL. .debug_srcinfo 000000 00000000 .debug_sfnames 000000 00000000 You can set your dev kit to production mode to bring up the IPL .debug 2add80 001d0e1c on bootup. To toggle the dev kit between development mode .line 09f704 00131718 Supporting the WAVEBIRD By Satoru Hosogai, SDSG Nintendo The Nintendo GameCube Wireless Controller (WAVEBIRD) presents some subtle issues of which Software developers should be aware. Because current availability of this controller is limited, this article will Development help you become familiar with some programming issues that are unique to the WAVEBIRD. Support Group Technically speaking, there is no code difference between supporting a standard controller and supporting a WAVEBIRD; however, the WAVEBIRD may behave inappropriately if the program doesn’t correctly handle the PAD_ERR_NO_CONTROLLER error. 4820 150th Ave. NE The proper way to handle PAD_ERR_NO_CONTROLLER is to call PADReset() in a continual Redmond, WA 98052 loop until the returned error value of PADStatus.err becomes PAD_ERR_NONE. Sample code demonstrating this can be found in section 4.2 of “Game Pad Library (PAD)” in the NINTENDO Phone: GAMECUBE Programmer’s Guide (located in (425) 861-2715 //Dolphin/docs/Developer/PDF/SDK1.0/Programmer’s Guide/PAD.us.pdf on the SDK CD). Phone Menu: The PAD_ERR_NO_CONTROLLER Error 1 Æ AGB There are two cases where the WAVEBIRD returns the error, even if 2 Æ CGB PAD_ERR_NO_CONTROLLER the WAVEBIRD Receiver is plugged into the controller socket. 3 Æ N64 4 Æ GCN In the first case, the error occurs because the WAVEBIRD Receiver is plugged into the controller 5 Æ Lot check socket, but the WAVEBIRD’s power is OFF. As soon as the WAVEBIRD’s power is turned ON, 6 Æ Licensing / How to the status of the controller will change from PAD_ERR_NO_CONTROLLER to PAD_ERR_NONE. become a developer 7 Æ Other questions In the second case, the WAVEBIRD Receiver is plugged into the controller socket, and the WAVEBIRD’s power is ON, but the receiver and controller channels do not match. Fax: After correcting the channel(s), the system will still return PAD_ERR_NO_CONTROLLER until it (425) 882-3585 detects a button event. Once the button event is detected, the status will change from PAD_ERR_NO_CONTROLLER to PAD_ERR_NONE. E-Mail: Also, note that once the handshaking is finished, controller status will remain as PAD_ERR_NONE [email protected] even if the WAVEBIRD’s power is turned OFF. HTTP: Using SIProbe() www.warioworld.com, The function checks the type of device plugged into the controller socket. In general, www.noa-engineering.com SIProbe() this function should not be used in the final version of your game to detect WAVEBIRD controllers. If you use , please do so with caution. returns the following error codes: NNTP: SIProbe() SIProbe() news.sdsg.nintendo.com SI_GC_RECEIVER: Occurs when the WAVEBIRD Receiver is plugged in with the WAVEBIRD OFF before handshaking, or when the Receiver is plugged in with the WAVEBIRD ON, but the wrong channel is selected before handshaking. SI_GC_WAVEBIRD: Occurs if the WAVEBIRD is working, or if the WAVEBIRD is turned OFF after handshaking. Avoiding Lot Check Pitfalls (continued from page 6) Nintendo SDSG wants to help you get through this reports and pass the next time through. There critical part of the approval process! are usually bugs hidden behind fundamental fixes to a game. CURRENT VERSIONS* OF GUIDELINES: Nintendo GameCube™ Nomenclature (1.01) We hope that this article has given you a better Video Guidelines (1.42) appreciation for our Lot Check process and you’ve become aware of potential problems that Controller Guidelines (1.4) you can avoid with early implementation of the Sound Guidelines (1.2) Nintendo GameCube Guidelines and GCN Optical Disc Drive Guidelines (1.2.2) Programming Cautions. At any point in your GCN Reset Guidelines (1.41) game development, if you have questions or are GCN Memory Card Guidelines Update (1.8a) Edited and produced by unclear on any Guideline, please contact us as *documents are subject to change; Yvette Kirby Waters, NTD soon as possible (e-mail: [email protected]). go to www.warioworld.com for the latest versions