Return to previous page | Return to menu | Proceed to next page

2＞ System regulations

The basic system flow is shown in Figure Appendix 1-1. This must be included in the processes, functions, and messages shown in this flow.

− Figure Separate Volume 1-1. Basic backup system flow −

*The flow may differ depending on the application.

Initialization check

Before starting the main game, be sure to check the initialization of the main unit RAM and cartridge RAM.
If either one has not been initialized, do not start the game. In this case, notify the user and urge the user to either perform the initialization process directly within the application, or to perform the initialization process on the saved data management screen in the Sega Saturn's BOOT ROM.

*Be sure to use BACKUPRAM BIOS when accessing backup RAM.
*Do not format the main unit RAM, cartridge RAM, or extended memory using any method other than SEGASATURN_BACKUP_FORMAT.

Presence/capacity check

Before the main game starts, confirm the existence of data that can be used by the own application and check the remaining capacity of each backup RAM.
If your data does not exist or there is not enough remaining space, a warning message will be displayed depending on the situation. (The specific message content will be explained later)

Load

Always check for data corruption when loading data.
If the data is unusable, the user must be notified of this fact, and the data must be distinguished and displayed in some way to make it clear that the data is unusable.

save

===Regulations regarding records===

＜ About the format＞

• Do not divide records unnecessarily. (In principle, one record per save)
• Do not create a format where you will be completely unable to play if even one record is missing (it is possible to have independent records for each mode)
• The maximum number of records for one type is 99 (_01 to _99).

＜ About the name＞

• In order to avoid using the same record name in different games, the "record name" when saving is managed by SEGA (Second Design Department).
• The only characters that can be used in the record name, etc. are numbers, uppercase letters, and underscores. However, do not use a number as the first character. (See table Appendix 1-1)
• Record names must be 11 characters long. If it is less than 11 characters, pad it with underscores (_) to make it 11 characters. Spaces are not allowed.
• When saving multiple records in one game, the first eight characters should be the same, and the three characters that can be changed should be composed of an underscore (_) and a number.
• The number of records shall be up to 99, and the three characters that can be changed in the record name shall start from _01 and end with _99.
• Avoid using generic names that are difficult to distinguish, such as GM_DATA_000.

  Example) In the case of "Panzer Dragoon" (requires saving in 3 locations)
  1st location: PANZER_D01
  2nd location: PANZER_D02
  3rd location: PANZER_D03
                └─┬──┘ └┬┘
                  │     Only 3 characters can be changed
                  8 characters in common

＜ About usage amount＞

• When expressing the “usage amount” of records (data), use the value calculated according to the following formula.

  Usage amount = ([Number of bytes used] + 32) ÷ 64

• In principle, the unit of usage should not be included , but if it is absolutely necessary to indicate it, the word "block" should be used.
• The amount of records used should not exceed 256K bytes. (Limitations due to the program specifications of the copy function of the main unit's BOOT ROM)
• If the recording usage exceeds 256K bytes, be sure to make copies available on the application side.

Comment support

Be sure to include some comments. Be sure to use ASCII characters (half-width alphanumeric characters, kana characters, table, refer to Appendix 1-1), up to a maximum of 10 characters.
Comments are used to learn more about the contents of the save data, so please use them effectively in each application. In particular, if you cannot find the intended use, please enter the game name (information that can be identified) in katakana.

Example) Example of effective use of comments
  PANZER_D_01: 5 Men-Boss         (Continue information)
  PHANT_ST_01: Alephkardonomachi  (name of the town where you saved)
  SEGARACE_01: Time attack M      (mode name)
  DERBY_ST_01: Mochikane69        (ranch name)

* Users are free to choose whether or not they can rewrite the content of their comments.

Supports timestamps

A timestamp must be included and cannot be changed by the user . As a general rule, records are displayed in ascending order of the timestamps (starting with the newest saved date).

Body RAM/Cartridge RAM selection

All applications that support backup must be able to store their records in either internal RAM or cartridge RAM. Even if the amount of recording used is too large to fit in the main body RAM, the principle is to use a simple storage method that can also be stored in the main body RAM.

*Excluding cases of extremely trivial recorded content (such as only high scores in shooting games)
*There are no specific regulations regarding where in the sequence this selection must be made.

*All characters can be used for “comments”. Only the part can be used as the “record name”.

− Table Separate volume 1-1. ASCII table of usable characters for record names and comments −

Return to previous page | Return to menu | Proceed to next page