Hardware errata

This is a list of known hardware errata in Nvidia graphics cards

NV3

Early VBIOS bugs

While not technically a hardware errata, due to an unknown issue with the video BIOS code in certain very early NVidia RIVA 128 units, certain VGA functions are broken. This causes garbage characters to appear inside of the Windows 98 Startup menu while trying to boot from CD-ROM.

This bug is known to exist in very early STB Velocity 128 units with VBIOS version 1.60, dated 8 August 1997, with GPUs manufactured in July 1997; this behaviour was discovered on a chip manufactured in week 33 of 1997, VRAM manufactured week 25, a 1.60 Velocity 128 VBIOS with a label on top reading 9/17/97 and a final board manufacture date of 10 October 1997, and was later confirmed when this VBIOS was dumped and emulated. This behaviour does not appear to exist on all other VBIOSes, which are dated 3 September 1997 or later. There is no workaround for this bug other than potentially updating the VBIOS, although using a method that involves mashing the down arrow key you can still get into Windows 98 Setup with no problems.

It is unclear if this issue originates from Nvidia, or any modifications STB Systems may have made to the VBIOS code. While bitrot of the VBIOS flash chip was considered, dumping the VBIOS multiple times and via multiple methods (both by reading out the PROM region and reading directly from the below-1mb area reserved for the VBIOS) proved that it was fully intact

Extremely strange behaviour on turning off interrupts

On a NV3T (RIVA 128 ZX) stepping A2 card, turning off interrupts did not turn off interrupts, but instead caused all areas of MMIO not to be mapped to a register to endlessly decrement, wrapping over to 0xFF when they reached zero. The card showed no outward symptoms of this extremely strange behaviour and otherwise continued to operate normally.

CRTC scanline counter needs to be read twice

Under some circumstances, the CRTC scanline counter needs to be read twice to get a correct result.

NV3 DMA submission error

In the following circumstances:

• A 16 or 32-bit blit is occurring via the DMA method;
• the source area has a width of less than 16 pixels;
• the format of the blit has alpha transparency;
• the blit needs to be stretched during transfer;
• the source of the blit is in the GPU local VRAM;
• the NV3 card is Revision A or B (i.e. an original RIVA 128 rather than a ZX).

The data may be transferred incorrectly, although the mechanism of such is not known. The drivers work around this by sending the pitch of the data to be sent in bytes, rather than the width in pixels. The older hardware revisions may not account for the pitch not being the same as the width (this is further suggested by the same code not being in the 8bpp blitting code) in this case.

NV4

Random VRAM corruption at pixel clocks above 160MHz using 64-bit bus

Due to a bug in the NV4 bus arbitration hardware to do with both memory refreshes and pagetable TLB misses, random VRAM corruption may occur if the straps are set such that the card is configured to use a 64-bit bus (used in many lower-end NV3, NV4 and NV5 configurations), and the pixel clock is above 160Mhz. This, in practice, requires a refresh rate of above 60Hz, a framebuffer configured to use 32 bits per pixel mode (which 24 bits per pixel is internally considered to be as well), and a resolution of 1600x1200 or higher. Nvidia worked around this in their drivers by simply preventing the selection of any video mode where the resolution is 1600x1200x32 and the refresh rate is above 60Hz.

PCRTC_CONFIG cannot be accessed unless another CRTC register is accessed first

The NV4 CRTC config register (configuring the Weitek licensed CRTC) cannot be accessed (for read or write) unless another CRTC is read first on NV4 revision A. This was fixed in revision B of the NV4.