A game console that could have existed in 1997 but never did. I'm building it for real, around a graphics chip that lost the PC wars, and I'm writing every line of code it runs.
Spec sheet
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
The what-if
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. No more Vérité chips come out.
2026NetBSD adds a new driver for the V2100 and V2200 in July, almost 30 years later.
Nov 2026The Vérité Console project starts.
Why this chip
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.
How it works
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.
Main processorPentium-class CPURuns the game: input, physics, and working out where every triangle goes. It writes the drawing commands into a list in main memory.
32-bit PCI, 33 MHzThe chip fetches its own workThe 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.
Inside the V2200
Input FIFOA 32-word queue in, an 8-word queue outCommands wait here until the chip's processor is ready. If the queue fills up, the sender simply waits.
RISC core, running microcodeReads each command and decides what to doThis 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.
Triangle, pixel and fill enginesFixed hardware does the heavy liftingThe 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–8 MB video memoryEverything the chip touches lives hereThe microcode itself, the textures, the depth buffer, and the picture being drawn.
Display outputFrom memory to the TVThe display controller reads the finished frame out of video memory and turns it into a video signal.
First contact
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.
Hardware
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. 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.
Progress
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.
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.
Hard parts
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.
Why
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.