-
Notifications
You must be signed in to change notification settings - Fork 3
List of Error Messages
If an error occurs during the program's flow, all actions will be paused on the command line, and hitting the Enter key will be required (just to confirm having read it) before anything else happens.
Here is a list of implemented error messages and what they mean.
The utility cannot start because a plain zs command was executed to launch the process. Without an additional command-line parameter to target a disk file path (preferably to a valid Zelda flash RAM game save file), nothing beyond the point of this error message can happen except program abortion.
The loaded file is probably not one valid for game save data in the case of the flash RAM chip for The Legend of Zelda: Majora's Mask. At least one page with garbage was found, or it is in a memory format whose implementation has yet to be conceived.
Otherwise, maybe the entire file is completely blank. If that is the case, this error message can be safely ignored as a warning. Try using the -= command as documented at the end of the general file manipulation commands section to force the byte order as appropriate for either N64 emulators or the actual console, or try just creating at least one new save file within the ROM's in-game file selection screen before running this utility again.
While attempting to access the on-disk file representing the contents of the game's flash memory chip, the C standard library was unable to open the file with the requested access mode. This is generally more likely to happen with file writes than reads--particularly if some kind of "Read Only" permission is set on the file system. It's also theoretically possible that the file location can't even be opened for reading either, like if another process is currently locking the file in some other concurrent usage that needs to be dealt with first.
As of yet, this error has never been encountered in any sort of practice, nor is it imaginable why it should ever be encountered. This would have to be a standard library failure in the C input/output functions with simply closing the link to the FILE stream when finished? Do tell if this ever happens.
While buffering the requested number of bytes from the disk's file system, an incomplete read occurred. This may happen due to the program importing the file on 8-byte intervals and if the file size is not a multiple of 8 bytes (as any hardware-accurate save should be...).
It also can happen if the flash memory file size is anything less than the N64's flash chip size: 131,072 bytes. In this case, this error can safely be ignored, and the program will simply write the resulting file to have the correct hardware-accurate file size. Some emulators like Project64 may store an unusually small save file if it is found that any further blocks in the file would all be null or 0 anyway.
After finishing all save-editing requests, the program is ready to exit but must first write the complete result of the new flash save file. Somehow, the standard library procedure has failed to write a complete 64-bit block from the RCP to the user's disk.
This would be surprising, unless running out of free disk space is no surprise.
Probably a bug in the program--please report.
Probably a bug in the program--please report.
These refer to a customized rule based loosely on RCP memory addressing--if the maximum RCP address (in this case, the flash RAM address) exceeds the physical limit or does not meet the minimum limit, reads and writes have undefined behavior for the R4300 master but probably not the RSP or RDP. The only way for a user to purposely exploit this without it being a definite bug in the program itself is through a command that permits low-level access to a fixed memory offset into the save file, which so far has not been implemented.
Due to any rule, the program has determined that a current string represents an option switch. These option switches are based on Unix command syntax and must always begin with a -(letter). Executing zs $FILE_PATH /r 99 instead of zs $FILE_PATH -r 99 is erroneous. The faulty request is ignored, but the error is by no means fatal.
A given command flag was used in the process command string but unimplemented.
Something like zs $FILEPATH -r 99 should be perfectly valid and give Link 99 rupees.
On the other hand, something like zs $FILEPATH -? ???" is invalid, because there is no such switch as -? implemented yet. (Of course, with the immense number of progress fields for this game to store in flash memory, it is hard to conceive that a finished version of this program would even have enough unimplemented or reserved flag switches for the occurrence of this error to be a reality.)
Refer to the online documentation for the flag in question. Some minimum number of required parameters to the flag must not have been met, although most flags in existence for this utility can successfully complete with no arguments at all (zs $FILE_PATH -m -r -R [...]).
There is no error message or warning for passing too many arguments (user annotations).
Refer to the online documentation for the flag in question. If the documented syntax explains that a (uint8_t) is to be supplied for a switch such as -m, but a command like zs $FILE_PATH -m 256 is executed, then the request is erroneous because 256 transcends either the minimum or the maximum boundary of values permissible for a zero-extended (unsigned) byte in the MIPS instruction set architecture rules.
Refer to the online documentation for the flag in question. If the documented syntax explains that a signed type like (int16_t) is to be supplied, but instead a value like -32769 is given, then the request is erroneous because -32769 falls short of the minimal boundary of values permissible for a sign-extended halfword according to the rules of the MIPS ISA.
Refer to the online documentation for the flag in question. If the documented syntax explains that a signed type like (int16_t) is to be supplied, but instead a value like +32769 is given, then the request is erroneous because +32769 exceeds the maximal boundary of values permissible for a sign-extended halfword according to the rules of the MIPS ISA.
Probably a bug in the program--please report.
There are no intended circumstances in which the error function should ever be able to be called with the ERR_NONE enumeration as the function parameter. This should be prevented.
Probably a bug in the program--please report.