TiNDC developper have got started working on plumbing to make Gallium3D work with fixed pipeline card like older nVidia cards (i.e.: cards that have fixed effects like "lightmaps", "dot3 bump-mapping", etc. instead of the modern "write some code in Cg that will do whatever you want").

This could be the perfect target to make a newer Voodoo 3/4/5 driver for Linux. (It's been a long time since the dri freedesktop website mentions that the drivers should be rewritten to be Glide-independant).

Are there still any voodoo developper that might be up to the task ?
dborca ? SFFT ?
It would be cool if our voodoos could still survive as secondary displays on our linux box a couple of years more... (instead of becoming useless junks once all distributions finish transitioning to DRI2 + Gallium3D)

After some testing I can say that :
OpenGL 3D acceleration is working nice again in latest versions of Xorg 7.2 and Mesa, as long as you provide a Glide3x library (as discussed elsewhere).
Also a couple of extensions are supported like GLX_EXT_texture_from_pixmap (necessary for compositing = drawing windows not onto screen, but into buffers and then using those buffers as texture inside compiz).

But ! This is not sufficient !
- Currently 3DFx drivers only supports power-of-two texture sizes (256, 1024 or 2048 pixel wide texture, for exemple, but nothing in between). This is a problem for compiz, because it uses the windows' buffers as texture for compositing and those windows could be any size, not only powers of two. Also, I currently don't remember if it's a hardware limitation (VSA-100 can only do power-of-two textures), Glide limitation (Glide is partially used as a backend for Mesa3D on Voodoo) or if the openGL driver is only too old (quite possible that everything is ready for arbitrarily-sized textures but wasn't implemented yet).

Also other non-critical obstacles :
- VSA-100 can't do AGP texturing, i.e.: It can't autonomously pull textures from main memory. Thus buffers with windows content have to be manually loaded into GPU memory.
- typical (unmodified) Voodoo have low memory. But for 3D-hardware assisted compositing you must allocation enough memory for double buffering + enough memory to hold the buffer with the content of every window (as I said, no AGP-texturing). So even if the texture-size problem is corrected, you'll be still limited to lower resolution where everything can fit inside the 32Mo per VSA-100 (64 with modified Voodoo 4s)

Just a quick update regarding 3dfx DRI acceleration on Linux.

The bug that caused problems has been fixed in latest version of Xorg 7.2 and Mesa 6.5.2
Be sure to upgrade your distribution (I've heard that it's available in Ubuntu Fiesty. For openSUSE 10.2, you must add the repository "xorg72" from software.opensuse.org, I don't know about the other).

Also you still have to provide your own glide3x. (Debian is the only distribution still providing it. The deb package can be imported into debian-based distro like Ubuntu. For others, either you manually extract it from debian package, or you can use an older version that you copy from an earlier version of you distro).

> Voodoo3 & Linux
Work out-of-the-box with most distro up to Xorg 6.8. Though a small handful of distros don't install Glide by default (needed for 3D).
Starting from Xorg 7.2 there's a bug in the Mesa 3D driver that needs some patching (see above discussion) and you have to provide a Glide library (I don't know any distro that still provides Glide as of Xorg 7.2)
2D still works flawlessly.

Cards doesn't necessarily need to be AGP, since voodoo don't use AGP texturing. The only reason to use is that AGP bus is faster (~66Mhz depending on bus overclocking), whereas most PCI bus found in non-server motheroard only work at half that speed (32bits 33Mhz) and doesn't benefit from the PCI-X extensions (64bits, 66Mhz).

> Wine and Games
I don't exactly know, It's been a time since I last used wine to play games. (Still dual boot).
Wine coming with the majority of distros has "wineconf" tool for graphical configuration (which is basically pointing which directories should be accessible as which device/drive letters under emulated Windows).

You may also try CrossOver or Cedega, but I have even less experience with them. You can also try linux variants of the games (3D engines from ID software and Epic are available under Linux too or have been ported by the community. So all Quakes, Dooms, Wolfensteins, Unreals, and some games sharing the engines can be run without wine) (other have been ported from open-sourced projects, or re-implemented : like Descent, Freespace or Homeworld. Or even Scumm and SCI point'n'click adventure games). Also don't forget the completly new reimplementation of game concept (like FreeCiv broadly inspired by Civilisation and such. Good game and less ugly if you change the tileset). The main problem will be graphical powers : anything newer than Quake3 / Return to Castle Wolfenstein may require too much compared to what the Voodoo3 can handle. You may need to lower the quality settings.

Also, there aren't as many nice graphical utilities to tweak the settings (there's driconf from freedesktop's website, but I don't know how much it supports tdfx driver). The good news is, as Glide is shared between Windows and Linux, most of the registry keys used in Windows can be used as environment string under linux (you can use the same FX_GLIDE_* names as in the windows .INI file)


> Coppermine processors, Asus P2B-D, etc.

Important readings :
P2B CPU upgrade FAQ
440BX RAM upgrade FAQ (Note: Crucial has such 440BX compatible Ram sticks, I use them)
Tweaking a P2B with a soldering Iron

The main difference between Coppermine and previous CPU is a slightly lower voltage and additionnal pins signalling the lower voltage (older CPU select voltage using 3pins, coppermine have a fourth pin).
Tualatin do really lower voltage and use different pin-out.

All of those processors have different microcodes than the previous PIII. With PC processors, the microcode is software modified and is loaded at boot time.

The strategy :

For BIOS :
- You should upgrade you BIOS. You have luck : most motherboard manufacturer like ASUS & MSI did provide BIOSes (or Alpha version of BIOSes) compatible with latest processors from Intel.
- Machine manufacturer like HP or Dell don't do that much update, you may end up manually modifying the BIOS, if it doesn't BOOT at all.
- If it BOOTs with an older BIOS, you can still upload Intel's  latest microcode from within Linux ( /proc/microcode )

For voltage, you have three situations :
- The motherboard has a complex voltage regulator that can support the special lower voltage of coppermine (even have a Tualatin-compatible Abit Slot-1 motherboard !?!).
In this case you need just a slotcket adapter that is compatible with the processor (most are, for Coppermines. For Tualatin there are a few company that produce compatible slotkets : some models from PowerLeap and most other similar companies).

- The processor voltage cpability and the CPU voltage requirement, aren't that much apart. As an exemple : non Coppermine-compatible mother board can go as low as 1.80 and ~1GHz Coppermines require 1.75v. It's almost the same. It close enough to be compatible. But the 3-pins signaling of the motherboard can't understand the voltage request of the CPU and can't provide the adapted voltage.
Then you need some slightly more complex slotcket which can override the voltage settings and force 1.80v (something that the motherboard can produce). It works like a charm with my 1.1Ghz 1.75V coppermine and I've read that with proper cooling other models shall work too (say, a 1.65v one).

- The processor is a Tualatin which is incompatible with most 440BX motherboard. Get a slotcket with it's own Tualatin-compatible voltage regulators and pinouts. It'll provide the needed voltage by itself (I use this on another Asus P2B mother board). Note: If you use non-air-blowing-based cooling solution (like water cooling) don't forget to cool the voltage regulator too (just put some small ram-heatsink) and check for leaky caps (one blew in an older slotcket).

(A fourth solution : modify the motherboard it self as per the 3rd source).

> Dual 450Mhz & 500Mhz
As you know, SMP with processor like PIIIs require both CPU to work at the same speed.
The problem is : the multiplier is locked on them. I don't know if you can hack something to make them both run at 450Mhz (or overclock them to 500Mhz).

Thank you, dborca, for everything you've done.
Just to show you that there're still Linux fans enjoying their Voodoo 5.

QuoteAlas, I failed to keep my last promise to this forum, but I will bring a release by spring 2007.

We're ll looking forward to it.
(Could it be some Xorg-less support for SLI, a la OpenGL Embed, that could be used to run on it both Xegl/Compiz and 3D games with SLI enabled ?)

I wish you success for both job and university.

(I know the topic is old and the poster may have fixed the problem alone, but I hope to be helpful to other users)

The driver "tdfx" should work with any 3dfx card with integrated 2D core (from Voodoo Banshee all they way up to Voodoo 5 6000).

(Voodoo 1&2 require another special driver if you want to use them for a X server. Note that when used as 2D display, old Voodoo 1&2 gards can't be used simultaneously for 3D with Mesa. So either one should use them for 2D only *OR* one should use a separate 2D card for X server and the Voodoo cards for 3D only using the pass-thru cable like in Windows *OR* one should use a more recent card that has both a 2D and a 3D core like the poster with his Banshee card *OR* one should use a card whose 3D core is supported by Xgl)

So, in  /etc/X11/XF86Config (or in Xorg 6.9 and up : xorg.conf), you should have a section similar to this one :

QuoteSection "Device"
 BoardName    "Voodoo5 5500"
 BusID        "1:0:0"
 Driver       "tdfx"
 Identifier   "Device[0]"
 Screen       0
 VendorName   "3Dfx"
EndSection

BoardName varies depending on the model, but isn't important.
BusID indicates where the card is connected : in my case, it's the first (and only) slot on the AGP bus. (If you have multiple video cards, each one will have a different BusID)
Identifier is just the name by which this device is referred to in other sections (like in the Section "Screen")


What exactly do you mean by :

QuoteI have a unreadable screen

Most of the time, the screen is unreadable because the screen setting aren't proprely entered in the config file, and the video card is using an out-of-spec refresh rate (Voodoo cards are highly programmable and can send pretty much any data rate that is within the spec of the RAMDAC, including TV compatible 480i).

The following section is needed in the config file :

QuoteSection "Monitor"
 HorizSync    28-107
 VertRefresh  43-170
 DisplaySize  360 270
 Identifier   "Monitor[0]"
 ModelName    "DELL P992"
 Option       "DPMS"
 VendorName   "DEL"
 UseModes     "Modes[0]"
EndSection

HorizSync (in KHz) and VertRefresh (in Hz) are THE most important settings defining the upper and lower limite for the monitor. You can find them on the manufacturer website, or maybe also in the .INI file of the Windows driver.
DisplaySize is not as important. It defines the size of the displaying surface and is used to compute DPI and stuff like that.
Identifier is the name by which the monitor will be referred in other sections.
UseModes refers to the Identifier of a Modline section that contain different setting to get different resolution. X server will you only those modes that fall between the monitor limitation defined with Hoiz- and VertRefresh.
ModelName and VendorName only describe the monitor and aren't required, just like in the Device section.

More information about the config file, if you have installed the xorg-x11-doc package :
man XF86Config or
man xorg.conf (depending on your version)


Also notice that the OpenSuSE distro has a very nice tools called "SaX" that help you configure the Xserver in a very easy way.

The 5v connector on the Voodoo5 is not regulated, and the VSA-100 tend to emit a lot of heat. So it's best to connect them to the PSU, and eventually use a normal 12v fan regulator (either manual or automatic).

Any fan advertised as universal (for all models GeForce / Ati Radeon / Northbridge chipset) should have the correct spacing to attach in the Voodoo board. Northbridge chipset-only fans may work too, but they'r usually higher and may get in the way.

You can also add small heatsink (RAM-sized) on the back side of the VSA-100 for additionnal cooling. Use only non-conductive medium to stick them (like the double sided tape that usually comes with such models. NO silver compound). You may also recieve such small RAM-heatsinks packed together with your fan. Just check the size before buying.

To get the heatsink out : use a very thin object (like a knife) that you insert between the surface of the VSA-100 (the black plastic part, not the green pcb wicht is soldered to the Board !) and the heat sink. The epoxy glue ins't very well speared and there are empty gaps. The objet must be thin (sharp knife). Check that no component (condenser or a-like) of the board is in the way, that you won't harm your self, and that no pressure is exerted on the PCB part of the chip (although not all balls of the BGA are wired : everything may still work even you if break a small corner. It hapenned to me. But play it self : knife goes between the two black parts).
Then lift the knife. You must use a lot of force to break the epoxy. That's why you must check that nothing else could break appart.

Then go in a well ventilated place (like outside ?) and use acetone (your girlfriend's nail polish remover) to remove excedent epoxy.

That helped me a lot : linux with Xrender acceleretion tends to use a lot of 2D hardware blending functions, much more than Windows (which barely use some H/W blitter), and sometimes, in summer, my Voodoo 5 overheats. The new fan combination changed the overheats for "often including in winter" to "only a couple in summer".
(It's probably a sub-defective sample that sliped thru the factory testing because of the complexe condition needed to reproduce - several hours of non-stop hardware blending before local overheating ).

I just wanted to mention that Google Summer of Code 2006 is starting to get organised.
Among the mentors, there's the X.org organisation and, as an exemple of what could be done for such a project, they mention improving the DRI drivers like 3dfx's (note that the DRI link is for the out-dated last year edition).
So if any of the developping guru around here wants to try some driver hacking on a new platforme, we linux user would be really happy ?

Don't know, like maybe SFFT would like to take a small summer break from the DX9 drivers ? ...

(I'm just hoping to have a functionnal SLI under Linux. And if there's a way to be able to switch in-the-fly between DUAL-Chip mode (for xgl, cairo, gnash, etc. on the desktop) and FSAA 4x (for games) without restarting server, i'll be really happy...)

Voodoo 5 on DOS Games.

It depends.
- A few games try to directly program the hardware registers (never seen such a game, only heard about it). They only work with the Voodoo Graphics. (Even the Voodoo 2 changed its register and those games can't work with it. You're out of luck with a Voodoo 5).

- Most accelerated DOS games use Glide (All which I've seen). They use a file called Glide2x.OVL (.OVL for DOS is amlost what .DLL is for Windows and .SO is for Linux). Remove any old glide that may still be in your game.
Just use the latest "Glide2x.OVL" that came with the latest 3dfx drivers for Win9x/Me (Win2k and WinXP aren't DOS based and therefor don't have OVL dos drivers).
I found 1 in latest official Win9x drivers.
I don't about latest community drivers.

- A very few games, usually open source, developped with DJGPP compiler use another format of dynamic libraries. They use DXE. You need to get a MesaFX DXE (for opengl) and a Glide2x DXE (3dfx voodoo acceleration for MesaFX). You may find more information at Danial Borca's Website.

Now the best part :
All the bells and whistle of the VSA-100 ALSO WORK IN DOS.
Yes, you can run those pre-Windows games in 640x480 WITH FSAA4x AND PseudoAnisotropic (using low LOD_BIAS combined with FSAA) enabled !
But configuration is a little bit more complex than with windows.
There is no interface for it.
You need to set environment variables to get it working. Like :
SET SSTH3_SLI_AA_CONFIGURATION=4
(this one turn FSAA 4x on).

Most of the variables name are the same for DOS environnement and Windows registry.
- You may have a look in you registry base at HKEY_LOCAL_MACHINE\SYSTEM\CurrenControlSet\Services\3dfxvs\Device0\Glide\ and ...\DEFAULT\
- You may have a look in the ".ini" file that came with your drivers.
- You may try to find all ASCII strings beginin with "SST" or "FX_GL" in glide2x.ovl
Because not ALL the same functions are supported in DOS as in Windows, the third method is the best to find out which settings are supported under DOS.
Also note that the Windows interface display different numbers for lod bias (numbered from -2 to +2 in 0.25 steps) than the variables in the environnement/registry (FX_GLIDE_LOD_BIAS is numbered between -8 and +8 in step of 1).

The best is to create a .BAT file with all settings inside.

Has anyone yet tried to play Dreamfall on Voodoo-powered hardware ?
How does it work ?
Is the framerate playable ?
Is the visual quality good, or is the VSA-100 missing some fundamental function (like Doom3 and the unsupported Bump-Mapping ?)

One of the reasons I kept using my Voodoo 5 (beside the fact it's a cool piece of hardware and the opensource DRI support in Linux), is that I love playing point'n'click games, and a nice RGSS like Voodoo5's does much more nice things to Longest Journey or Syberia than T&L or other stuff that the concurence was pushing at that time (and that can be handled OK by a good CPU).

Now that TLJ's sequel has moved to a more action- and less point'n'click-oriented design, I'm affraid if I would be able to play it on my hardware (Celeron (P3) @ 1.2Ghz, 512Mo RAM, Voodoo 5 5500 AGP), or if I'll be stuck with some flat-shaded aweful stuff like Doom3 on Voodoo (I mean without the shading patch) ?
I've read in some review that most of the texture in the PC version aren't that much different from the XBox ones. And given that a Xbox has a a CPU running at half of my speed, no gfx memory at all, and only 64MB total RAM, I hope my system will cope with that game without too much visual quality loss.

The internal mechanics of the 3DFX in FSAA mode :

* each chip can render up to 2 frames independently.
* Whenever the game sends polygon data to the 3DFX, each chip renders the polygon slighly offset in its own frame buffer. To the game eveyrthing looks like a standart 3D card, when in fact it's like 4 card working in parallel to create FSAA 4x.
* Whenever something try to read from the frame buffer (either by the game, or by the RAMDAC to display, or even by the chips themselves to do transparent textures) the corresponding pixel is read in each frame buffer from each chip and the result are mixed on-the-fly to provide a single pixel. To the game software, it looks like the card has 1 standart buffer.
* Whenever something is written to the frame buffer (game writing directly on frame buffer to display something without using the 3D engine) the same pixel is written to each frame on each chip. You don't get any AA, but at least it doesn't ****s up the frame buffers.

FSAA in 2D games : eveyrthing depends on how the data is written on screen.

* 2D games that write directly to the screen (like most old DOS games and a few windows games and also the Windows GUI itself) : no FSAA. In fact they don't even initialise the hardware into FSAA mode.
* 3D games using hardware acceleration (DOS games using Glide#x.OVL, Linux & Windows games using OpenGL or DirectX) : FSAA on per-polygon basis.
* 2D games that uses hardware acceleration to draw sprites on screen (GTA 1 and 2 come to mind. They use Glide/OpenGL/DirectX and represent sprites as flat polygons) : FSAA on per-polygon (aka per-sprite) basis.
* Emulators of 2D consoles (like MAME) or video players (like VLC) that use hardware acceleration to update and scale-up screen : if an FSAA enabled API like Glide/OpenGL/DirectX-3D is used the VSA-100 tries to apply FSAA on the single huge polygon that makes up the display. FSAA is on but actually makes the picture worse (blury). Either disable FSAA, or stick to other APIs : DirectDraw/SDL/XVideo/Xshm

I haven't experimented with StarCraft and I don't have Diablo.
But GTA 1 is a nice exemple of an (almost) 2D games where the sprites (cars, by standers, etc.) are considered as polygons and benefits from FSAA & a correct LOD Bias (less jaggy when rotating).

"Designed for DOS Games" : Only those that use Glide#x.ovl to display. For them everything is just automagically handled by Glide and everything seem to work as if there wasn't any FSAA involved. (Compare this to the FSAA in GeForce 2 where the single frame buffer was constantly scaled up and down, and sometime when directly writing to frame buffer, the wrong pixel could be writen).
DOS games that either try to control Voodoo hardware directly (and mostly fail, because they were disgned with Voodoo 1 hardware in mind) or don't use any hardware acceleration don't benefit at all from FSAA, for them your 3D works like a plain SVGA/VESA card.

(Reply based on 3DFx documentation and personnal experience tweaking my V5.)

Has someone managed to get Quake 4 (minimal visual quality) to work with Voodoo 5 ?
Doom3 has been able to run even on Voodoo2, Kyro II and TNT.
So quake 4 *should* be manageable (in low quality and without the nice light effects).

I've tried but :
- the MesaFX 6.3.0.1 (at dbroca's website) misses some functions. Or, to put it another way : supports only the hardware functions of 3DFX Voodoo 5. No way to force missing functions either in software or ignored.
- the MesaFX 6.1.0.9 Doom3 edition (on 3dfxzone) crashes when Quake 4 is loading.

Had anyone had more luck in trying to run Quake 4 on VSA-100 ?

Quotebut afaik only in OpenGL/Glide.

So it's a good oportunity to try to implement it in DirectX too !
Maybe Doom3 or HL2 won't benefit from it,
but improved Anti-Aliasing quality will surely be a good point for less intensive games (like adventure games).

Do you have more information on how to use temporal anti-aliasing in OpenGL/Glide ?

Just gave the URL to my downloading machine.

Thank you very much !

When launching the VSA-100,
3dfx demoed the motion blur capability of the T-Buffer, with a modified Quake III engine.

Does anyone know where I could find this thing ?

I would like to have fun with motion blur in Quake III.