Carte mère Falcon 030 recrée sous Eagle - Page 1

Très déçu par cet oiseau à sa sortie (trop lent), j'ai quitté le monde Atari en 1992 et continué ma route sur les ordinateurs Amiga. Les 1200 et 4000 étaient décevants aussi, mais extensibles...

Je me suis ensuite spécialisé dans la programmation asm 68k durant de très nombreuses années, et j'ai acquis une excellente expérience dans ce domaine passionnant...

J'aime bien aussi le hardware, mais moins doué hélas. Je connais bien Eagle de Cadsoft que je recommande à tous.

Bref, voici ma dernière création : une copie des schematics en utilisant ce logiciel moderne permettant la création d'une nouvelle PCB quasi identique à l'original revA...

J'ai quelques questions pour les spécialistes du Falcon :

- la broche 127 du MC68EC030FG16 (ou SC414230FE16) est-elle connectée au +5V ?
- la broche 4 du STMOD U4 (page 3) est-elle connectée à la GND ou à la AGND ?
- C49 (page 3) est-il connecté à la GND ou à la AGND ?
- quelle est la référence exacte du coil variable L61 (page 3) ?
- existe-t-il un équivalent aujourd'hui ?
- quelle est la référence exacte du delay line DL1 (page 3) ?
- existe-t-il un équivalent aujourd'hui ?
- pourquoi le 030 échange les données sur seulement 16 bits ?

- pourquoi le 030 échange les données sur seulement 16 bits ?

Apparemment la bécane avait été conçue initialement pour un 68000, puis ils sont passés au 68030 en adaptant.
Une personne d'ailleurs s'est refait (ou du moins un pré-prototype) une carte CPU mais cablée 32bits pour remplacer celle d'origine. Cette personne étant sur de nombreux projets je ne sais pas où en il en est là-dessus, cela a déjà 18 mois.

Ça aurait beaucoup changé les perfs ? 💡

Perso j’ai la nouvelle carte dbfx1 030, qui déconnecte le processeur du Falcon et qui passe tout en 32 bits avec possibilité de faire passer toutes les commandes en TTram.

jidewe (./4) :
Perso j’ai la nouvelle carte dbfx1 030, qui déconnecte le processeur du Falcon et qui passe tout en 32 bits avec possibilité de faire passer toutes les commandes en TTram.

Oui, j'avais vu, très intéresante !

Et ça influe comment sur les perfs ?

Brunni (./6) :
Et ça influe comment sur les perfs ?

Connais pas trop le Falcon, dépends des composants adjaçents...

J'ai trouvé ça :

A la grande question, pourquoi le FALCON a un bus DATA 16-Bit, voici l'hypothèse la plus probable:

Pour permettre un bus DATA 32-Bit pour le CPU et garder en même temps les performances avec l'entrelacement, il aurait fallu qu'Atari propose des configurations RAM de 2 ou 8 Mo. 2 est trop peu et 8, à l'époque, coûtait très cher...

Le 030 du FALCON accède en 4 cycles (16 MHz) à un banc. Un cycle dure 62.5 ns. Ceci nous fait 4 x 62.5 = 250 ns. Ca passe largement, même si la ram d'origine est de la 80 ns !

Le calcul de la bande passante de la ram (le nombre d'octets par seconde que l'on peut lire/envoyer de/dans la RAM) est le suivant:

1 WORD / 4 cycles d'horloge, soit 0.5 octets / cycles horloge.

Donc 0.5 x 16 000 000 = 8 Mo/s.

Ce que vous pouvez envoyer dans la RAM est une chose mais ce que le processeur peut faire en est une autre.
En effet, pour transférer entre de la RAM et un CPU, ce dernier doit exécuter des instructions. La plus utilisée est un bon vieux MOVE.L qui nécessite 5 cycles d'horloge sur 030 (2 sur 040) et ceci est bien évidemment la plus rapide pour lire. Du coup, ces 8 Mo/s ne sont que théoriques et la réalité en est un peu différente :

Sur un bus 16-Bit, le MOVE.L obligera le processeur à faire deux sorties sur le bus pour lire/écrire 2 WORDS. Heureusement, ce type de 'découpage' n'entraine pas de délais entre les deux WORDS.

De plus, il faut tenir compte du temps pris par les accès RAM pour alimenter le VIDEL. Ce temps peut prendre de 4 à 32 % de la bande passante du bus et donc réduire d'autant les performances d'accès du CPU.

Ce problème n'existe pas avec de la FAST-Ram puisque cette dernière n'est pas utilisée par la vidéo...

Prenons le cas du mode 640x480x2 couleurs (1 bit/pixel):

Le nombre d'octets à transférer de la RAM à VIDEL (c'est COMBEL qui se charge de les adresser) est de (640x480)/8 = 38400,soit 38400/4 = 9600 LONG (accès 32-Bit en RAM).
Le VIDEL reçoit ces LONG par BURST de 17 LONG.
Et le BURST se fait en 3, 1, 1, .....1, 1, 1 grâce au mode d'accès FAST-PAGE de la ram 80 ns.
Soit 9600/17 = 565 BURST (de 17 LONG),ce qui donne 565 x 19 = 10735 cycles pour une image.
Pour une seconde (60 images puisque 60 Hz en VGA), il faut compter 10735 x 60 = 644 100 cycles.
C'est en fait le temps pendant lequel le CPU ne peut pas profiter de la ST-Ram.
Ce qui représente 644 100 / 16 000 000 = 0.040, soit 4% !

En mode 16 couleurs, cela grimpe à 16% (4 bits/pixel), et en mode TC on atteint les 32% (16-Bit/pixel mais seulement 320 pixel/ligne); ce qui fait ralentir la machine !

Avec une CENTurbo, le bus du F030 passe à 25 MHz et on réduit ainsi à 20% pour le TC, 10.2% en 16 couleurs et 2.56% pour le mode 2 couleurs. On vous laisse calculer le mode 256 couleurs et découvrir une surprise...

Ainsi pour préciser les calculs, il faut compter:

16 000 000 - 644 100 = 15 355 900 cycles disponibles pour le CPU en mode monochrome 640x480.

Hmm ok, du coup on n'y perd pas trop en effet