Re: GUERRE ST-AMIGA, FIGHT !!!

par vicomte Sam 11 Juin - 18:39

je pense que les filles aussi on un "mot" à dire Wink

par **TotOOntHeMooN** Sam 11 Juin - 21:13

babsimov a écrit:Là, ça dépasse mes compétences technique, je veux bien croire que ça aurait été mieux, une sorte de dual playfield hardware (avec deux blitter ?)

Mais, cela m'amène à quelques questions, ces deux plans 4 bits aurait t il permit d'avoir un affichage 8 bit en 256 couleurs ? Cet affichage en 256 couleurs sur 2 plans aurait il été plus rapide qu'une affichage 8 bit de 8 x 1 plan ? Bref, l'AGA aurait il été plus rapide en général en 256 couleurs avec cette option ?

N'aurait il pas mieux valu tout simplement avoir un affichage bitplan de type ECS (6bit), pour la compatibilité et un mode chunky 4 et 8 bit. Il y aurait eux deux plans, un plan bitmap (jusqu'à 6 bit) et un plan chunky 4 et 8 bits, qui aurait pu fonctionner en dual playfield. Est ce une option intéressante ? Techniquement faisable ?

Ca aurait été adapté à des jeux typés arcade sur deux plans.(tel une Megadrive)
Non, on aurait pas eu de mode 256 couleurs... Mais vu la lenteur il ne sert de toute façon à rien.
Oui, avoir des modes Chunky avec le blitter qui va bien plutôt que l'AGA aurait été mieux.

par babsimov Dim 12 Juin - 0:05

TotOOntHeMooN a écrit:
babsimov a écrit:Là, ça dépasse mes compétences technique, je veux bien croire que ça aurait été mieux, une sorte de dual playfield hardware (avec deux blitter ?)

Mais, cela m'amène à quelques questions, ces deux plans 4 bits aurait t il permit d'avoir un affichage 8 bit en 256 couleurs ? Cet affichage en 256 couleurs sur 2 plans aurait il été plus rapide qu'une affichage 8 bit de 8 x 1 plan ? Bref, l'AGA aurait il été plus rapide en général en 256 couleurs avec cette option ?

N'aurait il pas mieux valu tout simplement avoir un affichage bitplan de type ECS (6bit), pour la compatibilité et un mode chunky 4 et 8 bit. Il y aurait eux deux plans, un plan bitmap (jusqu'à 6 bit) et un plan chunky 4 et 8 bits, qui aurait pu fonctionner en dual playfield. Est ce une option intéressante ? Techniquement faisable ?
Ca aurait été adapté à des jeux typés arcade sur deux plans.(tel une Megadrive)
Non, on aurait pas eu de mode 256 couleurs... Mais vu la lenteur il ne sert de toute façon à rien.
Oui, avoir des modes Chunky avec le blitter qui va bien plutôt que l'AGA aurait été mieux.

Le mode 256 est lent en haute résolution, autrement pour les jeux de l'époque 256 était le standard (PC/AGA). C'est pour la 3D texturée que l'AGA aurait eu besoin de mode chunky.
Mais, dire que les 256 couleurs de l'AGA ne servent à rien c'est, à mon sens, un peu exagéré.

Il aurait été souhaitable que le AA+ sorte à la place de l'AGA :
http://obligement.free.fr/articles/aa+.php

Dommage que Commodore n'est pas sortie ça avec le 3000 (c'est à dire fait évoluer l'Amiga correctement).

par ryosaeba Sam 23 Juil - 18:42

un petit comparatif : http://amiga.lychesis.net/knowledge/Comparison.html

par dlfrsilver Sam 23 Juil - 19:18

ryosaeba a écrit:un petit comparatif : http://amiga.lychesis.net/knowledge/Comparison.html

J'ai regardé rapidos ton lien, et clairement, on ne peut pas s'appuyer simplement sur ce qui est marqué sur le papier.

Les Atari ont beau utiliser un 68000 clocké à 8mhz, comme le 68000 est utilisé pour tout (programme et affichage), la machine ralenti comme si l'horloge n'était qu'à 4mhz, puisque le 68000 assure le boulot d'exécution du programme, mais fait aussi le boulot normalement dévolu à une puce graphique.

L'amiga lui a beau avoir sur le papier un clock d'horloge un poil moins rapide, le 68000 est utilisé pas à plus de 50%.

J'ai jamais vu un jeu amiga utilisant le CPU à 100% (en dehors des ports de softs direct du ST n'utilisant pas la machine pour ce qu'elle est).

En bref, le 68000 de l'amiga a de quoi être plus véloce que celui du ST malgré la vitesse d'horloge plus importante de ce dernier.

La différence en mhz côté Atari ST est complètement bouffé par le mode d'utilisation du 68000. Les 12% de clock en plus sont là pour atténuer la lenteur de la machine.

par **TotOOntHeMooN** Sam 23 Juil - 20:58

Non mais sur un Amiga de base, le 68000 n'a pas accès à la RAM en direct. (pas de fast)
Donc, il serait moins rapide que sur ST même s'il tournait à une fréquence supérieure.

par dlfrsilver Sam 23 Juil - 22:12

TotOOntHeMooN a écrit:Non mais sur un Amiga de base, le 68000 n'a pas accès à la RAM en direct. (pas de fast)
Donc, il serait moins rapide que sur ST même s'il tournait à une fréquence supérieure.

Tu compares les deux comme si les machines fonctionnaient sur le même principe sous prétexte d'utiliser le même CPU. Hors ce n'est pas le cas. La vitesse de clock du ST est perdue car le CPU est noyé par le flux d'information qu'il doit traiter (programme+affichage+Logique de jeu), tandis que sur l'Amiga le CPU ne gère que le programme, toute la partie sonore, graphique et animation est gérée par le chipset, qui est infiniment plus rapide que le 68000 tout seul.

C'est pas pour rien que pour parvenir à un résultat similaire à un simple A500, il aura fallu que le ST ait un CPU clocké à 20 mhz au lieu de 8.

Quand bien même, et de toute façon le 68000 de l'amiga est ralenti de force via une horloge qui tourne moins vite pour se synchroniser avec le chipset.

Ensuite la RAM utilisée sur l'Amiga est plus rapide que celle utilisée sur les Atari ST. Sur ST tout est ralenti car le CPU est monopolisé en permanence, alors que sur un Amiga, c'est pas le cas, l'usage CPU ne dépasse pas 50%, là ou sur ST le CPU est occupé à 98% pour un résultat inférieur.

par Invité Sam 23 Juil - 22:58

dlfrsilver a écrit:
C'est pas pour rien que pour parvenir à un résultat similaire à un simple A500, il aura fallu que le ST ait un CPU clocké à 20 mhz au lieu de 8.

d'ou viennent ces chiffres ? c'est pas un peu exagéré?

par dlfrsilver Sam 23 Juil - 23:26

kaot a écrit:
dlfrsilver a écrit:
C'est pas pour rien que pour parvenir à un résultat similaire à un simple A500, il aura fallu que le ST ait un CPU clocké à 20 mhz au lieu de 8.

d'ou viennent ces chiffres ? c'est pas un peu exagéré?

Non ce n'est pas exagéré, deux raison :

1) l'Amiga dispose d'une accélération matérielle, pas l'Atari

2) un 68000 à 20mhz + 2mo de ram constitue l'équivalent du combo 68000@7mhz+Chipset de l'Amiga+1mo de ram.

Concrètement, avec 20mhz de clock, le ST même avec 16 couleurs de palette de base, peut du coup faire
tout ce qu'un Amiga 500 peut faire de base, ex:

- Du changement de palette sans perte de cycle CPU ni de ralentissement, donc par exemple utiliser 5 ou 6 palettes de 16 couleurs là ou un ST classique avec 8 mhz seulement patauge grave dans la choucroute,

- Du scrolling parallaxe, des effets complexes, etc ;

- Utiliser des sprites gigantesques comme ceux qu'on peut voir sur Amiga, au lieu de sprites comme ceux des ordinateurs 8 bits ;

En bref, avec ça, tu portes tranquille Lionheart, Jim Power, Shadow Of the Beast 1,2,3, Brian the Lion, Flashback, et tout un tas d'autres jeux infaisables sur un ST de base avec tout les effets et l'animation de qualité qui va avec.

par Invité Sam 23 Juil - 23:30

dlfrsilver a écrit:
- Utiliser des sprites gigantesques comme ceux qu'on peut voir sur Amiga, au lieu de sprites comme ceux des ordinateurs 8 bits ;

par dlfrsilver Sam 23 Juil - 23:50

kaot a écrit:
dlfrsilver a écrit:
- Utiliser des sprites gigantesques comme ceux qu'on peut voir sur Amiga, au lieu de sprites comme ceux des ordinateurs 8 bits ;

Ben oui, tu as vu toi des jeux Atari ST avec des sprites gigantesques ? J'écarte Beast sur ST, parce que c'est un jeu Amiga de base. Les jeux ST se distinguent par des petits sprites.

J'ai dit un truc qui fallait pas ? MDR

par **TotOOntHeMooN** Dim 24 Juil - 0:41

dlfrsilver a écrit:Tu compares les deux comme si les machines fonctionnaient sur le même principe sous prétexte d'utiliser le même CPU. Hors ce n'est pas le cas.

Je compare ce qui est comparable.

par dlfrsilver Dim 24 Juil - 0:43

TotOOntHeMooN a écrit:
dlfrsilver a écrit:Tu compares les deux comme si les machines fonctionnaient sur le même principe sous prétexte d'utiliser le même CPU. Hors ce n'est pas le cas.
Je compare ce qui est comparable.

C'est à dire ? L'amiga n'utilise pas le 68000 pour faire les mêmes choses que le ST. Même CPU, electronique et fonctionnement différent, donc comment, est-ce que tu peux développer ?

par rocky007 Mer 27 Juil - 23:09

petit sprite ? encore une affirmation ridicule... les sprite sont tout aussi gros que sur l'amiga, simplement le framerate est plus lent.

par dlfrsilver Jeu 28 Juil - 8:01

rocky007 a écrit:petit sprite ? encore une affirmation ridicule... les sprite sont tout aussi gros que sur l'amiga, simplement le framerate est plus lent.

Salut Rocky, si tu fais allusion à Beast, c'est un port qui vient de l'Amiga. Tout les jeux natifs du ST utilisent systématiquement des petits sprites oui, je vois pas en quoi c'est ridicule.

par **TotOOntHeMooN** Jeu 28 Juil - 8:40

dlfrsilver a écrit:C'est à dire ? L'amiga n'utilise pas le 68000 pour faire les mêmes choses que le ST. Même CPU, electronique et fonctionnement différent, donc comment, est-ce que tu peux développer ?

Pourtant, bon nombres de logiciels Amiga n'utilisent pas ces spécificités et sont donc très comparable en terme d'utilisation à un ST ou autre machine à base de 68000...

C'est marrant, mais sur Amiga lorsqu'on veut comparer la puissance de la machine par rapport à une autre machine, on se base sur SysInfo ou AIBB qui ne font que ressortir les performances CPU/FPU... Mais dès lors qu'on parle d'une machine de base sans FAST, on ne peut plus faire ainsi ? Razz

par dlfrsilver Jeu 28 Juil - 9:11

TotOOntHeMooN a écrit:
dlfrsilver a écrit:C'est à dire ? L'amiga n'utilise pas le 68000 pour faire les mêmes choses que le ST. Même CPU, electronique et fonctionnement différent, donc comment, est-ce que tu peux développer ?
Pourtant, bon nombres de logiciels Amiga n'utilisent pas les spécificités et sont donc très comparable en terme d'utilisation à un ST ou autre machine à base de 68000...

C'est marrant, mais sur Amiga lorsqu'on veut comparer la puissance de la machine par rapport à un autre Amiga ou même une autre machine, on se base sur SysInfo ou AIBB qui ne font que ressortir les performances CPU/FPU... Mais il ne faut surtout pas utiliser ce principe si l'on parle d'une machine de base sans FAST.

Salut, oui, les logiciels dont tu parles sont programmés uniquement au 68000. c'est comme si tu portais un jeu megadrive, et que tu restais en 64 couleurs sur une neogeo, et que tu viennes dire après coup que la neogeo est comparable à la megadrive, sous prétexte que les deux utilisent un 68000. C'est une aberration !

l'amiga étant largement plus puissant qu'un Atari ST (et de loin), qui peut le plus peut le moins, n'importe quel jeu ST avec des graphismes en 16 couleurs peut tourner sur un Amiga. La différence vient du hardware, par essence, les moteurs en software, c'est de la merde, tandis que les moteurs de jeu utilisant des routines hard sont bien meilleurs (en terme de vélocité, en terme de framerate). Les moteurs software ne peuvent que tourner plus lentement sur Amiga, étant donné qu'il sont basé strictement sur le clock d'horloge du CPU. Quand ce genre de jeu tourne sur un Amiga, on force la machine à tourner au ralenti artificiellement. Un Amiga peut tourner en 50 images secondes en affichant 64 couleurs à l'écran à fond les balais, donc pourquoi utiliser du code ST qui va forcer l'Amiga à être lent, avec un frame rate minable en 20 fps, et des sprites d'une taille ridicule ? C'est quoi l'intérêt de faire de l'émulation de ST sur un Amiga ?

Je reviens à mon exemple concernant la neogeo et la megadrive, si j'ai acheté une neogeo, c'est pour jouer à des jeux qui tirent le maximum de la machine, et pas des jeux megadrive inférieurs tournant sur neogeo, sinon j'aurais acheté une megadrive :)

Remplace neogeo par amiga, et megadrive par Atari ST, tu comprendras ou je veux en venir :)

Concernant les comparaisons de puissance entre Amiga, c'est normal de se baser sur Sysinfo, puisque même les amiga ont la même base hardware, seule le jeu d'instruction et la vitesse du 680X0 change. On compare bien des hardwares qui sont similaires.

Un Atari ST n'a que son 68000 en commun avec l'Amiga, tout le reste n'a rien à voir. Et le 68000 n'est absolument pas utilisé pour faire les même choses entre les deux machines.

L'atari ST c'est rien d'autre qu'un CPC 16 bits en moins bien (et avec moins de possibilité sur le plan vidéo), sachant que l'Amiga écrasait déjà d'une grande hauteur le CPC, le ST n'apportant rien de plus techniquement, l'issue est simple : l'Amiga met le ST KO :)

par **TotOOntHeMooN** Jeu 28 Juil - 9:28

Je suis bien d'accord avec ce que tu dis car je sais très bien que l'Amiga est globalement plus puissant qu'un ST. Après, tout dépend de l'usage pour lequel est destiné la machine... Evidemment, ici on parle de jeux vidéo donc il n'y a pas débat. Mais d'autres ont fait le choix du ST pour ses logiciels, son OS et l'échange de fichiers avec des disquettes compatibles PC... Et là, c'est juste les performances CPU qui importent et pas l'aspect console que peut avoir un Amiga.

Concernant la NeoGeo... Même si ça foutait une claque, on s'amusait quand même mieux sur MD ou SNES. Mr. Green

par Invité Jeu 28 Juil - 12:31

dlfrsilver a écrit:
rocky007 a écrit:petit sprite ? encore une affirmation ridicule... les sprite sont tout aussi gros que sur l'amiga, simplement le framerate est plus lent.

Salut Rocky, si tu fais allusion à Beast, c'est un port qui vient de l'Amiga. Tout les jeux natifs du ST utilisent systématiquement des petits sprites oui, je vois pas en quoi c'est ridicule.

En fait des sprites softwares (qui sont utilisés sur ST) n'ont pas de contrainte de tailles Wink

.
La différence est qu'ils sont dépendants du CPU, et du reste du système pour être animés, et là c'est une autre histoire .

@Toto: tu entends quoi par le CPU n'a pas un accès direct à la chip ram ??

Et là, c'est juste les performances CPU qui importent et pas l'aspect console que peut avoir un Amiga.

Pas forcement, tu peux utiliser le hard pour déplacer des fenêtres par exemple, afficher plus de couleurs, etc ..,tout en gardant une fluidité supérieure au tout CPU .

par **TotOOntHeMooN** Jeu 28 Juil - 12:51

J'ai écrit ça ? Very Happy

Je voulais surtout dire que le 68000 de l'Amiga est par défaut pénalisé par les accès mémoires en Chip, s'il est dépourvu de Fast.

par Invité Jeu 28 Juil - 15:55

Ah ok ..

Tu avais écrit ça :

Non mais sur un Amiga de base, le 68000 n'a pas accès à la RAM en direct. (pas de fast)

D'où mon intérrogation,ça laissait sous entendre qu'il faille passer par un port pour accéder à la chip ..

par dlfrsilver Jeu 28 Juil - 17:48

TotOOntHeMooN a écrit:Je suis bien d'accord avec ce que tu dis car je sais très bien que l'Amiga est globalement plus puissant qu'un ST. Après, tout dépend de l'usage pour lequel est destiné la machine... Evidemment, ici on parle de jeux vidéo donc il n'y a pas débat. Mais d'autres ont fait le choix du ST pour ses logiciels, son OS et l'échange de fichiers avec des disquettes compatibles PC... Et là, c'est juste les performances CPU qui importent et pas l'aspect console que peut avoir un Amiga.

Concernant la NeoGeo... Même si ça foutait une claque, on s'amusait quand même mieux sur MD ou SNES.

Il est clair qu'il y a des logiciels qu'on trouve uniquement sur ST et pas sur Amiga. Pour autant que je sache, tout ces logiciels auraient pu tourner sans aucun problème sur Amiga si les éditeurs avaient voulu les sortir sur cet ordinateur.

L'OS de l'Atari ST n'a rien de particulier (vraiment....) Et concernant l'échange avec des disquettes PC compatible, il faut savoir que l'Amiga sait lire lui aussi le format ST et PC, mais pas que, avec un pilote adéquat, il peut lire aussi les disquettes macintosh encodée au format GCR, les format C64 (suffit d'avoir le lecteur de disquette).

Tout ça ne requiert aucune performance CPU, tout est géré en hardware via Paula.

Je lisais même dernièrement la réponse sur youtube d'un musicien qui se servait de l'Amiga pour faire de la MAO, qui disait que l'histoire ou du moins le mythe de la précision du ST pour faire de la MAO, c'était complètement bidon : il expliquait par exemple que Music-X 2.0 taillait des shorts à Notator sur Atari ST, et que les outils sortis sur Amiga certes moins nombreux faisaient admirablement bien le boulot.

Je connais au moins un grand qui utilisait l'Amiga pour faire de la MAO, c'est Chris Huelsbeck. Et faut voir la quantité de matos qu'il avait, voir la liste de celle utilisée par exemple pour faire la musique de fin de Apidya, incroyable le nombre d'éléments pilotés par un Amiga.

Ah je précise, il a composé la musique d'Apidya en format multipistes, et il a ensuite soundtracké (donc simplifié) la musique via le système TFMX 7 voix.

Finalement, la seule excuse ou raison d'utiliser un Atari ST, enfin quoi que je sais pas finalement, parce que les outils pour faire du séquençage et du MIDI coutaient le même prix sur Amiga et sur ST.

Notator coutait pas moins cher que Music X 2.0, qui lui même ne nécessitait pas un écran monochrome comme sur Atari ST (style SM-124).

J'ai lu aussi un post sur le forum EAB d'un mec qui utilisait EMUtos sur Amiga 600, et qui faisait tourner dessus par ce biais Notator 3.0 pour Atari ST, et ça tourne sans aucun problème.

Bref, fin du petit aparté, sinon je suis bien d'accord qu'un certain nombre de jeux de mégadrive avaient plus d'intêret (enfin quoi que...) que sur la neogeo.

Metal Slug est une série qui s'appele reviens-y quand même, c'est toujours hyper plaisant à jouer :)

par Invité Jeu 28 Juil - 17:54

Bref, fin du petit aparté, sinon je suis bien d'accord qu'un certain nombre de jeux de mégadrive avaient plus d'intêret (enfin quoi que...) que sur la neogeo.

L'avantage des consoles, étaient aussi d'avoir tout les styles de jeux contrairement à la NG .
Franchement un SOR est plus plaisant à jouer que mutation nation,burning fight,ou un robot army, qui étaient franchement beaux, mais assez nul à jouer .

par dlfrsilver Jeu 28 Juil - 18:16

TOUKO a écrit:
Bref, fin du petit aparté, sinon je suis bien d'accord qu'un certain nombre de jeux de mégadrive avaient plus d'intêret (enfin quoi que...) que sur la neogeo.
L'avantage des consoles, étaient aussi d'avoir tout les styles de jeux contrairement à la NG .
Franchement un SOR est plus plaisant à jouer que mutation nation,burning fight,ou un robot army, qui étaient franchement beaux, mais assez nul à jouer .

Clairement, les 3 jeux neogeo que tu cites ont de bons graphismes arcade, mais on sent bien qu'ils sont faibles d'un point de vue programme/logique de jeu. on le sent quand on joue, déjà y a assez peu d'étapes d'animation, et ça se sent dans les 3 titres, qui ont disons-le franchement très mal vieilli.

La débauche d'effets spéciaux contraste méchamment avec les animations qui sont franchement pauvre. ça jure quand on y prête attention lors d'une partie.

par Invité Jeu 28 Juil - 19:18

Oui voilà, rien a voir avec les sengoku 2 et 3 (surtout le 3) par contre .
Sur NG,en plus y'a pas de RPG, de simulations,RTS,jeux de sports (je crois) .

par Invité Jeu 28 Juil - 19:27

heu super sidekicks et neo turf masters, ca compte pas ?

par Invité Jeu 28 Juil - 19:33

kaot a écrit:heu super sidekicks et neo turf masters, ca compte pas ?

Si c'est vrai, mais étaient bien orientés arcade ??
Pour side kick (même en étant un super jeu), je suis pas sur que tu t'amusais autant que fifa ou iss .

par babsimov Jeu 28 Juil - 20:06

TotOOntHeMooN a écrit:J'ai écrit ça ?
Je voulais surtout dire que le 68000 de l'Amiga est par défaut pénalisé par les accès mémoires en Chip, s'il est dépourvu de Fast.

Sauf erreur de ma part, il me semble qu'il y a quelques pages en arrière, Stapha92 nous a expliqué en détail comment justement, même en absence de Fast, le 68000 perdait moins de cycles mémoire que le 68000 sur ST, parce que le Shifter du ST prenait des cycles au 68000 même quand il n'y avait d'accès graphique, à la différence du chipset Amiga qui ne prend des cycles au 68000 de l'Amiga que lorsqu'il en a besoin.

Résultat, mêmes sans Fast le 68000 "s'exprime" mieux sur Amiga.

Je cite de mémoire, il faudrait retrouver la réponse de Stapha92.

La véritable force du ST n'est nullement les quelques khz de plus de son 68000, ni sa prise MIDI, ni son OS, mais SURTOUT son prix (au début).

Dès que l'Amiga a vu son prix se rapprocher du ST, fini le ST. Jack Tramiel a même tenté le coup de vendre le 520STF à perte 2990 frs quand l'Amiga est passé à 4290 frs.... et a du monter le prix du STF six mois plus tard à 3490 frs.... Et à ce moment là on trouvait l'Amiga 500 à 3990 frs. Pour 500 frs de plus y avait pas photo on prenait un Amiga.

par **TotOOntHeMooN** Jeu 28 Juil - 20:11

dlfrsilver a écrit:L'OS de l'Atari ST n'a rien de particulier (vraiment....) Et concernant l'échange avec des disquettes PC compatible, il faut savoir que l'Amiga sait lire lui aussi le format ST et PC, mais pas que, avec un pilote adéquat [...] Metal Slug est une série qui s'appele reviens-y quand même, c'est toujours hyper plaisant à jouer :)

Tu parles de choses qui sont arrivés sur le tard... Sur un ST de base avec son OS en ROM localisé en français, c'était déjà tout inclus et bien plus ergonomique que le Workbench 1.3. Quand à Metal Slug, plaisant à jouer "aujourd'hui", sauf que le premier est sorti en 1996 et que ça faisait déjà un bail que la MD et l'Amiga étaient hors circuit !

par Invité Jeu 28 Juil - 20:15

@basimov: Je sais que le 68k de l'amiga est impacté quand tu utilises le chipset, donc si tu fais tout au CPU (avec seulement l'audio), ça devrait rien impacter niveau accès, car le CPU aura l'accès exclusif à la CHIP .

SLOW RAM/FAST RAM n'a absolument rien à voir avec la rapidité des puces soit dit en passant,contrairement à ce que certains prétendent .

par babsimov Jeu 28 Juil - 20:54

Voici la réponse de Stapha92 concernant les cycles, on peut la trouver ici :
https://www.gamopat-forum.com/t82337p60-guerre-st-amiga-fight

Je fais un copier coller :

"Le cycle représente l'unité de base temporelle d'un processeur. A chaque cycle, un signal est envoyé par une horloge (un quartz, un oscillateur, etc..) au 68000 via une broche dédiée (l'une des "pattes" du microprocesseur). On dit qu'il est "cadencé". A chacun de ces "tops", des actions très élémentaires sont effectuées par le 68000. Plus la vitesse à laquelle sont envoyés ces signaux est élevée, plus le processeur tourne vite. Mais il y a une limite au-delà de laquelle le processeur ne pourra pas aller. ça peut être parce que les élements internes qui le composent ne pourront pas changer d'état assez rapidement. Ou parce que le processeur se mettra à trop chauffer. En effet à chaque fois que des "actions élementaires" sont effectuées, il y a circulation de courant dans le processeur et donc création de chaleur. Plus le processeur va vite et plus il consomme et plus il chauffe.

Les 68000 qui se trouvent dans un mig ou un ST sont les mêmes. Mais celui du ST est cadencé à 8 Mhz alors que celui du mig à 7,14. C'est l'horloge qui le controle qui diffère.

La RAM :

La RAM d'un ordinateur est divisé en "cases". Dans une architecture 8 bits, chaque case fait un octet (8 bits). Dans une architecture 16 bits, chacune fait un mot (16 bits). Concretement, cela signifie qu'il y a 8 ou 16 fils qui véhiculent la donnée à lire ou à ecrire (en schématisant). Chaque fil correspondant à un bit, il transmet la valeur 0 ou 1. On appelle cet ensemble de fils le bus de données.
Cela ne suffit pas pour accéder à la RAM : c'est bien beau d'être capable de véhiculer une donnée. Mais il faut également pouvoir indiquer depuis ou vers quelle case le faire. Chacune des cases qui composent la RAM reçoit donc un numéro. Donc en plus du bus de données, on utilise un autre ensemble de fils qui permet d'indiquer le numéro de la case à laquelle on souhaite accéder. Ce numéro de case s'appelle "l'adresse". Ce deuxième ensemble de fils s'appelle donc le bus d'adresse ou d'adressage. Ce système permet d'accéder à n'importe quel case sans contrainte (En fait il peut y en avoir mais on va ignorer çat. De toute façon ça ne concerne pas le ST ou le MIG). C'est à cause de catte faculté que la mémoire est appelée RAM (Random Access Memory). On peut très bien imaginer une mémoire à laquelle on accède à une case en lisant toutes celles qui précèdent de façon séquentielle. ça serait bien de la mémoire vive, mais pas de la RAM.

Maintenant les RAM ont une vitesse : quand tu veux lire ou écrire une donnée, ça n'est pas immédiat. ça prend un certain temps. Par exemple, 125 nanosecondes. Soit 0,000 000 125 secondes. Donc il sera possible d'accéder à la RAM 8 000 000 de fois par seconde. On parlera dans ce cas de RAM à 125 nanosecondes ou 8 Mhz. On y reviendra.

Revenons un peu au 68000, représenté par le schéma ci-dessous :

Agrandir cette image

Si tu observes ce schema, on peut y voir :

16 broches D0 à D15 : c'est le bus de données qui est bien sur 16 bits.
23 broches A1 à A23 : c'est le bus d'adressage qui est sur 23 bits. Le 68000 peut donc gérer une RAM de 2 puissance 23 = 8 388 608 mots. Le double si on parle en octet. Ce qui fait 16 Mo.
2 broches LDS/UDS : elle permettent d'indiquer si le 68000 doit accéder à l'octet qui se trouve dans les broches D0 à D7 (LDS=1, UDS=0), D8 à D15 (LDS=0, UDS=1) ou D0 à D15 pour traiter un mot (LDS=0, UDS=0). Ce système permet au 68000 accéder à un octet seul. Comme un bon vieux 8 bits. Ce n'est pas le cas de tous les processeurs 16 bits.
1 broche R/W : elle indique si le processeur veut faire une lecture ou une ecriture (Read/Write).
1 broche CLK : C'est la broche qui reçoit le signal d'horloge (les "tops" donc je parlais au début. CLK = clock.

Sur la RAM, on retrouve aussi un bus de données, un bus d'adresses et un signal R/W. Si on les relit aux bus du 68000, ce dernier pourra travailler avec la ram. Si elle est assez rapide, il s'exprimera pleinement sans jamais subir de ralentissement. Simple et efficace.

Mais insuffisant ! Cette RAM ne peut être utilisée que par le 68000 ! Or, pour pouvoir afficher une image contenu dans cette même ram, elle doit pouvoir être accessible par le shifter (ST) ou Denise (Amiga).

Comment faire ? Et bien on ne va pas relier le 68000 directement à la RAM : on va intercaler entre les 2 un controleur mémoire (MMU dans le ST et Agnus dans le mig). Ce dernier sera d'un coté relié à la RAM et de l'autre à Denise ou au shifter. Un aiguillage qui va changer de coté 7,14 millions de fois par seconde pour le mig ou 4 millions de fois par seconde pour le ST. Donc à chaque fois que cet aiguillage se trouve dans une position, il y a le temps de faire un accès pour le mig ou 2 pour le ST.
La vitesse à laquelle correspond ce basculement n'est pas un hasard : ça correspond à un cycle processeur pour le mig et 2 cycles pour le ST. Dans les 2 cas, les concepteurs auront prévu une RAM assez rapide pour permettre cet accès dans ce laps de temps.

L'accès à la RAM est donc ralenti. Mais ce n'est pas grave ! Car le 68000 ne peut absolument pas accéder à la RAM tous les cycles : les instructions les plus rapides prennent 4 cycles. Pas de problème donc.

Vraiment pas ? Mais si une instruction prend 5 cycles, quand elle sera terminée et que le 68000 aura besoin de lire la prochaine, l'aiguillage sera du mauvais coté et le 68000 devra attendre un cycle de plus ! Et oui ! Sauf que... Aucune instruction ne prend 5 cycles sur le 68000. On pourrait faire le même raisonnement avec un instruction à 7 cycles. Mais on va arreter là : toutes les instruction du 68000 prennent un nombre de cycles qui est un multiple de 2. Il n'y aura jamais de ralentissement.

C'est ce que se sont dit les concepteurs du mig : puisque le 68000 fonctionne comme ça, on peut se permettre de réserver un accès mémoire sur 2 au chipset.

Les concepteurs du ST se sont plutot concentrés sur la durée minimum de 4 cycles. la plupart du temps cela revient au même. Sauf que lorsqu'une instruction prend 6 cycles, le 68000 du ST sera obligé d'en attendre 2 de plus pour pouvoir lire l'instruction suivante. Idem pour une instruction qui prend 10 cycles. Le nombre réel sera toujours arrondi au multiple de 4 supérieur.
Soyons clair : ça n'est absolument pas aussi grave qu'il n'y parait : la majorité des instructions du 68000 prennent déjà un nombre de cycles multiple de 4.
Simplement, quand Shiraz Shivji expliquait que le bus du ST était plus performant que celui du mig, il mentait à toute la communauté ST...

Revenons sur le mig. Est-ce aussi simple ? Est-ce que le mig n'est vraiment jamais ralenti ? Voyons ce qui se passe dans un mig avec un écran basse résolution en 16 couleurs :
(je schématise beaucoup et je triche sur l'ordre. mais ça ne change rien au principe)

Cycle 1 : Lecture des données du bitplan 1 (16 bits)
Cycle 2 : Libre pour le 68000
Cycle 3 : Lecture des données du bitplan 2 (16 bits)
Cycle 4 : Libre pour le 68000
Cycle 5 : Lecture des données du bitplan 3 (16 bits)
Cycle 6 : Libre pour le 68000
Cycle 7 : Lecture des données du bitplan 4 (16 bits) -> Affichage des 16 premiers pixels
Cycle 8 : Libre pour le 68000
Cycle 9 : Lecture des données du bitplan 1 (16 bits)
Cycle 10 : Libre pour le 68000
Cycle 11 : Lecture des données du bitplan 2 (16 bits)
Cycle 12 : Libre pour le 68000
Cycle 13 : Lecture des données du bitplan 3 (16 bits)
Cycle 14 : Libre pour le 68000
Cycle 15 : Lecture des données du bitplan 4 (16 bits) -> Affichage des 16 pixels suivants

Et ainsi de suite...

On se rend compte d'une chose : pendant l'affichage, tous les cycles réservés à Denise sont utilisés : Comment faire pour afficher 32 couleurs (5 bitplans) ou 64 (6 bitplans) ?
Et bien c'est simple : on va utiliser certains des cycles initialement réservés au 68000. Pour 32 couleurs, il nous faut un 5eme bitplan : on va lire ses données pendant les cycles 6 et 14 dans l'exemple ci-dessous. Si le 68000 cherche à accéder à la mémoire pendant l'un de ces cycles, il devra attendre 2 cycles.
Pour un affichage en 6 bitplans, ce sont les cycles 2 et 10 qui vont être pris. Pourquoi 2 et 10 et non pas 4 et 12 ? Pour s'assurer qu'il y avait toujours un cycle libre entre les 2 cycles perdus. Ceci afin de s'assurer que la latence imposée au 68000 ne dépasse jamais 2 cycles.

Partant de ce constat, les concepteurs se sont fixés 2 contraintes :
- Les cycles ne devront être "volés" que pendant l'affichage. Ainsi, en 320x200x32 couleurs, il y aura 20x200 = 4 000 cycles perdus par frame. Et encore, c'est un maximum : le 68000 ne va pas tomber sur ces cycles à chaque fois.
- Ce "vol" de cycles ne devra s'effectuer que si besoin : pas question de laisser ce système activé si on affiche un ecran en 16 couleurs ou moins.
Il a donc fallu passer d'un controleur mémoire qui se contentait de basculer entre denise et le 68000 à chaque cycles à un controleur capable d'adapter ses basculements au besoin.
On est passé d'un système statique à un système dynamique. Le ST ne dépassant pas 16 couleurs, il peut se contenter d'un système statique.

Et ça ne s'arrete pas là ! Et oui : dans le mig, il y a des copro qui peuvent avoir besoin d'accéder à la mémoire. Et le controleur doit pouvoir leur donner acces à la demande : il ne sait pas d'avance quels cycles réserver. Par exemple, il ne sait quand Paula aura besoin de lire un sample à l'avance : il doit lui envoyer quand il y en a besoin (en tout cas c'est le système qui a été choisi dans ce cas, car c'est le plus souple).
Et il peut même y avoir des demandes d'accès simultanés de plusieurs copro ! Il faudra déterminer lequel doit être mis en attente.

On n'est plus dans un simple controleur mémoire, c'est un circuit qui doit controler et prioriser toutes les demandes d'accès à la chip ram. Ces demandes peuvent parvenir de plusieurs sources : il y en a 25. Ce sont les fameux 25 canaux DMA du mig...

Et les concepteurs ont fait du bon boulot : Par exemple, le fait de pouvoir envoyer à Paula un sample à la demande et non de façon régulière et imposée est ce qui permet à Paula de faire des variations de tonalité. C'est ce qui permet au mig de reproduire des mod avec une meilleure qualité que ses concurrents tout en consommant moins de cpu.
Autre exemple : lorsque le blitter fait une opération et que le 68000 souhaite accéder à la chip-ram, le controleur peut interrompre le blitter juste le temps d'un cycle pour permettre au 68000 de ne pas rester bloqué. D'autant qu'avec de la fast-ram, le 68000 travaille en même temps que le blitter : il aurait été dommage de bloquer son traitement juste à cause d'un accès à la chip...
Et ça peut être primordiale par exemple si une interruption est déclenchée : sans ce système, le 68000 ne pourrait pas y répondre (s'il n'y avait pas de fast-ram). C'est ce qui arrive avec le STE : si on utilise le blitter pour déplacer un gros blocs de mémoire, le 68000 étant bloqué, il sera par exemple impossible de faire un changement de palette pour un raster. D'autant que lui n'a pas de fast-ram.
Atari, pour contourner le problème, avait la solution : il préconisaient de découper le travail du blitter pour ne déplacer qu'un tout petit bloc de données à la fois. Après chaque travail, le 68000 doit redéclencher le blitter. Ce qui lui permet de répondre à une interruption entre 2 travaux du blitter.
Je te laisse méditer sur l'élégance de la conception de notre "console à disquette" comparé à celle de "l'ordinateur hyper bien conçu"...

Pour info : dans l'ordre de priorité des canaux DMA, celui réservé au disque (D7 ou HD) est le plus prioritaire. Celui dédié au sprites est le moins prioritaire. A tel point qu'on peut, dans certains cas, perdre l'usage de 1 ou 2 sprites : c'est le seul cas ou un canal DMA n'est plus disponible.
Le chargement de données était primordiale pour les concepteurs alors que les sprites étaient l'élément le moins important : bizarre pour une machine conçue en tant que console... "

Et un complément un peu plus tard :
https://www.gamopat-forum.com/t82337p150-guerre-st-amiga-fight

Je cite :

"Si le ST se fait larguer par le mig, ce n'est pas parce qu'il est mauvais : c'est parce que le mig est vraiment bon

D'ailleurs, à cette époque là, si on comparait les performance du ST avec celle d'un mac ou d'un PC, il l'emportait haut la main...

Pour l'histoire de l'aiguillage qui ne bascule que tous les 2 cycles : ce n'est pas aussi grave qu'il n'y parait.

Je vais détailler pour que ce soit compréhensible. Et certains verront que je ne suis pas de mauvaise fois...

Si je fait la séquence d'attribution des cycles version ST, voilà ce que ça donne

Cycle 1 : Lecture des données du bitplan 1 (16 bits)
Cycle 2 : Lecture des données du bitplan 2 (16 bits)
Cycle 3 : Libre pour le 68000
Cycle 4 : Libre pour le 68000
Cycle 5 : Lecture des données du bitplan 3 (16 bits)
Cycle 6 : Lecture des données du bitplan 4 (16 bits) -> Affichage des 16 premiers pixels
Cycle 7 : Libre pour le 68000
Cycle 8 : Libre pour le 68000
Cycle 9 : Lecture des données du bitplan 1 (16 bits)
Cycle 10 : Lecture des données du bitplan 2 (16 bits)
Cycle 11 : Libre pour le 68000
Cycle 12 : Libre pour le 68000
Cycle 13 : Lecture des données du bitplan 3 (16 bits)
Cycle 14 : Lecture des données du bitplan 4 (16 bits) -> Affichage des 16 pixels suivants
Cycle 15 : Libre pour le 68000
Cycle 16 : Libre pour le 68000

Le découpage se fait tous les 2 cycles. Et on voit que pour le shifter ça ne change rien puisqu'il exploite les 2 cycles qui se suivent quand "l'aiguillage" est de son coté.

Qu'en est-il du 68000 ? Supposons qu'il doit executer une instruction qu'il lit pendant le cycle 3.
Quand il aura terminé, 2 types de cas pourront se présenter, en fonction de la durée de l'instruction :
- l'instruction dure 4,8,12,16,etc... cycles : il tombe sur le cycle n° 7,11,15,19,etc... : Donc il peut immédiatement lire l'instruction suivante. Aucun problème
- l'instruction dure 6,10,14,18, etc... cycles : il tombe sur le cycle n° 9,13,17,21,etc... : Problème : l'aiguillage est du mauvais coté ! La mémoire est donc inaccessible. le 68000 doit attendre 2 cycles avant que l'aiguillage se repositionne de son coté.
C'est ce que j'expliquais à certains Stistes qui ne voulaient pas l'admettre : Sur un ST, la durée des instructions est toujours arrondie au multiple de 4 supérieur.

Mais, comme je le disais dans mon post, ce n'est pas si grave : la majorité des instructions prennent déjà un multiple de 4.
Celles qui ne sont pas dans ce cas, sont en général celles qui travaillent en 32 bits avec des registres. Parce que le passage de 16 à 32 bits consomme 2 cycles en plus. Par exemple :
- cmp : comparaison entre 2 registres. 4 cycles en 16 bits, 6 cycles en 32 bits.
- sub : soustraction entre 2 registres. 4 cycles en 16 bits, 6 cycles en 32 bits.
- clr : nettoyage d'un registre. 4 cycles en 16 bits, 6 cycles en 32 bits.
Il y a aussi les décalages et rotations : chaque niveau de décalage coute 2 cycles de plus. Donc, en fonction, du nombre de bits à décaler, on peut tomber sur un multiple de 4 ou non
(exemple : lsl.w #3,D0 -> 12 cycles, lsl.w #4,D0 -> 14 cycles.)
Il y a aussi celles pour lesquelles ça ne change pas grand chose : une multiplication signée prend 70 cycles. Une division signée en prend 158. 2 cycles de plus à ce niveau là, ce n'est pas grand chose...
On en trouve d'autres, comme les calculs d'adresse qui ajoute un offset sur 8 bits, les move avec une pré-décrémentation du registre source, etc...

Une autre question se pose : c'est bien beau de parler de la durée des instructions. Mais une instruction peut être amenée à faire un ou plusieurs accès mémoires pendant son exécution. Elle pourrait donc être ralentie. Par exemple, l'instruction Move.l (A0),(A1) fait 5 les accès mémoires suivants :
- Lecture de l'instruction.
- Lecture des 16 premiers bits depuis l'adresse pointés par A0.
- lecture des 16 bits suivants.
- Ecriture des 16 premiers bits dans l'adresse pointée par A1.
- Ecriture des 16 bits suivants.

Que va-t-il donc se passer dans le ST ? Et bien il n'y aura aucun problème ! Et oui : le 68000 met toujours 4 cycles entre 2 accès mémoires. Cette instruction prendra 20 cycles : il n'y aura aucune perte.

Alors évidemment, il est facile d'écrire un code qui perdrait un gros pourcentage de cycles et qui tounerait bien plus vite sur le mig que sur le ST. Mais, dans la pratique, ça n'arrivait pas. La perte réelle est difficile à estimer. Mais elle doit être minime.

Si le mig garde si souvent l'avantage, c'est grace à son architecture, ses copros et son OS. Ce n'est pas que pour une raison unique.

Donc comme je le disais : ce n'est pas du tout aussi grave qu'il n'y parait.

En tout cas sur un ST de base... Et oui : essayons de bricoler un peu pour mettre un 68000 à 16 Mhz dans le ST. Que ce passe-t-il ? Et bien ça se comportera exactement comme un 68000 à 8 Mhz dans lequel toutes les instructions prendraient 2 fois moins de cycles pour s'executer. Une instruction qui prenait 4 cycles en prendra donc 2. Mais le 68000 devra en attendre 2 de plus pour pouvoir accéder à la RAM. Donc il en prendra 4. Aucun gain ! De même l'instruction détaillée ci-dessus devra attendre 2 cycles entre chaque accès mémoire. Ce qui implique qu'au final, un Move.l (A0),(A1) prendra exactement le même temps que le 68000 soit à 8 ou 16 Mhz. Et c'est le cas avec la majorité des instructions !
C'est pourquoi, dans son MegaSTE, Atari a été obligé de mettre une mémoire cache de 16 Ko pour que les 16 Mhz puisse apporter un gain (qui ne sera jamais de 200%...).
Dans un mig, sans aucun cache, cette instruction pourrait faire ses accès mémoire tous les 2 cycles et en prendrait 10 au total. Elle irait réellement 2 fois plus vite. Sans être obligée de mettre un cache (qui augmentait le cout...). Evidemment, avec des processeurs plus rapide, comme un 68030 à 50 Mhz, la mémoire n'est plus du tout en mesure de suivre. Mais l'architecture du mig gère la fastram. Et le problème est réglé. C'est pourquoi toutes les cartes accélératrices du mig en embarquait.

Le ST a une architecture non évolutive. Le mig est pensé dès le départ pour pouvoir évoluer.

Tu glisses une carte accéleratrice sur le coté d'un A500. Aucun démontage, aucune soudure et hop : tu peux jouer à DOOM de façon fluide.
Et l'A500 est le moins évolutif des Amiga..."

Je pense que c'est largement suffisant pour que cette histoire de "soi disant" avantage de vitesse du 68000 sur ST ne soit plus un argument.

Et on en revient au vrai avantage du ST, son prix au début, parce que sinon pour tout le reste y a rien :)