Re: GUERRE ST-AMIGA, FIGHT !!!

[babsimov]

babsimov, 

Tu me posais des questions sur l'absence de protection mémoire et de ressource tracking. 

La protection mémoire : 

Il faut savoir que, pour l'implémenter, il est impératif que le processeur dispose d'une MMU. Donc un 68020 + MMU (le 68030 est sorti en 1987). ça coutait une fortune. Donc pas possible. En plus, ça ralenti le fonctionnement de l'OS (a chaque basculement de tache l'OS doit la "reprogrammer" pour lui indiquer quelles sont les zones mémoires autorisées) et ça consomme de la RAM : il faut stocker les zones mémoires utilisées par chaque tache, et ceci bloc par bloc (on parle de "page" pour une MMU). 

Ne pas se laisser tromper par la MMU du ST : ce n'est qu'un controleur mémoire (j'ai déjà vu la confusion ici de la part d'un Stiste...). 

En plus, pour que ce soit efficace, il aurait fallu en avoir une dans le blitter et le copper. Ben oui, c'est pas tout de s'assurer que le processeur n'empietera pas sur une zone mémoire : s'il peut lancer une tache du blitter qui abouti au même effet, ça ne sert pas à grand chose... 
J'ai déjà expliqué l'utilité d'une MMU (c'était il n'y a pas longtemps : donc quelques dzaines de pages... LOL !!) et j'ai démontré qu'un accès mémoire illicite est tout aussi possible dans un os monotache. 
Je disais aussi qu'une MMU n'empeche pas un programme de planter, il n'y a pas de magie ! Pire : un accès illicite qui n'aurait eu aucune conséquence sans protection mémoire entrainerait l'arret du programme avec cette protection/ 
Même avec le dernier Windows : le moindre accès mémoire illicite entraine une erreur "acces violation". C'est ça la protection mémoire. 
Tu en vois souvent avec des logiciels pro toi ? Non ? Donc on peut s'en passer. 

Par contre, une MMU est hyper utile pour débugger un logiciel. En effet elle permet de detecter tous les accès mémoire non prévus (et donc buggés) et qui pourraient ne pas poser de problème pendant le débug et en poser quand ils tourneront réellement. Et c'est vrai que l'on soit en multitache ou non. 
Donc l'écriture un programme pro peut gagner énormément en fiabilité si le codeur dispose d'une MMU et d'un debugger sachant la gérer. Aucun problème pour le mig : facile d'avoir une MMU grace aux cartes accélératrices. Et pour le ST, on fait comment ? 

Le ressource tracking sert à une chose : éviter de rebooter quand un programme est en erreur. Windows en est pourvu : tu n'as jamais été obligé de rebooter ? C'est normal, ça ne marche pas toujours. je préfère un boot rapide à un ressource tracking. 

Je parle à l'époque du mig. Aujourd'hui, avec le cout de la mémoire (le ressource tracking en consomme aussi) et la vitesse des processeurs, il vaut mieux les avoirs (et garder le boot rapide...)

Je n'avais pas vu ta réponse pour le ressource tracking et la protection mémoire avant d'envoyer ma réponse précédente.
Pour ces deux points, tes explications confirment mon ressentit d'utilisateur à l'époque, ça ne m'a pas manqué plus que ça.
L'impact sur la vitesse de l'Amiga d'une MMU était cité dans une interview dont j'avais du mettre un lien ici, il y a un moment. Un des ingénieurs originaux chez Amiga (HI-TORO) expliquait qu'ils avaient développé une MMU spécifique pour l'Amiga, mais que son utilisation ralentissait trop les accès au chipset et qu'il fut décidé que ce ne serait pas implémenté. 
La protection mémoire était belle et bien prévue au départ dans CAOS, mais fut abandonnée quand TRIPOS est venu remplacer CAOS. On ne saura donc pas ce qu'aurait donné le ressource tracking sur Amiga (vitesse et consommation mémoire), mais quand on voit comment Carl Sassenrath a su optimiser Exec, je suis confiant qu'il aurait su faire quelques chose de bien.

Sur le principe, Rocky a raison : dans un OS monotache, le risque de bug est plus risqué qu'en multitache. Et le pire de tout est le multitache coopératif : avec ce système, c'est à chaque tache de rendre la main. Donc quand l'une d'elle plante, elle bloque tout le système, contrairement au préemptif. Et les fameux accessoires, cités régulièrement comme la panacée par les adorateurs du TOS, tournent avec ce système...

Je suis pas sur d'avoir compris, je pense que tu voulais écrire "le risque de BUG est moins risqué (en monotache) qu'en multitâche. Sinon tu ne dirais pas que Rocky007 a raison, puisque c'est ce qu'il ne cesse de dire, qu'un OS monotache est plus stable ? En tout cas, le multitâche coopératif, ça j'ai bien vu que c'était pas terrible (windows, macOS).

Mais le risque de bug ne dépend pas que de cela : il faut aussi considérer la facilité de développement, les outils disponible pour debugger, la robustesse du code, etc... 
Dans ces domaine le mig est beaucoup mieux pourvu que le ST.

Venant d'un programmeur expérimenté comme toi, ça fait plaisir de lire ça. Car l'argument programmation sur ST (et aussi quantité de langage de programmation) revient régulièrement.

Même son Guru meditation : il donnait beaucoup plus d'information sur l'origine du plantage que les bombes du ST. Il indiquait également à quel endroit ça avait eu lieu (trrrrrrrrès important pour la correction d'un bug). Et ce n'est pas tout : sais-tu qu'en branchant un ordinateur sur le port série du mig, on peut accéder à un debugger quand il y a un guru ? 
Il suffit de cliquer sur le bouton droit de la souris... 
Rien que ça, ça donne un gros avantage sur le ST pour la correction de bugs...

Oui, ça je le savais pour le port série (merci AmigaNews qui avait parlé de ça dans un article). Pour un programmeur, je veux bien croire que c'était très utile. Pour moi utilisateur, je trouvais ça bien pensé, mais je n'étais, bien évidemment, pas capable d'aller déboguer un guru. 
De toute façon, comme tu as du le comprendre, il y a pas grand chose sur Amiga que je ne trouvais pas bien pensé, c'est aussi pour ça que j'admirais cette machine (un quasi sans faute à tous les niveaux).

Tiens, pour illustrer tout ça, parlons de 2 applications phares du ST : Cubase et Le Redacteur. 

Pour le premier, Steinberg trouvait que le TOS était tellement pourri qu'il a fallu qu'ils écrivent leur propre OS (appelé MROS) pour faire tourner Cubase dessus ! 
Eh oui : LA killer app du ST ne tourne pas sur l'OS du ST ! Trop drole !

En voilà de l'info intéressante. J'ai trouvé un petit lien qui évoque MROS (très brièvement).
http://www.musicradar.com/tuition/tech/a-brief-history-of-steinberg-cubase-406132

Et qu'est ce qu'on lit, que malgré le succès de PRO24 sur ST, Cubase est d'abord sortit en 90 sur MAC... 

Et le rédacteur ? Voici le début du test de ST-Magazine (N° 49 de mars 91) : 

C'est à l'occasion de la sortie de la version 3.1. C'est pas une version Beta ! Donc c'est tellement stable que les auteurs ont mis un système qui sauvegarde automatiquement ! Apparemment ils ne sont pas parvenus à éviter les plantages !

Et on nous répète sans arret que sur le ST les applis étaient hyper stables... Encore plus drole ! 
Et on ne parle pas d'un petit programme du DP mais bien d'une application régulièrement citée par les STistes...

Ca aussi c'est une lecture instructive, on est étonné que les STistes n'ais pas ébruité ça :)

On n'a pas parlé que de stabilité : on nous a expliqué que le TOS était plus réactif que l'AmigaOS. C'est faux : il suffit d'essayer les 2. 
Mais ça ne s'arrete pas là : la date de création d'un fichier a une précision d'une minute sur le TOS (relis un de mes post ou je parle du correctif sur la résolution) et de moins d'une seconde sur un A500. Une Minute ? C'est quoi cette horreur ! 
D'ailleurs, l'AmigaOS a été choisi par pleins de sociétés pour ses capacités à faire du temps réel (par la Nasa par exemple).

Personnellement, je ne trouvais pas l'AmigaOS instable (peut être un plus le 1.2/1.3 qu'à partir du 2.x, pour ne pas être taxé d'idéalisation). Et je n'est cessé de parler de la très bonne réactivité de l'AmigaOS. 
Je suis bien content que tu abordes ce sujet et aille dans mon sens, car, je pense qu'on peut dire qu'il est incontestable que tu saches de quoi tu parles, tant au niveau du ST que de l'Amiga.
Le temps réel de l'Amiga je l'avais aussi souligné, notamment en donnant le lien vers l'article de l'Amiga à la Nasa. J'ai souvenir qu'on en avait minimisé l'importance ici. 

Mais, maintenant, je vais essayer de prendre du recul avec ces critiques de l'Amiga que je lis ici régulièrement.

Je relirais tes réponses sur le 800 XL, le multitache, la protection mémoire et ressource tracking pour ne pas passer à côté de quelques chose qui m'aurait échappé à la première lecture.

A nouveau, mes remerciement pour avoir pris le temps de rédiger tout ça, et de façon à ce qu'un néophyte puisse comprendre facilement. Bravo.

PS : Quand tu auras du temps, pourras tu regarder dans tes mails privés, une petite question, hors sujet ici, t'y attend. Je sais, je pose beaucoup de questions, mais c'est parce que tu y réponds si bien :)

[drfloyd]

Il y en a peut-être d'autres, mais force est de constater que oui, le GFA Basic a brutalement disparu. 

Et c'est bien le cas. Tu admettras que c'est quand même bizarre que cet outil très utilisé pendant un certain nombre d'années ait disparu comme ça. 

Il y a forcément des raisons :)

Ca s'appelle l'évolution. Il parait que ca va très vite en informatique. Le GFA a disparu avec le ST pour lequel il a été écrit en premier, rien d'anormal à ca.

disparu, c'est vite dit :

http://gfabasic32.blogspot.fr/p/download.html

[babsimov]

Il y en a peut-être d'autres, mais force est de constater que oui, le GFA Basic a brutalement disparu. 

Et c'est bien le cas. Tu admettras que c'est quand même bizarre que cet outil très utilisé pendant un certain nombre d'années ait disparu comme ça. 

Il y a forcément des raisons :)

Ca s'appelle l'évolution. Il parait que ca va très vite en informatique. Le GFA a disparu avec le ST pour lequel il a été écrit en premier, rien d'anormal à ca.

disparu, c'est vite dit :

http://gfabasic32.blogspot.fr/p/download.html

J'aurais pas cru que ça existait encore de nos jours.

Je n'ai pas pratiqué le GFA, mais quelqu'un qui l'a pratiqué sait il ce que ça vaut de nos jours par rapport, par exemple, au visual basic de Microsoft ?

Car, si j'ai bien compris le visual basic est une évolution du basic microsoft de l'époque et le GFA à l'époque avait la réputation d'être meilleur que le basic Microsoft.

[drfloyd]

Ca depend ce que tu veux faire....

ce GFA32 je ne suis pas trop certain de sa fiabilité, ni de sa documentation... j'ai l'impression que le support est abandonné.

En "pur" basic aujourd'hui le basic BLITZMAX est quand meme bien plus convivial par exemple

[dlfrsilver]

Ca s'appelle l'évolution. Il parait que ca va très vite en informatique. Le GFA a disparu avec le ST pour lequel il a été écrit en premier, rien d'anormal à ca.

Ah bon et la version Amiga, elle compte pour du beurre alors ? Toujours à tout voir au travers du prisme du ST, alors qu'en fait il a simplement disparu parce que des logiciels bien mieux foutus et mieux élaborés sont apparus. Mais pas sur ST, c'est vrai.

Il a cependant eu un gros succès, que tu l'aimes ou non et que ca te plaise ou non, le nombre de gens en ayant fait ou l'ayant acheté sur ST est assez impressionnant pour un langage de programmation.

ah mais j'ai jamais dit le contraire, il a aussi eu beaucoup de succès sur l'Amiga.

Il a aussi initié plein de gens à la programmation à une époque ou c'était quelque chose de très obscure pour 99.999% des gens, y compris les joueurs.

Je suis d'accord :)

Mais une fois de plus ton étroitesse d'esprit et ton besoin de vomir sur tout ce qui touche au ST t'empêche de voir plus loin que le bout de ton nez et d'être objectif.

Tu crois que ton esprit partialiste est mieux que ce que tu appelles mon étroitesse d'esprit ? A toujours tout voir via le prisme du ST, sans regarder plus au large ?

Je ne vomis pas TOUT ce qui touche au ST. Sinon j'aurais revendu mes machines depuis un bail. La différence c'est que je ne suis pas un fanboi du ST, contrairement à toi ou d'autres. J'ai un jugement froid sur les machines.
Je m'emballe pas en racontant des conneries du genre :

- "vroom sur ST est plus rapide"
- "ma grand-mère utilisait un ST, elle disait que pour faire du tricot en 2 couleurs y avait pas d'équivalent, et comme c'est une femme d'expérience, je sais que je peux l'écouter"
- "avec le ST j'ai appris à pisser droit et pas sur la cuvette"
- "Le ST est plus rapide qu'un escargot équipé de patins à roulettes"
- "Le ST aidait les ados dans leur vie sexuelle, on a jamais vu de claviers aussi blancs"
- "Le GEM du ST était un chef d'oeuvre de programmation pour les autistes"
- "L'amiga est doté d'outils graphiques extrêmement bien conçus, le choix de l'industrie en terme de format d'image, mais les outils du ST en 16 couleurs étaient bien au dessus, y a rien à redire"
- "Le ST a un processeur plus rapide que celui de l'amiga ; Ben oui, c'est normal, les ingés de chez Atari voulait pas qu'il soit en concurrence avec les machines 8 bits comme le CPC"

etc etc etc :)

Tu vois, le souci c'est que vous êtes coincés dans votre mode de pensée. Le ST fallait pas le regarder, en fait. Il faut juste se baser sur les jeux qu'il offre, et s'arrêter, car sur le plan hardware, il est au même niveau que le C64.
La même merde pondue par les même ingénieurs. Je me suis demandé à un moment sachant que je possède un C64, s'il y avait pas des points commun entre les 2 machines. Hardware malpropre, révisions multiples de carte mère à cause des bugs hardwares, alim foireuse, fragilité, etc.

Et puis j'ai découvert que les ingés qui ont bossé sur le ST étaient les mêmes que ceux ayant oeuvrés sur le C64.

Ceci expliquant tout celà.

Donc pour répondre à ton histoire de vomi, quand je joue à navy moves sur ST, j'apprécie le jeu pour ce qu'il est, sans regarder ce qui anime l'ensemble. Pareil pour Twinworld ou Rick Dangerous. Idem pour wings of death, j'apprécie le jeu pour ce qu'il est, sans regarder le support physique qui le fait tourner.

Maintenant, c'est comme pour tout, quand quelque chose ne me plait pas ou que je trouve un truc nul ou naze, je le dis, peu importe ce que c'est. Et sur le ST ou le STE y a matière à dire (ce qui ne veut pas dire qu'il n'y ait rien à dire sur amiga, et que la machine soit dépourvue de défaut).

[drfloyd]

tiens, alors meme le C64 en prend pour son grade, la rolls des micro 8bit etait une merde aussi....

[Seb]

Tu crois que ton esprit partialiste est mieux que ce que tu appelles mon étroitesse d'esprit ? A toujours tout voir via le prisme du ST, sans regarder plus au large ?

Je te rappelle que j'ai eu les 2 machines et que j'adore les 2. Mes posts précédents expliquaient même pourquoi l'Amiga était une machine globalement plus puissante que le ST. Je ne suis pas "partialiste" et je n'ai pas de prisme ST.

Je ne me souviens pas avoir écrit une seule des choses que tu as mises entre guillements au passage, sur Vroom ou autre chose, tu te trompes de personne.

Mais une fois de plus, tu ne vois que ce que tu veux voir.

[dlfrsilver]

tiens, alors meme le C64 en prend pour son grade, la rolls des micro 8bit etait une merde aussi....

Alors ton argument de rolls des micros 8 bits, désolé, mais personne ne peut l'acheter. Le seul truc qui sauve cette machine, c'est le SID. La palette de couleurs est juste immonde, le processeur ridicule.

L'amstrad CPC était clairement la Rolls des 8 bits : qualité de conception, de fabrication, un plastique de bonne qualité, qui ne s'éffrite pas (pas comme celui du c64 et du ST par exemple), performances globalement équilibrées, une belle palette de couleurs, et une puce dédiée à la vidéo, et aucun problème d'alimentation, avec une carte mère n'ayant que très peu de condensateurs.

Le c64 n'est pas une machine équilibrée. Tout à été misé sur le SID, et sur les sprites hardware, et les extensions qui coutaient bien trop cher pour ce qu'elles offraient.

Le C64 est d'un point matériel une machine très fragile oui, tu te souviens pas qu'au moment de sa sortie, il avait une garantie de 90 jours seulement justement à cause de ça ?

La machine pouvait te claquer dans les doigts sans mot dire. J'ai découvert cette information en lisant un journal de l'époque sur Abandonware Magazine.

J'avais trouvé ça très "tramielesque". Ou comment je me blinde les fouilles de pognon en refilant aux client du matos merdique.

Bien sur, si on s'en tient au son, le SID a un bon rendu, c'est un indéniable. Mais voilà, pour un ordinateur qui coutait une blinde, ça la foutait mal :)

Comme pour l'Amiga 1000, le c64 avait un prix inapproprié. Par rapport à sa qualité de finition et aux pièces qui le composait s'entend, car l'amiga avait lui un hardware de qualité supérieure et une bien meilleure finition.

[dlfrsilver]

Tu crois que ton esprit partialiste est mieux que ce que tu appelles mon étroitesse d'esprit ? A toujours tout voir via le prisme du ST, sans regarder plus au large ?

Je te rappelle que j'ai eu les 2 machines et que j'adore les 2. Mes posts précédents expliquaient même pourquoi l'Amiga était une machine globalement plus puissante que le ST. Je ne suis pas "partialiste" et je n'ai pas de prisme ST.

Je ne me souviens pas avoir écrit une seule des choses que tu as mises entre guillements au passage, sur Vroom ou autre chose, tu te trompes de personne.

Mais une fois de plus, tu ne vois que ce que tu veux voir.

Dans ce cas pourquoi tu as ramené la chose au ST, alors que je parlais du GFA basic, sorti sur les 2 machines ?

La version Amiga est pareille à la version ST et propose presque les même choses.

[Seb]

tiens, alors meme le C64 en prend pour son grade, la rolls des micro 8bit etait une merde aussi....

A un moment je pense que ca ne sert à rien de continuer à perdre son temps avec un troll.

Discuter avec dlfrsilver c'est un peu comme discuter avec les creationistes. Je vais arrêter de perdre mon temps en laissant cette image qui représente bien les discussions avec dlfrsilver ici et sur d'autres sites (heureusement que Stapha92 compense le niveau)

Dans ce cas pourquoi tu as ramené la chose au ST, alors que je parlais du GFA basic, sorti sur les 2 machines ? 

La version Amiga est pareille à la version ST et propose presque les même choses.

Parce que comme je le disais dans mon post le GFA basic a été développé sur ST puis porté ailleurs plus tard, donc c'était un bon exemple d'exclu ST en 1986 mais je m'arrête là c'est sans intéret cette discussion.

[babsimov]

Ca depend ce que tu veux faire....

ce GFA32 je ne suis pas trop certain de sa fiabilité, ni de sa documentation... j'ai l'impression que le support est abandonné.

En "pur" basic aujourd'hui le basic BLITZMAX est quand meme bien plus convivial par exemple

Je posais la question par curiosité, la programmation ça remonte bien trop loin pour moi.

[ryosaeba]

c'est en effet ce qui rend ce débat difficile, car l'avantage du ST se modifie en fonction du temps :

de 85 à 87 : c'est clairement le ST qui a le dessus : machine 2x moins cher, jeux presque identiques sur Amiga, plus pratique et fiable à utiliser au quotidien que WB 1.0

ensuite l'Amiga est devenu abordable et +- abouti dans sa version A500.  Atari a senti le vent tourner et a essayé de rattraper le coup avec le malheureux STe... et là, de 88 à 92, Atari n'a fait que perdre de la vitesse et n'a rien sorti de bon jusqu'au Falcon.

Donc je résumerais par :
 
85-88  : ATARI WINNER
89-92  : AMIGA WINNER

On peut dire ça, j'ajouterai une nuance :

85-88 : ATARI WINNER FINGER IN THE NOZE
89-92 : ATARI WINNER POUR LA BUREAUTIQUE/PRO/PROG/ULILITAIRES et AMIGA WINNER POUR LE JEU

Et comme pour moi la grande epoque 16/32bit c'etait 86-89... tous les titres revolutionnaires sont sortis sur cette période, et franchement y a eu essoufflement des 1990 dans la qualité des programmes... ATARI l'emporte donc HAUT LA MAIN dans cette guerre.

Je sais, je devais faire une pause, mais lire des truc comme ça, c'est du n'importe quoi !

Je l'ai déjà dit, le ex-ingénieurs Atari l'emportent haut là main (hardware et OS) !

Parce que les ingénieurs de l'Atari de l'époque ST n'avaient clairement RIEN à voir avec eux au niveau technique si j'en juge mes lectures sur ce forum.

Quant au jeux 16/32 bits qui s’essoufflent à partir de 1990... c'est sur qu'à partir de cette époque, le ST, il suit plus...

Et rappelons nous de ce qui sort à partir de 1990 comme jeux soit disant "essouflés" :

- Wing Commander (PC/Amiga), c'est LE JEU qui a fait basculer le marché du jeu sur PC. Même moi, à l'époque, j'ai faillit passer sur PC à cause de CE jeu.

- Dune (PC/Amiga). La version PC étant clairement une réussite à tous les niveaux.

- Dune II (PC/Amiga). Celui là c'est la base des jeux de stratégies temps réel qui sont de nos jours encore d'actualité.

- Wolfenstein3D (PC), là aussi la base des FPS... 
Sur ST vous en avez eu des FPS à l'époque ? Sur Amiga il y en a eut alors que c'était réputé impossible (c'est l'auteur de Wolfenstein 3D qui prétendait ça, encore un programmeur PC qui faisait tout au processeur... donc forcément l'Amiga il pouvait pas appréhender).

- The Settlers (PC/AMIGA)

- Civilization (PC/AMIGA/ST)... tiens je me demandais pourquoi l'affichage était si lent sur Amiga par rapport à la version PC... j'avais toujours pensé que c'était à cause de la version MAC... et non, ça devait encore être à cause d'un mauvais portage ST vers Amiga.

Et, il y en a surement d'autres dont je ne me souviens pas.

Quant au domaine des logiciels pro, en dehors de la bureautique (ou le ST avait la quantité et plus de chose en français), l'Amiga avait largement de quoi faire. Pour la programmation, tous les langages soit disant exclusif du ST ont été adapté sur Amiga (GFA et STos...). Ah et parlons de ce dernier... La version de STos sur Amiga s'appelait AMOS, qui, bien entendu, était meilleur que le STos... et que dit son auteur :

http://obligement.free.fr/articles/itwlionet.php

"Première question piège, quelle machine as-tu préféré, Atari ou Amiga ? Et bien entendu, pourquoi ?

L'Amiga bien entendu. Les modes graphiques de l'Atari en 640x480 maximum étaient vraiment trop limités, et je n'aimais pas le GEM."

Tiens un STiste qui n'aimait pas le GEM... et qui en plus préfère l'Amiga en ayant eut les deux... 

Et il persiste et signe pour le GEM :

"Au départ, le STOS était destiné à offrir un nouveau système pour remplacer le GEM sur Atari."

Tiens, ça me fait penser que ça fait au moins deux programmeurs chevronnés qui préfèrent l'Amiga (celui d'AMOS, et celui de DirectX)...

Et puisqu'on parle d'utilitaires, vous connaissez Aminet, la plus grosse bibliothèque d'utilitaires domaines publiques en tous genres et toute plateforme confondues de l'époque... Un des nombreux avantage de l'Amiga. Et cette bibliothèque n'a pas attendue internet pour être connue, il y avait les célèbres CD aminet, et avant les collections de disquettes DP.

Bref, ce que je constate sur ce forum, c'est que lorsque les Amigaistes font une pause, les PRO Atari ici se livrent au révisionnisme et distillent LEURS vérités en prétendant que c'était la réalité de l'époque. 

Pourtant, sans la petite nuance, j'aurais été prêt à accepter le résumé de Rocky007. 

Même si je n'adhère pas au +-abouti pour le 500 (face au ST non évolutif), ainsi qu'à la référence au WB 1.0 alors qu'on a vu que le TOS aussi il faudra attendre, je cite, "à partir du 1.04 ça commence enfin à devenir un plaisir d'utiliser un ST". Hors le 1.04 c'est 87. Donc égalité, puisque 87 c'est le 1.2 et on peut dire la même chose pour l'Amiga. 
Voici la source, c'est ST Magazine de l'époque, j'espère qu'on va pas me dire que c'était un magazine anti-ST :)




J'avais espéré que ma pause serait quand même plus longue. Je pensais pouvoir lire le sujet de manière détachée. Je vais essayer de le faire, à l'avenir, car, parfois on y apprend des choses intéressantes sur les deux machines.

Cela provient de quel numéro de st mag ?

[stapha92]

Babsimov,

Tu avais raison : je voulais dire qu'un OS monotache est "moins" risqué. J'ai édité mon post.

Pour ta question sur la difficulté à tirer parti du mig : non, ce n'est pas du tout aussi difficile que le XL. C'est même assez facile en fait.

Tu me posais des questions sur mon ressenti sur les 2 machines. 

J'ai eu un ST puis un mig. Et j'ai REELLEMENT utilisé les 2. Connais-tu quelqu'un qui l'ai fait et qui ait préféré le ST ? Je veux dire, en dehors de ce forum ? Personne ? C'est bien ce que je pensais... 

Et quand tu as codé en tatant du TOS et de l'AmigaOS, tu ne regrettais pas le premier. Vraiment pas. Car c'est le jour et la nuit. 
Je parle de coder : 
        - Sérieusement. Pas de jouer avec le GFA. Non pas que ce soit criticable, mais ce dernier cache au codeurs les appels aux fonctions du TOS. Tout juste peut-il se rendre compte que le GFA sur mig était plus rapide... 
        - Des applis pour l'OS. Un codeur de démo ou de jeux en n'avait rien à faire que le TOS soit si mal foutu : il ne l'utilisait (presque) pas. 
        
Je te le dis : ceux qui expliquent le contraire mentent. 

Donc j'ai eu les 2. Et tu sais quoi ? J'ai eu plus de bombes que de Guru meditation. Largement plus... Cela veut-il dire que le TOS/GEM est moins fiable ? Pas forcément : j'ai beau être un fan-boy Amiga, je n'oublie pas que j'ai eu le ST AVANT le mig. Donc j'ai bénéficié d'un AmigaOS plus ancien que le TOS. 

Parlons du livre cité par Rocky, l'auteur parle de bugs et donne deux exemples : 
        - Une division par 0 
        - Un manque de mémoire. Il s'agissait du Guru le plus courant : un programme demande une zone mémoire. L'OS lui renvoit la valeur NULL car il n'y a plus assez de mémoire dans la machine (donc la demande de mémoire est refusée) et le programme, au lieu de vérifier qu'il n'a pas reçu la valeur NULL va essayer d'exploiter l'adresse reçue. 
Dans les 2 cas, ça n'a rien à voir avec le multitache et ça peut tout aussi bien se produire avec n'importe quel OS... 

L'auteur parle de la programmation événementielle qui était une nouveauté (sur les machine personnels). Je me souviens avoir expliqué avoir découvert ça sur le mig quand je disais que coder dessus était bien plus interessant que coder sur ST. Et ça m'a été utile : aujourd'hui toutes les applis font de l'événementiel... 

Idem quand tu expliques à Rocky que c'était plus ergonomique de ne pas être obligé de saisir sa souris pour cliquer sur OK quand tu insérais la disquette demandée. Il t'a répondu qu'il suffisait de quelques lignes de code en C pour faire pareil. 
Sauf que quand tu appelles la fonction du GEM qui affiche une boite de dialogue pour confirmer ou annuler, ton programme n'a plus la main tant que l'utilisateur n'a pas fait l'un des 2 choix ! Donc ça : 

et comme déjà dit, rien n'empêchant le codeur de faire d'ajouter ses 10 lignes de C dans son logiciel pour faire la detection automatique.  
plein de jeux Atari detectait tout seul le changement de disquettes.

C'est faux. Le seul moyen pour le codeur est de gérer lui même la boite de dialogue entièrement : c'est un plus long que 10 lignes de code en C... 
L'autre solution serait l'ouverture d'une fenêtre modale. C'est à dire une fenêtre autonome qui ne bloque pas l'appelant. Mais ce n'est possible qu'avec du multitache. Donc interdit au ST... 
Et oui, le multitache sert aussi à faire des applis MDI. Ce qui apporte un plus en terme d'ergonomie.

Un jeu par contre, ne passe pas par le GEM pour demander une confirmation à l'utilisateur : c'est pour ça que des jeux pouvait le faire. Mais sortir cet exemple dans une discussion sur les limites du TOS/GEM. Hmmm.... 

Sur l'Autorun dont tu parlais : il n'y a pas que le programme lancé automatiquement. il y a aussi l'icone. Quand tu met un CD dans un micro d'aujourd'hui, c'est un icone peronnalisé qui apparait. Et c'est comme ça depuis 1995 sous windows. Ou 1985 sous AmigaOS...

Revenons sur le débat TOS/AmigaOS :

Il y a de grandes discussion ici sur le TOS et l'AmigaOS. 
Mais elles s'arretent sur l'aspect visible de ces OS. Et comme pour un iceberg, ça ne représente qu'une toute petite portion de l'OS. Et ce n'est pas la plus importante. 
Le plus important, ce sont les API de l'OS. Ce sont elles qui permettent à toutes les applications de tourner dessus.
Les API sont des ensembles de fonction qui permettent d'effectuer un certains nombre d'actions. Elle permettent, entre autres : 
        - D'éviter d'avoir à réinventer la roue à chaque écriture de logiciel. Pour cela elles doivent être le plus complete possible. Et le TOS est loin derrière le mig à ce niveau. 
        - D'utiliser le hardware sans être obligé de le manipuler directement. 
        - D'avoir des applications qui disposent du même look & feel. 

Un logiciel quel qu'il soit (on écarte les démos et les jeux de cette explication) passe une bonne partie de son temps à appeler ces fonctions de l'OS. 

Comment appeler une fonction de l'OS dans le mig ? 

Les fonctions sont regroupées dans des bibliothèques. Avant de pouvoir utiliser une fonction, il faut "ouvrir" la bibliothèques qui la contient. Bien sur, un programme ne le fait qu'une seule fois. Le plus souvent pendant son initialisation. 

Ouvrir une bibliothèque permet, entre autres, de savoir ou elle se trouve. C'est bien sur une obligation pour pouvoir l'utiliser ! 
Comment fait-on ? C'est simple : on utilise la fonction OpenLibrary de la bibliothèque EXEC. Mais comment ouvrir EXEC alors ?!!! 
Pas besoin : EXEC est la seule bibliotheque qui soit toujours ouverte. Et son adresse est fixe. C'est la seule qui soit dans ce cas dans tout l'AmigaOS. Ce qui apporte de la souplesse et permet de conserver une compatibilité totale si des bibliothèque sont modifiée. 

Exemple, on trouve en ROM une bibliothèque A et juste après une bibliotheque B. On améliore l'OS et on ajoute des fonction à la bibliothèque A. Du coup la bibliothèque B ne sera plus au même endroit. Avec le système de l'AmigaOS, ça ne posera pas de problème. Y compris pour EXEC : comme c'est la première des bibliothèques en ROM, elle se trouvera toujours au même endroit. 

Evidemment, rien n'empeche le codeur "maladroit" d'appeler une fonction de l'OS directement sans utiliser le système d'ouverture. Après tout, il sait bien ou se trouvent les fonctions dont il a besoin. Pourquoi s'embeter à respecter les recommandation de Commodore ? 
C'est ce que faisait souvent les jeux du début (Juste par flemme...). Et c'est pourquoi ils rencontreront des problèmes de compatibilité avec les versions ultérieures de l'AmigaOS. 

Alors : comment fonctionne OpenLibrary ? 

On lui donne le nom et la version de la bibliothèque que l'on souhaite utiliser et elle renvoit un pointeur qui contient l'adresse de base de la bibliothèque. Si elle ne la trouve pas dans la ROM, elle recherche dans le répertoire LIBS et si elle la trouve, la charge en mémoire. Elle vérifie que le numéro de version de la bibliothèque trouvée est supérieur ou égal au numéro de version que l'on a envoyé en paramètre. Si elle ne trouve pas la bibliothèque ou si celle qu'elle a trouvé n'a pas le bon numéro de version, elle renvoit null. 
On donne le nom de la bibliothèque en clair. On peut donc avoir un nombre énorme de bibliothèque différente. 
On peut même indiquer un chemin complet pour le nom de la bibliothèque et l'AmigaOS ira directement voir à cet endroit pour la charger (au lieu d'aller dans LIBS). 

Pour le programmeur, ça apporte un certain confort. Il ne se préoccupe pas de savoir si la bibliothèque qu'il utilise est en ROM ou si elle doit être chargée. Il n'a pas à vérifier si la bibliothèque qu'il utilise possède bien les fonctions dont il a besoin puisque la gestion des version le fait pour lui. Il n'a pas à vérifier si la bibliothèque est déjà chargée. S'il ouvre une bibliothèque qui l'est déjà, l'OS lui retournera le pointeur dont il a besoin et cela ne génèrera aucun problème. Ainsi, si une bibliothèque qui se trouve sur disque est déjà chargée en RAM par une autre application, c'est elle qui sera utilisée. L'OS ne la chargera pas deux fois. A l'inverse l'OS ne libérera la bibliothèque que lorsque toutes les applis qui l'utilisent l'auront fermé. 
C'est pour s'assurer qu'il n'y aura pas de problème lors de l'utilisation conjointe d'une bibliotheque par plusieurs application que Commodore imposait que le code d'une bibliothèque soit réentrant. Parce que n'importe quel codeur pouvait coder sa propre bibliothèque. Aminet en est rempli. 

Je ne connais aucun système analogue sur le TOS. Ni même quelque chose d'approchant. 

Ensuite, il faut pouvoir appeler les fonctions de la bibliothèque. On pourrait le faire de plusieurs façon mais les règles de Commodore imposait l'utilisation d'un adressage indirect avec déplacement. Elles imposaient également l'utilisation du registre A6 comme base. 
Concrètement cela signifie que A6 contient l'adresse qui a été retournée par OpenLibrary() et que l'on accède la façon suivante : 

JSR Offset(A6) 

Offset représente la position de la fonction par rapport au début de la bibliotheque. Par exemple, si une fonction se trouve à 1000 octets du début ça donnera : 

JSR 1000(A6) 

Efficace mais pas très parlant. Donc sur le mig, on ne fait pas comme ça : on utilise des constantes fournies par Commodore. Elle associe un nom de fonction à la valeur de l'offset qui lui correspond. Donc en assembleur un appel de fonction prend la forme suivante (exemple avec une fonction qui converti un caractère en majuscule) : 

Move.l #Code,(D0)        ; On met le code du caractère à convertir dans D0 
JSR ToUpper(A6)           ; On appelle la fonction. D0 contient le caractère converti. 

(Le "ToUpper" est la constante dont je parlais) 

Et c'est terminé. Le code ci-dessus prend 12+18 = 30 cycles. 

Le système est simple, efficace, rapide et très lisible. On jetant juste un oeil sur ce code, on sait exactement ce qu'il fait. 


Comment ça se passe dans le ST ? 

Le système est totalement différent. Il s'appuie sur l'instruction TRAP. Cette instruction prend en parametre un numéro de vecteur. Le 68000 utilise ce numéro pour savoir ou aller chercher l'adresse à laquelle il doit se rendre avant de traiter l'exception. 
Pour appeler une fonction, on met les paramètres sur la pile, on met le numéro de la fonction sur la pile, on fait le trap en utilisant un numéro de vecteur qui correspondra à la librairie que l'on souhaite utiliser et on réaligne la pile. Ca donne ceci : 

Move.l  #X,—(sp)         ; On empile un paramètre  
move.w  #3 ,—(sp)      ; On met le numéro de la fonction sur la pile 
TRAP #13                   ; On déclenche l'exception 
Move.l  (sp)+,D0         ; On recupère le retour dans D0 
addq.l  #2,sp              ; On réaligne la pile 

88 cycles. Mais ce n'est pas tout. Ce système oblige le TOS à faire des choses en plus : dépiler le numéro de fonction, utiliser ce numéro pour récupérer l'adresse de la fonction dans une table (après y avoir appliqué un décalage de 2 bits), appeler la fonction et dépiler le paramètre. Et le RTE que le TOS devra faire est plus couteux que le RTS que fera l'AmigaOS. Ouf ! 
On sera aux alentour de 130-140 cycles de plus que l'AmigaOS ! Et j'ai pris pour exemple une fonction avec un seul paramètre : plus ces derniers sont nombreux, plus l'écart est grand ! 

Donc au final : 
        - Le TOS perdra plein de temps à chaque appel de fonction. 
        - Les fonctions du TOS seront plus longues en taille. (Et pourtant le TOS utilise une ROM plus petite que l'AmigaOS) 
        - Les appels du coté de l'application seront plus long également. 
        - Le code sera beaucoup moins lisible. Car je n'ai jamais vu un système de constante analogue à ce qu'il y a avec le mig. Et 5 lignes sont moins lisibles que 2. 
        - le risque d'erreur sera plus grand. Non seulement il y a plus de code, mais il y a obligation de réaligner la pile. Si c'est mal fait, ça peut ne pas planter du tout, planter tout de suite ou planter bien plus tard. Si, dans l'exemple ci-dessus, le codeur choisi de ne plus récupérer la valeur de retour, il devra supprimer la 4eme ligne et surtout ne pas oublier de remplacer le #2 par #6. 

Je m'arrete là mais je pourrai passer des heures à faire des comparaisons qui seraient totalement défavorable au TOS/GEM...

[babsimov]

Dune PC a de très beaux graphismes et une belle bande son. Mais je lui préfère nettement celle de la version amiga, bien plus atmosphérique à mon gout. Celle-ci avait d'ailleurs eu 20/20 dans le magazine joystick.
Et ça se comprend :)

Mon principal reproche à la version Amiga de Dune, c'est qu'il n'y a que 3 musiques en tout et pour tout, là ou le PC en avait 9. 
Pour que tu comprennes mon point de vue à ce sujet, je vais vite fait résumer l'anecdote. La première fois que j'ai découvert Dune c'était sur PC. Un pote de l'époque (PCiste) venait de "l'avoir" et comme il savait que j'avais lu les livres DUNE et vu le film, voulait que je l'aide à un peu avancer. Moi, pas spécialement intéressé par voir un jeu PC, je lui dis ok, mais pas trop longtemps (le début quoi). Il lance le jeu et là, le choc... j'avais lu que les musiques sur PC était les meilleurs sur Adlib que même les ingénieurs d'Adlib ne pensait pas que c'était possible. Et bien, oui, c'était la première fois que j'était étonné des musiques sur PC. Et, il y en avait un paquet, toutes plus belles les unes que les autres. 
Bref, je suis resté et on a quasiment fini le jeu dans l'après midi (en tout cas, bien avancé). Il y avait un mode de lecture des musiques comme un CD. Je lui ais fait enregister les musiques sur cassette. J'ai ensuite lu un article qui expliquait qu'un CD allait sortir avec les musiques du jeu. Je suis passé chaque week end, pendant plusieurs semaine, au Virgin Megastore à Paris pour le trouver... et cerise sur le gateau, le jour ou je l'ai trouvé, l'équipe du jeu était là et j'ai eu la chance de parler avec eux, notamment de la suite du jeu... Et, même si je n'ai pas compris à l'époque, ils m'avaient décrit dans les grandes lignes, Dune II de Westwood. 
Je me souviens plus si la version Amiga était sortit quand j'ai eu le CD ou pas. En tout cas, comme je trouvais les versions PC des musiques déjà très bien, je me disais que sur Amiga ce serait encore meilleur...
Alors certes, les musiques Amiga ont plus de "coffre", mais il n'y en a que 3 et en plus celle que je préférais n'y étais pas (ornithoptère).

Version Adlib :


Version CD :



Je me suis souvent demandé pourquoi la version Amiga de Dune n'avait pas toutes les musiques de la version PC. Et la réponse qui parait le plus plausible, c'est que pour les jeux, l'Amiga était considéré comme une machine sans disque dur en standard. Le 1200 aurait eu un disque dur en standard, peut être aurait on vu toutes les musiques sur Amiga. 

Petit comparatif :

Intro PC :



Amiga :



Dune intro version CD (sign of the worm)



Ecolove Amiga (il ne semble pas y avoir de version d'écolove sur PC)



Ecolove CD



Freemen PC :



Freemen Amiga :



Freemen CD



Quelques comparaison entre la version Adlib et CD, des musiques qui n'existent pas sur Amiga :

Spice Opera PC



Spice Opera CD



Franchement, la version PC est quand même pas mal !

Wake Up PC :



Wake Up CD :



Water PC



Water CD :



Franchement la bande son adlib, pour l'époque, je la trouve bluffante, elle méritait amplement ses éloges et je regrette qu'on ait pas eu toutes les musiques sur Amiga.

La bande son Adlib complète :
https://www.youtube.com/watch?v=usTwtyjepPo&list=PLB324754A61AB3F1B&index=3

La bande son CD complète :
https://www.youtube.com/watch?v=_wMIMMmWS74&list=PL9DB7EF0D0FEBB95A


Là, je vais poser une question au préservateur de jeux qui est en toi dlfrsilver. J'ai vu que tu avais traduit Eyes of The Beholder I et II sur Amiga, ainsi que Ambermoon.

Existe t il une version AGA de Dune (je pense que c'est une version ECS, même sur AGA). Si cela n'existe pas, est il possible de transformer la version ECS en version AGA avec les graphismes issus du PC... et cerise sur le gateau, pour les compositeurs de mod sur Amiga, d'y intégrer des versions Amiga des musiques manquantes par rapport au PC... Une sorte de Dune version Gold sur Amiga ?
Peut être même demander les sources aux auteurs pour faire ça ?

Que dis tu de cette idée... on peut même demander de l'aide au programmeurs Amiga ici (et tiens un portage sur ST...), après tout, je suis sur que ça pourrais être intéressé des programmeurs ST ça ? 

Rocky007 ?
Stapha92 ?
Seb ?

[dlfrsilver]

Il n'existe pas de version A1200 de Dune à ma connaissance :)

Pour faire une version AGA, celà passe par 2 choses :
1) Désosser le programme de la version Amiga, surement codé en C et ASM. Et passer l'affichage de 5 à 8 bitplans (256 couleurs).
(C'est ce qui a été fait pour les 2 EOB).

2) Créer des outils pour ouvrir les fichiers archives qui composent le jeu et remplacer les graphismes.

A partir de la, une version AGA est possible. Mais ça nécessite un programmeur de talent.

CFOU pour EOB I et II a carrément du comprendre le système de compression utilisé pour chaque type de fichier et développer un compresseur supportant chaque format.

A voir si Philippe Ulrich aurait le code source de dune Amiga pour ce faire :)

Quand à porter Dune sur Atari ST, est-ce que le jeu en vaut la chandelle, le jeu est en 32 ou 64 couleurs sur Amiga (me souvient plus).

Dune Amiga ne possède pas toute les musiques c'est vrai, mais il a les principales, impeccablement répliquées via le tracker Starttrecker d'Exolon of Fairlight :).

Je possède également le CD des musiques, que j'ai aussi offert à mon beau-frère qui adore Dune comme moi :)

[Invité]

bon courage pour les musiques de dune.  ya que stephane picq qui peut faire du stephane picq ! (pour les curieux ; rippez les mods de la version amiga et regardez comment les instrus sont balladés d'une piste a l'autre... j'ai jamais rien vu de similaire.. completement dingue la facon dont il a fait ces. mods).

[dlfrsilver]

il a utilisé Startrekker, qui est un excellent tracker.

Par ailleurs, comme l'amiga joue des samples, la ou le ST ne fait que du pilotage midi, j'explique :

. Un ST peut faire jouer un morceau via le midi à un synthétyseur.

L'amiga peut non seulement le faire jouer, mais mieux, il peut enregistrer sur disque dur chaque sample correspondant à chaque touche du clavier et ou synthétyseur. Ce qui veut dire que l'amiga peut répliquer le morceau entier tel qu'on pourrait l'écouter avec le synthé, la ou le ST ne ferait que blip blip bloupe bloupe.

Problème sur l'amiga, la RAM que tout ça prend (sample+partoche en 4 voix). Chaque morceau eniter fait décompressé 190ko.

Dune Amiga était bien sur installable sur Disque dur, donc pas de souci à ce niveau :)

Je connais un mec sur Amiga qui sait très bien convertir les musique midi en format MOD :)

[babsimov]

Babsimov,

Tu avais raison : je voulais dire qu'un OS monotache est "moins" risqué. J'ai édité mon post.

Pour ta question sur la difficulté à tirer parti du mig : non, ce n'est pas du tout aussi difficile que le XL. C'est même assez facile en fait.

Tu me posais des questions sur mon ressenti sur les 2 machines. 

J'ai eu un ST puis un mig. Et j'ai REELLEMENT utilisé les 2. Connais-tu quelqu'un qui l'ai fait et qui ait préféré le ST ? Je veux dire, en dehors de ce forum ? Personne ? C'est bien ce que je pensais... 

Je n'ai pas connu beaucoup de personnes dans ce cas, mais c'est vrai que ceux que j'ai connu qui venaient du ST vers l'Amiga, ne sont pas retournés sur ST. 

Et quand tu as codé en tatant du TOS et de l'AmigaOS, tu ne regrettais pas le premier. Vraiment pas. Car c'est le jour et la nuit. 
Je parle de coder : 
        - Sérieusement. Pas de jouer avec le GFA. Non pas que ce soit criticable, mais ce dernier cache au codeurs les appels aux fonctions du TOS. Tout juste peut-il se rendre compte que le GFA sur mig était plus rapide... 
        - Des applis pour l'OS. Un codeur de démo ou de jeux en n'avait rien à faire que le TOS soit si mal foutu : il ne l'utilisait (presque) pas. 
        
Je te le dis : ceux qui expliquent le contraire mentent. 

Donc j'ai eu les 2. Et tu sais quoi ? J'ai eu plus de bombes que de Guru meditation. Largement plus... Cela veut-il dire que le TOS/GEM est moins fiable ? Pas forcément : j'ai beau être un fan-boy Amiga, je n'oublie pas que j'ai eu le ST AVANT le mig. Donc j'ai bénéficié d'un AmigaOS plus ancien que le TOS.

Tu accrédites donc le fait que les premières version du TOS/GEM étaient tout aussi "peu fiables" que les premières versions de l'AmigaOS ? 
A propos, en quelle année as tu eut ton Amiga et quel modèle ? Je suis aussi curieux de connaitre ta configuration, disque dur ? Ram ? Carte accélératrice ?

Parlons du livre cité par Rocky, l'auteur parle de bugs et donne deux exemples : 
        - Une division par 0 
        - Un manque de mémoire. Il s'agissait du Guru le plus courant : un programme demande une zone mémoire. L'OS lui renvoit la valeur NULL car il n'y a plus assez de mémoire dans la machine (donc la demande de mémoire est refusée) et le programme, au lieu de vérifier qu'il n'a pas reçu la valeur NULL va essayer d'exploiter l'adresse reçue. 
Dans les 2 cas, ça n'a rien à voir avec le multitache et ça peut tout aussi bien se produire avec n'importe quel OS...

Ce qui est bien avec tes réponses, c'est que tu as les arguments techniques qui font souvent défauts au non programmeurs comme moi, quand on en arrive à parler de ce genre de bugs.

L'auteur parle de la programmation événementielle qui était une nouveauté (sur les machine personnels). Je me souviens avoir expliqué avoir découvert ça sur le mig quand je disais que coder dessus était bien plus interessant que coder sur ST. Et ça m'a été utile : aujourd'hui toutes les applis font de l'événementiel...

La programmation événementielle, je ne connais que de nom. J'ai fait une petite recherche :
https://fr.wikipedia.org/wiki/Programmation_%C3%A9v%C3%A9nementielle

Ce que je retiens de ce que tu dis, c'est que, comme je le soutiens depuis le début, l'Amiga a permis à beaucoup "d'entrevoir" ce que serait l'avenir l'informatique.

Ta remarque sur la programmation m'amène à te poser une autre question. Je ne sais pas si tu as suivi le débat sur les propos de l'auteur de DirectX qui disait s'être inspiré de l'Amiga pour concevoir DirectX ?
J'étais venu donner cette information ici, ce qui a relancé le débat sur l'AmigaOS. 
Que peut tu dire du parallèle entre DirectX et l'AmigaOS (surtout époque Windows 95, je pense que de nos jours DirectX est bien différent).
Tu trouveras les propos de l'auteur de DirectX ici (vers le milieu de la page) :
http://blog.a-eon.biz/blog/?p=7873

Idem quand tu expliques à Rocky que c'était plus ergonomique de ne pas être obligé de saisir sa souris pour cliquer sur OK quand tu insérais la disquette demandée. Il t'a répondu qu'il suffisait de quelques lignes de code en C pour faire pareil. 
Sauf que quand tu appelles la fonction du GEM qui affiche une boite de dialogue pour confirmer ou annuler, ton programme n'a plus la main tant que l'utilisateur n'a pas fait l'un des 2 choix ! Donc ça : 

et comme déjà dit, rien n'empêchant le codeur de faire d'ajouter ses 10 lignes de C dans son logiciel pour faire la detection automatique.  
plein de jeux Atari detectait tout seul le changement de disquettes.

C'est faux. Le seul moyen pour le codeur est de gérer lui même la boite de dialogue entièrement : c'est un plus long que 10 lignes de code en C... 
L'autre solution serait l'ouverture d'une fenêtre modale. C'est à dire une fenêtre autonome qui ne bloque pas l'appelant. Mais ce n'est possible qu'avec du multitache. Donc interdit au ST... 
Et oui, le multitache sert aussi à faire des applis MDI. Ce qui apporte un plus en terme d'ergonomie.

Je suis content que tu confirmes mes propos pour ce point d'ergonomie de l'Amiga. 
Comme je ne connais pas la programmation ou le fonctionnement interne du TOS ou AmigaOS, j'ignorais qu'en absence de multitâche ce n'est pas possible sur ST... 
Mais Rocky007 nous a habitué à dire que tout était possible sur ST :) 

Un jeu par contre, ne passe pas par le GEM pour demander une confirmation à l'utilisateur : c'est pour ça que des jeux pouvait le faire. Mais sortir cet exemple dans une discussion sur les limites du TOS/GEM. Hmmm....

Oui, j'avais plus ou moins fait remarquer ça qu'un jeu ça n'avait pas trop de rapport avec TOS/GEM.

Sur l'Autorun dont tu parlais : il n'y a pas que le programme lancé automatiquement. il y a aussi l'icone. Quand tu met un CD dans un micro d'aujourd'hui, c'est un icone peronnalisé qui apparait. Et c'est comme ça depuis 1995 sous windows. Ou 1985 sous AmigaOS...

C'est tout à fait exact pour l'icone aussi (et en plus animée (deux états), pas juste un fond de couleur en plus quand elle est sélectionnée)

Revenons sur le débat TOS/AmigaOS :

Il y a de grandes discussion ici sur le TOS et l'AmigaOS. 
Mais elles s'arretent sur l'aspect visible de ces OS. Et comme pour un iceberg, ça ne représente qu'une toute petite portion de l'OS. Et ce n'est pas la plus importante. 
Le plus important, ce sont les API de l'OS. Ce sont elles qui permettent à toutes les applications de tourner dessus.
Les API sont des ensembles de fonction qui permettent d'effectuer un certains nombre d'actions. Elle permettent, entre autres : 
        - D'éviter d'avoir à réinventer la roue à chaque écriture de logiciel. Pour cela elles doivent être le plus complete possible. Et le TOS est loin derrière le mig à ce niveau. 
        - D'utiliser le hardware sans être obligé de le manipuler directement. 
        - D'avoir des applications qui disposent du même look & feel. 

Un logiciel quel qu'il soit (on écarte les démos et les jeux de cette explication) passe une bonne partie de son temps à appeler ces fonctions de l'OS. 

Comment appeler une fonction de l'OS dans le mig ? 

Les fonctions sont regroupées dans des bibliothèques. Avant de pouvoir utiliser une fonction, il faut "ouvrir" la bibliothèques qui la contient. Bien sur, un programme ne le fait qu'une seule fois. Le plus souvent pendant son initialisation. 

Ouvrir une bibliothèque permet, entre autres, de savoir ou elle se trouve. C'est bien sur une obligation pour pouvoir l'utiliser ! 
Comment fait-on ? C'est simple : on utilise la fonction OpenLibrary de la bibliothèque EXEC. Mais comment ouvrir EXEC alors ?!!! 
Pas besoin : EXEC est la seule bibliotheque qui soit toujours ouverte. Et son adresse est fixe. C'est la seule qui soit dans ce cas dans tout l'AmigaOS. Ce qui apporte de la souplesse et permet de conserver une compatibilité totale si des bibliothèque sont modifiée. 

Exemple, on trouve en ROM une bibliothèque A et juste après une bibliotheque B. On améliore l'OS et on ajoute des fonction à la bibliothèque A. Du coup la bibliothèque B ne sera plus au même endroit. Avec le système de l'AmigaOS, ça ne posera pas de problème. Y compris pour EXEC : comme c'est la première des bibliothèques en ROM, elle se trouvera toujours au même endroit. 

Evidemment, rien n'empeche le codeur "maladroit" d'appeler une fonction de l'OS directement sans utiliser le système d'ouverture. Après tout, il sait bien ou se trouvent les fonctions dont il a besoin. Pourquoi s'embeter à respecter les recommandation de Commodore ? 
C'est ce que faisait souvent les jeux du début (Juste par flemme...). Et c'est pourquoi ils rencontreront des problèmes de compatibilité avec les versions ultérieures de l'AmigaOS. 

Alors : comment fonctionne OpenLibrary ? 

On lui donne le nom et la version de la bibliothèque que l'on souhaite utiliser et elle renvoit un pointeur qui contient l'adresse de base de la bibliothèque. Si elle ne la trouve pas dans la ROM, elle recherche dans le répertoire LIBS et si elle la trouve, la charge en mémoire. Elle vérifie que le numéro de version de la bibliothèque trouvée est supérieur ou égal au numéro de version que l'on a envoyé en paramètre. Si elle ne trouve pas la bibliothèque ou si celle qu'elle a trouvé n'a pas le bon numéro de version, elle renvoit null. 
On donne le nom de la bibliothèque en clair. On peut donc avoir un nombre énorme de bibliothèque différente. 
On peut même indiquer un chemin complet pour le nom de la bibliothèque et l'AmigaOS ira directement voir à cet endroit pour la charger (au lieu d'aller dans LIBS). 

Pour le programmeur, ça apporte un certain confort. Il ne se préoccupe pas de savoir si la bibliothèque qu'il utilise est en ROM ou si elle doit être chargée. Il n'a pas à vérifier si la bibliothèque qu'il utilise possède bien les fonctions dont il a besoin puisque la gestion des version le fait pour lui. Il n'a pas à vérifier si la bibliothèque est déjà chargée. S'il ouvre une bibliothèque qui l'est déjà, l'OS lui retournera le pointeur dont il a besoin et cela ne génèrera aucun problème. Ainsi, si une bibliothèque qui se trouve sur disque est déjà chargée en RAM par une autre application, c'est elle qui sera utilisée. L'OS ne la chargera pas deux fois. A l'inverse l'OS ne libérera la bibliothèque que lorsque toutes les applis qui l'utilisent l'auront fermé. 
C'est pour s'assurer qu'il n'y aura pas de problème lors de l'utilisation conjointe d'une bibliotheque par plusieurs application que Commodore imposait que le code d'une bibliothèque soit réentrant. Parce que n'importe quel codeur pouvait coder sa propre bibliothèque. Aminet en est rempli. 

Je ne connais aucun système analogue sur le TOS. Ni même quelque chose d'approchant. 

Ensuite, il faut pouvoir appeler les fonctions de la bibliothèque. On pourrait le faire de plusieurs façon mais les règles de Commodore imposait l'utilisation d'un adressage indirect avec déplacement. Elles imposaient également l'utilisation du registre A6 comme base. 
Concrètement cela signifie que A6 contient l'adresse qui a été retournée par OpenLibrary() et que l'on accède la façon suivante : 

JSR Offset(A6) 

Offset représente la position de la fonction par rapport au début de la bibliotheque. Par exemple, si une fonction se trouve à 1000 octets du début ça donnera : 

JSR 1000(A6) 

Efficace mais pas très parlant. Donc sur le mig, on ne fait pas comme ça : on utilise des constantes fournies par Commodore. Elle associe un nom de fonction à la valeur de l'offset qui lui correspond. Donc en assembleur un appel de fonction prend la forme suivante (exemple avec une fonction qui converti un caractère en majuscule) : 

Move.l #Code,(D0)        ; On met le code du caractère à convertir dans D0 
JSR ToUpper(A6)           ; On appelle la fonction. D0 contient le caractère converti. 

(Le "ToUpper" est la constante dont je parlais) 

Et c'est terminé. Le code ci-dessus prend 12+18 = 30 cycles. 

Le système est simple, efficace, rapide et très lisible. On jetant juste un oeil sur ce code, on sait exactement ce qu'il fait. 


Comment ça se passe dans le ST ? 

Le système est totalement différent. Il s'appuie sur l'instruction TRAP. Cette instruction prend en parametre un numéro de vecteur. Le 68000 utilise ce numéro pour savoir ou aller chercher l'adresse à laquelle il doit se rendre avant de traiter l'exception. 
Pour appeler une fonction, on met les paramètres sur la pile, on met le numéro de la fonction sur la pile, on fait le trap en utilisant un numéro de vecteur qui correspondra à la librairie que l'on souhaite utiliser et on réaligne la pile. Ca donne ceci : 

Move.l  #X,—(sp)         ; On empile un paramètre  
move.w  #3 ,—(sp)      ; On met le numéro de la fonction sur la pile 
TRAP #13                   ; On déclenche l'exception 
Move.l  (sp)+,D0         ; On recupère le retour dans D0 
addq.l  #2,sp              ; On réaligne la pile 

88 cycles. Mais ce n'est pas tout. Ce système oblige le TOS à faire des choses en plus : dépiler le numéro de fonction, utiliser ce numéro pour récupérer l'adresse de la fonction dans une table (après y avoir appliqué un décalage de 2 bits), appeler la fonction et dépiler le paramètre. Et le RTE que le TOS devra faire est plus couteux que le RTS que fera l'AmigaOS. Ouf ! 
On sera aux alentour de 130-140 cycles de plus que l'AmigaOS ! Et j'ai pris pour exemple une fonction avec un seul paramètre : plus ces derniers sont nombreux, plus l'écart est grand ! 

Donc au final : 
        - Le TOS perdra plein de temps à chaque appel de fonction. 
        - Les fonctions du TOS seront plus longues en taille. (Et pourtant le TOS utilise une ROM plus petite que l'AmigaOS) 
        - Les appels du coté de l'application seront plus long également. 
        - Le code sera beaucoup moins lisible. Car je n'ai jamais vu un système de constante analogue à ce qu'il y a avec le mig. Et 5 lignes sont moins lisibles que 2. 
        - le risque d'erreur sera plus grand. Non seulement il y a plus de code, mais il y a obligation de réaligner la pile. Si c'est mal fait, ça peut ne pas planter du tout, planter tout de suite ou planter bien plus tard. Si, dans l'exemple ci-dessus, le codeur choisi de ne plus récupérer la valeur de retour, il devra supprimer la 4eme ligne et surtout ne pas oublier de remplacer le #2 par #6. 

Je m'arrete là mais je pourrai passer des heures à faire des comparaisons qui seraient totalement défavorable au TOS/GEM...

Comme toujours, dès que tu approfondis dans la technique, on comprends la différence entre les deux machines et OS. Il va quand même falloir que je fasse une seconde lecture, mais déjà à la première j'ai compris l'essentiel.

[Invité]

en parlant de ca dlfrsilver tu arriverais a gratouiller dans "extase" et sortir les mods de tous les levels ? il sont plus ou moins altérés par ce qui se passe en jeu du coup c'est un peu chaud a ripper (ca doit muter des pistes et lancer des one-shot a gogo.. j'arrive a chopper les sons mais pas les. mods)

[babsimov]

Il n'existe pas de version A1200 de Dune à ma connaissance :)

Pour faire une version AGA, celà passe par 2 choses :
1) Désosser le programme de la version Amiga, surement codé en C et ASM. Et passer l'affichage de 5 à 8 bitplans (256 couleurs).
(C'est ce qui a été fait pour les 2 EOB).

2) Créer des outils pour ouvrir les fichiers archives qui composent le jeu et remplacer les graphismes.

A partir de la, une version AGA est possible. Mais ça nécessite un programmeur de talent.

CFOU pour EOB I et II a carrément du comprendre le système de compression utilisé pour chaque type de fichier et développer un compresseur supportant chaque format.

A voir si Philippe Ulrich aurait le code source de dune Amiga pour ce faire :)

Quand à porter Dune sur Atari ST, est-ce que le jeu en vaut la chandelle, le jeu est en 32 ou 64 couleurs sur Amiga (me souvient plus).

Dune Amiga ne possède pas toute les musiques c'est vrai, mais il a les principales, impeccablement répliquées via le tracker Starttrecker d'Exolon of Fairlight :).

Des programmeurs de talents, nous en avons croisés dans ce sujet (demomaker, expert OS, programmeur de jeu). Peut être que certains pourraient être intéressés ?

A moins que quelqu'un ait un contact avec Philippe Ulrich pour le code source ?

Pour une version AGA, serait il possible avec le copper d'avoir encore plus de couleurs que sur la version PC (notamment pour les dégradé dans le désert ?)

Les musiques, il y a eu une version MT32 (qui est midi je crois), peut être est ce possible de les convertir. Sinon il y a encore des musiciens de talent sur Amiga (Gibbs d'Amiga Impact me vient à l'esprit). Ses remix sont de grande qualité, peut être pourrait il faire une version Startrecker des musiques PC ?

Autrement, il reste à demander à Stephane Picq s'il ne serait pas intéressé par ce défit, pour le fun ? Tiens pour les 30 ans de l'Amiga, une sorte d'hommage à l'Amiga ?

Au sujet des musiques, pour ma part, ce que tu appel les musiques principale pour la version Amiga, ce n'était pas mes préférés la version PC... et la cassette en question je l'ai écouté suffisamment en attendant la version Amiga et le CD pour être très déçu de ne pas avoir des version Amiga de toutes les musiques qui m'avait enchantées dans la version PC. 

Dune Amiga était bien sur installable sur Disque dur, donc pas de souci à ce niveau :)

Le problème n'était pas qu'il soit installable sur disque dur (je le sais, c'est ce que j'avais fait), mais qu'il DEVAIT être jouable sans, à partir des disquettes. Donc, pour éviter trop de changement de disquettes, je penses qu'il a fallu réduire le nombre de musiques au minimum. 
Une version Amiga pensée UNIQUEMENT pour être jouée depuis un disque dur aurait, à mon avis, eu le même nombre de musiques que sur PC.

Je connais un mec sur Amiga qui sait très bien convertir les musique midi en format MOD :)

Donc, tout est possible, allez après Ambermoon, une version AGA de DUNE ?
Et même, pourquoi pas, après, une version CD32 basée sur la version PC CD du jeux ?

Est ce même envisageable de remplacer les mod Amiga du jeu, par des versions basés sur des samples issus de la version CD de la bande son (celle du CD EXXOS je veux dire, pas la version PC CD)?

Je possède également le CD des musiques, que j'ai aussi offert à mon beau-frère qui adore Dune comme moi :)

Il faut dire que ce jeu était à la hauteur des livres, culte.

[babsimov]

La demande de Kaot, me fait penser que le mod de la musique en jeu de Transarctica m'intéresserait.

A l'époque j'avais essayé de ripper ça, mais pas réussi.

Celle-ci :



Elle dure plus longtemps que ça dans mon souvenir.

As tu la possiblité de me la ripper en mod ?

PS : je réalise que je te demande surement trop. Met ça sur le compte de la passion, mais c'est vrai que le mod Transarctica (la musique en jeu) je ne l'ais pas encore trouvé. On arrive à trouver l'intro, mais celle là, elle me plait pas. Ca me rappel pas trop le jeu, j'ai bien plus entendu la musique en jeu que l'intro dans mes parties.

[dlfrsilver]

tout sur le format de fichiers de dune pour PC ici :

http://bigs.fr/dune_old/

la plupart des fichiers de la version amiga se décompressent bien avec UNHSQ.exe ; cependant, les fichiers graphiques ne semblent pas encodés de la même manière.

[dlfrsilver]

en parlant de ca dlfrsilver tu arriverais a gratouiller dans "extase" et sortir les mods de tous les levels ? il sont plus ou moins altérés par ce qui se passe en jeu du coup c'est un peu chaud a ripper (ca doit muter des pistes et lancer des one-shot a gogo.. j'arrive a chopper les sons mais pas les. mods)

C'est normal que tu n'arrives pas à chopper la musique, ce n'est pas un fichier mod, mais de la musique interactive.

regarde ici :

http://www.exotica.org.uk/wiki/Extase

Le morceau y est, mais il faut deliplayer pour le lire.

Transarctica c'est pareil, c'est un module custom crée par Michel Pernot (le frère de Jean-Pierre ! Nan c'est une blague, je rigole)

Comme ce n'est pas un fichier mod, impossible de le gauler, Les jeux silmarils sont des "bytes_interpreters", et c'est ardu de récupérer les fichiers en question.

[rocky007]

C'est faux. Le seul moyen pour le codeur est de gérer lui même la boite de dialogue entièrement : c'est un plus long que 10 lignes de code en C...

effectivement si on utilise une boîte d'alerte GEM, on ne sait pas en sortir, par contre rien n'empêche d'ouvrir une fenêtre et y afficher un message de changement de disque.  quand je parlais de 10 lignes, c'était par exemple dans le cas d'un jeu ou d'un installateur sur disque dur. 


concernant le multitâche sur 800 XL, en effet, mea culpa, l'OS n'est pas en version définitive, mais toujours en développement.

( http://atari8.co.uk/gui/ )



beaucoup de choses à lire intéressantes ( et de stapha92   ).. et oui je ne connais strictement rien en hardware/coding XL, donc désolé si je ne fais que glaner sur internet des infos où je peux, vu que la bibliothèque du coin n'a probablement pas de livre sur le 800 XL.  Pour le displaylist par exemple, pour ce que j'en pu en lire, cela me semblait pourtant très similaire au copper : un copro indépendant du 6502 qui exécutait un script synchro sur l'affichage vidéo.  alors oui, c'est surement pas aussi puissant, mais le concept me semble qd même très similaire non ?

[barbarian_bros]

Pour les musiques de Dune, même la version MT-32 (pourtant très bonne), a un moins bon rendu que la version AdLib (et soundblaster, la SB étant à la base un clone d'AdLib).
C'est valable aussi pour KGB/Conspiracy, l'autre jeu d'aventure de Cryo qui utilise le même moteur et une interface quasi-similaire (d'ailleurs dans le générique du jeu une version CD de la musique est annoncée, comme pour Dune, mais il me semble qu'elle n'est jamais sortie).

En fait Stéphane Picq a composé les musiques AdLib ' de Dune et de KGB en utilisant le moteur sonore 'HERAN System', créé par Remi Herbulot (programmeur de chez Cryo) en collaboration avec les ingénieurs de chez AdLib.
Le Heran System  repousse les capacités de synthèse FM plus loin que ce que les responsables de chez AdLib croyait possible sur leur puce sonore.

[stapha92]

85-88 : ATARI WINNER FINGER IN THE NOZE

Hmmm... ah bon ? Et pourquoi donc ? Voyons voyons... 

Bureautique : Avec son écran monochromme, le ST a l'avantage. 
Midi : Les logiciels Midi sont adaptés sur le mig. Mais avec retard et pas tous... ST devant 

Pour ces 2 domaines, Atari gagnant si on achète un périphérique couteux avec son ST (imprimante ou expandeur midi) et qu'on est pret à se contenter d'un moniteur noir et blanc (ou a acheter 2 moniteurs et un switch). 

Continuons : 

Jeux : les meilleurs jeux sont déjà sur Amiga (alors qu'il ne l'exploitent pas encore...) et, techniquement, le ST ne peux pas suivre. 

Dessin : On a photon paint, digi paint, deluxe paint, etc... Des logiciels qui n'existent pas sur ST ou qui y existent sous forme d'erzast. De toute façon, le ST est trop largué pour pouvoir offrir quelque chose d'approchant... 

Musique : Les trackers à base de samples naissent sur le mig. Le ST ne peut pas suivre. Ses trackers sont incapables de reproduire tous les effets d'un mod créé sur le mig à cause du hardware bien trop largué par celui du mig... 

Animation :  Aegis Animator, Lights!Camera!Action!, DeLuxe Video, Disney Animation Studio, etc... : le ST est bien trop limité sur ce point... 

Modelisation 3D :  Sculpt 3D, TurboSilver, Videoscape 3D, Caligari, Imagine, Real 3D, Etc... : Les meilleurs logiciels sont sur Amiga. Les capacités graphiques du ST sont trop dépassées par celles du mig... 

Programmation : La programmation sur mig est plus moderne (événementielle, gestion de messages, Arexx, scripts...), plus agréable (API du TOS incomparable avec celle de l'AmigaOS), plus diversifiée (présence de coprocesseurs, et d'un chipset plus souple et performant). Il dispose de CygnusEd (éditeur dédié au coding et inégalé sur ST), de compilateur C gratuits (domaine public) et de AMOS (La version Amiga explose littéralementde STOS et a d'ailleurs beaucoup évolué et reçu une flopée d'extensions) et même du GFA (avec 2 mois de retard mais plus de possibilités grace à l'OS) 

CAO :  X-CAD, IntelliCAD, IntroCAD, MaxonCAD, ElektroCAD. Rien à envier au ST. Encore une fois, la haute résolution en 16 couleur est un plus. 

Dans ces domaines, le ST est déjà largué pendant cette période. Et il s'agit de choses qui se font sans être obligé d'investir dans un périphérique... 

89-92 : ATARI WINNER POUR LA BUREAUTIQUE/PRO/PROG/ULILITAIRES et AMIGA WINNER POUR LE JEU

Bureautique : Les logiciels de bureautique débarquent en nombre sur le Mig. Les écrans VGA baissent. Le mig a accès à des résolutions biens supérieures à celles du ST. 
                          Le premier traitement de texte a pouvoir intégrer des images 24 bits dans un document sort sur mig (WordWorth) 

Midi : Pro24 est disponible. Cubase ne l'est pas mais Bar & Pipes débarque. Son système de module est tellement révolutionnaire (et utilise abondamment le multitache) que Microsoft a racheté l'éditeur du logiciel pour reprendre sa technologie dans DirectSound... 

Pour le reste, l'avantage que le mig possédait déjà s'est creusé. 

Et pourquoi s'arreter en 92 ? Le ST avait peut-être disparu, mais ce n'était pas le cas du mig. 
Rien qu'au niveau des jeux : plus de 1 000 jeux sortiront sur le mig à partir de 1993... 

Et comme pour moi la grande epoque 16/32bit c'etait 86-89... tous les titres revolutionnaires sont sortis sur cette période, et franchement y a eu essoufflement des 1990 dans la qualité des programmes... ATARI l'emporte donc HAUT LA MAIN dans cette guerre.

Donc Vroom (1991) et Lotus 2 (1991) sont de moins bonne qualité que Buggy boy ? 
Même sur ST, ce que tu dis est complètement faux : les meilleurs jeux du ST sont sortis pendant cette période que tu prétend déclinante... 

Et sur Amiga, c'est encore pire : 1990 c'est le début de l'age d'or pour les jeux

[babsimov]

tout sur le format de fichiers de dune pour PC ici :

http://bigs.fr/dune_old/

la plupart des fichiers de la version amiga se décompressent bien avec UNHSQ.exe ; cependant, les fichiers graphiques ne semblent pas encodés de la même manière.

Est ce à dire que tu as déjà commencé le portage de DUNE en AGA :)

Ca ce serait cool. 

J'espère que cette idée lancée un peu comme ça, pourra se concrétiser.

[babsimov]

Stapha92, je me suis souvenu d'une de tes réponses récentes qui m'avait amené une nouvelle série de questions. Ca fait quelques pages déjà. Je pense que ces questions ont été diluées dans le flot de toutes celles que je t'ai déjà posé. Cela concernait ta version de ce qu'aurait du être l'AGA.

Je vais donc me permettre de remettre ta réponse d'origine, ainsi que les questions que celle ci avait entrainé de ma part, en espérant que tu trouveras un peu de temps pour y répondre. 
J'espère que tu ne m'en voudras pas pour cette démarche un peu "cavalière".

Tu avais é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.

Et je t'avais répondu ceci, avec plusieurs questions à l'intérieur :

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

[babsimov]

dlfrsilver

Transarctica c'est pareil, c'est un module custom crée par Michel Pernot (le frère de Jean-Pierre !  Nan c'est une blague, je rigole)

Comme ce n'est pas un fichier mod, impossible de le gauler, Les jeux silmarils sont des "bytes_interpreters", et c'est ardu de récupérer les fichiers en question.

Si c'est trop compliqué, c'est pas grave, t'embête pas. 
Cependant, si, un jour ça "t'amuse" d'essayer et que tu as du temps, je suis intéressé par le mod.

[dlfrsilver]

tout sur le format de fichiers de dune pour PC ici :

http://bigs.fr/dune_old/

la plupart des fichiers de la version amiga se décompressent bien avec UNHSQ.exe ; cependant, les fichiers graphiques ne semblent pas encodés de la même manière.

Est ce à dire que tu as déjà commencé le portage de DUNE en AGA :)

Ca ce serait cool. 

J'espère que cette idée lancée un peu comme ça, pourra se concrétiser.

Il manque un programmeur..... un vrai avec de large épaules.....

Je n'ai rien commencé du tout, les graphismes PC ne sont pas encodés comme ceux de l'amiga déjà.

Pas un projet simple

[babsimov]

tout sur le format de fichiers de dune pour PC ici :

http://bigs.fr/dune_old/

la plupart des fichiers de la version amiga se décompressent bien avec UNHSQ.exe ; cependant, les fichiers graphiques ne semblent pas encodés de la même manière.

Est ce à dire que tu as déjà commencé le portage de DUNE en AGA :)

Ca ce serait cool. 

J'espère que cette idée lancée un peu comme ça, pourra se concrétiser.

Il manque un programmeur..... un vrai avec de large épaules.....

Je n'ai rien commencé du tout, les graphismes PC ne sont pas encodés comme ceux de l'amiga déjà.

Pas un projet simple

Y aurais pas un programmeur Amiga avec de larges épaules ici ? :)

Tant qu'à faire, ne pas oublier d'ajouter des versions Amiga des musiques PC qui ne sont pas sur Amiga. Et tant qu'à faire, à implémenter la lecture en mode CD, comme sur PC :)

En faite faire ce qui aurait du être fait à l'époque en somme :)

Quoi je suis exigeant ? c'est que Dune ce fut un véritable choc pour moi à l'époque, un jeu CULTE.

Il semble qu'il y ait une tentative en cours pour une réécriture du jeu en open source :
http://sourceforge.net/projects/dunerevival/?source=typ_redirect