GT Turbo (./48) :
D'abord salut Rodolphe,
A la base j'étais aussi interesser par une Firebee mais en fin de compte, je m'apercois d'une chose, bonne idée, sacrée boulot, mais l'esprit Atari n'y est plus, tout ce que je vois c'est du cross compiling, le TOS est relegué au fond de la salle. Donc il reste quoi de cette esprit ?
Moi j'adore ma CT60 et ma CTPCI, si je peux avoir la meme machine mais dans un boitier plus 'pratique' va t'on dire, je peux dire que OUI !! Car pour moi ca sera l'esprit Atari.
GT Supporter de ce nouveau produit !!
Sur le firebbe y a 2 trucs qui me gènent :
- c'est pas un 68060
- c'est un compatible STE, pas Falcon...
J'estime que le dernier micro d'atari c'est bien le Falcon et c'est en ça qu'il reçoit tous notre intéret depuis sa sortie : on y a cru ! Et pour cause, le DSP et ses tracks audio était là ! Bon VIDEL n'était pas assez innovant...
Aujourd'hui, un falcon sans DSP ce ne peut pas être un falcon !
Un ST sans MIDI ça n'est pas un ST !
DONC je reprend la MIDI et le DSP 100% compatibles avec le Falcon ! Sauf que , eh eh, le DSP56002 à 80 Mhz avec accès host depuis le 060 sans cette saloperie de bus 16 Mhz du Falcon...ca va un peu changer la donne ! Je vais mettre du posted registre : le 060 ecrit la donnée à 100 MHz et dégage immediatement et pendant qu'il exécuter quelques autres instructions, le DSP reçoit la données postée... ce qui va être intéressant c'est qu'on pourra poster les 24bits d'un coup de 32-bit (long) au lieu de 3 bytes au 3 adresses du port HOST ! Ceux qui se servent des transfers host DSP vont comprendre...
En fait je maitrise assez bien le codage de ce genre d'interface avec la CT60...en synchrone ou asynchrone même (vitesse clock différente de chaque côté)...
Faudrait même voir pour utiliser un MOVE16 pour bener 4 longs en burst dans un buffer hard qui s'occuperait ensuite de balancer les bytes dans le port host... intéret ? ben pendant ce temps le 060 fait autre chose, donc énorme décharge du 060 ! Car actuellement,, à chaque byte dans le host DSP, il prend des wait state dans la gueule et c'est du temps mort !!! on peut aussi appliquer le même principe de registres postés dans ABE, et donc on peut balancer en move16 vers le falcon 030 et laisser ABE decomposer derrière en 8 words vers la ST-ram... bon vu que je nzoushaite pas promotionner le falcon en lui même, je ne porterai pas d'effort sur ABE pour la carte mère... Si je coupe la pouire en deux, ce sera juste un long posté ce qui est déja énorme :
Actuellement le 060 qui R/W un long depuis/sur le falcon (STram) bouffe 4*62.5ns*2 = 500 ns, soit 50 cycles 100 MHz (c'est beaucoup !)...
Immaginons que il puisse faire ça sans WS, ca ferait 2 cycles 100 Mhz = 20 ns !
Soit 25 fois plus vite... Bien sur si il revient juste derriere pour un autre long et que ABE n'a pas fini de traiter le long versle falcon, alors il prend des WS...
Il faudra utiliser astucieusement le temps du 060 entre 2 long vers le falcon...
Je sais pas si ça servira à quelqu'un ... mais bon...c'est faisable... par contre en lecture on ne peut pas... car si le 060 lit un long en STram...on est obnligé de le garder en attente pour avoir les 2 words et les assembler... la solution sur les CPU modernes (comme les PPC) c'est qque le CPu lance l'ordre mais peut revenir plus tard chercher le résultat (dans notre cas le long pret), mais le 060 ne sais pas faire ça...