 |
|
|
Atari demoscene BBS
| supervidel |
|
Posted by: marss
|
May,21.2004-21:35
|
i from Marss,
This is a message we got from our board from a man called Koshise. He explains his feelings about the supervidel. I allowed myself to edit it here for a feedback. The fist part in French, the other in English.
"Dites les jeunes, 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 |
> '--------' | '--------'
> ------||-----+-----[...]
|
[All messages in this thread] [Start new thread]
What's the anti-troll code? That's your personal code to be able to add comments and messages on the dhs.nu site.
Don't have a code or forgot it? Fix it here.
|
|
 |