Re: GUERRE ST-AMIGA, FIGHT !!!

[Invité]

J'espère que Meditating Guru ne va pas en faire un Software Failure.

[rocky007]

Mais c'est clair que le STE n'est pas du bricolage comme sur le mig, on peut tout utiliser en même temps, car les puces sont autonomes,fonctionnent en // est tout est bien pensé avec son blitter plus rapide que sur amiga et le son DMA qui fait passer paula pour le YM du ST ..
Trop fort atari . 

c'est ça votre problème : tu ne faites pas la différence entre une machine bricolé comme le A1000, et une machine non optimisée l’extrême comme le ST.
Encore une fois, mettez côte à côté aun jeu au CPU ( style Falcon, Stuntcar, etc..)...alors il est où le bricolage ?  ben ça tourne idem..( enfin plus vite sur ST grâce à sa clock , mais idem si la clock était la même).  L'amiga a été conç comme une console de jeu ( dixit Commodore et Jay Miner ), le ST comme un ordinateur, donc faut pas s'étonner que les jeux tournent mieux sur un Amiga.

[Invité]

c'est ça votre problème : tu ne faites pas la différence entre une machine bricolé comme le A1000, et une machine non optimisée l’extrême comme le ST.

Sans smiley on pourrait croire que tu es sérieux en disant ça !!

Je vois pas comment un hardware pensé pour qu'un chipset aussi complet puisse tourner ensemble, et donc en ayant maximisé l'utilisation de la bande passante mémoire dispo peut être qualifié de bricolage, alors qu'une machine sortie en 6 mois et même pas capable d'évoluer sans tout faire exploser l'est ?? 

Encore une fois, mettez côte à côté aun jeu au CPU ( style Falcon, Stuntcar, etc..)...alors il est où le bricolage ?  ben ça tourne idem..( enfin plus vite sur ST grâce à sa clock , mais idem si la clock était la même).  L'amiga a été conç comme une console de jeu ( dixit Commodore et Jay Miner ), le ST comme un ordinateur, donc faut pas s'étonner que les jeux tournent mieux sur un Amiga.

Là rocky, post of the year !!

Tu sais le but des copros, c'est justement pour pas avoir la même chose qu'avec une machine sans, sinon les bornes d'arcade auraient mis des ST pour faire tourner les jeux, si c'était pareil .
Et des copros ça sert pas qu'aux jeux, mais pour accélérer l'affichage, donc utile pour tout ce qui est graphique,OS compris.
Bon après c'est sur qu'avec le TOS/GEM comme OS vous pouvez pas comprendre ce qu'est un OS graphique 

[rocky007]

Te répéter tu es fort pour ça 
Tu repètes même souvent les mêmes inepties sur l'Amiga (alors qu'on a maintes fois montré que c'était des inepties).

n'inverse pas les rôles, le maître dans cet art, c'est bien toi, tu es mon mentor

Mais je sais bien que Byte à maintes fois dit du bien de l'Amiga, pas besoin de toi pour ça.
Je dis juste que ta citation de ce numéro de Byte omettait les points qui ne t'arrangeais pas, comme bien souvent.
Mais, ta réputation est déjà faites sur ce point.

j'ai cité ma source dans le cadre de mon intervention , qui est pour la rappel : le top 20 softwate... je ne parlais pas du chipset ou autre... juste du software, donc je cite la source pour celle-ci.  je note que tu n'as pas jamais cité de source pour la laser Atari non plus.

Parce qu'il n'y avait pas des problème d'incompatiblité entre les version de TOS ? Surtout quand les programmeurs n'ont pas respectés les consignes ? C'est ce qu'il expliquait pour les version de Kickstart. Ce n'est nullement la faute de Commodore, mais bien celle du programmeur.
Le Kicstart respectait les consignes de Motorola, résultat compatible 32 bits d'origine.

ah mais moi je ne dis pas le contraire, je t'explique simplement que c'est pas mieux sur amiga et que dès lors, critiquer le TOS est un peu ridicule
et d'après les explications de dlfrsilver, qui est je te rappelle un spécialiste confirmé, les changements dans le kickstart du A600/A500+ sont problématique et n'ont rien à voir avec des jeux mal codés.

L'Amiga avait Lightwave, Deluxe paint, Scala multimédia et d'autres qui ne me reviennent au premier abord.

j'ai rien vu de tout cela dans BYTE en effet, ni de Cubase ou de Calamus.

Et je t'ai déjà répondu sur ce point, le PC c'était encore plus facile les jeux gratuits... la preuve tu as fuis sur PC pour ça...

mais le PC plus cher.  donc amiga c'était une console au rabais avec les jeux gratuits, parfait pour les enfants comme cadeau de noël

Et comment que tous les jours je me faisait la réflexion, qu'est ce que c'est bien AmigaOS. Ce n'est pas pour rien que je suis resté sur Amiga jusqu'en 1998 et que je continue à défendre son OS encore de nos jours (et aussi à l'époque face aux PCistes).

eh ben tu as eu du courage..bravo à toi.  du reste, pourquoi as tu changé finalement ?

Ce qui me gène, c'est que je sais que le PC était la moins bonne solution (y compris son processeur) et que c'est ça qui s'est imposé. C'est affligeant.

oui donc c'est purement psychologique.  au fait sais tu pourquoi motorola a arrêté ses proc ?  parce qu'ils étaient moins rapide que ceux d'intel et qu'ils ne savaient plus suivre

Mais tu sais bien qu'un Amigaïste c'est pas très futé et très premier degré. Donc je suis content que tu finisses pas admettre la supériorité du Workbench 

je préfère encore qu'on me coupe un bras que dire une telle affirmation

Mais le C64 est bien dans ce numéro, y compris avec le SID. Pas de trace du ST (même comme mention) ou du YM. 

à ce que je sache, le SID n'est pas un ordinateur.  on ne parle pas ici du software ou hardware du ST, on parle simplement du fait que CP/M est repris dans le top 20, pas le workbench/amigaos. L'amiga n'est que salué de loin lorsqu'on parle de l'ensemble de la machine.  raison pour laquelle personne n'a jamais voulu racheter ou adapter AmigaOS/WB sur un autre machine, personne n'en voulait

Au fait, tu peux donner le liens vers l'article de Byte ?

ben c'est dans les pages que tu as toi même citée

C'est ça, ils parlent explicitement de son multitâche, comme l'une de ses forces pour l'époque, mais c'est pas parler de son OS.

non ils disent que l'amiga est un bon ordinateur dans son ensemble, et qui est multitâche.  ils vantent le mérite de l'ordinateur dans sa globabilité, et non pour une GUI exceptionnelle.

Un vaporware est rarement à la hauteur des attentes.

si la preuve : Win95

En tout cas, on voit bien que Stapha92 est doué aussi pour l'orthographe

je sais pas si tu as des filles, mais je pense qu'il ferait un bon parti

[rocky007]

Sans smiley on pourrait croire que tu es sérieux en disant ça !!

Je vois pas comment un hardware pensé pour qu'un chipset aussi complet puisse tourner ensemble, et donc en ayant maximisé l'utilisation de la bande passante mémoire dispo peut être qualifié de bricolage, alors qu'une machine sortie en 6 mois et même pas capable d'évoluer sans tout faire exploser l'est ?? 

je n'ai jamais vu un ST exploser.  par contre j'ai l'ami d'un copain qui a lu sur un forum polonais que qq a perdu sa maison à cause d'un amiga qui a pris feu.

et je ne cite que babsimov et dlfrsilver qui disaient que le A1000 est complétement buggé, avec un chipset incomplet au point d'oublier cette période et d'en faire du négatisme.  ils estiment que le premier amiga est le A500 en 87.  moi j'appelle cela du bricolage

[Invité]

je n'ai jamais vu un ST exploser.  par contre j'ai l'ami d'un copain qui a lu sur un forum polonais que qq a perdu sa maison à cause d'un amiga qui a pris feu.

Que la maison ??, même pas le chat et la belle mère ??

et je ne cite que babsimov qui disait que le A1000 est complétement buggé, avec un chipset incomplet.  moi j'appelle cela du bricolage

Et toi tu fais une généralité sur toute la gamme .
Atari juste avec une mobo,1 CPU et de la ram sont arrivé à faire un truc pas fini,et ne me dis pas que le ST n'a pas de bugs, des machines sans bugs, y'en a pas et c'est pour cela que les révisions existent .

[rocky007]

Et toi tu fais une généralité sur toute la gamme .
Atari juste avec une mobo,1 CPU et de la ram sont arrivé à faire un truc pas fini .

ben toi aussi...le TT était bien, même Stapha le dit .  Et le Falcon, à part son bus 16 bit, le reste est bien non ?
donc sur la période 85-87 le ST était mieux que le A1000.  Le A500 mieux que le STE, et le Falcon mieux que le A1200.
Si je compte bien, cela fait bien 2-1 pour Atari

[Invité]

Et le Falcon, à part son bus 16 bit, le reste est bien non ?

Es ce que j'ai dit que le falcon était pourri ??
Mais souffre du syndrome STE, CAD blitter inutilisable, et surtout sans intérêt .
La compatibilité ST/STE est une bêtise sans nom.

donc sur la période 85-87 le ST était mieux que le A1000

Non le ST avait un meilleurs rapport qualité/prix.

Le A500 mieux que le STE

A500 mieux que ST, STF,STE, ça fait déjà 3 là 

[rocky007]

et le même syndrome que l'amiga 1200 : vieux blitter de l'A500, là aussi probablement pour garder une compatibilité avec le A500.

le ST est sorti en 85, le STF en 86, le A500 n'existait donc pas, comment peux-tu les comparer ?
donc le seul "concurrent" était le A1000 donc vous préférez tous taire son existence.

Non le ST avait un meilleurs rapport qualité/prix.

à mon sens, sortir un ordinateur non terminé, avec un WB horrible, un OS buggé, un chipset incomplet, VS un Atari stable et propre, y'a pas photo.
sur le plan de la perf pure, oui A1000 était supérieur, dans la pratique c'était un attrape nigaud à 28000 FF.

[Zarnal]

Sans smiley on pourrait croire que tu es sérieux en disant ça !!

Je vois pas comment un hardware pensé pour qu'un chipset aussi complet puisse tourner ensemble, et donc en ayant maximisé l'utilisation de la bande passante mémoire dispo peut être qualifié de bricolage, alors qu'une machine sortie en 6 mois et même pas capable d'évoluer sans tout faire exploser l'est ?? 

je n'ai jamais vu un ST exploser.  par contre j'ai l'ami d'un copain qui a lu sur un forum polonais que qq a perdu sa maison à cause d'un amiga qui a pris feu.

Un frère du cousin de la belle-soeur a rapporté un ragot infondé venant d'un forum de l'ex URSS. Très fiable en effet comme source.

Une alimentation ST recyclée par un kamarade sans doute(s)...

[dlfrsilver]

Concernant les histoires de compatibilité, je disais que les mauvaises habitudes venant du ST ont été appliquées aux jeux sur Amiga (principalement ceux codés ou transcodés du ST).

Les programmeurs codaient les logiciels sur des Atari. Et c'est bien connu, quand on prend des mauvaises habitudes, on les prends partout. 

Je donnais l'exemple de twinworld, les mecs étaient des programmeurs Ataristes. Ayant désossé le jeu en entier, programme, graphismes et son, le code source de ce soft a été assemblé sur un Atari pour la version amiga. Comme sur ST un bon nombre de logiciel s'appuie sur la rom du TOS au lieu de routines perso incluses dans le programme, ça provoque des problèmes de compatibilité à chaque fois qu'il y a un changement de révision. 

A l'inverse, les logiciels codés directement pour l'Amiga ne font pas dans leur immense majorité appel à la rom 1.3 en accès codé en dur. 

Donc ça tourne sur 500, 500+, 600 et 1200 dans la mesure ou il n'y a pas d'instructions qui posent souci au 68020.

[Invité]

et le même syndrome que l'amiga 1200 : vieux blitter de l'A500, là aussi probablement pour garder une compatibilité avec le A500.

Oui, surtout à la même fréquence de 7.14 mhz, mais la différence étant qu'il était plus facile d'upgrader un chipset ECS bien pensé à l'origine sans avoir un truc bancale et en gardant la compatibilité(même si les perfs ont peu évoluées) que sur falcon où c'est son talon d'achille en bridant le hardware .
En gros avec le 1200 on à une machine du niveau du falcon, avec un prix de base moins cher tout en étant plus facilement évolutif .
Atari aurait du sortir le falcon sans compatibilité ST de merde, surement que la machine aurait été plus performante, et aussi moins chère .
Le DSP faisant bien mieux que le blitter aucun intérêt de le garder,et foutre une mémoire rien que pour l'audio,sur un bus à part pour pouvoir l'utiliser correctement .

[rocky007]

Je donnais l'exemple de twinworld, les mecs étaient des programmeurs Ataristes. Ayant désossé le jeu en entier, programme, graphismes et son, le code source de ce soft a été assemblé sur un Atari pour la version amiga. Comme sur ST un bon nombre de logiciel s'appuie sur la rom du TOS au lieu de routines perso incluses dans le programme, ça provoque des problèmes de compatibilité à chaque fois qu'il y a un changement de révision.

c'est l'inverse justement, c'est en utilisant des routines maisons que l'on rend un programme incompatible

[Invité]

c'est l'inverse justement, c'est en utilisant des routines maisons que l'on rend un programme incompatible

Pas forcément, tout dépend sur quoi s'appuie la routine maison .
S'appuyer sur un bios, c'est bien si tu as la certitude que rien de va changer lors d'une maj (et à l'époque c'était pas garanti du tout),ensuite tu as la quasi certitude d'avoir soit des fonctions buggées ou lentes, ou les 2,c'est pour ça que peu de personnes utilisaient les fonctions bios/roms d'origines (sauf pour les OS) .

[dlfrsilver]

Je donnais l'exemple de twinworld, les mecs étaient des programmeurs Ataristes. Ayant désossé le jeu en entier, programme, graphismes et son, le code source de ce soft a été assemblé sur un Atari pour la version amiga. Comme sur ST un bon nombre de logiciel s'appuie sur la rom du TOS au lieu de routines perso incluses dans le programme, ça provoque des problèmes de compatibilité à chaque fois qu'il y a un changement de révision.

c'est l'inverse justement, c'est en utilisant des routines maisons que l'on rend un programme incompatible

Non mais ça serait bien de me lire correctement Dave pour une fois :

En utilisant des routines maisons, on élimine le problème de compatibilité lié de base aux accès en rom figées en dur. Dès que tu utilises en accès fixe les routines en rom, tu casses automatiquement la compatibilité des kickstarts supérieurs. 

C'est pour ça qu'un bon jeu bien programmé n'a pas de lien avec la rom.

[rocky007]

accès en rom figées en dur

je comprends pas, tu peux donner un exemple concret ?

[stapha92]

en fait c'est là le problème.  les amigaistes veulent pas parler du A1000, du A1200, du A500+, du A600..
donc oui on est obligé à se contenter d'un A500 Vs ST alors que le ST est sur le marché depuis 2 ans.
on ne peut reprocher à Atari des bugs dans ses machines, des ratages des ingénieurs , quand Amiga a lui-même commis les mêmes fautes tout au long de sa carrière

Non pas de problème, on peut comparer les A1000, A500+, A600, A2000 à tous les ST si tu veux : le mig les écrase...

ben oui tout aussi débile que ceux qui dsont choqué que le TOS 1.0 n'exploite pas le Falcon
Je n'ai pas dit que c'était impossible du reste, j'ai dit qu'il fallait le patcher 

On n'a jamais reproché au TOS 1.0 (et tous les tos des 4 ou 5 premières années...) de ne pas exploiter le falcon. On leur reproche de ne pas être compatible avec un autre processeur (même un 68010). Alors que tous les KickStart sont compatibles avec tous les 680x0. Par contre vous reprochez au KS de l'A1000 de ne pas être finalisé alors qu'il était sur disquette ! Comme celui du ST.

le TOS était inclus sur la carte.  le TOS 1.6 gère le 68020, donc oui il n'y avait pas de carte 68020 sur ST avant 1987.  la plupart des les logiciels non compatibles sont comme sur amiga, ceux qui sont mal codés.  et des versions patchées existaient.

il ne faut même pas changer de processeur sur amiga pour avoir des jeux incompatibles, rien qu'entre 500/500+/600 ça foire déjà

Déjà le TOS 1.6 (et même le 1.06), c'est 1989. C'est à dire à l'époque ou, selon vous, les 16 bits n'existent plus... Marrant d'aller contre ses propres arguments... Et il y a l'architecture : quel interet de mettre un 68020 dans une architecture qui bride déjà un 68000 à 16 mhz ? Soyons sérieux : les cartes accélératrice sur ST c'est de la rigolade. Même aujourd'hui les vidéos d'A500 et A600 avec des 68030/40/50 sont nombreuses (avec des jeux et des applis qui les exploitent) alors que du coté ST c'est le désert...

Ensuite sur Amiga les problèmes de compatibilité ne concernent que les jeux. Les applis tournent sans problème. Ce n'est pas le cas du ST.
Je peux même te dire qu'à l'époque la communauté se moquait de l'Amiga Basic (un produit microsoft) qui n'était pas compatible avec les cpu 32 bits car il stocke des choses dans les octets de poids fort des registres d'adressage. ça le rend tout de même compatible avec un 68EC020. Mais ça ne suffisait pas pour les Amiga-istes. C'est dire si le taux de compatibilité était très bon avec les applis. Sinon ce cas ne se serait jamais dégagé...

Par contre c'est vrai que pour les jeux le changement de kickstart posait problème avec les jeux mal écrits (qui ne respectaient pas le principe qu'il n'y a qu'une seule adresse fixe dans l'amigaos). Sur ST aussi : il est connu qu'il y a des TOS plus compatible que d'autres même sur des machines identiques. Et là ce n'est pas que pour les jeux... Je n'aborde même pas la compatibilité GEM uniquement. tu l'as comparé au WB mais ça n'a pas de sens : sur le mig un programme WB peut être lancé sans le WB et vice-versa. Un programme GEM a besoin du GEM pour tourner...

Et sur le mig il y avait des solutions hardware abordables si on tenait a certains jeux. Même des solutions software pour ceux qui avaient une extension mémoire (softkick que j'ai utilisé su rmon 1200 pour quelques vieux jeux). WHDLoad utilise d'ailleurs ce principe et ça marche plutot bien...

Un autre problème avec les jeux concerne le code auto-modifiant ou généré qui est incompatible avec un cache d'instruction. Encore une fois ce n'est pas la faute du mig ou de l'OS. Mais commodore a eu la bonne idée d'inclure dans son boot-menu une option pour le désactiver. Y a ça sur ST ? Ah ben dommage parce que ce type de code est bien plus courant sur ST...

Sur un ST, même un 68000 a 16 Mhz génère des problèmes de compatibilité, c'est dire les problèmes que pose cette architecture : Atari a du inclure un système dans le STE qui lui permette de tourner à 8 Mhz car certaines applications (oui : applications et pas seulement les jeux...) ne tournaient pas sinon...

Franchement : comparer la compatibilité ascendante du mig et du ST ne peut conduire qu'à une victoire écrasante du mig. 

Va voir sur les forums qui parlent de mettre la carte vampire sur un ST. Tous les problèmes rencontrés c'est fou (hard comme soft) ! Alors que dans un mig, aucun problème...
Il y a même des problèmes physiques : des pro-st expliquent que selon les révisions de CM, la carte ne rentre pas de la même façon (et parfois pas du tout). Le processeur n'est pas forcément au même endroit ! Et on compare les révisions de CM amiga et ST ? LOL !!!!
Y en a même qui demandent à ce que le coeur appolo ait une mmu pour qu'il puisse mettre mint ou je ne sais quel os dérivé d'unix (très bonne idée). C'est clair : le TOS est tellement bien que quand un user ST booste son ordi, il ne reve que de le remplacer... Au final, devant l'impasse, la plupart des discussions autour du ST ont ete supprimées du forum apollo (alors que l'équipe était enthousiaste à l'idée de voir sa carte utilisée aussi sur ST !). Et la meilleure solution a été d'adapter EmuTOS au 68080 et de le mettre dans un A600.

Et oui messieurs : le ST le plus rapide qui soit est un amiga !

je ne suis pas d'accord avec toi.  La display a bien un programme qui s'execute, modifiable par l'utilisateur.
certes c'est largement moins perfectionné que la copper, mais malgré tout pas si mal, puisqu'on pouvait déjà avoir 2 résolutions différents sur le même écran ( ce que le shifter est incapable de faire ).
La display list est clairement le concept fondateur de la copper.

je cite  du reste :  ANTIC is a true microprocessor; it has an instruction set, a program, and data. The program for ANTIC is called the display list. 

http://www.atariarchives.org/dere/chapt02.php

du reste, seul 3 ordinateurs utilisent cette technique de display list : le XL, Amstrad PCW et l'Amiga.

https://en.wikipedia.org/wiki/Display_list

Je sais que c'est ce qui est écrit sur pleins de sites. Mais je ne suis pas d'accord avec ça. Déjà on nous parle de commande (et non pas d'instruction, la nuance est subtile mais importante) mais y en a-t-il une qui permet d'ecrire quelque chose ? NON. l'instruction MOV est de loin la plus utilisée sur le copper... En fait, y en a-t-il une qui permette de faire quelque chose que les chipset graphiques des autres micro étaient incapable de faire ? Non plus.

Atari avec la vcs avait conçu un circuit graphique (TIA) capable d'effectuer différent type d'affichage pour le playfield + des sprites (appelés player missile sur l'atari). Par contre ce circuit était incapable de lire les données nécessaires pour le playfield : c'était au cpu de se charger de l'alimenter. Et il devait le faire en synchro avec le balayage de la TV (en anglais on appelle cette technique "racing the beam"). Au moment de sortir l'atari 400/800, les ingénieurs améliorent ce circuit (qui devient alors le CTIA puis le GTIA) mais il n'est toujours pas capable de charger les données donc il a besoin. Plutot que de le transformer davantage, il lui adjoignent un autre circuit (ANTIC) qui lui se chargera de lire les données et d'alimenter GTIA. Afin de pouvoir gérer un mode caractère ou des lignes dédoublées par exemple, il lui donne la capacité de bufferiser une ligne d'affichage (ce que le copper, ou même l'amiga sont incapables de faire). La displaylist représente au final la façon dont ANTIC va alimenter GTIA, lire les données et traiter son buffer. Comme il bufferise une ligne à la fois, on a un échantillon de la playlist pour chaque ligne bufferisée. Donc un seul échantillon pour 2 lignes quand la résolutions est dédoublée verticalement ou pour 8 lignes quand ANTIC affiche un mode texte, etc.... Impossible d'avoir une granularité indépendante de ce buffer.
Et comme TIA (et CTIA ou GTIA) a toujours géré sa palettes et ses sprites tout seul, ANTIC est incapable de modifier la palette ou d'intervenir sur les sprites.

Du coup tu peux avoir plus de 2 résolutions sur un écran : une résolution (et même un mode) différente par ligne bufferisée. Par contre pour un simple raster, il faudra faire intervenir le cpu

Voilà je pense que tu saisi un peu mieux le fonctionnement des displaylist.

Le circuit graphique de l'Amiga est pensé différement dès le départ. Donc pour moi on ne peut pas dire que les display list soient le concept fondateur du copper.

Le shifter ne peut pas changer de résolution pendant l'affichage ? je l'ignorais. C'est pourtant quelque chose dont sont capables la plupart des micros de l'époque.

[rocky007]

Non pas de problème, on peut comparer les A1000, A500+, A600, A2000 à tous les ST si tu veux : le mig les écrase...

sur le plan électronique peut être, pas sur la fiabilité, tu ne vas pas réécrire l'histoire
même les plus grands partisans de l'amiga ici l'admette.  le A1000 n'était pas un produit commercialisable dans cet état

Déjà le TOS 1.6 (et même le 1.06), c'est 1989. C'est à dire à l'époque ou, selon vous, les 16 bits n'existent plus...

roh oui mon dieu, le STE n'est sorti qu'en 89, je pensais 87 ! glups

 Un programme GEM a besoin du GEM pour tourner...

GEM qui se lance en 1 seconde...c'est vrai que c'est dramatique.  c'est comme si aujourd'hui tu étais estomaquer de voir qu'on est obligé de démarrer Windows pour lancer un soft Windows

Il y a même des problèmes physiques : des pro-st expliquent que selon les révisions de CM, la carte ne rentre pas de la même façon (et parfois pas du tout). Le processeur n'est pas forcément au même endroit ! Et on compare les révisions de CM amiga et ST ? LOL !!!!
Y en a même qui demandent à ce que le coeur appolo ait une mmu pour qu'il puisse mettre mint ou je ne sais quel os dérivé d'unix (très bonne idée). C'est clair : le TOS est tellement bien que quand un user ST booste son ordi, il ne reve que de le remplacer...

je n'avais pas moi même de carte accélératrice, mais dans les tests que j'ai pu lire à l'époque, les problèmes de compatibilités sont pas si nombreux que tu le prétends. 

Je sais que c'est ce qui est écrit sur pleins de sites. Mais je ne suis pas d'accord avec ça. Déjà on nous parle de commande (et non pas d'instruction, la nuance est subtile mais importante) mais y en a-t-il une qui permet d'ecrire quelque chose ? NON. l'instruction MOV est de loin la plus utilisée sur le copper... En fait, y en a-t-il une qui permette de faire quelque chose que les chipset graphiques des autres micro étaient incapable de faire ? Non plus.

tu peux remonter jusqu'à la préhistoire si cela te chantes, là n'est pas la question.  on ne compare pas la puissance du Antic VS Copper.  Que ce soit des instructions ou des commandes, cela ne change pas le fait que c'est un circuit vidéo programmable, qui exécute un programme, indépendant du CPU.  alors appelles cela "programme" ou "liste de commandes", cela ne change rien au fait qu'il est autonome du CPU et qu'il est programmable  ( ou "commandable" si tu préfères )

[Zarnal]

Bonsoir rocky. Je ne comprends rien à tes explications techniques. Peux tu être plus explicite ?

[cryodav76]

un effet jamais vu sur st :son,scrolling parallaxe,balle ombrée https://youtu.be/OK_U9UnZoNs?t=44

[cryodav76]

j'adore cette music

[Meditating Guru]

L'affichage va deux fois trop vite d'après ton tableau (16 pixels en 8 cycles CPU), c'est pourquoi je demande des explications.

Punaise... Qu'est-ce qu'il y a de compliqué dans mes explications ??!!! Des gens qui disent ne pas connaitre grand chose en hardware ont dit qu'ils les avaient comprises !

Extrait :
ST :
  Cycle CPU
  Cycle CPU
  Cycle vidéo
  Cycle vidé

Amiga
  Cycle CPU
  Cycle vidéo
  Cycle CPU
  Cycle vidéo

Autant de cycle pour autant de pixels. Ou vois-tu que l'affichage va 2 fois trop vite ???!!!

Je faisais référence à ce tableau incorrect:

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

Au cycle 7, tu affiches 16 pixels, au cycle 15, tu affiches les 16 pixels suivants.
C'est pas deux fois trop vite?
Peut-être que ceux qui ont "compris", ils n'ont rien compris, ils étaient juste d'accord avec ton génie parce que ça allait dans leur sens (casser le ST avec des faux arguments)?

Décidément... tu ne réponds plus à grand chose (a court d'arguments ?)... Tu pourrais au moins le faire correctement.

Puisque tu dis sans cesse que je n'y connais rien et ne comprends rien, mieux vaut limiter les thèmes de discussion à quelques points où je n'obtiens pas satisfaction, malgré mon insistance.
Je te laisse croire ce que tu veux pour le reste, j'ai suffisamment expliqué mon point de vue (ex: Pac Mania).

Donc j'affiche au cycles 7 et 15. Donc à chaque fois que le circuit vidéo a fait 4 accès. Tu comprends jusque là ? Ok continuons.
Le circuit lit 16 bits à la fois (pourtant pas compliqué, c'est ecrit dans le tableau soi-disant "incorrect"). Donc 4 accès fois 16 bits = 64 bits. Toujours d'accord ?
Maintenant un pixel avec 4 bitplan occupe 4 bits. (C'est une évidence mais comme c'est le cas de toute l'explication je suis obligé de tout détailler...). Donc 16 pixels occupent 64 bits.
Ooooohhhh c'est pile poil ce que le circuit a lu !!!!!!!! Quel hasard !!!!!
Ceux qui ont compris n'avaient pas tes lunettes d'atariste plutot... Parce que tu te moques d'eux (note que je suis sur que des tas d'atariste ont tout à fait compris : ils n'ont pas tous tes lunettes...) mais à un moment ou un autre tu vas finir par réaliser que c'est toi qui ne comprend pas un truc tout simple...

Le pire c'est que le ST va tout aussi vite ! Donc tu devrais le voir être lui aussi 2x trop rapide ! Ce n'est pas la vitesse le problème mais la répartition (et le fait qu'elle reste identique meme en dehors de l'affichage...)! Tu dis toi-même que les instructions du ST sont arrondies au multiple de 4 supérieur : tu n'as jamais compris pourquoi ??!!! C'est précisément ce que le post de ce tableau explique ! Puisque tu connais la conclusion, tu aurais pu supposer que le raisonnement est bon !  Non, même pas !

Sur ST, en basse résolution, l'affichage est de 16 pixels par 16 cycles CPU.
Tu dis que l'Amiga va à la même vitesse.
Or, dans ton tableau, tu affiches 32 pixels en 16 cycles.
J'en conclus que ton tableau est incorrect.

C'est la deuxieme fois que je me trompe (et encore parce que j'admet que Paradox a tort mais fais des essais et comptes les cycles...). Comparé à toutes les inepties que tu as sortie je m'en tire très bien.
J'ai recherché et c'est vrai, le scroll se fait à la ligne (pas au pixel hein ? )

C'est indiqué par Paradox :

! The Atari STE shifter has a slight timing problem regarding the
Pixel Skip Register. Whenever this registers "jumps" from a value
>"0" to "0", the STE might display the wrong screen address.
This is a known problem and Atari affirms it.
Atari officially suggests to NOT set the Pixel Skip register in
the VBL as this causes the problem. Since changes on this
register have immediate effect, Atari suggests to use a HBL
routine that sets all registers connected to Video hardware
not in the VBL but in (for example) a HBL interrupt after the
VBL.

Tiens donc ! Un bug (reconnu par Atari, donc tu ne peux plus dire que c'est Paradox cette fois) dans le STE ! Pas foutu de mettre un scroll horizontal qui marche convenablement ! Et tu nous disais de ne pas critiquer les ingé Atari car ils avaient fait un  boulot parfait !

Je me trompe ou tu te bases encore sur la doc douteuse de Paradox en la prenant pour vérité parce que ça semble aller dans ton sens?
D'après moi, ce qu'il dit, c'est n'importe quoi ici aussi. A chaque fois tu te laisses prendre comme un fanboy.

Comme je l'ai déjà indiqué, le scrolling horizontal peut-être changé à tout moment.
S'il est différent de 0, le STE ajoute ce qu'il faut au compteur video en fin de ligne pour tenir compte du bout de ligne ajouté (l'équivalent de 16 pixels, variable selon la résolution), ce qui est logique.
Un registre permet d'ajuster le nombre de mots à ajouter en fin de ligne.
Donc si on passe de 0 à non 0 et vice versa, il faut adapter ce registre aussi. Ce n'est pas un bug, évidemment.

Et si tu n'as pas connu Cannon fodder ben là je ne peux plus rien pour toi.
Au fait, pourquoi jouer à un jeu en inferior? (chaos engine sur ST? :-) )

Ce n'est pas mon genre de dénigrer ce que je n'ai pas connu personnellement, mais il semble que le niveau de difficulté soit très mal dosé sur Cannon Fodder, ce qui est une tare typique des jeux Amiga: aucun gameplay (sauf les portages Atari ST), ça la fout mal pour une console à disquette.

Chaos Engine est semblable sur ST et Amiga, sauf que sur Amiga il y a une musique débile et les bruitages sont (à nouveau) d'un seul côté. Amiga, la poubelle stereo.
Sur ST, je dis pas si mal pour un ordinateur supposé "mort" (en 1993).

[dlfrsilver]

accès en rom figées en dur

je comprends pas, tu peux donner un exemple concret ?

Tu comprends pas quand je t'explique que le kickstart de l'Amiga, est tout bêtement une suite de routines en rom ? 

Que chacune de ces routines a un offset fixe (exemple $FFC356). Si un programme mal écrit parce que codé par un programmeur ayant l'habitude du ST (c'est d'eux que ça vient, faut pas chercher). 

Dans le kick 1.3, la routine clavier est en $FFC356 (un exemple, c'est pas la véritable adresse). Dans le Kick 2.0, pas de bol, cette même routine est en $FFD678. Résultat, comme le programmeur a codé la demande d'accès en dur (LEA $FFC356 dans le programme), hé ben le mec qui possède un amiga avec un kick v2.0, devine ce qui va se produire quand ce programme mal codé par aller taper à l'adresse $FFC356 dans la rom du kick 1.3 ? Simple : Guru Meditation ou plantage du programme ou malfunction comme dans twinworld, ou encore le jeu qui se bloque dès que t'appuies sur une touche du clavier.

Ce qu'il faut comprendre, c'est qu' à l'adresse $FFC356 dans un kick v2.0, t'es en plein milieu d'une routine qui n'est pas celle attendue. Donc c'est garanti que ça va merder.

Et c'est ce qui se produit quand un accès est codé en dur ou quand un programmeur force le programme à faire un accès direct à un offset précis en ROM. 

Les routines sont déplacés entre chaque révision de kickstart, sans parler de celle qui ont été modifiées, réécrites, ou voir encore qui sont plus petites que précédemment ou encore plus grosse. Les offsets d'accès changent, donc c'est clair, le programmeur ST semi-débile qui fait comme sur ST à faire des accès absolu au lieu de les faire en mode relatif voir carrément de bannir le linking avec les routines en rom, ben voilà, ça donne des logiciels qui merdent !

Stapha92 confirmera sans problème ce que je viens de te dire.

[rocky007]

j'adore cette music

elle serait tellement mieux en 50Khz

[rocky007]

Tu comprends pas quand je t'explique que le kickstart de l'Amiga, est tout bêtement une suite de routines en rom ? 

Que chacune de ces routines a un offset fixe (exemple $FFC356). Si un programme mal écrit parce que codé par un programmeur ayant l'habitude du ST (c'est d'eux que ça vient, faut pas chercher). 

Dans le kick 1.3, la routine clavier est en $FFC356 (un exemple, c'est pas la véritable adresse). Dans le Kick 2.0, pas de bol, cette même routine est en $FFD678. Résultat, comme le programmeur a codé la demande d'accès en dur (LEA $FFC356 dans le programme), hé ben le mec qui possède un amiga avec un kick v2.0, devine ce qui va se produire quand ce programme mal codé par aller taper à l'adresse $FFC356 dans la rom du kick 1.3 ? Simple : Guru Meditation ou plantage du programme ou malfunction comme dans twinworld, ou encore le jeu qui se bloque dès que t'appuies sur une touche du clavier.

Ce qu'il faut comprendre, c'est qu' à l'adresse $FFC356 dans un kick v2.0, t'es en plein milieu d'une routine qui n'est pas celle attendue. Donc c'est garanti que ça va merder.

Et c'est ce qui se produit quand un accès est codé en dur ou quand un programmeur force le programme à faire un accès direct à un offset précis en ROM. 

Les routines sont déplacés entre chaque révision de kickstart, sans parler de celle qui ont été modifiées, réécrites, ou voir encore qui sont plus petites que précédemment ou encore plus grosse. Les offsets d'accès changent, donc c'est clair, le programmeur ST semi-débile qui fait comme sur ST à faire des accès absolu au lieu de les faire en mode relatif voir carrément de bannir le linking avec les routines en rom, ben voilà, ça donne des logiciels qui merdent !

y'en encore des gens qui font ça sur amiga ?  mais c'est horrible !  note que ça m'étonne qu'à moitié....

[stapha92]

sur le plan électronique peut être, pas sur la fiabilité, tu ne vas pas réécrire l'histoire
même les plus grands partisans de l'amiga ici l'admette.  le A1000 n'était pas un produit commercialisable dans cet état

Bien sur...

GEM qui se lance en 1 seconde...c'est vrai que c'est dramatique.  c'est comme si aujourd'hui tu étais estomaquer de voir qu'on est obligé de démarrer Windows pour lancer un soft WindowsGEM qui se lance en 1 seconde...c'est vrai que c'est dramatique.  c'est comme si aujourd'hui tu étais estomaquer de voir qu'on est obligé de démarrer Windows pour lancer un soft Windows

Non ce n'est pas de ça dont je parle c'est du fait que quand on lit "compatible avec les programmes GEM", ça limite fortement la compatibilité. Beaucoup d'applications TOS ne sont pas GEM. Des fois c'est parce que le GEM est bien trop lent que ce choix est fait. Comme ton sacro saint GFA...
Oui une seconde à se lancer, mais après quelle lenteur...
Sur le mig y a pas de compatibilité limitée au WB. Tu as dit que ça revenait au meme : pas du tout...

tu peux remonter jusqu'à la préhistoire si cela te chantes, là n'est pas la question.  on ne compare pas la puissance du Antic VS Copper.  Que ce soit des instructions ou des commandes, cela ne change pas le fait que c'est un circuit vidéo programmable, qui exécute un programme, indépendant du CPU.  alors appelles cela "programme" ou "liste de commandes", cela ne change rien au fait qu'il est autonome du CPU et qu'il est programmable  ( ou "commandable" si tu préfères )

Je t'ai fait l'histoire des playlist et d'ANTIC pour t'expliquer comment c'était né. Je ne parle pas d'autonomie, je parle du fait que quand on la connait, on se rend bien compte que non : le copper n'est pas basé sur ANTIC. Il n'en n'est absolument pas une évolution.
Mais si tu penses le contraire libre à toi. ça ne me pose aucun problème : j'adore le XL (et pour le coup je n'ai aucun mal reconnaitre que le C64 est globalement meilleur)

accès en rom figées en dur

je comprends pas, tu peux donner un exemple concret ?

Sur le mig l'api de l'OS est partagée en librairies. Pour en utiliser une il faut l'ouvrir via une fonction de la librairie Exec (qui est la seule qui est déjà ouverte et dont l'adresse de base est constante) : OpenLibrairie()
On donne à cette fonction le nom et la version (minimum) de la librairie que l'on souhaite utiliser. La fonction renvoie l'adresse de base de la librairie (ou null si elle ne l'a pas trouvé ou n'a pas trouvé de version assez haute). Elle s'occupera même de charger la librairie depuis la disquette ou le HD si besoin. Tout est transparent pour le codeur.
Ensuite c'est à partir de cette adresse de base qu'on appelle les fonctions. On utilise un système de constante fourni par Commodore qui permet d'avoir un code clair même en assembleur. Et la norme veut qu'on mette l'adresse de base dans A6. Ainsi un appel à une fonction est de la forme :
 JSR fonction(A6).

Et  bien des petits malin s'amusaient à appeler directement les fonctions en mettant leur adresse en dur. Sauf que quand la librairie change d'adresse de base, ça ne marche plus. ça n'apporte rien du tout (à part economiser les octets du nom de la librairie...), mais ça a été fait. 

C'est ça les accès en dur dont parle Dlfrsilver

Décidément... tu ne réponds plus à grand chose (a court d'arguments ?)... Tu pourrais au moins le faire correctement.

Puisque tu dis sans cesse que je n'y connais rien et ne comprends rien, mieux vaut limiter les thèmes de discussion à quelques points où je n'obtiens pas satisfaction, malgré mon insistance.
Je te laisse croire ce que tu veux pour le reste, j'ai suffisamment expliqué mon point de vue (ex: Pac Mania).

Je te pensais capable de trouver mieux comme esquive... Mais ok comme  tu veux ! 

Donc j'affiche au cycles 7 et 15. Donc à chaque fois que le circuit vidéo a fait 4 accès. Tu comprends jusque là ? Ok continuons.
Le circuit lit 16 bits à la fois (pourtant pas compliqué, c'est ecrit dans le tableau soi-disant "incorrect"). Donc 4 accès fois 16 bits = 64 bits. Toujours d'accord ?
Maintenant un pixel avec 4 bitplan occupe 4 bits. (C'est une évidence mais comme c'est le cas de toute l'explication je suis obligé de tout détailler...). Donc 16 pixels occupent 64 bits.
Ooooohhhh c'est pile poil ce que le circuit a lu !!!!!!!! Quel hasard !!!!!
Ceux qui ont compris n'avaient pas tes lunettes d'atariste plutot... Parce que tu te moques d'eux (note que je suis sur que des tas d'atariste ont tout à fait compris : ils n'ont pas tous tes lunettes...) mais à un moment ou un autre tu vas finir par réaliser que c'est toi qui ne comprend pas un truc tout simple...

Le pire c'est que le ST va tout aussi vite ! Donc tu devrais le voir être lui aussi 2x trop rapide ! Ce n'est pas la vitesse le problème mais la répartition (et le fait qu'elle reste identique meme en dehors de l'affichage...)! Tu dis toi-même que les instructions du ST sont arrondies au multiple de 4 supérieur : tu n'as jamais compris pourquoi ??!!! C'est précisément ce que le post de ce tableau explique ! Puisque tu connais la conclusion, tu aurais pu supposer que le raisonnement est bon !  Non, même pas !
   

Sur ST, en basse résolution, l'affichage est de 16 pixels par 16 cycles CPU.
Tu dis que l'Amiga va à la même vitesse.
Or, dans ton tableau, tu affiches 32 pixels en 16 cycles.
J'en conclus que ton tableau est incorrect.

Déjà ton terme de cycle cpu ne veut rien dire mais bon.
Sur le ST, pour afficher 16 pixel, le shifter a besoin de 4 cycles : c'est une puce 16 bits (tu es au courant non ?) Et en basse résolution il y a 4  bitplans (tu es au courant aussi non ?). 
Comme le shifter partage les cycles avec le CPU moitié-moitié, cela fait 2x4 = 8 cycles "cpu" et pas 16...

Moi j'en conclus que tu te trompes depuis le début, après nous avoir dit que tu connaissais bien le ST. Qu'est-ce que ce serait dans le cas contraire...

Je me trompe ou tu te bases encore sur la doc douteuse de Paradox en la prenant pour vérité parce que ça semble aller dans ton sens?
D'après moi, ce qu'il dit, c'est n'importe quoi ici aussi. A chaque fois tu te laisses prendre comme un fanboy.

Comme je l'ai déjà indiqué, le scrolling horizontal peut-être changé à tout moment. 
S'il est différent de 0, le STE ajoute ce qu'il faut au compteur video en fin de ligne pour tenir compte du bout de ligne ajouté (l'équivalent de 16 pixels, variable selon la résolution), ce qui est logique.
Un registre permet d'ajuster le nombre de mots à ajouter en fin de ligne.
Donc si on passe de 0 à non 0 et vice versa, il faut adapter ce registre aussi. Ce n'est pas un bug, évidemment.

Ouh là ouh là ! Tu confonds totalement là : le pixel skip register permet de faire un scrolling au pixel près et toi tu me parles du registre de modulo...

Bon arretons là : tu ne maitrises visiblement pas assez les sujets que tu abordes...

Juste une chose, parce que tu as attaqué Paradox :

This is a known problem and Atari affirms it.
Atari officially suggests to NOT set the Pixel Skip register in
the VBL as this causes the problem.

Atari le reconnait et dit comment éviter le problème. Tu critiques Paradox (et moi aussi mais mais là c'est pas grave, c'est même de bonne guerre ) mais tu trouves normal que changer le nombre de pixel à eviter lors de l'affichage puisse poser problème quand il n'y a justement pas d'affichage... Qu'est-ce que ça aurait été si Atari avait ajouté l'overscan dans le STE... Il auraient conseillé un reboot à chaque pas de scroll ?

Sur le mig ce registre ne pose aucun soucis, alors que le circuit video a beaucoup plus de choses à gérer. Il est ou le bricolage ?

[stapha92]

Tu comprends pas quand je t'explique que le kickstart de l'Amiga, est tout bêtement une suite de routines en rom ? 

Que chacune de ces routines a un offset fixe (exemple $FFC356). Si un programme mal écrit parce que codé par un programmeur ayant l'habitude du ST (c'est d'eux que ça vient, faut pas chercher). 

Dans le kick 1.3, la routine clavier est en $FFC356 (un exemple, c'est pas la véritable adresse). Dans le Kick 2.0, pas de bol, cette même routine est en $FFD678. Résultat, comme le programmeur a codé la demande d'accès en dur (LEA $FFC356 dans le programme), hé ben le mec qui possède un amiga avec un kick v2.0, devine ce qui va se produire quand ce programme mal codé par aller taper à l'adresse $FFC356 dans la rom du kick 1.3 ? Simple : Guru Meditation ou plantage du programme ou malfunction comme dans twinworld, ou encore le jeu qui se bloque dès que t'appuies sur une touche du clavier.

Ce qu'il faut comprendre, c'est qu' à l'adresse $FFC356 dans un kick v2.0, t'es en plein milieu d'une routine qui n'est pas celle attendue. Donc c'est garanti que ça va merder.

Et c'est ce qui se produit quand un accès est codé en dur ou quand un programmeur force le programme à faire un accès direct à un offset précis en ROM. 

Les routines sont déplacés entre chaque révision de kickstart, sans parler de celle qui ont été modifiées, réécrites, ou voir encore qui sont plus petites que précédemment ou encore plus grosse. Les offsets d'accès changent, donc c'est clair, le programmeur ST semi-débile qui fait comme sur ST à faire des accès absolu au lieu de les faire en mode relatif voir carrément de bannir le linking avec les routines en rom, ben voilà, ça donne des logiciels qui merdent !

y'en encore des gens qui font ça sur amiga ?  mais c'est horrible !  note que ça m'étonne qu'à moitié....

Bien joué...

[babsimov]

Te répéter tu es fort pour ça 
Tu repètes même souvent les mêmes inepties sur l'Amiga (alors qu'on a maintes fois montré que c'était des inepties).

n'inverse pas les rôles, le maître dans cet art, c'est bien toi, tu es mon mentor

Un bon exemple de ce que j'avance, ta réponse un peu plus haut concernant Jay Miner qui aurait dit qu'il voulait faire une console. Quelques pages auparavant tu avais cité, partiellement, son interview, juste le passage qui pouvait accréditer ta thèse. Hors, dès le début de l'interview (une fois qu'on la lit au complet), Jay Miner dit bien qu'il avait toujours voulu créer un super ordinateur autour du 68000. 

Et donc, malgré que (une fois de plus, car cette interview tronquée tu t'en sert souvent) j'ai cité l'interview complète pour corriger ton "approximation", tu ne sembles pas avoir de mémoire. Pourtant c'était y a pas très longtemps.

Quant à Commodore, ils ont présenté l'Amiga comme une console avec l'Amiga 1000 à sortie ? Je ne crois pas. Mais comme on est habitué à ce que tu racontes n'importe quoi...

Mais je sais bien que Byte à maintes fois dit du bien de l'Amiga, pas besoin de toi pour ça.
Je dis juste que ta citation de ce numéro de Byte omettait les points qui ne t'arrangeais pas, comme bien souvent.
Mais, ta réputation est déjà faites sur ce point.

j'ai cité ma source dans le cadre de mon intervention , qui est pour la rappel : le top 20 softwate... je ne parlais pas du chipset ou autre... juste du software, donc je cite la source pour celle-ci.  je note que tu n'as pas jamais cité de source pour la laser Atari non plus.

Je parle de mémoire pour la laser, tu veux quand même pas que je recherche dans toutes les revues de l'époque pour retrouver ce test ? Je ne suis même plus sur de laquelle il s'agissait. Si ça se trouve je l'avais juste feuilleté en librairie. D'ailleurs, n'ais je pas dit que j'étais d'accord, pour l'imprimante laser, c'était une belle prouesse, juste que la revue avait émis quelques critiques sur le fait que du coup la mémoire était prise sur celle du ST, donc il fallait quasiment un MégaST 4 pour en profiter et juste que c'était exclusif à Atari. Mais, je ne dis nullement que je ne trouvais pas ses choix intéressants pour tirer les prix.

Tu penses que toutes la presse était en admiration devant Atari, il est bien logique qu'un test donne des plus et des moins, non ?

Parce qu'il n'y avait pas des problème d'incompatiblité entre les version de TOS ? Surtout quand les programmeurs n'ont pas respectés les consignes ? C'est ce qu'il expliquait pour les version de Kickstart. Ce n'est nullement la faute de Commodore, mais bien celle du programmeur.
Le Kicstart respectait les consignes de Motorola, résultat compatible 32 bits d'origine.

ah mais moi je ne dis pas le contraire, je t'explique simplement que c'est pas mieux sur amiga et que dès lors, critiquer le TOS est un peu ridicule 
et d'après les explications de dlfrsilver, qui est je te rappelle un spécialiste confirmé, les changements dans le kickstart du A600/A500+ sont problématique et n'ont rien à voir avec des jeux mal codés.

Comme critiqué l'AmigaOS alors, c'est tout aussi ridicule.

Ben relis, tu verras que c'est bien ce qu'il explique, c'est du à des jeux mal codés, en plus il t'explique ça en détail et tu ne comprends pas.

Et je cite :

@rocky007 a écrit:

accès en rom figées en dur

je comprends pas, tu peux donner un exemple concret ?

Tu comprends pas quand je t'explique que le kickstart de l'Amiga, est tout bêtement une suite de routines en rom ? 

Que chacune de ces routines a un offset fixe (exemple $FFC356). Si un programme mal écrit parce que codé par un programmeur ayant l'habitude du ST (c'est d'eux que ça vient, faut pas chercher). 

Dans le kick 1.3, la routine clavier est en $FFC356 (un exemple, c'est pas la véritable adresse). Dans le Kick 2.0, pas de bol, cette même routine est en $FFD678. Résultat, comme le programmeur a codé la demande d'accès en dur (LEA $FFC356 dans le programme), hé ben le mec qui possède un amiga avec un kick v2.0, devine ce qui va se produire quand ce programme mal codé par aller taper à l'adresse $FFC356 dans la rom du kick 1.3 ? Simple : Guru Meditation ou plantage du programme ou malfunction comme dans twinworld, ou encore le jeu qui se bloque dès que t'appuies sur une touche du clavier.

Ce qu'il faut comprendre, c'est qu' à l'adresse $FFC356 dans un kick v2.0, t'es en plein milieu d'une routine qui n'est pas celle attendue. Donc c'est garanti que ça va merder.

Et c'est ce qui se produit quand un accès est codé en dur ou quand un programmeur force le programme à faire un accès direct à un offset précis en ROM. 

Les routines sont déplacés entre chaque révision de kickstart, sans parler de celle qui ont été modifiées, réécrites, ou voir encore qui sont plus petites que précédemment ou encore plus grosse. Les offsets d'accès changent, donc c'est clair, le programmeur ST semi-débile qui fait comme sur ST à faire des accès absolu au lieu de les faire en mode relatif voir carrément de bannir le linking avec les routines en rom, ben voilà, ça donne des logiciels qui merdent !


Stapha92 confirmera sans problème ce que je viens de te dire.



Et un peu avant, dlfrsilver avait précisé :
Concernant les histoires de compatibilité, je disais que les mauvaises habitudes venant du ST ont été appliquées aux jeux sur Amiga (principalement ceux codés ou transcodés du ST).

Les programmeurs codaient les logiciels sur des Atari. Et c'est bien connu, quand on prend des mauvaises habitudes, on les prends partout. 

Je donnais l'exemple de twinworld, les mecs étaient des programmeurs Ataristes. Ayant désossé le jeu en entier, programme, graphismes et son, le code source de ce soft a été assemblé sur un Atari pour la version amiga. Comme sur ST un bon nombre de logiciel s'appuie sur la rom du TOS au lieu de routines perso incluses dans le programme, ça provoque des problèmes de compatibilité à chaque fois qu'il y a un changement de révision. 

A l'inverse, les logiciels codés directement pour l'Amiga ne font pas dans leur immense majorité appel à la rom 1.3 en accès codé en dur. 

Donc ça tourne sur 500, 500+, 600 et 1200 dans la mesure ou il n'y a pas d'instructions qui posent souci au 68020.

Et en plus tu insistes, montrant que t'a rien compris :

@rocky007 a écrit:

@dlfrsilver a écrit:
Je donnais l'exemple de twinworld, les mecs étaient des programmeurs Ataristes. Ayant désossé le jeu en entier, programme, graphismes et son, le code source de ce soft a été assemblé sur un Atari pour la version amiga. Comme sur ST un bon nombre de logiciel s'appuie sur la rom du TOS au lieu de routines perso incluses dans le programme, ça provoque des problèmes de compatibilité à chaque fois qu'il y a un changement de révision.

c'est l'inverse justement, c'est en utilisant des routines maisons que l'on rend un programme incompatible

Non mais ça serait bien de me lire correctement Dave pour une fois :

En utilisant des routines maisons, on élimine le problème de compatibilité lié de base aux accès en rom figées en dur. Dès que tu utilises en accès fixe les routines en rom, tu casses automatiquement la compatibilité des kickstarts supérieurs. 

C'est pour ça qu'un bon jeu bien programmé n'a pas de lien avec la rom.


Ne pas respecter les consignes de programmations semble être une règles sur Atari, puisque pour toi c'est la meilleure option. D'ailleurs Atari à montré l'exemple puisqu'ils n'ont pas respecté les consignes de Motorola pour les instructions à ne pas utiliser pour l'avenir. On a vu donc que ce n'était pas la bonne solution, puisque le TOS est incompatible avec autre chose qu'un 68000, sans devoir être réécrit. Tu trouves ça bien, personnellement je trouve ça "cavalier".

L'Amiga avait Lightwave, Deluxe paint, Scala multimédia et d'autres qui ne me reviennent au premier abord.

j'ai rien vu de tout cela dans BYTE en effet, ni de Cubase ou de Calamus.

Donc argument totalement de mauvaise foi de ta part, puisque Byte ne s'est pas intéressé à autre chose qu'à la logithèque MAC/PC de l'époque.

Et je t'ai déjà répondu sur ce point, le PC c'était encore plus facile les jeux gratuits... la preuve tu as fuis sur PC pour ça...

mais le PC plus cher.  donc amiga c'était une console au rabais avec les jeux gratuits, parfait pour les enfants comme cadeau de noël

Et le PC ne se vendait pas à cette époque, il a commencé à décoller à cette époque, alors qu'il était plus cher. C'est quoi qui l'a fait décoller, la bureautique ou les jeux gratuits ? Je penche quand même pour les jeux gratuits.

Si ça peut te convaincre, te rassurer de répéter "Amiga et console" dans la même phrase, que veux tu que je te dise. Rassure toi comme tu peux alors.

Et comment que tous les jours je me faisait la réflexion, qu'est ce que c'est bien AmigaOS. Ce n'est pas pour rien que je suis resté sur Amiga jusqu'en 1998 et que je continue à défendre son OS encore de nos jours (et aussi à l'époque face aux PCistes).

eh ben tu as eu du courage..bravo à toi.  du reste, pourquoi as tu changé finalement ?

Relis tu verras que je ne suis pas le seul a être resté aussi longtemps sur Amiga, il y en a même qui sont resté encore après.

Pourquoi avoir changé ? Parce que je voyais bien que les repreneurs successifs ne tenaient pas leurs promesses. J'avais envisagé les cartes powerPC etc... mais pour quoi faire, quasiment plus rien ne sortait à ce moment là, et pas grand chose en PowerPC. 
Par la force des choses, il a bien fallu que je passe sur PC (le MAC était exclu pour moi, d'autant plus qu'il était encore monotâche à ce moment là). Et puis, il y a eu LE jeu que je voulais absolument "Civilization Call To Power". Il me fallait donc un PC pour y jouer. Ce fut d'ailleurs une déception ce jeu. 
Pendant la première année j'ai gardé mon Amiga en parallèle, j'avais une configuration WinUAE aussi et puis petit à petit, la puissance ne suivait plus sur l'Amiga, les navigateurs internet sur Amiga n'étaient plus à jours etc etc... Bref, le PC est devenu incontournable, hélas. Mais ce ne fut qu'à partir de WindowsXP avec beaucoup de RAM que j'ai commencé à moins pester sur le PC, puis Vista et surtout Seven m'ont permis de retrouver le multitâche que j'avais connu sur Amiga. Mais la personnalisation du système on en est encore très très loin.

Ce qui me gène, c'est que je sais que le PC était la moins bonne solution (y compris son processeur) et que c'est ça qui s'est imposé. C'est affligeant. 

oui donc c'est purement psychologique.  au fait sais tu pourquoi motorola a arrêté ses proc ?  parce qu'ils étaient moins rapide que ceux d'intel et qu'ils ne savaient plus suivre

Non ce n'est pas psychologique. En tant qu'utilisateur ST, tu devrais savoir que le 68000 était une rolls face aux x86. D'ailleurs, sortit d'IBM (et compatible) quelle autre standard informatique à utilisé le x86 à l'époque. Je te rappel qu'IBM voulait le 68000 au départ pour son PC, le x86 c'était parce que c'était moins cher et qu'il avait déjà un environnement de développement plus étoffé, ce qui permettait de sortir la machine plus vite.

Motorola avait surtout moins de moyens qu'Intel sur la fin pour faire évoluer ses processeurs. Surtout qu'ils avaient fait l'erreur de passer du 680x0 au PowerPC, alors qu'ils avait un très bon processeur avec le 68000. Il aurait été tout à fait possible de faire évoluer le 680x0 comme le x86... il suffit de voir l'Apollo Core en FPGA.

Mais tu sais bien qu'un Amigaïste c'est pas très futé et très premier degré. Donc je suis content que tu finisses pas admettre la supériorité du Workbench  

je préfère encore qu'on me coupe un bras que dire une telle affirmation

Je n'irais pas jusque là, mais ta phrase étaient pourtant claire, mais on parlait face à Windows ? Tu es soulagé dans ce cas. Je suppose que tu considère GEM supérieur à Windows95 ?

Mais le C64 est bien dans ce numéro, y compris avec le SID. Pas de trace du ST (même comme mention) ou du YM. 

à ce que je sache, le SID n'est pas un ordinateur.  on ne parle pas ici du software ou hardware du ST, on parle simplement du fait que CP/M est repris dans le top 20, pas le workbench/amigaos. L'amiga n'est que salué de loin lorsqu'on parle de l'ensemble de la machine.  raison pour laquelle personne n'a jamais voulu racheter ou adapter AmigaOS/WB sur un autre machine, personne n'en voulait

Dec voulait porter l'AmigaOS sur son processeur Alpha à l'époque (refus de Commodore, bien sur). Dec avait le processeur le plus rapide du marché pour ses stations de travail, c'est surement pas assez bien pour toi ?
http://www.amigahistory.plus.com/adec.html

Et IBM a passé un accord avec Commodore pour regarder les sources de l'AmigaOS pour s'en inspirer pour OS/2. En échange Commodore obtenait le droit de porter le langage Rexx sur Amiga, ce qui devenu Arexx dans l'AmigaOS 2.0. Tu vas me dire quoi qu'Arexx n'existait pas ?

Pour le CP/M déjà répondu, il fut bien en son temps, logique qu'il soit dans la liste. L'AmigaOS et l'Amiga son indissociable, c'est l'OS fournit en standard. Ils en parlent donc en parlant de l'Amiga1000. Mais, le TOS, descendant du CP/M, ils l'abordent ? Je ne pense pas.

Au fait, tu peux donner le liens vers l'article de Byte ?

ben c'est dans les pages que tu as toi même citée

Au temps pour moi 

C'est ça, ils parlent explicitement de son multitâche, comme l'une de ses forces pour l'époque, mais c'est pas parler de son OS.

non ils disent que l'amiga est un bon ordinateur dans son ensemble, et qui est multitâche.  ils vantent le mérite de l'ordinateur dans sa globabilité, et non pour une GUI exceptionnelle.

Ils parlent de "multitasking windowing OS", donc la GUI est bien mentionnée. Tu disais que l'Amiga n'était pas mentionné dans ce numéro... il l'est. Tu devrais arrêter la mauvaise foi, tu as voulu utiliser une citation partielle de ce numéro pour aller dans ton sens, c'est tout. Ca c'est vu et tu cherches une pirouette. Par ailleurs si une machine est bonne dans sa globalité, c'est que tout ses éléments ont été jugé suffisamment bon pour qu'elle soit retenue.

Un vaporware est rarement à la hauteur des attentes.

si la preuve : Win95  

T'es bien est des rares à en être persuadé 

En tout cas, on voit bien que Stapha92 est doué aussi pour l'orthographe 

je sais pas si tu as des filles, mais je pense qu'il ferait un bon parti

Un tel parti est forcément déjà pris 

[Meditating Guru]

Décidément... tu ne réponds plus à grand chose (a court d'arguments ?)... Tu pourrais au moins le faire correctement.

Puisque tu dis sans cesse que je n'y connais rien et ne comprends rien, mieux vaut limiter les thèmes de discussion à quelques points où je n'obtiens pas satisfaction, malgré mon insistance.
Je te laisse croire ce que tu veux pour le reste, j'ai suffisamment expliqué mon point de vue (ex: Pac Mania).

Je te pensais capable de trouver mieux comme esquive... Mais ok comme  tu veux ! 

Ce n'est pas une esquive, d'ailleurs tu persistes dans ce message.

Donc j'affiche au cycles 7 et 15. Donc à chaque fois que le circuit vidéo a fait 4 accès. Tu comprends jusque là ? Ok continuons.
Le circuit lit 16 bits à la fois (pourtant pas compliqué, c'est ecrit dans le tableau soi-disant "incorrect"). Donc 4 accès fois 16 bits = 64 bits. Toujours d'accord ?
Maintenant un pixel avec 4 bitplan occupe 4 bits. (C'est une évidence mais comme c'est le cas de toute l'explication je suis obligé de tout détailler...). Donc 16 pixels occupent 64 bits.
Ooooohhhh c'est pile poil ce que le circuit a lu !!!!!!!! Quel hasard !!!!!
Ceux qui ont compris n'avaient pas tes lunettes d'atariste plutot... Parce que tu te moques d'eux (note que je suis sur que des tas d'atariste ont tout à fait compris : ils n'ont pas tous tes lunettes...) mais à un moment ou un autre tu vas finir par réaliser que c'est toi qui ne comprend pas un truc tout simple...

Le pire c'est que le ST va tout aussi vite ! Donc tu devrais le voir être lui aussi 2x trop rapide ! Ce n'est pas la vitesse le problème mais la répartition (et le fait qu'elle reste identique meme en dehors de l'affichage...)! Tu dis toi-même que les instructions du ST sont arrondies au multiple de 4 supérieur : tu n'as jamais compris pourquoi ??!!! C'est précisément ce que le post de ce tableau explique ! Puisque tu connais la conclusion, tu aurais pu supposer que le raisonnement est bon !  Non, même pas !
   

Sur ST, en basse résolution, l'affichage est de 16 pixels par 16 cycles CPU.
Tu dis que l'Amiga va à la même vitesse.
Or, dans ton tableau, tu affiches 32 pixels en 16 cycles.
J'en conclus que ton tableau est incorrect.

Déjà ton terme de cycle cpu ne veut rien dire mais bon.
Sur le ST, pour afficher 16 pixel, le shifter a besoin de 4 cycles : c'est une puce 16 bits (tu es au courant non ?) Et en basse résolution il y a 4  bitplans (tu es au courant aussi non ?). 
Comme le shifter partage les cycles avec le CPU moitié-moitié, cela fait 2x4 = 8 cycles "cpu" et pas 16...

Moi j'en conclus que tu te trompes depuis le début, après nous avoir dit que tu connaissais bien le ST. Qu'est-ce que ce serait dans le cas contraire...

Sur ST, en basse résolution, 16 pixels sont affichés en 16 cycles CPU, tandis que le rayon cathodique parcourt l'écran. On parle de vitesse ici, la vitesse d'affichage du Shifter, pas du partage des cycles.
D'après ton tableau, 32 pixels sont affichés en 16 cycles. Si c'était vrai, les lignes seraient deux fois trop courtes sur l'écran.
C'est très simple. N'essaye pas de noyer le poisson. Essaye plutôt d'améliorer ton tableau.

Je me trompe ou tu te bases encore sur la doc douteuse de Paradox en la prenant pour vérité parce que ça semble aller dans ton sens?
D'après moi, ce qu'il dit, c'est n'importe quoi ici aussi. A chaque fois tu te laisses prendre comme un fanboy.

Comme je l'ai déjà indiqué, le scrolling horizontal peut-être changé à tout moment. 
S'il est différent de 0, le STE ajoute ce qu'il faut au compteur video en fin de ligne pour tenir compte du bout de ligne ajouté (l'équivalent de 16 pixels, variable selon la résolution), ce qui est logique.
Un registre permet d'ajuster le nombre de mots à ajouter en fin de ligne.
Donc si on passe de 0 à non 0 et vice versa, il faut adapter ce registre aussi. Ce n'est pas un bug, évidemment.

Ouh là ouh là ! Tu confonds totalement là : le pixel skip register permet de faire un scrolling au pixel près et toi tu me parles du registre de modulo...

Non, j'ai décrit comment les registres HSCROLL et LINEWID sont utilisés, confronte avec la doc d'Atari et tu verras que c'est correct.
Tiens, pour t'aider, la partie pertinente, lis attentivement à partir de CAUTION:

HSCROLL This register contains the pixel scroll offset. If it is zero, this is the same as an ordinary ST. If it is nonzero, it indicates which data bits constitute the first pixel from the first word of data. That is, the leftmost displayed pixel is selected from the first data word(s) of a given line by this register.

LINEWID This register indicates the number of extra words of data (beyond that required by an ordinary ST at the same resolution) which represent a single display line. If it is zero, this is the same as an ordinary ST. If it is nonzero, that many additional words of data will constitute a single video line (thus allowing virtual screens wider than the displayed screen). CAUTION In fact, this register contains the word offset which the display processor will add to the video display address to point to the next line. If you are actively scrolling (HSCROLL <> 0), this register should contain The additional width of a display line minus one data fetch (in low resolution one data fetch would be four words, one word for monochrome, etc.).

Ce n'est pas un bug, mais le programmeur doit adapter LINEWID s'il passe de HSCROLL nul à non nul pour un même écran.

Bon arretons là : tu ne maitrises visiblement pas assez les sujets que tu abordes...

C'est ça, fuis tout en insultant les gens alors que tu n'arrêtes pas de te tromper.

Juste une chose, parce que tu as attaqué Paradox :

This is a known problem and Atari affirms it.
Atari officially suggests to NOT set the Pixel Skip register in
the VBL as this causes the problem.

Atari le reconnait et dit comment éviter le problème.

Si tu avais l'esprit critique, tu aurais perçu que le fait que Paradox prétende qu'Atari reconnaît un supposé bug ne signifie ni qu'il y avait un bug ni qu'Atari l'aie reconnu.
Vu leurs autres erreurs, tu devrais au minimum te méfier de leurs affirmations en matière de hardware.
De plus, même sans connaître le STE, tu devrais te rendre compte que leur charabia sur VBL et HBL ne signifie rien.

Tu critiques Paradox (et moi aussi mais mais là c'est pas grave, c'est même de bonne guerre ) mais tu trouves normal que changer le nombre de pixel à eviter lors de l'affichage puisse poser problème quand il n'y a justement pas d'affichage... Qu'est-ce que ça aurait été si Atari avait ajouté l'overscan dans le STE... Il auraient conseillé un reboot à chaque pas de scroll ?

Sur le mig ce registre ne pose aucun soucis, alors que le circuit video a beaucoup plus de choses à gérer. Il est ou le bricolage ?

A nouveau, c'est ce que prétend Paradox, et c'est faux, et j'ai expliqué pourquoi.

[babsimov]

Sans smiley on pourrait croire que tu es sérieux en disant ça !!

Je vois pas comment un hardware pensé pour qu'un chipset aussi complet puisse tourner ensemble, et donc en ayant maximisé l'utilisation de la bande passante mémoire dispo peut être qualifié de bricolage, alors qu'une machine sortie en 6 mois et même pas capable d'évoluer sans tout faire exploser l'est ?? 

je n'ai jamais vu un ST exploser.  par contre j'ai l'ami d'un copain qui a lu sur un forum polonais que qq a perdu sa maison à cause d'un amiga qui a pris feu.

et je ne cite que babsimov et dlfrsilver qui disaient que le A1000 est complétement buggé, avec un chipset incomplet au point d'oublier cette période et d'en faire du négatisme.  ils estiment que le premier amiga est le A500 en 87.  moi j'appelle cela du bricolage

T'as vu jouer ça ou que j'ai dit que l'Amiga 1000 était buggé et que le premier Amiga était l'Amiga 500. Ne déforme pas mes propos, merci.

J'ai reconnu que l'AmigaOS 1.0 avait des bugs, ce sont des faits. Le TOS 1.0 aussi, tu as du mal à l'admettre pour ta part. Il y a une différence entre des bugs logiciels et hardware. Nous parlions de l'architecture hardware de l'Amiga et c'est bien l'Amiga 1000 qui a posé l'architecture décrite plusieurs fois ici. On voit bien qu'elle était tout ce qu'il y a de bien pensé. L'architecture du ST (le premier) par contre est nettement plus "discutable" pour ne pas trop de froisser. Tu peux dire employer "bricolage" autant que tu voudras, ce terme est bien plus synonyme du ST que que l'Amiga.

[dlfrsilver]

Bien sur, les programmeurs Atari qui avaient le bon gout de programmer le ST comme un Amiga, avec toutes les conneries de rigueur. 

Les vrais bons codeurs Amiga ne linkaient JAMAIS leur programme à la rom. Jamais. Seuls les touristes du ST faisaient ça......