Re: GUERRE ST-AMIGA, FIGHT !!!

[dlfrsilver]

La mauvaise foi incroyable de difrsilver... Casser les jeux ST, Mortevieille Manor, Sundog, Carrier Command qui fut une révolution, le GFA basic... par jalousie car tous ces titres sont sortis en exclu ou BIEN AVANT sur Atari ST.

Mortevielle manor a été programmé en pascal sur les 3 machines : St, amiga, PC. Ah j'oubliais même la version CPC (lol).

LE GFA Basic, avec le recul, n'était pas si bien que ça. Son gros défaut c'est qu'on ne peut pas injecter dedans un listing programme contenu dans un fichier texte. C'est une des raisons pour lesquelles il a assez vite disparu.

Qui se souvient des listings en GFA basic sur Amiga (Et St) dans le magazine Joystick ?

[Seb]

Mortevielle manor a été programmé en pascal sur les 3 machines : St, amiga, PC. Ah j'oubliais même la version CPC (lol).

LE GFA Basic, avec le recul, n'était pas si bien que ça. Son gros défaut c'est qu'on ne peut pas injecter dedans un listing programme contenu dans un fichier texte. C'est une des raisons pour lesquelles il a assez vite disparu.

Et alors? Pour ton info plein de demos PC (certains mythiques) ont aussi été faites en (Turbo) Pascal. L'important est la qualité du code, pas le langage.

Pour le GFA Basic, il était excellent pour l'époque, beaucoup de gens ont commencé avec ca, c'était une très bonne école et c'était très accessible malgré quelques points faibles.

Mais c'est vrai, j'oubliais, tu ne programmes pas mais une fois de plus tu as un avis très tranché sur tout, même ce qui n'est pas ton domaine.

[rocky007]

LE GFA Basic, avec le recul, n'était pas si bien que ça. Son gros défaut c'est qu'on ne peut pas injecter dedans un listing programme contenu dans un fichier texte.

ah bon ? c'est nouveau ça ..  il y a "MERGE" qui permettait de lire un fichier texte

C'est une des raisons pour lesquelles il a assez vite disparu.

ah oui surement !  c'est pas toi qui fait l'émission " les dessous des camemberts" sur groland ?

[dlfrsilver]

Et alors? Pour ton info plein de demos PC (certains mythiques) ont aussi été faites en (Turbo) Pascal. L'important est la qualité du code, pas le langage.

Pfff les démos pour PC.... Si tu savais ce que j'en pense.... Même sur amiga, c'est quelque chose, et c'est un avis très personnel, ça ne m'emballe pas. Le seul intêret que j'y vois, c'est le développement de routines plus pointues.
Sinon je trouve ça sans intêret.

Ce que je voulais dire, c'est que le manoir n'a pas été spécifiquement fait pour le ST, malgré qu'il soit sorti dessus en premier, c'est bien la raison pour laquelle le pascal à été utilisé. ça permet un transcodage rapide entre les différentes plateformes.

Pour le GFA Basic, il était excellent pour l'époque, beaucoup de gens ont commencé avec ca, c'était une très bonne école et c'était très accessible malgré quelques points faibles.

Sauf que c'est trop fermé comme outil. Comme je le disais, si les auteurs avaient implémenté la possibilité de charger dans ce logiciel des fichiers textes contenant des programmes GFA, ça aurait été très pratique.

Je ne vois pas d'autre raison pour laquelle ce langage a disparu. Y a aussi les systèmes de développement type SNASM et Pegasus Development System (PDS) qui tournaient sur PC via une carte qui lui ont fait la peau.
Bien plus pratiques, et tout en assembleur, plus rapides :)

Mais c'est vrai, j'oubliais, tu ne programmes pas mais une fois de plus tu as un avis très tranché sur tout, même ce qui n'est pas ton domaine.

Et alors ? Tu es une sommité toi-même pour me dire comment je dois penser et voir même oser me dire que je pense mal ?

Je ne programme pas, parce que je ne me suis pas penché à fond sur le sujet, ça me prendrait beaucoup de temps, et ce temps là je l'occupe déjà à d'autres activités très chronophages. Je ne peux pas être partout, et surtout je ne le veux pas. La préservation logicielle occupe 80% de mon temps, et je ne suis pas payé pour ça, je le fais à titre gracieux. Chacun son truc :) Il faut faire des choix dans la vie, Seb, on ne peut pas tout faire.

Mais ça ne m'empêche pas d'essayer et de voir les dits programmes, histoire de ne pas mourir bête :) Et d'y trouver des qualités ou des défauts. le GFA basic, j'ai en original la dernière version du programme pour Amiga. Et de dire merde, c'est pas du tout 'open' comme logiciel, c'est rigide comme outil, pas besoin d'être programmeur avec 10 années d'expérience, ça saute aux yeux à l'utilisation. Je ne parle pas de l'aisance à programmer dessus, mais de l'outil en lui-même la façon dont il a été conçu, et de ce que peut faire ou pas l'utilisateur avec.

@Rocky007_"NanPasleBoaaNannnn" :

Je ne faisais pas allusion à l'instruction merge qui permet de fusionner (merge) un fichier texte avec le fichier en cours, mais bien d'importer un programme tapé en GFA Basic en dehors de l'éditeur dans un fichier texte.
Ce dernier ne le permet pas. Tout simplement parce que les fichiers générés dans l'éditeur GFA sont comme "compilés" (c'est peut-être pas le bon mot), et non sauvés comme du texte (comme pour un fichier ASM par exemple).

[rocky007]

Je ne faisais pas allusion à l'instruction merge qui permet de fusionner (merge) un fichier texte avec le fichier en cours, mais bien d'importer un programme tapé en GFA Basic en dehors de l'éditeur dans un fichier texte.
Ce dernier ne le permet pas. Tout simplement parce que les fichiers générés dans l'éditeur GFA sont comme "compilés" (c'est peut-être pas le bon mot), et non sauvés comme du texte (comme pour un fichier ASM par exemple).

justement : tu démarres GFA, tu choisis "merge", sélectionnes ton fichier TEXTE tapé dans n'importe quel éditeur ascii, et hop miracle, c'est importé !

Je ne programme pas, parce que je ne me suis pas penché à fond sur le sujet, ça me prendrait beaucoup de temps, et ce temps là je l'occupe déjà à d'autres activités très chronophages.

si tu comptes le temps passé à raconter n'importe quoi sur les forum, tu aurais pu être expert en PHP, SQL, C#, ASSEMBLEUR 6502-68k-FPGA-ATMEL, PYTHON et LOGO.

[Seb]

Et alors ? Tu es une sommité toi-même pour me dire comment je dois penser et voir même oser me dire que je pense mal ? 

Effectivement, non.

Mais il y a une différence fondamentale entre toi et moi (+Stapha92) sur ce thread: contrairement à toi, je parle de ce que je connais. J'ai fait du GFA et de l'assembleur sur ST pendant des années et depuis cette époque programmer reste un des éléments de mon boulot.

[dlfrsilver]

Je ne faisais pas allusion à l'instruction merge qui permet de fusionner (merge) un fichier texte avec le fichier en cours, mais bien d'importer un programme tapé en GFA Basic en dehors de l'éditeur dans un fichier texte.
Ce dernier ne le permet pas. Tout simplement parce que les fichiers générés dans l'éditeur GFA sont comme "compilés" (c'est peut-être pas le bon mot), et non sauvés comme du texte (comme pour un fichier ASM par exemple).

justement : tu démarres GFA, tu choisis "merge", sélectionnes ton fichier TEXTE tapé dans n'importe quel éditeur ascii, et hop miracle, c'est importé !

Je ne programme pas, parce que je ne me suis pas penché à fond sur le sujet, ça me prendrait beaucoup de temps, et ce temps là je l'occupe déjà à d'autres activités très chronophages.

si tu comptes le temps passé à raconter n'importe quoi sur les forum, tu aurais pu être expert en PHP, SQL, C#, ASSEMBLEUR 6502-68k-FPGA-ATMEL, PYTHON et LOGO.

ça te parait intuitif à toi d'avoir à utiliser la commande 'Merge' pour faire ça, alors que ça aurait du être permis avec une commande telle qu' 'Importer' ?

Et depuis quand parce que quelqu'un n'est pas d'accord avec ton opinion il raconte nécessairement n'importe quoi ? Mhhh ? Parce que tu crois que t'en racontes pas des belles toi ? Pourquoi tu crois que Stapha t'enterres à chaque fois que tu balances des arguments ? Si tu disais vrai, il ne pourrait pas le faire. Pas de bol, comme c'est pas le cas, c'est l'enterrement à chaque fois.

Alors monsieur je sais tout, tu as quoi à répondre à ça ?

Moralité de l'histoire : Avant de dénoncer les alumettes qui sont enfoncées dans mes yeux, regarde donc les poutres qui sont enfoncées dans les tiens ! 

[dlfrsilver]

Et alors ? Tu es une sommité toi-même pour me dire comment je dois penser et voir même oser me dire que je pense mal ? 

Effectivement, non.

Mais il y a une différence fondamentale entre toi et moi (+Stapha92) sur ce thread: contrairement à toi, je parle de ce que je connais. J'ai fait du GFA et de l'assembleur sur ST pendant des années et depuis cette époque programmer reste un des éléments de mon boulot.

Certes :) Mais justement, le problème quand on a le nez à fond dedans, ou le nez dans le guidon dans une discipline, on manque très souvent du recul nécessaire justement, très souvent :)

Je ne programme pas c'est un fait, mais pour avoir utilisé tel quel le GFA basic, d'un point de vue utilisation, je suis plus à même que toi qui a programmé avec d'avec un avis avec plus de recul. Tu vois l'outil d'un point de vue rahh trop bien, trop simple d'utilisation, et tu ne vois pas ou plus les défauts de l'outil.

Comme l'a dit lui-même Rocky, le fait d'avoir à utiliser la commande Merge au lieu d'importer pour monter un fichier texte contenant un programme GFA est une hérésie.

La commande Merge doit permettre normalement de fusionner 2 bouts de textes ou 2 bouts de programmes, c'est une simple question de définition : Fusionner n'a rien à voir avec importer.

Comment tu veux qu'un utilisateur à la base ne soit pas décontenancé ? Moi je m'en tiens au sens des mots du dictionnaire.

Tu comprends maintenant pourquoi j'ai jamais pu faire l'import d'un fichier texte ? Parce que je n'aurais jamais pensé une seule seconde que la commande Fusionner servait à ça dans l'éditeur GFA.

ça évidemment comme tu es un habitué du GFA, ça te passe au dessus de la tête, mais moi qui cherche d'abord et toujours à maitriser l'interface du soft avant de m'en servir, forcément ça me saute au yeux.

C'est absolument pas intuitif dans le principe.

[rocky007]

ça te parait intuitif à toi d'avoir à utiliser la commande 'Merge' pour faire ça, alors que ça aurait du être permis avec une commande telle qu' 'Importer' ?

intuitif ou non, tu t'es encore planté une fois de plus

Et depuis quand parce que quelqu'un n'est pas d'accord avec ton opinion il raconte nécessairement n'importe quoi ? Mhhh ? Parce que tu crois que t'en racontes pas des belles toi ? Pourquoi tu crois que Stapha t'enterres à chaque fois que tu balances des arguments ? Si tu disais vrai, il ne pourrait pas le faire. Pas de bol, comme c'est pas le cas, c'est l'enterrement à chaque fois.

ah bon ? je n'ai pas spécialement remarqué.  tu ne lis pas mes réponses apparemment.

[Urbinou]

Tu comprends maintenant pourquoi j'ai jamais pu faire l'import d'un fichier texte ? Parce que je n'aurais jamais pensé une seule seconde que la commande Fusionner servait à ça dans l'éditeur GFA.

Ben non je ne comprends pas... RTFM quoi

[Seb]

dlfrsilver: justement je n'ai jamais été un power user du GFA, j'ai même débuté avec, donc j'avais le recul nécessaire du non-expert. Aujourd'hui encore avec le recul je trouve que c'était très bon pour un basic pour 1986 malgré ses défauts, c'est d'ailleurs pour ca qu'il a été si populaire à l'époque et a réussi à toucher autant de gens.

[Seb]

Pfff les démos pour PC.... Si tu savais ce que j'en pense.... 

Encore un sujet que tu snobes et qui est sans intérêt (on est habitué) mais c'est ton droit.

Cela dit, pour ton info quand même, les demos ca va bien plus loin que "le développement de routines plus pointues", c'est une excellente école que ce soit sur le plan technique, artistique ou créatif. Ca développe une multitude de compétences, le gout de pousser toujours plus loin, de trouver des solutions originales, de travailler en équipe et surtout d'innover et créer.

Ce n'est pas par hasard si on retrouve d'anciens demomakers a plein de postes clés dans l'industrie du jeu video sur de très bons jeux (le directeur technique des God Of War sur PS2/PS3), le co-président de Naughty Dog, l'équipe technique et artistique de DICE en Suède, Remedy (Max Payne), Starbreeze, le co-fondateur de Media Molecule (un des studio les plus créatifs), sans parler des indies.

Par contre pour juste troller sur les forums, les demos c'est effectivement sans intérêt :)

[dlfrsilver]

Pfff les démos pour PC.... Si tu savais ce que j'en pense.... 

Encore un sujet que tu snobes et qui est sans intérêt (on est habitué) mais c'est ton droit.

Cela dit, pour ton info quand même, les demos ca va bien plus loin que "le développement de routines plus pointues", c'est une excellente école que ce soit sur le plan technique, artistique ou créatif. Ca développe une multitude de compétences, le gout de pousser toujours plus loin, de trouver des solutions originales, de travailler en équipe et surtout d'innover et créer.

Ce n'est pas par hasard si on retrouve d'anciens demomakers a plein de postes clés dans l'industrie du jeu video sur de très bons jeux (le directeur technique des God Of War sur PS2/PS3), le co-président de Naughty Dog, l'équipe technique et artistique de DICE en Suède, Remedy (Max Payne), Starbreeze, le co-fondateur de Media Molecule (un des studio les plus créatifs), sans parler des indies.

Je ne snobe pas les démos. C'est joli, mais je ne leur ai jamais trouvé un grand intêret. Franchement même dans les années 90, j'ai jamais collectionné les démos, je me cantonnais aux jeux et à certains utilitaires.

Je sais bien que même de gros pirates, y compris de la scène amiga ont des postes clés dans le secteur informatique, je suis bien d'avis avec toi :)

[dlfrsilver]

Exemple le patron de Megaupload, c'était un pirate sur Amiga :)

[stapha92]

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

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

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

Alors, il y a plusieurs cas : si on restreint l'amiga à de la chip ram uniquement, je pense que la bande passante du ST est un peu plus élevée.
Mais si on met une extension mémoire dans le mig, c'est une autre paire de manches : le fait que son accès ne soit pas entrelacé permet de multiplier par 2 le débit. 
Et tu noteras que les controleur SCSI du mig comportaient une extension mémoire (comme ton impact GVP). 
Et là le ST se fait exploser. Même si on est un bricoleur et que l'on met une extension mémoire dedans, ça ne changera rien. 

Et ce n'est pas le pire : si on prenait les cartes accéleratrices, la RAM passe en 32 bits (ce qui double encore la bande passante) et est plus rapide. La bande passante du mig devient facilement 5 fois plus rapide que celle du ST (voire encore bien plus avec les RAM les plus chères) 
Mais un HD qui pouvait suivre la moitié, voire le quart, d'un tel débit d'existait pas. L'interet était que le processeur pouvait accéder à la RAM en même temps que le controleur SCSI sans le ralentir.

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

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

es-tu en train de dire que : 

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

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

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

Non, ce n'est pas aussi catastrophique que ça. 

Si le ST se fait larguer par le mig, ce n'est pas parce qu'il est mauvais : c'est parce que le mig est vraiment bon  

D'ailleurs, à cette époque là, si on comparait les performance du ST avec celle d'un mac ou d'un PC, il l'emportait haut la main... 

Pour l'histoire de l'aiguillage qui ne bascule que tous les 2 cycles : ce n'est pas aussi grave qu'il n'y parait. 

Je vais détailler pour que ce soit compréhensible. Et certains verront que je ne suis pas de mauvaise fois... 

Si je fait la séquence d'attribution des cycles version ST, voilà ce que ça donne 

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

Le découpage se fait tous les 2 cycles. Et on voit que pour le shifter ça ne change rien puisqu'il exploite les 2 cycles qui se suivent quand "l'aiguillage" est de son coté. 

Qu'en est-il du 68000 ? Supposons qu'il doit executer une instruction qu'il lit pendant le cycle 3. 
Quand il aura terminé, 2 types de cas pourront se présenter, en fonction de la durée de l'instruction : 
        - l'instruction dure 4,8,12,16,etc... cycles : il tombe sur le cycle n° 7,11,15,19,etc... : Donc il peut immédiatement lire l'instruction suivante. Aucun problème 
        - l'instruction dure 6,10,14,18, etc... cycles : il tombe sur le cycle n° 9,13,17,21,etc... : Problème : l'aiguillage est du mauvais coté ! La mémoire est donc inaccessible. le 68000 doit attendre 2 cycles avant que l'aiguillage se repositionne de son coté. 
C'est ce que j'expliquais à certains Stistes qui ne voulaient pas l'admettre : Sur un ST, la durée des instructions est toujours arrondie au multiple de 4 supérieur. 

Mais, comme je le disais dans mon post, ce n'est pas si grave : la majorité des instructions prennent déjà un multiple de 4. 
Celles qui ne sont pas dans ce cas, sont en général celles qui travaillent en 32 bits avec des registres. Parce que le passage de 16 à 32  bits consomme 2 cycles en plus. Par exemple : 
        - cmp : comparaison entre 2 registres. 4 cycles en 16 bits, 6 cycles en 32 bits. 
        - sub : soustraction entre 2 registres. 4 cycles en 16 bits, 6 cycles en 32 bits. 
        - clr : nettoyage d'un registre. 4 cycles en 16 bits, 6 cycles en 32 bits. 
Il y a aussi les décalages et rotations : chaque niveau de décalage coute 2 cycles de plus. Donc, en fonction, du nombre de bits à décaler, on peut tomber sur un multiple de 4 ou non 
(exemple : lsl.w #3,D0 -> 12 cycles, lsl.w #4,D0 -> 14 cycles.) 
Il y a aussi celles pour lesquelles ça ne change pas grand chose : une multiplication signée prend 70 cycles. Une division signée en prend 158. 2 cycles de plus à ce niveau là, ce n'est pas grand chose... 
On en trouve d'autres, comme les calculs d'adresse qui ajoute un offset sur 8 bits, les move avec une pré-décrémentation du registre source, etc... 

Une autre question se pose : c'est bien beau de parler de la durée des instructions. Mais une instruction peut être amenée à faire un ou plusieurs accès mémoires pendant son exécution. Elle pourrait donc être ralentie. Par exemple, l'instruction Move.l (A0),(A1) fait 5 les accès mémoires suivants : 
        - Lecture de l'instruction. 
        - Lecture des 16 premiers bits depuis l'adresse pointés par A0. 
        - lecture des 16 bits suivants. 
        - Ecriture des 16 premiers bits dans l'adresse pointée par A1. 
        - Ecriture des 16 bits suivants. 
        
Que va-t-il donc se passer dans le ST ? Et bien il n'y aura aucun problème ! Et oui : le 68000 met toujours 4 cycles entre 2 accès mémoires. Cette instruction prendra 20 cycles : il n'y aura aucune perte. 

Alors évidemment, il est facile d'écrire un code qui perdrait un gros pourcentage de cycles et qui tounerait bien plus vite sur le mig que sur le ST. Mais, dans la pratique, ça n'arrivait pas. La perte réelle est difficile à estimer. Mais elle doit être minime. 

Si le mig garde si souvent l'avantage, c'est grace à son architecture, ses copros et son OS. Ce n'est pas que pour une raison unique.

Donc comme je le disais : ce n'est pas du tout aussi grave qu'il n'y parait.

En tout cas sur un ST de base... Et oui : essayons de bricoler un peu pour mettre un 68000 à 16 Mhz dans le ST. Que ce passe-t-il ? Et bien ça se comportera exactement comme un 68000 à 8 Mhz dans lequel toutes les instructions prendraient 2 fois moins de cycles pour s'executer. Une instruction qui prenait 4 cycles en prendra donc 2. Mais le 68000 devra en attendre 2 de plus pour pouvoir accéder à la RAM. Donc il en prendra 4. Aucun gain ! De même l'instruction détaillée ci-dessus devra attendre 2 cycles entre chaque accès mémoire. Ce qui implique qu'au final, un Move.l (A0),(A1) prendra exactement le même temps que le 68000 soit à 8 ou 16 Mhz. Et c'est le cas avec la majorité des instructions ! 
C'est pourquoi, dans son MegaSTE, Atari a été obligé de mettre une mémoire cache de 16 Ko pour que les 16 Mhz puisse apporter un gain (qui ne sera jamais de 200%...). 
Dans un mig, sans aucun cache, cette instruction pourrait faire ses accès mémoire tous les 2 cycles et en prendrait 10 au total. Elle irait réellement 2 fois plus vite. Sans être obligée de mettre un cache (qui augmentait le cout...). Evidemment, avec des processeurs plus rapide, comme un 68030 à 50 Mhz, la mémoire n'est plus du tout en mesure de suivre. Mais l'architecture du mig gère la fastram. Et le problème est réglé. C'est pourquoi toutes les cartes accélératrices du mig en embarquait. 

Le ST a une architecture non évolutive. Le mig est pensé dès le départ pour pouvoir évoluer. 

Tu glisses une carte accéleratrice sur le coté d'un A500. Aucun démontage, aucune soudure et hop : tu peux jouer à DOOM de façon fluide. 
Et l'A500 est le moins évolutif des Amiga...

[stapha92]

Babsimov, 

Pour ta question sur le 800XL : 

Tout d'abord, expliquer que le mig est une évolution du XL est une erreur. C'est la preuve d'une méconnaissance de l'architecture des 2 machines. 
La seule ressemblance se résume au sprites. Et encore : ceux du mig sont plus proches de ceux d'un C64... 
Idem pour l'affichage : la gestion et la génération des pixels d'un mig est bien plus proche de celle d'un amstrad que d'un XL ou d'un C64 (pas de chunky, pas de mode caractère, utilisation d'intensité RGB et non de valeurs chromatique prédéfinies, etc...) 
Quand à ceux qui expliquent que le copper est une évolution des displaylist. Ben je leur dirai d'arreter de piocher des affirmations sur internet et d'étudier le fonctionnement et la raison d'être des 2 systèmes... 
Cela dit, cela ne ne m'aurait pas dérangé que ce soit le cas : j'adore le 800XL qui était mon premier micro. Une bien belle machine qui, bien que dotée d'un technologie datée de 1979 parvenait à tenir la route face à des concurrents sortis bien après. 
Son principal défaut est la difficulté à tirer profit de toutes ses capacités. Mais, quand un codeur y parvient, cela peut donner des résultats impressionnants : 





 

Pas mal pour une techno de 1979... 


Revenons-en à ta question : 
Il est construit autour d'un 6502 : il s'agit d'un processeur capable d'accéder à la mémoire à chacun de ses cycles. Donc pas moyen d'utiliser un entrelacement systématique de la RAM. Chaque fois que le circuit graphique a besoin d'accéder à la RAM, le 6502 subit une latence. 
Heureusement, seul ANTIC a besoin de faire ça et ce dernier dispose d'un buffer : ça lui permet de gérer efficacement les modes caractères et lui évite de refaire un accès à la RAM quand une ligne est dédoublée (c'est à dire quand la résolution verticale est divisée par 2). 

Dans un post au-dessus, ou Rocky commence par "BIM !", on nous explique qu'il y a 4 circuit qui fonctionnent simultanément. C'est faux. (Mais j'ai comme l'impression que c'est volontaire et que c'est fait uniquement pour parler du 800XL, ce à quoi je ne peux que souscrire ! )
Pokey est le circuit sonore : il ne peut fonctionner que si le 6502 le pilote, comme le SID du C64 ou le YM des ST/CPC. Il n'est pas autonome. 
GTIA (ou CTIA) est le circuit qui génère l'affichage. Mais il ne lit pas les données dans la RAM : il est alimenté par ANTIC qui interprète ces dernières et envoit les données à afficher à GTIA. ANTIC a été ajouté à l'architecture de l'Atari 2600 justement pour ça. 
Donc comme je le disais, seul ANTIC a besoin d'accéder à la RAM (peut-être une exception pour les sprites, je ne sais plus). 

Quoi qu'il en soit, ces circuits ne sont pas des coprocesseurs et ne déchargent pas le 6502, contrairement aux copros du mig. 

Lis le test du mig publié par SVM et posté par Ryosaeba : 

https://www.gamopat-forum.com/t82265p16-amiga-topic-officiel

On y explique que 2 programmes basic lancés en même temps prennent moins de temps que lancés l'un après l'autre (et on nous explique le contraire ici depuis plusieurs années). 
Comment est-ce possible ? Et bien, quand un copro est utilisé, le 68000, plutot que d'attendre sagement qu'il ait terminé, va travailler sur une autre tache. 
Par exemple, le programme 1 doit afficher quelque chose, comme un simple texte. Il demande donc à l'OS de s'en occuper. L'OS va utiliser le blitter pour cela et, plutot que de laisser le 68000 attendre betement que le blitter ait terminé son travail, il va l'envoyer s'occuper du programme 2. 
S'il n'y a qu'un programme qui tourne, l'OS sera obligé de laisser le 68000 attendre. 
C'est, je pense, ce que veut dire dlfrsilver quand il parle d'architecture pensée pour le multitache. 

Note que l'exemple de SVM est fait sur un Amiga 1000 avec 256 Ko et un Kickstart 1.1 maximum. 
Etrange qu'ils n'aient pas signalé de Guru. 
Etrange de voir qu'il leur était possible de faire du multitache en lançant 2 interpréteurs BASIC (ça prend quand même de la place...) sur une machine de 256 Ko et un lecteur de disquette... Il parait que c'est impossible sur un A500 qui dispose de 512 Ko...

[dlfrsilver]

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

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

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

Alors, il y a plusieurs cas : si on restreint l'amiga à de la chip ram uniquement, je pense que la bande passante du ST est un peu plus élevée.
Mais si on met une extension mémoire dans le mig, c'est une autre paire de manches : le fait que son accès ne soit pas entrelacé permet de multiplier par 2 le débit. 
Et tu noteras que les controleur SCSI du mig comportaient une extension mémoire (comme ton impact GVP). 
Et là le ST se fait exploser. Même si on est un bricoleur et que l'on met une extension mémoire dedans, ça ne changera rien. 

Et ce n'est pas le pire : si on prenait les cartes accéleratrices, la RAM passe en 32 bits (ce qui double encore la bande passante) et est plus rapide. La bande passante du mig devient facilement 5 fois plus rapide que celle du ST (voire encore bien plus avec les RAM les plus chères) 
Mais un HD qui pouvait suivre la moitié, voire le quart, d'un tel débit d'existait pas. L'interet était que le processeur pouvait accéder à la RAM en même temps que le controleur SCSI sans le ralentir.

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

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

es-tu en train de dire que : 

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

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

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

Non, ce n'est pas aussi catastrophique que ça. 

Si le ST se fait larguer par le mig, ce n'est pas parce qu'il est mauvais : c'est parce que le mig est vraiment bon  

D'ailleurs, à cette époque là, si on comparait les performance du ST avec celle d'un mac ou d'un PC, il l'emportait haut la main... 

Pour l'histoire de l'aiguillage qui ne bascule que tous les 2 cycles : ce n'est pas aussi grave qu'il n'y parait. 

Je vais détailler pour que ce soit compréhensible. Et certains verront que je ne suis pas de mauvaise fois... 

Si je fait la séquence d'attribution des cycles version ST, voilà ce que ça donne 

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

Le découpage se fait tous les 2 cycles. Et on voit que pour le shifter ça ne change rien puisqu'il exploite les 2 cycles qui se suivent quand "l'aiguillage" est de son coté. 

Qu'en est-il du 68000 ? Supposons qu'il doit executer une instruction qu'il lit pendant le cycle 3. 
Quand il aura terminé, 2 types de cas pourront se présenter, en fonction de la durée de l'instruction : 
        - l'instruction dure 4,8,12,16,etc... cycles : il tombe sur le cycle n° 7,11,15,19,etc... : Donc il peut immédiatement lire l'instruction suivante. Aucun problème 
        - l'instruction dure 6,10,14,18, etc... cycles : il tombe sur le cycle n° 9,13,17,21,etc... : Problème : l'aiguillage est du mauvais coté ! La mémoire est donc inaccessible. le 68000 doit attendre 2 cycles avant que l'aiguillage se repositionne de son coté. 
C'est ce que j'expliquais à certains Stistes qui ne voulaient pas l'admettre : Sur un ST, la durée des instructions est toujours arrondie au multiple de 4 supérieur. 

Mais, comme je le disais dans mon post, ce n'est pas si grave : la majorité des instructions prennent déjà un multiple de 4. 
Celles qui ne sont pas dans ce cas, sont en général celles qui travaillent en 32 bits avec des registres. Parce que le passage de 16 à 32  bits consomme 2 cycles en plus. Par exemple : 
        - cmp : comparaison entre 2 registres. 4 cycles en 16 bits, 6 cycles en 32 bits. 
        - sub : soustraction entre 2 registres. 4 cycles en 16 bits, 6 cycles en 32 bits. 
        - clr : nettoyage d'un registre. 4 cycles en 16 bits, 6 cycles en 32 bits. 
Il y a aussi les décalages et rotations : chaque niveau de décalage coute 2 cycles de plus. Donc, en fonction, du nombre de bits à décaler, on peut tomber sur un multiple de 4 ou non 
(exemple : lsl.w #3,D0 -> 12 cycles, lsl.w #4,D0 -> 14 cycles.) 
Il y a aussi celles pour lesquelles ça ne change pas grand chose : une multiplication signée prend 70 cycles. Une division signée en prend 158. 2 cycles de plus à ce niveau là, ce n'est pas grand chose... 
On en trouve d'autres, comme les calculs d'adresse qui ajoute un offset sur 8 bits, les move avec une pré-décrémentation du registre source, etc... 

Une autre question se pose : c'est bien beau de parler de la durée des instructions. Mais une instruction peut être amenée à faire un ou plusieurs accès mémoires pendant son exécution. Elle pourrait donc être ralentie. Par exemple, l'instruction Move.l (A0),(A1) fait 5 les accès mémoires suivants : 
        - Lecture de l'instruction. 
        - Lecture des 16 premiers bits depuis l'adresse pointés par A0. 
        - lecture des 16 bits suivants. 
        - Ecriture des 16 premiers bits dans l'adresse pointée par A1. 
        - Ecriture des 16 bits suivants. 
        
Que va-t-il donc se passer dans le ST ? Et bien il n'y aura aucun problème ! Et oui : le 68000 met toujours 4 cycles entre 2 accès mémoires. Cette instruction prendra 20 cycles : il n'y aura aucune perte. 

Alors évidemment, il est facile d'écrire un code qui perdrait un gros pourcentage de cycles et qui tounerait bien plus vite sur le mig que sur le ST. Mais, dans la pratique, ça n'arrivait pas. La perte réelle est difficile à estimer. Mais elle doit être minime. 

Si le mig garde si souvent l'avantage, c'est grace à son architecture, ses copros et son OS. Ce n'est pas que pour une raison unique.

Donc comme je le disais : ce n'est pas du tout aussi grave qu'il n'y parait.

En tout cas sur un ST de base... Et oui : essayons de bricoler un peu pour mettre un 68000 à 16 Mhz dans le ST. Que ce passe-t-il ? Et bien ça se comportera exactement comme un 68000 à 8 Mhz dans lequel toutes les instructions prendraient 2 fois moins de cycles pour s'executer. Une instruction qui prenait 4 cycles en prendra donc 2. Mais le 68000 devra en attendre 2 de plus pour pouvoir accéder à la RAM. Donc il en prendra 4. Aucun gain ! De même l'instruction détaillée ci-dessus devra attendre 2 cycles entre chaque accès mémoire. Ce qui implique qu'au final, un Move.l (A0),(A1) prendra exactement le même temps que le 68000 soit à 8 ou 16 Mhz. Et c'est le cas avec la majorité des instructions ! 
C'est pourquoi, dans son MegaSTE, Atari a été obligé de mettre une mémoire cache de 16 Ko pour que les 16 Mhz puisse apporter un gain (qui ne sera jamais de 200%...). 
Dans un mig, sans aucun cache, cette instruction pourrait faire ses accès mémoire tous les 2 cycles et en prendrait 10 au total. Elle irait réellement 2 fois plus vite. Sans être obligée de mettre un cache (qui augmentait le cout...). Evidemment, avec des processeurs plus rapide, comme un 68030 à 50 Mhz, la mémoire n'est plus du tout en mesure de suivre. Mais l'architecture du mig gère la fastram. Et le problème est réglé. C'est pourquoi toutes les cartes accélératrices du mig en embarquait. 

Le ST a une architecture non évolutive. Le mig est pensé dès le départ pour pouvoir évoluer. 

Tu glisses une carte accéleratrice sur le coté d'un A500. Aucun démontage, aucune soudure et hop : tu peux jouer à DOOM de façon fluide. 
Et l'A500 est le moins évolutif des Amiga...

Merci pour ces informations :)

Le mec en question Petari, est bien connu de la scène ST. un des arguments qu'il m'a opposé aussi, c'est le prix du disque dur en question. mort de rire. Sauf que le Megafile 30 SH305 que je possédais coutait 4990 francs à l'époque de sa sortie, et était bien plus lent que le GVP II, vraiment très clair.

Ensuite, l'autre argument qu'il a posé, c'était que le ST a de base une bande passant côté RAM plus grande que celle de l'amiga.

C'est comme L'histoire de Vroom, ou ils soutiennent mordicus que le ST est plus rapide, alors qu'en ayant comparé les deux, on voit bien que c'est pas le cas (pas de beaucoup, mais c'est visible).

A l'inverse, et ça par contre il est pas venu me contrer sur ce point là, c'est que le GVP II est tellement rapide, qu'il y a contention avec le lecteur de l'amiga, qui lui pour le cas ne suit pas la cadence.

J'ai installé indiana jones 4 aventure sur le GVP II, et c'est la misère, le disque dur se retrouve mis en attente, car il copie les données plus vite que le lecteur de disquette n'arrive à les lire depuis les disquettes originales

C'est un phénomène que je n'ai jamais vu même sur mon A1200 qui est pourtant équipé d'un 68030 qui tourne à 50 mhz et d'un workbench 3.5 ;

Par ailleurs, la chip et la fast se retrouvent mélangées quand je regarde sous le workbench 1.3 qui est installé.

[stapha92]

Pour le débat sur le multitache en général. 

Rocky a raison : on peut faire du multitache avec toutes les machines (ou presque...). 
Maintenant quand il dit que ce n'était pas une révolution sur le mig et qu'il parle du multitache sur 800XL, faut juste mentionner que en 2015, ça n'existe toujours pas. 
Sur le mig c'était dispo il y a 30 ans (bon dans ce cas précis, je dirai qu'il fait de l'humour en nous faisant découvrir un truc interessant sur une autre machine). 
Il y a aussi SymbOS : OS multitache préemptif dédié au Z80... Et sorti 20 ans après l'AmigaOS... 



Si un OS multitache sur un Z80 avec 128 Ko est possible, cela ne signifie-t-il pas que la même chose sur un 68000 et 512 Ko est exploitable ? 

Par contre, je suis d'accord avec le fait que le ST aurait pu avoir un OS multitache dès le début. Rien dans son architecture l'en empeche. 
Je dirai même plus : vu la machine que c'est, il aurait mérité d'avoir mieux que ce TOS qui n'est qu'un cp/m cuisiné à la sauce 16 bits en vitesse. 

Franchement, quand on voit ça sur C64 : 



Quoi !!! Des noms longs ! Des icones personnalisés et en couleur ! C'est dingue : le GEM est incapable de faire quelque chose que faisait un OS sur 8 bits alors qu'ils étaient contemporains... Oui oui ! Je ne parle pas d'un OS sorti sur C64 20 ans après ! 


Alors, le multitache est-il possible sur toutes les machines ? 

Pour répondre, étudions le fonctionnement : 

Lorsqu'un programme fonctionne, il mémorise tout un tas de valeurs dans les registres processeurs. Donc lorsque l'OS va l'interrompre pour basculer sur une autre tache, il faudra qu'il sauvegarde tous ces registres afin de les restaurer quand il va rendre la main à cette tache. Mais il y également d'autres registres qui ne sont pas utilisés pour stocker des valeurs mais certaines infos nécessaires au fonctionnement du processeur. Par exemple les bits d'états, ou le PC (qui contient l'adresse de l'instruction en cours). 
Voilà donc la première condition pour faire du multitache : 
        - Le processeur doit permettre la sauvegarde/restauration de TOUS ses registres. 
Le nombre de registres n'étant pas illimité, un programme va également stocker des valeurs en mémoire. Il peut le faire en se réservant une zone mémoire dans laquelle il va stocker ces valeurs. Cela ne pose aucun problème dans un OS multitache : chaque programme aura réservée sa propre zone. Mais il peut le faire également en utilisant ce que l'on appelle une pile (parfois c'est obligatoire car il y a des processeurs qui ne peuvent faire certaines opérations que sur les valeurs stockées dans la pile). Il s'agit d'une zone mémoire dans laquelle on stocke des valeurs "l'une sur l'autre". D'ou le terme de pile : c'est comme une pile d'assiette. On peut toujours accéder à la dernière assiette ajoutée (les autres aussi mais pas aussi facilement...). Lire la derniere valeur de la pile revient à retirer l'assiette du haut. Ecrire une valeur dans cette pile revient à ajouter une assiette. 
Donc un OS multitache devra également sauvegarder le contenu de la pile du programme qu'il doit interrompre (et la restaurer quand il lui rend la main). C'est là que les problèmes commencent : Sauvegarder les registres processeurs va vite, car il n'y en a pas beaucoup. Les piles sont beaucoup plus grandes : si l'os doit vraiment faire ça de cette façon, le basculement d'une tache à l'autre va prendre beaucoup de temps et on va se retrouver avec un os qui tourne au ralenti... 
Comment faire ? Et bien c'est simple : au lieu de sauver/restaurer la pile, on va la mettre à un endroit différent pour chaque processe en cours d'exécution. Le programme 1 utilisera une pile située à l'adresse X, le programme 2 utilisera une pile située à l'adresse Y, etc... 
Comment implémenter ça ? 
Avec un Z80, la position de la pile est stockée dans un registre 16 bits (SP = Stack Pointer). Chaque programme pourra se voir allouer une zone mémoire différente pour sa pile au moment de son lancement. L'OS s'en occupera. Tout comme il s'occupera de mettre cette adresse dans le registre SP avant de donner la main au programme à lancer. Il va reserver une certaine taille. Comme il ne sait pas de quel taille le programme à lancer a besoin, il peut le faire de façon arbitraire ou en fonction d'un paramètre associé à un programme à lancer. C'est pourquoi on parle parfois de taille de pile sur des OS comme UNIX : il s'agit de cette fameuse zone. 
Avec un 68000, c'est pareil. A la différence que l'adresse qui est stockée est sur 32 bits. 
Grace à ça, le simple fait de stocker/restaurer tous les registres processeur va permettre de gérer une pile différente pour chaque process. 
Et le 6502 ? Et bien il pose un problème : le registre de pile ne contient qu'un octet. Or les adresse du 6502, comme celles du Z80, sont stockées sur 16 bits, soit 2 octets. Comment fait-il ? C'est simple : le 6502 considère toujours que le premier octet de l'adresse de la pile vaut 1. Cela revient à dire que pour avoir l'adresse réelle de la pile, il faut toujours ajouter la valeur 256 à celle qui est stockée. Donc la pile d'un 6502 sera toujours située entre les adresse 256 et 511 pour des valeurs de son registre qui iront de 0 à 255. 
Du coup, il n'y a aucun moyen de forcer le 6502 à stocker sa pile ailleurs. 

En résumé, la pile d'un Z80 ou d'un 68000 est relocalisable. Pas celle du 6502. 
Donc, pour faire du multitache avec le 6502, il faudra sauver/restaurer 256 octets (1024 accès mémoire...) à chaque basculement de tache. Ce qui va donner un os qui rame. Le seul moyen de s'en sortir est d'utiliser un système de banque mémoire. Mais il faut un hardware dédié. 
C'est pourquoi SymbOS existe pour les ordinateurs à base de Z80 depuis 2006 alors que l'atari800 attend toujours... 

Donc à la question "peut-on faire du multitache avec n'importe quel ordinateurs?" : la réponse est "oui si son processeur permet la sauvegarde/restauration de tous ses registres". 
Et à la question "peut-on faire du multitache de façon exploitable avec n'importe quel ordinateurs ?" : la réponse est "oui si, en plus, son processeur possède une pile relocalisable".

Donc, au final, ça ne dépend que du processeur.

[rocky007]

Tu comprends maintenant pourquoi j'ai jamais pu faire l'import d'un fichier texte ? Parce que je n'aurais jamais pensé une seule seconde que la commande Fusionner servait à ça dans l'éditeur GFA.

ça évidemment comme tu es un habitué du GFA, ça te passe au dessus de la tête, mais moi qui cherche d'abord et toujours à maitriser l'interface du soft avant de m'en servir, forcément ça me saute au yeux.

C'est absolument pas intuitif dans le principe.

Il suffit de lire le mode d'emploi, pour un langage de programmation ca peut être utile
mais bon si tu préfères reprocher au programme plutôt que te prendre en main...

[stapha92]

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

Sur le principe, Rocky a raison : dans un OS monotache, le risque de bug est moins 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... 

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. 

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

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 ! 

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

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

[dlfrsilver]

Tu comprends maintenant pourquoi j'ai jamais pu faire l'import d'un fichier texte ? Parce que je n'aurais jamais pensé une seule seconde que la commande Fusionner servait à ça dans l'éditeur GFA.

ça évidemment comme tu es un habitué du GFA, ça te passe au dessus de la tête, mais moi qui cherche d'abord et toujours à maitriser l'interface du soft avant de m'en servir, forcément ça me saute au yeux.

C'est absolument pas intuitif dans le principe.

Il suffit de lire le mode d'emploi, pour un langage de programmation ca peut être utile
mais bon si tu préfères reprocher au programme plutôt que te prendre en main...

Je raisonne de façon logique et pratique :

pour charger je cherche la commande load, pour sauver save, pour éditer, edit, pour annuler cancel, etc etc.

Le manuel ne sert qu'à approfondir les possibilités quand on connait le logiciel, qu'on aimerait faire quelque chose, qui est faisable et qu'on ne trouve pas à l'utilisation, le manuel est là pour guider.

Comment j'aurais pu savoir qu'ils avaient codé la fonction d'importer sur la commande de fusionnement ? C'est pas du tout logique, les 2 processus n'ont rien à voir.

C'est comme si dans une voiture pour changer une roue, il fallait en premier lieu dégonfler les pneus. Qui par logiquement irait regarder dans le manuel automobile la rubrique "dégonfler les pneus" pour découvrir dans le texte que ça permet de changer les roues ? 

Fusion et import n'ont pas du tout le même sens. Je ne vois pas comment j'aurais pu le deviner.

[rocky007]

En tous cas tu ne te prives pas pour en conclure que c'est a cause de cela que le GFA a été abandonne : pour une fonction présente que tu n'as pas trouvé !

[dlfrsilver]

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

[Seb]

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.

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

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.

[babsimov]

Babsimov, 

Pour ta question sur le 800XL : 

Tout d'abord, expliquer que le mig est une évolution du XL est une erreur. C'est la preuve d'une méconnaissance de l'architecture des 2 machines. 
La seule ressemblance se résume au sprites. Et encore : ceux du mig sont plus proches de ceux d'un C64... 
Idem pour l'affichage : la gestion et la génération des pixels d'un mig est bien plus proche de celle d'un amstrad que d'un XL ou d'un C64 (pas de chunky, pas de mode caractère, utilisation d'intensité RGB et non de valeurs chromatique prédéfinies, etc...) 
Quand à ceux qui expliquent que le copper est une évolution des displaylist. Ben je leur dirai d'arreter de piocher des affirmations sur internet et d'étudier le fonctionnement et la raison d'être des 2 systèmes... 
Cela dit, cela ne ne m'aurait pas dérangé que ce soit le cas : j'adore le 800XL qui était mon premier micro. Une bien belle machine qui, bien que dotée d'un technologie datée de 1979 parvenait à tenir la route face à des concurrents sortis bien après. 
Son principal défaut est la difficulté à tirer profit de toutes ses capacités. Mais, quand un codeur y parvient, cela peut donner des résultats impressionnants : 





 

Pas mal pour une techno de 1979... 

Tout d'abord, merci Stapha92 pour ta réponse, qui comme à l'accoutumée est très claire et pleines d'informations intéressantes.

Ces trois vidéo sont, effectivement, impressionnantes quant on pense que c'est de 1979. 
C'était bien ce que j'avais déduis de mes lectures de forum 800XL VS C64. Le 800 XL, bien programmé, pouvait en remontrer au C64 (plus récent). Rien que ce fait démontre que Jay Miner était un très bon ingénieur et concepteur d'ordinateur. Il a toujours cherché à proposer des machines innovantes avec la technologie la plus avancée possible à l'époque de leur conception, de façon à ce qu'elle reste quelques années à la pointe.

Revenons-en à ta question : 
Il est construit autour d'un 6502 : il s'agit d'un processeur capable d'accéder à la mémoire à chacun de ses cycles. Donc pas moyen d'utiliser un entrelacement systématique de la RAM. Chaque fois que le circuit graphique a besoin d'accéder à la RAM, le 6502 subit une latence. 
Heureusement, seul ANTIC a besoin de faire ça et ce dernier dispose d'un buffer : ça lui permet de gérer efficacement les modes caractères et lui évite de refaire un accès à la RAM quand une ligne est dédoublée (c'est à dire quand la résolution verticale est divisée par 2). 

Dans un post au-dessus, ou Rocky commence par "BIM !", on nous explique qu'il y a 4 circuit qui fonctionnent simultanément. C'est faux. (Mais j'ai comme l'impression que c'est volontaire et que c'est fait uniquement pour parler du 800XL, ce à quoi je ne peux que souscrire !  )
Pokey est le circuit sonore : il ne peut fonctionner que si le 6502 le pilote, comme le SID du C64 ou le YM des ST/CPC. Il n'est pas autonome. 
GTIA (ou CTIA) est le circuit qui génère l'affichage. Mais il ne lit pas les données dans la RAM : il est alimenté par ANTIC qui interprète ces dernières et envoit les données à afficher à GTIA. ANTIC a été ajouté à l'architecture de l'Atari 2600 justement pour ça. 
Donc comme je le disais, seul ANTIC a besoin d'accéder à la RAM (peut-être une exception pour les sprites, je ne sais plus). 

Quoi qu'il en soit, ces circuits ne sont pas des coprocesseurs et ne déchargent pas le 6502, contrairement aux copros du mig.

Cette précision est importante, car, pour un non connaisseur comme moi, sur le papier, POKEY, GTIA et ANTIC ressemblait au principe des 3 copros de l'Amiga. Je comprend aisément qu'on puisse se tromper sur ce point. Ton explication sur la différence d'architecture entre le 800XL et l'Amiga devrait lever cet argument récurent. 
L'Amiga est donc bien une nouvelle architecture bien démarquée de la génération des Atari 8 bit (qui n'en demeurent pas moins bien conçus eux aussi, il suffit de voir les vidéo).

A propos, tu dis que pour tirer partit des capacités du 800 XL c'est assez difficile au niveau programmation. Dirais tu que c'est plus facile sur l'Amiga en comparaison, ou que le niveau de programmation nécessaire pour tirer au mieux parti de l'Amiga est similaire à celui du 800 XL ? 

Lis le test du mig publié par SVM et posté par Ryosaeba : 

https://www.gamopat-forum.com/t82265p16-amiga-topic-officiel

On y explique que 2 programmes basic lancés en même temps prennent moins de temps que lancés l'un après l'autre (et on nous explique le contraire ici depuis plusieurs années). 
Comment est-ce possible ? Et bien, quand un copro est utilisé, le 68000, plutot que d'attendre sagement qu'il ait terminé, va travailler sur une autre tache. 
Par exemple, le programme 1 doit afficher quelque chose, comme un simple texte. Il demande donc à l'OS de s'en occuper. L'OS va utiliser le blitter pour cela et, plutot que de laisser le 68000 attendre betement que le blitter ait terminé son travail, il va l'envoyer s'occuper du programme 2. 
S'il n'y a qu'un programme qui tourne, l'OS sera obligé de laisser le 68000 attendre. 
C'est, je pense, ce que veut dire dlfrsilver quand il parle d'architecture pensée pour le multitache. 

Note que l'exemple de SVM est fait sur un Amiga 1000 avec 256 Ko et un Kickstart 1.1 maximum. 
Etrange qu'ils n'aient pas signalé de Guru. 
Etrange de voir qu'il leur était possible de faire du multitache en lançant 2 interpréteurs BASIC (ça prend quand même de la place...) sur une machine de 256 Ko et un lecteur de disquette... Il parait que c'est impossible sur un A500 qui dispose de 512 Ko...

L'article de SVM est très intéressant, je n'ai pas encore tout lu, il est relativement long, mais je le lirais.

Une fois de plus tes explications concernant le test du multitâche de l'article sont des plus intéressantes. Personnellement, comme tu le sais, je suis tout à fait convaincu de la possibilité du multitâche sur un Amiga 500 avec 512 KO :)

stapha92

Pour le débat sur le multitache en général. 

Rocky a raison : on peut faire du multitache avec toutes les machines (ou presque...).

Je ne pense pas avoir prétendu autre chose.

Maintenant quand il dit que ce n'était pas une révolution sur le mig et qu'il parle du multitache sur 800XL, faut juste mentionner que en 2015, ça n'existe toujours pas. 
Sur le mig c'était dispo il y a 30 ans (bon dans ce cas précis, je dirai qu'il fait de l'humour en nous faisant découvrir un truc interessant sur une autre machine).

Oui, Rocky007 est un habitué de "l'humour" :)

Il y a aussi SymbOS : OS multitache préemptif dédié au Z80... Et sorti 20 ans après l'AmigaOS... 



Si un OS multitache sur un Z80 avec 128 Ko est possible, cela ne signifie-t-il pas que la même chose sur un 68000 et 512 Ko est exploitable ?

Belle prouesse sur le Z80 et 128 Ko. Je suis d'accord avec toi pour le 68000 et 512 Ko, mais je suis aussi certain que Rocky007 faire va preuve de son "humour" coutumier pour te contredire :)

Par contre, je suis d'accord avec le fait que le ST aurait pu avoir un OS multitache dès le début. Rien dans son architecture l'en empeche. 
Je dirai même plus : vu la machine que c'est, il aurait mérité d'avoir mieux que ce TOS qui n'est qu'un cp/m cuisiné à la sauce 16 bits en vitesse.

C'est bien pour ça qu'en arrivant ici, j'avais posé la question au sujet d'OS/9. Je m'étonnait qu'Atari n'ait pas envisagé de l'utiliser, puisqu'il existait une version 68000 déjà. Je m'interrogeais sur le choix du TOS (cp/m) et GEM. Il y a quelques pages, je ne sais plus qui a donné un lien vers un article sur la genèse du ST. De mémoire, ils avaient envisagé MS-DOS et Windows, puis comme ça demandait trop de temps, ils se sont orientés vers une version spéciale du CP/M et de GEM. Ils ne semblent pas avoir envisagé autre chose. C'est bien dommage.

Franchement, quand on voit ça sur C64 : 



Quoi !!! Des noms longs ! Des icones personnalisés et en couleur ! C'est dingue : le GEM est incapable de faire quelque chose que faisait un OS sur 8 bits alors qu'ils étaient contemporains... Oui oui ! Je ne parle pas d'un OS sorti sur C64 20 ans après !

Si tu te rappel de certaines de mes réponses à travers le sujet, tu sais tout le bien que je pense de GEOS (sur PC, je n'ai pas connu la version C64). GEOS sur PC était multitache et ça fonctionnait aussi bien que sur AmigaOS. 
Je crois avoir lu que GEOS C64 était seulement monotache (ton explication sur le 6502 et le multitache va dans ce sens), mais c'est vrai que ça parait mieux que le GEM. J'ai lu que GEOS était entièrement écrit en assembleur.

Donc à la question "peut-on faire du multitache avec n'importe quel ordinateurs?" : la réponse est "oui si son processeur permet la sauvegarde/restauration de tous ses registres". 
Et à la question "peut-on faire du multitache de façon exploitable avec n'importe quel ordinateurs ?" : la réponse est "oui si, en plus, son processeur possède une pile relocalisable".

Ton explication du fonctionnement du multitâche est tout à fait claire, merci. 
Le processeur était donc primordial. A une époque j'avais posé la question dans un autre sujet, pourquoi Commodore n'avait remplacé le 68000 de l'Amiga par un 65816 (ce qui aurait donné la compatibilité C64), je comprends maintenant que c'était une question "idiote". Pas de multitâche sur un 6502 et surement sur ses évolutions.

Merci à nouveau pour tes réponses toujours aussi instructives.

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