NV3 Getting Started - Revision history

Starfrost at 02:04, 11 November 2026

2026-11-11T02:04:57Z

← Older revision		Revision as of 02:04, 11 November 2026
Line 105:		Line 105:
	* If you are doing 3D rendering: In windowed mode, GDI still takes up memory in order to display the frame buffer. This can be a serious memory usage bottleneck, especially on a 4 MB card; even an 800x600x16bpp framebuffer takes up nearly 1/4th of VRAM (960 KB), ignoring any hidden objects! While the NV3 can swap textures out to system RAM, this is much slower and hence one of the reasons, among several others, why windowed-mode games tend to run slower. This is not helped by the fact that you ''have'' to render 3D graphics in 16-bit mode, as, although the NV3 architecture is perfectly happy outputting 32-bit fragments (output pixels), ''it can only accept 16-bit texture formats!'' Not being able to texture anything is a serious limitation in 3D rendering, so the drivers simply prevent you from doing so on Windows. After GDI and its surfaces, you get textures used by the current 3D scene (which can also be stored in system memory), which are usually swizzled in some way by the driver (do not confuse this feature with actual "texture swizzling", this seems to just be a memory usage optimisation by the Direct3D and OpenGL drivers).		* If you are doing 3D rendering: In windowed mode, GDI still takes up memory in order to display the frame buffer. This can be a serious memory usage bottleneck, especially on a 4 MB card; even an 800x600x16bpp framebuffer takes up nearly 1/4th of VRAM (960 KB), ignoring any hidden objects! While the NV3 can swap textures out to system RAM, this is much slower and hence one of the reasons, among several others, why windowed-mode games tend to run slower. This is not helped by the fact that you ''have'' to render 3D graphics in 16-bit mode, as, although the NV3 architecture is perfectly happy outputting 32-bit fragments (output pixels), ''it can only accept 16-bit texture formats!'' Not being able to texture anything is a serious limitation in 3D rendering, so the drivers simply prevent you from doing so on Windows. After GDI and its surfaces, you get textures used by the current 3D scene (which can also be stored in system memory), which are usually swizzled in some way by the driver (do not confuse this feature with actual "texture swizzling", this seems to just be a memory usage optimisation by the Direct3D and OpenGL drivers).

	After that you get two buffers; one is the current, presented 3D scene in its entirety and the next presents as a strange rainbow-looking thing, which is the Z-buffer (which stores the order in which to render polygons, for proper depth perception).		After that you get two buffers; one is the current, presented 3D scene in its entirety and the next presents as a strange rainbow-looking thing, which is the Z-buffer (which stores the order in which to render polygons, for proper depth perception). Now you've got a tour of how VRAM works, let's start programming this thing!

	~~Now~~ you~~'ve got a tour of~~ how ~~VRAM works, let's start programming this thing!~~		By default, most of the subsystems of the NV3 are actually turned off. This is done, presumably, in order to reduce power use by not having unneeded systems running while they are not being used. In order to turn on the GPU, you need to write <code>0x11111111</code> to <code>NV_PMC_ENABLE</code> (0x200) in order to turn on all subsystems. You also need to write the value <code>0x3</code> to <code>NV_PMC_INTR_EN_0</code> (<code>0x140</code>) in order to allow critical interrupts, like the VBlank interrupt, to fire. This is how nvplay does it:

	~~By default~~, ~~the~~ subsystems of ~~the NV3 ar e~~		<pre>

			/* Power up all GPU subsystems */
			Logging_Write(LOG_LEVEL_DEBUG, "NV3 Init: Enabling all GPU subsystems (0x11111111 -> NV3_PMC_ENABLE)...");
			NV_WriteMMIO32(NV3_PMC_ENABLE, 0x11111111);
			Logging_Write(LOG_LEVEL_DEBUG, "Done!\n");

			/* Enable interrupts (test) */
			Logging_Write(LOG_LEVEL_DEBUG, "NV3 Init: Enabling interrupts...");
			NV_WriteMMIO32(NV3_PMC_INTERRUPT_ENABLE, (NV3_PMC_INTERRUPT_ENABLE_HARDWARE \| NV3_PMC_INTERRUPT_ENABLE_SOFTWARE));
			</pre>

			<code>(NV3_PMC_INTERRUPT_ENABLE_HARDWARE \| NV3_PMC_INTERRUPT_ENABLE_SOFTWARE)</code> is a bitfield representation of 0x3 - bit 1 (0x2) enables software interrupts, while bit 0 (0x1) enables hardware interrupts.

Starfrost at 01:34, 11 November 2026

2026-11-11T01:34:39Z

← Older revision		Revision as of 01:34, 11 November 2026
Line 94:		Line 94:
	'''Note: ''' For some reason, at least under Windows 9x, if you open a DOS box, the top left corner of the window will be mirrored in the legacy VGA space (BAR0 <code>0xA0000-0xBFFFF</code>), in whatever graphics format the GPU is set up to use, but interlaced. This is, quite frankly, bizarre.		'''Note: ''' For some reason, at least under Windows 9x, if you open a DOS box, the top left corner of the window will be mirrored in the legacy VGA space (BAR0 <code>0xA0000-0xBFFFF</code>), in whatever graphics format the GPU is set up to use, but interlaced. This is, quite frankly, bizarre.

	BAR1 has two primary purposes on NV3. The first chunk of the BAR1 space is		BAR1 has two primary purposes on NV3. The first chunk of the BAR1 space is a mirror of Video RAM (usually 4 or 8 MB on a RIVA 128 ZX, rarely 2 MB), for basic ("dumb") framebuffer operations. The intended way of using Video RAM is to use the [[NV3 PGRAPH]] <code>B*</code> registers, via submitting "Image in Memory" objects, to configure any of up to four buffers with a pixel format, start position and size, and then assigning graphics objects to any of them (you can write to all of them at once) in instance memory, which is the other primary use of BAR1. Instance memory is located at <code>0xC00000</code> and basically holds the current loaded objects (within the current DMA channels) and allows you to execute "methods" (graphics commands) on them. This is a very simplified explanation, which will be further elaborated on later.

			If you have a working RIVA 128 and dump VRAM from it (using nvplay or some other feature), it has a very different layout depending on what you are actually doing with the card:

			* If you are in DOS, there won't be much here. At most, you'll see a weird 64-bit format that has something to do with how text-mode is displayed, where the 8th byte is the actual display, likely having something to do with the internal representation of the VGA font data; the actual VGA RAM is mirrored in BAR0.
			* If you are just doing 2D rendering, the format of the data takes the current graphics mode; if you are in 8-bit indexed colour mode, the format will be indexed colour (how to write colour indexes will be explained later), in 32-bit colour mode the format will be ARGB8888 (at least by default), and so on. The only minor exception is for 16-bit rendering, which for some reason, is actually 15-bit RGB555 unless <code>PRAMDAC_GENERAL_CONTROL</code> bit 12 is set, in which case it will be 16-bit RGB565 format. Note that the GPU often uses a different format during its own internal operations and downconverts to the format for the current surface later.

			The Windows GDI driver's VRAM management model is pretty simple; it just puts the visible display at VRAM address 0 (by setting buffer 0 to offset 0) and does ''not'' use any additional buffers (the GPU supports up to 4), and stores icons and other currently unused surfaces offscreen, right after the screen for optimisation reasons. It copies needed GDI surfaces into visible VRAM when needed.

			* If you are doing 3D rendering: In windowed mode, GDI still takes up memory in order to display the frame buffer. This can be a serious memory usage bottleneck, especially on a 4 MB card; even an 800x600x16bpp framebuffer takes up nearly 1/4th of VRAM (960 KB), ignoring any hidden objects! While the NV3 can swap textures out to system RAM, this is much slower and hence one of the reasons, among several others, why windowed-mode games tend to run slower. This is not helped by the fact that you ''have'' to render 3D graphics in 16-bit mode, as, although the NV3 architecture is perfectly happy outputting 32-bit fragments (output pixels), ''it can only accept 16-bit texture formats!'' Not being able to texture anything is a serious limitation in 3D rendering, so the drivers simply prevent you from doing so on Windows. After GDI and its surfaces, you get textures used by the current 3D scene (which can also be stored in system memory), which are usually swizzled in some way by the driver (do not confuse this feature with actual "texture swizzling", this seems to just be a memory usage optimisation by the Direct3D and OpenGL drivers).

			After that you get two buffers; one is the current, presented 3D scene in its entirety and the next presents as a strange rainbow-looking thing, which is the Z-buffer (which stores the order in which to render polygons, for proper depth perception).

			Now you've got a tour of how VRAM works, let's start programming this thing!

			By default, the subsystems of the NV3 ar e

Starfrost at 01:05, 11 November 2026

2026-11-11T01:05:19Z

← Older revision		Revision as of 01:05, 11 November 2026
Line 84:		Line 84:
	}		}
	</pre>		</pre>


	== Initialisation ==		== Initialisation ==
Line 93:		Line 92:
	'''Warning: ''' If the "mediaport" region (at <code>0x200000-0x200FFF</code>) is written to or read from without something being plugged into the mediaport, or certain other regions like the object registers, '''the entire PCI bus will lock up''', and the system will hard freeze, with the only option for recovering the system being using the rocker switch (the switch at the back).		'''Warning: ''' If the "mediaport" region (at <code>0x200000-0x200FFF</code>) is written to or read from without something being plugged into the mediaport, or certain other regions like the object registers, '''the entire PCI bus will lock up''', and the system will hard freeze, with the only option for recovering the system being using the rocker switch (the switch at the back).

	'''Note: ''' For some reason, at least under Windows 9x, if you open a DOS box, the top left corner of the window will be mirrored in the legacy VGA space (BAR0 <code>0xA0000-0xBFFFF), in whatever graphics format the GPU is set up to use, but interlaced. This is, quite frankly, bizarre.		'''Note: ''' For some reason, at least under Windows 9x, if you open a DOS box, the top left corner of the window will be mirrored in the legacy VGA space (BAR0 <code>0xA0000-0xBFFFF</code>), in whatever graphics format the GPU is set up to use, but interlaced. This is, quite frankly, bizarre.

	BAR1 has two primary purposes on NV3. The first chunk of the BAR1 space is		BAR1 has two primary purposes on NV3. The first chunk of the BAR1 space is

Starfrost at 01:04, 11 November 2026

2026-11-11T01:04:52Z

← Older revision		Revision as of 01:04, 11 November 2026
Line 3:		Line 3:
	== Introduction ==		== Introduction ==
	Most of the pages on this website are for people interested in how Nvidia's hardware works. You don't need to know everything about how the RIVA 128 works in order to actually program the hardware; you just need to be able to understand the interfaces to it and some of the registers. This is not for the faint of heart. You are directly programming complex graphics hardware (old does not mean simple - the RIVA 128 has 3.5 million transistors, far more than any human can individually comprehend) that is not yet fully understood, but advances are being made all the time, so check back to this page for new updates. Eventually versions of this page will be made for the NV1 and RIVA TNT, and hopefully the Riva TNT2 and maybe, one day, even the GeForce 256 and its Celsius/NV1x brethren, such as the GeForce 2 and the GeForce 4 MX. If you want to write a game or some other piece of software in this way, you will be effectively writing a mini-GPU driver to manage the GPU hardware resources combined with whatever software you may wish to develop. If you want to write raw-NV software for Windows, Linux or any other operating system you will need to write a kernel driver that exposes the GPU's raw interface to usermode before you can write anything at all (this driver may be done in the future). You can get around this by using something like [https://www.delorie.com/djgpp/ DJGPP] in order to write a DOS application using a 32-bit memory model, without any of DOS's 16-bit segmented cruft. This is the recommended approach as it has the minimum amount of overhead and boilerplate code, plus working under a DOS box such as the Windows 9x DOS box.		Most of the pages on this website are for people interested in how Nvidia's hardware works. You don't need to know everything about how the RIVA 128 works in order to actually program the hardware; you just need to be able to understand the interfaces to it and some of the registers. This is not for the faint of heart. You are directly programming complex graphics hardware (old does not mean simple - the RIVA 128 has 3.5 million transistors, far more than any human can individually comprehend) that is not yet fully understood, but advances are being made all the time, so check back to this page for new updates. Eventually versions of this page will be made for the NV1 and RIVA TNT, and hopefully the Riva TNT2 and maybe, one day, even the GeForce 256 and its Celsius/NV1x brethren, such as the GeForce 2 and the GeForce 4 MX. If you want to write a game or some other piece of software in this way, you will be effectively writing a mini-GPU driver to manage the GPU hardware resources combined with whatever software you may wish to develop. If you want to write raw-NV software for Windows, Linux or any other operating system you will need to write a kernel driver that exposes the GPU's raw interface to usermode before you can write anything at all (this driver may be done in the future). You can get around this by using something like [https://www.delorie.com/djgpp/ DJGPP] in order to write a DOS application using a 32-bit memory model, without any of DOS's 16-bit segmented cruft. This is the recommended approach as it has the minimum amount of overhead and boilerplate code, plus working under a DOS box such as the Windows 9x DOS box.

			== Concepts ==
			Before we start programming, there are many concepts, some that are more general to raw-level GPU development and other very specific to Nvidia, that need to be explained.

	== Pre-initialisation ==		== Pre-initialisation ==
Line 54:		Line 57:
	Then the two addresses returned must have their lower 24 bits masked off, so that they are aligned to a 16 MB boundary, as the lower byte is used for determining if prefetching is enabled (which it is) rather than store the lower byte of the address. Additionally, the RIVA 128 only decodes the upper 8 bits of its PCI BAR values, so if these values are not aligned, MMIO addresses will be misaligned, which is fatal for graphics programming. This is especially important if you want to change the PCI BARs later. Since these addresses are not mapped within your CPU's memory management unit (MMU), they now need to be mapped in order to actually perform memory-mapped I/O. This is done, on x86 architectures, by adding additional segment descriptors to the local descriptor table (LDT) of your CPU, with a base address for each BAR and a "limit" (MMU parlance for size) of 16 MB. In DJGPP, this is done by <code>#including</code> the file <code>dpmi.h</code> allocating two LDT descriptors with the function <code>__dpmi_allocate_ldt_descriptors(1);</code>. The parameter 1 is the number of descriptors to allocate, as it is is easier syntactically to allocate them one at a time. The function returns an integer that is later used to actually interface with the MMIO space. After this, the functions <code>__dpmi_set_segment_base_address</code> and <code>__dpmi_set_segment_limit</code> are done to actually assign the base and limit values to the LDT descriptors.		Then the two addresses returned must have their lower 24 bits masked off, so that they are aligned to a 16 MB boundary, as the lower byte is used for determining if prefetching is enabled (which it is) rather than store the lower byte of the address. Additionally, the RIVA 128 only decodes the upper 8 bits of its PCI BAR values, so if these values are not aligned, MMIO addresses will be misaligned, which is fatal for graphics programming. This is especially important if you want to change the PCI BARs later. Since these addresses are not mapped within your CPU's memory management unit (MMU), they now need to be mapped in order to actually perform memory-mapped I/O. This is done, on x86 architectures, by adding additional segment descriptors to the local descriptor table (LDT) of your CPU, with a base address for each BAR and a "limit" (MMU parlance for size) of 16 MB. In DJGPP, this is done by <code>#including</code> the file <code>dpmi.h</code> allocating two LDT descriptors with the function <code>__dpmi_allocate_ldt_descriptors(1);</code>. The parameter 1 is the number of descriptors to allocate, as it is is easier syntactically to allocate them one at a time. The function returns an integer that is later used to actually interface with the MMIO space. After this, the functions <code>__dpmi_set_segment_base_address</code> and <code>__dpmi_set_segment_limit</code> are done to actually assign the base and limit values to the LDT descriptors.

	It is highly recommended to write utility functions to make it easier to read and write to MMIO space. Most Nvidia registers are 32-bit, but 8-bit versions of the functions are also required in order to write to 8-bit legacy VGA registers. In DJGPP, these functions would be written like this; ~~they~~ are ~~likely~~ easy to port to any other 32-bit flat DOS environment of your choosing:		It is highly recommended to write utility functions to make it easier to read and write to MMIO space. Most Nvidia registers are 32-bit, but 8-bit versions of the functions are also required in order to write to 8-bit legacy VGA registers. In DJGPP, these functions would be written like this, with <code>bar0_selector</code> being the selector that you allocated earlier; these functions are very easy to port to any other 32-bit flat DOS environment of your choosing:

	<pre>		<pre>
Line 69:		Line 72:
	}		}

			/* Write 8-bit value to the MMIO */
	void NV_WriteMMIO8(uint32_t offset, uint8_t val)		void NV_WriteMMIO8(uint32_t offset, uint8_t val)
	{		{
Line 74:		Line 78:
	}		}

			/* Write 32-bit value to the MMIO */
	void NV_WriteMMIO32(uint32_t offset, uint32_t val)		void NV_WriteMMIO32(uint32_t offset, uint32_t val)
	{		{
Line 79:		Line 84:
	}		}
	</pre>		</pre>


	== Initialisation ==		== Initialisation ==
	After this the actual initialisation of the GPU can commence. But before that, ''what do you actually get?'' from those two descriptors?		After this the actual initialisation of the GPU can commence. But before that, ''what do you actually get?'' from those two descriptors?

	~~== Concepts ==~~		BAR0 is a pointer into the GPU's register space. Registers are very sparsely grouped together; the vast majority of addresses decode to open bus (often, but not entirely consistent, garbage, seemingly related to what the GPU is currently writing into Video RAM). A header file with the addresses of the registers can be obtained here: ((TODO : UPLOAD UNOFFICIAL NV3_REF.H)); see [[NV3 memory mapping]] for an explanation of which regions correspond to which functional blocks within the chip. It also contains (at offset <code>0x110000</code>) a mirror of the Video BIOS, if one is installed (an integrated chip may not have one).
	~~Before we start programming~~, ~~there are many concepts~~, some ~~that are more general to raw~~-~~level~~ GPU ~~development and other very specific~~ to ~~Nvidia~~, ~~that need to be explained~~.
			'''Warning: ''' If the "mediaport" region (at <code>0x200000-0x200FFF</code>) is written to or read from without something being plugged into the mediaport, or certain other regions like the object registers, '''the entire PCI bus will lock up''', and the system will hard freeze, with the only option for recovering the system being using the rocker switch (the switch at the back).

			'''Note: ''' For some reason, at least under Windows 9x, if you open a DOS box, the top left corner of the window will be mirrored in the legacy VGA space (BAR0 <code>0xA0000-0xBFFFF), in whatever graphics format the GPU is set up to use, but interlaced. This is, quite frankly, bizarre.

			BAR1 has two primary purposes on NV3. The first chunk of the BAR1 space is

Starfrost at 00:52, 11 November 2026

2026-11-11T00:52:17Z

Show changes

Starfrost at 00:30, 16 June 2025

2025-06-16T00:30:48Z

← Older revision		Revision as of 00:30, 16 June 2025
Line 15:		Line 15:

	== Concepts ==		== Concepts ==
	Before we start programming, there are many concepts, some general to raw-level GPU development and other very specific to Nvidia, that need to be explained.		Before we start programming, there are many concepts, some that are more general to raw-level GPU development and other very specific to Nvidia, that need to be explained.

Starfrost at 01:15, 9 June 2025

2025-06-09T01:15:54Z

← Older revision		Revision as of 01:15, 9 June 2025
Line 2:		Line 2:

	== Introduction ==		== Introduction ==
	Most of the pages on this website are for people interested in how Nvidia's hardware works. You don't need to know everything about how the RIVA 128 works in order to actually program the hardware; you just need to be able to understand the interfaces to it and some of the registers. This is not for the faint of hearted. You are directly programming complex graphics hardware (old does not mean simple - the RIVA 128 has 3.1 million transistors, far more than any human can individually comprehend) that is not yet fully understood, but advances are being made all the time, so check back to this page for new updates. Eventually versions of this page will be made for the NV1 and RIVA TNT, and hopefully the Riva TNT2 and maybe, one day, even the GeForce 256 and its Celsius/NV1x brethren, such as the GeForce 2 and the GeForce 4 MX. If you want to write a game or other software in this way, you will be effectively writing a mini-GPU driver to manage the GPU hardware resources combined with whatever software you may wish to develop. If you want to write raw-NV software for Windows, Linux or any other operating system you will need to write a kernel driver that exposes the GPU's raw interface to usermode before you can write anything at all (this driver may be done in the future). You can get around this by using something like [https://www.delorie.com/djgpp/ DJGPP] in order to write a DOS application using a 32-bit memory model, without any of DOS's 16-bit segmented cruft. This is the recommended approach as it has the minimum amount of overhead and boilerplate code, plus workin under a DOS box such as the Windows 9x DOS box. An emulator like [https://86box.net/ 86Box] and its emulated nVIDIA RIVA support can be used for testing without access to a real system, although it has not been merged into mainline as of yet and still may not be entirely accurate to how the real hardware may behave.		Most of the pages on this website are for people interested in how Nvidia's hardware works. You don't need to know everything about how the RIVA 128 works in order to actually program the hardware; you just need to be able to understand the interfaces to it and some of the registers. This is not for the faint of hearted. You are directly programming complex graphics hardware (old does not mean simple - the RIVA 128 has 3.5 million transistors, far more than any human can individually comprehend) that is not yet fully understood, but advances are being made all the time, so check back to this page for new updates. Eventually versions of this page will be made for the NV1 and RIVA TNT, and hopefully the Riva TNT2 and maybe, one day, even the GeForce 256 and its Celsius/NV1x brethren, such as the GeForce 2 and the GeForce 4 MX. If you want to write a game or other software in this way, you will be effectively writing a mini-GPU driver to manage the GPU hardware resources combined with whatever software you may wish to develop. If you want to write raw-NV software for Windows, Linux or any other operating system you will need to write a kernel driver that exposes the GPU's raw interface to usermode before you can write anything at all (this driver may be done in the future). You can get around this by using something like [https://www.delorie.com/djgpp/ DJGPP] in order to write a DOS application using a 32-bit memory model, without any of DOS's 16-bit segmented cruft. This is the recommended approach as it has the minimum amount of overhead and boilerplate code, plus workin under a DOS box such as the Windows 9x DOS box. An emulator like [https://86box.net/ 86Box] and its emulated nVIDIA RIVA support can be used for testing without access to a real system, although it has not been merged into mainline as of yet and still may not be entirely accurate to how the real hardware may behave.

	== Environment Setup ==		== Environment Setup ==

Starfrost at 01:15, 9 June 2025

2025-06-09T01:15:42Z

← Older revision		Revision as of 01:15, 9 June 2025
Line 2:		Line 2:

	== Introduction ==		== Introduction ==
	Most of the pages on this website are for people interested in how Nvidia's hardware works. You don't need to know everything about how the RIVA 128 works in order to actually program the hardware; you just need to be able to understand the interfaces to it and some of the registers. This is not for the faint of hearted. You are directly programming complex graphics hardware, ~~and the hardware~~ is not yet fully understood, but advances are being made all the time, so check back to this page for new updates. Eventually versions of this page will be made for the NV1 and RIVA TNT, and hopefully the Riva TNT2 and maybe, one day, even the GeForce 256 and its Celsius/NV1x brethren, such as the GeForce 2 and the GeForce 4 MX. If you want to write a game or other software in this way, you will be effectively writing a mini-GPU driver to manage the GPU hardware resources combined with whatever software you may wish to develop. If you want to write raw-NV software for Windows, Linux or any other operating system you will need to write a kernel driver that exposes the GPU's raw interface to usermode before you can write anything at all (this driver may be done in the future). You can get around this by using something like [https://www.delorie.com/djgpp/ DJGPP] in order to write a DOS application using a 32-bit memory model, without any of DOS's 16-bit segmented cruft. This is the recommended approach as it has the minimum amount of overhead and boilerplate code, plus workin under a DOS box such as the Windows 9x DOS box. An emulator like [https://86box.net/ 86Box] and its emulated nVIDIA RIVA support can be used for testing without access to a real system, although it has not been merged into mainline as of yet and still may not be entirely accurate to how the real hardware may behave.		Most of the pages on this website are for people interested in how Nvidia's hardware works. You don't need to know everything about how the RIVA 128 works in order to actually program the hardware; you just need to be able to understand the interfaces to it and some of the registers. This is not for the faint of hearted. You are directly programming complex graphics hardware (old does not mean simple - the RIVA 128 has 3.1 million transistors, far more than any human can individually comprehend) that is not yet fully understood, but advances are being made all the time, so check back to this page for new updates. Eventually versions of this page will be made for the NV1 and RIVA TNT, and hopefully the Riva TNT2 and maybe, one day, even the GeForce 256 and its Celsius/NV1x brethren, such as the GeForce 2 and the GeForce 4 MX. If you want to write a game or other software in this way, you will be effectively writing a mini-GPU driver to manage the GPU hardware resources combined with whatever software you may wish to develop. If you want to write raw-NV software for Windows, Linux or any other operating system you will need to write a kernel driver that exposes the GPU's raw interface to usermode before you can write anything at all (this driver may be done in the future). You can get around this by using something like [https://www.delorie.com/djgpp/ DJGPP] in order to write a DOS application using a 32-bit memory model, without any of DOS's 16-bit segmented cruft. This is the recommended approach as it has the minimum amount of overhead and boilerplate code, plus workin under a DOS box such as the Windows 9x DOS box. An emulator like [https://86box.net/ 86Box] and its emulated nVIDIA RIVA support can be used for testing without access to a real system, although it has not been merged into mainline as of yet and still may not be entirely accurate to how the real hardware may behave.

	== Environment Setup ==		== Environment Setup ==

Starfrost at 01:10, 9 June 2025

2025-06-09T01:10:50Z

← Older revision		Revision as of 01:10, 9 June 2025
Line 3:		Line 3:
	== Introduction ==		== Introduction ==
	Most of the pages on this website are for people interested in how Nvidia's hardware works. You don't need to know everything about how the RIVA 128 works in order to actually program the hardware; you just need to be able to understand the interfaces to it and some of the registers. This is not for the faint of hearted. You are directly programming complex graphics hardware, and the hardware is not yet fully understood, but advances are being made all the time, so check back to this page for new updates. Eventually versions of this page will be made for the NV1 and RIVA TNT, and hopefully the Riva TNT2 and maybe, one day, even the GeForce 256 and its Celsius/NV1x brethren, such as the GeForce 2 and the GeForce 4 MX. If you want to write a game or other software in this way, you will be effectively writing a mini-GPU driver to manage the GPU hardware resources combined with whatever software you may wish to develop. If you want to write raw-NV software for Windows, Linux or any other operating system you will need to write a kernel driver that exposes the GPU's raw interface to usermode before you can write anything at all (this driver may be done in the future). You can get around this by using something like [https://www.delorie.com/djgpp/ DJGPP] in order to write a DOS application using a 32-bit memory model, without any of DOS's 16-bit segmented cruft. This is the recommended approach as it has the minimum amount of overhead and boilerplate code, plus workin under a DOS box such as the Windows 9x DOS box. An emulator like [https://86box.net/ 86Box] and its emulated nVIDIA RIVA support can be used for testing without access to a real system, although it has not been merged into mainline as of yet and still may not be entirely accurate to how the real hardware may behave.		Most of the pages on this website are for people interested in how Nvidia's hardware works. You don't need to know everything about how the RIVA 128 works in order to actually program the hardware; you just need to be able to understand the interfaces to it and some of the registers. This is not for the faint of hearted. You are directly programming complex graphics hardware, and the hardware is not yet fully understood, but advances are being made all the time, so check back to this page for new updates. Eventually versions of this page will be made for the NV1 and RIVA TNT, and hopefully the Riva TNT2 and maybe, one day, even the GeForce 256 and its Celsius/NV1x brethren, such as the GeForce 2 and the GeForce 4 MX. If you want to write a game or other software in this way, you will be effectively writing a mini-GPU driver to manage the GPU hardware resources combined with whatever software you may wish to develop. If you want to write raw-NV software for Windows, Linux or any other operating system you will need to write a kernel driver that exposes the GPU's raw interface to usermode before you can write anything at all (this driver may be done in the future). You can get around this by using something like [https://www.delorie.com/djgpp/ DJGPP] in order to write a DOS application using a 32-bit memory model, without any of DOS's 16-bit segmented cruft. This is the recommended approach as it has the minimum amount of overhead and boilerplate code, plus workin under a DOS box such as the Windows 9x DOS box. An emulator like [https://86box.net/ 86Box] and its emulated nVIDIA RIVA support can be used for testing without access to a real system, although it has not been merged into mainline as of yet and still may not be entirely accurate to how the real hardware may behave.

			== Environment Setup ==
			Even before beginning to learn NV3 programming you must initialise the card. There are several steps for initialising an NV card:

			1. Mapping the MMIO and VRAM of the card into memory (using either the PCI BIOS or the main API)
			2. Determining the revision, straps, manufacture-time configuration and VRAM amount on the card
			3. Configuring the card for graphics operation
			4. Creating the objects that will be used for graphics operation (you can do this later, but in many cases objects are reused, so it is a good idea to do this)

			For now, copy <code>nv3_api.h</code> and <code>nv3_ref.h</code> from [https://github.com/starfrost013/nvplayground/tree/main/src/architecture/nv3 here] to get started. This isn't yet a complete reference, but it's enough to do basic work. This will be formalised into a real SDK later.

			== Concepts ==
			Before we start programming, there are many concepts, some general to raw-level GPU development and other very specific to Nvidia, that need to be explained.

Starfrost: X

2025-06-09T00:56:57Z

New page

You can program your completely obsolete GPU the way that the company intended, using boring APIs such as Direct3D and OpenGL. Or you can do it in the cool way. The choice is yours.

== Introduction ==
Most of the pages on this website are for people interested in how Nvidia's hardware works. You don't need to know everything about how the RIVA 128 works in order to actually program the hardware; you just need to be able to understand the interfaces to it and some of the registers. This is not for the faint of hearted. You are directly programming complex graphics hardware, and the hardware is not yet fully understood, but advances are being made all the time, so check back to this page for new updates. Eventually versions of this page will be made for the NV1 and RIVA TNT, and hopefully the Riva TNT2 and maybe, one day, even the GeForce 256 and its Celsius/NV1x brethren, such as the GeForce 2 and the GeForce 4 MX. If you want to write a game or other software in this way, you will be effectively writing a mini-GPU driver to manage the GPU hardware resources combined with whatever software you may wish to develop. If you want to write raw-NV software for Windows, Linux or any other operating system you will need to write a kernel driver that exposes the GPU's raw interface to usermode before you can write anything at all (this driver may be done in the future). You can get around this by using something like [https://www.delorie.com/djgpp/ DJGPP] in order to write a DOS application using a 32-bit memory model, without any of DOS's 16-bit segmented cruft. This is the recommended approach as it has the minimum amount of overhead and boilerplate code, plus workin under a DOS box such as the Windows 9x DOS box. An emulator like [https://86box.net/ 86Box] and its emulated nVIDIA RIVA support can be used for testing without access to a real system, although it has not been merged into mainline as of yet and still may not be entirely accurate to how the real hardware may behave.