Dreamcast Software Development Standards
Dreamcast Software Development Standards/Ver.1.00E
A VM Special Game to be loaded into VM (Visual Memory) and executed is called an execution file. The contents of a backup on Saturn was called data, but here it is called a file (save file) to maintain consistency of the names. Please note that this may require changes to the display during games.
Note: The save file for a Dreamcast application must always be registered (report by special document to the Development Planning Department and Software Promotion Department).
15.1.1 Save File Name
Required: Only 1-byte upper-case English letters, numbers, underscore and period may be used. Spaces are not allowed. (See grayed part of table).
Required: File names must be exactly 12 characters.
Required: When multiple files are saved by one game, the first 9 characters of each file name must be the same (only the last 3 may differ).
In the Boot ROM file menu, the first 9 characters determine files associated with each game, so if these characters are not the same, the files are not recognized as belonging to the same game, and the batch copy function will not work.
Recommended: If saves are possible at various stages, the last 3 characters of the file names should be sequentially numbered, and other files (key configuration data, additional game options, etc.) should have the last 3 characters alphabetic.
Note: The backup library handles file names as case-sensitive: lower-case characters are disallowed.
Standardized:
Game Option File        DRAGOON3.SYS
Typical Game Save File  DRAGOON3.001
                        DRAGOON3.002
                        DRAGOON3.003
Recommended: File names should clearly indicate the game they relate to: avoid needless descrepancies.
Note: The number of files that may be created is no longer limited.
15.1.2 VMS Comments
Although the Boot ROM comments described in 15.1.3 are displayed in the File Control Menu, only the file names and VMS Comments are displayed in the VM file mode, so the VMS Comments should contain descriptions of the files.
Required: VMS Comments shall consist of up to 16 single-byte ASCII characters (20 to 7D and A0 to DF). Character 7E (tilde) should not be used as it is does not represent a character in VMS.
Table: Usable characters for file names and VMS Comments
Recommended: The status at game save time or the game name should always be written as a VMS Comment.
Standardized:
5 Menbos       (Game screen indication)
Zoano Machi  (Name of saved game)
Time Attach   (Game mode name)
Sonachine      (Player name), etc.
Required: Boot ROM comments may consist of up to 32 single-byte or 16 double-byte upper-case English characters (double-byte characters display as 24x24 dots with the Boot ROM, and single-byte characters as 24x12 dots).
Required: The game title (or a shortened form of the title, if necessary) is written as a Boot ROM Comment.
15.1.4 Save File Icon
Required: Each application should have its own unique icon.
The unique icon allows each applications' save files to be recognized in the Boot ROM File Control Menu.
Recommended: When preparing Visual Comments, observe the 23. Ethics Considerations to avoid improper ethics in the comments.
Recommended: Visual comments may be made in 16- or 256-color mode (do not use the 32k color mode).
A Visual Comment in the 32k color mode would occupy about 16 blocks, requiring extra time to save and load. As the image size is small, there is little advantage to the 32k color mode, so it is better to save the users' time.
Note: The 32k color mode requires about 16 blocks, 256 colors about 9 blocks, and 16 colors about 5 blocks. Whether or not a Visual Comment is provided is determined at the application side.
15.1.6 File Size
Recommended: Obtain the maximum size (number of blocks) available for a file save from the software.
For a save file that is considered to have variable length data up to stage 1 using 2 blocks, and at the final stage using 6 blocks, create a file of 6 blocks (the maximum size) beforehand, and avoid storing empty space (empty blocks) when overwriting in the midst of the file.
Note: If an application is to save its progress during use (or if the size change is extreme) such as the special case of "Dezaemon," please contact the person in charge at Sega beforehand.
15.1.7 Other Data to Save
Recommended: When VMS Volume Icon is saved (save with file name as ICONDATA_VMS) in the application (in the case when the application has this function), determine if the VMS Volume already exists in the Visual Memory. If so,
E Display the original icon on the screen,
E and display the following confirmation: "This icon already exists in the memory card. Is it okay to overwrite?"
15.1.8 Other Data to Save
CD Label Data (place 0GDTEX.PVR in the root directory of the GD area)
Visual memory screen display color data (information about Visual Memory color can be stored)
There are no requirements or recommendations for the 2 files above.
15.2 Memory Card (Visual Memory) Selection
Check which of the following types A - C applies to the application:
A: The application has a memory card selection screen at save (and load) time, and supports multiple memory cards. (go to 15.2.1)
B: Once a memory card has been selected by the application for autosaving (e.g., "Trail of Wonder" and "Wizardry"), only the one memory card is used (during the game) (go to 15.2.2)
C: Only one memory card is used to save data, such as high score, key configuration, etc., or no memory card selection screen is included (go to 15.2.3)
15.2.1 For applications that have a memory card selection screen at save (and load) time, and supports multiple memory cards (Fig. 2).
In this case, the user selects the memory card at each save.
Required: Any memory card in a usable port must be selectable.
Required: When allowing the user to select the port and expansion socket for a memory card, their selection (e.g., Port A Expansion Socket 2) should be clearly indicated.
Required: Hot swapping (inserting and removing with power on) of memory cards must be supported (except during actual save operations).
Recommended: A memory card should be selectable regardless of whether compatible or incompatible port/controllers are connected or being used.
Particularly in controllers planned for the future, keyboards will not be provided with an expansion socket. So if a keyboard is used, it should be possible to save to a memory card inserted at another port or on another controller. At that time, saving should be possible even if an unused or incompatible controller is connected.
15.2.2 With an application that performs autosave (e.g., "Trail of Wonder" and "Wizardry"), once a memory card has been selected, operation is the same as for a single memory card (during the whole game), as shown in Fig. 3.
In this case, the memory card for the save file is selected when starting the game, and the save file is overwritten during the game.
Required: Any memory card in a usable port must be selectable.
Required: When allowing the user to select the port and expansion socket for a memory card, their selection (e.g., Port A Expansion Socket 2) should be clearly indicated.
Recommended: A memory card should be selectable regardless of whether compatible or incompatible port/controllers are connected or being used.
Required: When a memory card is removed during the game, play must be paused and a message displayed asking that the memory card be replaced. If a memory card having the same save file (identical time stamp and checksum) as that removed is reinserted, the game resumes.
15.2.3 A single memory card should be used when only data like high scores and key configurations are to be saved, or when a memory card selection screen is not provided because it does not suit the character of the game.
In this case, when high score or key configuration data is changed, the application can freely write to the memory card.
Recommended: The port (controller) and extension socket of the memory card used for the save file should not be predefined.
We do not propose assigning memory cards to specific sockets, such as requiring that "a memory card be inserted in Expansion Socket 1 of the Controller on Port A."
Recommended: When multiple memory cards are inserted into multiple controllers or expansion sockets, and the ports and sockets are not predefined (per the previous recommendation), the memory card that is inserted into a port (controller) being used by the current game should have priority. Furthermore, if two memory cards are inserted into the same port (controller), priority should be given to expansion socket 1.
15.3 Memory Card (Visual Memory) Initialization
Recommended: Initialization of memory cards should not be handled at the application side.
Currently, all visual memories are shipped in the fully initialized state. If reinitialization is needed, it should be done from the File Control Menu of the Boot ROM.
Recommended: Except in the case of autosaving, a caution message such as "Saving, do not turn Power off" should be displayed on the TV screen while a save is in progress.
It can be assumed that data may be lost if power is turned off or a reset performed while saving, so the caution message is important.
Required: Soft reset capability must be disabled while a save is executing.
Required: When a save operation fails to complete correctly, a caution message such as "Save could not complete correctly" should be displayed.
Recommended: When the user selects a save as in 15.2.1 that would overwrite a file with the same name, a caution message such as "This file already exists. Is it okay to overwrite? (YES/NO)" should be displayed, and the user be allowed to choose.
Recommended: Before overwriting a VM Special Game file during application execution, a caution message such as "A VM Special Game is installed. If overwritten, it cannot be played any more. Is it okay to overwrite? (YES/NO)" and allow the user to choose.
No particular message display is needed during 15.2.2 Autosave or when 15.2.3 high scores, etc. are saved.
15.4.1 Saving When Activating Autosave
Recommended: If an option is provided to activate Autosave to save key configuration and other settings to a file during a game, activating Autosave should cause the application to check whether a file is already present, and if so, a caution message such as "Current settings will be overwritten. Okay?" should be displayed.
(An actual case with a PlayStation application resulted in settings being lost when it was started without a memory card. If a memory card was then inserted, the key configuration was not refreshed, so the previously saved settings overwrote the current settings.)
15.5 Caution Messages
When power is turned on, if a memory card is not present, or if there is not enough space to save a file on a memory card, a caution message should be displayed immediately after the License Logo clearly indicating the difficulty in proceeding with the game (Fig. 6).
The rules for each case are as follows:
Required: When the free space (blocks) on a currently installed memory card runs low, display a caution message such as "There are not enough free memory blocks. XX empty blocks are required for saving. If the game is started, saving will not be possible."
Check all installed memory cards (except the save location where high scores and configuration data is assigned, such as to Port A expansion socket 1, etc., per 15.2.3) to determine if any memory card has enough space (blocks).
Required: When no memory card is installed, indicate the required space (blocks) and display a caution message such as "A memory card with at least XX empty blocks is required for saving."
Required: If the save location of high scores and configuration data is assigned to Port A extension socket 1 according to 15.2.3, the port and expansion socket should be indicated in the caution message, such as "A memory card is not inserted in Port A Extension Socket 1. Please insert a memory card at this location to save High Score."
Required: Except in the case of autosave in 15.2.2 (e.g., after game start, the memory card is always required), after one of the above caution messages ("Not enough space," "Memory card not present" or "Memory card not present in the assigned location"), it must still be possible to start the game (even though saving is not possible).
15.6 Memory Control Screen
Recommended: If a Memory Control Screen is included in an application, a "Delete All Files" command should not be provided.
By not providing a command to erase all files, the problem of the user accidentally using it during memory control is avoided.
15.7 Loading Saved Files
Required: When loading a saved file, a message such as "Loading..." or equivalent indication must be displayed.
Required: The integrity of a loaded file must be checked, and if damaged, a caution message such as "the file did not load correctly" should be displayed.
Recommended: In the case where a file does not load correctly, it should not be immediately erased (the damaged file may be necessary later for customer service purposes).
The flow processes of file loading described in 15.2.1 and 15.2.2 are shown in Figs. 4 and 5, respectively.
15.8 Prohibited Terms
This section is currently under development.
15.9 VM (Visual Memory) Displays
Recommended: Except in the Autosave case of 15.2.2, the results of a save or load should be displayed immediately upon completion by such as "OK", "NG" on the LCD.
Recommended: Except in the Autosave case of 15.2.2 and in addition to the above LCD indication, the results of a save or load should be signaled by appropriate audible beeps.
Recommended: When an audible indication is provided as above, the Visual Memory sounds should be able to be turned on and off by a user option (for night use: VM sounds should not be turned off even if TV sound is muted).
Recommended: Except in the Autosave case of 15.2.2, after a memory card is selected and until a save or load is completed, a message such as "Selecting..." should be displayed on the LCD when accessing Visual Memory.
Recommended: In the case of a game that saves while being played as in 15.2.2, a caution message should be displayed to indicate selecting or saving to the selected Visual Memory.
Depending on the type of controller and expansion socket, whether a Visual Memory card should be inserted facing towards or away from the user should be indicated on the display as described in 26. VM (Visual Memory) Illustration.
15.10 Handling Long Save Times
Currently, compared with Saturn, Dreamcast requires a relatively long time to access a memory card during saves (about 16 seconds for 200 blocks).
Also, after a save command is issued (but before the save is completed), normal processing is possible.
Based on the above conditions, when a long time is needed for saving, observe the following recommendations.
Recommended: Applications that create large save files with RPG or simulations can return to normal game processing without waiting for saves to finish.
Note: If an application needs to save RAM that changes according to game progress, copy the RAM area to a separate area in RAM and then save the copy. While saving, resume normal processing, but with care to avoid changing the contents of the RAM being saved.
When following the above recommendations, to avoid the situation where the user turns the power off or performs a soft reset due to confusion during a long save, please observe creation standards 15.1 to 15.9 and the following standard 15.10.1.
15.10.1 Display of Return to Normal Processing
Required: (While saving) When returning to normal processing after starting a save, an on-screen indicator (such as a progress bar at the bottom) must be provided to show the user that a save is in progress.
Note: Soft reset and CD door open conditions should be indicated in a manner that is compatible with the normal save indication.
![]() |
![]() |
---|