1-5 Creating Resident/Non-Resident Programs When the amount of data becomes too large and cannot be stored completely within Saturn's memory, it is possible to preload only the portion of data that is used. In the case of code, it is possible to use overlays. However, since an overlay feature is not provided on the Saturn, it is necessary to structure your application for this purpose as well as to use linker functions. Use the following example as a starting point: 1. Creating Resident Programs A resident program contains minimal file I/O functions as well as shared-use libraries. There are two ways of executing a non-resident program (module) that is loaded in from the CD-ROM to a specified address. a. Call Program from a Specified Address After the non-resident module is loaded, it is executed from a preset address. Coding Example: fid = GFS_NameToId((Sint8 *)fname); /* fname is the non-resident module */ GFS_Load(fid, 0, 0x6080000, GFS_BUFSIZ_INF); /* The starting address is read from the non-resident module's map file. */ ((volatile void (*)())(0x6081000))(); <Declaration of the program at link-time> GCC -m2 -Xlinker -Tkernal.cof -Xlinker -e -Xlinker ___Start .... In this example, it will be necessary to recompile this program if the address of the non-resident module's execution start function changes. b. Define a function with an external declaration and set an address at link- time for the function with the -defsym option. The function is executed after the non-resident module is read into memory. Coding Example: extern void SUB_main1( void ); #define SUB_ADDR 0x06080000 void main( void ) { : /* Example of loading a non-resident module */ buf[0].type = CDBUF_COPY; buf[0].trans.copy.addr = (Uint32)SUB_ADDR; : slCdLoadFile(); /* Executing the non-resident module */ SUB_main1(); : } <Declaration of the program at link-time.> GCC -m2 -Xlinker -defsym -Xlinker _SUB_main1=0x06081000 * -Xlinker -Tkernal.cof -Xlinker -e -Xlinker ___Start .... Since the address of the non-resident module's execution start function is undefined, set a dummy address first and then set the real address later from the completed non-resident program's map. It is necessary to link the program after resetting the address. 2. Creating Non-Resident Programs (Modules) A non-resident module is a program that is not used constantly within the application. For example, the program can be only used on a per-game stage basis. Although multiple non-resident modules may exist, the following precautions must be taken when they are coded: a. Caution During Programming Name the object files so that they are not created with the same function name contained in the resident program (e.g. the main function may conflict). b. Caution When Loading the Non-Resident Module Set the start address of the non-resident module to the same address as the load address of the resident program. c. Passing the Resident Program's Map Data When creating the non-resident module, use the linker's -R option to specify the resident program's execution file (Kernal.COF in our example) GCC -m2 -Xlinker -R -Xlinker kernal.cof..... With this setting, the resident program's symbols are extracted and included in the non-resident program. If the same functions exist when libraries that are being used are linked in the same manner as the resident program, the information contained in the COFF file specified by the -R option overrides others. 3. Resetting the Non-Resident Program's Execution Start Address Called by the Resident Program. After creating the non-resident program, check the function address called by the resident program from the map file. Use that address to reset the execution start function address with the -defsym option at link-time. This does not need to be done if the address is already the same as the resident program.