Termination Status
User's Guides
The Main Ways of Handling the Main Errors
Points to Note in Error Handling
Error Codes
Recommended Error Handling Sequences
This section refers to flowcharts in discussing the kinds of sequences that best handle errors. These error-handling sequences use the following three expressions for the termination status of each function.
With abnormal termination, the error number and cause of the error are displayed on the screen. The game user is asked to read the user's guides and attempt to solve the problem based on this information. With forced termination, LeoClearQueue() is called, and functions that have been interrupted during execution or canceled while awaiting execution are forcibly terminated. (LeoClearQueue() itself always terminates normally.) The reasons for interrupting the functions vary depending on the game. Thus, subsequent efforts to cope with the error will take these reasons into account.
There are two types of user's guides, the guide included with the 64DD and that included with the game. For reference, APPENDIX C lists the error messages given in the user's guide included with the 64DD. Future documentation will discuss how these error messages should be described in user guides that accompany games.
The Main Ways of Handling the Main Errors (parentheses contain error numbers)
This section discusses the handling of the main errors that occur and how these handling methods are implemented. For specific handling methods, please see the section Recommended Error-Handling Sequences. The items discussed for each error and their descriptions are as follows.
| Cause | The main causes of the error are given. |
| Coping Methods | Coping methods that can be used in the program are briefly described. Please see Recommended Error-Handling Sequences. |
| Display/Non-display of Error Numbers | This indicates whether the error number should be displayed with the error message. |
| Error Messages | This item indicates the kind of expression that should be used to communicate the error to the user. Text with (Example) before the quote marks is one example of message text. Please use text that is appropriate for the game. Ensure that message text that is not preceded by (Example) is displayed to the screen without revision. (This should be strictly observed.) |
DIAGNOSTIC_FAILURE(02)
Cause
This error occurs if the eject button remains in the partially depressed state for several seconds with the disk is inserted. A partially depressed state is one in which the eject button is partially depressed and the disk has not been ejected (remains inserted).
Coping Methods
Prompt the user to eject the disk once and then reinsert it. Do not display the error number. Continue to display this error until reinsertion (including the time during which the disk is ejected).
Display/Non-display of Error Numbers
Display
Error Messages (example)
"The eject button may have been pushed. Please remove the disk once and completely reinsert it."
Cause
Coping Methods
With cause 2), the RTC will operate normally once the time has been set.
When the cause is 1), the RTC will operate normally immediately after it has been set, because power is supplied to the RTC from the N64 when it is turned on. However, the same error will recur once the N64 power is turned off and on again.
With disk-startup games, it is unlikely that 1) or 2) will occur as a result of a problem in the game. (The error most likely occurs in the IPL. Thus, with 1) or 2, setting the time in the IPL will probably prevent the error from occurring in the game.) Consequently, treat 3) as the cause, and consider the problem an abnormality.
With Game Pak ROM-startup games, check the clock time once at startup (see 2. Initialization Sequence for Game Pak-Startup Games). If the error occurs, prompt the user to set the clock once. If the cause is not 3), the error will not likely occur until the N64 is turned off, as mentioned previously. The game user can determine that the cause is 1) if the error appears to occur at every startup, 2) if it appears to occur only once, and 3) in other cases. Ultimately, the only means of handling the error in the program is to prompt the user to set the clock once (put up a display asking the user to see the User's Guide for details).
Display/Non-display of Error Numbers
Non-display
Error Messages (example)
With disk-startup games: "Please refer to the User's Guide."
With Game Pak ROM-startup games (examples)
"Please set the time. For details, refer to the User's Guide." "Please push the ** button to display the menu, then set the time. For details, refer to the User's Guide." The first portion of each of the examples is given as a suggestion, but please be sure to add "For details, refer to the User's Guide" and provide a thorough description in the user's guide.
UNRECOVERED_READ_ERROR(23)
Cause
This error message appears when C2 error correction cannot be performed. It also occurs when the program attempts to read from a block that has not been written to. (See 7.9, Power Failure During a Write). In addition, this error occurs when reading is attempted of a block that has never been written to. For information on C2 error correction, see 7.8, Retry and Error Correction.
Coping Methods
If this error occurs when the program attempts to read from the ROM area, the disk cannot be used unless it has a mirror area (other disk area containing identical data). Display the error and prompt the user to refer to the User's Guide. If the error occurs when backup data are being read, the disk itself can be used even though those data cannot be used. Please refer to 7.9 Power Failure During a Write and implement appropriate processing. In addition, depending on the evaluation by the game, please provide the user with an explanation, such as indicating that the data have been lost.
The error also occurs when the program attempts to read from a block that has not been written to. (Please note, however, that occurrence of the error cannot be guaranteed; whether or not the error will occur is uncertain.) Consequently, please be sure to initialize at startup the RAM area used by the game, or submit the master with some type of initialization value inserted from the start. (See Chapter 12).
If a variable is used to specify the block, the variable may be destroyed by a bug, and a block may be accessed that was not intended to be accessed. Please take adequate precautions against such problems.
Display/Non-display of Error Numbers
Display when the error occurs in the ROM area; Do not display when the error occurs in the RAM area. Please see Coping Methods above.
Error Messages
"Please refer to the User's Guide." (When an error occurs in the ROM area)
COMMAND_TERMINATED(34)
Cause
This error occurs when processing of the function is interrupted byLeoClearQueue().
Coping Methods
The handling method depends on whether LeoClearQueue()is used at some point in the game program.
If it is, the programmer then deliberately interrupts functions that are in the middle of execution or waiting to be executed. Thus, the coping method used depends on the reason for the interruption and varies between games and situations. As a result, the expression used for all such cases is "Forced interruption." Subsequent handling should be appropriate for the situation.
If LeoClearQueue()is not used in the game program, the error should not be returned, so the error should be handled as being of uncertain cause. Display the error number and the message "Please refer to the User's Guide," and consider this an abnormal termination.
Display/Non-display of Error Numbers
Depends on the case. Please see Coping Methods above.
Error Messages
"Please refer to the User's Guide." (when error message displayed)
Cause
Occurs when the size of the command queue is insufficient.
Coping Methods
The first and foremost approach is to ensure that the document queue is large enough to prevent this error. For the rare case of the error occurring despite this prevention, implement an error handling sequence or some other measure.
An example of such a measure is to allow some time to pass after the error occurs, then again call the function for which it occurred (e.g. call during an interrupt of the next vertical trace). However, if too much time is required for the command queue to empty, display the error message to the screen.
Display/Non-display of Error Numbers
Depends on the case. Please see Coping Methods above.
Error Messages
"Please refer to the User's Guide." (when error message displayed)
DEVICE_COMMUNICATION_FAILURE(41)
Cause
Coping Methods
With either cause, resuming operation and accessing 64DD is very risky in this state. Consider this an abnormal termination, interrupt processing, and prompt the user to refer to the User's Guide.
Only during development can the IPLROM cassette not being connected be considered a possible cause of the error. Using 5.3 Debugging during Development as a reference, ensure that the IPLROM cassette is connected.
Display/Non-display of Error Numbers
Display
Error Messages
"Please refer to the User's Guide."
MEDIUM_NOT_PRESENT(42)
Cause
Occurs when a function requiring the disk is called and the disk has not been inserted.
Coping Methods
Prompt the user to insert the disk.
Display/Non-display of Error Numbers
Either
Error Messages (examples)
"Has the disk been inserted?" "Please insert disk."
POWERONRESET_DEVICERESET_OCCURED(43)
Cause
Occurs immediately after power to the 64DD is turned on or immediately after the 64DD is reset. Power to the 64DD is provided through the 50-pin expansion connector on the underside of the N64. Thus, the error may occur in the following cases.
Coping Methods
The methods vary depending on whether it is a disk-startup game or Game Pak-startup game.
With a disk-startup game, 1), 2), and 3) do not occur in the game program.
Therefore, with a disk-startup game, prepare for the rare case of this error occurring for another reason by simply displaying the error number and the message "Please refer to the User's Guide" to the screen.
With a Game Pak-startup game,(the cause may be 1), 2), or 3).
Cases 1) and 2) are likely to occur in LeoReadDiskID(), which is called immediately after the initialization function is called.
This error should not result in these two cases. Therefore, in both cases, call LeoResetClear() (see section 7.5.2, Clearing a Reset State) to clear the reset. When this function is called, the "reset status" of the 64DD is cleared if roughly 300 ms has elapsed since power to the 64DD was turned on or it was reset. If 300 ms has not elapsed when the function is called, the reset status is not cleared. Whether the clearance was successful cannot be determined until the next function is called. Therefore, please call LeoReadDiskID() again after calling LeoResetClear(). If LeoReadDiskID()does not return a POWERONRESET_DEVICE_OCCURRED error, the clearance was successful. If it does return this error, return to the point where LeoResetClear() is called and repeat the call until the error is not returned (until approximately 300 ms elapses). It is recommended that the LeoResetClear()/LeoReadDiskID() calls be repeated at a rate of once per frame or less. The elapsed time can be roughly measured by counting the number of such call repetitions. If the error is returned even though 500 ms has elapsed, an abnormality is clearly indicated, and the error number and the message "Please refer to the User's Guide" should be displayed to the screen. For example, if these functions are called once per frame and the error continues even if the calls are repeated 30 times, an abnormality has occurred.
If the error occurs at a point other than 1) or 2), it is a case of 3) and should be considered a fatal error. As with a disk-startup game, display the error number and the "Please refer to the User's Guide." (However, a hang up may also occur with a Game Pak-startup game due to security measures.)
Display/Non-display of Error Numbers
Display (see Coping Methods above)
Error Messages
"Please refer to the User's Guide."
MEDIUM_MAY_HAVE_CHANGED(47)
Cause
Occurs when the disk is exchanged for another.
Coping Methods
First read the disk ID and confirm that the appropriate disk has been inserted. If the appropriate disk has not been inserted, notify the user. (Whether a disk is appropriate varies with the game and situation. With single-disk games, the inserted disk is the appropriate disk. With two-disk games, the second disk is appropriate when the situation calls for substituting it for the first disk. The various marketing formats and the corresponding appropriate responses are to be discussed in a separate document.)
Display/Non-display of Error Numbers
Either
Error Messages
Vary with the situation. (Examples) "Disk 2 has been inserted. Please insert Disk 1." "This is not a (game name) disk. Please insert a (game name) disk."
EJECTED_ILLEGALLY_RESUME(49)
Cause
Occurs when the user pushes the eject button while the disk is being accessed.
Coping Methods
Warn the user that doing so is risky and prompt them to insert the disk.
Display/Non-display of Error Numbers
Display
Error Messages
[Caution: Do not remove a disk when the access lamp is blinking. For details, refer to the User's Guide. Please insert a disk.] (Be sure to display portions except "Please insert a disk." "Please insert a disk." portion is simply an example.)
Other Errors
The causes of other errors are briefly described below. For handling methods, please see section 10.2, Error Handling Sequences.
DRIVE_NOT_READY(1)
The motor is not turning or is unstable.
COMMAND_PHASE_ERROR(3)
The drive status is abnormal.
DATA_PHASE_ERROR(4)
Occurs when data transfer is not completed in the prescribed time.
BUSY(8)
The PI bus is in use when the LeoTestUnitReady( )function is executed.
INCOMPATIBLE_MEDIUM_INSTALLED(11)
A disk of an unsupported format has been inserted.
NO_SEEK_COMPLETE(21)
Occurs when a seek cannot be performed.
WRITE_FAULT(22)
Occurs when track location information is not read, and the track over which the head is positioned cannot be determined.
NO_REFERENCE_POSITION_FOUND(24)
Occurs when the head is positioned over the desired track, but data for correcting its position to the center of the track cannot be read.
TRACK_FOLLOWING_ERROR(25)
Occurs when the head strays from above the track after seeking is completed and reading or writing has begun.
INVALID_COMMAND_OPERATION_CODE(31)
Occurs when an erroneous command is issued to the Leo manager. This error usually is not available.
LBA_OUT_OF_RANGE(32)
Occurs when a function specifies an LBA that is out of the LBA range.
WRITE_PROTECT_ERROR(33)
Occurs when an attempt is made to write to the ROM area.
ILLEGAL_TIMER_VALUE(36)
Occurs when LeoSetRTC( ) attempts to set the RTC to a non-existent date or time, such as February 30.
WAITING_NMI (37)
An error that is returned to the command that had been executing when LeoReset( ) was executed and to the subsequently executed command.
The errors that can be returned from 64DD functions are those indicated above. The following are not errors that are obtained as the returned value of a function. Rather, they should be used with cassette-startup games as codes to be displayed to the screen to notify the game user.
RAMPACK_NOT_CONNECTED(44)
An error that indicates that the Memory Expansion Pak has not been connected. The developer needs to be aware of this code only for cassette-startup games.
With cassette startup, the game program must check whether the Memory Expansion Pak is connected. Specificially, if the return value of the osGetMemSize( ) function is not 0x00800000, the Memory Expansion Pak is judged not to be connected. In such cases, this number should be used as the displayed error number. For more information, see 2. Initialization Sequence for Game Pak-Startup Games. Note that this error code is not the return value of osGetMemSize() function.
With disk-startup games, the developer need not consider this code. The IPL checks the Memory Expansion Pak connection and displays errors (see 4.1 IPL for detail.)
Although the following errors need be of no concern to the developer, they are briefly described here. They are not returned as error codes, and the developer does not need to use them.
NOT_BOOTED_DISK(45)
DIDNOT_CHANGED_DISK_AS_EXPECTED(46)
Reserved. These values are not returned as error codes.
RTC_NOT_SET_CORRECTLY(48)
DIAGNOSTIC_FAILURE_RESET(50)
EJECTED_ILLEGALLY_RESET(51)
An error code used only by the IPL. The developer need not use them.
Points to Note in Error Handling (items to be strictly observed)
This section discusses points that must be strictly observed in actually writing the error handling portion of a program. Failure to observe these points may result in disk destruction or other irreversible problems. Therefore, please take adequate note of these items.
| Error Code | Error Name(defined in leo.h) |
| 0 | LEO_ERROR_GOOD |
| 1 | LEO_ERROR_DRIVE_NOT_READY |
| 2 | LEO_ERROR_DIAGNOSTIC_FAILURE |
| 3 | LEO_ERROR_COMMAND_PHASE_ERROR |
| 4 | LEO_ERROR_DATA_PHASE_ERROR |
| 5 | LEO_ERROR_REAL_TIME_CLOCK_FAILURE |
| 8 | LEO_ERROR_BUSY |
| 11 | LEO_ERROR_INCOMPATIBLE_MEDIUM_INSTALLED |
| 21 | LEO_ERROR_NO_SEEK_COMPLETE |
| 22 | LEO_ERROR_WRITE_FAULT |
| 23 | LEO_ERROR_UNRECOVERED_READ_ERROR |
| 24 | LEO_ERROR_NO_REFERENCE_POSITION_FOUND |
| 25 | LEO_ERROR_TRACK_FOLLOWING_ERROR |
| 31 | LEO_ERROR_INVALID_COMMAND_OPERATION_CODE |
| 32 | LEO_ERROR_LBA_OUT_OF_RANGE |
| 33 | LEO_ERROR_WRITE_PROTECT_ERROR |
| 34 | LEO_ERROR_COMMAND_TERMINATED |
| 35 | LEO_ERROR_QUEUE_FULL |
| 36 | LEO_ERROR_ILLEGAL_TIMER_VALUE |
| 37 | LEO_ERROR_WAITING_NMI |
| 41 | LEO_ERROR_DEVICE_COMMUNICATION_FAILURE |
| 42 | LEO_ERROR_MEDIUM_NOT_PRESENT |
| 43 | LEO_ERROR_POWERONRESET_DEVICERESET_OCCURED |
| 44 | LEO_ERROR_RAMPACK_NOT_CONNECTED |
| 45 | LEO_ERROR_NOT_BOOTED_DISK |
| 46 | LEO_ERROR_DIDNOT_CHANGED_DISK_AS_EXPECTED |
| 47 | LEO_ERROR_MEDIUM_MAY_HAVE_CHANGED |
| 48 | LEO_ERROR_RTC_NOT_SET_CORRECTLY |
| 49 | LEO_ERROR_EJECTED_ILLEGALLY_RESUME |
| 50 | LEO_ERROR_DIAGNOSTIC_FAILURE_RESET |
| 51 | LEO_ERROR_EJECTED_ILLEGALLEY_RESET |
Recommended Error-Handling Sequences
Recommended error-handling sequences are shown below. If these sequences are not used, please adhere to the guidelines given in the previously mentioned items to be strictly observed and to the handling methods given with the description of each function (not including the example sections). Although loops are commonly used, please be careful to ensure that they are not infinite loops. For example, when the program is waiting for disk insertion, a disk-insertion check once every 1 or 2 frames is sufficient. Please note that programming the check itself as a loop entirely precludes graphics display and other such processing until the disk is inserted. To see how a loop shown in one of the flowcharts can be programmed, please refer to the included sample program ddspgame.
Note: When an error occurs during reading, the method of handling will likely depend on which block the program was attempting to read. For example, when the block is in the ROM area, the game cannot continue to the next scene because the data cannot be read, and the game must at that point be interrupted. However, when backup data in the RAM area cannot be read, even though these data cannot be used, the game can continue by using separately saved data. Please handle these circumstances flexibly and in accordance with the needs of the particular game. Each of the following sequences assumes that the error prevents the game from continuing.
Index by Role
Error-Handling sequence for initialization (disk startup)
Error-Handling sequence for initialization (Game Pak startup)
Error-Handling sequence for read, write, seek, and rezero
Error-Handling sequence for disk-insertion check
Error-Handling sequence for reading the ID
Error-Handling sequence for reading the internal clock
Error-Handling sequence for setting the internal clock
Error-Handling sequence for changing the motor halt time
Error-Handling sequence for halting the motor
Error-Handling sequence for motor startup
Error-Handling sequence for ejection check
Index by Function Used
LeoCreateLeoManager( )
LeoC*CreateLeoManager( )
LeoReadWrite( )
LeoSeek( )
LeoRezero( )
LeoReadDiskID( )
LeoReadRTC( )
LeoSetRTC( )
LeoModeSelectAsync( )
LeoSpdlMotor( )(SLEEP)
LeoSpdlMotor( )(ACTIVE, STANDBY)
LeoTestUnitReady( )
* LeoInquiry( ), LeoReadCapacity(), and LeoClearQueue( ) do not return errors and are therefore omitted from the list of error-handling sequences.
* LeoByteToLBA( ) and LeoLBAToByte() return an LBA_OUT_OF_RANGE error when out-of-range numeric values are given as arguments but do not return an error in any other case. They are therefore omitted from the list of error-handling sequences.
* Displaying Error Numbers and Messages
In the sequences shown below, expressions like "Display . . . in Area" are used to describe the display of error numbers and messages. These "display areas" are assumed to be as shown in the following figure.
As the figure indicates, the message display region of the screen is divided into three major areas. These are labeled areas (1), (2), and (3), indicating their relative distance from the top of the screen. Area (1) is used for displaying error numbers, Area (2) for displaying material such as error descriptions and user alerts, and Area (3) for displaying specific instructions to the user (e.g., "Please remove the disk.").
In the sequences, the display of material in an area and the clearing of that area are generally matched (e.g., "Display . . . in Area (1) " and "Clear Area (1)). Once material is displayed in an area, that display should not be erased until the processing for clearing that area has begun. Although an area can be used to display a message before that area is cleared, the message will be written over the message previously displayed in that area. (With abnormal termination, the sequence terminates without the screen first being cleared. In this case, displaying and clearing are not matched).