Any electronic device needs a clock source to operate, and nVIDIA GPUs are no exception. In early GPUs, the system of generating phase-locked loops (PLL) was a derivative of the system used by the SGS-Thomson (now STMicro) STG-1764 "Van Gogh", which was used as the external RAMDAC on the NV1. Although which PLLs existed changed, the overall system implementation was very similar from [[NV1]] until [[NV20]]. A partial break from this system was introduced with the implementation of multi-stage clocks in [[NV30]] and a full break was achieved with [[NV40]]'s implementation of clock domains{{ref|a}}.

=== Initial clock system (1995-2002) ===

The clock system in NV1 to NV2x is based in the external DAC (NV1) or on chip within in the <code>[[PRAMDAC]]</code> functional block (NV3 or later). Where it is integrated onto the chip, it is exposed in all generations at the MMIO address range between <code>0x680300</code> and <code>0x680FFF</code>. In most cases (and in all cases prior to [[NV10]]), the registers starting at MMIO address <code>0x680500</code> and ending at <code>0x6805FF</code> are used for PLL configuration; each PLL has a 32-bit{{ref|c}} register assigned to it, and there is a second 32-bit register (typically at <code>0x68050C</code>) that is used to configure these PLLs. Each PLL register is split into three dividers{{ref|b}}, with the low 8 bits of the register making up <code>MDIV</code>, bits 15 through 8 making up <code>NDIV</code>, and a three-bit (bits 18 through 16) <code>PDIV</code>. These are combined with a base clock speed - which can be simply the clock speed of the signal coming directly from the on-board clock crystal or configured via straps - in order to create the final clock speed using the following formula:

<pre>(base_clock_speed * NDIV) / (MDIV << PDIV)</pre>

For example, if the base clock speed is 10MHz, <code>NDIV</code> is 90, <code>MDIV</code> is 10 and <code>PDIV</code> is 1, the formula resolves as:

<pre>(10000000 * 90) / (10 << 1)</pre>

which resolves to exactly 45,000,000 Hz (or 45 MHz).

Additionally, via the configuration register at <code>0x60850C</code>, various steps can be applied by the RAMDAC after this initial calculation. These settings are typically per-PLL; for example, a clock could be divided by a fixed divider, or its source can be changed. This aspect of the operation of the clock generators will be covered more in detail in the GPU-specific section.

=== PLLs on the NV1 ===
The NV1 has three PLLs which are used for different purposes and are presented in this table. In the NV1, the organisation of the registers for the clock dividers is slightly different - since they are located within the STG-1764 DAC, they are not located within MMIO but are actually located inside the internal register space of the 1764, which uses 8-bit registers. This, as well as the ultimately never used OPLL, means that each PLL takes up four 8-bit registers, one for each divider; the first register is used to hold the <code>MDIV</code>, the second the <code>NDIV</code>, the third the <code>ODIV</code> and the last the <code>PDIV</code>

{| class="wikitable"
|+ Clock sources on the NV1
|-
! PLL !! Purpose !! MMIO address !! Notes
|-
| <code>MPLL</code> || The name means '''M'''emory PLL, but actually clocks both the GPU core and the Video RAM || DAC space <code>0x18-0x1C</code> ||
Set by [[VBIOS]] scripts by default, however the GPU drivers will clock the GPU themselves if the Video BIOS does not. Default values are: <br>

* '''Video BIOS''': <code>NDIV</code>=91, <code>MDIV</code>=11, <code>PDIV</code>=1 (50.033454 MHz),
* '''Drivers''' (if PLL command cannot be found in Video BIOS): <code>NDIV</code>=100, <code>MDIV</code>=14, <code>PDIV</code>=1 (43.2 MHz),
|-
| <code>APLL</code> || Used to drive the audio system, although I am not sure exactly what it does - perhaps it drives the AD1845 SoundPort codec chip || DAC space <code>0x14-0x17</code> || Unknown
|-
| <code>VPLL</code> || Used to drive the video signal || DAC space <code>0x10-0x13</code> || Clock speed dependent on chosen refresh rate and resolution. Typically within the range of 40 to a maximum of 170MHz.
|}

==== Configuration ====

On NV1, the only configuration on the STG-1764 that directly corresponds to controlling the operation of the PLLs is the low three bits of <code>SGS_DAC_POWER_MGMT_B</code> (SGS DAC register <code>0x000D</code>), which are used to switch off individual PLLs (mysteriously misspelt as "PPLs"); enabling bit 2 will disable APLL, bit 1 will disable VPLL and bit 0 would disable VPLL.

==Notes==

{{note|a|}} Used to allow different parts of the GPU core to run at different clock frequencies.<br>
{{note|b|}} The NV1 technically has a fourth divider, <code>ODIV</code>, but it is always set to a value of 1 and is effectively never used.
{{note|c|}} Only 19 bits are actually used by these registers (except in NV1)

GPU Clocking

2026-03-25T17:23:28Z

Starfrost:

Any electronic device needs a clock source to operate, and nVIDIA GPUs are no exception. In early GPUs, the system of generating phase-locked loops (PLL) was a derivative of the system used by the SGS-Thomson (now STMicro) STG-1764 "Van Gogh", which was used as the external RAMDAC on the NV1. Although which PLLs existed changed, the overall system implementation was very similar from [[NV1]] until [[NV20]]. A partial break from this system was introduced with the implementation of multi-stage clocks in [[NV30]] and a full break was achieved with [[NV40]]'s implementation of clock domains{{ref|a}}.

=== Initial clock system (1995-2002) ===

The clock system in NV1 to NV2x is based in the external DAC (NV1) or on chip within in the <code>[[PRAMDAC]]</code> functional block (NV3 or later). Where it is integrated onto the chip, it is exposed in all generations at the MMIO address range between <code>0x680300</code> and <code>0x680FFF</code>. In most cases (and in all cases prior to [[NV10]]), the registers starting at MMIO address <code>0x680500</code> and ending at <code>0x6805FF</code> are used for PLL configuration; each PLL has a 32-bit{{ref|c}} register assigned to it, and there is a second 32-bit register (typically at <code>0x68050C</code>) that is used to configure these PLLs. Each PLL register is split into three dividers{{ref|b}}, with the low 8 bits of the register making up <code>MDIV</code>, bits 15 through 8 making up <code>NDIV</code>, and a three-bit (bits 18 through 16) <code>PDIV</code>. These are combined with a base clock speed - which can be simply the clock speed of the signal coming directly from the on-board clock crystal or configured via straps - in order to create the final clock speed using the following formula:

<pre>(base_clock_speed * NDIV) / (MDIV << PDIV)</pre>

For example, if the base clock speed is 10MHz, <code>NDIV</code> is 90, <code>MDIV</code> is 10 and <code>PDIV</code> is 1, the formula resolves as:

<pre>(10000000 * 90) / (10 << 1)</pre>

which resolves to exactly 45,000,000 Hz (or 45 MHz).

Additionally, via the configuration register at <code>0x60850C</code>, various steps can be applied by the RAMDAC after this initial calculation. These settings are typically per-PLL; for example, a clock could be divided by a fixed divider, or its source can be changed. This aspect of the operation of the clock generators will be covered more in detail in the GPU-specific section.

=== PLLs on the NV1 ===
The NV1 has three PLLs which are used for different purposes and are presented in this table. In the NV1, the organisation of the registers for the clock dividers is slightly different - since they are located within the STG-1764 DAC, they are not located within MMIO but are actually located inside the internal register space of the 1764, which uses 8-bit registers. This, as well as the ultimately never used OPLL, means that each PLL takes up four 8-bit registers, one for each divider; the first register is used to hold the <code>MDIV</code>, the second the <code>NDIV</code>, the third the <code>ODIV</code> and the last the <code>PDIV</code>

{| class="wikitable"
|+ Clock sources on the NV1
|-
! PLL !! Purpose !! MMIO address !! Notes
|-
| <code>MPLL</code> || The name means '''M'''emory PLL, but actually clocks both the GPU core and the Video RAM || DAC space <code>0x18-0x1C</code> ||
Set by [[VBIOS]] scripts by default, however the GPU drivers will clock the GPU themselves if the Video BIOS does not. Default values are: <br>

* '''Video BIOS''': <code>NDIV</code>=91, <code>MDIV</code>=11, <code>PDIV</code>=1 (50.033454 MHz),
* '''Drivers''' (if PLL command cannot be found in Video BIOS): <code>NDIV</code>=100, <code>MDIV</code>=14, <code>PDIV</code>=1 (43.2 MHz),
|-
| <code>APLL</code> || Used to drive the audio system, although I am not sure exactly what it does - perhaps it drives the AD1845 SoundPort codec chip || DAC space <code>0x14-0x17</code> || Unknown
|-
| <code>VPLL</code> || Used to drive the video signal || DAC space <code>0x10-0x13</code> || Clock speed dependent on chosen refresh rate and resolution. Typically within the range of 40 to a maximum of 170MHz.
|}

==== Configuration ====

==Notes==

{{note|a|}} Used to allow different parts of the GPU core to run at different clock frequencies.<br>
{{note|b|}} The NV1 technically has a fourth divider, <code>ODIV</code>, but it is always set to a value of 1 and is effectively never used.
{{note|c|}} Only 19 bits are actually used by these registers (except in NV1)

GPU Clocking

2026-03-25T17:15:59Z

Starfrost:

GPU Clocking

2026-03-25T17:06:42Z

Starfrost:

2026-01-19T20:08:38Z

Starfrost:

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

== Shared across multiple GPUs ==

== 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 <code>9/17/97</code> 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 VBIOSes dated 3 September 1997 and later, although it is currently unknown whether this behaviour exists in older VBIOS versions, with VBIOS versions as old as 1.40 being known to exist (however this VBIOS may have only been present in engineering samples). 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 as a possibility, dumping the VBIOS multiple times and via multiple methods (both by reading out the <code>PROM</code> region and reading directly from the below-1 MB 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 <code>0xFF</code> 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 an accurate 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 [[PSTRAPS|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.

=== [[VBIOS]] mapped to wrong location ===
Official documentation for NV4-based products states that the VBIOS should be mapped to <code>0x300000-0x300FFF</code> (<code>PROM</code>) in BAR0. However, in practice, according to dumps on multiple revision A5 NV4 chips, it is actually mapped to <code>0x700000-0x70FFFF</code>, which clashes with the first <code>0xFFFF</code> bytes of [[NV4 PRAMIN|PRAMIN]] and makes that range of RAMIN unusavble (unless the ROM is disabled using PCI configuration space register 0x31?); the area that NVIDIA seemingly intended the Video BIOS to be mapepd to instead simply returns <code>0xFF</code> for all bytes. However, this is not a problem in practice since only the areas of RAMIN starting at an offset <code>0x10000</code> are actually used by Nvidia's drivers due to where the location of [[NV4 RAMHT|RAMHT]] is initialised to. However, it is of concern to emulator developers and those individuals hoping to program the GPU registers directly.

=== <code>PCRTC_CONFIG</code> 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.

=== TV mode: Cursor & overlay position inaccuracies ===
The cursor, as well as the overlay position may have a slightly inaccurate position if an NV4-based card is connected to a TV and the straps are configured for TV Mode. This is worked around in the drivers by Nvidia by adding an adjust value - <code>0x00010400</code> in the case of the overlay position and <code>0x00010004</code> for the window start position.

NVPlay

2026-01-13T16:57:19Z

Starfrost:

{{Infobox software
| screenshot = Nvplay_6.png
| caption = A screenshot of NVPlay after completing some tests on an Nvidia Riva 128
| developer = [https://github.com/starfrost013/ Connor Hyde (starfrost)]
| released = {{Start date and age|2025|04|14|df=y}}
| latest release version = 1.0.1
| latest release date = {{Start date and age|2026|01|05|df=y}}
| latest preview version = 2.0.0.103; 1.1.0.102
| latest preview date = {{Start date and age|2026|01|13|df=y}}
| repo = {{URL|https://github.com/starfrost013/nvplayground/}}
| operating system = [[wikipedia:MS-DOS|MS-DOS]], [[wikipedia:Windows 3.x|Windows 3.x]] and [[wikipedia:Windows 9x|Windows 9x]]
| programming language = [[wikipedia:C (programming language)|C]]
| genre = [[wikipedia:Device driver|Driver]], [[wikipedia:Read-eval-print loop|REPL]], [[wikipedia:Diagnostic program|Diagnostic program]]
| license = [[wikipedia:MIT License | MIT License]]
}}

'''NVPlay''' is a tool designed to allow low-level communication with and control of graphics hardware, focusing on early Nvidia GPUs from the mid to late 1990s. It is a tool intended for developers to aid emulation efforts. The program will initialise your installed GPU in an entirely freestanding way without any drivers and has several modes that allow different methods to control your graphics hardware; it can run in a Windows 9x DOSbox, and has also been tested on Windows 3.1 and even 3.0, so can be run at the same time as NVIDIA's drivers.

By default, NVPlay runs in a REPL loop that lets you run a set of commands that do register-level GPU I/O.