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

Game media

Cartridge

A CompactFlash card in a shell

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 Rendition 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, which is what the simulator below is for.

Simulator

A pretend V2200 that runs on my PCIt runs the same chip programs the real card would: the processor, the triangle, pixel and fill engines, the command queues, the chip fetching its own work, and the screen timing. It saves what's in video memory as a picture. It runs about 3.4 million chip instructions a second, and Rendition's own 2D microcode runs on it start to finish without a single warning. It also flags code that breaks the chip's timing rules. It can't say how fast the real chip will be, or settle the places where the manual is vague: those are listed, to check on the card.

SDK

Games are ordinary C and C++ programsThere's still no operating system. Instead, a thin layer answers the requests a program would normally make to Linux, such as opening a file or reading the clock, so standard C and C++ libraries work unchanged on bare metal. Game files load into memory at boot as a read-only folder. It all targets the original Pentium, with no newer instructions, and a test suite boots it in an emulator to check it. Along the way it caught a maths library that, on the Pentium's floating-point unit, worked out floor(−2.5) as −2.5 and sin(10) as almost zero.

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.

Taking apart the Quake that Rendition built

vQuake is the best record of what this chip did for real. Rendition's engineers and id Software made it in 1996, with Michael Abrash's help, and kept updating it into 1997. Its source code was never released, so I took the program apart instead: the game itself, the Rendition library built into it, and the chip program it loads. Every command it sends was traced from the game's code to the routine on the chip that handles it, and two separate checking passes went over every finding.

• It drove the V2200 like the older V1000None of the V2200's new hardware gets used. Its triangle engine and fill engine sit idle. The chip program shipped for V2200 cards is the very same file as the V1000-era one, byte for byte.
• The main processor did the hard workThe CPU sorted every visible surface, row by row, so each pixel was drawn exactly once, then sent the chip each row segment as six numbers. The CPU also lit every surface. The chip filled in the rows and, in later versions, turned the 256-color surfaces into 16-bit color.
• So a faster chip barely helpedRendition's Stefan Podell explained it in 1997, with a test that threw away every drawing command, as if the chip and the bus were infinitely fast. His numbers are below.
• Moving lights were the expensive partI built id's open-source Quake renderer with counters added and ran its three demos at three resolutions. Turned into vQuake's commands, an average frame is about 39,000 to 82,000 words on the bus, depending on resolution. The biggest share, and nearly all of the worst frames, is relighting surfaces whenever a rocket, explosion or muzzle flash moves past them. The bus itself sat mostly idle: under 10% busy at the frame rates Podell measured. The real cost was the CPU work behind the commands.
• The fix was already in the chip programvQuake's microcode has a command for lighting surfaces on the chip. The game never sends it. Rendition tried chip-side lighting on the slower V1000 and found the CPU faster.

Frames per second in vHexen2, which uses the same engine, from Podell's 1997 post. A Pentium 166 MMX, except "faster CPU", a Pentium II 300. At low resolution the V2200 was slower than the V1000, and even an infinitely fast chip stopped at 56 fps on the Pentium 166. A faster CPU did more.

The lesson for the console: keep the main processor out of per-row and per-pixel work, and do the lighting on the chip. The Dark Forces design below already works that way. If Quake ever comes to the console, it would send the chip the level's geometry and lights, and let the chip build the rows and light the surfaces.

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.
• DoneThe engine runs on the console's own software in an emulator, with no operating system underneath, on a Pentium-class processor. It draws a test level of my own pixel for pixel the same as the PC build does. For now the emulator's plain screen stands in for the Vérité: that's scaffolding, not the port.
• DoneWrote the chip program that draws Dark Forces' walls, floors, sky, sprites and 3D objects in the exact 256-color mode, about 15 KB of microcode. It passes every one of its tests in the simulator, down to whole frames the chip fetches from memory by itself.
• UnderwayMaking it fast enough. In the simulator, a typical frame keeps the chip's processor busy for about 43 ms. The paper estimate was about 8 ms. That's roughly 23 frames a second instead of 60. Floors take almost half: the chip's 32-bit processor grinding through 64-bit maths for each run of floor. Four fixes are lined up, none tried yet.
• NextLoad the real game's files on the console build. So far it has only drawn the test level, because game files can't go in the repository.
• 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 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 paper estimate was about 11 ms a frame, inside a 60 fps budget, but the first simulator count puts the chip's own processor at about 43 ms, so 60 fps isn't won yet. 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.

Spend in stages, and stop anywhere

The dream 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 the rule is: buy hardware only when the next question can't be answered without it. Each stage proves something before the next one depends on it, and each one is a fine place to stop.

1 · Simulator

A pretend chip, for $0The simulator described above. It proves chip programs and the code that drives them, but not speed, exact pixels or anything electrical. Working now.

2 · Desktop PC

The real card in an ordinary PCThe V2200 card on its way goes into a desktop with an Intel DX58SO motherboard, which still has one old-style PCI slot. Nearly all the graphics work happens here: waking the chip, my own triangle microcode, screen modes, real speed measurements and the game ports. The PC has no serial port, so a plug-in serial card carries the debug log.

3 · Console CPU

The same card on the console's own processorThe console's 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 the untouched V2200 card can plug in. It's a 4-layer board with every signal under 25 mm long. In software terms this is the finished console, with honest performance. The adapter is being designed now.

4 · Chip-down

The chip moves onto my own board (optional)Only needed for the console's final physical form. The V2200 is a 27 mm ball-grid chip with its connections underneath, so it comes off a cheap AGP V2200 card bought as a donor, while the working PCI card is used to read the chip's reset straps: resistors that tell it, at power-on, what memory it has and how fast to run. A middle ground is a carrier board with a PCI slot that takes the stock card. The processor for a single-board console is still open.

What it might look like

Five case ideas, rendered in 3D as mood pieces. They aren't engineering yet: the real shell has to wait until the board's final shape is known. Every one of them takes cartridges.

Cartridges, not discs

A game cartridge is a CompactFlash card in a cartridge shell. Each game, and often each level, loads its own chip program and textures, so this console loads often, and flash has no seek time, where a 1997 CD drive makes every level change wait. The same card holds saves, so there's no separate memory card. Since ports never include game files, you copy your own copy of a game onto a card from a PC. And CompactFlash dates from 1994, so it's period-plausible.

Starting a game works like a real console: insert the cartridge, switch on, and the game starts. A small boot program of the console's own, the "console ROM", sets the chip's clocks, shows the logo, reads the cartridge's header to see what to load, and starts the game. With no cartridge in, it asks for one. One catch: the card can't be pulled out while the power is on, so the slot gets a lock tied to the power switch, as the Super Nintendo had.

Controllers the graphics chip reads itself

The V2200 has a little-used video input port, meant for 1997 video-capture add-on cards, that writes incoming bytes straight into video memory. The plan uses it for controllers. A small input board polls the pads in step with the screen's refresh and feeds their buttons through that port, so the chip's own processor sees them without the main CPU or the bus doing anything. One wire wakes both processors when a new sample lands. The chip could then move a cursor or turn the camera at the very last moment before a frame is shown. It's three custom boards: the pad, the input hub, and a port board with the four front sockets. For now this is a proposal: nothing is built.

Where it's at

Still before any hardware, but the software side has moved fast: there's now a simulated chip to run code on, a way to build games, and a first game's chip program. The build log below has the day-by-day story.

• 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, and wrote the echo test.
• DoneWorked out how the chip's clocks are set, and found that the X.org driver's comments label its own clock speeds wrong.
• DoneBuilt a simulator of the V2200, so chip programs can be tested before the card arrives. The echo test passes in it.
• DoneBuilt the SDK: games are ordinary C and C++ programs running with no operating system.
• DoneTook vQuake apart to see how Rendition used its own chip. See above.
• DoneDesigned Dark Forces' renderer, got the engine running on the console's software, and wrote its chip program. See above.
• DoneChose cartridges over discs, planned the controllers, and rendered five case ideas. See above.
• UnderwayA used V2200 card with 8 MB of memory is on its way from Australia. Meanwhile, the adapter board is being designed.
• NextPut the card in the desktop PC and see the chip answer the echo test.
• ThenShow a picture on screen, draw the first triangle with my own microcode, and run Dark Forces' three card tests.
• LaterThe console's own processor and the adapter board, then, maybe, a single board with everything on it.

None of the chip code has run on a real Vérité yet. It runs in my simulator, which follows the manual, but a simulator can be wrong exactly where the manual is vague. The first real test is the day the card arrives.

What happened, day by day

Newest first. The rest of the page always shows where things stand now. This is the diary of how they got there.

What could go wrong

• The chip's little processor may be the bottleneckThe drawing engines are fast; the processor that feeds them runs at 55 MHz. The first simulated Dark Forces frame needs about 43 ms of its time, five times the paper estimate. If the real chip agrees, most of the fix has to come from smarter chip code. Raising the clock, below, only helps as far as the silicon allows.
• Rendition's 3D microcode was a black boxHow to talk to the microcode PC games used for 3D was never documented. vQuake's is now decoded, and it only strengthens the case for writing my own: it left the V2200's best hardware unused.
• Transplanting a chipOnly if the project goes as far as stage 4. The V2200 is a ball-grid chip, with its connections in a grid underneath, so moving it from a card that's nearly 30 years old means reflowing it off without damage, then soldering it onto a new board where the joints can't be seen.
• 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.
• VQuake on the Vogons Wiki with Stefan Podell's 1997 post on why vQuake ran little faster on the V2x00.
• The Force Engine the open-source Dark Forces engine the port is built on.
• Rust-DOS an open-source DOS emulator that emulates the Vérité's processor.
• verite-gl an open-source OpenGL driver for Rendition's GL microcode, from the author of NetBSD's veritefb.