VR4300: Difference between revisions
Added section for known differences between original VR4300 and one used in the N64.
Fraser.mips (talk | contribs) m (→Known Bugs: Added a clearer example of the MUL/MUL CPU bug) |
(Added section for known differences between original VR4300 and one used in the N64.) |
||
| (3 intermediate revisions by the same user not shown) | |||
Line 1:
The '''VR4300''' is the CPU of the Nintendo 64, and is
[[:File:VR4300-Users-Manual.pdf|VR4300 Users Manual]]
= Naming History =
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.
= Modifications =
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
{| 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.''
= Known Bugs =
Line 7 ⟶ 34:
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 early model Nintendo 64 consoles generally NUS-01 (Japan Only), NUS-02 (Japan Only), NUS-03 (First US Revision).
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 (fp)
For example, consider this function:
▲ <code>float mul(float x, float y) { return x * y; }</code>
Without the fix it may generate this code:
<
jal mul
nop
Line 20 ⟶ 46:
jr $31
mul.s $f0,$f12,$f14
</
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:
<
mul.s $f1,$f13,$f15
nop
Line 34 ⟶ 60:
jr $31
nop
</
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.
[[Category:Motherboard components]]
| |||