Dites les djeunes, faudrait pas faire comme le PC maniaque de base et se masturber sur des gros chiffres et/ou de grosses configs ! J'ai discuté un peu hard avec les concepteurs du SuperVidel, histoire de refroidir leur hardeur et leur candeur. C'est gentil de vouloir croire que not' bon vieux Falcon+CT60+SuperVidel va pouvoir concurrencer un Athlon XP 3200+ATI Radeon 9800 Pro, encore faudrait-il rester humble et avoir les pieds sur terre :
1600*1200*32 bits, c'est 7680000 octets, à raison de 90 Hz, c'est surtout un DAC et une mémoire capable de scanner 7.32 Mo * 90, soit 691200000 octets à la seconde (659.18 Mo/seconde). Partant du postulat que la mémoire est DDR (double accès par cycle d'horloge) et 32 bits (4 octets), ça nous fait 200000000 * 4 octets à 100 MHz, soit 800000000 octets par seconde (762.94 Mo/seconde).
Mathématiquement, ça passe (659.18 Mo/seconde tiens dans 762.94 Mo/seconde). Seulement s'il n'y a que le SuperVidel qui lit en DDR. Or l'intéret est aussi de pouvoir y écrire. Et celui qui y écrit, c'est le 68060 de la CT60, à raison de 66 MHz * 4 octets (bus 32 bits), soit 264000000 octets par seconde (251.77 Mo/seconde). 762.94 Mo/sec - 251.77 Mo/sec, soit 511,17 Mo/sec de libre pour acceder au DAC, y'a conflit, on n'arrive plus aux 90 Hz tant vantés (659.18 Mo/seconde), tout juste 70 Hz !!!
Ensuite, si on voulait VRAIMENT un jeux ou une démo qui tourne REELLEMENT à 90 Hz (en 1 VBL quoi...), il faudrait que la CT60 puisse AU MOINS écrire à 659.18 Mo/seconde dans la DDR, et la DDR de pouvoir lire derrière les 659.18 Mo écrit dans la même seconde pour alimenter le DAC. Ce qui demande déjà une CT60 à 172.8 MHz, et pas 66 MHz comme actuellement. Ensuite ça demande une DDR qui tienne les 1318.36 Mo par seconde (2 fois 1600*1200*32 bits*90 Hz, un coup pour écrire, un coup pour lire), soit une DDR elle aussi cadencée à 172.8 MHz (double accès - ça tombe bien mathématiquement, écriture sur front montant, lecture sur front descendant -, soit 345600000 * 4 octets, donc les 1382400000 octets par seconde).
Mais si la CT60 est cadencée à 172.8 MHz pour écrire à la bonne vitesse, il faudrait aussi qu'elle ai encore un peu de temps pour les calculs 3D et autres conneries. Résumons simplement la choses, ne soyez pas bêtes, ça donne un coup de fouets à nos applis ATARI, mais ça nous met pas au même pied d'égalité que nos confrêres PC.
L'ATARI, c'est bien mort, mais c'est encore tellement bon...
Kochise, nécrophile ATARIste convaincu !
PS : Un des mails original que j'ai écrit à Nature... Copiez le texte suivant dans un éditeur de texte à fonte non proportionelle (un bon vieux éditeur ASCII quoi)
[font police=courier new]
> > > > > > This is NOT a graphic processor, this is a BLITTER :
> > > > > >
http://www.acceleon.com/ -> Why not as a blitter on the SuperVidel card ?
> > > > >
> > > > > I took a look at their homepage but I couldn't quite tell wether they sell
> > > > > complete processor chips, or if they just sell licenses for the whole thing,
> > > > > so we would have to make our own chips. Either way, it wouldn't be cheap to
> > > > > use it I think, even if the specs seem quite good.
Another problem is that
> > > > > the SuperVidel card has a limited size of about 11x9 cm, which can not be
> > > > > increased due to the limited space inside the Falcon with a CT60 mounted. We
> > > > > have already had to take away two of the four DDR-SDRAM chips due to this,
> > > > > limiting the memory bandwidth to half its original value.
> > > > >
> > > > > But maybe it would be possible to make another expansion card for the CT60 bus
> > > > > in the future, using this chip? Can't promise anything though... ;-)
> > > >
> > > > Once a day I started a littler board which features a 1 MB flash memory to
> > > > upgrade the TOS. It was never finished but I sent the idea to Rodolphe.
> > > >
> > > > The board have chips on both sides, so you may add the two lasting DDR controlers
> > > > The Acceleon would be cool to avoid to make things by hand/CPU into the DDR memory
> > > > (copy, flood fill, ...) and thus leaving the 060 alone with its SDRAM while the
> > > > Acceleon works in the DDR.
> > > >
> > > > The idea would be to fill the DDR with datas and some commands, launch the Acceleon
> > > > like we could launch the DSP alone, and do some other tasks beside.
> > > >
> > > > As a coder in embedded graphics, I know that graphics operations are very bandwidth
> > > > consuming, so it would be great to speed up thing by adding a blitter on the SuperVidel
> > > > card. Especialy if you plan resolutions up to 1600*1200*32*75Hz -> 549.3 MB/s !!!
> > > >
> > > > A 8 channels 24 bits sound stream of 96 kHz weight 'only' 4.4 MB/s !
> > > >
> > > > The 060 only reach 69 MB/s on the SDRAM at 66 MHz ! The 060 is enough for music and
> > > > process, but definitively NOT for graphics :/ So something have to be done
> > > >
> > > > Kochise
> > >
> > > As a coder in embedded graphics, I know that graphics
> > > operations are very bandwidth consuming, so it would be
> > > great to speed up thing by adding a blitter on the
> > > SuperVidel card. Especialy if you plan resolutions up
> > > to 1600*1200*32*75Hz -> 549.3 MB/s !!!
> >
> > Yeah, I know.
I hope the bandwidth we're aiming at will
> > be enough, so it won't just be enough for displaying a
> > picture in 1600x1200. We have a 32 bit data bus, running at
> > (hopefully) 200 MHz. With DDR accesses, that gives
> > 200*2*4=1600 MB/s
>
> Wrong math, let me explain :
>
> When I wrote 549.3 MB/s, it was the bandwidth needed to feed
> correctly the DAC. With "hopefully" 1600 MB/s, it would leave
> 1050.7 MB/s free to write into the DDR !
>
> Imagine you want a 1600*1200*32*75Hz game at 1 VBL, you then
> need a processor able to write at 549.3 MB/s minimum, to write
> 75 1600*1200*32bits screens. The 060 with it's 70 MB/s is far
> from being able to achieve this, even if the bandwidth will be
> enough.
>
> Then you will have to second problem : RAM access priority !
> We have currently the problem with the Videl of the Falcon030.
> More the resolution is high, more the bandwidth is important
> beetween the Videl and the memory, leaving lesser and lesser
> time to the processor to access the video memory.
>
> What I see is soon the same problem, wait-states of the 060
> while waiting for the SuperVidel to scan the video memory,
> even if it will be faster than the EDO memory
>
> The solution I given you with the Acceleon (or could be a
> ColdFire with it's own graphic API) is to perform a multi-
> tasking video process :
>
> SIMPLE IDEA - DOUBLE BUFFER
>
> 64 bits | 64 bits
> ,--------, | ,--------,
> | | | | |
> CT60 -> | BANK 0 | | | BANK 1 | -> DAC (800 MB/s)
> | WRITE | | | READ |
> '--------' | '--------'
> |
>
> That would free the half of the memory for writing from the
> 060 without any wait-state, and a full access to the DAC for
> the second half of the memory. A bank switching would be
> aknowledged by the 060 at the end of the process -> RS or
> JK gate (switch on VSync).
>
> The best is a register to write in (4 bytes boundary -
> 30 bits to wire) to allow the bank switching on the next
> VSync, a read at this address tells the number of the bank
> currently accessible to the 060.
>
> COMPLEX IDEA - QUAD BUFFER + GPU
>
> 32 bits | 32 bits
> ,--------, | ,--------,
> | | - | |
> CT60 -> | BANK 0 | - | BANK 3 | -> DAC (400 MB/s)
> | WRITE | | | READ |
> '--------' | '--------'
> ------||-----+-----||------
> ,--------, | ,--------,
> | | | | |
> | BANK 1 | - | BANK 2 |
> | READ | - | WRITE |
> '--------' | '--------'
> 32 bits | 32 bits
> | | ^
> | |
> '---> GPU ----'
>
> For instance, the CT60 fills BANK 0 with some textures and
> commands for the GPU.
>
> The GPU read and process datas from BANK 1 and write the
> result in BANK 2.
>
> The DAC is currently displaying the content of BANK 3.
>
> At the next bank switching, a normal configuration would be
> to switch BANK 0/1 to feed the GPU with new datas, and
> BANK 2/3 to feed the DAC with the new screen to display.
>
> 1600*1200*32*60 Hz would be possible with a 233 MHz DDR memory
> and a 32 bits bus.
>
> The main idea would be :
>
> APEX IDEA - QUAD BUFFER + TWO 64 BITS BUS + GPU
>
> 64 bits | 64 bits
> ,--------, | ,--------,
> | | | | |
> CT60 -> | BANK 0 | | | BANK 0 | -> DAC (800 MB/s)
> | WRITE | | | READ |
> '--------' | '--------'
> -----| |----- | ----| |-----
> ,--------, | ,--------,
> | | | | |
> | BANK 1 | | | BANK 1 |
> | READ | | | WRITE |
> '--------' | '--------'
> 64 bits | 64 bits
> | | ^
> | |
> '-----> GPU ------'
>
>
> Here, the card would embed 2*32 MB of DDR -> 2 sets of
> 2*16 MB 32 bits. It would not be possible to switch between the
> 4 banks, but only the two on the CT60 side, and the two on the DAC
> side.
>
> The GPU, instead to have hard-wired ops like the Acceleon blitter could
> embed a flash rom with a nicely designed set of graphic function (matrix
> math, texture mapping, raster ops, ...) in order to perform some tasks.
>
> And why not a native OpenGL API ? With a bus close enough to PCI or AGP,
> the card would be sellable on PC computers too !
>
> That's my 2 euro cents !
>
[/font]
(Outline Party)
