backup

How to deal with unformatted and corrupted backup files?

Q)

Depending on how the user handles the cartridge RAM (power memory) (for example, when it is inserted or removed when the power is turned on), irregular characters may appear in the file name, comment, and usage value on the multiplayer "Saved Data Management" screen. or a numerical value may be displayed.

At this time, the file is not unformatted (the application does not recognize it as unformatted), and there are corrupted files.

If you record data to a cartridge RAM like the one above, it will stop within the BUP_Write() function.

For comparison, I tried running the data recording process of another application (created by calling the SBL function with the same name using the same procedure), and it ran normally. Are there differences depending on the library in the internal processing of the BUP_Write() function?

A)

First, I think it depends on where the buffer prepared for the backup library is located.

If the backup data is corrupted, the data size information included in the backup data may also have changed.
A situation may occur where the buffer is overflowed when reading/writing a backup.
If it is an important area used by the system, it may hang.

In the first place, it is quite possible that a situation like this could occur depending on the user's usage, but if this happens, the application will no longer be able to intervene.

The size returned by the backup management screen and the application are different.

Q)

The built-in backup memory of the main unit is 32k bytes (512 blocks).
However, when I look at the backup data management screen, the free space is displayed as 461 blocks even though it is initialized.
Does this mean that the backup area available to the user is 461 blocks (approximately 29K bytes)? Also, why is that?

In the case of 4096 bytes of continuous data, when calculated using the usage formula in the creation standards, the usage should be (4096+32)/64=65 blocks, but when it is actually written to backup RAM and "BUP_Dir" If you check with "BUP_Stat", the amount of blocks used is 72 blocks.
Also, on the backup data management screen, it is displayed as 65 blocks according to the calculation formula. Why does this difference occur?

Is it okay to use the device's built-in backup RAM to its capacity limit for one backup data?
Or is it morally necessary to leave a certain amount of space free?

A)

The difference between the number of free blocks obtained by the backup library function Bup_Stat and the number of blocks that can actually be used occurs because there is an area reserved as a reserve area for future expansion. For this reason, the actual usable capacity is slightly smaller.

When accessing the backup RAM, check whether it is possible to write in the block unit shown in the structure BupStat obtained by Bup_Stat, and refer to it.

I don't really understand how to calculate "block" as a unit of capacity.

Q)

I don't quite understand the specifications of the "block" unit of capacity.
Developer's Information The value calculated from the contents of STN-9 and the value returned by the library do not match.

A)

The reason why the two values do not match is because the purpose of use is different.
Please use the correct one for each purpose.

" Consumption amount [block] " explained in Developer's Information STN-9 is
This is a convenient value to notify the 'user' of usage.

(Amount used) = ( [Number of bytes used] + 32 ) / rounded up to 64

The calculation formula is used.

This calculation formula is the same as the consumption calculation formula displayed on the main unit's BOOT-ROM backup management screen, and is common to all main units, cartridges, and FDs. This is different from consumption in the strict sense of the word, so it cannot be used to check remaining capacity.

In addition, the size of "block" in library functions differs depending on the device, and is as follows.

	Total number of blocks total block	1 block capacity blocksize (in bytes)
Built-in RAM (current)	512	64
Power memory (old model)	1024	512
Power memory (new model)	2048	256

*Not all of the above values can be used as save data areas.

How should I check the remaining backup capacity?

Q)

How should I check the remaining backup capacity?

A)

First, check if save data already exists.
Please use the following directory information acquisition function BUP_dir() .

Format

Sint32 BUP_Dir(device, filename, NUM, dir)

[input]

Uint32 device:Device number (0:Built-in memory 1:Cartridge)

Uint8 *filename: File name (ASCII string of up to 11 characters)

Uint16 NUM: Number of directory information structures secured

[output]

BupDir dir[NUM] :Status information

[Function value]

Number of file name matches
(If the number of matches exceeds NUM, the value will be reversed)

[explanation]

Searches the file name by prefix match and returns the number of matches as a function value.
In the case of an application that uses multiple save data, all files with the same file name other than the number at the end will be searched.
Also, if the number of matches is less than or equal to NUM, the directory information of each file will be obtained in dir[NUM].

If the number of matches is 0 for all devices, the save data does not exist.
In that case, check whether a new save is possible. Please use the following status acquisition function BUP_Stat().

[Format]

Sint32 BUP_Stat(device, datasize, stat)

[input]

Uint32 device:Device number (0:Built-in memory 1:Cartridge)

Uint32 datasize: Save data size (in bytes)

[Output] BupStat *stat :Status information

[Function value]

Device status
(0: Acquisition successful BUP_NON: Not connected BUP_UNFORMAT: Unformatted)

[explanation]

You can check the number of files that can be saved.
Call the function by specifying the device number and data size.
If the function value is 0, the status information was successfully retrieved.
Refer to stat.datanum to get the number of files that can be saved.

[Notes]

Among the acquired status information, please do not use the following information.
The reason is that the remaining capacity cannot be checked correctly.

stat.blocksize :Size of 1block (in bytes)

stat.freeblock: Number of unused blocks

stat.freesize: Unused capacity (in bytes)

However, there is no problem in using stat.freesize only when the number of files to be saved is one.
(Can be compared with the byte size of the data to be saved)

What should I set as the 'language type' when saving?

Q)

What should I set as the 'language type' when saving?

A)

The language type referred to here is the language of the comment information in the save file. Only ASCII codes can be used for save data file names, but katakana etc. can be used for comment information.

If you want to write the comment in Japanese, please specify BUP_JAPANESE for 'Language type'.

For other languages, use one of the following:

BUP_ENGLISH	:English
BUP_FRANCAIS	:French
BUP_DEUTSCH	:German
BUP_ESPANOL	:Spanish
BUP_ITALIANO	:Italian

* Please refer to "Backup Creation Standards" for characters that can be used in file names and comment information.

How do I check the connection of the backup cartridge?

Q)

How do I check the connection of the backup cartridge?

A)

You can check this when you initialize the backup library.

      BUP_Init( addr, workbuff, conf)
        Uint32 *addr           :Library deployment area 
        Uint32 workbuff[2078]  :Library work area
        BupConfig conf[3]      :Connected device information
                               conf[0] Built-in RAM
                               conf[1] Cartridge RAM
                               conf[2] FDD (currently unavailable)

After executing BUP_Init(), refer to the connected device information conf[1].
When the cartridge is not connected → conf[1].unit_id will be 0.
When the cartridge is connected → conf[1].unit_id becomes 2.

How should I do a bug check if the backup RAM is in an uninitialized state?

Q)

How can I do a bug check if the backup RAM is uninitialized?

A)

An easy way to initialize the main unit's RAM is to turn on the main unit with the battery removed.
We are currently preparing a dedicated tool to detect uninitialized cartridges and corrupted files.