| QA1 | The display breaks apart when I remove the performance meter... |
| QA2 | I want to randomly switch the retrace cycle between 30 and 60Hz... |
| QA3 | [ver1.2]A warning appears when I rebuild the library... |
| QA4 | [ver1.2]PFS_ERR_INVALID is returned when I call nuContPakRepairId()... |
| QA5 | How do I use xbus microcodes? |
| QA6 | I'm having a hard time reconstructing nuhighreso... |
| QA7 | How do I burn a program created with NuSystem into FLASH RAM? |
| QA8 | How do I overlay programs? |
| QA9 | Graphic task does not terminate if Audio is included. (199908) |
| QA10 | If Reset button remains pressed down, sound does not stop when MUS and HVQM are being used. (199909) |
| QA11 | MPAL64 hangs up when Reset button is pressed. (199909) |
Q1 I'm using the performance meter in the NUSYS debugging function to check rendering performance, but rendering, which is stable while the performance meter is displayed, breaks down when it is not displayed. Is the performance meter processing a really big burden?
A1 The performance meter processing depends on how many graphics tasks are running. However, since no more than several dozen polygons are used for rendering itself, the load is at most several percent.
You can view the number of tasks being processed and how many are waiting to be precessed with pendingGfx. When the performance meter or debugging console display is removed to control rendering processing, etc., processing must be performed with a mind toward reducing the number of tasks.
Please note that the total number of tasks increases when the performance meter and the debugging console are displayed, since various additional tasks are called.
Q2 I want to be able to randomly switch the retrace cycle between 30 and 60Hz, but the only way to do this now is to modify nuboot.c and use a fixed cycle. However, I'd like to be able to change the cycle depending on the situation.
A2 In addition to nuboot.c, you can also change the retrace cycle with osViSetEvent(). However, since the value of the retrace cycle is used in computing the number of samples in one frame of audio, it must be changed for the audio as well. This is because the number of samples is calculated by the audio manager only during initialization.
Incidentally, a retrace is generated by the hardware for each frame. Switching the cycle is no more than changing the cycle at which the retrace message is sent within the VI manager. Therefore, processing will be the same on the application side even if you perform screen rendering or main processing on a 2-frame cycle.
Q3 I am using NuSystem 1.2, but when I rebuild NuSystem using exeGCC, two warnings
../player_api.c:40: warning: assignment from incompatible pointer type ../player.c:1330: warning: comparison of distinct pointer types lacks a cast
come up while compiling the files under /mus.
The cause of this was that the "Channeldata", which is a member of the "song_t" structure in player.h, is in char format. The warnings disappeared when I changed this to the unsigned char format. The same thing was true for the "fxs" member of the "musConfig" structure in libmus.h.
Could I be forgetting something in my environment settings?
A3 You may ignore these warnings.
Whether a char is an unsigned char or a signed char is dependent on the compiler. Since char becomes a signed char when there is no option for exeGCC, the optional environment variable gcc in setup.bat is set so that the char is interpreted as unsigned in order to maintain compatibility with the IRIX compiler source code.
set gccsw=-mips3 -mgp32 -mfp32 -funsigned-char ...
By attaching this option, the pointer to an unsigned char and the pointer to char are the same thing, but the compiler will send a warning.
If this bothers you, modify the source code. (The warning does not appear in the SGI compiler.)
Since problems will arise when incorporating software which is dependent on this expression, please use u8, s8, u16, ...
Q4 I am using NuSystem 1.2, but the PVS_ERR_INVALID is returned every time I use ofPfsRepairId.
The processing procedure is something like,
Am I doing something wrong?
A4 When PFS_ID_FATAL is returned upon calling nuContPakOpen(), osMotorInit() is currently called. It seems that the PFS_ERR_INVALID is being returned because the Rumble Pak flag is then set in the OSPfs structure at that point. This is a problem of NuSystem 1.2 that has been corrected in NuSystem 2.0 and later.
To correct this in version 1.2, delete the else segment from line 73 to line 87 in NuSystem's nucontpakmgr.c file.
Since this will make it so that the Rumble Pak will not be recognized by the nuContPakOpen() Controller Pak initialization function, use the following processing sequence if it is necessary to identify a Rumble Pak.
Q5 Please tell me how to use xbus microcodes, such as F3DEX2.xbus, etc. on the NuSystem. Also, is the load on the RDP lightened by using an xbus microcode?
A1NuSystem is compatible with xbus microcodes starting with Ver. 2.0. In this case, please specify NU_SC_UCODE_XBUS in the NuGfxTaskStart() flag. Then, use nuGfxSetUcode() to set the microcode structure that contains the xbus microcode, and, once the xbus microcode has been added to spec, it can be used.
The advantage of using xbus, is that it is difficult to slow access from the RDP to the Z buffer and frame buffer in RDRAM since the fifo buffer in RDRAM is no longer accessed from the RSP. In addition, since the fifo buffer becomes unnecessary, that much memory is opened up.
However, since xbus microcodes directly send display lists from the RSP to the RDP, if the RDP is slow, the RSP will be made to wait and be slowed down. In contrast, when fifo is used, even if the RDP is slow, RSP processing can still continue as long as the fifo buffer is open. As for which to use, determine the one with the best performance and use it.
Q6 I am trying to copy Draw8Font() in nusnake to the nuhighreso sample, but I'm not having much luck. What should I do?
A6 This will not work since nuhighreso uses S2DEX, while Draw8Font() uses a GBI called gSPTexture() that does not exist in S2DEX. Use it separately.
Q7 How do I burn a program created with NuSystem onto a FLASH cartridge? (What is the syntax for using MAKEFILE?)
A7 Create a ROM image by replacing the linked library with a ROM library (changing makefile -lnusys_d -lgultra_d, etc. to -lnusys -lgultra_rom, etc.). Then, after changing the resulting ROM image into a master ROM image with a program called makemask, distributed on floppy disk when you entered into a contract with this company, write it to a FLASH cartridge.
Q8 What should I watch out for when overlaying programs with NuSystem?
A8The precautions for overlaying programs are pretty much the same as for most N64 programs, even when using NuSystem. Please refer to Chapter 10 "Using Overlays" in the N64 Programming Manual. However, since it is assumed with nuPiReadRom that data are only being loaded, only the data cache is disabled, making it necessary to disable the command cache, etc. yourself when overlaying code. Starting with NuSystem 2.05, a function, nuPiReadOverlay, has been added that is convenient for loading overlays. Please refer to the overlay sample, nuoverlay, which has been created using this function.
Q9 After Audio was included, Graphic task hangs up when more than a set process load was added. Sound is heard normally and the process inside the game is performed normally in such conditions. F3DEX2 and L3DEX2 microcodes are being used by switching them with the self-loading function for Graphic task. Is there anything I need to be aware of here?
A9It is necessary to specify OS_TASK_LOADABLE flag when starting the task if self-loading is used.
Specify NU_SC_TASK_LOADABLE in nuGfxTaskStart() flag in case of NuSystem.
Notes:
As there is a typing error in nusys.h for NuSystem version 2.06 or earlier versions, an error occurs if this constant is used.
Change the 82nd line of nusys.h (if ver.2.06)
to #define NU_SC_TASK_LOADABLE (OS_TASK_LOADABLE<<16) /* LOADABLE */
and use it.
Q10 When making a sound using the MUS library, if I continue to press down Reset button, the sound continues on. The same occurs when playing back HVQM. Tell me how to shut down the sound completely when resetting.
A10 First, about the MUS library, are you executing
nuAuPreNMIFuncSet(nuAuPreNMIProc);
at the time of initializing?
NuSystem sample, nu4 should be a good reference for the definite usage.
You probably are using the attached sample in the HVQM package, nuhvqm for the reference; however, this sample does not take PRENMI into consideration.
It is necessary to have a process to stop HVQM processing in order to stop sounds.
In case of nuhvqm, add nuPreNMIFuncSet(hvqmDelete); to initStage01(void).
(Resetting by nuPreNMIFuncRemove and nuAuPreNMIFuncSet is necessary when switching the HVQM playback with the ordinary game process.)
Q11 I use NuSystem Ver.1.00; if MPAL64 is used a hang up occurs sometimes when Reset button is pressed. Since I do not have osAfterPreNMI because of OS2.0H, I used the source you have instructed about, but it did not work properly. Currently, the following function is registered by nuGfxPreNMIFuncSet as the PreNMI process.
void preNMIProc(void)
{
nuGfxDisplayOff();
rumbleStop(); /* Stop Rumble Pak */
while ( osAfterPreNMI() != 0 );
while (1);
}
Probably this is because it does not wait for the end of the task. What should I do?
A11 Change as follows to wait for the task to end completely.
void preNMIProc(void)
{
s32 ret;
rumbleStop(); /* Stop Rumble Pak */
// Delete the callback function of Retrace.
nuGfxFuncRemove();
// Wait for the Graphic task to end completely.
nuGfxTaskAllEndWait();
// Stop the thread of the Task Manager so as not to start
// Graphic task and Audio Task anew.
osStopThread(&nusched.graphicsThread);
osStopThread(&nusched.audioThread);
osViSetYScale(1.0); // Needed when changing YScale.
// Black out the screen.
nuGfxDisplayOff();
do {
ret = osAfterPreNMI();
} while (ret != 0);
while (1);
}
Since NuSystem Ver.2.00, these processes are performed by NuSystem, so there is no need for these by the application.