Re: GUERRE ST-AMIGA, FIGHT !!!

[dlfrsilver]

Pour la fenêtre je connaissais (voici une question avec une arrière pensée....).

tu penses que j'avais pas vu ? ahahah lol

Sur le Gem, c'est beaucoup plus simple encore une fois.
De manière générale, la gestion des fenêtres est beaucoup plus simple que sur Amiga.

Je ne vois pas en quoi, c'est exactement le même principe que sur amiga, la différence c'est que c'est plus lent et plus moche sur le ST.

Encore une preuve que le WB n'est pas terminé.

C'était la première version du WB grand public. Il était appelé à évoluer.

sur ST c'était figé et foiré dès le départ. de 1985 à 1990 ceux qui ont acheté un ST ont du se fader la même chiasse qu'était le GEM, comme au début en 1985 alors qu'il était déjà totalement dépassé.

Franchement je pense que cela pourrait intéressant de faire un comparatif filmé des manipulations des fenêtres, formatages, directory,...... sur le Gem et le WB.

Oui sans problème.

- La manipulation des fenêtres sur amiga est plus rapide sur que ST ;
- Le formatage d'une disquette en temps à voir, j'ai pas de chrono sous la main.
- l'affichage des directory est plus long que sur ST, car les programmes et les fichiers sont plus lourds. Le ST a moins de données à charger depuis un disque de 720ko formaté avec le GEM.

Les outils que j'avais sur le WB étaient fournis avec. Les ST les mêmes outils fallait les avoir, mais c'était pas fourni, c'était en plus !

Oui je connais bien le ST..... que trop hélas

Maintenant tous les outils que tu avais sur le WB tu pouvais les avoir aussi sur le GEM. Je me demande si tu connais réellement le St ?

[ryosaeba]

Quels outils qui étaient founis avec le WB ne pouvaient pas exister sur le St ?

[dlfrsilver]

Quels outils qui étaient founis avec le WB ne pouvaient pas exister sur le St ?

Les outils non fournis d'office avec le bureau GEM à l'achat d'un atari ST mais fournis de base avec l'A500 :

- Le Shell
- Le CLI
- L'horloge
- notepad
- paramétrages de la vitesse de la souris et du clavier
- L'outil de gestion de disques dur gérant des disques dur allant jusqu'à 2,5Go

Et j'en passe.

Tout ça c'était pas fourni avec le ST, fallait les copier ou les acheter en plus !


Hé, finalement, j'ai utilisé le chronomètre sur mon téléphone portable pour mesurer les temps de formatage :

Test de formatage sur le workbench de mon Amiga 500  en mode complet :

- 1 mn 20 secondes 28 centièmes - pour formater 901120 octets (880k)

Test de formatage sur le GEM de l'Atari ST (1040 STF) en mode complet double face :

- 1 mn 35 secondes 23 centièmes - pour formater 726016 octets (720k).

Je serais à votre place les gars, je me ferais tout petit, sans déconner !

15 secondes de plus que l'Amiga sur un ST pour formater 720 malheureux kilos quand l'Amiga est plus rapide pour formater 160ko de plus !!

Ah oui vous pouvez vous moquer et la ramener avec votre histoire du ST qui est plus rapide, tu parles encore un mythe à 2 balles qui s'effondre !

Putain sur la même lancée, je crois vraiment que je vais finir par faire la vidéo de comparaison pour Vroom entre la version Amiga et ST, et ça sera la deuxième baffe de la journée pour le ST

[ryosaeba]

Quels outils qui étaient founis avec le WB ne pouvaient pas exister sur le St ?

Les outils non fournis d'office avec le bureau GEM à l'achat d'un atari ST mais fournis de base avec l'A500 :

- Le Shell
- Le CLI
- L'horloge
- notepad
- paramétrages de la vitesse de la souris et du clavier
- L'outil de gestion de disques dur gérant des disques dur allant jusqu'à 2,5Go

Et j'en passe.

Tout ça c'était pas fourni avec le ST, fallait les copier ou les acheter en plus !


Hé, finalement, j'ai utilisé le chronomètre sur mon téléphone portable pour mesurer les temps de formatage :

Test de formatage sur le workbench de mon Amiga 500  en mode complet :

- 1 mn 20 secondes 28 centièmes - pour formater 901120 octets (880k)

Test de formatage sur le GEM de l'Atari ST (1040 STF) en mode complet double face :

- 1 mn 35 secondes 23 centièmes - pour formater 726016 octets (720k).

Je serais à votre place les gars, je me ferais tout petit, sans déconner !

15 secondes de plus que l'Amiga sur un ST pour formater 720 malheureux kilos quand l'Amiga est plus rapide pour formater 160ko de plus !!

Ah oui vous pouvez vous moquer et la ramener avec votre histoire du ST qui est plus rapide, tu parles encore un mythe à 2 balles qui s'effondre !

Putain sur la même lancée, je crois vraiment que je vais finir par faire la vidéo de comparaison pour Vroom entre la version Amiga et ST, et ça sera la deuxième baffe de la journée pour le ST

Tu ne réponds pas à la question pour les outils..... Pour ton formatage,tu prends en compte le chargement du WB ? Des changements incessants de D7 (?) ?

[dlfrsilver]

Quels outils qui étaient founis avec le WB ne pouvaient pas exister sur le St ?

Les outils non fournis d'office avec le bureau GEM à l'achat d'un atari ST mais fournis de base avec l'A500 :

- Le Shell
- Le CLI
- L'horloge
- notepad
- paramétrages de la vitesse de la souris et du clavier
- L'outil de gestion de disques dur gérant des disques dur allant jusqu'à 2,5Go

Et j'en passe.

Tout ça c'était pas fourni avec le ST, fallait les copier ou les acheter en plus !


Hé, finalement, j'ai utilisé le chronomètre sur mon téléphone portable pour mesurer les temps de formatage :

Test de formatage sur le workbench de mon Amiga 500  en mode complet :

- 1 mn 20 secondes 28 centièmes - pour formater 901120 octets (880k)

Test de formatage sur le GEM de l'Atari ST (1040 STF) en mode complet double face :

- 1 mn 35 secondes 23 centièmes - pour formater 726016 octets (720k).

Je serais à votre place les gars, je me ferais tout petit, sans déconner !

15 secondes de plus que l'Amiga sur un ST pour formater 720 malheureux kilos quand l'Amiga est plus rapide pour formater 160ko de plus !!

Ah oui vous pouvez vous moquer et la ramener avec votre histoire du ST qui est plus rapide, tu parles encore un mythe à 2 balles qui s'effondre !

Putain sur la même lancée, je crois vraiment que je vais finir par faire la vidéo de comparaison pour Vroom entre la version Amiga et ST, et ça sera la deuxième baffe de la journée pour le ST

Tu ne réponds pas à la question pour les outils..... Pour ton formatage,tu prends en compte le chargement du WB ? Des changements incessants de D7 (?) ?

Tu n'as pas toi même correctement répondu à ma propre affirmation, et ta question n'est pas en relation avec mon affirmation, ce qui indique que tu n'as pas compris ce que je disais.

Pour le formatage, je suis désolé mon grand, mais on compare 2 choses comparables :

1) temps de formatage départ - arrêt
2) si je mets pas de disquette dans mon lecteur sur le ST, il faut attendre une plombe avant que le GEM ne s'affiche.
3) y a pas de changement incessant de disquettes sur Amiga. Je sais pas ou t'as vu ça, mais ça n'existe pas.
Les seuls changements se font quand tu utilises un seul lecteur de disquette et que tu utilises un outil qui demande à acceder à la disquette workbench. Quand le formatage est lancé, l'amiga ne s'arrête pas, il trace de la piste 0 à 79.

Donc c'est bien ce que je disais, Formatage : amiga = 1 ; Atari ST = 0. Quand je dis que le ST est une bécane lente, c'est pas une vue de l'esprit, 15 secondes perdue sur ST pour formater une disquette qui fait 160ko de moins que celle de l'Amiga,

T'as quoi à dire la dessus ? sinon reconnaitre que le ST est plus lent pour ça qu'un A500, alors ?

[ryosaeba]

Quels outils qui étaient founis avec le WB ne pouvaient pas exister sur le St ?

Les outils non fournis d'office avec le bureau GEM à l'achat d'un atari ST mais fournis de base avec l'A500 :

- Le Shell
- Le CLI
- L'horloge
- notepad
- paramétrages de la vitesse de la souris et du clavier
- L'outil de gestion de disques dur gérant des disques dur allant jusqu'à 2,5Go

Et j'en passe.

Tout ça c'était pas fourni avec le ST, fallait les copier ou les acheter en plus !


Hé, finalement, j'ai utilisé le chronomètre sur mon téléphone portable pour mesurer les temps de formatage :

Test de formatage sur le workbench de mon Amiga 500  en mode complet :

- 1 mn 20 secondes 28 centièmes - pour formater 901120 octets (880k)

Test de formatage sur le GEM de l'Atari ST (1040 STF) en mode complet double face :

- 1 mn 35 secondes 23 centièmes - pour formater 726016 octets (720k).

Je serais à votre place les gars, je me ferais tout petit, sans déconner !

15 secondes de plus que l'Amiga sur un ST pour formater 720 malheureux kilos quand l'Amiga est plus rapide pour formater 160ko de plus !!

Ah oui vous pouvez vous moquer et la ramener avec votre histoire du ST qui est plus rapide, tu parles encore un mythe à 2 balles qui s'effondre !

Putain sur la même lancée, je crois vraiment que je vais finir par faire la vidéo de comparaison pour Vroom entre la version Amiga et ST, et ça sera la deuxième baffe de la journée pour le ST

Tu ne réponds pas à la question pour les outils..... Pour ton formatage,tu prends en compte le chargement du WB ? Des changements incessants de D7 (?) ?

Tu n'as pas toi même correctement répondu à ma propre affirmation, et ta question n'est pas en relation avec mon affirmation, ce qui indique que tu n'as pas compris ce que je disais.

Pour le formatage, je suis désolé mon grand, mais on compare 2 choses comparables :

1) temps de formatage départ - arrêt
2) si je mets pas de disquette dans mon lecteur sur le ST, il faut attendre une plombe avant que le GEM ne s'affiche.
3) y a pas de changement incessant de disquettes sur Amiga. Je sais pas ou t'as vu ça, mais ça n'existe pas.
Les seuls changements se font quand tu utilises un seul lecteur de disquette et que tu utilises un outil qui demande à acceder à la disquette workbench. Quand le formatage est lancé, l'amiga ne s'arrête pas, il trace de la piste 0 à 79.

Donc c'est bien ce que je disais, Formatage : amiga = 1 ; Atari ST = 0. Quand je dis que le ST est une bécane lente, c'est pas une vue de l'esprit, 15 secondes perdue sur ST pour formater une disquette qui fait 160ko de moins que celle de l'Amiga,

T'as quoi à dire la dessus ? sinon reconnaitre que le ST est plus lent pour ça qu'un A500, alors ?

Oui un seul lecteur de D7. Répond à ma question et pas par une pirouette ou en donnant des infos erronées.

[rocky007]

Bien sur que non. Depuis quand faire les maps des niveaux d'un jeu c'est du vol ? Sans parler des sprites ?

Tu ne connais strictement rien à la préservation de toute façon, donc je ne vais pas commenter ni débattre avec toi sur ce sujet.

Sérieusement, celle-là on me l'avait jamais faite, faut vraiment être..... Atariste pour sortir ce genre de chose ?

ah oui je vois le niveau..donc même sur des choses aussi élémentaires, tu ne connais pas.

tu rip des graphismes qui sont soumis à des droits d'auteur, et en plus, plus grave, tu les reproduits et diffuse probablement sur des sites.  cela s'appelle du vol.

bref, ce n'est pas bien grave je te l'accorde, mais c'est triste que c'est ta seule activité créative : voler le travail des autres, sous pretexte fallacieux de "préservation"..
ah bon ? tu préserves quoi ?  quand tu voles les sprites de Strider , tu préserves quoi ?  le jeu va disparaître du jour au lendemain de tout les site internet ainsi que les originaux ?

fais donc quelques chose par toi même, c'est pas bien difficke de vivre sa propre vie au lieu de vivre celle des autres.

[rocky007]

Sur un autre aspect, le bureau GEM n'est que l'interface graphique du Bios du ST (le TOS quoi!).

et voilà encore une connerie de plus...ça n'arrête pas avec toi.

le GEM c'est pas seulement le bureau de l'Atari, c'est tout l'environement graphique.  si tu codes un logiciel, tu peux faire appel aux fonctions du GEM pour afficher une fenêtre,
un menu déroulants, un selecteur de fichier etc..

[rocky007]

tiens ENCORE un bug sur l'amiga, ça n'arrête pas, même formatter une disquette, il en est incapable, il faut faire une modif hardware...quelle beauté

https://www.youtube.com/watch?v=Uoi9VXIlGF0

[rocky007]

Et bien, tout simplement parce que l'Amiga il attend pas qu'on insère une disquette DF0: ou DF1: mais un volume comme par exemple "Final Copy II install disk 1" puis "Final Copy II install disk 2" puis "Final Copy II install disk 3". Et si tu insères le disque 3 alors qu'il attend le 2, l'installation ne reprend pas. Et cette fausse manipulation là, elle m'est arrivé (car oui, un humain fait des fausses manips), mais l'Amiga il a pas continué l'install, ou été écrire sur la disquette 3 (soit dit en passant, protégée en écriture !).

c'est bien ce que je dis : l'amiga va changer démarrer le lecteur, se positionner pour lire le nim du volume..bref 2-3 secondes de perdues pour seulement afficher que c'est pas le bon volume. ( en espérant qu'il plante pas, et c'est un cas vécu, je ne compte les dizaines que jeux qui plantaient aux changements de disques, dès qu'on insérait un mauvais disque ).

et comme déjà dit, rien n'empêchant le codeur de faire d'ajouter ses 10 lignes de C dans son logiciel pour faire la detection automatique. 
plein de jeux Atari detectait tout seul le changement de disquettes.

L'Amiga appartenant à Commodore, si tu reconnais que le système existait sur Amiga, il est évident qu'il y a quelques part un brevet la dessus et qui appartient à Commodore. Mais, comme la fonction, là aussi est à l'avantage de l'Amiga... "c'est un peu ridicule d'en débattre"... belle objectivité !

apple est en procès avec samsung parce que Samsung a utilisé de la technologie apple dans les smartphone Samsung, et bien entendu Samsung n'a pas eu le culot de breveter la technologie apple. 
et toujours pour rappel , Commodore A PERDU SON PROCES !!!!  CQFD

Mais, bien entendu... aussitôt le GEM c'est la même chose... il exploite "si nécessaire" le hardware... on apprécie de savoir que le GEM est acceléré au Blitter (en tous cas pas dès l'origine, si tant es qu'il le soit vraiment), parce que, de ce que j'ai cru comprendre le blitter du ST bloque le système, donc pour une GUI c'est peut être pas l'idéal... Mais, là, il est vrai je m'avance peut être un peu et j'ai peut être tord.

ben désolé si c'est la cas.  le GEM est aussi un ensemble de librairires, qui exploite l'hardware de la machine.  sous pretexte que c'est GEM, alors c'est forcément primitif ? 

Ah bon, pourquoi tu ne donnes pas un modèle, une marque ?

 les PC sous win 3.1 NT, le X68000, l'archimede, FM town etc..




oui sur un A1000, avec HD, r2mb de RAM, un machine à 20.000 FF...   c'est une autre histoire sur un A500 de base..en fait, tu sais à peine faire tourner Deluxe Paint tout seul sur un A500.  de plus, tu parles d'un copié collé...c'est du multitâche ça ?  j'appelle ça du switch...du multitâche pour moi, c'est par exemple regarde une video et en même temps travailler sur un logiciel, et ça , ton amiga il explose !





désolé, mais je maintiens qu'offrir un OS multitâche sur une machine qui ne servira qu'à 99% pour des jeux, et pour 1% restant cela ne sert qu'à démarrer une calculatrice, je vois pas l'intérêt d'avoir investit là dedans.  C'est une bonne chose, rien à redire, mais je trouve cela superflu sur un A500 de base, ce qui représentait la quasi totalité du parc amiga.  et il n'y a pas de quoi frimer, le QL le faisait bien avant l'amiga.  Atari aurait pu tout aussi bien le faire, rien ne les empêchait. 




non tu as des cartes acceleratrices pour Atari ST, il y avait juste un bootloader à ajouter.  et puis quand bien même, qui s'offrait des cartes accélératrices en 1985 ??  t'es toujours à comparer les choses qui n'ont rien à voir : on parle du ST en 1985, toi tu parles des années 90 ( WB 2.0, carte accélératrices, etc..). 



pardon, c'est ATW800, pas ATX800






si des boîtes comme Invers on développé intensivement Calamus comme suite ultime PAO, tu crois vraiment que le GEM était pourri ?  tu les crois assez débile d'avoir préféré Atari à un super Amiga super WB ??

[dlfrsilver]

Sur un autre aspect, le bureau GEM n'est que l'interface graphique du Bios du ST (le TOS quoi!).

et voilà encore une connerie de plus...ça n'arrête pas avec toi.

le GEM c'est pas seulement le bureau de l'Atari, c'est tout l'environement graphique.  si tu codes un logiciel, tu peux faire appel aux fonctions du GEM pour afficher une fenêtre,
un menu déroulants, un selecteur de fichier etc..

J'aurais du dire peut-être la face visible du TOS ? le GEM est le GUI du ST, soit l'interface graphique !

Ok pour l'info :)

[dam's]

Enorme!
Forum relancé le 2 juillet 2015, et déjà à 39 pages! 
Y'a pas à dire cette bonne vieille guerre n'est pas loin de s'arrêter! :-)

Quoi que vous disiez, quoi que vous fassiez celui qui a la classe c'est l'Amiga 

[dlfrsilver]

tiens ENCORE un bug sur l'amiga, ça n'arrête pas, même formatter une disquette, il en est incapable, il faut faire une modif hardware...quelle beauté

https://www.youtube.com/watch?v=Uoi9VXIlGF0

La c'est toi qui raconte des conneries, t'as compris au moins ce que le mec explique dans la vidéo et la solution au problème ?

Non pas le moins du monde, sinon tu aurais posté quelque chose en corrélation avec la vidéo. Mais comme apparemment tu comprends l'anglais comme moi je comprends l'allemand, ça se pose là hein

Et si tu arrêtais de citer des bugs sur amiga qui sont en fait des pannes, ça nous arrangerait.

Comme t'es pas foutu de l'expliquer correctement aux gens qui lisent ce topic, c'est moi qui vais m'en charger.

L'utilisateur qui a confié son Amiga 1200 à RetroGameModz, un réparateur amiga bien connu sur youtube pour ses vidéos simples et fort bien expliquées, car il a eu subitement un problème pour formatter ses disquettes du jour au lendemain.

RetroGameModz a procédé à l'analyse à l'oscilloscope des possibilités de sources de la panne de prime abord, soit la porte (GATE), ou bien le signal 'SERIE' (SERIAL). Après examen de la schématique de l'Amiga 1200, il procède au test, qui confirme que le problème est côté GATE. Autre page de la schématique, qui montre les ports floppy, avec une resistance de 27ohms et une TTL 74LS86.

Après test sur les deux, RetroGameModz détermine un potentiel problème de piste coupée dans la carte mère.

Dans la deuxième vidéo faite par le propriétaire du 1200, celui-ci au vu des tests déjà effectués et de ses propres tests découvre qu'un condensateur SMD est la source du problème (un 47uf 16v) et que celui-ci à coulé, et bouffé au passage la dite trace, d'ou le problème !

Après remplacement du dit condensateur, il peut à nouveau formater.

Donc moralité de l'histoire, t'essaies de faire avaler aux gens que les pannes sont des bugs natifs de la machine, quelle stupidité !

PS : je ne t'en veux pas, comme cet utilisateur, mon A1200 utilise une carte mère identique à la sienne (rev 1D.4).

Et je n'ai aucun problème de mon côté (j'ai changé les condos en 2007 !).

[babsimov]

je ne dis pas que le WB est moins ou plus évolué. Je dis simplement qu'il est moins conviviale. De part sa convivialité, le GEM est plus conviviale. Je parle de l'environnement graphique.

Sauf qu'il ne l'es pas convivial. On est complètement à l'étroit avec ce truc, et visuellement c'est absolument immonde.

Même le WB 1.3 on peut lui affecter des couleurs moins laides que celles d'origine. Pitié !

Oui, c'est vrai que les couleurs du workbench 1.2/1.3 je les trouvais bien jolies (surtout celle de fond) et qu'on pouvait les modifier (a mince tu as dit que c'était moche, honte à toi ! Je plaisante, bien entendu). J'ai regretté le passage au gris terne du 2.0. Je l'avais déjà dis, l'Amiga, ordinateur couleur par excellence qui passait au gris, limite monochrome ça m'avait choqué quand même. Quand je suis passé au 3.0 j'ai vite fait changé tout ça et mis les MagicWB puis plus tard Newicon (ah Newicon, quel bon souvenir).

J'ignorais qu'on ne pouvait pas changer le vert du GEM. Pourtant je croyais avoir vu une image d'écran GEM qui n'était pas en vert, mais en gris ? C'était peut être sur l'écran monochrome alors ?

Mais, après, les gouts et les couleurs justement, chacun les siens, donc je ne sais pas si on peut critiquer sur ce point ? Par contre on peut très bien faire remarquer, si c'est confirmé, qu'on ne pouvait pas changer la couleur du GEM. C'est une information intéressante.

Tu peux m'expliquer comment tu fais pour agrandir une fenêtre sous WB ?

T'es sur de l'avoir utilisé pour autre chose que jouer ton Amiga, parce qu'avec une question comme ça j'ai de sérieux doute là ! Tu sous entends qu'on peut pas agrandir une fenêtre avec le Workbench là, si je comprends bien !

Voici deux vidéo (la première dure 01h30) ou tu devrais voir tout ce que tu veux voir :


La seconde est plus courte et montre le 1.3/2.0 puis 3.1 :


Voilà, je pense avoir répondu à ta question du mieux que je pouvais.

tiens ENCORE un bug sur l'amiga, ça n'arrête pas, même formatter une disquette, il en est incapable, il faut faire une modif hardware...quelle beauté

https://www.youtube.com/watch?v=Uoi9VXIlGF0

Je n'ai pas compris tous ce qui est écrit en commentaire en anglais, mais il est probable que ce 
1200 est un Escom qui avait un lecteur de disquette PC modifié, parce qu'Escom n'avait fait fabriqué des lecteurs de disquettes identique à ceux des Amiga de Commodore, pour économiser quelques centimes. Et il est connu que les 1200 Escom étaient capricieux niveau compatibilité. Il peut s'agir aussi d'un 1200 en panne tout simplement.
En 10 ans d'Amiga pas eu de problème avec mes lecteurs de disquettes, et pourtant ils en ont vu des disquettes !
J'espère que tu reconnaitra que c'est de la mauvaise foi.

babsimov]
Et bien, tout simplement parce que l'Amiga il attend pas qu'on insère une disquette DF0: ou DF1: mais un volume comme par exemple "Final Copy II install disk 1" puis "Final Copy II install disk 2" puis "Final Copy II install disk 3". Et si tu insères le disque 3 alors qu'il attend le 2, l'installation ne reprend pas. Et cette fausse manipulation là, elle m'est arrivé (car oui, un humain fait des fausses manips), mais l'Amiga il a pas continué l'install, ou été écrire sur la disquette 3 (soit dit en passant, protégée en écriture !).

c'est bien ce que je dis : l'amiga va changer démarrer le lecteur, se positionner pour lire le nim du volume..bref 2-3 secondes de perdues pour seulement afficher que c'est pas le bon volume. ( en espérant qu'il plante pas, et c'est un cas vécu, je ne compte les dizaines que jeux qui plantaient aux changements de disques, dès qu'on insérait un mauvais disque ).

et comme déjà dit, rien n'empêchant le codeur de faire d'ajouter ses 10 lignes de C dans son logiciel pour faire la detection automatique.  
plein de jeux Atari detectait tout seul le changement de disquettes.

Pourquoi à chaque fois tu ramène ça au jeu ! Je te parle d'installation de logiciels sous workbench (et même avec les jeux prévus pour disque dur ça marchait) !
Si ton jeu plantait au changement de disquette, c'est que c'est le jeu qui est mal programmé, pas un problème de l'Amiga ! 
Et ta remarque sur les jeux atari qui détectaient tout seul leur disque deux inséré ! Heureusement qu'un jeu qui zappe l'OS détecte ses propres disquettes ! C'était aussi le cas sur Amiga pour les jeux et démo non DOS !
Quand tu veux pas reconnaitre un avantage évident de l'Amiga, tu feras toutes les pirouettes possible. Seulement, puisque tu ne crois pas mon vécu au jour le jour, pourquoi moi je devrais croire le tiens avec TON CAS UNIQUE de disquette qui fait planter et qui surement était un jeu non prévu pour installation sur disque dur ! La, tu commences vraiment à m'énerver. Cette pause je pense que je vais me la prendre finalement.

L'Amiga appartenant à Commodore, si tu reconnais que le système existait sur Amiga, il est évident qu'il y a quelques part un brevet la dessus et qui appartient à Commodore. Mais, comme la fonction, là aussi est à l'avantage de l'Amiga... "c'est un peu ridicule d'en débattre"... belle objectivité !

apple est en procès avec samsung parce que Samsung a utilisé de la technologie apple dans les smartphone Samsung, et bien entendu Samsung n'a pas eu le culot de breveter la technologie apple.  
et toujours pour rappel , Commodore A PERDU SON PROCES !!!!  CQFD

Y a quand même un truc qui m'interpèle dès le début de cette histoire de procés. Comment Commodore aurait pu intenter un procés à Microsoft en 1995 pour l'autorun, puisqu'à partir de mai 1994, Commodore n'existe plus ? J'en avais pas entendu parler de cette histoire de procès. Le seul procès dont j'ai entendu parler était une histoire de commande XOR (me demande pas ce que c'est, j'en sais rien). Tout ce que je sais c'est que c'est ce qui a empêché Commodore de vendre la CD32 au Etats Unis et ce qui a accéléré sa faillite (entre autre). 

Mais, bien entendu... aussitôt le GEM c'est la même chose... il exploite "si nécessaire" le hardware... on apprécie de savoir que le GEM est acceléré au Blitter (en tous cas pas dès l'origine, si tant es qu'il le soit vraiment), parce que, de ce que j'ai cru comprendre le blitter du ST bloque le système, donc pour une GUI c'est peut être pas l'idéal... Mais, là, il est vrai je m'avance peut être un peu et j'ai peut être tord.

ben désolé si c'est la cas.  le GEM est aussi un ensemble de librairires, qui exploite l'hardware de la machine.  sous pretexte que c'est GEM, alors c'est forcément primitif ?  

Ma remarque ne concernait pas le fait que le GEM soit un ensemble de librairies, mais que ces librairies lui permettent d'utiliser une accélération hardware pour l'affichage, alors que techniquement il n'est avait pas (j'éspère que tu vas pas dire le contraire). Certes il y a eu le blitter sur les modèles suivants (je sais plus lesquelles), mais j'avais compris que ce blitter s'il est utilisé il bloque le système (peut être ais je mal compris). En tout cas les STF et précédent (les plus répandus) point d'affichage accéléré du GEM.

Ah bon, pourquoi tu ne donnes pas un modèle, une marque ?

 les PC sous win 3.1 NT, le X68000, l'archimede, FM town etc..

- Windows 3.1 NT, on parlait de 1988 et c'est sorti en 1993 et en plus c'est Windows NT 3.1.
https://fr.wikipedia.org/wiki/Windows_NT
Et en plus, je l'ai vu tourner ce Windows NT (tu te rappel du PC de compétition de l'Amigaiste au MP3... il était sous NT ! Et c'était en 1994/95 ou début 96. C'était une horreur de lourdeur ce truc... Et pourtant son PC était le TOP du TOP des PC de l'époque... C'est bien pour ça qu'il préférait travailler sur son 4000 avec sa 060. Et là aussi accélération hardware de l'affichage t'oublis sur NT. 

- X68000, comme je te l'ai dit, inconnu en Europe à l'époque et totalement hors du prix des ST et Amiga. Et toi, tu sais lire le japonais pour utiliser son OS ? Mais on progresse c'est 1987.
https://en.wikipedia.org/wiki/X68000
Mais, dès qu'on parle d'OS, ça m'a pas l'air bien folichon puisque c'est inspiré de MS-DOS et que je vois pas de mention de multitache. Donc, mauvaise pioche aussi !

- L'archimedes : Tiens, mais j'en avais pas parlé de celui là ? A l'époque c'est cantoné au marché britannique, c'est plus cher qu'un 500 (je te rappel la gamme de prix) et... c'est multitache coopératif ! Je sais même pas s'il y a le plug and play (peut être). Et le sujet sur l'archimèdes ici a montré que c'était pas au niveau d'un Amiga 500 ! Mais le premier modèle c'est 1987 (même année que le 500)
https://en.wikipedia.org/wiki/Acorn_Archimedes

- FM town : Encore une machine (très bien je te l'accorde) totalement inconnue en Europe et extrêmement cher. Et en plus c'est 1989 (on parlait de 1988). Par ailleurs l'OS est en japonais et de ce que je comprends est, lui aussi, basé sur MS-DOS (normal c'est un PC très amélioré), donc probablement monotache ou au mieux coopératif. J'ignore pour le plug and play. Donc, là encore mauvaise pioche.
https://fr.wikipedia.org/wiki/FM_Towns

oui sur un A1000, avec HD, r2mb de RAM, un machine à 20.000 FF...   c'est une autre histoire sur un A500 de base..en fait, tu sais à peine faire tourner Deluxe Paint tout seul sur un A500.  de plus, tu parles d'un copié collé...c'est du multitâche ça ?  j'appelle ça du switch...du multitâche pour moi, c'est par exemple regarde une video et en même temps travailler sur un logiciel, et ça , ton amiga il explose !

Non mais ou t'a vu que la démo de présentation il y avait 2 MB de ram et un HD ! Je suis même pas sur qu'en 1985 ce type d'extension existait déjà pour l'Amiga 1000 !
Si deluxe paint tourne sur un Amiga 1000 de base avec 256 ko de ram, je vois vraiment pas le problème avec un Amiga 500 qui à 512 ko de base :)
C'est sur que tu regarde une vidéo sur la même machine que sur laquelle tu travailles (tiens tu dois bien avancer dans ton boulot si tu passes ton temps à regarder des films au lieu d'être sur ton tableur !). Et, ne t'en déplaise, s'il y a une des deux machines qui explosent en jouant une vidéo c'est plutôt le ST !  
Tu sais vraiment plus quoi inventer comme mauvaise foi tellement ça te ferait du mal d'admettre que le mulitache avait sont intéret en 1985.

désolé, mais je maintiens qu'offrir un OS multitâche sur une machine qui ne servira qu'à 99% pour des jeux, et pour 1% restant cela ne sert qu'à démarrer une calculatrice, je vois pas l'intérêt d'avoir investit là dedans.  C'est une bonne chose, rien à redire, mais je trouve cela superflu sur un A500 de base, ce qui représentait la quasi totalité du parc amiga.  et il n'y a pas de quoi frimer, le QL le faisait bien avant l'amiga.  Atari aurait pu tout aussi bien le faire, rien ne les empêchait.

Ne fais pas une généralité de ton usage de l'Amiga. Il y beaucoup de professionnels qui ont utilisé l'Amiga pour autre chose que jouer (s'il ont même joué un jour avec !)
L'AmigaOS était prévu pour l'avenir et le multitache avait tout son sens dans ce cas, mais bon je te l'ait répété et répété en long et en large, et d'autres que moi l'ont fait... 
Et toujours le QL qui vient à la rescousse du ST, quand c'est pas le ZX81... je te l'ai déjà dit, l'Amiga il a besoin d'aucune autre machine pour se défendre, il se suffit à lui même ! 
Si rien n'empéchait Atari de faire un ST multitache, pourquoi ils l'ont pas fait... Je vais te le dire "histoire de gros sous et temps trop limité pour faire autre chose que récupérer un truc tout près et l'adapter à la va vite (CP/M et GEM)... alors que, comme je l'avais dis en arrivant, ils auraient pu aller chercher OS/9 qui tournait sur 68000 et était multitache préemptif, compatible unix, réseau, avait le ressource tracking et je crois même qu'il avait la protection mémoire et bien entendu une GUI. Bref, à tous les niveaux c'était mieux que l'AmigaOS... mais Atari n'y ont pas pensé (alors que Thomson pour son projet de machine 68000 lui l'a fait !). Je vais même être gentil, supposons qu'ils y ont pensé, c'était peut être trop cher pour eux, trop long à porter (pourtant il était déjà en 68K) ou même pas adaptable sur ST, qui sait ?

https://en.wikipedia.org/wiki/OS-9

Tu vas me dire "et Amiga ils aurait aussi pu faire ça... et bien oui ils auraient pu, mais Carl Sassenrath voulait créer son propre OS et l'AmigaOS n'est qu'une version bridée de ce qu'il prévoyait, comme je l'ai expliqué longuement (à cause de Jack Tramiel, soit dit en passant... merci encore à Atari de cette époque !). 
PS : Loin de moi de minimiser la compétence de Jack Tramiel pour ce qui était de savoir vendre... je dis juste qu'il a souvent utilisé des méthodes discutables (mais "business is war" c'était ses mots).

 non tu as des cartes acceleratrices pour Atari ST, il y avait juste un bootloader à ajouter.  et puis quand bien même, qui s'offrait des cartes accélératrices en 1985 ??  t'es toujours à comparer les choses qui n'ont rien à voir : on parle du ST en 1985, toi tu parles des années 90 ( WB 2.0, carte accélératrices, etc..)

 

Tant mieux qu'il y ait eut des cartes accélératrices pour le ST (ton bootloader, c'était pour quoi, à ton avis... rendre ton ST compatible avec, c'est bien ce que j'ai lu ici).
Qui s'offrait des cartes accélèratrices... tout d'abord les professionnels bien entendu et les passionnés avertis, les enthousiastes. 
Non je ne te parle pas de 1990... des cartes accélératrices il y en avait pour le 1000, puis le 500 et 2000. Dans Amiganews, il y avait souvent (peut être un numéro sur deux) des test de cartes accélératrices aussi bien interne pour le 500 (sur support 68000) que des carte zorro II pour le 2000... et même pour le 1000. 
Je t'ai longuement parlé du 1.x il me semble et n'est ce pas logique de parler ensuite des évolutions que furent le 2.x et 3.x ?
Quand on a eu le débat sur le TOS/AmigaOS je t'ai trouvé un lien sur les bug de l'AmigaOS (bug majeurs hein) et ensuite la même chose pour le TOS... et qu'est ce qu'on voyait, de mémoire (il suffit à celui qui le voudra de remonter dans les différents ST VS Amiga ici pour retrouver le lien), donc qu'est qu'on voyait, à partir du 2.x les bug majeurs ont disparus, alors que sur TOS... même sur Falcon le TOS avait un long listing de Bugs majeurs à corriger ! Mais tu vas dire que j'affabule de mémoire. Je n'ai pas l'envie d'aller faire à nouveau cette recherche, tu es trop usant !

pardon, c'est ATW800, pas ATX800

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

Donc je remet notre échange au complet, pour bien resituer le contexte :

La tirade juste avant, je l'ai rajouté à ma relecture. Mais, ce que je voulais dire, c'est qu'objectivement, si on veut résumer, la technologie de l'Atari ST était tournée vers le passé (et sera difficile à moderniser) et la technologie de l'Amiga tournée vers l'avenir (et évoluera dans la douceur, je parle de l'AmigaOS là, tout le monde sait que l'ECS et l'AGA n'ont été que le minimum syndicale de l'évolution par manque de moyens). Là aussi, ce sont des faits !

pourtant le TT,  Falcon sont là pour prouver que Atari à su faire évoluer son TOS/GEM sur une génération 32bit non ?
et tu oublies également toutes les machines pro, comme le ATX800

J'en conclu donc que tu considère que l'ATW800 est une évolution du TOS/GEM... et qu'est ce qu'on lit dans le wiki :

"in 1986 Tim King^[2] left his job at MetaComCo, along with a few other employees, to start Perihelion Software in England. There they started development of a new parallel-processing operating systemknown as "HeliOS". At about the same time a colleague, Jack Lang, started Perihelion (later Perihelion Hardware) to create a new transputer based workstation that would run HeliOS.
While at MetaComCo, much of the Perihelion Software team had worked with both Atari Corp. and Commodore International, producing ST BASIC for the former, and AmigaDOS for the latter. The principals still had contacts with both companies. Commodore had expressed some interest in their new system, and showed demos of it on an add-on card running inside an Amiga 2000. It appears they later lost interest in it. It was at this point that Atari Corp. met with Perihelion and work started on what would eventually become the ATW."

Donc l'OS, c'est dehors TOS et GEM, c'est HELIOS...

Mais, détail plus important encore... les créateur de ce système ou il sont allé d'abord... Chez Commodore et c'était une carte pour Amiga 2000... Mais quand Commodore a cessé de s'y intéresser, là ils sont allé chez Atari... Qu'est ce que je dis depuis le début que la direction de Commodore n'a cessé de prendre des décisions débiles quant à l'avenir de l'Amiga ? En voici encore une nouvelle preuve... Car figure toi que les cartes Transputer... et bien il y en avait un test dans un AmigaNews... et bien entendu un test sur Amiga (la carte en question) et tout le monde était enthousiaste...
En tout cas, les gars de metacomco... tu sais ceux qui ont écrit l'AmigaOS du coup (relis un peu l'histoire que j'ai raconté), quand ils sont arrivé chez Atari, il ont même pas cherché à utiliser le TOS/GEM... ils l'ont jeté (et on se demande pourquoi ?).

Et encore mieux !
https://en.wikipedia.org/wiki/HeliOS

Qu'est ce qu'on lit :
Helios extended TRIPOS' use of a light-weight message passing architecture to networked parallel machines.

Là je me marre ! Tu sais ce que c'est TRIPOS... c'est l'AmigaOS... Les transputers Atari (le top du top de la gamme) utilisaient une version améliorée de l'AmigaOS.... trop fort chez Atari... même pas honte !
Tu comprends maintenant pourquoi le prototype de la carte transputer il a d'abord été sur Amiga... l'intégration en multitache avec l'AmigaOS ça devait pas être un problème.... Faudrait que je retrouve un test des transputer sur Amiga tiens.

Je viens de trouver ça :
http://www.amigahistory.plus.com/prototypes/transputer.html

En tout cas, qu'est ce que je me marre, merci Rocky007 pour cette belle trouvaille !!! Mais, je suis d'accord avec toi, tu peux être très fier de cet ATW800, j'en suis fier moi aussi, puisque c'est basé sur l'Amiga...

C'est juste dommage que la direction de Commodore n'ait surement pas (une fois de plus) écouté ses ingénieurs...

[babsimov]

Ah j'allais oublié pourquoi je venais ici au départ.

Voici un lien avec pas mal d'info sur le 3000+ dont je parlais et le DSP 3210. Ainsi que l'AGA qui était pret en février 1991.

http://www.amigahistory.plus.com/prototypes/transputer.html

Pour ceux que ça intéresse

[dlfrsilver]

L'O/S 9 de microware a été utilisé sur X68000 pour programmer les jeux de machine d'arcade de Toaplan nommés Outzone (pour ne citer que lui).

J'ai trouvé l'info dans un PDF scanné de 686 pages de doc de design de chez TOAPLAN. L'X68000 fut leur seconde machine de développement. Avant lui, ils utilisaient l'ordinateur Sony BMC-777.

Juste en apparté :)

[stapha92]

rocky007

Un TT maintenant ? Quand bien même, tu pourrais pas.

oui un TT, et les débits que permettait le TT en SCSI ainsi que les HD SCSI permettent ce type d'animation

On parle du ST je te rapelle : regarde le titre du TOPIC. Le STE ne devrait même pas y etre (la grande majorité des ST vendus ne sont pas des STE) 

Rapellons un peu le début du débat. Tu t'es emporté avec ces vidéos. Tu étais en joie et tu n'as pas hésité à te moquer des amigaistes. 
Tu as même traité cryodav76 de rigolo alors que ses interrogations étaient fondés. Interrogations auxquelles tu as repondu des choses du genre :

rocky007
il ne faut rien modifier à la machine, faut juste un lecteur CF

rocky007

mon dieu, mais..pfff..c'est qd même pas compliqué à comprendre :
le STe sait afficher sans problème une image overscann 4096 couleurs... 
alors techniquement, c'est super simple : il lit l'image sur la CF et l'affiche, et ce 25 par seconde. 
il n'y a pas de buffering ( hormis peut-être un simple swap) , pas de décompression, rien, lit un bloc d'octets et l'affiche, pourquoi il lui faudrait 5 giga de RAM ? 300 ko maximum suffisent largement pour effectuer l'opération. donc le seul point crucial est le débit, il n'y a rien de magique la dedans. 
c'est de la simple logique que même un amigaiste pourrait comprendre ( quoique, apparemment non, puisque tu butes une vidéo d'un autre player qui n'a rien à voir )

rocky007
Il lit l'image et il l'affiche""... Tu es vraiment à coté de la plaque...

Pour ces vidéos, j'ai parlé de débits et des explications de l'auteur pour t'expliquer que c'était impossible sur un ST non modifié. ça n'a pas suffit à te convaincre et tu te réfugies maintenant derrière le TT pour éviter de reconnaitre que tu t'étais moqué de cryodav76 à tort.

Alors je vais t'expliquer pourquoi c'est impossible meme avec un débit SCSI de 2,5 Mo/s (donc le double de l'interface la plus rapide AUJOURD'HUI !) :

Une image de 416x228 en 16 couleurs prend 47424 octets. ça donne 47 924 x 50 = 2,3 Mo à "lire et à écrire" à chaque seconde. Un 68000 en est totalement incapable ! Donc si : c'est magique...
N'importe quel codeur ST ou mig sait cela... 

Et il faut rajouter les changements de palette : 

Spectrum 512 a montré que le maximum que le ST pouvait faire c'est 3 changements de palette / ligne. Si tu passes en overscan, c'est moins parce que ça bouffe aussi du cpu à chaque ligne. Donc 416 pixels/ligne avec 3 changements de couleurs, c'est impossible sur un ST, même avec une image fixe !
Rien que ça aurait du te mettre la puce à l'oreille... 

Ok, faisons comme si un ST pouvait afficher ce genre d'image... 

Le changement de palette occupe tout le cpu pendant toute la zone d'affichage qui représente 73% de la frame. Il reste donc 27% des ressources cpu à chaque frame pour "lire l'image et l'écrire". 
ça fait du 2,3 Mo/0,27 = 8,5 Mo/s. C'est plus du double de ce que peut faire le blitter du mig qui lui-même explose un 68000 !!!! 
En fait, c'est plus que la RAM du ST (ou la chip ram du mig) peut faire... C'est dire le ridicule de tes affirmations ! C'est encore plus "magique" !

Alors quand tu te moques des amigaistes comme cryodav76 (à qui tu proposais un mouchoir après avoir posté ces vidéos), c'est toi même que tu décridibilise... 

Au fait pour les 8,5 Mo/s : ce nombre s'applique aussi au TT. Donc tes affirmations sur les débits du TT en SCSI, tu peux les garder

Au final tu avais raison sur un point : cryodav76 avait besoin d'un mouchoir car il a du pleurer de rire...

rocky007
Je ne comprends pas ton explication.  si j'ai bien compris, fait bien scroller ton écran HAM d'un pixel ?  donc tu auras des problème de couleurs.

C'est pourtant pas compliqué. 

Je ne fais pas scroller l'écran, je le déplace ! Je détaille : 

Sur le mig, la taille et la position de l'écran peuvent être librement défini. Y a pas juste un mode fenêtre et un mode overscan. 
Donc quand je dis que je déplace l'écran, c'est vraiment ça. mais comme j'ai mis deux sprites (de couleur noire, qui font toute la hauteur de l'écran et qui sont au dessus du playfield) à gauche et à droite de l'écran, ça donne l'impression que ça scrolle. Il n'empeche que Denise va traiter les pixels cachés, donc il n'y aura aucun problème de couleur. 

Quand le déplacement atteint 16 pixels, on déplace le contenu en changeant le registre d'adresse. On aura donc largement eu le temps de préparer la copperlist suivante. 

C'est clair cette fois ?

rocky007tu te trompes, je n'ai jamais parlé de la plateforme, mais bien de l'effet "tube" en fond.  avec un motif adéquat, tu peux faire le même effet en precalc, et mirrorant et doublant certaines lignes pour le partie haute et basse, ce qui fait facilement 80 étapes d'animations avec 1 mo

Ah bon ? Alors c'est quoi çà :

rocky007
euh, encore une fois tu as l'air bien sûr de toi... moi tout ce que je vous, c'est un fond précalculé, ainsi qu'une plateforme précalculée également. Et rien du tout infaisable sur ST. Le shoot ? qu'y a-t-il de spéciale ? Le parallax précalculé comme on en faisait sur St depuis la Union Demo ?
Vraiment là, tu as pris le mauvais exemple.

Ou alors ça :

rocky007
pour moi, un effet qui est strictement identique comme rotation de plateformes identiques au degré prés , effet rotatif avec motif répétitif, tout ça, ça m'a l'air pas catholique. Pourquoi, si c'était du temps réel, ne pas exploiter ce dernier, en faisant des plateformes de différents tailles, qui bougent différemment ou en fonction du personnage

Bon pour celle là, je peux te trouver une excuse : les plates-formes bougent justement en fonction du personnage : son poids les fait pencher. Mais j'admet volontiers que ça ne se voit pas vraiment dans la vidéo.

Plus loin dans ce post tu expliques avoir planifié de ripper les données et adapter en GFA et prouver que c'était possible en pre-calc avec 640 Ko.

Bon allez, comme tu n'as jamais été capable de reconnaitre une erreur. On va oublier et se concentrer sur le tube. 

Tu arrives comment à 80 étapes d'animations ? Tu sors ce chiffre de quel chapeau ? Et combien pèse chacune d'entre elles ? 

Tactique classique : tu assènes des affirmations assorties de concepts que tu ne maitrises pas et de nombre sortis de ton chapeaux. ça fait illusion auprès de certains peut-être, mais surement pas auprès de ceux qui connaissent un tant soit peu les machines dont on parle.

Allons-y :

1) Le motif du tube se répète si on considère que les changement de couleurs peuvent être obtenu avec un changement de palette. Inutile donc d'avoir une image qui fait tout l'écran. 
L'image necessaire semble faire 50 lignes de haut. 
2) Chaque ligne de l'écran a une largeur différente. Mais comme la courbure est centrée, chaque largeur est utilisée 2 fois. On a donc 100 largeurs différentes. 

ça nous fait 50 lignes à stocker dans 100 largeurs. 5 000 lignes donc. 
Une ligne fait 160 Octets : 50x100x160 = 800 Ko. ça fait beaucoup pour du précalc. 
Mais ce n'est pas le seul problème : copier les différentes lignes en optimisant correctement le code 68000 va prendre quasiment tout le temps cpu disponible dans une frame. 
Donc en GFA, tu peux oublier cette méthode. 

Tu as codé sur ST et tu ne sais pas que la simple copie d'une image prend presqu'une frame entière en assembleur ? 

Pour le faire en GFA, il te faudrait stocker les images entières et modifier l'adresse écran à chaque fois. Mais comme il y a 50 lignes à traiter avant de boucler, il te faudrait 50 images pour que ça reste fluide meme quand la vitesse ralentie. 50 x 32 Ko = 1,6 Mo. Donc en GFA, tu peux oublier... 

Récapitulons :
Tu nous as expliqué qu'un ST pouvait afficher certaines vidéos sans modifs, alors qu'il ne peut même pas afficher ne serait-ce que l'une des frames de ces vidéos en tant qu'image fixe.
Tu as affirmer pourvoir reproduire 2 effets en précalc en gfa alors que tu ne pourrais en faire un seul à la fois (pour les plates-formes : ce serait pire...).

ça fait 2 fois que tu es à coté de la plaque quand tu parles du ST. En fait bien plus mais je me restreint au sujet abordés dans le débat qui nous oppose.

Je laisse aux lecteurs le soin de juger de ta crédibilité quand tu prétend expliquer des choses sur le mig quand on voit à quel point tu peux te planter quand tu parles de ta machine de prédilection...

Allez, je suis gentil et je vais t'expliquer comment cet effet peut être obtenu sur ST dans une démo. 

Tu commences par stocker tes lignes sur 3 plans : le précalc prendra 600 Ko. Le problème va être de l'appliquer sur 4 plans sans perdre de temps. 
Sur un mig, les bitplans étants séparés, il n'y aurait aucune difficulté : on ne traiterait que 3/4 des données. 

Sur ST on ne peut pas faire pareil mais, en etant malin, on peut s'arranger pour gagner du temps. 
J'explique : 

Sur ST la mémoire écran est disposé comme suit : 

11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44... 

Chaque chiffre représentent un octet et désigne le bitplan auquel il est destiné. On voit qu'ils sont regroupés 2 par 2 car le shifter lit les données 16 bits à la fois. 

On va stocker les lignes du tunnel en disposant les plans 1,2 et 4 de cette façon : 

11 22 11 22 11 22 11 22 11 22 11 22 11 22 44 44 44 44 44 44 44 

On chargera en 2 temps : 

movem.l (a6)+,d0/d2/d4/d6/a0/a2/a4 
movem.w (a6)+,d1/d3/d5/d7/a1/a3/a5 

Le premier movem travaille avec des longword, ce qui permet permet de charger le plan 1 dans la partie haute et le plan 2 dans la partie basse de chaque registre. 
le deuxième travaille avec des word. Seuls les partie basses de chaque registre seront chargées avec les données du plan 4. la partie haute, qui correspond au plan 3 restera à 0 (on aura pris soin d'effacer les registres avant le traitement bien sur)

Puis on ecrit tous les registres d'un coup : 

movem.l d0-d7/a0-a5,-(a7) 

On a fait notre conversion 3 plans->4 plans sans perdre de temps. On en a meme gagné grace au deuxieme movem qui traite des word et non des longword. 
(les 2 movem réunis prennent 108 cycles. un seul movem.l qui lit les 14 registres en aurait pris 124) 

Donc pour une ligne entière il faudra faire : 

movem.l (a6)+,d0/d2/d4/d6/a0/a2/a4 
movem.w (a6)+,d1/d3/d5/d7/a1/a3/a5 
movem.l d0-d7/a0-a5,-(a7) 
movem.l (a6)+,d0/d2/d4/d6/a0/a2/a4 
movem.w (a6)+,d1/d3/d5/d7/a1/a3/a5 
movem.l d0-d7/a0-a5,-(a7) 
movem.l (a6)+,d0/d2/d4/d6/a0/a2 
movem.w (a6)+,d1/d3/d5/d7/a1/a3 
movem.l d0-d7/a0-a3,-(a7) 

Pour traiter une ligne avec 3 séries, il faut que les deux premières utilisent 14 registres, il faudra donc se mettre en mode superviseur pour en avoir un de plus. 
On pourra aussi faire 4 série avec 10 registres et en garder 4 disponibles. ça pourrait être plus interessant au final, a cause de ce qu'il reste à faire. A tester. 

ça prendra 656 cycles par lignes. Il faudra ajouter le calcul de l'adresse de la ligne à copier (qui pourra être stockée dans une table de précalc) et le bouclage (et il ne reste plus de registres pour ça...). On va arrondir le tout à 700 cycles. Donc ça fait 700 * 200 lignes * 50 i/s = 7 000 000 cycles : il en reste 1 millions. On va donc pouvoir mettre quelques interruptions horizontales pour faire les changements de palettes. 

Par contre, après, il ne restera plus assez pour ajouter une plate-forme. même sans faire de rotation...

Donc OUI : on peut faire l'effet de tube sur un ST en utilisant 600 Ko de précalc et plus de 90% des ressources cpu avec un code correctement optimisé. 

Au final tu auras reproduis partiellement un effet du mig en bouffant tellement de RAM et de CPU que ça sera inutilisable. Exactement comme la phaleon demo et son screen qui reproduit très partiellement SOTB...

C'est pas la premiere fois qu'un AMIGA-FANBOY poste un code qui présente des optimisations spécifiques au ST. 
Par contre j'ai toujours pas vu le moindre code posté par l'un de nos experte STiste... 

Pour info, si on veut faire pareil sur le mig. C'est à dire en precalc, et sans utiliser le blitter, le copper ou les sprites il suffirait d'utiliser une interruption horizontale et de redefinir à chaque ligne l'adresse à afficher pour chacun des 3 plans. en comptant les changements de palette (qui seraient dans la même interruption). ça prendrait 10 % de cpu...

Et oui : meme sans utiliser ses atouts, le mig explose le ST juste grace à la souplesse de son chipset...

rocky007

Entrelacé, c'est le truc qui était une obligation en vidéo. Et ou as-tu vu qu'il faut un moniteur à plus 10 000 FF pour l'afficher ? Faudrait que tu te décides à ne parler que des domaines que tu maitrises, ça t'éviterait pas mal d'inepties : Le mode entrelacé a toujours fonctionné avec tous les moniteurs et TV.

oui avec des scintillements à flinguer les yeux en 10 minutes.

Tu as attendu l'époque des LCD pour regarder la TV ? Parce que je le répète à l'intention de tous ceux qui, comme toi, nous rabachent cet argument bidon : 

 - TOUT CE QUE TU POUVAIS VOIR À LA TÉLÉ ÉTAIT ENTRELACÉ à l'époque du mig (TV, K7 video, Laserdisc, DVD) !!! Autant qu'avec le mig, la seule différence est le niveau de contraste maximum : il est bien plus élevé avec un mig ou un ST en RGB qu'avec tous les autres systèmes (sauf le matériel pro). Il y avait des TV 100 Hz à l'époque des CRT justement pour réduire ce phénomène. ça marchait d'ailleurs très bien pour le mig... 
 - TOUS LES MODES D'AFFICHAGE DU MIG EXISTENT EN ENTRELACE ET EN PROGRESSIF !! 
 - MEME AUJOURD'HUI, TOUS LES PROGRAMMES TV SONT ENTRELACES !! (Quand une télé affiche 576i, le i signifie interlaced) Mais ça se voit moins (malgré l'utilisation du numérique qui permet d'atteindre des niveaux de contraste maximum) à cause du temps de latence des LCD 
 
Et on parlait de l'utilisation PRO. L'absence de mode entrelacé était rédhibitoire pour eux. Ils doivent être aveugles puisqu'ils nous balancent de l'entrelacé depuis les débuts de la TV...

rocky007

un simple exemple, déjà cité :


Agrandir cette image

Tu es sérieux là ? Tu me sors une carte à 16 000 Fr qui ne se branche que sur un mega ST 2/4 ? ça fait la config à 30 000 si on comptes le deuxième moniteur !!! 
Parce que ta super carte sort une image qui est à part de celle du ST... C'est ridicule... Et ce n'est utilisable qu'avec des programmes spécifiques... 
Ce n'est pas la faute de la carte (par ailleurs très bien faite), c'est la faute de la super architecture du mega ST qui en fait une machine pas vraiment évolutive 
Pour 30 000 Fr tu avais un A2000 avec une carte graphique 24 bits utilisables par pleins de logiciels (car connectée dans le port vidéo que LUI possédait...) et une carte accélératrive qui faisait que ton mega ST pouvait se rabiller. 
En fait, vu l'année ou est sortie ta carte chili, c'est un A3000 + carte graphique que tu pouvait avoir... 

C'est bien de nous parler du TT, puis du Mega ST, puis d'une carte à 16 000 Fr. Mais on est dans un topic Amiga VS ST... 

Tu pouvais faire du titrage avec un A500+genlock. En haute définition, overscan (704x576x16)... Un ST peut même pas en rever... 

Tant qu'on y est, on va prendre un 800XL avec VBXE et expliquer que c'est mieux qu'un C64... 

rocky007

Pourquoi sur parole ? 
J'ai livré des codes. Tu peux les prendre pour les faire vérifier sur des forums ST ou Amiga. Pas besoin de me faire confiance. 
Et ne t'inquiètes pas : si j'ai menti dans les codes, on tardera pas à voir quelqu'un venir rectifier. 

Si je résume : 
 - Tu ne sais pas comment fonctionne le blitter du mig. 
 - Tu ne comprends pas le code d'une C2P 
Et tu te permets d'affirmer que le blitter du mig ne peut pas en faire. Et tu insistes en plus ! Je t'avais donné des arguments faciles à vérifier 
Surtout pour quelqu'un qui codait sur ST... 

Y a pas quelque chose qui cloche ?

en quoi j'insiste ?  tu as donné ta démonstration de l'utilisation partielle du blitter dans une routine C2P, ok, je l'ai acceptée non ? 
je n'ai jamais prétendu connaître l'amiga et encore moins le fonctionnement de son blitter, ni même être un expert Atari.  Où vois-tu que j'ai prétendu être cela ?  et je te rassure, je sais comment fonctionne une routine C2P, peut-être pas de la façon la plus optimisée, mais dans son principe.

Tu insiste en disant "même si je dois te croire sur parole". Tu pourrais juste dire "ok tu as raison" mais non : ça a l'air d'être trop dur. 

Je me permet de te raffaichir la mémoire : 

rocky007
Je suis pas spécialiste,  mais il me semble que blitter de l'amiga est assez rigide.  Il très pratique pour déplacer des gros blocs de mémoire, mais certainement pas pour aider à faire du polyfill sur des scènes complexes et encore moins pour du C2P.

tu commences pas "Je suis pas spécialiste,  mais il me semble" puis tu dis que le blitter du mig est rigide. Ah bon ? Tu sors ça d'ou ? Du même chapeau que toutes tes autres élucubrations ?
Ensuite tu continues avec du "certainement pas" et du "encore moins" : tu ne joues pas les expert qui sait de quoi il parle ? Alors que tu fais 3 fausses affirmations dans la meme phrase.

Quand je t'ai répondu tu as pris un ton moqueur en me mettant au défi de te montrer une routine c2p plus rapide que sur ST grace au blitter.

Pas de bol : ça ne m'a posé aucun problème. Je t'ai posté deux routines C2P optimisées : une pour ST et une pour le mig.

Parce qu'il n'y a pas qu'avec le mig que tu parles sans savoir : c'est tout aussi vrai avec le ST...

ps :

C'est parce que tu disais devoir me croire sur parole que j'en ai conclu que tu ne savais pas comment fonctionne une C2P et j'ai estimé que ce n'était pas logique d'affirmer des choses dessus. Ce n'était pas une critique de tes connaissances en coding. Si tu l'as pris comme ça, je te présente mes plus plates excuses. 

Le niveau en tant que codeur de quelqu'un n'est jamais criticable. Pour moi, le type qui est content de parvenir à afficher les nombres premiers en GFA mérite autant de respect que celui qui découvre l'interpolation à base de addx. 
Je serai tout autant ravi d'aider le premier que le second. Aucune différence pour moi. tout comme cela ne ferait aucune différence que ce soit un codeur sur ST ou sur mig. 

Dans le cas présent, je critique ton attitude (que tu n'es pas le seul a adopter, loin de là) surtout pas tes connaissances.

rocky007

Donc très proche, c'est pas gagné. Peut-être avec des techniques modernes et 3 Mo minimum. Mais, dans le même cas, le mig aurait pu avoir un Ambermoon bien plus fluide.

C'est pourquoi je trouve que les "aurait pu" n'apportent rien au débat et font tourner en rond. 

exactement comme ton scrolling HAM... qd qq'un dit qu'un ST aurait été incapable de faire ambermoon dans son état actuel, et tu le confirme, cela est faux : le ST aurait pu approcher fortement et cela n'aurait pas été un jeu irréalisable comme certains le prétendent ici... ( contrairement à d'autres jeux comme Lion Heart )

Non, mon scrolling HAM ne rentrait pas dans le cadre du "aurait pu", il entre dans celui du "c'est possible". je te rappelle qu'à la base de cette discussion tu disais (et tu n'étais pas le premier, loin de là...) que le HAM ne pouvait afficher que des images statiques et qu'il ne restait que 1% de CPU. J'ai déjà prouvé que c'était faux. 
Quand au scrolling, c'est juste de la faisabilité dont il était question : je n'ai même pas dit que cela pourrait être utilisable dans un jeu. 

Oui je confirme ce que j'ai dit. Je ne reviens pas dessus. Je peux même ajouter qu'avec un peu moins de couleurs et de fluidité (il aurait fallu se limiter à 1 Mo et on ne disposait pas des techniques actuelles), il n'aurait pas du tout perdu de son interet. 
Pour moi Thalion a fait une erreur, ils auraient du le sortir en utilisant le moteur d'Amberstar : ça n'aurait pas couté grand chose en dev (ils auraient même pu faire évoluer un peu le moteur) et ça aurait donné un super jeu au ST. Il n'aurait donc pas été necessaire d'en vendre des tonnes pour être bénéficiaire... 

rocky007

Donc ça nous fait (44 + 20 + 32 + 36) * 5 000 = 660 000 cycles/secondes. Le ST disposant de 850 000 cycles de plus que le mig, on voit que l'avantage est déjà en grande partie consommé alors qu'on a pas joué de sample encore ! La routine qui doit s'en occuper va encore prendre quelques dizaines de cycles... 5 000 fois par secondes.

c'est bizarre, lorsque je fais le calcul :

64 ( interruption ) * 5000 = 320000 cycles ce qui te laisse 530000 cycles libre pour une simple routine monovoie de playback, ce qui est parfaitement réalisable.  de plus, c'est pas le seul élément à prendre en compte : personne ici ne peut dire comment est le code amiga et s'il a été correctement porté et optimisé. 

C'est bizarre mais lorsque tu fais le calcul :
 - Tu te limites à 5000 Hz mais penses-tu que cela soit suffisant pour obtenir un son acceptable avec une variation de tonalité (y en a dans vroom) ? Surement pas... 
 - Tu parles de routine monovoie mais tu as du remarquer qu'il y avait plusieurs voies dans Vroom non ?
 - Tu choisis d'écarter la sauvegarde/restauration des registres. Tu te rends compte que cela limitera l'efficacité des movem qui seront utilisé pour effacer l'écran par exemple ?

Le pire : même en faisant ça, tu as tort... 

Je ne me suis jamais interessé à l'exploitation du YM, il faudrait donc que je me documente avant de pouvoir écrire une "simple routine monovoie de playback" corectement optimisée. 
Aussi, je vais me contenter d'en reprendre une. Elle est posté par l'auteur de Wolfenstein 3D. Je pense que l'on peut estimer que c'est quelqu'un qui sait de quoi il parle... 

La voici : 

    movem.l d0-d1/a6,-(sp)         
    move.l  usp,a6                     (4) 
    moveq.l #0,d0                      (4) 
    move.b  (a6)+,d0                   (8) 
    lsl.w   #3,d0                      (12) 
    subq.l  #1,position                (8)
    bne.s   .play                      (10) 
    lea.l   sample,a6
    move.l  sample_length(pc),position         
.play
    move.l  a6,usp                    (4)
    lea.l   $ffff8800.w,a6            (8)
    movem.l .da_table(pc,d0.l),d0/d1  (34) 
    movep.l d0,(a6)                   (24) 
    move.l  d1,(a6)                   (8) 
    movem.l (sp)+,d0-d1/a6         
    rte         


J'ai mis le nombre de cycles entre parenthèses. J'ai ignoré les sauvegarde et les restaurations des registres utilisés, et le repositionnement au début du sample. Le total est de 124 cycles. 
En fait 126 puisque le bne.s prendra 2 cycles de plus sur un vrai ST. 
        
Donc au final, on obtient 126 * 5000 = 630 000 cycles + 320 000 cycles pour l'interruption 

980 000 cycles pour jouer un sample : 
        - à 5 Khz 
        - sur une seule voie 
        - sans variation de tonalité 
        - sans tenir compte du bouclage 
        - En réservant 4 registres
On est pourtant au-delà des 850 000 cycles qu'il restait au ST... 

Même en optimisant à mort, quitte à stocker les samples sur 8 octets (ce qui n'est pas réaliste), une routine pour reproduire ce qu'il faut dans vroom consommerait bien plus... 

Tu as raison par contre : personne ne peut dire comment est le code amiga. Mais ce dont on est certain, c'est que la partie son a du être réécrite corretement puisqu'il n'y a pas le choix. C'est un classique dans les St-ports. Et jouer des samples sur 4 voix à 20 Khz avec une variation de tonalité sans bloquer de registres est gratuit sur le mig. 
Quand à l'affichage, comme tout se fait au cpu et que le mig s'est restreint à du 320x200x16, ça doit prendre le même temps.

rocky007

Mais c'est faux de dire que toutes les applis pro allaient plus vite sur ST

sur ST, une application tournaient pour elle seule, sur amiga, tu as tout les threads qui tournent en fonds.  donc pas convaincu

Plutot que de repartir sur un long discours qui ne pourrait pas te convaincre, je t'invite à essayer des applis qui existent sur les 2 machines. PageStream ou Pro24 existent sur les 2 plates-formes et sont du domaine de prédilection du ST. Tu verras que la gestion des threads est extrement performante. 
Ou essaie un jeu OS-Friendly dans lequel tu peux couper le multitache (Breathless, un doom-like par exemple doit le permettre) : tu ne verras aucune différence dans le frame-rate. 

Et je ne vois pas ou tu as vu qu'l y avait un tas de threads qui tournent en fond.

Quand bien même : si on avait besoin d'un cpu rapide pour une utilisation sérieuse, on pouvait mettre une carte accélératrice, nous.

?? l'atari aussi... il y a avait une large gamme de cartes accélératrices

Sur ST ? Pas du tout !

Tout ce qu'il y avait c'est des cartes qui se mettaient à l'intérieur du ST. Sur que les pros étaient tous des geek bricoleurs qui se foutaient de la garantie...
Et tout ce qu'il y avait, c'était des 68000 boostés. La plupart du temps à 16 Mhz. Et celles qui étaient le plus efficage avait une mémoire cache. Ce qui permettait un gain de 50-60 % à cette fréquence. Celles qui n'en n'avaient pas atteignaient 10-20 % d'amélioration en réel.
Parce que tu peux mettre le micro-processeur que tu veux dans un ST, il sera toujours ralenti par la RAM..
Meme Atari, dans le MegaSTE a du mettre une mémoire cache pur réussir à accélérer sa machine et suivre un époustouflant 68000 à 16 Mhz... Ouaouhhh !

Un Amiga 500 pouvait être accéléré avec un 68000/010/020/030/040/060 sans aucun problème (pour les derniers, pas dès le début puisqu'ils n'existaient pas). Y avait rien à démonter et le gain de vitesse était totalement disponible.

il y a une différence entre qualité sonore, et qualité des phonèmes et le programme qui les gère.

Montre nous ça parce que je n'ai pas vu ces phonèmes géniaux. J'ai du mal chercher...

Et tu n'as pas répondu : à quoi ça sert dans un logiciel ? Sur mig tu pouvais en faire dans un programme en GFA ou dans un script...

Donc, si le port série ne peut pas faire du midi avec la même qualité, je dois donc en déduire que Steinberg et C-Lab sont des arnaqueurs puisque ces 2 entreprises (les plus renommées dans le midi) proposaient des boitiers midi qui, je le répète, avaient plus de prises et de canaux que ce qu'il y a d'origine. Et ces boitiers se branchaient sur le port série. Je parle de boitiers midi pour le ST, pas pour le mig ! 
Ces boitiers sont la preuve que le port série du ST peut faire du midi plus efficacement que les ports midi du ST... Alors pourquoi pas le mig ? Ben justement : lui aussi avait des boitiers avec plus de prises que ce qu'il y a d'origine sur un ST.

oui et est-ce aussi bon qu'une seule prise midi ?  je possède encore le modèle steinberg et je me souviens avoir eu pas mal de problème de synchro, problème inexistant qd je passais en direct sur la prise midi.

Oui tout à fait. C'est aussi bon. ça marche EXACTEMENT de la même façon avec une bande passante plus élevée.
Ah bon ? Donc Steinberg, le nom plus respectée dans l'informatique musicale à l'époque vendait des boitiers qui marchaient mal (et c'était des boitiers pro pour certains en rack 19". Pas des mini boitiers à 100 Francs...). J'ai du mal à croire ça...
Tu es au courant que sur mig aussi on trouve des artistes qui ont fait du midi et sorti des albums ?
C'est bizarre parce que aucun mig n'a de prise midi en série : ils sont forcément passés par un boitier...
Comment ont-ils fait ?
Maintenant je ne dis pas que tu mens : peut-être que ton boitier avait un problème. Ou que tu utilises un pass-thru pour imprimante qui en pose.

[Invité]

- L'archimedes : Tiens, mais j'en avais pas parlé de celui là ? A l'époque c'est cantoné au marché britannique, c'est plus cher qu'un 500 (je te rappel la gamme de prix) et... c'est multitache coopératif ! Je sais même pas s'il y a le plug and play (peut être). Et le sujet sur l'archimèdes ici a montré que c'était pas au niveau d'un Amiga 500 ! Mais le premier modèle c'est 1987 (même année que le 500)
https://en.wikipedia.org/wiki/Acorn_Archimedes

Le problème de l'archi est un peu le même que le ST, à part qu'il a un CPU de la mort, donc requiert bcp de RAM (et rapide surtout 120/140 ns) ce qui fait exploser son prix,donc pas de copros .
Les pros archis diront toujours que l'intérêt de copros quand tu as l'ARM est nul ,ce qui est débile mais bon, car je connais pas de bécanes performantes en tout avec juste le CPU .

[dlfrsilver]

rocky007

Un TT maintenant ? Quand bien même, tu pourrais pas.

oui un TT, et les débits que permettait le TT en SCSI ainsi que les HD SCSI permettent ce type d'animation

On parle du ST je te rapelle : regarde le titre du TOPIC. Le STE ne devrait même pas y etre (la grande majorité des ST vendus ne sont pas des STE) 

Rapellons un peu le début du débat. Tu t'es emporté avec ces vidéos. Tu étais en joie et tu n'as pas hésité à te moquer des amigaistes. 
Tu as même traité cryodav76 de rigolo alors que ses interrogations étaient fondés. Interrogations auxquelles tu as repondu des choses du genre :

rocky007
il ne faut rien modifier à la machine, faut juste un lecteur CF

rocky007

mon dieu, mais..pfff..c'est qd même pas compliqué à comprendre :
le STe sait afficher sans problème une image overscann 4096 couleurs... 
alors techniquement, c'est super simple : il lit l'image sur la CF et l'affiche, et ce 25 par seconde. 
il n'y a pas de buffering ( hormis peut-être un simple swap) , pas de décompression, rien, lit un bloc d'octets et l'affiche, pourquoi il lui faudrait 5 giga de RAM ? 300 ko maximum suffisent largement pour effectuer l'opération. donc le seul point crucial est le débit, il n'y a rien de magique la dedans. 
c'est de la simple logique que même un amigaiste pourrait comprendre ( quoique, apparemment non, puisque tu butes une vidéo d'un autre player qui n'a rien à voir )

rocky007
Il lit l'image et il l'affiche""... Tu es vraiment à coté de la plaque...

Pour ces vidéos, j'ai parlé de débits et des explications de l'auteur pour t'expliquer que c'était impossible sur un ST non modifié. ça n'a pas suffit à te convaincre et tu te réfugies maintenant derrière le TT pour éviter de reconnaitre que tu t'étais moqué de cryodav76 à tort.

Alors je vais t'expliquer pourquoi c'est impossible meme avec un débit SCSI de 2,5 Mo/s (donc le double de l'interface la plus rapide AUJOURD'HUI !) :

Une image de 416x228 en 16 couleurs prend 47424 octets. ça donne 47 924 x 50 = 2,3 Mo à "lire et à écrire" à chaque seconde. Un 68000 en est totalement incapable ! Donc si : c'est magique...
N'importe quel codeur ST ou mig sait cela... 

Et il faut rajouter les changements de palette : 

Spectrum 512 a montré que le maximum que le ST pouvait faire c'est 3 changements de palette / ligne. Si tu passes en overscan, c'est moins parce que ça bouffe aussi du cpu à chaque ligne. Donc 416 pixels/ligne avec 3 changements de couleurs, c'est impossible sur un ST, même avec une image fixe !
Rien que ça aurait du te mettre la puce à l'oreille... 

Ok, faisons comme si un ST pouvait afficher ce genre d'image... 

Le changement de palette occupe tout le cpu pendant toute la zone d'affichage qui représente 73% de la frame. Il reste donc 27% des ressources cpu à chaque frame pour "lire l'image et l'écrire". 
ça fait du 2,3 Mo/0,27 = 8,5 Mo/s. C'est plus du double de ce que peut faire le blitter du mig qui lui-même explose un 68000 !!!! 
En fait, c'est plus que la RAM du ST (ou la chip ram du mig) peut faire... C'est dire le ridicule de tes affirmations ! C'est encore plus "magique" !

Alors quand tu te moques des amigaistes comme cryodav76 (à qui tu proposais un mouchoir après avoir posté ces vidéos), c'est toi même que tu décridibilise... 

Au fait pour les 8,5 Mo/s : ce nombre s'applique aussi au TT. Donc tes affirmations sur les débits du TT en SCSI, tu peux les garder

Au final tu avais raison sur un point : cryodav76 avait besoin d'un mouchoir car il a du pleurer de rire...

rocky007
Je ne comprends pas ton explication.  si j'ai bien compris, fait bien scroller ton écran HAM d'un pixel ?  donc tu auras des problème de couleurs.

C'est pourtant pas compliqué. 

Je ne fais pas scroller l'écran, je le déplace ! Je détaille : 

Sur le mig, la taille et la position de l'écran peuvent être librement défini. Y a pas juste un mode fenêtre et un mode overscan. 
Donc quand je dis que je déplace l'écran, c'est vraiment ça. mais comme j'ai mis deux sprites (de couleur noire, qui font toute la hauteur de l'écran et qui sont au dessus du playfield) à gauche et à droite de l'écran, ça donne l'impression que ça scrolle. Il n'empeche que Denise va traiter les pixels cachés, donc il n'y aura aucun problème de couleur. 

Quand le déplacement atteint 16 pixels, on déplace le contenu en changeant le registre d'adresse. On aura donc largement eu le temps de préparer la copperlist suivante. 

C'est clair cette fois ?

rocky007tu te trompes, je n'ai jamais parlé de la plateforme, mais bien de l'effet "tube" en fond.  avec un motif adéquat, tu peux faire le même effet en precalc, et mirrorant et doublant certaines lignes pour le partie haute et basse, ce qui fait facilement 80 étapes d'animations avec 1 mo

Ah bon ? Alors c'est quoi çà :

rocky007
euh, encore une fois tu as l'air bien sûr de toi... moi tout ce que je vous, c'est un fond précalculé, ainsi qu'une plateforme précalculée également. Et rien du tout infaisable sur ST. Le shoot ? qu'y a-t-il de spéciale ? Le parallax précalculé comme on en faisait sur St depuis la Union Demo ?
Vraiment là, tu as pris le mauvais exemple.

Ou alors ça :

rocky007
pour moi, un effet qui est strictement identique comme rotation de plateformes identiques au degré prés , effet rotatif avec motif répétitif, tout ça, ça m'a l'air pas catholique. Pourquoi, si c'était du temps réel, ne pas exploiter ce dernier, en faisant des plateformes de différents tailles, qui bougent différemment ou en fonction du personnage

Bon pour celle là, je peux te trouver une excuse : les plates-formes bougent justement en fonction du personnage : son poids les fait pencher. Mais j'admet volontiers que ça ne se voit pas vraiment dans la vidéo.

Plus loin dans ce post tu expliques avoir planifié de ripper les données et adapter en GFA et prouver que c'était possible en pre-calc avec 640 Ko.

Bon allez, comme tu n'as jamais été capable de reconnaitre une erreur. On va oublier et se concentrer sur le tube. 

Tu arrives comment à 80 étapes d'animations ? Tu sors ce chiffre de quel chapeau ? Et combien pèse chacune d'entre elles ? 

Tactique classique : tu assènes des affirmations assorties de concepts que tu ne maitrises pas et de nombre sortis de ton chapeaux. ça fait illusion auprès de certains peut-être, mais surement pas auprès de ceux qui connaissent un tant soit peu les machines dont on parle.

Allons-y :

1) Le motif du tube se répète si on considère que les changement de couleurs peuvent être obtenu avec un changement de palette. Inutile donc d'avoir une image qui fait tout l'écran. 
L'image necessaire semble faire 50 lignes de haut. 
2) Chaque ligne de l'écran a une largeur différente. Mais comme la courbure est centrée, chaque largeur est utilisée 2 fois. On a donc 100 largeurs différentes. 

ça nous fait 50 lignes à stocker dans 100 largeurs. 5 000 lignes donc. 
Une ligne fait 160 Octets : 50x100x160 = 800 Ko. ça fait beaucoup pour du précalc. 
Mais ce n'est pas le seul problème : copier les différentes lignes en optimisant correctement le code 68000 va prendre quasiment tout le temps cpu disponible dans une frame. 
Donc en GFA, tu peux oublier cette méthode. 

Tu as codé sur ST et tu ne sais pas que la simple copie d'une image prend presqu'une frame entière en assembleur ? 

Pour le faire en GFA, il te faudrait stocker les images entières et modifier l'adresse écran à chaque fois. Mais comme il y a 50 lignes à traiter avant de boucler, il te faudrait 50 images pour que ça reste fluide meme quand la vitesse ralentie. 50 x 32 Ko = 1,6 Mo. Donc en GFA, tu peux oublier... 

Récapitulons :
Tu nous as expliqué qu'un ST pouvait afficher certaines vidéos sans modifs, alors qu'il ne peut même pas afficher ne serait-ce que l'une des frames de ces vidéos en tant qu'image fixe.
Tu as affirmer pourvoir reproduire 2 effets en précalc en gfa alors que tu ne pourrais en faire un seul à la fois (pour les plates-formes : ce serait pire...).

ça fait 2 fois que tu es à coté de la plaque quand tu parles du ST. En fait bien plus mais je me restreint au sujet abordés dans le débat qui nous oppose.

Je laisse aux lecteurs le soin de juger de ta crédibilité quand tu prétend expliquer des choses sur le mig quand on voit à quel point tu peux te planter quand tu parles de ta machine de prédilection...

Allez, je suis gentil et je vais t'expliquer comment cet effet peut être obtenu sur ST dans une démo. 

Tu commences par stocker tes lignes sur 3 plans : le précalc prendra 600 Ko. Le problème va être de l'appliquer sur 4 plans sans perdre de temps. 
Sur un mig, les bitplans étants séparés, il n'y aurait aucune difficulté : on ne traiterait que 3/4 des données. 

Sur ST on ne peut pas faire pareil mais, en etant malin, on peut s'arranger pour gagner du temps. 
J'explique : 

Sur ST la mémoire écran est disposé comme suit : 

11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44... 

Chaque chiffre représentent un octet et désigne le bitplan auquel il est destiné. On voit qu'ils sont regroupés 2 par 2 car le shifter lit les données 16 bits à la fois. 

On va stocker les lignes du tunnel en disposant les plans 1,2 et 4 de cette façon : 

11 22 11 22 11 22 11 22 11 22 11 22 11 22 44 44 44 44 44 44 44 

On chargera en 2 temps : 

movem.l (a6)+,d0/d2/d4/d6/a0/a2/a4 
movem.w (a6)+,d1/d3/d5/d7/a1/a3/a5 

Le premier movem travaille avec des longword, ce qui permet permet de charger le plan 1 dans la partie haute et le plan 2 dans la partie basse de chaque registre. 
le deuxième travaille avec des word. Seuls les partie basses de chaque registre seront chargées avec les données du plan 4. la partie haute, qui correspond au plan 3 restera à 0 (on aura pris soin d'effacer les registres avant le traitement bien sur)

Puis on ecrit tous les registres d'un coup : 

movem.l d0-d7/a0-a5,-(a7) 

On a fait notre conversion 3 plans->4 plans sans perdre de temps. On en a meme gagné grace au deuxieme movem qui traite des word et non des longword. 
(les 2 movem réunis prennent 108 cycles. un seul movem.l qui lit les 14 registres en aurait pris 124) 

Donc pour une ligne entière il faudra faire : 

movem.l (a6)+,d0/d2/d4/d6/a0/a2/a4 
movem.w (a6)+,d1/d3/d5/d7/a1/a3/a5 
movem.l d0-d7/a0-a5,-(a7) 
movem.l (a6)+,d0/d2/d4/d6/a0/a2/a4 
movem.w (a6)+,d1/d3/d5/d7/a1/a3/a5 
movem.l d0-d7/a0-a5,-(a7) 
movem.l (a6)+,d0/d2/d4/d6/a0/a2 
movem.w (a6)+,d1/d3/d5/d7/a1/a3 
movem.l d0-d7/a0-a3,-(a7) 

Pour traiter une ligne avec 3 séries, il faut que les deux premières utilisent 14 registres, il faudra donc se mettre en mode superviseur pour en avoir un de plus. 
On pourra aussi faire 4 série avec 10 registres et en garder 4 disponibles. ça pourrait être plus interessant au final, a cause de ce qu'il reste à faire. A tester. 

ça prendra 656 cycles par lignes. Il faudra ajouter le calcul de l'adresse de la ligne à copier (qui pourra être stockée dans une table de précalc) et le bouclage (et il ne reste plus de registres pour ça...). On va arrondir le tout à 700 cycles. Donc ça fait 700 * 200 lignes * 50 i/s = 7 000 000 cycles : il en reste 1 millions. On va donc pouvoir mettre quelques interruptions horizontales pour faire les changements de palettes. 

Par contre, après, il ne restera plus assez pour ajouter une plate-forme. même sans faire de rotation...

Donc OUI : on peut faire l'effet de tube sur un ST en utilisant 600 Ko de précalc et plus de 90% des ressources cpu avec un code correctement optimisé. 

Au final tu auras reproduis partiellement un effet du mig en bouffant tellement de RAM et de CPU que ça sera inutilisable. Exactement comme la phaleon demo et son screen qui reproduit très partiellement SOTB...

C'est pas la premiere fois qu'un AMIGA-FANBOY poste un code qui présente des optimisations spécifiques au ST. 
Par contre j'ai toujours pas vu le moindre code posté par l'un de nos experte STiste... 

Pour info, si on veut faire pareil sur le mig. C'est à dire en precalc, et sans utiliser le blitter, le copper ou les sprites il suffirait d'utiliser une interruption horizontale et de redefinir à chaque ligne l'adresse à afficher pour chacun des 3 plans. en comptant les changements de palette (qui seraient dans la même interruption). ça prendrait 10 % de cpu...

Et oui : meme sans utiliser ses atouts, le mig explose le ST juste grace à la souplesse de son chipset...

rocky007

Entrelacé, c'est le truc qui était une obligation en vidéo. Et ou as-tu vu qu'il faut un moniteur à plus 10 000 FF pour l'afficher ? Faudrait que tu te décides à ne parler que des domaines que tu maitrises, ça t'éviterait pas mal d'inepties : Le mode entrelacé a toujours fonctionné avec tous les moniteurs et TV.

oui avec des scintillements à flinguer les yeux en 10 minutes.

Tu as attendu l'époque des LCD pour regarder la TV ? Parce que je le répète à l'intention de tous ceux qui, comme toi, nous rabachent cet argument bidon : 

 - TOUT CE QUE TU POUVAIS VOIR À LA TÉLÉ ÉTAIT ENTRELACÉ à l'époque du mig (TV, K7 video, Laserdisc, DVD) !!! Autant qu'avec le mig, la seule différence est le niveau de contraste maximum : il est bien plus élevé avec un mig ou un ST en RGB qu'avec tous les autres systèmes (sauf le matériel pro). Il y avait des TV 100 Hz à l'époque des CRT justement pour réduire ce phénomène. ça marchait d'ailleurs très bien pour le mig... 
 - TOUS LES MODES D'AFFICHAGE DU MIG EXISTENT EN ENTRELACE ET EN PROGRESSIF !! 
 - MEME AUJOURD'HUI, TOUS LES PROGRAMMES TV SONT ENTRELACES !! (Quand une télé affiche 576i, le i signifie interlaced) Mais ça se voit moins (malgré l'utilisation du numérique qui permet d'atteindre des niveaux de contraste maximum) à cause du temps de latence des LCD 
 
Et on parlait de l'utilisation PRO. L'absence de mode entrelacé était rédhibitoire pour eux. Ils doivent être aveugles puisqu'ils nous balancent de l'entrelacé depuis les débuts de la TV...

rocky007

un simple exemple, déjà cité :


Agrandir cette image

Tu es sérieux là ? Tu me sors une carte à 16 000 Fr qui ne se branche que sur un mega ST 2/4 ? ça fait la config à 30 000 si on comptes le deuxième moniteur !!! 
Parce que ta super carte sort une image qui est à part de celle du ST... C'est ridicule... Et ce n'est utilisable qu'avec des programmes spécifiques... 
Ce n'est pas la faute de la carte (par ailleurs très bien faite), c'est la faute de la super architecture du mega ST qui en fait une machine pas vraiment évolutive 
Pour 30 000 Fr tu avais un A2000 avec une carte graphique 24 bits utilisables par pleins de logiciels (car connectée dans le port vidéo que LUI possédait...) et une carte accélératrive qui faisait que ton mega ST pouvait se rabiller. 
En fait, vu l'année ou est sortie ta carte chili, c'est un A3000 + carte graphique que tu pouvait avoir... 

C'est bien de nous parler du TT, puis du Mega ST, puis d'une carte à 16 000 Fr. Mais on est dans un topic Amiga VS ST... 

Tu pouvais faire du titrage avec un A500+genlock. En haute définition, overscan (704x576x16)... Un ST peut même pas en rever... 

Tant qu'on y est, on va prendre un 800XL avec VBXE et expliquer que c'est mieux qu'un C64... 

rocky007

Pourquoi sur parole ? 
J'ai livré des codes. Tu peux les prendre pour les faire vérifier sur des forums ST ou Amiga. Pas besoin de me faire confiance. 
Et ne t'inquiètes pas : si j'ai menti dans les codes, on tardera pas à voir quelqu'un venir rectifier. 

Si je résume : 
 - Tu ne sais pas comment fonctionne le blitter du mig. 
 - Tu ne comprends pas le code d'une C2P 
Et tu te permets d'affirmer que le blitter du mig ne peut pas en faire. Et tu insistes en plus ! Je t'avais donné des arguments faciles à vérifier 
Surtout pour quelqu'un qui codait sur ST... 

Y a pas quelque chose qui cloche ?

en quoi j'insiste ?  tu as donné ta démonstration de l'utilisation partielle du blitter dans une routine C2P, ok, je l'ai acceptée non ? 
je n'ai jamais prétendu connaître l'amiga et encore moins le fonctionnement de son blitter, ni même être un expert Atari.  Où vois-tu que j'ai prétendu être cela ?  et je te rassure, je sais comment fonctionne une routine C2P, peut-être pas de la façon la plus optimisée, mais dans son principe.

Tu insiste en disant "même si je dois te croire sur parole". Tu pourrais juste dire "ok tu as raison" mais non : ça a l'air d'être trop dur. 

Je me permet de te raffaichir la mémoire : 

rocky007
Je suis pas spécialiste,  mais il me semble que blitter de l'amiga est assez rigide.  Il très pratique pour déplacer des gros blocs de mémoire, mais certainement pas pour aider à faire du polyfill sur des scènes complexes et encore moins pour du C2P.

tu commences pas "Je suis pas spécialiste,  mais il me semble" puis tu dis que le blitter du mig est rigide. Ah bon ? Tu sors ça d'ou ? Du même chapeau que toutes tes autres élucubrations ?
Ensuite tu continues avec du "certainement pas" et du "encore moins" : tu ne joues pas les expert qui sait de quoi il parle ? Alors que tu fais 3 fausses affirmations dans la meme phrase.

Quand je t'ai répondu tu as pris un ton moqueur en me mettant au défi de te montrer une routine c2p plus rapide que sur ST grace au blitter.

Pas de bol : ça ne m'a posé aucun problème. Je t'ai posté deux routines C2P optimisées : une pour ST et une pour le mig.

Parce qu'il n'y a pas qu'avec le mig que tu parles sans savoir : c'est tout aussi vrai avec le ST...

ps :

C'est parce que tu disais devoir me croire sur parole que j'en ai conclu que tu ne savais pas comment fonctionne une C2P et j'ai estimé que ce n'était pas logique d'affirmer des choses dessus. Ce n'était pas une critique de tes connaissances en coding. Si tu l'as pris comme ça, je te présente mes plus plates excuses. 

Le niveau en tant que codeur de quelqu'un n'est jamais criticable. Pour moi, le type qui est content de parvenir à afficher les nombres premiers en GFA mérite autant de respect que celui qui découvre l'interpolation à base de addx. 
Je serai tout autant ravi d'aider le premier que le second. Aucune différence pour moi. tout comme cela ne ferait aucune différence que ce soit un codeur sur ST ou sur mig. 

Dans le cas présent, je critique ton attitude (que tu n'es pas le seul a adopter, loin de là) surtout pas tes connaissances.

rocky007

Donc très proche, c'est pas gagné. Peut-être avec des techniques modernes et 3 Mo minimum. Mais, dans le même cas, le mig aurait pu avoir un Ambermoon bien plus fluide.

C'est pourquoi je trouve que les "aurait pu" n'apportent rien au débat et font tourner en rond. 

exactement comme ton scrolling HAM... qd qq'un dit qu'un ST aurait été incapable de faire ambermoon dans son état actuel, et tu le confirme, cela est faux : le ST aurait pu approcher fortement et cela n'aurait pas été un jeu irréalisable comme certains le prétendent ici... ( contrairement à d'autres jeux comme Lion Heart )

Non, mon scrolling HAM ne rentrait pas dans le cadre du "aurait pu", il entre dans celui du "c'est possible". je te rappelle qu'à la base de cette discussion tu disais (et tu n'étais pas le premier, loin de là...) que le HAM ne pouvait afficher que des images statiques et qu'il ne restait que 1% de CPU. J'ai déjà prouvé que c'était faux. 
Quand au scrolling, c'est juste de la faisabilité dont il était question : je n'ai même pas dit que cela pourrait être utilisable dans un jeu. 

Oui je confirme ce que j'ai dit. Je ne reviens pas dessus. Je peux même ajouter qu'avec un peu moins de couleurs et de fluidité (il aurait fallu se limiter à 1 Mo et on ne disposait pas des techniques actuelles), il n'aurait pas du tout perdu de son interet. 
Pour moi Thalion a fait une erreur, ils auraient du le sortir en utilisant le moteur d'Amberstar : ça n'aurait pas couté grand chose en dev (ils auraient même pu faire évoluer un peu le moteur) et ça aurait donné un super jeu au ST. Il n'aurait donc pas été necessaire d'en vendre des tonnes pour être bénéficiaire... 

rocky007

Donc ça nous fait (44 + 20 + 32 + 36) * 5 000 = 660 000 cycles/secondes. Le ST disposant de 850 000 cycles de plus que le mig, on voit que l'avantage est déjà en grande partie consommé alors qu'on a pas joué de sample encore ! La routine qui doit s'en occuper va encore prendre quelques dizaines de cycles... 5 000 fois par secondes.

c'est bizarre, lorsque je fais le calcul :

64 ( interruption ) * 5000 = 320000 cycles ce qui te laisse 530000 cycles libre pour une simple routine monovoie de playback, ce qui est parfaitement réalisable.  de plus, c'est pas le seul élément à prendre en compte : personne ici ne peut dire comment est le code amiga et s'il a été correctement porté et optimisé. 

C'est bizarre mais lorsque tu fais le calcul :
 - Tu te limites à 5000 Hz mais penses-tu que cela soit suffisant pour obtenir un son acceptable avec une variation de tonalité (y en a dans vroom) ? Surement pas... 
 - Tu parles de routine monovoie mais tu as du remarquer qu'il y avait plusieurs voies dans Vroom non ?
 - Tu choisis d'écarter la sauvegarde/restauration des registres. Tu te rends compte que cela limitera l'efficacité des movem qui seront utilisé pour effacer l'écran par exemple ?

Le pire : même en faisant ça, tu as tort... 

Je ne me suis jamais interessé à l'exploitation du YM, il faudrait donc que je me documente avant de pouvoir écrire une "simple routine monovoie de playback" corectement optimisée. 
Aussi, je vais me contenter d'en reprendre une. Elle est posté par l'auteur de Wolfenstein 3D. Je pense que l'on peut estimer que c'est quelqu'un qui sait de quoi il parle... 

La voici : 

    movem.l d0-d1/a6,-(sp)         
    move.l  usp,a6                     (4) 
    moveq.l #0,d0                      (4) 
    move.b  (a6)+,d0                   (8) 
    lsl.w   #3,d0                      (12) 
    subq.l  #1,position                (8)
    bne.s   .play                      (10) 
    lea.l   sample,a6
    move.l  sample_length(pc),position         
.play
    move.l  a6,usp                    (4)
    lea.l   $ffff8800.w,a6            (8)
    movem.l .da_table(pc,d0.l),d0/d1  (34) 
    movep.l d0,(a6)                   (24) 
    move.l  d1,(a6)                   (8) 
    movem.l (sp)+,d0-d1/a6         
    rte         


J'ai mis le nombre de cycles entre parenthèses. J'ai ignoré les sauvegarde et les restaurations des registres utilisés, et le repositionnement au début du sample. Le total est de 124 cycles. 
En fait 126 puisque le bne.s prendra 2 cycles de plus sur un vrai ST. 
        
Donc au final, on obtient 126 * 5000 = 630 000 cycles + 320 000 cycles pour l'interruption 

980 000 cycles pour jouer un sample : 
        - à 5 Khz 
        - sur une seule voie 
        - sans variation de tonalité 
        - sans tenir compte du bouclage 
        - En réservant 4 registres
On est pourtant au-delà des 850 000 cycles qu'il restait au ST... 

Même en optimisant à mort, quitte à stocker les samples sur 8 octets (ce qui n'est pas réaliste), une routine pour reproduire ce qu'il faut dans vroom consommerait bien plus... 

Tu as raison par contre : personne ne peut dire comment est le code amiga. Mais ce dont on est certain, c'est que la partie son a du être réécrite corretement puisqu'il n'y a pas le choix. C'est un classique dans les St-ports. Et jouer des samples sur 4 voix à 20 Khz avec une variation de tonalité sans bloquer de registres est gratuit sur le mig. 
Quand à l'affichage, comme tout se fait au cpu et que le mig s'est restreint à du 320x200x16, ça doit prendre le même temps.

rocky007

Mais c'est faux de dire que toutes les applis pro allaient plus vite sur ST

sur ST, une application tournaient pour elle seule, sur amiga, tu as tout les threads qui tournent en fonds.  donc pas convaincu

Plutot que de repartir sur un long discours qui ne pourrait pas te convaincre, je t'invite à essayer des applis qui existent sur les 2 machines. PageStream ou Pro24 existent sur les 2 plates-formes et sont du domaine de prédilection du ST. Tu verras que la gestion des threads est extrement performante. 
Ou essaie un jeu OS-Friendly dans lequel tu peux couper le multitache (Breathless, un doom-like par exemple doit le permettre) : tu ne verras aucune différence dans le frame-rate. 

Et je ne vois pas ou tu as vu qu'l y avait un tas de threads qui tournent en fond.

Quand bien même : si on avait besoin d'un cpu rapide pour une utilisation sérieuse, on pouvait mettre une carte accélératrice, nous.

?? l'atari aussi... il y a avait une large gamme de cartes accélératrices

Sur ST ? Pas du tout !

Tout ce qu'il y avait c'est des cartes qui se mettaient à l'intérieur du ST. Sur que les pros étaient tous des geek bricoleurs qui se foutaient de la garantie...
Et tout ce qu'il y avait, c'était des 68000 boostés. La plupart du temps à 16 Mhz. Et celles qui étaient le plus efficage avait une mémoire cache. Ce qui permettait un gain de 50-60 % à cette fréquence. Celles qui n'en n'avaient pas atteignaient 10-20 % d'amélioration en réel.
Parce que tu peux mettre le micro-processeur que tu veux dans un ST, il sera toujours ralenti par la RAM..
Meme Atari, dans le MegaSTE a du mettre une mémoire cache pur réussir à accélérer sa machine et suivre un époustouflant 68000 à 16 Mhz... Ouaouhhh !

Un Amiga 500 pouvait être accéléré avec un 68000/010/020/030/040/060 sans aucun problème (pour les derniers, pas dès le début puisqu'ils n'existaient pas). Y avait rien à démonter et le gain de vitesse était totalement disponible.

il y a une différence entre qualité sonore, et qualité des phonèmes et le programme qui les gère.

Montre nous ça parce que je n'ai pas vu ces phonèmes géniaux. J'ai du mal chercher...

Et tu n'as pas répondu : à quoi ça sert dans un logiciel ? Sur mig tu pouvais en faire dans un programme en GFA ou dans un script...

Donc, si le port série ne peut pas faire du midi avec la même qualité, je dois donc en déduire que Steinberg et C-Lab sont des arnaqueurs puisque ces 2 entreprises (les plus renommées dans le midi) proposaient des boitiers midi qui, je le répète, avaient plus de prises et de canaux que ce qu'il y a d'origine. Et ces boitiers se branchaient sur le port série. Je parle de boitiers midi pour le ST, pas pour le mig ! 
Ces boitiers sont la preuve que le port série du ST peut faire du midi plus efficacement que les ports midi du ST... Alors pourquoi pas le mig ? Ben justement : lui aussi avait des boitiers avec plus de prises que ce qu'il y a d'origine sur un ST.

oui et est-ce aussi bon qu'une seule prise midi ?  je possède encore le modèle steinberg et je me souviens avoir eu pas mal de problème de synchro, problème inexistant qd je passais en direct sur la prise midi.

Oui tout à fait. C'est aussi bon. ça marche EXACTEMENT de la même façon avec une bande passante plus élevée.
Ah bon ? Donc Steinberg, le nom plus respectée dans l'informatique musicale à l'époque vendait des boitiers qui marchaient mal (et c'était des boitiers pro pour certains en rack 19". Pas des mini boitiers à 100 Francs...). J'ai du mal à croire ça...
Tu es au courant que sur mig aussi on trouve des artistes qui ont fait du midi et sorti des albums ?
C'est bizarre parce que aucun mig n'a de prise midi en série : ils sont forcément passés par un boitier...
Comment ont-ils fait ?
Maintenant je ne dis pas que tu mens : peut-être que ton boitier avait un problème. Ou que tu utilises un pass-thru pour imprimante qui en pose.

Merci encore pour ces explications, j'en connais un qui s'est mangé son "coup de bon fonctionnement" du lundi matin

quand je lis ce que Stapha écrit, j'en viens à me dire mais pourquoi les Ataristes viennent nous faire la guerre alors que qu'elle fut pire que perdue, et que plus il en écrit, et plus les choses deviennent claires. Je regrette de ne pas avoir d'aptitude en programmation, ça m'aurait permis de pouvoir expliquer certaines choses voir d'en affirmer d'autres de manière empirique.

C'est surement ça mon problème. Je comprends et je constate, le souci dans certains cas c'est de prouver les choses.

L'exemple de Vroom est parlant, de même que mon histoire de temps pour formater une disquette. Les Ataristes rabachent que le ST est plus rapide alors que c'est simplement pas vrai du tout. Ils ont répandu des mythe(o)s au sujet de l'amiga qui ne tiennent pas la route : Le WB de l'amiga plante souvent (connerie), les accès disques sont plus rapide (connerie), le CPU est plus rapide sur ST (vrai et une connerie en même temps).

Le CPU du ST est plus rapide oui, car je pense que les ingés d'atari ont du se rendre compte que la machine de base n'étant pas un cheval de course, ils ont préféré mettre un 68000 avec un quartz doté d'une cadence de 8 mhz pour booster le tout.

L'amiga lui a été volontairement "ralenti" pour qu'il puisse se synchroniser avec le chipset.

Donc en bref, c'est une comparaison qui semble avoir un sens, mais qui en fait n'en a pas dans la réalité.

Stapha a même prouvé et expliqué dans ses arguments que l'architecture même de l'amiga, sans parler de CPU est beaucoup plus rapide que celle du ST. C'est pour ça qu'on dit que l'Amiga est doté d'une architecture matériellement accélérée, la ou le ST a une architecture totalement standard avec un 68k couplé à un framebuffer.

Les explications de Stapha confirment également ce que je disais plus haut : à chose égale, le CPU du ST est totalement étranglé, la ou le CPU de l'amiga garde un maximum de marge. Et cela malgré le fait que le CPU du ST tourne plus vite que celui de l'Amiga !

[Invité]

si l'AMIGA est une console à disquettes, 
Le ST est un boulier avec une sortie péritel.


les ataristes trouveront toujours les plus viles excuses pour prouver la superiorité de leur machine.

ON ESSAYE DE NOUS FAIRE CROIRE QUE MON PETIT PONEY EST PLUS FORT QUE GODZILLA dans ce topic. même sans aucune connaissance approfondie de l'affaire (d'autres en parleront mieux que moi, mais les faits sont la), il suffit d'ouvrir les yeux 10 secondes. A ce niveau là c'est plus de la mauvaise foi, c'est du déni de réalité.


figure 1: le 1er prototype d'Atari ST

[Urbinou]

Y en a qui craquent ici !!

[dlfrsilver]

si l'AMIGA est une console à disquettes, 
Le ST est un boulier avec une sortie péritel.


les ataristes trouveront toujours les plus viles excuses pour prouver la superiorité de leur machine.

ON ESSAYE DE NOUS FAIRE CROIRE QUE MON PETIT PONEY EST PLUS FORT QUE GODZILLA dans ce topic. même sans aucune connaissance approfondie de l'affaire (d'autres en parleront mieux que moi, mais les faits sont la), il suffit d'ouvrir les yeux 10 secondes. A ce niveau là c'est plus de la mauvaise foi, c'est du déni de réalité.


figure 1: le 1er prototype d'Atari ST

Oui c'est exactement ça, du déni de réalité. on peut avoir de bons souvenirs de jeux sur l'Atari, mais rester les pieds sur terre au sujet de la machine.

[oliver27]

si l'AMIGA est une console à disquettes, 
Le ST est un boulier avec une sortie péritel.

Pas très sympa la comparaison.... enfin, si j'étais un beau boulier en bois, bien fini et tout et tout, j'aimerais pas être comparé à cette quincaillerie qu'est le ST 

[Invité]

et encore le boulier affiche davantage de couleurs simultanément.

[dlfrsilver]

Han on a Brice de Nice à bord loool :) ahahaha

Excellente celle-là !

[stapha92]

La question a déjà été posée mais je ne pense pas avoir eu une réponse claire.... Comment peut-on faire sur Amiga pour avoir un directory d'une D7 et ce de la manière la plus simple.... soit sans HD ? Et quid si pas de WB et de programme spécifique comme Opus ?

Ben tu fais fais un double-clic sur la disquette. On t'a déjà répondu... 
Ah je vois : tu veux dire dans le cas ou tu veux voir les fichiers cachés (sans icone) avec une des premières version du WB ? 
Pourquoi faire ça ? L'utilisateur lambda n'en a pas besoin ! Pour lui c'était plus pratique de ne voir que les fichiers qui lui étaient utiles... 

L'utilisateur expérimenté pouvait utiliser le CLI. Pas besoin du WB ou de DOpus 

Autre question, pour faire démarrer en boot un programme, il faut une startup sequence ....faut-il obligatoirement passer par un éditeur de texte ?

pour le faire démarrer en boot, la seul chose à mettre dans la startup sequence est le nom du programme. 
Tu peux passer par un éditeur de texte quelconque ou taper ed dans le cli. 
Tu peux aussi créer ta startup sequence sans éditeur avec une seule ligne sous le cli : il suffit d'utiliser la redirection. 
Oui je sais, c'est encore un concept inconnu sur ST. J'expliquerai une autre fois... 

S'il s'agit d'un programme que tu souhaites lancer depuis le worbench, il te suffit de le mettre dans le dossier WBStartup 

Autre question, si je mets un programme sur D7 qui a besoin de la librairie du WB, je dois jouer à l'alchimiste pour créer une D7 avec tous ce qui faut dedans ?

La librairie du WB n'est utile qu'avec le WB. Tu penses qu'elle sert à l'affichage des fenêtres ? Pas du tout, ça c'est pris en charge par Intuition. 
C'est une librairie qui se trouve en rom et qui offre bien plus de fonctions que le GEM... 
La librairie workbench sert surtout aux AppIcon, AppMenu, AppWindow. Ils s'agit de systèmes qui pemettent au workbench d'envoyer un message à une application en fonction d'actions de l'utilisateur. On est encore dans des concepts inconnu sur ST... Alors tu peux te moquer avec ton arrière pensée mais le fait est que même en faisant l'alchimiste, tu ne pourras jamais faire avec le GEM ce que te permet la librairie du WB... 

Au fait : la librairie du workbench consiste en un seul petit fichier. Pour l'alchimiste, tu repasseras... 

Autre question... sur le ST les programmes se reconnaissent facilement car il y a une icone standard. Sur l'Amiga ce n'est pas le cas sauf si on en créer une spécifique ?

Euh... Jamais personne n'a eu du mal a reconnaitre un programme sur le mig. Pour la plupart des logiciel, quand tu cliquais sur la disquette, tu voyais 2 icones : un pour lancer le logiciel et un pour l'installer. Tu n'étais pas obligé de naviguer avec tous les fichiers présents sur la disquette pour les retrouver. 
Sinon, le WB peut afficher une icone spécifique aux exécutables qui n'en ont pas. Tu peux donc retrouver le système du ST. Et j'ai jamais vu un programme livré comme ça... 

Tu as voulu prouver quoi là ? Que le St était plus convivial ? Désolé mais ce n'est pas le cas pour moi. Le fait d'avoir des icones personnalisables (et de n'importe quel taille), des noms de fichiers en clair, et des fichiers que l'on peut cacher est plus convivial pour moi. D'ailleurs, les OS d'aujourd'hui ne fonctionnent-ils pas comme ça ? 

Ou alors j'ai mal compris. Tu voulais dire que le ST est un meilleur gestionnaire de fichier que le mig grace à son GEM en rom ? 
Tu as raison : j'admet que quelqu'un qui voulait un ordinateur et s'en servir juste pour regarder le contenu de disquettes ou de répertoires devait prendre un ST. 

Maintenant à mon tour de poser des questions. 

Tu as posé une question sur le démarrage au boot d'un programme. Ton arrière pensée était "avec un ST tu le fais en mettant ton programme dans le dossier "AUTO". 
J'ai 2 questions sur les autoboot : 
Avec un ST tu faisais comment pour faire démarrer au boot un logiciel qui tournait en haute résolution (sans patch ni outil supplémentaire)? 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST tu faisais comment pour faire démarrer au boot un logiciel GEM (c'est à dire qui utilisait la souris, les fenêtre, les icones, du classique quoi ) ? 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST, tu faisais comment pour renommer un répertoire ? 
Ah tu pouvais pas ? Obligé de passer par un programme... Ah mais non ! je suis bête ! C'est pas seulement le GEM qui n'offrait pas cette fonction, c'est carrément le TOS ! Donc tu ne pouvais même pas le faire par programmation ! LOL ! 
Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST, tu faisais comment pour avoir plus de 40 répertoires ? 
Ah tu pouvais pas... Bon c'est pas si grave : plus de 40 répertoires sur une disquette, c'était pas courant... 
Ah mais ça concerne aussi les HD ? Aie ! 40 repertoires max (en comptant tous les sous-répertoire et toutes les partitions) sur un HD, là par contre ça craint... 
Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST tu faisais comment pour que la position, la taille, les paramètres d'une fenêtre (d'une disquette ou d'un répertoire) soient mémorisés ? 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST tu faisais comment pour ouvrir plus de 4 fenêtres ? 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST tu faisais comment pour déplacer (et non copier) un fichier plus grand que la taille disponible sur ta disquette (donc pas moyen de copier et supprimer la source) ? 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST tu faisais comment pour faire une sauvegarde incrémentale avec ton HD vu que l'attribut d'archivage était buggé et ne se posait pas ? 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST tu faisais comment pour copier tous les fichiers qui correspondaient à des critère particuliers et qui se trouvaient dans différents endroits ? 
Par exemple, copier sur une disquette 30 fichier IFF disséminés dans 5 répertoires et mélangés avec d'autres fichiers. 
Et tout ça en une seule manip, pas 30... 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 


Je pourrai continuer longtemps comme ça : au jeu des manques ou de la convivialité, le ST n'est absolument pas devant le mig, contrairement à ce qu'affirment beaucoup de Stistes ici. 
Et vu que tu prétends que le WB n'était pas terminé, je peux en conclure la même chose. Certaines des choses que je viens de citer ont été réglés après l'arrivée du 2.0. Et y en a qui posaient des problèmes autres que la convivialité...

Note que je me suis restreint au domaine que tu abordais : la manipulation de fichiers...

Ah non, tu as parlé des librairies aussi. Alors j'explique l'interet :

Dans l'amigaos tu as accès à tout un tas de librairies qui sont en rom ou pas.
Par exemple, il y a une librairie mathématique qui te donne accès à des fonctions trigonometriques. 
Si tu utilises un logiciel pour de rendering 3D, le programme utilisera abondamment cette libriarie (s'il a été correctement écrit). Maintenant imaginons que tu achete une carte avec un 68020+copro arithmétique, tu aimerais bien que ce programme (et d'autres) utilisent le copro de ta carte, non ?
Et bien il suffira de dire à l'OS que tu souhaite utiliser une autre librairie et de lui fournir. Et là c'est très compliqué : il faut copier un fichier dans le répertoire libs. Et même plusieurs puisqu'il y a surement plusieurs librairie que tu pourrais rendre plus performantes. Bien sur, les cartes accélératrices étaient livrés avec des logiciels d'install qui faisaient tout ça. ça permettait, si tu faisais ça sur ta disquette WB ou ton HD de rendre immédiatement pleins de programmes beaucoup plus rapides que s'ils s'étaient contenté de ne profiter que de l'accélération apportée par le 68020 (on est dans des facteurs de vitesse qui se mesurent en dizaines/centaines).
Ce système est tellement souple qu'il permettrait à des logiciels écrits pour le 68000 de profiter de la puissance du powerpc quand les cartes qui en étaient équipées sortiront...

Et pourtant, l'utilisateur lambda ne savait pas qu'il y avait un répertoire libs...
ça vaut pas le coup, en échange de ce que ça apporte, de jouer les "alchimistes" ?

Moi, la convivialité, je dirai que c'est très subjectif. Et je noterai que tous les OS moderne utilisent une ergonomie plus proche de celle du mig que du ST : noms long, icones personnalisés, sauvegarde des paramètres d'affichage des dossiers, jauge indiquant l'espace restant (ah tiens ! encore un truc bien pratique qui n'existait pas sur ST), etc... 

J'explique pour ceux qui ont du mal à comprendre et que ça interesse sincèrement. 

L'OS du mig est en ROM (tu as raison Ryosaeba : ça pose les même problèmes de mise à jour qu'avec le TOS du ST). 
Mais l'OS ne contient pas le bureau. C'est la différence avec celui du ST. Mais tout le reste y est (y compris l'interface graphique). 
Et l'amigaos propose une API bien plus complète que celle du TOS/GEM. Elle est non seulement plus optimisé (les fonctions de l'OS n'ont pas besoin de manipuler la pile autant que sur ST...) mais elle prend plus de place. 
Un ST c'est 192 Ko pour l'OS et le bureau. 
Un mig c'est 256 Ko pour l'OS seul. 

Un bureau, pour être le plus convivial, doit être personnalisable. Et je ne parle pas que de cosmétique, je parle de personnalisation qui permet d'améliorer la productivité. 
Un exemple simple : sur le WB, tu peux personnaliser la surface d'affichage pour qu'elle occupe le maximum visible sur un moniteur. Faire ce réglage à chaque allumage de l'ordinateur n'aurait pas de sens. Il faut donc que ce soit mémorisé, sinon personne ne l'utiliserait. Attention ! je ne parle pas d'étirer la zone comme on pouvait le faire sur certains moniteurs (ceux qui le faisaient étaient rares). je parle d'augementer le nombre de pixels : plus on en a mieux c'est. Grace à ça, en moyenne résolution, le mig avait un bureau de 680-700 pixels par 260/280 lignes. (et une application qui ouvrait ses propres écrans pouvait reprendre les réglages du WB...) Le ST restait cantonné à du 640 x 200. Et tout ça dans une fenêtre ridiculement petite. 
Grace à ce système, sur un Amiga, pour avoir un bureau de 14 pouces, il fallait un écran de 15 pouces. Sur un ST, il fallait un écran de 18/19 pouces ! Et tout ça avec moins de pixels, moins de couleurs, et un pointeur qui ne pouvait pas avoir sa palette spécifique. Ce qui n'est pas très convivial quand on dispose de 4 couleurs en tout... 
Donc quand tu as un bureau hautement configurable et personnalisable, il est logique de le mettre sur disquette puisqu'il faudra de toute façon charger pleins de choses avant de l'ouvrir. 


Maintenant tous les outils que tu avais sur le WB tu pouvais les avoir aussi sur le GEM ? Tu es loin du compte...
Une chose est sure : tu ne connais pas le mig... Ou plutot les outils que tu peux avoir sur le WB. Rien que celui dont je parle juste au-dessus qui te permet d'optimiser la suface d'affichage : ça n'existe pas sur le ST et c'est impossible à faire... 

A propose d'outil, il y en avait un sur ST qui permettait de lancer un programme en moyenne résolution au boot (bon c'est plus un correctif qu'un outil...). 
Il se mettait lui aussi dans le dossier AUTO. 
Voici un extrait de sa doc : 

Although the ST's internal clock keeps time with an accuracy of two seconds, the time-stamping of files is accurate only to within one minute. To be absolutely certain that the AUTO folder will work correctly, you should allow at least two minutes to elapse between the time that you place each file in AUTO. This ensures that the ST will have no difficulty deciding the correct order in which to run the programs. 

Il faut attendre au moins 2 minutes entre chaque copie de fichier ! ça c'est convivial ! LOL !

L'ordre des programmes dépend de la date des fichiers ! Super si tu veux changer cet ordre...
Je préfère 1000 fois une statupsequence.

Et je pourrais te citer des tas de choses que tu faisais facilement avec une startupsequence (et un cli intégré en ROM...) et qui auraient demandé de solides connaissances en programmation pour les faire avec un ST...

[dlfrsilver]

Stapha92 vs les fessés du ST : 2 à 0 !

[ryosaeba]

Stapha92 vs les fessés du ST : 2 à 0 !

non Ryosaeba 3 - Amigaiste :0 

Sans Stapha vous n'auriez même pas su répondre...... Et je peux continuer comme cela aussi bien en mettant en valeur l'Amiga ou le St ou l'inverse.

[dlfrsilver]

Stapha92 vs les fessés du ST : 2 à 0 !

non Ryosaeba 3 - Amigaiste :0 

Sans Stapha vous n'auriez même pas su répondre...... Et je peux continuer comme cela aussi bien en mettant en valeur l'Amiga ou le St ou l'inverse.

Il a démonté tout ce que tu as dis clairement. Même moi tu as biaisé à mort sur mes propres affirmations.

Et pire, j'ai démontré que rien que côté lecteur de disquette l'amiga défonce encore le ST

Donc oui Ryosaeba 0 - dlfrsilver 1 et Ryosaeba 0 - Stapha92 2

MDRRR !!!!

[Invité]

si l'AMIGA est une console à disquettes, 
Le ST est un boulier avec une sortie péritel.

[ryosaeba]

Stapha92 vs les fessés du ST : 2 à 0 !

non Ryosaeba 3 - Amigaiste :0 

Sans Stapha vous n'auriez même pas su répondre...... Et je peux continuer comme cela aussi bien en mettant en valeur l'Amiga ou le St ou l'inverse.

Il a démonté tout ce que tu as dis clairement. Même moi tu as biaisé à mort sur mes propres affirmations.

Et pire, j'ai démontré que rien que côté lecteur de disquette l'amiga défonce encore le ST

Donc oui Ryosaeba 0 - dlfrsilver 1 et Ryosaeba 0 - Stapha92 2

MDRRR !!!!

Tu n'as rien compris........ RyoSaeba 5 - dlfrsilver :0