AGA et diverses questions générales

15 sujets de 1 à 15 (sur un total de 26)

Anonyme
17 juin 2016 à 13h47 #262585
Bonjour,

J’ai quelques questions techniques concernant le chipset AGA

1. Je souhaite savoir si dans le cadre d’un jeu 2D l’ajout de Fast Ram permet d’améliorer les performances de base (hormis bien entendu la place gagnée pour la chip).

2. A partir de quel moment est il plus judicieux de tout faire tourner au CPU sans » attaquer directement » le chipset (68030/68040/68060) ?

3. Je comprends mal un truc : il parait que le 1200 de base était capable d’égaler une console 16 bits (moins les effets spéciaux bien sur) mais si on regarde la production (je pense à Flink en particuler que j’ai découvert il y a peu, recyclage des routines de lionheart je supppose) manifestement nous sommes à peine à une 1/2 megadrive (cause 1/2 VBL). Brian le lion était sympa bien que mou mais malheureusement conçu à la base pour l’ECS et pas en exclu AGA. Banshee je n’ai pas apprécié à l’époque… Et puis AGA ou non cette impression de manque de couleurs/couleurs ternes… Quoique Mr nutz est une exception (rires).

4. Peut on me détailler le multiplexage de sprites, je ne suis pas sûr de bien avoir compris (pour l’AGA).
TameBest
17 juin 2016 à 16h28 #262597
@zarnal

1. Les jeux ont été écrits pour tourner sur les Amiga repris sur la boîte de jeu. Parfois il est indiqué « 1 Mega », ce qui signifie (dans le cas d’un Amiga 500) qu’il faudra qu’il soit équipé d’une extension mémoire. L’ajout de Fast RAM n’y change rien si le jeu est prévu pour tourner avec de la CHIP. Par contre si tu parles de WHDLoad alors la FAST est indispensable parce que jamais tu ne pourras te contenter de la RAM embarquée…

2. A priori quand le jeu n’a pas été programmé avec les instructions réservées au Blitter, Copper,… Donc par exemple un simple portage d’un jeu Atari ST vers l’Amiga (mais il y a en a d’autres; par exemple « Gravity Force » utilise le 68000 et rien d’autre)

3. Tout dépend de la machine pour laquelle le jeu a été programmé à la base (et donc optimisé). Pour les couleurs, tu peux voir OSCAR aussi qui est un exemple de jeu exploitant plein de jolies couleurs pas ternes du tout. Si tu prends une SNES et son mode 7, il sera impossible à émuler sur Amiga… Idem pour certains jeux Amiga comme « Shadow of the beast » optimisé pour Amiga… Tu prends n’importe quelle autre version et tu perds: le plein écran, les 12 scrolling paralaxes,… Dommage pour Banshee (excellent au demeurant ^^), essaye Apidya dont les couleurs vont te ravir je pense ^^

4. Je laisse à plus calé que moi, je n’en sais rien :p

Amiga 500 avec Viper 520, KS 1.2/3.1, HDD & CD-Rom externe, 10M de RAM - Amiga 1200 avec Blizzard 1230 MKIV & SCSI + FlickerFixer - Amiga 600 avec 68030 et 10M de RAM + CF interne de 8G - Amiga 600 avec Vampire 2 Batch 1 - Amiga CD32 et PLEIN d'autres Amiga/Atari/Mac
Ma collection de machines/Jeux:
athlonet68k
17 juin 2016 à 16h59 #262601
Sur A1200, l’ajout de fast ram accélére l’amiga. En gros un gain de 70% du fait de son architecture 32 bits.

-* Certains ont essayé autre chose, ils ont eu des problèmes... *-
Anonyme
17 juin 2016 à 17h51 #262603
Tout d’abord merci pour vos réponses.

Je vais reformuler mes deux première question :p

Je ne parle pas de WHDLOAD.

1. Sachant que le 68020 et le chipset doivent se partager les cycles sur un A1200 stock : si je mets de la fast je souhaite savoir ce qu’il se passe lors des accès DMA à la chip des copros (sont ils améliorés puisque ils ne sont plus partagés, augmentation de la bande passante de la chip peut être) ? Et quelles conséquences sur un jeu 2d programmé en conséquence en utilisant l’ensemble des cycles (les 70% sont ils effectifs) ?

2. Quand est ce que le CPU peut prendre l’avantage sur le 68020+Copper+blitter de base du 1200. Par exemple un 68040 à 50Mhz peut-il être plus rapide qu’un 68EC020+copper+blitter en lui demandant de tout faire (donc se passer du blitter et du copper d’origine du 1200). Désolé si j’exprime mal les choses. :p

3. C’est surtout que j’ai toujours été allergique au tramage des couleurs (rires). apidya oui je connais mais je trouve les sprites/bobs trop petits par rapport à la taille de l’écran (rires). Disposerable heroes ECS est plus réussi à mon goût (bon je n’ai jamais apprécié 1941 ceci expliquant certainement cela pour banshee, rires).
athlonet68k
17 juin 2016 à 18h10 #262607
Je sais que tout booste avec l’ajout de ram, accès disque, etc…

-* Certains ont essayé autre chose, ils ont eu des problèmes... *-
cyb0rg
17 juin 2016 à 19h40 #262610
Pour les jeux bien codé et qui sont déjà synchro VBL (ou la demi-VBL), peux importe si tu as de la Fast ou CPU de malade, ils n’iront pas plus vite …

sur du cpu rapide (à determiner :)) tu blit plus vite au cpu qu’au blitter … apres remplacer le copper avec du cpu, je ne vois pas trop le truc 🙂

tu parlais peut-être de c2p (chuncky To Plannar) ?

maintenant oui, les jeux auraient pu bénéficier des avantages de la fast ram, pour gagner en détails par exemple ou des optimisations sur le programme lui même, mais toujours coincé par la lenteur de la chip ram (qui fait office de mémoire vidéo).
donc difficile pour Amiga musclé de faire mieux en 2D, même avec un 68060@100mhz et 64Mo de fast…. sauf de passé par une c2p peut-être…

Only amiga makes it possible
XTR Games
Magic Productions
tilde
MiGaNuTs
17 juin 2016 à 19h40 #262611
De base le 68020, même sans fast ram est plus rapide que le blitter.
en réalité l’aga n’est pas plus rapide que l’ECS, alors quand il doit gérer 2 bitplans de plus ça rame carrément. suffit de voir comment le workbench rame juste en passant en 256 couleurs.
Rien qu’en ajoutant de la fastram le 68020 peut travailler presque 2x plus vite, mais ca ne change rien pour les copros. Par contre vu que la plupart du taff est faite par le CPU, ca accélère déjà grandement la machine.
J’ai jamais compris pourquoi y’avais pas au moins un support sim d’origine (en plus de la trappe d’extension) sur le 1200, et un peu de fast d’origine sur la CD32. Ça aurais grandement aidé a une époque ou la 3D commençait a pointer son nez et que nos machine de base étaient incapable d’afficher qqch qui tiens la route.

Du reste quelques modes vidéo en chunky auraient pas été du luxe dans l’AGA.
Ca sent la puce sortie dans l’urgence et en limitant les couts de dev par une boite qui commençait déja a tirer la langue après s’être trop longtemps reposé sur ses lauriers.
Jul
17 juin 2016 à 20h21 #262612
@Arnaud : par « multiplexage » de sprites, veux-tu parler de la réutilisation des sprites plusieurs fois par écran ? Auquel cas c’est très simple :

L’Amiga a 8 sprites en hardware, contrôlés par divers registres. Parmi ceux-ci, 8 registres contiennent les adresses des sprites dans la mémoire graphique, et d’autres registres la position du sprite à l’écran. L’idée est donc, quand un des sprites a été affiché, de faire immédiatement pointer le registre de sa position à l’écran vers une autre position (forcément plus bas sur l’écran, puisque le faisceau d’électrons du tube cathodique va de haut en bas). Ainsi, le sprite sera ré-affiché.

Les sprites peuvent avoir n’importe quelle hauteur. Donc, si ton écran fait 320 lignes et que ton sprite fait 10 lignes de haut, tu pourrais l’afficher 32 fois à l’écran. (Moins, en fait, car, pour des raisons techniques, il faut laisser passer au moins une ligne, donc 320/11 = 29 sprites. Et tu as 8 sprites ainsi disponibles. 🙂

En plus, rien ne t’empêche de modifier également après chaque affichage le registre pointant les graphismes du sprite en mémoire graphique, pour le faire pointer vers un autre graphisme : tu pourras ainsi afficher un sprite différent, en utilisant le même sprite hardware.

Voilà comment on peut avoir des centaines de sprites à l’écran. 🙂 Seule la quantité de mémoire chip disponible limite les possibilités.

Prédateur Chess | Amiga 500 + ACA500 | Amiga 1200 + ACA1233
lexomil
17 juin 2016 à 20h34 #262613
Bonsoir Arnaud,

1. alors dans l’ensemble l’ajout de FAST augmente les perfs de la machine, tout simplement car le CPU n’a plus à partager des cycles d’accès mémoire avec les copro (Blitter et Copper), mais ce n’est pas aussi simple, la vidéo peut aussi « manger » des cycles d’accès lorsque l’on utilise des résolution élevées, c’est pour celà qu’il existe un mode « boost » sur l’AGA qui permet des accès 64 bits pour la vidéo (le fameux fetch mode), donc normalement même avec 8 plans si on est bien en FMODE 3, la vidéo ne devrait pas manger des cycles d’accès et donc les copro peuvent paraitres plus rapide (ce qui intrinsèquement n’est pas le cas).

2. à partir d’un 68030 à 30mghz le Blitter n’est plus du tout compétitif, et même sur un 1200 de base c’est limite au point qu’on finissais par s’en servir juste pour effacer l’écran.

3. Sur le papier un 1200 est quasiment l’équivalent d’une Genesis, au niveau graphique 2 plans en 16 couleurs mais moins de sprites et le son un peu meilleur sur Amiga. Par contre il n’est pas au niveau d’une Super Nintendo, moins de couleurs par plan, moins de sprites, moins d’effets spéciaux (type mode 7, zoom)

4. Sur tout amiga tu peux multiplexer des sprites, les limites théoriques sont simples, l’amiga peut afficher 8 sprites par ligne (je dis bien par ligne et non pas par écran). Mais il est aussi possible d’augmenter ce nombre grace au copper en écrivant directement dans les registres de données des sprites, il y’a cependant des limitations du à la vitesse du copper et il faut donc faire des concessions (même motif à un autre endroit sur la même ligne ou motif différent mais en un seul plan).

Bonne soirée
TameBest
17 juin 2016 à 23h07 #262615
Moi ce que je voulais dire dans l’absolu c’est:

– Ajouter de la Fast n’a jamais accéléré un jeu sur disquettes (je n’ai aucun exemple concret). C’est seulement un mal nécessaire pour les jeux qui ont besoin de PLUS de RAM; pas pour accélérer le jeu

– Accélérer un jeu c’est souvent le rendre INJOUABLE (donc aucun intérêt), c’est d’ailleurs un des soucis de l’émulation qui parfois accélère démesurément un jeu et le rend totalement injouable

@lexomil Peut-être que tu as raison concernant la vitesse du Blitter larguée face à un 68030 à 30 MHz mais dans tous les cas l’utilisation des copro déchargeait le processeur et comme certaines boîtes exploitaient à fond les capacités (même du 1200), ce surplus de puissance n’était pas négligeable. Le programmeur (génial) de Son Shu Shi (jamais sorti officiellement mais mis en ligne par l’ex-CAPS team) travaillait ainsi avec des vu-mètres sur le côté droit de l’écran. Chaque vu-mètre était dédié à un circuit: cycles machines du 680×0, Blitter, Copper,… Et quand dans une phase de jeu il trouvait le moyen de rajouter un sprite, un blob ou n’importe quoi pour exploiter l’Amiga à 100% il le faisait ! Puis « blob » = « Blitter Object »… Compte tenu de la limitation à 8 sprites hardware, c’était bien utile et le bypasser sous prétexte que le processeur le fait plus vite n’était pas une bonne idée je pense.

Amiga 500 avec Viper 520, KS 1.2/3.1, HDD & CD-Rom externe, 10M de RAM - Amiga 1200 avec Blizzard 1230 MKIV & SCSI + FlickerFixer - Amiga 600 avec 68030 et 10M de RAM + CF interne de 8G - Amiga 600 avec Vampire 2 Batch 1 - Amiga CD32 et PLEIN d'autres Amiga/Atari/Mac
Ma collection de machines/Jeux:
dcmostro
17 juin 2016 à 23h14 #262616
Bonsoir,

il y a quand même un truc qu’il faut savoir sur l’AGA (ou alors j’avais loupé ce même truc à l’époque…), c’est juste un OCS/ECS avec un petit plus. Lexomil, quand tu parle de fetch 32 ou 64 bits, as-tu fait des tests? Je veux dire par là que quand j’ai testé à l’époque, je me suis rendu compte d’un truc: tu fetch en 32bits par exemple et tu te dis: avec 8 bitplans en 320 et en fetch 32 bits, j’utilise juste les 4 canaux DMA bitplans (2 plans par canal) donc aucun « vole » de cycle pair sur le copper/blitter/cpu… sauf que ça ne marche pas comme ça ou alors je n’avais pas trouvais le truc. Tu bouffe les 4 canaux impairs ET les 4 canaux pairs… mais un coup sur 2 puisque tu viens de fetcher 32bits de bitplan au lieu de 16 !!! Donc, 1 coup tu sature le bus comme pour le mode hires 16 couleurs de l’OCS (les 4 cycles impairs + les 4 cycles pairs, sauf que pour le hires OCS le cycle de fetch c’est 4 et pas 8 mais c’est le même encombrement du bus), et le cycle de fetch suivant rien! C’est à dire que tu dispose bien de tes 4 cycles pairs mais tes 4 cycles impairs sont perdus puisque non utilisés!!! Donc si on fait la moyenne, le 8 plans AGA est aussi lent que le 6 plans OCS/ECS au niveau affichage. Le DMA bitplans ne « multiplex » pas. C’est 16 ou 32 ou 64 bits mais du même plan.
Mais si tu as testé ou si tu sais comment faire autrement, ce serai sympa de partager. Merci.
ANTEK
17 juin 2016 à 23h40 #262618
des jeux accélérés par la fast il y en a pas mal…

Jaguar xj220 par exemple, mais surtout TV Sports Football de Cinemaware: perso j’étais obligé de jouer sans fast sans quoi c’était difficilement jouable… injouable même puisque les joueurs controllés par le CPU devenait si rapide que mon quaterback se faisait sacker avant même de recevoir le ballon 😉 La seule solution était de virer la barette mémoire (et quand je suis passé sur des cartes blizzard, de désactiver la carte avant de lancer le jeu ou d’utiliser relockick 1.4 pour downgrader la machine)

PS: oui, c’est un fait reconnu que l’AGA a été sorti dans la précipitation, c’est mehdi ali, si je ne dis pas de bétises, qui aurait demandé que cette version incomplète du chipset AAA soit utilisé immédiatement pour pouvoir équiper les A1200 et A4000 sortis un peu dans la précipitation. Quel dommage, car quand on voit les possibilités qu’offraient le A1200 AGA, je n’ose imaginer ce qu’un Amiga AAA aurait donné
lexomil
18 juin 2016 à 11h48 #262638
Bonjour,

@TameBest : je n’ai pas dit qu’il ne fallait pas utiliser le Blitter avec un 020 (ou +), c’est juste qu’à l’époque, alors que la mode était à la 3D, utiliser le Blitter pour remplir une surface n’était pas du tout adapté et qu’on finissait par l’utiliser juste pour effacer l’écran. Après concernant l’affichage de BOBs bien évidemment qu’il avait toujours un intérêt couplé avec le 020, de toute façon concernant les jeux 2D l’Amiga était relativement bien équipé et performant.

@dcmostro : tu as complètement raison, le fetch se fait plan par plan, mais tu gagnes tout de même quelques cycles DMA comme tu l’explique (uniquement vrai en fetch 64 bits quand tu es en 8 plans), car tu ne sature le DMA que sur les 8 premier cycles, puis il t’en reste ensuite 24/2 de dispo pour les copro/proc (16 pixels lowres = 8 cycles).
De mémoire il y’avait eu des tests dans ANews et je dois avoir du code qui traine avec des tests du Blitter en fetch 64 bits. La contrepartie de ce type de fetch c’est que tu perds des sprites car tu dois démarrer plus tôt le fetching et empiéter sur le DMA sprite (et c’est bien entendu pire si en plus tu veux faire du scroll).

Bonne journée
lexomil
18 juin 2016 à 11h53 #262639
Ha, et on est d’accord que le Blitter et le Copper étaient exactement les même que sur ECS, même fréquences, même capacités, contrairement à ce que disait Commodore à l’époque le Blitter de l’AGA n’était pas du tout 4x plus rapide que celui de l’ECS, il avait besoin du même nombre de cycle pour effectuer ses opérations, il « parassait » plus rapide car, grace au fetch en 32 ou 64 bits, il avait plus de cycles de dispo par lignes pour travailler.
Anonyme
19 juin 2016 à 20h28 #262716
Merci à tous pour ces explications détaillées.

@TameBest et Lexomil

Je viens de me relire et j’ai certainement mal posée ma question. Je ne cherchais pas à savoir si l’ajout de Fast améliorait les jeux existants mais si la programmation d’un même jeu aurait changé la donne en cas de présence de cette dernière. Prenons un exemple concret AGA (Flink ou Banshee par exemple) et réécrivons l’histoire en partant du principe que d’origine la CD32 était dotée de Fast (oui soyons fou, rires). Le résultat final aurait il été meilleur ? Et en cas de présence d’un 68030+Fast ? Merci.