Re: Falcon030 vs Amiga 1200

[TotOOntHeMooN]

Je ne parle pas de ça. Je parle de déclarer que le 68030 du Falcon est un 32/16 et le 68020 du 1200 un 32/24.
Il ne sait pas faire la différence entre une capacité d'adressage mémoire, et une largeur de bus mémoire lors des accès mémoire.

Ha ok... Quoi qu'il en soit, de base le Falcon a un bus d'adresse de 24bit et un bus de données de 16bit.
Là ou le A1200 a de base un bus d'adresse de 24bit et un bus de données de 32bit.

Avoir un bus d'adresse de 24bit n'est pas pénalisant en soit. Ca limite juste la capacité mémoire.
Mais à l'époque, pouvoir tourner en gros avec 16Mo de RAM c'était un luxe.

Par contre, avoir un bus de données tronqué empèche le 030 du Falcon de directement charger des registres de cette taille.
Après, ce n'est pas nonplus critique, sachant que son DSP et sa FPU sont pleinement cablées, elles.

En passant, évidemment, est occulté le fait que, à fréquence égale, un 68030 est plus rapide qu'un 68020.

Oui, mais ce n'est pas vrai pour le Falcon, car son bus de données est tronqué et le mode burst inutilisable

Sans rire, ne même pas regarder les wikis pour sortir un commentaire anti Atari, ça ne mérite pas spécialement ma courtoisie. Notez les rimes : je suis un pouet. Prout sur l'A1200, vive le Falcon.

Les Wiki... Pas vraiment une référence, vu que tout le monde va mettre ce qu'il croit être juste...
Il vaut mieux regarder les datasheets des différents fabricants, pour peut qu'on sache les décrypter.

[babsimov]

Hey Babsimov prends des cours sur les CPUs.
Tu ne sais pas faire la différence entre un espace d'adressage, et une largeur de bus mémoire.
C'est grave quand même.

Il ne se trompe pas. C'est bien l'espace d'adressage d'une CPU qui définie la quantité de mémoire directement accessible.
C'est d'ailleurs pour cela qu'il est possible d'ajouter bien plus de mémoire avec une carte accélératrice sur bus 32bit.

Je ne parle pas de ça.
Je parle de déclarer que le 68030 du Falcon est un 32/16,
et le 68020 du 1200 un 32/24.
Ridicule.
Il ne sait pas faire la différence entre une capacité d'adressage mémoire, et une largeur de bus mémoire lors des accès mémoire.
Comme c'est nase.
Tout ça pour dénigrer le Falcon.

Je ne suis pas expert en hardware, mais je sais lire entre les lignes les tests dont je donne les liens (relit). Je savais déjà à l'époque la différence entre un processeur 16/32 bits (68000) et un 32/32 (à partir du 68020). Je n'aurais pas su l'expliquer en détail techniquement, mais je comprenais parfaitement que si en interne un processeur fonctionne en 32 bit, s'il doit communiquer en 16 bit avec l'extérieur il est donc ralentit.

Si j'ai volontairement indiqué que le 68030 du Falcon était 32/16 bits, c'est justement pour montrer comme l'article de STFormat (comparatif entre Falcon et Amiga 1200) laissait entendre que le 68EC020 du 1200 n'était pas vraiment un vrai 32 bit, mais un 24 bit, alors que le 68030 du Falcon était lui un vrai 32 bits.

Ils passent sous silence le fait que le 68EC020 du 1200 est bien un vrai 32 bits (interne et externe) sur un bus 32 bits, là ou le Falcon a un vrai processeur 32bits (68030) mais avec un bus 16 bits (et ça c'est totalement partial de la part de STformat, qui maquille et arrange les faits à sa sauce).

Je l'ai déjà dit maintes fois dans ce sujet et dans d'autres, je n'ai aucune raison de descendre le Falcon pour descendre le Falcon. C'est la seule machine Atari (époque Jack Tramiel) que je trouve intéressante et je dirais même que j'envie à la communauté Atari, en particulier à cause du DSP.

Au départ on me reprochait d'avoir donné un test du Falcon par AmigaNews. J'avais parlé auparavant d'un test d'un revue Atari entre le Falcon et le 1200 qui avait été cité dans un autre sujet. Comme le test d'AmigaNews pointait justement la "lenteur" du Falcon de base à cause du bus 16 bits... On m'a dit "c'est partial", parce que le 1200 de base sortait vainqueur.

Le test de la revue Atari (et je l'avais indiqué) donnait des résultats inverses. Falcon de base devant le 1200, mais Amiga 1200 avec Fast plus rapide qu'un Falcon 4MO (taille mémoire équivalente).

J'ai fait l'effort de rechercher dans le sujet ST vs Amiga le lien (qui malheureusement n'amène plus à ce test). J'ai recopié une partie du texte du test d'origine qui avait été cité à l'époque.

Et pour retrouver le test j'ai fait une recherche google avec le nom du test (celui du lien). C'est là que j'ai trouvé le test de STFormat. J'ai mis le lien, parce que, justement CE test là était totalement partial et biaisé.

Le premier test de la revue Atari était de mémoire largement plus honnête, car il pointait les qualités et défaut réels de chacune des machines. Le test d'AmigaNews me parait aussi tout à fait honnête. D'ailleurs, comme je l'ai fait remarquer, ce sont deux tests par des Amigaïstes qui évoquent avec surprise la consommation mémoire "excessive" du MultiTOS rien que pour se lancer et avoir du multitâche. Pas souvenir qu'un test d'une revue Atari (ceux que j'ai lu ici) parle de cela, alors que ça me parait quand même une information qu'un acheteur devrait connaître en connaissance de cause. Pourquoi, parce que, selon les propos des testeurs Amiga, sur un Falcon 4MO, il ne reste après MultiTOS lancé que 1 MO d'utilisable !!!! Autant dire que celui qui espérait avoir 3/4 MO pour ses applications en multitâche, il faudra qu'il s'oriente vers la version 14 MO pour avoir une bonne marge.
Note que j'ai trouvé cette information un peu surprenante et que j'ai demandé ici si quelqu'un pouvait confirmer ou mieux vérifier avec vidéo à l'appui.

En passant, évidemment, est occulté le fait que, à fréquence égale, un 68030 est plus rapide qu'un 68020.
Sans rire, ne même pas regarder les wikis pour sortir un commentaire anti Atari, ça ne mérite pas spécialement ma courtoisie.
Notez les rimes : je suis un pouet.
Prout sur l'A1200, vive le Falcon.

Comme je t'ai dit ce n'est nullement un commentaire anti-Atari, c'est plutôt un article anti Amiga 1200 et biaisé auquel j'ai réagit.

Je sais lire wiki. J'ai souvent donné des tas de liens wiki ici, souvent, justement, pour rectifier les approximations et raccourcis rapides de certains AtariSTes sur l'Amiga ou d'autres machines appelées à la rescousse du ST pour "descendre" l'Amiga et qui au final ne s'avéraient pas aussi folichonnes que ça face à un Amiga.

Je peux comprendre que tu es réagit vertement si tu as pensé que c'était une critique gratuite d'une de tes machines préférées. J'ai aussi été plus d'une fois énervé de lire certaines choses et raccourcis bidons au sujet de l'Amiga. 

Mais, ma réponse n'était nullement une critique du Falcon, mais bien de la façon dont l'article cité arrange les faits pour justement démolir l'Amiga et passer sous silence le bus 16 bit du Falcon. Tu es bien d'accord que le 68030 du Falcon a un bus 16 bits ? Ce serait pour raison de compatibilité ST, mais le 68030 lui est bien un 32 bit interne et externe, je le sais depuis sa sortie (Les articles d'époque avaient suffisamment bien vulgarisé cela pour que ce soit clair).

Le test en question
http://www.stformat.com/news/news-450.html

Et la phrase qui m'a fait réagir (je l'avais déjà cité) :

"The main processor in the A1200 is a Motorola EC68020 running at 14MHz, while the chip has embedded internal 32-bit buses, it only has an external 24-bit address bus and built-in instruction cache. The EC68020 is normally restricted to clock speeds of 16 and 25MHz, so why did Commodore use only 14MHz to run their machine? The Motorola 68030 has full 32-bit internal and external addressing along with both instruction and data caches, thus increasing the processing speed of the chip."


J'ai donc mis en gras la façon dont STFormat biaise les choses :
Le 68020 pour eux est 32 bits en interne et 24 bit en externe (ils disent bus d'adresse c'est exact en fait).
Mais après, la manière dont le 68030 est présenté il est dit qu'il adresse en 32 bit en interne et externe. Sous entendu le 68020 non... puisque le lecteur va retenir pour le 68020 internal 32 bit et external 24 bit (même si dans ce cas c'est l'espace mémoire adresse et non la largeur du bus externe du 68020 (qui lui est en 32 bits comme le 68030). Bref STFormat fait passer le 68020 de l'Amiga 1200 pour un faux processeur 32 bits, un mauvais choix, tout en passant sous silence qu'en fait c'est Atari qui a bridé le bus externe 32 bits du 68030 par un bus 16 bit. Voilà pourquoi j'ai traduit leur texte en disant que selon eux le 68020 est 32/24 bits et donc j'ai dit volontairement qu'en réalité le 68030 dans le Falcon se retrouve de fait être un 32/16 bits (à cause du bridage du bus 16bits).

Et comme je l'avais fait remarquer aussi, pour descendre encore un peu plus le choix de Commodore, on nous dit que le 68EC020 peut normalement fonctionner à 16 ou 25 mhz alors pourquoi l'avoir (sous entendu) bridé à 14 mhz... 

Pour moi cet article STFormat n'est rien d'autre qu'un article de "propagande" pour conforter la communauté Atari dans le fait qu'Atari fait toujours les meilleurs choix techniques... 
Tu es d'accord qu'on a déjà vu sur d'autres sujet que plusieurs des choix techniques du ST sont discutables, ainsi que le bus 16 bits dans le Falcon ? Comme d'ailleurs certains choix dans l'Amiga 1200. 
Pour la première génération Amiga 500/1000/2000 on ne peut pas reprocher grand chose au hardware. J'accepte par contre quelques critiques à la marge sur l'OS pour faire plaisir à la communauté ST.

EDIT : Plusieurs réflexions/questions me sont venues au sujet du bus 16 bit du Falcon et de la compatibilité ST :
- Si le bus 16 bits du Falcon a été mis là pour rester compatible ST, doit on en conclure que le TT qui (sauf erreur de ma part) avait lui un vrai bus 32 bits n'était pas compatible avec toutes la logithèque du ST (je pense bien entendu aux jeux, je suppose que pour le reste pas de problème) ?
- En quoi un bus 16 bit dans le Falcon le rendait plus compatible avec le ST ? Je m'explique sur Amiga 1200 qui avait donc un bus 32 bits, les jeux OCS/ECS n'étaient pas dérangés par cela. Par contre c'était le cache du 68020 qui pouvait poser problème et l'AGA. Commodore avait donc inclus le fameux "early boot menu" avec lequel on pouvait désactiver le cache du 68020 (il restait cependant 32 bits interne/externe) et choisir entre OCS/ECS et AGA (best available pour être précis).
- Donc qu'est ce qui aurait empêché Atari de donner au Falcon un bus 32 bits pour exploiter au maximum son 68030 au lieu de le sous exploiter en lui imposant un bus trop petit pour lui ? Je veux dire il leur aurait suffit d'un système similaire à celui de l'Amiga 1200 et voilà ? 
- Parce que, quitte à ne pas pouvoir exploiter les plus du 68030, comme le mode burst (déjà mentionné dans une autre réponse), autant avoir mis un 68EC020 à 25 mhz, car du coup le 68030 dans le Falcon est plus proche du fonctionnement d'un 68020 que d'un 68030. Certes il a la MMU intégrée. Serait ce cela qui a plus ou moins obligé Atari à utiliser un 68030 ? J'avais cru comprendre que la MMU (qui n'est est pas une en fait) dans le ST ne gérait que 4MO de mémoire. La MMU du 68030 servait elle à permettre au Falcon d'aller au delà des 4MO du ST (je veux dire de permettre au TOS de voir au delà) ?
Je précise que ce sont des questions qui me paraissent légitimes et non des attaques en règle contre le Falcon. Car sans cette histoire de bus 16 bits, sur le papier y a pas photo un Falcon en jette davantage qu'un Amiga 1200 (et pourtant je n'aurais pas acheté autre chose qu'un Amiga à l'époque, à cause de l'AmigaOS).

J'espère qu'après la lecture de cette longue réponse mon propos te parait plus clair (EDIT, y compris après le EDIT qui, là aussi, j'espère ne sera pas mal interprété).

[ChistopheS]

Tu tentes la course sur piste savonneuse on dirait.
Au lieu de divaguer, disserter, autant rappeler les faits.
Voilà comment lire un descriptif de CPU :
Longueur, en bits, du mot lu par défaut par le CPU / capacité d'adressage mémoire, en bits, du CPU.(2^ce chiffre te dit la quantité de RAM que le CPU peut aller lire).

Le bus mémoire n'entre nul part en ligne de compte dans cette écriture valeur1/valeur2.
Ou alors on appellera cette nouvelle convention l'écriture à Baba.

De plus puisque le Falcon a un 68030 avec du cache, plus qu'un 68020, très certainement avoir un bus mémoire 16 bits ne doit pas être si pénalisant que cela.
Pas autant que si c'était un 68020 avec bus mémoire 16 bits.
Par exemple en cas de lecture multiple en mémoire pour remplir les registres, ça ne m'étonnerait pas que bus mémoire 16 bits + cache du 68030 donnent de meilleurs résultats que bus mémoire 32 bits avec moins de cache du 68020.
En tout cas je n'affirmerais rien.
Il faudrait vérifier, mais par pitié, pas d'affirmation sans vérification.
Quand tu as écrit 'Et ça c'est vrai.' et bien non : tout faux mon ami.

Pour l'Amiga et ses CPU toujours downclockés, ben oui, on peut considérer que c'est quand même très con de brider un CPU, non ?
Tout ça car ces bécanes ont des chipsets qui fonctionnent cadencés sur des fréquences de balayage écran.
J'avoue ne jamais avoir compris pourquoi C= n'avait pas un peu plus creuser pour avoir leurs CPUs en full speed, et derrière avec des multiplicateurs et diviseurs tout de même eu un chipset fonctionnant sur fréquence de balayage écran.
Peut ètre trop cher, ou alors de temps à autre on était très légèrement en décalage, et ça ne passe pas.
C'est un peu comme si tu avais un moteur 24 soupapes, mais bon, pour que les essuie glasses fonctionnent vraiment bien, on t ôte le fonctionnement de 3 soupapes.
C'est quand même risible.

Au fait je rappelle à nouveau :
A fréquence égale le 68030 est plus rapide que le 68020.
Et oui, que C= ait pris la version éco du 68020, qui ne peut adresser que 2^24 bits, au lieu de 2^32, tout ça pour économiser quelques dollars, c'est très bof ; surtout quand pas de DSP, et pas d'Akiko. Se sont pas trop foulés les ingénieurs pour le concevoir, le 1200.
Quel gâchis alors que les PCs arrivaient en force.
Atari s'est un peu plus cassé la tête, machine avec DSP, et puis un chip vidéo aux caractéristiques intéressantes, planar et linear.
C= n'aura même pas fait l'effort de faciliter le développement de jeux 3D (ni Akiko, ni grosse puissance de calculs (Cpu faiblard, pas de dsp ), ni modes linear).
Et Paula, toujours que du 4 canaux avec séparation stéréo extrêmes.
Le prix était bien, mais bon ça ne valait pas plus.
Sans carte accélératrice le 1200 ça reste une blague, sympa pour jouer et regarder des démos, mais pour le reste il ne faut pas trop lui en demander.
Avec le Falcon, on piuvait envisager tout autre chose, avec une machine qui de base en a sérieusement sous le clavier, et bien positionné niveau prix quand on voit tout ce qu'elle offre en standard.
Dommage je n'en ai jamais eu un.
J'ai pris un 1200 quand il était bradé, et je lui ai mis une carte accélératrice pour ne pas me morfondre de sa lenteur en hi res.
Et puis très vite il a fini au placard pour un DX4/100 avec une Gravis Ultrasound.
Rhhaaa la Dope avec ses 28 canaux ...

Je relisais un coup et j'édite : faire croire que l'accès à la mémoire du Falcon, avec son bus 16 bits, va être 2 fois plus lent que celui du 1200 avec son bus 32 bits, c'est méconnaitre la programmation.
Jamais tu ne fonctionnes en permanence sur mots 32 bits parceque tu as un système 32 bits.
Exemple : traiter des tables. En 8 ou en 16 bits c'est bien suffisant.
Tu ne prendras pas 32 bits pour gaspiller ta mémoire.
Afficher 1 pixel en mode hi res : 16 bits ça suffit.
Etc etc la liste est bien longue, et comme je l'ai dit, avec un cache supérieur pour le 68030, même si sur accès 32 bits il y aura des cycles d'accès mémoire supplémentaire, au niveau des cycles de décodage pour l'ensemble des instructions, le 68030 sera le plus rapide.
Tout ça à vérifier, mais bon le cache va servir à ça. Est conçu pour ça. Faut vérifier s'il est en cache données, ou en cache processeur.

[TotOOntHeMooN]

...

S'il y en a un qui divague pour le coup, c'est bien toi.
Tout ce que tu dis est uniquement valable si le 030 était pleinement câblé sur le Falcon... Ce n'est pas le cas.

Le 68030 n'est qu'une révision du 68020, pas une nouvelle architecture. Il est gravé plus fin, pour monter en fréquence, peut intégrer la MMU si besoin et passe à 256 octets de cache. Ce dernier élément n'est pas suffisant pour gagner quoi que se soit en performance avec un traitement sur 32bit sur une CPU castrée...

La réalité, c'est qu'il va prendre deux fois plus de cycles à fréquence égale pour charger ces registres.
Il est donc plus lent qu'un 020 à même fréquence dès lors qu'il faut traiter des opérations sur des LONG et que la valeur à (ré)utiliser n'est pas chargée... Ce qui est très souvant le cas mine de rien.

Je me répète (mais tu ne m'a pas lu), ce n'est pas tant pénalisant car le Falcon à une architecture qui repose sur le DSP.

[ChistopheS]

Le 68020 a un cache instructions de 256 octets.
Le 68030 a un cache instructions de 256 octets ET un cache données de 256 octets.
Ainsi comme je le disais le fait d'avoir un bus mémoire 16 bits ne va pas être autant pénalisant que si c'était un 68020 (les données sont mises en cache, sur le Falcon. Pas sur le 1200).

Et oui bien sûr qu'avec un DSP tout ce qui est traitement de données va aller au DSP, et pas au CPU.
En bref les pro Amiga dénigrent le Falcon qui a un vrai copro, c'est à dire un DSP avec ses 16 MIPS, là où ils vont vanter leur chipset moisi face aux possesseurs d'Atari ST.
Aucune logique à tout cela.
Ridicule.

[babsimov]

Tu tentes la course sur piste savonneuse on dirait.
Au lieu de divaguer, disserter, autant rappeler les faits.
Voilà comment lire un descriptif de CPU :
Longueur, en bits, du mot lu par défaut par le CPU / capacité d'adressage mémoire, en bits, du CPU.(2^ce chiffre te dit la quantité de RAM que le CPU peut aller lire).

Le bus mémoire n'entre nul part en ligne de compte dans cette écriture valeur1/valeur2.
Ou alors on appellera cette nouvelle convention l'écriture à Baba.

Je ne divague pas en disant que le Falcon a son 68030 (32 bit interne et externe) sur un bus 16 bit. Ce sont des faits. Mon propos était de réagir à l'article de STFormat qui laisse entendre que le 68EC020 de l'Amiga 1200 lui serait en fait un 32 bit interne et 24 bit externe... tout en passant sous silence le fait que sur le Falcon le 68030 (32 bit intégral) est connecté à la machine par un bus 16 bits... 

Je ne suis pas programmeur donc je ne peux pas te suivre dans une discussion trop technique. Par contre relis le comparatif d'AmigaNews, tu verras qu'il semble bien que ce bus 16 bit pénalise le Falcon face à un Amia 1200 de base.

http://obligement.free.fr/articles/falcon030.php

Par contre un test dans une revue Atari disait exactement l'inverse. Peut être ont il utilisé les cas particuliers qui faisaient que le bus ne dérangeait pas le test. J'ai toujours eu confiance, pour ma part, dans les articles d'AmigaNews. En général leur avis/critiques/conseils sur tel ou tel logiciel/matériel était tout à fait pertinents. 

De plus puisque le Falcon a un 68030 avec du cache, plus qu'un 68020, très certainement avoir un bus mémoire 16 bits ne doit pas être si pénalisant que cela.
Pas autant que si c'était un 68020 avec bus mémoire 16 bits.
Par exemple en cas de lecture multiple en mémoire pour remplir les registres, ça ne m'étonnerait pas que bus mémoire 16 bits + cache du 68030 donnent de meilleurs résultats que bus mémoire 32 bits avec moins de cache du 68020.
En tout cas je n'affirmerais rien.
Il faudrait vérifier, mais par pitié, pas d'affirmation sans vérification.
Quand tu as écrit 'Et ça c'est vrai.' et bien non : tout faux mon ami.

Mon cher ami, comme dit, le bus 16 bits du Falcon, c'est un fait établit. Je n'y peux rien. Pour le fait que ce soit pénalisant, je t'invite à te reporter au test d'AmigaNews. 

D'ailleurs je n'empêche aucun AtariSTe à faire un test comparatif entre un 1200 de base et un Falcon de base avec la même routine assembleur pour nous apporter des éléments de réponse (vidéo à l'appui, bien sur).

Tu nous parles d'un 68020 sur un bus 16 bits, peut être. Je remarque juste que les ingénieurs de Commodore n'ont pas fait l'erreur dans une machine 32 bits de connecter leur processeurs 32 bit intégral sur un bus 16 bits (3000/1200/4000).

On peut leur reprocher (enfin c'est à cause de la direction) d'avoir mis un 68040 sur un bus de 68030 qui sous exploite le 68040 (je ne peux pas entrer dans un débat trop technique sur ce point, mais je ne fais que reprendre les propos de Dave Haynie au sujet du 4000 et de la carte 3640 qui était selon lui la pire carte 68040 du marché. Parenthèse, au moment du lancement du 3000, Commodore avait la première carte 68040 au monde prête pour intégration dans le 3000, avec du cache etc... bref exploitant pleinement le 68040. Ce processeur n'étant officiellement pas encore commercialisé Commodore avait du demander à Motorola l'autorisation de montrer la carte avec le lancement de l'Amiga 3000. Motorola a accepté, la direction de Commodore, à la dernière minute à "jugé" que ça aurait fait de l'ombre à l'Amiga 3000... C'est certain que vu "l'avancée" technologique de l'ECS, avoir au moins une première mondiale en compensation ça aurait pas fait de mal à l'Amiga... Une décision stupide de plus !!! Mais c'était un peu hors sujet.

EDIT (après réponse à Ryoseba) : Puisque tu parles de 68020 sur un bus 16 bit sur Amiga, j'ai fait un peu de recherche. Je pense que le plus proche de cela que j'ai pu trouver est la carte LUCAS domaine public qui était sortit pour Amiga en 1989 :

http://obligement.free.fr/articles/lucas68020.php

Et maintenant, voici un comparatif des performances de cette carte face au nouveau Amiga 3000 (full 32 bits) :

http://obligement.free.fr/articles/amiga3000.php
Et l'article original :
http://download.abandonware.org/magazines/Amiga%20News/amiganews_numero25/A-News%20025%20-%20Page%2028%20%281990-05%29.jpg

Si je comprend bien le 3000 complètement 32 bits est au moins deux fois plus rapide (ce qui est logique). Par contre, dans le test ils parlent de kickstart en 32 bits (la LUCAS utilisée aurait donc un peu de mémoire 32 bits pour y reloger le kickstart ?). Ce point n'est pas clair.

De plus je viens de voir qu'Obligement avait mal recopié puisque le 68020 de la LUCAS n'avait pas été testé à 25 mhz, mais 20 mhz (article original).

Aux connaisseurs des 68020/68030, est ce qu'un 68020 avec mémoire 32 bits à 20 mhz peut être globalement deux fois moins performant qu'un 68030 à 25 mhz avec mémoire 32 bits ? Ou ces performances d'un 68020 sont elles conformes à un 68020 avec uniquement de la mémoire 16 bit ?

Note : je vais prévenir Obligement du problème de recopie sur leur site. Je précise afin qu'on aille pas dire ensuite, quand l'article aura été rectifié, que je racontais n'importe quoi.

Pour l'Amiga et ses CPU toujours downclockés, ben oui, on peut considérer que c'est quand même très con de brider un CPU, non ?

Non, pas toujours downclockés. Les modèles desktop avaient des processeurs aux fréquences officielles Motorola (2500/3000/4000). Ce sont les modèles d'entrée de gamme qui étaient downclockés. Une question de réduction des coûts si j'ai bien compris. D'ailleurs on ne peut pas leur en vouloir, puisqu'il y avait le chipset à côté pour compenser. 

Mais, si tu veux aller sur ce terrain, dans le sujet ST vs Amiga, tu pourras retrouver qu'un 68000 à 16 mhz sur un Amiga 500 fonctionnait à sa pleine vitesse, alors qu'un 68000 à 16 mhz dans un Mega ST ne fonctionnait en fait qu'à 50 % de sa vitesse, justement à cause de l'architecture interne du ST qui faisait que le 68000 perdait toujours des cycles même quand ce n'était pas nécessaire. Sur Amiga, ce n'était pas le cas.
Ce n'est pas moi qui ait expliqué cela, c'était Stapha92 qui connait très bien les deux machines.

Tout ça car ces bécanes ont des chipsets qui fonctionnent cadencés sur des fréquences de balayage écran.
J'avoue ne jamais avoir compris pourquoi C= n'avait pas un peu plus creuser pour avoir leurs CPUs en full speed, et derrière avec des multiplicateurs et diviseurs tout de même eu un chipset fonctionnant sur fréquence de balayage écran.

Peut ètre trop cher, ou alors de temps à autre on était très légèrement en décalage, et ça ne passe pas.
C'est un peu comme si tu avais un moteur 24 soupapes, mais bon, pour que les essuie glasses fonctionnent vraiment bien, on t ôte le fonctionnement de 3 soupapes.
C'est quand même risible.

Il y avait déjà un diviseur dans le chipset, mais comme tu le supposes c'était bien pour une question de coût pour les 500/1200. Les autres modèles avait leur propres quartz pour le processeur qui fonctionnait comme tu dis en full speed.

Au fait je rappelle à nouveau :
A fréquence égale le 68030 est plus rapide que le 68020.
Et oui, que C= ait pris la version éco du 68020, qui ne peut adresser que 2^24 bits, au lieu de 2^32, tout ça pour économiser quelques dollars, c'est très bof ; surtout quand pas de DSP, et pas d'Akiko. Se sont pas trop foulés les ingénieurs pour le concevoir, le 1200.
Quel gâchis alors que les PCs arrivaient en force.

Le 68020 est un full 32 bits (interne et externe), comme le 68030. La c'est toi qui raconte n'importe quoi, ou alors je n'ai pas compris ta phrase.

Par contre, nous sommes d'accord, le 1200 n'a pas apporté assez (ou trop peu). Je doute que tu trouves un Amigaïste qui te dira le contraire. Mais ce n'était pas ce que les ingénieurs voulaient sortir pour la génération AGA. Je l'ai déjà dit plus d'une fois. Ce qui devait sortir c'était le 1000+ et le 3000+ (avec DSP) :

http://obligement.free.fr/articles/amiga3000+_coulisses.php
http://www.amigahistory.plus.com/prototypes/1000plus.html

Et si tu regardes les liens, ont dit bien que c'était des modèles à 25 mhz (même pour l'entrée de gamme).

Atari s'est un peu plus cassé la tête, machine avec DSP, et puis un chip vidéo aux caractéristiques intéressantes, planar et linear.

Nous sommes d'accord, le Falcon et surtout avec son DSP faisait plus rêver. Enfin pour moi il lui manquait l'AmigaOS.

EDIT de relecture : C'est d'autant plus dommage qu'Atari a cherché à proposer quelque chose d'intéressant, d'avoir bridé son processeur avec ce fameux bus 16 bit. S'il n'y avait pas eu ce bus 16 bits, nous ne serions pas là à débattre. Les tests d'époque auraient donné le Falcon vainqueur du 1200 sans discussion possible. Atari, comme à l'époque du ST, s'est mis une épine dans le pied par des décisions de conception.

Comme déjà dit, en quoi un bus 16 bit rendait le Falcon plus compatible avec le ST ?

C= n'aura même pas fait l'effort de faciliter le développement de jeux 3D (ni Akiko, ni grosse puissance de calculs (Cpu faiblard, pas de dsp ), ni modes linear).
Et Paula, toujours que du 4 canaux avec séparation stéréo extrêmes.
Le prix était bien, mais bon ça ne valait pas plus.
Sans carte accélératrice le 1200 ça reste une blague, sympa pour jouer et regarder des démos, mais pour le reste il ne faut pas trop lui en demander.

Ce n'est pas ce qui aurait du sortir (voir plus haut). Mais je suis d'accord, l'AGA était loin d'être au niveau de l'OCS à sa sortie en terme d'avancée technologique.

Je ne dis pas qu'une carte accélératrice n'apportait pas un certain confort, mais je suis resté un an avec un Amiga 1200 de base (avec disque dur) et je peux t'assurer que j'ai vu une réelle différence avec mon Amiga 500 avec disque dur pour un usage bureautique. 
Bien sur, dès que j'ai eu ma carte accélératrice j'ai vu une belle différence aussi.

Avec le Falcon, on piuvait envisager tout autre chose, avec une machine qui de base en a sérieusement sous le clavier, et bien positionné niveau prix quand on voit tout ce qu'elle offre en standard.
Dommage je n'en ai jamais eu un.

C'est surtout dommage qu'Atari ait abandonné le Falcon quasiment à sa sortie et que les AtariSTe n'aient pas suivi. Note que je n'aurais pas acheté un Falcon, trop content de mon AmigaOS, mais si le Falcon avait eu un certain succés, ça aurait obligé Commodore à sortir le DSP promis.

J'ai pris un 1200 quand il était bradé, et je lui ai mis une carte accélératrice pour ne pas me morfondre de sa lenteur en hi res.
Et puis très vite il a fini au placard pour un DX4/100 avec une Gravis Ultrasound.
Rhhaaa la Dope avec ses 28 canaux ...

Certes la gravis ultrasound c'était autre chose, mais c'était aussi très cher ta configuration face à un 1200 et tu te retrouvais avec un MS/DOS, Windows 3.1... (bof) ou un Windows95 bancale (enfin sur un DX4/100 bon courage).

Je relisais un coup et j'édite : faire croire que l'accès à la mémoire du Falcon, avec son bus 16 bits, va être 2 fois plus lent que celui du 1200 avec son bus 32 bits, c'est méconnaitre la programmation.
Jamais tu ne fonctionnes en permanence sur mots 32 bits parceque tu as un système 32 bits.
Exemple : traiter des tables. En 8 ou en 16 bits c'est bien suffisant.
Tu ne prendras pas 32 bits pour gaspiller ta mémoire.
Afficher 1 pixel en mode hi res : 16 bits ça suffit.
Etc etc la liste est bien longue, et comme je l'ai dit, avec un cache supérieur pour le 68030, même si sur accès 32 bits il y aura des cycles d'accès mémoire supplémentaire, au niveau des cycles de décodage pour l'ensemble des instructions, le 68030 sera le plus rapide.
Tout ça à vérifier, mais bon le cache va servir à ça. Est conçu pour ça. Faut vérifier s'il est en cache données, ou en cache processeur.

Comme je te dit je ne peux pas te suivre sur ce terrain. Mais comme je l'ai dit, rien n'empêche un AtariSTe ici à faire le test comparatif avec la même routine sur chaque machine.

Le 68020 a un cache instructions de 256 octets.
Le 68030 a un cache instructions de 256 octets ET un cache données de 256 octets.
Ainsi comme je le disais le fait d'avoir un bus mémoire 16 bits ne va pas être autant pénalisant que si c'était un 68020 (les données sont mises en cache, sur le Falcon. Pas sur le 1200).

Et oui bien sûr qu'avec un DSP tout ce qui est traitement de données va aller au DSP, et pas au CPU.
En bref les pro Amiga dénigrent le Falcon qui a un vrai copro, c'est à dire un DSP avec ses 16 MIPS, là où ils vont vanter leur chipset moisi face aux possesseurs d'Atari ST.
Aucune logique à tout cela.
Ridicule.

Et bien l'affichage du Falcon semble lui aussi ne pas être exempt de défaut. Il semblerait que le mode chunky true color soit assez lent et que certain démomaker préférent passer pour une routine chunky to planar à la place (faite au DSP ?).

La grande force du Falcon et ça c'est indiscutable c'est le DSP. Après ce qu'il y a autour j'ai l'impression que comme avec l'AGA c'était le minimum vital pour l'époque. Sur le papier l'affichage du Falcon fait plus moderne je te l'accorde. De toute façon, je doute que l'AGA ait été mis en avant pour vanter l'Amiga 1200 face à un Falcon.

Par contre le chipset Amiga face au ST, y a pas photo le ST ne tient pas la comparaison. Et ça ce n'est que pour le chipset, le reste du ST non plus ne suit pas.

[ryosaeba]

@babsimov, je suis en congé début janvier. J'en profiterai pour faire le test avec le multitos.

[babsimov]

@babsimov, je suis en congé début janvier. J'en profiterai pour faire le test avec le multitos.

D'accord, je te remercie.

Ce sera avec plaisir que je lirais ça, ou mieux que je le verrais si tu veux faire une vidéo.

Bien entendu, sur un Falcon avec le MultiTOS livré d'origine, sans ajouts ou accélérateurs graphiques sortit après. Pour être au plus prés de la configuration dont parlait les tests que j'avais cité. Mais, je pense me souvenir que ton Falcon est un modèle a 4MO, donc pile la configuration des tests.

Merci encore pour prendre le temps de faire ce test.

EDIT : tiens et puisque que j'y pense, tu pourrais pas faire un test comparatif de performance avec le même programme de benchmark entre le 1200 de base (tu en as un je pense) et le Falcon de base sous TOS cette fois (et sous AmigaOS 3.0 de base pour le 1200 pour être vraiment d'époque). Comme ça on aura un test processeur pour voir qui de AmigaNews ou de la revue Atari était le plus proche de la réalité. Désolé de rajouter encore une demande, mais comme je vois que j'ai hâtisé une polémique je me disais que comme nous savons que tu es autant Commodoriste qu'Atariste (bon enfin ça reste à voir  ), tu feras ça de façon impartiale. Merci (si tu veux prendre le temps)

J'ai pensé à ça comme logiciel de test :
http://aminet.net/package/util/moni/Dhrystone11

Il semble qu'il y ait le source, c'est possible de le compiler sur Falcon ? Sinon quelque chose de similaire qui fonctionne sur les deux machines.

[ChistopheS]

Je répète qu'à fréquence égale un 68030 est plus rapide qu'un 68020, car là où le 68020 n'a qu'un seul cache de 256 octets, le 68030 en a 2 : 1 de 256 octets pour mettre en cache les instructions, 1 de 256 octets pour les données.
Je répète aussi que si le bus mémoire du Falcon est 16 bits, et celui du 1200 est 32 bits,
. le cache instructions du 68030 du Falcon va aider à compenser la dégradation de performance
. un CPU ne passe pas tout son temps à extraire / envoyer des données en mémoire
. l'architecture est pensée pour que le DSP soit le grand communiquant avec la mémoire

En bref : quand on rappelle aux Amigaistes le fait que les CPU des Amiga sont downclockés, on recoit la réponse 'on s'en fout chez nous le CPU est déchargé de nombreuses tâches par notre génial chipset'.
Bizarrement, si un Falconiste explique que de toutes façons le CPU est beaucoup déchargé grâce à un copro de 16 MIPS, ben là non, il faut continuer de cracher sur le bus 16 bits.
. je rappelle aussi que le VIDEL du Falcon met minable le chip video de l'Amiga.
Et Babsimov, non il n'y a pas de flicker fixer dans le chip du Falcon : cette notion de 'fixer' c'est bien pour réparer/corriger une réalisation bâclée de la part des ingés de C=.
Et ça coûte cher pour corriger.
Quand c'est bien pensé er intégré dés le départ, ça ne coûte qu'ube petite poignée de transistors en plus dans la puce vidéo.
Comme chez Acron je crois, pour leurs machines, qui peuvent sortir des fréquences TV et VGA, et aussi afficher du low res aussi bien sur moniteur rgb que vga.

[TotOOntHeMooN]

Je répète qu'à fréquence égale un 68030 est plus rapide qu'un 68020, car là où le 68020 n'a qu'un seul cache de 256 octets, le 68030 en a 2 : 1 de 256 octets pour mettre en cache les instructions, 1 de 256 octets pour les données.

Personne ne dit le contraire. Mais, ce n'est pas le problème.

Je répète aussi que si le bus mémoire du Falcon est 16 bits, et celui du 1200 est 32 bits,
. le cache instructions du 68030 du Falcon va aider à compenser la dégradation de performance
. un CPU ne passe pas tout son temps à extraire / envoyer des données en mémoire
. l'architecture est pensée pour que le DSP soit le grand communiquant avec la mémoire

La mémoire cache n'est que de 256 octets... Dans certains cas spécifiques tu compenseras, mais pas au point d'avoir les performances d'un bus 32-bit. Sinon, toutes les CPU seraient restés en 16-bit pour en faciliter coût et design.
Il faut jouer d'astuce sur Falcon, en privilégiant l'usage du DSP dès que possible. C'est la force de la machine.

En bref : quand on rappelle aux Amigaistes le fait que les CPU des Amiga sont downclockés, on recoit la réponse 'on s'en fout chez nous le CPU est déchargé de nombreuses tâches par notre génial chipset'. Bizarrement, si un Falconiste explique que de toutes façons le CPU est beaucoup déchargé grâce à un copro de 16 MIPS, ben là non, il faut continuer de cracher sur le bus 16 bits.

Ca n'a rien à voir...

non il n'y a pas de flicker fixer dans le chip du Falcon : cette notion de 'fixer' c'est bien pour réparer/corriger une réalisation bâclée de la part des ingés de C=. Et ça coûte cher pour corriger.
Quand c'est bien pensé er intégré dés le départ, ça ne coûte qu'ube petite poignée de transistors en plus dans la puce vidéo.

Foutaise... Déjà "Flicker-Fixer" est une marque commerciale et non le procédé : On parle de scan-doubler.
Donc extrapoler sur le fait que ça fixe quelque chose mal fait, ça n'a rien de vraiment sérieux...

Le but est de désentrelacer un signal vidéo pour le convertir en signal progressif. 2 champs entrelacés -> 1 frame progressive. C'est utilisé encore aujourd'hui dans les TV LCD pour convertir les sources vidéo 15kHz en 31Khz.

Sur Falcon, bien qu'il soit possible de programmer Videl pour générer un signal entrelacé, ce n'est pas vraiment utilisé. Comme sur PC, un écran VGA est nécessaires pour profiter du 640x480 en progressif. (en tout cas, je n'ai jamais vu personne utiliser un Falcon en 640x480 entrelacé, et pour cause ce n'est pas une résolution standard).
https://mikro.naprvyraz.sk/docs/mikro/videl.html

tiens et puisque que j'y pense, tu pourrais pas faire un test comparatif de performance avec le même programme de benchmark entre le 1200 de base (tu en as un je pense) et le Falcon de base sous TOS cette fois (et sous AmigaOS 3.0 de base pour le 1200 pour être vraiment d'époque). Comme ça on aura un test processeur pour voir qui de AmigaNews ou de la revue Atari était le plus proche de la réalité. Désolé de rajouter encore une demande, mais comme je vois que j'ai hâtisé une polémique je me disais que comme nous savons que tu es autant Commodoriste qu'Atariste (bon enfin ça reste à voir  Very Happy), tu feras ça de façon impartiale. Merci (si tu veux prendre le temps)

Et tu auras en résultat les deux cas... Si le test tient dans le câche, le 030 sera plus performant, et s'il ne tient pas, il sera à la rue. De là, monsieur A1200 dira que c'est mieux sur Amiga et monsieur Falcon dira que c'est mieux sur Atari. 
(je pense que les deux benchs sont valides, et que chacun à pris ce qui l'intéressait)

[babsimov]

Je répète qu'à fréquence égale un 68030 est plus rapide qu'un 68020, car là où le 68020 n'a qu'un seul cache de 256 octets, le 68030 en a 2 : 1 de 256 octets pour mettre en cache les instructions, 1 de 256 octets pour les données.
Je répète aussi que si le bus mémoire du Falcon est 16 bits, et celui du 1200 est 32 bits,
. le cache instructions du 68030 du Falcon va aider à compenser la dégradation de performance
. un CPU ne passe pas tout son temps à extraire / envoyer des données en mémoire
. l'architecture est pensée pour que le DSP soit le grand communiquant avec la mémoire

Je suis d'accord un 68030 est plus rapide qu'un 68020 à fréquence égale, à condition qu'on ne le bride pas par un bus 16 bit. C'était le cas sur Falcon, j'y peux rien si ça te plait pas, c'est juste un fait.

256 octet de cache c'est rien du tout, même à l'époque. Il me semble que les processeurs Intel équivalent en avait plus. C'est surement pas ça qui va compenser un bus 16 bit, ou dans des cas très spécifiques. Mais dans 80/90 % des cas le 68030 du Falcon est ralentit par son bus. Aller pour te faire plaisir disons un ration 70 % ralentit et 30 % à fond grâce aux caches.

Je ne suis pas expert en programmation, mais je pense quand même qu'un CPU passe beaucoup de son temps à communiquer avec la RAM.

Le DSP est là je n'ai jamais dit le contraire, j'ai même plus d'un fois et à chaque fois salué le DSP dans le Falcon. Ca n'enlève pas le fait qu'Atari à VRAIMENT bridé son 68030 avec un bus 16 bit. 

En bref : quand on rappelle aux Amigaistes le fait que les CPU des Amiga sont downclockés, on recoit la réponse 'on s'en fout chez nous le CPU est déchargé de nombreuses tâches par notre génial chipset'.
Bizarrement, si un Falconiste explique que de toutes façons le CPU est beaucoup déchargé grâce à un copro de 16 MIPS, ben là non, il faut continuer de cracher sur le bus 16 bits.
. je rappelle aussi que le VIDEL du Falcon met minable le chip video de l'Amiga.
Et Babsimov, non il n'y a pas de flicker fixer dans le chip du Falcon : cette notion de 'fixer' c'est bien pour réparer/corriger une réalisation bâclée de la part des ingés de C=.
Et ça coûte cher pour corriger.
Quand c'est bien pensé er intégré dés le départ, ça ne coûte qu'ube petite poignée de transistors en plus dans la puce vidéo.
Comme chez Acron je crois, pour leurs machines, qui peuvent sortir des fréquences TV et VGA, et aussi afficher du low res aussi bien sur moniteur rgb que vga.

Tu ne devrais pas entrer sur le débat de la machine baclée... Il suffit de relire au fil des pages du sujet ST vs Amiga pour voir que c'est à chaque fois Atari (époque Jack Tramiel) qui a baclé ses machines avec des choix de conceptions qui sont souvent pas si élégants que ça.

Tu veux une liste :
- Atari qui ne tient pas compte des consignes de Motorola en utilisant des instructions du 68000 dont Motorola a dit qu'elles seraient incompatibles avec les futurs générations... Résultat le TOS d'origine ne fonctionne pas sur un 68020 et suivant (ce n'est pas moi qui l'ait expliqué, c'est une information trouvée au fil des débats). Commodore a écouté Motorola, l'OS 1.x fonctionne parfaitement sur 68020. Un Atariste avait prétendu le contraire et j'avais montré une vidéo et des articles d'époque qui montrait qu'il se trompait. Il avait fait mauvaise foi sur mauvaise foi pour dire que c'était pas vrai.
- Le Shifter qui prend des cycles au 68000, même quand il n'y a pas besoin... Pas de ça sur Amiga (expliqué en long et en large par Stapha92
- Le composant AY2149 utilisé en désespoir de cause parce qu'ils n'ont pas réussi à utiliser le composant AMY (plus avancé et au point pour 68000, par l'équipe Atari (la vrai))... pour pas trop que ça se voit on met une prise MIDI (non voulu au départ). C'est une interview de Shiraz Shijvi en personne qui explique tout ça.
- Un controleur SCSI custom buggé et dont même si tu changes par la version corrigée, tu n'es même pas sur que ça fonctionnera correctement sur ton ST tellement il y a eu de révision du ST. C'est un réparateur spécialisé dans le ST qui a expliqué ça sur un forum anglais.
- Un blitter moins bon que celui de l'Amiga, 4 ans après et en plus qui bloque le processeur quand il est utilisé ! Quel intéret d'avoir un coprocesseur s'il ne peut pas fonctionner en parallèle correctement !
- Un TOS rempli de bugs jusqu'au Falcon
- Et pour le Falcon un bus 16 bits pour un processeur 32 bits. Franchement s'ils avaient mis un bus 32 bits de base (comme le 1200), il y aurait pas débat sur ce point.

Ceci n'est qu'une liste de ce qui me revient en tête du fil des débats de ces dernières années.

L'ECS permettait d'avoir du 640x512 en 4 couleur sans scan doubleur. Mais c'est un faux débat. J'ai fait toute ma bureautique pendant des années sur Amiga en 640x256 sur un 1084 et c'était largement suffisant pour le particulier. J'ai reconnu que le mode monochrome du ST était un plus sur ce point (alors qu'en arrivant ici je le trouvais obsolète et archaique).

Le VIDEL sur le papier en jette davantage c'est exact. Je ne le connais pas assez pour m'avancer. De toute façon, je ne pense pas que tu trouveras une seule fois ou j'ai prétendu que l'AGA était le top du top et qu'il surclassait quoi que ce soit. Par contre l'OCS (et à la rigueur l'ECS) surclassaient un ST/STE sans problème.


L'Amiga ne t'en déplaise à été extrêment bien pensé. Toutes les décisions de conception ont été fait pour que l'architecture soit la plus élégante possible. C'était le cas a été reconnu maintes et maintes fois.

[ChistopheS]

L'AGA c'est du bâclé, seuls les Amigaïstes trouvent ça bien.
Lent en haute res, et même en low res avec pas mal de couleurs, et pas de mode linear.
Largué pour la 3D temps réel.
Me sortir les specs du st, ce n'est pas de ça dont on parlait.
Techniquement, le Falcon, en machine 'stock' il n'y a rien d'aussi bien à moins de 5000 francs de l'époque.
Sujet à parcourir sur site Atari pour bien comprendre la puissance d'un Falcon bien programmé :
http://www.atari-forum.com/viewtopic.php?f=2&t=32754
tu peux toujours en rêver sur un 1200 stock.
T'auras intérêt à avoir une carte accélératrice PPC pour contrer le DSP : ça c'est un vrai coprocesseur, pas un truc d'amateur avec 5 malheureuses commandes comme ton copper et ton blitter.
Je ne reprendrai pas les points que j'ai déjà développés et que tu persistes à trasher, alors qu'ils sont tout à fait pertinents (comme le cache processeur ET le cache données, ce que n'a pas le 68020 du 1200).

Tes réponses tombent à côté, on dirait un politicard.
Pas étonnant que Gamopat soit méprisé pour son niveau lamentable sur le site Atari.

[TotOOntHeMooN]

comme le cache processeur ET le cache données, ce que n'a pas le 68020 du 1200

[Anarwax]

L'AGA c'est du bâclé, seuls les Amigaïstes trouvent ça bien.
Lent en haute res, et même en low res avec pas mal de couleurs, et pas de mode linear.
Largué pour la 3D temps réel.
Me sortir les specs du st, ce n'est pas de ça dont on parlait.
Techniquement, le Falcon, en machine 'stock' il n'y a rien d'aussi bien à moins de 5000 francs de l'époque.
Sujet à parcourir sur site Atari pour bien comprendre la puissance d'un Falcon bien programmé :
http://www.atari-forum.com/viewtopic.php?f=2&t=32754
tu peux toujours en rêver sur un 1200 stock.
T'auras intérêt à avoir une carte accélératrice PPC pour contrer le DSP : ça c'est un vrai coprocesseur, pas un truc d'amateur avec 5 malheureuses commandes comme ton copper et ton blitter.
Je ne reprendrai pas les points que j'ai déjà développés et que tu persistes à trasher, alors qu'ils sont tout à fait pertinents (comme le cache processeur ET le cache données, ce que n'a pas le 68020 du 1200).

Tes réponses tombent à côté, on dirait un politicard.
Pas étonnant que Gamopat soit méprisé pour son niveau lamentable sur le site Atari.

BRAVO !!!! 

[TotOOntHeMooN]

Il est clair que le Falcon était supéreur au A1200, en version stock.
C'est d'ailleurs cette machine que j'aurai souhaité... Mais faute de budget, c'est un A1200 que j'ai acheté.

Il faut quand même dire qu'il y avait 1500F d'écart. Ce n'est pas rien... 
Surtout qu'Atari avait habitué à un positionnement tarifaire agressif avec le ST plus le STE. 
Beaucoup de gens auraient eu un Falcon si l'écart avait été moindre, vu les comparatifs des magazines.

[Urbinou]

Pas étonnant que Gamopat soit méprisé pour son niveau lamentable sur le site Atari.

Gamopat est surtout renommé pour ses trolls

[babsimov]

L'AGA c'est du bâclé, seuls les Amigaïstes trouvent ça bien.
Lent en haute res, et même en low res avec pas mal de couleurs, et pas de mode linear.
Largué pour la 3D temps réel.
Me sortir les specs du st, ce n'est pas de ça dont on parlait.

Tu n'as pas du me lire, je te disais que tu auras du mal à trouver un Amigaïste qui dira que l'AGA c'était bien, moi le premier. Tout ce que tu dis sur l'AGA est exact et je suis le premier à l'accepter et à le déplorer.

Ce qui était dans les cartons c'était le AAA qui lui aurait probablement mis "minable" le VIDEL comme tu dis. Mais c'était trop cher à produire pour une machine à 500 dollars. L'AGA a été fait en catastrophe pour cela, ce n'est pas un secret. 

Je ne t'ai pas sortit les specs du ST, mais listé tout ce qui montre que le ST quelque soit sa génération était quelque chose de largement plus baclé que l'OCS/ECS/AGA. Le Falcon a eu la chance d'avoir une mise au point plus longue que tous les autres ST et malgré tout on lui met un bus 16 bit pour un processeur 32 bits, parce qu'on ne trouve pas un autre moyen de le rendre compatible ST, c'est un peu léger non ?
Du côté de Commodore, même si l'AGA n'apportait pas beaucoup, il exploitait au mieux ce dont il disposait (Il ne disposait de pas assez, c'est vrai). Le point noir du 1200 c'est de ne pas avoir eu de FAST en standard (mais là aussi relit le lien sur le 1000+ et tu verras que ce n'était pas ce qui était voulu par les ingénieurs de Commodore). 
Dans le test de la revue Atari (qui malheureusement n'est plus en ligne), justement un 1200 + FAST sortait vainqueur d'un Falcon standard (4MO) en performance processeur (malgré le 68030 du Falcon), tout ça à cause du bus 16 bits. Ce n'est pas moi qui l'invente. La revue expliquait que le Falcon de base gagnait face à un A1200 de base, mais que dès qu'il y avait de la fast, c'était à l'avantage du 1200. J'y peux rien moi, je ne fais que reprendre leurs résultats. Pourquoi le Falcon vainqueur face à un 1200 de base ? Probablement parce que 14 mhz pour le 1200 contre 16 mhz pour le Falcon, les deux bridés, l'un par l'absence de fast et l'autre par son bus 16 bit. Mais une fois que le 1200 est débridé, le 68020 fonctionne à fond et prend l'avantage. Le 68030 dans tous les cas reste bridé par son bus 16 bits sur le Falcon. Il faut changer de carte mère pour que ce ne soit plus le cas.

Techniquement, le Falcon, en machine 'stock' il n'y a rien d'aussi bien à moins de 5000 francs de l'époque.
Sujet à parcourir sur site Atari pour bien comprendre la puissance d'un Falcon bien programmé :
http://www.atari-forum.com/viewtopic.php?f=2&t=32754
tu peux toujours en rêver sur un 1200 stock.

Ce que je vois c'est un lien vers des démos qui ne tournent pas sur un Falcon stock, mais sur un 68060 et est un portage de la version Amiga
http://www.pouet.net/prod.php?which=25778
Mais j'ai peut être mal regardé ou pas assez approfondi.

Le Falcon à 5000 frs, c'est sans disque dur et sans écran :
http://obligement.free.fr/articles/falcon030.php

Donc le DSP et son direct to disk, tu oublies déjà (il faut donc un disque dur de toute façon, comme sur 1200).

Avec un écran et disque dur c'est 10500 frs.... et là on va retomber sur le débat, à ce prix tu as un PC486 avec carte son etc etc... (qui est valable aussi pour le 1200).

T'auras intérêt à avoir une carte accélératrice PPC pour contrer le DSP : ça c'est un vrai coprocesseur, pas un truc d'amateur avec 5 malheureuses commandes comme ton copper et ton blitter.

Ou as tu lu que je critique le DSP du Falcon ? A quel moment ? Je ne cesse de dire que c'est son grand point fort. Avant de critiquer relis mieux. D'ailleurs j'ai déjà dit aussi que c'était bien la première fois qu'Atari avait un vrai coprocesseur dans sa gamme (relis aussi).

Le blitter et le copper d'amateur comme tu dis, les "professionnels" d'Atari ont été incapables de proposer un blitter mieux 4 ans après, et rien d'équivalent au Copper !!! 

Et pour revenir au DSP et l'Amiga, as tu lu le lien sur le 3000+ et son DSP que j'avais mis (j'en doute) ? Tu vois les ingénieurs de Commodore voulaient sortir un Amiga AGA avec DSP. Ils n'ont pas choisit la facilité, comme Atari. 
Pourquoi la facilité ?
Parce que par bien des côtés le Falcon c'est le NeXT du pauvre, comme le ST était le MAC du pauvre, une copie de l'original fait pour être le moins cher possible. Alors, le challenge est réussi au niveau tarif, je te l'accorde et apporter pour le Falcon un DSP au grand public était vraiment bien.

Mais, du côté Commodore, les ingénieurs n'ont pas voulu juste copier le NeXT, ils voulaient proposer quelque chose de mieux. Donc pas de DSP 56001 24 bit, mais un DSP AT&T 3210 32 bits à virgule flottante, qui offrait une puissance de calcul en flottant dix fois celle d'un 68040 (excuse du peu). En plus le DSP du Falcon tourne à 32 mhz, celui choisit par Commodore aurait tourné à 50 mhz. En plus si ce n'était pas suffisant, ce DSP avait son propre OS multitâche propriétaire à AT&T qui aurait été interfacé avec l'AmigaOS et aurait tourné en parallèle avec l'AmigaOS et son 680x0... Là c'était une vrai machine bi-processeur si on va par là. Mais, la direction de Commodore a annulé tout ça (alors que finalisé et prévu pour sortir fin 91 début 92). C'est Apple qui a récupéré le travail de Commodore pour l'intégrer au MAC, en perdant au passage le multitâche et en cantonnant ce DPS au son.

https://fr.wikipedia.org/wiki/Motorola_56000
http://obligement.free.fr/articles/dsp.php
http://www.thule.no/haynie/research/dsp3210/docs/notes.pdf
http://www.thule.no/haynie/research/a3000p/docs/a3000p.pdf
http://obligement.free.fr/articles/amiga3000+_coulisses.php

Bonnes lectures

Et pour revenir au Falcon, bien entendu que ses caractéristiques de base font nettement plus rêver que celles d'un Amiga 1200 (moi le premier je pestais à l'époque que Commodore n'ait pas mis un DSP en plus). L'AGA, à sa sortie, personne ne savait les limitations qu'il avait, on pensait que ce serait aussi bien que le fut l'OCS en son temps en terme d'avancée.

Mais, tu ne m'enlèvera pas de l'idée que j'avais déjà à l'époque que si Atari à mis un 68030 dans le Falcon (tout en le bridant par un bus 16 bit), c'était pour deux raisons :
- Ca faisait que le Falcon avait quasiment les spécifications papier du NeXT (largement encensé par la presse à l'époque et justifié en son temps, bien que le NeXT aussi n'était pas exempt de petits défauts).
- Sur le papier ça sonnait mieux que 68020.

Mais, une fiche technique, quelle que soit la machine ça ne veut rien dire. Sans parler du Falcon, l'AGA  sur le papier c'était 256 couleurs dans tous les modes. Dans la réalité on peut l'afficher, mais c'est inutilisable à partir de 640x512 (voir 256 je me souviens pas bien). Pareil pour l'Archimedes, c'est 256 couleurs, mais avec contraintes et en plus dans un autre sujet on a vu que son architecture était loin d'être optimum et qu'en dehors de la 3D (non texturée), l'archimedes malgré un bon processeur ne surpassait pas un Amiga OCS.

Je ne reprendrai pas les points que j'ai déjà développés et que tu persistes à trasher, alors qu'ils sont tout à fait pertinents (comme le cache processeur ET le cache données, ce que n'a pas le 68020 du 1200).

Mais, au contraire, je n'ai pas trashé, j'ai juste dit que je doute que tes affirmations soient pertinentes, différent. En plus j'ai demandé à un participant de bien vouloir (s'il a le temps) faire un test comparatif sur ce point. 

Mais je vais encore faire mieux. Puisque que tu sembles t'y connaître en programmation (plus que moi, y a pas de mal), je te propose de mettre ici publiquement une routine assembleur qui aura une version avec cache et une sans cache, avec une utilisation en 16 bit et une en 32 bits. De la compiler sur Falcon et sur Amiga 1200 et de comparer les résultats. Comparaison entre un Falcon de base et un 1200 de base, puis un 1200 avec de la fast, bien entendu.

Je te demande de publier publiquement le source pour que ceux qui s'y connaissent en assembleur puissent vérifier qu'il n'y aurait pas d’optimisation qui favoriserait le Falcon au détriment du 1200 (j'ai vu trop de mauvaise foi AtariSTe ici).

Tiens en parlant de mauvaise foi, je te rappel que cette histoire de bus 16 bit est parti au départ du fait que j'ai voulu souligner la mauvaise foi de STFormat qui voulait faire passer le 68020 du 1200 comme un sous-processeur face au 68030 parfait du Falcon (tout en passant sous silence ce fameux bus 16 BIT). Je voulais la souligner cette mauvaise foi, parce qu'on avait laissé entendre que le test d'AmigaNews était de mauvaise foi (j'en doute). Mais, bien sur tu n'a pas du lire cette partie là de mes réponses dirait on ? 

EDIT (de relecture) :
Tiens il semble bien qu'AmigaNews avait fait le test cache et sans cache (comme quoi les Amigaïstes que l'on critique tant ici, semblent savoir tester) :

http://obligement.free.fr/articles/falcon030.php

"Le matériel

Le coeur de la machine est un 68030 cadencé à 16 MHz. Comme le 68020, ce processeur possède 256 octets de cache instruction, mais il possède en plus 256 octets de cache données, une unité de gestion mémoire (MMU) et un mode d'accès mémoire rapide "en rafale" (burst). Ce mode est désactivé sur le Falcon, car le bus mémoire est sur 16 bits. Que l'on ne vienne pas nous raconter des histoires sur ce fameux bus mémoire, qui serait plus ou moins 32 bits, mais uniquement 16 bits pour le processeur. Les chiffres ne se discutent pas, et un test d'accès mémoire (20 millions de "move") en mots courts puis en mots longs fait apparaitre une différence de vitesse de lecture et d'écriture qui ne peut se discuter.

Test du bus : 20 millions d'accès mémoire en mot court et long :



"
Pour ceux qui s'y connaissent en assembleurs, ces chiffres sont ils défavorables pour le 68030 du Falcon face à au 68020 du 1200 ?

Tes réponses tombent à côté, on dirait un politicard.
Pas étonnant que Gamopat soit méprisé pour son niveau lamentable sur le site Atari.

J'ai déjà dit que quand je fais de la mauvaise foi je le dis ouvertement (ou alors c'est que cela m'a échappé et je le précise ensuite). Dans le cas de cette histoire de bus 16 bits, ce n'est pas de la mauvaise foi, juste une chose exacte qui est occultée par les AtariSTes en général. Ce n'est pas de ma faute si Atari a commis l'erreur de donner au Falcon un point critiquable non ? 
Tu as du lire ici plusieurs Amigaïstes qui t'ont dit "oui le Falcon était bien/mieux que le 1200" en terme d'équipement hardware ? Tu ne peux pas reprocher à un Amigaïste de juste te pointer du doigt le point discutable du Falcon de base non ? Tu critique bien l'AGA (et c'est tout à fait juste), t'ais je dit "non l'AGA c'était le TOP ? je ne crois pas, je sais reconnaître et accepter les défauts et qualité de mon Amiga (c'est même moi plus d'une fois qui en est "offert" au STistes qui ne les connaissaient pas (je parle de défauts de l'Amiga, pour ce qui est des qualités elles j'ai fait le nécessaire pour qu'elles soient ouvertement reconnues).

Et pour ce qui concerne Gamopat, tu a bien mal choisit ta critique, car ce site est quand même réputé pour être PRO Atari. Il te suffira de relire les débats ST vs Amiga pour t'en convaincre.

L'AGA c'est du bâclé, seuls les Amigaïstes trouvent ça bien.
Lent en haute res, et même en low res avec pas mal de couleurs, et pas de mode linear.
Largué pour la 3D temps réel.
Me sortir les specs du st, ce n'est pas de ça dont on parlait.
Techniquement, le Falcon, en machine 'stock' il n'y a rien d'aussi bien à moins de 5000 francs de l'époque.
Sujet à parcourir sur site Atari pour bien comprendre la puissance d'un Falcon bien programmé :
http://www.atari-forum.com/viewtopic.php?f=2&t=32754
tu peux toujours en rêver sur un 1200 stock.
T'auras intérêt à avoir une carte accélératrice PPC pour contrer le DSP : ça c'est un vrai coprocesseur, pas un truc d'amateur avec 5 malheureuses commandes comme ton copper et ton blitter.
Je ne reprendrai pas les points que j'ai déjà développés et que tu persistes à trasher, alors qu'ils sont tout à fait pertinents (comme le cache processeur ET le cache données, ce que n'a pas le 68020 du 1200).

Tes réponses tombent à côté, on dirait un politicard.
Pas étonnant que Gamopat soit méprisé pour son niveau lamentable sur le site Atari.

BRAVO !!!!    

C'est bien ce que je disais, PRO Atari ici 

TotOOntHeMooNIl est clair que le Falcon était supéreur au A1200, en version stock.
C'est d'ailleurs cette machine que j'aurai souhaité... Mais faute de budget, c'est un A1200 que j'ai acheté.

Il faut quand même dire qu'il y avait 1500F d'écart. Ce n'est pas rien... 
Surtout qu'Atari avait habitué à un positionnement tarifaire agressif avec le ST plus le STE. 
Beaucoup de gens auraient eu un Falcon si l'écart avait été moindre, vu les comparatifs des magazines.

La différence de prix n'explique pas tout. Atari n'avait clairement plus le soutien des éditeurs et les STistes avaient en majorité fuis sur PC dès 1989/90. Au lieu d'acheter un Amiga ou d'attendre le Falcon (comme les Amigaïstes ont attendu la nouvelle génération). Résultat, tout le monde a perdu puisque les deux marques pionnières de la micro informatique familiales ont disparu et que c'est le PC qui s'est imposé en enlevant tout le fun à l'informatique. L'échec du Falcon a conduit à la fin pour Atari et pour Commodore la nouvelle direction a tout fait pour saborder sa société (car malgré ses défauts la génération AGA se vendait relativement bien).

Personnellement je l'ai déjà dit, à l'époque je n'envisageais pas d'acheter autre chose qu'un Amiga, trop content de mon AmigaOS. Bien sur les articles sur le Falcon dans les revues laissaient envisager que pour une fois Atari allait avoir l'avantage hardware. Ca ne me plaisait pas plus que ça, mais d'une certaine façon je me disais "tant mieux, ça va obliger Commodore à se bouger un peu et à sortir le DSP". Comme le Falcon a été vite stoppé par Atari, Commodore n'a pas considéré que l'ajout du DSP promis était urgent (une erreur de plus).

[Anarwax]

bah oui pro Atari moi, ici c'est qd meme un topic Falcon Vs Gaga non ????
donc ya les deux clans

[TotOOntHeMooN]

La différence de prix n'explique pas tout. Atari n'avait clairement plus le soutien des éditeurs et les STistes avaient en majorité fuis sur PC dès 1989/90. Au lieu d'acheter un Amiga ou d'attendre le Falcon (comme les Amigaïstes ont attendu la nouvelle génération). Résultat, tout le monde a perdu puisque les deux marques pionnières de la micro informatique familiales ont disparu et que c'est le PC qui s'est imposé en enlevant tout le fun à l'informatique. L'échec du Falcon a conduit à la fin pour Atari et pour Commodore la nouvelle direction a tout fait pour saborder sa société (car malgré ses défauts la génération AGA se vendait relativement bien).

Clairement, c'était un PC qu'il fallait prendre en 1992 si l'on avait le budget d'un Falcon... 
Mais il faisait rêver avec son DSP à ce moment quand même ! 

[Zarnal]

Le souci du PC c'était surtout son encombrement/ventilation et surtout la façon dont certains assembleurs pouvaient accueillir un jeune non accompagné qui avait des questions à la con du genre " peut on le brancher sur la TV ". Ce n'est pas comme aujourd'hui et heureusement. Véridique.

J'ai toujours branché mes Amiga sur la TV. Autant dire que niveau budget...

[Anarwax]

ah ouais pareil.... mon st était sur une téloche, bien moins chère que l’écran officiel !!
et la télé en bidouillant une antenne !!! mes parents ne l'ont jamais su :)

[TotOOntHeMooN]

De souvenir, un Falcon030 sans moniteur, c'est un peut la loose quand même.

[babsimov]

bah oui pro Atari moi, ici c'est qd meme un topic Falcon Vs Gaga non ????
donc ya les deux clans

Ne te méprends pas, y a pas de problème, c'était juste pour appuyer mon propos que j'ai repris ta réponse 

Elle était pleine d'enthousiasme pour ce défenseur du Falcon me reprochant de faire de la mauvaise foi et de l'anti Atarisme primaire (ce qui n'est pas le cas). Cela ne faisait que confirmer mon propos sur le site 

Il est tout à fait légitime de défendre le Falcon, surtout qu'en plus j'ai déjà dit que c'est la seule machine de la gamme ST qui, pour moi, a un intérêt au niveau du hardware. Je vous l'envie, enfin surtout son DSP.

Je ne fais que dire ce qui était au sujet du 68030 du Falcon et je demande juste qu'on refasse le test pour comparer, tout comme MultiTOS. Pas ma faute si on me réponds que 256 octets de caches suffisent à compenser l’absence d'un vrai bus 32 bits. Je ne suis pas expert, mais ça me parait des plus douteux.

TotOOntHeMooN

La différence de prix n'explique pas tout. Atari n'avait clairement plus le soutien des éditeurs et les STistes avaient en majorité fuis sur PC dès 1989/90. Au lieu d'acheter un Amiga ou d'attendre le Falcon (comme les Amigaïstes ont attendu la nouvelle génération). Résultat, tout le monde a perdu puisque les deux marques pionnières de la micro informatique familiales ont disparu et que c'est le PC qui s'est imposé en enlevant tout le fun à l'informatique. L'échec du Falcon a conduit à la fin pour Atari et pour Commodore la nouvelle direction a tout fait pour saborder sa société (car malgré ses défauts la génération AGA se vendait relativement bien).

Clairement, c'était un PC qu'il fallait prendre en 1992 si l'on avait le budget d'un Falcon... 
Mais il faisait rêver avec son DSP à ce moment quand même !  

Tu sais que je ne partage pas ce point de vu au sujet du PC et tu as juste dit les mots qui justement font la différence "il faisait rêver avec son DSP", ce qu'aucun PC ne peut faire.

Comme je l'ais dit, de toute façon, pour moi c'était AmigaOS sinon rien, même sans DSP 

[TotOOntHeMooN]

u sais que je ne partage pas ce point de vu au sujet du PC et tu as juste dit les mots qui justement font la différence "il faisait rêver avec son DSP", ce qu'aucun PC ne peut faire.

C'est pour cela que j'aurai choisi le Falcon, malgré le fait que tous les jeux étaient sur PC.
Avec le A1200 et le Flacon, j'avais l'impression qu'on vivait dans le futur... Mais c'est le passé qui l'a emporté.

[babsimov]

u sais que je ne partage pas ce point de vu au sujet du PC et tu as juste dit les mots qui justement font la différence "il faisait rêver avec son DSP", ce qu'aucun PC ne peut faire.

C'est pour cela que j'aurai choisi le Falcon, malgré le fait que tous les jeux étaient sur PC.
Avec le A1200 et le Flacon, j'avais l'impression qu'on vivait dans le futur... Mais c'est le passé qui l'a emporté.

C'était tout à fait ça. Enfin bon le Falcon faisait plus futuriste avec son DSP que l'Amiga 1200 (mais Commodore promettait un DSP, donc on espérait (enfin moi j'y avais cru un bon moment)).

C'est effectivement bien dommage que le marché Américain à préféré acheter majoritairement du PC.

[Urbinou]

Avec le A1200 et le Flacon,

Oui, du moment qu'on ait l'ivresse...

[Zarnal]

ah ouais pareil.... mon st était sur une téloche, bien moins chère que l’écran officiel !!
et la télé en bidouillant une antenne !!! mes parents ne l'ont jamais su :)

C'est surtout qu'elle était déjà présente à la maison, donc 0 à dépenser.

[Anarwax]

ah moi j'avais dans ma chambre du coup !!!

[Templeton]

Par contre le Falcon, mort née dès sa sortie. Logithèque peau de chagrin et compatibilité désastreuse avec le St

La ludothèque est peau de chagrin, pas la logithèque qui est bien fournie et qui a même explorée plus de domaines que le ST !
Ensuite la compatibilité est "désastreuse" pour qui n'a pas eu de Falcon ou n'achetait pas de revue Atari pour être informé de ce qui se passait sur cette machine.
Quelques semaines après la sortie du Falcon la compatibilité du Falcon était du même niveau que sur Amiga 1200 car il y a eu de nombreux outils pour corriger ça (certains appelaient ça des "émulateurs ST"), le plus célèbre d'entre eux étant Backward fait par un français.
En fait Atari avait prévu dès le départ cet aspect là, comme pour le 1200 quand on appuie sur les 2 boutons de la souris au boot.
Mais ça n'a pas été implémenté pour être accessible au quidam (manque de place dans la ROM, de temps, autres ?).
Il y a donc un registre qui permet de mettre le 68030 à 8MHz, le BUS à 8MHz, le DMA en 8Bits, le Blitter à 8MHz et la possibilité également de désactiver les 2 caches du CPU. Les programmeurs l'ont vite utilisé mais des logiciels comme Backward faisaient bien plus que ça.
Par exemple un des aspects les plus critiques était étonnamment la partie son, beaucoup de jeux plantaient à cause du Yamaha !
Pour optimiser leurs routines sonores, de nombreux programmeurs utilisaient des registres interdits par Atari (certains les appelaient les shadow registers) et ces dits registres n'existent plus sur Falcon donc plantage à la clef quand un accès de ce type se produisait.
Il y avait d'autres raisons qui ont été détectées et corrigées mais je ne vais pas rentrer dans les détails, ça n'intéressera pas grand monde ^^
Aujourd'hui que ce soit le Falcon ou le 1200, ces deux machines ont quasi accès à l'intégralité de la ludothèque de leurs ancêtres, merci WHDLOAD, ULS, HAGA et consort.

Au final jouer aux principaux jeux ST sur le Falcon était possible et il y avait même plusieurs avantages à le faire:
- Hormis les jeux 3D où tout le monde se doute que ça tournait mieux sur le rapace, beaucoup de jeux 2D en profitaient.
Disparition ou moins de ralentissements, une VBL grattée par ci par là, le gain était plus visible que sur le 1200 car comme tout le monde le sait, la logithèque arcade du ST était moins bien lotie niveau framerate que celle du 500.
- En plus d'un gain en fluidité/rapidité améliorant le gameplay, tu avais aussi le fait d'avoir un environnement sonore plus agréable aux oreilles vu que la sortie audio du Falcon était à mille lieux de ce que proposait les anciennes machines de la gamme.
- On pouvait patcher des jeux de plusieurs disquettes pour les mettre sur une seule vu que le Falcon possédait un lecteur 1.44Mo, bye bye les séances grille-pains.
- Autre exemple moins connue, tu peux choisir la taille des pixels car le VIDEL possède plusieurs horloges vidéos !
On peut par exemple afficher un jeu 320x200 sans les fameuses bandes noires à droite et à gauche. Un peu comme les consoles qui étirent l'image pour remplir tout l'écran malgré leurs faibles résolution (ex SNES). Bref, sur un même moniteur, là où tu joueras à Rainbow Island avec des grosses bandes noires sur Amiga ou ST, sur Falcon ce n'est plus le cas!

"Ajouter de la Fast RAM ne te permetra pas non plus d'écouter un MP3 sur un Amiga standard.
Un Falcon030 sorti du carton peut lire un MP3 44 KHz 16bits en 256 kbit/s sans saccades grâce au DSP"

---->Aucun intérêt le Mp3 aujourd'hui sur ce genre de micros

?! Les lecteurs MP3 au DSP sur Falcon ne datent pas d'hier !
D'ailleurs pour l'anecdote, quand les cartes Delphina à base de DSP 56k sont sorties quelques années après pour 1200/4000, ce sont des ataristes qui ont donné le code pour que ces cartes aient un lecteur MP3 exploitant leur DSP.

Tout les jeux 2D impressionnant qu'on voit sur falcon comme BOR par exemple, utilise un moteur de sprites au DSP .
Après je sais pas dans quelle mesure le blitter peut être utile ??

Et bien aussi surprenant que cela puisse paraitre, le Beat Of Rage sur Falcon n'utilise pas le DSP pour afficher ces gros sprites.
C'est fait au 030 et la routine de Thadoss est sacrément chiadée, ceux qui veulent en savoir plus, allez sur atari-forum, il y a un sujet épinglé qui en parle.
Maintenant si ça tourne aussi bien c'est pas seulement grâce au talent du codeur mais aussi grâce au Falcon et notamment au performant Videl.
Contrairement à ce que tout le monde pense, le mode hi-color (chunky) du Falcon n'est pas utile que pour la 3D ou les effets au pixel.
En fait même en 2D il peut être vachement intéressant, tu peux faire des routines de sprites sans les classiques opérations AND et OR !
Tu peux créer des routines plus véloces en 65000 couleurs qu'en mode planar 256 couleurs :)
De plus il est beaucoup plus facile à appréhender que le mode planar, c'est donc plus simple de créer/optimiser des routines avec ce mode vidéo.
Le portage de Galaga 88 est un bon exemple, le jeu tourne en 50 FPS dans ce fameux mode et pourtant il y a de nombreux sprites.

En ce qui concerne la question sur l'utilité du Blitter, il offre un gros avantage pour les programmeurs "normaux" ou débutants, pas besoin de se prendre la tête à créer des routines de la mort qui tue en ASM. La puce est simple à programmer et plus rapide qu'on ne le pense.
Il est plus véloce que sur Amiga ou ST donc on peux faire des choses en Basic ou C vraiment chouettes.
Quand j'aurais un peu de temps devant moi, je ferais une démo jouable d'un jeu d'arcade connu rien qu'avec le Blitter en mode planar 256 couleurs et sans une goute d'asm; vous verrez de grands sprites en nombres tournant en 1VBL 50 FPS , c'est un jeu qui existe déjà sur ST & Amiga donc vous pourrez faire la comparaison !

En fait c'est ça qui est bien avec le Falcon, c'est une machine qui offre de nombreux choix et qui peut convenir à tout type de programmeurs, qu'ils soient débutants ou confirmés.
Vais-je utiliser le mode planar ou le mode chunky ? Utiliser le 68030, le Blitter ou le DSP ?

Là par contre, je ne suis pas d'accord. Une machine Bi processeur c'est la BeBOX, là l'OS gère les deux processeurs et les applications sont écrites pour répartir les charges entre les deux. Pour moi, ce que tu décris c'est un coprocesseur. Tu as peut être raison, mais je suis dubitatif tout de même.

C'est pourtant bien le cas, l'exemple que tu cites est le "modèle" architectural le plus connu mais le Falcon est bien une machine bi-processeur.
Le DSP est un microprocesseur avec son propre jeu d'instructions (complet), ses propres registres/modes d'adressages, sa propre RAM avec ses bus de données/adresses pour y accéder, etc.
Il peut également avoir accès en DMA à la RAM centrale sans même que le 68030 ne soit au courant.
Et bien sûr il peut travailler de concert avec le 68030 et pas seulement tout seul dans son coin.
Bref on est à mille lieu d'un coprocesseur comme pourrait l'être un Blitter ou le 68882 par exemple.

On peut tourner ça comme on veut, c'était idiot de mettre un 68030 sur un bus 16 bit. Mais, comme je l'ai compris, c'était inévitable pour être un tant soit peu compatible ST ?
Et on revient au seul vrai avantage du Falcon, son DSP, on est d'accord.

Ce n'est pas idiot au sens que Motorola a permit de faire cela (contrairement au 68040 ou 68060) et c'était une pratique courante à cette époque, que ce soit sur PC (386SX) ou Apple avec certains de ses Mac qui étaient pourtant des machines pro.
Et pour répondre à ta question, non, le choix du BUS 16Bits n'a rien avoir avec le STF/STE ou une quelconque histoire de compatibilité avec ces derniers.
Atari a été obligé de prendre cette solution parce que le Falcon était paradoxalement un ordi tourné vers l'avenir et avait donc besoin de beaucoup de RAM vu la technologie qu'il embarquait !
Or tu ne peux pas faire ce que tu veux quand tu dois créer une archi mémoire rapide avec accès entrelacés.
Si Atari avait décidé de faire un BUS 32 Bits on aurait eu des configurations mémoires de 2Mo ou 8Mo. 8 aurait été beaucoup trop cher et 2Mo aurait été trop peu.
Avec un BUS 16 Bits tu as la possibilité d'avoir 4Mo ou 16Mo (en fait 14 sur Falcon). C'est un ingénieur hardware connu dans le monde Atari qui a expliqué ça il y a déjà trèèèès longtemps.
Certains ont tendance à oublier que les données sonores et graphiques peuvent prendre 2 fois plus de place sur Falcon (son 16 bit+ chunky 16 bit).
Atari a fait un compromis judicieux en réservant un accès 32Bits à sa puce Vidéo, la solution choisie était la bonne.

Maintenant si j'étais un fanboy Amiga je me garderai bien de parler de cette histoire de BUS 16 Bits car ça peut te revenir vite dans la figure façon boomerang puisque la bande passante mémoire du 1200 avec son BUS 32 Bits est moins bonne que celle du Falcon avec son BUS 16 Bits; à se demander qu'elle est la machine la mieux conçue 8)
Certains vont dire que c'est la honte pour Commodore mais tout le monde ou presque oublie que la largeur du BUS n'est qu'une donnée parmi tant d'autres pour définir la bande passante d'une machine !

Et on revient au seul vrai avantage du Falcon, son DSP, on est d'accord.

Je pense que c'est réducteur, certes le DSP était un atout marquant pour l'époque mais un Falcon c'est bien plus que ça !
C'est, entre autres, un affichage chunky Hi-Color 65536 couleurs et c'est 8 canaux DMA 16 Bits 50KHz en entrée et en sortie. Bien que dans la pratique on peut faire bien plus que ça !

La TT-RAM a aussi été débattu sur le sujet Amiga vs ST et au final, il semble bien que la TT-RAM était un ajout tardif pour les TT et que sa gestion était nettement moins bien pensée que la véritable fast ram sur Amiga. Il suffit de relire le sujet, tu devrais trouver ça.

Il ne faut pas croire tout ce qui est dit sur les forum, même sur Gamopat :)
Le TT était plus puissant que l'Amiga 3000 qui lui faisait face contrairement à ce qui a été dit, tout en étant nettement moins cher !
Le 68030 était plus rapide, le 68882 plus rapide, la chip ram aussi, etc.
Le copro qui gérait les accès mémoires était bien conçu et donnait la possibilité d'avoir 10Mo de CHIP RAM là où le monde Amiga a toujours été coincé à 2Mo.
Le Shifter du TT était aussi plus véloce, il avait accès à la mémoire via un BUS 64 Bits !
La où le 3000 offrait 32 couleurs sans contrainte, le TT c'était 256 couleurs.
En fait il y a pleins d'autres trucs qui étaient mieux sur le TT et c'est aussi vrai pour le 3000 (aucune machine n'est parfaite) mais on est hors-sujet donc je ne vais pas m'étendre la dessus.
Juste conclure qu'il y a des ataristes fan de cette machine qui ne veulent même pas entendre parler du Falcon !

Oui, DSP rien à dire. Juste une remarque, imagine ce qu'aurait donné le DSP de l'Amiga. Celui du Falcon tournait à 32 mhz et était 24 bit. Celui prévu pour l'Amiga tournait à 50 mhz et était 32 bit. Il parait qu'il calculait les flottants 10 fois plus vite qu'un 68040 à 25 mhz. Je ne sais pas combien de MIPS ça fait, mais ça devait être plutôt pas mal pour son époque.

Tu vas être surpris mais tout n'est pas en 24 Bits, un programmeur qui sévit dessus te diras qu'il est 24/48/56 Bits !
En terme de performances (en MIPS), à fréquences égales les DSP56k de Motorola étaient 2 fois plus rapides que les 3210 d'AT&T choisi par Commodore !
Le modèle sur le 3000+ tournait à 50MHz pour 12.5MIPS alors que celui du Falcon est cadencé à 32 MHz pour 16 MIPS.
Et quand on sait qu'on peut facilement le sur-cadencer à 50MHz et qu'on obtient ainsi 25MIPS...
Après ils ont tous les deux des points forts et points faibles car ils sont quand même assez différents dans leur fonctionnement.
La plus grosse différence étant qu'à part un petit cache de 8KO le DSP d'AT&T n'a pas de RAM dédiée, il doit donc récupérer ses infos dans la ram centrale (FAST dans le cas présent), ses performances dépendent donc fortement de l'architecture mémoire de la machine. Et cela affecte évidement le CPU qui ne travaille plus seul avec la FAST...
L'avantage c'est que face aux solutions classiques (SRAM dédié), il n'est pas "limité" par la taille de la mémoire.
ça peut-être intéressant par exemple pour avoir de grosses textures si tu veux faire de la 3D avec.

De mémoire en fait la puce du Falcon pour le mode VGA était une puce VGA, c'est ce que j'avais lu à l'époque dans un test de TILT ou similaire.

Il n'y a pas de puce VGA, c'est le VIDEL qui s'occupe de tout.
Beaucoup de conneries ont été dites au sujet du Falcon dans les revues de l'époque, la pire fut sans aucun doute Joystick.
Même des revues spécialisées de l'autre camp ont dit des âneries dessus comme Amiga News qui avait fait un test de la machine; test pleins d'erreurs, de mauvaises fois, etc.
ça avait mis en rogne beaucoup de gens et leur standard téléphonique a été assailli d'appels; à tel point qu'ils ont été obligé dans la revue suivante (ou deux n° après, je ne sais plus trop) de refaire un article dessus pour faire leur mea-culpa !!!
Démarche louable mais c'était un peu la honte, d'autant plus que l'article avait encore des erreurs sjmsb...
Quand tu veux t'immiscer dans un monde que tu ne maitrises pas c'est toujours casse gueule et quand l'auteur en plus raconte des conneries sur "sa" machine pour la défendre ça n'arrange pas le tableau; en effet ce dernier affirmait que le BLITTER du 1200 était nouveau et en 32Bits :))

Pour ce qui est de l'optimisation, j'ai lu ici que justement ce mode true color était particulièrement lent comparé au PC de l'époque. C'était pour ça que les démomaker utilisent un chunky to planar à la place du mode natif ?

Le mode true color n'est pas lent et il est utilisé massivement dans les jeux/démos, il y a assez d'exemples sur youtube pour le confirmer sans avoir eu la machine.
Ce qui était lent c'était la VDI, les routines d'affichage de l'OS quand tu travaillais sous GEM; tout le monde achetait un logiciels tiers pour corriger ça. Appelé NVDI il boostait de façon spectaculaire l'affichage dans tous les modes vidéos.
Il faisait partie des indispensables de la machine et sur ST aussi d'ailleurs.
A part quelques exceptions, aucun Demomaker n'utilisait de routines chunky to planar sur un Falcon standard, le mode true color est plus rapide que le mode planar 256 couleurs sauce C2P.
D'ailleurs le VIDEL est tellement bien conçu que la bande passante mémoire en mode true color est meilleure que le chipset AGA en 256 couleurs !!
La question de l'utilisation d'une telle routine peut par contre se poser sur une grosse carte accélératrice avec sa FAST RAM car là ça sera plus rapide en débits mais ça n'est pas sans conséquences puisque tu perds plus de 65000 couleurs dans l'opération...
Cette pratique est surtout répandue sur Amiga car les programmeurs n'ont pas vraiment le choix, il n'y a que le vieux mode planar à disposition.

Je cherchais à me renseigner un peu plus sur le Falcon et j'ai trouvé un article en anglais avec une information surprenante concernant MultiTOS. Il semble que MultiTOS réclamait 1.6 MO de RAM rien que pour booter ? C'est exact ça ?

C'est une connerie vu que MultiTOS peut booter sur un 1040STF. De toute façon on voit que le gars ne maitrise pas son sujet puisqu'il confond Mint et MultiTOS...
Un conseil, ne va pas sur des sites Amiga pour avoir des infos sûres au sujet du Falcon ou le monde TOS en général.

Et qu'est ce qu'on nous dit que sur un modèle 4MO, après ces 1.6 MO pour le multitâche il reste seulement un peu plus d'un mégaoctet d'utilisable... donc en fait le MultiTOS sur un modèle 1MO n'est même pas lançable.... puisqu'il semble donc que MultiTOS rien que pour tourner utilise : 4MO - 1.6 MO - 1 MO : 1.4 MO !!!!

Je crois que tu t'emmêles un peu les pinceaux dans tes calculs, d'où sort ce -1Mo ?!
Dans mes souvenirs, si tu voulais utiliser la protection mémoire il devait te rester 2.5Mo et sans, 3.3 donc c'est toujours plus qu'un 1200 sorti de sa boite.
Ensuite il faut arrêter avec ces histoires de Falcon 1Mo, personne en avait pour deux raisons.
La première c'est qu'à son lancement cette configuration n'était pas disponible en magasin et c'était voulu par Atari.
La deuxième c'est que lorsque des vendeurs ont pu proposer cette config longtemps après que le parc soit installé, c'était pour permettre aux acheteurs qui voulaient une config 14Mo d'acheter des cartes mémoire tiers de 16 Mo pas "chers" pour éviter de se retrouver avec une carte de 4Mo sur les bras.
Maintenant penser qu'un Falcon soit utilisable avec seulement 1Mo de mémoire en manipulant des graphismes et du son 16bits, sérieusement ?!
En plus fin 92/ début 93, 1Mo c'est presque de la préhistoire, Atari proposait déjà ce genre de config en 1986 avec ses 1040STF.
Déjà que les 2 Mo du 1200 c'était limite...
Un Falcon standard c'est 4 Mo et vu la technologie embarquée dans la machine, ce n'est pas trop.
En plus pour ceux qui n'avait pas les moyens de se payer une carte 16Mo, le Falcon permettait avec des logiciels comme Outside de transformer de l'espace disque en mémoire virtuelle, chose impossible sur un 1200 puisque le 68020 n'a pas de MMU contrairement au 68030 du Falcon.

Blague à part, Silmaris fut l'une des premières société à sortir des versions de leur jeux les plus récents sur Falcon et AGA. Je crois d'ailleurs qu'il n'y avait pas de grosse différence entre ces versions.

La différence se situe au niveau audio, par exemple dans Ishar 2 c'est fromage ET dessert sur Falcon, tu as les bruitages d'ambiance plus la musique donc Silmarils devait exploiter les 8 canaux du Falcon.
L'autre différence est le nombre de disquette, par exemple sur Ishar 3 c'est 8 disquettes sur Amiga AGA et seulement 4 sur Falcon.
Pour Ishar 3 et Robinson Requiem le Falcon dispose des versions CD plus aboutis, Silmarils ne les a pas sorti sur Amiga.
Comme quoi, la machine devait quand même rapporter un peu d'argent :)

[TotOOntHeMooN]

Ce n'est pas idiot au sens que Motorola a permit de faire cela (contrairement au 68040 ou 68060) et c'était une pratique courante à cette époque, que ce soit sur PC (386SX) ou Apple avec certains de ses Mac qui étaient pourtant des machines pro.
Et pour répondre à ta question, non, le choix du BUS 16Bits n'a rien avoir avec le STF/STE ou une quelconque histoire de compatibilité avec ces derniers.
Atari a été obligé de prendre cette solution parce que le Falcon était paradoxalement un ordi tourné vers l'avenir et avait donc besoin de beaucoup de RAM vu la technologie qu'il embarquait !
Or tu ne peux pas faire ce que tu veux quand tu dois créer une archi mémoire rapide avec accès entrelacés.
Si Atari avait décidé de faire un BUS 32 Bits on aurait eu des configurations mémoires de 2Mo ou 8Mo. 8 aurait été beaucoup trop cher et 2Mo aurait été trop peu. Avec un BUS 16 Bits tu as la possibilité d'avoir 4Mo ou 16Mo (en fait 14 sur Falcon). C'est un ingénieur hardware connu dans le monde Atari qui a expliqué ça il y a déjà trèèèès longtemps.

Je suis d'accord avec toi sur la totalité de ton post, sauf sur cette histoire de bus de données 16-bit pour la CPU.
Tu dis que le Falcon était tourné vers l'avenir et donc devait utiliser de la RAM issue du passé sur un bus 16-bit.
Rien ne te dérange ? Je veux dire, à la sortie du Falson ça faisait déjà 3 ans qu'on trouvait de la SIMM-72 (32-bit).
Ca, c'était l'avenir (le présent en fait) ... Et non pas de faire une PCB propréiétaire là ou une barette seule aurait suffie.
La SIMM-72 était dispo en capacités de 1/2/4/8/16Mo dans un premier temps, puis 32/64/128Mo dans un second temps.

Je pense plutôt que le choix du bus 16-bit était jugé comme étant un bon compromis pour le design de la machine. Ca simplifie grandement le rooting de la carte mère dont la densitée est déjà impressionnante. Car à partir du moment ou l'on utilise des puces de RAM 4-bit, la largeur du bus de données est juste fonction de leurs agencement. (par 2 en 8-bit, par 4 en 16-bit et par 8 en 32-bit)

[Templeton]

>>Je pense plutôt que le choix du bus 16-bit était jugé comme étant un bon compromis pour le design de la machine. Ca simplifie grandement le rooting de la carte mère dont la densitée est déjà impressionnante.
 Car à partir du moment ou l'on utilise des puces de RAM 4-bit, la largeur du bus de données est juste fonction de leurs agencement. (par 2 en 8-bit, par 4 en 16-bit et par 8 en 32-bit) .

 
Quand je dis tourné vers l'avenir, je parle de la manipulation des données en haute résolution pour le son (16bit) et le graphisme (16bit) plus le traitement des signaux numériques à haute vitesse via le DSP.
Je ne fais que rapporter les propos d'un ingénieur Hardware qui a conçu des cartes mères et cartes accélératrices à cette époque.
Ne pas avoir choisi de SIMM-72 (32-bit) vient sans doute du coût de cette dernière ou de sa disponibilité.
Le choix d'Atari c'était un compromis judicieux, surtout quand on a un deuxième CPU qui peut travailler seul dans son coin avec un bus mémoire (plusieurs en fait) qui tourne à une vitesse stratosphérique.
Ton hypothèse sur la densité de la carte mère est intelligente mais n'est pas valable sur le Falcon, car sur ce dernier la chip ram n'est pas sur la carte mère et contrairement au ST il y a de nombreuse couches !
La chip ram est soudé sur une carte fille qui se plug sur le Bus mémoire (il y a beaucoup de la place entre la carte mère et le clavier).
Maintenant peut-être qu'on aura le fin mot de l'histoire bientôt, MiKRO (un atariste réputé) a réussi à entrer en contact avec un gros gourou hardware de chez Atari sur cette période et il va lui poser de nombreuses questions, celle ci doit être sur la liste.