Developers News 1.5

1.5

Nintendo 64 Developers Newsletters will be published periodically, as needed. These feature software and hardware system anomalies, which have been discovered, and their solutions and/or work-arounds. Development tips will also be included.

Reset Processing

There are two types of reset used in the Nintendo 64. Cold Reset is accomplished by cycling the power OFF and ON, while NMI (non-maskable interrupt) Reset is generated by pressing the RESET button. This document describes the processing methods for resetting the system using NMI.

Note: There are actually 3 reset methods which can be used with the R4000 Series: cold reset, soft reset and NMI, but soft reset is not supported by the Nintendo 64.

Processing Flow During Reset

The processing flow when the user presses the RESET button is as follows.

Press RESET button
Pre-NMI is generated
Pre-NMI processing
NMI generated
CPU goes to reset vector
CPU executes boot program

The time from Pre-NMI generation to NMI generation is 0.5 seconds or more. That is, if the finger is removed from the RESET button within 0.5 seconds, this time duration will be 0.5 seconds. However, if the button is continuously pressed for more than 0.5 seconds, the reset time will continue until immediately after the finger is removed (i.e., if the button is continuously pressed for 1 second, reset time will be 1 second).

There is no RESET switch on the current emulation boards, but a pseudo-NMI can be generated by executing a RESET program (see Nintendo 64 Developer News 1.2, "Tip: Handling Console Reset").

Precautions

NMI's are generated by the PIF. The PIF's job is primarily to perform the processing for mechanisms which use a serial interface, such as the Controller. Consequently, in cases where the CPU is constantly monitoring the Controller, there are instances in which the PIF will be BUSY and RESET generation will be delayed. This creates no problems as long as Controller data are read one time per frame.

In addition, the NMI wait time on current emulation boards is 0.5 seconds or more (around several seconds).

About Pre-NMI Processing

If the PIF load is at a normal level, a pre-NMI is generated at the time the RESET switch is pressed. The minimum processing that must be performed at the time of the pre-NMI is comprised of the following 4 items:

Stop graphics task
Stop audio task
Don't issue a new PI DMA
Return Yscale value to 1 (execute osViSetYScale(1)), if it has been modified

In other words, all RCP processing is stopped. When 64DD is used, it must also be reset.

Reasons for Pre-NMI

An NMI signal is generated in the Nintendo 64 only for the CPU. No RESET signal is input to the RCP. This is because it is difficult to forcibly terminate graphic and sound tasks which are currently being executed without giving the user an uneasy feeling.

Therefore, if processing in the RCP is not terminated after the pre-NMI is generated, processing in the RCP will continue to be executed even after a RESET. In the worst case, this will have a detrimental effect on the CPU's boot sequence, inevitably causing the CPU to hang up. In order to avoid this situation, it is necessary to terminate any processing being executed in the RCP after a pre-NMI has been generated.

Sample of Pre-NMI Processing

In the following example, a sample source code "simple" has been partially modified.

Each thread senses the generation of a pre-NMI by means of an OS_EVENT_PRENMI message, and the necessary processing is performed.

(a) Stopping GFX tasks

static void gameproc (void *argv)
{
  . . .
  while (1)
  {
    . . .
      switch (msg->gen.type)
      {
        . . .

          if (pendingGFX < 2)
          {
            createGfxTask(&glnfo[drawbuffer]);
            pendingGFX++;
            drawbuffer ^=1; /* switch the drawbuffer */
          }

        . . .

        case (OS_SC_PRE_NMI_MSG): /* stop creation of graphics tasks */
          pendingGFX += 2;
          break;

By not creating any new GFX tasks after the pre-NMI is generated, the drawing of new screens can be stopped, and the screen can be interrupted.

In addition, by making the pre-NMI processing portion as follows:

        case (OS_SC_PRE_NMI_MSG): /* stop creation of graphics tasks */
          pendingGFX += 2;
          osViBlack(TRUE);
          break;

The screen can be deleted (cleared to black) at the same time that the pre-NMI is generated, after resetting Yscale value to 1. Other processing is also possible in which the screen is gradually cleared by decreasing the brightness of the screen in the step-wise fashion, etc. All of this screen clearing processing is to avoid giving the user an uneasy feeling and, at the same time, it is necessary on the system level to stop the execution of tasks in the RCP by not creating any new tasks (the pendingGFX +=2 line in the above sample corresponds with this).

(b) Stopping audio tasks

static void _amMain (void *arg)
{
  . . .

  while (!done)
  {
    . . .

    switch (msg->gen.type)
    {
      . . .

      case (OS_SC_PRE_NMI_MSG):
      /* what should we really do here? quit? ramp down volume? */
        alSeqpStop(seqp) ;
        alSeqpDelete(seqp) ;
        done = 1;
        break ;

      . . .
    }
  }

  alClose(&_am.g);
}

It is possible to stop sound in the same way as graphics by not performing any new processing after generating a pre-NMI. In the above case, the procedure

alSeqpStop -> alSeqpDelete

was used because a standard MIDI sequence player is being used, but if a compact MIDI player is being used, sound would be stopped using the procedure

alCSPStop -> alCSPDelete

while if synthesizer voice is being used by a sound effect, the sound effect would be stopped using the procedure

alStopVoice -> alSynDelete

(however, alSynDelete cannot be implemented at the current time).

Caution is required when using alSeqpDelete and alCSPDelete, since there is a system anomaly in the N64 OS up to revision 2.0e which makes it possible that the interrupt would continue to be masked. Because of this, either use patch 1.01, or use OS 2.0g or later, when using these functions.

Processing is also possible which gradually diminishes the sound in the same way as the screen by decreasing the volume in a stepwise fashion. However, stop the execution of new audio tasks when the volume reaches 0.