Re: GUERRE ST-AMIGA, FIGHT !!!

[Meditating Guru]

C'est ainsi que je l'ai compris. Les extensions de 512K typiques seraient de la "Chip".

Et ???
Alors tout d'abord la chip est une mémoire à 280ns @7,14 mhz,soit 1 accès tout les 2 cycles .
Le CPU est à 1 accès tout les 4 cycles soit 560ns(@7,14mhz) .
De plus tu te doutes bien que le copper/paula/blitter accédent à la chip plus vite que le 68K, donc même en ayant de la chip comme mémoire elle est largement plus rapide que ce que peut accéder le 68k .
ensuite le terme de slow ram, ne vient pas du fait que les puces utilisées pour la mémoire soit de la chip, mais du bus utilisé .
La slow RAM utilise la zone mémoire juste au dessus de la chip, donc le même bus que la chip, contrairement à la fast qui utilise en bus dédié,d'où les différences d'appellations .
Donc ceux qui sortent que la chip est appelée slow ram, faudrait qu'ils fassent preuve d'un minimum de réflexion avant d'affirmer ça,parce que sans connaitre l'amiga, l'évidence saute aux yeux, sauf pour celui qui veut pas la voir . .

Sur mon Amiga, il y a une extension interne de 512K avec un switch on/off sur le côté. Ceci est-il de la mémoire "fast" dans le sens que le chipset n'y a pas accès, ou chip?

Si le programme est logé en Fast ram, le CPU ne sera ralenti par rien pour lire le programme ("fetching").
Mais le programme doit accéder à la mémoire chipset, pour par exemple préparer l'image... changer les sons, etc.
Donc en pratique, il y aura partage de cycles, et d'une façon difficile à prévoir, voire chaotique.
Ca me fait penser à un infâme bricolage.

[dam's]

Sur Atari, tu avais aussi une extension? Je veux dire: tu t'es mis à la soudure?
Perceuse aussi, pour faire un trou sous la table pour brancher un joystick... C'est ptet pour ça en fait que le ST a eu de moins bons jeux: impossible de jouer en fait...

[rocky007]

m

[Invité]

mdrr le cpu pas loin d'imploser (4.30)
quelle puissance ! quelle musicalité ! 

[Tryphon]

m

voyelle !

[Invité]

tu devrais remettre ton lien rocky, c'était vraiment instructif

[dam's]

Je crois qu'il a fait un guru m

[Invité]

je me permets de remettre la video


vers 4.30, c'est particulierement grandiose.
quel ordinateur fantastique.

[rocky007]

Je ne dis pas qu'il n'a pas fait le job (je l'ai déjà dit). Mais je ne le mettrais pas dans la même catégorie qu'un Chuck Peddle ou Jay Miner.

oui possible en effet, difficile de juger sans connaître ses travaux, sa bio est assez faiblarde
mais bon, même si il est en dessous de Jay Miner, cela reste un excellent ingénieur

Mais tu en sait surement plus que lui sur les DSP et en particulier sur le DSP3210 qu'il a interfacé dans le 3000+ ?

C'est comme le blitter du ST soit disant en parallèle, tu en sais plus que les codeurs de démo.

oui en effet, tu as raison il semblerait

faudrait que tu apprennes à lire correctement, pour le blitter j'ai clairement expliqué et cité la source détaillant le process.

Mais, non je t'ai déjà expliqué ils ne savent même pas, si ça se trouve que le ST ou l'Amiga avaient une GUI. Et s'il le savent, de toute façon les producteurs ne recherchaient pas à être historique.

si ils le savent, puisqu'il savaient comment un C64 affichait ses graphismes , ses couleurs et sa résolutions, ses fonts etc...

Tu racontes n'importe quoi, le commun il avait pas de graveur de CDROM ! En 1994 l'Amigaïste avec les configurations haut de gamme a voulu se prendre un graveur de CDROM, pour faire des compilations. Ca coûtait une fortune, il a renoncé, jusqu'à ce que les prix deviennent abordables deux ans après, de mémoire.

Je m'en souviens des modchip, je suivais ça de loin, mais c'était bien plus tard. Au début la playstation 1 s'est vendu sur ses capacités qui écrasait toutes les autres consoles. C'est ce qui a fait son succès initial et donc conduit à l'apparition des modchip.

tu vois, tu ne lis pas correctement encore une fois... vue à géométrie variable ?
est-ce que j'ai dit que le commun des mortels avait un graveur ? non !  j'ai dit qu'il y avait toujours un gars dans le cas qui en possédait un et à qui se fournir, et ce bien avant la PS1.  Les modchip, ce n'était pas du tout "bien" plus tard, c'est "bien" plus tard selon toi, selon ton vécu, mais cela ne correspond pas du tout à la réalité.  Les premiers modchip sont apparus très rapidement.  Comme expliqué, la chine produisait déjà des copies pressées de jeux PC, etc.. dès que la faille PS1 est apparue ( soir probablement 1 semaine après la sortie de la console ), les chinois ont bossé sur les copies et les modchips. 

Mais, tu n'es pas représentatif de la majorité, cet équipement coûtait fort cher. 

Pourquoi il n'y avait pas de protection au début, justement ? Parce que ce support était considéré comme sur.

pas du tout.  ils savaient dès le début qu'ils pourraient être copié, simplement ce n'est pas démocratisé et le coût d'une protection était probablement inutile.  du reste, le jeux PS1 et Saturn étaient protégé, et pourtant le graveur n'était démocratisé.

Le succès d'une console c'est un tout. Il faut, la bonne technologie, le bon prix, le jeu qui épate tout de suite et le bon marketing puis d'autres jeux tout aussi impressionnant. Sony a réussi tout ça.

la 3DO avaient des jeux qui épatait, une bonne technologie, un bon concept.  On peut pas dire non plus qu'ils étaient nul en marketing, tout le monde connaissait la 3DO et elle était distribuée partout.
mais comme tu le dis si bien : la technologie ne fait pas tout.  tu peux avoir une machine technologiquement pas au top de ce qu'il se fait, mais l'apprécier quand même.

Les réguliers oui, mais ceux qui témoignent de temps en temps tu les oublie.

des faux compte avec juste 1 message que des amigasites créent pour venir gonfler artificiellement

Oui, mais là c'est autre chose. Dans ces conditions, comme je l'avais dit, c'était utilisable. L'Amiga avait ça de façon simple par des cartes passerelles pour le 2000/1000, et plus tard par des cartes sur le port d'extension mémoire pour l'Amiga 500.

je sais plus pour PC, mais pour MAC c'était une carte qui se mettait dans le port cartouche

Mais pas du tout, ce n'était pas moi qui manipulait le PC, mais un PCiste confirmé en école d'informatique (DUT ou plus). Je n'avais pas de PC à ce moment là.

ben à mon avis il a dû refaire ses études, j'étais pas spécialement doué en PC, et je n'ai jamais eu le moindre problème avec mes modems et pourtant j'en changeait tous les 6 mois.

[rocky007]

je me permets de remettre la video


vers 4.30, c'est particulierement grandiose.
quel ordinateur fantastique.

inutile, c'est une vidéo sous émulation et donc pas sur un Ste réel, cela n'a donc aucun intérêt.

mais si tu aimes les vidéos, en voici une :)



et le meilleur scrolling amiga :

[Zarnal]

c'est bien ce que je disais, vous ne savez que poster les sempiternelle 10 même vidéos , car en fait sur amiga, à part ces 10 jeux pas trop mal réalisé, c'est le vide totale, soit des jeux minables, soit des portages Atari ( heureusement pour vous qu'atari a été là pour vous donner des jeux ...quand on voit le résultat de vos créations "amiga" ...)

L'un entrainant l'autre...


De plus, j'aime les vidéos représentatives :

Voici le street fighter 2 de l'atari st :



Un autre jeu poussant le st dans ses derniers retranchements.



Ouahouuuuuu.

[Urbinou]

Un autre jeu poussant le st dans ses derniers retranchements.

Le pire c'est que c'est sans doute vrai

[rocky007]

c'est d'autant plus honteux que vous avez tout pour faire un jeu correctement visuellement : scrolling hard, sprite hard, etc.. et pourtant vous arrivez encore à faire de la merde, c dingue

Su ST on peut encore comprendre, puisque c'est au codeur à le faire lui-même le scroling et sprite, mais sur Amiga c'est une bande de fougnasse

[stapha92]

oui, et où sont alors les soundtracker en 56 Khz ?  ou une simple demo ?  je n'en ai jamais vu.

Pour les mêmes raisons que tu n'en vois pas à 50 sur STE/falcon,la place que ça prend,et sur STE/AMIGA surement trop de CPU.

C'est pas parce que c'est possible de sortir du 50/56khz, que tu peux avoir un module dans cette qualité .

the CPU usually has a chance of loading the next instruction
before the BLiTTER hogs the bus.

 
Ca veut dire que le reste du temps le CPu se prend un  de la part du blitter,effectivement c'est beau une machine bien pensée ..

Il doit y en avoir. Il y a pleins de tracker compatible AHI, ça leur donne la possibilité d'utiliser ce mode.

Attention, il faut savoir que ça ne fonctionne qu'avec un écran VGA, donc impossible (sans trick) avec la grande majorité des jeux. De plus, un tracker n'utilisera pas de sample à 56 Khz (en fait 57,7 Khz) mais plutot à 40 Khz. En effet sur Amiga on fait varier la tonalité en jouant sur la vitesse de restitution. C'est bien pour ça que le son d'un module sur le mig est incomparable avec celui d'un STE. Donc si on veut un sample par octave, il faut pouvoir monter/baisser la fréquence de racine carrée de 2. Donc avec 40 Khz on est dans les clous.

Au niveau cpu, ça ne prend rien sur le mig, parce que les variations de tonalité et/ou de volume sont gérées par Paula. Sur le STE par contre, vu que le cpu doit retoucher les samples pour appliquer ces 2 variations, c'est une autre paire de manches...

@stapha92 a écrit:Et 25 ans pour arriver à faire un pacmania fluide sur STE. J'ai dit fluide parce quand ici je lis que ça vaut la version Amiga... deux fois moins de couleurs, une fenêtre au lieu de l'overscan...

Pacmania STE utilise l'overscan vertical pour présenter les dimensions appropriées. Je ne passe pas mon temps à compter les couleurs mais je n'ai pu qu'entendre que la musique "stereo" sur l'Amiga était juste bonne à casser les oreilles. Quelle casserole.   

Ah oui super, un overscan vertical au bout de 25 ans : Ouaouhhhh !!! Tout ça sur l'Amiga-Killer, tel qu'il était présenté par Atari, les rois de l'esbrouffe..
Pas besoin de compter : un STE ne peut pas afficher plus de 16 couleurs (hors rasters). Rien de nouveau au pays du shifter de ce coté...
En se limitant à 16 couleurs, le mig pourrait faire Pacmania en haute résolution sans problème. et encore, avec les sprites il continuerait  à avoir plus de 16 couleurs...
Attention ! Je ne critique pas le travail des codeurs qui ont fait ce jeu su STE. je remet juste les choses dans l'ordre quand vous prétendez que ça vaut la version mig...
Et si tu avais VRAIMENT eu un amiga à l'époque, tu aurais pu prendre un cordon à 10 francs et retrouver l'inimitable son de ton ST si parfait...

Sur STE, le blitter est en compétition avec le CPU, mais sur Amiga aussi, la contrainte étant qu'il n'y a qu'un bus à partager pour les accès CPU, blitter, DMA et video, avec la priorité à la video.
Malgré cette contrainte, dont Atari ne se vantait pas trop, le Blitter permettait d'accélérer l'affichage parce qu'il pouvait faire plus que le CPU: copie avec masque. Avec un CPU plus performant comme sur le Falcon, le blitter perdait son avantage et devenait inutile.
Techniquement, sur ST comme sur Amiga, on peut lire ou écrire un "mot" (donnée de 16bit) tous les 2 cycles. Pendant l'affichage, la moitié des cycles va à la video, sinon l'image est corrompue.
L'avantage de l'Amiga est que le blitter prend les cycles non CPU en dehors de l'affichage, tandis que le blitter du STE fonctionne de la même façon, affichage ou pas.
Corrigez-moi si je me trompe, car je connais mal "l'architecture" (bricolage) de l'Amiga.

Relis mes anciens posts et tu verras quelle machine est un bricolage...

Alors oui tu te trompes : Sur le mig, le 68000 peut travailler pendant un blit, même sans fast ram. Avec de la fast (concept inexistant sur le ST...), il n'est absolument pas ralenti. Ensuite le blitter du STE, contrairement à celui du mig NE SAIT PAS FAIRE DE COPIE AVEC MASQUE !!! Pour ça il faut savoir gérer 3 sources. Or le blitter du STE n'en gère que 2. Résultat, il est obligé de le faire en 2 fois. Super comme conception...

La Fast ne concerne pas l'Amiga 500.
Oui, le blitter ST c'est source + destination, mais c'est plus que ce que le CPU peut faire avec un MOVE, c'était le sens de la remarque. Du coup, tu as peut-être raison sur le 68030 vs blitter.

EDIT: un masque peut-être entré dans les registres du blitter, sous forme de 3 x 16bits (premier mot, autres mots, dernier mot).

En fait le blitter du ST c'est 2 sources + destinations. Mais pour appliquer un masque il faut que la destination soit aussi une source.
Ok je confirme alors : le blitter du ST est bien plus rapide qu'un 68000. Et c'est encore pire quand il y a des décalage de bits.

Techniquement le 68000 peut lire ou écrire un mot tous les 2 cycles sur le mig mais tous les 4 cycles sur le ST : tu te trompes encore...
C'est pour ça que dans cette super machine toutes les instructions voient leur nombre de cycle arrondi au multiple de 4 suivant... Et c'est pour ça que quand Atari a conçu le mega STE il se sont confrontés à un problème : le 68000 tournant 2 fois plus vite, c'est comme si on divisait par 2 le nombre de cycles de chaque instructions. mais il faut l'arrondir à 4 après ! (en fait c'est pire : c'est le temps entre 2 accès au bus qui doit être arrondi, et beaucoup d'instructions font plusieurs accès...) Du coup y a presque aucun gain ! Et Atari a été obligé de mettre une mémoire cache pour compenser et obtenir une accélération moyenne de 50 % ! Ouaouhhh !!! Met un 68000 à 14 Mhz dans un mig et il ira 2 fois plus vite. Point barre.

Misères de la mémoire partagée...
Je parlais du bus, qui permet un R/W tous les deux cycles. Le 68000 a besoin de minimum 4 cycles pour un R/W. Le CPU et le MMU sont entrelacés. On sait que sur ST, le CPU n'a pas accès pendant les cycles MMU. En pratique, les cycles perdus par le CPU ne sont pas trop nombreux car les instructions ont tendance à s'arrondir à 4 cycles.

Ca arrive sur Amiga aussi.
"Some 68000 instructions do not match perfectly with the allocation of even
cycles and cause cycles to be missed. If cycles are missed, the 68000 must
wait until its next available memory slot before continuing. However, most
instructions do not cause cycles to be missed, so the 68000 runs at full
speed most of the time if there is no blitter DMA interference."

J'avais bien compris et non : le bus bascule tous les 2 cycles sur le ST et tous les cycles sur le mig. Super le design...
Oui pas trop perdus c'est vrai mais ça reste inacceptable quand on sait qu'il suffisait de faire basculer le MMU 2 fois plus vite (économie quand tu nous tiens...) ! Et ça devient carrément ridicule avec un mega STE ou une carte avec un 68000 à 16 Mhz : Super l'évolutivité de la machine, on sent le truc conçu pour perdurer... LOL !! Avec une bascule à chaque cycle le mega STE serait plus rapide sans avoir de mémoire cache. On peut faire mieux pour moins cher : faut juste prévoir les choses dès le début et arreter le bricolage...
Oui ça arrive sur le mig mais met l'article en entier : ça parle du cas ou le chipset est obligé de voler des cycles. Ce qui n'arrive jamais, si le mig se limite à une résolution du type ST, c'est à dire 352x288x16 ou 704x288x4... Ah ben non ! c'est déjà au dessus de ce que peut faire un ST. En tout cas dans ce mode, le mig ne perd AUCUN cycles. Je parle sans fast ram bien sur. Sinon il n'y a plus de problèmes...

Tu veux le détail du fonctionnement ? Relis donc un de mes anciens posts :

babsimov, 

pour les démos, Seb a répondu bien mieux que je n'aurai pu le faire (merci à lui pour cette explication détaillée et très interessante). 

Pour l'explication que tu demandes, je suis obligé de passer par des généralités barbantes pour que tu puisses comprendre: 

D'abord les cycles processeurs : 

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... 

Je pense que tu commences à avoir une bonne vision sur cet histoire de cycles et d'accès à la chip-ram. 
En tout cas je ne peux pas faire plus clair... Ni plus barbant !   

Toutefois, le blitter du STE peut fonctionner pendant l'affichage, pas celui de l'Amiga.   
Au total, le blitter de l'Amiga a un peu plus de cycles, on est bien d'accord. Mais le blitter d'Atari n'est pas si nul que ça. Ce n'est pas du bricolage. 

Ah bon ? Le blitter du mig ne fonctionne pas pendant l'affichage ? Première nouvelle.

Sans Fast, c'est affichage ou CPU ou blitter, pas les trois en même temps, même sur ta super console.

Tu fais déjà des erreurs quand tu parles du ST. Tu crois qu'il est prudent de parler du mig ? Tu as tort : Sans fast tu peux avoir les 3. Et même plus en y ajoutant le son, les sprites, etc...
Toujours cette technique très prisée sur ce forum d'affirmer des énormités avec aplomb...

Non, il n'est pas si nul, mais il lui manque des tas de choses présentes dans celui du mig pourtant conçu bien avant...
Et son intégration dans le ST relève, elle, du bricolage. Relis mes anciens posts, tu comprendras pourquoi j'ai malgré tout du respect pour le ST et absolument pas pour le STE

Le blitter n'est pas propre au STE, sa conception date du STF, il était une des "attractions" du Mega. On peut critiquer mais le GEM affichait nettement plus vite avec le blitter.
N'étant pas un fanboy, je ne prétends pas qu'il est mieux que celui de l'Amiga. Mais ce n'est pas un bricolage, c'est une architecture à compromis.

Ah bon ? Alors pourquoi les STF des premières années n'ont pas l'emplacement pour le blitter ? Il a bien été conçu après celui du mig non ? Alors pourquoi ne pas l'avoir rendu capable de laisser des cycles au 68000 quand celui-ci en a besoin ? C'est ce qui se passe dans le mig, suffisait de copier ! A moins que l'architecture pourrie du ST ne l'ait pas permis...
A noter : le blitter du mig peut se comporter comme celui du ST et bloquer totalement le cpu quand il n'y a pas de fast. Ce mode de fonctionnement est appelé "nasty mode" (mode dégueulasse). Donc ST mode = nasty mode...
Continue ta lecture du HRM (et je salue l'effort de chercher des informations sur cette source, dommage que tu n'ais pas tout compris...), tu verras que je n'invente pas.

En me documentant, j'ai lu que si on utilise l'instruction TAS sur un Amiga, on a droit au Guru Meditation car l'architecture bricolée perd les pédales. 

Tu t'es mal documenté. Tu sais à quoi sert cette instruction et quelle est sa spécificité ? Renseignes toi déjà là dessus et tu comprendras qu'il ne faut pas croire tout ce qu'on lit...

Tu parles au gens comme s'ils étaient des ignorants et que seul l'Amigaleux détenait la Vérité...   
Voici ma source:

  Avoid the TAS instruction.
  --------------------------
  The 68000 test-and-set instruction (TAS) should never be used in the
  Amiga; the indivisible read-modify-write cycle that is used only in
  this instruction will not fit into a DMA memory access slot.
 

Je ne critique pas l'ignorance, ce n'est pas une tare. je critique le fait d'affirmer sans savoir, c'est trop fréquent ici.
Alors parlons de TAS, puisque tu penses avoir trouvé un point faible sur le mig.

Cette instruction test l'état d'un bit à une adresse indiquée et met ce bit à 1 dans la foulée, ça revient à faire un BTST + un BSET.
Qu'a-t-elle de spécial ? Et bien entre le test et la pose du bit, le 68000 ne libère pas l'accès à la mémoire.
Mais alors pourquoi faire ? Et bien cela est utile dans un environnement multi-processeur pour gérer les ressources partagées.

J'explique : imaginons un micro dans lequel il y a 2 68000, et imaginons qu'il puissent avoir besoin d'accéder à la même ressource, une imprimante par exemple.
Tu imagines ce qui se passera si tous les 2 envoient des données à imprimer en même temps ? ça va mélanger le tout et mettre un bordel monstre !
Le codeur va donc choisir une adresse mémoire qui va servir de sémaphore et indiquer si l'imprimante est en cours d'utilisation.
Du coup, quand l'un des processeurs veut accéder à l'imprimante :
- il va tester le sémaphore qui correspond à l'imprimante
- il va le mettre à 1
- S'il était à 1 au moment du test , il va attendre ou abandonner.
- S'il était à 0 il va utiliser l'imprimante et, quand il aura teminé il va mettre à 0 le sémaphore

Pourquoi ne pas utiliser BTST pour tester le sémaphore et un BSET pour le poser alors ? Et bien supposons que les 2 68000 fasse le test avec un seul cycle d'écart : les 2 vont le voir à 0 et donc les 2 vont le mettre à 1. Et les 2 vont utiliser l'imprimante (ok ça a une chance infime d'arriver...). Problème !
Avec TAS, entre le test et la pose du sémaphore, l'accès à la mémoire n'est pas libéré par le 1er 68000 (alors qu'il y a plusieurs cycles ou il n'en a pas besoin). Donc, quand le 2eme 68000 vient pour tester le sémaphore, il est mis en attente jusqu'à ce que le premier ai terminé et l'ai posé. Quand il fera sa lecture, il verra bien le sémaphore posé et il n'y a plus aucun risque de problème d'accès concurrent.

Pourquoi cette instruction doit-elle etre évité sur le mig ? Et bien parce que le CPU et le blitter peuvent tourner en même temps ! On pourrait avoir le blitter qui tente d'accéder au bus alors que le 68000 ne le libère pas. Aie !
Quels sont les impacts ? Aucun !!!! tu as déjà vu un ST ou un mig avec 2 68000 qui tournent en // ? Non ? moi non plus !
Mais je te rassure, puisque tu semble être géné par ça j'imagine que tu avais prévu de monter un 2eme 68000 dans un amiga. Pas de problème alors : il suffit de mettre tous les sémaphores dont tu auras besoin en fast. et là aucun problème... 

En dehors de ça, TAS n'a aucun interet.

Encore une fois ta source est bonne mais il faut étudier un peu plus le truc...

Le blitter ne bloque totalement le CPU qu'en mode Hog. En mode Blit, les cycles sont partagés moitié moitié chaque scanline, donc le CPU ne va rien louper, sauf si on programme au cycle près, mais même ça c'est possible parce que les cycles sont plus faciles à déterminer qu'avec l'Amiga.

Ah bon ? totalement faux. Le blitter bloque le cpu dès qu'il fonctionne sur ST.

En mode Hog, le blitter bloque jusqu'à la fin de blit. En mode Blit, il rend la main au CPU toutes les scanlines. 

Tu peux insister et rester sur tes affirmations pleines d'aplomb qui peuvent en tromper certains mais c'est faux.
Il est préconisé de faire un blit ligne à ligne pour que les interruptions puissent être gérées. Il faut donc le faire manuellement et rendre un peu la main à chaque ligne copiée et non pas à chaque scanline. Si ça c'est pas du bricolage...
ça oblige le 68000 a tester à chaque fois pour voir si la dernière ligne du blit a été atteinte. En plus je te laisse imaginer le décalage qu'il peut y avoir avec les interruptions. Pratique pour jouer un module (et bien sur, le système de gestion d'interruption pour la lecture de sample est moins bien pensé que celui du mig. comme d'habitude...) ou pour faire un raster... Au final, quand il faut des interruptions (ce qui est courant sur 8 bits et encore plus sur 16), on est obligé d'oublier le blitter. Super...

Ah bon ? Les cycles plus faciles à déterminer sur ST ? Encore une fois c'est faux : sur le mig tu peux te baser sur la doc motorola alors que sur le ST, tu dois arrondir les accès à la RAM au multiple de 4 supérieur (pratique quand on sait que pleins d'instructions font plusieurs accès à la RAM). En fait sur Amiga on ne programme pas au cycle près parce que :
 - on n'en n'a pas vraiment besoin, on a le copper pour faire ce genre de chose.
 - ça enlève toute compatibilité avec des machines plus rapides.
 - c'est une technique utilisée sur les 8 bits. Donc obsolète à l'époque du ST et du mig

Ou parce ce qu'ils sont difficiles à déterminer avec ce blitter qui prend des cycles de façon anarchique, bricolée...
Sur ST, on programme au cycle près pour se synchroniser avec l'affichage et tricher sur les bordures (toutes ces demos overscan...).

Non pas de façon anarchique, tout est détaillé et précis dans la doc. Toujours cette habitude de dire des betises avec de l'aplomb pour leur donner de la crédibilité. Je te le répète : le système de bascule du controleur mémoire du ST rend plus difficile la prédiction du nombre de cycles. Sauf quand le blitter tourne bien sur : dans ce cas c'est 0 cycles pour le 68000. Pas plus simple comme calcul ! LOL !!!

Oui sur ST, c'est une habitude (voire une obligation pour l'overscan) de coder au cycle près. Et on retrouve cette habitude sur c64, 800XL ou Amstrad. ça en dit long. Lance un Spectrum sur un mega STE en mode 16 Mhz et admire les méfait d'un kernel qu'on rigole...
Sur le mig si on veut se synchroniser avec l'affichage, on a le copper. il est bien plus pratique et nous permet d'avoir une compatibilité entre tous les mig. Et sur le mig y a pas besoin de tricher avec le shifter (et de faire grésiller le moniteur...) pour avoir de l'overscan.

Vous êtes les rois pour asséner des betises avec un aplomb tel que ceux qui ne maitrisent pas ces machines ne peuvent qu'y croire. Le pire est que vous avez fini par y croire...

Comme on vient de le voir, ce ne sont pas des bêtises.

Comme je viens de le montrer : ce sont des betises énormes. Tu ne l'as simplement pas encore compris...

Déjà avec l'aide du copper (qui peut compléter le travail du DMA), tous les amiga peuvent monter à plus que 50 Khz (paula peut dépasser 3 Mhz...). Ensuite, sans trick (et sans copper) les amiga ECS (donc les contemporains au STE) et AGA peuvent faire du 56 Khz.
Et tous les Amiga peuvent faire du 14 bits. Simplement il n'y aura plus que 2 voies au lieu de 4...

Mais oui... pourtant ça sonne plutôt casserole et 8bit en général. 

Venant de quelqu'un qui préfère le son du ST, c'est plutot rassurant...

@TOUKO a écrit:

@Zarnal a écrit:Bon alors, le blitter fasté il peut m'ajouter mes sprites manquants dans flink en fait ? Sinon concrêtement, que fait on de plus avec un blitter fasté ? 

Rien, seul le CPU peut accéder à la fast .

Reformulation correcte :

Bon alors, le blitter avec ses cycles de récupérés  grace à la fast il peut m'ajouter mes sprites manquants dans flink en fait ? Sinon concrêtement, que fait on de plus avec un blitter qui récupère l'ensemble de ses cycles et n'a plus à partager avec le CPU?  Merci.

Deux fois oui : non seulement le blitter récupérera quelques cycles mais, surtout, on pourra lui accorder une plus grande portion de la frame pour faire ses déplacements puisque tout ce qui concerne la logique du jeu sera fait en // au lieu d'être fait à la suite.

Et si les 2 entrent en conflit, c'est le 68k qui devra attendre,c'est tout .

Tiens donc. Le blitter bloque le CPU sur Amiga aussi.   

En nasty mode uniquement (appelé aussi le ST-like mode LOL !!). En mode normal, quand le 68000 a besoin d'accéder à la chipram, Agnus va arreter le blitter au nout de 3 cycles, laisser le 68000 faire son accès et redonner la main au blitter. Pas de problème sur le mig pour déclencher une interruption pendant un blit, même s'il n'y a que de la chipram...

The 68000 test-and-set instruction (TAS) should never be used in the
  Amiga; 

Je remarque que cette instruction ne doit presque être utilisé dans rien dés qu'il y a autre chose que le CPU sur la mobo(pour info sur la Md c'est pareil), encore une joyeuseté du 68K.

Sur les bricolages oui. Sur ST, l'instruction s'appelle Test and Set (TAS) et fonctionne comme prévu.
Sur Amiga, elle s'appelle Test and Set Guru (TASG) . Le Guru Meditation indique que l'Amiga est conforme à son "architecture".

Ben c'est normal : y a que le cpu dans un ST ! et dans un STE le 68000 est bloqué quand le blitter travail, ça ne risque pas de poser problème ! Je préfère ne pas pouvoir utiliser une instruction inutile que perdre des interruptions...

En mode Blit, il rend la main au CPU toutes les scanlines. 

Et comment il fait si il doit faire un blit de 512 octets (ou plus) par exemple ??
il les fait qd ses blits ?? parce qu'un écran pendant l'affichage n'est composé que de scanline, et comme le blitter du ST/STE ne fonctionne pas pendant le hblank, faut expliquer là .

Le blitter a le bus pendant 256 cycles, puis c'est le CPU, puis le blitter... jusqu'à la fin du blit (et le CPU reprend immédiatement la main à la fin).

Le concept est simple sur STE, pour chaque bloc de 4 cycles:
2 cycles CPU ou Blitter  / 2 cycles MMU (video, refresh, DMA...)
Contrairement à l'Amiga, le blitter du STE ne prendra jamais les cycles que j'appelle MMU. Ca évite les plantages (suivez mon regard...   ).

Oui le concept est simple, ou plutôt simpliste : un controleur mémoire avec une répartition statique des cycles. Avec la bonne idée de réserver des cycles à l'affichage même en dehors de la zone d'affichage (même les 8 bits ne font pas cette erreur) ou de grouper les cycles cpu par 2, ce qui fait qu'il y en a un d'inutilisable...
Sur le mig, la répartition est dynamique, ce qui lui permet de bien mieux utiliser la mémoire. Mais comme il y a des priorités, le blitter du mig n'empietera jamais sur la vidéo, les accès disques ou le copper par exemple. Donc le "contrairement à l'amiga" et les plantages, tu peux oublier...

32 Channels Hi-Fi quality (16bit/50kHz/Stereo) playback

Faudrait qu'il m'explique comment il fait pour garder une précision de 16 bit en mixant 4 samples 16 bits ensemble ..
Parce que chez moi 16+16+16+16 ça fait pas un nombre sur 16 bits .

C'est sur, ça ne fait que 14 bits. Ce qui est déjà très bien. Mais ou est le volume ? Y en a pas ? Ou il est fait en software ? Donc, on perd encore en précision  : quand on fait du mixage professionnel, contrôler le volume de chaque voie est une obligation. Et les pros voulaient un volume sur 8 bits (donc dans le pire des cas il reste 6 bits...)
Mais je répète, ça reste super bien pour une utilisation personnelle. Je n'ai aucun mal à dire que le Falcon est une super bécane pour l'audio.

Si le programme est logé en Fast ram, le CPU ne sera ralenti par rien pour lire le programme ("fetching").
Mais le programme doit accéder à la mémoire chipset, pour par exemple préparer l'image... changer les sons, etc. 
Donc en pratique, il y aura partage de cycles, et d'une façon difficile à prévoir, voire chaotique.
Ca me fait penser à un infâme bricolage. 

Préparer l'image ? Changer les sons ? Mais le principe est qu'ils seront en chip. Il y aura des accès chip par le cpu mais ils seront bien moins nombreux que ce que tu laisses entendre.
Ah bon ? "difficile à prévoir", "chaotique" ? Tu sors ça d'ou ? Du monde imaginaire ou le ST est une super bécane ? Chaque accès en chip coute 3 cycles de plus quand le blitter tourne. point barre. Même un fanboy confirmé doit être capable de faire ce genre d'addition. De toute façon sur le mig on ne code pas de kernel au cycle près, on regarde le temps que met une routine (et il sera toujours identique, y a rien de "chaotique") et c'est tout. Et tu sais quoi ? Ben la plupart du temps, sur le ST aussi...

[Seb]

Rocky: on peut trouver des jeux de merde sur toutes les plateformes, je ne suis pas sur que ça prouve quoi que ce soit.

[stapha92]

Rocky: on peut trouver des jeux de merde sur toutes les plateformes, je ne suis pas sur que ça prouve quoi que ce soit.

Un jour il faudrait poster d'un coup quelques centaines de jeux infaisables sur ST. ça mettrait fin aux comparaisons. Cela dit il y a du progrès : au début il n'y avait que SOTB qui était infaisable, après 2 ou 3 jeux et maintenant c'est la dizaine qui est donnée comme nombre ici. On progresse...

Cela dit Rocky a raison : quand on voit que tu peux faire un scrollng fluide avec AMOS sans difficulté (je ne parle même pas du blitz basic : skidmarks, worms, etc...) il faut admettre que c'est encore plus inadmissible de voir des choses pareilles sur le mig (même si, effectivement, ça ne prouve rien).
Franchement vu la taille de  la zone à scroller (10%, 15% de l'écran ?), ce jeu pourrait avoir un scrolling au pixel et être fluide sans aucun problème sur un STF...

[Invité]

skidmarks est fait en basic oO ?

[Zarnal]

Petit comparatif sonore de l'intro d'elvira ;





j'en  encore de   .

A 38s pour le ST.

Edit : merci à stapha72 pour sa réponse sur le blitter.

[Invité]

Tiens donc. Le blitter bloque le CPU sur Amiga aussi.  

Non ce cas là est rare, mais peu arriver .

Le blitter a le bus pendant 256 cycles, puis c'est le CPU, puis le blitter... jusqu'à la fin du blit (et le CPU reprend immédiatement la main à la fin).

Etant donnée que sur ST/STE le blitter ne peut rien faire pendant le hblank après 256 cycles il doit pas rester grand chose au CPU,surtout qu'il faut aussi relancer le DMA avant la prochaine scanline(plus les DMA sons après interruption ),plus autres interruption, timer,hsync possibles..
Sachant qu'une simple interruption (sans traitement) coûte 64 cycles, ça commence à piquer .

Sur mon Amiga, il y a une extension interne de 512K avec un switch on/off sur le côté. Ceci est-il de la mémoire "fast" dans le sens que le chipset n'y a pas accès, ou chip?

Ca dépend de quelle extention tu as, si tu as la plus courante, c'est ce qu'on appelle de la slow car sur le même bus que la chip, mais quand même seulement accessible par le CPU .
Elle fonctionne quasiment comme de la fast, les pertes en cycles sont quasi nulles .
Donc oui c'est plus proche de la fast que de la chip.

Donc en pratique, il y aura partage de cycles, et d'une façon difficile à prévoir, voire chaotique.
Ca me fait penser à un infâme bricolage. 

Fetcher une instruction c'est pas dramatique par rapport à lire écrire des données en continu .
Tu as peu de chances que le fetch de l'instruction soit ralenti, par contre si en plus du fetch tu accèdes à la mémoire c'est plus pareil .
C'est bien parce que le STE est un bricolage pur jus que même avec ces rajouts fait à la va que j'te pousse il arrive pas au niveau de l'amiga .

pour par exemple préparer l'image... changer les sons, etc. 

Tu peux faire ça pendant le vblank, la logique du jeu elle va tourner en fast, et rien ne t'empêche de reloger le code en fast pour qu'il s'exécute en fast .
T'as une autre question ??

Donc en pratique, il y aura partage de cycles, et d'une façon difficile à prévoir, voire chaotique.

Chaotique ??
Non je vois pas pk, du code timé existe sur amiga.

C'est sur, ça ne fait que 14 bits. Ce qui est déjà très bien. Mais ou est le volume ? Y en a pas ? Ou il est fait en software ?

Sans parler de la stéréo qui forcement n'existe plus .

[rocky007]

Rocky: on peut trouver des jeux de merde sur toutes les plateformes, je ne suis pas sur que ça prouve quoi que ce soit.

oui je sais, mais bon, faut bien rigoler un peu non ?

[rocky007]

C'est sur, ça ne fait que 14 bits. Ce qui est déjà très bien. Mais ou est le volume ? Y en a pas ? Ou il est fait en software ?

Sans parler de la stéréo qui forcement n'existe plus .

attendez mais là on parle de quoi ? du STe ou du Falcon ?

[Invité]

attendez mais là on parle de quoi ? du STe ou du Falcon ?

Faut suivre mon petit rocky   
Je parle du moment où tu mixes les samples entre eux tu n'as plus de stéréo, et j'entend par stéréo le panning pas le fait d'avoir le son sur les 2 écouteurs .
Par exemple si on mixe le sample A et le sample B ensemble, tu ne peux plus jouer sur la stéréo du sample A ou B individuellement, comme tu le ferais si chacun avait sa propre voix .

[rocky007]

oui mais sur le falcon, tu n'as pas besoin de les mixer puisque tu as 8 voies..ou alors tu parlais du Ste ?  oui j'avoue ne plus trop suivre, y'a trop de post

[Invité]

oui mais sur le falcon, tu n'as pas besoin de les mixer puisque tu as 8 voies..ou alors tu parlais du Ste ?  oui j'avoue ne plus trop suivre, y'a trop de post

Je parlais plus pour ton logiciel qui annonce 32 voix,mais sinon c'est juste sur falcon tant que tu restes sur 8 voix les réglages hard de la puce sont valables pour chaque samples .

[Meditating Guru]

@stapha92 a écrit:Et 25 ans pour arriver à faire un pacmania fluide sur STE. J'ai dit fluide parce quand ici je lis que ça vaut la version Amiga... deux fois moins de couleurs, une fenêtre au lieu de l'overscan...

Pacmania STE utilise l'overscan vertical pour présenter les dimensions appropriées. Je ne passe pas mon temps à compter les couleurs mais je n'ai pu qu'entendre que la musique "stereo" sur l'Amiga était juste bonne à casser les oreilles. Quelle casserole.   

Ah oui super, un overscan vertical au bout de 25 ans : Ouaouhhhh !!! Tout ça sur l'Amiga-Killer, tel qu'il était présenté par Atari, les rois de l'esbrouffe..

Des jeux contemporains utilisaient aussi l'overscan vertical.

Pas besoin de compter : un STE ne peut pas afficher plus de 16 couleurs (hors rasters). Rien de nouveau au pays du shifter de ce coté...

Si, en redéfinissant les couleurs au vol, de là à le faire dans un jeu à 50 fps...

En se limitant à 16 couleurs, le mig pourrait faire Pacmania en haute résolution sans problème. et encore, avec les sprites il continuerait  à avoir plus de 16 couleurs...
Attention ! Je ne critique pas le travail des codeurs qui ont fait ce jeu su STE. je remet juste les choses dans l'ordre quand vous prétendez que ça vaut la version mig...
Et si tu avais VRAIMENT eu un amiga à l'époque, tu aurais pu prendre un cordon à 10 francs et retrouver l'inimitable son de ton ST si parfait...

Le fait est qu'il est en basse résolution, il y avait forcément une limite...
J'AVAIS un Amiga, et je le subissais en mono.
Même en mono, la musique de Pac Mania est horrible sur Amiga.

Techniquement le 68000 peut lire ou écrire un mot tous les 2 cycles sur le mig mais tous les 4 cycles sur le ST : tu te trompes encore...
C'est pour ça que dans cette super machine toutes les instructions voient leur nombre de cycle arrondi au multiple de 4 suivant... Et c'est pour ça que quand Atari a conçu le mega STE il se sont confrontés à un problème : le 68000 tournant 2 fois plus vite, c'est comme si on divisait par 2 le nombre de cycles de chaque instructions. mais il faut l'arrondir à 4 après ! (en fait c'est pire : c'est le temps entre 2 accès au bus qui doit être arrondi, et beaucoup d'instructions font plusieurs accès...) Du coup y a presque aucun gain ! Et Atari a été obligé de mettre une mémoire cache pour compenser et obtenir une accélération moyenne de 50 % ! Ouaouhhh !!! Met un 68000 à 14 Mhz dans un mig et il ira 2 fois plus vite. Point barre.

Misères de la mémoire partagée...
Je parlais du bus, qui permet un R/W tous les deux cycles. Le 68000 a besoin de minimum 4 cycles pour un R/W. Le CPU et le MMU sont entrelacés. On sait que sur ST, le CPU n'a pas accès pendant les cycles MMU. En pratique, les cycles perdus par le CPU ne sont pas trop nombreux car les instructions ont tendance à s'arrondir à 4 cycles.

Ca arrive sur Amiga aussi.
"Some 68000 instructions do not match perfectly with the allocation of even
cycles and cause cycles to be missed. If cycles are missed, the 68000 must
wait until its next available memory slot before continuing. However, most
instructions do not cause cycles to be missed, so the 68000 runs at full
speed most of the time if there is no blitter DMA interference."

J'avais bien compris et non : le bus bascule tous les 2 cycles sur le ST et tous les cycles sur le mig. Super le design...

OK ici j'avoue mon ignorance, je croyais que la résolution était de 2 cycles sur Amiga aussi.

Oui pas trop perdus c'est vrai mais ça reste inacceptable quand on sait qu'il suffisait de faire basculer le MMU 2 fois plus vite (économie quand tu nous tiens...) ! Et ça devient carrément ridicule avec un mega STE ou une carte avec un 68000 à 16 Mhz : Super l'évolutivité de la machine, on sent le truc conçu pour perdurer... LOL !! Avec une bascule à chaque cycle le mega STE serait plus rapide sans avoir de mémoire cache. On peut faire mieux pour moins cher : faut juste prévoir les choses dès le début et arreter le bricolage...
Oui ça arrive sur le mig mais met l'article en entier : ça parle du cas ou le chipset est obligé de voler des cycles. Ce qui n'arrive jamais, si le mig se limite à une résolution du type ST, c'est à dire 352x288x16 ou 704x288x4... Ah ben non ! c'est déjà au dessus de ce que peut faire un ST. En tout cas dans ce mode, le mig ne perd AUCUN cycles. Je parle sans fast ram bien sur. Sinon il n'y a plus de problèmes...

Ca peut arriver sur Amiga, moins que sur ST. Dans les deux cas, ce n'est pas dramatique.

Tu veux le détail du fonctionnement ? Relis donc un de mes anciens posts :

[bla bla bla]
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 
[bla bla bla]

Quelle est l'unité de ces cycles? Sur ST, 16 pixels sont affichés en 16 cycles CPU, ici on dirait que c'est 8? Mais l'écran Amiga ne tourne pas deux fois plus vite?

Toutefois, le blitter du STE peut fonctionner pendant l'affichage, pas celui de l'Amiga.   
Au total, le blitter de l'Amiga a un peu plus de cycles, on est bien d'accord. Mais le blitter d'Atari n'est pas si nul que ça. Ce n'est pas du bricolage. 

Ah bon ? Le blitter du mig ne fonctionne pas pendant l'affichage ? Première nouvelle.

Sans Fast, c'est affichage ou CPU ou blitter, pas les trois en même temps, même sur ta super console.

Tu fais déjà des erreurs quand tu parles du ST. Tu crois qu'il est prudent de parler du mig ? Tu as tort : Sans fast tu peux avoir les 3. Et même plus en y ajoutant le son, les sprites, etc...
Toujours cette technique très prisée sur ce forum d'affirmer des énormités avec aplomb...

Ca dépend de ce qu'on appelle en même temps. Sur 4 cycles unité CPU, combien d'accès pour le blitter, le CPU, l'affichage... Je comptais 2. Ne me dis pas que c'est 4 sur l'Amiga!

Non, il n'est pas si nul, mais il lui manque des tas de choses présentes dans celui du mig pourtant conçu bien avant...
Et son intégration dans le ST relève, elle, du bricolage. Relis mes anciens posts, tu comprendras pourquoi j'ai malgré tout du respect pour le ST et absolument pas pour le STE

Le blitter n'est pas propre au STE, sa conception date du STF, il était une des "attractions" du Mega. On peut critiquer mais le GEM affichait nettement plus vite avec le blitter.
N'étant pas un fanboy, je ne prétends pas qu'il est mieux que celui de l'Amiga. Mais ce n'est pas un bricolage, c'est une architecture à compromis.

Ah bon ? Alors pourquoi les STF des premières années n'ont pas l'emplacement pour le blitter ? Il a bien été conçu après celui du mig non ? Alors pourquoi ne pas l'avoir rendu capable de laisser des cycles au 68000 quand celui-ci en a besoin ?

Ce fut leur choix de mettre en concurrence le CPU et le blitter, sans toucher aux cycles "MMU". Ca permet au blitter de travailler pendant l'affichage, qui représente quand même la majorité des cycles.
L'idée étant sans doute que le blitter est plus rapide que le CPU.

C'est ce qui se passe dans le mig, suffisait de copier ! A moins que l'architecture pourrie du ST ne l'ait pas permis...

Je crois que c'est l'équipe Amiga qui copiait les autres et bricolait un système trop complexe, aux plantages inévitables.

A noter : le blitter du mig peut se comporter comme celui du ST et bloquer totalement le cpu quand il n'y a pas de fast. Ce mode de fonctionnement est appelé "nasty mode" (mode dégueulasse). Donc ST mode = nasty mode...

Le mode Hog du ST, pas Blit.

Continue ta lecture du HRM (et je salue l'effort de chercher des informations sur cette source, dommage que tu n'ais pas tout compris...), tu verras que je n'invente pas.

En me documentant, j'ai lu que si on utilise l'instruction TAS sur un Amiga, on a droit au Guru Meditation car l'architecture bricolée perd les pédales. 

Tu t'es mal documenté. Tu sais à quoi sert cette instruction et quelle est sa spécificité ? Renseignes toi déjà là dessus et tu comprendras qu'il ne faut pas croire tout ce qu'on lit...

Tu parles au gens comme s'ils étaient des ignorants et que seul l'Amigaleux détenait la Vérité...   
Voici ma source:

  Avoid the TAS instruction.
  --------------------------
  The 68000 test-and-set instruction (TAS) should never be used in the
  Amiga; the indivisible read-modify-write cycle that is used only in
  this instruction will not fit into a DMA memory access slot.
 

Je ne critique pas l'ignorance, ce n'est pas une tare. je critique le fait d'affirmer sans savoir, c'est trop fréquent ici.
Alors parlons de TAS, puisque tu penses avoir trouvé un point faible sur le mig.

Cette instruction test l'état d'un bit à une adresse indiquée et met ce bit à 1 dans la foulée, ça revient à faire un BTST + un BSET.
Qu'a-t-elle de spécial ? Et bien entre le test et la pose du bit, le 68000 ne libère pas l'accès à la mémoire.
Mais alors pourquoi faire ? Et bien cela est utile dans un environnement multi-processeur pour gérer les ressources partagées.

J'explique : imaginons un micro dans lequel il y a 2 68000, et imaginons qu'il puissent avoir besoin d'accéder à la même ressource, une imprimante par exemple.
Tu imagines ce qui se passera si tous les 2 envoient des données à imprimer en même temps ? ça va mélanger le tout et mettre un bordel monstre !
Le codeur va donc choisir une adresse mémoire qui va servir de sémaphore et indiquer si l'imprimante est en cours d'utilisation.
Du coup, quand l'un des processeurs veut accéder à l'imprimante :
- il va tester le sémaphore qui correspond à l'imprimante
- il va le mettre à 1
- S'il était à 1 au moment du test , il va attendre ou abandonner.
- S'il était à 0 il va utiliser l'imprimante et, quand il aura teminé il va mettre à 0 le sémaphore

Pourquoi ne pas utiliser BTST pour tester le sémaphore et un BSET pour le poser alors ? Et bien supposons que les 2 68000 fasse le test avec un seul cycle d'écart : les 2 vont le voir à 0 et donc les 2 vont le mettre à 1. Et les 2 vont utiliser l'imprimante (ok ça a une chance infime d'arriver...). Problème !
Avec TAS, entre le test et la pose du sémaphore, l'accès à la mémoire n'est pas libéré par le 1er 68000 (alors qu'il y a plusieurs cycles ou il n'en a pas besoin). Donc, quand le 2eme 68000 vient pour tester le sémaphore, il est mis en attente jusqu'à ce que le premier ai terminé et l'ai posé. Quand il fera sa lecture, il verra bien le sémaphore posé et il n'y a plus aucun risque de problème d'accès concurrent.

En fait, même si je ne suis qu'un atariste, je savais ça.

Pourquoi cette instruction doit-elle etre évité sur le mig ? Et bien parce que le CPU et le blitter peuvent tourner en même temps ! On pourrait avoir le blitter qui tente d'accéder au bus alors que le 68000 ne le libère pas. Aie !
Quels sont les impacts ? Aucun !!!! tu as déjà vu un ST ou un mig avec 2 68000 qui tournent en // ? Non ? moi non plus !
Mais je te rassure, puisque tu semble être géné par ça j'imagine que tu avais prévu de monter un 2eme 68000 dans un amiga. Pas de problème alors : il suffit de mettre tous les sémaphores dont tu auras besoin en fast. et là aucun problème... 

En dehors de ça, TAS n'a aucun interet.

Encore une fois ta source est bonne mais il faut étudier un peu plus le truc...

Mais des programmes sur ST l'utilisent pour leurs propres besoins (plus rapide que BTST + BSET).

Le blitter ne bloque totalement le CPU qu'en mode Hog. En mode Blit, les cycles sont partagés moitié moitié chaque scanline, donc le CPU ne va rien louper, sauf si on programme au cycle près, mais même ça c'est possible parce que les cycles sont plus faciles à déterminer qu'avec l'Amiga.

Ah bon ? totalement faux. Le blitter bloque le cpu dès qu'il fonctionne sur ST.

En mode Hog, le blitter bloque jusqu'à la fin de blit. En mode Blit, il rend la main au CPU toutes les scanlines. 

Tu peux insister et rester sur tes affirmations pleines d'aplomb qui peuvent en tromper certains mais c'est faux.
Il est préconisé de faire un blit ligne à ligne pour que les interruptions puissent être gérées. Il faut donc le faire manuellement et rendre un peu la main à chaque ligne copiée et non pas à chaque scanline. Si ça c'est pas du bricolage...
ça oblige le 68000 a tester à chaque fois pour voir si la dernière ligne du blit a été atteinte. En plus je te laisse imaginer le décalage qu'il peut y avoir avec les interruptions. Pratique pour jouer un module (et bien sur, le système de gestion d'interruption pour la lecture de sample est moins bien pensé que celui du mig. comme d'habitude...) ou pour faire un raster... Au final, quand il faut des interruptions (ce qui est courant sur 8 bits et encore plus sur 16), on est obligé d'oublier le blitter. Super...

Je crains que tu te trompes... on peut utiliser le blitter en mode Blit et le bus sera partagé tous les 256 cycles. Les interruptions seront gérées.
Le TOS utilise ce mode en relançant le Blitter dès que le CPU a la main, mais ce n'est pas obligatoire.
Ca marche quelle que soit la taille du blit total.

Ou parce ce qu'ils sont difficiles à déterminer avec ce blitter qui prend des cycles de façon anarchique, bricolée...
Sur ST, on programme au cycle près pour se synchroniser avec l'affichage et tricher sur les bordures (toutes ces demos overscan...).

Non pas de façon anarchique, tout est détaillé et précis dans la doc. Toujours cette habitude de dire des betises avec de l'aplomb pour leur donner de la crédibilité. Je te le répète : le système de bascule du controleur mémoire du ST rend plus difficile la prédiction du nombre de cycles. Sauf quand le blitter tourne bien sur : dans ce cas c'est 0 cycles pour le 68000. Pas plus simple comme calcul ! LOL !!!

Oui sur ST, c'est une habitude (voire une obligation pour l'overscan) de coder au cycle près. Et on retrouve cette habitude sur c64, 800XL ou Amstrad. ça en dit long. Lance un Spectrum sur un mega STE en mode 16 Mhz et admire les méfait d'un kernel qu'on rigole...
Sur le mig si on veut se synchroniser avec l'affichage, on a le copper. il est bien plus pratique et nous permet d'avoir une compatibilité entre tous les mig. Et sur le mig y a pas besoin de tricher avec le shifter (et de faire grésiller le moniteur...) pour avoir de l'overscan.

Sur ST, il est prouvé qu'on pouvait synchroniser le CPU et le Blitter avec l'affichage. Pas sur Amiga, vu qu'on utilisait le copper (qui était super pratique). Et c'est clair que l'Amiga n'a pas besoin de triche pour ça, sur ST c'était le fun de truquer la machine.

Mais oui... pourtant ça sonne plutôt casserole et 8bit en général. 

Venant de quelqu'un qui préfère le son du ST, c'est plutot rassurant...

C'est pas de ma faute si le son est souvent meilleur sur ST, problème de talent et de gens qui sont trop vite contents d'eux dès que le son est samplé. J'ai donné des exemples valables.

Tiens donc. Le blitter bloque le CPU sur Amiga aussi.   

En nasty mode uniquement (appelé aussi le ST-like mode LOL !!). En mode normal, quand le 68000 a besoin d'accéder à la chipram, Agnus va arreter le blitter au nout de 3 cycles, laisser le 68000 faire son accès et redonner la main au blitter. Pas de problème sur le mig pour déclencher une interruption pendant un blit, même s'il n'y a que de la chipram...

Quel bricolage. Qui est prioritaire à la fin? Le blitter ou le CPU? Je ne suis plus.

The 68000 test-and-set instruction (TAS) should never be used in the
  Amiga; 

Je remarque que cette instruction ne doit presque être utilisé dans rien dés qu'il y a autre chose que le CPU sur la mobo(pour info sur la Md c'est pareil), encore une joyeuseté du 68K.

Sur les bricolages oui. Sur ST, l'instruction s'appelle Test and Set (TAS) et fonctionne comme prévu.
Sur Amiga, elle s'appelle Test and Set Guru (TASG) . Le Guru Meditation indique que l'Amiga est conforme à son "architecture".

Ben c'est normal : y a que le cpu dans un ST ! et dans un STE le 68000 est bloqué quand le blitter travail, ça ne risque pas de poser problème ! Je préfère ne pas pouvoir utiliser une instruction inutile que perdre des interruptions...

Quand une instruction ne marche pas sur Amiga, on dit qu'elle est inutile.  

En mode Blit, il rend la main au CPU toutes les scanlines. 

Et comment il fait si il doit faire un blit de 512 octets (ou plus) par exemple ??
il les fait qd ses blits ?? parce qu'un écran pendant l'affichage n'est composé que de scanline, et comme le blitter du ST/STE ne fonctionne pas pendant le hblank, faut expliquer là .

Le blitter a le bus pendant 256 cycles, puis c'est le CPU, puis le blitter... jusqu'à la fin du blit (et le CPU reprend immédiatement la main à la fin).

Le concept est simple sur STE, pour chaque bloc de 4 cycles:
2 cycles CPU ou Blitter  / 2 cycles MMU (video, refresh, DMA...)
Contrairement à l'Amiga, le blitter du STE ne prendra jamais les cycles que j'appelle MMU. Ca évite les plantages (suivez mon regard...   ).

Oui le concept est simple, ou plutôt simpliste : un controleur mémoire avec une répartition statique des cycles. Avec la bonne idée de réserver des cycles à l'affichage même en dehors de la zone d'affichage (même les 8 bits ne font pas cette erreur) ou de grouper les cycles cpu par 2, ce qui fait qu'il y en a un d'inutilisable...

En dehors de l'affichage, ces cycles sont utilisés par le memory refresh et le DMA. Ce qui fait que les disques durs sont plus fiables sur ST.

Sur le mig, la répartition est dynamique, ce qui lui permet de bien mieux utiliser la mémoire. Mais comme il y a des priorités, le blitter du mig n'empietera jamais sur la vidéo, les accès disques ou le copper par exemple. Donc le "contrairement à l'amiga" et les plantages, tu peux oublier...

C'est ce que je disais à mon Amiga chaque fois qu'il me sortait un Guru (chaque jour d'utilisation).

Si le programme est logé en Fast ram, le CPU ne sera ralenti par rien pour lire le programme ("fetching").
Mais le programme doit accéder à la mémoire chipset, pour par exemple préparer l'image... changer les sons, etc. 
Donc en pratique, il y aura partage de cycles, et d'une façon difficile à prévoir, voire chaotique.
Ca me fait penser à un infâme bricolage. 

Préparer l'image ? Changer les sons ? Mais le principe est qu'ils seront en chip. Il y aura des accès chip par le cpu mais ils seront bien moins nombreux que ce que tu laisses entendre.

Si, tout se passe là-bas, la logique du jeu sur les jeux d'espace habituels de cette console à disquette est des plus rudimentaires.

Ah bon ? "difficile à prévoir", "chaotique" ? Tu sors ça d'ou ? Du monde imaginaire ou le ST est une super bécane ? Chaque accès en chip coute 3 cycles de plus quand le blitter tourne. point barre. Même un fanboy confirmé doit être capable de faire ce genre d'addition. De toute façon sur le mig on ne code pas de kernel au cycle près, on regarde le temps que met une routine (et il sera toujours identique, y a rien de "chaotique") et c'est tout. Et tu sais quoi ? Ben la plupart du temps, sur le ST aussi...

Le ST est une super bécane.
J'ai l'impression qu'avec ces règles confuses de priorité DMA, bien malin qui peut calculer les cycles.
Mais c'est vrai qu'en général, on ne devrait pas calculer au cycle près. C'est réservé aux machines intéressantes comme le C64 et le ST.

[Invité]

Quand une instruction ne marche pas sur Amiga, on dit qu'elle est inutile.   

La megadrive a le même souci avec TAS, faut pas l'utiliser, donc ..

C'est réservé aux machines intéressantes qui ont des lacunes comme le C64 et le ST. 

[Meditating Guru]

Sur Atari, tu avais aussi une extension? Je veux dire: tu t'es mis à la soudure?
Perceuse aussi, pour faire un trou sous la table pour brancher un joystick... C'est ptet pour ça en fait que le ST a eu de moins bons jeux: impossible de jouer en fait...

En fait, pour le switch, un trou a été percé sur le côté de la poubelle.
Quant au ST, c'est clair qu'il n'était pas conçu comme un console de jeu a priori, le joystick n'était pas prioritaire. Les fiches MIDI étaient plus accessibles.

Le blitter a le bus pendant 256 cycles, puis c'est le CPU, puis le blitter... jusqu'à la fin du blit (et le CPU reprend immédiatement la main à la fin).

Etant donnée que sur ST/STE le blitter ne peut rien faire pendant le hblank après 256 cycles il doit pas rester grand chose au CPU,surtout qu'il faut aussi relancer le DMA avant la prochaine scanline(plus les DMA sons après interruption ),plus autres interruption, timer,hsync possibles..
Sachant qu'une simple interruption (sans traitement) coûte 64 cycles, ça commence à piquer .

Non, le CPU et le blitter se partagent le slot 1, la video, DMA, etc. le slot 2, hblank ou pas.
Ce que je disais, c'est que si le blit dure 40 cycles, le CPU n'attend pas bêtement jusqu'aux 256 pour reprendre la main.

Sur mon Amiga, il y a une extension interne de 512K avec un switch on/off sur le côté. Ceci est-il de la mémoire "fast" dans le sens que le chipset n'y a pas accès, ou chip?

Ca dépend de quelle extention tu as, si tu as la plus courante, c'est ce qu'on appelle de la slow car sur le même bus que la chip, mais quand même seulement accessible par le CPU .
Elle fonctionne quasiment comme de la fast, les pertes en cycles sont quasi nulles .
Donc oui c'est plus proche de la fast que de la chip.

Quel bricolage! On ne s'y retrouve pas. Si elle est sur le bus de la chip, il y a concurrence si je comprends bien?  

pour par exemple préparer l'image... changer les sons, etc. 

Tu peux faire ça pendant le vblank, la logique du jeu elle va tourner en fast, et rien ne t'empêche de reloger le code en fast pour qu'il s'exécute en fast .
T'as une autre question ??

Il faut être un expert pour que la Fast serve à quelque chose. Et la logique du jeu, comme je disais, vu le niveau habituel des jeux sur Amiga: bing pouf bang!  

Quand une instruction ne marche pas sur Amiga, on dit qu'elle est inutile.   

La megadrive a le même souci avec TAS, faut pas l'utiliser, donc ..

Oui, entre consoles on se partage le style "d'architecture."

[Zarnal]

skidmarks est fait en basic oO ?

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

[Invité]

Oui, entre consoles on se partage le style "d'architecture." 

Bien vu 

c'est que si le blit dure 40 cycles, le CPU n'attend pas bêtement jusqu'aux 256 pour reprendre la main.

je comprends bien, mais tu utilises rarement le blitter pour 40 cycles, c'est presque aussi coûteux à le configurer que ce que représente la copie.
déjà 256 cycles doit représenter 100 octets max (si le blitter copie 1 octet/2 cycles) .
Une scanline représente combien de cycles CPU sur ST ?? 500 maxi ??
Si tu enlèves à ces 500 cycles les accès du shifter, il doit pas en rester bcp pour le blitter et le CPU .
Et n'oublies pas que sur ces cycles, le STE bouffe encore des cycles avec le DMA de l'audio, et plus tu montes en fréquence, plus il va en bouffer,tu commences à comprendre pk le 50khz est une blague ??

Il faut être un expert pour que la Fast serve à quelque chose. 

Reloger du code en RAM+code automodifié est le B.A BA du codeur .. 
C'est comme si tu disais qu'il fallait être un expert pour utiliser une extension mémoire sur ton ST.
Tu utilises la fast comme tu utilises la slow ou la chip, seulement tu sais que seul le CPU y accède, niveau CPU ça change rien,c'est juste plus rapide .

Quel bricolage! On ne s'y retrouve pas. Si elle est sur le bus de la chip,

D'un point de vue utilisateur ça change rien,pour le codeur pas grand chose non plus à moins d'attaquer les adresses mémoire à la sauvage .
Il a juste à initialiser un pointeur mémoire sur la bonne adresse de début de la RAM, comme le ferrait un codeur ST qui teste une extension de mémoire .
Avec le 68k ça pose aucun problème ce genre de manip .
Tu as les mêmes style d'appellation avec la mémoire sur ST/STE, alors je vois pas pk tu pinailles .

 il y a concurrence si je comprends bien?   

Tu es dans un cas similaire au ST avec la slow,sauf que les accès sont plus optimisés et ici le chipset ne gêne quasiment pas le CPU(c'est pas du tout avec la fast) .
Avec la slow c'est déjà mieux que le ST avec ou sans extension .

L'avantage du blitter/DMA son du ST/STE, c'est qu'ils peuvent accéder à bpc plus de RAM que le chipset de l'amiga qui est limité à 512ko(OCS)/1MO(ECS) et 2MO(AGA) .

[Zarnal]

Pour en revenir aux cartes PPC modernes/Vampire Axxx(x) je me pose la question de savoir quel en est réellement l'intérêt ? Hormis pour l'hypothétique vampire 1200 qui pourrait apporter la partie graphique sans se prendre la tête avec une tour. ce qui serait chouette Alors super on a un amiga boosté, on peut faire tourner mame à la frame sans son, quelques vidéos  mais quid de sa nouvelle nourriture ? C'est bien beau de penser " un jour on aura ci ou ça, pleins de nouveaux programmes " mais concrètement on voit bien que c'est une autre histoire. Je ne sais pas si il en va de même pour les accélérateurs ST.

[TotOOntHeMooN]

On le voit bien sur le forum de Apollo Team... Tourne sur les Amiga boostés des émulateurs (vieux Mac, MAME, ...) et tout ce qui peut-être recompillé du monde Linux. Bref, on marche sur la tête car cela n'apporte rien de plus que ce qu'on pouvait déjà faire sur PC fin des années 90, les jeux en moins.

Je partage donc le même sentiment, en me disant aussi que le jour ou une version 1200 sortira, ça permettra effectivement d'avoir sous le capot tout ce dont j'aurai rêvé il y a 20 ans (CPU, RTG, AHI) en une seule carte.