Forumzone Community

ho appena notato sul forum di 3dhq (http://www.tdhq.net/cgi-bin/yabb/YaBB.pl?board=6;action=display;num=1041743780) la foto della scheda che tempo addietro mio zio mi aveva prestato (ora se l'e' ripresa..), cioe' una Voodoo 4 4500 della Powercolor con Tv-Out. Solo ora dopo aver anche usato quella scheda nel mio case ho notato un piiiiicolissimo particolare... qui in foto:
(https://www.forumzone.it/public/uploaded/20031644638_voodoo4%20-%20powercolor.jpg)
.
.
.
.
.
beh.. se proprio non ci arrivate ve lo dico io... questa voodoo4 della powercolor e' AGP4X, e molti di voi sanno cosa cio' vuol dire (compatibilita' con le ultime sk. madri, ecc). Ora mi chiedo.. avendo in mano informazioni tenciche sulla suddetta scheda non sarebbe possibile rendere tutte le voodoo 4/5 compatibili agp4x con qualche modifica per poterle usare per esempio su schede con nforce2.. e battere i record mondiali di velocita' delle nostre care voodoo ?

ciao, nigel

ho appena trovato questo sito:
http://rashly3dfx.tripod.com/products/voodoo4.html

guardate le 2 foto enormi in basso.. e' una voodoo4 liscia 3dfx ma con agp4x...

questa storia mi lascia perplesso :(

ciao, nigel

Anche la mia 3dfx voodoo 4500 è agp4x:):)
E lo sono tutte le voodoo 4 di recente produzione. Non esistono problemi di compatibilità nè che sia agp 4x che 2x.
L'incremento prestazionale tra 2x e 4x è insignificante: si attesta nell'ordine del 2-3% max.

Enjoy Nigel sta dicendo una cosa molto interessante, tra agp 2x 4x e 8x non cambia nulla a livello prestazionale però se sono compatibili agp 4x le puoi mettere sulle ultime schede madri!!!
grande Nigel vediamo se si può fare qualcosa

beh la modifica è semplice....nell'attacco si fa un taglietto li dove manca e....zac, fottuta la scheda e ve ne prendete una 4x :D
comunque è vero, questa dell'agp a 4x/8x è una grandissima boiata.... potrei capire se le schede avessero ancora 16mb e facessero largo uso del bus, ma con 64/128mb non ne vedo proprio l'utilità... per di più le vodoo manco lo supportano l'agp texturing, potrebbero tranquillamente essere montate su pci! mah...tutto x cambiare mobo/sk grafica!!

In che senso si possono montare sulle ultime schede madri??
Ovvio che una 4500 2x la puoi montare anche su una scheda madre uscita 2 settimane fa che supporta l'8x!
La mia banshee per esempio (agp 1x) l'ho montato su una a7v8x di un mio amico e funziona perfettamente..
Fino ad ora a parte qualche scheda madre per p4 che non ha la giusta tensione di alimentazione sullo slot agp non ne ho sentite di mobo che non garantiscano la compatibilità con i precedenti standar di agp
.Correggimi se sbaglio, magari portando esempi

CitazioneIn che senso si possono montare sulle ultime schede madri??
Ovvio che una 4500 2x la puoi montare anche su una scheda madre uscita 2 settimane fa che supporta l'8x!
La mia banshee per esempio (agp 1x) l'ho montato su una a7v8x di un mio amico e funziona perfettamente..
Fino ad ora a parte qualche scheda madre per p4 che non ha la giusta tensione di alimentazione sullo slot agp non ne ho sentite di mobo che non garantiscano la compatibilità con i precedenti standar di agp
.Correggimi se sbaglio, magari portando esempi

Hai mai visto una scheda con Nforce2 o kt400 che hanno l'Agp 8x?? mi sa di no eh!!

le schede fisicamente non ci entrano!!!!!!
lo slot è diverso per questo è importanto quello constatato da Nigel.....

é vero l'ho visto adesso, chiedo venia..
Però vedo l'operazione molto rischiosa..

Non vorrei sminuirvi ma mi sembra un po impossibile, forse possiamo inventare uno slot che da agp2x sia possibile andare ad un agp4x.

sarebbe interessante, ma ci credo poco.... bidognerebbe progettare un' interfaccia a livello hardware per portare i livelli di tensione compatibili con le voodoo....

questa sta sul sito di uno di voi ;)

(https://www.forumzone.it/public/files/screenshots/utenti/5.jpg)

argh! allora ci sono... basta trovarle

visto che esiste ci sara' un datasheet della versione 4x per poter magari rendere anche le 2x compatibili... potrebbe essere una scoperta molto importante per aumentare ulteriormente la longevita' della nostra scheda preferita..

ciao, nigel

scusa la curiosità....ma xkè ti downclocchi le schede?? :D

la voodoo5 su consiglio di un tizio dul forum dei tdhq ho visto che va leggermente meglio @159 piuttosto che @166, mentre la 3500... visto che ci tengo anche a lei, e che scalda come una bestia, le ho levato un po' di mhz :)

Si sapevo della loro esistenza ma penso che ce ne siano molte poche in giro, forse un paio, visto che non ce l'hanno fatta a vedere la luce del sole.

Da quel che sapevo io, la Voodoo 5 non era in grado di comunicare a 4X perchè richiedeva una tensione pari a 3,3 volt, contro gli 1,5 del AGP 4X.
Ma è probabile, visto che è alimentata a parte, sia ugualmente possibile. Forse la 3dfx avava iniziato la produzione di sole voodoo 5 con AGP 2X per paura di incompatibilità (agli inizi il 4X dava un sacco di problemi con molte schede video), poi ha visto che funzionava ed ha iniziato la produzione di Voodoo 5 AGP 4X. Sfortunatamente è fallita.
Personalmente però, ritengo che mandare una Voodoo 5 a 4X non aumenti enormemente le sue prestazioni. Ricordiamo che non sfrutta AGP Texturing, quindi la banda dell'AGP 2X basta ed avanza...

Non aumentava di sicuro le prestazioni ma aumentava molto la compatibilità con le schede madri di ora.

Ebbravo il nostro Nigel! :cool:

:D :D

CitazioneDa quel che sapevo io, la Voodoo 5 non era in grado di comunicare a 4X perchè richiedeva una tensione pari a 3,3 volt, contro gli 1,5 del AGP 4X.
Ma è probabile, visto che è alimentata a parte, sia ugualmente possibile. Forse la 3dfx avava iniziato la produzione di sole voodoo 5 con AGP 2X per paura di incompatibilità (agli inizi il 4X dava un sacco di problemi con molte schede video), poi ha visto che funzionava ed ha iniziato la produzione di Voodoo 5 AGP 4X.

ho ritrovato ieri un'intervista con un pr della 3dfx, in cui veniva detto proprio che la voodoo4 sarebbe stata agp fino a 4x, mentre la voodoo5 'semplicemente 2x', in
quanto l'agp 4x non supportava un carico elettrico di più di un chip... quindi sicuramente anche quelle col dentino in meno non ci vanno...

anche se cmq, quella foto che ho postato nell'altra pagina e che stava nel sito di davide, mi piacerebbe sapere che revisione è! ha pure un bel po di componenti in meno per l'alimentazione...



Scritto Da - ToxicWaltz on 02 Febbraio 2003  09:48:44

voodoo5 5000 agp 4x (sempre che ci vada, cmq notare sempre la 'carenza' di componenti a destra!)

(https://www.forumzone.it/public/uploaded/ToxicWaltz/voodoo5-5000_2.jpg) (https://www.forumzone.it/public/uploaded/ToxicWaltz/voodoo5-5000_1.jpg)

Io ho montato delle Biostar M7VIK KT400 e posso assicurarvi che lo slot AGP è uguale a quello della mia K7S5A. Non so se è una particolarità di questa MB, ma fisicamente anche le schede 2x entrano, che poi funzionino o meno è un'altro discorso anche perchè le nuove MB hanno una tensione del bus AGP pari a 1,5V variabile fino a 1,8V. Cmq credo che per la V5 5500 il discorso sia un po' diverso grazie all'alimentazione supplementare che ha e, in teoria, dovrebbe funzionare anche su AGP 8x. L'unico modo per saperlo è provare :)

CAZZOLINA!!!!!!

La foto che vedete, o è un fotomontaggio, oppure siamo di fronte a uno dei rarissimi prototipi di VSA101!!!!
notate i chip di ram....SONO DELLE DDR!!!!!

Mancano alcuni componenti sull'alimentazione poiche i chipset vsa101 sono a 0.18micron anziche 0.25 e consumano per questo meno della metà di una normale 5500......pur avendo una frequenza di 183-200mhz....

Dove avete trovato questa foto?????

ma sei sicuro che sono delle DDR? penos esistano anche delle sdram con quel tipo di package...
cmq non mi sewmbra che esistano schede col VSA-101 in SLI...quella foto l'ho presa in un sito che non ricordo, cmq la trovi pure qui
http://rashly3dfx.tripod.com/index2.html

oltretutto in quel sito foto del VSA-101 ce ne sono (su products/daytona), non sono poi così difficili da trovare ;)

Ragazzi leggete pure quello che c'è sotto le foto!!!
Quella è una delle rare voodoo 5 5000 AGP con 32MB!!!
Non vedete la disposizione delle SDR!!!
L'alimentazione ha pochi componenti essendo la versione 32Mb meno esosa della 64MB!!
Quello che mi lascia + basito è perchè 3dfx abbia prodotte le varie 4 4000/4500 5 5000 con AGP4x e le versioni di punta 5500/6000, con AGP2x!!!
Forse xchè con 64/128Mb la scheda era meno bus dipendente, delle versioni inferiori a 32Mb ad 1 o 2 VSA100, che colmavano il gap prestazionale con un aumento dellla larghezza di banda del bus AGP portandolo a 4x!!!
Una 2x cmq nn puo in nessun modo diventare 4x!!
Quel package di SDR, è vecchissimo, ho qua una vecchia Diamond Viper con ZX128 con quelle SDR con contatti su tutti e 4 i lati!!
Solo le prime DDR richiedevano i contatti su tutti e 4 i lati!!!
Ciaooooooooo

se guardi nell'altra pgina di questa discussione, c'è anche una 5500 (penso!) agp 4x e con meno componenti per l'alimentazione... cmq si quella è una 5000 32mb

Per 105$ qui:
http://www.target-sale.com/tusa/items/videoagp/i03635.html
Ci si porta a casa una v55k AGP con DVI, peccato che nelle immagini riporti una PCI!!
Ciaooooo

Ecco un immagine chiaritrice:

(https://www.forumzone.it/public/uploaded/f3dfx/3dfx-Voodoo5-5000_small.jpg) (https://www.forumzone.it/public/uploaded/f3dfx/3dfx-Voodoo5-5000.jpg)

Ed eccovi un bel prototipo v4 4500 DVI/Tv-Out

(https://www.forumzone.it/public/uploaded/f3dfx/3dfx-voodoo4-4500-tv.jpg)

Un bel bios v.1.11 DVI/Tv-OUT

(https://www.forumzone.it/public/uploaded/f3dfx/biosv4tv.jpg)

E i drivers x-3dfx con supporto DVI:



Puo darsi pure che le ultime rev. di v55k siano AGP4x, ma sono x lo + prototipi come quello sopra!!!

Ciaooooo

mi sembra difficile ne abbiano ancora... cmq le pci sono piuttosto rare, non è per niente un male! :)
tra l'altro a risoluzioni alte vanno persino un po meglio delle agp

Ecco i drivers con DVI by x-3dfx!!

cmq sicuramente quella nella foto del sito con uscita dvi è la versione mac (avranno messo una foto a caso)

No, no è un prototipo AGP x PC!!!

(https://www.forumzone.it/public/uploaded/f3dfx/biosv4tv.jpg)

Ecco il pettine AGP della sk sopra:

(https://www.forumzone.it/public/uploaded/f3dfx/voodoo4-4500-tv-agp-connector.jpg)

CIaoooooo

si si il pettine di quella si riconosceva anche nella prima (certo dev'essere rarissima!!)
intendevo la 5500 in vendita a 105$ ;)

ma come le trovi queste foto??

Leggendo i dati tecnici del Napalm, alias voodoo 5 6000, ho scoperto delle cose molto interessanti, tipo che il VSA100 supporta dal PCI all'AGP2x/4x oltre che ben 64Mb x chip, che ha portato qualche utente oltre oceano a creare una voodoo 5 5500 128Mb AGP!!Ecco i dai tecnici:
1.        Introduction
The Napalm Graphics Engine is a fifth (Voodoo Graphics, Voodoo2, Voodoo Banshee, Voodoo3, ...) generation 3D graphics engine based on the original SST1 architecture. Napalm incorporates all of the original SST1 features such as true-perspective texture mapping with advanced mipmapping and lighting, texture anti-aliasing, sub-pixel correction, gouraud shading, depth-buffering, alpha blending and dithering. Napalm also has 2 full-featured texturing units, which allow for advanced features like trilinear filtering, dual-texturing or bump mapping to be performed at the rate of a pixel per clock. Also, Napalm incorporates true-color rendering, 24-bit depth, and stenciling capabilities. In addition to the SST1 features, Napalm includes a VGA core, 2D graphics acceleration, and support for Intel's AGP 4x bus.
Features
SST1 baseline features with 2 texturing units.
SST1 software compatible
AGP 4X / AGP2X / AGP 1X / PCI bus compliant
Native 128-bit VGA core
2D acceleration
Binary/Ternary operand raster ops
Screen to Screen, Screen to Texture space, and Texture space to Screen Blits.
Color space conversion YUV to RGB.
1:N monochrome expansion
Rendering support of 2048x2048
Integrated RAMDAC and PLLs.
Bilinear video scaling
Video in via feature connector
Supports SGRAM and SDRAM memories
TV out interface runs at 100MHz DDR
Video-In:
Operates simultaneously with TV out interface.
Decimation
Support for interlaced video data
Support VMI, SAA7110 video connectors
Triple buffers for video-in data
Video-Out:
Bilinear scaling zoom-in (from 1 to 10x magnification in increments of 0.25x)
Decimation for zoom-out (0.25x, 0.5x, 0.75x)
Chroma-keying for video underlying and overlaying
Support for stereoscopic display
Hardware cursor
Double buffer frame buffers for video refresh
DDC support for monitor communication
DPMS mode support
Overlay windows (for 3D and motion video)


3.3        Functional Overview

Bus Support: Napalm implements both the PCI bus specification 2.1 and AGP specification 1.0 protocols, including support for the AGP 4x specification. Napalm is a slave only device on PCI, and a master device on AGP. Napalm supports zero-wait-state transactions and burst transfers.
PCI Bus Write Posting: Napalm uses an synchronous FIFO 32 entries deep which allows sufficient write posting capabilities for high performance. The FIFO is asynchronous to the graphics engine, thus allowing the memory interface to operate at maximum frequency regardless of the frequency of the PCI bus. Zero-wait-state writes are supported for maximum bus bandwidth.
VGA: Napalm includes a 100% IBM PS/2 model 70 compatible 128-bit VGA core, which is highly optimized for 128 bit memory transfers. The VGA core supports PC '97 requirements for multiple adapter, and vga disable.
Memory FIFO: Napalm can optionally use off-screen frame buffer memory or AGP memory to increase the effective depth of the PCI bus FIFO. The depth of this memory FIFO is programmable, and when used as an addition to the regular 32 entry host FIFO, allows up to 1Mbyte host writes to be queued without stalling the PCI interface. Napalm supports 2 independent command streams that are asynchronous to each other. Either command stream can be located in AGP memory or frame buffer memory.
Memory Architecture: The frame buffer controller of Napalm has a 128-bit wide datapath to RGB, alpha/depth-buffer, 2D desktop, video, and texture memory with support for up to 200 MHz SGRAMs or SDRAMS. For 2D fills using the standard 2D bitBLT engine, 8 16-bit pixels are written per clock, resulting in a 800 Mpixel/sec peak fill rate. For screen clears using the color expansion capabilities specific to SGRAM, 64 bytes are written per clock, resulting in a 12.8 Gbytes/sec peak fill rate. For Gouraud-shaded or textured-mapped polygons with depth buffering enabled, one pixel is written per clock – this results in a 166 Mpixels/sec peak fill rate. The minimum amount of memory supported by Napalm is 4 Mbytes, with a maximum of 64 Mbytes supported.
Storing texture bitmaps, the texture memory controller of Napalm must share the 128-bit wide Datapath to Napalm memory. The texture unit uses sophisticated caching to reduce the required bandwidth of memory to perform bilinear texture filtering with no performance penalty. The amount of texture memory is only limited by the maximum amount of Napalm frame buffer memory.
Host Bus Addressing Schemes: Napalm occupies a combined 256 Mbytes of memory mapped address space, using two PCI memory base address pointers. Napalm also occupies 256 bytes of I/O mapped address space for video and initialization registers. The register space of Napalm occupies 6 Mbytes of address space, the linear frame buffer occupies 128 Mbytes of address space, the ordered texture download port occupies 2 Mbytes of address space, and the 3D pipeline linear frame buffer takes 8 Mbytes of address space.
2D Architecture: Napalm implements a full featured 128-bit 2D windows accelerator capable of displaying 8, 16, 24, and 32 bits-per-pixel screen formats. Napalm supports 1, 8, 16, 24, and 32 bits-per-pixel RGB source pixel maps for BitBlts. 4:2:2 and 4:1:1 YUV colorspace are supported as source bitmaps for host to screen BitBlts. Napalm supports screen-to-screen and host-to-screen stretch BitBlts at 100 Mpixels/Sec. Napalm supports source and destination colorkeying, multiple clip windows, and full support of ternary ROP's. Patterned Bresenham line drawing with full rop support, along with polygon fills are supported in Napalm's 2D core. Fast solid fills, pattern fills, and transparent monochrome bitmap BitBlts in 8 bits-per-pixel, 16 bits-per-pixel, and 32 bits-per-pixel modes.
Linear Frame Buffer and Texture Access: Napalm supports linear frame buffer, texture download access, and 3D pipeline frame buffer access for software ease and regular porting. Multiple color formats are supported for linear frame buffer write. Any pixel may be written to the 3D pixel pipeline for fogging, lighting, alpha blending, dithering, etc. Texture maps can be downloaded into common Napalm memory either through standard linear frame buffer space, 3D pixel pipeline frame buffer access, or down through the ordered texture memory access address space.
Triangle-based Rendering: Napalm supports an triangle drawing primitive and supports full floating point hardware triangle setup. Triangle primitives may be passed from the CPU to Napalm as independent triangles, as part of a triangle strip, or as part of a triangle fan. Only the parameter vertex information is required by the host CPU, as Napalm automatically calculates the parameter slope and gradient information required for proper triangle iteration.
Additional drawing primitives such as spans and lines are rendered as special case triangles. Complex primitives such as quadrilaterals must be decomposed into triangles before they can be rendered by Napalm.
Gouraud-shaded Rendering: Napalm supports Gouraud shading by providing RGBA iterators with rounding and clamping. The host provides starting RGBA and DRGBA information, and Napalm automatically iterates RGBA values across the defined span or trapezoid.
Texture-mapped Rendering: Napalm supports full-speed texture mapping for triangles. The host provides starting texture S/W, T/W, 1/W information, and Napalm automatically calculates their slopes D(S/W), D(T/W), and D(1/W) required for triangle iteration. Napalm automatically performs proper iteration and perspective correction necessary for true-perspective texture mapping. During each iteration of triangle walking, a division is performed by 1/W to correct for perspective distortion. Texture image dimensions must be powers of 2 and less than or equal to 256. Rectilinear and square texture bitmpas are supported.
Texture-mapped Rendering with Lighting: Texture-mapped rendering can be combined with Gouraud shading to introduce lighting effects during the texture mapping process. The host provides the starting Gouraud shading RGBA as well as the starting texture S/W, T/W, 1/W, and Napalm automatically calculates their slopes DRGBA, D(S/W), D(T/W) required for triangle iteration. Napalm automatically performs the proper iteration and calculations required to implement the lighting models and texture lookups. A texel is either modulated (multiplied by), added, or blended to the Gouraud shaded color. The selection of color modulation or addition is programmable.
Texture Mapping Anti-aliasing: Napalm allows for anti-aliasing of texture-mapped rendering with support for texture filtering and mipmapping. Napalm supports point-smapled, bilinear, and trilinear texture filters. While point-sampled and bilinear are single pass operations, Napalm supports trilinear texture filtering as a two-pass operation.
In addition to supporting texture filtering, Napalm also supports texture mipmapping. Napalm automatically determines the mipmap level based on the mipmap equation, and selects the proper texture image to be accessed. Additionally, the calculated mipmap LOD may be biased and/or clamped to allow software control over the sharpness or "fuzziness" of the rendered image. When performing point-sampled or bilinear filtered texture mapping, dithering of the mipmap levels can also optionally be used to remove mipmap "banding" during rendering. Using dithered mipmapping with bilinear filtering results in images almost indistingusihable from full trilinear filtered images.
Texture Map Formats: Napalm supports a variety of 4-bit, 8-bit, 16-bit, and 32-bit texture formats as listed below:

4-bit Texture Formats        8-bit Texture Formats        16-bit Texture Formats        32-bit Texture Formats        
4-bit FXT1        RGB (3-3-2)        RGB (5-6-5)        ARGB(8-8-8-        
4-bit DXT1        Alpha(         ARGB(8-3-3-2)                
        Intensity(         ARGB(1-5-5-5)                
        Alpha-Intensity(4-4)        ARGB(4-4-4-4)                
        YAB(4-2-2)        Alpha-Intensity(8-                
        PalettedRGB(8 expanded to RGB 8-8-         Alpha-Paletted RGB(8-8 expanded to RGB 8-8-                
        PalettedRGBA(8 expanded to ARGB 6-6-6-6)        AYAB (8-4-2-2)                
        8-bit DXT2/3                        
        8-bit DXT4/5                        
Napalm includes an internal 256-entry texture palette, which can be downloaded directly from the host CPU or via a command to load the palette directly from texture memory. Either during downloads or rendering, software programs a palette offset register to control which portion of the texture palette is to be used.
Texture-space Decompression: Napalm supports a variety of compressed texture data formats. The advantages of using compressed textures are increased effective texture storage space and lower bandwidth requirements to perform texture filtering.
In one scheme, texture data compression is accomplished using a "narrow channel" YAB compression scheme. 8-bit YAB format is supported. The compression is based on an algorithm which compresses 24-bit RGB to a 8-bit YAB format with little loss in precision. The compression scheme is called "YAB" because it effectively creates a unique color space for each individual texture map - examples of potential color spaces utilized include YIQ, YUV, etc. This YAB compression algorithm is especially suited to texture mapping, as textures typically contain very similar color components. The algorithm is performed by the host CPU, and YAB compressed textures are passed to Napalm.
Napalm also supports the Microsoft/S3 "DXT" 4 and 8-bit compressed formats, as well as a 3dfx proprietary 4-bit compressed format known as "FXT1."
Depth-Buffered Rendering: Napalm supports hardware-accelerated depth-buffered rendering with minimal performance penalty when enabled. The standard 8 depth comparison operations are supported. To eliminate many of the Z-aliasing problems typically found on 16-bit Zbuffer graphics solutions, Napalm allows the (1/W) parameter to be used as the depth component for hardware-accelerated depth-buffered rendering. When the (1/W) parameter is used for depth-buffering, a 16-bit floating point format is supported. A 16-bit floating point(1/W)-buffer provides much greater precision and dynamic range than a standard 16-bit Z-buffer, and reduces many of the Z-aliasing problems found on 16-bit Z-buffer systems.
To handle co-planar polygons, Napalm also supports depth biasing. To guarantee that polygons which are co-planar are rendered correctly, individual triangles may be biased with a constant depth value - this effectively accomplishes the same function as stenciling used in more expensive graphics solutions but without the additional memory costs.
Pixel Blending Operation: Napalm supports alpha blending functions which allow incoming source pixels to be blended with current destination pixels. An alpha channel (ie. Destination alpha) stored in offscreen memory is only supported when depth-buffering is disabled. The alpha blending function is as follows:
Dnew Ü (S · a) +/- (Dold · b)
where
        Dnew        The new destination pixel being written into the frame buffer
        S        The new source pixel being generated
        Dold        The old (current) destination pixel about to be modified
        a        The source pixel alpha function.
The destination pixel alpha function.
Fog: Napalm supports a 64-entry lookup table to support atmospheric effects such as fog and haze. When enabled, a 6-bit floating point representation of (1/W) is used to index into the 64-entry lookup table. The output of the lookup table is an "alpha"value which represents the level of blending to be performed between the static fog/haze color and the incoming pixel color. Low order bits of the floating point (1/W) are used to blend between multiple entries of the lookup table to reduce fog "banding." The fog lookup table is loaded by the host CPU, so various fog equations, colors, and effects are supported.
3D Rendering Color Modes: Napalm supports 16-bit RGB (5-6-5), 15-bit RGBA (1-5-5-5) and 32-bit RGBA buffer display pixel depths. Internally, Napalm graphics utilizes a 32-bit ARGB 3D pixel pipeline for maximum precision. When running in 15 or 16 bpp color modes, the 24-bit internal RGB color is dithered to 15 or 16-bit RGB before being stored in the color buffers. When running in 32 bpp color mode, the data is stored directly into the frame buffer with no dithering applied.
Chroma-Key and Chroma-Range Operation: Napalm supports a chroma-key operation used for transparent object effects. When enabled, an outgoing pixel is compared with the chroma-key register. If a match is detected, the outgoing pixel is invalidated in the pixel pipeline, and the frame buffer is not updated. In addition, a superset of chroma-keying, known as chroma-ranging, may be used. Instead of matching outgoing pixels against a single chroma-key color, chroma-ranging uses a range of colors for the comparison. If the outgoing pixel is within the range specified by the chroma-range registers and chroma-ranging is enabled, then the frame buffer is updated with the pixel.

Color Dithering Operations: All operations internal to Napalm operate in native 32-bit ARGB pixel mode. However, color dithering from the 24-bit RGB pixels to 16-bit RGB (5-6-5) pixels is provided on the back end of the pixel pipeline. Using the color dithering option, the host can pass 24-bit RGB pixels to Napalm, which converts the incoming 24-bit RGB pixels to 16-bit RGB (5-6-5) pixels which are then stored in the 16-bit RGB buffer. The 16-bit color dithering allows for the generation of photorealistic images without the additional cost of a true color frame buffer storage area.

Programmable Video Timing: Napalm uses a programmable video timing controller which allows for very flexible video timing. Any monitor type may be used with Napalm , with 76+ Hz vertical refresh rates supported at 800x600 resolution, and 100+ Hz vertical refresh rates supported at 640x480 resolution. Lower resolutions down to 320x200 are also supported.

Video Output Gamma Correction: Napalm uses a programmable color lookup table to allow for programmable gamma correction. The 16-bit dithered color data from the frame buffer is used an an index into the gamma-correction color table -- the 24-bit output of the gamma-correction color table is then fed to the monitor

Video Overlay: Napalm supports one full featured video overlay that is unlimited in size, and supports pixel formats of YUV 411, YUV 422, RGB (1-5-5-5), RGB (5-6-5), and RGB (x-8-8- . The video overlay can be double, tripple or quad buffered, and can be bilinear scaled to full screen resolutions.

Video In: VMI video in port with complete host port is fully supported in Napalm. Video in is double buffered and can be optionally deinterlaced by replicating lines in a single frame or by merging 2 frames together.

PLL/DAC: Napalm contains 3 independent PLL's for clock generation. The PLL's are totally programmable giving the capability to change video, graphics, and memory clocks to any specified frequency. Napalm supports a high speed 300 Mhz RAMDAC, capable of doing 1600x1280 @ 76Hz refresh.
3.4        Modifications from SST1
Colbufsetup
Auxbufsetup
Chroma Range
intrCtrl, userIntrCMD
fbiTriangles register
Full triangle setup registers
Fogmode
Fogtable
fbzColorPath
fbzMode
increase of rendering window to -4k to 4k
Additional clip rectangle
Byte access lfb
New command fifo interface
Texture mirroring
Addition of VGA core
Addition of Video surfaces
Additional 6666 palettized texture format
Full featured 2D accelerator engine.
Separate filter controls for Alpha, and RGB.
Combined TMU unit
Increased blending fraction from 1.4 to 1.8.
Separate register / LFB byte swizzling for big endian machines.
PC '97 compliant

3.5        Additions to Avenger from Banshee
Higher core clock frequency = 143 MHz.
Graphics core and memory interface now all run on a master graphics clock.
300MHz RAMDAC.
0.25 micron, 5LM technology
452pin BGA
AGP 2x support
Deeper on-chip command fifo RAM to increase AGP command fifo performance.
Programmable watermarks for lfb/cmdfifo write fifo (pciInit0); can increase efficiency of command transport.
2 TMUs for to enable single-cycle special effects such as trilinear filtering, dual-texturing and bump-mapping.
tsplit functionality added back in to the TMUs.
Video fetch performance modification (controlled with CYA in vidProcCfg); boost video performance by making video fifo thresholds more effective.
Increased performance for minified textures (texture fetch engine was modified).
Adjustable delay for TV-out clock.
Support for simultaneous VMI and TV-out.
Additional internal status observability registers:cmdStatus0, cmdStatus1.
Removal of separate mclk domain (mclk domain is now gclk domain).
Two device ID's supported: 5=high-speed Napalm, 4=lower speed sort; different PLL programming is required depending on device ID: see section on PLL programming.

3.6        Additions to Napalm from Avenger
Higher core clock frequency = 166 MHz target
Support for AGP 4x bus protocol
Support for 32 and 64 MByte memory configurations
Support for true color (32-bit) 3D rendering
Support for 24-bit depth 3D rendering
Support for stencils during 3D rendering
Addition of Apple's 1555 mode in video and 3D rendering units
New texture and color combine blending modes
Alpha blend subtract mode
Max. 2k x 2k texture map size
32-bit textures
4-bit compressed textures (DXT and 3dfx proprietary)
Support for guardband clipping
Support for [-4k,4k] rasterization coordinate space
2 pixel-per-clock rendering for single textured triangles
Support for Scanline Interleaving
Support for Anti-Aliasing

3.7        Programming Notes on Avenger vs. Banshee
Video register changes per TV-out interface: addtion of (VidInStatusCurrentLine, vidTvOutBlankHCount, vidTvOutBlankVCount, vidInFormat, vidSerialParallelPortRegister, vidInYDecimDeltas)
Additional flushing code required around texture downloads (Maintaining Cache Coherency, section 18.3)
Additional texture download aperture: see Napalm Address Space and Command Packet 5 sections.
Software should try to tune video fifo watermarks to boost performance, given the enhanced video fetch logic.
Programming of PLL depends on device ID: id==5 -> m, n, k are all fully programmable; id==4 -> m is fixed to 0x24; see section 9.
Problem with VGA-space P6-style write combining is fixed.
Board Note: Because of the presence of an AGP pll, it is strongly recommended that the chip not be run in AGP pll bypass mode.
SDRAM fastfillCMD command must still be done by using just the color-plane fill.
Swapbuffer pending count logic is fixed, and will increment/decrement as described in the documentation.

Incredibile nn trovate!!!
Ciaoooo

già un singolo vsa è in grado di supportare l'agp 4x, ma per 2 si poveva il problema del carico elettrico troppo alto, che comunque non mi spiego vista l'alimentazione esterna...
x i 128mb ci si pensava anche qua, ma x adesso non se n'è fatto nulla...vuoi provare tu?;)

se vi interessa la Powercolor Voodoo 4 AGP 4x con DVI e Tv-Out la trovate ancora in vendita qui (insieme ad altre voodoo): http://www.ctcncomputers.com/Components/video.htm

STB   VOODOO 5 5500 64M SGRAM PCI 3DFX RETAIL $ 168.40
POWERCOLOR   VOODOO 4 4500 32M w/ TV OUT SDRAM AGP 3DFX OEM OR RETAIL $ 153.00

tanto per citarne un paio.
se vi venisse la tentazione, avevo gia' mandato una mail chiedendo delucidazioni, e chiedono 33 $ per la spedizione in Italia :)

ciao, nigel

i prezzi sono altissimi...

Se a qualcuno interessa magari per tentare l'aggiunta dei 32mb di ram gli posso vendere la mia 4500 agp 4x.questa è la sua foto

(https://www.forumzone.it/public/uploaded/200324135444_45001.JPG)

per non andare o.t mandatemi un pvt se siete interessati

Quanto ci vuoi fare della 4500??
Di dove sei??
Ciaooooooooo