Vérité Console

At a glance

Graphics chip

V2200

Rendition Vérité, 1997

Graphics core

55 MHz

As Rendition's drivers set it

Video memory clock

110 MHz

Twice the core clock

Video memory

4–8 MB

SGRAM, from the donor card

Bus

32-bit PCI

33 MHz, between CPU and graphics

Operating systems

0

Bare metal, from power-on

A graphics chip that lost, given a second life

In the mid-'90s a Mountain View startup called Rendition made the Vérité, one of the first chips built to make 3D games look good on a PC. Its first version, the V1000, reached stores in 1996, and id Software made a special version of Quake just for it, called vQuake, in time for Christmas. Next to the blocky software-drawn graphics most PCs had, it had smoothly filtered textures and anti-aliased edges.

Then 3dfx's Voodoo Graphics arrived and drew pixels about twice as fast. Rendition answered in 1997 with the V2100 and V2200, nearly doubling the V1000's speed, sold on cards like the Hercules Thriller 3D. It wasn't enough. Micron bought the company in 1998, and the Vérité line ended there.

Meanwhile, the PlayStation, the Saturn and the Nintendo 64 were showing what dedicated 3D hardware could do in a box under the TV. Consoles are where an unusual chip can shine: the hardware never changes, and programmers write straight to it instead of going through generic drivers. So I'm asking: what if someone had built a console around the Vérité? Then I'm building that console, from real parts of the era.

• 1993Rendition is founded in Mountain View, California.
• 1996V1000 cards ship. vQuake comes out for Christmas. The Nintendo 64 launches.
• 1997The V2100 and V2200 arrive. Hercules announces the Thriller 3D in August, with 4 or 8 MB of memory.
• 1998Micron buys Rendition. The silicon dies here.
• 2026NetBSD adds a new driver for the V2100 and V2200 in July, almost 30 years later.
• Nov 2026The Vérité Console project starts.

It was a programmable graphics chip, years early

Most 3D chips of 1996 and 1997 were fixed-function: hardwired circuits that do one job, drawing textured triangles, the same way every time. The Vérité put a small general-purpose processor, a RISC core, in front of its drawing hardware. The computer never draws anything itself. It sends the chip a stream of 32-bit command words, and a program running on the chip's own processor, called microcode, decides what each command means and drives the drawing engines.

Every modern graphics chip works roughly this way: games ship small programs, called shaders, that run on the GPU. In 1997 it was unusual, and on PCs it was mostly a handicap. The extra processor added overhead, and games only ever ran Rendition's own microcode, through generic Windows drivers.

A console changes that. There's no driver layer and no other software to stay compatible with, so I can write my own microcode, shaped for exactly the games this machine runs. That's the part nobody got to try back then.

What makes it possible now

The manual

The instruction set is documentedRendition's 69-page V2200 technical specification from January 1998 describes every instruction. That includes tri, which starts drawing a whole triangle, with depth, texture coordinates and shading, in a single instruction.

Drivers

Working open-source drivers surviveThe long-running X.org driver, and NetBSD's new veritefb, which even has an experimental way to run your own 3D microcode. Between them, they show the exact order of steps that wakes the chip up safely.

Reference code

Rendition's own microcode still existsTheir 2D microcode for the V2200 ships with the X.org driver. Once I could decode it, I could read how the people who designed the chip actually programmed it.

A graphics chip you can reprogram per game

The Vérité wasn't completely alone. The Nintendo 64's graphics coprocessor also ran swappable microcode, and Chromatic Research's Mpact media chips were programmable too. But among PC 3D cards it was rare, and the N64 shows the idea works best exactly where this project puts it: in a console.

One catch shapes everything below. The chip's processor is slow next to its drawing hardware. At 55 MHz, drawing 640×480 thirty times a second leaves it only about six clock cycles per pixel, so running a program for every pixel only works on small areas. Where it shines is work done once per command, per triangle or per row of pixels, and building data in video memory so the main processor and the PCI bus don't have to.

• Every game brings its own GPUEach game, or even each level, loads its own microcode. A platformer gets a sprite-and-tile engine, a racer gets a terrain renderer. The console has no fixed graphics API at all, which is the most alternate-history thing about it.
• A sprite chip and a 3D chip in oneMicrocode that behaves like a classic 2D video chip. The CPU sends scroll positions and tile numbers, and the Vérité draws whole layers, including rotating, tilted "Mode 7"-style floors using its triangle engine, mixed with 3D models on top. This is the one I'd like to make the console's signature.
• Particles that live on the chipThe CPU sends one command, "500 sparks here", and the microcode keeps the particles in video memory, moves them every frame and draws them. On PCs that didn't become normal until programmable shaders in the mid-2000s.
• Textures that draw themselvesFire, plasma, rippling water and lava computed by the chip straight into small textures, such as 64×64. Animated surfaces then cost no CPU time and no bus traffic.
• Drawing each pixel exactly onceThe microcode sorts spans of pixels row by row, like Quake's software renderer did, so nothing gets drawn and then covered up. The drawing speed saved can go into more polygons.
• A chip that reports on itselfThe microcode counts the cycles each command takes and draws its own performance overlay. It can also record the commands it receives into video memory, for instant replays, ghost racers or exact bug reports. I'll want this during bring-up anyway.

These are ideas, not features yet. Each one is a small program that grows out of the four-instruction echo test below, so they can be tried one at a time once the chip is running.

From the processor to the screen

Here's the path a frame takes in the finished console. The main processor and the graphics chip work side by side: while the Vérité draws one frame, the CPU is already working out the next.

1. Main processor Pentium-class CPU Runs the game: input, physics, and working out where every triangle goes. It writes the drawing commands into a list in main memory.
2. 32-bit PCI, 33 MHz The chip fetches its own work The Vérité pulls the command list straight out of main memory by itself (bus-master DMA), so the CPU doesn't have to copy it over word by word.
3. Inside the V2200
   1. Input FIFO A 32-word queue in, an 8-word queue out Commands wait here until the chip's processor is ready. If the queue fills up, the sender simply waits.
   2. RISC core, running microcode Reads each command and decides what to do This is where my own code runs. The core is big-endian, the opposite byte order from the x86 CPU, so the chip has byte-swapping windows to translate between the two.
   3. Triangle, pixel and fill engines Fixed hardware does the heavy lifting The triangle engine takes about 4 clock cycles to start a triangle, then roughly 1 per line and 1 per pixel, filling in depth, texture and shading as it goes.
   4. 4–8 MB video memory Everything the chip touches lives here The microcode itself, the textures, the depth buffer, and the picture being drawn.
4. Display output From RAM to the CRT The display controller reads the finished frame out of video memory and turns it into a video signal.

Four instructions that prove it's alive

Before drawing anything, I need to prove the whole path works: the CPU loads my code into the chip, the chip runs it, commands go in, and answers come back. So the first microcode is an echo. It takes each number the CPU sends, adds one, and sends it back.

; echo.s: the first Vérité Console microcode
    .org 0x8000           ; free slot in video memory
    .entry start

start:
    add a0, fifo, zero    ; take a word from the CPU (waits if none)
    add a0, a0, #1        ; add one
    b   start             ; loop back...
    add fifo, a0, zero    ; ...but this runs first: send the answer

The odd-looking last line is a real quirk of the chip. Like many RISC processors of the time, the instruction right after a jump, called the delay slot, always runs before the jump takes effect. So the line that sends the answer back sits after the jump, and still runs every time.

The boot code around it finds the chip on the PCI bus, resets it, and holds its processor still. It then loads the echo program and reads it back twice: once from the CPU's side, and once by making the chip's own processor read it, which proves the byte order is right. Only then does it start the chip, send five numbers, and check that each comes back one higher.

The one hard rule: if any check fails, never start the chip's processor. Code that wasn't verified could rewrite the chip's memory controller settings, and a soft reset doesn't put those back.

The toolbox I built first

Disassembler

Turns the chip's machine code back into readable instructionsTested on Rendition's own 2D microcode: of its 4,683 words, only 6 aren't instructions, all of them in a data table, and all 483 jump targets land inside the program. That's how I know the decoding is right.

Assembler

Turns my instructions into the chip's machine codeI couldn't find a public assembler for this chip, so I wrote one. Both of Rendition's microcode programs go through disassemble, then reassemble, and come out byte-for-byte identical.

Firmware

Bare-metal C and x86 assemblyIt switches the CPU into 32-bit protected mode, scans every PCI device, and reports over a serial cable and on screen. It's built with Zig's bundled C compiler and tested in the QEMU emulator. QEMU can't pretend to be a Vérité, though, so the chip part waits for real hardware.

Board design

KiCad, driven from scriptsPin maps for the bus wiring are generated by code, not drawn by hand, so a typo can't slip into one of 120 connections.

Dark Forces, drawn the way it was drawn in 1995

The first big game for the console is LucasArts' Star Wars: Dark Forces from 1995, through The Force Engine, an open-source rebuild of the game's engine. You bring your own copy of the game's files; the port only replaces the engine. It's a non-commercial showcase.

Dark Forces didn't draw the way 3D cards do. It painted walls as vertical strips and floors as horizontal rows. It looked through doorways and windows so that every pixel on screen was painted exactly once. And it used 256 colors, darkened through a table of 32 light levels the artists made by hand. A 1997 3D card, a Voodoo or a Vérité, would redraw all that as triangles in 16-bit color and approximate the lighting. This port goes the other way: it bends the Vérité into drawing the way Dark Forces draws, at 640×480 instead of the original 320×200.

Where the port is

• DoneRead through The Force Engine's code and wrote up what porting it takes.
• DoneDesigned the Vérité renderer described below.
• DoneSet up the port's own code repository. It's kept apart from the console's code because the engine is under the GPL.
• NextRun the game on the console's CPU in an emulator, drawn by the original software renderer, with the Vérité only putting the finished picture on screen. That's scaffolding to get the game running, not the port.
• ThenThree tests on the real card that decide whether the exact 256-color mode works: colors passing through the chip untouched, one wall strip matched pixel for pixel against the original renderer, and how fast the chip builds lit textures.
• LaterThe full renderer, then the filtered Smooth mode, then the menus, cutscenes and extras.

How to read the tags

• Vérité quirkA feature of this chip that the port leans on, often one Rendition built for something else.
• Beats the VoodooSomething 3dfx's Voodoo Graphics, the card to beat in 1997, can't match.
• Turned aroundA spot where a stock V2200, running Rendition's own drivers, lost to the Voodoo or only tied it. The port flips it.
• Ahead as stock tooThe stock card already beat the Voodoo here.

Scoreboard against the Voodoo

Where each trick goes

• Vérité quirkBeats the VoodooTurned around 256 colors, straight through The Vérité has a little-used 8-bit grayscale texture mode that passes each byte through untouched. Feed it Dark Forces' 256-color art and it writes out the same color numbers, which the display then shows through the game's own palette. The stock V2200 had no 256-color textures at all, so in 1997 this was a clear loss to the Voodoo. But the Voodoo only draws in 16-bit color, so it can't show the art as it is either. This is the first thing to test when the card arrives.
• Vérité quirkBeats the VoodooTurned around The original lighting, exactly Along one wall strip or one floor row, the light level in Dark Forces doesn't change. So the chip's own processor can darken each texture once for each light level it's needed at, keep the result in video memory and reuse it, instead of lighting every pixel as it's drawn. Shaded 3D objects use the texture unit as a lookup table: one color's 32 light steps laid out as a tiny texture. Every other 3D card of the time, the stock Vérité included, could only blend toward the lighting.
• Vérité quirkBeats the VoodooTurned around Screen flashes the DOS way When you take damage the screen flashes, and night-vision goggles turn it green. DOS did that by changing the palette, and so can the console, because the chip's processor can rewrite the palette itself. A 3D card drawing in 16-bit color, Voodoo or stock V2200, has to paint a tinted layer over the whole picture instead.
• Vérité quirkBeats the Voodoo Walls drawn sideways, one command each The triangle engine has a switch, meant for drawing steep lines, that makes it fill a shape column by column instead of row by row. That's how Dark Forces paints walls, so a whole stretch of wall at one light level becomes a single command and the chip works out the rest. The main processor keeps Dark Forces' own code for working out what's visible, stops where it used to paint pixels, and leaves short commands in memory for the Vérité to fetch by itself. On a Voodoo Graphics, the main processor has to set up every triangle before the card can draw it.
• Vérité quirk Every pixel drawn once Because Dark Forces never paints a pixel twice, the walls and floors don't need the usual depth test. The chip can write depth without reading it first, which halves that memory traffic, and enemies and objects still test against what was written. Smaller tricks ride along: color 0 is see-through for sprites and signs, and textures are read in the column order the game stores them, with no reshuffling.
• Vérité quirkBeats the VoodooAhead as stock too Menus and cutscenes get their own chip program When you leave a mission, the chip swaps in a second microcode built for Dark Forces' 2D menus and animated cutscenes. The Voodoo Graphics has no 2D at all: it sits beside an ordinary graphics card and switches over for 3D.
• Vérité quirk Extras, off by default Hit detection to the pixel: when you fire, the chip invisibly redraws each enemy at the crosshair and reports whether the shot hit a solid part of it in front of the wall. Rendition built this in as "collision detection"; the original game uses rough cylinders. Stereo 3D: the display can alternate two pictures every refresh, made for 1990s shutter glasses. And a performance overlay, drawn by the chip from its own cycle counter.
• Vérité quirk Sound on the graphics chip The Vérité has a small side bus for extra chips on the board, with exactly the connections a Yamaha OPL3, the music chip of 1990s Sound Blasters, needs. Put one there and Dark Forces' music plays on real FM hardware with no separate sound card. It's a board decision still to make.

Where the Voodoo still wins: raw drawing speed. The Voodoo Graphics and the V2200 both draw about one pixel per clock, at 50 and 55 MHz, and the 1998 Voodoo2 has two texture units. The port doesn't try to win that race. Drawing each pixel once at 640×480, the estimate is about 11 ms a frame, inside a 60 fps budget. And in the exact 256-color mode, 3D objects that are both textured and smoothly shaded get one light level per polygon, the design's one approximation. There's also a Smooth mode with filtered textures in 16-bit color, close to what a Voodoo looks like, to show the chip can do both.

Three boards, each riskier than the last

The finished console is one custom circuit board with everything on it. Getting there in one jump would mean debugging a new board, a transplanted chip and brand-new code all at once. That's a recipe for a $500 brick. So it happens in three steps, each one proving something before the next one depends on it.

1 · Adapter

A normal graphics card on the console's CPUThe CPU is a PC/104-Plus module: a coaster-sized industrial computer that stacks onto other boards through a 120-pin PCI connector. My adapter board turns that connector into a standard PCI slot, so an untouched V2200 card can plug in. It's a 4-layer board with every signal under 25 mm long, and nothing gets desoldered. Being designed now.

2 · Carrier

The chip moves onto my boardThe V2200 and its memory come off the donor card and onto a board of mine, with the CPU module plugged on top. Before desoldering, I'll read the chip's reset straps: resistors that tell it, at power-on, what memory it has and how fast to run.

3 · Console

One board with everythingProcessor, memory and Vérité together, like a real console motherboard. The front-runners are the Vortex86, which puts the CPU, memory controller and PCI on one chip, and AMD's Geode GX1, from 1997–98. The final pick is still open.

Where it's at

It's early. Most of the work so far is groundwork: the code and tools needed before the hardware shows up.

• DoneTracked down the chip's original 1998 technical manual, Rendition's 3D programming guide, and both open-source drivers.
• DoneWrote the code that starts the machine and looks for the graphics chip. The chip identifies itself with the number 1163:2000: 1163 is Rendition, 2000 is the V2100/V2200.
• DoneBuilt an assembler and disassembler for the chip's own instruction set.
• DoneWrote the echo test: send the chip a number and wait for it to send back one more.
• DoneWorked out how the chip's clocks are set, and found that the X.org driver's comments label its own clock speeds wrong.
• DonePicked the first big port, Dark Forces, and designed how the Vérité will draw it. See above.
• DoneOrdered a used V2200 card with 8 MB of memory. It's on its way from Australia.
• UnderwayDesigning the adapter board so a regular V2200 card can be tested before pulling any chips off it.
• NextGet the real hardware on my desk and see the chip answer.
• ThenShow a picture on screen, then draw the first triangle with my own microcode.
• LaterThe carrier board, then the final single board, then games.

None of the chip code has run on a real Vérité yet. It all follows what the manual and the two drivers do, but the first real test is the day the parts arrive.

What could go wrong

• Rendition's 3D microcode is a black boxThe microcode that PC games used for 3D still exists in old drivers, but how to talk to it was never documented. That's a big reason to write my own instead.
• Transplanting a chipDesoldering a fine-pitch chip and its memory from a card that's nearly 30 years old, without damaging either, and wiring them back up correctly.
• Booting without its ROMOn a graphics card, the chip starts up by running code from its own ROM chip. On my board, either that ROM comes along, or the CPU has to hold the chip still and load code into it first. It's not yet known whether the chip is happy with no ROM at all.
• ClocksOne clock generator feeds both the core and the memory, and the memory must always run at least as fast as the core. Within the generator's limits the core could go from 55 MHz to about 83 MHz. Whether the silicon can keep up is another question.
• Fast signals on homemade boardsPCI is forgiving at 33 MHz, but only if the wiring is short and has a solid ground layer under it. Every board in this project is designed around that.

Because it's a great puzzle

It's part nostalgia for '90s tech, part puzzle, and part the fun of making something that only existed in an alternate timeline. It's also a chance to find out what a forgotten, ahead-of-its-time chip could really do when someone writes code just for it.

Further reading

• Rendition, Inc. on Wikipedia: the company's history.
• Vérité V1000 and V2x00 on vintage3d.org: architecture and benchmarks.
• vQuake by Fabien Sanglard: how Quake was ported to the V1000.
• xf86-video-rendition the X.org driver.
• NetBSD src, sys/dev/pci home of the veritefb driver.
• Microprocessor Report on the V1000 and V2x00 period write-ups of the architecture.
• The Rendition Vérité thread on Vogons, the retro PC forum.