Hardware errata - Revision history

Starfrost at 20:09, 19 January 2026

2026-01-19T20:09:02Z

← Older revision		Revision as of 20:09, 19 January 2026
Line 39:		Line 39:

	=== <code>PCRTC_CONFIG</code> cannot be accessed unless another CRTC register is accessed first ===		=== <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.		The NV4 CRTC config register (configuring the [[Weitek]] licensed CRTC) cannot be accessed (for read or write) unless another CRTC register is read first on NV4 revision A. This was fixed in revision B of the NV4.

	=== TV mode: Cursor & overlay position inaccuracies ===		=== 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.		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.

Starfrost at 20:08, 19 January 2026

2026-01-19T20:08:38Z

← Older revision		Revision as of 20:08, 19 January 2026
Line 36:		Line 36:

	=== [[VBIOS]] mapped to wrong location ===		=== [[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-~~0x700FFF~~</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.		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 ===		=== <code>PCRTC_CONFIG</code> cannot be accessed unless another CRTC register is accessed first ===

Huanker: Amendment to VBIOS bug to introduce mention of older VBIOS versions.

2025-12-25T21:00:43Z

Amendment to VBIOS bug to introduce mention of older VBIOS versions.

← Older revision		Revision as of 21:00, 25 December 2025
Line 8:		Line 8:
	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.		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 ~~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.		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.		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.

Starfrost at 14:00, 16 September 2025

2025-09-16T14:00:39Z

← Older revision		Revision as of 14:00, 16 September 2025
Line 36:		Line 36:

	=== [[VBIOS]] mapped to wrong location ===		=== [[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-0x700FFF</code>, the first <code>0xFFFF</code> bytes of [[NV4 PRAMIN\|PRAMIN]], and ~~therefore making it unusable~~ (unless the ROM is disabled using PCI configuration space register 0x31?); the intended ~~area~~ instead simply returns <code>0xFF</code> for all bytes. However, this is not a problem in practice since only the areas of RAMIN ~~after~~ 0x10000 are actually used by Nvidia's drivers due to where [[NV4 RAMHT\|RAMHT]] is initialised to. However, it is of concern to emulator developers and those individuals hoping to program the GPU registers directly.		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-0x700FFF</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 ===		=== <code>PCRTC_CONFIG</code> cannot be accessed unless another CRTC register is accessed first ===

Starfrost at 13:59, 16 September 2025

2025-09-16T13:59:28Z

← Older revision		Revision as of 13:59, 16 September 2025
Line 36:		Line 36:

	=== [[VBIOS]] mapped to wrong location ===		=== [[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-~~0x70FFF~~</code>, the first <code>0xFFFF</code> bytes of [[NV4 PRAMIN\|PRAMIN]], and therefore making it unusable (unless the ROM is disabled using PCI configuration space register 0x31?); the intended area instead simply returns <code>0xFF</code> for all bytes. However, this is not a problem in practice since only the areas of RAMIN after 0x10000 are actually used by Nvidia's drivers due to where [[NV4 RAMHT\|RAMHT]] is initialised to. However, it is of concern to emulator developers and those individuals hoping to program the GPU registers directly.		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-0x700FFF</code>, the first <code>0xFFFF</code> bytes of [[NV4 PRAMIN\|PRAMIN]], and therefore making it unusable (unless the ROM is disabled using PCI configuration space register 0x31?); the intended area instead simply returns <code>0xFF</code> for all bytes. However, this is not a problem in practice since only the areas of RAMIN after 0x10000 are actually used by Nvidia's drivers due to where [[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 ===		=== <code>PCRTC_CONFIG</code> cannot be accessed unless another CRTC register is accessed first ===

Starfrost at 13:59, 16 September 2025

2025-09-16T13:59:14Z

← Older revision		Revision as of 13:59, 16 September 2025
Line 36:		Line 36:

	=== [[VBIOS]] mapped to wrong location ===		=== [[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-0x70FFF</code>, the first <code>0xFFFF</code> bytes of [[NV4 PRAMIN\|PRAMIN]], and therefore making it unusable (unless the ROM is disabled using PCI configuration space register 0x31?); the intended area instead simply returns <code>0xFF</code> for all bytes. However, this is not a problem in practice since only the areas of RAMIN after 0x10000 are actually used by Nvidia's drivers due to where [[NV4 ~~PRAMHT~~\|~~PRAMHT~~]] is initialised to. However, it is of concern to emulator developers and those individuals hoping to program the GPU registers directly.		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-0x70FFF</code>, the first <code>0xFFFF</code> bytes of [[NV4 PRAMIN\|PRAMIN]], and therefore making it unusable (unless the ROM is disabled using PCI configuration space register 0x31?); the intended area instead simply returns <code>0xFF</code> for all bytes. However, this is not a problem in practice since only the areas of RAMIN after 0x10000 are actually used by Nvidia's drivers due to where [[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 ===		=== <code>PCRTC_CONFIG</code> cannot be accessed unless another CRTC register is accessed first ===

Starfrost at 13:58, 16 September 2025

2025-09-16T13:58:56Z

← Older revision		Revision as of 13:58, 16 September 2025
Line 36:		Line 36:

	=== [[VBIOS]] mapped to wrong location ===		=== [[VBIOS]] mapped to wrong location ===
	Official documentation for NV4-based products states that the VBIOS should be mapped to <code>0x300000-~~0x30FFF~~</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-0x70FFF</code>, the first <code>0xFFFF</code> bytes of [[NV4 PRAMIN\|PRAMIN]], and therefore making it unusable (unless the ROM is disabled using PCI configuration space register 0x31?); the intended area instead simply returns <code>0xFF</code> for all bytes. However, this is not a problem in practice since only the areas of RAMIN after 0x10000 are actually used by Nvidia's drivers due to where [[NV4 PRAMHT\|PRAMHT]] is initialised to. However, it is of concern to emulator developers and those individuals hoping to program the GPU registers directly.		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-0x70FFF</code>, the first <code>0xFFFF</code> bytes of [[NV4 PRAMIN\|PRAMIN]], and therefore making it unusable (unless the ROM is disabled using PCI configuration space register 0x31?); the intended area instead simply returns <code>0xFF</code> for all bytes. However, this is not a problem in practice since only the areas of RAMIN after 0x10000 are actually used by Nvidia's drivers due to where [[NV4 PRAMHT\|PRAMHT]] 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 ===		=== <code>PCRTC_CONFIG</code> cannot be accessed unless another CRTC register is accessed first ===

Starfrost at 13:58, 16 September 2025

2025-09-16T13:58:20Z

← Older revision		Revision as of 13:58, 16 September 2025
Line 10:		Line 10:
	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 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.		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 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 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-~~1mb~~ area reserved for the VBIOS) proved that it was fully intact.		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 ===		=== Extremely strange behaviour on turning off interrupts ===

Starfrost at 12:37, 16 September 2025

2025-09-16T12:37:21Z

← Older revision		Revision as of 12:37, 16 September 2025
Line 34:		Line 34:
	=== Random VRAM corruption at pixel clocks above 160MHz using 64-bit bus ===		=== 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.		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-0x30FFF</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-0x70FFF</code>, the first <code>0xFFFF</code> bytes of [[NV4 PRAMIN\|PRAMIN]], and therefore making it unusable (unless the ROM is disabled using PCI configuration space register 0x31?); the intended area instead simply returns <code>0xFF</code> for all bytes. However, this is not a problem in practice since only the areas of RAMIN after 0x10000 are actually used by Nvidia's drivers due to where [[NV4 PRAMHT\|PRAMHT]] 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 ===		=== <code>PCRTC_CONFIG</code> cannot be accessed unless another CRTC register is accessed first ===
Line 39:		Line 42:

	=== TV mode: Cursor & overlay position inaccuracies ===		=== 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).		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.

Starfrost at 13:10, 22 June 2025

2025-06-22T13:10:46Z

← Older revision		Revision as of 13:10, 22 June 2025
Line 38:		Line 38:
	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.		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 inaccuracies ===		=== TV mode: Cursor & overlay position inaccuracies ===
	The cursor may have a slightly inaccurate position if an NV4-based card is connected to a TV. This is worked around in the drivers by Nvidia by adding an adjust value.		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).