Re: * ATARI ST * TOPIC OFFICIEL

[drfloyd]

C'est jamais bon d'avoir le cul entre 2 chaises... on se casse forcement la gueule.

Il vaut mieux etre bien assis (faire un vrai ST 2 en 1988, en restant dans l'idée micro (Mac pas cher), et non console de jeu)

ou changer vraiment de chaise (un nouveau micro)

[epc35]

Le 1200 n'était pas la machine qu'on aurait voulu, surtout du point de vue graphique, y a pas de raisons de la defendre.

[TotOOntHeMooN]

Le 1200 n'était pas la machine qu'on aurait voulu, surtout du point de vue graphique, y a pas de raisons de la defendre.

Je dirai plutôt que c'est une machine qui aurait dû sortir à la place du A500+ et qu'on aurait souhaité mieux de la part de Commodore et d'Atari en 1993. Tout comme l'affichage du Falcon (Videl) avait plus sa place dans la gamme STe.

[Yoyost]

C'était la dernière chance pour Commodore, ils savaient qu'ils n'allaient pas acquérir de nouvelles part de marché et que donc il fallait essayer de conserver ce qu'ils avaient déjà, en gardant une compatibilité.

[TotOOntHeMooN]

C'était la dernière chance pour Commodore, ils savaient qu'ils n'allaient pas acquérir de nouvelles part de marché et que donc il fallait essayer de conserver ce qu'ils avaient déjà, en gardant une compatibilité.

C'est un sujet fortement discutable qui a sa place sur le topic Amiga vs ST.

[drfloyd]

Moi je ne voulais pas un Amiga like pour le ST 2, je voulais un STF 68020-30 classique, avec 2mo et le blitter installé, et un GEM vraiment amélioré

C'est tout

Je voulais qu'ils continuent dans la voie Mac Killer.

[Dbug]

Un truc que j'ai jamais compris c'est pourquoi Atari n'a pas négocié l'intégration de trucs comme NVDI ou Magic/Geneva dans le GEM, ca aurait donné une machine bien plus performante de facon standard, avec un multi-tache qui fonctionne sans perdre trop de performance comparé a MiNT.

[TotOOntHeMooN]

Est-ce que se sont des extensions qui auraient pu tenir en ROM ?
A ce que je comprends, il y a 256K sur le STe par exemple.
Ca aurait aussi pu se faire sous forme de cartouche.

[Dbug]

Est-ce que se sont des extensions qui auraient pu tenir en ROM ?
A ce que je comprends, il y a 256K sur le Ste par exemple.
Ca aurait aussi pu se faire sous forme de cartouche.

NVDI ca remplace la VDI de la ROM (écrite en C) par un équivalent écrit en assembleur, donc de coté là probablement pas de problème.
Pour le core multi-tâche, je ne sais pas, mais c'est probablement pas très gros, l'essentiel de la place c'est probablement les modifications du bureau avec les nouvelles fonctions.

[drfloyd]

le port cartouche jamais utilisé.... 

Le GFA en cartouche bordel !

[Yastuna Lynx]

MultiTOS n'était pas en ROM...
Et je ne pense pas que la VDI et l'AES dans la ROM étaient très optimisés niveau taille (majoritairement codés en C, pas en assembleur).

Je pense surtout que MiNT était gratuit (enfin, il a fallu embaucher Eric Smith mais il s'est bien vengé en commettant Club Drive sur Jag), nord-américain alors que NVDI était commercial et européen.

[TotOOntHeMooN]

@Dbug D'accord. Donc, c'était effectivement quelque chose d'envisageable comme évolution. 
Il serait déjà intéressant de savoir si l'auteur de NVDI a été en contact avec Atari.

[Copper]

le port cartouche jamais utilisé.... 

Le GFA en cartouche bordel !

Genre tu as acheté le GFA en original + le compilateur (pas donné quand même)

[dlfrsilver]

Tu as très bien compris ce que je veux dire... Tu interprètes la moindre phrase pour venir dénigrer l'Atari ST et ta signature, même réduite, en atteste toujours. On t'as d'ailleurs fait la remarque plus haut (plutôt bien argumenté) concernant le Mega STe.

Arrête. J'interprète rien du tout, j'ai juste donné une information (qui sera par ailleurs publiée).

Si une personne préfère le MSTE au TT030 pour X raisons, ça la regarde :)

[dlfrsilver]

L'Amiga 1200 est objectivement moins avancé que le l'Atari Falcon 030... mais en terme de machine dans une gamme complète, le 1200 est utilisable comme mise à jour pour un Amiga 500/600/1000, alors que ca n'est pas le cas du Falcon.

L' Amiga 1200 est une évolution de l'architecture existante, là où le Falcon 030 a le cul entre deux chaises en étant ni un ST ni un TT. La machine de Commodore s'en est bien mieux sortie sur l'autel du compromis.

Pour revenir au YM, il serait nécessaire de déconnecter le signal SNDCS (pin 26) pour le remplacer par un décodage qui exclus les lignes d'adresses A7 à A2, si l'on souhaite récupérer la compatibilité avec les jeux ST.

Le Falcon 030 faisait partie de la suite de la ligne ST, en terme de machine low cost. Le TT030 était strictement prévu pour faire du pro, et uniquement du pro (le fait qu'il ne soit pas compatible pour faire du jeu était entièrement voulu comme tel par atari), et c'était le haut de gamme chez Atari avec le prix très élevé qui va avec.

Atari afin quand même de sortir de l'ornière (enfin essayer), a fait en sorte que le Falcon 030 soit plus puissant que la gamme ST/STE au prix de problèmes de compatibilité. 

Pour l'histoire du 1200, on en discutera sur l'autre topic et pas ici.

[TotOOntHeMooN]

J'interprète rien du tout [...] Si une personne préfère le MSTE au TT030 pour X raisons, ça la regarde :)

Preuve que si, ma remarque ne faisait pas du tout référence à cela... Enfin, j'ai l'habitude maintenant. :)

[Dbug]

J'imagine que tu as une source incontestable pour ce que tu viens d'écrire.

Que Atari n'est pas fait d'efforts pour maintenir la compatibilité avec les logiciels tapant dans le hardware, c'est une chose.
Faire en sorte que ca soit conçu pour être incompatible, c'est autre chose.

A ma connaissance personne ne fait le choix de rendre sa machine incompatible avec le reste de la gamme, ca n'a absolument aucun sens, ca réduit la valeur de la machine sans rien apporter en échange.

[TotOOntHeMooN]

Atari n'a évidemment pas fait en sorte que le Falcon soit volontairement incompatible avec le ST.

[dlfrsilver]

Y'avait pas de consignes elle ne sont apparues qu'au moment de l'AGA (en tout cas il n'en est pas fait mention dans la Bible) et pour moi c'était juste un prétexte pour ne pas publier les specs...

Après appeler une routine directement dans la ROM c'est jamais conseillé quelque soit la machine

Commodore a très mal pris que les consignes n'aient pas été respectées sur l'Amiga 500. Du coup quand l'AGA est sorti, ils ont refusé de donner aux programmeurs la bible permettant d'utiliser le 1200 et le 4000 au ras du métal. 

Le mot d'ordre c'était "vous utilisez ces 1200 au niveau OS, pas en bas niveau..." Les intéressés n'ont pas apprécié, et ils ont du coup exploré eux même les capacités des nouvelles machines.

Et oui sur Amiga 500, pas mal de jeu avaient ce truc qui venait du monde Atari (accès direct à la rom système non pas de manière intelligente, mais directement via un JMP sur l'offset de la routine en ROM), qui a posé problème dès que Commodore a upgradé la rom kickstart, les jeux plantaient ou ne fonctionnaient plus.

[dlfrsilver]

J'imagine que tu as une source incontestable pour ce que tu viens d'écrire.

Que Atari n'est pas fait d'efforts pour maintenir la compatibilité avec les logiciels tapant dans le hardware, c'est une chose.
Faire en sorte que ca soit conçu pour être incompatible, c'est autre chose.

A ma connaissance personne ne fait le choix de rendre sa machine incompatible avec le reste de la gamme, ca n'a absolument aucun sens, ca réduit la valeur de la machine sans rien apporter en échange.

Y a pas besoin de sortir de St-Cyr pour s'en rendre compte. Déjà, tout les jeux sur ST reposent  sur une programmation full CPU, donc 68000. Problème, Atari afin de proposer une machine plus puissante est passé sur un 68030 custom, avec des fonctions déportées dans les puces annexes (c'est indiqué dans le manuel du falcon, si je me rappelle bien). Donc clairement, pour la compatibilité en terme de programme/code pur, déjà c'est mort.

Le clock d'horloge du CPU est plus rapide sur le 030 du Falcon, donc forcément, les routines faites pour du 8mhz sur 68000, ça marchera pas. 

L'incompatibilité est entièrement lié au changement et à l'upgrade de la machine.

Pour le Falcon 030, ils étaient obligés de laisser les modèles ST/STE derrière, bien trop lents et totalement en dehors du coup vis à vis des machines du marché à l'instant T. 

Le but était d'essayer de récupérer la main, mais en pure perte, ils n'ont pas réussi.

[dlfrsilver]

Atari n'a évidemment pas fait en sorte que le Falcon soit volontairement incompatible avec le ST.

Ben si mécaniquement, c'est le cas. Le STE avait déjà des problèmes de compatibilité avec les ST déjà pour commencer, et le Falcon 030 était un monstre de frankenstein construit sur la base d'un 1040 STE equipé d'une carte fille avec le 030/videl/Combel + DSP, dont ce tout à été ensuite réduit à une simple carte mère avant de passer en pré-production (Rappel, le Falcon 030 n'est pas une machine finie, ces machines sont TOUTES des machines prototypes, d'après le codage sur numéro de série établi par Atari - Note: Atari a sorti avec grand mal 22.000 Falcon 030, et ma machine (la 7444ème sortie des lignes de production), est un modèle prototype (pré-production). 

Tu peux regarder le numéro de série de la tienne, c'est exactement pareil, y a pas de Falcon030 finalisé (Atari a en plus fait plusieurs défauts de paiement par manque d'argent, qui ont entrainé un arrêt de la fabrication de l'ordi).

[Copper]

Ça ne change rien au fait que Commodore n'avait pas donné de consignes à l'époque de l'OCS il les a donné après coup

[dlfrsilver]

Un truc que j'ai jamais compris c'est pourquoi Atari n'a pas négocié l'intégration de trucs comme NVDI ou Magic/Geneva dans le GEM, ca aurait donné une machine bien plus performante de facon standard, avec un multi-tache qui fonctionne sans perdre trop de performance comparé a MiNT.

Tu demandes, mais tu connais déjà la réponse : ça aurait cassé la compatibilité avec tout ce qui existait déjà.

Sur ST comme sur Amiga, la première chose que faisait le programmeur c'était dégager le système pour aller taper directement au ras du métal. 

Voilà pourquoi le ST est resté sur la base de départ, démarrage sur bootsecteur pour shooter le système, ou alors programmes reposant sur les fonctions du GEM. 

Aucun programme existant pour le coup n'aurait pu fonctionner avec du multi-tâche en soft. C'est pour ça que rien n'a été fait en ce sens.

L'utilisation de ces programmes ne pouvait relever que d'une volonté personnelle d'essayer autre chose.

[dlfrsilver]

Ça ne change rien au fait que Commodore n'avait pas donné de consignes à l'époque de l'OCS il les a donné après coup

Le recueil de consignes, c'était la bible hardware.

[Copper]

Non ce n'est pas la même chose

[Yastuna Lynx]

Un truc que j'ai jamais compris c'est pourquoi Atari n'a pas négocié l'intégration de trucs comme NVDI ou Magic/Geneva dans le GEM, ca aurait donné une machine bien plus performante de facon standard, avec un multi-tache qui fonctionne sans perdre trop de performance comparé a MiNT.

Tu demandes, mais tu connais déjà la réponse : ça aurait cassé la compatibilité avec tout ce qui existait déjà.

Sur ST comme sur Amiga, la première chose que faisait le programmeur c'était dégager le système pour aller taper directement au ras du métal. 

Voilà pourquoi le ST est resté sur la base de départ, démarrage sur bootsecteur pour shooter le système, ou alors programmes reposant sur les fonctions du GEM. 

Aucun programme existant pour le coup n'aurait pu fonctionner avec du multi-tâche en soft. C'est pour ça que rien n'a été fait en ce sens.

L'utilisation de ces programmes ne pouvait relever que d'une volonté personnelle d'essayer autre chose.

Comment les softs qui fonctionnaient avec NVDI et Magic ou Geneva faisaient pour tourner alors ?
Je n'ai pas l'impression qu'il fallait faire des incantations particulières ou sacrifier un Amiga à chaque pleine lune pour ça.

J'ai l'impression que pour toi, un programme = un jeu ou une démo, ou là oui, majoritairement ils n'utilisaient pas les fonctions systèmes mais il y avait plein d'autres choses à faire que jouer sur un ST et même un Amiga.

Je n'ai pas de souvenirs particuliers d'incompatibilités avec NVDI par rapport à la VDI (vu que le but était de réécrire les fonctions de la VDI d'une manière plus optimisée). Pour Magic effectivement, les programmes GEM mal écrit pouvaient probablement avoir des problèmes de refresh (et encore, du moment ou ils avaient un menu pour gérer les accessoires, ils étaient confrontés au problème). Eventuellement, les produits Steinberg qui se basaient sur leur propre noyau multitache MROS. Je ne sais pas si Cubase fonctionnait avec Magic ou pas.

[TotOOntHeMooN]

@dlfrsilver Ca serait bien que tu partes en weekend, voir en vacances.

[dlfrsilver]

Les softs faits pour tourner avec ces programmes n'étaient pas compatibles avec la config standard ST. 

Une personne qui sortait du standard savait très bien que les logiciels pouvant tourner se réduisaient à peau de chagrin. 

Exemple simple, prends multiTOS, et essaie de faire tourner un programme standard ST, ça ne fonctionnera pas.

le noyau multitache MROS chez Steinberg, tu faisais pas tourner dessus les programmes classiques tournant sous GEM. 

Les logiciels sur Atari ST étaient programmés en mode monotache (ce qu'est le ST de base). Quand tu passes avec un programme qui permet de faire du multitache, ça ne fonctionne pas puisque qui dit multitache dit 'arbitrage' au niveau du traitement.

[dlfrsilver]

@dlfrsilver Ca serait bien que tu partes en weekend, voir en vacances.

c'est pas toi qui décide 

[Yastuna Lynx]

Le ST de base n'est pas exactement monotache, il y a les accessoires que tu sembles oublier... Ce n'est pas un multitache préemptif comme l'Amiga (et on ne peut pas connecter 4 lecteurs de disquettes pour formatter ou copier 4 disquettes à la fois) mais il n'est pas stricto sensu monotache.

Et je n'ai jamais dit que d'autres programmes pouvaient tourner sur MROS, juste que je ne savais pas comment les programmes Steinberg se reposant sur MROS tournaient (ou pas) avec Magic.

Quand à Magic, sa compatibilité semblait suffisamment bonne pour que beaucoup de monde l'achète à l'époque (sauf ceux qui ne faisaient que jouer sur les machines bien sur).

et oui, j'ai essayé des programmes ST avec MultiTOS à l'époque (j'avais acheté le Falcon la semaine de sa sortie), et ça fonctionnait globalement bien (sous réserve que le programme tournait sur Falcon)

[Dbug]

C'est toujours marrant d'écouter monsieur Silver sortir des trucs en relation avec la programmation, dommage que je soit en manque de popcorn.

Pour ceux qui n'ont pas encore compris, dlfrsilver utilise son prestige d'expert archiviste/preservation pour balancer des trucs approximatifs ou incorrects de facon "je suis un expert" que malheureusement les gens souvent écoutent parce qu'il n'ont pas forcément les connaissances.

Et typiquement il ignore tous les arguments contraires et rebondit sur ce qui va dans son sens, en postant message après message pour noyer le poisson.

Et effectivement le "Atari on des tous des dieux du bas de gamme" ca résume bien le personnage, il aime l'Amiga et l'Atari c'est de la merde, et il ne peut pas s’empêcher de foutre la merde sur les endroits ou sa cause Atari, et en général il faut dépenser une quantité hallucinante d'énergie pour qu'il arrete... mais il repart sur autre chose dès qu'on tourne le dos.

Pour ceux qui n'ont pas suivit, j'ai déjà démonté les arguments du monsieur concernant Shadow of the Beast.

En gros il s'y connait suffisamment en programmation pour balancer des trucs style ChatGPT (il sait ce qu'est un JMP ou un vecteur d'interruption mais je doute qu'il sache programmer sur ST).

Et jamais il n'écrira qu'il est incertain sur truc, non, c'est toujours "Je l'ai lu sur les tablettes que Moise a récupéré sur le mont machin truc".

Et oui sur Amiga 500, pas mal de jeu avaient ce truc qui venait du monde Atari (accès direct à la rom système non pas de manière intelligente, mais directement via un JMP sur l'offset de la routine en ROM), qui a posé problème dès que Commodore a upgradé la rom kickstart, les jeux plantaient ou ne fonctionnaient plus.

C'est juste la première génération de softs, dès que la ROM 1.1 est sortie tous ces jeux plantaient, et typiquement c'était du a des manques dans la documentation, typiquement certain jeux lisaient les coordonnées du joystick ou de la souris dans les valeurs en ram, ou bien partaient du principe que l'écran était a une addresse fixe, etc...

Y a pas besoin de sortir de St-Cyr pour s'en rendre compte. Déjà, tout les jeux sur ST reposent  sur une programmation full CPU, donc 68000. Problème, Atari afin de proposer une machine plus puissante est passé sur un 68030 custom, avec des fonctions déportées dans les puces annexes (c'est indiqué dans le manuel du falcon, si je me rappelle bien). Donc clairement, pour la compatibilité en terme de programme/code pur, déjà c'est mort.

Le clock d'horloge du CPU est plus rapide sur le 030 du Falcon, donc forcément, les routines faites pour du 8mhz sur 68000, ça marchera pas. 

L'incompatibilité est entièrement lié au changement et à l'upgrade de la machine.

Il y a très très peu de code 68000 qui foire sur 68030, en gros ce qui foire c'est:
- Le code auto-modifié a cause de la taille du prefetch/cache
- Les handlers d'exception a cause du stack frame

Et au final, c'est les protections qui plantent, rarement le jeu lui même parce que très peu de jeux ont besoin de faire ca. Et pour ce qui est du 8/16 mhz, ca expliquerait des jeux plus rapides, mais pas les plantages.

Ca m'intéresserait que tu me trouve la section dans le manuel du Falcon qui dit que c'est un 68030 custom avec des fonctions déportées dans des puces annexes, a ma connaissance c'était un 68030 standard, juste que pour des raisons de cout ils ont mis un bus 16 bit au lieu de 32 bit, ce qui nuit a la performance.

Le Falcon 030 est une machine LENTE: Oui il est plus rapide que le ST, mais un Falcon en 320x200 en mode TRUE COLOR est plus lent qu'un ST en mode 16 couleurs.

> Atari n'a évidemment pas fait en sorte que le Falcon soit volontairement incompatible avec le ST.
Ben si mécaniquement, c'est le cas. 

Voila, tu viens en gros de dire que tu racontais n'importe quoi dans le premier message: Oui l'incompatibilité existe mais c'est pas fait exprès.
Le boss d'Atari il s'est pas levé le matin en chantant "JE VEUX QUE LE FALCON SOIT INCOMPATIBLE".
En gros tu sais pas lire: Le mot important c'était VOLONTAIREMENT. Non c'est pas volontaire.

> Un truc que j'ai jamais compris c'est pourquoi Atari n'a pas négocié l'intégration de trucs comme NVDI ou Magic/Geneva dans le GEM, ca aurait donné une machine bien plus performante de facon standard, avec un multi-tache qui fonctionne sans perdre trop de performance comparé a MiNT.
Tu demandes, mais tu connais déjà la réponse : ça aurait cassé la compatibilité avec tout ce qui existait déjà.

Bein non, la majorité des softs GEM tournent bien avec NVDI et MAGIC, et les jeux et les démos s'en tapent vu qu'elles giclent le système, comme tu le dis toi même dans la phrase juste en dessus: Sur ST comme sur Amiga, la première chose que faisait le programmeur c'était dégager le système pour aller taper directement au ras du métal. 

J'adore la capacité a se contredire dans le même message.

Aucun programme existant pour le coup n'aurait pu fonctionner avec du multi-tâche en soft. C'est pour ça que rien n'a été fait en ce sens.

C'est du multi-tâche coopératif, ca marche déjà sur les ST standard avec les accessoires de bureau, juste que c'est très limité au niveau du fonctionnement.

J'adore à chaque fois que tu nous rappelle qu'en fait tu connais rien sur le ST.

@Yastuna, je suis d'accord avec quasiment tout ce que tu à écris.

J'arrête là, je sais que le silver va continuer a balancer message après message jusqu’à plus personne ne voit celui là, ce mec il est épuissant, c'est l'équivalent retro-gaming d'une Fake News.