VR4300: Difference between revisions

1,402 bytes added ,  1 year ago
Added section for known differences between original VR4300 and one used in the N64.
No edit summary
(Added section for known differences between original VR4300 and one used in the N64.)
 
(5 intermediate revisions by 3 users not shown)
Line 1:
The '''VR4300''' is the CPU of the Nintendo 64, and is ana NEC VR4300iVR4300 with slight modifications. Running at 93.75 MHz, the VR4300 handles game logic, reading responding to controller input from the [[PIF]], and preparing display lists and audio command lists for the [[RCP]] to draw and synthesize audio.
 
[[:File:VR4300-Users-Manual.pdf|VR4300 Users Manual]]
 
= KnownNaming BugsHistory =
In 1993, [[w:MIPS Technologies|MIPS Technologies, Inc.]] (MTI), the same company that designed the MIPS III architecture, developed the [[w:R4200|R4200]] microprocessor. Later in 1995, they made the R4300i, a derivative of the R4200. When MTI licensed it to NEC and Toshiba, those companies renamed the chips the VR4300 and TX4300 respectively. The microprocessor used in the N64's CPU, is a derivative of NEC's VR4300.
 
Over the years, these model names have been incorrectly identified. There is no such thing as a VR4300i, nor is there a NEC R4300.
Some VR4300 CPUs contain the “VR4300 multiplication bug”. This causes incorrect results to be generated, under certain circumstances, after computing a floating-point multiplication. The bug was fixed in later [https://en.wikipedia.org/wiki/Stepping_level steppings], and affects some but not all Nintendo 64 consoles. There is a ROM which tests if your hardware is affected by this bug (where?)
 
= Modifications =
GCC accepts the <code>-mfix4300</code> flag, which tells GCC to generate code with a workaround for this bug—two <code>nop</code> instructions are inserted after every <code>mul.s</code> or <code>mul.d</code>. For example, consider this function:
The VR4300 used in the N64 has been modified compared to the original VR4300 chip. Currently the known differences include:
 
* Six pins are in different locations
float mul(float x, float y) { return x * y; }
{| class="wikitable"
! !! Original !! N64
|-
| /INT1 || 58 || 57
|-
| JTCK || 57 || 58
|-
| /EValid || 105 || 104
|-
| /Reset || 104 || 105
|-
| DivMode0 || 116 || 112
|-
| DivMode1 || 112 || 116
|}
 
''There may be other differences, more research is required.''
If the fix is disabled, GCC will generate the following assembly (for the n32 ABI):
 
= Known Bugs =
 
Some VR4300 CPUs contain the “VR4300 multiplication bug”. This causes incorrect results to be generated, under certain circumstances, after computing a floating-point multiplication. The bug was fixed in later processor [https://en.wikipedia.org/wiki/Stepping_level steppings], and affects someearly but not allmodel Nintendo 64 consoles. Theregenerally isNUS-01 a(Japan ROMOnly), whichNUS-02 tests(Japan ifOnly), yourNUS-03 hardware(First isUS affectedRevision). by this bug (where?)
# Does not contain workaround, may cause problems.
mul:
jr $31
mul.s $f0,$f12,$f14
 
WithGCC accepts the setting<code>-mfix4300</code> enabledflag, which tells GCC willto appendgenerate code with a workaround for this bug—two <code>nop</code> instructions. Noteare thatinserted inafter thisevery case<code>mul.s (fp)</code>, the<code>mul.d second(fp)</code>, oneor goes into<code>mult the branch delay slot(integer)</code>.
 
For example, consider this function:
# Contains workaround for CPU bug.
<code>float mul(float x, float y) { return x * y; }</code>
mul:
Without the fix it may generate this code:
jr $31
<pre>
nop
jal mul.s $f0,$f12,$f14
nop
mul.s $f1,$f13,$f15
mul:
jr $31
mul.s $f0,$f12,$f14
</pre>
The mul.s after the nop (red) may produce unexpected results, if the operands in the mul.s after the jr (yellow) include NaN, Zero or Infinity.
 
With the fix it may generate this code:
<pre>
mul.s $f1,$f13,$f15
nop
jal mul
nop
nop
mul:
mul.s $f0,$f12,$f14
jr $31
nop
</pre>
Depending on the other instructions that can be reordered the nops could be other instructions that perform work, so this is a worst case scenario.
There may be a ROM which tests if your hardware is affected by this bug, but determining based on the Motherboard revision is easier.
[[Category:Motherboard components]]