Q&A- Microcode

Q1 What is a suitable FIFO buffer size for the FIFO microcode?

A1 The larger the size, the less time is wasted between SP and DP, making it possible to increase the overall speed of the RCP. However, the speed stops changing past a certain size. Since the suitable size differs depending on the application, it must be determined while viewing the balance between processing time in the RSP and idle RAM space. Depending on the circumstances, sometimes 128KB are taken, but there are also times when 10KB is enough. The minimum required size is 0x300 bytes for F3DEX series, and 0x800 bytes for S2DEX. In addition, around 100Kbytes are reserved for Mario.

top

Q2 What is the current status of the Z-sort microcode?

A2 Its release has been announced, and it is only a matter of distributing the Z-sort Microcode. However, the Z-sort microcode libraries are still not completed. Consequently, it currently has not been officially released.

An official release date for the Z-sort microcode has not yet been determined. There are several reasons for this, including the following:

1. Its incorporation into games is not easy because it is not compatible with F3D GBI's
2. Preprocessing in the CPU is required to run the microcode
3. Minimum scheduling samples for the RSP and CPU (including audio processing) to make them usable in games have not been established
4. There are no tools for outputting with a Z-sort structure

The latest version, Version 0.34, has been uploaded to NTSC-ONLINE as a beta Version for evaluation.

Precautions

Using this microcode and its libraries may or may not have an effect on games in which the RDP currently is a bottleneck. However, please be aware that it has no effect on those games in which the CPU and/or RSP are a bottleneck. In addition, even though there is an effect on RDP processing, it cannot be guaranteed to improve the overall performance of game applications. Please evaluate this microcode keeping these facts in mind.

Since the current version 0.34 is a beta test version, please understand that the specifications are subject to substantial change. While the majority of this microcode is beyond the scope of support, it would be helpful if you would contact us, attn: NTSC, regarding bugs, etc.

top

Q3 Which microcodes are currently supported?

A3 As of February 1, 1999

Officially Supported Microcodes

• F3DEX(2), L3DEX(2) microcodes
• S2DEX(2) microcode
• aspMain, n_aspMain microcodes
• Fast3D and Line3D microcodes are within the scope of support for the purposes of "bug fixes," but it is recommended that you use F3DEX2.

Not Supported

• Turbo3D microcode
• Sprite2D microcode
• Fast3D and Line3D microcodes are within the scope of support for the purposes of "bug fixes," but it is recommended that you use F3DEX or L3DEX microcodes or S2DEX2.

Supported as a beta test version
Currently accepting test reports, bugs and requests:

• JPEG microcode
• Z-sort microcode

Q4 What's happening with the "JPEG microcode" mentioned in the Allman Manual?

A4 The JPEG microcode is currently in the beta test version. You can use the SGI version which has been uploaded to NTSC-ONLINE.

top

Q5 By slightly changing the program, rendering processing by the microcode will either work fine or may hang up.

A5 There are two causes for a program stopping while waiting for microcode processing to end.

1. There may be a problem with the contents of the display list which has been created, which may cause the RCP to crash.

   -Or-

2. The contents of the display list have been changed before rendering processing by the RSP has been completed, causing an illegal display list to be processed.

Write the program so that the vertex data and matrix data, etc. used by the display list are held until the RSP finishes its processing.

top