In this case, restarting means to start another, separate game from the game that was initially started. In the description that follows, the game initially started is called the "startup game," and the game newly started by restarting is called the "started game." The started game must be stored on disk, while the startup game can be stored on either a cartridge or disk.

Games on disk usually cannot be run while a cartridge is inserted. However, they can be booted by calling game functions from the cartridge.

An example of how this could be used would be for an expanded or later version of a game previously sold as a cartridge game. The expanded or newer version could be sold on disk.

However, not all games can be rebooted. Several revisions for restarting must be made to both the startup game and started game when they are created. There also are certain restrictions on restarting, such as the fact that the started game cannot reboot itself or another started game. These restrictions are discussed in the following sections.

The function LeoBootGame( ) is used for restarting.

bootaddr contains the starting address of the boot segment of the started game.

The following is an example of the use of LeoBootGame( ).

The started game cannot be located at the start of a disk. With a disk boot, however, the IPL attempts to start the game at the start of the disk. Thus, the game placed at the start of the disk cannot be the started game.

As with cassette startup, when a started game is to be played with disk startup (in cases such as when games on the same disk are to be played and a disk alone is used, or a cassette is also inserted), a reboot sequence is included in the game at the start of the disk.

The following describes the restarting process in this case.

Note: The above example differs from the example in 15.1.2 only at step (1).

The following shows the sequence for restarting from the startup game.

1. If plenty of memory is available, data other than the boot segment data can be loaded. 2. The means of obtaining the ID can be determined by the game creator. No particular method is recommended. One method is to first write these data to a specified block. Another is to store them in ID. Such processing is unnecesssary in cases where the storage location of the started game is known in advance by the startup game, such as when restarting from a disk-startup game, ( See 15.1.3, Disk Startup Processing) or when the cartridge and disk are sold together.

There are a few differences between compiling startup and started games and compiling normal games. This section describes these differences.

Startup Game

• Makefile

Use the option -B 0 with makerom (or makedisk).

Started Game

• Makefile

Use the option -B 1 with makedisk.

Store the size and disk storage location of the boot segment (segment loaded before restarting) of the started game to disk in a manner that allows these two pieces of information to be obtained by the game.

• spec

Set the boot segment LBA to a nonzero value.

For information on makedisk, see 3.1 makedisk.

Startup Game

• Makefile

Use the option -B 0 with mild.

Started Game

• Makefile

Use the option -B 1 with mild.

Store the size and disk storage location of the boot segment (segment loaded before restarting) of the started game to disk in a manner that allows these two pieces of information to be obtained by the game.

• spec

Set the boot segment LBA to a nonzero value.

For information on mild, see 3.2 mild.

A sample with a restarting feature is installed in usr/src/PR/demos/reboot with the NW version and in ultra\usr\src\PR\demos\reboot with the PC version. In this sample, onetri, which is stored on disk, is rebooted by topgun, which is on cartridge. When initially booting the sample from disk, the following message appears: "The included cartridge is required to play this sample."

Procedure for Running the Sample Program

1. In the NW version this is run in usr/src/PR/demos/reboot; in the PC version it is run in ultra\usr\src\PR\demos\reboot.

2. Type <dwrite in the PARTNER command window to write to disk the disk image to be rebooted.

3. Using l reboot, load the ROM image into emulation ROM.

4. Type g. topgun will start. Press button A. Selecting OK in response to the prompt asking whether startup should proceed starts the copy of onetri stored on disk.

Using resetdd and g in steps 3 and4, respectively, results in booting from the start of the disk.

The directory structure below reboot/ is as follows.

ddproc/

A module containing items such as functions for disk processing and message display. Its use is shared by the following three applications.

topgun/

A game started from cartridge; it reboots onetri.

onetri/

A started game; it is rebooted by topgun.

hello_world/

A game written to the start of the disk.

makefat/

An application that outputs to a file the size of the specification file and the specified storage location.

The following restrictions apply when using LeoBootGame( ).

• LeoBootGame( ) cannot be used by the started game. Execution of LeoBootGame( ) is allowed only once, in the initial startup game.

• Before loading the started game, ensure that the disk ID is always checked to confirm that the disk is the desired one.

• The started game cannot be placed at LBA 0. That is, the started game cannot be booted by normal disk startup using the IPL. Another game should be stored starting at LBA 0. This disk-startup game does not need to include LeoBootGame( ). As described in 15.1.3, LeoBootGame( ) can be included in the started game to enable it to be booted. With this structure, when a make is applied to the disk-startup game the -B 0 option should be used with makedisk for the NW version and with mild for the PC version.

• When passing data between the startup game and the started game, it is convenient to use osAppNMIBuffer. This buffer is not cleared when booting with the 64-byte buffer. Although other data in RDRAM are not cleared, it cannot be guaranteed that these data will be left unaltered. When more than 64 bytes of data are passed, procedures such as writing the data to a predetermined RAM area on disk and reading it from the started game after booting are necessary.

• After restarting, the value of the global variable osResetType is 2. Subsequent resetting makes its value 1 in the startup game (figure below).