Re: GUERRE ST-AMIGA, FIGHT ! (Mauvaise foi assurée)

par dlfrsilver Dim 31 Déc 2023 - 13:05

touko a écrit:
youki a écrit:
touko a écrit:
Apres si toi tu parles du code généré par le compilateur, oui
En même temps c'était un peu le but du post de silver au passage,de dire que le jeu était pourri car codé en C

C'est pas le langage qui fait le jeu est pourri ou pas.
Oh que si, le langage y joue bcp, surtout en 93/96 sur des machines qui sont sensées être exclusivement codées en ASM pour des raisons de perfs, et de place mémoire .
Le C à cette époque pouvait suffire pour des jeux statiques style des points & click, mais pas plus .Même aujourd'hui c'est tendu, les compilos ont fait bcp de progrès sur les vieilles archis comme le 68000, mais ça reste encore pas génial et loin d'être aussi bon que de l'ASM .
Sur Md il faut bien connaitre le compilo pour savoir comment bien coder en C pour que le code généré soit le mieux possible, mais à la différence de 93, c'est que GCC a bcp évolué et dans l'ensemble il génère du code pas mal du tout et permet de code des jeux d'action de manière plutôt efficace dans l'ensemble .

Ah oui quand même ! Je pensais que c'était uniquement lié à la qualité du code craché par le compilo.
Donc ça veut dire que même en ayant le source de Space Quest IV et en recompilant avec un compilo moderne, ça puerait encore la merde comme à l'époque..... ohnon

par Yoyost Dim 31 Déc 2023 - 13:07

Moi ce qui m'épate, c'est qu'aucune autorité n'est venu vérifié ce qu'ils faisaient. Commodore n'a pas coulé parce que l'argent rentrait pas, Commodore a coulé parce que le management s'est servi dans la caisse.

C'est peut être parce qu'il n'y avait pas matière à enquêter. Ca doit juste être un fantasme complotiste de plus pour se voiler la face et ne pas voir que ces machines avaient fait leur temps et étaient complètement à la ramasse après 1993.

par **youki** Dim 31 Déc 2023 - 13:09

dlrfSilver a écrit: Commodore n'a pas coulé parce que l'argent rentrait pas

Si, c'est le cas. Commodore a coulé parce que les ventes de ses machines se sont écroulé. Et ca a commencé en 1991.

par touko Dim 31 Déc 2023 - 13:09

Donc ça veut dire que même en ayant le source de Space Quest IV et en recompilant avec un compilo moderne, ça puerait encore la merde comme à l'époque....

Non les compilos sont bien meilleurs aujourd'hui qu'à l'époque, et le code généré par gcc serait largement au dessus de celui de 93 .
C'est juste que le 68000 n'a pas forcément la même attention que les autres CPu plus modernes, et gcc n'est pas optimal sur tout .

par **youki** Dim 31 Déc 2023 - 13:23

touko a écrit:
youki a écrit:
touko a écrit:
Apres si toi tu parles du code généré par le compilateur, oui
En même temps c'était un peu le but du post de silver au passage,de dire que le jeu était pourri car codé en C

C'est pas le langage qui fait le jeu est pourri ou pas.
Oh que si, le langage y joue bcp, surtout en 93/96 sur des machines qui sont sensées être exclusivement codées en ASM pour des raisons de perfs, et de place mémoire .
Le C à cette époque pouvait suffire pour des jeux statiques style des points & click, mais pas plus .Même aujourd'hui c'est tendu, les compilos ont fait bcp de progrès sur les vieilles archis comme le 68000, mais ça reste encore pas génial et loin d'être aussi bon que de l'ASM .
Sur Md il faut bien connaitre le compilo pour savoir comment bien coder en C pour que le code généré soit le mieux possible, mais à la différence de 93, c'est que GCC a bcp évolué et dans l'ensemble il génère du code pas mal du tout et permet de code des jeux d'action de manière plutôt efficace dans l'ensemble .

tu peux faire du tres bon code en C et du tres mauvais en assembleur.

Les premiers jeux colecovision etait codé en Pascal , les jeux NEO GEO sont en grand partie en C.

Si tu es très bon bien sur tu pourra toujours faire un code plus rapide en assembleur qu'en C . Mais au final, tu aura un code non portable et c'est une aberration de faire ca si tu as un business derrière.

Ils vaut mieux programmer en C 80 à 90% de ton jeu , et n'optimiser que quelques routines critiques ou spécifiques en assembleur.

ù

par Jacques Atari Dim 31 Déc 2023 - 13:33

On a les révisionnistes qui proclament que les chambres à gaz n'ont jamais existé.
On a les platistes qui nous affirment que la Terre est plate.
On a désormais les amigaïstes, qui nous disent que Commodore a fermé boutique pas parce que la boîte était ruinée mais parce que... Bah, c'est comme ça. Les caisses étaient pleines et tout, mais euh, enfin... C'est marqué dans le livre de Gunhed, voilà!

ohnon

par dlfrsilver Dim 31 Déc 2023 - 13:37

youki a écrit:
dlrfSilver a écrit:Oui quand on parle de code pourri craché par les compilateurs de l'époque, le cas de la routine de gestion de la souris qui fait 25 instructions en C contre 3 en assembleur, c'est un cas d'école.

Si c'est un cas d'école ok, montre moi l'exemple. Je trouve ca intéressant techniquement.

surtout la routine de "gestion de la souris" en 3 lignes d'assembleur... je me demande bien ce que tu appelles "gestion de la souris"... si c'est juste récupérer les coordonnées X et Y de la souris , j'appelle pas ca une "Gestion" de la souris.

Un exemple qui me vient tout de suite à l'esprit, c'est le jeu innocent until caught de Psygnosis. La routine de gestion de la souris est l'exemple même de ce que je dis. Le jeu est codé en C pour PC à l'origine, et ils l'ont adaptée toujours en C pour l'Amiga. Ce qui est délirant, c'est qu'en dehors de la gestion de souris faite en code C, tout le jeu est 100% en assembleur !.

La gestion de la souris, en assembleur pour detecter la pression du bouton gauche c'est 3 instructions.
J'avais posé la question à Bertrand Jardel (CFOU!), mon acolyte de toujours, pour la lenteur des jeux en C, et il m'avait dit que c'était du aux routines C non optimisées et surgonflées présentes dans les jeux. D'ou dans certains cas quand c'est possible de recoder complètement la routine de gestion de la souris en assembleur.

La routine de gestion de la souris gère les coordonnées et la pression bouton gauche/droit, et le pointeur sur Amiga est géré sous forme de sprite hardware, c'est le plus simple, et ça coute 0 cycles CPU.

par touko Dim 31 Déc 2023 - 13:39

tu peux faire du tres bon code en C et du tres mauvais en assembleur.

Tu généralises à aujourd'hui où la diff entre assembleur et langages haut niveau est pas énorme, mais à cette époque sur des machines pas faites pour les langages haut niveau un mauvais code ASM sera presque toujours meilleurs que du code C, même bon car le compilo lui va faire de la merde .

Alors à moins que le codeur asm soit particulièrement mauvais .

Ils vaut mieux programmer en C 80 à 90% de ton jeu , et n'optimiser que quelques routines critiques ou spécifiques en assembleur.

Tout dépend de la période et de la machine cible, aujourd'hui oui, mais avant non, et puis pas tous les compilo te permettaient facilement de mettre de l'assembleur en ligne dans le code C .
Je pense que ce genre de pratique s'est démocratisée avec la gen 32 bits .

par dlfrsilver Dim 31 Déc 2023 - 13:51

youki a écrit:tu peux faire du tres bon code en C et du tres mauvais en assembleur.

Oui, du très bon code C, en 2023 je suis d'accord. Tinyus en est la preuve.

Les premiers jeux colecovision etait codé en Pascal , les jeux NEO GEO sont en grand partie en C.

Pour les jeux Colecovision je sais pas et je me fous, par contre, dire que les jeux NEO GEO sont codés en C, tu te plante complètement ! Ces jeux là sont entièrement codés en assembleur. Seul l'ossature des programmes NEO GEO est en C (avec les mentions XREF, etc). Toutes les routines d'animations, l'IA, la détection des collisions, les hitboxes, le driver pour les musiques, tout est en ASM 68000 ! Le programme final est compilé et le linker rassemble tout les binaires composant le programme sous forme de code objet en un programme binaire unique. Mais la partie C c'est 5% du code source. Va jeter un oeil sur le code source d'Art of Fighting !

Si tu es très bon bien sur tu pourra toujours faire un code plus rapide en assembleur qu'en C . Mais au final, tu aura un code non portable et c'est une aberration de faire ca si tu as un business derrière.

Alors ça je suis en partie d'accord avec toi. C'est vrai uniquement si le code assembleur n'est pas commenté.
Par exemple, je citais Art of Fighting, le code source Assembleur du jeu est entièrement commenté. Le programmeur Japonais a décrit très proprement chaque routine, bout de programme assembleur.

Si tu as un business, le mec qui code doit avoir l'obligation de commenter son code, quoi qu'il arrive.
Par exemple, mon beau-père a connu ça quand il codait le micro-logiciel embarqué dans des calculateurs de bagnoles (ex: BX de citroën) ou pour PSA. Il était tombé sur un ingé qui codait en ASM sans commenter son code, et ça avait été une galère pour comprendre le code afin de le repasser en code C. Et il m'expliquait aussi que c'était pas toujours simple car c'était serré en terme de cycles et que le C était parfois trop lent.

Ils vaut mieux programmer en C 80 à 90% de ton jeu , et n'optimiser que quelques routines critiques ou spécifiques en assembleur.

Valable uniquement aujourd'hui. A l'époque, même correctement programmé en C, les compilateurs crachaient un code pourri et lent. L'assembleur était la seule issue pour avoir un programm véloce.

par dlfrsilver Dim 31 Déc 2023 - 13:53

touko a écrit:
tu peux faire du tres bon code en C et du tres mauvais en assembleur.
Tu généralises à aujourd'hui où la diff entre assembleur et langages haut niveau est pas énorme, mais à cette époque sur des machines pas faites pour les langages haut niveau un mauvais code ASM sera presque toujours meilleurs que du code C, même bon car le compilo lui va faire de la merde .

Alors à moins que le codeur asm soit particulièrement mauvais .

Ils vaut mieux programmer en C 80 à 90% de ton jeu , et n'optimiser que quelques routines critiques ou spécifiques en assembleur.
Tout dépend de la période et de la machine cible, aujourd'hui oui, mais avant non, et puis pas tous les compilo te permettaient facilement de mettre de l'assembleur en ligne dans le code C .
Je pense que ce genre de pratique s'est démocratisée avec la gen 32 bits .

200% d'accord. Tout ceux qui programment le disent et le savent de toute façon.

par touko Dim 31 Déc 2023 - 13:55

les jeux NEO GEO sont en grand partie en C.

Il y a une partie du code source de AOF NG dans le CDrom pce, et je peux te garantir que c'est de l'ASM .
D'ailleurs le code source PCE en partie présent aussi, ne laisse aucun doute à ce sujet .

Alors c'est possible qu'il y ait des jeux codés en C, mais je pense que la grande majorité l'étaient en ASM .

par dlfrsilver Dim 31 Déc 2023 - 13:58

Yoyost a écrit:
Moi ce qui m'épate, c'est qu'aucune autorité n'est venu vérifié ce qu'ils faisaient. Commodore n'a pas coulé parce que l'argent rentrait pas, Commodore a coulé parce que le management s'est servi dans la caisse.

C'est peut être parce qu'il n'y avait pas matière à enquêter. Ca doit juste être un fantasme complotiste de plus pour se voiler la face et ne pas voir que ces machines avaient fait leur temps et étaient complètement à la ramasse après 1993.

Désolé, mais une entreprise est une entité non physique. Et voler dans les caisses d'une entreprise dont on a la gestion, c'est comme voler dans le portefeuille d'une personne handicapée dont on s'occupe à domicile.
Même aux USA, capitalistes n°1, c'est un crime !

Tout l'argent récolté suite à la vente des 500.000 A1200, hop envolé ! Commodore c'est une entreprise qui était dirigée par des sagouins qui se sont fait plaisir sur la bête, et qui l'ont mise en faillite, exactement comme des gosses mal appris casseraient leur jouet !

par dlfrsilver Dim 31 Déc 2023 - 14:01

touko a écrit:
les jeux NEO GEO sont en grand partie en C.
Il y a une partie du code source de AOF NG dans le CDrom pce, et je peux te garantir que c'est de l'ASM .
D'ailleurs le code source PCE en partie présent aussi, ne laisse aucun doute à ce sujet .

Alors c'est possible qu'il y ait des jeux codés en C, mais je pense que la grande majorité l'étaient en ASM .

J'ai sorti le code source d'Art of Fighting Neo geo et je l'ai rendu publique.

Si tu désosses le code de Metal Slug, tout est en ASM.

Les jeux d'arcade, avec de l'ASM et du Code C, je peux en citer 1 que je possède et que je connais, c'est Super Space Invaders '91 de Taito. J'ai la PCB, et pour m'amuser j'ai désassemblé le code 68000 du jeu, et j'ai trouvé des portions avec du code C dont les instructions ASM 68000 LINK et UNLINK, toujours présentes quand il y a du C dans un programme.

par Yoyost Dim 31 Déc 2023 - 14:07

Désolé, mais une entreprise est une entité non physique. Et voler dans les caisses d'une entreprise dont on a la gestion, c'est comme voler dans le portefeuille d'une personne handicapée dont on s'occupe à domicile.
Même aux USA, capitalistes n°1, c'est un crime !

Il y a eu un procès? Non? Bon ben voilà, pure spéculation gratuite pour fanboy qui ne veut pas voir la vérité en face.

par dlfrsilver Dim 31 Déc 2023 - 14:15

Yoyost a écrit:
Désolé, mais une entreprise est une entité non physique. Et voler dans les caisses d'une entreprise dont on a la gestion, c'est comme voler dans le portefeuille d'une personne handicapée dont on s'occupe à domicile.
Même aux USA, capitalistes n°1, c'est un crime !

Il y a eu un procès? Non? Bon ben voilà, pure spéculation gratuite pour fanboy qui ne veut pas voir la vérité en face.

Ils sont passés à travers. Tout simplement..... Renseigne toi sur la loi des entreprises aux USA et tu verras.

par Yoyost Dim 31 Déc 2023 - 14:17

Ils sont passés à travers. Tout simplement..... Renseigne toi sur la loi des entreprises aux USA et tu verras.

Bien sur, mais heureusement les enquêteurs équipés d'un Amiga ont pu mener l'enquête en multitâches et révéler le scandale. C'est risible ou mignon, suivant votre degré d'humour.

par Jacques Atari Dim 31 Déc 2023 - 14:19

dlfrsilver a écrit:J'ai sorti le code source d'Art of Fighting Neo geo et je l'ai rendu publique.

Moi je, moi je, moi je... Mais quel con ce mec, quel con... J'ai rarement vu ça. ohnon

par **youki** Dim 31 Déc 2023 - 14:32

touko a écrit:Tout dépend de la période et de la machine cible, aujourd'hui oui, mais avant non, et puis pas tous les compilo te permettaient facilement de mettre de l'assembleur en ligne dans le code C .
Je pense que ce genre de pratique s'est démocratisée avec la gen 32 bits .

Tu n'as pas besoin que ton compilateur C accepte l'assembleur en ligne pour mixer assembleur et C... tu sais il y a un truc qui s'appelle un Linker.. Very Happy

Faut juste declarer des fonctions qui ne sont pas dans ton code source en C , comme "extern" et tu demandes a ton linker de linker des binaires que tu aurais au préalable assemblé a ton executable.

La programmation en C pour les jeux , s'est developpé avec l'air 16bits... ca se fait beaucoup moins à l'air 8bits... la c'etait plutot le Pascal que l'on rencontrait.

Beucoup de jeux et logiciels developpés par les gros editeurs US (je parle pas du bed room coder) n'etait pas developpé sur la machine cible , ils avait des "pre"-PC et des PC par la suite , ils developpaient en language de haut niveau et cross compilait. Seule les librairies d'abstraction hardware était codé en assembleur.

Et ca faisait bien pendant les années 80.

par **youki** Dim 31 Déc 2023 - 14:47

Yoyost a écrit:
Ils sont passés à travers. Tout simplement..... Renseigne toi sur la loi des entreprises aux USA et tu verras.

Bien sur, mais heureusement les enquêteurs équipés d'un Amiga ont pu mener l'enquête en multitâches et révéler le scandale. C'est risible ou mignon, suivant votre degré d'humour.

arf.. je pense que l'on s'est planté... en fait Silver à raison depuis le début... je viens de trouver ses sources... effectivement on voit bien que les ventes de l'Amiga s'envole à partir de 1991... et le PC chute... donc forcèment si ils ont coulé , c'est à cause des managers qui ont piqué le pognon.

GUERRE ST-AMIGA, FIGHT ! (Mauvaise foi assurée) - Page 7 Vente_10

par **Copper** Dim 31 Déc 2023 - 14:49

Par contre il faut un peu maîtriser les conventions d'appel entre le C et l'assembleur et surtout il me semble qu'il faut avoir un format d'obj compatible entre le compilateur C et l'assembleur

par **youki** Dim 31 Déc 2023 - 15:26

Copper a écrit:Par contre il faut un peu maîtriser les conventions d'appel entre le C et l'assembleur et surtout il me semble qu'il faut avoir un format d'obj compatible entre le compilateur C et l'assembleur

oui, bien sur il faut connaitre les conventions d'appel. Pour le format Obj , il me semble que c'est standard ca .

Enfin a l'époque , c'est une technique que j'utilisais beaucoup , j'avais appris cette technique quand je bossais à IBM en 92 . Je faisais mes routines en assembleurs dans les quelles je devais compter le moindre cycle que je linkais à l'interpréteur de commande qui était en C. j'utilisais microsoft C 6 et masm.

Apres j'ai fait ça pour mes propres jeux sur PC.

Maintenant effectivement je m'embête plus je fais de l'inline asm.

par **Copper** Dim 31 Déc 2023 - 16:08

T'as déjà essayé de mélanger des obj borland avec des obj microsoft ?

par tapomag Dim 31 Déc 2023 - 16:15

Youki: Dans quels cas as-tu besoin de inliner de l'assembleur ?

Si tu as vraiment besoin de battre ton compilateur, jette un coup d'œil aux « intrinsics », ça te permettra de définir directement des types étendus pour sse ou avx, ou autre selon ta plateforme cible.

par **youki** Dim 31 Déc 2023 - 16:17

Copper a écrit:T'as déjà essayé de mélanger des obj borland avec des obj microsoft ?

il me semble que j'avais déja fait ça. Enfin toujours microsoft C mais TASM au lieu de MASM comme assembleur. Mais bon, ca fait bien longtemps , ma mémoire peut me jouer des tours.

par **youki** Dim 31 Déc 2023 - 16:20

tapomag a écrit:Youki: Dans quels cas as-tu besoin de inliner de l'assembleur ?

Si tu as vraiment besoin de battre ton compilateur, jette un coup d'œil aux « intrinsics », ça te permettra de définir directement des types étendus pour sse ou avx, ou autre selon ta plateforme cible.

Ben, je fais ça de temps en temps dans mes jeux. Par exemple pour Battle of Hoth , le scrolling des patterns est fait avec de l'inline ASM , le reste du jeu c'est du C.

par touko Dim 31 Déc 2023 - 16:22

Tu n'as pas besoin que ton compilateur C accepte l'assembleur en ligne pour mixer assembleur et C... tu sais il y a un truc qui s'appelle un Linker..

Oui et c'est vrai qu'avoir des libs externes en .o c'était vachement courant en 93, surtout pour les jeux qd tu vois le temps de compilation.
En tous cas les machines 16 bits étaient essentiellement codées en ASM .

Maintenant effectivement je m'embête plus je fais de l'inline asm.

Tiens, utiliser le linker et les .o c'est plus aussi bien tout d'un coup !!
Tu vois c'est ce que je te dis, c'est absolument pas adapté .

La programmation en C pour les jeux , s'est developpé avec l'air 16bits... ca se fait beaucoup moins à l'air 8bits... la c'etait plutot le Pascal que l'on rencontrait.

Non tu as eu quelques jeux(surtout en fin de vie des machines), et c'est tout, les compilos n'étaient pas assez performants, sans parler du temps de compilation .C'est l'ère 32 bits qui a démocratisé la pratique .

Beucoup de jeux et logiciels developpés par les gros editeurs US (je parle pas du bed room coder) n'etait pas developpé sur la machine cible , ils avait des "pre"-PC et des PC par la suite , ils developpaient en language de haut niveau et cross compilait. Seule les librairies d'abstraction hardware était codé en assembleur.

Alors là , j'ai de très,très gros doutes que la cross compil ait eu lieu à cette période avec des machines bien moins puissantes et chères, alors que les machines cibles ST/AMIGA faisaient largement mieux .

par tapomag Dim 31 Déc 2023 - 16:31

youki a écrit:
Ben, je fais ça de temps en temps dans mes jeux. Par exemple pour Battle of Hoth , le scrolling des patterns est fait avec de l'inline ASM , le reste du jeu c'est du C.

Je suppose que ce n'est pas sur PC (x86) alors, c'était ce à quoi je pensais.

par touko Dim 31 Déc 2023 - 16:35

youki a écrit:
tapomag a écrit:Youki: Dans quels cas as-tu besoin de inliner de l'assembleur ?

Si tu as vraiment besoin de battre ton compilateur, jette un coup d'œil aux « intrinsics », ça te permettra de définir directement des types étendus pour sse ou avx, ou autre selon ta plateforme cible.

Ben, je fais ça de temps en temps dans mes jeux. Par exemple pour Battle of Hoth , le scrolling des patterns est fait avec de l'inline ASM , le reste du jeu c'est du C.

Oui aujourd'hui c'est possible du fait de compilos modernes, machines modernes qui rende le cross compil totalement adapté pour une machine comme la coleco, en 80, impossible de faire ça .Bien sur tu vas me prétexter que le devkit d'une console c'est pareil Razz

par **youki** Dim 31 Déc 2023 - 16:39

tapomag a écrit:
youki a écrit:
Ben, je fais ça de temps en temps dans mes jeux. Par exemple pour Battle of Hoth , le scrolling des patterns est fait avec de l'inline ASM , le reste du jeu c'est du C.

Je suppose que ce n'est pas sur PC (x86) alors, c'était ce à quoi je pensais.

ah non, ca fait bien longtemps que j'ai plus fait d'ASM pour du code PC. La derniere fois que j'ai fait ca sur un PC , ca a était pour les routines graphiques de mon front end AtomicFE sous windows. Pour gerer les rotations et l'alpha blending directement sur les buffer de direct draw. Ca fait plus de 10 ans que je ne l'ai plus touché lui.

par **Copper** Dim 31 Déc 2023 - 16:48

De toute façon c'est hors sujet le PC

par Yastuna Lynx Dim 31 Déc 2023 - 16:53

dlfrsilver a écrit:
Exemple : les 5 millions d'Atari vendus sur le globe. des anciens d'Atari France ont dit à Gunhed dans le cadre d'un entretien amical que c'était faux par exemple, on sait de source sure qu'il y a eu plus d'Amiga de vendu sur le globe que d'Atari (le dernier du marché de l'informatique). Atari racontait des conneries aux actionnaires, et les 5 millions ça en fait partie. Mais y a pas que ça. Quand Atari coulait, au lieu de dire aux actionnaires que ça n'allait pas, ils continuaient à noyer le poisson en racontant n'importe quoi.

Tout ça est documenté dans le livre de Gunhed, il a fait les recherches adéquates, contacté ou échangé avec les personnes ayant les bonnes informations.

Et les Ataristes continuent de crier au mensonge (ça veut dire également que vous traitez les anciens d'Atari de menteurs, c'est la plus belle celle là alors qu'ils savent de quoi ils parlent puisqu'ils y bossaient et que c'est eux qui géraient, et comme ils l'ont dit à Gunhed, "On en a rien à carrer que les fanbois nous traitent de menteurs ou d'affabulateurs, les choses sont comme elles ont été, et s'ils sont pas jouasses, on en a rien à battre, et qu'ils ne cherchent pas à nous contacter pour avoir confirmation!")

Atari est sorti du monde de l'informatique en tant que constructeur en 1993. le démantelement complet (infrastructure et administrative) s'achèvera en 1996 avec la "fusion lors du rachat par JTS".

Bon alors sur ce point, je vais la faire courte, je ne sais pas qui est Gunhed et je m'en fous, comme de la plupart des historiens auto-proclamés (cf plus loin) et autres influenceurs, je ne sais pas si Commodore a vendu plus d'Amiga qu'Atari de ST et je m'en fous (même si je me doute que vu que l'Amiga a survécu grâce à un sursaut en 91/92 c'est probablement le cas).
Ce n'est pas ça qui m'intéresse dans ces machines, mais ton message me permet de mieux comprendre ce qui nous distingue et pourquoi on ne peut pas échanger. Tu te considères comme un historien analyste de la période, je me considère juste comme un ancien passionné toujours intéressé par ces bécanes. Effectivement, cette histoire m'intéresse mais pas d'un point de vue analytique car c'est trop tôt. Il faut laisser le temps et ce qu'en penseront les générations à venir dans 100 ou 200 ans (si elles existent encore et s'en foutent de ces vieux coucous) n'a pas à être documentée et écrite maintenant. La révision historique se fera avec le temps, et comme la période est très courte, ce sera du kif kif et de l'anecdotique (si c'est mentionné).

Idem, je ne vais pas me lancer sur le sujet de la préservation, je sais que je suis à contre-courant de quasi tout le monde (et pourtant je suis éditeur).

Le ST était un "miracle" voué à l'échec à court terme (et non à long terme). Ces machines auront eu une durée de vie courte. Comme l'a dit à un Atariste Richard Costello, développeur Atari, le ST a débuté sa mort quand l'Amiga 500 est sorti, c'était impossible pour lui de tenir tête à l'amiga, et c'est pas la niche MAO qui allait lui sauver les fesses, c'est pas avec x.000 utilisateurs que tu peux faire un marché.

Court terme ou long terme c'est selon. Si on se place en 86, alors 90 c'ets du long terme et 93 c'est du très long terme. Après tout à l'époque, les générations se suivaient en repartant d'une page blanche, c'est le PC (et le Mac) qui a généré ce besoin de compatibilité dans le temps. Le ST (et probablement l'Amiga) n'ont probablement pas été conçus dans cette optique. Vu de 2023 forcément, c'était court-termiste comme vision pour les 2.

Le ST est mort à cause du piratage, en sus de sa faiblesse côté hardware, avec des ventes logicielles ridicules.

Non, le ST est mort car en 90 il n'offrait rien de plus qu'en 87 et était largué vis à vis du PC et du Mac. L'Amiga aussi mais Commodore a réussi à lui donner un sursis avec l'AGA et le 1200.

L'Amiga n'a pas été un gachis, il a enterré la gamme ST ainsi que l'Atari Falcon (indépendamment des difficultés de trésorerie d'Atari). L'Amiga a été fabriqué de 1985 à 1998 (Amiga 4000 Quikpak). Soit 13 ans, la fabrication ayant continué bien après que Commodore ait mis la clé sous porte. Côté Atari, la fabrication des ST/TT/Falcon est stoppée fin 1993 soit 8 années seulement.

Le Falcon a péniblement été sorti à 22.000 unités contre 500.000 unités au niveau mondial pour le 1200.
Et Commodore était à la peine financière avec leurs conneries au même titre qu' Atari. Ils ne s'attendaient pas à ce que le 1200 ait un tel succès, malgré les rabotages côté hardware.

Ben justement si c'est un gâchis, il a eu une période de conception de combien ? 4 ou 5 ans voire plus ?
Il a été marketé n'importe comment, présenté comme une machine de jeu à l'origine, vendu comme une workstation avec l'A1000, puis Commodore prend un virage à 180° avec le 500 pour survivre en se positionnant sur le marché du ST.
Malgré tout, ils ont tenté de faire perdurer la gamme workstation avec les 2000, 3000 et 4000.
Bref, sur la papier et vu de l'extérieur, tout était réuni pour qu'il fasse mieux, et au final, il ferait juste un peu mieux que le ST que tu considères comme un échec, et il n'a jamais fait mieux que le C64 ? J'appelle ça un gâchis de mon point de vue, je te laisse utiliser ton vocable.
La gamme ST a survécu à Atari avec le C-Lab, Milan, Hadès, Coldfire. Certes c'est moins flamboyant que ce qu'il y a eu coté Amiga (et qu'il y a encore d'ailleurs), mais au final, être un marché de niche ou d'ultra niche, ça ne change pas grand chose (et je met rien de péjoratif la dedans, au contraire je suis admiratif de ce genre de passion et de dévouement à sa passion).

D'un point de vue "versatile" pour reprendre ton terme, l'Amiga est bien plus doué et mieux conçu pour ça. L'Amiga n'est pas seulement évolutif au contraire de la ligne ST, il est aussi infiniment plus souple que le ST.
On peut faire plus de choses avec un Amiga qu'avec un ST, c'est ce qui aura toujours été sa grande force. Y a pas que les jeux vidéos qui étaient attirant sur l'Amiga, mais les logiciels tournant dessus, la rapidité, l'OS ultra modulaire et entièrement multitâche, le ST pouvait pas rivaliser, et le Falcon 030 encore moins.....

Peut-être, je n'ai pas connaissance de logiciels dédiés pour médecins (et autres professionnels de santé), architectes, avocats et autres métiers sur Amiga mais ça a probablement exister. Tout comme sur les 2 il a du y avoir toute une palanquée de logiciels de programmation, systèmes experts et bases de données...
Et je suis probablement biaisé par le marketing de Commodore qui ne m'atteignait à l'époque que par l'Amiga 500 et leur communication autour du jeu vidéo et du graphisme, et éventuellement la partie vidéo pour les 2000. Bref, des sujets qui ne me donnaient pas envie de changer vu que j'avais tout ce que je voulais sur ST.
Mais en associant la conception et l'évolutivité de l'Amiga au coté versatile de l'ordinateur, tu confirmes mon impression de gâchis concernant l'Amiga.

Et juste pour apporter une précision sur un autre message, je ne crois pas que Commodore France existait avant l'époque Atari Tramiel, c'était une société d'import indépendante (dirigée par Elie Kenan de mémoire) qui effectivement a suivi Tramiel chez Atari en créant la filiale Atari France.