Re: QUI ETAIT LE MEILLEUR ? L'ATARI ST OU L'AMIGA ?

[ryosaeba]

Une petite video du Ste (1040) avec un HD et terradesk:

http://cenestpasunexercice.free.fr/ST/DEMO/Demo.htm

La video est un peu merdique.

[stapha92]

A mon avis, tu n'as pas bien vu la vidéo avec GFA et Dpain tournant en même temps. Cle Dpaint est devenu inutilisable ( pas assez de mémoire, le cercle s'affichait à la vitesse d'un..Spectrum ZX )

Tu devrais eviter de citer cet exemple...

encore une erreur de ta part... oui c'est un logiciel de composition, sauf que sa seule tâche simultanée avec un autre programme est... jouer un module, qui plus est est géré par un copro. C'est pour cela que c'était le seule tâche qui ne ralenti pas les autres processus, car elle est gérée par le corpo et non le 68000. Et c'est bien pour cela que dès que tu utilises un autre programme, qui lui utilise le 68000, cela devient impossible à utiliser.

Ah bon ? jouer un module se fait sans utiliser le copro ? Tu vas de plus en plus loin dans affirmations erronées ...

Je reconnais que cette fonction pouvait dépanner de temps en temps, mais de là à en avoir un usage quotidien ! De plus, je l'ai démontré ici : utiliser 2 programmes en mêmes temps est ridicule, donc aun final, la seule fonction utile est de pouvoir switcher entre deux programmes, sans devoir quitter le travail en cours. Ce que le ST pouvait faire sans problème avec des ACC Switch, et ce dès le début du ST.

Tu continues à citer tes accessoires et à croire que c'est equivalent... Sans commentaire...

Je suppose qu'Atari a opté pour un OS plus léger, plus simple, et plus court en développement plutôt qu'intégrer du multitâche gadget. Je ne vois pas vraiment le problème de l'intégrer plus tard, comme ils ont fait, pour le TT. Cela ne pose aucun problème. tu dis en "profiter" du multitâche... mais profiter de quoi ? honnêtement, je ne vois pas du tout ce que cela m'aurait apporté le multitâche sur ST. Lorsque j'avais besoin de plusieurs soft en même temps, j'utilisais le switch.. et ce cas était plutôt rare, car avec 1mb de mémoire vive, tu ne sais pas faire cohabiter bcp de softs.

Le problème de l'intégrer plus tard ? Même en supposant que ce n'était pas utilisable (ce que je réfute), ça assure la compatibilité. Moi je pense que ta supposition est fausse et que le choix d'Atari de prendre une adaptation rapide du CP/M est un choix conditionné par le cout. Comme tout ce qu'il y a dans un ST : le but était d'être moins cher que le Mac.

on t'a déjà dis mille fois, OUI : on sait formater une disquette tout en travaillant sur ST. Il suffit d'installer un formatteur en tâche de fond en ACC. J'aimerais préciser qq chose :

Formater une disquette ne demande presque rien au 68000. Il envoie une seule commande au controlleur floppy,
sans la moindre données ( hormis le numéro de piste, nbr de secteur etc..). Donc, le 68000 n'a que qq instructions pour formater chaque piste, ce qui permet de faire autre chose pendant ce temps. Par contre, ouvrir et lire une disquette, transférer des données, et l'interprétation de celles-ci par le 68000, ça bouffe du cycle

Ah bon ? Alors lance un formatage avec ton accessoire puis une appli qui utilise l'interruption vbl qu'on voit ce que ça va donner.
Moi j'ai flingué une disquette en voulant formater depuis Windows 3.1 sur un 486.

Moi perso, je suis très content du MacOs, tout comme le Win 7.

Pour conclure : je dirais que oui, le multitâche d'origine sur ST n'aurait pas été déplaisant, pourquoi pas...c'est vrai que de temps en temps, cela peu être utile, mais nous avions les soft Switch pour ces cas là.
Mais au final, je préfère 1000X une machine qui se boot en 1 sec, qui m'ouvre le directory de n'importe quel disquette en 1 sec, qui me permet de faire toute les opérations de base, et ce sans devoir ré-insérer le WB à chaque fois, plutôt qu'un multitâche.

Ben pourquoi t'es pas resté sur 8 bits ? ça boot aussi en 1 secondes ? Et comment peux-tu être content de MacOs ou de Win 7 : ça boote pas en une seconde !

[stapha92]

Mon but n'était que de rectifier des affirmations fausses ici

Alors edite tes posts...
T'as fait plein d'affirmations fausses et pour certaines tu les as répétées pleins de fois (comme ton coup du GFA ou tu expliques quelque chose de contraire au B.A.BA du coding...)

[stapha92]

Une petite video du Ste (1040) avec un HD et terradesk:

http://cenestpasunexercice.free.fr/ST/DEMO/Demo.htm

La video est un peu merdique.

C'est bien ce qu'on dit : c'est utilisable le multitache sur un 520 STE. Or l'A500 prend beaucoup moins de ressources pour jouer un mod qu'un STE. Donc je vois pas pourquoi ça devrait devenir inutilisable sur un mig...

[babsimov]

Pour conclure, je dirais que je trouve ton post irrespectueux ou alors on s'est mal compris. J'ai en particulier pas apprécié le coup du "syndrome", non seulement c'est irrespectueux envers mes souvenirs mais surtout envers les victimes dudit syndrome.
De même pour la partie ou tu méprise mon niveau en informatique (alors que quelques réponse auparavant tu me félicitait d'avoir essayé tout ça), belle hypocrisie de ta part. J'ai déjà dis, plusieurs fois, que je ne suis qu'un utilisateur.
Excuse moi d'avoir essayé de faire partager mes souvenirs ici et de ne pas avoir une mémoire infaillible.

Je suis vraiment désolé de t'avoir choqué et je m'en excuse. Je ne voulais en aucun te critiquer et encore moins les victimes dont j'ai pris exemple. Je respecte parfaitement l'utilisation que tu faisais de ton amiga et ton parcours informatique, et je ne me positionne en aucun cas comme qq supérieur parce que je faisais ci ou là avec mes ordis. Nous avons chacun nos niveaux, et nos expériences et ce en fonction de nos connaissances. Un électronicien aura encore un autre avis sur l'ST et l'Amiga, car il se basera que la qualité de l'architecture, du choix des composants etc... il est donc difficile d'avoir une vérité absolue, car chacun selon ses besoins et sa vision de l'informatique y trouvera son compte ou non.

Mon but n'était que de rectifier des affirmations fausses ici

Excuses acceptée et appréciée.

Ayant lu les différentes réponses de stapha92, j'attend tes réponses à ses arguments qui me semble quand même bien plus proche de ce dont je me souviens de l'Amiga.
Je ne dit pas que TOS n'avait pas d'avantages.
Le truc du formateur en tache de fond que tu installe si rapidement, c'était cool. Ca me rappel un peu les petits utilitaires qu'on pouvait installer sur l'Amiga pour rajouter des fonctions ou corriger des défaut connus du système (il y en avait bien sur, comme sur tout système jeune). Je pourrais pas te donner des noms d'utilitaires. Je me souviens juste que chaque mois, je commandais un lot de disquette domaine public de la collection Fred Fish. Il me semble que c'était dans la newsletter de Giorgio Cuppertino. Il avait fait une sélection des utilitaires les plus "indispensables". Parfois c'était des logiciels qui ne m'intéressaient pas et ciblaient un public précis. Parfois c'était comme Browser (celui je m'en souviens) qui permettait de faire une bonne gestion de fichier avec la souris. Une sorte de directory opus avant l'heure. Je n'en ais qu'un vague souvenir pourtant.
Pareil pour le GEM en français, cool, ça je le savais pas avant le voir ici et franchement je comprend pourquoi se retrouver devant le workbench en anglais ça pouvait dérouter un STiste. Comme de toute façon j'étais habitué à l'époque que l'anglais soit la langue de l'informatique, je m'étais dit, c'est comme ça. En plus ça me forçait à travailler mon anglais. D'ailleurs les readme des utilitaires était souvent en anglais aussi.

Ce que je peux dire c'est que le 500 m'a donné déjà pas mal de satisfaction, mais que sur le 1200 avec le 3.0, pour moi ça été presque la redécouverte tellement il y avait eu de bonnes évolutions dans le bon sens.

[stapha92]

Une video qui montre une présentation de l'amiga 1000



à 4:15 on voit la boing ball démo qui tourne et y a aucune latence lorsque le gars tape son texte au clavier et le mouvement de la boule reste identique. En plus il a laissé ouvert un cli : avec le workbench,il y a 4 taches qui tournent et lui-meme dit qu'il y en a 2...

Et c'est un Amiga 1000 avec un OS 1.0 qui n'était pas finalisé.

Un A500 s'en tire encore mieux (ne serait-ce que parce que ses copros peuvent acceder à plus de mémoire) et dispose d'un OS plus au point...

[erikrom2]

je sais pas si cela a deja ete posté mais sur gameone il on tout compris sur la rivalité amiga atari st

excellent

http://www.gameone.net/programmes/retro-game-one/episodes/retro-game-one-le-monde-de-atari-st/video/le-monde-de-l-atari-st-327448/

[Invité]

Oui, qu'est-ce que c'est bon de revoir ça ! :)

[babsimov]

Ah bon ? D'après moi, le mode Sliced HAM ne permet d'avoir une seule palette complète par scanline, soit 16 couleurs / scanline. De plus, pour utiliser le SHAM, le copper n'est plus suffisant, le 68000 doit gérer le changement de palette avec à la clé perte de cycles.

Le principe du HAM est de pouvoir modifier à chaque pixel l'une des 3 composantes de l'une de 16 couleurs de la palette. ça permet une compression spatiale avec pertes. Et ça implique qu'on n'est plus limité à 16 couleurs par ligne.
Sinon tu as tort : si le copper se retrouve dans l'impossibilité de modifier des registres, le 68000 ne pourra pas faire mieux. Je ne vois pas comment le 68000 pourrait avoir des cycles inaccessibles au copper. En plus, il lui en faut plus pour faire la même action. Tu ne connais pas autant le mig que tu le penses on dirait...
Dans les faits, en HAM (ou plutot avec 6 plans), le copper perd des cycles (dans la zone d'affichage uniquement). Mais il lui en reste assez pour faire presque autant de changement qu'un 68000 dans un mode 16 couleurs.
Et le HAM que tu dénigres n'est pas une arnaque, il a même eu droit a une évolution avec l'AGA. Il permet de faire pleins de choses, comme les séquences en raytracing qui bluffaient tout le monde à l'époque ou même :


ça peut tourner sur n'importe quel amiga avec un HD ou une carte. Et c'est du HAM tout simple stocké sous forme de fichier ANIM, un ancien format utilisé sur le mig...

T'es sur que le ST peut suivre avec ses 3 changements de palette par lignes ?

Extrémement impressionnant ça ! Je connaissais pas ces vidéos HAM. Je pensais que l'animation en HAM n'était pas possible. Je me trompais. Il y avait aussi un format pour la vidéo sur CD32, le CDXL, il utilisait le HAM ou HAM8 si je me souviens bien ? J'ai cherché et j'ai trouvé ca :
http://en.wikipedia.org/wiki/CDXL
http://en.wikipedia.org/wiki/ANIM

Les copros permettent d'aller bien plus loin que ça. Pour que tu comprennes leur potentiel regarde cette vidéo:



à 9:00 tu as l'un des tableaux bonus et les déformations et les rotations sont en temps réel. Tout ça avec 2 layers...
Et ce jeu est remplit d'effets du même genre (ça commence dès l'intro et ça continue entre chaque tableau).

à 19:15 commence une séquence shoot simple pour le mig mais introuvable sur le ST, même dans un vrai shoot them up.

Je le connaissais pas Brian the lion (de nom seulement). Surement que je l'ai vu passer à l'époque, mais le thème ne m'avait pas inspiré, j'avais donc pas du aller bien loin. En tout cas, jolie performance technique ce jeu. Il va falloir que je le cherche pour l'essayer un jour.

Wow, terrible l'argument... et je peux répliquer avec la même mauvaise foi : quand tu as planté ta seul disquette de WB, tu fais comment pour formater ta disquette avec ton super multitâche ? Tu fais comment pour utiliser tes softs qui nécessite WB ?
Ah oui, tu vas me dire qu'il suffit d'avoir un WB en backup... ben oui, tout comme il suffisait d'avoir une disquette formatée sur Atari de réserve. De plus, toute personne utilisant correctement son ST utilisait un gestionnaire de fichier évolué, qui permettait dans chaque programme utilisant le GEM de faire toutes les opérations disques possibles, sans ce sans quitter le programme en cours.
Je ne parle bien entendu pas des softs qui permettait de switcher entre le bureau GEM et un programme à tout instant.

Je suis bien d'accord pour l'argument du gestionnaire de fichier qui était réservé aux personnes qui maitrisaient leur ST. Il est évident qu'un OS a besoin d'un minimum de maitrise pour être bien exploité. Celui du mig étant plus complexe que celui du ST, est-ce vraiment un scandale que sa maitrise soit un peu plus compliquée ?
Et je le répète : pour ce type d'action (formatage, copie, etc...) le ST est plus pratique. Surtout si on part ordi éteint. Mais un OS ne servant pas qu'à ça, je ne pense pas qu'on puisse conclure que ça rendait le TOS meilleur que l'AmigaOS.

Comme je l'ai reconnu le TOS/GEM en ROM offrait un avantage certain du point de vue utilisateur, ca n'enlève rien aux plus de l'AmigaOS, selon mon opinion d'utilisateur.

- Lamentable, la possibilité des faire des icones customs est apparue très rapidement après la sortie du ST. et franchement....c'est ton seul argument pour l'amiga ?

D'abord tu nous expliques que le chargement d'un WB est redhibitoire et après tu nous parles de patcher ton OS dans tous les sens...
Ensuite tu t'obstines à penser que les icones n'ont qu'un role visuel : ce n'est pas du tout le cas sur le mig. Et tu peux mettre les patchs que tu veux, tes icones ne gereront jamais rien sur un ST et ne seront pas spécifiques à chacun des fichiers auquel tu veux en attribuer. Resultat : niveau personnalisation, on sera loin du compte alors que l'on ne parle que de l'aspect visuel. Pour tout le reste, y a aucun patch qui donnera aux icones du GEM les possibilités de ceux du mig.
Et je n'ai pas que ça pour défendre l'Amiga : c'était pour répondre au problème évoqué sur les icones qui n'étaient pas créés automatiquement par le WB. Je pourrai te parler de pleins d'autres choses sur l'OS : du layer hardware à l'auto-config en passant par les écrans draggables, les datatypes, la gestion des devices, les écrans publiques, l'API bien plus fournie, les librairies partagées au code réentrant, le CLI, etc...

Stapha92, tu as trouvé les mots pour expliquer ce que je voulais dire pour le coté novateur par rapport au TOS. Tu es mon héros

La limitation des fenêtres a elle aussi été augmentée sur les TOS suivant, et par parch pour les premiers TOS.

Encore un patch ? Et t'arrives à combien de fenêtres ? LOL !!!
Même le TT, la version pro, était limité de ce coté non ?

Question, sur MAC y avait il cette même limitation des fenêtres ? Je l'ai lancé sur Shapeshifter, mais j'ai pas beaucoup cherché, sur MAC, il y avait pas grand chose que je trouvait intéressant.
Autre question, sait on pourquoi cette limitation a été imposée au GEM ?

bref, tous tes arguments sont tellement légers que c'en est même fatiguant de répondre.
tu prends vraiment des détails pour valoriser l'amiga, comme si c'était LE truc qui tue..excuses moi mais c'est un peu ridicule.

je te rappelle que je répondais aux attaques sur la convivialité. Evidemment que l'ergonomie est faite de détails. Par contre le multitache est quelque chose d'essentiel et tu le traite comme un détail inutile. Moi c'est ça que je trouve un peu ridicule...

Nous avons le même point de vue sur le multitache, je trouvais que c'était une belle avancée.

Mais moins ridicule que ça :


T'as posté ça en t'appuyant dessus pour dire que la version ST est plus colorée et en accusant au passage Babsimov de mauvaise foi.
N'importe quel utilisateur de ST se rend compte tout de suite que ce n'est pas un ST. Y a même pas besoin de regarder, on s'en rend compte rien qu'avec le son.
La vrai version ST est beaucoup moins coloré. La prochaine fois défend le ST avec un jeu ST.

Je pense qu'il avait mis les deux versions, je me souviens que le son de la version ST était moins bon. Après, lui ayant fait remarqué que les couleurs étaient moins bien sur ST, il avait posté une version avec une meilleure qualité vidéo. J'avoue ne pas avoir fait attention si c'était le même son. Donnons à Rocky007 le bénéfice du doute, puisque je n'ai pas été revérifier sur le sujet en question.

Tu prends Babsimov constamment de haut avec des exemples erronnés (ou des affirmations peines de certitudes et pourtant fausses, j'y reviendrais...)

Merci de ton soutien. J'ai fait part ici de mon impression sur la manière dont il m'avait répondu et en particulier sur une réponse en particulier. Rocky007 s'étant excusé, je met ça sur le compte de l'emportement du à la passion. M'étant moi même emporté plus d'une fois et commis des erreurs dans certaines affirmations (souvent pas méconnaissance ou souvenir défaillant). Il a le mérite d'avoir fait un certain nombre de vidéo. Sa dernière vidéo sur le ST m'ayant agréablement surpris je dois dire pour la faciliter de rajouter des fonctions sur cette machine.

C'est ça le pire... Ils ont mis plus de temps pour l'amigaOs, et au final, c'est quoi ? même pas foutu de faire un directory... wow..
de plus je ne savais pas que tu as fais partie des deux équipes de développement, et peux ainsi affirmer qu'il a fallu plus de temps pour développer AmigaOS. Depuis quand le "temps" de développement est un gage de qualité ? As-tu comparé le nombre de personnes qui ont bossé sur GEM et sur Aos ?

Ah bon ? on peut pas faire de directory ? Première nouvelle... Et tu ne réponds pas sur le fait que toutes les choses que tu dénigres sur le mig sont dans tous les OS modernes ?
Pour la conception et le dev des 2 machines, renseigne toi : c'est de notoriété publique. Et pour garder l'exemple d'Exec, le gars qui s'en est occupé (Carl Sassenrath) est devenu célèbre pour ce travail qui a impressionné (comme d'autres de l'équipe). Y a la même chose du coté du ST ?

C'est effectivement exact que bon nombre, dont Carl Sassenrath, des créateurs originaux de l'Amiga ont gagné l'admiration pour leur excellent travail sur cette machine. Il me semble que la 3DO a été en partie conçu par l'un d'eux. J'avais même lu, mais là je suis pas sur, que la partie vidéo de la Lynx avait été créé par eux. Cette console, que je n'ai pas eu, semblait avoir pas mal d'innovation pour l'époque.

je connais également de nombreuses personnes qui sont passées sur Amiga, pour retourner ensuite sur Atari, car (selon eux ) il était impossible de travailler correctement sur amiga, comme simplement faire du traitement de textes. Tout était tellement laborieux. Toujours selon eux, l'amiga était aussi compliqué qu'un PC avec ses Config.sys et autoexec.bat... ah oui bien sûr, qd on a fait ingénieur informatique, on arrive à tirer tout le potentiel d'un amiga, mais pour le petit prof qui veut taper ses cours sur un ordi, c'est une autre histoire.

Quand on a fait de l'info, on sait qu'un PC adresse 10 pages de 64 Ko là ou un ST ou un mig adressent plusieurs méga de façon linéaire. Et on en déduit qu'il n'y avait pas de config.sys à se fader pour faire tourner ou installer quelque chose sur le mig (tout comme le ST d'ailleurs). Un clic pour lancer le programme ou l'installation et c'est tout. Comparer le WB au DOS est aussi drole que de le comparer au TOS. Sans compter qu'on devait jouer avec le config.sys pour configurer les périphériques alors que le mig avait déjà l'auto-config, qui est l'ancetre du plug & play...
Maintenant je voudrais que tu m'expliques : qu'y avait-il de compliqué à utiliser ou installer une appli sur le mig ?

Ah bon, il y avait un config.sys sur TOS ? Ca s'est vraiment pas sympa de cacher ça ! Je pensais que le ST fonctionnait comme l'Amiga, qu'il avait un genre de truc ressemblant à l'autoconfig (ou du moins approchant), puisque personne ne parlait de problème de gestion ou installation des extensions ou périphériques sur cette machine, comme c'était le cas sur PC. Je tombe de haut là !
Pour l'instant le ST me semblait avoir toujours une parade, mais là un config.sys à configurer par l'utilisateur, c'est un coup rude pour la convivialité. Mais je ne demande qu'à apprendre que le config.sys du ST était quand même plus cool à gérer que celui de MS-DOS ?

pour ton histoires de cycles, je ne comprends pas vraiment ou tu veux en venir. Selon toi, l'Atari est moins rapide que l'Amiga, puisqu'il prend 33% de temps en plus pour exécuter une instruction ?
C'est très étonnant comme affirmation, surtout sur des jeux tels que Interphase qui utilise 100% du 68000, et qui est au final plus rapide sur Atari.. ( grâce à la fréq plus élévée du 68000 ). Les instructions 68000 s'exécute en multiple de 4 cycles sur Atari.

Ah bon ? Tu codais sur ST et tu n'es pas au courant (et d'ou tu sors ce 33% ? tu penses que les instructions 68000 font toutes 6 cycles ?)? Et tu penses que c'est du à quoi si elles prennent des multiples de 4 cycles ? A cause du 68000 ? Non : à cause du controleur DMA du ST qui ne commute pas à chaque cycle mais tous les 2 cycles et qui le fait même hors de la zone d'affichage. Des cycles sont réservés au shifter qui ne les utilise même pas. Tu parles d'une conception : 2 gachis de ressource cpu ! On parle pourtant d'un controleur mémoire bien plus simple à concevoir que celui du mig. Pour info : un Atari 800 ou un C64 ne gachent aucun cycle quand l'affichage n'en a pas besoin et ont un controleur mémoire qui commute aussi vite que nécessaire...
Donc une instruction pourra prendre plus de cycles (et jamais moins !) sur un ST : ce n'est pas si grave qu'il n'y parait mais ça va à l'encontre de la légende des STistes qui prétendent que le 68000 s'exprime mieux dans un ST. Dans la vraie vie, c'est exactement le contraire...

Exemples :
- Move.w -(A0),D1 : 12 cycles sur le ST, 10 cycles sur l'Amiga
- Not.l D2 : 8 cycles sur le ST, 6 cycles sur le mig

Avoue que ces exemples ne s'appuient pas sur des instructions rarement utilisées...
Et médites sur le gachis de porter un code ST optimisé pour limiter la pertes de cycles sur le mig là ou ce dernier aurait été plus rapide avec l'algo avant l'optimisation des cycles. C'est ce qui se passait au début...

Oui, Interphase est plus rapide sur ST. Et je peux te citer pleins de jeux dans le même cas (même en 2D). ça montre juste qu'il n'était pas bien programmé sur le mig. C'est toujours la même histoire : on code l'original sur le ST et comme le mig arrive à s'en sortir à peu près, on se contente de recompiler. Maintenant, sur pleins de jeux 3d ce n'était plus vrai alors que je n'ai vu aucun jeu correctement optimisé. Si on s'était juste contenté d'utiliser le blitter pour effacer l'écran, le même jeu 3d serait plus rapide sur le mig (d'autant que j'ai expliqué au-dessus comment une partie de la fréquence plus élevé du 68000 était bouffée par l'architecture). Je ne parle pas des jeux 3D avec un son à base de samples : couteux sur ST et gratuits sur le mig. A noter que le principe est applicable pour le STE : grace à une utilisation minimal du blitter, stunt car racer aurait pu être plus rapide dessus.
je ne parle pas du fait que le blitter du mig sait tracer des lignes et faire des remplissages bien plus vite que le 68000 : là on aurait pu avoir des jeux 3d bien plus fluides encore...

Voilà la réponse, j'avais parlé de manque d'optimisation de la version Amiga. Il semble bien que c'était le cas. Du moins d'un mauvais portage depuis le ST. Comme quoi, même un utilisateur sans connaissance en programmation peut trouver par le bon sens les bonnes réponses. Maintenant je pouvais pas le prouver comme cela vient d'être fait.

De plus, il est vrai que le 68000 du ST est mieux organisé : ne dépendant pas de copro, il ne doit pas être synchro avec les différents copros.

Si tu n'utilises pas le blitter ou le copper, le 68000 n'est absolument pas ralenti car le controleur DMA du mig ne prend que le strict nécessaire lui (alors qu'il tourne 2 fois plus vite et gère bien plus de canaux...) et quand tu les utilises, ils font le travail bien plus vite que le 68000 (>10 fois plus rapidement pour le blitter). Et dans un Amiga avec fast-ram, le 68000 n'est jamais gené.
Dans le ST, le 68000 est TOUT LE TEMPS gené par l'architecture. Donc non : il s'exprime moins bien. Tu peux ranger ton "de plus, il est vrai..." car c'est bien ce que j'ai dit : une légende des Stistes fondée sur rien...

Je m'étalerai pas sur le "nasty mode" du blitter qui lui permet de travailler en parralèle et avec lequel le 68000 est bien moins impacté. Encore un truc inexistant sur le blitter du STE...

Je laisse les experts débattre de ce sujet, mais il me semble bien avoir lu que le blitter du STE était effectivement bridé par l'architecture interne du ST. Ce qui peut s'expliquer parce que la machine n'a pas été prévue au départ pour avoir un blitter, alors que sur Amiga il est au centre de la machine (c'était l'idée de base de Jay Miner pour sa puce graphique).

ah bon ? et dis-moi quels étaient les milliers de process qui étaient magnifiquement cachés sur amiga ? un sous programme qui détecte l'insertion d'une disquette ? wow....ça c'est du multitâche...
Le GEM aussi avait bien évidement des sous-programme qui tournait en boucle. Le "concept de l'interruption" dans ce cas précis était un logiciel qui utilisation une interruption 68000 pour formater une disquette en tâche de fond, pendant que tu utilisais un ton ST normalement.

ça c'est du troll : l'exemple que j'ai donné était en réponse à ton affirmation qui prétend que le multitache ne sert à rien même avec les OS modernes...
Ah oui ? un formatage en multitache en travaillant normalement ? Et que ce passe-t-il si tu lances un programme qui utilise aussi des interruptions ? Ou s'il contient des adressages absolus ? Même Windows 3.1 avec son multitache coopératif n'y arrivait pas : j'ai raconté dans le topic fight comment j'ai flingué une disquette en essayant de la formater en tache de fond sous ce système...

Et j'attend toujours ton exemple du multitache sous TOS ou tu formates, écoutes un mod et compresse un fichier...

Rocky007 ce serait intéressant en effet avec ton ST équipé du formateur en tache de fond que tu as montré.

Pour le multitâche C64, voici le lien : http://www.6502.org/users/andre/osa/oa1.html, pour ton info, il est préemptif.

TU l'as essayé cet OS ? Tu crois qu'on peut dire que le c64 en faisait autant que le mig pour reprendre ton affirmation ?

Ok lisons un peu ce qu'il y a sur la page de ton lien :

At the very last, a "real OS includes some form of multitasking

Un vrai os est multitache... Bon ok, c'est du troll je te taquine. Le TOS est un VRAI OS (et le GEM un VRAIE interface graphique, c'est tout aussi évident). Mais admet que c'était tentant.

Plus sérieusement :

Even the stack pointer is 8 bits, restricting the stack to the 256 bytes from $0100 to $01ff. The stack size and the absolute addresses are a severe limitation if you intend to develop a multitasking OS on this machine (...) I solved the stack problem by using an MMU, a Memory Management Unit.

Tiens donc : Le gars nous explique que la pile non relocalisable (lui a dit "fixe") est un problème : C'est exactement ce que j'ai affirmé ! Et pour ne pas perdre en perf, il utilise une mmu !
Tout cela me donne raison : le 6502 n'est pas doué pour faire du multitache et pourtant il est très fort pour la gestion des interruptions (et il a moins de registres à sauvegarder qu'un 68000). Et note que l'auteur explique que la version C64 sans MMU ne peut pas être considéré comme multitache mais multi-thread (et là pas de pile à préserver...)
Bien sur que du vrai multitache est possible sur C64 mais je maintiens que c'est trop couteux en ressources.
Donc tu me contredit avec un lien qui me donne raison : tu penses toujours que c'est moi qui suis ridicule ?

Il y a une MMU sur C64 ? C'est peut être une question idiote, là vous entrez tous les deux dans un domaine trop technique pour moi.

Je vois mal comment un A500 qui utilise 100% des ressources lors d'un calcul d'une image 3D peux préparer la suivante sans diminuer par conséquent la vitesse de calcul de ton image.

Bien sur qu'elle va prendre plus longtemps à calculer. Mais si elle prend 10 min de plus et que tu as pu modéliser pendant 1H, tu seras gagnant sur le temps total. Et si tu passes plus de temps à modéliser que le temps du calcul, il n'y aura finalement plus d'attente.

C'était mon propos et l'utilisation que je faisait du multitache. Quand j'avais un truc à faire qui pouvait fort bien s'accommoder de le faire en tache de fond, je le faisait. Ca me permettait de continuer à faire mon travail sur l'Amiga sans perdre de temps sur le reste. Que la tache de fond mette 5 minutes ou 10 minutes qu'est ce que ça m'importait, puisque de toute façon j'allais passer une heure ou deux à écrire ou autre sur l'Amiga. C'est ça l'utilité du multitache. Comme ce qu'on fait de nos jours couramment, ni plus ni moins.

Par contre oui, un slide show qui devra intégrer un sous titre sur image, peut préparer l'image suivante lors d'une pause. Mais ça, c'est faisable sans problème sur ST. C'est le soft qui devrait gérer cela, tout simplement.

Bien sur que c'est faisable, et il n'y a même pas besoin de gérer plusieurs taches puisque lorsqu'une image est affichée, le proc n'est plus sollicité. A moins que cet affichage fasse appel au cpu (pour une image spectrum 512) mais même dans ce cas, le ST peut le faire sans problème.
Entendons nous bien : je n'ai jamais dit que le ST ne pouvait pas gérer un système multitache. Il peut le faire sans aucun problème. Je dis juste que lorsque vous dénigrez cet aspect du mig, vous ne réalisez pas à quel point vous avez tort car dès qu'on en prenait l'habitude, on ne pouvait plus s'en passer.

Moi non plus je n'ai pas dit que le ST ne pouvait pas être multitache. Je regrette juste que cela n'est pas été d'origine, comme sur l'Amiga. Tout le monde (Atariste comme Amigaiste) en aurait été gagnant. Les Ataristes aurait eu le plaisir de le découvrir en même temps que nous (même avant en fait). Et Commodore aurait du faire l'effort de sortir plus vite les versions de l'AmigaOS pour garder de l'avance.

J'aimerais avoir un exemple concret du multitâche dans toute sa splendeur sur A500... parce que vous en parlez comme LA révolution de l'Amiga, concrètement, à part formater une disquette, ça donne quoi ? Cites-moi un seul exemple vraiment impressionnant, qu'un Atari ne peut faire sans multitâche ?

Je t'ai donné l'exemple d'une modélisation que tu fais dans un logiciel dédié pendant que le rendu se fait sous POV : impossible sans multitache. Il y a pleins d'exemples : comme celui d'une impression en couleurs (tu te souviens de la vitesse des jets d'encre de l'époque ?). ça permet pleins d'autres choses, comme l'ajout des commodities dans le WB qui apportaient un vrai confort et qui sans cela n'aurait été que des accessoires (mais non limités en nombre...)

Les commodités, c'est à partir du 2.0, sauf erreur de ma part. On se limitait au 1.x (même si j'ai du aussi commettre des impairs à ce niveau).

Nier l'apport du multitache , c'est comme nier celui de la haute résolution du ST associée aux écrans monochrommes. Un point clé qu'on sous-estime tant qu'on ne l'a pas essayé.

Sur ce point je dois dire que c'est vrai. Au début, quand je suis arrivé ici, j'ai clairement mis en doute l'intéret du mode monochrome haute résolution. Mais la lecture de plusieurs revues d'époque m'ont démontré que la majorité des logiciels de travail en tiraient partit et que le moniteur monochrome du ST était unanimement reconnu comme un plus. Plus tard, j'ai moi même reconnu que j'avais eu tord pour le mode monochrome que j'avais traité d'obsolète.
Je me demande, pourquoi Atari n'a pas sortit un moniteur couleur capable en plus d'afficher le monochrome haute résolution ? Ca aurait été trop cher ?

Maintenant, les STistes n'arretent pas de nous sortir des OS multitaches sur le ST en oubliant que dans ce cas là, on perd pas mal de RAM et la compatibilité avec les logiciels du TOS : Cubase (qui est un bijou dont peut rever le mig) tourne sur Mint ?... Hmmmm...

C'est comme le bureau en ROM : je ne nie pas que ça a des avantages. Je dis juste que ça n'a pas QUE des avantages. j'ose ajouter qu'avec un disque dur, comme ça a été dit ici, ça n'en a presque plus.

Oui, il me semblait bien avoir lu que le multiTOS ne brillait pas par sa compatiblité.
Par contre, Cubase n'a t il pas eu une version Amiga ? Il me semblait bien que oui ?

Le ST est une super machine (contrairement, pour moi, au STE ou au Falcon) et je peux expliquer pourquoi pendant des pages. Mais quand on prétend qu'il meilleur qu'un Amiga, je ne suis pas d'accord.

Je te rejoint, le ST est une bonne machine, surtout pour son prix à l'époque. Mais l'Amiga reste tout de même bien au dessus.

L'AmigaOS que tous les STistes se plaisent à descendre, existe aujourd'hui sous 4 formes :
- AmigaOS 3.9 : dernière version utilisable sur 68000 ou 68000+PowerPC
- AmigaOS 4.1 : version pour les machines powerpc
- MorphOS : idem
- AROS : portage multi-plateforme

Les 3 premières sont commerciales et lancent les applis Amiga de façon native, la dernière est gratuite mais necessite une recompilation des applis.

Bien sur, leur implantation est anecdotique mais ce TOS, qui écrasait tellement l'AmigaOS, doit logiquement être mieux représenté aujourd'hui : on en est ou ?

J'avais il me semble fait remarquer ça aussi.

[babsimov]

je sais pas si cela a deja ete posté mais sur gameone il on tout compris sur la rivalité amiga atari st

excellent

http://www.gameone.net/programmes/retro-game-one/episodes/retro-game-one-le-monde-de-atari-st/video/le-monde-de-l-atari-st-327448/

Merci pour cette vidéo, j'avoue avoir passé un excellent moment. Marcus de retour sur GameOne, je le savais pas. Du coup de vais peut être regardé à nouveau cette chaine. Ca passe à quelle heure son émission ?

[Invité]

Si, l'Amiga avait le format Anim5/Anim7 (entre autre) qui permettait de jouer des séquences HAM6/8 en plein écran 25fps, et c'était très impressionnant.
Malheureusement, l'espace disque ne permettait par de faire autre chose que des boucles sur quelques secondes ... Mais forcément, avec une compact flash de 4Go tu peux stocker des films.

[babsimov]

Si, l'Amiga avait le format Anim5/Anim7 (entre autre) qui permettait de jouer des séquences HAM6/8 en plein écran 25fps, et c'était très impressionnant.
Malheureusement, l'espace disque ne permettait par de faire autre chose que des boucles sur quelques secondes ... Mais forcément, avec une compact flash de 4Go tu peux stocker des films.

Encore des années d'avance pour l'Amiga avec cette possibilité (même si à l'époque on ne pensait pas que des supports de cette taille existeraient).

[stapha92]

Je pense qu'il avait mis les deux versions, je me souviens que le son de la version ST était moins bon. Après, lui ayant fait remarqué que les couleurs étaient moins bien sur ST, il avait posté une version avec une meilleure qualité vidéo. J'avoue ne pas avoir fait attention si c'était le même son. Donnons à Rocky007 le bénéfice du doute, puisque je n'ai pas été revérifier sur le sujet en question.

C'est bien la vidéo qu'il a posté en t'accusant de mauvaise foi. Et evidemment que les couleurs étaient meilleures sur cette version puisque ce n'est pas sur ST...
Pourtant il s'agit d'un jeux des bitmap brothers qui étaient connus pour être des bons avec le ST.

Merci de ton soutien. J'ai fait part ici de mon impression sur la manière dont il m'avait répondu et en particulier sur une réponse en particulier. Rocky007 s'étant excusé, je met ça sur le compte de l'emportement du à la passion. M'étant moi même emporté plus d'une fois et commis des erreurs dans certaines affirmations (souvent pas méconnaissance ou souvenir défaillant). Il a le mérite d'avoir fait un certain nombre de vidéo. Sa dernière vidéo sur le ST m'ayant agréablement surpris je dois dire pour la faciliter de rajouter des fonctions sur cette machine.

J'ai vu qu'il s'était excusé et j'en suis heureux. Pour la facilité d'installation des accessoires : t'as déjà eu des problèmes à retirer un commoditie ? Parce qu'un accessoire ça ne se retire pas : faut rebooter ! On ne nous dit pas tout !

C'est effectivement exact que bon nombre, dont Carl Sassenrath, des créateurs originaux de l'Amiga ont gagné l'admiration pour leur excellent travail sur cette machine. Il me semble que la 3DO a été en partie conçu par l'un d'eux. J'avais même lu, mais là je suis pas sur, que la partie vidéo de la Lynx avait été créé par eux. Cette console, que je n'ai pas eu, semblait avoir pas mal d'innovation pour l'époque.

Oui c'est bien eux qui sont à l'origine de la lynx. Le kit de dev de la Lynx était d'ailleurs sur Amiga : et oui ! sur une machine commodore ! (au passage ça montre que le mig n'était pas assez stable pour le dev...)

Ah bon, il y avait un config.sys sur TOS ? Ca s'est vraiment pas sympa de cacher ça ! Je pensais que le ST fonctionnait comme l'Amiga, qu'il avait un genre de truc ressemblant à l'autoconfig (ou du moins approchant), puisque personne ne parlait de problème de gestion ou installation des extensions ou périphériques sur cette machine, comme c'était le cas sur PC. Je tombe de haut là !
Pour l'instant le ST me semblait avoir toujours une parade, mais là un config.sys à configurer par l'utilisateur, c'est un coup rude pour la convivialité. Mais je ne demande qu'à apprendre que le config.sys du ST était quand même plus cool à gérer que celui de MS-DOS ?

Du calme... Il n'y en avait pas sur le TOS (pas de problème de page mémoire à gérer). Et il n'avait pas non plus d'auto-config. Je répondais sur le fait que l'os du mig était soi-disant du niveau du DOS (alors que les ressemblances, comme les noms de fichiers, sont plutot du coté du TOS...)

Je laisse les experts débattre de ce sujet, mais il me semble bien avoir lu que le blitter du STE était effectivement bridé par l'architecture interne du ST. Ce qui peut s'expliquer parce que la machine n'a pas été prévue au départ pour avoir un blitter, alors que sur Amiga il est au centre de la machine (c'était l'idée de base de Jay Miner pour sa puce graphique).

Y a rien à débattre : le blitter du mig est meilleur

- Il a 3 source et celui du STE 2
- Il peut réaliser 256 combinaisons logiques entre les sources et le STE 16
- Il peut faire du cookie-cut en une passe : il en faut 2 au STE
- Il peut travailler en parrallèle avec le 68000. Le 68000 du STE est totalement bloqué quand le blitter bosse.
- Il peut tracer des lignes ou faire du remplissage : pas celui du STE.

Comme moi je ne suis pas un fanboy, je vais te donner les avantages du blitter du STE :
- Plus rapide lors d'une opération sans source (effacement) car il le fait en prenant tous les cycles alors que celui du mig en laisse la moitié au proc.
- Possède un mode indirect : peu exploité pour l'instant mais ça devrait permettre de faire des choses sympa.

Il y a une MMU sur C64 ? C'est peut être une question idiote, là vous entrez tous les deux dans un domaine trop technique pour moi.

Non y en a pas. La MMU permet de contourner le problème que je soulevais sur la pile non relocalisable et dans le lien qu'à donné Rocky, le type explique qu'il a developpé son OS sur une machine équipé d'un 6502 et d'une MMU. Il dit aussi que la version C64 de son OS n'est pas vraiment multitache car il n'y a pas de MMU dans le C64.

Sur ce point je dois dire que c'est vrai. Au début, quand je suis arrivé ici, j'ai clairement mis en doute l'intéret du mode monochrome haute résolution. Mais la lecture de plusieurs revues d'époque m'ont démontré que la majorité des logiciels de travail en tiraient partit et que le moniteur monochrome du ST était unanimement reconnu comme un plus. Plus tard, j'ai moi même reconnu que j'avais eu tord pour le mode monochrome que j'avais traité d'obsolète.
Je me demande, pourquoi Atari n'a pas sortit un moniteur couleur capable en plus d'afficher le monochrome haute résolution ? Ca aurait été trop cher ?

Et oui, c'est une question de prix. Un amiga pouvait afficher de la haute résolution non entrelacée et en 16 couleurs : Génial... Sauf que pour en profiter il fallait se payer un moniteur qui valait le prix de 2 A500 minimum ! C'est seulement quand les moniteurs VGA ont baissé qu'on a pu avoir de la vrai haute réolution sur le mig, c'est à dire bien des années après le ST...

Oui, il me semblait bien avoir lu que le multiTOS ne brillait pas par sa compatiblité.
Par contre, Cubase n'a t il pas eu une version Amiga ? Il me semblait bien que oui ?

Je ne sais pas.

[babsimov]

Je pense qu'il avait mis les deux versions, je me souviens que le son de la version ST était moins bon. Après, lui ayant fait remarqué que les couleurs étaient moins bien sur ST, il avait posté une version avec une meilleure qualité vidéo. J'avoue ne pas avoir fait attention si c'était le même son. Donnons à Rocky007 le bénéfice du doute, puisque je n'ai pas été revérifier sur le sujet en question.

C'est bien la vidéo qu'il a posté en t'accusant de mauvaise foi. Et evidemment que les couleurs étaient meilleures sur cette version puisque ce n'est pas sur ST...
Pourtant il s'agit d'un jeux des bitmap brothers qui étaient connus pour être des bons avec le ST.

Merci donc pour cette correction, je n'avais pas remarqué la chose.
Je pense que les bitmap brothers étaient bon tout court :)

Merci de ton soutien. J'ai fait part ici de mon impression sur la manière dont il m'avait répondu et en particulier sur une réponse en particulier. Rocky007 s'étant excusé, je met ça sur le compte de l'emportement du à la passion. M'étant moi même emporté plus d'une fois et commis des erreurs dans certaines affirmations (souvent pas méconnaissance ou souvenir défaillant). Il a le mérite d'avoir fait un certain nombre de vidéo. Sa dernière vidéo sur le ST m'ayant agréablement surpris je dois dire pour la faciliter de rajouter des fonctions sur cette machine.

J'ai vu qu'il s'était excusé et j'en suis heureux. Pour la facilité d'installation des accessoires : t'as déjà eu des problèmes à retirer un commoditie ? Parce qu'un accessoire ça ne se retire pas : faut rebooter ! On ne nous dit pas tout !

Non, bien sur qu'une commodité pouvait être retirée ou ajouté quand on voulait. Si mon souvenir est bon, il suffisait de la placer dans le bon répertoire (wbstartup ?) ou alors si tu en avait besoin subitement de double cliquer dessus ?

C'est effectivement exact que bon nombre, dont Carl Sassenrath, des créateurs originaux de l'Amiga ont gagné l'admiration pour leur excellent travail sur cette machine. Il me semble que la 3DO a été en partie conçu par l'un d'eux. J'avais même lu, mais là je suis pas sur, que la partie vidéo de la Lynx avait été créé par eux. Cette console, que je n'ai pas eu, semblait avoir pas mal d'innovation pour l'époque.

Oui c'est bien eux qui sont à l'origine de la lynx. Le kit de dev de la Lynx était d'ailleurs sur Amiga : et oui ! sur une machine commodore ! (au passage ça montre que le mig n'était pas assez stable pour le dev...)

Je savais pas ça... les ataristes ne s'en vantent pas
Mais c'est tout à fait compréhensible que les créateurs de l'Amiga préfèrent utiliser leur machine comme machine de développement.

Ah bon, il y avait un config.sys sur TOS ? Ca s'est vraiment pas sympa de cacher ça ! Je pensais que le ST fonctionnait comme l'Amiga, qu'il avait un genre de truc ressemblant à l'autoconfig (ou du moins approchant), puisque personne ne parlait de problème de gestion ou installation des extensions ou périphériques sur cette machine, comme c'était le cas sur PC. Je tombe de haut là !
Pour l'instant le ST me semblait avoir toujours une parade, mais là un config.sys à configurer par l'utilisateur, c'est un coup rude pour la convivialité. Mais je ne demande qu'à apprendre que le config.sys du ST était quand même plus cool à gérer que celui de MS-DOS ?

Du calme... Il n'y en avait pas sur le TOS (pas de problème de page mémoire à gérer). Et il n'avait pas non plus d'auto-config. Je répondais sur le fait que l'os du mig était soi-disant du niveau du DOS (alors que les ressemblances, comme les noms de fichiers, sont plutot du coté du TOS...)

Je ne m'emportait pas, désolé si j'en ai donné l'impression. J'avais juste mal compris ton propos. Pour les ressemblance du TOS avec le DOS, c'était aussi mon impression.

Je laisse les experts débattre de ce sujet, mais il me semble bien avoir lu que le blitter du STE était effectivement bridé par l'architecture interne du ST. Ce qui peut s'expliquer parce que la machine n'a pas été prévue au départ pour avoir un blitter, alors que sur Amiga il est au centre de la machine (c'était l'idée de base de Jay Miner pour sa puce graphique).

Y a rien à débattre : le blitter du mig est meilleur

- Il a 3 source et celui du STE 2
- Il peut réaliser 256 combinaisons logiques entre les sources et le STE 16
- Il peut faire du cookie-cut en une passe : il en faut 2 au STE
- Il peut travailler en parrallèle avec le 68000. Le 68000 du STE est totalement bloqué quand le blitter bosse.
- Il peut tracer des lignes ou faire du remplissage : pas celui du STE.

Comme moi je ne suis pas un fanboy, je vais te donner les avantages du blitter du STE :
- Plus rapide lors d'une opération sans source (effacement) car il le fait en prenant tous les cycles alors que celui du mig en laisse la moitié au proc.
- Possède un mode indirect : peu exploité pour l'instant mais ça devrait permettre de faire des choses sympa.

Tout ça c'est un peu technique pour moi (surtout le cookie-cut, les combinaisons logique et les 3 sources). Mais je comprend quand même l'idée générale. C'est logique qu'un blitter intégré après sur une architecture pas prévue pour soit moins bon.

Il y a une MMU sur C64 ? C'est peut être une question idiote, là vous entrez tous les deux dans un domaine trop technique pour moi.

Non y en a pas. La MMU permet de contourner le problème que je soulevais sur la pile non relocalisable et dans le lien qu'à donné Rocky, le type explique qu'il a developpé son OS sur une machine équipé d'un 6502 et d'une MMU. Il dit aussi que la version C64 de son OS n'est pas vraiment multitache car il n'y a pas de MMU dans le C64.

C'est bien ce qui me semblait. Par contre je suis surpris ça existe une MMU pour 6502 ? C'était pas apparut à partir des processeurs 16 bits ?

Sur ce point je dois dire que c'est vrai. Au début, quand je suis arrivé ici, j'ai clairement mis en doute l'intéret du mode monochrome haute résolution. Mais la lecture de plusieurs revues d'époque m'ont démontré que la majorité des logiciels de travail en tiraient partit et que le moniteur monochrome du ST était unanimement reconnu comme un plus. Plus tard, j'ai moi même reconnu que j'avais eu tord pour le mode monochrome que j'avais traité d'obsolète.
Je me demande, pourquoi Atari n'a pas sortit un moniteur couleur capable en plus d'afficher le monochrome haute résolution ? Ca aurait été trop cher ?

Et oui, c'est une question de prix. Un amiga pouvait afficher de la haute résolution non entrelacée et en 16 couleurs : Génial... Sauf que pour en profiter il fallait se payer un moniteur qui valait le prix de 2 A500 minimum ! C'est seulement quand les moniteurs VGA ont baissé qu'on a pu avoir de la vrai haute réolution sur le mig, c'est à dire bien des années après le ST...

Je me souviens en effet d'un moniteur appelé "haute rémanence" sur Amiga qui coutait fort cher.
Ce qui confirme la pertinence du mode monochrome sur ST. Voici un des éléments en faveur du ST et qui me parait, maintenant, plus discutable.
Je me demande, l'Amiga aurait t il pu utiliser un moniteur monochrome ou noir et blanc peut cher pour afficher sa haute résolution (mais en niveau de gris). La je sens que je fais me faire démolir, mais tant pis :)

Oui, il me semblait bien avoir lu que le multiTOS ne brillait pas par sa compatiblité.
Par contre, Cubase n'a t il pas eu une version Amiga ? Il me semblait bien que oui ?

Je ne sais pas.

http://www.steinbergusers.com/cubase/cubase_legacy.php

Voici en 1986, pro24 est ce que c'est ça ?

[ryosaeba]

Pour info et en haute résolution (640*400) sur Ste:

http://www.pouet.net/prod.php?which=12237

Really impressive hardcore coding: the routine displays 640x400 images with up to 14,000 colours on STE machines using a blend of techniques (midres, palette/scanline interlace and blitter palette-shiftings).

[ryosaeba]

Pour la lynx, mais c'était connu:

http://www.atariage.com/forums/topic/173172-atari-lynx-development-system-epyx-amiga-binder/

[drfloyd]

rhaaa si le STE était sorti en fin 1988 à 2490 francs...

et pas en 1990 a 3490f ! (plus cher que le ST de 1987 !!!!!)

[MikeeMike_2008]

qu'il soit même sorti en 79 (à la place de la vcr) c'est la même il restera toujours moins bon que le mig :lol:

et même s'il le donne ça ne change rien :lol:

et pour la démo du ste....... faut juste lire les petits commentaires en dessous ......"Never worked on my 4 MB STe"
il faut quoi comme config pour la faire fonctionner cette démo de paradox ???? :lol:

peut-être celle-ci ......... "Works fine on my 4MB MegaSTE" :lol: :lol: :lol: :lol:


quand on parle des extentions sur le mig.....comme la ram (512ko), AR3..... le ste c'est encore pire même avec 4Mo de ram (plus que le 1200 !!!!) ...... pour un résultat

[ryosaeba]

qu'il soit même sorti en 79 (à la place de la vcr) c'est la même il restera toujours moins bon que le mig :lol:

et même s'il le donne ça ne change rien :lol:

et pour la démo du ste....... faut juste lire les petits commentaires en dessous ......"Never worked on my 4 MB STe"
il faut quoi comme config pour la faire fonctionner cette démo de paradox ???? :lol:

peut-être celle-ci ......... "Works fine on my 4MB MegaSTE" :lol: :lol: :lol: :lol:


quand on parle des extentions sur le mig.....comme la ram (512ko), AR3..... le ste c'est encore pire même avec 4Mo de ram (plus que le 1200 !!!!) ...... pour un résultat

La config pour cette demo est un STE (ou mega ste) avec au moins 1 meg.

[stapha92]

Voilà la réponse, j'avais parlé de manque d'optimisation de la version Amiga. Il semble bien que c'était le cas. Du moins d'un mauvais portage depuis le ST. Comme quoi, même un utilisateur sans connaissance en programmation peut trouver par le bon sens les bonnes réponses. Maintenant je pouvais pas le prouver comme cela vient d'être fait.

Le pire, c'est que certaines optimisations auraient été reprises sur les STE si on avait pris l'habitude de les utiliser. J'ai déjà citer l'emploi du blitter pour effacer le buffer ecran. Mais il y en a d'autres, comme le calcul des adresses mémoires par rapport aux coordonnées. Je m'explique : quand tu as déterminé la position X,Y d'un point (ce qu'on fait pour chaque sommet en 3D), tu dois l'utiliser pour calculer l'adresse de l'octet qui heberge le pixel correspondant. Et lors de ce calcul, tu dois par exemple multiplier l'ordonnée par la taille de chaque ligne (160 ou 40 pour affichage en 320). Or la multiplication n'est pas rapide sur un 68000. Il y a donc une astuce simple qui consiste à séparer chaque ligne d'écran par 256 octets afin de remplacer cette opération par un décalages gauche de 8 bits, que le 68000 fait bien plus rapidement (et tu rajoutes l'abscisse avec un MOVE qui est plus rapide qu'un ADD). Et d'autres opérations en bénéficieront de la même façon.
Sur l'Amiga, la souplesse de l'affichage permet d'obtenir cet affichage facilement. Sur STE, il existe un registre d'offset horizontal qui permet d'arriver au même resultat juste en le renseignant avec la valeur 96.

Donc le STE, que tout le monde pensait être meilleur qu'un ST en 2D mais equivalent en 3D peut également le devancer sur ce point s'il est correctement programmé. (et vu ce que je pense du STE par rapport au ST, c'est pas facile à dire )

Et l'Amiga peut bénéficier de davantage d'optimisations...

Je ne m'emportait pas, désolé si j'en ai donné l'impression. J'avais juste mal compris ton propos.

Ne t'excuses pas, j'avais bien compris. le "du calme" était une boutade.

[ryosaeba]

qu'il soit même sorti en 79 (à la place de la vcr) c'est la même il restera toujours moins bon que le mig :lol:

et même s'il le donne ça ne change rien :lol:

et pour la démo du ste....... faut juste lire les petits commentaires en dessous ......"Never worked on my 4 MB STe"
il faut quoi comme config pour la faire fonctionner cette démo de paradox ???? :lol:

peut-être celle-ci ......... "Works fine on my 4MB MegaSTE" :lol: :lol: :lol: :lol:


quand on parle des extentions sur le mig.....comme la ram (512ko), AR3..... le ste c'est encore pire même avec 4Mo de ram (plus que le 1200 !!!!) ...... pour un résultat

Oui le ST/STE est inférieur à l'amiga mais pour une machine que a été developpé en quelques mois, Jack était un génie.

En terme de dévelopement l'amiga a couté plus chère que le St. Mais pour quels résultats ? Dans la pratique, en terme de durée de vie, la différence n'est vraiement pas grande.

[rocky007]

Très joli post, mais ta technique de reprendre de fausses affirmations de ma part pour ensuite les contester est un peu pénible..alors relis mes posts correctement, et débattons en si tu veux...

ça peut tourner sur n'importe quel amiga avec un HD ou une carte. Et c'est du HAM tout simple stocké sous forme de fichier ANIM, un ancien format utilisé sur le mig...

T'es sur que le ST peut suivre avec ses 3 changements de palette par lignes ?

j'ai pas dénigré, j'ai dit que l'utilisation était très restreinte, les problèmes pour avoir un rendu net, et de deux, inexploitable dans un jeu. Oui, pour faire une video, ou un slide show, ça va.
Et oui, je pense que cela est possible sans problème sur un ST.

Et désolé mais rien de tel n'a été démontré ici. tu prétends que ça ne se voyait que sur 4 ou 5 jeux mais tu dois mal connaitre le mig. Tu trouves que la différence ne ne saute pas aux yeux là ?

oui, tu as pris en exemple 1 des 5 jeux difficlement réalisable sur ST. Je ne comprends pas ton débat, on a clairement démontré le puissance d'un Amiga pour les jeux, alors que veux tu de plus ?
On sait très bien que face à un armée de copros, le ST ne peut pas suivre, même si au final il s'en sort très très bien.

Encore une fois c'est faux : un scroll vertical n'a pas besoin de décalage de bits avec un affichage en bitplan (je vais même te dire pourquoi : parce que le balayage tv se fait d'abord horizontalement et que le shifter parcourt des adresses mémoires qui se suivent), donc pas de précalcul.

oui ok, j'ai confondu vertical et horizontal. tu confonds jamais ta gauche et ta droite ?

J'ai pas dit qu'il ne faisait pas appel au copro, j'ai dit que le mig n'avait pas besoin des copro pour ce type de jeu mais uniquement du scrolling hardware. Pour les tiles à préparer et les quelques sprites à afficher, le 68000 suffit.

tiens, pourtant ce n'est pas ce que tu affirmais au début...

Alors que ce jeux n'a même pas besoin des copro pour tourner à 50 i/s sur le mig. Et c'est un jeu du début...

Donc oui, ce jeux est géré par les copros, le 68000 ne servant plus qu'à afficher 4 malheureux sprites et gérer les tiles...

à 9:00 tu as l'un des tableaux bonus et les déformations et les rotations sont en temps réel. Tout ça avec 2 layers...
Et ce jeu est remplit d'effets du même genre (ça commence dès l'intro et ça continue entre chaque tableau).

à 19:15 commence une séquence shoot simple pour le mig mais introuvable sur le ST, même dans un vrai shoot them up.

euh, encore une fois tu as l'air bien sûr de toi... moi tout ce que je vous, c'est un fond précalculé, ainsi qu'une plateforme précalculée également. Et rien du tout infaisable sur ST. Le shoot ? qu'y a-t-il de spéciale ? Le parallax précalculé comme on en faisait sur St depuis la Union Demo ?
Vraiment là, tu as pris le mauvais exemple.

Sur Beast, c'était le plan avec les arbres qui posait problème, ainsi que la taille des sprites.

Ah bon, tu n'étais pas au courant qu'il existait de nombreuse extension de mémoire ? De plus, charger un TOS avec un HD ne prend que qq secondes, je ne vois pas le problème. Le mint était destiné au Falcon, et pas à la gamme ST, même si ceux ci pouvait le faire tourner.

Ah bon, d'un seul coup le chargement n'est pas genant. Content de te l'entendre dire parce que j'ai lu partout ici que le chargement du WB était une hérésie. Donc on est d'accord...
Quand à Mint, ce n'est pas moi qui en ai parlé en premier.
Y avait pas d'extension mémoire sans fer à souder. D'ailleurs le ST est particulièrement pauvre au niveau extension : il n'a qu'un port cartouche ridicule (128 Ko en 2 banques, unidirectionnel) qui n'est pas au niveau de n'importe quelle consoles 8 bits ou de l'atari 800...
[/quote]

Simplement que tu ne te situes pas en 1985. Même un deuxième lecteur de disquette était un luxe immense... alors expliques moi comment tu bosses sur un A500 avec un seul lecteur, et exploiter celui, et son multitâche ? alors les extensions nécessitait un fer à souder ? Et alors ? Tu portais ton Atari au mag, il te l'installais et basta. Où était le problème ? Le plaisir de le faire soi-même ?

Alors oui, côté port cartouche c'était limite.. mais au final ? nous avions qd même tout ce qui pouvait exister..digitaliseur, scanner, etc... et nous avions le SCSI d'origine ainsi que le Midi...

Je suis bien d'accord pour l'argument du gestionnaire de fichier qui était réservé aux personnes qui maitrisaient leur ST. Il est évident qu'un OS a besoin d'un minimum de maitrise pour être bien exploité. Celui du mig étant plus complexe que celui du ST, est-ce vraiment un scandale que sa maitrise soit un peu plus compliquée ?
Et je le répète : pour ce type d'action (formatage, copie, etc...) le ST est plus pratique. Surtout si on part ordi éteint. Mais un OS ne servant pas qu'à ça, je ne pense pas qu'on puisse conclure que ça rendait le TOS meilleur que l'AmigaOS.

non c'est clair pas meilleur, mais plus conviviale à utiliser, ce qui a fait le succès de l'Atari.

Ensuite tu t'obstines à penser que les icones n'ont qu'un role visuel : ce n'est pas du tout le cas sur le mig. Et tu peux mettre les patchs que tu veux, tes icones ne gereront jamais rien sur un ST et ne seront pas spécifiques à chacun des fichiers auquel tu veux en attribuer. Resultat : niveau personnalisation, on sera loin du compte alors que l'on ne parle que de l'aspect visuel. Pour tout le reste, y a aucun patch qui donnera aux icones du GEM les possibilités de ceux du mig.
Et je n'ai pas que ça pour défendre l'Amiga : c'était pour répondre au problème évoqué sur les icones qui n'étaient pas créés automatiquement par le WB. Je pourrai te parler de pleins d'autres choses sur l'OS : du layer hardware à l'auto-config en passant par les écrans draggables, les datatypes, la gestion des devices, les écrans publiques, l'API bien plus fournie, les librairies partagées au code réentrant, le CLI, etc...

ah bon, j'ai souvenance que le newdesk servait justement à ça, attribuer un icone à un fichier précis.

Les fonctions que tu décris ici ? j'ai pas souvenance qu'elles étaient toutes présentes sur le WB 1.3.
Sinon, te souviens tu du GDOS, VDI ? il y a la gestion des fontes vectorielles sur 1.3 ?

Encore un patch ? Et t'arrives à combien de fenêtres ? LOL !!!
Même le TT, la version pro, était limité de ce coté non ?

ah bon, pourquoi sur amiga, il n'y aucun patch entre deux versions de WB peut-être ?

je te rappelle que je répondais aux attaques sur la convivialité. Evidemment que l'ergonomie est faite de détails. Par contre le multitache est quelque chose d'essentiel et tu le traite comme un détail inutile. Moi c'est ça que je trouve un peu ridicule...

et défendre un multitâche sur une A500 sans mémoire, sans HD, sans deuxième lecteur, je trouve également ridicule.

T'as posté ça en t'appuyant dessus pour dire que la version ST est plus colorée et en accusant au passage Babsimov de mauvaise foi.
N'importe quel utilisateur de ST se rend compte tout de suite que ce n'est pas un ST. Y a même pas besoin de regarder, on s'en rend compte rien qu'avec le son.

Tu crois vraiment que cela a été fait exprès ? Justement je porte un point d'honneur à être aussi précis que possible, j'ai fait confiance au titre de la video sans en vérifier le contenu. Désolé. Je ferais moi même la comparaison.

Ah bon ? on peut pas faire de directory ? Première nouvelle... Et tu ne réponds pas sur le fait que toutes les choses que tu dénigres sur le mig sont dans tous les OS modernes ?
Pour la conception et le dev des 2 machines, renseigne toi : c'est de notoriété publique. Et pour garder l'exemple d'Exec, le gars qui s'en est occupé (Carl Sassenrath) est devenu célèbre pour ce travail qui a impressionné (comme d'autres de l'équipe). Y a la même chose du coté du ST ?

ah ben tu vas peut-être m'apprendre qq chose... quand je mets une disquette dans l'amiga pour en connaître le contenu, j'ai..une grosse main qui tiens une disquette... et lorsque je démarre WB et cliques ensuite sur DF0, j'ai...rien non plus...? alors ? il y a une astuce ?

Ta question est : y a t il des gens célèbre chez Atari ?

Ou qui permette au GEM de stocker les préférences d'un directory ? Et tes logiciels tierces, une fois que tu en as mis une tripoté, ça bouffe combien de RAM ?

Quelques dizaines de Ko...pas plus.. il te faut pas 100 accessoires..juste 1 ou 2...

Quand on a fait de l'info, on sait qu'un PC adresse 10 pages de 64 Ko là ou un ST ou un mig adressent plusieurs méga de façon linéaire. Et on en déduit qu'il n'y avait pas de config.sys à se fader pour faire tourner ou installer quelque chose sur le mig (tout comme le ST d'ailleurs). Un clic pour lancer le programme ou l'installation et c'est tout. Comparer le WB au DOS est aussi drole que de le comparer au TOS. Sans compter qu'on devait jouer avec le config.sys pour configurer les périphériques alors que le mig avait déjà l'auto-config, qui est l'ancetre du plug & play...
Maintenant je voudrais que tu m'expliques : qu'y avait-il de compliqué à utiliser ou installer une appli sur le mig ?

quand je parlais de config.sys et autoexec.bat, je ne parlais pas de la gestion de mémoire, mais le côté laborieux pour démarrer un logiciel sur Amiga. Ce que je constate c'est que pour démarrer ton deluxe paint en 30 sec au lieu de 2m30, tu as dû re-créer une disquette avec ta propre startup sequence...

Je parlais pas du STE (qui est pour moi une bouse, contrairement au ST qui mérite du respect). J'ai dit qu'en utilisant un entrelacement comme sur le ST, le mig c'était 29791 couleurs. Tu sais comment fonctionne le système ? Alors fais le calcul : Un mig ou un STE arriveront à 29791 couleurs. tant que tu y es, refais le calcul pour le ST et tu obtiendras 3375 couleurs. C'est pas les 4096 qui étaient affichées sur les boites de certains logiciels de dessin et sont régulièrement annoncées par les STistes comme si le principe pour les afficher était spécifique au ST. Et pour afficher 4096 couleurs simultanément sur un STE, il faut faire bosser le 68000 à fond. Pas sur l'A500 sorti bien avant...
Un bon moyen de mesurer les capacités d'affichage d'une machine est de calculer la quantité max de données transférées en 1 trame. un CPC c'est 16 Ko, un ST(E) c'est 32 Ko, un A500 c'est plus de 100 Ko... Tu continues à penser que ST et Amiga sont du même niveau ?

je n'ai jamais parlé d'entrelacement, j'ai juste parlé de 512 couleurs sur St et 4096 sur un STe sans entrelacement. tu pars dans un débat qui n'existe pas.

On parle pourtant d'un controleur mémoire bien plus simple à concevoir que celui du mig. Pour info : un Atari 800 ou un C64 ne gachent aucun cycle quand l'affichage n'en a pas besoin et ont un controleur mémoire qui commute aussi vite que nécessaire...
Donc une instruction pourra prendre plus de cycles (et jamais moins !) sur un ST : ce n'est pas si grave qu'il n'y parait mais ça va à l'encontre de la légende des STistes qui prétendent que le 68000 s'exprime mieux dans un ST. Dans la vraie vie, c'est exactement le contraire...

et voilà, encore un faux débat... tu ne lis jamais mes post ? j'ai pourtant clairement indiqué : Les instructions 68000 s'exécute en multiple de 4 cycles sur Atari. Mes 33% sont la déduction de ta fausse affirmation :

le 68000 du ST perd des cycles : Si une instruction prend 6 cycles sur le mig, elle en prendra 8 sur le ST...

Avec cette phrase tu insinues que TOUTES les instructions 68000 prennent systématiquement 2 cycles de plus, ce qui est bien entendu faux, et c'est pourquoi que j'ai déduis 33% de lenteur supplémentaire sur ST selon toi.

alors moi aussi je peux prendre un ex :

- Move.w (A0)+,D1 : 8 cycles sur le ST, 8 cycles sur l'Amiga

Avoue que ces exemples ne s'appuient pas sur des instructions rarement utilisées...
Et médites sur le gachis de porter un code ST optimisé pour limiter la pertes de cycles sur le mig là ou ce dernier aurait été plus rapide avec l'algo avant l'optimisation des cycles. C'est ce qui se passait au début...

et toi médites sur le pourquoi, un code porté d'un Atari (qui perd des cycles à tour de bras) sur Amiga
( qui est parfait), est finalement plus lent sur Amiga ?

Oui, Interphase est plus rapide sur ST. Et je peux te citer pleins de jeux dans le même cas (même en 2D). ça montre juste qu'il n'était pas bien programmé sur le mig. C'est toujours la même histoire : on code l'original sur le ST et comme le mig arrive à s'en sortir à peu près, on se contente de recompiler. Maintenant, sur pleins de jeux 3d ce n'était plus vrai alors que je n'ai vu aucun jeu correctement optimisé. Si on s'était juste contenté d'utiliser le blitter pour effacer l'écran, le même jeu 3d serait plus rapide sur le mig (d'autant que j'ai expliqué au-dessus comment une partie de la fréquence plus élevé du 68000 était bouffée par l'architecture). Je ne parle pas des jeux 3D avec un son à base de samples : couteux sur ST et gratuits sur le mig. A noter que le principe est applicable pour le STE : grace à une utilisation minimal du blitter, stunt car racer aurait pu être plus rapide dessus.
je ne parle pas du fait que le blitter du mig sait tracer des lignes et faire des remplissages bien plus vite que le 68000 : là on aurait pu avoir des jeux 3d bien plus fluides encore...

très intéressant... mais pourquoi alors on n'a JAMAIS vu un jeu 3D sur Amiga plus rapide ?
Ou même dans une démo ? Cela veut-il dire que strictement personne n'utilise le blitter ?

Si tu n'utilises pas le blitter ou le copper, le 68000 n'est absolument pas ralenti car le controleur DMA du mig ne prend que le strict nécessaire lui (alors qu'il tourne 2 fois plus vite et gère bien plus de canaux...) et quand tu les utilises, ils font le travail bien plus vite que le 68000 (>10 fois plus rapidement pour le blitter). Et dans un Amiga avec fast-ram, le 68000 n'est jamais gené.
Dans le ST, le 68000 est TOUT LE TEMPS gené par l'architecture. Donc non : il s'exprime moins bien. Tu peux ranger ton "de plus, il est vrai..." car c'est bien ce que j'ai dit : une légende des Stistes fondée sur rien...

j'aime bien....tu le dis toi-même..quand l'amiga n'utilise pas le blitter ou le copper...ce qu'il fait justement dans la plupart des cas...

Ah oui ? un formatage en multitache en travaillant normalement ? Et que ce passe-t-il si tu lances un programme qui utilise aussi des interruptions ? Ou s'il contient des adressages absolus ? Même Windows 3.1 avec son multitache coopératif n'y arrivait pas : j'ai raconté dans le topic fight comment j'ai flingué une disquette en essayant de la formater en tache de fond sous ce système...

Je ne connais pas de softs sous gem utilisant des interruptions.. donc ce cas doit être plutôt rare.
sinon au pire, tu avais l'action replay

Et j'attend toujours ton exemple du multitache sous TOS ou tu formates, écoutes un mod et compresse un fichier...

tu sais parfaitement que c'est possible sous Geneva/mint etc..

Tout cela me donne raison : le 6502 n'est pas doué pour faire du multitache et pourtant il est très fort pour la gestion des interruptions (et il a moins de registres à sauvegarder qu'un 68000). Et note que l'auteur explique que la version C64 sans MMU ne peut pas être considéré comme multitache mais multi-thread (et là pas de pile à préserver...)
Bien sur que du vrai multitache est possible sur C64 mais je maintiens que c'est trop couteux en ressources.
Donc tu me contredit avec un lien qui me donne raison : tu penses toujours que c'est moi qui suis ridicule ?

Je n'ai jamais contesté le problème technique en soi, mais ton affirmation qui disait de base était que le multitâche sur C64 était IMPOSSIBLE.

EDIT : je rectifie, en effet, tu n'avais pas dit que c'était impossible.

Je t'ai donné l'exemple d'une modélisation que tu fais dans un logiciel dédié pendant que le rendu se fait sous POV : impossible sans multitache. Il y a pleins d'exemples : comme celui d'une impression en couleurs (tu te souviens de la vitesse des jets d'encre de l'époque ?). ça permet pleins d'autres choses, comme l'ajout des commodities dans le WB qui apportaient un vrai confort et qui sans cela n'aurait été que des accessoires (mais non limités en nombre...)

je ne vois pas trop le rapport avec POV. En cas le multitâche est indispensable ?
Pour le reste, tu te trompes encore d'époque..nous parlons de 1985, WB 1.3

Maintenant, les STistes n'arretent pas de nous sortir des OS multitaches sur le ST en oubliant que dans ce cas là, on perd pas mal de RAM et la compatibilité avec les logiciels du TOS : Cubase (qui est un bijou dont peut rever le mig) tourne sur Mint ?... Hmmmm...

oui là je te donne raison, Amiga a fait un projet "visionnaire" (...copie d'unix ) à long terme avec son AmigaOs, et forcement, ayant de bonne fondation, la suite coule de source. On ne patch pas outrageusement un TOS et espérer un compatibilité à 100%. C'était le dilemme de l'époque : respecter le GEM et avoir un soft poussif, ou sortir des sentiers battus et se retrouver avec un soft incompatible. Mais je pense que le problème également avec les softs sur A1200 ??

L'AmigaOS que tous les STistes se plaisent à descendre, existe aujourd'hui sous 4 formes :
- AmigaOS 3.9 : dernière version utilisable sur 68000 ou 68000+PowerPC
- AmigaOS 4.1 : version pour les machines powerpc
- MorphOS : idem
- AROS : portage multi-plateforme

Ben sur St nous avons :

Tos : Freemint, Mint, SpareMint, Geneva, EmuTos,
Gem : XaAES etc...

[rocky007]

Ok, puisque tu ne me crois pas, essai cette disquette dans un A500 :

En effet, je ne te crois pas... et j'ai testé : 1:06 avant de tomber sous WB 1.3...on est très loin de tes 20 secondes.

Pour la deuxième disquettes, je te donnes raison...ça prend moins de 10 secondes... pour planter

[ryosaeba]

20 sec c'est avec un HD non ?

Ou avec Winuea avec l'option D7 boosté :)

[rocky007]

ah ok, alors si c'était sur HD...c'est autre chose...

[rocky007]

à mon avis tu as essayé d'installer ton Win 98 sur ton Amiga...parce que sur mon Pentium 1 de l'époque, ça tournait sans aucun problème...

Win95 et 98 ne sont pas préemptif, et pourtant, ça marche très bien non ?
Si les programmes sont bien écrit, ça ne pose aucun problème...

Ah bon ? Première nouvelle ! Encore une ineptie de ta part : ils sont préemptifs tous les 2. C'est bien pour ça qu'ils sont d'un autre niveau que 3.1...

Sur que dans ce cas là, on comprend que tu penses que le coopératif est aussi bien que le préemptif...

Je cite Wiki :

Le multitâche coopératif est une forme simple de multitâche où chaque processus doit explicitement permettre à une autre tâche de s’exécuter. Il a été utilisé, par exemple, dans les produits Microsoft Windows jusqu’à Windows 3.11 ou dans Mac OS jusqu’à Mac OS 9.

Le cas de Windows 95 (ainsi que de windows 98 et ME) est particulier dans le contexte du multitâche. Ces systèmes embarquent en effet un multitâche « hybride », dans certains cas agissant en multitâche préemptif, dans d'autres, en multitâche coopératif.


Pour ton info, Mac OS 9 est sorti en octobre 1999...

[rocky007]

L'AmigaOS est une copie de Unix plus économe en ressources. Or Unix a été créé en 1969 sur des machines bien moins puissante qu'un ST ou un AMIGA. Il a prix son essort en 1974 sur des machines qui avaient à peu près la moitié de puissance processeur d'un 68000. Tiens tiens... Bizarre... Continuons. En 1985, le top du top c'était une station SPARC de SUN : ça tourne avec UNIX et une interface graphique et c'était considéré comme le top du top: Pourtant, au niveau puissance CPU, c'est pas le pérou : à peu près 4 fois la puissance d'un 68000 pour un système bien plus lourd (et SANS les copros du mig pour l'interface graphique...).
D'ailleurs SUN voulait commercialier des Amiga 3000 avec UNIX (implémenté sans utiliser les copros). L'accord a échoué mais Commodore a quand même sorti le modèle pour les pros.

en effet très bizarre que lorsqu'on lance 2 tâches, plus rien ne va et ça plante...quelle puissance phénoménale..

[babsimov]

Voilà la réponse, j'avais parlé de manque d'optimisation de la version Amiga. Il semble bien que c'était le cas. Du moins d'un mauvais portage depuis le ST. Comme quoi, même un utilisateur sans connaissance en programmation peut trouver par le bon sens les bonnes réponses. Maintenant je pouvais pas le prouver comme cela vient d'être fait.

Le pire, c'est que certaines optimisations auraient été reprises sur les STE si on avait pris l'habitude de les utiliser. J'ai déjà citer l'emploi du blitter pour effacer le buffer ecran. Mais il y en a d'autres, comme le calcul des adresses mémoires par rapport aux coordonnées. Je m'explique : quand tu as déterminé la position X,Y d'un point (ce qu'on fait pour chaque sommet en 3D), tu dois l'utiliser pour calculer l'adresse de l'octet qui heberge le pixel correspondant. Et lors de ce calcul, tu dois par exemple multiplier l'ordonnée par la taille de chaque ligne (160 ou 40 pour affichage en 320). Or la multiplication n'est pas rapide sur un 68000. Il y a donc une astuce simple qui consiste à séparer chaque ligne d'écran par 256 octets afin de remplacer cette opération par un décalages gauche de 8 bits, que le 68000 fait bien plus rapidement (et tu rajoutes l'abscisse avec un MOVE qui est plus rapide qu'un ADD). Et d'autres opérations en bénéficieront de la même façon.
Sur l'Amiga, la souplesse de l'affichage permet d'obtenir cet affichage facilement. Sur STE, il existe un registre d'offset horizontal qui permet d'arriver au même resultat juste en le renseignant avec la valeur 96.

Donc le STE, que tout le monde pensait être meilleur qu'un ST en 2D mais equivalent en 3D peut également le devancer sur ce point s'il est correctement programmé. (et vu ce que je pense du STE par rapport au ST, c'est pas facile à dire )

Et l'Amiga peut bénéficier de davantage d'optimisations...

J'avoue que j'ai pas toujours tout compris en détail, même si globalement je saisit le concept de l'astuce donnée. Je pense qu'un programmeur expérimenté saisira plus clairement ce que tu décrit.
Mais ce que je retient c'est que le STE n'a pas été exploité à son plein potentiel.
Tu dis que tu trouves que le STE n'est pas une bonne machine par rapport au ST. Tu lui reproches quoi exactement ? D'avoir simplement voulu rattraper techniquement l'Amiga ? Une mauvaise conception ?
Attention, que ce ne soit pas mal interprété, je pose des questions je n'émet aucun jugement sur le STE.

Je ne m'emportait pas, désolé si j'en ai donné l'impression. J'avais juste mal compris ton propos.

Ne t'excuses pas, j'avais bien compris. le "du calme" était une boutade.

Autant pour moi :)

[ryosaeba]

[rocky007]

[quote="stapha92"]
Tu compares quoi là ? Un Dpaint qui est stocké sous forme compressée avec une disquette originale ? Tout le monde sait que la décompression permet de gagner du temps sur le chargement en raison de la lenteur du lecteur disquette...[quote]
ah bon ? je pensais que c'était surtout gagner de la place sur sa disquette.... tu veux vraiment que je poste une video avec un Dpaint décompresser et comparer si cela va plus vite à charger qu'à décompresser ? allez, tu es un gars intelligent,...soyons sérieux..

Ou as tu vu qu'un programme court prend moins de cpu ?

où ais-je parlé de cela ? je parlais de la place mémoire prise par cette boucle.

En fait, ta boucle demande 100% de cpu : avec ton fameux multitache coopératif, toutes les autres taches seraient bloquées. Et l'exemple de la démo est mal tombé : elle prendra moins de % cpu que ta boucle car elle attend par moment la vbl.

tout dépend comment la boucle est construite. tu devrais savoir ça...

Et, au fait, le programme qui s'execute ne fait pas 10 octets car c'est le GFA qui tourne (et lui qui prend de la mémoire)... Mais même si tu le compiles, ça ne changera rien puisque les ressources CPU n'ont rien avoir avec la taille du programme qui s'executent...

c'est vrai wow t'es un vrai mathématicien toi !! arrêtes de sortir mes propos de leur contexte. le contexte était : super le multitache, quand tu codes, tu peux en même temps écouter un module et dessiner sous Dpaint. J'ai donc démontré qu'avant une simple boucle prenant 10 octets ( en plus du GFA, mais je pense que tout le monde comprend que le GFA reste en mémoire non ? ), ça bouffait déjà trop de ressource mémoire et CPU.. et donc que demander de coder un soft normal sous GFA avec des mallocs etc..?

Profites de la disquette pour comparer la réactivité d'un Dpaint seul ou avec le WB (tu peux même t'amuser à ouvrir des gadgets comme l'horloge) et tu ne sentiras aucune différence. Tu es d'accord pour dire que le WB + des gadgets est bien plus long que ta boucle ?

tu perds ton temps, ici on démontre l'utilité au quotidien du multitache sur un A500 de base... oui en effet, tu peux lancer une horloge...ou un module..voilà, on a fait le tour.

[babsimov]

Y avait pas d'extension mémoire sans fer à souder. D'ailleurs le ST est particulièrement pauvre au niveau extension : il n'a qu'un port cartouche ridicule (128 Ko en 2 banques, unidirectionnel) qui n'est pas au niveau de n'importe quelle consoles 8 bits ou de l'atari 800...

Simplement que tu ne te situes pas en 1985. Même un deuxième lecteur de disquette était un luxe immense... alors expliques moi comment tu bosses sur un A500 avec un seul lecteur, et exploiter celui, et son multitâche ? alors les extensions nécessitait un fer à souder ? Et alors ? Tu portais ton Atari au mag, il te l'installais et basta. Où était le problème ? Le plaisir de le faire soi-même ?

La c'est quand même pas en faveur du ST de devoir aller faire souder son extension mémoire. Si t'a pas de revendeur agréé à proximité tu fait quoi ? Tu l'envoie par transporteur ou tu dois te déplacer en personne.
Sur l'Amiga, la trappe d'extension s'ouvre facilement, tu glisse l'extension à l'intérieur et tu referme. Cinq minutes pas plus et à la portée de n'importe qui. C'est même pas une question du plaisir de le faire soi-même, c'est juste que c'est bien plus pratique pour l'utilisateur. Surtout qu'en plus de la trappe d'extension mémoire du 500, sur le coté il y a le port d'extension pour y brancher tout ce qu'on voulait.

Alors oui, côté port cartouche c'était limite.. mais au final ? nous avions qd même tout ce qui pouvait exister..digitaliseur, scanner, etc... et nous avions le SCSI d'origine ainsi que le Midi...

Ca c'est un bon point pour le ST, en effet. Avoir du SCSI était vraiment bien, surtout d'origine. Il me semblait que c'était du ACSI, était ce réellement compatible avec les périphériques SCSI standards ?