Re: GUERRE ST-AMIGA, FIGHT !!!

[Zarnal]

Sauf que dans mon cas l'image est déja tramée avant d'être importée. Je dois repartir bosser, je vérifie et je détaille ce soir.

[stapha92]

le sujet exact de départ était l'utilité de travailler en 16 couleurs un document qui sera imprimée en trame noir et blanc
en effet zarnal nous a montré qu'une fois tramée, l'image s'affiche bel et bien en noir et blanc 

L'utilité ? Je te la redonne une énième fois : Quand tu imprimes une image, même si elle est imprimée en N&B avec des trames, tu auras l'impression qu'il y aura plusieurs nuances de gris grace à la taille des points imprimés. Donc un rendu écran avec 16 gris sera plus proche de l'impression que ta bouillie de pixel composée de trames qui sont sans rapport avec le tramage de l'imprimante. à moins d'etre avec un zoom surpuissant et à condition que ce zoom permette d'avoir une correspondance 1 point=1 pixel pile poil...

Cela veut dire que le débit maximum ASCI de l'atari peut être atteint et n'est pas limité par la lenteur du HD.  et que donc, des solutions techniques existaient pour dépasser les débits des HD Atari, rien de ridicule dans tout cela

Ok alors montre moi la solution d'époque qui permette d'atteindre 2,5 Mo/s. Même aujourd'hui un ultrasatan ne les atteint pas, pas du tout. C'est ce qu'explique l'auteur des vidéos...
Mais toi tu as prétendu avoir fait tourner ces vidéos sur ton ST....

tiens, le schéma d'un DAC qui se connecte sur port // ... R, R2, etc.. tu sais ce que cela veut dire ?

Oui je sais ce que ça veut dire. Et toi sais-tu ce que veut dire DAC ? ça veut dire Digital Analogique Converter. C'est ce que fait Paula. ton schema représente l'inverse : analogique vers digital. En fait il s'agit d'un simple aiguillage qui transforme un signal unique en 8 signaux ayant chacun un niveau de plus en plus petit. La transformation de ces signaux est assurée par l'interface parrallèle. C'est le gros du boulot pour la conversion A-> D 
Donc ça n'a rien à voir. En plus ton schéma donnerait vraiment un son de merde : si tu penses obtenir un vrai sample 8 bits avec ça...
Ce qui est drole c'est que tu avais posté 2 autres schémas avant de modifier ton post. Et pour le coup il s'aggissait de vrai DACs. Pourquoi les avoir enlevé ? Parce que tu as réalisé qu'il y avait des portes logiques et un transistor ? Ou pour avoir réalisé que ce DAC produirait un son pourri ? 
Mets à 1 le lsb, mesure le niveau du signal analogique et mets à 1 le bit suivant : tu devrais obtenir un niveau 3 fois plus elevé : à la lecture de tes 2 schémas, il est clair que ça n'aurait pas du tout été le cas.

Cela dit libre à toi de croire que Paula = quelques résistances. C'est vexant parce que on voit à quel point quelques résistances permettent au mig d'exploser le ST.
Elles sonnent bien ces résistances :


A écouter sur une chaine hifi : si tu reproduis ça avec quelques résistances, je t'invite dans le resto de ton choix ! (sinon je t'inviterai également avec plaisir, mais je ne te laisserai pas choisir le resto !   )

ok je te cite :  Es-tu au courant que sur une imprimante couleur il n'y a pas de niveaux de cyan, jaune ou magenta ? 

je trafique toujours ?

T'étais en train d'expliquer qu'avec les imprimantes moderne il n'y a pas de tramage. Qu'il y ait 1 niveau de cyan ou 2 ou 3 (encore une fois pas sur toutes les imprimantes modernes) ne change rien : un tramage est toujours obligatoire. Tu chipotes pour t'écarter du sujet initial ?

à quoi a ressemble l'impression d'une photo sur une imprimante qui imprime en N&B et fait donc du tramage ? A ta bouille en 2 couleurs ? Ou à l'image du mig en 16 gris ? Réponse : celle du mig bien sur...

ben non elle ressemblera exactement à ce qui est présenté sous Calamus
une imprimante imprime en trame, 1 pixel n'est pas imprimé tel quel.  donc la représentation de final copy sera fausse

Exactement ??!!  
Si c'est le cas, change d'imprimante...

tu vois, malgré mes efforts à t'expliquer simplement, tu n'arrives toujours pas à suivre.  je t'ai expliqué, et c'est le point de départ de ce débat, c'est que pour travailler le N&b avec précision, on désactive l'antialising, pour ne travailler qu'avec du noir et du blanc.  je n'ai jamais prétendu que les pros travaillent en monochrome.  pour la plupart des cas, ils travaillent en couleurs, mais certains travaux n&b plus précis nécessitent de passer en n&b.  mais 2017 est différent de 1985 : la puissance des machines, des moniteurs, des imprimantes.  si aujourd'hui un soft PAO peux extrapoler des pixels n&b en nuances de gris lorsque tu dezooms, il y a la puissance pour, cela n'était pas le cas dans les années 80

Tout  fait d'accord (Hourra ! resto pour feter ça !) : il n'y avait pas la puissance pour interpoler des trames en niveaux de gris. C'est tout à fait vrai (sauf à accepter que ça rame ou que ça bouffe plein de ram).
Mais je parlais du cas inverse : l'impression d'une image ou d'une photo qui, elles, ne sont certainement pas stockée sous forme de trame.

voilà pourquoi il n'a pas été implanté dans le GFA, trop de travail

Parce que Intuition était assez rapide pour répondre au cahier des charge des créateurs du GFA. Contrairement au GEM (me parles pas de ton exemple : je vais expliquer pourquoi c'est bidon plus bas)

ben tu le sais très bien, pourquoi fais-tu semblant de ne pas savoir à longueur de post , juste pour ne pas admettre l'évidence : si un PRINT en GFA ne se fait pas en fenêtre, c'est avant tout parce que le GEM n'est pas forcément chargé lorsque ce programme sera exécute.

Chargé ? De quoi parles tu ? Il n'est pas en ROM le GEM ? Tu peux appeler les fonctions GEM sans problème sous GFA. Mais c'est un casse tete...

tout en conservant tes 4 voies ?  ah ben non, il t'en reste plus que 2..très pratique pour faire de la synthèse sonore.
donc oui, si tu veux faire du soundchip, équivalent à ce qui se fait sur ST, C64 etc.., il faut le faire par CPU

Oui 2. Il a combien de voies le ST ? Une voix de moins que le ST pour une synthèse AM-FM infiniment plus évoluée que ce que propose le ST...
Il n'empeche : Paula PEUT faire de la synthèse FM. T'as juste dit le contraire

[stapha92]

eh bien pas de chance, encore une fausse affirmation de ta part, une de plus...

J'adore ta façon d'essayer de faire illusion en disant une de plus...

Et biens voyons ça :

FOR I=1 TO 1000
PRINT I
NEXT I

En GFA Atari ST direct : 24,50 secondes
En GFA Amiga fenêtre  : 40,2 secondes

donc afficher un PRINT dans une fenêtre, sur Amiga, et contrairement à ce que tu as affirmé, prends presque 2 fois plus de temps !

J'ai fait l'essai avec :
   - Steem : STF à 8 Mhz (souvenons nous que l'auteur de pacmania expliquait que Steem va plus vite qu'un ST mais bon...)
   - WinUAE : A500 ocs cycle exact (sans fast ram bien entendu...)

Et bizarrement j'obtiens :
   - ST : 26,5 secondes
   - Amiga : 36,5 secondes

Etrange cette propension à s'écarter un peu des résultats... Ton WinUAE ne serait pas ralenti par la synchro vbl avec l'affichage du PC ? (le pourcentage cpu ne doit jamais dépasser 100%...).

ça n'est pas "presque 2 fois plus de temps". En fait moins de 40% de temps en plus.

Mais ce n'est pas fini ! Pour que le test soit cohérent, comparons ce qui est affiché dans les 2 cas.

ST :



Et Amiga


Que voit_on ?

 - D'abord le nombre de couleurs : 2 sur ST et 4 sur le mig (je ne compte pas celles du pointeur de souris bien sur...). Le print du ST manipule donc 2 fois moins de données. Mais bon, passons...
 - Le nombre de lignes : 25 sur ST et 29 sur le mig. C'est normal, en PAL le mig utilise des écrans de 256 lignes par défaut. En passant sur un ecran de 200 lignes, le mig met 29,5 secondes (tu peux essayer facilement : il suffit de mettre le mig en NTSC) ! Ah ben tient, ça devient presque la même chose ! Avec 2 fois plus de couleurs !
 - Le pointeur sur ST est ou ? Ben le GFA ne l'affiche que si on bouge la souris. Sauf qu'il le fait très mal : il apparait pendant une vbl de temps en temps. Super ! Et si on bouge la souris pendant le test, et bien le ST met 29,5 secondes !

Mais ça ce n'est rien : sur le mig, le multitache est activé et la fenêtre peut être déplacée, être redimensionnée, prendre ou perdre le focus, etc... De plus l'affichage marcherait sur une carte graphique (ce qui serait vrai pour le GFA aussi s'il passait par le GEM...). Et bien sur le pointeur ne scintille absolument pas !

Donc dans une fenêtre sur le mig, avec 2 fois plus de couleurs, en utilisant les fonctions systemes et en laissant le multitache activé, ça tourne quasiment aussi vite que le ST en 2 couleurs, en affichage direct, et allant jusqu'à oublier le pointeur de souris !  

mais tu vas surement me dire : et sur ST hein, dans une fenêtre... ben tu devrais surtout pas poser la question, en fait c'est déjà trop tard pour toi 


PRINT dans une fenêtre GFA Atari ST :  25,20 secondes !!!!  deux fois plus rapide que le super intuition amiga !

OPENW 1
FULLW #1
FOR I=1 TO 1000
PRINT I
NEXT I   
CLOSEW #1

Là ça devient triste de te voir t'enfoncer comme ça...

Tu as mesuré le temps sans la deuxième ligne, c'est à dire avec une fenêtre minuscule. Tu as ajouté "FULLW #1" pour avoir une fenêtre plein écran comme le mig mais tu n'as pas pensé à refaire la mesure !
Moi je l'ai fait :

1 minutes 21 secondes !!!!!!

Le "super intuition" explose ton GFA !!!!

Mais ce n'est pas tout. Que donne ta fenêtre ?
Ceci :

C'est quoi cette fenêtre ??!!!! Ce n'est pas une fenêtre GEM !!!! C'est une fenêtre gérée par le GFA directement !!! Mais pourquoi avoir fait ça si le GEM est si rapide ??  
Et faut voir ce que le GFA fait pour optimiser l'affichage : quand tu la redimensionnes pour la passer en plein écran, il n'efface même pas les anciens bords ! C'est le défilement qui les fait disparaitre !
Et bien sur pas de pointeur de souris : très pratique si on veut gerer le déplacement de la fenêtre (qu'il faudra faire soi même...) pendant qu'il y a un affichage dedans...

Donc dans une fenêtre gérée par le GFA, avec des prints bien plus rapides que ceux du GEM, ça n'atteint même pas la moitié de vitesse obtenue par intuition (presque le tiers !!!!) avec 2 fois plus de couleurs, une gestion de la fenêtre en temps réel et un multitache activé !!!

En fait, avec une fenêtre GEM, l'écart serait plus grand que ce que j'avais pensé !

Et pour afficher une fenêtre GEM, c'est tout simple, il suffit de faire ça

Code:

ret%= WIND_GET(0,4,rootx%,rooty%,rootw%,rooth%)
handle%=WIND_CREATE(&H2F,30,30,100,100)
titre$="GFA"
ret%=WIND_SET(handle%,2,CARD(SWAP(VARPTR(titre$))),CARD(VARPTR(titre$)),0,0)
ret%=WIND_OPEN(handle%,workx%,worky%,workw%,workh%)

Juste l'ouverture de la fenêtre. Faut encore écrire dedans...
C'est ça votre super GFA ? Qui est soi-disant mieux implémenté dans le ST ? 
Et je ne parle pas de l'editeur de code : une horreur...

Tu te souviens ? Tu avais expliqué qu'il fallait 2 minutes pour lancer le GFA sur le mig. Encore une de tes explications foireuses : tu avais mis la D7 du WB d'abord...
Je t'avais dit qu'en démarrant sur la disquette GFA, ça n'avait rien à voir. Et je t'avais montré que sur mig il était facile de démarrer automatiquement sur le GFA et je t'avais demandé comment faire la même chose sur le ST. Toujours pas de réponse. Normal : c'est une horreur ! Pour une machine hyper conviviale, c'est un parcourt du combattant ! (j'expliquerais une autre fois : y en a qui vont se fendre la gueule...)

Et bien c'est de cette disquette que je suis parti. Du coup, amiga éteint, il faut une cinquantaine de secondes pour lancer le GFA, taper le code test et attendre son execution. 30 secondes de moins que le temps que met le ST pour le test seul dans une fenêtre...  

Et je l'ai mis en vidéo pour que tu vois bien que je ne ment pas :


Je repense à ta première phrase : visiblement c'est toi qui n'a pas de chance...

[stapha92]

Tout simplement parce que j'ai dans les 2 cas appliqué un floyd steinberg.

J'ai pris ton image originale pour la convertir en 1 bits avec fs (sinon aucun intérêt) avec PSP6 (pour aller plus vite, je fais la même chose avec hamlab sur amiga).

Puis import direct avec les programmes respectifs.

Tu tombes dans le piège tendu par Rocky en faisant ça. A quoi sert de faire le tramage ? Tu ne peux pas savoir combien de pixels l'image prendra à l'impression. Nombre de pixels qui changerait à chaque changement de taille de l'image dans le document. Et il te faudrait refaire ton floyd à chaque fois...

Pire : un document doit pouvoir être imprimé sur des imprimantes avec des caractéristiques différentes sans s'arracher les cheveux. C'est pourquoi le tramage doit se faire à l'impression.

Y a que Rocky qui fait son tramage en amont...

[rocky007]

L'utilité ? Je te la redonne une énième fois : Quand tu imprimes une image, même si elle est imprimée en N&B avec des trames, tu auras l'impression qu'il y aura plusieurs nuances de gris grace à la taille des points imprimés. Donc un rendu écran avec 16 gris sera plus proche de l'impression que ta bouillie de pixel composée de trames qui sont sans rapport avec le tramage de l'imprimante. à moins d'etre avec un zoom surpuissant et à condition que ce zoom permette d'avoir une correspondance 1 point=1 pixel pile poil...

encore une fois, si tu veux travailler le type de trame, c'est la seule option
ce n'est pas avec ton pseudo dégradé que tu pourras avoir la main sur la trame.
du reste les logiciels pro le font tous : qd tu travailles une image tramée, en dezoom elle sera extrapolée en nuance de gris, et quand tu zoomeras dessus tu pourras bien travailler sur la trame.  aujourd'hui on peut mixer les deux modes

Ok alors montre moi la solution d'époque qui permette d'atteindre 2,5 Mo/s. Même aujourd'hui un ultrasatan ne les atteint pas, pas du tout. C'est ce qu'explique l'auteur des vidéos...
Mais toi tu as prétendu avoir fait tourner ces vidéos sur ton ST....

le débit ACSI est de +-1.8Mb/s ( plus que le débit théorique de 1.25 )
le débit SCSI sur TT est de +- 4 Mb / sec  ( http://www.atari-wiki.com/?title=ACSI,_SCSI_and_IDE )

voilà, tu as ta réponse

Oui je sais ce que ça veut dire. Et toi sais-tu ce que veut dire DAC ? ça veut dire Digital Analogique Converter. C'est ce que fait Paula. ton schema représente l'inverse : analogique vers digital. En fait il s'agit d'un simple aiguillage qui transforme un signal unique en 8 signaux ayant chacun un niveau de plus en plus petit. La transformation de ces signaux est assurée par l'interface parrallèle. C'est le gros du boulot pour la conversion A-> D

ouille ouille, là c'est n'est plus une branche qui se casse, mais une forêt entière qu'on rase !
alors prenons déjà ton explication : simple aiguillage qui transforme un signal unique en 8 signaux ayant chacun un niveau de plus en plus petit.

es-tu au courant qu'un port // travaille en binaire ? donc tu ne peux avoir que 0 ou 1, selon un point de bascule qui se situe en général ) 3.3V.  donc ce qui est en dessous de 3.3V sera considéré comme 0, ce qui sera au dessus sera considéré comme 1.   ton explication n'a dès lors aucune logique : à quoi servirait d'avoir des signaux proportionnellement de plus en plus petit, puisqu'ils ne seront de toute façon converti qu'un 0 ou en 1 ?  qu'auras-tu comme résultat sur un signal audio < 3.3V ?  0 !    c'est d'un ridicule !

par contre l'inverse, ooooh magie, ça fonctionne :  chaque bit du port // passe dans le réseau de résistance, composant ainsi un voltage unique qui sera, miracle, la représentation analogique des bits !

Donc ça n'a rien à voir. En plus ton schéma donnerait vraiment un son de merde : si tu penses obtenir un vrai sample 8 bits avec ça...
Ce qui est drole c'est que tu avais posté 2 autres schémas avant de modifier ton post.

ben oui , je vais même t'expliquer pourquoi : j'avais en effet posté les schémas, mais je me suis dit qu'ils étaient trop complexe pour toi, j'ai donc continué mes recherches et suis tombé sur un autre schéma... oui le schéma que tu prétends être faux ( selon toi un ADC ! ) est en fait le schéma de la carte son Covox pour PC !    ( https://en.wikipedia.org/wiki/Covox_Speech_Thing )

y'a pas à dire, il n'y a pas un post sans des erreurs à tomber par terre chez toi !


un son de merde ?  pour la petite info, ce type de DAC est même suffisamment précis  pour générer un signal vidéo !

A écouter sur une chaine hifi : si tu reproduis ça avec quelques résistances, je t'invite dans le resto de ton choix ! (sinon je t'inviterai également avec plaisir, mais je ne te laisserai pas choisir le resto !  

bon, ça t'arrange quand ?

T'étais en train d'expliquer qu'avec les imprimantes moderne il n'y a pas de tramage. Qu'il y ait 1 niveau de cyan ou 2 ou 3 (encore une fois pas sur toutes les imprimantes modernes) ne change rien : un tramage est toujours obligatoire. Tu chipotes pour t'écarter du sujet initial ?

j'ai jamais expliqué cela, tu inverses les rôles, c'est toi qui modifie tes propos, preuve à l'appui...il aura fallu 5 post pour que tu constate qu'en effet, tu avais bien prétendu que les imprimantes n'avait pas de niveau...et encore, même ici tu te débats toujours

Chargé ? De quoi parles tu ? Il n'est pas en ROM le GEM ? Tu peux appeler les fonctions GEM sans problème sous GFA. Mais c'est un casse tete..

mets Calamus dans un dossier Auto, tu verras si ça fonctionne

Il n'empeche : Paula PEUT faire de la synthèse FM. T'as juste dit le contraire

je ne suis pas d'accord : tu dois quand même lui fournir des données pour les modulations ainsi qu'un sample sur lequel appliquer tout cela.   sans sample, il ne sait rien faire.

[Invité]

je ne suis pas d'accord : tu dois quand même lui fournir des données pour les modulations ainsi qu'un sample sur lequel appliquer tout cela.   sans sample, il ne sait rien faire.

Et tu crois que ca marche comment sur une puce fm ???
Tu as un sample,representé par une onde(spuvent simple,sur md c est juste une sinusoide),dont tu modules la frequence .

[rocky007]

Et bizarrement j'obtiens :
   - ST : 26,5 secondes
   - Amiga : 36,5 secondes

donc tu avais bien tort en prétendant que l'affiche PRINT en fenêtre Amiga était plus rapide que l'affiche direct sur ST. 

 - D'abord le nombre de couleurs : 2 sur ST et 4 sur le mig (je ne compte pas celles du pointeur de souris bien sur...). Le print du ST manipule donc 2 fois moins de données. Mais bon, passons...

mais qu'est que tu racontes ?  l'affichage est en 16 couleurs sur le ST, amuses à dessiner un dégradé de 16 couleurs, fais ton PRINT et tu verras qu'il va scroller dans la fenêtre, preuve qu'il manipule bien un écran entier 16 couleurs
 

- Le nombre de lignes : 25 sur ST et 29 sur le mig. C'est normal, en PAL le mig utilise des écrans de 256 lignes par défaut. En passant sur un ecran de 200 lignes, le mig met 29,5 secondes

oui c'est toujours plus que le ST.  donc cela ne change rien au fait que tu te sois encore trompé.
tu peux venir avec ta souris, des bidules et autres, ce n'est que de la poudre aux yeux pour essayer à tout prix d'avoir raison.  un PRINT direct sur ST est plus rapide que sur Amiga, point barre.  c'était ton affirmation et elle est fausse.

Mais ça ce n'est rien : sur le mig, le multitache est activé et la fenêtre peut être déplacée, être redimensionnée, prendre ou perdre le focus,

oui et alors ? si tu as un soft qui tourne en fond, cela pas ralentir ?  ici justement, il n'y a qu'une tâche, le GFA, pourtant c'est plus lent.   pire : c'est soi disant multitâche ? pourquoi alors quand on veut redimensionner/déplacer etc.. le programme GFA s'arrête ?  ah oui wow, c'est terriblement efficace !

Tu as mesuré le temps sans la deuxième ligne, c'est à dire avec une fenêtre minuscule. Tu as ajouté "FULLW #1" pour avoir une fenêtre plein écran comme le mig mais tu n'as pas pensé à refaire la mesure !
Moi je l'ai fait :

1 minutes 21 secondes !!!!!!

tu disais quoi à propos de ma config et de mes chiffres ?  je pense que c'est plutôt toi qui a un sacré problème.

Je t'avais dit qu'en démarrant sur la disquette GFA, ça n'avait rien à voir. Et je t'avais montré que sur mig il était facile de démarrer automatiquement sur le GFA et je t'avais demandé comment faire la même chose sur le ST. Toujours pas de réponse.

ben tu mets GFA dans un repertoire AUTO, vu qu'il n'est pas en GEM, il démarre direct

cinquantaine de secondes pour lancer le GFA

mon dieu, oui c'est ultra lent...20-30 sec sur ST maxi

[rocky007]

je ne suis pas d'accord : tu dois quand même lui fournir des données pour les modulations ainsi qu'un sample sur lequel appliquer tout cela.   sans sample, il ne sait rien faire.

Et tu crois que ca marche comment sur une puce fm ???
Tu as un sample,representé par une onde(spuvent simple,sur md c est juste une sinusoide),dont tu modules la frequence .

cela peut être un oscillateur

[Meditating Guru]

C'est quoi cette fenêtre ??!!!! Ce n'est pas une fenêtre GEM !!!! C'est une fenêtre gérée par le GFA directement !!! Mais pourquoi avoir fait ça si le GEM est si rapide ??  
Et faut voir ce que le GFA fait pour optimiser l'affichage : quand tu la redimensionnes pour la passer en plein écran, il n'efface même pas les anciens bords ! C'est le défilement qui les fait disparaitre !
Et bien sur pas de pointeur de souris : très pratique si on veut gerer le déplacement de la fenêtre (qu'il faudra faire soi même...) pendant qu'il y a un affichage dedans...

C'est bien une fenêtre GEM. Je programme sous Windows en C/C++ et c'est la même chose, même pire, il n'y a pas de PRINT pour la fenêtre, tu dois tout (re)dessiner toi-même en fonction des messages.  
J'étais un enthousiaste du GFA basic 2 quand il est sorti, pour son code structuré, bon apprentissage, mais quand on y réfléchit, en effet, il n'exploitait pas le GEM sans des peek et des poke, à part les messages d'alerte, le sélecteur de fichier que tout le monde utilisait.
EDIT Oops, et les menus je crois?
Avant je lui aurais donné 90%, maintenant ce serait 60% pour ignorer le (super) OS du ST. Tu peux critiquer le GEM mais apprendre à le programmer (VDI, AES), ce que je n'ai pas fait, aurait été une grande aide pour commencer sous Windows (que les fanboys Amiga critiquent aussi   ).
C'est venu plus tard avec la version 3 je crois.

[Zarnal]

C'est bien une fenêtre GEM. Je programme sous Windows en C/C++ et c'est la même chose, même pire, il n'y a pas de PRINT pour la fenêtre, tu dois tout (re)dessiner toi-même en fonction des messages.  
J'étais un enthousiaste du GFA basic 2 quand il est sorti, pour son code structuré, bon apprentissage, mais quand on y réfléchit, en effet, il n'exploitait pas le GEM sans des peek et des poke, à part les messages d'alerte, le sélecteur de fichier que tout le monde utilisait.
EDIT Oops, et les menus je crois?
Avant je lui aurais donné 90%, maintenant ce serait 60% pour ignorer le (super) OS du ST. Tu peux critiquer le GEM mais apprendre à le programmer (VDI, AES), ce que je n'ai pas fait, aurait été une grande aide pour commencer sous Windows (que les fanboys Amiga critiquent aussi   ).
C'est venu plus tard avec la version 3 je crois.

Ah, un truc piqué au C64... 

[stapha92]

encore une fois, si tu veux travailler le type de trame, c'est la seule option
ce n'est pas avec ton pseudo dégradé que tu pourras avoir la main sur la trame.
du reste les logiciels pro le font tous : qd tu travailles une image tramée, en dezoom elle sera extrapolée en nuance de gris, et quand tu zoomeras dessus tu pourras bien travailler sur la trame.  aujourd'hui on peut mixer les deux modes

Pourquoi je m'embete ?!!!
Si tu veux : un mode monochrome c'est mieux et avoir 16 gris ou 16 couleurs ne sert à rien.
Content ? Tu te doute que personne ne va être d'accord avec toi..

le débit ACSI est de +-1.8Mb/s ( plus que le débit théorique de 1.25 )
le débit SCSI sur TT est de +- 4 Mb / sec  ( http://www.atari-wiki.com/?title=ACSI,_SCSI_and_IDE )

voilà, tu as ta réponse

Ah ok... Le TT a la rescousse alors ? Puisque tu as la bonté de me donner des réponses : dis moi comment tu as pu jouer des vidéos qui ont besoin de 2,5 Mo/s (et de plusieurs modif sur le ST dont une qui permet d'alimenter le shifter directment...) sur ton ST avec Ultrasatan ?

es-tu au courant qu'un port // travaille en binaire ? donc tu ne peux avoir que 0 ou 1, selon un point de bascule qui se situe en général ) 3.3V.  donc ce qui est en dessous de 3.3V sera considéré comme 0, ce qui sera au dessus sera considéré comme 1.   ton explication n'a dès lors aucune logique : à quoi servirait d'avoir des signaux proportionnellement de plus en plus petit, puisqu'ils ne seront de toute façon converti qu'un 0 ou en 1 ?  c'est d'un ridicule !

Mais justement : avec des signaux de plus en plus petit mais tous proportionnels au sgnal de départ, plus ce dernier sera élevé, plus nombreux seront les signaux qui seront au-dessus de 3,3 V et plus nombreux seront les 1. Donc un signal plus fort générera un plus grand nombre binaire qu'un signal faible. Il y aura bien conversion analogique/digitale.
Mais je te le répète : c'est le port parallèle qui fera le gros du boulot. C'est lui qui s'occupera de traduire le courant en 0 ou 1 en fonction de la barrière de 3,3V.

Je te rappelle : tu as expliqué que l'on pouvait faire un DAC avec UNIQUEMENT des résistances. ça reste faux. Ton schéma utilise un port parrallele qui représente bien plus que des résistances.

ben oui , je vais même t'expliquer pourquoi : j'avais en effet posté les schémas, mais je me suis dit qu'ils étaient trop complexe pour toi, j'ai donc continué mes recherches et suis tombé sur un autre schéma... oui le schéma que tu prétends être faux ( un ADC ! ) est en fait le schéma de la carte son Covox pour PC !     ( https://en.wikipedia.org/wiki/Covox_Speech_Thing )

y'a pas à dire, il n'y a pas un post sans des erreurs à tomber par terre chez toi !

Et bien remets les tes premiers schémas :
Il n'avaient pas besoin d'un port parallèle eux. Et, comme par hasard, ils n'étaient pas composés que de résistances.

Sinon tu as raison : ton schéma est bien un DAC. Tu vois moi je reconnais mes erreurs. Je ne cherche pas à dévier et je n'évite pas de répondre à certains posts. Par contre je maintiens que des résistances ne suffisent pas pour faire un DAC

Par contre pour ta vidéo : c'est bien un son de merde. Il y a une musique Amiga alors c'est facile de comparer...

Si tu me trouves un schema de DAC avec uniquement des résistances et qui ne s'appuie pas sur une électronique plus complexe, là tu pourras prétendre que Paula = quelques résistances comme tu l'as affirmé.
En attendant cette preuve (qui ne pourra pas venir), tu as eu completement tort. alors ta réflexion "y a pas à dire" tu peux te la garder. Demande toi pourquoi y en a plusieurs qui doutent autant de tes dires...

bon, ça t'arrange quand ?   

Tu te moques mais ça ne me dérangerais pas du tout ! Après tout j'aime bien le ST...
mais même si je considérais que ta carte covox est un DAC qui n'utilise que des résistances (encore une fois ce n'est pas le cas...) il faut que tu reproduises la qualité de ce que j'ai posté. On en est loin... 

j'ai jamais expliqué cela, tu inverses les rôles, c'est toi qui modifie tes propos, preuve à l'appui...

Oui tu tournes en rond. Mais c'est plus la peine : continues à affirmer que 2 couleurs sont mieux que 16. je ne te contredirai pas.

mets Calamus dans un dossier Auto, tu verras si ça fonctionne

Ben oui : ton dossier Auto est traité par le TOS avant qu'il lance le GEM. Du coup un programme GEM ne peut pas être lancé automatiquement. Encore un super truc du couple TOS/GEM...

Mais on peut appeler les fonctions GEM depuis le GFA. Donc le problème n'est pas là : le problème est que ça ramerait trop...

[stapha92]

C'est bien une fenêtre GEM. Je programme sous Windows en C/C++ et c'est la même chose, même pire, il n'y a pas de PRINT pour la fenêtre, tu dois tout (re)dessiner toi-même en fonction des messages.   
J'étais un enthousiaste du GFA basic 2 quand il est sorti, pour son code structuré, bon apprentissage, mais quand on y réfléchit, en effet, il n'exploitait pas le GEM sans des peek et des poke, à part les messages d'alerte, le sélecteur de fichier que tout le monde utilisait.  
Avant je lui aurais donné 90%, maintenant ce serait 60% pour ignorer le (super) OS du ST. Tu peux critiquer le GEM mais apprendre à le programmer (VDI, AES), ce que je n'ai pas fait, aurait été une grande aide pour commencer sous Windows (que les fanboys Amiga critiquent aussi   ). 
C'est venu plus tard avec la version 3 je crois.

Je programme sous Windows aussi et ça implique de faire de la programmation événementielle... Qui existait sur Amiga. ça m'a simplifié les choses.

Et sous windows, quand tu instancies un form (une fenêtre pour ceux qui ne connaissent pas), tu n'as pas besoin de gérer son positionnement, son redimensionnement, etc... Tu réagis aux événement que tu souhaites mais tu n'es jamais obligé de coder toutes ces choses : comme le mig...

Par exemple , tu sais bien que si tu veux gérer un clic sur un bouton, tu ne vas pas constamment tester la position de la souris et si un clic est effectué. Tu vas créer un évenement clic sur ce bouton. Exactement comme le mig et contrairement au ST. En cela l'Amiga a été une bonne école.

Je ne dis pas que le GFA est un mauvais langage, pas du tout. Je considère qu'il a permis à pleins de gens qui venait du basic d'apprendre la programmation structurée. Très bonne chose.

[babsimov]

Merci pour ta réponse, ça confirme donc ce que je pensais du MAC, c'était une belle arnaque. A propos, ce système de répartition des cycles sur le MAC (qui n'est donc pas adapté au 68000), serait il en fait un "héritage" du l'Apple II et du 6502 ?

une belle arnaque qui figure pourtant parmi les ordinateurs historiques selon Byte...
je rêve du jour où l'amigaiste cessera de confondre les performances pures et le plaisir d'utilisation

Mais le MAC n'a pas de performance pure, le ST est meilleur que lui dans tous les domaines. Je dis que le MAC est de l'arnaque pour ça. Le MAC c'est le succès du marketing c'est tout. Pourquoi est il dans Byte, mais parce que, malgré tout, Apple furent les premiers à proposer la GUI au "grand public". Et comme Apple est encore présent de nos jours, il est bien évident que le MAC ne pouvait pas ne pas être dedans.

Du reste l'Amiga est dedans, pas le ST (note qu'il aurait pu lui faire, malgré tout, une petite place, il avait fait un article sur le 1040ST et son prix intéressant pour 1 MO de mémoire).

Tu penses que je ne savais pas que le chip sonore du IIGS était issu du créateur du SID ? Je le savais. J'avais même dit que le son était certes très clair, mais que je préférais celui de Paula à base de samples. J'avais notamment comparé Defender Of The Crown, et la musique Amiga me parait sonner bien plus médiévale. Celle du SID aussi. Celle du IIGS fait trop "artificielle". Relis tu verras que c'est ce que j'avais dit. 

comment peux-tu comparer la qualité d'un chip sonore en comparant simplement deux musiques du même jeu.  si le musicien qui l'a adapté sur Apple IIGS ne s'est pas foulé, forcément ce sera moins bon.  

Relis un peu quand j'avais fait des comparaisons avec plusieurs machines face à l'Amiga. Bien entendu que j'avais écouté plusieurs musiques des mêmes jeux en version IIGS et Amiga. Loin de moi l'idée de dire que la qualité sonore du IIGS n'est pas très bien. J'avais dis que le son était limpide, mais que malgré tout, en règle générale la version Amiga sonnait mieux.

Ben voyons, si la majorité des plateformes (dont le ST) à l'époque cherchaient à pouvoir jouer les MODS Amiga, c'est bien qu'ils devaient avoir des qualités non ? Les musiques Amiga sonnaient "vrais", les chip tune nettement moins.
Au fait, tu as reconnu toi même que Paula était une révolution à l'époque. Il suffit de relire nos longs débats sur le son. Mais tu oublies vite.

non ce sont tous les ces utilisateurs d'amiga qui ont fuit sur d'autres machine et qui voulaient retrouver la musique qu'ils entendaient pendant leurs copies.

Quelle argumentation ridicule... et la démo de 2003 qui repompe le module d'Enigma pour soit disant glorifier le ST (enfin le STE puisqu'il semble qu'il faille un STE pour la jouer et encore moins bien que sur l'Amiga) ! Bref, nier qu'à l'époque toutes les plateformes enviaient et cherchaient à atteindre le niveau du son natif de l'Amiga c'est vraiment faire preuve de mauvaise foi, mais on est habitué avec toi.

Paula était une révolution dans l'idée, mais pas dans sa conception ( mais cela n'engage bien évidement que moi ).
C'était simple et très efficace.  

Mais Paula ce n'est pas que le son, c'est aussi la gestion des entrées sortie. En tout cas, choisir de mettre du sample à l'époque était bien là aussi une révolution, comme tu l'avais reconnu dans l'échange au sujet de Paula, il y a bien longtemps. 

Et bien l'Archimèdes relis le sujet, tu verras qu'en fait dans la réalité il fait du 4 voies (parce que 8 voies ça prend trop de processeur). Les mods Amiga joués dessus sonnent moins bien, comme sur le ST. D'ailleurs, tiens encore un exemple de machine qui a cherché à pouvoir jouer les mods Amiga... 

je suis pas spécialiste, j'ai lu la fiche technique et ils indiquent 8 voies stéréo.  je ne vois pas pq les mods amiga sonneraient moins bien, sinon un soundtracker qui n'est pas suffisamment compatible

Oui, comme la fiche technique du STE dit qu'il y a un blitter, ça veut pas dire qu'il surpasse celui de l'Amiga, comme la fiche technique du 1200 dit que c'est 256 couleurs dans tous les modes (dans la réalité, c'est le cas, mais à quelle vitesse !). Ou comme l'Archimède a 256 couleurs, mais seulement 16 de paramétrables (si je me souviens bien du sujet). Bref, on fait dire ce qu'on veut à une fiche technique, mais dans la réalité c'est souvent bien différent. La fiche technique de l'Amiga, par contre, annonçait la réalité, l'utilisateur n'a pas été déçu.

On a aussi parlé du prix. Et le chiptune c'est pas du sample, le sample sonne plus "vrai" pour moi. On a déjà suffisamment comparé des musiques de cartes sons hyper cher face à l'Amiga et dans de nombreux cas, l'Amiga sonne bien mieux.

oui bien évidement, un sample serait toujours plus réaliste que le même instrument synthétisés.  mais à quel prix ? ( taille, fréquence, etc..)  

Si ta machine coûte moins cher que celle avec chiptune ou autre et que le son qu'elle sort est meilleur, c'est donc que le choix technique du sample était le plus judicieux. D'autant plus que l'histoire de la mémoire (RAM) n'est même pas le problème au prix des cartes son PC !

Mais elle était à quelle prix ? C'est normal que si tu paye nettement plus que l'Amiga tu obtiennes mieux, surtout si la machine sort bien après l'Amiga.

ah donc pour toi, ils faut tenir compte des critères suivant pour dire que Paula le meilleur :

- vendu en france
- pas cher
- connu de tous

si par malheur un autre sound chip existe mais ne rempli pas ces trois critères, il est disqualifié et considéré comme inexistant

On parlait des machines connues du plus grand nombre à l'époque, PC/MAC/ST et sur ces machines il a fallu bien longtemps et très cher pour arriver à égaler le son de l'Amiga.

La majorité des machines issues du japon que tu as cité sont sorties bien après l'Amiga, étaient très peu connues en dehors du Japon. Et même dans ce cas, le son chiptune de ces machines pouvaient être "simulé" sur l'Amiga, donc "mieux" je suis pas convaincu.

Le YM est difficile à émuler. Il ne fait pas beaucoup s'y connaître pour affirmer le contraire. Certaines videos sonnent mal à cause des anciennes versions des émulateurs. Encore aujourd'hui, l'émulation n'est pas parfaite. Le son du YM est puissant dans les basses (sans le grésillement du SIDA), et presque strident dans les aigües, ce qui rend les morceaux bien plus captivants que les quelques samples 8bit de l'Amiga (rappelons qu'un piano a besoin de gigas pour être restitué sans faire saigner les oreilles...). Defender of The Crown est inferior sur Amiga, quelle caricature de musique!   



Ou il y a un problème d'émulation? Car c'est vraiment insupportable.   

Je pense la même chose d'Enchanted Land mais j'ai connu la musique sur ST d'abord, du coup la version Amiga sonne comme une mauvaise imitation.

Mais c'est vrai que le registre du YM est limité, on ne sait pas tout faire avec. 




Séparation stereo horrible comme d'hab...  
J'entends déjà votre réponse: on l'écoute en mono.   

Comme tu es le seul à critiquer les samples 8 bits comme inacceptable (surtout que pour l'époque c'était ce qu'il y avait de mieux toute machine confondue)... Ton message n'est donc plus très crédible.

[Meditating Guru]

Comme tu es le seul à critiquer les samples 8 bits comme inacceptable (surtout que pour l'époque c'était ce qu'il y avait de mieux toute machine confondu)... Ton message n'est donc plus très crédible.

Ce n'est pas ce que je dis. Je dis que le sample 8bit par rapport au soundchip (YM, SID), ça se discute, et que beaucoup de musiques Amiga sont horribles.
Sûr qu'à l'époque la technologie était très bien.
De là à dire que ça surpasse musicalement la MT32...

[babsimov]

Comme tu es le seul à critiquer les samples 8 bits comme inacceptable (surtout que pour l'époque c'était ce qu'il y avait de mieux toute machine confondu)... Ton message n'est donc plus très crédible.

Ce n'est pas ce que je dis. Je dis que le sample 8bit par rapport au soundchip (YM, SID), ça se discute, et que beaucoup de musiques Amiga sont horribles.
Sûr qu'à l'époque la technologie était très bien.
De là à dire que ça surpasse musicalement la MT32...

T'es quand même un peu le seul à dire que les musiques Amiga sont "horribles" 

En ce qui concerne le MT32, je disait au moment du débat sur ce point, que je trouvais que c'était une honte qu'une carte son aussi chère n'arrive qu'au mieux dans certain cas à égaler le son de l'Amiga. La plus part du temps le son fait "toc", notamment les percussions. Je ne dis pas que le son sortit par la carte n'est pas clair, je dis que la même musique sur Amiga sonne plus vrai.

[rocky007]

Pourquoi je m'embete ?!!!
Si tu veux : un mode monochrome c'est mieux et avoir 16 gris ou 16 couleurs ne sert à rien.
Content ? Tu te doute que personne ne va être d'accord avec toi..

alors expliques moi comment tu gères ta trame si tu n'as qu'un visuel couleur ?

Ah ok... Le TT a la rescousse alors ? Puisque tu as la bonté de me donner des réponses : dis moi comment tu as pu jouer des vidéos qui ont besoin de 2,5 Mo/s (et de plusieurs modif sur le ST dont une qui permet d'alimenter le shifter directment...) sur ton ST avec Ultrasatan ?

la question était : était-ce possible à cette époque, la preuve que oui est faite
j'ai pu jouer les vidéos téléchargeable, j'ai pas chronométré le framerate, le but de cette affirmation était la qualité de l'image, dont personne ici ne croyait que c'était possible.

Mais justement : avec des signaux de plus en plus petit mais tous proportionnels au sgnal de départ, plus ce dernier sera élevé, plus nombreux seront les signaux qui seront au-dessus de 3,3 V et plus nombreux seront les 1.

et donc ?  si ton signal sonore est faible, il ne se passe rien ( tout à zero ) et s'il est trop fort, il ne se passe rien non plus ( tout à 1 )...tu ne pourras mesurer que de grandes fluctuations...bref, tu te débat encore...

Je te rappelle : tu as expliqué que l'on pouvait faire un DAC avec UNIQUEMENT des résistances. ça reste faux. Ton schéma utilise un port parrallele qui représente bien plus que des résistances.

ton DAC , tu dois bien lui donner un signal digital non ? que cela vienne d'un port // ou d'un microcontroller, cela ne change rien.   donc qd agnus feed paula en données, il le fait déjà bien sous forme digitale non ?

le fait que tu fournisses au DAC les données sous forme de bit, données série, I2C, etc..ne change rien à sa fonction : il converti une valeur digitale en analogique.

regarde un DAC tel que le AD558, il fait exactement la même chose : tu rentres 8 bits sur les pins respectives, et il te sort un signal analogique

 l

Je te rappelle : tu as expliqué que l'on pouvait faire un DAC avec UNIQUEMENT des résistances. ça reste faux. Ton schéma utilise un port parrallele qui représente bien plus que des résistances.

et oui, et tu as prétendu que cela était faux...pire encore, tu as prétendu que mon schéma était un ADC, c'est à mourir de rire...

Par contre pour ta vidéo : c'est bien un son de merde. Il y a une musique Amiga alors c'est facile de comparer...

c'est ta vision des choses.. et cela n'engage que toi.

si tu me trouves un schema de DAC avec uniquement des résistances et qui ne s'appuie pas sur une électronique plus complexe, là tu pourras prétendre que Paula = quelques résistances comme tu l'as affirmé.

j'ai eut complement tort ?  ahaha elle est forte celle, tu viens la queue entre les jambes dire que tu t'es trompé, et tu oses encore dire cela ?
merci, tu confirmes donc Paula = résistances

Ben oui : ton dossier Auto est traité par le TOS avant qu'il lance le GEM. Du coup un programme GEM ne peut pas être lancé automatiquement. Encore un super truc du couple TOS/GEM...

Mais on peut appeler les fonctions GEM depuis le GFA. Donc le problème n'est pas là : le problème est que ça ramerait trop...

et voilà, tu avais tort encore et tu te débats comme une grenouille à qui on vient d'arracher les pattes..
dis moi comment tu lances des fonctions GEM dans le GFA si le GEM n'est pas chargé ?  mets ton GFA dans un Auto, et retapes ton listing GEM... oh ben zut, ça marche pas..
eh oui raison pour laquelle GFA sort un print nativement hors GEM, car il n'est pas forcément chargé.  tu avais encore une fois tort

[babsimov]

Le SID m'impressionne toujours autant.

Je viens de trouver un démo avec un hommage à Enigma et une version SID de la musique de la démo :



Voici la musique de la démo :




Je croyais que personne ne se souvenais des musiques Amiga :



C'est sur qu'il y a pas de public


Et un autre et la on cite au public l'Amiga (avec des titres comme It Came From The Desert, on peut difficilement faire plus Amiga comme jeu) :

[rocky007]

c'est fou comme la musique sur le SID donne mieux que sur l'amiga

[babsimov]

c'est fou comme la musique sur le SID donne mieux que sur l'amiga

Elle était facile celle là, tu pouvais faire mieux. En tout cas, j'aimerais bien entendre une version d'Enigma au YM, si ça existe.

Là on pourrait comparer avec le YM avec le SID (on sait déjà que le SID est gagnant en fait :) )

Si le son de l'Amiga était si mauvais, pourquoi penses tu qu'on lui rendrait hommage sur le C64 ?

Comme déjà dit, y a rien à dire, le son natif de l'Amiga était ce qu'on pouvait trouver de mieux pour l'époque. D'ailleurs, la quasi totalité de ce qu'offrait l'Amiga était ce qu'il y avait de mieux pour l'époque à ce prix.

[rocky007]

pour jouer des samples oui, pour de la synthese, non

[babsimov]

pour jouer des samples oui, pour de la synthese, non

Il peut avoir un son synthèse. Le sample était l'avenir. On a déjà débattu de tout ça.

Je suis tombé sur le making off d'Another World. Et que dis Eric Chahi (10"53) "l'Amiga avait un chouette environnement de travail" (on voit le workbench 1.3 ensuite)... Et il a programmé semble t il son jeu en GFA basic... sur Amiga... c'est donc qu'il devait bien avoir choisit le GFA sur Amiga et pas sur ST.




Et un hommage sous forme de bande annonce pour un hypothétique film "Another world"



et un autre 



Un remake de l'intro :

[rocky007]

de qualité inférieure à un vraie puce de synthèse, exactement comme une puce de synthese peut faire du sample..

le sample l'avenir ?  t'es au courant du retour en force des synthés analogique, style moog ?
que sur tout les synthé actuels, c'est principalement de la synthese

le sample a toujours été l'instrument du "pauvre"

[babsimov]

de qualité inférieure à un vraie puce de synthèse, exactement comme une puce de synthese peut faire du sample..

le sample l'avenir ?  t'es au courant du retour en force des synthés analogique, style moog ?
que sur tout les synthé actuels, c'est principalement de la synthese

le sample a toujours été l'instrument du "pauvre"

On l'avait aussi eu ce débat et bon pas convaincu. Tous les micros délaisseront la synthèse pour le sample.

Le sampler c'était surement aussi les instruments du pauvre. Pourtant ils coûtaient fort cher.

Bref, pour du son natif, on faisait pas mieux que l'Amiga à l'époque et certainement pas le YM du ST.

[stapha92]

Rocky tes posts deviennent vraiment lourds et insultants !

Personne à part toi n'es venu dire que je racontait n'importe quoi. Par contre plusieurs personnes t'ont fait ce reproche y compris des Stistes.

Donc voilà comment je vais répondre à ton post : j'en ai marre d'essayer de démontrer quoi que ce soit face un dieu du troll pareil... 

Mode mochrome meilleur : connerie !

Vidéos "hi-color" possible avec un ST : connerie !

Tu parles du framerate maintenant ? Connerie ! tu peux même pas afficher les images de ces vidéos en fixe : tu mens

Tes explications sur les DAC uniquement avec des resistances : connerie ! T'as pas dit que paula était des résistances + un port parrallele. T'as dit juste des résistances : connerie ! Et ton dessin du AD558 : aucun interet.

Et ton réseau de resistance : il sont ou les composants qui envoient un signal quand Dx est à 1 et rien quand Dx est à 0 ? Connerie !

T'es là a parler de tes résistances dont tout le monde se fout : branche un mig et un ST sur une chaine, ferme là et fais ecouter à 10 personnes prises au hasard. Tu te sentiras seules quand elles te donneront leur avis. Ou alors trouve toi un "resistances Vs transistors"

Le GEM pas utilisé parce qu'il est pas chargé ? Connerie ! pourquoi est-ce que sur le mig ils ont fait l'effort d'initialiser intuition et n'ont pas initialisé le GEM ?

J'ai admis une erreur, sur DAC/ADC (erreur qui ne valide en rien ce que tu prétends avec Paula=resistances). J'aurai pu faire comme toi : ne pas répondre sur ce point.

Parce que c'est ta spécialité M. qui glisse des "je me marre", "tu t'enfonces", "tu te débats" entre toutes les phrases :

Pourquoi tu ne réponds plus sur les couleurs plus nombreuses du ST par ligne ? Je me marre !

Pourquoi tu ne réponds plus sur "intuition" moins rapide que GFA en fenêtre ? Je me marre !

Pourquoi tu ne réponds plus sur le HAM qui scintille ? Je me marre !

Pourquoi tu ne réponds plus sur le HAM qui prend 100% du cpu ? Je me marre !

Pourquoi tu ne réponds plus sur "le ST peut jouer des mods aussi bien que le mig ? Je me marre !

Pourquoi tu ne réponds plus sur "le ST peut faire tout ce que scala peut faire" ? Je me marre !

Pourquoi tu ne réponds plus sur "le copper ne fait pas de branchement" ? Je me marre !

Pourquoi tu ne réponds plus sur "le cpu doit recharger la copperlist " ? Je me marre !

Pourquoi tu ne réponds plus sur "lacopper est limitée à 16 couleurs/ligne" ? Je me marre !

Pourquoi tu ne réponds plus sur "le blitter ne peut pas faire de c2p" ? Je me marre !

Pourquoi tu ne réponds plus sur "je peux reproduire le niveau de bonus de BTL en precalc avec 600 Ko" ? Je me marre !

Pourquoi tu ne réponds plus sur "y avait des cartes 68030/40/60 sur ST" ? Je me marre !

Pourquoi tu ne réponds plus sur "La gestion du multitache fait ramer le mig" ? Je me marre !

Pourquoi tu ne réponds plus sur "Les jeux sans scrolling sont meilleurs sur ST" ? Je me marre !

Pourquoi tu ne réponds plus sur "Les circuits du mig font ramer le cpu même quand il ne sont pas utilisés" ? Je me marre !

T'as été jusqu'à poster une vidéo de chaos engine version console en croyant que c'était sur ST alors que n'importe quel amateur de ST voit tout de suite que c'était pas possible !

Je pourrai en faire 4 pages mais je n'ai même pas besoin de continuer : Même ton camp ne te soutient plus. Et la plupart des lecteurs ici n'accordent plus de crédits à tes écrits.

Tu passes ton temps à commencer par dire : "si si c'est possible sur ST" pour finir par "Sur TT c'est possible" ou "y a mieux sur X68000" ou autre. T'es là pour défendre le ST ou pour descendre le mig ?
La dernière dans le genre : le SID c'est mieux que Paula...

Tiens une dernière : quelqu'un de ce forum a fait une démo sur le mig uniquement avec des appels systèmes. Tu lui as expliqué que c'était possible sur ST via des appels systèmes aussi. Tu t'es même pas rendu compte que t'avais aucune crédibilité quand tu as sortie cette monstruosité. T'as déjà codé une démo de cette façon avant de l'ouvrir ? Il rigole encore...

Accessoirement, il attend encore que tu lui explique pourquoi le 640x256 scintille.

[stapha92]

eh bien pas de chance, encore une fausse affirmation de ta part, une de plus...

J'adore ta façon d'essayer de faire illusion en disant une de plus...

Et biens voyons ça :

FOR I=1 TO 1000
PRINT I
NEXT I

En GFA Atari ST direct : 24,50 secondes
En GFA Amiga fenêtre  : 40,2 secondes

donc afficher un PRINT dans une fenêtre, sur Amiga, et contrairement à ce que tu as affirmé, prends presque 2 fois plus de temps !

J'ai fait l'essai avec :
   - Steem : STF à 8 Mhz (souvenons nous que l'auteur de pacmania expliquait que Steem va plus vite qu'un ST mais bon...)
   - WinUAE : A500 ocs cycle exact (sans fast ram bien entendu...)

Et bizarrement j'obtiens :
   - ST : 26,5 secondes
   - Amiga : 36,5 secondes

Etrange cette propension à s'écarter un peu des résultats... Ton WinUAE ne serait pas ralenti par la synchro vbl avec l'affichage du PC ? (le pourcentage cpu ne doit jamais dépasser 100%...).

ça n'est pas "presque 2 fois plus de temps". En fait moins de 40% de temps en plus.

Mais ce n'est pas fini ! Pour que le test soit cohérent, comparons ce qui est affiché dans les 2 cas.

ST :



Et Amiga


Que voit_on ?

 - D'abord le nombre de couleurs : 2 sur ST et 4 sur le mig (je ne compte pas celles du pointeur de souris bien sur...). Le print du ST manipule donc 2 fois moins de données. Mais bon, passons...
 - Le nombre de lignes : 25 sur ST et 29 sur le mig. C'est normal, en PAL le mig utilise des écrans de 256 lignes par défaut. En passant sur un ecran de 200 lignes, le mig met 29,5 secondes (tu peux essayer facilement : il suffit de mettre le mig en NTSC) ! Ah ben tient, ça devient presque la même chose ! Avec 2 fois plus de couleurs !
 - Le pointeur sur ST est ou ? Ben le GFA ne l'affiche que si on bouge la souris. Sauf qu'il le fait très mal : il apparait pendant une vbl de temps en temps. Super ! Et si on bouge la souris pendant le test, et bien le ST met 29,5 secondes !

Mais ça ce n'est rien : sur le mig, le multitache est activé et la fenêtre peut être déplacée, être redimensionnée, prendre ou perdre le focus, etc... De plus l'affichage marcherait sur une carte graphique (ce qui serait vrai pour le GFA aussi s'il passait par le GEM...). Et bien sur le pointeur ne scintille absolument pas !

Donc dans une fenêtre sur le mig, avec 2 fois plus de couleurs, en utilisant les fonctions systemes et en laissant le multitache activé, ça tourne quasiment aussi vite que le ST en 2 couleurs, en affichage direct, et allant jusqu'à oublier le pointeur de souris !  

mais tu vas surement me dire : et sur ST hein, dans une fenêtre... ben tu devrais surtout pas poser la question, en fait c'est déjà trop tard pour toi 


PRINT dans une fenêtre GFA Atari ST :  25,20 secondes !!!!  deux fois plus rapide que le super intuition amiga !

OPENW 1
FULLW #1
FOR I=1 TO 1000
PRINT I
NEXT I   
CLOSEW #1

Là ça devient triste de te voir t'enfoncer comme ça...

Tu as mesuré le temps sans la deuxième ligne, c'est à dire avec une fenêtre minuscule. Tu as ajouté "FULLW #1" pour avoir une fenêtre plein écran comme le mig mais tu n'as pas pensé à refaire la mesure !
Moi je l'ai fait :

1 minutes 21 secondes !!!!!!

Le "super intuition" explose ton GFA !!!!

Mais ce n'est pas tout. Que donne ta fenêtre ?
Ceci :

C'est quoi cette fenêtre ??!!!! Ce n'est pas une fenêtre GEM !!!! C'est une fenêtre gérée par le GFA directement !!! Mais pourquoi avoir fait ça si le GEM est si rapide ??  
Et faut voir ce que le GFA fait pour optimiser l'affichage : quand tu la redimensionnes pour la passer en plein écran, il n'efface même pas les anciens bords ! C'est le défilement qui les fait disparaitre !
Et bien sur pas de pointeur de souris : très pratique si on veut gerer le déplacement de la fenêtre (qu'il faudra faire soi même...) pendant qu'il y a un affichage dedans...

Donc dans une fenêtre gérée par le GFA, avec des prints bien plus rapides que ceux du GEM, ça n'atteint même pas la moitié de vitesse obtenue par intuition (presque le tiers !!!!) avec 2 fois plus de couleurs, une gestion de la fenêtre en temps réel et un multitache activé !!!

En fait, avec une fenêtre GEM, l'écart serait plus grand que ce que j'avais pensé !

Et pour afficher une fenêtre GEM, c'est tout simple, il suffit de faire ça

Code:

ret%= WIND_GET(0,4,rootx%,rooty%,rootw%,rooth%)
handle%=WIND_CREATE(&H2F,30,30,100,100)
titre$="GFA"
ret%=WIND_SET(handle%,2,CARD(SWAP(VARPTR(titre$))),CARD(VARPTR(titre$)),0,0)
ret%=WIND_OPEN(handle%,workx%,worky%,workw%,workh%)

Juste l'ouverture de la fenêtre. Faut encore écrire dedans...
C'est ça votre super GFA ? Qui est soi-disant mieux implémenté dans le ST ? 
Et je ne parle pas de l'editeur de code : une horreur...

Tu te souviens ? Tu avais expliqué qu'il fallait 2 minutes pour lancer le GFA sur le mig. Encore une de tes explications foireuses : tu avais mis la D7 du WB d'abord...
Je t'avais dit qu'en démarrant sur la disquette GFA, ça n'avait rien à voir. Et je t'avais montré que sur mig il était facile de démarrer automatiquement sur le GFA et je t'avais demandé comment faire la même chose sur le ST. Toujours pas de réponse. Normal : c'est une horreur ! Pour une machine hyper conviviale, c'est un parcourt du combattant ! (j'expliquerais une autre fois : y en a qui vont se fendre la gueule...)

Et bien c'est de cette disquette que je suis parti. Du coup, amiga éteint, il faut une cinquantaine de secondes pour lancer le GFA, taper le code test et attendre son execution. 30 secondes de moins que le temps que met le ST pour le test seul dans une fenêtre...  

Et je l'ai mis en vidéo pour que tu vois bien que je ne ment pas :


Je repense à ta première phrase : visiblement c'est toi qui n'a pas de chance...

Alors M. "je me marre", pas de réponse ?

[Invité]

le sample a toujours été l'instrument du "pauvre"

sauf quand le STE fait pareil ? j'ai bon ? 

tu occultes en gros une bonne moitié de la prod musicale moderne. ce qu'il faut pas lire comme conneries ici.

[rocky007]

la plupart des musiques amiga c'est quoi ? des musiques composées avec des instruments samplés ( merci les samplers )... à partir de synthé qui font de la synthèse.

les micros ont délaissé la synthese pourquoi ?  parce que maintenant on a l'espace nécessaire pour stocker des musiques qualité CD...ce n'était pas le cas dans les années 80, où la RAM et les supports était ultra limité.  Pourquoi mettre Paula dans un C64 quand tu n'as que 64ko, soit qq seconds de sample ?   dès l’apparition des CD, plus de problème de stockage, donc on tapait des musiques qualité studio directement sur le disque et basta.

[rocky007]

Alors M. "je me marre", pas de réponse ?

ben si, tu n'as pas vu ??  remontes un peu

[rocky007]

Rocky tes posts deviennent vraiment lourds et insultants !

Personne à part toi n'es venu dire que je racontait n'importe quoi. Par contre plusieurs personnes t'ont fait ce reproche y compris des Stistes.

Donc voilà comment je vais répondre à ton post : j'en ai marre d'essayer de démontrer quoi que ce soit face un dieu du troll pareil...

ça y est, monsieur est coincé alors il boude et fait son fâché.  pourtant je ne fais qu'utiliser tes propres armes : la condescendance avec une touche de foutage de gueule comme seul toi sais le manier.  mais je suis content que tu reconnaisses mon niveau, venant de mon mentor, ça fait plaisir

Mode mochrome meilleur : connerie !

donc explique moi comment tu travailles ta trame sur une image en couleur sur amiga ?

Tu parles du framerate maintenant ? Connerie ! tu peux même pas afficher les images de ces vidéos en fixe : tu mens

photochrome c'est quoi alors ?

Tes explications sur les DAC uniquement avec des resistances : connerie ! T'as pas dit que paula était des résistances + un port parrallele. T'as dit juste des résistances : connerie ! Et ton dessin du AD558 : aucun interet.

tu rage de t'être vautré, et plusieurs fois.. et le pire tu continues à t'enfoncer.  le AD558 fonctionne comme le DAC avec résistances, à partir de 8 bits.  tu disais que c'était pas un vrai DAC, car "incomplet", je t'ai prouvé, une fois de plus, que c'en était un, preuve à l'appui d'un DAC commercial fonctionnant exactement de la même façon.  mais bon, arrêtes là, tu te ridicules..n'importe qui ici tape "DAC resistor" et trouveras des centaines de DAC basés sur des résistances.

je n'ai jamais dit que Paula était un port // + résistance, quelle sacrée manie de toujours inventer des propos que je n'ai pas dit !  Paula aussi se fait envoyer ses datas sur son bus 16 bits...et c'est qui fait le boulot équivalent du port //, ben c'est agnus.

Et ton réseau de resistance : il sont ou les composants qui envoient un signal quand Dx est à 1 et rien quand Dx est à 0 ? Connerie !

  ça coule, ça couuuuule

T'es là a parler de tes résistances dont tout le monde se fout : branche un mig et un ST sur une chaine, ferme là et fais ecouter à 10 personnes prises au hasard. Tu te sentiras seules quand elles te donneront leur avis. Ou alors trouve toi un "resistances Vs transistors"

c'est tout ce que tu as trouvé ? décevant...

Le GEM pas utilisé parce qu'il est pas chargé ? Connerie ! pourquoi est-ce que sur le mig ils ont fait l'effort d'initialiser intuition et n'ont pas initialisé le GEM ?

et oui, tu t'es aussi vautré sur cela...  on s'en fout que le mig le fait ou non, le ST ne le fait pas, point barre, ce n'était pas le sujet : tu pensais qu'on pouvait faire des appels GEM , sans le GEM !

J'ai admis une erreur, sur DAC/ADC (erreur qui ne valide en rien ce que tu prétends avec Paula=resistances). J'aurai pu faire comme toi : ne pas répondre sur ce point.

on a vu que la carte covox, utilisant exactement ce système, te sortait du soundtracker 44Khz...mais bon, la rage t'as non seulement aveuglé, mais aussi bousillé les oreilles

Parce que c'est ta spécialité M. qui glisse des "je me marre", "tu t'enfonces", "tu te débats" entre toutes les phrases :

alors c'est tout ce que tu as sous le coude ?  après avoir demandé à tes petits camarades de te venir en aide parce que tu t'en sortais plus tout seul, maintenant tout ce que tu trouves pour faire diversion c'est de citer toutes mes erreurs sur plusieurs années ? style "ouin c'est pas moi c'est luiiiii" ?   pas très mature tout cela...


je cite, rien que sur tes 2 derniers posts : n&b en 2 bits, appels GEM sans GEM, ADC pour un DAC ( et je te passes toutes les énormités sur le DAC que tu as dites ), print fenêtre plus rapide de print en direct, fenêtre GEM qui est géré par GFA, print fenêtre amiga plus rapide que print fenêtre ST, gestion écran en 2 couleurs lors d'un PRINT sur ST, etc..etc..j'en ai des sueurs et de l'arythmie rien que de les relire

Pourquoi tu ne réponds plus sur "je peux reproduire le niveau de bonus de BTL en precalc avec 600 Ko" ? Je me marre !

tiens c'était pas toi qui disait que ma méthode "débile" ne fonctionnerait jamais, jusqu'au moment où je t'ai prouvé le contraire ?

Tiens une dernière : quelqu'un de ce forum a fait une démo sur le mig uniquement avec des appels systèmes. Tu lui as expliqué que c'était possible sur ST via des appels systèmes aussi.

beuh ? aucune souvenir de cela...

enfin je te vois traumatisé, je suppose donc que le resto est annulé ? 

[cryodav76]

c'est fou comme la musique sur le SID donne mieux que sur l'amiga

tu peu opposé n'importe quel machine a l'amiga pour essayer de dire que c'est moins bien que le st,
du pc a la megadrive en passant pas les ordi jap etc mais alors utiliser le c64 fallait oser

[Urbinou]

donc explique moi comment tu travailles ta trame sur une image en couleur sur amiga ?

Ce n'est pas à l'utilisateur de tramer. Tu importes une image avec les meilleures infos possibles dans ton document. A un niveau domestique, c'est ensuite ton imprimante qui décide comment mélanger ses couleurs ou comment tramer son noir selon la qualité et le papier choisis. A un niveau pro, les metteurs en page travaillent avec des versions basse-def des images à l'écran, et on importe les hautes déf au moment du "ripping", càd l'envoi du fichier optimisé pour la machine concernée (presse numérique, direct-to-plate, ou photocompo si ça existe encore).
Le but est donc bien d'offrir à l'utilisateur un wysi quasiment wyg, un maximum de couleurs/niveaux de gris à l'écran est donc un plus, cqfd.