Japanese
FAQGeneral program
Back | ■
FAQ/Program General

others



When SH2 crashed.

Q)
What should I check when SH2 crashes?

A)
When SH2 crashes, it is best to check the PR and see if the return address from the routine is correct.
This lets you know which routine crashed.
This also works for code written in C.


I don't think there are enough registers for SH2.

Q)
Here's a slightly palliative technique using assembly.

A)

  1. Use MACL, MACH, and GBR as temporary.

  2. Store pr in a register. (sts.l pr,r14)

This technique should only be used by those who are familiar with library behavior and SH assembly. These operations can cause the library to run out of control if not used properly.


What are the parameter rules (at assembler level) in GCC?

Q)
I would like to incorporate a function created in C into an assembler program, but how are the arguments and return values of the C function coded?
Also, which register should the contents be saved?

A)
The details look like this:

r0:
The value returned by the function.

r0-r3:
temporary. It can be destroyed by calling a function. - No need to save and restore.

r4-r7:
first four arguments. broken by callee.

r8-r15:
Temporary available. These must be preserved between function calls. Assembly functions handled by gcc must preserve these registers.

pr:
Processor Return Must be saved.

gbr:
C compilers usually do not create code that uses gbr. Therefore, the gbr register can be used freely. (However, SGL uses gbr in the system. If you want to use both the SGL system and assembler, you need to be careful. Specifically, gbr always uses the start address of the system variable area. It points.)

mac?:
It will be destroyed. Also, since all arguments after the fifth are saved on the stack, performance will improve if you limit the number of arguments to four or less for C functions.

*Before calling the C function, be sure to make char and short in r4-r7 signed or extend them with 0. In the case of gcc, the argument in the register is expected to be signed and expanded to an int.

Are there any precautions to be taken when using the SH2 divider?

Q)
Are there any precautions to be taken when using the SH2 divider?

A)
The SH2 divider has a unit that can perform division in about 39 cycles.
The thing to keep in mind when using a divider is that if an interrupt occurs while the divider is being used in main processing, and the divider is used within the interrupt processing, the calculation result of the interrupted main processing side will be That would be dishonest.

To deal with this,

  1. If interrupt processing uses a divider, interrupts should be disabled in the main processing.

  2. A divider is not used in interrupt processing.

there is.

SH The C compiler has an option switch that uses a divider, so if you do not want to be aware of this, use the option that does not use it (-div=cpu) or the option that disables interrupts when using the divider (- div=peripheral).

* gcc does not generate code that uses a divider unless you use it explicitly (for example, inline assembler) in your C compilation code.


I would like to know the time required for data transfer by CPU, DMA (CPU/SCU), etc.

Q)
Could you please tell me the time required for data transfer for program transfer, CPU-DMA transfer, and SCU-DMA transfer?

A)
The time required to transfer 256 bytes to VDP1, VDP2, and SCSP (Sound RAM) (measured value) is shown below. This measurement was performed under the following conditions.

  1. It is in VBlank. (During the period when VDP2 is always writable)

  2. SCSP is in a state where both 68000 and internal DSP are stopped.

  3. VDP1 is not drawing or displaying.

  4. CPU-DMA transfers and SCU-DMA transfers do not include the time to register data in registers.

●WORKRAM-H--> SCSP (256 bytes)
Program transfer 78.14 micro/sec (32.80 clocks per 4 bytes)
CPU-DMA transfer 77.74 micro/sec (32.70 clocks per 4 bytes)
SCU-DMA transfer 63.89 micro/sec (26.80 clocks per 4 bytes)
* Any transfer takes a considerable amount of time. Even when transferring 256 bytes or less, the speed per 4 bytes does not change much.

●WORKRAM-H--> VDP1 (256 bytes)
Program transfer 36.75 micro/sec (15.40 clocks per 4 bytes)
CPU-DMA transfer 29.56 micro/sec (12.40 clocks per 4 bytes)
SCU-DMA transfer 5.36 micro/sec (2.25 clocks per 4 bytes)
* SCU-DMA transfer speed is quite fast. However, when transferring 256 bytes or less, the number of clocks per 4 bytes becomes worse.
(The number of clocks per 4 bytes required for 16 byte transfer is 5.97)

●WORKRAM-H--> VDP2 (256 bytes)
Program transfer 36.58 micro/sec (15.40 clocks per 4 bytes)
CPU-DMA transfer 17.98 micro/sec (7.60 clocks per 4 bytes)
SCU-DMA transfer 5.20 micro/sec (2.20 clocks per 4 bytes)
* SCU-DMA transfer speed is quite fast. However, when transferring 256 bytes or less, the number of clocks per 4 bytes becomes worse.
(The number of clocks per 4 bytes required for 16 byte transfer is 5.00)

SCU-DMA includes pre-processing (20 clocks or more) and post-processing (12 clocks or more) during execution, so it is especially effective when transferring large amounts of data to VDP1 or VDP2. Since SCSP requires a wait for external transfer, it is better to use CPU-DMA or program transfer. (This is because SCU-DMA is in burst mode, so if a cache miss or write occurs after execution, processing will stop until the SCU-DMA transfer is completed.)

What should I be careful about when developing SEGASATURN software?

Q)
I'm going to develop a game software with SEGASATURN, and I'm looking at the hardware manual to see what kind of graphical features it has, but there are so many that I can't choose.
So, please tell me in simple terms what functions SATURN actually has and what limitations it has.

A)
It is true that SATURN has a variety of functions, and it is very difficult to know how to use them, but if we explain what to do from the perspective of graphic design, here are the points you should pay attention to when designing graphics: ,

palette:
Palettes are shared between scrolls and sprites. Therefore, where and how to allocate the limited color data is a very important issue. Saturn uses palette data of 1024 or 2048 colors. You should decide which palette to use where before you start drawing.

VRAM:
VDP1 and VDP2 are used in different ways, so we will explain each separately.

First, VDP1 stores image data, sprite display commands, color lookup tables, and Gouraud shading tables in VRAM. Including all of this, it must be kept within 512KB. In other words, it doesn't mean that you can use 512KB just for the image data. Naturally, if picture data takes up a lot of data, there will be less space for commands, which will reduce the number of pictures that can be drawn, and vice versa. It would be best to keep these things in mind when finalizing the specifications.

Next is VDP2, which contains bitmap data, character pattern data, pattern name data, and in some cases, rotation coefficient data (this data can also be stored in color RAM). Of course all of this data can fit within VRAM, but there is also the issue of access.

The only thing to keep in mind is that bitmaps require a large amount of RAM, so you need to be careful.

drawing:
VDP1 and VDP2 have different drawing capabilities for high resolution and low resolution, respectively. When using high resolution, the drawing capacity will be half that of low resolution. Therefore, please take into consideration that there are quite severe restrictions when using high-resolution and meeting the requirement of staying within 1 Int.

VDP1:
VDP1 is responsible for processing sprites. Translucency is a problem when displaying sprites.
Translucency can be applied to sprites or to sprites and scrolls, but it is not possible to use translucency for both sprites and scrolls at the same time, so the initial design Careful attention must be paid to this point at this stage.
If you want to perform translucent processing on both sprites and scrolling at the same time, you will need to mesh them. (It is a good idea to know how different the effects are between mesh and translucent in the early stages of development.It is also a good idea to know the difference between high-resolution and low-resolution.)
Another problem is Gouraud shading. Gouraud shading is a useful feature that can make the connections between polygons look smooth, but this only works if the sprite image data is in RGB format or in color lookup mode, and the lookup table is in RGB. This function is valid only when In palette mode, Gouraud shading is not applied, so you need to have some idea of which sprites will be used in which mode at the design stage.

VDP2:
VDP2 is mainly responsible for handling scrolling. When using VDP2, you must pay attention to the parameter called the cycle pattern, which sets the order of VRAM access.
Basically, where to place the scroll data to be displayed depends on this cycle pattern.
]]]]]]< When using SGL, this setting is automatically set with slAutoDisp, but you need to be aware of how to use VRAM when designing. Parameters that affect the cycle pattern are: rotating scroll surface, cell, map position on VRAM, VRAM division, number of colors, reduction setting, vertical cell scrolling, high resolution/low resolution, CPU to VRAM during screen display period. It will be access. All of these things consume or limit the cycle pattern, so consider in advance the design of what kind of scrolling to use and where to put the data, and whether these specifications can be implemented.

What trap vectors are available?

Q)
What trap exception handling vectors are available?

A)
Only user vectors 20H to 3FH are currently not used in the BOOT-ROM while the application is running, so you can use them freely.
Other vectors cannot be used by applications for purposes other than their original purpose. 48H to 7FH cannot be used by the user, so if you are using them, please change them.
Please note the following points when using vectors.

  1. To access the vector area, you must use the system program built into BOOT-ROM. SYS_SETSINT()

  2. NMI vectors cannot be rewritten. This is for handling the reset button.


Even if I create an IP, it won't boot.

Q)
When I changed the compiler to SH Series C Compiler Ver.3.0B, it no longer boots even if I create an "IP" as before.
We are using your company's sample files to create the IP.
(However, the area code only links Japan)

\SATURN\SEGASMP\SYS\MK.BAT
                    SMPSYS.C
                    SMPSYS.LNK
                    SYS_ID.SRC

It seems that the versions of ASSEMBLER and LINKAGE EDITOR are not related.
Is there anything I need to change in the compiler?

A)
Line 114 of SMPSYS.C

Sint16 vbIcnt = 0;

from,

volatile Sint16 vbIcnt = 0;

Please rewrite it like this.


Notes on creating a PAL version.

Q)
When changing a title created for the Japanese or USA version to the PAL version, what kind of changes are required to the program, graphics, and sound data?

A)

●Problems regarding dot aspect ratio
In the PAL version, the dot aspect ratio is wider than in NTSC.
Therefore, graphic data must also take this into consideration.

●Problems regarding V-Blank
PAL has a shorter V-blank compared to NTSC. Therefore, if the processing during blanking is too heavy, processing will be delayed.
Also, since PAL has a cycle of 50Hz and NTSC has a cycle of 60Hz, if you port an NTSC game as it is, the overall speed will be 5/5 (as the 60 times per second will be reduced to 50 times per second). Since the speed will be 6, it will be necessary to devise a method to compensate for this.

●About Cinepak and TrueMotion
There are basically no problems with Cinepak and TrueMotion.
This is because these are compressed while incorporating time information when creating the movie.
However, since the aspect ratio will change, the picture will appear shrunk, so please be careful.

Also, if the data places too much load on VDP, it may not be displayed correctly. (In other words, frames will be dropped.)


Which ANSI C library can be used for SATURN development?

Q)
Please tell me the ANSI standard compliant C library functions that can be used in include files.

A)
Basically, file input/output relations such as fopen, fget, fscanf, etc.
(Of course, please use the CD access related functions that come with the Sega Saturn library.) Also, functions that request input/output from the console such as printf and scanf cannot be used.
(Even if the compilation passes, we cannot guarantee the operation. However, if you use libcross.a in the SNASM environment, you can use it without any problems. In that case, the standard output will be the standard output window that appears on snbugsat. Masu.)

Also, functions related to memory such as calloc, malloc, and sprintf compile and work, but this is not an appropriate way to program a gaming machine.
Calloc, malloc, etc. are functions that are deeply dependent on the OS, so if they are used on Saturn, an error will not be returned even if they are mapped to an illegal address. I think these are natural results considering that the Saturn is not a machine loaded with an OS.
(This is the same for both SBL and SGL.)


Regarding the default values of VDP, SCU, and SCSP when changing the clock.

Q)
It is stated in the SMPC User's Manual that when a clock change is executed, VDP1, VDP2, SCU, and SCSP are set to the default values when the power is turned on. Could you please tell me the default values?

A)
When a clock change is performed, SCU, VDP1, and VDP2 are reset, but the setting values are set to the initial values in each hardware manual.
Please refer to each hardware manual for the setting values.

Please refer to the system program user's manual in the Programmer's Guide for information on the processing after a clock change.
To describe it simply,

About reinitialization process after reset

●SCU
It is necessary to reinitialize the bus, interrupt mask, etc. However, use the SYS_GETSCUIM value for the interrupt mask value.

●VDP2
You need to set TV mode relatively quickly. Since the device itself is in 320/640 mode after being reset, especially if you change the system clock to 352/704 mode, the synchronization signal may be out of sync with the TV and the screen may be distorted.

●VDP1, VDP2, SCSP
All previous settings will be invalidated and you will need to reconfigure them.
If you are using a library, you will need to do something similar to initializing your application.


Regarding the recording range of the CD program area.

Q)
I have a question regarding the recording range of the program area.
Currently, the maximum length is 63 minutes and 4 seconds, but is it okay to create data that exceeds this?
If so, how many minutes is possible?

A)
This restriction is to ensure a security area on the CD-ROM, and data that exceeds the maximum time cannot be used as a product as it will erode the security area.

For the above reasons, it is not possible to create data longer than 63 minutes and 4 seconds.
If the software you create is longer than 63 minutes and 4 seconds, it will naturally not be possible to commercialize it.


About data cartridges.

Q)
I have a question regarding data cartridges.

  1. When emulating the cartridge part, is it possible to specify the address of the ROM image when setting the address on CartDev or Programming Box?

  2. Does Cart Dev use SIMM memory for emulation?

  3. In that case, is it possible to coexist with the file system?

  4. Can ROM cartridges be accessed in byte units?

  5. Are the SCU restrictions the same as normal A-Bus access?

  6. We set the SCU weight, but how slow is the access compared to LOW-RAM?

  7. Are there any sample programs that use data cartridges?

  8. In the case of a CD, I will submit one created using a write-once writer, but how should I submit the data for the data cartridge part?
    (Compress and submit with floppy, create ROM with ROM writer, etc.)

A)
I'll answer.

  1. Since the ROM space to be used is fixed, it is not possible to specify the address of the ROM image.

  2. Emulation will be performed by setting the SIMM in a special cartridge (sold by Ado Denshi) used in the SIMM system.

  3. SIMM system (GFS debug mode) and cartridge emulation may be possible if the GFMC_Base setting address does not conflict with the cartridge usage address.

  4. You can also do this in bytes.

  5. No change. However, unlike the CD buffer, there is an update of the read address (that is, there is an update of the read address like a normal memory copy), so be careful when setting the DMA.

  6. I set it to 3 clock waits (as stated in the manual), but it actually took about 25 clocks to obtain 16 bits of data.
    This means that it is about 4 times slower than WORKRAM-L.

  7. No sample program is provided. Be careful when programming so that reading from the CD and reading the cartridge do not overlap.

  8. Like old cartridge software such as MegaDrive, it is basically delivered in ROM. This format may be subject to change at the time of delivery.


I want to create a self-starting CD.

Q)
I want to create a self-starting CD, but how do I do that?

A)
The steps to create a self-starting CD are as follows:

  1. Create an executable file in BIN format.

  2. Create an IP.

  3. Create a virtual CD script file and create a disk image.

  4. Check operation with virtual CD.

  5. Create a TOC file using VCDMKTOC.EXE.

  6. Create a write-once CD using SEGACDW.EXE.

For an explanation of the IP itself and how to write a self-starting CD script file, see

reference
"Programmer's Guide" DISC Format Standard Specifications/ Boot System

Please refer to.

The execution procedure for each item is as follows.

  1. Creating a BIN file
  2. ○For GNU environment
    First, create a coff file as usual, then use the objcopy (sh-objcopy for IRIX) command as follows.

     objcopy -O binary input output

    or with GCC's link option

     -Xlinker -oformat -Xlinker binary

  3. Creating an IP
  4. In the sample version IP, the address of 1stREAD FILE is set to 0x06010000, and the sample initialization program jumps to the first address of 1stREAD FILE.

    If you change the read address of 1stREAD FILE, you need to recompile the IP.
    The IP sources and security objects currently provided are for SH-C, so it is necessary to create an IP using Hitachi SH-C.
    Alternatively, we can provide the files necessary to create an IP for GNU by email, so please contact us if you need them.

  5. Create script file
  6. Please refer to " Appendix A/Various Sample List " of the DISC Format Standard Specifications in the Programmer's Guide.

    The file (1ST READ FILE) that is automatically loaded after loading the IP is the first file in ASCII order on the CD-ROM (synonymous with the file with file identifier 2).
    Specify the file name on the CD-ROM with the File command, and specify the source on DOS with the FileSource command. At this time, the file name on the CD and the source file name do not need to match.
    Also, please refer to the attached document for the meaning of the text files registered in the system area. (These text files can be dummy during development, but be sure to include text files related to rights before mastering.) Note that when using the self-starting execution method, the SNASM debugger is not used. Please note that this is not possible.


How to put data as big endian on byte boundaries?

Q)
How can I reserve relative values as big endian data on byte boundaries?

A)
As an example, let me introduce an example using ASMSH in the Hitachi compiler environment.
In the Hitachi assembler environment, divider shift can be used for absolute values. Using this function,

.DATA.B \data>> twenty four
.DATA.B \data<< 8>> twenty four
.DATA.B \data<< 16>> twenty four
.DATA.B \data<< twenty four>> twenty four

Please define a macro such as


Where should I set the load address for 1st Read File?

Q)
Where should I set the load address for the 1st read file?

A)
The 1st read file is the first file loaded as an application after IP.BIN. The areas that can be loaded are as follows.

6002000H + IP size┏━━━━━━━━━━━━━━━┓
                  ┃ 1st read file ┃
                  ┃ loadable area ┃
                  ┃               ┃
                  ┃               ┃
60FF000H          ┣━━━━━━━━━━━━━━━┫
                  ┃ System usage  ┃
                  ┃ area          ┃
60FFFFFH          ┗━━━━━━━━━━━━━━━┛

60FF000H to 60FFFFFH are used by the system, so never load the 1st read file.

After loading the 1st read file, it will be released to the application.
Also, 6000000H to 6001FFFH are used by the system and should not be used by applications.
However, stacks from 600E00H to 6001FFFH can be used.
After IP processing is completed and the application starts,

If you prepare other stacks of master SH, up to 6001000H,
If you prepare another slave SH stack, up to 6000E00H.

Each can be used.

6000000H     ┏━━━━━━━━━━━━━━━━━━━━━━━━━━┓
             ┃ Vector, resident routine ┃
6000E00H     ┣━━━━━━━━━━━━━━━━━━━━━━━━━━┫
             ┃ Slave SH stack           ┃
6001000H     ┣━━━━━━━━━━━━━━━━━━━━━━━━━━┫
             ┃ Master SH stack          ┃
6002000H     ┣━━━━━━━━━━━━━━━━━━━━━━━━━━┫
             ┃                          ┃


The moment it blacks out from the SEGA logo, it goes out of control when you open the tray.

Q)
After loading the 1st Read File, the SEGA logo appears, but immediately after this blackout occurs and the screen turns black, if you open the CD tray, the program will run out of control.
During normal games, if I open the CD tray, the game will jump to the multiplayer screen without any problem, but if I open the CD tray at this time, it will go out of control. Why?

A)
The most likely cause of such symptoms is neglecting to check the CD tray open.
To explain the principle in detail, once the screen goes black, control is transferred to the application program.
After this, if a new program is loaded, if the tray open check is not performed, the program will be called with the program data incompletely loaded.
The result after that is self-evident, but the application will run out of control.
In other words, the application must always open the tray.
In addition, it has been confirmed that on rare occasions (although at very severe times) this kind of symptom occurs due to a bug in the GFS library.
If the same symptoms occur despite taking the above measures, there may be a bug in GFS, so please replace with the latest GFS library (lincd.a file in the case of SGL). .


Please tell me about the hierarchical structure of 3D models.

Q)
I'm thinking of making a 3D multi-jointed game, but I don't really understand how to manipulate data that has a 3D indirect structure.
Please tell me about creating 3D games.

A)
Generally, when creating a 3D game with a hierarchical structure, a method is used to calculate child data from the parent-child structure of the model.
In other words, the child only has a relative component from the parent, and when the parent's calculation is completed, the child's coordinates are calculated using the parent's data.
If you have the parent's position information in a matrix, to calculate the child's coordinates, generate the child's relative components by applying 3D affine transformation to the child's parent matrix. In the case of SGL, this can be easily done using the functions provided by the system.
Of course, this is not to say that it cannot be done with SBL, but it is easier to do with SGL. *SGL has a sample that uses the AKIRA model of Virtua Fighter, but the hierarchical structure of this sample program uses a very special method and is not suitable for use as a reference.
If you want a sample of the hierarchical structure, please see s_8_12 (sample_8_12 for IRIX). This concept itself can be used in both SGL and SBL.


Back | ■
FAQGeneral program
Copyright SEGA ENTERPRISES, LTD. 1997