backup

What to do with a corrupted backup file that is not unformatted?

Q)

Depending on how the user handles the cartridge RAM (power memory) (for example, plugging / unplugging when the power is turned on), indefinite characters may appear in the file name, comment, or usage value on the multiplayer "Saved data management" screen. And numerical values may be displayed.

At this time, it is not in the unformatted state (it is not recognized as unformatted by the application), and the corrupted file exists.

When data is recorded to the cartridge RAM as described above, it stops in the BUP_Write () function.

For comparison, I tried running the data recording process of another application (created by calling the function with the same name in SBL in the same procedure), but it was executed normally. Is there a difference depending on the library due to the internal processing of the BUP_Write () function?

A)

First of all, it depends on where the buffer prepared for the backup library is placed.

If the backup data is corrupted, the data size information contained in the backup data may have changed.
It is possible that the buffer will be exceeded when reading / writing a backup.
It can also hang if it is an important area of your system.

In the first place, depending on how the user uses it, it is quite possible that this will happen, but if this happens, the application will no longer be able to handle it.

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

Q)

The built-in backup memory of the main unit is 32 kbytes (512 blocks).
However, when I look at the backup data management screen, the free space is displayed as 461 blocks even in the initialized state.
Does this mean that the backup area available to the user is 461 blocks (about 29 Kbytes)? And why is that?

In the case of continuous data of 4096 bytes, the usage should be (4096 + 32) / 64 = 65 blocks when calculated by the usage formula in the creation standard, but actually write to the backup RAM and "BUP_Dir" If you check with "BUP_Stat" or "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 built-in backup RAM of the main unit up to the capacity limit with one backup data?
Or is it necessary to leave some capacity free as a moral?

A)

The difference between the number of free blocks acquired by the backup library function Bup_Stat and the number of blocks that can actually be used is caused by the fact that there is an area reserved as a reserve area for future expansion. For this reason, the capacity that can actually be used is slightly reduced.

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

I'm not sure how to calculate the "block" as a unit of capacity.

Q)

I'm not sure about the specifications of "blocks", which are units of capacity.
Why doesn't the value calculated from the contents of Developer's Information STN-9 match the value returned by the library?

A)

The two values do not match because they are used for different purposes.
Please use the correct one for each purpose.

The "consumption [block] " described in Developer's Information STN-9 is
It is convenient value for notifying the amount used in the 'user'.

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

Use the formula.

This formula is the same as the formula for consumption displayed on the backup management screen of the main unit BOOT-ROM, and is common to all of the main unit, cartridge, and FD. Since it is different from the consumption amount in the strict sense, it cannot be used for checking the remaining capacity.

In addition, the size of "block" in the library function differs for each device, and is as follows.

	Total number of blocks totalblock	Capacity of 1 block 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 the save data already exists.
Use the following directory information acquisition function BUP_dir () .

Form

Sint32 BUP_Dir (device, filename, NUM, dir)

[input]

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

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

Uint16 NUM: Number of secured directory information structures

[output]

BupDir dir [NUM]: Status information

[Function value]

Number of file name matches
(If the number of matches exceeds NUM, the sign is inverted.)

[explanation]

Searches the file name with a prefix match and returns the number of matches as a function value.
For applications that use multiple save data, all files other than the last number will be searched if they have a common file name.
Also, if the number of matches is NUM or less, the directory information of each file is acquired in dir [NUM].

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

[Formula]

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: Successful acquisition BUP_NON: Not connected BUP_UNFORMAT: Unformatted)

[explanation]

You can know 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 has been acquired successfully.
See stat.datanum to get the number of files that can be saved.

[Notes]

Do not use the following information among the acquired status information.
The reason is that the remaining capacity cannot be checked correctly.

stat.blocksize: 1block size (in bytes)

stat.freeblock: number of unused blocks

stat.freesize: unused capacity (in bytes)

However, you can use stat.freesize only when the number of files to be saved is one.
(Comparison with the byte size of the data to be saved)

What is set for the'language type'when saving?

Q)

What is set for the'language type'when saving?

A)

The language type here is the language of the comment information of the save file. Only ASCII code can be used for the save data file name, but katakana etc. can be used for comment information.

If you want to write the content of the comment in Japanese, 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

* For the characters that can be used in the file name and comment information, refer to "Backup Creation Criteria".

How to check the connection of the backup cartridge?

Q)

How to check the connection of the backup cartridge?

A)

You can check it when you initialize the backup library.

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

Execute BUP_Init () and then refer to the connected device information conf [1].
When the cartridge is not connected → conf [1] .unit_id becomes 0.
When the cartridge is connected → conf [1] .unit_id becomes 2.

What should I do to check for bugs when the backup RAM is in an uninitialized state?

Q)

How should I check for bugs when the backup RAM is in the uninitialized state?

A)

The easiest way to uninitialize the main unit RAM is to turn on the main unit with the batteries removed.
We are currently preparing a dedicated tool for the uninitialized state of the cartridge and the corrupted state of the file.