Projects – deprecated
In English
- ATI Radeon cards
- MPlayer
- Neverwinter Nights
- SB Audigy2 under Linux
- TV-Out on ATI
- WLAN firmware re-distribution under F/OSS operating systems
ATI Radeon cards
This is now finally not maintained anymore.
Buying guide
- Top of the line - X1900 XTX
- Performance - X800 XL
- Value - X550
Current models
| Model | Bus Width | Core (MHz) | RAM (MHz) | Px/Vrtx | Notes |
| R5xx | |||||
| X1900 XTX (R580) | 256-bit | 650 | 775(1550) | 48/8 | |
| X1900 XT | 256-bit | 625 | 725(1450) | 48/8 | |
| X1800 XT (R520) | 256-bit | 625 | 750(1500) | 16/8 | |
| X1800 XL | 256-bit | 500 | 500(1000) | 16/8 | |
| R4xx | |||||
| X850 XT PE (R480/1) | 256-bit | 540 | 590(1180) | 16/6 | |
| X850 XT | 256-bit | 520 | 540(1080) | 16/6 | |
| X850 Pro | 256-bit | 520 | 540(1080) | 12/6 | |
| X800 XL (R430) | 256-bit | 400 | 500(1000) | 16/6 | |
| X800 GTO | 256-bit | 400 | 490(980) | 12/6 | These are leftover R480-chips that are sold for a cheap price. |
| X800 GT | 256-bit | xxx | xxx(xxx) | 8/6 | These are leftover R480-chips that are sold for a cheap price. |
| X800 | 256-bit | 400 | 350(700) | 12/6 | |
| RV5xx | |||||
| X1600 XT (RV530) | 128-bit | 590 | 690(1380) | 12/5 | |
| X1600 Pro | 128-bit | 500 | 340(680) | 12/5 | |
| X1300 Pro (RV515) | 128-bit | 600 | 400(800) | 4/2 | |
| X1300 | 128-bit/64-bit | 400 | 250(500) | 4/2 | HyperMemory-variant also available. |
| RV4xx | |||||
| X700 XT (RV410) | 128-bit | 475 | 525(1050) | 8/6 | |
| X700 Pro | 128-bit | 425 | 430(860) | 8/6 | |
| X700 | 128-bit | 400 | 350(700) | 8/6 | |
| RV3xx | |||||
| X600 XT (RV380) | 128-bit | 500 | 370(740) | 4/2 | Similar to 9600 XT with faster memory. |
| X600 Pro (RV381?) | 128-bit | 400 | 300(600) | 4/2 | Similar to 9600 Pro. |
| X550 | 128-bit | 400 | 250(500) | 4/2 | |
| X300 (RV370) | 128-bit | 325 | 200(400) | 4/2 | Similar to 9600. |
| X300SE (RV371?) | 64-bit | 325 | 200(400) | 4/2 | Similar to 9600SE. |
Old models
| Model | Bus Width | Core (MHz) | RAM (MHz) | Px/Vrtx | Notes |
| R4xx | |||||
| X800 XT PE (R420/3) | 256-bit | 520 | 560(1120) | 16/6 | |
| X800 XT | 256-bit | 500 | 500(1000) | 16/6 | |
| X800 Pro | 256-bit | 475 | 450(900) | 12/6 | |
| X800SE | 256-bit | 425 | 350(700) | 8/6 | |
| R3xx | |||||
| 9800 XT (R360) | 256-bit | 412 | 365(730) | 8/4 | |
| 9800 Pro (R350) | 256-bit | 380 | 340(680) | 8/4 | |
| 9800 | 256-bit | 325 | 290(580) | 8/4 | |
| 9800SE | 128-bit | 325 | 250(500) | 4/4 | |
| 9700 Pro (R300) | 256-bit | 325 | 310(620) | 8/4 | |
| 9700 | 256-bit | 275 | 270(540) | 8/4 | |
| RV3xx | |||||
| 9600 XT (RV360) | 128-bit | 500 | 300(600) | 4/2 | |
| 9600 Pro (RV350) | 128-bit | 400 | 300(600) | 4/2 | |
| 9600 | 128-bit | 325 | 200(400) | 4/2 | |
| 9600SE (RV351) | 64-bit | 325 | 200(400) | 4/2 | |
| 9550 | 128-bit | 250 | 200(400) | 4/2 | |
| 9550SE | 64-bit | 250 | 200(400) | 4/2 | |
| 9500 Pro (RV300) | 128-bit | 275 | 275(550) | 8/4 | Double the pixel & vertex pipelines of 9500/9550/9600-series, thus faster in most situations than even 9600Pro. |
| 9500 | 128-bit | 275 | 270(540) | 4/2 | |
| Avoid SE-models, 64-bit memory bus makes them slower than anything else. | |||||
| R2xx | |||||
| 9250 | 128-bit | 240 | 200(400) | 4/1 | 9000-series gets slower still... |
| 9200 Pro (RV280) | 128-bit | 300 | 300(600) | 4/1 | 9000 with AGP 8x -support (-> 9200 is a product created purely for marketing purposes) |
| 9200 | 128-bit | 250 | 200(400) | 4/1 | -- "" -- |
| 9200SE | 64-bit | 200 | 166(333) | 4/1 | |
| 9100 | 128-bit | 250 | 250(500) | 4/2 | Double tex. samples / pixel pipeline vs. 9000, 9200-series |
| 9100LE | 128-bit | 250 | 200(400) | 4/2 | -- "" -- |
| 9000 Pro (RV250) | 128-bit | 275 | 275(550) | 4/1 | |
| 9000 | 128-bit | 250 | 200(400) | 4/1 | |
| 8500 (R200) | 128-bit | 275 | 275(550) | 4/2 | Double tex. samples / pixel pipeline vs. 9000, 9200-series |
| 8500LE | 128-bit | 250 | 250(500) | 4/2 | -- "" -- |
| Series 8500, 9000, 9100 and 9200 are more or less the same, the original 8500 often being the fastest of the bunch. 9200SE is far slower than any other of the R200-series. | |||||
| Pre-R200 | |||||
| 7500 (RV200) | 128-bit | 290 | 230(460) | 2/0.5(TnL) | 3 tex. samples / pixel pipeline |
| 7500LE | 128-bit | 250 | 180(360) | 2/0.5(TnL) | -- "" -- |
| 7200 (R100) | 128-bit | 166 | 166 | 2/0.5(TnL) | -- "" -- |
| 7000 | 64-bit | 183 | 183(366) | 1/0 | -- "" -- |
| DDR | 128-bit | 183 | 183 | 2/0.5(TnL) | -- "" -- |
| SDR | 128-bit | 166 | 166 | 2/0.5(TnL) | -- "" -- |
| VE/LE | 64/128 | 148-183 | 148-183 | 1/0 | -- "" --. Card configurations vary. |
MPlayer
Note: I'm using mainly GStreamer nowadays (via Totem and other players), so I'm not updating this anymore. LFE downmixing is btw also supported in GStreamer quite nicely.
I'm aiming to use completely free software and free video/audio formats, but there are still a few obstacles. Alas, currently, I still have a few CSS-encrypted (ie. "copy protected") DVDs, and it's illegal according to some that I'd play the DVDs I have bought with the gear of my choice. Adding to this problem are the non-free/patent-encumbered video (MPEG-2) and audio (AC3) formats used on the DVDs. No company is currently selling popular movies in a free format, so I can't buy movies in e.g. Ogg format, Ogg Theora for video and Ogg Vorbis for audio.
Because of the few DVDs I still have (most of my video files are nowadays in the Ogg format), I'm using a custom build of MPlayer, compiled with a more limited amount of non-free/questionable components (no mp3, xvid, divx etc. encoding). However, as it still includes the MPlayer's integrated ffmpeg-library, I can use it together with my convert scripts to convert the remaining video files in (most) proprietary formats to Ogg.
I hope that one day it is enough for me to use the video player _that is bundled with my GNU/Linux distribution_.
for Ubuntu Linux / Debian GNU/Linux
The packages below should work with Ubuntu 5.10 (Breezy Badger), 5.04 (Hoary Hedgehog) & Debian GNU/Linux 3.1 (Sarge), though you may want to change settings in /etc/mplayer/mplayer.conf-file (see man mplayer). Packages were compiled with 'dpkg-buildpackage -rfakeroot' and with the following options: --enable-live --enable-runtime-cpudetection --disable-mp3lib --enable-gui. Most needed libraries for various input/output devices etc. (inc. live.com) were installed at the compile time. The packages also include an OSD font and a skin for the GUI.(binary package removed, sources still available) (source|dsc|changes)
LFE downmixing
Note: I once tried MPlayer CVS version and couldn't find a way to do LFE downmixing anymore. With the above version these instructions still work.
Note2 (2007): Checked that nowadays the following works on my my setup for 5.1 -> 2 channels: 'mplayer -channels 6 -af pan=2:.25:0:0:.25:.25:0:0:.25:.25:.25:.25:.25'
LFE (Low Frequency Effects) on DVDs and other AC3 5.1 media are often wanted even when downmixing the sound for e.g. a stereo setup (2.0), or a stereo setup and a subwoofer (2.1) or four channel surround setup (4.0). MPlayer allows this, while Xine doesn't support this at the moment.
Unfortunately, enabling the downmixing is anything but clear. It should be done with -af pan ('pan' audio filter), but the documentation is lacking and partly false. Man page and html documentation don't even state the same facts. Without going into further details, I've managed to have correct 5.1 downmixing for my stereo setup with the following command:
mplayer -ao alsa -channels 6 -af pan=6:1:0:1:0:1:1:0:1:0:1:1:1
So, the number of channels should be set at 6 in both -channels and in the pan filter. The rest is according to the documentation, with the exception that putting in any floating point numbers somehow messes up the whole setup. It seems that even though center and LFE channels are mixed to both left and right channels, they're not too loud. It'd be more logical would to use "0.5" in those parts of the command, but for some reason they don't work for me as stated.
Other reported configs include (I haven't tested them myself):5.1 -> 4+mixed LFE -channels=6 -af pan=6:1:0:0:0:0.5:0.5:0:1:0:0:0.5:0.5:0:0:1:0:0:0:0:0:0:1:0:0:0:0:0:0:0:0:0:0:0:0:0:0
Neverwinter Nights
Neverwinter Nights is what computer role-playing games have needed for a long time - the endless customization possibilities and the concept of "dungeon master" brought to computer screens. Fortunately enough, me being a Linux user, Neverwinter Nights is also available for Linux, together with the expansion packs Shadows of Undrentide and Hordes of the Underdark.
To purchase your own copy of Neverwinter Nights, please support the Linux gaming community as a whole by buying it from Tux Games!
SB Audigy2 under Linux
ALSA (Advanced Linux Sound Architecture) drivers fully support Audigy2, and they are integrated in the kernel in Linux 2.6 kernel series.
The only problem nowadays is that the mixer settings are not at all easy when trying to do something more sophisticated. There there are a few points worth noticing (updated as of Alsa 1.0.3):
- To record from analog sources, increase volume in e.g. Line and Analog Mix Capture.
- To hear what you are recording, increase volume in Analog Mix.
- In alsamixer, "PCM" is the one controlling the volume of wave output, "WAVE" is actually seemingly controlling the recording volume of "What you hear".
- In order to properly voice communicate via internet, you have to mute the "WAVE" so as not to record everything but only the source you want (ie. Mic).
- To enable Mic input, you have to raise the volume of "Capture" and "AC97 Capture" and select "Capture" and "Mic" as the recording sources. The volume slider of "Mic" doesn't change a thing, it seems. It's also recommended to unmute the "Mic Boost"-selection to have a +20dB volume increase in the Mic input.
- In KMix (the KDE mixer), "IGain" is what "Capture" is in alsamixer, and there is no corresponding sliders for "WAVE" or "AC97 Capture" at all.
TV-Out on ATI
Here I hope to collect some information about how to utilize the TV-Out on ATI series of cards (originally aimed for the Radeon 8500-9200 series) under Linux-environment. For various reasons, enabling TV-Out has always been a bit difficult, but if you want to have a definitely working solution, you can consider an external PC to Video converter (eg. here, or here) - with that, you only need to have a working multi-monitor support.
- First of all, TV-out support for various Radeon cards in the 7000 - X850 range have now TV-out support in the latest 6.8-series of X.org ati driver. One can try to enable it with the following commands or a variation of them:
xrandr -s 800x600 xrandr --output S-video --set tv_standard pal xrandr --addmode S-video 800x600 xrandr --output S-video --mode 800x600
- MPlayer. Tv-out video playing with -vo vesa from the console. Unfortunately broken since glibc 2.2.5, some discussion on mplayer mailing lists about that but no solution. Other mplayer solutions include (-vo) fbdev and DirectFB, but I haven't found how to output to TV with them, either. Using vesafb from kernel I don't get any 50Hz mode on, and DirectFB doesn't work with vesafb for me. Using radeonfb from kernel I get 50Hz output of console but the image on the TV is somehow garbled, and using mplayer's fbdev or DirectFB with radeonfb shows a black screen (only Mplayer's OSD is shown on the monitor, no video).
- Movix. A working solution, but alas, requires booting. Comes with MPlayer (and an earlier glibc). Use MoviX² to get X interface, choose 'vesa' at the bootup options. My movix.pl (not any more available) and isolinux.cfg (not anymore available) force VESA and software scaling to use, and select 'vesa' as the default bootup option. MoviX² 0.3.0pre4 was used. Update Aug 13, 2003: It seems that newer versions don't work correctly with vesa output, so I'm sticking to 0.3.0pre4 for now. 0.3.1preX has a working tv-out with 'VesaFB' boot option, but has choppiness problems with DVD playback (others play fine for me).
- Linux ATI TV-Out Support Program. Development stopped, the program doesn't work on newer Radeons
WLAN firmware re-distribution under F/OSS operating systems
Update (2006): See FSF's page for some updated information about the best choices (no firmware blob needed either).
Pre-amble: "OpenBSD Works To Open Wireless Chipsets"
Currently most up-to-date information: OpenBSD's "Out of the Box" Wireless Support (feature article)
There has been a recent quest to allow free re-distribution of Wireless LAN chipset firmwares, which are needed to have WLAN working out-of-the-box with Free and Open Source Software operating systems (BSDs, Linux-distributions). If the re-distribution is not allowed, none of these wireless devices work under any *BSD or Linux distribution, unless each distribution makes a separate agreement with each of the vendors.
It is not sought after to have open source firmware, only that the binary firmwares - running on the WLAN card itself, not the host computer - could be re-distributed so that users can use their cards. This seems to be a confusing matter, with people e.g. bashing the attempt by saying that the vendors can't open the firmware code as it would allow for too easy manipulation of used radio frequencies etc. The only thing that is wanted is that people could use their network without being to forced to download a firmware from the Internet (because the license is such that you can't re-distribute the firmware) and generally having to find out how to make it work instead of "just works" which could be accomplished by the distribution developers.
The manufacturers can be currently (as of June 2005) divided in the following groups:
(links to manufacturer sites, GPL drivers and discussion about firmware distribution)
Firmware re-distribution allowed
- Symbol - since April, 2004 [link]
- Zydas (zd1201, zd1211) - since October, 2004 [link]
- Atmel (AT76C50XXx) - since October, 2004 [link]
Do not (necessarily) need firmware to be freely distributed
Do not have a host CPU
- Atheros (eg. ar5211, ar5212)
- Ralink (RT2400, 2500, see list)
- Realtek (RTL8180, (RTL8185, RTL8225))
Have a flash memory (ie. the firmware is already on-board)
- old Orinoco devices
- old Prism devices
- old Symbol devices
ps. the driver statuses for different chipsets still wary, so you do not necessarily want to purchase some of the recommended devices blindly... see the driver pages for more information
Firmware re-distribution not allowed
- Intel has said "no", at least for now [link] [link] [link]
- TI [link] [link]
- Conexant/Intersil (Prism G/Javelin)
- Broadcom [link]
- Some of these companies may be possible to convert still. After all, it would benefit them and everyone else.
This (WLAN) section) (L) 2005 Libre Commons Res Communes License. Feedback/corrections: timo.jyrinki@hut.fi