Re: GUERRE ST-AMIGA, FIGHT !!!

par ryosaeba Mar 8 Sep 2015 - 21:44

babsimov a écrit:
ryosaeba a écrit:Voila je l'ai posté :

Sauf, que sur Amiga c'est plus rapide et qu'à un moment ça tourne et ça bouge aussi dans la profondeur. C'était ce dont je me souvenais et je viens de vérifier en regardant sur youtube.

L'enregistrement n'est pas parfait, la faute à Windows 10............. Je pense ne pas avoir enregistré suffisamment longtemps pour voir tous les effets.....

par Seb Mar 8 Sep 2015 - 21:49

Ryosaeba: en plus Youtube doit la jouer à 30 images secondes vu que tu n'es pas en HD. Iil me semble qu'il faut être en HD pour avoir accès aux 60 fps sur Youtube non?

par ryosaeba Mar 8 Sep 2015 - 22:01

par cryodav76 Mar 8 Sep 2015 - 22:44

ryosaeba a écrit:

par rocky007 Mer 9 Sep 2015 - 9:50

babsimov a écrit:J'avoue que je suis pas assez calé pour te répondre. Pour une musique, que veux tu dire ? si deux jouent la même musique en même temps ? Je pense que ça fera un écho, la même musique joué en même temps ? Ou alors, tout simplement, le lecteur de la musique lancé en second se verra refusé l'accès à Paula, tant que la premier lecteur n'est pas fermé. Honnétement j'en sais rien du tout, je me souviens pas d'avoir eu un cas comme ça sur Amiga.

ok merci du renseignement... je ne me souviens pas non plus, j'étais curieux de voir comment il gérait cela.

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.
par exemple, si un soft ne rendait pas la main sur les ressources, le second programme est tout simplement bloqué en attente de la libération des ressources.
idem, en quittant un programme, c'est à lui à remettre tout en ordre, s'il ne le fait pas proprement, cela reste en l'état, raison des nombreux guru.

GUERRE ST-AMIGA, FIGHT !!! - Page 3 Capture

GUERRE ST-AMIGA, FIGHT !!! - Page 3 Capture

par rocky007 Mer 9 Sep 2015 - 10:02

babsimov a écrit: Je vais poser une question à la cantonade (en fait cette question m'en a amené plusieurs du coup). C'est certainement un peu hors sujet, voir beaucoup hors sujet, mais j'aimerais avoir l'avis de la communauté ST/Amiga présente ici.

Voici donc que quoi il s'agit. A l'époque du ST/Amiga, j'ai le sentiment (avec mes lectures d'époque et aussi sur Internet) que beaucoup de système d'exploitation, logiciels, jeux et bien entendu démo était programmés en assembleur. Ce qui, je pense explique que, finalement ces première machine avec GUI faisaient sensiblement les même choses (bureautique) au moins d'une manière aussi rapide (toute proportion gardée) que ne le font de nos jours les PC (mais en ayant besoin d'une configuration minimum pour le faire bien supérieure à celle de l'époque).
J'ai lu sur internet, que de nos jours, la plupart des OS ou logiciels ne sont plus écrit en assembleur, mais dans des langages de plus haut niveau.

La question est la suivante : Est ce un effet nostalgie qui me conduit à croire que l'assembleur et l'optimisation qui va avec était plus présent à l'époque ST/Amiga ou est ce une réalité.

Et, les autres questions que cela amène sont :
- Les programmeurs actuelles (en particulier les jeunes) sont ils moins doués, inventifs, connaisseurs, passionnés ou formés qu'autrefois (ce n'est en aucune façon un jugement mais une question) ?
- Les processeurs actuelles (AMD/ARM/INTEL) sont t ils devenu trop compliqué à programmer en assembleur (c'est une chose que j'avais lu pour justifier ce choix des langage plus haut niveau)
- Est ce, tout simplement une considération économique, l'assembleur étant trop couteux en terme de temps de développement ?

Voilà, c'est très probablement hors sujet dans ce débat, mais je ne voyais pas ou la poser pour avoir l'avis des générations de programmeurs ST/Amiga. D'autant plus que ça permet d'appaîser, pour un temps le débat, je pense.

Comme dirais les guignols "quand on arrive pas régler un problème, le mieux est de changer de problème !"

aujourd'hui l'assembleur est devenu très rare. les seuls applications que l'ont en fait est surtout pour les microcontrolleurs, où il y a encore des contraintes de vitesses /mémoire.
sur les ordinateurs, c'est un peu problématique, car avec la rotation rapide des processeurs, les programmes seront rapidement incompatibles, et ce sans oublier le nombre de ressources qu'il faudra prendre en compte en assembleur et qui sont gérées de façon transparente en C par exemple.

c'est l'avantage des langages comme le C++, C sharp, Unreal, unity ( pour les jeux ) etc.. : la quantité de librairies existantes, qui réduit au minimum le travail du codeur.
C'est même frustrant : imaginons que tu aies besoin d'un générateur de bruit fractal, auparavant tu l'aurais codé par toi-même, pris des jours à le faire, à l'optimiser. aujourd'hui, il y 99% de chance qu'un mec a déjà fait ce boulot, et probablement mieux optimisée que tu ne l'aurais fait toi même, car étant open source, ce code aura été vu et amélioré par la communauté. il suffit de télécharger sa librairie et l'utiliser. c'est vrai que expliqué comme ça, ça parait bien, mais d'un autre côté tu as de moins en moins la main sur ton programme : on se retrouve avec un multitude de libraires écrites par d'autres, et dont tu ne connais pas ( sauf si tu passes ton temps à l'analyser ) ce qu'elles comportent exactement. bref, c'est travailler un peu à l'aveugle, et c'est très déroutant pour des codeurs des années 80 qui faisait tout par eux-même et avait la maitrise sur l'ensemble de leur programme.

par cryodav76 Mer 9 Sep 2015 - 11:59

rocky007 a écrit:
babsimov a écrit: Je vais poser une question à la cantonade (en fait cette question m'en a amené plusieurs du coup). C'est certainement un peu hors sujet, voir beaucoup hors sujet, mais j'aimerais avoir l'avis de la communauté ST/Amiga présente ici.

Voici donc que quoi il s'agit. A l'époque du ST/Amiga, j'ai le sentiment (avec mes lectures d'époque et aussi sur Internet) que beaucoup de système d'exploitation, logiciels, jeux et bien entendu démo était programmés en assembleur. Ce qui, je pense explique que, finalement ces première machine avec GUI faisaient sensiblement les même choses (bureautique) au moins d'une manière aussi rapide (toute proportion gardée) que ne le font de nos jours les PC (mais en ayant besoin d'une configuration minimum pour le faire bien supérieure à celle de l'époque).
J'ai lu sur internet, que de nos jours, la plupart des OS ou logiciels ne sont plus écrit en assembleur, mais dans des langages de plus haut niveau.

La question est la suivante : Est ce un effet nostalgie qui me conduit à croire que l'assembleur et l'optimisation qui va avec était plus présent à l'époque ST/Amiga ou est ce une réalité.

Et, les autres questions que cela amène sont :
- Les programmeurs actuelles (en particulier les jeunes) sont ils moins doués, inventifs, connaisseurs, passionnés ou formés qu'autrefois (ce n'est en aucune façon un jugement mais une question) ?
- Les processeurs actuelles (AMD/ARM/INTEL) sont t ils devenu trop compliqué à programmer en assembleur (c'est une chose que j'avais lu pour justifier ce choix des langage plus haut niveau)
- Est ce, tout simplement une considération économique, l'assembleur étant trop couteux en terme de temps de développement ?

Voilà, c'est très probablement hors sujet dans ce débat, mais je ne voyais pas ou la poser pour avoir l'avis des générations de programmeurs ST/Amiga. D'autant plus que ça permet d'appaîser, pour un temps le débat, je pense.

Comme dirais les guignols "quand on arrive pas régler un problème, le mieux est de changer de problème !"

aujourd'hui l'assembleur est devenu très rare. les seuls applications que l'ont en fait est surtout pour les microcontrolleurs, où il y a encore des contraintes de vitesses /mémoire.
sur les ordinateurs, c'est un peu problématique, car avec la rotation rapide des processeurs, les programmes seront rapidement incompatibles, et ce sans oublier le nombre de ressources qu'il faudra prendre en compte en assembleur et qui sont gérées de façon transparente en C par exemple.

c'est l'avantage des langages comme le C++, C sharp, Unreal, unity ( pour les jeux ) etc.. : la quantité de librairies existantes, qui réduit au minimum le travail du codeur.
C'est même frustrant : imaginons que tu aies besoin d'un générateur de bruit fractal, auparavant tu l'aurais codé par toi-même, pris des jours à le faire, à l'optimiser. aujourd'hui, il y 99% de chance qu'un mec a déjà fait ce boulot, et probablement mieux optimisée que tu ne l'aurais fait toi même, car étant open source, ce code aura été vu et amélioré par la communauté. il suffit de télécharger sa librairie et l'utiliser. c'est vrai que expliqué comme ça, ça parait bien, mais d'un autre côté tu as de moins en moins la main sur ton programme : on se retrouve avec un multitude de libraires écrites par d'autres, et dont tu ne connais pas ( sauf si tu passes ton temps à l'analyser ) ce qu'elles comportent exactement. bref, c'est travailler un peu à l'aveugle, et c'est très déroutant pour des codeurs des années 80 qui faisait tout par eux-même et avait la maitrise sur l'ensemble de leur programme.

je sais meme pas si faire par exemple un jeu(commercial ) en assembleur serai possible tellement la somme de travail serai important
meme sur console a architecture fixe je pense pas que ce soit le cas..
d'ailleur combien de temps on mis les programmeurs pour exploiter l'amiga ou meme le st a fond? on découvre même encore aujourd'hui des demos innovantes...

par Doctoritchy Mer 9 Sep 2015 - 12:54

tout jeu actuelle repose sur un moteur graphique , par moteur j'entend un récode et une interface "graphique" permetant de crée aisement toute sorte de jeu , c'est moteur graphique sont dédier pour le type de jeu , allant du simple appli php web au moteur pro (doom , cs , steam devellopement , unreal , ect ect ! )

c'est du prémacher +- car le travail est toujours complexe il faut crée les texture , modélisé , crée des spam point , travaillé l'IA , ect

on est loin des codeur que l'on as eu pour les "vieux" jeux , certain jeu complexe sont dévollopé sur des soft "maison" et du raylight ,catia ect :)

sur console idem il y as les soft de base qui crée le code automatiquement il faut en gros "copier coller" les texture les son , les interactions apres le soft s'occupe de codé , puis il y as les debbuger qui vont corriger le code si le system as fait des bug ( et il en fait bcp :) )

actuellement on exploite pas as "fond" on fait un jeu sur un moteur graphique "standardisé" on débug pour que le jeu soit performant sur un type de configuration ( type de config indiquée sur la pochette du jeu ) apres pour les autre config c'est au drivers des diverse carte acceleratrice de "géré" donc non c'est plus comme avant as cherché as grapiller 1 ou 2 instruction pour optimiser le temps cpu !!!

si on codais comme avant sur une machine actuelle que le jeu pourrais booter sur le dvd sans se soucier de quoi est installé sur les disque dur que le jeu aurais son propre systeme d'exploitation ses propre drivers dédier sur mesure sa propre gestion memoire , enfin si le jeu controlais chaque composant du "pc" avec une machine de base on pourrais surement faire tourné un jeu qui ne tourne actuellement que sur le plus gros pc disponible actuellement !!!

par Seb Mer 9 Sep 2015 - 13:58

Doctoritchy a écrit:tout jeu actuelle repose sur un moteur graphique , par moteur j'entend un récode et une interface "graphique" permetant de crée aisement toute sorte de jeu , c'est moteur graphique sont dédier pour le type de jeu , allant du simple appli php web au moteur pro (doom , cs , steam devellopement , unreal , ect ect ! )

c'est du prémacher +- car le travail est toujours complexe il faut crée les texture , modélisé , crée des spam point , travaillé l'IA , ect

on est loin des codeur que l'on as eu pour les "vieux" jeux , certain jeu complexe sont dévollopé sur des soft "maison" et du raylight ,catia ect :)

sur console idem il y as les soft de base qui crée le code automatiquement il faut en gros "copier coller" les texture les son , les interactions apres le soft s'occupe de codé , puis il y as les debbuger qui vont corriger le code si le system as fait des bug ( et il en fait bcp :) )

actuellement on exploite pas as "fond" on fait un jeu sur un moteur graphique "standardisé" on débug pour que le jeu soit performant sur un type de configuration ( type de config indiquée sur la pochette du jeu ) apres pour les autre config c'est au drivers des diverse carte acceleratrice de "géré" donc non c'est plus comme avant as cherché as grapiller 1 ou 2 instruction pour optimiser le temps cpu !!!

si on codais comme avant sur une machine actuelle que le jeu pourrais booter sur le dvd sans se soucier de quoi est installé sur les disque dur que le jeu aurais son propre systeme d'exploitation ses propre drivers dédier sur mesure sa propre gestion memoire , enfin si le jeu controlais chaque composant du "pc" avec une machine de base on pourrais surement faire tourné un jeu qui ne tourne actuellement que sur le plus gros pc disponible actuellement !!!

FAUX FAUX FAUX, je ne suis pas du tout d'accord avec ce concept de "prémaché" et de "on ne pousse pas à fond" :)
(je me permets car c'est mon boulot et ca va faire 10 ans que notre équipe utilise des déclinaisons/évolutions de moteurs maison).

Quand on utilise un moteur, on code quand même la plupart des trucs et on en ajoute en permanence. Le moteur qui fait tout pour toi, en tout cas pour les gros jeux, est un mythe, idem pour "le code est généré par le moteur". Pour un petit jeu indé fait à la maison, c'est un autre histoire, la complexité d'un "petit" jeu est en général gérable par Unity sans trop de code par exemple, via des langages de scripting etc, mais même là, tu vas devoir coder si tu veux pousser un peu.

On essaie d'exploiter à fond la machine, de fond en comble, on fait du profiling tous les jours, CPU et GPU, on regarde tous les jours comment mieux threader les taches sur les différents cores, mieux organiser les jobs CPU, mieux utiliser le GPU (async compute shaders etc), mieux utiliser le cache du CPU, éviter les stalls, etc etc. Même si le gamer a l'impression que non, on passe tous les jours du temps à optimiser. Je ne compte plus le nombre de fois ou quelqu'un dans l'équipe a réorganisé notre renderthread pour grapiller quelques millisecondes et moins.

Non, un moteur ne pond pas le code pour toi, c'est un mythe ca (je parle une fois de plus de gros jeux, pas d'un petit jeu indé fait à la maison). Un moteur va te donner accès à différentes choses, va avoir des tools intégrés, va avoir certaines couches déjà faites, des inits, il va inclure des lib mais c'est très loin de représenter le gros du travail du jeu et le gros du code, et encore moins les optimisations.

Ca ne se voit pas pour le gamer au final car la complexité d'un jeu et de son code est sans commune mesure avec ce qui se faisait il y a 10 ans (et encore moins il y a 25 ans).

Un moteur, ca sert à ne pas réinventer la roue, à ne pas te soucier de certaines choses si tu ne veux pas, ou en tout cas le moins possible, à ne pas recoder les trucs de bases pour chaque jeu, à t'offrir une solution clé en main pour les fondations. Après, il y a tout le reste spécifique à ton jeu, et ca c'est très gros si tu veux pousser un minimum la qualité. D'ailleurs, le même moteur original utilisé sur 2 jeux dans 2 studios différents finit généralement par donner 2 moteurs très différents de l'original avec un code fortement modifié et parfois des concepts devenus complètement incompatibles.

Pour donner un exemple qui n'est pas celui que j'ai sous les yeux: pour un jeu comme Batman qui utilise Unreal l'équipe a sans doute ré-écrit plein de choses, modifié plein de choses, car un moteur offre rarement ce qui colle aux contraintes de ton jeu (open world ou jeu linéaire, lighting précalculé ou time of day dynamique, déplacement à pieds ou en voiture changeant considérablement les problématiques de streaming du data, jeu de course sur un circuit ou jeu dans une ville ou zone immense, etc etc etc).

Autre exemple: un jeu utilise Havok, le moteur physique. Contrairement à ce qu'on peut croire, un gros jeu va prendre un programmeur physique à plein temps même avec Havok, car non, Havok ne va pas pondre le code pour toi. Il te donne les briques de base, des concepts, mais tu dois quand même coder un paquet de choses, faire que ce que Havok propose soit utilisable et compatible avec ton jeu, ses contraintes, son gameplay, son architecture, la facon dont son data est gérée, les besoins de ton jeu etc. Aussi puissant soit-il, Havok ne simule pas l'univers, c'est à toi de coder les comportements qui t'intéressent, particulièrement dans le cadre d'un jeu.

Pour revenir à l'assembleur, dans un moteur de jeu on a très très très peu de choses écrites en assembleur, sauf certaines routines très critiques, parce que ca n'aurait aucun intéret en terme de gains.

Ex: Sur PS3, il arrivait à certains de faire de l'assembleur sur SPU pour mieux les utiliser (intrinsics), mais ca n'était pas parce que le compilateur faisait moins bien, c'était pour une autre raison plus compliquée de data et instructions 128 bytes.
Sur les GPU, on regarde le code produit par les compilateurs de shaders pour voir si on peut faire mieux, avoir une meilleure occupancy etc.

Les compilateurs sont devenus extrêmement performants (et les CPU très complexes), donc écrire du code de gameplay, de rendu, de physique ou autre en assembleur n'aurait aucun intéret. Le vrai gain, en temps et en perfs, est de savoir ce que ton code va générer, si ton algo est intelligent, si il est "cache friendly", si tes données sont bien organisées, etc.

Donc pour répondre à la question intéressante de Babsimov: non, on ne fait plus d'assembleur dans les jeux console/PC sauf pour des sections critiques ou très spécifiques (et très rares). Ca serait une perte de temps, ca serait infaisable en temps, ingérable niveau lisibilité du code (quand ton équipe a 30 programmeurs et que tu veux que ce code soit réutilisé plus tard) et ca n'apporterait aucun gain en performances (vraiment)

Le vrai gain est de bien connaitre l'architecture de ta machine, savoir comment organiser ton code et ton data en fonction, savoir si ton algo est optimal et bien pensé, si il utilise bien le cache, maitriser le multithreading etc.

Et contrairement aux mythes et idées recues véhiculés sur internet, les programmeurs font de l'optim en permanence, et de facon très pointue, aucun moteur ne pond le code pour eux. Certes la compléxité des jeux actuels ne rend sans doute pas ca évident mais c'est pourtant un fait :)

par Seb Mer 9 Sep 2015 - 17:40

J'ai modifié mon post au dessus pour que ca soit plus complet.

Pour illustrer, les jeux ci-dessous utilisent leur propre moteur, que les dev connaissent parfaitement, et pourtant ca prend une armée de programmeurs pour la Nème itération de leur franchise:

GTA 5: rien que dans les locaux de Rockstar North ~50 programmeurs dans les crédits
Skyrim: 35

Pour le dernier Batman qui utilise un moteur externe, Unreal, tu compteras une 40aine de programmeurs sur tous les sites, car un moteur est loin de faire le travail à leur place :)

Pour revenir à l'assembleur, j'avais eu une discussion avec le codeur de Populous et Powermonger sur ST il y a un an (Glenn Corpes), il me racontait qu'il avait écrit Populous en C et ensuite Powermonger 100% en assembleur, mais qu'avec du recul il avait regretté, que ca n'avait finalement pas vraiment été utile de tout refaire en assembleur (et j'imagine que ca lui avait pris plus de temps). Les quelques sections de code critique auraient surement suffi.

par Invité Mer 9 Sep 2015 - 18:21

J'ai toujours perçu powermonger comme bien plus abouti techniquement que populous quand j'y jouais .

par Seb Mer 9 Sep 2015 - 19:45

TOUKO a écrit:J'ai toujours perçu powermonger comme bien plus abouti techniquement que populous quand j'y jouais .

Ca n'est pas forcément lié au choix du langage mais possiblement plus à la chronologie et aux connaissances accumulées sur la programmation et la maitrise d'un type de jeu et de plateforme.

Uncharted 2 est plus abouti techniquement que le 1, tout comme Assassin's Creed 2 face au 1, Batman Arkham City face à Asylum, Skyrim face à Oblivion, Xenon 2 face à Xenon 1 etc...

par rocky007 Mer 9 Sep 2015 - 19:53

merci seb pour ces infos...
j'ajouterais que heureusement les gros studios n'utilisent pas les moteurs de bases et niveler par le bas le niveau des jeux. c'est justement le problème des moteur clé en main : la plupart des jeux qui les utilisent se ressemblent tous ( je ne parle pas dans le scenario voire le gameplay, mais la physique, le rendu, etc.. )

par babsimov Mer 9 Sep 2015 - 19:55

rocky007 a écrit:
babsimov a écrit:J'avoue que je suis pas assez calé pour te répondre. Pour une musique, que veux tu dire ? si deux jouent la même musique en même temps ? Je pense que ça fera un écho, la même musique joué en même temps ? Ou alors, tout simplement, le lecteur de la musique lancé en second se verra refusé l'accès à Paula, tant que la premier lecteur n'est pas fermé. Honnétement j'en sais rien du tout, je me souviens pas d'avoir eu un cas comme ça sur Amiga.

ok merci du renseignement... je ne me souviens pas non plus, j'étais curieux de voir comment il gérait cela.

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.
par exemple, si un soft ne rendait pas la main sur les ressources, le second programme est tout simplement bloqué en attente de la libération des ressources.
idem, en quittant un programme, c'est à lui à remettre tout en ordre, s'il ne le fait pas proprement, cela reste en l'état, raison des nombreux guru.

Ce fut, comme je te l'ai dit, un problème souvent reproché à Exec, l'absence de ressource tracking. Comme je te l'ai expliqué dans le petit résumé de la création de l'Amiga (et donc d'AmigaOS).
Dans ce qui devait être le Commodore Amiga OS (CAOS) prévu au départ pour l'Amiga par Jay Miner et son équipe système d'exploitation, le ressource tracking était présent.
C'est l'adaptation "au pied levé" de TRIPOS sur ce qui existait d'AmigaOS (Exec) qui a obligé à retirer le ressource tracking. Pourquoi cela, je n'en ais pas la moindre idée. Mais, les ingénieurs Amiga regrettaient suffisamment celà que si cette fonction a été retiré c'est qu'ils n'avaient certainement pas d'autre choix.
Comme je l'ai dit, c'était donc un défaut connu de l'AmigaOS qui faisait partie des choses à régler (avec la protection mémoire) pour le passage à une autre architecture processeur (PA-RISC). Mais, la faillite a fait qu'on a pas vu ce que ça pouvait donner. A l'époque, dans mon usage ce problème je ne l'ai pas vraiment ressentit. J'ai commencé à entendre parler de ce problème de ressource tracking à partir du 3.x quand il a été question de faire évoluer l'Amiga vers un autre processeur. Mais, ceux qui en parlaient disaient que c'était un problème connu des dévellopeurs depuis le début.

L'AmigaOS 4.1 dispose, si j'ai bien compris, d'un ressource tracking et d'une protection mémoire limitée. Ces options (en tout cas pour la protection mémoire) sont réservés aux nouveaux logiciels écrit pour l'AmigaOS 4.1. Le problème de l'AmigaOS 4.1 c'est qu'ils n'ont pas de moyens et font comme il peuvent pour le faire évoluer en reprenant en grande partie les sources de 3.x quand ils existent. Et ils sont quasi obligés de faire comme ça, parce qu'il n'y a plus de marché pour l'AmigaOS 4.1 sur un hardware PPC extrêmement cher et déjà en retard de plusieurs années (même pour le haut de gamme). Il se murmure qu'il y aurait, 2000 AmigaNG ou un peu plus qui ont trouvé preneur dans le monde entier... donc c'est un marché de passionnés, mais rien de vraiment commercial. En fait personne ne connait le chiffre exact, mais cette approximation serait assez proche de la réalité. Ces 2000 utilisateurs seraient pour AmigaOS 4.1. Il y aurait en plus ceux de MorphOS (un nombre similaire) et ceux d'AROS et là comme c'est open source difficile d'avoir un chiffre. Récemment, A-Eon (qui vend les machines NG pour AmigaOS 4.1) a déclaré que le fait que WinUAE ait maintenant l'émulation PPC a grandement aidé les ventes de la version d'AmigaOS 4.1 FE PPC (30 euros). Ils ont probablement raison, puisque je l'ai enfin acheté pour tester. Je voulais bien tester mais mettre au minimum 1500 à 2000 euros voir plus, juste pour voir comment à évolué mon OS préféré, j'étais pas pret à faire ça. D'autant plus que je savais pertinemment qu'en dehors de faire tourner l'OS, niveau application, grosso modo, c'était celles qu'on avait à l'époque sans presque aucune amélioration et que la navigation internet ce serait pas trop ça non plus. Donc, pour ce prix, ce n'était pas possible (ou alors en renonçant à plein de chose) de l'utiliser comme machine principale, comme je le faisait autrefois avec mon Amiga (et pourtant ça me plairait qu'on puisse faire ça de nos jours, mais ce n'est pas le cas objectivement).

EDIT : J'ai oublié de préciser qu'il y a deux branches dans l'AmigaOS4.1 celle pour les NG (des cartes mère sans aucun chipset Amiga et totalement PPC) et l'AmigaOS 4.1 Classic (pour les Amiga OCS/ECS/AGA équipés de cartes powerPC 603/604 de l'époque). Le chiffre des utilisateurs d'AmigaOS 4.1 que je citais concernait celle des NG. Il a été souvent répété que l'AmigaOS 4.0 Classic c'est mieux vendu que les NG et c'est pour ça que la version 4.1 a été continué sur Classic. L'émulation du carte PPC sur WinUAE ayant conduit à une augmentation des vente de l'AmigaOS 4.1 FE Classic, il est possible que la future version 4.2 voit le jour sur Amiga PPC classic. Mais, rien n'est moins sur, car cette fameuse version 4.2 est censé apporter le multicoeur à l'Amiga, justement pour tirer partit des nouvelles carte mère NG qui doivent sortir cette année avec des multicoeurs. Mais, j'ai lu récemment que la fonction multicoeur du 4.2 serait pour l'instant mise en attente, car il y aurait d'autre chose à faire pour l'évolution de l'AmigaOS 4.x.

Pour le test de l'AmigaOS 4.1 FE, certains ont réussi à le faire tourner sur WinUAE, personnellement, toujours pas. Pourtant j'ai suivis un tutorial très bien fait sur un site Amiga français, j'ai même demandé de l'aide au créateur du tutorial... mais il n'a pas trouvé d'ou venait le problème puisque j'avais suivi ce qu'il fallait faire. Il suppose que, comme cette émulation PPC est encore un prototype, je devrais réessayer dans une future version de WinUAE. Pour l'instant, je met donc ce test de coté. Si un jour j'arrive à le faire tourner, si cela intéresse, je donnerais ici mon impression. Attention, ce ne sera qu'un test succint, un ressentit et aucunement un test pointus (je n'ai pas les compétences pour ça). Ceux qui veulent lire un test de l'AmigaOS 4.1, voici un test ici :
http://obligement.free.fr/articles/amigaos41.php

Il s'agit de la première édition. L'AmigaOS 4.1 FE (Final Edition) regroupe tous les précédents patch au fil des années et des nouveaux patch.
En lisant ce test je n'avais pas conscience, mais l'Amiga OS 4.1 c'est 2008 on dirait, et l'édition "complète" c'est 2015... c'est dire comme ils n'ont pas de moyens pour le faire évoluer... on a l'impression que l'équipe fait ça sur son temps libre (attention, ce n'est pas une critique, c'est déjà bien de continuer à faire vivre l'AmigaOS de manière commerciale, et j'ai la plus grande admiration pour eux (comme pour les équipes AROS et MorphOS). C'est juste pour mettre en avant que ça n'a plus rien à voir avec l'époque Commodore.

par rocky007 Mer 9 Sep 2015 - 20:07

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.

par babsimov Mer 9 Sep 2015 - 20:10

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

par rocky007 Mer 9 Sep 2015 - 20:13

babsimov a écrit:

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

par babsimov Mer 9 Sep 2015 - 20:24

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

par babsimov Mer 9 Sep 2015 - 20:25

rocky007 a écrit:
babsimov a écrit:

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

par Seb Mer 9 Sep 2015 - 20:29

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 Very Happy

par babsimov Mer 9 Sep 2015 - 20:39

Seb a écrit: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 ?

par ryosaeba Mer 9 Sep 2015 - 21:06

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

par babsimov Mer 9 Sep 2015 - 22:43

rocky007 a écrit:

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.

par babsimov Mer 9 Sep 2015 - 23:28

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

par rocky007 Jeu 10 Sep 2015 - 10:55

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 Wink

par stapha92 Jeu 10 Sep 2015 - 17:56

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 :

GUERRE ST-AMIGA, FIGHT !!! - Page 3 Mc680011

GUERRE ST-AMIGA, FIGHT !!! - Page 3 Mc680011

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

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.

par stapha92 Jeu 10 Sep 2015 - 18:06

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

par babsimov Jeu 10 Sep 2015 - 20:32

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

GUERRE ST-AMIGA, FIGHT !!! - Page 3 Gamopa10

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

GUERRE ST-AMIGA, FIGHT !!! - Page 3 Gamopa10

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

par **Urbinou** Jeu 10 Sep 2015 - 20:59

Stapha, tu écris que tu vas être barbant, mais que du contraire, c'est un régal de te lire thumleft

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 !

par babsimov Jeu 10 Sep 2015 - 21:14

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

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

par babsimov Jeu 10 Sep 2015 - 21:26

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

Qui a gagné la grande guerre ST-AMIGA ?