mirror/86box.github.io
1
0
Fork 0
mirror of https://github.com/86Box/86box.github.io.git synced 2026-02-21 17:15:35 -07:00
Code Issues Packages Projects Releases Wiki Activity

More capitalization

Browse Source
This commit is contained in:
RichardG867
2025-01-22 18:38:00 -03:00
parent 8f37e21552
commit a0ce313d39
1 changed files with 19 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
_posts/2025-01-19-riva128-part-1.md
View File

@@ -17,16 +17,20 @@ If you are in possession of any of:
* Source code (drivers, VBIOS, etc) related to the NVIDIA RIVA 128
* Any similar documents, **excluding the well-known datasheet**, with technical information about a GPU going by the name "NV3", "STG-3000", "RIVA 128", "NV3T", "RIVA 128 Turbo" (an early name for the ZX) or "RIVA 128 ZX"
* **Any** document, code, or materials relating to a graphics card by NVIDIA, in association with Sega, Helios Semiconductor or SGS-Thomson (now STMicroelectronics) codenamed "Mutara", "Mutara V08", or "NV2", or relating to a cancelled Sega console codenamed "V08"
* Any documentation relating to Riva TNT
* Any documentation relating to RIVA TNT
* Any NVIDIA SDK version that is not 0.81 or 0.83
Please contact me @ thefrozenstar_ on Discord, via the 86Box Discord, my email address (mario64crashed@gmail.com) or via the linked GitHub account. These documents would be very helpful in helping me to emulate the NVIDIA RIVA 128 and other NVIDIA graphics cards.
---
## Introduction
The NVIDIA RIVA 128 is a graphics card released in 1997 by NVIDIA (nowadays of AI and $2000 overpriced quad-slot GPU fame). It was a Direct3D 5.0-capable accelerator, and one of the first to use a standard graphics API, such as DirectX, as its "native" API. I have been working on emulating this graphics card for the last several months; currently, while VGA works and the drivers are loading successfully on Windows 2000, they are not rendering any kind of accelerated output yet. Many people, including me, have asked for and even tried to develop emulation for this graphics card and other similar cards (such as its successor, "NV4" or Riva TNT), but have not succeeded yet (although many of these efforts continue). This is the first part of a series where I explore the architecture and my experiences in emulating this graphics card. I can't guarantee success, but if it was successful, it appears that it would be the first time that a full functional emulation of this card has been developed (although later NVIDIA cards have been emulated to at least some extent, such as the GeForce 3 in Cxbx-Reloaded and Xemu).
The NVIDIA RIVA 128 is a graphics card released in 1997 by NVIDIA (nowadays of AI and $2000 overpriced quad-slot GPU fame). It was a Direct3D 5.0-capable accelerator, and one of the first to use a standard graphics API, such as DirectX, as its "native" API. I have been working on emulating this graphics card for the last several months; currently, while VGA works and the drivers are loading successfully on Windows 2000, they are not rendering any kind of accelerated output yet. Many people, including me, have asked for and even tried to develop emulation for this graphics card and other similar cards (such as its successor, "NV4" or RIVA TNT), but have not succeeded yet (although many of these efforts continue). This is the first part of a series where I explore the architecture and my experiences in emulating this graphics card. I can't guarantee success, but if it was successful, it appears that it would be the first time that a full functional emulation of this card has been developed (although later NVIDIA cards have been emulated to at least some extent, such as the GeForce 3 in Cxbx-Reloaded and Xemu).
This is the first part of a series of blog posts that aims to demystify, once and for all, NVIDIA Riva 128. This is the first part, which will dive into the history of NVIDIA up to the release of the NVIDIA RIVA 128, and a brief overview of how the Riva 128 actually works. The second part will dive into the architecture of NVIDIA's drivers and how they relate to the hardware, and the third part will follow the lifetime of a graphics object from birth to display on the screen in extreme detail. Then, part four and an unknown number of parts after part four will go into detail on the experiences of developing a functional emulation for this graphics card.
This is the first part of a series of blog posts that aims to demystify, once and for all, NVIDIA RIVA 128. This is the first part, which will dive into the history of NVIDIA up to the release of the NVIDIA RIVA 128, and a brief overview of how the RIVA 128 actually works. The second part will dive into the architecture of NVIDIA's drivers and how they relate to the hardware, and the third part will follow the lifetime of a graphics object from birth to display on the screen in extreme detail. Then, part four and an unknown number of parts after part four will go into detail on the experiences of developing a functional emulation for this graphics card.
---
## A brief history
@@ -51,20 +55,22 @@ The reasons that 3dfx was able to design such an effective GPU when all others f
Effectively, NVIDIA had to design a graphics architecture that could at very least get close to 3dfx's performance, on a shoestring budget, with very little resources (60% of the staff, including the entire sales and marketing teams, having been laid off to preserve money). Since they did not have the time, they not only could not completely redesign the NV1 from scratch if they felt the need to do this (this would take two years - time that NVIDIA simply didn't have - and any design that came out of this effort would be immediately obsoleted by other companies, such as 3dfx's Voodoo line and ATI with its initially rather pointless, but rapidly advancing in performance and driver stability, Rage series of chips) the chip would have to work reasonably well on the first tapeout, as they simply did not have the capital to produce more revisions of the chip, The fact they were able to achieve a successful design in the form of the NV3 under such conditions was testament to the intelligence, skill and luck of NVIDIA's designers. Later on in this blogpost, we will explore how they managed to achieve this.
### The NV3 (Riva 128)
### The NV3 (RIVA 128)
It was with these financial, competitive and time constraints in mind that design on the NV3, which would eventually be commercialised as the RIVA 128 ("Real-time Interactive Video and Animation accelerator", with the 128 owing to its at-the-time very large 128-bit size of its internal bus), began in 1996. NVIDIA retained SGS-Thomson (soon to be renamed to STMicroelectronics, which is the name it is still under today) as the manufacturing partner, in return for SGS-Thomson cancelling their rival GPU - the STG-3001. In a similar vein to the NV1, NVIDIA was initially going to sell the card as the "NV3" with inbuilt audio functionality and SGS-Thomson was going to white-label the chip as the SGS-Thomson STG-3000 without audio functionality - it seems, based on the original contract language, which for some reason is [**only available on a website for example contracts, where it has been around since 2004**](https://contracts.onecle.com/NVIDIA/sgs.collab.1993.11.10.shtml), but appears to have originated from a filing with the U.S. Securities and Exchange Commission, based on the format and references to "the Commission", that NVIDIA convinced them to cancel their own GPU, the STG-3001, and manufacture the NV3 instead - which would prove to be a terrible decision for STMicro when NVIDIA dropped them and moved to TSMC for the RIVA 128ZX due to yield issues, and the fact that NVIDIA's venture capital funders were pressuring them to move to TSMC. STMicro manufactured PowerVR cards for a few more years, but they had dropped out of the market entirely by 2001.
After the NV2 disaster, the company made several calls on the NV3's design that turned out to be very good decisions. First, they acquiesced to Sega's advice (which they might have done already, but too late, to save the Mutara V08/NV2) and moved to an inverse texture mapping triangle based model (although some remnants of the original quad patching design remain) and removed the never-used DRM functionality from the card. This may have been assisted by the replacement of Curtis Priem with the rather egg-shaped David Kirk, perhaps notable as a "Special Thanks" credit on Gex and the producer of the truly unparalleled *3D Baseball* on the Sega Saturn during his time at Crystal Dynamics, as chief designer - Priem insisted on including the DRM functionality with the NV1, because back when he worked at Sun, the game he had written as a demo of the GX GPU designed by Malachowsky was regularly pirated. Another decision that turned out to pay very large dividends was deciding to forgo a native API entirely and entirely build the card around accelerating the most popular graphical APIs - which led to an initial focus on Direct3D (although OpenGL drivers were first publicly released in alpha form in December 1997, and released fully in early 1998). Initially DirectX 3.0 was targeted, but 5.0 came out late during the development of the chip (4.0 was cancelled due to [**lack of developer interest in its new functionality**](https://devblogs.microsoft.com/oldnewthing/20040122-00/?p=40963)) and the chip is mostly Direct3D 5.0 compliant (with the exception of some blending modes such as additive blending, which Jensen Huang later claimed was due to Microsoft not giving them the specification in time), which was made much easier by the design of their driver (which allowed, and still allows, graphical APIs to be plugged in as "clients" to the Resource Manager kernel - as I mentioned earlier, this will be explained in full detail later). The VGA core (which was so separate from the main GPU on the NV1 that it had its own PCI ID) was replaced by a VGA core licensed from Weitek (who would soon exit the graphics market), which was placed in the chip parallel to the main GPU with its own 32-bit bus, which massively accelerated performance in unaccelerated VESA titles, like Doom - and provided a real advantage over the 3D-only 3dfx cards (3dfx did have a combination card, the SST-96 or Voodoo Rush, but it used a crappy Alliance card and was generally considered a failure). Finally, Huang, in his capacity as the CEO, allowed the chip to be expanded (in terms of physical size and number of gates) from its original specification, allowing for a more complex design with more features.
The initial revision of the architecture appears to have been completed in January 1997. Then, aided by hardware simulation software (unlike the NV0, an actual hardware simulation) purchased from another almost-bankrupt company, an exhaustive test set was completed. The first bug presented itself almost immediately when the "C" character in the MS-DOS codepage appeared incorrectly, Windows took 15 minutes to boot, and moving the mouse cursor required a map of the screen so you didn't lose it by moving too far, but ultimately the testing was completed. However, NVIDIA didn't have the money to respin the silicon for a second stepping if problems appeared, so it had to work at least reasonably well in the first stepping. Luckily for NVIDIA, when the card came back it worked well enough to be sold to NVIDIA's board partners (almost certainly due to that hardware simulation package they had), and the company survived - most accounts indicate it was only three or four weeks away from bankruptcy; when 3dfx saw the RIVA 128 at its reveal at the CGDC 1997 conference, the response of one of the founders was "You guys are still around?" - NVIDIA's financial problems were so severe that 3dfx almost *bought* NVIDIA, effectively for the purpose of killing the company as a theoretical competitor, but refused, as they assumed they would be bankrupt within months anyway (a disastrous decision). However, this revision of the chip - revision A - was not the revision that NVIDIA actually commercialised; SGS-Thompson dropped the plans for the STG-3000 at some point, which led NVIDIA, now flush with cash (revenue in the first nine months of 1997 was only $5.5 million, but skyrocketed up to $23.5 million in the last three months - the first three month period of the RIVA 128's availability, owing to the numerous sales of RIVA 128 chips to add-in board partners), to create a new revision of the chip to remove the sound functionality (although some remnants of it were left after it was removed); some errata was also fixed and other minor adjustments made to the silicon - there are mentions of quality problems with early cards in a lawsuit filed against STB Systems (who were the first OEM partner for the Riva 128), it is not clear if the problems were on STB or NVIDIA's end and respun the chip, with the revision B silicon being completed in October 1997 and presumably available a month or two later. It is most likely that some revision A cards were sold at retail, but based on the dates, these would have to be very early units, with the earliest NVIDIA RIVA 128 drivers that I have discovered (labelled as "Version 0.75") dated August 1997 (these also have NV1 support - and actually are the only Windows NT drivers with NV1 support), and reviews starting to drop on websites like Anandtech in the first half of September 1997. There are no known drivers for the audio functionality in the revision A of the RIVA 128 available, so anyone wishing to use it would have to write custom drivers to actually use it.
The initial revision of the architecture appears to have been completed in January 1997. Then, aided by hardware simulation software (unlike the NV0, an actual hardware simulation) purchased from another almost-bankrupt company, an exhaustive test set was completed. The first bug presented itself almost immediately when the "C" character in the MS-DOS codepage appeared incorrectly, Windows took 15 minutes to boot, and moving the mouse cursor required a map of the screen so you didn't lose it by moving too far, but ultimately the testing was completed. However, NVIDIA didn't have the money to respin the silicon for a second stepping if problems appeared, so it had to work at least reasonably well in the first stepping. Luckily for NVIDIA, when the card came back it worked well enough to be sold to NVIDIA's board partners (almost certainly due to that hardware simulation package they had), and the company survived - most accounts indicate it was only three or four weeks away from bankruptcy; when 3dfx saw the RIVA 128 at its reveal at the CGDC 1997 conference, the response of one of the founders was "You guys are still around?" - NVIDIA's financial problems were so severe that 3dfx almost *bought* NVIDIA, effectively for the purpose of killing the company as a theoretical competitor, but refused, as they assumed they would be bankrupt within months anyway (a disastrous decision). However, this revision of the chip - revision A - was not the revision that NVIDIA actually commercialised; SGS-Thompson dropped the plans for the STG-3000 at some point, which led NVIDIA, now flush with cash (revenue in the first nine months of 1997 was only $5.5 million, but skyrocketed up to $23.5 million in the last three months - the first three month period of the RIVA 128's availability, owing to the numerous sales of RIVA 128 chips to add-in board partners), to create a new revision of the chip to remove the sound functionality (although some remnants of it were left after it was removed); some errata was also fixed and other minor adjustments made to the silicon - there are mentions of quality problems with early cards in a lawsuit filed against STB Systems (who were the first OEM partner for the RIVA 128), it is not clear if the problems were on STB or NVIDIA's end and respun the chip, with the revision B silicon being completed in October 1997 and presumably available a month or two later. It is most likely that some revision A cards were sold at retail, but based on the dates, these would have to be very early units, with the earliest NVIDIA RIVA 128 drivers that I have discovered (labelled as "Version 0.75") dated August 1997 (these also have NV1 support - and actually are the only Windows NT drivers with NV1 support), and reviews starting to drop on websites like Anandtech in the first half of September 1997. There are no known drivers for the audio functionality in the revision A of the RIVA 128 available, so anyone wishing to use it would have to write custom drivers to actually use it.
The card generally reviewed quite well at its launch and was considered as the fastest graphics card released in 1997, with raw speed, although not video quality, higher than the Voodoo1 - most likely, the lower quality of the NV3 architecture's graphics output owes much to the card's rushed development (due to NVIDIA's financial situation) leading to shortcuts being taken in the GPU design process in order to ship on time. For example, some of the Direct3D 5.0 blending modes are not supported, and per-polygon mipmapping, a graphical technique involving scaling down textures as you move away from an object in order to prevent shimmering, was used instead of the more accurate per pixel approach, causing seams between different mipmapping layers. The dithering quality and the quality of the Riva 128's bilinear texture filtering were often criticised. Furthermore, some games exhibited seams between polygons, and the drivers were generally very rough at launch, especially if the graphics card was an upgrade and previous drivers were not. While NVIDIA were able to fix many of the driver issues by the time of the version 3.xx drivers, which were released in 1998 and 1999, and even wrote a fairly decent OpenGL ICD, the standards for graphical quality had risen over time and what was considered "decent" in 1997 was considered to be "bad" and even "awful" by 1999. Nevertheless, Over a million units were sold within a few months and NVIDIA's immediate existence as a company was secured; an enhanced version (revision C, also called "NV3T"), branded as the RIVA 128 ZX, was released in March 1998 in order to compete with a hypothetically very fast and much-hyped, but not actually very good card, the Intel/Lockheed Martin i740 chip (the predecessor of the universally detested Intel iGPUs). As of 2024, Intel has finally managed to produce a graphics card people actually want to buy (and aren't forced to due to a lack of financial resources, as with their iGPUs), the mid-range Intel Arc B580, based on the "Battlemage" architecture, Intel's 16th-generation GPU architecture (or in Intel parlance, the 13th, because of great names such as "Generation 12.7"). Better late than never, I guess.
The card generally reviewed quite well at its launch and was considered as the fastest graphics card released in 1997, with raw speed, although not video quality, higher than the Voodoo1 - most likely, the lower quality of the NV3 architecture's graphics output owes much to the card's rushed development (due to NVIDIA's financial situation) leading to shortcuts being taken in the GPU design process in order to ship on time. For example, some of the Direct3D 5.0 blending modes are not supported, and per-polygon mipmapping, a graphical technique involving scaling down textures as you move away from an object in order to prevent shimmering, was used instead of the more accurate per pixel approach, causing seams between different mipmapping layers. The dithering quality and the quality of the RIVA 128's bilinear texture filtering were often criticised. Furthermore, some games exhibited seams between polygons, and the drivers were generally very rough at launch, especially if the graphics card was an upgrade and previous drivers were not. While NVIDIA were able to fix many of the driver issues by the time of the version 3.xx drivers, which were released in 1998 and 1999, and even wrote a fairly decent OpenGL ICD, the standards for graphical quality had risen over time and what was considered "decent" in 1997 was considered to be "bad" and even "awful" by 1999. Nevertheless, Over a million units were sold within a few months and NVIDIA's immediate existence as a company was secured; an enhanced version (revision C, also called "NV3T"), branded as the RIVA 128 ZX, was released in March 1998 in order to compete with a hypothetically very fast and much-hyped, but not actually very good card, the Intel/Lockheed Martin i740 chip (the predecessor of the universally detested Intel iGPUs). As of 2024, Intel has finally managed to produce a graphics card people actually want to buy (and aren't forced to due to a lack of financial resources, as with their iGPUs), the mid-range Intel Arc B580, based on the "Battlemage" architecture, Intel's 16th-generation GPU architecture (or in Intel parlance, the 13th, because of great names such as "Generation 12.7"). Better late than never, I guess.
After all of this history and exposition, we are finally ready to actually explore the GPU behind the RIVA 128 series. I refer to it as NV3, as NV3 is the architecture behind it (and this can be used to refer to all cards manufactured using it, including STG-3000, if a prototype form of one does ever turn out to exist, RIVA 128, and RIVA 128 ZX). Note that the architecture of the 32-bit Weitek core will not be discussed in length here unless it is absolutely required. It's pretty much a standard SVGA, and really is not that interesting compared to the main card. It's not even substantially integrated with the main GPU, although there are a few areas in the design that allow the main GPU to write directly to the Weitek's registers.
---
## Architectural Overview
The NV3 is the third-generation of the NV architecture designed by NVIDIA in 1997, commercialised as the RIVA 128 (or RIVA 128 ZX). It implements a "partially" (by modern standards; by the standards of 1997 it was one of the more fully featured and complete accelerators available) hardware-accelerated, fixed-function 2D and 3D render path, primarily aimed at desktop software and video games. It can use the legacy PCI 2.1 bus, or the then-brand new AGP 1X bus, with the RIVA 128 ZX improving this further in order to use AGP 2X. The primary goal of the architecture was to be cheap to manufacture, be completed quickly (due to the very bad financial condition of NVIDIA at that time), and to beat the 3dfx Voodoo1 in raw pixel pushing performance. It generally achieved these goals, with some caveats, with a cost of $15 per chip in bulk, a design period of somewhere around nine months (excluding Revision B), and mostly better than Voodoo performance (although the Glide API did help 3dfx out); the NVIDIA architecture is much more efficient at drawing small triangles, but this rapidly drops off to a slightly-better-than-the-Voodoo raw performance (which probably ends up being less efficient overall due to the Riva's higher clockspeed) when drawing larger triangles. While the focus of study has been the Revision B card, efforts have been made to understand both the A and C revisions. To change revision, the NV_PFB_BOOT_0 register in MMIO space (at offset `0x100000`) must return the following values:
The NV3 is the third-generation of the NV architecture designed by NVIDIA in 1997, commercialised as the RIVA 128 (or RIVA 128 ZX). It implements a "partially" (by modern standards; by the standards of 1997 it was one of the more fully featured and complete accelerators available) hardware-accelerated, fixed-function 2D and 3D render path, primarily aimed at desktop software and video games. It can use the legacy PCI 2.1 bus, or the then-brand new AGP 1X bus, with the RIVA 128 ZX improving this further in order to use AGP 2X. The primary goal of the architecture was to be cheap to manufacture, be completed quickly (due to the very bad financial condition of NVIDIA at that time), and to beat the 3dfx Voodoo1 in raw pixel pushing performance. It generally achieved these goals, with some caveats, with a cost of $15 per chip in bulk, a design period of somewhere around nine months (excluding Revision B), and mostly better than Voodoo performance (although the Glide API did help 3dfx out); the NVIDIA architecture is much more efficient at drawing small triangles, but this rapidly drops off to a slightly-better-than-the-Voodoo raw performance (which probably ends up being less efficient overall due to the RIVA's higher clockspeed) when drawing larger triangles. While the focus of study has been the Revision B card, efforts have been made to understand both the A and C revisions. To change revision, the NV_PFB_BOOT_0 register in MMIO space (at offset `0x100000`) must return the following values:
| Revision | NV_PFB_BOOT_0 value |
| -------- | ------------------- |
@@ -82,9 +88,9 @@ Furthermore, the PCI configuration space Revision ID register must return the fo
| B | `0x10` |
| C | `0x20` |
There is a common misconception that the PCI ID is different on RIVA 128 ZX chips. This is partially true, but misleading. The standard NV3 architecture uses a PCI vendor ID of `0x12D2` (labelled as "SGS/Thomson-NVIDIA joint venture" - not the later NVIDIA vendor ID!) and `0x0018` for the device ID. If ACPI is enabled on a Riva 128 ZX, the ID changes to `0x0019`. However, the presence of a 0x0019 device ID is not sufficient: the revision must be C, or 0x20, for a Riva 128 ZX to be detected and the specific Device ID does not matter. This has been verified by reading both reverse engineered VBIOS and driver code. The device ID can be either value, the best way to check is to use the revision ID encoded into the board at manufacturing time (either using the NV_PFB_BOOT_0 register, or the PCI configuration space registers).
There is a common misconception that the PCI ID is different on RIVA 128 ZX chips. This is partially true, but misleading. The standard NV3 architecture uses a PCI vendor ID of `0x12D2` (labelled as "SGS/Thomson-NVIDIA joint venture" - not the later NVIDIA vendor ID!) and `0x0018` for the device ID. If ACPI is enabled on a RIVA 128 ZX, the ID changes to `0x0019`. However, the presence of a 0x0019 device ID is not sufficient: the revision must be C, or 0x20, for a RIVA 128 ZX to be detected and the specific Device ID does not matter. This has been verified by reading both reverse engineered VBIOS and driver code. The device ID can be either value, the best way to check is to use the revision ID encoded into the board at manufacturing time (either using the NV_PFB_BOOT_0 register, or the PCI configuration space registers).
The NV3 architecture incorporates accelerated triangle setup, which the Voodoo Graphics only implements around two thirds of, the aforementioned span and edge interpolation, texture mapping, blending, and final presentation. It does not accelerate the initial polygon transformation or lighting rendering phases. It is capable of rendering in 2D at a resolution of up to 1280x1024 (at least 1600x1200 in ZX, not sure what?) and 32-bit colour. 3D rendering is only possible in 16-bit colour, and at 960x720 or lower in a 4MB card due to a lack of VRAM. While 2MB and even 1MB cards were planned, they were seemingly never released. The level of pain of using them can only be imagined; there were also low-end cards released that only used a 64-bit bus - handled using a manufacture-time configuration mechanism, sometimes exposed via DIP switches, known as the straps, which will be explained in Part 2. The RIVA 128 ZX, to compete with the i740, had, among other changes that will be described later, an increased amount of VRAM (8 Megabytes) that also allowed it to perform 3D at higher resolutions of up to 1280x1024. The design of the Riva is very complex compared to other contemporaneous video cards; I am not sure why such a complex design was used, but it was inherited from the NV1 - the only real reason I can think of is that the overengineered design is intended to be future-proof and easy to enhance without requiring complete rewiring of the silicon, as many other companies had to do. EDID is supported for monitor identification via an entirely software-programmed I2C bus. The GPU is split into a large number (around a dozen) of subsystems (or really "functional blocks" since they are implemented as hardware), each one of which starts with the letter "P" for some reason; some examples of subsystems are `PGRAPH`, `PTIMER`, `PFIFO`, `PRAMDAC` and `PBUS` - presumably, a subsystem has a 1:1 mapping with a functional block on the GPU die, since the registers are named after the subsystem that they are a part of. There are several hundred different registers across the entire graphics card, so things are necessarily simplified for brevity, at least in Part 1. To be honest, the architecture of this graphics card is too complicated to show in a diagram without simplifying things so much as to be effectively pointless or complicating it to the point of not being useful (I tried!), so a diagram has not been provided.
The NV3 architecture incorporates accelerated triangle setup, which the Voodoo Graphics only implements around two thirds of, the aforementioned span and edge interpolation, texture mapping, blending, and final presentation. It does not accelerate the initial polygon transformation or lighting rendering phases. It is capable of rendering in 2D at a resolution of up to 1280x1024 (at least 1600x1200 in ZX, not sure what?) and 32-bit colour. 3D rendering is only possible in 16-bit colour, and at 960x720 or lower in a 4MB card due to a lack of VRAM. While 2MB and even 1MB cards were planned, they were seemingly never released. The level of pain of using them can only be imagined; there were also low-end cards released that only used a 64-bit bus - handled using a manufacture-time configuration mechanism, sometimes exposed via DIP switches, known as the straps, which will be explained in Part 2. The RIVA 128 ZX, to compete with the i740, had, among other changes that will be described later, an increased amount of VRAM (8 Megabytes) that also allowed it to perform 3D at higher resolutions of up to 1280x1024. The design of the RIVA is very complex compared to other contemporaneous video cards; I am not sure why such a complex design was used, but it was inherited from the NV1 - the only real reason I can think of is that the overengineered design is intended to be future-proof and easy to enhance without requiring complete rewiring of the silicon, as many other companies had to do. EDID is supported for monitor identification via an entirely software-programmed I2C bus. The GPU is split into a large number (around a dozen) of subsystems (or really "functional blocks" since they are implemented as hardware), each one of which starts with the letter "P" for some reason; some examples of subsystems are `PGRAPH`, `PTIMER`, `PFIFO`, `PRAMDAC` and `PBUS` - presumably, a subsystem has a 1:1 mapping with a functional block on the GPU die, since the registers are named after the subsystem that they are a part of. There are several hundred different registers across the entire graphics card, so things are necessarily simplified for brevity, at least in Part 1. To be honest, the architecture of this graphics card is too complicated to show in a diagram without simplifying things so much as to be effectively pointless or complicating it to the point of not being useful (I tried!), so a diagram has not been provided.
### Fundamental Concept: The Scene Graph
In order to begin to understand the NVIDIA NV3 architecture, you have to understand the fundamental concept of a scene graph. Although the architecture does not strictly implement a scene graph, the concept is still good to understand how graphical objects are represented by the GPU. A scene graph is a description of a form of tree where the nodes of the tree are graphical objects. The properties of a parent object cascade down to its children; this is how almost all modern game engines represent 3D space (Unity, Unreal, Godot...); a very easy way to understand how a scene graph works is, although with the caveat that characteristics of parent nodes do not automatically cascade down to a child (although they can), is - I am not joking - install Roblox Studio, place some objects into the scene, and save the file as an "RBXLX" file (it has to be RBXLX, as by default since 2013 the engine exports a binary format, although the structure is similar). Then, open it in a text editor of your choice. You will see an XML representation of the scene you have created represented by a scene graph.
@@ -103,7 +109,7 @@ Generally, most manufacturers set the memory clock at around 100 megahertz and t
### Memory Mapping
Before we can discuss any part of how the RIVA 128 works, we must explain the memory architecture, since this is a fundamental requirement to even access the graphics card's registers in the first place. NVIDIA picked a fairly strange memory mapping architecture, at least for cards of that time. The exact setup of the memory mapping changed numerous times as NVIDIA's architecture evolved, so only the NV3-based GPUs will be analysed.
The RIVA 128 was designed during the era of full-sized, old school PCI, but also needed to be compatible with the then-brand new (the RIVA 128 released the very same month as the first AGP 1X, 1.0-based motherboards) Accelerated Graphics Port (AGP), which was a modified high-transfer speed variant of PCI specifically intended for graphics; all GPUs released between 1997 and 2004, and some low-end GPUs released up to 2008 (the Radeon HD 5000 series of 2009 was intended to have AGP support, and this even made it into the drivers, but the SKUs never launched) used the AGP (or AGP Pro) bus in its various forms. Note that motherboard support did not last that long - a HP computer using an ASUS motherboard I disassembled recently, manufactured in early 2006 and with a motherboard from 2005, exclusively had PCIe. The memory mapping is split into three primary components, all of which are exposed via memory-mapped I/O (there is no facility for any other I/O form, except the Weitek core's registers for VESA compatibility); specifically, they are exposed using the Base Address Registers (BAR) in PCI/AGP configuration space. The Riva 128 only uses two of these - BAR0 and BAR1; both of these only have their highest byte wired up to anything at all within the GPU and therefore they must be mapped at a 16 megabyte boundary, with BAR0 holding the main GPU registers and BAR1 holding the `DFB` and `RAMIN` areas (which really refer to overlapping areas of memory); these will be delineated later.
The RIVA 128 was designed during the era of full-sized, old school PCI, but also needed to be compatible with the then-brand new (the RIVA 128 released the very same month as the first AGP 1X, 1.0-based motherboards) Accelerated Graphics Port (AGP), which was a modified high-transfer speed variant of PCI specifically intended for graphics; all GPUs released between 1997 and 2004, and some low-end GPUs released up to 2008 (the Radeon HD 5000 series of 2009 was intended to have AGP support, and this even made it into the drivers, but the SKUs never launched) used the AGP (or AGP Pro) bus in its various forms. Note that motherboard support did not last that long - a HP computer using an ASUS motherboard I disassembled recently, manufactured in early 2006 and with a motherboard from 2005, exclusively had PCIe. The memory mapping is split into three primary components, all of which are exposed via memory-mapped I/O (there is no facility for any other I/O form, except the Weitek core's registers for VESA compatibility); specifically, they are exposed using the Base Address Registers (BAR) in PCI/AGP configuration space. The RIVA 128 only uses two of these - BAR0 and BAR1; both of these only have their highest byte wired up to anything at all within the GPU and therefore they must be mapped at a 16 megabyte boundary, with BAR0 holding the main GPU registers and BAR1 holding the `DFB` and `RAMIN` areas (which really refer to overlapping areas of memory); these will be delineated later.
#### MMIO
This is the primary area of memory mapping, and is set up as Base Address Register 0 in the PCI configuration registers. This is how you speak to the GPU - sixteen megabytes (!) of MMIO, mapped at whatever the operating system decides to map it at during initialisation (my test system under Windows 2000 tends to map it at `0xdc000000`, but this is HIGHLY variable and dependent on the system configuration). This MMIO area has numerous functional subsystems of the GPU mapped into it and a table of where, and a brief description of what, these subsystems actually are is mapped below (note some parts overlap, and what each graphics object does will be introduced later):
@@ -303,5 +309,7 @@ More research is ongoing. It seems most notifiers are generated by the driver in
#### PRAMDAC
The final part of the GPU that handles the intricacies of generating a video signal, sets the resolution, and holds a color lookup table for the various modes. I haven't looked into this part as much, so expect more information in an update on this part or in future parts of this series. It's not really super critical to emulate anyway, other than the fact it actually controls the aforementioned clocks - but the actual video-generation part mostly does not apply to emulation as we don't need to generate an analog video signal.
#### Next Part
---
## Next Part
The next part will dive into how NVIDIA's drivers work and how they make this ridiculously complicated mess of an architecture transform itself into a GPU that allows you to run games you may actually want to play. Stay tuned!