GUERRE ST-AMIGA, FIGHT !!!

rocky007 a écrit:
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...

stapha92 a écrit:

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 ?

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

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

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

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

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

Pour terminer, il semblerait que le Blitter ST ne soit pas si mauvais que cela en perfs pure, étant plus rapide dans certains cas, et moins rapide dans d'autres.  Dans l'affichage de sprite, l'amiga ne l'emporte qu'avec 5% de plus !

Edit:

Some numbers: in general the Amiga Blitter is exactly two times faster in clock cycles for each memory operation. So the "cookie cut" method uses a total of 8 cycles. Compared to the new blitting method above this speed can only be achieved on the Atari on sprite areas where the ENDMASK is $ffff. 

Sprites 32x32 4bitplanes without clearing:
- Atari: 40064 / 1344 = 29,8
- amiga 320x256 5 bitplanes: 44512/ 1280 = 34,8 (is 16% faster than ST)
- amiga 320x200 4 bitplanes: 54112 / 1280 = 42,3 (is 41% faster than ST)

Sprites 32x32 4bitplanes with clearing:
- Atari: 40064 / 1728 = 23,2
- amiga 320x256 5 bitplanes: 44512/ 1728 = 25,8 (is 11% faster than ST)
- amiga 320x200 4 bitplanes: 54112 / 1728 = 31,3 (is 35% faster than ST)

stapha92 a écrit: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 ...

oui comme indiqué dans mon post si tu l'avais lu correctement, je ne parlais de des perfs pure du blitter 

mais je te remercie de m'apprendre que l'amiga avec ses sprite hardware est plus balèse que le ST sans sprite hardware.

Dans l'affichage de sprite, l'amiga ne l'emporte qu'avec 5% de plus !

rocky007 a écrit:tiens, un jeu Thalion que je ne connaissais pas , et on dirait qu'il rame sur amiga ( 6:24 ) VS ( 5:42 ) sur ST :

Dans l'affichage de sprite, l'amiga ne l'emporte qu'avec 5% de plus !

Si ça c'est explicite, bah dis donc ..  
Moi j'interprète ça comme :
Si on fait un jeu sur les 2 machines, l'amiga n'affichera que 5% de sprites en plus .

je parle donc bien uniquement et seulement du blitter, alors n'invente pas des propos qui n'existent pas. Si on parle des perfs du blitter seul, je vois pas pourquoi je devrais prendre en compte le copper, le paula, et tout la clique...  c'est ridicule

Meditating Guru a écrit:

rocky007 a écrit:tiens, un jeu Thalion que je ne connaissais pas , et on dirait qu'il rame sur amiga ( 6:24 ) VS ( 5:42 ) sur ST :

En effet, quelle bouse!

rocky007 a écrit:Dlfrsilver : décidément tu dois vraiment avoir un problème avec l'informatique, nous sommes plusieurs icic à avoir un ultrasatan sur Ste, sans le moindre problème.

Et désolé si en 1985 Atari n'avait pas prévu l'utilisation de carte SD, quelle bande d'idiots !

Stapha : oui tu as raison, tous les codeurs qui préfèrent coder sur ST sont juste cons, aveugle et débiles.  Pourquoi perdre son temps sur ST alors qu'il y a le superbe Amiga.

Ta comparaison avec le C64 est juste ridicule, je ne pensais pas lire une telle énormité venant de toi.  Montres nous donc des logiciels comme Vroom, Wings of Death, Cubase, Calamus sur un C64 !  et des jeux plus moches sur amiga que sur C64, il y en a des tonnes, il suffit de voir les vidéos que j'ai postées ci dessus.

Tu as aussi bien facile de critiquer les bugs de l'atari... c'est vrai que la limitation à 40 répertoires, c'est un manque de fiabilité...

à ce compte, le manque de mode lasso est un manque de fiabilité aussi sur l'amiga.

c'est très décevant de ta part, que je me permette d'être un trolleur assumé, c'est une chose, mais un être si pur que toi, non, ça je ne te tolère pas.

Car évidement tu ne parles jamais des bugs amiga, comme par exemple l'impossibilité de booter sur HD,

de mettre un HD supérieur à 40mb,

de l’impossibilité d'avoir un directory sous WB,

de la lenteur des accès disque,

etc..etc...  affirmer tout le temps des éléments à charge, c'est un manque totale neutralité, serais-tu donc un fanboy aussi ?

Le ST n'est certes pas un joyaux d'ingénierie, mais cela n'enlève en rien ses qualités.

Pour rappel, il se positionnait comme concurrent au Macintosh pas à une megadrive.
Reproche-t-on à Macintosh le fait qu'il n'a pas de scrolling hardware ?  Et ce sont pas les millions d'utilisateurs qui diront le contraire.  et ces millions d'utilisateurs n'ont rien à foutre qu'un cycle par ci par là est perdu, au quotidien c'était une machine fiable et puissante.

Pour terminer, il semblerait que le Blitter ST ne soit pas si mauvais que cela en perfs pure, étant plus rapide dans certains cas, et moins rapide dans d'autres.  Dans l'affichage de sprite, l'amiga ne l'emporte qu'avec 5% de plus !

rocky007 a écrit:tiens, un jeu Thalion que je ne connaissais pas , et on dirait qu'il rame sur amiga ( 6:24 ) VS ( 5:42 ) sur ST :

Meditating Guru a écrit:

Il s'intéresse plus aux vrais ordinateurs qu'aux consoles à disquette, c'est compréhensible.

Oui à l'Amiga. J'ai toujours besoin de consoles, c'est pour ça que je garde mes STs. Sous consoles sous pas chères sous capables sous productives 

stapha92 a écrit:

"Exploser"... quel langage agressif. 
Le fait est que sur ST, les proportions sont respectées, la musique ne casse pas les oreilles, les graphiques sont plaisants, sans couleurs baveuses. C'est un bon jeu, ne vous déplaise. Et sur STE, c'est magnifique.

Meuh non c'est pas agressif, c'est juste la réalité. Ennuyeux la réalité  .

Sur ST y a rien de respecté, ni la vitesse, ni la musique à cause du cable pourri de la puce dans le hardware de la machine.... Ah tout les ingés ne valent pas ceux de chez Amstrad, qui eux ont fait le boulot correctement (le YM sonne correctement, et sans grésiller, et en stéréo !).

L'overscan ne fait pas grésiller mon moniteur, mais il est clair que cette technique n'était pas prévue par Atari, elle a été inventée par la scène très imaginative du ST.

Imaginative d'accord. Mais l'overscan, au secours sur ST...... 

Tu cherches des fautes de frappe dans la doc? C'est ça tes arguments?   
EDIT: je crois qu'en fait BSET est valable. Cette instruction teste le bit avant de le mettre à 1.

C'était des caliméros chez Atari ahahah ! Tu parles, le hardware de tordu !   Et les docs qui sentent le paté. Ah ça c'est sur, le HRM de l'Amiga c'est pas la même histoire tout de suite   Mis à jour, complet, sans conneries comme chez Atchaa.....ri.

Attention avec ce genre d'énumération, "moi président" s'y est essayé et s'est planté comme un Amiga.
Des bugs minimes, certes, mais en général fiable, pas comme sur Amiga.


Je note que tu ne réponds pas sur les timings d'affichage.

Ah je suis désolé, mais il est connu que pèpère il avait un atari. Sobriété, 49.3, ratés à répétition, fait rire la galerie pour un résultat ridicule..... Ah oui on est sur ST :) 

TOUKO a écrit:

oui comme indiqué dans mon post si tu l'avais lu correctement, je ne parlais de des perfs pure du blitter 

mais je te remercie de m'apprendre que l'amiga avec ses sprite hardware est plus balèse que le ST sans sprite hardware.

Comme tu as le chic de sortir les choses de leur contexte pour faire croire ce qui t'arrange, et dire après "si tu avais lu mon post" .
Qd on prend des perfs en compte on le fait sur une globalité, pas sur un truc en particulier parce que c'est le plus flatteur .
Donc la conclusion est qu'en opération pure blitter l'amiga éclate le STE, tu imagines, si on utilise en plus le reste du hardware !!, c'est une déculotté pour le STE .
C'est pour ça que WOD est une prouesse sur STE, tout en étant inférieur à l'amiga, alors qu'en plus sur amiga c'est un jeu quelconque par rapport aux gros shoots de la machine .

Dans l'affichage de sprite, l'amiga ne l'emporte qu'avec 5% de plus !

Si ça c'est explicite, bah dis donc .. 
Moi j'interprète ça comme :
Si on fait un jeu sur les 2 machines, l'amiga n'affichera que 5% de sprites en plus .

rocky007 a écrit:Atari STE Stereo / 8 voices / 25 KHz mixer / 50 KHz output / 8 bit samples

rocky007 a écrit:ben y'a bien des bananes qui achètent un amiga pour écouter un module pendant formater une disquette, alors qu'un une radio suffirait

rocky007 a écrit:Stapha : oui tu as raison, tous les codeurs qui préfèrent coder sur ST sont juste cons, aveugle et débiles.  Pourquoi perdre son temps sur ST alors qu'il y a le superbe Amiga. 

Ta comparaison avec le C64 est juste ridicule, je ne pensais pas lire une telle énormité venant de toi.  Montres nous donc des logiciels comme Vroom, Wings of Death, Cubase, Calamus sur un C64 !  et des jeux plus moches sur amiga que sur C64, il y en a des tonnes, il suffit de voir les vidéos que j'ai postées ci dessus.

Tu as aussi bien facile de critiquer les bugs de l'atari... c'est vrai que la limitation à 40 répertoires, c'est un manque de fiabilité... à ce compte, le manque de mode lasso est un manque de fiabilité aussi sur l'amiga.  c'est très décevant de ta part, que je me permette d'être un trolleur assumé, c'est une chose, mais un être si pur que toi, non, ça je ne te tolère pas.  Car évidement tu ne parles jamais des bugs amiga, comme par exemple l'impossibilité de booter sur HD, de mettre un HD supérieur à 40mb, de l’impossibilité d'avoir un directory sous WB, de la lenteur des accès disque,etc..etc...  affirmer tout le temps des éléments à charge, c'est un manque totale neutralité, serais-tu donc un fanboy aussi ?

Le ST n'est certes pas un joyaux d'ingénierie, mais cela n'enlève en rien ses qualités.  Pour rappel, il se positionnait comme concurrent au Macintosh pas à une megadrive.
Reproche-t-on à Macintosh le fait qu'il n'a pas de scrolling hardware ?  Et ce sont pas les millions d'utilisateurs qui diront le contraire.  et ces millions d'utilisateurs n'ont rien à foutre qu'un cycle par ci par là est perdu, au quotidien c'était une machine fiable et puissante.

rocky007 a écrit:mon St était branché sur un ampli, comme le dirait Stapha, tu sais pas te payer un cable à 10 balles ?

stapha92 a écrit:

rocky007 a écrit:mon St était branché sur un ampli, comme le dirait Stapha, tu sais pas te payer un cable à 10 balles ?

Oui c'est vrai, le même cordon que celui pour brancher un baladeur. Moi aussi j'avais mon ST branché sur un ampli.

Pauvre ampli... 

rocky007 a écrit:

babsimov a écrit:
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.

stapha92 a écrit:

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.