Re: GUERRE ST-AMIGA, FIGHT !!!

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

[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

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 .

je ne vois pas pourquoi avoir plus de 8 voies de ferais perdre la stéreo !

[Invité]

je ne vois pas pourquoi avoir plus de 8 voies de ferais perdre la stéreo !

Parce que la stéréo se règle sur la voix, quand 2 samples(ou plus) sont sur la même voix(mixages de samples) si tu modifies la stéréo de la voix (le panning) ,ca va toucher tout les samples mixés dans la voix .
Donc si tu mixe le sample A avec le samples B, et que tu veux donner un effet sur le samples A par exemple, et le faire passer de droite à gauche, tu pourras plus, ou sinon tout les samples mixés avec A feront pareil .
Avoir un son stéréo veut dire pouvoir le sortir sur le HP de droite, de gauche ou les 2 .

[stapha92]

@stapha92 a écrit:

[size=11]@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...[/size]

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.

Tout à fait. Et sur STF en plus. Encore une fois je ne critique pas les codeurs. je salue même le portage de pacmania (même si j'aurai préféré une version STF, quitte à ce qu'elle soit un peu moins bien). Simplement je m'amuse des commentaires qui pensent que cette version vaut celle du mig, alors qu'elle est impossible à égaler, même sur un STE

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

j'avais dis "hors rasters" : je parlais de la redéfinition des couleurs.
En fait si : un ST peut tout à fait en faire dans un jeu à 50 fps. Et il aurait pu en faire dans pacmania sans problème (du moins je le suppose car j'imagine que le scrolling s'appuie sur le scrolling hardware et pas sur le blitter). Simplement le jeu ne s'y prete pas.

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.

Les gouts et les couleurs...
La plupart des samplers PRO de l'époque ne dépassaient pas le 12 bits. Le son en 8 bits n'est pas aussi mauvais que ça. Surtout que sur mig, dans un mod, on les a toujours, on ne les perd pas pour jouer sur le volume ou mixer des voies et qu'il n'y a pas de perte quand on joue sur la tonalité, fonctionnement qui est assez unique.

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.

Quand l'amiga se contente de résolutions du type de celles du ST ça ne lui arrive JAMAIS. Ils auraient pu faire pareil sur le ST avec un basculement à chaque cycle. Mais il est vrai que ce n'est pas aussi dramatique qu'on pourrait le croire, je l'ai bien précisé dans mes explications antérieures. Par contre sur un mega STE, c'est ridicule...

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?

Je ne comprend pas... Mais les cycles sont à peu près identiques entre les 2 machines

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!

Ah je comprend mieux la méprise : sur le mig la répartition des accès mémoire n'est pas concentrée dans un format qui se répète tous les 4 cycles. Elle se répartit sur toute la frame ! Heureusement car il y a 25 destinations possibles pour chaque accès mémoire dans le mig... Et cette répartition est dynamique : elle s'adapte au besoin. C'est bien pour ça que lorsque le cpu a besoin d'accéder à la chip, Agnus est capable d'interrompre le blitter pendant 1 cycle pour que le 68000 puisse faire son accès. Simplement il attendra 3 cycles pour le cas ou il n'y aurait que de la chip : ça permet de ne pas arreter le 68000 tout en évitant de trop ralentir le blitter (d'autant que le 68000 est loin de pouvoir accéder à la RAM à tous les cycles).
C'est bien cette façon de faire que j'aurai bien voir implémentée sur le blitter du STE. Vu que l'architecture ne le permet pas, ils auraient pu mettre un système qui arrete le blitter quand une interruption se déclenche (quitte à ce que ce soit le 68000 qui le relance). ça aurait évité bien des problèmes

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 vrai mais ils auraient pu travailler en même temps ! Pour illustrer, je prend le pire des cas : Si un programme a besoin de faire des calculs pendant un blit, par exemple des divisions (jeu 3d ou le calcul des sommets se fait pendant que le blitter efface l'écran). Le fait d'interrompre le blitter quand le 68000 doit accéder à la mémoire pour lire la division qu'il doit faire ralentit le blitter d'un cycle : c'est pas très couteux. Par contre, la division se fera en interne du 68000 pendant 156 cycles. Il y a donc un gros gain à le faire comme ça par rapport à si on le fait à la suite ! Et beaucoup d'instructions 68000 prennent beaucoup de cycles même si 156 est un extreme. En fait il y aurait un gain pour chaque instruction qui en prend au moins 2 : les instructions 68000 les plus simples (ADD, AND, OR, ...) en prennent 4. Et encore en 16 bits : en 32 c'est 6 (donc 8 pour le ST...). Tu vois le gain ?
Et si on ajoute à ça la possibilité d'avoir de la fast, on voit bien que le mig et le STE n'ont pas du tout la même intelligence de conception.

Je parle du STE et pas du STF. Car même si certains STF ont un blitter, ce n'est pas quelque chose qui était mis en avant. En tant que consommateur, si on me met un blitter sans me prévenir, je ne peux que me réjouir de ce qu'il apporte en plus. par contre si on me vend un STE en me parlant de son blitter qui est censé surpasser celui du mig, y a de quoi être énervé.

C'est ce que j'ai toujours dit ici : le STF t'en donnait pour ton argent. Le STE n'était qu'une esbrouffe...

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.

Ca ne change pas grand chose. Au lieu de faire faire tout le travail du blitter puis du cpu, on fait une alternance sans exploiter le fait que le 68000 utilises plusieurs cycles pour ses instructions. C'est juste un léger mieux pour les interruptions. Mais il y a une meilleure façon de faire : en demandant le traitement d'une ligne à la fois. Le blitter du STE utilise un compteur de ligne à traiter qui finit à 0 à la du blit. Il suffit de le remettre à 1 pour lancer la copie de la ligne suivante, il n'y a pas besoin de toucher aux autres registres. Grosso modo, faute d'une répartition de cycles dynamique, on confie cette tache au 68000. On peut aussi le faire en mode blit en manipulant le flag busy mais au prix d'un délai plus long en cas d'interruption (sauf pour des lignes très longues bien sur...). Un simple mode qui aurait attribué, par exemple, 4 cycles au blitter et 1 au 68000 aurait permis une meilleure parralélisation sans être incompatible avec l'architecture du ST puisque là aussi ça aurait été statique

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

Oui plus rapide : 10 cycles au lieu de 12. Sauf que sur ST une instruction de 10 cycles en prend 12...
On gagne quand même en place mémoire. Mais à quel prix ? Impossible de choisir le bit à poser, et blocage de la mémoire pendant 5 cycles. là ou btst+bset la bloque pendant 2 cycles. Evidemment sur un ST ou aucune parralélisation est possible ce n'est pas grave (et c'est pour ça qu'elle est utilisable) mais sur le mig il y aurait une perte, ce serait stupide à utiliser pour gagner 2 octets sur le code source (et 2 cycles pour le cpu puisque sur le mig TAS prend 10 cycles)
Pas toujours bon de chercher à gagner de la mémoire : tu veux qu'on parle du LINE-F utilisé par l'OS du ST (et malheureusement par pleins de programmes...) et qui le rend incompatible avec une FPU ?

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.

Non ça je sait mais ce n'est pas de la parralélisation. Les interruptions seront gérées avec jusqu'à 256 cycles de retard ! Plus de la moitié d'une scaline sera passée avant même d'ajouter les quelques dizaines de cycles que met le 68000 à traiter une interruption ! Même pour un raster c'est bien trop long ! Mais c'est pas grave : tant que TAS fonctionne...

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.

Je suis bien d'accord. Mais c'est surtout pour les démos. Démos que je ne dénigre pas, bien au contraire ! Les démos ST sont très chouette, rien à dire là dessus. Mais c'est bien plus difficile à faire dans un jeu (voir enchanted land : un monstre au niveau codage pour faire un scrolling qui ne vaut celui de pleins de démo ST)
Par contre quand je vois ça dans une application (spectrum...) qui, du coup, ne fonctionne plus dès qu'on la passe sur autre chose qu'un 68000 à 8 Mhz (TT, mega STE, falcon, cartes à 16 Mhz pour ST), je trouve ça inacceptable...

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.

Non le bricolage c'est l'ajout du blitter dans une architecture non prévue pour. La capacité d'attribuer les canaux DMA de façon dynamique est l'un des avantages du mig.

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.   

Elle marche très bien en fast. Pourtant on ne l'y utilise pas davantage..

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.

Renseigne toi : pas vraiment... Et même quand ils sont fiables, votre TOS apporte les bugs qu'il faut pour tout gacher...
Tu penses qu'il n'y a pas de refresh ou de canaux DMA pour les HD et FD sur le mig ? LOL !!

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

oui c'est ça...

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.

ça c'est de l'argument ! il ne reste que ça aux stistes ? revenir sur la console à disquette ? Quel ordinateur a un port cartouche mais pas de possibilité d'évolution ? Un OS incompatible 32 bits et fpu qui n'est qu'un hack dépassé du cp/m ? Auquel on a jouté une surcouche hyper lente pour gérer le fenêtrage ?
Qui possède les bugs les plus drole en matiere de gestion de disques ? Qui est écrit en faisant fi des recommandation de motorola pour gagner quelques octets en ROM ? Et que la majorité achetait pour jouer alors qu'il est moins bon qu'un C64 pour ça ?

Et non : la logique du jeu est gérée en fast. Donc elle peut être très évolué. Quand tu veux changer de son ou d'image, le programme n'a besoin que de manipuler des pointeurs et faire faire le boulot au chipset. Pendant ce temps il a tout pleins de cycles à utiliser en fast. Pourquoi veux-tu qu'il passe son temps en chip ?
Oui c'est ça une logique rudimentaire : The settlers gérait 64000 personnages simultanément avec un A500 sans fast... Mais comme c'est un jeu inaccessible au ST, tu ne peux pas comprendre...

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. 

C'est vrai que le ST est une super bécane (pas le STE...).
C'était surtout réservé aux 8 bits. Les 16 bits n'avaient plus besoin de ce genre de chose. Faut croire que le ST si...
A moins que les codeurs ST bien conscient qu'il ne fallait pas croire tout ce qui était affirmé sur les emballages et les manuels (les 4096 couleurs de Degas...) se soient dit : "ben non ça peut pas être un 16 bits, sur pleins de points le c64 est meilleur. Allons coder des kernels alors !" LOL !!!

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 .

En fait c'est encore plus simple : tu demandes de la fast à l'OS et c'est lui qui gère. Grace au l'autoconfig, pas besoin de tester une adresse mémoire. S'il n'y a pas de fast tu recevras une adresse en chip. Et c'est tout.

[rocky007]

je ne vois pas pourquoi avoir plus de 8 voies de ferais perdre la stéreo !

Parce que la stéréo se règle sur la voix, quand 2 samples(ou plus) sont sur la même voix(mixages de samples) si tu modifies la stéréo de la voix (le panning) ,ca va toucher tout les samples mixés dans la voix .
Donc si tu mixe le sample A avec le samples B, et que tu veux donner un effet sur le samples A par exemple, et le faire passer de droite à gauche, tu pourras plus, ou sinon tout les samples mixés avec A feront pareil .
Avoir un son stéréo veut dire pouvoir le sortir sur le HP de droite, de gauche ou les 2 .

mais cela ne change rien : imaginons que tu as 4 samples mixés sur chacune des 8 voies du Falcon, cela te fait bien 32 samples, et toujours 8 voies stereo.  idem pour les effets : si tu veux faire passer un sample de la voie 1 LEFT ( qui est composé de 4 samples mixés ) sur une voie RIGHT, suffit simplement que une des 4 voies RIGHT a un slot de libre pour ce sample.

je n'ai jamais vu une module qui utilise 32 voies même temps,

[Invité]

mais cela ne change rien : imaginons que tu as 4 samples mixés sur chacune des 8 voies du Falcon, cela te fait bien 32 samples, et toujours 8 voies stereo.

Justement non, comment veux tu donner des effets de stéréo à un sample en particulier, si tu en as 4 sur la même voix, ça peut pas marcher .

suffit simplement que une des 4 voies RIGHT a un slot de libre pour ce sample.

Oui, et comment tu fais si tu en as pas ??,le musicien doit se faire chier à savoir ce qui est utilisé de ce qu'il ne l'est pas quand il fait de la musique ??
de plus c'est aléatoire, tu sais pas comment le programme va réagir si 1 emplacement est dispo sur plusieurs voix,pour le musicos c'est ingérable.

je n'ai jamais vu une module qui utilise 32 voies même temps,

Sur Pc moi oui avec des modules IT (impulse tracker),et c'est déjà très gourmand sur une machine à plus de 100 mhz avec SB16,donc sur falcon ça m'étonne pas,c'est ce que je vous dis depuis le début,c'est pas parce que l'option existe que c'est faisable sur une machine de base,c'est comme le WB en hi-res.

[rocky007]

faut pas rigoler, avec 32 voies, suffit de laisser libre qq channel sur chaque voie, le soundtracker étant suffisamment malin pour savoir quelle voie est libre sur les 16 voies pour y appliquer un effet.

Jochen hippel se cassait bien plus la tête quand il composait !

[Invité]

faut pas rigoler, avec 32 voies, suffit de laisser libre qq channel sur chaque voie, le soundtracker étant suffisamment malin pour savoir quelle voie est libre sur les 16 voies pour y appliquer un effet.

Oui, mais alors on est plus sur 32 voix du coup .

Jochen hippel se cassait bien plus la tête quand il composait !

Oui, mais il codait aussi, la différence c'est le musicos de base qui compose sur un tracker, ne se fait pas chier avec les détails techniques .
Lui, il vaut pour faire ce qui est annoncé, CAD les 32 voix stéréos 16 bits 50 khz que tu annonces, et se rend compte que c'est du baratinage .
Au final je trouve que toi et guru aimaient enculer les mouches sur des détails qd c'est sur les machines de commodore, avec les ataris vous êtes bcp,bcp, plus conciliants .

[Meditating Guru]

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

En basse résolution, une scanline fait 512 cycles.
Un blit peut durer plusieurs alternances CPU/blitter, à la fin il peut juste rester 40 cycles à blitter: donc ce n'est pas un problème de "trop petit blit".  

 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 .

Bref, il y a concurrence et les détracteurs ont bien raison de l'appeler de la Slow au lieu de la Fast.

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

En plus. C'est la différence entre un architecture élaborée par un pro et un bricolage d'amateurs sous-payés.
"Wow mec, j'ai de la fast, j'utilise le blitter à donf."
... Guru Meditation ...

Des jeux contemporains utilisaient aussi l'overscan vertical.

Tout à fait. Et sur STF en plus. Encore une fois je ne critique pas les codeurs. je salue même le portage de pacmania (même si j'aurai préféré une version STF, quitte à ce qu'elle soit un peu moins bien). Simplement je m'amuse des commentaires qui pensent que cette version vaut celle du mig, alors qu'elle est impossible à égaler, même sur un STE

Inégalable pour le son 8bit et la fenêtre trop large. Au moins sur STF et STE, les proportions sont fidèles à l'arcade, et donc le gameplay est respecté. Sur Amiga, c'est n'importe quoi comme d'hab.

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.

Quand l'amiga se contente de résolutions du type de celles du ST ça ne lui arrive JAMAIS. Ils auraient pu faire pareil sur le ST avec un basculement à chaque cycle. Mais il est vrai que ce n'est pas aussi dramatique qu'on pourrait le croire, je l'ai bien précisé dans mes explications antérieures. Par contre sur un mega STE, c'est ridicule...

En même temps, le hiatus de vitesse CPU/chipset est apparu sur PC aussi, et le besoin de mémoire cache. Ca ne prouve donc aucunement que l'architecture du ST(E) était erronée.

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?

Je ne comprend pas... Mais les cycles sont à peu près identiques entre les 2 machines

Sur ST, il faut 16 cycles pour lire et afficher (fetch & shift) 16 pixels en basse résolution.
Le MMU lit un mot (16bit) de la mémoire video tous les 4 cycles, le transmet au Shifter, qui combine les plans. Avec 4 mots, on a 16 pixels sur 4 plans.
En moyenne résolution, le shifter combine 2 plans mais va deux fois plus vite, et 4 fois plus vite en monochrome (il tourne à 32mhz).
La vitesse d'affichage correspond au balayage du rayon cathodique.
D'après moi, tu dois faire x2 dans ton tableau pour parler en cycles CPU.

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!

Ah je comprend mieux la méprise : sur le mig la répartition des accès mémoire n'est pas concentrée dans un format qui se répète tous les 4 cycles. Elle se répartit sur toute la frame ! Heureusement car il y a 25 destinations possibles pour chaque accès mémoire dans le mig... Et cette répartition est dynamique : elle s'adapte au besoin. C'est bien pour ça que lorsque le cpu a besoin d'accéder à la chip, Agnus est capable d'interrompre le blitter pendant 1 cycle pour que le 68000 puisse faire son accès. Simplement il attendra 3 cycles pour le cas ou il n'y aurait que de la chip : ça permet de ne pas arreter le 68000 tout en évitant de trop ralentir le blitter (d'autant que le 68000 est loin de pouvoir accéder à la RAM à tous les cycles).
C'est bien cette façon de faire que j'aurai bien voir implémentée sur le blitter du STE. Vu que l'architecture ne le permet pas, ils auraient pu mettre un système qui arrete le blitter quand une interruption se déclenche (quitte à ce que ce soit le 68000 qui le relance). ça aurait évité bien des problèmes

Ca, c'est si on veut que l'interruption soit immédiatement servie. Je trouve le système du STE un bon compromis.

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 vrai mais ils auraient pu travailler en même temps ! Pour illustrer, je prend le pire des cas : Si un programme a besoin de faire des calculs pendant un blit, par exemple des divisions (jeu 3d ou le calcul des sommets se fait pendant que le blitter efface l'écran). Le fait d'interrompre le blitter quand le 68000 doit accéder à la mémoire pour lire la division qu'il doit faire ralentit le blitter d'un cycle : c'est pas très couteux. Par contre, la division se fera en interne du 68000 pendant 156 cycles. Il y a donc un gros gain à le faire comme ça par rapport à si on le fait à la suite ! Et beaucoup d'instructions 68000 prennent beaucoup de cycles même si 156 est un extreme.

Certains disaient à Rocky qu'il ne pouvait pas prendre ce cas limite...

En fait il y aurait un gain pour chaque instruction qui en prend au moins 2 : les instructions 68000 les plus simples (ADD, AND, OR, ...) en prennent 4. Et encore en 16 bits : en 32 c'est 6 (donc 8 pour le ST...). Tu vois le gain ?
Et si on ajoute à ça la possibilité d'avoir de la fast, on voit bien que le mig et le STE n'ont pas du tout la même intelligence de conception.

Je parle du STE et pas du STF. Car même si certains STF ont un blitter, ce n'est pas quelque chose qui était mis en avant. En tant que consommateur, si on me met un blitter sans me prévenir, je ne peux que me réjouir de ce qu'il apporte en plus. par contre si on me vend un STE en me parlant de son blitter qui est censé surpasser celui du mig, y a de quoi être énervé.

C'est ce que j'ai toujours dit ici : le STF t'en donnait pour ton argent. Le STE n'était qu'une esbrouffe...

Je crois qu'on est d'accord avec ce dernier point concernant le marketing. Si le STE était apparu à l'époque du STF, parfait. Mais venir avec ça si tard...

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.

Ca ne change pas grand chose. Au lieu de faire faire tout le travail du blitter puis du cpu, on fait une alternance sans exploiter le fait que le 68000 utilises plusieurs cycles pour ses instructions. C'est juste un léger mieux pour les interruptions.

Autrement dit, les interruptions sont servies sans problème.

Mais il y a une meilleure façon de faire : en demandant le traitement d'une ligne à la fois. Le blitter du STE utilise un compteur de ligne à traiter qui finit à 0 à la du blit. Il suffit de le remettre à 1 pour lancer la copie de la ligne suivante, il n'y a pas besoin de toucher aux autres registres. Grosso modo, faute d'une répartition de cycles dynamique, on confie cette tache au 68000. On peut aussi le faire en mode blit en manipulant le flag busy mais au prix d'un délai plus long en cas d'interruption (sauf pour des lignes très longues bien sur...). Un simple mode qui aurait attribué, par exemple, 4 cycles au blitter et 1 au 68000 aurait permis une meilleure parralélisation sans être incompatible avec l'architecture du ST puisque là aussi ça aurait été statique

Heureusement que tu ne travaillais pas chez Atari. On parlerait des bombes plus que des gurus.  

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

Oui plus rapide : 10 cycles au lieu de 12. Sauf que sur ST une instruction de 10 cycles en prend 12...
On gagne quand même en place mémoire. Mais à quel prix ? Impossible de choisir le bit à poser, et blocage de la mémoire pendant 5 cycles. là ou btst+bset la bloque pendant 2 cycles. Evidemment sur un ST ou aucune parralélisation est possible ce n'est pas grave (et c'est pour ça qu'elle est utilisable) mais sur le mig il y aurait une perte, ce serait stupide à utiliser pour gagner 2 octets sur le code source (et 2 cycles pour le cpu puisque sur le mig TAS prend 10 cycles)
Pas toujours bon de chercher à gagner de la mémoire : tu veux qu'on parle du LINE-F utilisé par l'OS du ST (et malheureusement par pleins de programmes...) et qui le rend incompatible avec une FPU ?

Sur ST, le jeu complet d'instruction du 68000 était utilisable.
Les FPU de Motorola ne valent pas grand chose, et puis ce serait une diversion d'en parler.
Mais c'est vrai, ils auraient du laisser la line F tranquille.

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.

Non ça je sait mais ce n'est pas de la parralélisation. Les interruptions seront gérées avec jusqu'à 256 cycles de retard ! Plus de la moitié d'une scaline sera passée avant même d'ajouter les quelques dizaines de cycles que met le 68000 à traiter une interruption ! Même pour un raster c'est bien trop long ! Mais c'est pas grave : tant que TAS fonctionne...

Moins d'une scanline de temps de réaction, c'est un délai acceptable pour la programmation normale. Si tu veux te synchroniser à l'affichage, il vaut mieux éviter les interruptions.

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...[/size]

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

Non le bricolage c'est l'ajout du blitter dans une architecture non prévue pour. La capacité d'attribuer les canaux DMA de façon dynamique est l'un des avantages du mig.

De façon anarchique.  

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.

Renseigne toi : pas vraiment... Et même quand ils sont fiables, votre TOS apporte les bugs qu'il faut pour tout gacher...
Tu penses qu'il n'y a pas de refresh ou de canaux DMA pour les HD et FD sur le mig ? LOL !!

Les bugs du TOS sont minimes. Les compagnies préféraient développer sur le ST, plus fiable, plus simple pour le HD.

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.

ça c'est de l'argument ! il ne reste que ça aux stistes ? revenir sur la console à disquette ? Quel ordinateur a un port cartouche mais pas de possibilité d'évolution ? Un OS incompatible 32 bits et fpu qui n'est qu'un hack dépassé du cp/m ? Auquel on a jouté une surcouche hyper lente pour gérer le fenêtrage ?
Qui possède les bugs les plus drole en matiere de gestion de disques ? Qui est écrit en faisant fi des recommandation de motorola pour gagner quelques octets en ROM ? Et que la majorité achetait pour jouer alors qu'il est moins bon qu'un C64 pour ça ?

Fanboy TRIGGERED  

Et non : la logique du jeu est gérée en fast. Donc elle peut être très évolué. Quand tu veux changer de son ou d'image, le programme n'a besoin que de manipuler des pointeurs et faire faire le boulot au chipset. Pendant ce temps il a tout pleins de cycles à utiliser en fast. Pourquoi veux-tu qu'il passe son temps en chip ?
Oui c'est ça une logique rudimentaire : The settlers gérait 64000 personnages simultanément avec un A500 sans fast... Mais comme c'est un jeu inaccessible au ST, tu ne peux pas comprendre...

J'ai joué à Settler, sur PC. Sur Amiga, c'était trop lent, comme le superbe Civilization. Rassure-toi, le jeu (Settler) n'en vaut pas la peine. Je n'ai pas tenu une heure.
En fait ici je taquine.    Pour Pinball Dreams (un des jeux que j'apprécie sur cette console à disquette - tiens, voilà à quoi sert le clavier, à émuler les boutons de flipper   ), par exemple, j'imagine qu'il y a pas mal de logique "hors chips" pour calculer la trajectoire de la bille...

A moins que les codeurs ST bien conscient qu'il ne fallait pas croire tout ce qui était affirmé sur les emballages et les manuels (les 4096 couleurs de Degas...) se soient dit : "ben non ça peut pas être un 16 bits, sur pleins de points le c64 est meilleur. Allons coder des kernels alors !" LOL !!!

En effet, c'est un 16/32bit. Le C64 est meilleur pour tenir ta tasse de café chaude, à part ça... pas trop regarder les graphiques.

[rocky007]

faut pas rigoler, avec 32 voies, suffit de laisser libre qq channel sur chaque voie, le soundtracker étant suffisamment malin pour savoir quelle voie est libre sur les 16 voies pour y appliquer un effet.

Oui, mais alors on est plus sur 32 voix du coup .

et sur amiga comment tu faisais peut être pour passer un sample d'un canal gauche à un canal droit avec un paning ?
ben tu es obligé de monopoliser 2 voies sur les 4

[dlfrsilver]

Oui mais je comparais sans fast ram, quand il faut tout partager (Amiga 500?).
Et dans ce cas, on ne peut bien sûr avoir CPU + Blitter + Shifter pendant l'affichage. 

Bah non justement sur amiga tout est prévu dés le départ, c'est pas du petit bonheur la chance,les perfs max sont avec de la fast .
Mais sans fast le blitter fonctionne pendant l'affichage, mais forcement pas au max .

C'est cela, oui. Comme les Amiga 500 avec de la vraie fast ram étaient super rares, les programmes... pardon, les jeux n'exploitaient pas cette possibilité.  

En mode Blit, les cycles sont partagés moitié moitié chaque scanline, donc le CPU ne va rien louper

Tu parles comme si le blitter et le CPU avaient toute la scanline, n'oublies pas qu'en plein affichage tu as peu de cycles dispos,donc oui tu peux rater des trucs,surtout avec des accès mémoire en 4 cycles ou plus .
N'oublies pas que rien que la prise d'interruption c'est 64 cycles sur 68k .

Non je dis juste que le CPU a la main chaque scanline, il ne reste pas bloqué pendant des siècles.
Mais partage des cycles il y a.

En pratique, il y a des demos "fullscreen" avec blitter.

En tout cas leonard dans sa dernière demo, a été obligé de faire des effets tout au CPU pour pas le bloquer avec le blitter .

A ma connaissance, lui aussi a fait des demos fullscreen avec blitter. Un cas n'est pas l'autre.

En parlant de Fast ram, l'Atari ST n'en avait pas :) Il utilisait de la ram Lenteeeeeeee 

[rocky007]

déjà revenu ? pffffff

[dlfrsilver]

Vous parlez de fast ram mais ça n'existe pas sur le falcon. Il s'agit de RAM reliée directement au proc. Pour utiliser cette RAM il faut un  programme adapté : l'OS ne sait pas l'attribuer.

pas du tout, certe sens strict, le TOS d'origine ne détecte pas la " TTRAM ", mais ce n'est qu'un faux problème un TOS modifié était livré avec la carte dans sa mémoire flash, ou simplement par un patch à mettre dans le repertoire AUTO selon le type de carte.  Donc pour l'utilisateur, c'est complétement transparent.  Idem avec Mint, dont les distributions adaptées existent.  Donc tous les softs compatible TT RAM fonctionnent sur Falcon en fastram.

Non seulement le TOS ne détecte pas la TTRAM mais, surtout, il ne la gère pas. La seule gestion, héritée du TT, consiste à mettre l'executable en Fast au moment de son chargement si le header du fichier exécutable a été correctement trafiqué. 
Par contre, une fois que ce dernier s'execute, à chaque fois qu'il demandera de la RAM à l'OS, celui-ci lui en attribuera en ST-RAM, c'est le seul moyen d'assurer une compatibilité ascendante. 
Sur le mig, à chaque demande de RAM, le programme demande à l'OS le type de RAM dont il a besoin. Ainsi un logiciel mig ne s'amusera jamais à stocker des variables, un buffer, une pile d'exécution, etc... en chip RAM alors qu'il dispose d'une RAM ultra rapide sur une carte 68060. Le Falcon si...
Sur le mig, le concept de fast est pensé DES LE DEPART et totalement intégré à l'OS. Sur le TT, il a fallu bricoler...

Et après on nous dit que c'est le mig qui est un bricolage...

Votre carte CT60 est exploitée comment par tous les logiciels PRO du falcon ou du ST ? Vous avez essayé ? Vous devriez : ça vous fera retomber sur terre...

Calamus tourne nickel avec sa version patchée. 

D'accord donc pour profiter d'un falcon avec carte accélératrice, il faut trouver un logiciel compatible Falcon, ça restreint déjà le choix... Et il faut qu'il soit patché (qui a dit bricolage ?) !
Et le patch, c'est juste ce qui permet à l'exécutable d'être chargé en fast, ça ne règle pas les problème d'allocation que j'évoque plus haut. Donc il sera loin d'exploiter une CT60...
Dis moi : un Cubase ça tourne correctement sur Facon ? Parce qu'un Bar & Pipes n'a aucun problème. et lui saura exploiter les cartes accélératrices installées...

Parlons en de cette carte : vous osez comparer une carte (enfin un hack...) sortie BIEN APRES la mort du Falcon (et inexploitée par 95% des logiciels compatibles avec cette machine) et équipée de SDRAM et d'un 68060 à 100Mhz avec des cartes CONTEMPORAINES (donc 60 Mhz et pas du tout la même RAM) au mig ?

encore une erreur de ta part : les cartes accélératrice embarquant TT RAM + Proc sont sortie à peine 1 ou 2 deux après la sortie du Falcon.
elles sont donc parfaitement contemporaine.  CT63/60 est l'ultime carte, mais il en existait bien d'autres.

Je parle de la CT60 car c'est elle qui est mise en avant systématiquement quand on parle de Falcon accéléré. Si on se restreint aux cartes contemporaines, le Falcon est à poil à coté du 1200 (qui avait des carte PowerPC CONTEMPORAINES à plus de 266 Mhz par exemple).

Et encore c'est pas fair play : il s'agit encore d'une carte contemporaine et pas la plus rapide. Et il s'agit d'un vrai jeu sorti il y a longtemps...

5 ans après la sortie du A1200, bref, il est sorti quand la machine était déjà morte et est tout à fait faisable sur un Falcon, tu devrais le savoir

Non : le jeu tourne sur une configuration qu'on pouvait se procurer en allant à la FNAC. Pas en achetant un Falcon, en attendant 10 ans qu'une carte assez rapide sorte et qu'on ait appris à l'installer (parce qu'il ne s'agit pas d'une carte qui s'enfiche dans un port dédié, il faut le rappeler...).

On pourrait prendre une carte vampire qui vaut la moitié du quart de votre CT60 aussi...

toi aussi tu vas utiliser l'argument tu prix .?  "c'est moins bien mais c'est moins cher donc c'est mieux"

Non tu m'as mal compris : une carte Vampire vaut une fraction du prix d'une CT60 TOUT EN ETANT PLUS PERFORMANTE !!!
Exemple : lecture d'une vidéo mpeg en haute résolution (640 pixels/ligne) en 24 bits qui n'utilise que 50% du processeur. Le falcon ne suit pas, meme avec une CT60 et un superVidel.
Au fait, cette lecture vidéo : c'est sur un simple A600 + vampire...
Donc tu comprendras qu'il vaut mieux oublier toutes les extensions et se restreindre aux machines d'origine. D'ailleurs en terme d'extension, un Facon ou un ST sont du même niveau qu'un A600 qui est le parent pauvre de la gamme de ce coté...

Le GPU du falcon est tellement bien que les démos TBL n'utilisent pas son mode chunky : une C2P avec le 68060 est plus performante... Trop ridicule ! Et la palette 24 bits ? Oubliée par atari ? Super les dégradés fins sur Falcon...

faudrait savoir, plus haut tu parles que la CT60 n'est pas une carte contemporaine et tu viens critiquer que Videl, qui lui est contemporain n'est pas assez puissant pour supporter cette accélération.  Si tu prend une CT60, tu prends la Super-Videl qui va avec.  Ce qui est vraiment ridicule par contre, est un Amiga de 1992, sorti à l'ère du CD qui est incapable de gérer la qualité CD.  ça oui c'est ridicule

Ah ok, pour avoir une palette de 24 bits il faudra attendre plus de 10 ans que le super Videl soit disponible...
Sur Amiga, tu pouvait avoir des cartes audio CONTEMPORAINES (encore une fois...) à ce compte là.

Note que pour l'Audio, et à condition de prendre un Falcon MK2, le Falcon est une super machine. Je n'ai aucun mal à le reconnaitre puisque, en tant qu'amigaiste, je ne suis pas obligé de me voiler la face :
Son DSP, même si c'est un principe auquel je ne croyais pas (pour Babsimov : espace mémoire, moins performant que les CPUs, surtout quand ceux-ci auront des jeux d'instructions étendus type MMX ou Altivec. D'ailleurs, aujourd'hui il n'y a plus de micro avec un DSP...) est une bonne idée. Et la limite de bande passante imposée par son bus 16 bits ne pose pas de problème pour traiter de l'audio.

Par contre au niveau affichage, une palette de 18 bits en 92, c'est insuffisant...

Vous critiquez le 680EC20 et son absence de MMU : Vous l'utilisez la MMU sur le facon ? Et par rapport au 68020, vous savez ce que provoque le EC ? Ben ça limite l'adressage à 16 Mo : Y a un interet a mettre plus de 16 Mo dans un A1200 non accéléré ? Parce que  vu le prix de la mémoire valait mieux mettre l'argent dans une carte (une vrai ! pas un hack qui oblige à perdre sa garantie...) accélératrice limité à 8 Mo...
D'ailleurs, votre Falcon dispose d'un  68030 complet mais qui est limité à 14 Mo par la machine... Encore une fois ridicule...

au moins sur Falcon, on avait le choix d'utiliser la MMU ou non, c'est n'était pas imposé comme sur le A1200.  et comme tu le dis toi même, quel intérêt à mettre plus de 14 Mo dans un Falcon non accéléré ?  Il valait mieux investir une vraie carte.  Garantie ?  sais-tu qu'à l'époque c'était 1 an de garantie.  Les cartes à base de 68040 ne sont sortie que bien après l'expiration de la garantie, aussi bien sur Amiga que sur Atari.  

Le choix oui mais vous l'utilisiez ? ben non... Y a une protection mémoire dans le TOS (protection qui necessite une MMU) ? ben non...
Oui je suis d'accord : aucun interet de mettre 14 Mo dans un Facon non accéléré (surtout qu'il n'y aurait pas de fast dans ces 14 mo...). C'était pour répondre à ceux qui critiquaient le fait que le 68020 du A1200 est un EC et ne gère donc que 16 Mo. Merci donc d'aller dans mon sens...
Non : il y avait des cartes 68040 pour le mig bien avant la fin de sa commercialisation , donc bien avant la fin de sa garantie (qui était de 2 ans sauf pour le lecteur de disquettes dans mon cas...)

Pour terminer sur le 1200. Un bon jeu commercialisé il y a 15 ans :

oui qui tourne sur un A1200 68040/25 + carte graphique bvision.  pas très intéressant sur le plan technique, mais intéressant comme jeu.

Non ça tourne très bien avec l'AGA. Cherche d'autres vidéo sur le tube. Tu sais bien sur qu'avec un 68040 la conversion C2P n'a aucun surcout ?...
C'était surtout pour dire que le 1200 a eu droit a des tas de jeux commerciaux qui exploitent les cartes accélératrice, voire PowerPC.

@stapha92 a écrit:
Vous expliquez tranquillement que le Facon avec son DSP c'est 512 sprites de 16x16 en truecolor et ça devient le dieu de la 2D. Ok calculons : 

un sprite en  16x16 = 256 pixels. en true colors (2 octets par pixels) ça fait 512 octets. Donc ça 512 octets x 512 sprites = 256 Ko à lire + 256 Ko à écrire par frame. Au total 512 Ko. Avec 50 i/s ça fait 25 Mo/s. Regardez les chiffres postés par Rocky007 : c'est  4 à 5 fois plus que ce qu'il est possible d'obtenir avec la ST-RAM ! Faut garder les pieds sur terre...

...et pourtant c'est une réalité. Il est vraiment jouable sur mon Falcon030 (et en 31KHz de surcroit). J'ai même réussi à le terminer une (seule) fois.

Et que puis-je te dire ? Faire comme Galilée et dire "Et pourtant elle est ronde" ?
Il ne peut y avoir autant de sprites à 50 i/s, c'est juste IMPOSSIBLE.

Bon, je pense qu'on devrait oublier le Falcon et le 1200. De toute façon les ataristes n'ont pas acheté de Falcon, comme tout le monde. Inutile donc d'en parler...

Mais si ça intéresse quelqu'un, voici une analyse du super bus du Falcon effectuée par quelqu'un qui maitrise la machine :

https://mikro.naprvyraz.sk/docs/mikro/030_stram.html

C'est clair : super bien pensée...

C'est pas ce qu'on a lu ici, le blitter du ST bloquait le processeur quand il était utilisé. Atari conseillait même de ne l'utiliser que pour de tous petits traitements et surtout pas tout à la suite, sinon le processeur ne peut plus travailler. Quelle conception géniale... Mais, en fait, c'est normal, le ST n'a pas été pensé pour avoir des coprocesseurs. Ils ont mis le blitter parce que ça faisait bien sur le papier et parce que tout le monde en voulait parce que l'Amiga en avait un.

faux, tu as deux mode : travailler seul ou en cooperatif avec le CPU.  il n'y a pas de question, il accéléré l'affichage.  de nombreux jeux ou demo l'utilise pour les sprites etc..correctement programmé, il peut fonctionner en // avec le CPU, tout dépend du code 68000 ( toutes les instructions qui n'accèdent pas au bus ).  à t'entendre il ne fait que ralentir l'ordinateur quand on l'utilise.

C'est bien ce que j'ai lu ici, même Atari conseillait de ne pas trop l'utiliser pour que le processeur ait un peu de temps. Je pense même me souvenir que c'était dans une interview ou une citation de Shiraz Shijvi en personne qui disait que le blitter bloque le CPU.

apparemment même quand on t'explique, tu ne comprends pas.  je t'explique que le blitter Atari a une mode coopératif avec le CPU.  tout dépend comment tu l'emploies.

évidement dans un fullscreen qui doit être synchro au cycle près, c'est une autre histoire.... 
le CPU peut exécuter une instruction n'utilisant pas le bus en même temps que le blitter, ok c'est assez limité je l'admet, mais pendant ce moment il fonctionne en // avec le CPU !

Apparemment c'est toi qui ne comprends pas : le 68000 NE PEUT PAS fonctionner en même temps que le blitter. J'ai déjà expliqué ça ici. Tu n'es pas au courant que TOUTES les instructions d'un 68000 utilisent le bus ? ben oui, avant d'executer une instruction, le 68000 doit la lire, non ? et comment peut-il le faire sans utiliser le bus ?

Va lire la doc Atari et tu verras ce qu'ils préconisaient : faire des blits ligne à ligne afin de permettre au 68000 de répondre aux interruptions avec un décalage pas trop grand ! Juste ridicule !!!
Parce que oui : quand le blitter tourne le 68000 ne peut même pas repondre aux interruptions. Fais une interruption pour faire un raster (hyper classique dans les jeux ST) et ajoute après une copie de bloc avec le blitter et admire le résultat sur ta machine de rêve...

Du coup tu sais pourquoi ton ST ne chauffait pas assez : le 68000 était souvent à l'arret...

oui, il aura fallu 12 années pour arriver à programmer correctement un amiga...c'est long.

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

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

10 ? Hmmm... Heureusement qu'il y a longtemps que j'ai compris que tu n'avais pas eu d'Amiga à l'époque sinon j'aurai des doutes sur tes capacités cognitives...

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

Quand à dire que le 68030 va plus vite que le blitter, vous êtes 2 à l'avoir affirmé mais, vous appuyez cette déclaration sur quoi ? Faites une copie de bloc avec masquage et décalage de quelques bits (en gros  : simuler un sprite) avec un 68030 et un blitter et comparez : vous réaliserez que vous êtes à coté de la plaque.

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

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

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

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

je t'ai déjà expliqué pas tout à fait vrai :

It might often not be possible to organize CPU code around BLiTTER
operations, but if you do, you might gain a lot of speed by placing
the right instructions directly in front of a BLiTTER operation.
As the BLiTTER might require a couple of cycles before actually doing
anything, the CPU usually has a chance of loading the next instruction
before the BLiTTER hogs the bus. If this instruction requires no
additional bus access, it will be carried out _in parallel_ to the
BLiTTER operation, making the Atari ST/STE a dual-processor system
for this short period.

C'est juste ridicule : le 68000 peut  charger une instruction après avoir lancé le blitter parce celui-ci met quelques cycles à se lancer... Et si cette instruction ne fait pas d'accès mémoire elle pourra s'executer...
Génial, le 68000 peut, parfois, effectuer 1 instruction pendant que le blitter tourne.
Continuer à vous voiler la face, ça nous fait rire ;-)

le DSP ne peut pas compenser une sortie sonore limité.  Si la srotie est en 28Khz, tu ne pourras jamais avoir de la qualité CD, même avec un DSP.

C'est faux  
Paula est limitée à 28khz ,parce que le DMA n'alimente le(s) DAC au mieux qu'a cette fréquence .
En mode manuel, tu peux monter à bcp plus, regarde le 1200, il peut faire du 56khz .
Plus tu montes en fréquences, plus tu as besoin d'accès à la ram(donc de cylces DMA) .
Tu comprends donc pk les 50khz du falcon/STE c'est du gros n'importe quoi,et pk les consoles 32 bits ont une mémoire dédiée aux samples/sons .

Et tu comprends aussi qu'une puce PCM 8 bits c'est pas si mal, car le DMA envoie 16 bits/accès donc tu as 2 samples pour 1 accès .

C'est encore pire que ça touko. 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...

Putain faut arrêter maintenant, je vais finir par prendre 50 kilos d'un coup à force de bouffer du pop-corn. 

Des barres de rires   !!! Y a des gens y prennent des tours de manèges gratuit ahahah PTDR !

[dlfrsilver]

déjà revenu ? pffffff

Je reviens TOUJOURS   !

"IL" est revenu   !

[rocky007]

vas-y, mets en citations 50 pages pour commenter juste 1 phrase

[dlfrsilver]

je me permets de remettre la video


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

Merci mais purée c'est atroce. T'achète un micro qui fait du 50khz, et à l'utilisation, le CPU explose juste pour lire un pauv' fichier MOD. L'Arnaque totale !

[dlfrsilver]

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 :

Bravo !! 2 superbes adaptations de jeux de merde venant de l'Atari ST, quel miracleeee 

[rocky007]

désolé pour toi, le magnifique jeux Sony Game avec son superbe scrolling est pur jus amiga et le Hotball est plus rapide sur ST, !

[dlfrsilver]

désolé pour toi, le magnifique jeux Sony Game avec son superbe scrolling est pur jus amiga !

On se rassure comme on peut hein ?   

Allez va, j'te l'accorde, c'est un jeu amiga du domaine publique. Mais il a le bon gout et la délicieuse odeur d'un popo fait sur Atari 

[rocky007]

et voilà tu te recommence avec tes références scato..c plus fort que toi

mais tu ne m'avais pas répondu : pourquoi critiques tant d'atari, alors que tu en collectionne tellement que tu en as plus que d'amiga...

[dlfrsilver]

et voilà tu te recommence avec tes références scato..c plus fort que toi

mais tu ne m'avais pas répondu : pourquoi critiques tant d'atari, alors que tu en collectionne tellement que tu en as plus que d'amiga...

Je m'appuie sur mes références atari 

"Parce que critiquer l'Atari, c'est bon et c'est sain, tandis que l'inverse pose question"

Ainsi parlait "Motorolière", le célèbre "processeur de théatre" qui équipe l'Atari  ! 

Tu sais, celui qui jouait avec aisance "les précieuses applications ridicules", le "malade de la puissance CPU imaginaire", "L'avare des prouesses graphiques",  "L'imposteur du son et le tartuffe des ordis"  

 

ahahahahaha 

[rocky007]

wow, comme c'est rigolo, ça doit être la fête à Noël avec un tel humour

[Invité]

et sur amiga comment tu faisais peut être pour passer un sample d'un canal gauche à un canal droit avec un paning ?
ben tu es obligé de monopoliser 2 voies sur les 4

Oui, mais les musiques n'étaient soient plus en 4 voix, soit le musicien se débrouillait, mais quand tu restes dans le domaine des 4 voix ou 8 sur falcon c'est jouable sans soucis, avec 32 mixées en soft c'est difficilement faisable .

[Urbinou]

mais tu ne m'avais pas répondu : pourquoi critiques tant d'atari, alors que tu en collectionne tellement que tu en as plus que d'amiga...

Probablement pour collectionner toutes les révisions de carte-mère (avec et sans sparadrap, avec et sans rustine, avec et sans pseudo-blitter...)
Ou bien parce qu'il faut une dizaine de ST pour en faire un qui fonctionne à moitié ?

[dlfrsilver]

mais tu ne m'avais pas répondu : pourquoi critiques tant d'atari, alors que tu en collectionne tellement que tu en as plus que d'amiga...

Probablement pour collectionner toutes les révisions de carte-mère (avec et sans sparadrap, avec et sans rustine, avec et sans pseudo-blitter...)
Ou bien parce qu'il faut une dizaine de ST pour en faire un qui fonctionne à moitié ?

Mr Urbinou, +1 ! 

effectivement, il faut un data center d'Atari STs, tous connectés les uns aux autres pour en avoir 1 qui marche  

ahahaha

[Zarnal]

Perso j'ai mon 1200 de 92 et une CM neuve pour pièces. Si ça claque tant pis il restera winuae.  

Quant au 1040ste récupéré en 2013 à mon ancien boulot en loose et sans cable et bien dégueu, il n'a pas tenu 1 semaine dans le placard grâce à un ko....d collègue qui l'a confondu avec un clavier pour PC.

[rocky007]

et sur amiga comment tu faisais peut être pour passer un sample d'un canal gauche à un canal droit avec un paning ?
ben tu es obligé de monopoliser 2 voies sur les 4

Oui, mais les musiques n'étaient soient plus en 4 voix, soit le musicien se débrouillait, mais quand tu restes dans le domaine des 4 voix ou 8 sur falcon c'est jouable sans soucis, avec 32 mixées en soft c'est difficilement faisable .

je ne vois aucune différence : que le musicien doit composer ses effets avec 4 voies ou 32 voies, il doit de toute façon se débrouiller pour réserver une voie libre s'il veut faire du paning.
pour le musicien, le mixage des voies est complétement transparent, il a doit 16 voies gauche et 16 voies droite et il fait ce qu'il a envie, exactement comme quand tu as 2 voies gauche et 2 voies droite.  Le fait que le volume soit hardware ou software ne change strictement rien au problème, tu doit doubler le sample sur les deux voies pour cet effet.

[rocky007]

Perso j'ai mon 1200 de 92 et une CM neuve pour pièces. Si ça claque tant pis il restera winuae.  

Quant au 1040ste récupéré en 2013 à mon ancien boulot en loose et sans cable et bien dégueu, il n'a pas tenu 1 semaine dans le placard grâce à un ko....d collègue qui l'a confondu avec un clavier pour PC.

et voilà, encore la preuve... les amiga ça se trouve dans les vides grenier de jouets , les Atari, ça se trouve dans les boîtes pro.

[stapha92]

Des jeux contemporains utilisaient aussi l'overscan vertical.

Tout à fait. Et sur STF en plus. Encore une fois je ne critique pas les codeurs. je salue même le portage de pacmania (même si j'aurai préféré une version STF, quitte à ce qu'elle soit un peu moins bien). Simplement je m'amuse des commentaires qui pensent que cette version vaut celle du mig, alors qu'elle est impossible à égaler, même sur un STE

Inégalable pour le son 8bit et la fenêtre trop large. Au moins sur STF et STE, les proportions sont fidèles à l'arcade, et donc le gameplay est respecté. Sur Amiga, c'est n'importe quoi comme d'hab.

Quel répartie... A court d'argument ?

Oui c'est sur si la proportion est respectée, il est clair que ça compense les saccades, le son de merde, et la palette hyper réduite...


Comme souvent, le ST se fait exploser par le C64...

Au fait l'overscan qui fait grésiller le moniteur (certains n'ont pas résisté...), c'est pas du bricolage ça ?

Quand l'amiga se contente de résolutions du type de celles du ST ça ne lui arrive JAMAIS. Ils auraient pu faire pareil sur le ST avec un basculement à chaque cycle. Mais il est vrai que ce n'est pas aussi dramatique qu'on pourrait le croire, je l'ai bien précisé dans mes explications antérieures. Par contre sur un mega STE, c'est ridicule...

En même temps, le hiatus de vitesse CPU/chipset est apparu sur PC aussi, et le besoin de mémoire cache. Ca ne prouve donc aucunement que l'architecture du ST(E) était erronée.

Ah bon ? Tu dis encore n'importe quoi : sur un PC, la mémoire principale n'est pas partagée entre le cpu et un chipset. Et si : l'architecture du ST(E) qui implique que TOUTE la mémoire visible par le cpu subit des ralentissement inutiles montre bien les défauts de conception initiaux...

Ah je comprend mieux la méprise : sur le mig la répartition des accès mémoire n'est pas concentrée dans un format qui se répète tous les 4 cycles. Elle se répartit sur toute la frame ! Heureusement car il y a 25 destinations possibles pour chaque accès mémoire dans le mig... Et cette répartition est dynamique : elle s'adapte au besoin. C'est bien pour ça que lorsque le cpu a besoin d'accéder à la chip, Agnus est capable d'interrompre le blitter pendant 1 cycle pour que le 68000 puisse faire son accès. Simplement il attendra 3 cycles pour le cas ou il n'y aurait que de la chip : ça permet de ne pas arreter le 68000 tout en évitant de trop ralentir le blitter (d'autant que le 68000 est loin de pouvoir accéder à la RAM à tous les cycles).
C'est bien cette façon de faire que j'aurai bien voir implémentée sur le blitter du STE. Vu que l'architecture ne le permet pas, ils auraient pu mettre un système qui arrete le blitter quand une interruption se déclenche (quitte à ce que ce soit le 68000 qui le relance). ça aurait évité bien des problèmes

Ca, c'est si on veut que l'interruption soit immédiatement servie. Je trouve le système du STE un bon compromis.

En même temps tu trouves que le ST est mieux qu'un mig, donc...

Bien sur qu'on veut que ce soit immédiatement servi : c'est le principe des interruptions !

C'est vrai mais ils auraient pu travailler en même temps ! Pour illustrer, je prend le pire des cas : Si un programme a besoin de faire des calculs pendant un blit, par exemple des divisions (jeu 3d ou le calcul des sommets se fait pendant que le blitter efface l'écran). Le fait d'interrompre le blitter quand le 68000 doit accéder à la mémoire pour lire la division qu'il doit faire ralentit le blitter d'un cycle : c'est pas très couteux. Par contre, la division se fera en interne du 68000 pendant 156 cycles. Il y a donc un gros gain à le faire comme ça par rapport à si on le fait à la suite ! Et beaucoup d'instructions 68000 prennent beaucoup de cycles même si 156 est un extreme.

Certains disaient à Rocky qu'il ne pouvait pas prendre ce cas limite... 

Quel répartie... A court d'argument ?

N'ai-je pas dit que c'était un cas extreme ? Les instructions 68000 durent 8 cycles en moyenne. ça suffit largement à rendre le parallélisme bénéfique...

Ca ne change pas grand chose. Au lieu de faire faire tout le travail du blitter puis du cpu, on fait une alternance sans exploiter le fait que le 68000 utilises plusieurs cycles pour ses instructions. C'est juste un léger mieux pour les interruptions. 

Autrement dit, les interruptions sont servies sans problème.

Des interruptions traitées avec 1/2 scanline de retard correspond à "sans problème" dans le monde ST ? Même le fanboyisme le plus extreme n'explique pas ça...

Heureusement que tu ne travaillais pas chez Atari. On parlerait des bombes plus que des gurus.   

Quel répartie... A court d'argument ?

Tu passes aux attaques personnelles maintenant ?
 1 : Il y avait plus de bombes que de guru. En plus : c'est quoi ce truc sérieusement !! Des bombes pour indiquer un plantage ! Pratiquement aucune info ! là ou le guru en donne plein et offre la possibilité en se connectant au port série du mig d'executer un debugger. Même quand il plante, le mig le fait plus intelligemment qu'un ST. Et c'est pour ça que le Guru est plus connu. Le mig plantait moins : tu le saurais si tu avais vraiment eu un mig. Tu peux prétendre le contraire mais il est évident que c'est faux.

 2 : La méthode que je donne n'est pas de moi : elle est recommandé par des codeurs confirmés sur ST. En plus elle evite les plantages en cas d'appel d'une fonction de l'OS pendant que le cpu a la main. (fait un line A sur ST pendant les cycles cpu qu'on rigole...)

 3 : Lis la doc d'Atari sur le blitter : des erreurs énormes. Par exemple il font un bset pour tester l'état du blitter. Trop drole ! Et ils mettront plusieurs années pour corriger ! Et il y en a pleins comme ça dans les doc Atari. Trouve moi un truc du genre dans le HRM : tu vas avoir du mal...

Le rédacteur est le seul logiciel que je connaisse ou ils ont essayé d'implanter à la énième version un système qui essaye de sauvegarder le document automatiquement en cas de plantage (avec un taux de réussite très faible...) parce qu'ils ne sont jamais parvenus à éliminer ces plantages. Et je ne parle pas d'un DP mais du logiciel de PAO que vous n’arrêtez pas de mettre en avant ! Encore une fois : trop ridicule le ST ! LOL !!!

Tu sembles croire que c'était des bons chez Atari. Ben non : à cause de tramiel, il n'y a plus personne. S'ils avaient confié la rédaction de leur doc à un stagiaire, elle aurait contenu moins d'erreurs...

Sur ST, le jeu complet d'instruction du 68000 était utilisable.
Les FPU de Motorola ne valent pas grand chose, et puis ce serait une diversion d'en parler.
Mais c'est vrai, ils auraient du laisser la line F tranquille. 

Le jeu complet et même plus : on pouvait utiliser des instructions qui n'existent pas (LINE A aussi...) ! Tout ça pour gagner quelques octets et faire des economies sur la taille de la rom... C'est juste ridicule...
Sur le mig aussi on pouvait tout utiliser je te rassure...
Oui c'est ça : une diversion... Vous n'arretez pas de nous dire que le ST était un vrai ordinateur mais quand on vous montre les lacunes de son OS et de son architecture vous nous dites que c'est hors sujet...

Moins d'une scanline de temps de réaction, c'est un délai acceptable pour la programmation normale. Si tu veux te synchroniser à l'affichage, il vaut mieux éviter les interruptions. 

Oui ça rend juste les interruptions qui se font à la ligne inutilisables... Adieu les raster... mais c'est vrai qu'avec ses 16 couleurs simultanées en basse résolution, le ST reproduit la totalité du spectre lumineux !

Merci pour la leçon ! Mais tu peux me dire pourquoi il vaut mieux eviter les interruptions ? Pour faire du code quasi-inutilisable dans les jeux ou les applications ? Ou du code incompatible avec d'autres machines que le ST de base ? Ou parce qu'il ne faut pas sortir des techniques 8 bits ?

Y a des centaines de jeu STF qui utilisent des rasters... Créés avec des interruptions...
Je n'ose même pas aborder les autres cas d'interruptions non synchro avec l'affichage mais qu'1/2 ligne de décalage rend inutilisables...

Non le bricolage c'est l'ajout du blitter dans une architecture non prévue pour. La capacité d'attribuer les canaux DMA de façon dynamique est l'un des avantages du mig.

De façon anarchique.   

Quel répartie... A court d'argument ?

Continue à le répéter. ça deviendra peut-être vrai.

Les bugs du TOS sont minimes. Les compagnies préféraient développer sur le ST, plus fiable, plus simple pour le HD.

Minimes ? Tu ne sais pas de quoi tu parles...

Deux affirmations sorties de nulle part et non étayées. Les compagnies ont développé plus de logiciels et de jeux sur le mig que sur le ST. Le mig possède bien plus de langages. Donc tes affirmations...

 Le HD plus fiable et plus simple grace au bug du TOS qui fait qu'il peut charger plus de données que ce qu'on lui a demandé et déborder du buffer alloué (bonjour les bombes) ?
 Le HD plus fiable et plus simple grace à la limite de 40 répertoires pour toutes les partitions ?
 Le HD plus fiable et plus simple grace à l'impossibilité pendant longtemps de déplacer un fichier ou de renommer un répertoire même par programmation ?
 Le HD plus fiable et plus simple grace au bug sur le bit d'archive ?
 Le HD plus fiable et plus simple grace à l'imprécision des dates de fichier ?
 Le HD plus fiable et plus simple grace à la pauvreté des attibuts de fichier ?
 Le HD plus fiable et plus simple grace au noms courts des fichiers et encore plus court (une lettre !) des partitions ?
 Le HD plus fiable et plus simple grace à l'impossibilité pour le TOS d'assigner un répertoire ?
 Etc...

En effet, c'est un 16/32bit. Le C64 est meilleur pour tenir ta tasse de café chaude, à part ça... pas trop regarder les graphiques.

Peut-être mais au niveau son et animation, il explose un ST...

[stapha92]

Je reviens sur la documentation Atari. Voici un extrait d'une doc sur le blitter rédigée par des expert du ST :

      If an interrupt service however cannot be completed in 64 cycles
      and should not be stalled by the BLiTTER again, Atari states that
      it is possible to "stall" the BLiTTER by writing Bit 7 to zero -
      But Atari points out in the official documentation that it needs
      to be set to the original state before end-of-interrupt is reached:
      
        move.b  $FFFF8A3C.w,-(sp)     ; Write register to stack
        bclr.b  #7,$FFFF8A3C.w        ; unset busy bit
        nop                           ; BLiTTER might interfere here
        
       
        
        move.b (sp)+,$FFFF8A3C.w      ; restore original register
        
      Unfortunately, this does not work at all and is not mentioned in
      other documentation regarding the BLiTTER i have read so far.
      This seems to origin from the internal state handling. The CPU
      reads a "1" in the BLiT-busy bit when reading out the register,
      even though internally it is a "0" because the BLiTTER is pausing
      for 64 cycles. Writing through a "0" will not have any effect and
      not stop the internal state handler to set it back to "1" internally
      after 64 cycles. The BLiTTER will only write a "0" if it is done
      copying data (i.e. the line counter turns "0"). There does not seem
      to be any other way of stalling the BLiTTER on request.

Donc on nous explique que la méthode donnée par Atari pour arrêter le blitter dans le cas ou on veut s'assurer que le traitement d'une interruption parviendra à aller jusqu'au bout ne marche pas ! Pire, il s'avère qu'il est impossible d’empêcher le blitter de repartir ! 

Un stagiaire aurait fait mieux je vous dit !

Après ça, ces expert donnent une autre façon de faire qui, elle, fonctionne totalement et est plus efficace (surtout dans le cas de petites lignes).  C'est celle qui a été raillée par Guru (c'est dans cette doc que je l'avais lu). En ce moquant de moi, il a raillé le travail d'un groupe ST qui a fait du super boulot... 

A part ça le ST était un ordinateur pro et était préféré pour le développement ...

[dlfrsilver]

Je reviens sur la documentation Atari. Voici un extrait d'une doc sur le blitter rédigée par des expert du ST :

      If an interrupt service however cannot be completed in 64 cycles
      and should not be stalled by the BLiTTER again, Atari states that
      it is possible to "stall" the BLiTTER by writing Bit 7 to zero -
      But Atari points out in the official documentation that it needs
      to be set to the original state before end-of-interrupt is reached:
      
        move.b  $FFFF8A3C.w,-(sp)     ; Write register to stack
        bclr.b  #7,$FFFF8A3C.w        ; unset busy bit
        nop                           ; BLiTTER might interfere here
        
       
        
        move.b (sp)+,$FFFF8A3C.w      ; restore original register
        
      Unfortunately, this does not work at all and is not mentioned in
      other documentation regarding the BLiTTER i have read so far.
      This seems to origin from the internal state handling. The CPU
      reads a "1" in the BLiT-busy bit when reading out the register,
      even though internally it is a "0" because the BLiTTER is pausing
      for 64 cycles. Writing through a "0" will not have any effect and
      not stop the internal state handler to set it back to "1" internally
      after 64 cycles. The BLiTTER will only write a "0" if it is done
      copying data (i.e. the line counter turns "0"). There does not seem
      to be any other way of stalling the BLiTTER on request.

Donc on nous explique que la méthode donnée par Atari pour arrêter le blitter dans le cas ou on veut s'assurer que le traitement d'une interruption parviendra à aller jusqu'au bout ne marche pas ! Pire, il s'avère qu'il est impossible d’empêcher le blitter de repartir ! 

Un stagiaire aurait fait mieux je vous dit !

Après ça, ces expert donnent une autre façon de faire qui, elle, fonctionne totalement et est plus efficace (surtout dans le cas de petites lignes).  C'est celle qui a été raillée par Guru (c'est dans cette doc que je l'avais lu). En ce moquant de moi, il a raillé le travail d'un groupe ST qui a fait du super boulot... 

A part ça le ST était un ordinateur pro et était préféré pour le développement ...

Hé oui, je finis par croire que même les forçats du ST chez les codeurs c'étaient des fanboys..... J'en sais clairement pas autant que toi, et ce que tu expliques pose clairement les choses. 

Finalement, les atarists cherchent à défendre l'indéfendable..... Tiens histoire de te faire ricaner un peu (histoire que ça ne soit pas toujours nous rigolions de ce que tu écris tellement ça met des baffes  ), j'ai appris dernièrement qu'il y a toujours un problème entre les STE et l'utilisation d'ultrasatan, c'est tellement bancal que ça mérite d'être relevé :

il apparait que les alims des Atari ne sont pas assez balaise pour l'écriture sur carte SD, ça participe à la corruption des données (lol), sans parler des condos de mauvaise qualité utilisés sur la majorité des Alims.....

quand j'aurais un peu plus de thune, je ferais des tests avec mon propre matériel ST afin d'aider le copain électronicien de métier qui s'arrache les cheveux sur le sujet......