Re: GUERRE ST-AMIGA, FIGHT !!!

[babsimov]

Merci à tous pour vos réponses concernant le "hors sujet".

Je vois que là aussi les avis peuvent diverger. 

J'avoue que j'étais plus ou moins de l'avis qu'on optimise plus, fait plus d'effort etc...

Mais, la réponse de Seb m'a permis d'avoir le point de vu de l'intérieur de mieux comprendre pourquoi l'assembleur a été délaissé au profit de langage plus évolué. C'était des plus intéressant (ce qui ne veut pas dire que les autres avis n'était pas intéressants aussi).

[rocky007]

Mais, la réponse de Seb m'a permis d'avoir le point de vu de l'intérieur de mieux comprendre pourquoi l'assembleur a été délaissé au profit de langage plus évolué. C'était des plus intéressant (ce qui ne veut pas dire que les autres avis n'était pas intéressants aussi).

il faut aussi ajouter que les compilateurs de nos jours fonctionnent vraiment très bien

[babsimov]

je ne me souvenais pas que tu avais expliqué cela, au contraire, lorsque je disais que le multitâche était justement source de guru à gogo , tu niais cela.

pourtant , l'auteur du livre qui est un spécialiste amiga l'a clairement indiqué : faire tourner plusieurs applications sérieuses sur amiga est comme construire un château de carte.  c'était exactement le ressenti que j'avais à l'époque.

Je n'ai pas nié qu'il y avait des guru, j'ai nié, comme tu le disais que l'AmigaOS se résumait à guru sur guru.

Comme je l'ai dit, au fil des 10 ans d'Amiga, j'ai eu des guru, mais pas plus que ça. Sinon, si je n'avais pas pu travailler sur l'Amiga, j'aurai cherché une autre machine. Au début des années 90 beaucoup de monde autour de moi avait des PC (pour jouer principalement) et il y avait des jeux qui étaient mieux sur PC à cette époque (Wing Commander/Dune me viennent à l'esprit)... J'ai plus d'une fois lorgné vers l'achat d'un PC... Mais MS-DOS/Windows 3.1 c'était même pas possible pour moi en ayant connu l'AmigaOS 1.x (pourtant celui qui était réputé le moins stable)... J'ai attendu que Commodore sorte la génération AGA et je n'ai pas regretté, ce fut presque comme une redécouverte de l'AmigaOS avec le 3.x.

Donc, oui, ce problème de guru existait, mais c'était souvent en testant des petits logiciels domaine public pour voir si c'était bien et/ou pratique de l'avoir tous les jours d'installé. Et, rapidement, la communauté Amiga à fait le tri dans les DP fiables et ceux qui ne l'étaient pas. Alors, bien entendu, parfois, il y avait un guru par ci par là... comme parfois, par ci par là, il devait y avoir des bombes sur le ST et comme il y avait des plantages ou "freeze" sur Windows 3.1/95... Comme je l'ai dit, TOUTES LES MACHINES PLANTENT.

EDIT : et en plus, pour te montrer que je ne nie pas les guru, je pense t'avoir expliqué dans une anecdote que j'avais installé un petit utilitaire qui interceptait les messages des guru (dont la signification n'était pas claire pour un néophite). Ce petit programme dont j'ai oublié le nom (c'était que 1.3) ouvrait une boite de dialogue, en donnant en clair le type de problème. Et dans la majorité des cas, il y avait un bouton qui s'affichait "résoudre" et le problème du guru était réglé tu pouvais continuer à travailler. Bien entendu, il y avait des cas ou là c'était reboot obligatoire (mais c'était une boite de dialogue, tu avais la possibilité de sauvegarder ton travail, sauf si le programme fautif était celui sur lequel tu travaillait). Note que je dis bien le 1.3, après sur le 3.x je n'ai pas ressentit le besoin d'un tel programme (si tant es qu'il existait en version pour le 2.x et 3.x).
Alors, est ce dommage que Commodore n'ai pas inclut ce petit programme de base (ou un truc similaire) dans l'OS... certainement... est ce un problème qu'il n'y ait pas eut de ressource tracking et de protection mémoire dans l'OS... probablement, même si au fil des évolutions de l'OS il semble bien que Commodore avait fait ce qu'il fallait pour que ça n'ait plus trop d'impact sur la stabilité du système (pédagogie auprès des développeurs, meilleurs optimisation du multitache (ce n'est qu'une supposition de ma part)). 

Le problème était, pour moi, que TU laissait trop souvent entendre que, limite, dès que tu lançait deux programmes sur l'Amiga, c'était guru systèmatique. Ce n'était pas vrai. 
EDIT : voir même que le simple fait de lancer quoi que ce soit sur Amiga, c'était guru (et celle là tu l'as faite dans une des pages, je sais plus ou, mais je me souviens avoir bondit et répondu aussitôt).

Il est tout à fait possible que la stabilité du 1.0 et 1.1 était plus problématique (j'ai pas connu, je peux rien dire là dessus), mais à partir du 1.2/1.3 c'était utilisable au quotidien. Est ce que tu crois qu'AmigaNews qui faisait toute sa mise en page sur Amiga aurait continué à le faire si en lançant leur traitement de texte et leur logiciel de PAO en même temps, c'était guru ? Et pour que tu me dise pas que c'était à partir du 2.x, la revue à commencé en 1988 (soit l'époque du 1.2).

Je veux bien que tu laisse entendre que j'ai fait de la mauvaise foi (et il est possible que ça me soit arrivé), mais à ce jeu là tu es largement champion et plus d'une fois ça c'est vu. 

Mais, c'est sans rancune.

[babsimov]

Mais, la réponse de Seb m'a permis d'avoir le point de vu de l'intérieur de mieux comprendre pourquoi l'assembleur a été délaissé au profit de langage plus évolué. C'était des plus intéressant (ce qui ne veut pas dire que les autres avis n'était pas intéressants aussi).

il faut aussi ajouter que les compilateurs de nos jours fonctionnent vraiment très bien

Je veux bien te croire sur parole à ce niveau :)

[Seb]

Babsimov: de rien ca fait plaisir. Pour la partie fun et se faire peur avec des chiffres, un jeu dit "AAA" c'est plusieurs (dizaines de) millions de lignes de code C++. Je n'ose même pas imaginer ce que ca ferait en assembleur

[babsimov]

Babsimov: de rien ca fait plaisir. Pour la partie fun et se faire peur avec des chiffres, un jeu dit "AAA" c'est plusieurs (dizaines de) millions de lignes de code C++. Je n'ose même pas imaginer ce que ca ferait en assembleur

Oui, je veux bien croire. Et pour les OS c'est pareil, même le noyau par exemple, l'assembleur c'est fini ? Les compilateurs sont devenus performants à ce point ?

[ryosaeba]

@Seb : Connais-tu les membres de DHS ? Je pense que j'ai déjà vu l'effet du jeux Bran the lion dans une de leurs demos. Maintenant, je peux me tromper mais j'aimerais avoir leur avis sur la faisabilité ou non sur un ST.

[babsimov]

Dans ma précédente réponse liée à ce texte que tu as collé ici, je n'avais fait que survoler l'anglais. Mais, là j'ai un peu mieux lu et que dis l'auteur (en substance) :

"Il était de la responsabilité du programmeur du logiciel de suivre et respecter les consignes de programmation de Commodore afin de s'assurer qu'il n’enfreindrait pas les régles de fonctionnement du multitache d'Exec. Hors, comme il précise, à l'époque (en 1985) que beaucoup de programmeurs n'étaient pas familier avec le multitache, car habitués à écrire pour du monotache." 
Tiens, à la relecture, cette remarque de l'auteur, me laisse supposer que puisque la majorité des programmeurs de l'époque étaient habitués au monotache... le fait qu'ils découvraient (avec l'Amiga) le multitache pour la première fois c'était bien que l'Amiga apportait une révolution par rapport à ce qui se faisait couramment auparavant (sur ce segment de marché informatique pour que ça ne reparte pas dans un long débat qu'on à usé dans tous les sens je pense).

Bref, ce commentaire de l'auteur m'a fait me souvenir, il me semble, que j'avais déjà dit la même chose. Si le programmeur respectait les règles, pas de problème (sauf bug, mais c'était son boulot de les rechercher et les corriger (c'est pas la faute de l'AmigaOS s'il y a un bug dans un logiciel tiers). 

Et donc, les développeurs agréé Commodore recevaient les guides de programmations, allaient au conférence développeurs, ce qui faisait que les logiciels commerciaux étaient stables dans leur grande majorité (on est pas à l'abri de bugs ou de programmeurs sans scrupules qui livraient des versions bétas (moins que ça se fait de nos jours j'ai l'impression, cependant...)

Quel genre de programmeurs reste il en dehors, ceux qui font ça comme un hobby et donc distribuent leur travail dans le domaine publique. Attention, je ne critique pas leur travail (j'étais bien incapable de faire pareil), je dis juste qu'ils avaient, forcément, plus de chance de ne pas respecter des consignes de programmations, puisqu'ils n'en avaient pas toujours connaissance. Et comme je t'ai dit, les petits utilitaires domaine public qui était fiables furent vite identifiés par la communauté. 
Donc, à moins de tester tout ce qui sortait, il était aisé d'avoir un AmigaOS raisonnablement stable. Ca ne veut pas dire que de temps à autre, pour une raison qui m'échappait, je n'avais pas quelque guru, mais certainement pas à chaque boot ou lancement de logiciel comme on pourrait le croire en te lisant.

Par ailleurs, il est facile de dire "l'auteur du livre qui est pourtant un spécialiste Amiga" sans citer le titre du livre ou le nom de cet auteur. Car, ceci peut aussi être un texte tiré d'un livre ou revue pro Atari, ou Anti Amiga... Comme tu es le roi de la mauvaise foi, ça pourrait être tout fait le cas...

Note que cette remarque n'est pas là pour mettre en doute ta parole, parce que, je pars du principe que ta source est une source tout à fait fiable (et d'ailleurs j'aimerais bien le lire ce livre), c'est juste une hypothèse qui m'a traversé l'esprit en ne voyant pas la source citée.

[babsimov]

car j'ai lu ci et là que le multitâche de l'amiga n'était pas si "merveilleux" que l'on le prétend : si le programme était mal codé, ça marchait pas.

Juste pour que tu comprennes bien mon point de vue par rapport au coté "merveilleux" du multitache de l'Amiga... C'est que la réactivé de l'AmigaOS, le coté basculement de tache "instantané", bref ce ressentit là à l'utilisation, même de nos jours, un Windows avec plein de Ghz, dans certaines conditions (basculement entre certains jeu et bureau), ce n'est pas là. Il est bien évident que cela n'arrive pas tout le temps, mais, ça arrive. 
Il me semble, à tord ou à raison, que ce ressentit, que l'on peut résumer par le terme "lourdeur" est partagé par une majorité d'Amigaistes vis à vis de Windows ou encore MAC-OS ou encore Linux.

Tiens, un autre exemple d'une chose qui ne posait pas de problème sur Amiga. 
Sur Windows (95 à seven), imaginons que je veuille personnaliser l'apparence de Windows au delà de ce qui est prévu par les options de personnalisation (changer l'image de boot, changer l'apparence du bouton démarrer, changer le skin des fênêtres, changer l'emplacement des gadget des fenêtres), bref ce genre de chose.
Si tu veux le faire toi même, il faut s'accrocher pour la manipulation à faire, et il est FORTEMENT déconseillé de le faire, parce que la stabilité ou la compatibilité avec les logiciels serait compromise.
On trouves des logiciels commerciaux pour faire ça "clé en main", mais là aussi, il y a des incompatibilités.

Sur Amiga, changer l'apparence du système ne te demandais pas beaucoup d'efforts (bon parfois un peu si tu voulais aller vraiment loin), mais, de toute façon, les logiciels fonctionnaient tout aussi bien après, le système n'en devenait pas instable pour autant.
Tiens, essaye de remplacer le bureau Windows par un bureau qui te plairait mieux... ah ben non on peut pas. Sur Amiga, tu pouvais remplacer le Workbench par Directory Opus ou Scalos (il y en a peut être d'autre que je ne connais pas). Il suffisait de remplacer dans la startup-sequence LoadWB par le programme de lancement de SCALOS (je me souviens plus de comment il s'appelait). Et Directory Opus, c'était encore plus simple, lors de l'installation, il te demandait si tu voulais le faire et s'occupait de tout. Encore une des choses qui sont impossibles sur Windows... Mais, il parait qu'on peut faire ça sur Linux/UNIX (à condition de t'y connaitre)... tiens mais alors l'AmigaOS faisait déjà comme les "grands" il y a 30 ans... qui a dit "avances"... si, je suis sur d'avoir entendu ça au fond du forum, il y a bien quelqu'un d'attentif.... (bon là je te l'accorde j'en rajoute pour essayer de te faire réagir, j'ai bien compris que sur ce point précis de "l'avance" on sera pas d'accord)

Au début de mon arrivée sur PC (Windows 98, puis XP), j'avais essayé de "personnaliser" un peu. Mais, je me suis très vite aperçu que c'était quelque chose qu'il fallait oublier. J'ai mis un petit programme pour changer le fond d'écran régulièrement et c'était tout (et encore, je l'ai enlevé rapidement, parce que, ça faisait ramer). Avant Vista/Seven j'en était arrivé à laisser le thème par défaut parce que je m'étais fait à l'idée que ce n'était pas MON micro, mais le micro que Microsoft me laissait utiliser comme il le souhaitait. Sur Amiga, c'était VRAIMENT MA MACHINE... Personne d'autre n'avait un workbench identique au mien. Je l'avais personnalisé à mon gout. Certes, il y avait une base commune (bien que j'ai vu des copies d'écrans de workbench qui ne ressemblaient plus du tout à un workbench et même c'était superbe). Je me souviens même d'une copie d'écran d'un Worbench 1.3, plein de couleurs (certainement 16 ou 32) qui de nos jours n'aurait pas dépareiller avec les écrans des média player basés sur des distribution Linux. 

Mais, je réalise que j'ai largement dévié du multitache... comme je l'ai dit, quand il s'agit de l'Amiga je m'enflamme vite tant j'ai apprécié cette machine et son OS.

[rocky007]

je ne dis pas le contraire : si un soft est correctement programmé et lancé en même temps qu'un autre logiciel bien programmé, normalement, cela ne devrait pas provoquer de guru.  mais comme tu le soulignes, bcp n'étaient pas habitué  à coder des logiciels qui vont partager des ressources communes ( mémoire, chipset,etc..), ce n'est pas le genre de soucis qu'on a sur un environnement monotâche, et forcément, même dans les logiciels pro, il y a eu forcément des trucs instables.

Parce qu'il ne faut pas croire qu'un pro ne fait pas d'erreur ou de bug.  Il suffit de voir Windows, GEM, WB, bref n'importe quel noyaux qui est censé être parfait puisque le coeur d'un système, pourtant développé dans des équipes de pros, et au final, truffés de bugs.  tu l'as dis toi-même, le WB 1.0>1.2 étaient des foires aux bugs.  ( ils ne pouvaient même pas booter sur un disque dur, ce qui tu l'avoueras, sur un A1000 à ce prix est un peu ridicule )

donc cela pour en revenir que forcément l'amiga plante plus souvent que l'atari, l'atari ne plantera jamais à cause d'un second programme qui va empêtrer sur sa mémoire, ou bloquera tout le processus. et pour cause : il est monotâche !
là aussi, tu le dis toi-même, le OS est sorti en version allégée, loin de ce qui avait été prévu.  ( ressource tracking )

pour le livre, voici le lien :

https://books.google.fr/books?id=z-blqZH2gWwC&pg=PA155&lpg=PA155&dq=amigaos+1.3+bug+list&source=bl&ots=vypPu6E5Cz&sig=slN0_cKWU-052BCluBg7FBmkPz4&hl=fr&sa=X&ved=0CE8Q6AEwBmoVChMIuPib5fjnxwIVhbgUCh14VgFM#v=onepage&q=amigaos%201.3%20bug%20list&f=false

je n'ai lu que quelques pages, mais il semble vraiment intéressant.

"roi de la mauvaise foi"..tu me flattes mais quand même, il y a plus fort que moi ici : quand on parle sérieusement, je sais être sérieux, par contre qd il s'agit de répondre à des trolls, oui là, je me lâche un peu

[stapha92]

babsimov, 

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

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

D'abord les cycles processeurs : 

Le cycle représente l'unité de base temporelle d'un processeur. A chaque cycle, un signal est envoyé par une horloge (un quartz, un oscillateur, etc..) au 68000 via une broche dédiée (l'une des "pattes" du microprocesseur). On dit qu'il est "cadencé". A chacun de ces "tops", des actions très élémentaires sont effectuées par le 68000. Plus la vitesse à laquelle sont envoyés ces signaux est élevée, plus le processeur tourne vite. Mais il y a une limite au-delà de laquelle le processeur ne pourra pas aller. ça peut être parce que les élements internes qui le composent ne pourront pas changer d'état assez rapidement. Ou parce que le processeur se mettra à trop chauffer. En effet à chaque fois que des "actions élementaires" sont effectuées, il y a circulation de courant dans le processeur et donc création de chaleur. Plus le processeur va vite et plus il consomme et plus il chauffe. 

Les 68000 qui se trouvent dans un mig ou un ST sont les mêmes. Mais celui du ST est cadencé à 8 Mhz alors que celui du mig à 7,14. C'est l'horloge qui le controle qui diffère. 

La RAM : 

La RAM d'un ordinateur est divisé en "cases". Dans une architecture 8 bits, chaque case fait un octet (8 bits). Dans une architecture 16 bits, chacune fait un mot (16 bits). Concretement, cela signifie qu'il y a 8 ou 16 fils qui véhiculent la donnée à lire ou à ecrire (en schématisant). Chaque fil correspondant à un bit, il transmet la valeur 0 ou 1. On appelle cet ensemble de fils le bus de données. 
Cela ne suffit pas pour accéder à la RAM : c'est bien beau d'être capable de véhiculer une donnée. Mais il faut également pouvoir indiquer depuis ou vers quelle case le faire. Chacune des cases qui composent la RAM reçoit donc un numéro. Donc en plus du bus de données, on utilise un autre ensemble de fils qui permet d'indiquer le numéro de la case à laquelle on souhaite accéder. Ce numéro de case s'appelle "l'adresse". Ce deuxième ensemble de fils s'appelle donc le bus d'adresse ou d'adressage. Ce système permet d'accéder à n'importe quel case sans contrainte (En fait il peut y en avoir mais on va ignorer çat. De toute façon ça ne concerne pas le ST ou le MIG). C'est à cause de catte faculté que la mémoire est appelée RAM (Random Access Memory). On peut très bien imaginer une mémoire à laquelle on accède à une case en lisant toutes celles qui précèdent de façon séquentielle. ça serait bien de la mémoire vive, mais pas de la RAM. 

Maintenant les RAM ont une vitesse : quand tu veux lire ou écrire une donnée, ça n'est pas immédiat. ça prend un certain temps. Par exemple, 125 nanosecondes. Soit 0,000 000 125 secondes. Donc il sera possible d'accéder à la RAM 8 000 000 de fois par seconde. On parlera dans ce cas de RAM à 125 nanosecondes ou 8 Mhz. On y reviendra. 

Revenons un peu au 68000, représenté par le schéma ci-dessous : 



Si tu observes ce schema, on peut y voir : 

16 broches D0 à D15 : c'est le bus de données qui est bien sur 16 bits. 
23 broches A1 à A23 : c'est le bus d'adressage qui est sur 23 bits. Le 68000 peut donc gérer une RAM de 2 puissance 23 = 8 388 608 mots. Le double si on parle en octet. Ce qui fait 16 Mo. 
2 broches LDS/UDS : elle permettent d'indiquer si le 68000 doit accéder à l'octet qui se trouve dans les broches D0 à D7 (LDS=1, UDS=0), D8 à D15 (LDS=0, UDS=1) ou D0 à D15 pour traiter un mot (LDS=0, UDS=0). Ce système permet au 68000 accéder à un octet seul. Comme un bon vieux 8 bits. Ce n'est pas le cas de tous les processeurs 16 bits. 
1 broche R/W : elle indique si le processeur veut faire une lecture ou une ecriture (Read/Write). 
1 broche CLK : C'est la broche qui reçoit le signal d'horloge (les "tops" donc je parlais au début. CLK = clock. 

Sur la RAM, on retrouve aussi un bus de données, un bus d'adresses et un signal R/W. Si on les relit aux bus du 68000, ce dernier pourra travailler avec la ram. Si elle est assez rapide, il s'exprimera pleinement sans jamais subir de ralentissement. Simple et efficace. 

Mais insuffisant ! Cette RAM ne peut être utilisée que par le 68000 ! Or, pour pouvoir afficher une image contenu dans cette même ram, elle doit pouvoir être accessible par le shifter (ST) ou Denise (Amiga). 

Comment faire ? Et bien on ne va pas relier le 68000 directement à la RAM : on va intercaler entre les 2 un controleur mémoire (MMU dans le ST et Agnus dans le mig). Ce dernier sera d'un coté relié à la RAM et de l'autre à Denise ou au shifter. Un aiguillage qui va changer de coté 7,14 millions de fois par seconde pour le mig ou 4 millions de fois par seconde pour le ST. Donc à chaque fois que cet aiguillage se trouve dans une position, il y a le temps de faire un accès pour le mig ou 2 pour le ST. 
La vitesse à laquelle correspond ce basculement n'est pas un hasard : ça correspond à un cycle processeur pour le mig et 2 cycles pour le ST. Dans les 2 cas, les concepteurs auront prévu une RAM assez rapide pour permettre cet accès dans ce laps de temps. 

L'accès à la RAM est donc ralenti. Mais ce n'est pas grave ! Car le 68000 ne peut absolument pas accéder à la RAM tous les cycles : les instructions les plus rapides prennent 4 cycles. Pas de problème donc. 

Vraiment pas ? Mais si une instruction prend 5 cycles, quand elle sera terminée et que le 68000 aura besoin de lire la prochaine, l'aiguillage sera du mauvais coté et le 68000 devra attendre un cycle de plus ! Et oui ! Sauf que... Aucune instruction ne prend 5 cycles sur le 68000. On pourrait faire le même raisonnement avec un instruction à 7 cycles. Mais on va arreter là : toutes les instruction du 68000 prennent un nombre de cycles qui est un multiple de 2. Il n'y aura jamais de ralentissement. 

C'est ce que se sont dit les concepteurs du mig : puisque le 68000 fonctionne comme ça, on peut se permettre de réserver un accès mémoire sur 2 au chipset. 

Les concepteurs du ST se sont plutot concentrés sur la durée minimum de 4 cycles. la plupart du temps cela revient au même. Sauf que lorsqu'une instruction prend 6 cycles, le 68000 du ST sera obligé d'en attendre 2 de plus pour pouvoir lire l'instruction suivante. Idem pour une instruction qui prend 10 cycles. Le nombre réel sera toujours arrondi au multiple de 4 supérieur. 
Soyons clair : ça n'est absolument pas aussi grave qu'il n'y parait : la majorité des instructions du 68000 prennent déjà un nombre de cycles multiple de 4. 
Simplement, quand Shiraz Shivji expliquait que le bus du ST était plus performant que celui du mig, il mentait à toute la communauté ST... 

Revenons sur le mig. Est-ce aussi simple ? Est-ce que le mig n'est vraiment jamais ralenti ? Voyons ce qui se passe dans un mig avec un écran basse résolution en 16 couleurs : 
(je schématise beaucoup et je triche sur l'ordre. mais ça ne change rien au principe) 

Cycle 1  : Lecture des données du bitplan 1 (16 bits) 
Cycle 2  : Libre pour le 68000 
Cycle 3  : Lecture des données du bitplan 2 (16 bits) 
Cycle 4  : Libre pour le 68000 
Cycle 5  : Lecture des données du bitplan 3 (16 bits) 
Cycle 6  : Libre pour le 68000 
Cycle 7  : Lecture des données du bitplan 4 (16 bits) -> Affichage des 16 premiers pixels 
Cycle 8  : Libre pour le 68000 
Cycle 9  : Lecture des données du bitplan 1 (16 bits) 
Cycle 10 : Libre pour le 68000 
Cycle 11 : Lecture des données du bitplan 2 (16 bits) 
Cycle 12 : Libre pour le 68000 
Cycle 13 : Lecture des données du bitplan 3 (16 bits) 
Cycle 14 : Libre pour le 68000 
Cycle 15 : Lecture des données du bitplan 4 (16 bits) -> Affichage des 16 pixels suivants 

Et ainsi de suite... 

On se rend compte d'une chose : pendant l'affichage, tous les cycles réservés à Denise sont utilisés : Comment faire pour afficher 32 couleurs (5 bitplans) ou 64 (6 bitplans) ? 
Et bien c'est simple : on va utiliser certains des cycles initialement réservés au 68000. Pour 32 couleurs, il nous faut un 5eme bitplan : on va lire ses données pendant les cycles 6 et 14 dans l'exemple ci-dessous. Si le 68000 cherche à accéder à la mémoire pendant l'un de ces cycles, il devra attendre 2 cycles. 
Pour un affichage en 6 bitplans, ce sont les cycles 2 et 10 qui vont être pris. Pourquoi 2 et 10 et non pas 4 et 12 ? Pour s'assurer qu'il y avait toujours un cycle libre entre les 2 cycles perdus. Ceci afin de s'assurer que la latence imposée au 68000 ne dépasse jamais 2 cycles. 

Partant de ce constat, les concepteurs se sont fixés 2 contraintes : 
        - Les cycles ne devront être "volés" que pendant l'affichage. Ainsi, en 320x200x32 couleurs, il y aura 20x200 = 4 000 cycles perdus par frame. Et encore, c'est un maximum : le 68000 ne va pas tomber sur ces cycles à chaque fois. 
        - Ce "vol" de cycles ne devra s'effectuer que si besoin : pas question de laisser ce système activé si on affiche un ecran en 16 couleurs ou moins. 
Il a donc fallu passer d'un controleur mémoire qui se contentait de basculer entre denise et le 68000 à chaque cycles à un controleur capable d'adapter ses basculements au besoin. 
On est passé d'un système statique à un système dynamique. Le ST ne dépassant pas 16 couleurs, il peut se contenter d'un système statique. 

Et ça ne s'arrete pas là ! Et oui : dans le mig, il y a des copro qui peuvent avoir besoin d'accéder à la mémoire. Et le controleur doit pouvoir leur donner acces à la demande : il ne sait pas d'avance quels cycles réserver. Par exemple, il ne sait quand Paula aura besoin de lire un sample à l'avance : il doit lui envoyer quand il y en a besoin (en tout cas c'est le système qui a été choisi dans ce cas, car c'est le plus souple). 
Et il peut même y avoir des demandes d'accès simultanés de plusieurs copro ! Il faudra déterminer lequel doit être mis en attente. 

On n'est plus dans un simple controleur mémoire, c'est un circuit qui doit controler et prioriser toutes les demandes d'accès à la chip ram. Ces demandes peuvent parvenir de plusieurs sources : il y en a 25. Ce sont les fameux 25 canaux DMA du mig... 

Et les concepteurs ont fait du bon boulot : Par exemple, le fait de pouvoir envoyer à Paula un sample à la demande et non de façon régulière et imposée est ce qui permet à Paula de faire des variations de tonalité. C'est ce qui permet au mig de reproduire des mod avec une meilleure qualité que ses concurrents tout en consommant moins de cpu. 
Autre exemple : lorsque le blitter fait une opération et que le 68000 souhaite accéder à la chip-ram, le controleur peut interrompre le blitter juste le temps d'un cycle pour permettre au 68000 de ne pas rester bloqué. D'autant qu'avec de la fast-ram, le 68000 travaille en même temps que le blitter : il aurait été dommage de bloquer son traitement juste à cause d'un accès à la chip... 
Et ça peut être primordiale  par exemple si une interruption est déclenchée : sans ce système, le 68000 ne pourrait pas y répondre (s'il n'y avait pas de fast-ram). C'est ce qui arrive avec le STE : si on utilise le blitter pour déplacer un gros blocs de mémoire, le 68000 étant bloqué, il sera par exemple impossible de faire un changement de palette pour un raster. D'autant que lui n'a pas de fast-ram. 
Atari, pour contourner le problème, avait la solution : il préconisaient de découper le travail du blitter pour ne déplacer qu'un tout petit bloc de données à la fois. Après chaque travail, le 68000 doit redéclencher le blitter. Ce qui lui permet de répondre à une interruption entre 2 travaux du blitter. 
Je te laisse méditer sur l'élégance de la conception de notre "console à disquette" comparé à celle de "l'ordinateur hyper bien conçu"... 

Pour info : dans l'ordre de priorité des canaux DMA, celui réservé au disque (D7 ou HD) est le plus prioritaire. Celui dédié au sprites est le moins prioritaire. A tel point qu'on peut, dans certains cas, perdre l'usage de 1 ou 2 sprites : c'est le seul cas ou un canal DMA n'est plus disponible. 
Le chargement de données était primordiale pour les concepteurs alors que les sprites étaient l'élément le moins important : bizarre pour une machine conçue en tant que console... 

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

Point suivant : qu'est-ce qui change avec l'AGA ? 

Avec l'AGA, la chip-ram passe à une architecture 32 bits. En gros cela veut dire que le bus de données utilise 32 "fils" et non plus 16 pour véhiculer les données à lire ou écrire dans la ram. Donc les données peuvent être lues 2 fois plus vite. En plus la RAM dispose d'un mode spécial qui permet de faire des lectures doubles en rafale. Et Lisa exploite ce mode, ce qui lui permet de lire les données 64 bits à la fois. Donc 4 fois plus vite qu'avec l'OCS/ECS. 
Concrètement, cette fois il n'y a plus besoin de voler des cycles au 68000 dès qu'on dépasse 4 plans en basse résolution. En 256 couleurs, on double la quantité de données par rapport à 16. Comme on lit 4 fois plus vite, on peut afficher ce genre de résolution en n'utilisant que la moitié des cycles réservés à l'affichage. En haute résolution 256 couleurs, on double encore : on atteint le max avant d'être obligé de "voler" des cycles au cpu. Donc un Affichage en 704x288x256 couleurs (ou 704x756x256 en entrelacé) ne provoque aucun ralentissement du cpu avec l'AGA. 

ça se sont les bonnes nouvelles. Maintenant les mauvaises : 

La chip-ram n'est pas accélérée : pour garder la compatibilité sans devoir refaire tout le chipset, Commodore a gardé la fréquence de 7 Mhz. C'est LE gros défaut de l'AGA. 
Et c'est pour cela qu'un A1200 va deux fois plus vite dès qu'on y met de la fast-ram. le 68020 tourne 2 fois plus vite que le 68000 et met moins de cycles (2 fois moins en général) a executer une instruction que le 68000. Pour qu'il soit aussi à l'aise que le 68000 dans l'OCS, il aurait donc fallu que la chip-ram aille 4 fois plus vite. Le passage en 32 bits lui permet de multiplier par 2 sa vitesse et ce n'est pas assez. 

S'ils avaient permit à tout le chipset de pouvoir basculer à 14 Mhz (quitte a pouvoir revenir à 7 Mhz pour la compatibilité), tout aurait été amélioré. Le blitter aurait été 2 fois plus rapide et le copper aussi. Le 68020 aurait atteint la vitesse max sans mettre de fast-ram. etc... 
Ils ont choisi la facilité : ils ont remplacé Denise par Lisa mais ont gardé le reste tel quel. Donc le blitter est le même et le copper aussi. 

Quand à Paula, elle gère le son et les accès disque : elle ne gene pas le 68020. D'autant que la lecture d'un sample n'a jamais demandé beaucoup d'accès mémoire sur le mig. 

Il y a eu beaucoup de spéculations sur ce qu'aurait du être le A1200 : chunky pixel, DSP, j'en passe et des meilleurs. 

Je ne suis pas d'accord avec tout ça : ce qu'il fallait, dans l'idéal, c'est une fréquence doublée pour le chipset et un passage en 32 bits pour tous les copro. Le blitter aurait été 4 fois plus performant ()alors qu'en 256 couleurs on n'a besoin de ne déplacer "que" le double de données). Idem pour le copper (sa résolution aurait de 2 pixels au lieu de 8). Idem pour Paula (ça aurait permit 8 canaux en 16 bits ou 16 en 8 bits). Il aurait également fallu que l'entrée de gamme pour le processeur soit au moins un 68020 à 28 Mhz. 

Un A1200 avec tout ça (Meme pour un prix plus élevé : le A1200 était vendu moins cher que le A500 à sa sortie...) aurait eu beaucoup plus de chance.

[stapha92]

merci stapha92 des renseignements techniques sur les "videos" mais quand on voit qu'il existe seulement des avi de ses videos(facile de remettre ça sur youtube et de dire c'est un st qui fait ça)

Pas de quoi cryodav76.

Le pire c'était ça :

magnifique :

http://atari.8bitchip.info/OverscanOvertake.avi

J'avais téléchargé le fichier : c'est un AVI de 768x576. ça correspond à un signal TNT classique. Et ça n'est pas la résolution annoncée pour les vidéos du ST. L'auteur n'a même pas pris la peine de redimensionner... LOL !!

Que ce soit clair : quand je dis ça, je ne pense pas à Rocky. Il est évident qu'il ne s'est pas amusé à poster des fakes. Il avait l'air si fier de ce qu'il croyait que faisait le ST...

[babsimov]

je ne dis pas le contraire : si un soft est correctement programmé et lancé en même temps qu'un autre logiciel bien programmé, normalement, cela ne devrait pas provoquer de guru.  mais comme tu le soulignes, bcp n'étaient pas habitué  à coder des logiciels qui vont partager des ressources communes ( mémoire, chipset,etc..), ce n'est pas le genre de soucis qu'on a sur un environnement monotâche, et forcément, même dans les logiciels pro, il y a eu forcément des trucs instables.

Ce n'est pas moi, c'est l'auteur du livre, qui souligne le point de la nécessité pour les programmeurs de revoir leur façon de programmer, à cause du passage du monotache (plus facile) au multitache (plus exigeant). Qu'il y ait des trucs instables, ais je dis le contraire ? Par contre, je dis que la grande majorité des logiciels commerciaux étaient quand même suffisamment testé pour que l'Amiga puisse être utilisé au quotidien sans être, comme tu le dis, "Guru à gogo !". Je comprends pas pourquoi tu n'acceptes pas le fait que je te dit que j'ai utilisé mon Amiga pour autre chose que jouer (et j'ai joué aussi) et que je n'ai pas un souvenir d'une machine horriblement instable (j'ai plus de souvenirs de ce type sur Windows 3.1 au boulot qui, sans raison se mettait à freezer.. enfin souvenir précis non, mais je sais que je pestait souvent). 

Parce qu'il ne faut pas croire qu'un pro ne fait pas d'erreur ou de bug.  Il suffit de voir Windows, GEM, WB, bref n'importe quel noyaux qui est censé être parfait puisque le coeur d'un système, pourtant développé dans des équipes de pros, et au final, truffés de bugs.  tu l'as dis toi-même, le WB 1.0>1.2 étaient des foires aux bugs.  ( ils ne pouvaient même pas booter sur un disque dur, ce qui tu l'avoueras, sur un A1000 à ce prix est un peu ridicule )

Là aussi, n'ais je pas dit qu'il pouvait y avoir des bugs... mais, tu ne peux pas imputer l'instabilité d'un système à un bug dans un logiciel tiers... Si le système plante à cause de ce bug, c'est que le programmeur du logiciel n'a pas suffisamment testé son logiciel. 
Quand au noyau Exec, je t'ai expliqué pourquoi il n'a pas eu le ressource tracking... et qui en était en partie responsable (Atari et sa nouvelle direction avec son procès). Je vais pas revenir là dessus. Le problème du 1.0 et 1.1 ont été les mêmes que ceux du TOS 1.0 qui a été dévellopé dans l'urgence en six mois. Aucun n'était totalement pret pour la mise sur le marché. C'est regrettable, mais depuis le début on parlait de mon expérience sur 1.2/1.3... et je te dit que c'était tout à fait utilisable.
Le boot sur disque dur ne fut possible qu'à partir du kickstart 1.3 (je veux dire au démarrage), mais sinon avant il fallait booter sur une disquette de boot qui passait la main au disque dur (je n'avais pas changé mon Kickstart 1.2 en 1.3 et c'est ce que je faisait). Les professionnels ont changé leur kickstart, bien evidemment. Tu vas me dire pourquoi je n'ai pas changé le kickstart ? Tout simplement parce que j'avais un peu peur de le faire faire, qu'il aurait fallu que j'envoi mon Amiga chez un revendeur agréé et que je ne voulais pas être sans ordinateur trop longtemps. Je me suis habitué au petit boot rapide sur disquette. J'avais acheté mon Amiga au moment ou le 1.3 venait de sortir, là ou je l'ai acheté (par correspondance), il devait avoir du 500 1.2 en stock à ce moment là, mais après ceux qui ont acheté un Amiga avait le 1.3 en standard.
Pour donc en finir avec cette histoire de disque dur, certes, et je l'ai reconnu, le SCSI en standard était un plus indéniable en faveur du ST.
Au passage, l'Amiga 1000 n'avait pas son kickstart en ROM, mais dans en disquette qui restait en RAM résistant au reboot, donc dès que le 1.3 a existé, il l'a eu facilement. D'ailleurs, pour beaucoup des premiers Amigaistes l'Amiga 1000 était le vrai Amiga, les autres n'étant que des ersatz (je le sais, à l'époque j'ai renconté un de ces premiers millistes qui m'a tenu ce discours (et c'est là que j'ai vu en vrai un Amiga 1000 (enfin un Amiga comme il disait, il n'aimait pas qu'on l'appel un 1000)). Toujours est il qu'il ne VOULAIT même pas changer pour un 500/2000... c'est donc qu'il trouvait des qualités à l'Amiga alors qu'il avait connu le 1.0 et 1.1. Mais sur ces deux versions je ne pourrais pas aller plus loin, ne les ayant pas connues. 

donc cela pour en revenir que forcément l'amiga plante plus souvent que l'atari, l'atari ne plantera jamais à cause d'un second programme qui va empêtrer sur sa mémoire, ou bloquera tout le processus. et pour cause : il est monotâche !

Excuse moi, mais c'est toi qui ne cesse d'affirmer que l'AmigaOS plantait plus que le TOS... pourtant, ici, j'ai lu des avis différents au fil des pages... malgré que le TOS soit monotache. Et on ne parle même pas de Windows 3.1 sur PC à l'époque qui n'était pas non plus parfait (pourtant c'était bien le monde PRO).

là aussi, tu le dis toi-même, le OS est sorti en version allégée, loin de ce qui avait été prévu.  ( ressource tracking )

C'est, en fait que l'AmigaOS n'est pas le même OS que celui prévu à l'origine...
TRIPOS et CAOS, même s'il semble être proche dans leur concept, CAOS paraissait plus fini. Mais ils n'avaient plus le temps de le finaliser. Le ressource tracking a donc été enlevé d'Exec, parce que, semble t il ça n'était pas prévu dans TRIPOS.
Mais, si tu vas par là, pour quelque chose de sortit à la hate en 6 mois (comme le TOS/GEM), le résultat est quand même au dessus que ce qu'Atari à fait. Ne serait ce que par ses fonctionnalités supplémentaires qui ont été listée ici il y a peu.

pour le livre, voici le lien :

https://books.google.fr/books?id=z-blqZH2gWwC&pg=PA155&lpg=PA155&dq=amigaos+1.3+bug+list&source=bl&ots=vypPu6E5Cz&sig=slN0_cKWU-052BCluBg7FBmkPz4&hl=fr&sa=X&ved=0CE8Q6AEwBmoVChMIuPib5fjnxwIVhbgUCh14VgFM#v=onepage&q=amigaos%201.3%20bug%20list&f=false

je n'ai lu que quelques pages, mais il semble vraiment intéressant.

Je l'avais acheté ce livre. Mais, en fait, je le trouve un peu brouillon dans son style et donc je ne l'ai que survolé.
Par contre, je suis surpris (en fait non) que tu n'es pas donné le titre...."The Commodore Amiga... The future was here". Tiens, c'est marrant, le titre, si je sais lire, ça voudrait dire : "Le Commodore Amiga ... L'avenir est ici". Pourquoi tu n'a pas cité le titre ? Ne serait ce pas parce que ça aurait accrédité le titre de Byte "10 ans d'avances" qui te reste en travers de la gorge ? D'autant plus que ça aurait été un aveux de ta part, puisque tu disais de l'auteur "qu'il était un spécialiste de l'Amiga" (donc qu'il sait de quoi il parle)...
Mais, quand on regarde avec quel terme tu as cherché son livre "amigaos 1.3 bug list"



Et voici ce que j'ai trouvé, en cliquant uniquement sur la couverture en bas à gauche de ton lien

"roi de la mauvaise foi"..tu me flattes mais quand même, il y a plus fort que moi ici : quand on parle sérieusement, je sais être sérieux, par contre qd il s'agit de répondre à des trolls, oui là, je me lâche un peu 

L'exemple juste au dessus en est une belle illustration.
Tu n'allais certainement pas dire que le titre du livre était "Le Commodore Amiga, l'avenir est ici".... alors que ton propos était de trouver un moyen de démonter mes arguments depuis de début (le nom de ta recherche est édifiant). 
Hors, hasard, dans l'un de ceux ci, je te dis que l'Amiga était vu, à l'époque, comme ayant 10 ans d'avances... et le titre du livre semble bien me donner raison. 
C'est certain que ce n'est pas de mauvaise foi de choisir juste le passage du livre qui va dans ton sens, dont d'ailleurs, j'ai reconnu que oui, les premières versions (avant la 1.2) avait probablement plus de problèmes que je le pensais au départ. Mais, je maintient, il était malgré tout possible de travailler sur Amiga, surtout à partir du 1.2/1.3.
Bref, voici une nouvelle preuve de ta mauvaise foi...
Et tu en veux une autre ?
N'ais je pas déjà reconnu que l'AmigaOS avait ses lacunes (y compris dans l'époque 1.2/1.3). Mais, quand on te liste les bugs du ST (reconnus), quand on te donne des exemples des choses que le TOS/GEM était incapable de faire alors que l'AmigaOS/Worbench 1.2 (au minimum) était capable... à aucun moment je ne t'ai pas vu faire amende honorable, bien au contraire (il est possible que cela m'est échappé). En fait, le plus souvent, tu te contente de garder le silence sur ces points là et de chercher de nouveaux arguments de mauvaise foi. Je ne pense pas être le seul à avoir remarqué cette tendance de ta part :)

Et les transputer Atari tournant sous une évolution de TRIPOS, lui même la base de l'AmigaOS... tu as fait amende honorable ? Tu as dit que finalement le TOS/GEM ils n'avaient pas d'autre choix, dans ce cas, de ne pas l'utiliser, parce que faire du calcul parallèle avec un OS monotache, ce doit surement pas être évident ? Mais, c'est vrai, selon toi, le multitache (à cette époque) n'avait aucun intêret !

Mais, sans rancune.

[Urbinou]

Stapha, tu écris que tu vas être barbant, mais que du contraire, c'est un régal de te lire  je n'ai rien appris de ton intro, mais tu trouves les mots justes, c'est parfait. Et puis quand tu rentres dans les spécificités amiga, c'est tout bonnement passionnant (et là j'apprends des choses !!), merci !

[babsimov]

babsimov, 

Je te laisse méditer sur l'élégance de la conception de notre "console à disquette" comparé à celle de "l'ordinateur hyper bien conçu"... 

Merci Stapha92 pour ton explication tout à fait claire et pas du tout "barbante" comme tu le dis. J'ai déjà compris l'essentiel à ma première lecture et je pense que je relirais ça plusieurs fois pour être sur de ne rien avoir manqué.

En tout cas, chapeau à Jay Miner et son équipe, c'est vrai que la manière dont ils ont géré le système de cycle et l'accès mémoire, bravo.

Edit : J'oubliais, j'espère que tes explications feront aussi méditer certains STistes ici. En tout cas, moi je suis en pleine relecture et c'est passionnant et j'admire de plus en plus l'équipe d'ingénieurs qui à conçu l'Amiga. Comme tu le fait remarquer, ils ont, à chaque fois choisit la solution la plus élégante.
Tiens, du coup, je serais intéressé par une comparaison de la gestion des cycles entre l'architecture du 800XL et celle de l'Amiga, si, bien entendu, tu en as le temps et l'envie.

Pour info : dans l'ordre de priorité des canaux DMA, celui réservé au disque (D7 ou HD) est le plus prioritaire. Celui dédié au sprites est le moins prioritaire. A tel point qu'on peut, dans certains cas, perdre l'usage de 1 ou 2 sprites : c'est le seul cas ou un canal DMA n'est plus disponible. 
Le chargement de données était primordiale pour les concepteurs alors que les sprites étaient l'élément le moins important : bizarre pour une machine conçue en tant que console... 

J'ai particulièrement apprécié cette info, comme tu dois t'en douter.

En tout cas, comme à ton habitude, tu as très bien su mettre tes explications au niveau de ton interlocuteur afin que ce soit compris. J'admire cette qualité chez toi, tu es très pédagogue. Merci encore.

[babsimov]

Il y a eu beaucoup de spéculations sur ce qu'aurait du être le A1200 : chunky pixel, DSP, j'en passe et des meilleurs. 

Je ne suis pas d'accord avec tout ça : ce qu'il fallait, dans l'idéal, c'est une fréquence doublée pour le chipset et un passage en 32 bits pour tous les copro. Le blitter aurait été 4 fois plus performant ()alors qu'en 256 couleurs on n'a besoin de ne déplacer "que" le double de données). Idem pour le copper (sa résolution aurait de 2 pixels au lieu de 8). Idem pour Paula (ça aurait permit 8 canaux en 16 bits ou 16 en 8 bits). Il aurait également fallu que l'entrée de gamme pour le processeur soit au moins un 68020 à 28 Mhz. 

Un A1200 avec tout ça (Meme pour un prix plus élevé : le A1200 était vendu moins cher que le A500 à sa sortie...) aurait eu beaucoup plus de chance.

Moi aussi, comme tu as du le lire parfois ici, j'ai beaucoup réfléchit à ce qu'aurait du être le 1200. Bien entendu ce que tu dit n'est pas faux, mais tu es sur que le simple fait d'avoir doublé la fréquence du chipset aurait permis de compenser l'abscence de Chunky (notamment pour les jeux de type Wolfenstein qui se démocratisait à l'époque ?) ou les jeux 3D texturé en général ? 
Un Paula à fréquence double aurait pu jouer 8 canaux 16 bits (alors que dans l'électronique interne il n'y avait que 4 canaux ? Ca n'aurait pas demandé un peu de puissance processeur ?
J'ai souvenir que jouer 8 canaux avec Octamed était réputé pour consommer un peu plus de processeur (j'ignore combien) que 4 canaux (ce qui ne consommait rien). Mais 8 canaux avec Paula la qualité du son était moindre si je me souviens bien. C'est pour ça que je me pose la question avec un Paula à fréquence doublé (mais à l'électronique inchangée), on aurait vraiment pu avoir 8 voies 16 bits ?

En tout cas, pour le 68020 à 28 mhz, c'était ce que j'avais avec ma carte accélératrice (avec 4MO de fast) et jusqu'en 95/96 c'était largement suffisant pour un usage courant. Je peux t'assurer que le jour ou j'ai mis cette carte dans le 1200, dès le boot j'ai vu la différence. J'ai tout suite su que j'avais bien fait de prendre une carte accélératrice.

La configuration idéale que tu propose pour le 1200 me convient, j'y ajouterai juste un mode chunky et un DSP (même optionnel).

[Seb]

Stapha, tu écris que tu vas être barbant, mais que du contraire, c'est un régal de te lire  je n'ai rien appris de ton intro, mais tu trouves les mots justes, c'est parfait. Et puis quand tu rentres dans les spécificités amiga, c'est tout bonnement passionnant (et là j'apprends des choses !!), merci !

Pareil :)

@Seb : Connais-tu les membres de DHS ? Je pense que j'ai déjà vu l'effet du jeux Bran the lion dans une de leurs demos. Maintenant, je peux me tromper mais j'aimerais avoir leur avis sur la faisabilité ou non sur un ST.

Ca ne me dit rien. J'ai demandé à Evil/DHS mais ca ne lui dit rien non plus. Je ne pense vraiment pas que cet effet de logo dans Brian The Lion soit faisable sur ST à la même vitesse. Je ne sais pas comment c'est fait sur Amiga mais sur ST juste au 68000 ca tournerait clairement plus lentement.

[ryosaeba]

Stapha, tu écris que tu vas être barbant, mais que du contraire, c'est un régal de te lire  je n'ai rien appris de ton intro, mais tu trouves les mots justes, c'est parfait. Et puis quand tu rentres dans les spécificités amiga, c'est tout bonnement passionnant (et là j'apprends des choses !!), merci !

Pareil :)

@Seb : Connais-tu les membres de DHS ? Je pense que j'ai déjà vu l'effet du jeux Bran the lion dans une de leurs demos. Maintenant, je peux me tromper mais j'aimerais avoir leur avis sur la faisabilité ou non sur un ST.

Ca ne me dit rien. J'ai demandé à Evil/DHS mais ca ne lui dit rien non plus. Je ne pense vraiment pas que cet effet de logo dans Brian The Lion soit faisable sur ST à la même vitesse. Je ne sais pas comment c'est fait sur Amiga mais sur ST juste au 68000 ca tournerait clairement plus lentement.

Mais est-ce faisable ou non sur un St de base ? Ce n'est pas l'effet du logo mais celui que l'on retrouve dans le jeux (décor arrière).

[rocky007]

Excuse moi, mais c'est toi qui ne cesse d'affirmer que l'AmigaOS plantait plus que le TOS... pourtant, ici, j'ai lu des avis différents au fil des pages... malgré que le TOS soit monotache. Et on ne parle même pas de Windows 3.1 sur PC à l'époque qui n'était pas non plus parfait (pourtant c'était bien le monde PRO).

euh non , j'ai lu aussi des avis dans mon sens   et l'auteur du bouquin le confirme.

Tiens, c'est marrant, le titre, si je sais lire, ça voudrait dire : "Le Commodore Amiga ... L'avenir est ici". Pourquoi tu n'a pas cité le titre ? Ne serait ce pas parce que ça aurait accrédité le titre de Byte "10 ans d'avances" qui te reste en travers de la gorge ? D'autant plus que ça aurait été un aveux de ta part, puisque tu disais de l'auteur "qu'il était un spécialiste de l'Amiga" (donc qu'il sait de quoi il parle)...
Mais, quand on regarde avec quel terme tu as cherché son livre "amigaos 1.3 bug list"

"l'avenir est ici", ça veut pas dire "10 ans d'avance"..  mais si tu veux, je veux bien admettre 3 - 5 ans d'avance

pour la recherche, tu m'as grillé... ben oui c'est pénible que bien évidement les personnes compétentes pour expliquer les points faibles de l'amiga ne le font pas, alors bien obligé de le faire moi même
c'est comme ça, et avec stupéfaction, que je découvre que l'amiga à 20.000FF ne bootais pas sur HD alors que c'est indispensable pour utiliser correctement WB... !!!  alors qu'on reproche qu'on savait pas changer la couleur verte du bureau Atari !!  je suis choqué

N'ais je pas déjà reconnu que l'AmigaOS avait ses lacunes (y compris dans l'époque 1.2/1.3). Mais, quand on te liste les bugs du ST (reconnus), quand on te donne des exemples des choses que le TOS/GEM était incapable de faire alors que l'AmigaOS/Worbench 1.2 (au minimum) était capable...

quoi donc ?  des futilités du genre renommer un repertoire, changer la couleur verte du GEM, démarrer un programme haute résolution dans un répertoire AUTO ?    bah il suffisait d'avoir une Action Replay !





je n'ai pas appronfondit sur le Transputer, raison pour laquelle j'ai laissé en suspend.  mais je ne vois pas vraiment le rapport au final, que l'Atari tourne sur un OS inspiré de TRIPOS qui a lui même inspiré l'AmigaOS ne me pose aucun problème. Il auraient pu utiliser un bon vieux Unix également.

Je ne dis pas que le multitache à cet époque n'a AUCUN intérêt, je dis que sur un A500 avec 512ko de RAM ( ce qui représentait la majorité du parc Amiga ), ne représentait pas une option indispensable.  Sinon oui, j'imagine bien que sur une plus grosse config, 1mb RAM, HD, WB 2.0, cela devait être sympa.. mais là, on est déjà fin des années 90.

[babsimov]

Point suivant : qu'est-ce qui change avec l'AGA ? 

Avec l'AGA, la chip-ram passe à une architecture 32 bits. En gros cela veut dire que le bus de données utilise 32 "fils" et non plus 16 pour véhiculer les données à lire ou écrire dans la ram. Donc les données peuvent être lues 2 fois plus vite. En plus la RAM dispose d'un mode spécial qui permet de faire des lectures doubles en rafale. Et Lisa exploite ce mode, ce qui lui permet de lire les données 64 bits à la fois. Donc 4 fois plus vite qu'avec l'OCS/ECS. 
Concrètement, cette fois il n'y a plus besoin de voler des cycles au 68000 dès qu'on dépasse 4 plans en basse résolution. En 256 couleurs, on double la quantité de données par rapport à 16. Comme on lit 4 fois plus vite, on peut afficher ce genre de résolution en n'utilisant que la moitié des cycles réservés à l'affichage. En haute résolution 256 couleurs, on double encore : on atteint le max avant d'être obligé de "voler" des cycles au cpu. Donc un Affichage en 704x288x256 couleurs (ou 704x756x256 en entrelacé) ne provoque aucun ralentissement du cpu avec l'AGA. 

ça se sont les bonnes nouvelles. Maintenant les mauvaises : 

La chip-ram n'est pas accélérée : pour garder la compatibilité sans devoir refaire tout le chipset, Commodore a gardé la fréquence de 7 Mhz. C'est LE gros défaut de l'AGA. 
Et c'est pour cela qu'un A1200 va deux fois plus vite dès qu'on y met de la fast-ram. le 68020 tourne 2 fois plus vite que le 68000 et met moins de cycles (2 fois moins en général) a executer une instruction que le 68000. Pour qu'il soit aussi à l'aise que le 68000 dans l'OCS, il aurait donc fallu que la chip-ram aille 4 fois plus vite. Le passage en 32 bits lui permet de multiplier par 2 sa vitesse et ce n'est pas assez. 

S'ils avaient permit à tout le chipset de pouvoir basculer à 14 Mhz (quitte a pouvoir revenir à 7 Mhz pour la compatibilité), tout aurait été amélioré. Le blitter aurait été 2 fois plus rapide et le copper aussi. Le 68020 aurait atteint la vitesse max sans mettre de fast-ram. etc... 
Ils ont choisi la facilité : ils ont remplacé Denise par Lisa mais ont gardé le reste tel quel. Donc le blitter est le même et le copper aussi. 

Quand à Paula, elle gère le son et les accès disque : elle ne gene pas le 68020. D'autant que la lecture d'un sample n'a jamais demandé beaucoup d'accès mémoire sur le mig. 

Mais, mon souvenir c'est que l'AGA en 256 couleurs 640x512 ou plus en doublePAL c'était limite inutilisable. Tu parles d'aucun ralentissement en 704x756x256 en entrelacé. J'avoue que j'avais lu que quelqu'un avait dit qu'en 640x512 256 couleurs entrelacé et l'indivision (scan doubleur) l'affichage était 75 % plus rapide que la même chose en DoublePAL. 
Ce problème du DoublePAL (31khz) sur l'AGA était il du à la vitesse de la chip ram trop lente, comme tu le dit dans les "points faibles" de l'AGA ?

Autre question relative à l'évolution du chipset Amiga. A te lire, pour faire évoluer de manière simple et élégante le chipset Amiga d'origine, il suffisait, à chaque révision (en dehors d'ajouter des bitplans) de doubler sa fréquence d'évolution en évolution ? Est ce aussi simple que ça ? Car, j'ai lu ici par les détracteurs de l'Amiga que le chipset Amiga était trop compliqué à faire évoluer ? As tu une opinion à ce sujet ?

[Seb]

Ryosaeba: sur un ST de base le plus proche de Brian The Lion qu'on puisse faire est Enchanted Land.

Donc pas de 2eme léger background différentiel au loin comme les montagne dans BTL (on pourrait mais ca limiterait à 8 couleurs par ligne tout ce qui est au 1er plan y compris le décor qui scroll) et pas de variation de vitesse de scroll horizontal comme dans Brian The Lion, ca demanderait trop de mémoire (ca passerait peut-être sur 1Mo par contre, à calculer). C'est pour ca que le scroll se fait "par zone" dans Enchanted Land, le décor scroll toujours du même nombre de pixels par frame, 4 ou 8 j'imagine, sinon ca ne serait pas possible avec 512k de RAM.

A noter qu'à cause de cette technique qui prend de la mémoire, le jeu n'a aucun double buffering. Donc pour éviter que les sprites ne clignotent, il y a du code qui les affiche au bon moment en fonction de leur position à l'écran à chaque frame.

Enchanted Land arrive à avoir tout l'écran qui scroll grace à la technique du syncscroll. Ca n'est pas un feature du hardware, c'est plus un hack de demomaker qui permet de faire "scroller" l'écran de 16 pixels horizontalement et de 1 pixel ou plus verticalement.

Pour donner l'illusion qu'on scroll de moins de 16 pixels, on doit utiliser des versions décalées du décor sur d'autres écrans, par exemple une de 4 pixels, une de 8, une de 12, donc ca double, triple ou quadruple la taille de la "mémoire video". C'est pourquoi Enchanted Land n'a plus de place pour faire du double buffering (swapper entre 2 écrans pour éviter les clignotements lors de l'affichage du contenu).

[babsimov]

Excuse moi, mais c'est toi qui ne cesse d'affirmer que l'AmigaOS plantait plus que le TOS... pourtant, ici, j'ai lu des avis différents au fil des pages... malgré que le TOS soit monotache. Et on ne parle même pas de Windows 3.1 sur PC à l'époque qui n'était pas non plus parfait (pourtant c'était bien le monde PRO).

euh non , j'ai lu aussi des avis dans mon sens   et l'auteur du bouquin le confirme

Oui, des avis de pro STiste :)

L'auteur du bouquin ne confirme pas "guru à gogo"

Je reprend donc le passage (que tu avait, bien entendu, élégamment tronqué là ou ça t'arrangeait) :



Que dit l'auteur dès le début en substance :

"Que l'AmigaOS était un pionnier des OS multitaches..." Pour que tu ne t'énerve pas, j'ajouterai pour lui "sur le marché du grand public"

Et il dit aussi "et part sa philosophie qui était que tout devait être accessible à l'utilisateur dans un ordinateur et aisément (ou élégamment) modifiable" (tiens, c'est pas ce que je disais ça quelques pages plus tôt ?)

Bien entendu, ce que je viens de citer, tu l'avais coupé, et tu commences à citer qu'à partir du moment ou il dit "que l'AmigaOS manquaient de protections".

Là encore, ais je dis le contraire ? C'est même moi qui ait commencé à te parler d'absence de ressource tracking (et tu t'y es engouffré). J'ai souvenir que tu avais, il y a longtemps, parlé de "sans protection mémoire" et, là encore, ais je contredit ? Non, pas du tout, je t'ai juste dit que c'était le rôle du programmeur d'éviter ce genre de problème (programmeur du logiciel).

Et que dit l'auteur... et bien que l'utilisateur était forcé d'espérer que le programmeur du logiciel avait correctement respecté les règles de programmation du manuel de l'Amiga et évité les bugs... N'est ce pas le cas sur tout ordinateur ?

Mais, il dit aussi "qu'en cas de bug ou non respect des règles" il arrivait trop souvent une visite du guru... N'est il pas exact sur toute machine qu'un plantage est un plantage de trop :)

Alors bon, là il y a un peu de mauvaise foi, à cause du "trop souvent", mais il parle de l'Amiga 1000 (1.0 1.1), sur le 1.2 la stabilité était nettement meilleure, (c'est celui dont je parle pour l'époque 1988-1992 dans mon cas, enfin dès 1988 j'utilise le 1.3 en fait avec le kickstart 1.2).

https://fr.wikipedia.org/wiki/AmigaOS#Kickstart.2FWorkbench_1.0.2C_1.1.2C_1.2.2C_1.3

Tiens, c'est marrant, le titre, si je sais lire, ça voudrait dire : "Le Commodore Amiga ... L'avenir est ici". Pourquoi tu n'a pas cité le titre ? Ne serait ce pas parce que ça aurait accrédité le titre de Byte "10 ans d'avances" qui te reste en travers de la gorge ? D'autant plus que ça aurait été un aveux de ta part, puisque tu disais de l'auteur "qu'il était un spécialiste de l'Amiga" (donc qu'il sait de quoi il parle)...
Mais, quand on regarde avec quel terme tu as cherché son livre "amigaos 1.3 bug list"

"l'avenir est ici", ça veut pas dire "10 ans d'avance"..  mais si tu veux, je veux bien admettre 3 - 5 ans d'avance 

Eh ben tu vois, on progresse. Pour le hardware, je veux bien accepter 5 ans (parce que l'ECS et l'AGA, c'était quand même des "upgrade" au rabais. Par contre pour l'AmigaOS, je maintient 10 ans, car il a bien fallu 10 ans entre 1985 et 1995 pour que le grand public découvre le multitache (moins bien) sur autre chose qu'un Amiga.

Et ne me dit pas que le ST ou Falcon le proposait, car, ce test ici me permet de dire que "oui, c'est vrai", à condition que tu te contentes d'utiliser multitos sur Falcon, sans utiliser la moindre application. 

http://www.atarimusic.net/index.php?option=com_content&view=article&id=263:the-falcon030-vs-the-amiga1200&catid=60:atari-hardware&Itemid=214

Le test devrait te plaire, le Falcon gagne :)
Sur un site Atari, c'est bien le minimum (même si j'ai toujours dit que le Falcon était la seule machine digne d'intêret chez Atari (époque ST et après).

Donc dans le test que lit on ? 

"While the Falcon has its operating system in ROM, the multi-tasking version ships on floppy. There is a good reason for this (Other than it wasn't ready when the Falcon first shipped!), many professional applications would not work well with this new system, especially timing critical programs like Cubase and Logic. For these to run properly, the more common ROM based operating system was used while power users who needed the new functions could install the new operating systems on their hard drives. Even with this installed, there was always the option to boot into the single tasking OS with the use of a control panel applet, which could also configure other options on the machine, like the advanced sound system and the new high speed serial port."

Donc le multitache du Falcon, oui il le faisait, quand il pouvait (c'est à dire en renonçant à ses applications phare, quelle belle évolution... Sur Amiga les logiciels PRO tournaient sans problème en multitache en passant du 1.x au 3.x (sauf ceux qui était programmé sans tenir compte des recommandations de Commodore).

Et finalement la conclusion du test qui donne le Falcon vainqueur par rapport à un Amiga 1200 de base... avec une petite note intéressante :

"Both machines have their merits, but out of the box for processor intensive applications, the Falcon is the better machine. However adding Fast RAM to the Amiga turns it into something that the Falcon could have and should have been, and suddenly for processor intensive tasks, the machine with the 'poorer' processor takes a lead."

A, mince alors, dès qu'on met de la fast ram (sans même un processeur plus rapide), l'Amiga 1200 avec un 68020 à 14 mhz devient meilleur qu'un Falcon avec son 68030 à 16 mhz (pourtant épaulé d'un DSP) pour les applications à usage intensif du processeur... N'est ce pas ce qui a été dit ici ? Car, si on lit bien le test, il est expliqué que le Falcon reprend l'architecture du ST... Donc, ce qui est dit ici depuis un moment, c'est que l'architecture du ST, malgré son 68000 à  8 mhz était moins efficace en tout que celle de l'Amiga. Ce test prouve, une fois de plus, que les ingénieurs d'Atari n'étaient pas aussi bon que ceux de Commodore et que l'architecture de l'Amiga avait, dès le début, été extrêmement bien pensée, autant pour le présent que pour l'avenir, puisque l'AGA, comme l'a si bien expliqué Stapha92, n'est qu'un ECS+ qui est lui même une évolution très mineure de l'OCS.  Mais, je repart sur un long argumentaire, alors qu'au départ je voulais juste te parler du test Falcon VS 1200 et pointer le problème du multiTOS. 

pour la recherche, tu m'as grillé... ben oui c'est pénible que bien évidement les personnes compétentes pour expliquer les points faibles de l'amiga ne le font pas, alors bien obligé de le faire moi même 

Je commence à avoir l'habitude maintenant, c'est pour ça que le critère de recherche m'a sauté au yeux :)

Pour la phrase suivante, je ne sais pas si tu parles de moi ou de quelqu'un d'autre, en tout cas, c'est moi qui t'es parlé de l'absence de ressource tracking et qui dès le début a reconnu ton affirmation sur la protection mémoire (en t'expliquant que bien programmé l'impact était minime).
Tu attendais quoi de moi, que je t'explique en détail le fonctionnement du noyau Exec, que je te fasse un cours sur le fonctionnement du multitache de l'Amiga après que j'ai désassemblé Exec ? 
Je n'ai pas ses connaissances techniques là, je te parle de mémoire et du point de vue utilisateur. La notion de ressource tracking, maintenant, à force de lire ici ou là j'arrive à l'appréhender, mais à l'époque et au moment de mon arrivée ici, certainement pas. 
Quant à la protection mémoire, déjà c'était plus parlant pour moi, mais j'étais et je suis bien incapable de l'expliquer en détail. Tout ce que je sais, c'est, qu'à l'époque, de mon point de vue utilisateur, ces deux fonctions je n'en avais pas conscience et ça ne m'a pas manqué pendant mes 10 ans d'Amiga. Bien entendu, avec le recul, je vois bien que c'était deux choses importantes pour l'évolution de l'AmigaOS, car, en lisant un peu, au fil du temps, les discussion à ce propos concernant MorphOS ou AmigaOS 4.x, il semble bien que ce fut assez compliqué à ajouter et même ainsi ce n'est pas parfait. 
Tu vois, n'est ce pas reconnaitre les points faibles de l'AmigaOS ça ?
As tu fait de même, ne serait ce que pour le passage au multitache du TOS qui, si je me réfère au test fut tout aussi compliqué que l'ajout des deux fonctions dont nous débattons. Je veux dire compliqué dans le sens compatibilité avec la logithèque existante.
Je suis convaincu qu'a l'époque le passage à un processeur RISC aurait rendu ce problème secondaire, car il y aurait eu quasi obligation de réécrire la logithèque et que cela ce serait fait au fil des mois. Car, l'Amiga avait encore un marché à cette époque et une réputation auprès d'un certain nombre de professionnels dans ses domaines de prédilection. 
Le Falcon qui restait sur 680x0 n'aurait peut être pas eu ce type d'opportunité.

c'est comme ça, et avec stupéfaction, que je découvre que l'amiga à 20.000FF ne bootais pas sur HD alors que c'est indispensable pour utiliser correctement WB... !!!  alors qu'on reproche qu'on savait pas changer la couleur verte du bureau Atari !!  je suis choqué

Et je suis choqué que tu ressortes encore et encore qu'un disque dur était indispensable à utiliser à Amiga 1000, alors que le Workbench tenait sur UNE SEULE disquette ! Et qu'on t'a expliqué qu'il y a eu une démonstration du 1000 faisant tourner deux application (Deluxe Paint et un traitement de texte ou tableur (je me souviens plus) et tout ça SANS DISQUE DUR... alors que tu prétendais qu'il lui fallait un disque dur et 2 MO de RAM pour ça !!! 
Il pouvait même pas booter sur un disque dur... tu vois comme ton argument était de mauvaise foi !
Et je suis choqué que tu ne reconnaisse pas que j'ai dit, quasiment dès le début, que je saluait le connecteur SCSI en standard du ST (je m'en souvenais même pas en arrivant ici, qu'il avait ça).
Alors, oui, c'est vrai l'autoboot sur disque dur, il a fallu attendre le 1.3. Autrement il fallait booter sur une disquette qui passait la main au disque dur pour continuer le boot. Ca ne veut pas dire, pour autant, que l'Amiga ne pouvait pas être utilisé pour travailler...
Et d'ailleurs, soit dit en passant, dans la même émission américaine qui testait l'Amiga 1000, j'ai vu un ST en démonstration... qui avait un gros boitier dessous ou derrière... ne serait ce pas le disque dur SCSI externe du ST ? Est ce à dire qu'Atari considérait qu'on ne pouvait pas travailler autrement qu'avec un disque dur ? Ou plutôt que ça faisait tache de ne pas avoir un lecteur de disquette intégré dès le départ ?
Tu vois on peut tourner en rond longtemps comme ça...
Ah oui, et j'oubliais... n'ais je pas lu plusieurs fois ici (de personnes différentes) que le contrôleur disque dur du ST était buggué au niveau hardware... c'est quand même autre chose à corriger que des bugs logiciels... 

N'ais je pas déjà reconnu que l'AmigaOS avait ses lacunes (y compris dans l'époque 1.2/1.3). Mais, quand on te liste les bugs du ST (reconnus), quand on te donne des exemples des choses que le TOS/GEM était incapable de faire alors que l'AmigaOS/Worbench 1.2 (au minimum) était capable...

quoi donc ?  des futilités du genre renommer un repertoire, changer la couleur verte du GEM, démarrer un programme haute résolution dans un répertoire AUTO ?    bah il suffisait d'avoir une Action Replay !

Et bien, comme je n'ai pas eu de ST, je vais laisser quelqu'un qui a eu les deux répondre à ma place, la lecture est des plus intéressante :

Maintenant à mon tour de poser des questions. 

Tu as posé une question sur le démarrage au boot d'un programme. Ton arrière pensée était "avec un ST tu le fais en mettant ton programme dans le dossier "AUTO". 
J'ai 2 questions sur les autoboot : 
Avec un ST tu faisais comment pour faire démarrer au boot un logiciel qui tournait en haute résolution (sans patch ni outil supplémentaire)? 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST tu faisais comment pour faire démarrer au boot un logiciel GEM (c'est à dire qui utilisait la souris, les fenêtre, les icones, du classique quoi ) ? 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST, tu faisais comment pour renommer un répertoire ? 
Ah tu pouvais pas ? Obligé de passer par un programme... Ah mais non ! je suis bête ! C'est pas seulement le GEM qui n'offrait pas cette fonction, c'est carrément le TOS ! Donc tu ne pouvais même pas le faire par programmation ! LOL ! 
Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST, tu faisais comment pour avoir plus de 40 répertoires ? 
Ah tu pouvais pas... Bon c'est pas si grave : plus de 40 répertoires sur une disquette, c'était pas courant... 
Ah mais ça concerne aussi les HD ? Aie ! 40 repertoires max (en comptant tous les sous-répertoire et toutes les partitions) sur un HD, là par contre ça craint... 
Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST tu faisais comment pour que la position, la taille, les paramètres d'une fenêtre (d'une disquette ou d'un répertoire) soient mémorisés ? 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST tu faisais comment pour ouvrir plus de 4 fenêtres ? 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST tu faisais comment pour déplacer (et non copier) un fichier plus grand que la taille disponible sur ta disquette (donc pas moyen de copier et supprimer la source) ? 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST tu faisais comment pour faire une sauvegarde incrémentale avec ton HD vu que l'attribut d'archivage était buggé et ne se posait pas ? 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST tu faisais comment pour copier tous les fichiers qui correspondaient à des critère particuliers et qui se trouvaient dans différents endroits ? 
Par exemple, copier sur une disquette 30 fichier IFF disséminés dans 5 répertoires et mélangés avec d'autres fichiers. 
Et tout ça en une seule manip, pas 30... 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 


Je pourrai continuer longtemps comme ça : au jeu des manques ou de la convivialité, le ST n'est absolument pas devant le mig, contrairement à ce qu'affirment beaucoup de Stistes ici. 
Et vu que tu prétends que le WB n'était pas terminé, je peux en conclure la même chose. Certaines des choses que je viens de citer ont été réglés après l'arrivée du 2.0. Et y en a qui posaient des problèmes autres que la convivialité...

Note que je me suis restreint au domaine que tu abordais : la manipulation de fichiers...

Ah non, tu as parlé des librairies aussi. Alors j'explique l'interet :

Dans l'amigaos tu as accès à tout un tas de librairies qui sont en rom ou pas.
Par exemple, il y a une librairie mathématique qui te donne accès à des fonctions trigonometriques. 
Si tu utilises un logiciel pour de rendering 3D, le programme utilisera abondamment cette libriarie (s'il a été correctement écrit). Maintenant imaginons que tu achete une carte avec un 68020+copro arithmétique, tu aimerais bien que ce programme (et d'autres) utilisent le copro de ta carte, non ?
Et bien il suffira de dire à l'OS que tu souhaite utiliser une autre librairie et de lui fournir. Et là c'est très compliqué : il faut copier un fichier dans le répertoire libs. Et même plusieurs puisqu'il y a surement plusieurs librairie que tu pourrais rendre plus performantes. Bien sur, les cartes accélératrices étaient livrés avec des logiciels d'install qui faisaient tout ça. ça permettait, si tu faisais ça sur ta disquette WB ou ton HD de rendre immédiatement pleins de programmes beaucoup plus rapides que s'ils s'étaient contenté de ne profiter que de l'accélération apportée par le 68020 (on est dans des facteurs de vitesse qui se mesurent en dizaines/centaines).
Ce système est tellement souple qu'il permettrait à des logiciels écrits pour le 68000 de profiter de la puissance du powerpc quand les cartes qui en étaient équipées sortiront...

Et pourtant, l'utilisateur lambda ne savait pas qu'il y avait un répertoire libs...
ça vaut pas le coup, en échange de ce que ça apporte, de jouer les "alchimistes" ?

Moi, la convivialité, je dirai que c'est très subjectif. Et je noterai que tous les OS moderne utilisent une ergonomie plus proche de celle du mig que du ST : noms long, icones personnalisés, sauvegarde des paramètres d'affichage des dossiers, jauge indiquant l'espace restant (ah tiens ! encore un truc bien pratique qui n'existait pas sur ST), etc... 

J'explique pour ceux qui ont du mal à comprendre et que ça interesse sincèrement. 

L'OS du mig est en ROM (tu as raison Ryosaeba : ça pose les même problèmes de mise à jour qu'avec le TOS du ST). 
Mais l'OS ne contient pas le bureau. C'est la différence avec celui du ST. Mais tout le reste y est (y compris l'interface graphique). 
Et l'amigaos propose une API bien plus complète que celle du TOS/GEM. Elle est non seulement plus optimisé (les fonctions de l'OS n'ont pas besoin de manipuler la pile autant que sur ST...) mais elle prend plus de place. 
Un ST c'est 192 Ko pour l'OS et le bureau. 
Un mig c'est 256 Ko pour l'OS seul. 

Un bureau, pour être le plus convivial, doit être personnalisable. Et je ne parle pas que de cosmétique, je parle de personnalisation qui permet d'améliorer la productivité. 
Un exemple simple : sur le WB, tu peux personnaliser la surface d'affichage pour qu'elle occupe le maximum visible sur un moniteur. Faire ce réglage à chaque allumage de l'ordinateur n'aurait pas de sens. Il faut donc que ce soit mémorisé, sinon personne ne l'utiliserait. Attention ! je ne parle pas d'étirer la zone comme on pouvait le faire sur certains moniteurs (ceux qui le faisaient étaient rares). je parle d'augementer le nombre de pixels : plus on en a mieux c'est. Grace à ça, en moyenne résolution, le mig avait un bureau de 680-700 pixels par 260/280 lignes. (et une application qui ouvrait ses propres écrans pouvait reprendre les réglages du WB...) Le ST restait cantonné à du 640 x 200. Et tout ça dans une fenêtre ridiculement petite. 
Grace à ce système, sur un Amiga, pour avoir un bureau de 14 pouces, il fallait un écran de 15 pouces. Sur un ST, il fallait un écran de 18/19 pouces ! Et tout ça avec moins de pixels, moins de couleurs, et un pointeur qui ne pouvait pas avoir sa palette spécifique. Ce qui n'est pas très convivial quand on dispose de 4 couleurs en tout... 
Donc quand tu as un bureau hautement configurable et personnalisable, il est logique de le mettre sur disquette puisqu'il faudra de toute façon charger pleins de choses avant de l'ouvrir. 


Maintenant tous les outils que tu avais sur le WB tu pouvais les avoir aussi sur le GEM ? Tu es loin du compte...
Une chose est sure : tu ne connais pas le mig... Ou plutot les outils que tu peux avoir sur le WB. Rien que celui dont je parle juste au-dessus qui te permet d'optimiser la suface d'affichage : ça n'existe pas sur le ST et c'est impossible à faire... 

A propose d'outil, il y en avait un sur ST qui permettait de lancer un programme en moyenne résolution au boot (bon c'est plus un correctif qu'un outil...). 
Il se mettait lui aussi dans le dossier AUTO. 
Voici un extrait de sa doc : 

Although the ST's internal clock keeps time with an accuracy of two seconds, the time-stamping of files is accurate only to within one minute. To be absolutely certain that the AUTO folder will work correctly, you should allow at least two minutes to elapse between the time that you place each file in AUTO. This ensures that the ST will have no difficulty deciding the correct order in which to run the programs. 

Il faut attendre au moins 2 minutes entre chaque copie de fichier ! ça c'est convivial ! LOL !

L'ordre des programmes dépend de la date des fichiers ! Super si tu veux changer cet ordre...
Je préfère 1000 fois une statupsequence.

Et je pourrais te citer des tas de choses que tu faisais facilement avec une startupsequence (et un cli intégré en ROM...) et qui auraient demandé de solides connaissances en programmation pour les faire avec un ST...

je n'ai pas appronfondit sur le Transputer, raison pour laquelle j'ai laissé en suspend.  mais je ne vois pas vraiment le rapport au final, que l'Atari tourne sur un OS inspiré de TRIPOS qui a lui même inspiré l'AmigaOS ne me pose aucun problème. Il auraient pu utiliser un bon vieux Unix également.

Je ne dis pas que le multitache à cet époque n'a AUCUN intérêt, je dis que sur un A500 avec 512ko de RAM ( ce qui représentait la majorité du parc Amiga ), ne représentait pas une option indispensable.  Sinon oui, j'imagine bien que sur une plus grosse config, 1mb RAM, HD, WB 2.0, cela devait être sympa.. mais là, on est déjà fin des années 90.

Ce que je soulignais avec TRIPOS (enfin HELIOS) avec le transputer c'est que dès qu'il s'est agit d'aller dans le domaine des stations de travail (donc PRO), au revoir TOS/GEM, alors que tu n'a de cesse de me parler pour l'utrapro des TT... 
Je me rappel encore de nos échanges au sujet de Lightwave où tu me disais que certains producteurs d'effet spéciaux pour des séries télé aurait tout aussi bien pu acheter des TT et y faire tourner Lightwave. Tu disais même que pour le prix des Amiga 2000 équipés tel que c'était expliqué ils auraient pu acheter je ne sais combien de TT et que le calcul parallèle aurait été bien plus rapide...
On voit bien que l'utilisation du TOS pour du calcul parallèle... c'était pas trop ça... d'autant plus que Lightwave sur Atari ça n'existait pas !
Mais, à part ça, tu n'es pas le roi de la mauvaise foi :)

Ce que tu n'arrives pas à comprendre, c'est que l'AmigaOS il était pas prévu pour une machine limité à 512 KO... Il pouvait en gérer 2GO si je ne me trompe (parce qu'il était 32 bits). A cette époque c'était totalement inimaginable. Ce que je veux te faire comprendre, c'est que le choix du multitache c'était un choix d'avenir. Commodore a présenté l'Amiga (le 1000) à l'époque comme une machine professionnelle. Et en face, il y avait quoi un MAC avec 128 ko, et le ST avec 512 KO... non extensible. L'Amiga était extensible à 8 MO (énorme pour l'époque). Et on t'a montré une vidéo de multitache (application bureautique) sur un Amiga 1000 (256 ko, mais je veux bien t'accorder qu'ils avaient pu l'augmenter à 512 ko, puisque je pense que cette extension interne de 256 ko existait à la sortie).

Oui, tu as raison, tout ceux qui ont commencé avec un 500 avait 512 ko de base... mais t'en connais beaucoup qui n'ont pas fini par lui ajouter 512 ko de plus (c'était tellement facile... suivez mon regard :) )
Donc si le multitache fonctionnait sur Amiga 1000 avec 256 ko, pourquoi il aurait pas fonctionné avec 512 ko ?
C'est certain que celui qui ne faisait que jouer, il s'en apercevait pas du multitache de l'AmigaOS, mais là c'est un autre public que celui dont je parle. Nous parlons d'Amigaistes, des vrais, ceux qui ont cherché à voir ce qu'était leur machine et pas seulement à jouer avec.

Tu penses trop en terme de ST "non extensible de base"
Tiens on va imaginer un dialogue :
Utilisateur : "Tiens mon Amiga 500 je t'installe 512 ko de plus"
Amiga 500 : "T'es dingue, l'AmigaOS il a été pensé pour 512 ko maxi, je vais quand même pas m'embêter à profiter de plus de mémoire pour mon OS... quelqu'un a dit un jour qu'on aurait jamais besoin de plus de 640 Ko sur un ordinateur ! Et ben sur Amiga on a dit que c'était pas plus de 512 Ko ! Et encore, c'est bien parce qu'on est obligé !"
Utilisateur : "Et l'Amiga 2000 alors avec 1 MO"
Amiga 500 : "C'est pas ma faute si y a des gogos qui ont cru que ça leur servirait à quelque chose d'avoir plus de 512 ko !"
Utilisateur : "Et mon multitache ?"
Amiga 500 : "Et tu vas arrêter de nous gonfler avec ça, j'ai déjà bien assez à faire à afficher des guru constamment, c'est pas en plus pour en afficher plusieurs à la fois !"

Franchement, tu trouves pas que le role de l'Amiga 500 il a un accent qui te ressemble ? Comme je te l'ai maintes fois dit, l'Amiga 500 était pensé comme une machine évolutive et le multitache prenait tout son sens dans cette optique. Et avec 512 ko tu pouvais le découvrir et si tu voulais aller plus loin tu en avait la possiblité. Mais, pour ça fallait pas se cantonner au jeu et suivre les conseils d'une revue comme Amiga News. En général les passionnés dans un domaine sont de bon conseils.

Mais, je veux bien t'accorder qu'un disque dur était un plus. Et la configuration dont tu parles 1 MO et disque dur, je ne l'ai pas eu en 1990, mais en 1989 sur un Amiga500 et avec le workbench 1.2/1.3 et c'était déjà très sympa, ne t'en déplaise. 
Tu vois comme tu es de mauvaise foi, le 2.0 c'est mai juin 1990 si je me souviens bien (j'étais au SICOB quand l'Amiga 3000 y a été présenté (en France) et c'était le même mois qu'aux Etats Unis)). Mais le 2.0 je l'ai pas utilisé, je suis resté sur la config 1 MO/HD/Workbench 1.2/1.3 jusqu'à ce que je prenne un 1200. Les applications programmées pour le 2.0 tournaient sur le 1.3. Il y avait juste le look des fenêtres qui était différent parce quand ça tournait sur 1.3, mais sinon ça fonctionnait pareil. Je n'avais pas de d'installabilité chronique, les logiciels que j'utilisais en multitache ne se "téléscopaient pas" pour appeler des gurus. 
Ca m'est arrivé d'en avoir par ci par là, mais rien d'aussi systèmatique que tu le prétends.

Je suis malgré tout curieux, qu'as tu fait sur ton Amiga pour avoir de tels souvenirs de guru sous AmigaOS ?

PS : A la relecture, je pense qu'on a fait quand même pas mal le tour au sujet du débat TOS/GEM et AmigaOS, car j'ai l'impression qu'on retombe quasiment sur les mêmes arguments de part et d'autre. Je serais d'avis qu'on en reste là au moins pendant quelques temps. Par contre la question de savoir ce que tu as fait sur Amiga m'intéresse pour comprendre d'ou te vient cette opinion.

[dlfrsilver]

merci stapha92 des renseignements techniques sur les "videos" mais quand on voit qu'il existe seulement des avi de ses videos(facile de remettre ça sur youtube et de dire c'est un st qui fait ça)

Pas de quoi cryodav76.

Le pire c'était ça :

magnifique :

http://atari.8bitchip.info/OverscanOvertake.avi

J'avais téléchargé le fichier : c'est un AVI de 768x576. ça correspond à un signal TNT classique. Et ça n'est pas la résolution annoncée pour les vidéos du ST. L'auteur n'a même pas pris la peine de redimensionner... LOL !!

Que ce soit clair : quand je dis ça, je ne pense pas à Rocky. Il est évident qu'il ne s'est pas amusé à poster des fakes. Il avait l'air si fier de ce qu'il croyait que faisait le ST...

Justement, je me suis frité avec lui, au sujet du disque dur haut de gamme pour A500 que je possède, et qui défoncait aussi les ST, TT, Falcon, et même le 1200 en terme de vitesse.

J'ai 8 mo de fast-ram embarqué dedans (je précise, c'est un HD+8 impact A500 GVP II series), et y a une puce WD93XXX de chez western Digital qui fait le SCSI to DMA. Le taux de transfert des données est de 3,58Mo/s.

Question quelle est la différence entre la vitesse de la ram de l'amiga et celle du ST, et quelle est la différence réelle en terme de bande passante entre les deux ?

Histoire de lui retaper ses gencives au monsieur :)

Et aussi si tu pouvais expliquer un peu plus dans le détail ce point là :

Un aiguillage qui va changer de coté 7,14 millions de fois par seconde pour le mig ou 4 millions de fois par seconde pour le ST. Donc à chaque fois que cet aiguillage se trouve dans une position, il y a le temps de faire un accès pour le mig ou 2 pour le ST.

es-tu en train de dire que :

1) Denise est infiniment plus rapide que le shifter, et que donc le shifter représente un sacré goulot d'étranglement sur le ST ?

2) que celà explique pourquoi même si le ST possède un CPU clocké 12% plus rapide, l'amiga garde l'avantage quoi qu'il arrive ?

Et que donc bon dieu de nom de dieu, j'ai donc parfaitement raison quand je disais que c'est bien pour ça que l'architecture même de l'amiga lui donne l'avantage sur le hardware full quincaillerie du ST conçu par le père Shiraz Shivji ?

[rocky007]

L'auteur du bouquin ne confirme pas "guru à gogo"

si il le confirme
" result is far too often a visit of guru"... pour moi le mot "too often" est révélateur non ?

Et que dit l'auteur... et bien que l'utilisateur était forcé d'espérer que le programmeur du logiciel avait correctement respecté les règles de programmation du manuel de l'Amiga et évité les bugs... N'est ce pas le cas sur tout ordinateur ?

non... exemple : sur un ST, on n'a pas la crainte qu'un autre logiciel vient empiété sur notre RAM.  on sait qu'on qu'est est seul dans la RAM disponible.   cela permet un peu aux logiciels mal codés de passer qd même.
sur amiga, la moindre erreur ne pardonne pas., parce que le OS ne pardonne rien. 

Alors bon, là il y a un peu de mauvaise foi, à cause du "trop souvent", mais il parle de l'Amiga 1000 (1.0 1.1), sur le 1.2 la stabilité était nettement meilleure, (c'est celui dont je parle pour l'époque 1988-1992 dans mon cas, enfin dès 1988 j'utilise le 1.3 en fait avec le kickstart 1.2).

donc si je comprends bien, si on va dans ton sens on est de bonne foi, dès qu'on est qq chose de négatif sur l'amiga on est de mauvaise foi... je note.

Eh ben tu vois, on progresse. Pour le hardware, je veux bien accepter 5 ans (parce que l'ECS et l'AGA, c'était quand même des "upgrade" au rabais. Par contre pour l'AmigaOS, je maintient 10 ans, car il a bien fallu 10 ans entre 1985 et 1995 pour que le grand public découvre le multitache (moins bien) sur autre chose qu'un Amiga.

pas du tout, je t'ai déjà donné des exemples ( X68000 etc..).
le hardware de l'amiga était sur  une architecture déjà existante ( le XL ), le OS prenait ses bases sur Unix / Tripos etc..
comme tu le dis, le miracle d'amiga est d'avoir upgradé toutes ces technologies dans un ordi puissant 16 bit à un prix accessible avec le A500.  de mémoire, les OS multitâche pour Falcon / ST sont apparus fin des années 90.  on peut donc dire que Amiga a été leader entre 88 et 92.

Donc le multitache du Falcon, oui il le faisait, quand il pouvait (c'est à dire en renonçant à ses applications phare, quelle belle évolution... Sur Amiga les logiciels PRO tournaient sans problème en multitachen passant du 1.x au 3.x (sauf ceux qui était programmé sans tenir compte des recommandations de Commodore).

oui tout comme il fallait des récritures de logiciels A500 pour qu'ils fonctionnent sur A1200.
de plus quel intérêt d'utiliser un vieux soft n'exploitant pas le falcon ? ex pour cubase, pourquoi utiliser la version ST qui n'a pas de direct to disk ? pourquoi utiliser un vieux programmes de dessin alors que le DSP est justement là pour faire du traitement d'image ?

Et finalement la conclusion du test qui donne le Falcon vainqueur par rapport à un Amiga 1200 de base... avec une petite note intéressante :

je suis d'accord avec toi, le Falcon manque toujours cruellement des avantages de l'amiga ( dual playfield, sprite, etc..)
même si son DSP compense, c'est dommage qu'il n'aie pas poussé plus loin.

Et je suis choqué que tu ressortes encore et encore qu'un disque dur était indispensable à utiliser à Amiga 1000, alors que le Workbench tenait sur UNE SEULE disquette ! Et qu'on t'a expliqué qu'il y a eu une démonstration du 1000 faisant tourner deux application (Deluxe Paint et un traitement de texte ou tableur (je me souviens plus) et tout ça SANS DISQUE DUR... alors que tu prétendais qu'il lui fallait un disque dur et 2 MO de RAM pour ça !!! 

ah bon ? faire tourner deluxe paint et un tableur + workbench avec 256mb de RAM ?
une seule diquette pour le WB 1.2 ?  tu es sûr ?  j'ai vu qu'il en fallait TROIS pour A1000 !!!

Ah oui, et j'oubliais... n'ais je pas lu plusieurs fois ici (de personnes différentes) que le contrôleur disque dur du ST était buggué au niveau hardware... c'est quand même autre chose à corriger que des bugs logiciels... 

cela n'a touché qu'un faible pourcentage de personnes.  ce bug n'est devenu célèbre que depuis l'apparation de lecteur CF.  perso, j'en en abait jamais entendu parlé dans les années 90, pourtant qd tu as 400 personnes dans une coding party, ce genre de problème devrait être connu non ?

Et bien, comme je n'ai pas eu de ST, je vais laisser quelqu'un qui a eu les deux répondre à ma place, la lecture est des plus intéressante :

eh oui, c'est bien ce que je voulais dire : les personnes qualifées pour nous expliquer les travers de l'amiga s'en abstiennent bien !!

pourtant quand on vois les révisions du WB :

1.3.0 :

• The bug in AutoConfig was fixed (see Notes/comments section)
  
• Memory autoconfig was added; "addmem" commands no longer needed
  
• The recoverable RAM: drive was called "RAMB0:"
  
• Autoboot from hard drive, and other non-DF0 media (except CD-ROMs)
  
• Addition of the Shell
  

1.3.2 :

• Improved stability
  
• FFS can handle hard disks up to 2.5GB (old limit was 308MB)
  
• Better support of the printer.device for "multi pass" printers
  
• Bugs fixed in commands Setpatch, LoadWB, Format, NoFastMem, FastMemFirst and CMD, as well as info.library, serial.device and printer.devic
  

1.3.3 :

• Bug fixes
  
• Removal of enforcer hits
  

ça fait aussi beaucoup de bug corrigés non ?

On voit bien que l'utilisation du TOS pour du calcul parallèle... c'était pas trop ça... d'autant plus que Lightwave sur Atari ça n'existait pas !
Mais, à part ça, tu n'es pas le roi de la mauvaise foi :)

je vois pas le rapport avec le OS, tu peux faire sans problème du calcul // avec un environnement monotâche.
du reste, de mémoire, tu pouvais le faire avec POV.




tu résumes bien la situation : pour la plupart, c'était mettre un jeu et jouer.  donc multitache : aucun intérêt.  pour les autres, c'est démarrer une calculette et basculer entre deux logiciels, là encore, le multitache n'était pas indispensable.  il reste donc un faible pourcentage de personne dont le multitache était un nécessité.




ce que j'ai fait avec l'amiga ?  un peu de tout : jeux bien sûr, mais aussi de l'utilisation pro.

bref, on peut conclure que tu es de mauvaise foi 

[Urbinou]

ça fait aussi beaucoup de bug corrigés non ?

Bah, au moins sur l'amiga, les bugs pouvaient être corrigés  

Et quoi de plus normal ? Toutes les semaines, je reçois bien des corrections de bugs pour mon seven.

[Invité]

oui enfin pour seven on n'est pas trop sur si ca corrige vraiment les bugs ou si ca en ajoute

[Seb]

Allez, un peu d'humour sur ce thread :)

[babsimov]

L'auteur du bouquin ne confirme pas "guru à gogo"

si il le confirme
" result is far too often a visit of guru"... pour moi le mot "too often" est révélateur non ?

Oui, j'ai fait de la mauvaise foi à ce niveau, comme je vais te le montrer juste en dessous.

Alors bon, là il y a un peu de mauvaise foi, à cause du "trop souvent", mais il parle de l'Amiga 1000 (1.0 1.1), sur le 1.2 la stabilité était nettement meilleure, (c'est celui dont je parle pour l'époque 1988-1992 dans mon cas, enfin dès 1988 j'utilise le 1.3 en fait avec le kickstart 1.2).

donc si je comprends bien, si on va dans ton sens on est de bonne foi, dès qu'on est qq chose de négatif sur l'amiga on est de mauvaise foi... je note.

En fait, ma réponse que tu cites est incomplète et je me suis mal exprimé, je m'en aperçois maintenant. Je parlais de mauvaise foi pour moi, par rapport à ma réponse juste avant. Je cite le message pour que ce soit plus clair.

Mais, il dit aussi "qu'en cas de bug ou non respect des règles" il arrivait trop souvent une visite du guru... N'est il pas exact sur toute machine qu'un plantage est un plantage de trop :)

Alors bon, là il y a un peu de mauvaise foi, à cause du "trop souvent", mais il parle de l'Amiga 1000 (1.0 1.1), sur le 1.2 la stabilité était nettement meilleure, (c'est celui dont je parle pour l'époque 1988-1992 dans mon cas, enfin dès 1988 j'utilise le 1.3 en fait avec le kickstart 1.2).

Le smiley après "un plantage de trop" était pour montrer que c'était un peu mauvaise foi, et ma remarque en dessous pour le souligner. Je n'accuse nullement l'auteur de mauvaise foi, je ne me le permettrait pas !

En tout cas, moi, je n'ai pas coupé le passage ou il dit du bien de l'Amiga (tu sais pionnier, élégant, ce genre de mots).
Tu gardes le titre de roi de la mauvaise foi :)

Et que dit l'auteur... et bien que l'utilisateur était forcé d'espérer que le programmeur du logiciel avait correctement respecté les règles de programmation du manuel de l'Amiga et évité les bugs... N'est ce pas le cas sur tout ordinateur ?

non... exemple : sur un ST, on n'a pas la crainte qu'un autre logiciel vient empiété sur notre RAM.  on sait qu'on qu'est est seul dans la RAM disponible.   cela permet un peu aux logiciels mal codés de passer qd même.
sur amiga, la moindre erreur ne pardonne pas., parce que le OS ne pardonne rien.  

Parce que le TOS il pardonne les bugs DU SEUL LOGICIEL qui tourne... comment tu expliques les bombes alors ?
Mais, là encore, cet argument il refait surface à chaque fois dans nos échanges sur l'AmigaOS, comme je te l'ai dit, je pense qu'on a plus rien à ajouter. On a bien compris les positions de chacun et je ne suis pas sur que le lecteur du forum ait envie de nous voir répéter les mêmes choses. 
Tu as préféré le TOS/GEM... très bien. De mon coté j'était très content de mon AmigaOS "soit disant inutilisable"...

Eh ben tu vois, on progresse. Pour le hardware, je veux bien accepter 5 ans (parce que l'ECS et l'AGA, c'était quand même des "upgrade" au rabais. Par contre pour l'AmigaOS, je maintient 10 ans, car il a bien fallu 10 ans entre 1985 et 1995 pour que le grand public découvre le multitache (moins bien) sur autre chose qu'un Amiga.

pas du tout, je t'ai déjà donné des exemples ( X68000 etc..).
le hardware de l'amiga était sur  une architecture déjà existante ( le XL ), le OS prenait ses bases sur Unix / Tripos etc..

Et comme, à chaque fois, quand tu fait un pas en avant, tu en fait deux en arrière... et tu vas chercher une autre machine (cette fois le X68000) pour défendre le ST. Comme je te l'ai déjà dit, aussi bien que soit cette machine, en dehors du Japon elle était quasi inconnue et totalement inabordable et inutilisable pour le commun qui ne connaissait pas le japonnais. Et son OS n'était pas multitache, basé sur MS-DOS (je n'ai pas trouvé d'autre infos à ce sujet). Mais combien de fois tout ceci à été dit ici déjà !

comme tu le dis, le miracle d'amiga est d'avoir upgradé toutes ces technologies dans un ordi puissant 16 bit à un prix accessible avec le A500.  de mémoire, les OS multitâche pour Falcon / ST sont apparus fin des années 90.  on peut donc dire que Amiga a été leader entre 88 et 92.

Même si le terme miracle me plait bien pour l'Amiga, c'était surtout une volonté de Jay Miner et son équipe d'innover et de proposer quelque chose de jamais vu sur le marché grand public. Ce fait sera vrai de 1985 à 1995 ne t'en déplaise. Mais, là encore, je te l'ai dit été répété, je sais que ça te plait pas de lire ce genre de chose et que tu as une rancune tenace contre l'Amiga (j'en ignore la raison). 

Les OS multitache du Falcon et ST, tu plaisantes ? Avec des incompatibilités reconnues par le site Atari (le test en question), génial la transition au multitache sur ST/Falcon ! Un OS il est multitâche au départ, on ne transforme pas un OS monotache en OS multitache comme ça en claquant du doigt ! Tout ceux qui ont essayé ont été obligé de finalement tout réécrire et de jeter l'OS précédent (Windows/MacOS et le TOS aussi puisqu'il fallait zapper le TOS/GEM en ROM pour utiliser multiTOS sur disque dur... 
Mais, tout ça aussi on l'a dit et redit en long et ne large et on a bien compris qu'on ne sera pas d'accord.

Donc le multitache du Falcon, oui il le faisait, quand il pouvait (c'est à dire en renonçant à ses applications phare, quelle belle évolution... Sur Amiga les logiciels PRO tournaient sans problème en multitachen passant du 1.x au 3.x (sauf ceux qui était programmé sans tenir compte des recommandations de Commodore).

oui tout comme il fallait des récritures de logiciels A500 pour qu'ils fonctionnent sur A1200.

Remplace donc plutôt logiciel par jeux, ce sera plus proche des faits !
Je n'ai pas changé toute ma logithèque bureautique en passant du 500 au 1200... en fait, je n'ai perdu que certains jeux (et encore il y avait la Early Startup) qui réglait pas mal de chose à ce niveau. 
Le problème des incompatibilités des jeux sur 1200 venaient souvent des protections... Le même jeu provenant d'une source "alternative" fonctionnait souvent directement sur le 1200... 
Pour ce qui était des logiciels écrit pour le système (bureautique, graphique etc...) pas de problème ça marchait. 

de plus quel intérêt d'utiliser un vieux soft n'exploitant pas le falcon ? ex pour cubase, pourquoi utiliser la version ST qui n'a pas de direct to disk ? pourquoi utiliser un vieux programmes de dessin alors que le DSP est justement là pour faire du traitement d'image ?

L'intéret est de ne pas avoir à racheter toute ta logithèque d'un coup. Je ne sais pas quel était le prix de Cubase, mais ça devait pas être donné... 
Alors bon si tu as investit dans des logiciels, le moins que tu attends, c'est que la version suivante de l'OS puisse continuer à les faire tourner. Hors, le test sur ce site Atari, dis clairement, que ce n'était pas le cas avec MultiTOS... tu vas quand même pas dire qu'ils affabulent.
Je ne dis pas qu'à terme tu fait évoluer ta logithèque, mais imagine un musicien ou graphiste, en lisant ça, il change pas de machine, il garde celle qu'il a jusqu'à pouvoir acheter la nouvelle machine et le nouveau logiciel. 
C'est quand même un frein à la vente d'une nouvelle génération de machines (c'est valable pour toute plateforme). Par contre, être assuré qu'on pourra utiliser son ancienne logithèque dès l'achat de ta nouvelle machine, ça permet d'inciter à acheter. Au minimum le processeur est plus rapide. Tu vas me dire, que le TOS/GEM était en ROM. Oui, et c'est peut être pour ça que ces problèmes d'incompatibilité de la logithèque avec MultiTOS a fait que MultiTOS a peu été adopté à l'époque. L'arret du Falcon y a aussi contribué certainement.

Et finalement la conclusion du test qui donne le Falcon vainqueur par rapport à un Amiga 1200 de base... avec une petite note intéressante :

je suis d'accord avec toi, le Falcon manque toujours cruellement des avantages de l'amiga ( dual playfield, sprite, etc..)
même si son DSP compense, c'est dommage qu'il n'aie pas poussé plus loin.

Au moins un point d'accord :)

Et je suis choqué que tu ressortes encore et encore qu'un disque dur était indispensable à utiliser à Amiga 1000, alors que le Workbench tenait sur UNE SEULE disquette ! Et qu'on t'a expliqué qu'il y a eu une démonstration du 1000 faisant tourner deux application (Deluxe Paint et un traitement de texte ou tableur (je me souviens plus) et tout ça SANS DISQUE DUR... alors que tu prétendais qu'il lui fallait un disque dur et 2 MO de RAM pour ça !!! 

ah bon ? faire tourner deluxe paint et un tableur + workbench avec 256mb de RAM ?
une seule diquette pour le WB 1.2 ?  tu es sûr ?  j'ai vu qu'il en fallait TROIS pour A1000 !!!

Oui, je suis sûr, le Workbench 1.2 est sur une disquette, la seconde contient l'AmigaBasic et des extras (démo etc). Le 1.3 aussi d'ailleurs !

https://en.wikipedia.org/wiki/AmigaOS_versions

Je n'ai pas eu le 1000, mais je pense savoir pourquoi 3 disquettes sur ce premier Amiga. Il n'avait pas de Kickstart en ROM. La première disquette devait être le kickstart, tu le lançait et ensuite il restait dans une RAM résistant au restet (c'était peut être même une flashrom ?) En tout cas, le workbench 1.2 et 1.3 quel que soit l'Amiga c'était une disquette pour l'AmigaOS et la deuxième pour l'AmigaBasic et ses démos.
C'est à partir du 2.0 que le nombre de disquettes augmente... pourquoi, parce que à partir de cette version 2.0, l'AmigaOS est pensé uniquement pour disque dur (normal le 3000 a un disque dur en standard). Mais je l'avais expliqué il y a quelque pages. Je me demande si tu ne retient pas que ce qui t'arrange dans mes propos :)

Ah oui, et j'oubliais... n'ais je pas lu plusieurs fois ici (de personnes différentes) que le contrôleur disque dur du ST était buggué au niveau hardware... c'est quand même autre chose à corriger que des bugs logiciels... 

cela n'a touché qu'un faible pourcentage de personnes.  ce bug n'est devenu célèbre que depuis l'apparation de lecteur CF.  perso, j'en en abait jamais entendu parlé dans les années 90, pourtant qd tu as 400 personnes dans une coding party, ce genre de problème devrait être connu non ?

C'était un bug connu dès l'époque, puisque qu'Atari a sortit une version corrigée du ce composant... mais, même avec cette version corrigée, ça ne corrige pas le problème, c'est la loterie...

Il y a, sur Amiga 3000/4000, le composant BUSTER qui nécessitait d'être changé pour que éviter des bugs sur certaines configurations matérielles. Le changement de ce composant règle le problème sans équivoque, tu n'as pas besoin de demander "marchera ?" "marchera pas ?".

Tiens, mais je viens, une fois de plus de te donner un défaut de l'Amiga... quand as tu ouvertement reconnu un défaut du ST qui n'avait pas encore été pointé dans la discussion (si tu le reconnais d'ailleurs) ? J'aurais très bien pu me taire, mais j'ai essayé d'être impartial sur ce coup. J'ai bon ? 

Et bien, comme je n'ai pas eu de ST, je vais laisser quelqu'un qui a eu les deux répondre à ma place, la lecture est des plus intéressante :

eh oui, c'est bien ce que je voulais dire : les personnes qualifées pour nous expliquer les travers de l'amiga s'en abstiennent bien !!

Parce que, comme je l'ai écrit au dessus, si on te pointe pas un problème sur ST, t'es venu nous en donner des défauts du ST, de toi même ? 
Tu n'a cessé de répéter que la conception du ST, du TOS, du GEM était parfaite dès le premier jour ! Mais quand une personne qui a eut les deux et connais les deux machines sur le bout des doigts (et surement d'autres machines), vient te démonter par A+B que tu disait n'importe quoi, tu l'accuse de ne pas critiquer l'Amiga ?

Qu'est ce que tu veux qu'il ajoute au fait que le ressource tracking et la protection mémoire n'étaient pas dans l'AmigaOS ?
D'ailleurs, il me semble, qu'au tout début de nos échanges sur l'AmigaOS, Stapha92 (pour ne pas le nommer, car c'est bien de lui dont tu parles), était intervenu pour rétablir les faits et avait lui aussi expliqué que ton argument du plantage systématique était faux et que les logiciels commerciaux (autre que les jeux) respectaient les consignes de programmation et ne faisaient pas planter le système. Il avait, de mémoire, lui aussi évoqué les domaines publiques et les logiciels de provenance "alternative". 

Mais, si ça peut te faire plaisir, je profite de cette réponse pour demander à Stapha92 de nous faire part, via son expertise, de l'impact de l'absence de protection mémoire et ressource tracking sur la stabilité de l'AmigaOS. 
Est ce que cela rendait l'Amiga totalement inutilisable au quotidien et provoquait guru sur guru comme tu ne cesses de le prétendre ?
Mais, si on aborde ce sujet, tout à fait légitime, je lui demande aussi de nous parler des "bombes" sur ST et de la stabilité que tu prétends supérieure du TOS/GEM.
Je ne sais pas si Stapha92 prendra le temps de répondre à cette question, mais j'espère qu'au moins tu apprécieras que j'ai posé la question ouvertement.

[/quote]
pourtant quand on vois les révisions du WB :

1.3.0 :

• The bug in AutoConfig was fixed (see Notes/comments section)
  
• Memory autoconfig was added; "addmem" commands no longer needed
  
• The recoverable RAM: drive was called "RAMB0:"
  
• Autoboot from hard drive, and other non-DF0 media (except CD-ROMs)
  
• Addition of the Shell
  

1.3.2 :

• Improved stability
  
• FFS can handle hard disks up to 2.5GB (old limit was 308MB)
  
• Better support of the printer.device for "multi pass" printers
  
• Bugs fixed in commands Setpatch, LoadWB, Format, NoFastMem, FastMemFirst and CMD, as well as info.library, serial.device and printer.devic
  

1.3.3 :

• Bug fixes
  
• Removal of enforcer hits
  

ça fait aussi beaucoup de bug corrigés non ? [/quote]

Comme ta précédente recherche "workbench 1.3 bug list" n'avait pas eu le résultat escompté, tu as persisté avec ce critère de recherche. Que veut tu que je te dise ? Qu'il restait des bugs à corriger dans le 1.3, la preuve. Ais je dis à un moment ici que l'AmigaOS n'avait pas de bugs ? 

Du reste, au niveau des bugs, on avait déjà fait le comparatif dans une des pages d'un des précédents archives de ce sujet. Je pense que c'était ça :

http://computer.wikia.com/wiki/Atari_TOS



Alors que voit on ?

Quasi constamment des bugs fixes jusqu'au Falcon. Et même pour le  1.04 (1989, soit l'époque du 1.3.x) il est dit "many bug fixes", il y a a tellement à corriger que c'est même pas listé :)

Et sur Amiga :

http://wiki.classicamiga.com/History_of_Workbench_and_Amiga_OS



Passé le 1.3.4 le mot bug disparaît et le 1.3.4 c'est, allez au pire début 90 (avant le 2.0 avec le 3000).

Mais, ça je l'avais déjà dit plusieurs pages auparavant. On se répète dans ce débat, c'est un peu pour ça que je voudrais prendre une pause (au moins sur le débat AmigaOS).

On voit bien que l'utilisation du TOS pour du calcul parallèle... c'était pas trop ça... d'autant plus que Lightwave sur Atari ça n'existait pas !
Mais, à part ça, tu n'es pas le roi de la mauvaise foi :)

je vois pas le rapport avec le OS, tu peux faire sans problème du calcul // avec un environnement monotâche.
du reste, de mémoire, tu pouvais le faire avec POV.

Tu compares POV avec Lightwave... trop fort !
Et vas y tiens sur un OS monotache faire un calcul POV en tache de fond :) 
Pour le calcul parallèle si le TOS avait pu le faire, pourquoi ils ont pas pris le TOS à la place d'HELIOS comme OS pour leur Transputer ?
Note que je peux me tromper, je ne suis pas expert, mais du calcul parallèle ça sonne quand même plus "multitache" que "monotache".

tu résumes bien la situation : pour la plupart, c'était mettre un jeu et jouer.  donc multitache : aucun intérêt.  pour les autres, c'est démarrer une calculette et basculer entre deux logiciels, là encore, le multitache n'était pas indispensable.  il reste donc un faible pourcentage de personne dont le multitache était un nécessité.

Si le fait de "sous exploiter" son Amiga en ne faisant que jouer avec te conduit à conclure "donc multitache : aucun intérêt" c'est sur qu'on avait pas la même vision de l'Amiga !

Ton résumé de l'utilisation du multitache correspond aussi à ce que font, de nos jours, la majorité des utilisateurs de Windows... 
Est ce que pour autant tu conclurais aussi vite "donc multitache : aucun intérêt"... ?
Tiens va dire ça aux monde des entreprises et ajoute "Et les gars revenez TOUS au monotache, on n'a JAMAIS FAIS MIEUX !"... 
Déjà à l'époque les stations de travail le multitache n'était même pas discuté, c'était UNE NECESSITE...
Les entreprises (vidéo, multimédia, graphisme, 3D) qui avait choisit l'Amiga AURAIT TRES BIEN PU PREFERER un PC, un MAC voir un ST, mais ils ont préféré l'Amiga... le multitache y était peut être pour quelque chose...
Parce que beaucoup des utilisateurs du 500 n'étaient que des jeunes qui se cantonnaîent à son aspect ludique, il aurait fallu priver du multitache les professionnelles et ceux qui voulait utiliser l'Amiga pour l'ordinateur qu'il était ? Belle mentalité !
Et comme je l'ai dit, si Jay Miner avait jugé que le multitache n'avait aucun intérêt pour l'Amiga, il n'aurait surement pas recruté Carl Sassenrath... On a vu qu'il s'y connaissait en hardware... tu peux au moins le créditer d'un minimum de connaissance en système d'exploitation pour voir ce qui a un intérêt pour son ordinateur. 
Donc le multitâche sur Amiga, ne t'en déplaise, avait tout son intérêt. Il ne tenait qu'à son utilisateur d'en profiter ou pas. Là encore, tout comme dans son architecture hardware, il donne le choix, soit on se contente d'utiliser l'Amiga au minimum, soit on essaye de découvrir tous ses aspects (le multitâche de l'AmigaOS en est un).
Mais, de toute façon, j'aurais beau faire tous les plaidoyer que je voudrais, on a compris ton point de vue et qu'on ne sera pas d'accord. On se répète une fois de plus.

ce que j'ai fait avec l'amiga ?  un peu de tout : jeux bien sûr, mais aussi de l'utilisation pro.

Oui, ben des fois je doute que tu es fait autre chose que jouer avec ton Amiga. Cette phrase m'avait mis la puce à l'oreille (d'ou ma question)

car j'ai lu ci et là que le multitâche de l'amiga n'était pas si "merveilleux" que l'on le prétend : si le programme était mal codé, ça marchait pas.

Personnellement, je l'ai utilisé au quotidien le multitache de l'Amiga et il fonctionnait plutôt pas mal et mieux que celui de Windows 95 ou MacOS (de l'époque). Quand je lis ce genre de propos de ta part, j'ai un doute sur ton coté "j'ai testé le multitache de l'Amiga et c'était guru sur guru". 

Je n'ai pas prétendu qu'il n'y avait pas des plantages, je dis juste que mon souvenir n'est pas pire que sur Windows 3.1. L'AmigaOS était bien plus stable que Windows 3.1 dans mon souvenir.

bref, on peut conclure que tu es de mauvaise foi   

A ce jeu là je ne peux pas être à ton niveau :)

Comme je l'ai dit, je souhaiterais faire une pause au niveau du débat TOS vs AmigaOS. Je te répondrais, mais en essayant (si j'y arrive) à être plus court. 
Je pense qu'on a fait le tour du débat, au moins pour l'instant. Chacun de nous a son opinion et, sauf, sur des points de détails, on ne sera pas d'accord. 
Comme nos récents échanges le montrent, on retombe sur les même réponses et échanges, bref on se répète. Je souhaite donc faire une pause dans ce débat. Est ce que tu en conviens ?

[rocky007]

Parce que le TOS il pardonne les bugs DU SEUL LOGICIEL qui tourne... comment tu expliques les bombes alors ?
Mais, là encore, cet argument il refait surface à chaque fois dans nos échanges sur l'AmigaOS, comme je te l'ai dit, je pense qu'on a plus rien à ajouter. On a bien compris les positions de chacun et je ne suis pas sur que le lecteur du forum ait envie de nous voir répéter les mêmes choses. 
Tu as préféré le TOS/GEM... très bien. De mon coté j'était très content de mon AmigaOS "soit disant inutilisable"...

oui il y avait t aussi des bombes, c'est vrai, mais cela arrivait moins souvent, c'est logique.  relis mon explication, c'est pourtant clair.  si tu as 1024ko dédié à un programme, celui peut s'approprier l'ensemble de la mémoire et des ressources, et ce même de façon un peu cochone.  qd tu as deux softs en même temps, cela ne pardonne pas.

Et comme, à chaque fois, quand tu fait un pas en avant, tu en fait deux en arrière... et tu vas chercher une autre machine (cette fois le X68000) pour défendre le ST. Comme je te l'ai déjà dit, aussi bien que soit cette machine, en dehors du Japon elle était quasi inconnue et totalement inabordable et inutilisable pour le commun qui ne connaissait pas le japonnais. Et son OS n'était pas multitache, basé sur MS-DOS (je n'ai pas trouvé d'autre infos à ce sujet). Mais combien de fois tout ceci à été dit ici déjà !

mais cela ne change rien au problème:  un machine plus puissante existait en 1988, qu'elle soit "confidentiel" ou pas, cela ne change rien, cela existait.  de plus, les japona le is se pose aussi la même question " c'est quoi un amiga ?"
il y a avait un OS multitache sur X68000, le SX Windows.

Même si le terme miracle me plait bien pour l'Amiga, c'était surtout une volonté de Jay Miner et son équipe d'innover et de proposer quelque chose de jamais vu sur le marché grand public. Ce fait sera vrai de 1985 à 1995 ne t'en déplaise. Mais, là encore, je te l'ai dit été répété, je sais que ça te plait pas de lire ce genre de chose et que tu as une rancune tenace contre l'Amiga (j'en ignore la raison). 

non mais c'est  là que tu me comprends pas : j'adore l'amiga, tout autant que l'atari, je trouve que c'est une machine fabuleuse, mais j'arrive à garder l'eglise au centre du village.  je ne le surestime pas.  et malgré que je reconnais la supériorité évidente de l'amiga sur tout les plan technologique, j'arrive pourtant à trouver des avantages au ST, si l'on le resitue.  Ajourd'hui je ne dirais plus la même chose si je devais acheter une machine, mais en 1985 , le ST avait des atouts indéniables.

Un OS il est multitâche au départ, on ne transforme pas un OS monotache en OS multitache comme ça en claquant du doigt ! Tout ceux qui ont essayé ont été obligé de finalement tout réécrire et de jeter l'OS précédent (Windows/MacOS et le TOS aussi puisqu'il fallait zapper  TOS/GEM en ROM pour utiliser multiTOS sur disque dur... 
Mais, tout ça aussi on l'a dit et redit en long et ne large et on a bien compris qu'on ne sera pas d'accord.

je ne peux te répondre sur ce point, je pense que certains ici qui utilisent le MultiTOs pourront mieux répondre.  Mais je suppose que des versions patchées de logiciels tels que Calamus , cubase etc.. ont dû existé, comme cela existe pour les jeux ST -> Falcon.  mais je te l'accord aussi, c'est en effet un problème, et je te rejoins sur le fait que commencer un OS multitâche dès le début permet d'éviter ce genre de problème.  Mais je souligne que je ne m'y connais pas en multitos.  car je vois pas pourquoi un soft bien respectant scrupuleusement le GEM ne pourrait tourner sur MultiOS.  les quelques programmes que j'ai essayé sur mon falcon fonctionnait sans problème en tous cas.

Alors bon si tu as investit dans des logiciels, le moins que tu attends, c'est que la version suivante de l'OS puisse continuer à les faire tourner. Hors, le test sur ce site Atari, dis clairement, que ce n'était pas le cas avec MultiTOS... tu vas quand même pas dire qu'ils affabulent.

ce n'est pas vrai : combien de périphériques j'ai dû racheter parce que les drivers n'existaient pas en Win X.X, ou de programmes incompatibles.




pourtant je me souviens parfaitement que pour formater une simple disquette, il fallait réinsérer la disquette WB.
donc tout ne se chargeait pas en mémoire.




ce bug ne touche que certaines modèles de STE entre 88 et 90, et se produit avec des disques durs non officiels dans certaines conditions.  c'est donc loin de faire une généralité.





je vais très honnête : je ne m'en souvenais pas qu'il y en avait   par exemple, qu'un logiciel auto reso ne boot pas dans un dossier auto, je m'en souviens pas ( du reste, est-ce si grave ? )... idem l'ordre des fichiers dans ce même répertoire pour définir l'odre de boot, etc..)  tout ça est très loin , 25 ans déjà !

Tu compares POV avec Lightwave... trop fort !
Et vas y tiens sur un OS monotache faire un calcul POV en tache de fond :) 

Pour le calcul parallèle si le TOS avait pu le faire, pourquoi ils ont pas pris le TOS à la place d'HELIOS comme OS pour leur Transputer ?

Note que je peux me tromper, je ne suis pas expert, mais du calcul parallèle ça sonne quand même plus "multitache" que "monotache".

je ne compare pas ces deux logiciels, je parle du principe .  le calcul parallèle peut se faire aussi comme aujourd'hui avec le cloud computing : tu envoies un liste de tâches à calculer sur un serveur, celui-ci te renvoie le boulot terminé et ensuite tu assembles le tout.  POV fonctionnait avec des scripts, il était peut-être possible de faire traiter différent aspect de l'image par différent machine.  Je ne sais pas du tout, je dis simplement que techniquement, même avec un environnement monotâche tu peux faire du calcul parallèle.

Est ce que pour autant tu conclurais aussi vite "donc multitache : aucun intérêt"... ?
Tiens va dire ça aux monde des entreprises et ajoute "Et les gars revenez TOUS au monotache, on n'a JAMAIS FAIS MIEUX !"... 

Déjà à l'époque les stations de travail le multitache n'était même pas discuté, c'était UNE NECESSITE...

Les entreprises (vidéo, multimédia, graphisme, 3D) qui avait choisit l'Amiga AURAIT TRES BIEN PU PREFERER un PC, un MAC voir un ST, mais ils ont préféré l'Amiga... le multitache y était peut être pour quelque chose...


Parce que beaucoup des utilisateurs du 500 n'étaient que des jeunes qui se cantonnaîent à son aspect ludique, il aurait fallu priver du multitache les professionnelles et ceux qui voulait utiliser l'Amiga pour l'ordinateur qu'il était ? Belle mentalité !

j'ai pas dit que c'était inutile, je dis que en 1985 sur une machine de base, c'est peu utilisé et secondaire, évidement sur une vision long terme, cela a été finalement un bon choix

alors oui certains boites on préféré l'amiga, mais ce plus pour ses perfomances graphiques,sonores, genlocking etc.. que pour son multitâche.  tout comme il y a des entreprises qui ont préféré l'Atari à l'Amiga pour la PAO, MAO, etc..preuve que même sans multitache, des société on opté pour le ST et que par conséquent ce n'est pas si indispensable que tu le prétends !

Je n'ai pas prétendu qu'il n'y avait pas des plantages, je dis juste que mon souvenir n'est pas pire que sur Windows 3.1. L'AmigaOS était bien plus stable que Windows 3.1 dans mon souvenir.

j'ai bcp bossé de façon pro sur l'amiga, spécialement avec les serveurs BBS, ainsi que graphisme et soundtracker.
je n'y jouais presque pas en fait, j'admirais le jeu mais je ne jouais pas.  idem sur ST, j'ai peut-être terminé 4 - 5 jeux maximum.

Comme nos récents échanges le montrent, on retombe sur les même réponses et échanges, bref on se répète. Je souhaite donc faire une pause dans ce débat. Est ce que tu en conviens ?

[/quote]

oui c'est vrai qu'on tourne un peu en rond

[babsimov]

Parce que le TOS il pardonne les bugs DU SEUL LOGICIEL qui tourne... comment tu expliques les bombes alors ?
Mais, là encore, cet argument il refait surface à chaque fois dans nos échanges sur l'AmigaOS, comme je te l'ai dit, je pense qu'on a plus rien à ajouter. On a bien compris les positions de chacun et je ne suis pas sur que le lecteur du forum ait envie de nous voir répéter les mêmes choses. 
Tu as préféré le TOS/GEM... très bien. De mon coté j'était très content de mon AmigaOS "soit disant inutilisable"...

oui il y avait t aussi des bombes, c'est vrai, mais cela arrivait moins souvent, c'est logique.  relis mon explication, c'est pourtant clair.  si tu as 1024ko dédié à un programme, celui peut s'approprier l'ensemble de la mémoire et des ressources, et ce même de façon un peu cochone.  qd tu as deux softs en même temps, cela ne pardonne pas.

J'ai reconnu l'absence de ressource tracking, c'est même moi qui te l'es dit... et la protection mémoire aussi tout le monde le savait. Alors, oui ça aurait été bien de l'avoir, et, malgré qu'on ne l'avait pas, je te dis que ça plantait moins que tu le dit et qu'on pouvait travailler avec. Mais j'avais dit que je ferais court, pour ce point je vais pas plus loin (il suffit de relire les dizaines de pages pour avoir mon point de vue :) )

Et comme, à chaque fois, quand tu fait un pas en avant, tu en fait deux en arrière... et tu vas chercher une autre machine (cette fois le X68000) pour défendre le ST. Comme je te l'ai déjà dit, aussi bien que soit cette machine, en dehors du Japon elle était quasi inconnue et totalement inabordable et inutilisable pour le commun qui ne connaissait pas le japonnais. Et son OS n'était pas multitache, basé sur MS-DOS (je n'ai pas trouvé d'autre infos à ce sujet). Mais combien de fois tout ceci à été dit ici déjà !

mais cela ne change rien au problème:  un machine plus puissante existait en 1988, qu'elle soit "confidentiel" ou pas, cela ne change rien, cela existait.  de plus, les japona le is se pose aussi la même question " c'est quoi un amiga ?"
il y a avait un OS multitache sur X68000, le SX Windows.

https://en.wikipedia.org/wiki/SX-Windows
Je ne dirais qu'une chose "SX-Windows was a non-preemptive...." disqualifié, normal c'était basé sur MS-DOS.

Même si le terme miracle me plait bien pour l'Amiga, c'était surtout une volonté de Jay Miner et son équipe d'innover et de proposer quelque chose de jamais vu sur le marché grand public. Ce fait sera vrai de 1985 à 1995 ne t'en déplaise. Mais, là encore, je te l'ai dit été répété, je sais que ça te plait pas de lire ce genre de chose et que tu as une rancune tenace contre l'Amiga (j'en ignore la raison). 

non mais c'est  là que tu me comprends pas : j'adore l'amiga, tout autant que l'atari, je trouve que c'est une machine fabuleuse, mais j'arrive à garder l'eglise au centre du village.  je ne le surestime pas.  et malgré que je reconnais la supériorité évidente de l'amiga sur tout les plan technologique, j'arrive pourtant à trouver des avantages au ST, si l'on le resitue.  Ajourd'hui je ne dirais plus la même chose si je devais acheter une machine, mais en 1985 , le ST avait des atouts indéniables.

Excuse moi, mais ton "adoration" de l'Amiga n'a pas transpirée souvent :)
Et, moi aussi, j'ai reconnu des atouts indéniables au ST (SCSI, mode monochrome et son écran pas cher, MIDI). Mais je reste aussi lucide, et quand tu dis que le ST était "une machine de première catégorie" "une conception parfaite dès le premier jour" et ce genre de chose... Tu comprendras que je puisse réagir vertement... car on a vu laquelle des deux machines est mieux conçue... c'est l'Amiga et ça c'est indéniable.
Je me tient à ce que j'ai dit, je fait plus court.

Un OS il est multitâche au départ, on ne transforme pas un OS monotache en OS multitache comme ça en claquant du doigt ! Tout ceux qui ont essayé ont été obligé de finalement tout réécrire et de jeter l'OS précédent (Windows/MacOS et le TOS aussi puisqu'il fallait zapper  TOS/GEM en ROM pour utiliser multiTOS sur disque dur... 
Mais, tout ça aussi on l'a dit et redit en long et ne large et on a bien compris qu'on ne sera pas d'accord.

je ne peux te répondre sur ce point, je pense que certains ici qui utilisent le MultiTOs pourront mieux répondre.  Mais je suppose que des versions patchées de logiciels tels que Calamus , cubase etc.. ont dû existé, comme cela existe pour les jeux ST -> Falcon.  mais je te l'accord aussi, c'est en effet un problème, et je te rejoins sur le fait que commencer un OS multitâche dès le début permet d'éviter ce genre de problème.  Mais je souligne que je ne m'y connais pas en multitos.  car je vois pas pourquoi un soft bien respectant scrupuleusement le GEM ne pourrait tourner sur MultiOS.  les quelques programmes que j'ai essayé sur mon falcon fonctionnait sans problème en tous cas.

Je pense que la personne qui a écrit le test comparatif Falcon/Amiga 1200 connaissait le MultiTOS et n'a pas écrit ça à la légère. Ce test me semble tout à fait impartial et présente vraiment les qualités et défauts de chacune des deux machines. Sur ce point, je ne peux aller plus loin non plus.

Alors bon si tu as investit dans des logiciels, le moins que tu attends, c'est que la version suivante de l'OS puisse continuer à les faire tourner. Hors, le test sur ce site Atari, dis clairement, que ce n'était pas le cas avec MultiTOS... tu vas quand même pas dire qu'ils affabulent.

ce n'est pas vrai : combien de périphériques j'ai dû racheter parce que les drivers n'existaient pas en Win X.X, ou de programmes incompatibles.

On parlait d'Atari et de MultiTOS face à l'AmigaOS. La politique de Microsoft a quasiment toujours été celle que tu décrit. Ils ont le monopoles, pour eux c'est facile. Par contre, pour Atari et Commodore s'assurer que l'investissement des utilisateurs soit rentable, ça me paraissait très important pour leur pérennité... 
Regarde Apple, même en changeant d'OS, de processeur, ils se sont assuré d'avoir un émulateur performant pour, justement cela. Ils pouvaient pas se permettre de perdre des utilisateurs, alors que Microsoft, de toute façon ils savent que d'une manière ou d'un autre tu n'auras pas d'autre choix tôt ou tard.

pourtant je me souviens parfaitement que pour formater une simple disquette, il fallait réinsérer la disquette WB.
donc tout ne se chargeait pas en mémoire.

Quand ais je dit que d'avoir tout en ROM n'avait pas certains avantages ? Je pense même l'avoir dit dans les tous débuts du débat.

ce bug ne touche que certaines modèles de STE entre 88 et 90, et se produit avec des disques durs non officiels dans certaines conditions.  c'est donc loin de faire une généralité.

Le problème n'est pas là. Le problème c'est que même si tu changes le composant par un composant débogué, tu n'es même pas sur que sa fonctionne... Sur Amiga quand tu changes BUSTER, tu es SUR que ton problème est réglé. Si tu n'a pas la chance d'avoir le ST avec le bon composant installé d'origine, ce sera la loterie en espérant que tu sera gagnant (ça montre bien un problème sur les cartes mère ça).

je vais très honnête : je ne m'en souvenais pas qu'il y en avait 

  par exemple, qu'un logiciel auto reso ne boot pas dans un dossier auto, je m'en souviens pas ( du reste, est-ce si grave ? )... idem l'ordre des fichiers dans ce même répertoire pour définir l'odre de boot, etc..)  tout ça est très loin , 25 ans déjà !

Enfin une parole censée "tu t'en souvenais pas"... mais aussitôt concernant les bugs TOS "du reste est-ce si grave" alors que sur AmigaOS pour toi "c'était la catastrophe". 
Tu veux que je sois honnête avec toi aussi... mon Workbench 1.3 je l'ai jamais mis à jour entre 1989 et 1992. C'était la disquette que m'avait donné le revendeur en échange de 1.2. Les bugs du 1.3 j'en ignorais même jusqu'à l'existence... et pendant ces 3/4 ans (car je ne sais plus si je n'ai pas eu le 1.3 déjà fin 1988) j'ai très bien pu travailler avec mon Amiga sans avoir de visites du guru à gogo comme tu le dis. Il faut que je fasse court alors je vais pas plus loin.

Tu compares POV avec Lightwave... trop fort !
Et vas y tiens sur un OS monotache faire un calcul POV en tache de fond :) 

Pour le calcul parallèle si le TOS avait pu le faire, pourquoi ils ont pas pris le TOS à la place d'HELIOS comme OS pour leur Transputer ?

Note que je peux me tromper, je ne suis pas expert, mais du calcul parallèle ça sonne quand même plus "multitache" que "monotache".

je ne compare pas ces deux logiciels, je parle du principe .  le calcul parallèle peut se faire aussi comme aujourd'hui avec le cloud computing : tu envoies un liste de tâches à calculer sur un serveur, celui-ci te renvoie le boulot terminé et ensuite tu assembles le tout.  POV fonctionnait avec des scripts, il était peut-être possible de faire traiter différent aspect de l'image par différent machine.  Je ne sais pas du tout, je dis simplement que techniquement, même avec un environnement monotâche tu peux faire du calcul parallèle.

Moi non plus je ne suis pas expert dans le domaine. Je m'étonnais juste que le TOS ait été écarté dans le cas du Transputer Atari.

Est ce que pour autant tu conclurais aussi vite "donc multitache : aucun intérêt"... ?
Tiens va dire ça aux monde des entreprises et ajoute "Et les gars revenez TOUS au monotache, on n'a JAMAIS FAIS MIEUX !"... 

Déjà à l'époque les stations de travail le multitache n'était même pas discuté, c'était UNE NECESSITE...

Les entreprises (vidéo, multimédia, graphisme, 3D) qui avait choisit l'Amiga AURAIT TRES BIEN PU PREFERER un PC, un MAC voir un ST, mais ils ont préféré l'Amiga... le multitache y était peut être pour quelque chose...


Parce que beaucoup des utilisateurs du 500 n'étaient que des jeunes qui se cantonnaîent à son aspect ludique, il aurait fallu priver du multitache les professionnelles et ceux qui voulait utiliser l'Amiga pour l'ordinateur qu'il était ? Belle mentalité !

j'ai pas dit que c'était inutile, je dis que en 1985 sur une machine de base, c'est peu utilisé et secondaire, évidement sur une vision long terme, cela a été finalement un bon choix

Moi, je te dit que le multitâche à n'importe quelle époque de l'informatique (ça a existé assez tôt), c'était TOUJOURS UN PLUS très appréciable.
Ah, enfin une parole de lucidité de ta part "sur le long terme c'était un bon choix" :) Merci Rocky007

alors oui certains boites on préféré l'amiga, mais ce plus pour ses perfomances graphiques,sonores, genlocking etc.. que pour son multitâche.  tout comme il y a des entreprises qui ont préféré l'Atari à l'Amiga pour la PAO, MAO, etc..preuve que même sans multitache, des société on opté pour le ST et que par conséquent ce n'est pas si indispensable que tu le prétends !

Certes, ce sont les caractéristiques vidéo etc de l'Amiga qui ont d'abord fait porter vers lui le choix de telle ou telle entreprise. Mais le multitâche leur a apporté un confort d'utilisation très appréciable. Tu te rappel de Lightwave et de l'Amigaiste qui avait l'Amiga de compétition et le PC de compétition. Le PC de compétition faisait tourner Lightwave et WindowNT était multitâche... mais il préférait travailler sur l'Amiga  avec Lightwave, parce que le multitâche de l'Amiga était plus réactif. J'allais repartir sur une longue tirade, mais j'ai déjà dit tout ça en substance (relire les dizaines de pages :) )
Quand il s'agit de comparer l'utilisation au quotidien entre deux logiciels identiques, sur deux OS différents, le multitâche peut devenir un critère de choix.

Je n'ai pas prétendu qu'il n'y avait pas des plantages, je dis juste que mon souvenir n'est pas pire que sur Windows 3.1. L'AmigaOS était bien plus stable que Windows 3.1 dans mon souvenir.

j'ai bcp bossé de façon pro sur l'amiga, spécialement avec les serveurs BBS, ainsi que graphisme et soundtracker.
je n'y jouais presque pas en fait, j'admirais le jeu mais je ne jouais pas.  idem sur ST, j'ai peut-être terminé 4 - 5 jeux maximum.

Les BBS, tout ça je connaissais que de nom. Ca demandait beaucoup de temps et de connaissances ça ?

Comme nos récents échanges le montrent, on retombe sur les même réponses et échanges, bref on se répète. Je souhaite donc faire une pause dans ce débat. Est ce que tu en conviens ?

oui c'est vrai qu'on tourne un peu en rond 

Faisons donc cette pause sur le TOS et l'AmigaOS pour mieux reprendre dans quelques temps :)

[drfloyd]

En tout cas votre débat est explosif !!!

La guerre ST Amiga n'aura donc jamais de fin ?