Re: GUERRE ST-AMIGA, FIGHT !!!

[rocky007]

Un blitter c'est une puce qui décharge le CPU principal, donc dans le principe c'est un co-processeur. Il fonctionne en parallèle du CPU.

je t'ai posé la question ?

Une puce d'encodage décodage MPEG, c'est clairement plus simple dans le principe qu'une puce comme le copper. Et de loin.

forcément de la part d'un mec qui croyait que la copper faisait de la 3D, ça m'étonne pas que tu penses cela...
à ton avis, si tu dois faire un chip en FPGA, lequel sera le plus simple à faire ? un copper ou la puce d'encodage ?

[Invité]

un copper ou la puce d'encodage ?

T'es chiant,t'aurais pu mettre blitter à la place, j'avais une chouette vanne avec .. 

[Zarnal]

Merci. Pour les sprites j'ai trouvé

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

Par contre je ne comprends pas le sens exact de cette phrase

Enfin, chacun des huit sprites peut maintenant avoir sa propre palette. A noter que le plus gros point noir n'a pas été résolu : toute surcharge du bus (écran en suraffichage par exemple) entraînera encore et toujours la disparition d'un à sept sprites (snif !)


Comment surcharge t'on ce fameux bus ?
Quelle est sa bande passante ?
Suraffichage = overscan ?
Et pourquoi les sprites disparaissent ?

[dlfrsilver]

je t'ai posé la question ?

T'es de la police ? Nan, bon alors pouet pouet   !

forcément de la part d'un mec qui croyait que la copper faisait de la 3D, ça m'étonne pas que tu penses cela...
à ton avis, si tu dois faire un chip en FPGA, lequel sera le plus simple à faire ? un copper ou la puce d'encodage ?

la puce d'encodage sans hésitation. Le copper est beaucoup plus compliqué, d'ailleurs je doute qu'on puisse reproduire exactement en FPGA celle-ci sans décapper la puce et examiner ses connexions, ses portes logiques et consorts. 

Une puce d'encodage décodage hardware, c'est juste 2 fonctions différentes dans une puce. Le copper n'utilise que 3 instructions, mais comme toutes les puces customs de commodore, il y a des fonctions impossible à découvrir tant que la puce n'a pas eu le ventre à l'air, il y a "des secrets" dans le fonctionnement des puces (certains sont des bugs quand même autant le préciser).

[Invité]

A noter que le plus gros point noir n'a pas été résolu : toute surcharge du bus (écran en suraffichage par exemple) entraînera encore et toujours la disparition d'un à sept sprites (snif !)

Il parle de la limite de sprites /ligne qui n'a pas bougée,soit 8 sprites sur la même ligne MAX, comme sur ocs .

Comment surcharge t'on ce fameux bus ?

En faisant trop de multiplexage de sprites sur la même ligne .

Quelle est sa bande passante ? 

8 sprites 16pixels max/ligne

Et pourquoi les sprites disparaissent ?

Car le copper n'as pas assez de cycles DMA pour pouvoir lire les patterns des sprites suivants,donc ils ne sont pas affichés .

[rocky007]

Parce que sur les STs c'était indiqué toutes les conneries impossible à corriger ou à réparer sans refaire toute la carte mère de la machine from scratch ?

oui tu l'as dit toi même, ils patchaient en usine

Aucune idée. L'Amiga 1000 était une machine assez peu vendue, donc on s'en fout.

non on s'en fout pas : qd on sort une machine de ce prix et qu'on l'annonce révolutionnaire et ce pendant 2 ans seule sur le marché, la moindre des choses est de faire qq de correct

C'est parfaitement faux, tu vas sur ebay, le chip du 3000 coute pinuts, il a été produit en grande série, c'est du composant off the shelf. Pour les autres, tu les trouves sur ebay ou en NOS sans problème.
 

bizarre sur ebay il n'y a qu'un seul Super Buster, à 26 $ avec le shipping... tu trouves cela bon marché ? à ce prix là tu trouves des Amiga 500 d'occasion !  le ramsey, un seul sur ebay, 34 $ et un seul super DMAC à 79$.. ah oui tu as raison, c'est blindé de puces sur ebay...
 

Non mais toi oui apparemment. Tu peux nous expliquer coco comment tu fais pour patcher en soft des problèmes hardware, vas-y on attend tous ta réponse   !

c'est toi qui prétend avoir réparé ton A1200 en software

J'ai le droit de collectionner ce que je veux, par contre, j'ai tout à fait le droit de gueuler parce que la machine c'est du ni fait ni à faire.

on collection ce qu'on aime...surtout quand on y investi autant de temps et d'argent

J'ai jamais été riche, et j'aurais jamais eu l'idée de mettre en place un ramdisk pour aussi peu.

ben je n'y peux rien si tu n'as jamais eu cette idée formidable, je te blame pas

Quand au fait que ça se charge plus vite que sur un HD, oulà, tu vas un peu vite en besogne : 

pfff...que dire... donc tu vas me dire que le transfert HD->RAM  est plus rapide que du RAM->RAM...t'as un sacré problème avec ton amiga dans ce cas

Sur ST les disque dur sont lents, et ils sont très rapide sur l'Amiga (en même temps vu le prix, on est sur du 1er choix)

faux, c'est l'inverse, déjà on a pas votre filesystem ultra lent, et de deux les débits sont plus élévés

Arrête de me prendre pour un Atariste stp. Si ton source est composé de 20 fichiers et que le tout pèse 50ko, tu montes pas de ramdisk. Arrête de raconter n'importe quoi en balançant l'argument qui n'en est pas un "je suis programmeur, nananère". Ben non, tu passes pas par la case départ et tu touches pas 20000, non mais.

comment tu pourrais comprendre la facilité de pouvoir éditer et sauvegarder n'importe quelle partie de ces 20 fichiers, et de compiler le tout, sans le moindre accès disque ou disquette.  

as-tu déjà pensé à une autre orientation ?

Bien entendu, mais ça ne te regarde pas :)

je ne peux qu'approuver ta décision.
déjà un "informaticien de formation" qui sait pas utiliser de simples balises HTML c'est déjà douteux

L'install de pilotes quand t'as pas le choix ? Ben oui :)

tiens toi qui est informaticien de formation explique moi comment Win95 détecte un périphérique sur le port série, et communique avec lui et demande un driver ?

Bien sur que non, si tu savais de quoi tu parles, tu aurais compris qu'il était en surcouche par dessus du WB1.3...... mais c'est trop te demander.......

donc d'après toi, quand tu fais une copie de fichier dans directory opus, en fait il ne fait rien, c'est le workbench qui le fait en cachette ? 

Y a pas un mec sur Amiga, pas même un plouc qui irait mettre ses fichiers en ramdisk. Attends 2 secondes que j'en cause à mes potes qui programment sur Amiga, que je leur raconte l'histoire du mec qui pour 50 ko de source va monter un ramdisk sur une bécane avec 512ko de ram.

Ahahah, attends, je sors le pop-corn ! 

tu confirmes donc que tout les amigaistes étaient des ploucs, puisque WB 1.3 Amiga installe par défaut un ramdisk.
s'il n'était pas nécessaire, à quoi il servait ?  juste pour le plaisir de coder un ramdisk gratuitement ?

[rocky007]

la puce d'encodage sans hésitation. Le copper est beaucoup plus compliqué

mon dieu mon dieu...

[Invité]

mon dieu mon dieu... 

Oh,eh de peu !! 

[Zarnal]

A noter que le plus gros point noir n'a pas été résolu : toute surcharge du bus (écran en suraffichage par exemple) entraînera encore et toujours la disparition d'un à sept sprites (snif !)

Il parle de la limite de sprites /ligne qui n'a pas bougée,soit 8 sprites sur la même ligne MAX, comme sur ocs .

Comment surcharge t'on ce fameux bus ?

En faisant trop de multiplexage de sprites sur la même ligne .

Quelle est sa bande passante ? 

8 sprites 16pixels max/ligne

Et pourquoi les sprites disparaissent ?

Car le copper n'as pas assez de cycles DMA pour pouvoir lire les patterns des sprites suivants,donc ils ne sont pas affichés .

Je vais aller me coucher plus intelligent que ce matin . Merci.

[rocky007]

Car le copper n'as pas assez de cycles DMA pour pouvoir lire les patterns des sprites suivants,donc ils ne sont pas affichés .

problème inexistant sur le ST par ailleurs

[Invité]

problème inexistant sur le ST par ailleurs 

C'est vrai, mais vu qu'il sait rien faire,ça risquait pas d'arriver de toutes façons ..

[ryosaeba]

Ne peut-on pas utiliser le DMA du St comme un blitter ?

[Meditating Guru]

C'est possible que certains point m'aient échappé, mais il me semble bien avoir compris que ce blitter est loin d'être implémenté dans les meilleures règles de l'art.

Alors, tu n'as pas compris. Le blitter a été très bien intégré.
Le mettre en concurrence avec le CPU est plus malin qu'avec tous les autres composants (Video...).
En effet, les programmes de cette époque étaient séquentiels.

MOVE...
MOVE...
BLIT...
MOVE...
COMPUTE...

Au moins on savait où on était.
Avec le système anarchique de l'Amiga, bien malin qui peut dire à quel endroit du code assembleur le blit va se terminer. Le plantage n'est pas loin.
C'est pourquoi l'exemple de la doc Atari (qui est correcte, ainsi que son blitter) se contente de relancer le blitter en attendant une interruption éventuelle.

Je parlais, pour le ST, de son mode de fonctionnement qui était celui d'un 8 bit. Comme cela a été expliqué ici, par quelqu'un qui s'y connait bien plus que moi dans le fonctionnement interne du ST et de l'Amiga.

Un 16bit est un 16bit, point. Les experts à qui tu fais appel sont biaisés.

Ben voyons, l'expert dont tu parles, Stapha92 est celui qui a le mieux défendu le ST. Il a su me faire comprendre l'intéret du mode monochrome alors qu'en arrivant ici je trouvais que c'était un truc archaïque.

Au contraire, je trouve qu'il est assez objectif, il sait pointer les points faibles du ST, ses points forts. Il a su aussi expliquer à un spécialiste de l'Archimède comment fonctionnait l'affichage de sa machine, alors que celui-ci n'avait pas compris. Il a su reconnaitre lorsqu'il s'était trompé (pas souvent). 

Il ne me parait pas du tout discrédité.

Le mot est biaisé, pas discrédité.
Et l'architecture est définie par le CPU et le bus, pas par les coprocesseurs.

oui donc au contraire, tu es comme le ST, tu es propre tu attend de finir ta cuisine avant d'aller aux toilettes

Non le ST tu chies dans la cuisine tout de suite, tout en faisant à manger (parce qu'il peut pas gérer les deux, il est pas cablé pour) Avec l'Amiga tu vas d'abord aux toilettes, et ENSUITE seulement la salle de bain pour les pognes, et au final la cuisine 

Ca n'a pas de sens. L'Amiga est multitâche et dans ce cas ci, ça marche: ton steak a un goût de savon et d'autre chose.  

Je suis (informaticien de métier et pardon, mais c'est) complètement débile. 

Si tu supprimes le nombre de mots adéquat du milieu, c'est tout à fait ça.  

[Invité]

un copper ou la puce d'encodage ?

T'es chiant,t'aurais pu mettre blitter à la place, j'avais une chouette vanne avec .. 

[Invité]

Ne peut-on pas utiliser le DMA du St comme un blitter ?

Non, le DMA ne fait que copier une série d'octets consécutifs, le blitter peut copier entre autre une zone rectangulaire,faire des opérations à la volée pendant la copie, décalage de bits, masquage,tracer des lignes,remplir des surfaces à la volée,etc.  .

Si ça t'intéresse voilà une doc sur ce que peu faire le blitter de l'amiga:
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0118.html

[dlfrsilver]

oui tu l'as dit toi même, ils patchaient en usine

Vrai et ça merde quand même après :)

non on s'en fout pas : qd on sort une machine de ce prix et qu'on l'annonce révolutionnaire et ce pendant 2 ans seule sur le marché, la moindre des choses est de faire qq de correct

Pourquoi tu insistes sur une machine mal positionnée, trop chère, sortie trop rapidement ?


Elle n'a marqué que quand elle est sortie. La machine qui a cartonné, c'est l'Amiga 500.

bizarre sur ebay il n'y a qu'un seul Super Buster, à 26 $ avec le shipping... tu trouves cela bon marché ? à ce prix là tu trouves des Amiga 500 d'occasion !  le ramsey, un seul sur ebay, 34 $ et un seul super DMAC à 79$.. ah oui tu as raison, c'est blindé de puces sur ebay...

Mais c'est le prix ! On est pas en train de parler de metal slug en version AES à 10000 boules que personne peut se payer quand même mince quoi ! Quand on a du pognon à mettre dans une machine rétro, y a des coûts annexes derrière ! 

c'est toi qui prétend avoir réparé ton A1200 en software  

Oui j'ai corrigé le bug hardware du 1200 d'origine via un patch qui contourne le problème 

on collection ce qu'on aime...surtout quand on y investi autant de temps et d'argent

Hmmm c'est vrai ça :) Ah ça tu peux le dire, mes STs sont les machines qui m'auront couté que dalle à l'achat (j'ai acheté un pack de 3 ST pour presque 50 euros y a plus d'un 1 an de ça maintenant), ça coute que dalle. Mais ensuite : révision du PSU : 55 euros, ajout de ram 35 euros, bref j'en passe et des meilleures. Un Amiga ça coute pas aussi cher à réviser et à entretenir. 

je ne peux qu'approuver ta décision.
déjà un "informaticien de formation" qui sait pas utiliser de simples balises HTML c'est déjà douteux  

Et la flemme tu connais ? J'ai juste pas envie de m'emmerder :) 

pfff...que dire... donc tu vas me dire que le transfert HD->RAM  est plus rapide que du RAM->RAM...t'as un sacré problème avec ton amiga dans ce cas

Ben sur mon A500, par exemple, c'est pas si simple...... le disque dur est ultra rapide, plus même que l'ultrasatan du ST, qui est du matos récent...... 

Je me souviens d'un jeu de blue byte, qui se mettait en ramdisk sur mon A600, et même sans accès disque, c'était lent quand même depuis la ram. A l'inverse le même jeu sur mon A500 sur disque dur, il bombarde à fond la caisse. 

ça dépend du hardware utilisé. 

faux, c'est l'inverse, déjà on a pas votre filesystem ultra lent, et de deux les débits sont plus élévés

non pas à moi s'te plait ! le lecteur de disquette de l'amiga est plus rapide que celui du ST. 


J'ai fait y a un bail la mesure au chronomètre de la vitesse, le drive du ST est plus à formatter 160ko de moins que ce que contiennent les disquettes de l'Amiga.


L'amiga formatte 880ko en OFS plus rapidement qu'un atari ne formate en 720ko. 


Ce dernier met 15 secondes de plus que l'Amiga pour effectuer la même opération.

ben je n'y peux rien si tu n'as jamais eu cette idée formidable, je te blame pas

Encore heureux puisque c'est inutile quand on a aussi peu de ram.

comment tu pourrais comprendre la facilité de pouvoir éditer et sauvegarder n'importe quelle partie de ces 20 fichiers, et de compiler le tout, sans le moindre accès disque ou disquette.   

Pour gagner quoi ? 10 secondes au total ? ça sert à rien....... Ou t'achètes un disque dur (lent au possible sur ST, et ça je t'en cause, j'en ai possédé un, un SH305 de chez Atari. Aussi lent que ma grand-mère pour traverser un passage clouté (la pauvre !)

tiens toi qui est informaticien de formation explique moi comment Win95 détecte un périphérique sur le port série, et communique avec lui et demande un driver ?

T'as de l'argent ? Je travaille pas gratuitement :)


plus sérieusement, voici le modèle de modem que j'utilisais, et sa doc au format PDF. 

http://support.usr.com/support/5625/5625-files/5625-frnc-Manual.pdf


Page 18, il est indiqué qu'il faut installer les drivers sous Windows 95 et de connecter le cable du modem sur le port série. 


Car ce modem fonctionne uniquement sur port série..... oh que c'est ballot, et Windows 95 ne sait pas le reconnaitre sans le pilote !


Donc, preuve à l'appui, j'avais raison ! Une fois de plus t'as raconté n'importe quoi, comme d'hab 

donc d'après toi, quand tu fais une copie de fichier dans directory opus, en fait il ne fait rien, c'est le workbench qui le fait en cachette ?   

Exactement, et après j'ai droit à une turlutte   !

tu confirmes donc que tout les amigaistes étaient des ploucs, puisque WB 1.3 Amiga installe par défaut un ramdisk.

Pas sur le mien. 

S'il n'était pas nécessaire, à quoi il servait ?  juste pour le plaisir de coder un ramdisk gratuitement ?

Le ramdisk était utile sur les machines possédent entre 2mo de ram ou plus. un ramdisk sur une machine avec 512ko, c'est juste ridicule, c'est vraiment un truc d'atariste, et encore.... si ça se trouve, c'est un truc made in Rocky....

[Meditating Guru]

Le problème est que le ST n'était en fait pas pensé pour être évolutif du tout.

Tandis que l'Amiga a été conçu pour évoluer lentement mais sûrement vers une console de jeu intégrale (CD32).

Alors que dans son interview, Shiraz Shijvi ose prétendre haut et fort qu'il a tout fait pour que la machine soit évolutive ! Un des nombreux mensonges de son interview. Et si, il a fait miroiter un passage facile au 68020, par upgrade, si me souviens bien. Il promettait un blitter plus puissant que l'Amiga, pour 1988 (acheté sur étagère) etc etc...

Je pense qu'en fait il était "custom", je ne vois pas qui à part Atari l'aurait fait. Ce n'est quand même pas Motorola?

[Zarnal]

Le problème est que le ST n'était en fait pas pensé pour être évolutif du tout.

Tandis que l'Amiga a été conçu pour évoluer lentement mais sûrement vers une console de jeu intégrale (CD32).

Même pas vrai, une console c'est plein écran en 60hz et pleins de sprites.
En plus comparer cette infamie de CD32 à une console. 

[rocky007]

Pourquoi tu insistes sur une machine mal positionnée, trop chère, sortie trop rapidement ?

parce qu'il faut pas renier l'histoire d'amiga et de sa perfection   donc d'après toi, il faut tout oublier et considérer qu'amiga n'a commencé qu'en 1987..eh ben...

Mais c'est le prix ! On est pas en train de parler de metal slug en version AES à 10000 boules que personne peut se payer quand même mince quoi ! Quand on a du pognon à mettre dans une machine rétro, y a des coûts annexes derrière !

et c'est ça que tu appelles peanuts ? presque 150$ pour faire fonctionner son amiga ?  et tu disais qu'il y en avait plein ..j'ai trouvé qu'une seule de chaque et encore pas sûr que ce soit la bonne révision

Oui j'ai corrigé le bug hardware du 1200 d'origine via un patch qui contourne le problème 

tu devrais vendre sur ebay ta solution, pour couper l'herbe à tout ces arnaqueurs qui vendent des puces debuggées

Ben sur mon A500, par exemple, c'est pas si simple...... le disque dur est ultra rapide, plus même que l'ultrasatan du ST, qui est du matos récent...... 

Je me souviens d'un jeu de blue byte, qui se mettait en ramdisk sur mon A600, et même sans accès disque, c'était lent quand même depuis la ram. A l'inverse le même jeu sur mon A500 sur disque dur, il bombarde à fond la caisse. 

ça dépend du hardware utilisé.

mais s'teplait, un transfert HD n'ira jamais aussi vite qu'un pure transfert RAM, c'est la logique la plus élémentaire

non pas à moi s'te plait ! le lecteur de disquette de l'amiga est plus rapide que celui du ST.

formater une disquette  n'est pas l'utilisation quotidienne que tu fais d'un floppy..enfin si, sur amiga : on format, on copie, on joue

le système de l'amiga est mondialement reconnu comme lent

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

compte le nombre de fois qu'il est dit "very slow"

Pour gagner quoi ? 10 secondes au total ? ça sert à rien....... Ou t'achètes un disque dur (lent au possible sur ST, et ça je t'en cause, j'en ai possédé un, un SH305 de chez Atari. Aussi lent que ma grand-mère pour traverser un passage clouté (la pauvre !)

quand tu développes, tu édites et compiles peut-être 200 fois sur une journée... fais le compte

plus sérieusement, voici le modèle de modem que j'utilisais, et sa doc au format PDF. 

http://support.usr.com/support/5625/5625-files/5625-frnc-Manual.pdf


Page 18, il est indiqué qu'il faut installer les drivers sous Windows 95 et de connecter le cable du modem sur le port série. 

Car ce modem fonctionne uniquement sur port série..... oh que c'est ballot, et Windows 95 ne sait pas le reconnaitre sans le pilote !

et ça se dit "informaticien de formation"... wouhaha...

1° comme je le disais, windows ne detecte aucun périphérique, tu dois insérer ta disquette
2° ta fameuse disquette ne fait qu'installer qu'un raccourci modem pré-configuré, ce que tu aurais pu faire à la main tout seul.  en fait, c'est fait pour ceux qui savent pas utiliser windows, les gens qui n'y connaisse pas grand chose, si tu vois ce que je veux dire
3° la preuve en est encore que sous 3.x il ne faut pas de pilote, donc il n'en nécessite pas pour fonctionner en série

Le ramdisk était utile sur les machines possédent entre 2mo de ram ou plus. un ramdisk sur une machine avec 512ko, c'est juste ridicule, c'est vraiment un truc d'atariste, et encore.... si ça se trouve, c'est un truc made in Rocky....

le ramdisk est utile pour n'importe qui dont le besoin se fait ressentir, quelque soit sa taille... il n'y a pas de minimum.
la preuve encore : on te le fournissait gratuitement avec WB, pourtant, y'avait bcp de gens qui possédait 2mo ?  t'es trop marrant ..

[dlfrsilver]

L'amiga 1000 n'a marqué que l'industrie pour son avancée. Le grand public lui a connu la perfection à partir de l'A500, qui a terrassé le ST (tranquille hein, sans forcer   ).

et c'est ça que tu appelles peanuts ? presque 150$ pour faire fonctionner son amiga ?  et tu disais qu'il y en avait plein ..j'ai trouvé qu'une seule de chaque et encore pas sûr que ce soit la bonne révision

Tu veux qu'on compare avec les presque 80 euros par machine que coute un ST ? Et encore, sans lecteur de disquette virtuelle, parce que la on explose la note !!!

tu devrais vendre sur ebay ta solution, pour couper l'herbe à tout ces arnaqueurs qui vendent des puces debuggées

Pourquoi j'irais vendre le patch logiciel permettant de corriger le bug PCMCIA de la révision 1D4 du 1200 ?
Le mec qui a pondu le patch ne l'a pas fait payer, pourquoi j'irais le vendre ? T'as pas la lumière à tout les étages mon garçon ! 

mais s'teplait, un transfert HD n'ira jamais aussi vite qu'un pure transfert RAM, c'est la logique la plus élémentaire

Mais oui mais oui disait l'atariste qui avait de la ram hyper lente dans son atari, à son collègue sur Amiga dont la chip ram était plus speed, oui oui oui 

formater une disquette  n'est pas l'utilisation quotidienne que tu fais d'un floppy..enfin si, sur amiga : on format, on copie, on joue

le système de l'amiga est mondialement reconnu comme lent

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

compte le nombre de fois qu'il est dit "very slow"  

oui il est très lent, mais incomparablement plus rapide que celui du ST, et haut la main ! 

quand tu développes, tu édites et compiles peut-être 200 fois sur une journée... fais le compte

ça dépend, tu étais programmeur professionnel ou programmeur touriste ? Le programmeur pro utilise une config avec plus de ram pour plus confort et un disque dur. Le touriste utilise un ramdisk.

et ça se dit "informaticien de formation"... wouhaha...   

1° comme je le disais, windows ne detecte aucun périphérique, tu dois insérer ta disquette
2° ta fameuse disquette ne fait qu'installer qu'un raccourci modem pré-configuré, ce que tu aurais pu faire à la main tout seul
3° la preuve en est encore que sous 3.x il ne faut pas de pilote, donc il n'en nécessite pas pour fonctionner en série

Arrête de raconter de la merde. Le manuel indique clairement qu'il faut installer le pilote, et c'est pas qu'un raccourci ! 


Et d'ailleurs y a pas qu'un pilote, y a aussi le logiciel de communication spécifique à 3com pour ce modèle de modem. Donc tu racontes 2 conneries en une !


Je sais ce que je dis, et pas de pilote sous Windows 3.x ; Non mais sérieux, tu oses tout, et comme disait Audiard, c'est à ça qu'on les reconnait   


je cite dans le manuel page 25 :


"insérez votre disquette dans le lecteur, afin que windows 95 puisse installer les pilotes de votre nouveau modem !"


Et avec ça meussieur Rocky avance que Windows 95 reconnait tout seul direct d'emblée le matériel ? 


Tu n'y connais rien en fait en informatique Rocky. Seul l'Amiga fait du plug'n'play. 


Et tu me traites de débile ou de mec qui s'y connait pas ? Tocard va ! 

le ramdisk est utile pour n'importe qui dont le besoin se fait ressentir, quelque soit sa taille... il n'y a pas de minimum.

je connaissais pas le ramdisk pour idiots à 50ko. je me coucherais moins atariste demain :)

la preuve encore : on te le fournissait gratuitement avec WB, pourtant, y'avait bcp de gens qui possédait 2mo ?  t'es trop marrant ..

Les développeurs sur Amiga, oui ! Ils avaient un disque dur, avec de la ram en plus. Y a que les débiles qui développent sérieusement avec 512k. Enfin quoi que, je dirais rien finalement. Narco police de Dinamic a été codé sur un ST avec 512k de ram (j'ai discuté avec le programmeur, et franchement, on sentait bien la galère que c'était...... le pauvre :/ )

[rocky007]

L'amiga 1000 n'a marqué que l'industrie pour son avancée. Le grand public lui a connu la perfection à partir de l'A500,

donc tu confirmes, Amiga c'était une usine à bug, pas le ST.

Tu veux qu'on compare avec les presque 80 euros par machine que coute un ST ? Et encore, sans lecteur de disquette virtuelle, parce que la on explose la note !!!

tu comptes bien, pour à peine la moitié du prix de tes pièces détachée, tu as un ST complet fonctionnel

Mais oui mais oui disait l'atariste qui avait de la ram hyper lente dans son atari, à son collègue sur Amiga dont la chip ram était plus speed, oui oui oui 

1° c'est faux, 2° c'est quoi le rapport avec le ramdisk ?  tu n'arrives même plus à suivre, c'est déjà trop complexe ?

oui il est très lent, mais incomparablement plus rapide que celui du ST, et haut la main ! 

rappelles moi le temps pour obtenir un directory sur WB 1.3 ?   tu veux qu'on compare avec le ST ?  tu veux qu'on compare l'écriture de 50 fichiers et voir qui va le plus vite ?

ça dépend, tu étais programmeur professionnel ou programmeur touriste ? Le programmeur pro utilise une config avec plus de ram pour plus confort et un disque dur. Le touriste utilise un ramdisk.

si tu veux je te présenterais des programmeurs qui ont développé des chefs d'oeuvres avec un lecteur cassette.

Arrête de raconter de la merde. Le manuel indique clairement qu'il faut installer le pilote, et c'est pas qu'un raccourci !

ben je vais pas t'apprendre ton métier... mais fais un effort , c'est pas compliqué pourtant, en plus y'a des jolies images

Et d'ailleurs y a pas qu'un pilote, y a aussi le logiciel de communication spécifique à 3com pour ce modèle de modem. Donc tu racontes 2 conneries en une !

aaaah, de mieux en mieux... un modem série qui n'est compatible qu'avec un seul logiciel

Et avec ça meussieur Rocky avance que Windows 95 reconnait tout seul direct d'emblée le matériel ?

eh bien oui, tu aurais ajouté manuellement le modem cela revenait au même

Tu n'y connais rien en fait en informatique Rocky. Seul l'Amiga fait du plug'n'play. 

Et tu me traites de débile ou de mec qui s'y connait pas ? Tocard va ! 

ouhla... de mieux en mieux

je connaissais pas le ramdisk pour idiots à 50ko. je me coucherais moins atariste demain :)

même 5 ko tu sais, pour coder un boot sector par exemple, ça suffit

Les développeurs sur Amiga, oui ! Ils avaient un disque dur, avec de la ram en plus. Y a que les débiles qui développent sérieusement avec 512k. Enfin quoi que, je dirais rien finalement. Narco police de Dinamic a été codé sur un ST avec 512k de ram (j'ai discuté avec le programmeur, et franchement, on sentait bien la galère que c'était...... le pauvre :/ )

et bien tu vois finalement, tu y arrives, bravo

[dlfrsilver]

donc tu confirmes, Amiga c'était une usine à bug, pas le ST.

Je parlais de l'Amiga 1000. Le ST est une usine à bug, je parle même pas du STE :)

tu comptes bien, pour à peine la moitié du prix de tes pièces détachée, tu as un ST complet fonctionnel

ah mais non ! quand tu achètes un ST d'occaz, faut le retaper de A à Z. Déjà l'alim (obligatoire), voir changer les barrettes de ram (l'alim quand elle déconne leur colle des gifles, j'ai du remplacer mes barrettes sur mon 520 et 1040 STE, et allez vas-y  ).


Le ST fonctionnel, c'est quand tu as recappé l'alim, viré tout les moutons de poussière, décrassé le lecteur de disquette (ces derniers tombent en panne faut voir sur ces machines, rien ne vaut le lecteur d'un 500, c'est tank built, et pas comme ces cochonneries de drives Epson ou sony, qui prennent la rouille....).


Maintenir des ST quand on en a plusieurs ça coute TRES CHER. J'ai jamais déjà autant d'argent sur les Amiga. Eux, tu recappes et c'est bon. La qualité et la solidité (bon après si il a trainé en bord de fenetre comme chez toi Rocky, hein, à l'impossible nul n'est tenu ahaha  ).

1° c'est faux, 2° c'est quoi le rapport avec le ramdisk ?  tu n'arrives même plus à suivre, c'est déjà trop complexe ?

1° c'est vrai, 2° c'est totalement en rapport avec le ramdisk. Alors tu suis ou pas, c'est trop dur ?

rappelles moi le temps pour obtenir un directory sur WB 1.3 ?   tu veux qu'on compare avec le ST ?  tu veux qu'on compare l'écriture de 50 fichiers et voir qui va le plus vite ?

Hyper rapide. Je mets à l'amende n'importe quel atari ST en terme de volume de fichiers à afficher, en config disque dur que ce soit sur l'Amiga ou sur le ST.


L'Amiga est plus rapide que l'Atari, je te l'ai déjà dis, et je suis pas le seul. L'atari écrit par secteur, l'Amiga écrit par pistes, je te laisse deviner lequel met une tarte à l'autre (je t'aide : c'est pas l'Atari lol).

si tu veux je te présenterais des programmeurs qui ont développé des chefs d'oeuvres avec un lecteur cassette.

Effectivement. Tu as des potes chez robert Hue ahahah   ?

ben je vais pas t'apprendre ton métier... mais fais un effort , c'est pas compliqué pourtant, en plus y'a des jolies images

Ben justement, vas te laver les yeux, c'est marqué comme le porc salut dans le manuel 

aaaah, de mieux en mieux... un modem série qui n'est compatible qu'avec un seul logiciel

Le logiciel de 3com était surement mieux foutu que la daube fourni pour miasmosoft.

eh bien oui, tu aurais ajouté manuellement le modem cela revenait au même 

Tu nous prends vraiment pour des ataristes pas vrai ? 

même 5 ko tu sais, pour coder un boot sector par exemple, ça suffit

Nan pas possible ???? Touko tu confirmes ? Le Monsieur il dit que 5ko ça suffit pour faire bomber un atari ! 

et bien tu vois finalement, tu y arrives, bravo

Oui mais lui il était obligé pour manger. Toi tu fais le touriste parce ce que ça amuse la galerie :


"Hé les mecs, je crée une ramdisk pour enquiller 50ko de source dans une machine qui manque de ram, parce que quand mon drive y tourne, je suis malheureux" 


nawak 

[babsimov]

Affligeant à quel point tu es de mauvaise foi. Les machines Atari conçues par Jay Miner avant l'Amiga, tu les trouves très bien et l'Amiga tout d'un coup il sait plus rien faire !

ben toi même tu l'as avoué : l'Amiga 1000 est plein de bugs à sa sortie... je trouve cela scandaleux pour une machine de ce prix.  Pire : les bugs ( comme celui de l'agnus ) ne sera jamais résolu , il faudra acheter un A500.

Pourquoi j'aurai nié que l'AmigaOS 1.0 avait des bugs ? Il a été fait trop vite pour tenir un délais comme je te l'ai indiqué. Par contre, quand on te pointe des bugs du TOS, tu ne les reconnais même pas. Car, que je sache le TOS au début n'était pas plus terminé que l'AmigaOS 1.0, il n'était pas en ROM non plus, mais en disquette, justement parce qu'il y avait encore du travail à faire dessus.

C'est normal pour Agnus de l'Amiga 1000, il n'a cessé d'évoluer. Au début il n'était que NTSC, il n'avait pas le mode EHB (64 couleurs), si ma mémoire est bonne. Pour le bug dans Agnus dont tu parle je ne sais pas.

Le problème est que le ST n'était en fait pas pensé pour être évolutif du tout. Alors que dans son interview, Shiraz Shijvi ose prétendre haut et fort qu'il a tout fait pour que la machine soit évolutive ! Un des nombreux mensonges de son interview. Et si, il a fait miroiter un passage facile au 68020, par upgrade, si me souviens bien. Il promettait un blitter plus puissant que l'Amiga, pour 1988 (acheté sur étagère) etc etc...

Tout comme commodore promettait une machine super fiable pro avec le A1000 et c'était une usine à bugs.  L'architecture  ST semble bien avoir été pensé évolutive puisque la gamme des MegaST, Ste, TT, Falcon, ont bel et bien existé.  Le ST a donc pu bel et bien évoluer comme prévu.  Le blitter, dans certains cas, en puissance brute, est plus rapide que celui de l'amiga, il n'avait pas menti ( par exemple pour l'effacement d'un écran )

Bugs logiciels que seront corrigés. Mais, de toute façon, tu détestes tellement l'Amiga que même avec des vidéos sous les yeux qui te montrent que ça fonctionne (test en plateau télé de présentation de l'Amiga), tu ne le crois pas.

Le megaST aura donc un blitter bancale, à cause de la conception originale du ST qui n'était pas prévu pour. Il devra avoir une mémoire cache sur son 68000 à 16 mhz, parce que la gestion des cycles ne permettaient pas d'avoir un gain de performance autrement. Et encore, il n'aura qu'un gain de 50 % (soit la moitié de ce qu'il aurait du avoir). Le STe se trainera aussi les même défauts que le ST d'origine. Le TT devra utiliser une "Fast RAM" et abandonner le blitter du ST trop lent (au lieu d'en proposer un nouveau plus rapide). Le Falcon se trainera le bus 16 bits du ST, avec un processeur 32 bits. Si t'appel ça de l'évolutivité, j'appel ça bricoler autour d'une architecture bancale dès le départ.

Il est plus rapide dans ce cas là, peut être parce qu'il prend toutes le cycles non ? Celui de l'Amiga en laisse à son processeur. Il faudrait l'avis d'un véritable technicien.

Il était conçu pour un 68000, ça devrait suffire non ? Il faisait partie du projet SIERRA à base de 68000, c'était la puce son de la machine. Et, comme par hasard il n'aurait pas fonctionné correctement en environnement 16 bits, alors que c'était son environnement natif ? Arrête, Shiraz Shivji, lui même dans l'interview fait comprendre à demi mot que sans les ingénieurs d'origine ils n'arrivaient pas l'interfacer.

c'est vraiment ridicule de spéculer sur un sujet que ni moi ni toi ne connaissons les tenant et aboutissant.  il n'y a aucune info concernant ce chip, et le peu qui existe ne permettent pas de telle conclusion, ta mauvaise foi faisant le reste

Spéculer... Dans son interview il a clairement fait comprendre à Jack Tramiel, à demi mot, que c'était idiot d'avoir viré les ingénieurs d'origine. Et AMY était bien prévue pour un 68000. 
Mais, pour te faire plaisir, admettons que c'était un ratage hardware total et qu'il n'était pas possible de la faire fonctionner... sinon ses "génies" du hardware y serait forcément arrivés.

Tripos et l'AmigaOS (au début) c'est quasi identique. Ils l'ont juste adapté pour qu'il s'interface avec le noyau exec et ce qui était déjà écrit par l'équipe Amiga. TripOS était déjà très bien. Lors de la démonstration chez Commodore, TripOS a fini avec les applaudissements de tous.

bref, ils ont vraiment rien foutu chez Amiga, que reprendre des idées de partout.  Au moins chez Atari, ils ont écrit le GEMDOS.

Comme tu dis, si j'étais toi, je me vanterais pas de GEMDOS. Pour revenir à l'Amiga, Carl Sassenrath a écrit un noyau multitâche parmi les plus performant de son temps avec EXEC, tout en assembleur. Ca me parait quand même d'un autre niveau que de porter CP/M sur 68000 en le renommant TOS. 
Amiga travaillait sur son propre OS (avec  ressource tracking). Il s'appelait Commodore Amiga OS (CAOS). Comme je te l'ais dit, ils ont du tout arrêter pendant six mois, à cause d'Atari. Pas étonnant que pour tenir la date de lancement voulue par Commodore, ils ait cherché une solution. TRIPOS était une très bonne solution, salué par des applaudissement et porter assez vite par Metacomco.

Tu n'as jamais inventé ou adapté à ta manière certaines chose concernant l'Amiga, j'en doute.

ben ici tu peux le vérifier par toi même, donc je n'ai pas besoin d'inventer.   mais évidement quand tu es coincé, tu dois quand même trouver encore un fond de mauvaise foi

J'ai déjà vérifié plus d'une fois que tu citais de travers, enlevait les passages de citations qui ne t'arrangeait pas, inventait des choses ici ou là. Dans la mauvaise foi, personne ne peut t'égaler ici.

Et que ce mode parallèle était utilisable dans certains cas précis si je me souviens bien. Je pense que les démomaker savent de quoi ils parlent.

les sources ont été citées, tu peux donc t'amuser à lire.  pourquoi tu ne lis pas et comprendre par toi même au lieu de répéter comme un mouton aveuglement ce que des gars sur un forum écrivent ?  cela ne t'arrive jamais avoir ta propre opinion sur un sujet ?

Mais justement, j'ai lu vos échanges et je te livre l'opinion que je me suis faites. Le Blitter du ST était un bricolage et un implémentation bancale, alors qu'il y avait moyen de mieux l'implémenter, comme cela a été expliqué. Toujours par la même personne, Stapha92, qui non seulement explique très bien, mais sais aussi défendre le ST quand il le faut.

Pas entendu parler de ce bug SCSI ?
C'est ça dont tu parles :
http://www.amiga.org/forums/showthread.php?t=22995

Le contrôleur est un Western Digital, c'est la faute de Commodore s'il a un problème dans une configuration précise ? On parlait d'un composant conçu par Atari, c'est déjà différent.

quand on intègre un chip, on s'assure qu'il fonctionne bien, c'est le minimum pour un machine orientation professionnelle à ce prix.  oui ils ont corrigé quelques erreurs , mais pas toutes sur l'Amiga 3000T.  Et qu'en est il des autres chip buggés : le Ramsey, le DMAC ?
donc quand tu achète un ordi de ce prix, tu dois remplacer tout ses composants ? car là si je compte bien, cela fait 4 chips défectueux buggés sur une machine professionnelle hors de prix !   Oui Commodore a +- corrigé cela avec le temps, mais proposait-il le remplacement dans les machines déjà vendues ?  Ben non.  Ces circuits étaient ils vendu ?  non plus.. ils sont ultra rare, ce qui fait pleurer les possesseurs d'amiga 3000.

Parce que même de nos jours, il n'y a pas sur les cartes mère PC des composants tierces buggès ? Ils font quoi dans ce cas les fabricants de la carte mère, il te reprennent ta carte mère et te l'échange ? Ben bonne chance pour y arriver. Dans la très grande majorité des cas, ce contrôleur fonctionnait. Et un changement du composant règle le problème. Ce n'est pas le cas pour le bug du ST, ça vient d'un spécialiste des réparations ST (il y avait eu les citations en anglais de ses échanges).

Je me souviens plus des bugs pour Ramsey et DMAC, si tu pouvais me dire ?

Mais non, il a été expliqué que même si ce ne sont pas des données graphiques, le TOS mettra les données dans le STRAM (plus lente d'accès pour le 68030). Sur Amiga, seules les données graphiques iront en Chip RAM, le reste ira en Fast RAM où le processeur pourra y accéder à sa pleine vitesse. Elégant, bien pensé dès le départ.

pas du tout, les données non chipset ( son, video etc..)  sont évidemment logées en TT RAM.

Ben c'est pas ce qui était expliqué. Et, entre ce que tu dis et une explication en détail de la part de Stapha92, je préfère celle Stapha92 qui a quand bien moins souvent que toi dit des choses erronées.

J'ignorais qu'il avait quitté Atari en 1988, peut être après son interview calamiteuse ? Il s'en rendu compte qu'il s'était discrédité en promettant tout et n'importe quoi pour 1988 ?

toujours moins la honte que Jay miner sortant l'oeuvre de sa vie, sous la forme de l'ordinateur le plus buggé du monde, le A1000 et dont l'erreur ( guru meditation ) aura même sa propre page Wikipedia tellement elle est connue.

Ordinateur qui sera salué comme ayant dix ans d'avance par la presse...

En tout cas, l'interview en question c'est du grand n'importe quoi. Mais, comme il est de bon ton de glorifier le ST ici, c'est surement que je n'ai pas sur lire l'interview comme il fallait  

Ben si, le TT se traine la limitation de la STRAM par une gestion bancale de la TTRAM. Et il a sa version spéciale du TOS compatible 32 bits, un belle héritage du TOS non compatible 32 bits issu du ST et des choix de départ discutables. Surtout qu'il semble bien que Motorola s'assurait de faire savoir à ses clients, quelles seraient les instructions qui ne seraient pas dans la génération suivante. 

je ne vois pas en quoi elle est bancale... si tu comprenais ce que tu lisais sur les forum, peut-être que tu relativiserais.   mais évidement tu lis et bois aveuglement les propros, sans jamais te documenter par toi même, ni même essayer de comprendre ou réfléchir.  on dirait un perroquet.

Et quand ce qu'on dit te plait pas, tu en arrives aux comparaisons avec des oiseaux. 

C'est ma faute si Atari a commis l'erreur de ne pas écouter les conseils de Motorola, rendant son TOS incompatible avec même un 68010 ? 

Quand à me documenter, je pense justement que je vais régulièrement vérifier ce qui est dit, y compris tes propos... souvent erronés. Comme quand tu disais, lorsque j'ai abordé le point en question, que sans patch il était impossible de lancer le Workbench 1.3 avec un 68020... Pas de chance ça fonctionne en natif, comme le lien vers la discussion que j'avais cité le confirmait.

Tiens au fait, j'avais relu une ancienne réponse de Stapha92 (à l'occasion de nos débats). Il disait que le TOS n'était pas compatible 32 bits. A l'époque, je n'avais pas compris ce qu'il voulait dire. C'est quand je suis tombé par hasard sur l'information des instructions non garanties par Motorola que j'ai compris. Donc, tu vois, il disait vrai une fois de plus, bien avant que le sujet ne soit abordé.

on a bien démontré que les WB et les nombreux kickstart n'étaient pas compatible non plus entre eux, je serais toi , ce serait un sujet que j'éviterais.  

Je vois pas où est le problème, tu va pas faire tourner un workbench 1.3 avec une ROM 2.0, quand tu as le workbench 2.0, qui permet de faire tourner sans problème les applications système issues du 1.x. Soit dit en passant les applications 2.x tournaient sous 1.3, puisque j'en utilisait. Il y avait juste un affichage différent des gadgets des fenêtres, par rapport à ceux du 1.3. 
Commodore et l'équipe Amiga a écouté Motorola et son OS tournait avec un 68020, sans modification nécessaire.
Mais, glorifions le ST, c'est de bon ton, si Atari à fait ce choix, c'était pour tirer les prix, bonne décision sur le court terme... 

Il était mieux que le Falcon, puisque 32 bits et avec un DSP 32 bit aussi, plus puissant  

sur le papier... et combien de puces buggées ? 10 ? 15 ?

Toujours la surenchère avec toi. Je vais donc entrer dans ton jeu, pourquoi pas toute la carte mère tant que t'y es ? 

Mais glorifions le ST, c'est de bon ton... quelle belle décision d'Atari que de concevoir un Falcon 32 bits (le Falcon040) et de ne finalement pas le sortir alors qu'il était terminé. Pire de laisser tomber purement et simplement le Falcon040 et la communauté ST (qui était sa base) pour se concentrer sur les consoles de jeu... 

Mais, on l'a déjà dit, l'autorun, DirectX, le multitâche partout... On a déjà tout dit la dessus et tu penses encore qu'on se souvient de l'Amiga parce qu'il n'a rien apporté ! C'était le premier ordinateur vraiment moderne, le premier à être réellement multimédia... Je suis lassé de devoir constamment te répéter les même chose.

mais à ce que je sache, le multitache n'a pas été inventé par Amiga, ce n'est donc pas un héritage d'eux.    Direct X n'a pas été inventé sur amiga, ce n'est pas un héritage non plus, surtout que toute GUI possède forcément une librairie graphique, alors que le codeur de Direct X se soit inspiré d'un amiga parce qu'il jouait dessus, peut être, mais il aurait pu s'inspirer du GEM également. L'autorun n'est qu'une évolution de l'autoexec.  Bref, aucune trace des technologies inventées par Amiga.

Bien sur, ce n'est pas l'Amiga qui fut le premier représentant de l'informatique moderne ? Pourtant, c'est bien ainsi qu'on l'à présenté pour son 30ème anniversaire. Surement des gens payés par Commodore, comme tu sais si bien le dire.

Il reste quoi du ST dans ce cas ? Ou sont les OS monotaches ? Ou sont les affichages tout au processeur ? Ou sont les interfaces graphiques sans icones personnalisées ? Tout cela a disparu depuis bien longtemps. Le ST a eu son heure de gloire en 1985 pour son excellent rapport performance/prix ça on ne peut pas lui enlever. Mais sortit de ça, il n'avait pas grand chose à offrir pour l'avenir.

contrairement à toi, je ne glorifie pas le ST en icône, je suis réaliste... le ST n'a rien laissé non plus.

Non, tu ne glorifie pas le ST, c'est sur. Quand on te donne des bugs du ST, c'est faux il était parfait, quand on te dit que l'architecture du ST était bancale, c'est faux il était parfait dès le départ... C'est surement du réalisme façon Atari. 

T'es tellement réaliste que tu prétendais que le transputer Atari était LA station graphique la plus puissante de son temps ! C'est plus du réalisme à ce niveau, mais du surréalisme  

Mais, nous sommes au moins d'accord sur un point, le ST n'a rien laissé.

On t'a expliqué qu'ils n'étaient pas capable de fonctionner de manière autonome, comme sur Amiga. Relis tu verras.

ah bon parce que tu crois qu'il n'y a que sur amiga des copro autonomes ?  reprenons le cas du YM : tu charges les données et sans le CPU il va générer le son, il est donc autonome.  tout comme les chip video ont des sprites autonome sur les 8 bit, la display list du XL ( ancêtre du copper list ) fonctionnait elle aussi de façon autonome du CPU.

Ben non, j'ai lu que justement qu'on t'a expliqué que non. 

Une machine qui obtient à sa sortie dans la principale revue informatique américaine un commentaire "dix ans d'avance" c'est sur qu'elle a rien inventé ! C'est bien que les autres ils n'avaient pas d'équivalent !

oui parce qu'elle avait de spec avancées : son ,graphique etc..  mais ce n'était que des évolutions de technologies déjà inventées

Quand tu veux pas comprendre. On a déjà débattu de tout ça des pages et des pages, je vais pas encore répéter et répéter.

Et c'est aussi pour ça que ce fut un échec ! Donc une mauvaise décision de conception de plus pour lui.

oui bien sûr, tu étais là au conseil d'administration pour savoir la raison de l'échec.   Si Commodore a coulé à cause de l'amiga, c'est à cause justement de l'amigaos...si cela avait été du Windows, Amiga serait encore là, s'ils avaient pu produire des machines sans la moitié du chipset buggé.

Je t'ai expliqué pourquoi Commodore à coulé, ce n'est certainement pas à cause de l'Amiga et de sa technologie, qui était le véritable atout de Commodore. Mais bien à cause des décisions stupides de la direction.

Quant à associer Windows et l'Amiga, mais personne ne voulait de ça.... et personne ne l'aurait acheté. Windows est l'antithèse de ce que représentait l'Amiga. 

Et pourtant chez Commodore ils ont eu cette idée stupide... enfin la direction. Figure toi que pour Hombre (PA/RISC) la direction envisageait d'y voir tourner une version de WindowsNT... car ils n'avait plus d'argent pour y porter l'AmigaOS.

Bien entendu les ingénieurs étaient contre, car ils savaient que la communauté Amiga n'aurait pas acheté ça. Et ils avaient raison, car, lorsque cette information a été divulguée, après la faillite, c'était un rejet dans la communauté. 

D'ailleurs, David Pleaseance, PDG de Commodore Angleterre, qui voulait racheter Commodore (car sa filiale était la seule qui dégageait encore des bénéfices et pouvait continuer à exister), souhaitait, bien sur finaliser Hombre, mais avec un portage de l'AmigaOS. Il avait bien compris ce qui faisait de l'Amiga un Amiga. Le succès de l'Amiga en Grande Bretagne parlait pour lui.

Dans une interview récente, il expliquait d'ailleurs qu'il ne comprenait pas bon nombre de décisions de la direction américaine à l'époque. Il avait vu le prototype d'Hombre et il avait tout de suite compris que c'était ça qui pourrait relancer l'Amiga. C'est comme le 4000 à base d'ECS il n'avait pas compris quelle idée était passé par la tête de la direction. Son interview est des plus intéressante, on en apprend beaucoup sur l'année après la faillite et comment Escom a en fait torpiller le seul espoir sérieux de voir revenir l'Amiga, c'est à dire Commodore Angleterre.

C'est un ancien de Gateway2000 qui a expliqué tout ça. Mais, tu vas encore dire que c'est un affabulateur.

les mecs qui coulent doivent toujours trouver un bouc émissaire, sinon ils se suicident s'ils se rendent compte qu'ils ont été juste incompétent en misant sur le mauvais cheval.  le syndrome de calimero

Tu nous la fait à chaque fois celle là. Je peux t'assurer qu'à l'époque des faits, je suivais tout ça sérieusement et qu'avec le temps et les recoupements d'interview c'est tout ce qu'il y a de crédible.

Gateway2000 en rachetant l'Amiga avait clairement dit qu'ils cherchaient un moyen de se passer du monopole Microsoft, avec leur propre machine. Ils ont allouer un gros budget pour la mise au point d'un nouvelle machine moderne, d'un version mise à jour en conséquence de l'OS. 

Et tout d'un coup plus rien, ils coupe les vannes. Hasard, ils ont obtenus une super ristourne sur les licences Windows pour plusieurs années... en échange de l'abandon de tout projet Amiga...

Mais, tu ne le croira pas, libre à toi, encore surement quelqu'un de payé par Commodore pour désinformer. 

Et voilà, c'est pas toi qui m'avait reproché un certain dérapage ? Relis, tu verras que Windows 95 ne faisait pas l'unanimité pour ce qui est de sa "fiabilité". Dire le contraire c'est faire preuve d'une belle mauvaise foi. Mais tu es égale à toi même  

tiens..tiens... pourtant regardons ton magazine favori, BYTE, dans son top excellence meilleure technologie de 1992, qu'y trouves-t-on ?  Workbench 3.0 pourtant sorti en 92 ?  ben non, pas une ligne, pas un mot.. par contre windows 3.1 est dans le top !

https://archive.org/details/BYTE-1993-01

pire, dans le numéro anniversaire 20 ans, ils reprennent les 20 softwares ayant marqué l'histoire, on y trouve :

CP/M  ( tiens donc...)
Unix system
Mac OS
DOS 2.0
Windows 3.x

tiens...pas d'Amiga OS ou de TripOS que tout le monde applaudit ?  

et c'est dommage, je ne trouve pas le numéro du mois d'aout dans lequel ils testent Windows 95

Et pour les 30 ans de l'Amiga, ils diront que c'était le premier ordinateur multimédia. 

Le CP/M je dis pas que ce ne fut pas bien en son temps, juste qu'en 1985 ce n'était plus son temps.

Tiens c'est marrant dans le top 20 des ordinateurs, l'Amiga 1000 (avec mention de son multitâche) :
https://archive.org/stream/byte-magazine-1995-09/1995_09_BYTE_20-09_20_Years#page/n77/mode/2up

Je vois pas le ST ? Il y a même le Commodore PET pourtant... même le Xerox STAR, que des ordinateurs pro...

Tiens les composants les plus marquant de l'informatique, ça me dit quelque chose, Agnus, Denise, Paula :
https://archive.org/stream/byte-magazine-1995-09/1995_09_BYTE_20-09_20_Years#page/n93/mode/2up

Et même le SID (pas le YM), le MOS 6502 aussi y est.

Ils sont ou le Shifter, le Videl ?

Maintenant, les compagnies les plus marquantes de l'informatique :
https://archive.org/stream/byte-magazine-1995-09/1995_09_BYTE_20-09_20_Years#page/n119/mode/2up

Commodore y est, mais Atari ? Ben non...
Et encore mention de l'Amiga "et en 1985 apparait le premier ordinateur Multimédia, l'Amiga" et ils ajoutent "un exemple classique d'une machine en avance sur son temps"...

Les 20 plus gros échec :
La tablette de Shiraz Shijvi en fait partie :
https://archive.org/stream/byte-magazine-1995-09/1995_09_BYTE_20-09_20_Years#page/n171/mode/2up

Les 20 plus gros vaporware :
https://archive.org/stream/byte-magazine-1995-09/1995_09_BYTE_20-09_20_Years#page/n187/mode/2up

Windows95 est dedans... pourtant il était tellement bien selon toi. WindowsNT aussi est dedans !

Une erreur de typo... parce que ça s'est vu, sinon tu aurais laissé passer   
Je commence à savoir comment tu fonctionnes  

oui bien sûr, je vais faire croire aux gens ici que l'Amiga 1000 est sorti après l'amiga 500..

Ce ne serais pas la première fois que tu essaierais d'embrouiller les esprits  

C'est possible que certains point m'aient échappé, mais il me semble bien avoir compris que ce blitter est loin d'être implémenté dans les meilleures règles de l'art.

Alors, tu n'as pas compris. Le blitter a été très bien intégré.
Le mettre en concurrence avec le CPU est plus malin qu'avec tous les autres composants (Video...).
En effet, les programmes de cette époque étaient séquentiels. 

MOVE...
MOVE...
BLIT...
MOVE...
COMPUTE...

Au moins on savait où on était.
Avec le système anarchique de l'Amiga, bien malin qui peut dire à quel endroit du code assembleur le blit va se terminer. Le plantage n'est pas loin.
C'est pourquoi l'exemple de la doc Atari (qui est correcte, ainsi que son blitter) se contente de relancer le blitter en attendant une interruption éventuelle.

Je n'ai pas l'impression que les programmeurs Amiga soient perdus dans la programmation de l'Amiga. Maintenant, peut être que les programmeurs ST qui tentent d'apprendre à programmer pouvait trouver cela "anarchique". Mais, les explications donnés montrent bien, au contraire, qu'il n'y a rien d'anarchique la dedans, mais que tout est logique et bien pensé.

Je parlais, pour le ST, de son mode de fonctionnement qui était celui d'un 8 bit. Comme cela a été expliqué ici, par quelqu'un qui s'y connait bien plus que moi dans le fonctionnement interne du ST et de l'Amiga.

Un 16bit est un 16bit, point. Les experts à qui tu fais appel sont biaisés.

Ben voyons, l'expert dont tu parles, Stapha92 est celui qui a le mieux défendu le ST. Il a su me faire comprendre l'intéret du mode monochrome alors qu'en arrivant ici je trouvais que c'était un truc archaïque.

Au contraire, je trouve qu'il est assez objectif, il sait pointer les points faibles du ST, ses points forts. Il a su aussi expliquer à un spécialiste de l'Archimède comment fonctionnait l'affichage de sa machine, alors que celui-ci n'avait pas compris. Il a su reconnaitre lorsqu'il s'était trompé (pas souvent). 

Il ne me parait pas du tout discrédité.

Le mot est biaisé, pas discrédité.
Et l'architecture est définie par le CPU et le bus, pas par les coprocesseurs. 

Mais non il est pas biaisé, puisqu'il a défendu très bien le ST dans un autre sujet et même ici quand c'était nécessaire.

Non sur une machine avec des coprocesseurs c'est un tout. Pour que ce soit efficace, il faut penser l'ensemble de façon que tout soit harmonieux. Ce qu'à fait l'équipe Amiga, comme expliqué. Relis tout ce qu'à écris Stapha92 sur la façon dont est organisé l'Amiga et tu verras. Il explique cela très bien, je lui avais même demandé un niveau plus que débutant et il l'a très bien fait. Ce fut d'ailleurs salué par tout le monde ici, à l'époque.

Le problème est que le ST n'était en fait pas pensé pour être évolutif du tout. 

Tandis que l'Amiga a été conçu pour évoluer lentement mais sûrement vers une console de jeu intégrale (CD32).

Comme le PC a évolué vers la XBOX...

Alors que dans son interview, Shiraz Shijvi ose prétendre haut et fort qu'il a tout fait pour que la machine soit évolutive ! Un des nombreux mensonges de son interview. Et si, il a fait miroiter un passage facile au 68020, par upgrade, si me souviens bien. Il promettait un blitter plus puissant que l'Amiga, pour 1988 (acheté sur étagère) etc etc...

Je pense qu'en fait il était "custom", je ne vois pas qui à part Atari l'aurait fait. Ce n'est quand même pas Motorola?

Dans l'interview il parle qu'il a un fournisseur pour le blitter, il dit que c'est le meilleur blitter du marché. Il ne parle pas d'un blitter custom. Mais, peut être qu'au final il n'a pas pu intégrer ce blitter dans le ST, pour les même raison qu'AMY, certainement... Il ne fonctionnait pas. Le fournisseur en question a du lui montrer un prototype non finalisé. Du coup il fait son blitter "bricolé".

[stapha92]

Quel répartie... A court d'argument ?

Oui c'est sur si la proportion est respectée, il est clair que ça compense les saccades, le son de merde, et la palette hyper réduite...

Comme souvent, le ST se fait exploser par le C64...

"Exploser"... quel langage agressif. 
Le fait est que sur ST, les proportions sont respectées, la musique ne casse pas les oreilles, les graphiques sont plaisants, sans couleurs baveuses. C'est un bon jeu, ne vous déplaise. Et sur STE, c'est magnifique.

Un bon jeu qui prend à peine plus de la moitié de la zone d'affichage, qui elle-même prend la moitié de l'ecran...
Et combien de vbls ? ce qui donne quoi comme latence ? 80-100 ms entre le moment ou tu agis sur le joystick et celui ou ça réagit ? C'est sur ça doit être super. Surtout aux niveaux ou ça va vraiment vite...

L'overscan ne fait pas grésiller mon moniteur, mais il est clair que cette technique n'était pas prévue par Atari, elle a été inventée par la scène très imaginative du ST.

Il faut effectivement faire preuve d'une grande imagination pour combler les lacunes du ST. Mais des fois ça ne marche que dans les démos (code synchronisé justement) : j'attend toujours un jeu avec un scrolling horizontal digne de ce nom sur ST...

Bien sur qu'on veut que ce soit immédiatement servi : c'est le principe des interruptions !

Le plus vite possible, pas immédiatement. L'interruption à la priorité la plus élevée est celle qui détecte le moniteur monochrome, afin d'éviter d'endommager l'écran. Il ne sera pas endommagé en une demi-scanline.

ah bon ? Sur ST on se satisfait d'une demi-scanline de retard ? La machine vous a rendu moins exigeant que ce que l'on attendait d'un simple 8 bits ? Heureusement que tu dis n'importe quoi...
Et j'apprend qu'il faut faire intervenir le cpu pour ne pas endommager l'écran.  
A part ça c'est pas du bricolage le ST... 

Ben lui aussi il prenait cet exemple. Lancer un MUL ou un DIV avant un blit est concevable si on fait de la 3D.

Oui, et ça serait bien de faire tous les MUL et les DIV nécessaires à une scene 3D pendant que le blitter efface l'écran. ça ne ralentirait presque pas le blitter et ça accélérerait grandement le calcul( si le blitter ne s'arrete que lorsque le cpu a besoin d'un cycle et qu'il redemarre immédiatement...). Sur Amiga ça ne pose pas de problème. Sur le STE si...

 1 : Il y avait plus de bombes que de guru. En plus : c'est quoi ce truc sérieusement !! Des bombes pour indiquer un plantage ! Pratiquement aucune info ! là ou le guru en donne plein et offre la possibilité en se connectant au port série du mig d'executer un debugger. Même quand il plante, le mig le fait plus intelligemment qu'un ST. Et c'est pour ça que le Guru est plus connu. Le mig plantait moins : tu le saurais si tu avais vraiment eu un mig. Tu peux prétendre le contraire mais il est évident que c'est faux.

Tu me traites de menteur?  

Tu mens soit quand tu dis posséder un amiga soit quand tu prétends qu'il avait des guru à répétition. Et c'est une constante ici : pleins de personnes disent avoir eu les 2 machines à l'époque et préférer le ST. Bizarrement, à l'époque je n'en ai pas connu une seule ! Bien au contraire : plusieurs STistes sont passés au mig quand ils ont vu mon mig. Et vu l'évolution des chiffres de ventes des 2 machines (et des logiciels dédiés) quand le A500 sort, il est clair que mon cas n'était pas isolé. C'est bien celui rapporté dans ce forum qui l'est. A croire que c'était un monde parralèle...

Et elle sont jolie les photos de ton A500 mais ça prouve quoi ? Que tu en as un aujourd'hui, c'est tout. J'ai eu un ST et un A500 et je n'en ai aucun aujourd'hui, juste mon 1200...
Allez, si tu veux : j'admet que tu en avais un.  Ce qui est encore plus grave...

La méthode du TOS permet de servir les interruptions sans planter.

Ah bon ? Essaie de lancer une copie en blit mode et quand le cpu a la main appelle une fonction du TOS qui utilise le blitter et compte les bombes... Le TOS ne peux pas savoir si le blitter est occupé, et Atari ne semblait pas au courant (ni dans la doc ni dans les fonctions)...

Tu cherches des fautes de frappe dans la doc? C'est ça tes arguments?   
EDIT: je crois qu'en fait BSET est valable. Cette instruction teste le bit avant de le mettre à 1.

Au temps pour moi si BSET teste le bit. Du coup, TAS est plus lent que BSET (et ne donne pas la possibilité de choisir le bit...). Contrairement à ce que tu as dit (tu expliques que TAS est utilisé sur Atari parce que c'est plus rapide).
Cela dit ça n'est pas suffisant : vu que ta superbe architecture génère un accès concurrent, le BSET ne suffit pas.

D'ailleurs :

In the 1990's revision of Atari's BLiTTER manual, they revised the
code quoted above the following:

loop:
    tas     $FFFF8A3C.w        ; (re)start the BLiTTER
    nop                        ; BLITTER will need a few cycles
    bmi.s   loop               ; Loop if register shows "busy"

3 ans pour corriger ce qui n'était pas qu'une faute de frappe finalement...
J'adore le "nop" (un classique de la programmation sur ST...) qui fait perdre du temps et montre la qualité d'une architecture qui oblige souvent son utilisation. Je ne me rappelle pas avoir du l'utiliser sur le mig. Comme quoi tu avais raison : vous utiliser bien toutes les instructions motorola sur ST : meme celles qui ne font rien et celle qui n'existent pas...   

Merci pour la leçon ! Mais tu peux me dire pourquoi il vaut mieux eviter les interruptions ? Pour faire du code quasi-inutilisable dans les jeux ou les applications ? Ou du code incompatible avec d'autres machines que le ST de base ? Ou parce qu'il ne faut pas sortir des techniques 8 bits ?

Parce que quand on se synchronise, c'est pour faire de l'overscan qui ravira la scène ST, et c'est plus difficile de mêler overscan, interruptions et blitter. De plus, quand tu es synchronisé, tu ne t'amuses pas à utiliser un Timer B pour changer la palette, tu le fais directement.

Dans ce cas là je suis d'accord. Mais si on veut faire un vrai jeu et pas une démo ? Tu trouves normal de devoir oublier les raster quand on veut utiliser le blitter ? C'est ça le ST ? On vous rajoute une fonctionnalité mais vous en perdez une !
En tout cas c'est bien ce que je disais : l'overscan (en tout cas horizontal) est quasi inutilisable dans les jeux ou les applications et est incompatible avec d'autres machines que le ST de base.

Y a des centaines de jeu STF qui utilisent des rasters... Créés avec des interruptions...
Je n'ose même pas aborder les autres cas d'interruptions non synchro avec l'affichage mais qu'1/2 ligne de décalage rend inutilisables...

Parce qu'il n'y en a pas!   

Jouer un sample, ou sampler depuis un digitaliseur branché sur le port parralèle, ou communiquer via un port série ou des ports midi... Non c'est sur : y en a pas ! 

Attention avec ce genre d'énumération, "moi président" s'y est essayé et s'est planté comme un Amiga.
Des bugs minimes, certes, mais en général fiable, pas comme sur Amiga.

Oui il s'est planté en remportant les élections après son "moi président"...
Oui bien sur : fiable pas comme sur Amiga. Répète le quelques millions de fois, ça deviendra peut-être vrai...
Notes que certains "bugs minimes" n'en sont pas : ce sont carrément des trucs absents de l'OS mais qui existent dans tous les autres. Du coup tu as raison : le ST a des bugs très fiables...

Je note que tu ne réponds pas sur les timings d'affichage.

J'ai expliqué la répartition des cycles du mig. Je vois pas ce que tu veux dire. Combien de temps durent-ils ? A peu près la meme chose que sur ST (à peu près car 7.14 Mhz vs 8 Mhz). Mais ils ne sont pas groupés par 2 mais gérables individuellement. Et le mig peut les répartir dynamiquement et d'une façon beaucoup plus souple que le ST.

Je me moquais plus de ton idée "4 cycles pour le blitter, 1 cycle pour le CPU".
Il convient de recouper ce que dit cet "expert". A première vue, si ce qu'il dit est correct, il me semble possible de pauser le blitter en changeant le compteur de lignes (mais n'est-ce pas ce qu'il dit aussi?).
Ce serait donc un autre problème de doc, à vérifier. Pas étonnant, à l'époque du STE, je serais le premier à le reconnaître, Atari avait baissé (sans atteindre le niveau de Commodore).

Ce n'était qu'une suggestion comme ça.Je t'en donne une autre : 
Puisque tu maitrises le fonctionnement des cycles du ST, tu admettras facilement que s'il y avait eu mode qui, sur les 2 cycles cpu consécutifs, en attribuait 1 au 68000 et un 1 au blitter (donc toujours du statique)  ça aurait eu comme conséquence : 
1 : le 68000 aurait tourné a pleine vitesse (il ne peut jamais accéder au 2eme cycle de toute façon, encore une aberration de la superbe architecture)
2 : le blitter aurait tourné à la même vitesse qu'en mode blit (puisqu'au final il aurait eu accès dans les 2 cas à la moitié des cycles cpu)
3 : les interruptions auraient fonctionné aussi bien qu'avec le blitter arreté.
Comme quoi il faut vraiment pas chercher loin pour trouver une meilleur implémentation que le bricolage d'Atari...

Faster Atari bus is one factor, the other one is a buggy amiga chipset. 
Amiga blitter needs one idle cycle per each copying/clearing word. It means that copy takes 3 bus cycles and clearing takes 2 bus cycles per word.
Therefore, during the border area (when video DMA is off) clearing takes 4 CPU cycles per word and on the visible area 8 CPU cycles per word. It is valid for 4 bitplane mode, and each additional bitplane increases copy/clearing process by further 2 CPU cycles per word.
In case of the Atari, it is always 4 CPU cycle per each word.

J'adore le "buggy amiga chipset" pour commencer... Faudrait étudier le fonctionnement du blitter du mig avant de dire ça. 
Ensuite c'est faux : le blitter laisse un cycle sur 2 au cpu (donc le cpu n'est quasiment pas ralenti, en fait il l'est autant que dans un ST sans blitter, cad que tous les accès mémoires sont arrondis à 4 cycles) quand les sources sont coupées (c'est à dire en cas d'effacement ou d'application d'une valeur constante) mais pas quand il copie : donc 2 bus cycles for clearing and 2 bus cycles for copying.
Et la suite est encore plus bizarre : le blitter du mig, c'est 8 cycles pour traiter 3 sources + 1 destination. On compare ça avec le blitter du ST qui ne sait pas traiter 3 sources ??!!!
Ensuite on explique que chaque bitplan ajouté au delà de 4 augmente le nombre de cycles de 2 par mot et on compare avec l'Atari qui lui reste toujours à 4 cycles alors qu'il ne peut pas avoir plus de 4 bitplans...
Enfin tout ça pour expliquer que le blitter du ST est plus rapide alors tous les tests ont montré le contraire...
Je rappelle que j'avais été raillé sur ce forum quand j'avais expliqué ici que le St n'affichait pas 4096 couleurs mais 3375 quand il utilise 2 frames pour augmenter le nombre de couleurs. Des vrais connaisseurs ont du s'y reprendre à plusieurs fois pour faire comprendre pourquoi j'avais raison. 
Il y a des tas de gens très doués et très interessants sur Atari forum (et qui souvent se foutent du mig, et ils ont bien raison) mais pas que...

Since I wrote the "We Were @" demo, my opinion about blitter has changed a bit  Blitter is efficient because you don't have instruction prefetching penalties. For 32*32 sprites, because of the "mask set each scanline" trick, I realize blitter is faster than CPU for 32*32

Là si j'ai bien compris, il utilise une astuce qui consiste à utiliser les masquages de début et fin de ligne pour remplacer la 3eme source qui manque pour faire du cookie-cut. Mais cela a 2 défauts : d'abord le cpu est obligé d'alimenter les masques à chaque ligne et cela ne marche pas avec des éléments de plus de 32 pixels de large. Ce qui est bien par contre c'est que dans ce mode, le cpu reprend la main tous les 32 pixels et que les interruptions subissent un décalage plus faible. En tout cas c'est une belle solution. Encore une fois, il faut l'ingeniosité des coders ST pour contourner les contraintes du ST.

Sprites 32x32 4bitplanes without clearing:
- Atari: 40064 / 1344 = 29,8
- amiga 320x256 5 bitplanes: 44512/ 1280 = 34,8 (is 16% faster than ST)
- amiga 320x200 4 bitplanes: 54112 / 1280 = 42,3 (is 41% faster than ST)

Sprites 32x32 4bitplanes with clearing:
- Atari: 40064 / 1728 = 23,2
- amiga 320x256 5 bitplanes: 44512/ 1728 = 25,8 (is 11% faster than ST)
- amiga 320x200 4 bitplanes: 54112 / 1728 = 31,3 (is 35% faster than ST)

Etrange : On ajoute un clearing comme s'il n'y avait pas de fond. Et pour effacer, le blitter du mig n'utilise que la moitié des cycles disponibles. Donc cela donne un avantage au ST (En théorie car le cpu utiliserait l'autre moitié des cycles pendant ce clearing dans le mig). Sauf que dans une situation réelle (avec un fond), ce n'est pas du clearing mais une copie simple. Et là le blitter utilise tous les cycles. Donc les chiffres du bas ne sont pas valables dans la vrai vie mais seulement dans un test avec un fond unique...
Ensuite on donne les nombres pour l'Atari sans préciser le nombre de bitplans. Evidemment, il ne peut y en avoir que 4.
En plus cela utilise la méthode évoquée plus haut : si on fait le test avec des gros sprites, elle ne peut plus être utilisée et l'écart grandit.
Au final, le chiffre de 41% est celui qui est le plus proche d'une comparaison equitable dans une situation utilisable ailleurs que dans un test. (chiffre théorique, en pratique l'écart est plus grand).

Cela Rocky, je suis bien d'accord avec toi : le blitter n'est pas si mauvais que ça et c'est vrai que c'est un plus. Le problème est qu'il aurait du être meilleur que celui du mig (et était annoncé comme ça) car conçu bien après. Le fait qu'il ne soit même pas aussi bien (alors qu'il tourne à 8MHz vs 7,14Mhz) pose question...

wiki : 
Due to bugs in Kickstart 37.300, the maximum supported size of a hard disk is limited to 40 MB

le Kicstart 37.300 est celui du A600. Y en a pleins aujourd'hui qui tournent avec une carte bien plus grande sans que cela pose problème...

ben à t'entendre le ST était tellement pourri et mal conçu que c'était à fuir comme la peste et que l'amiga était THE machine pour développer.  je sais que tu ne critiques pas les talents des codeurs ST, mais probablement leur choix d'utiliser une si mauvaise machine

c'est assez culotté de comparer des jeux en plus faible résolution et dire que c'est mieux que le ST.
alors oui, le C64 a son scrolling "hardware trické" horizontal, c'est cool qu'après 20 ans on découvre cela...
c'est une autre histoire en 1985.   et puis c'est assez réducteur : c64 enterre le ST parce qu'il a des scrolls horizontaux fluide sur plusieurs plans. hum hum...( même si j'avoue que le niveau 2 de Enforcer est assez spectaculaire ).

Wing death ( ou lethal xcess ) minable VS C64 ?  montre moi donc un jeu en 30 couleurs, 320x256 et 200 sprites sur C64.  

Non je ne critique pas leur choix. Sinon je pourrai critiquer tout autant celui de ceux qui codent sur mig en 2016...
Oui en faible résolution mais la fluidité est plus importante pour le gameplay. Et c'est pas 20 ans après : quand j'ai eu mon ST j'ai regretté la version de boulder dash que j'avais sur mon XL. Et le XL est moins bon que le C64 (même si je suis un fanboy du 800 XL !) pour ce genre de jeux.
30 couleurs ? ou ça ? tu comptes la zone de score ? Voyons c'est bon pour la pochette ça !
200 sprites ? On est loin de la moitié de la moitié de ça, alors qu'on est en 3 vbl...
Et il est ou le scroll horizontal à la battle squadron (qui apporte au gameplay puisque ça élargit le champ de jeu) ? Le c64 n'a pas de problème pour ça lui...

un jeu de plateforme fluide ?

Oui un jeu de plateforme fluide.... sur STE. Donc pas pour la majorité des possesseurs d'atari ST (meme ceux qui ont un blitter). Avec un seul plan. Tout ça en 1992...

ah oui, donc si je comprends bien, à la version 2.0 ils ont ajouté une option qu'il ne jugeait pas nécessaire.  je ne comprends plus.  c'était utile ou pas utile ?   imaginons un Win 10 dont il faudrait repasser sur une fenêtre ligne de commande pour avoir accès au contenu du disque dur, c 'est le top , on s'embête pas avec des icones inutiles.  Là encore Amiga était innovateur, c'était la seule GUI au monde à ne pouvoir faire cela.

Ben dans Win10, les fichiers cachés et système ne sont pas affichés par défaut...
Ils ont ajouté une option rarement utile, donc désactivée par défaut. Et le ST il fait quoi lui ? Ben  il affiche betement TOUS les fichiers quoiqu'il arrive et dans toutes les versions du TOS, non ?
Et pourquoi afficher tout le contenu du disque dur dans le WB ? Quel interet à part avoir des fenêtre remplies de fichiers abscons ?
Je peux comprendre qu'on puisse préférer un choix plutot que l'autre mais quand on a un cli, celui du wb me parait très cohérent. Cela dit, à partir du 2.0 les amigaistes auront le choix. Les Stistes jamais...

je ne parlais pas de cela, mais de la sortie DAC du DSP.  pour le //, relis bien mon enfant, même ton dieu  Stapha confirme que cela existe et possible dans l'absolu

Dans l'absolu c'est possible, dans le mig ça existe, dans le ST non (a part lancer une instruction juste après avoir lancé un blit...)

le blitter sert à faire des certaines opérations plus rapidement que le 68000.  c'est ce qu'il fait dans le ST, en // ou non.  en // c'est mieux, mais le fait qu'il ne le soit pas n'est pas une preuve de mauvaise intégration.

C'est vrai qu'il le fait mieux qu'un 68000. C'est clair. Quand à l'intégration : on associe un cpu qui fait un accès mémoire tous les 8 cycles en moyenne avec un blitter et personne ne se dit : "ben si on laissait un cycle de temps en temps au cpu, ce dernier tournerait presqu'aussi vite que normalement et le blitter ne serait pas très ralenti...". Non a la place on créé un mode ou le blitter va bloquer le cpu pendant 256 cycles et lui donner la main pendant 256 cycles qu'il sera incapable d'utiliser entièrement (il en utilisera 32  en moyenne, 64 au maximum). Tous ces cycles inutilisés, c'est pas plutot ça la preuve de mauvaise integration ?

Une routine d'interruption peut pauser le blitter en mettant le bit BUSY à 0.
L'expert prétend que ça ne marche pas.

Voici une routine "timer B" de Lethal Xcess avec mon commentaire:

CODE:

Code:

(PC 014D8C sur STE 4MB)
 move.w $8a3c.W,$612.w                            ; sauver registre blitter
 clr.w $8a3c.W                                    ; mettre à zero pour stopper 
 movem.l D0-7/A0,-(a7)                            ; vu que la routine est longue
 movea.l $-17672(pc),a0 {$010894}                 ; (conformément doc Atari)
 movem.l (a0),D0-7                                ; 
 lea $8209.w,a0                                   ; 
 clr.w d7                                         ; 
 move.b (a0),d7                                   ; 
 sub.b (a0),d7                                    ; 
 bne.s -6 {$014DA8}                               ; attendre fin affichage ligne
 movem.l D0-7,$8242.W                             ; changer palettes pour ligne suivante
 nop                                              ; 
 nop                                              ; 
 nop                                              ; 
 nop                                              ; 
 nop                                              ; 
 nop                                              ; 
 nop                                              ; 
 nop                                              ; 
 clr.b $fa1b.W                                    ; programmation timer B suivant
 move.b #$9,$fa21.w                               ;  
 move.b #$8,$fa1b.w                               ; 
 move.l $-504(pc),$120.w {$014BDE}                ; 
 movem.l (a7)+,D0-7/A0                            ; 
 move.w $612.W,$8a3c.w                            ; restaurer registre blitter
 rte                                              ;

Autrement dit, cette routine fait EXACTEMENT ce qui est préconisé par Atari, et visiblement ça marche.
Donc SVP attendez un peu avant de critiquer les ingénieurs Atari. 

En même temps cette routine ne tourne qu'une ou deux fois par vbl (elle permet d'avoir une palette differente pour la zone de score ?) donc même si le busy bit ne marche pas, ça ne se verra pas puisqu'elle reprendra là ou elle en était quand le blitter lui rendra la main. Elle devrait même être capable de faire son movem qui affecte la palette avant les 256 cycles...
Mais admettons, disons que Paradox racontent des conneries. Il n'empeche, quand on regarde la routine on voit ou est le bricolage. Punaise tous ces nop  ! Que de cycles perdus ! On se demande bien pourquoi faire. Si on compte les cycles, on ne trouve pas que le dernier nop se produit après 256 cycles. Comme s'il fallait être sur que les instructions qui suivent ne se feront que lorsque le blitter aura rendu la main.
Comme si Paradox avait raison finalement... 
 

Car comme on l'a déjà expliqué maintes fois, le blitter ne prendra jamais un cycle DMA sur le STE, ce n'est pas comme l'Amiga.

Et c'est qui "on" ? Qui l'a expliqué ? Qui a expliqué quelque chose sur le mig d'abord ? Vous assenez des absurdités en vrac : vous ne les expliquez jamais...
Bien entendu c'est archi faux !
Qu'appelles tu DMA déjà ? Parce que dans le vrai sens (direct mémory access), ta phrase ne veut rien dire : Le blitter utilise un canal DMA pour fonctionner ! 
Je vais t'exliquer alors : tu te souviens du système de priorité pour les 25 canaux DMA dont je t'ai parlé ? Ben le blitter a l'une des plus basses. Donc il ne prendra jamais un cycle au disques (HD ou FD : c'est la plus grande priorité) à l'affichage, au copper, au son, etc...  La seule victime possible est le cpu. Normal : ce dernier n'est pas performant en terme d'accès mémoire et il a droit à la fast pour s'exprimer. Encore une affirmation bidon assénée avec assez d'aplomb pour faire croire qu'elle est réelle. 

Pour s'en rendre compte, il faut lire la doc Atari attentivement. 7 cycles bus, ça veut dire 28, c'est le temps pris par les instructions de l'exemple pour relancer le blitter. 64 cycles, comme tu l'as remarqué toi-même, ce serait ridicule.
La confusion vient du fait qu'ils parlent de "bus cycle", pas "CPU cycle".

Et tout ça marche parfaitement sur Lethal Xcess, qui utilise aussi le son DMA.

Oui c'est sur ça marche : 2 interruptions vbl qu'un ordinateur à cartes perforées serait capable de suivre. Montre nous donc un jeu qui emploie le blitter intensément et qui affiche un dégradé en fond. Courant sur STF (sans blitter) et sur le mig (avec blitter). Bizarrement absent du STE (avec blitter). Oui c'est sur : ça marche parfaitement !   
On n'a pas la mêle notion du parfait ou du bricolage visiblement...  
28 cycles pour démarrer ? Franchement je croyais que c'était 7. Il tourne au gazole le blitter du ST ou quoi ?   

Oui elle reste active tant que le CPU ne l'a pas acquittée, mais tu es au courant que pour jouer un sample par exemple, il faut envoyer les données de façon continue sans quoi la qualité devient dégradée .
Le scrolling par exemple sur le STE, si tu peux changer le scroll mid scanline, rater le bon moment peut être une cata,et je parle même pas du code timé qui est impossible à faire .
Et sur ST ou les timing CPU sont la base pour faire quelque chose de potable, c'est même pas la peine .

pourtant il y a bien un overscan 

Oui... un overscan partiel : vertical uniquement. Celui qui ne coute que quelques scanlines au début de la frame et qui utilise une interruption vbl... l'overscan total c'est plutot pour les démos sur ST hein ? 

Si le blitter n'était pas intéressant, il ne serait pas utilisé. Les affirmations diverses sur le blitter doivent être prises avec scepticisme.

Je le répète alors : le blitter est interessant. Y a pas photo. Celui qui dit le contraire a tout faux. Mais on peut se demander comment, en le sortant des années après celui du mig, Atari n'a pas réussi a en faire un meilleur ? 

Exactement. Si tu le programmes ainsi, le blitter va deux fois plus vite que celui de l'Amiga, qui est handicapé par sa mémoire Slow.

Donc quand le blitter du mig va 2 fois moins vite, ça équivaut à 41% plus rapide ? (d'après des chiffres donnés sur Atari forum : en pratique c'est pire)
L'Amiga LE ST a-t-il un impact aussi horrible sur l'intellect?   

 
C'est encore pire alors, parce que ça veux dire que le CPU peut avoir un delai de 256 cycles avant la prise de l'interruption(et je compte pas les 44 pour l'interruption + code blitter,soit plus de 300 cycles) .

Exactement Touko. Et Atari a l'audace d'appeler ce mode "cooperatif" !   

A noter qu'un DIV peut prendre dans les 150 cycles, là aussi l'interruption doit attendre, sur ta console aussi.

Tout a fait. C'est ce que Touko et moi te disons depuis le début : le 68000 n'est pas doué pour les interruptions ! Faut être idiot pour les rendre encore moins efficace !
C'est pourquoi sur le mig les concepteurs ont pensé qu'il fallait mettre un coprocesseur. Grace à lui notre superbe OS nous offre le drag d'ecran dans les applications par exemple (sans surcout cpu).
Donc on a une architecture qui comble les défaut du 68000 et une autre qui les aggrave... ça veut tout dire...  

Oui mais c'est quand même un délais inacceptable pour plein d'effets qui nécessitent du code timé .
Es ce que les registres de scrolling du STE sont buffered ??
CAD que si tu les modifies mid scanline, le scroll sera appliqué à la scanline suivante ??

Grace à la puissance du STE, le scroll ne sera appliqué qu'à la frame suivante !   
(On oublie le zoom temps réel avec le scroll trick ou les scrolling hardware ligne à ligne à la streetfighter...)

J'ai mes doutes là-dessus. Il n'y a qu'un bus et plusieurs composants qui veulent l'accès. Sur ST, l'accès est divisé en tranches de 2 cycles. J'ai posé la question, les experts ici présents n'ont pas été capables de répondre, sur Amiga, la division n'est quand même pas de 1 cycle?
Si l'on peut me démontrer que sur 4 cycles CPU, le bus de l'Amiga est utilisé 4 fois en lecture ou en écriture par des composants différents, j'admettrai que son bricolage est en fait une architecture supérieure à celle du ST. Si ce n'est pas le cas, je donne l'avantage au ST pour la simplicité de conception.

Non seulement il peut utiliser 4 cycles cpu pour 4 choses différentes (blitter / son / copper / cpu / sprite et même affichage) mais en plus sa répartion ne s'étale pas sur 4 cycles seulement : c'est bien plus évolué que ça. J'ai déjà tout expliqué (et remis il y a peu mon explication en citation).
Tu peux aller voir le HRM si tu veux.
Mais sinon, t'embetes pas : inutile d'admettre quoi que ce soit...

GEM était moderne et mieux foutu que le PorkBench. Le CP/M était fonctionnel et n'était qu'une couche de l'OS.

C'est pour ça que IBM a récupéré de la technologie de l'amigaOS pour l'OS et microsoft pour directX. Et le ST, qu'est-ce qui a été repris ? Hmmm...
C'est pire que ça : Apple a  fait un procès pour le GEM qui était sorti sur PC et qui copiait trop le mac (et ils ont gagné). Le GEM du ST le copie tout autant mais apple n'a jamais attaqué : le bricolage ne leur faisait pas peur...

De plus, le son DMA du STE a pu s'intégrer facilement dans ce schéma.

Bien sur, vu la bande passante nécessaire à un son DMA. Rien de plus facile...

Mon PC actuel est 64bit, il est hérité de l'architecture 8/16 des premiers PC.

Et il lui en coute : un x64 est obligé d'intégrer tous les élements nécessaires à une retro-compatibilité. A cause de ça, à fréquence et nombre de transistor identiques, il se fait exploser par le PowerPC...
Quand à l'OS, il est obligé d'inclure une rétro-compatibilité via emulation. Tout ça a un coup pour l'OS...

- De même, pour utiliser un 68000 à 16 mhz, devoir ajouter de la mémoire cache, pour ne l'exploiter en fait qu'à 50 %.

Problème récurrent de l'informatique courante. Ton CPU n'a pas de cache peut-être?   

Avoir une mémoire à 8 Mhz et un cpu capable d'y acceder à la vitesse de 4 Mhz pour au final devoir mettre un cache (qui est en dehors du cpu : rien à voir avec ce que tu  dis) pour que ça suive n'a jamais été un problème récurrent de l'informatique... Sauf pour le ST ! 

super évolutif le A1200, tu l'étends et plus rien ne fonctionne.  magnifique conception

pourtant il y en a des tonnes d'A1200 étendus... J'ai du rever...  

Lui non plus n'a pu répondre. Son tableau de cycles était douteux.
Tu n'avances aucun élément objectif pour démontrer que le ST était "bricolé".

Pas de ma faute si tu n'as rien compris. Relis-le lentement ou va voir le HRM.

ah bon , maintenant il y a "coprocesseur" et "coprocesseur style amiga" ?  tu racontes n'importes quoi, un coprocesseur EST un coprocesseur.  le YM2149  du ST est aussi un coprocesseur pour que tu saches !  

Donc le YM execute un programme ? C'est pour ça alors que le son est si pourri ? Parce qu'il est occupé à executer des instructions que personne n'a jamais vues ?

Tout comme commodore promettait une machine super fiable pro avec le A1000 et c'était une usine à bugs.  L'architecture  ST semble bien avoir été pensé évolutive puisque la gamme des MegaST, Ste, TT, Falcon, ont bel et bien existé.  Le ST a donc pu bel et bien évoluer comme prévu.  Le blitter, dans certains cas, en puissance brute, est plus rapide que celui de l'amiga, il n'avait pas menti ( par exemple pour l'effacement d'un écran )

ça c'est vrai. En cas d'effacement le blitter du ST est plus rapide (et c'est le seul cas, tu peux enlever le par exemple). Note qu'en cas d'effacement le 68000 du mig tourne à vitesse quasi normal : ses accès mémoires seront arrondis au multiple de 4 cycles supérieur, exactement comme le ST quand le blitter est à l'arret. Il n'empeche : il aurait été interessant d'avoir un mode ou le blitter aurait tourné à fond en cas d'effacement. Son architecture en pipeline l'en empeche.

pas du tout, les données non chipset ( son, video etc..)  sont évidemment logées en TT RAM.

pas du tout : quand un programme demande de la memoire sur ST, il ne peut pas préciser son type. Si tu veux utiliser la TT-RAM faut l'attaquer directement sans passer par l'OS (super pour la compatibilité...). ça oblige à réécrire une partie des applis (ce qui a rarement été fait...). Sur le mig, on passe par l'OS depuis la première version sur la première machine. Et dès qu'on met une carte accélératrice dans n'importe quel Amiga, on en profite à fond... Le TOS n'est pas foutu de fonctionner avec un 68010, un cpu 32 bits ou meme un coprocesseur. Et on veut nous faire croire qu'il était utilisé pour la 3D ?  
C'est sur : un ordinateur non évolutif, y a pas plus pro

[stapha92]

Alors, tu n'as pas compris. Le blitter a été très bien intégré.
Le mettre en concurrence avec le CPU est plus malin qu'avec tous les autres composants (Video...).
En effet, les programmes de cette époque étaient séquentiels. 

MOVE...
MOVE...
BLIT...
MOVE...
COMPUTE...

Au moins on savait où on était.
Avec le système anarchique de l'Amiga, bien malin qui peut dire à quel endroit du code assembleur le blit va se terminer. Le plantage n'est pas loin.
C'est pourquoi l'exemple de la doc Atari (qui est correcte, ainsi que son blitter) se contente de relancer le blitter en attendant une interruption éventuelle.

Tu devrais arreter de parler du mig : tu éviterais de dire des betises. Non seulement on peut savoir précisément ou le blit va s'arreter mais, en plus, on n'en a même pas besoin...

Le blitter du mig est en concurrence avec quoi a ton avis ? Avec la vidéo ? Donc quand le blitter du mig travaille, il n'y a plus d'affichage ? Trop ridicule comme toujours...

Tu parles beaucoup mais si tu abordais les cycles réservés aux shifter quand il n'y a pas d'affichage : pourquoi ne pas les avoir attribué au blitter ? ces cycles ne sont utilisés par rien...

Apprend à connaitre le fonctionnement du ST et du mig : quand ce sera fait tu n'oseras plus les comparer...

Et l'architecture est définie par le CPU et le bus, pas par les coprocesseurs. 

Encore une betise...

[Invité]

Avec le système anarchique de l'Amiga, bien malin qui peut dire à quel endroit du code assembleur le blit va se terminer. Le plantage n'est pas loin.

J'espère qu'au moins tu sais que le blitter sur amiga génère une interruption quand il a fini ??
Et qu'il est aussi possible de l'interrompre pendant un blit ??, et avec le copper en plus ??

ça c'est vrai. En cas d'effacement le blitter du ST est plus rapide (et c'est le seul cas, tu peux enlever le par exemple). Note qu'en cas d'effacement le 68000 du mig tourne à vitesse quasi normal : ses accès mémoires seront arrondis au multiple de 4 cycles supérieur, exactement comme le ST quand le blitter est à l'arret. Il n'empeche : il aurait été interessant d'avoir un mode ou le blitter aurait tourné à fond en cas d'effacement. Son architecture en pipeline l'en empeche.

C'est vrai à condition de le faire pendant l'affichage et sans utiliser le 68k sur amiga, sinon non .
Maintenant blitter VS blitter celui de l'amiga est plus rapide si tu lui laisses tout les cycles DMA .

Exactement Touko. Et Atari a l'audace d'appeler ce mode "cooperatif" !   

Si c'est le cooperatif façon atari, CAD avec rien du tout 

Tout a fait. C'est ce que Touko et moi te disons depuis le début : le 68000 n'est pas doué pour les interruptions ! Faut être idiot pour les rendre encore moins efficace !

Et quel est le con qui utiliserait des div dans son code en ayant un besoin vital des interruptions ??
Comme je l'ai dit, dans le cas où l'interruption doit être juste dans la scanline (peu importe où) ça va, par contre dans le cas de code timé c'est juste pas possible,dans le cas du STE, blitter + div, même dans tout les cas c'est tendu,voire pas possible sans rater la scanline .

[rocky007]

Il faut effectivement faire preuve d'une grande imagination pour combler les lacunes du ST. Mais des fois ça ne marche que dans les démos (code synchronisé justement) : j'attend toujours un jeu avec un scrolling horizontal digne de ce nom sur ST..

le pire est que tu sais que cela est techniquement possible, simplement personne n'en a le courage

Cela Rocky, je suis bien d'accord avec toi : le blitter n'est pas si mauvais que ça et c'est vrai que c'est un plus. Le problème est qu'il aurait du être meilleur que celui du mig (et était annoncé comme ça) car conçu bien après. Le fait qu'il ne soit même pas aussi bien (alors qu'il tourne à 8MHz vs 7,14Mhz) pose question...

on peut en dire autant de l'A1200, comment après 6 ans ils n'ont pas su le faire évoluer plus ?  cela pose aussi question... les erreurs sont dans les deux camps, faut pas rêver

le Kicstart 37.300 est celui du A600. Y en a pleins aujourd'hui qui tournent avec une carte bien plus grande sans que cela pose problème...

c'est pourtant une info reprise également sur lemon

http://www.lemonamiga.com/help/kickstart-rom/kickstart-rom-2-0-5.php

Non je ne critique pas leur choix. Sinon je pourrai critiquer tout autant celui de ceux qui codent sur mig en 2016...
Oui en faible résolution mais la fluidité est plus importante pour le gameplay.

tu dis cela alors que 80% des jeux actuels ne tournent pas en 60 FPS

30 couleurs ? ou ça ? tu comptes la zone de score ? Voyons c'est bon pour la pochette ça !

cela ne change rien au fait..as-tu 30 couleurs sur ton C64 ?

200 sprites ? On est loin de la moitié de la moitié de ça, alors qu'on est en 3 vbl...
Et il est ou le scroll horizontal à la battle squadron (qui apporte au gameplay puisque ça élargit le champ de jeu) ? Le c64 n'a pas de problème pour ça lui...

là n'est pas la question, refais Lethal Xcess sur C64, exactement identique, et tu pourras dire que le C64 est supérieur. 
ce n'est pas le cas, il est incapable de faire 320x200 comme le ST en fait. Tu utilises un des avantages du C64 pour en faire une généralité, un ordinateur ne se résume pas à sa faculté de faire un scrolling

Oui un jeu de plateforme fluide.... sur STE. Donc pas pour la majorité des possesseurs d'atari ST (meme ceux qui ont un blitter). Avec un seul plan. Tout ça en 1992...

ce n'est pas la faute d'Atari si les codeurs de jeux n'ont pas exploité leurs machines

Ben dans Win10, les fichiers cachés et système ne sont pas affichés par défaut...

il y a une différence entre un fichier système dont tu n'es pas censé toucher et des fichiers classiques.  le système Atari est celui repris sur tout les GUI, sans workbench < 2.0

Ils ont ajouté une option rarement utile, donc désactivée par défaut. Et le ST il fait quoi lui ? Ben  il affiche betement TOUS les fichiers quoiqu'il arrive et dans toutes les versions du TOS, non ?

non si tu le désires tu peux aussi cacher un fichier ou un repertoire

Je peux comprendre qu'on puisse préférer un choix plutot que l'autre mais quand on a un cli, celui du wb me parait très cohérent. Cela dit, à partir du 2.0 les amigaistes auront le choix. Les Stistes jamais...

non moi je ne trouve pas, et je ne suis pas le seul puisque commodore l'a instauré lui même dans son WB 2., c'est que je ne devais pas être le seul à trouver cela stupide de repasser dans un CLI pour avoir le contenu complet de ma disquette alors que j'ai une GUI

Dans l'absolu c'est possible, dans le mig ça existe, dans le ST non (a part lancer une instruction juste après avoir lancé un blit...)

donc c'est possible, tu confirmes merci

C'est pire que ça : Apple a  fait un procès pour le GEM qui était sorti sur PC et qui copiait trop le mac (et ils ont gagné). Le GEM du ST le copie tout autant mais apple n'a jamais attaqué : le bricolage ne leur faisait pas peur..

ce que tu n'expliques pas, c'est que suite à ce procès, le GEM du ST a été modifié pour qu'il soit légal...donc normal qu'il n'y avait pas de procès !  évidement si tu n'expliques pas tout ! 

.pourtant il y en a des tonnes d'A1200 étendus... J'ai du rever...

oui et combien fonctionnes avec de bugs ?

Donc le YM execute un programme ? C'est pour ça alors que le son est si pourri ? Parce qu'il est occupé à executer des instructions que personne n'a jamais vues ?

as-tu des difficultés à lire ?  où ais-je indiqué qu'il exécutait un programme ?

pas du tout : quand un programme demande de la memoire sur ST, il ne peut pas préciser son type.

mais là on ne parle pas du ST.  On parle du TT et de sa TT RAM

[stapha92]

Merci. Pour les sprites j'ai trouvé 

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

Par contre je ne comprends pas le sens exact de cette phrase

Enfin, chacun des huit sprites peut maintenant avoir sa propre palette. A noter que le plus gros point noir n'a pas été résolu : toute surcharge du bus (écran en suraffichage par exemple) entraînera encore et toujours la disparition d'un à sept sprites (snif !)


Comment surcharge t'on ce fameux bus ?
Quelle est sa bande passante ? 
Suraffichage = overscan ?
Et pourquoi les sprites disparaissent ?

On surcharge ce fameux bus en poussant l'overscan horizontal et en utilisant le scrollong hardware horizontal. Deux élément qui obligent le circuit vidéo à charger les données graphiques bien plus tot, ce qu'il fera au moment ou il charge les sprites habituellement.
Par contre, je ne pense pas qu'on puisse perdre 7 sprites...

Et les sprites disparaissent car ils représentent le canal DMA le moins prioritaire : l'Amiga n'est pas une console. C'est le seul cas ou un canal est perdu et pas seulement décalé (mais on peut toujours les avoir en chargeant leurs données avec le cpu ou le copper)

Sinon pour les sprites AGA, les nouveautés sont :
 - Palettes indépendantes en mode 16 couleurs (avec l'OCS les palettes étaient indépendante uniquement en mode 4 couleurs)
 - 64 pixels de large vs 16 (les sprites faisant toute la hauteur de l'ecran, on peut donc avoir un layer complet avec 5 sprites...)
 - 3 résolutions disponibles (basse, haute et super haute)

 Ne peut-on pas utiliser le DMA du St comme un blitter ?

Un canal DMA (dans le ST comme dans le mig) permet juste de lire des données transmises à un circuit. Un blitter doit lire, traiter et ecrire des données.

 Pour le débat sur Shiraz Shijvi, je vous invite, Rocky et Babsimov, a aller sur des forums C64 : il est détesté par les amateurs de cette machine...
 Moi je pense qu'il n'a rien fait sur cette machine  : sa fameuse interview montre qu'il n'y connait rien. Il ne fait que de la com et tramiel l'a utilisé parce que son nom était connu (parce qu'associé, à tort, au C64...).
 Les ingé Atari ont fait du bon boulot honnetement : ils ont atteint l'objectif fixé dans le délai imparti (il est notoire d'ailleurs qu'il y avait pleins de Mac démontés chez Atari pendant le dev du ST). Rien à dire là dessus. Et s'il n'y avait pas eu le mig, cela aurait le meilleur micro de son époque (car bien meilleur que le Mac, le PC n'en parlons même pas). Une autre bonne idée qu'avait eu les ingénieurs Atari concernait l'impression laser : le moyen qu'ils ont trouvé pour en commercialiser une bien moins chère que la concurrence était de sortir un modèle qui ne possèdait pas (ou très peu) de RAM. Vu le prix de la RAM à l'époque, il est facile de mesurer l'économie réalisé en supprimant 1 Mo (voire plus sur certains modèles). C'est la RAM du ST qui était utilisée (bien sur pas un 520 mais les ST étaient les champions du prix de l'octet).
 Ils l'a proposaient ainsi dans un package avec un ST et un écran mono à un prix défiant toute concurrence. Ainsi, non content de démocratiser la technologie 16 bits, ils ont fait pareil avec l'impression laser.
 
 C'est ce genre de chose que les STistes devraient mettre en avant...

[dlfrsilver]

le pire est que tu sais que cela est techniquement possible, simplement personne n'en a le courage

Il y a bien un truc en cours, mais c'est d'une complexité folle en terme de programmation. J'ai mal à la tête à la place du mec......

on peut en dire autant de l'A1200, comment après 6 ans ils n'ont pas su le faire évoluer plus ?  cela pose aussi question... les erreurs sont dans les deux camps, faut pas rêver

Tu n'as pas compris la philosophie derrière le 1200. le but était de le vendre à prix sympa, tout en pouvant augmenter et faire évoluer sa puissance par la suite avec une carte. 

c'est pourtant une info reprise également sur lemon

http://www.lemonamiga.com/help/kickstart-rom/kickstart-rom-2-0-5.php

Coupons la poire en deux. Il y a une révision de kickstart pour le 600 qui pose problème avec les disque dur. A l'inverse, le Kick 37.350 est la dernière révision pour A600, et celle-ci supporte sans aucun problème les disque durs (même les gros). Mon A600 utilise cette révision du kickstart d'ailleurs.

ce n'est pas la faute d'Atari si les codeurs de jeux n'ont pas exploité leurs machines[:quote]


En fait, je l'avais déjà expliqué par le passé. Ce que tu appelles exploiter l'Atari, en soit je ne suis pas d'accord. Les programmeurs ayant fait tout ce qu'ils pouvaient pour tirer le maximum de la machine.


Mais voilà, quand tu programmes un logiciel commercial, tu peux pas perdre ton temps à coder une pauvre routine sans avoir de certitude en bout de compte. T'es payé pour fournir un résultat, pas pour faire de la sorcellerie informatique, dont les acheteurs en bout de course n'ont strictement rien à fouttre.


CQFD l'explication d'Erik Simon de chez Thalion qui disait qu'au final ça ne servait à rien, puisque les gens en ont rien à carrer. 

non si tu le désires tu peux aussi cacher un fichier ou un repertoire

Et comment ? Depuis le GEM y a aucune option pour faire cette opération.

non moi je ne trouve pas, et je ne suis pas le seul puisque commodore l'a instauré lui même dans son WB 2., c'est que je ne devais pas être le seul à trouver cela stupide de repasser dans un CLI pour avoir le contenu complet de ma disquette alors que j'ai une GUI

Tu peux pas comprendre, tu l'aimes trop ta console à disquette Atari :)

donc c'est possible, tu confirmes merci

Il a dit que c'était pas possible, pourquoi t'insistes ?

oui et combien fonctionnes avec de bugs ?

C'est ça que tu comprends pas, il y a des bugs, mais ceci n'empêche absolument un fonctionnement correct de la machine, contrairement à l'Atari ST, ou ça entraine même des bizarreries en terme de coding. 


J'imagine à l'époque, ceux qui transcodaient du ST vers l'Amiga, et qui ne savaient pas pour les différentes d'architecture malgré l'utilisation du même CPU, forcément ça ne pouvait déboucher que sur des conneries. Je prends le cas de super wonderboy in monsterland, mais c'est criant comment la programmeuse s'est complètement foirée sur ce soft. Et si ça se trouve c'est exactement à cause des bizarreries propres au hardware bancal du ST que la version Amiga est toute merdeuse.

[Invité]

on peut en dire autant de l'A1200, comment après 6 ans ils n'ont pas su le faire évoluer plus ?

On te l'a déjà dit que dés 89/90 un hardware bcp plus puissant venait d'être finalisé par miner avant son départ.
L'AGA n'est qu'une machine sortie à l'économie pour essayer de sauver les meubles, car commodore n'avait plus les moyens de promouvoir une machine entièrement nouvelle et aussi bcp plus chère et je pense aussi que commodore a eu peur de l'effet A1000 .

[rocky007]

Pourquoi j'aurai nié que l'AmigaOS 1.0 avait des bugs ? Il a été fait trop vite pour tenir un délais comme je te l'ai indiqué. Par contre, quand on te pointe des bugs du TOS, tu ne les reconnais même pas.

si il y a des bugs dans le TOS mais largement moins et qui n'ont pas de conséquence, alors que dans le A1000 cela le rend totalement instable.  Le manque de temps n'est pas une excuse pour une machine de ce prix

Car, que je sache le TOS au début n'était pas plus terminé que l'AmigaOS 1.0, il n'était pas en ROM non plus, mais en disquette, justement parce qu'il y avait encore du travail à faire dessus.

oui pendant qq mois en effet, il n'aura pas fallu 2 ans

Bugs logiciels que seront corrigés. Mais, de toute façon, tu détestes tellement l'Amiga que même avec des vidéos sous les yeux qui te montrent que ça fonctionne (test en plateau télé de présentation de l'Amiga), tu ne le crois pas.

je n'ai jamais dit que cela ne fonctionnait pas, mais il y a une sacrée marge entre la réalité et vos propos "il aura fallu attendre Win 10 pour avoir la même qualité que WB".  ça marchait mais pas aussi bien que vous vous souvenez

Le TT devra utiliser une "Fast RAM" et abandonner le blitter du ST trop lent (au lieu d'en proposer un nouveau plus rapide). Le Falcon se trainera le bus 16 bits du ST, avec un processeur 32 bits. Si t'appel ça de l'évolutivité, j'appel ça bricoler autour d'une architecture bancale dès le départ.

parce que le A1200 est une belle preuve d'évolutivité ?  avec 80% de son chipset n'ayant pas évolué ?

Spéculer... Dans son interview il a clairement fait comprendre à Jack Tramiel, à demi mot, que c'était idiot d'avoir viré les ingénieurs d'origine. Et AMY était bien prévue pour un 68000.

. donc selon toi, on pourrait simplement mettre Paula dans un ST ?  il est aussi prévu pour un 68000

TRIPOS était une très bonne solution, salué par des applaudissement et porter assez vite par Metacomco.

et non repris dans les meilleurs OS par Byte...contrairement à CP/M

Parce que même de nos jours, il n'y a pas sur les cartes mère PC des composants tierces buggès ? Ils font quoi dans ce cas les fabricants de la carte mère, il te reprennent ta carte mère et te l'échange ?

ben oui, quand un bug empêche du matos de fonctionner, c'est repris par le constructeur

Je me souviens plus des bugs pour Ramsey et DMAC, si tu pouvais me dire ?

aucune idée, c'est juste répertorié comme chipset défectueux

Ben c'est pas ce qui était expliqué. Et, entre ce que tu dis et une explication en détail de la part de Stapha92, je préfère celle Stapha92 qui a quand bien moins souvent que toi dit des choses erronées.

et oui, on ne croit que ce qui arrange sa conscience

Quand à me documenter, je pense justement que je vais régulièrement vérifier ce qui est dit, y compris tes propos... souvent erronés. Comme quand tu disais, lorsque j'ai abordé le point en question, que sans patch il était impossible de lancer le Workbench 1.3 avec un 68020... Pas de chance ça fonctionne en natif, comme le lien vers la discussion que j'avais cité le confirmait.

je parlais du WB 1.3 sur A1200, pas sur un A500

Commodore et l'équipe Amiga a écouté Motorola et son OS tournait avec un 68020, sans modification nécessaire.
Mais, glorifions le ST, c'est de bon ton, si Atari à fait ce choix, c'était pour tirer les prix, bonne décision sur le court terme...

joli air de violon...et au final quel est le problème ?  tu ouvres de toutes façon ta machine pour mettre ton 68020, sur ST aussi, aussi qu'en même temps la carte accélératrice embarque un nouveau TOS.  donc qu'est ce que cela peut il faire ?  l'utilisateur au final, il est même content, il a un TOS plus récent dans sa machine, ce n'est que bénéfice

Pire de laisser tomber purement et simplement le Falcon040 et la communauté ST (qui était sa base) pour se concentrer sur les consoles de jeu...

et commodore n'a pas terminé sa carrière avec le CD32 ?  c'est pas une (mauvaise) console de jeu ?

T'es tellement réaliste que tu prétendais que le transputer Atari était LA station graphique la plus puissante de son temps ! C'est plus du réalisme à ce niveau, mais du surréalisme  

et toi tu disais que Jurrasic Park avec été entièrement réalisé avec un A500 + floppy

Ben non, j'ai lu que justement qu'on t'a expliqué que non.

ben si, la display list est autonome du CPU

Je t'ai expliqué pourquoi Commodore à coulé, ce n'est certainement pas à cause de l'Amiga et de sa technologie, qui était le véritable atout de Commodore. Mais bien à cause des décisions stupides de la direction.

si ils avaient adapté Win 3.1 dessus, les choses seraient peut-être différence.

Bien entendu les ingénieurs étaient contre, car ils savaient que la communauté Amiga n'aurait pas acheté ça. Et ils avaient raison, car, lorsque cette information a été divulguée, après la faillite, c'était un rejet dans la communauté.

évidement, la communauté ne voulait que des jeux vidéos piratés et une nouvelle version de XCOPY

Gateway2000 en rachetant l'Amiga avait clairement dit qu'ils cherchaient un moyen de se passer du monopole Microsoft, avec leur propre machine. Ils ont allouer un gros budget pour la mise au point d'un nouvelle machine moderne, d'un version mise à jour en conséquence de l'OS.

non mais sérieux, qu'est que Amiga représentait en 97 comme menace pour Microsoft.  C'était plié depuis longtemps.
microsoft fait du logiciel, pas d'ordinateur.    Win 95 s'est vendu à 40.000.000 d'exemplaires...vendu, on ne compte pas le nombre de version pirate.  Tu pense vraiment que ton AmigaOS avait un quelconque intérêt ?  Il n'a jamais été racheté par les gros, preuve que la technologie et les brevets étaient désuets

Le CP/M je dis pas que ce ne fut pas bien en son temps, juste qu'en 1985 ce n'était plus son temps.

c'est pour cela qu'il  a été amélioré en GEMDOS.  et le GEM était suffisamment intéressant pour que Microsoft pense à le commercialiser.  Est-ce le cas de WB ?

Je vois pas le ST ? Il y a même le Commodore PET pourtant... même le Xerox STAR, que des ordinateurs pro...

et en quoi cela est étonnant, le ST n'a pas innové sur le plan technologique

Les 20 plus gros vaporware :
https://archive.org/stream/byte-magazine-1995-09/1995_09_BYTE_20-09_20_Years#page/n187/mode/2up

Windows95 est dedans... pourtant il était tellement bien selon toi. WindowsNT aussi est dedans !

tu sais ce que veux dire vapoware ? cela ne veut pas dire mauvais