Re: GUERRE ST-AMIGA, FIGHT !!!

[babsimov]

paula et sid, le duo gagnant.

Quel est le point commun entre les deux ?

Réponse : Des ingénieurs qui se sont d'abord fait plaisir en concevant leur puce avant de penser à faire quelque chose de commercial.

[drfloyd]

et donc Atari a gagné la guerre MEME SANS LE PROJET SIERRA ! C'est dire.....

[babsimov]

et donc Atari a gagné la guerre MEME SANS LE PROJET SIERRA ! C'est dire.....

Toujours le révisionnisme chronique... comme je l'ai dit, ce sont les ex ingénieurs Atari qui gagnent et haut la main, tant pour l'Amiga que pour le projet SIERRA, ou encore la gamme XL.

En tout cas, ça me navre de voir la façon dont ici on balaye d'un revers de la main un projet tel que SIERRA, sans même reconnaître que techniquement c'était bien plus abouti qu'un ST. 

J'en reviens pas comme certains Atariste ont les yeux fermés parfois ! 

Comment on peut raisonnablement préférer qu'Atari ait sortit le ST à la place de SIERRA ???? Ca me sidère !

J'ai peut être eu tord de prendre, au premier abord, cette réponse au sérieux en fait. Il faut que je sois plus vigilant à l'avenir en lisant ici.

[babsimov]

Un article très intéressant sur le projet SIERRA chez Atari et raconter par un des ingénieurs qui ont participé au projet. Il est fait mention de l'Amiga aussi. Il semble que finalement au niveau graphique l'Amiga était mieux. C'est ce qu'il dit.

http://www.alternatehistory.com/discussion/showpost.php?p=7232140&postcount=189

Je n'ai pas encore tout lu, mais le peu que j'ai lu est passionnant. Ca semble tiré d'un livre qui s'appel : 

From Quarters to Bullets: The Real Story of Atari, by Steve Mayer


Je pense que ça pourrais intéresser les lecteurs du forum.


CORRECTION : C'EST UN ARTICLE FICTION EN TRES GRANDE PARTIE

EDIT : Ils avaient conçu une puce son qui incluait PAULA et AMY, ce qui permettait d'avoir de la musique samplé et une synthèse vocale de grande qualité ! La puce s'appelait PAMELA !


"Jed and Frank Pullian from Coin Op argued strenuously that we should go with the AMY chip (for speech synthesizer purposes) and I argued back just as vociferously that we should use PAULA (for music, which is the backbone of any good game). It was Bill Mensch who came up with the idea to combine the two.[10] He hacked out the stupid I/O stuff and grafted on AMY’s cheap oscillators, and came up with a new sound chip, codenamed PAMELA, that could handle both music and voice. I’m getting ahead of myself here, but I think it’s no exaggeration to say that PAMELA is probably the biggest Atari success that you’ve never heard of; we used versions of it in all of our computers up until 1995![11] Even today, I can call up Bill and say “You got your peanut butter in my chocolate!” and get him to laugh and reminisce about the design for PAMELA."


Rien que ça démontre que les ex-ingénieurs Atari évoluaient à un autre niveau que ceux qui ont conçu le ST !

Du coup, j'aurais préféré que Commodore rachète ATARI et AMIGA tiens... comme ça on aurait eu, en plus des DENISE et AGNUS... PAMELA...

EDIT 2 : Ils voulaient faire une version 65816 à 7 mhz du 800XL (avec un chipset amélioré et un coprocesseur mathématique. A cette vitesse un 65816 aurait été 4 fois plus rapide qu'un 68000 à 7 mhz... c'est vraiment intéressant de lire tout ça.

[rocky007]

je poste un petit hors sujet : un membre du forum m'avait contacté il y a qq mois à propos de ma collection Atari.  Je ne retrouve plus son pseudo vu que le mail date de plusieurs mois.

Ce message est pour lui, ainsi que pour tout personne intéressée : j'ai toujours ma collection complète ( +- 4000 disquettes Atari ), et miracle, j'ai retrouvé le listing d'un grosse partie de son contenu  ( 7000 références ), si qq'un recherche un programme qui n'est pas présent sur le net, il y a un chance que je le possède encore.

[rocky007]

1) Tu te plains d'avoir du chercher l'icone sur lequel cliquer : C'est de la faute de l'OS si les gars de GFA ont mis le même icone ? Rien ne les empechait de mettre un icone particulier pour l'exe..

Sur ST, tu différencies toujours l'icone d'un programme et le reste, quoiqu'il arrive.  +1 Atari

3) Tu te plains d'avoir du chercher l'icone sur lequel cliquer : Tu n'as pas remarqué que tu pouvais cliquer sur n'importe lequel ? Ben oui : ça lance le GFA et ça charge le source sur lequel tu as cliqué. Y a pas de truc comme ça sur ST ?

oui mais si je veux lancer le GFA SANS l'obliger à charger un source dont je n'ai pas besoin et perdre encore plus de temps ?  

Tu parles de 45 secondes. Mais tu oublies de dire que tu as laissé les lecteurs en fast : tous les chargements sont immédiats !
Pour booter avec un desktop.inf (pour arriver sur un bureau en moyenne résolution), il faut 10 secondes au ST

Tu pourrais nous donner le temps total sans tricher ? On dépasse largement la minute non ?

pas du tout, j'ai testé le boot d'un desktop.inf à l'instant sur un vrai ST, c'est immédiat.  je prépare une vidéo sur un vrai ST.
( et sincèrement j'ai pas triché, j'ai démarrer Steem dans sa config par défaut, je suis pas habitué, désolé si il y a une option cachée, à voir le clignotement du "lecteur" lors du chargement du GFA, cela me paraissait vitesse réelle.

Et ça donne 1 minute 5 secondes. Tu peux les jeter tes 4 minutes. Et le doc qui a du avoir une erection en voyant tes vidéos va pouvoir se calmer...

et tout ce que tu as fait, c'était à la portée du mec qui vient de s'acheter un amiga ?  non, le mec normal, il boot sa disquette workbench, et puis mets sa disquette GFA basic, et là, l'horreur se produit.

La preuve en est, que nous avons ici des super spécialistes de l'amiga et aucun n'a bronché sur ma vidéo à part toi, ce qui veut dire que le commun des utilisateurs Amiga ne savent pas préparer une disquette optimisée pour un boot plus rapide tellement c'est complexe.

dans ta vidéo, je comprends pas, le répertoire du contenu de ta disquette GFA se charge super vite, alors que chez moi c'est lent à mourir, comment cela se fait-il ?

[rocky007]

J'ai une autre théorie concernant le fait qu'Atari n'ait pas utilisé Pokey à la place du YM2149.
Attention, cela n'engage que moi.

un autre raison serait la honte pour Atari d'utiliser un chip qui a été utilisé dans son 8 bit, pour sa nouvelle gamme semi-pro 16 bit.

concernant l' AMY, c'est très dommage qu'il n'existe pas un seule vidéo de ses capacités.  On trouve les devkit, le chip se trouve sur des prototypes, mais malheureusement rien en réel.  Il parait qu'il y avait une démo impressionante avec un chanteur d'opéra.

[dlfrsilver]

pas du tout, techniquement l' Amiga n'est pas assez puissant pour simuler complétement un YM2149 ( et c'est vrai   )... donc ils ont dû downgrader la musique pour Enchanted Land.

bon c'est un peu hors sujet, mais quand même le pokey...

Ah oui l'Amiga pas assez puissant pour émuler un YM2149 ? Tu permets, je me cale sur ma chaise, et là j'éclate de rire

Tu connais les jeux Rod-land, Ninja warriors, silkworm et Saint Dragon sur Amiga, mhhh ?

Est-ce que tu as une idée de la manière dont la musique est jouée ?

Non, normal, je le savais pas moi-même avant d'avoir une petite discussion avec Mr Pieket Weeserik, le programmeur de Storm/sales curves.

Qui m'a expliqué la chose suivante :

L'amiga possède 4 voix, mais il voulait reproduire la musique des machines d'arcade de façon fidèle. Il a donc mis au point un logiciel synthétiseur FM. Grâce à lui, il a composé la musique des jeux dont j'ai cité le nom plus haut.

Particularité, aptitude à jouer de la musique FM sur 8 voix, et donc l'idée sous-jacente qui il a eu était de permettre la reproduction de la musique des puces YM2151 de yamaha et ses 8 voix, avec en plus les digitalisations sonores (et dans ces jeux, je pense à NW).

alors quand tu dis que l'amiga ne peut pas émuler un YM2149, à part te rire au nez, je sais pas trop en fait

Le YM2149 est bien plus simple qu'un YM2151 à émuler, c'est 3 misérables voix, y a rien de compliqué. Et même mieux certains jeux transcodés du ST sortent du son YM2149 émulé via paula.

Aucun prestige et aucune difficulté à faire ça, faut juste que le programmeur sache utiliser correctement Paula.

Je ne sais pas si c'est du troll de pauvre ou pas, mais si c'est trollé c'est du troll de luxe

[babsimov]

J'ai une autre théorie concernant le fait qu'Atari n'ait pas utilisé Pokey à la place du YM2149.
Attention, cela n'engage que moi.

un autre raison serait la honte pour Atari d'utiliser un chip qui a été utilisé dans son 8 bit, pour sa nouvelle gamme semi-pro 16 bit.

Parce que c'était pas une honte d'utiliser le YM2149 qui venait aussi du 8 bit et était moins bon que POKEY ?

Je ne suis pas le seul à le penser si j'en juge par ce sujet sur un forum Atari anglais :

http://www.atari-forum.com/viewtopic.php?t=10594&start=200

concernant l' AMY, c'est très dommage qu'il n'existe pas un seule vidéo de ses capacités.  On trouve les devkit, le chip se trouve sur des prototypes, mais malheureusement rien en réel.  Il parait qu'il y avait une démo impressionante avec un chanteur d'opéra.

J'en ais entendu parler de cette démo de chanteur d'opéra. Il semble que le concepteur d'AMY était un passionné de synthèse vocale et qu'il avait étudié toutes les puces de synthèses vocales existante à l'époque pour intégrer les meilleures technologies dans un seul composant. 
Selon ce que j'avais lu, la démo passait en temps réel du champ d'un homme à celui d'une femme et c'était d'une très grande qualité.

[babsimov]

Des vidéo de la GUI du 1200XL à base de 65816 à 7.16mhz.











Et un petit commentaire au sujet de la puce PAMELA (PAULA et AMY ensemble) :

 "Using 1984 technology, the PAMELA chip would be inexpensive (~$20 per unit) and – given enough secondary RAM – would essentially outperform everything IOTL until Creative Labs’s Sound Blaster Live! DSP – which came out in 1998."




PAMELA a été conçu par Bill Mensch, qui faisait partie de l'équipe à la base du 6502.


EDIT : j'ai un doute sur l'article, si j'en juge par la réponse à ce sujet :
http://atariage.com/forums/topic/220281-from-quarters-to-bullets-the-real-story-of-atari/

Enfin, j'espère que PAMELA existait vraiment. Car la partie qui parle de SIERRA parait quand même bien documentée. Ou alors l'auteur est doué.

A un moment il cite Optimized System Sofware et cette société semble bien avoir existé à l'époque :
https://en.wikipedia.org/wiki/Optimized_Systems_Software

EDIT 2 :

Mais, en lisant un peu mieux, je pense que PAMELA et une bonne partie de l'article sont des inventions. Dommage, ça m'avait bien fait rêver.

Par contre l'info qu'il cite sur AMY est exacte :

"This is OTL’s AMY chip! (Atari really is a fascinating company.) It was completely built in 1983 and lost during the sale to Jack Tramiel. By the time it was rediscovered and integrated into a planned Atari computer (the 65XEM), the 8-bit market was nearly dead and Atari had shifted its focus to its ST line of computers. AMY was then sold to Sight & Sound of Milwaukee, who built a MIDI synthesizer around it, but Atari sued Sight & Sound before they could ship any product. And so AMY was lost to history."

[rocky007]

Je ne sais pas si c'est du troll de pauvre ou pas, mais si c'est trollé c'est du troll de luxe

t'as encore raté une occasion de te taire.  même sur PC, il n'y a aucun player YM2149 qui est fidèle à 100% au chip original..
alors j'ose pas imaginer un Amiga.  Oui il fera un truc qui sonnera +- comme un YM2149 pour du chiptune simple de base, mais certainement pas le chiptune avec les effets avancés ( comme le Sync Buzzer )

[rocky007]

Des vidéo de la GUI du 1200XL à base de 65816 à 7.16mhz.

c'est incroyable qu'un XL a un OS multitâche plus beau et plus complet que le Workbench.

[dlfrsilver]

Je ne sais pas si c'est du troll de pauvre ou pas, mais si c'est trollé c'est du troll de luxe

t'as encore raté une occasion de te taire.  même sur PC, il n'y a aucun player YM2149 qui est fidèle à 100% au chip original..
alors j'ose pas imaginer un Amiga.  Oui il fera un truc qui sonnera +- comme un YM2149 pour du chiptune simple de base, mais certainement pas le chiptune avec les effets avancés ( comme le Sync Buzzer )

Pas besoin d'être à 100% fidèle. Les jeux utilisant une émulation du son YM2149 font un rendu très fidèle grâce à Paula. Tu jurerais jouer sur un atari ST

PS : Exxos a déclaré aujourd'hui avoir répliqué le problème de corruption avec une disquette protégée en écriture, et après avoir fait des tests, c'est lié à ce putain de système DMA à la con dont est équipé le ST :

je traduis son post en français :

"Mieux vaut tard que jamais sur ce sujet - Pendant que je testais des lecteurs de disquettes pour des gens aujourd'hui, j'ai réussi à corrompre le contenu d'une disquette en essayant simplement de booter depuis la disquette. Le "lecteur fautif" a réussi à corrompre la disquette lui-même apparemment, même si ces dernières étaient protégées en écriture.

J'ai eu à reformater ma disquette de test pour la 6ème fois à présent, un autre lecteur fonctionne correctement, ce lecteur que je teste la tout de suite, essaie de lire la disquette, quelque fois je peux voir des fichiers, mais en gros il ne fait que la corrompre. Donc à chaque fois que j'essaie de démarrer à partir de la disquette, elle finit par se corrompre apparemment. Et oui, la disquette est protégée en écriture chaque fois qu'elle va dans le ST. Ce qui veut dire que "protéger en écriture" les disquettes (avec le taquet) ne protège pas la disquette entièrement, en tout cas pas avec des lecteurs "incertains".

Il a posté ensuite ceci dans son topic principal:

"J'ai testé des lecteurs de disquettes pour des gens aujourd'hui et découvert plus de problèmes liés aux lecteurs de disquettes..

Les lecteurs que je teste sont des EPSON 380. Ce qu'il semble se produire est qu'ils ne fonctionnent qu'en mettant une petite pression sur la tête de lecture du dessus. Donc soit les têtes ont vieilli et le voltage devient trop faible pour lire la disquette, ou le "ressort" en métal sur lequel la tête est montée, se déforme et incline légèrement la tête de la surface de la disquette. J'ai même monté et abaissé le rail de 5V juste pour voir si ça aide, mais ça n'a rien donné. J'ai passé un petit moment avant d'essayer de résoudre ce problème de tête, mais il ne semble y avoir aucun ajustement possible, que ce soit mécanique ou lié au circuit. Jusqu'à il y a récemment je blamais le lecteur de disquette lui-même, mais ce n'est pas toujours le cas. Bien entendu, nettoyer les têtes de lecture aide beaucoup et devrait être obligatoire ces jours-ci.

Quoi qu'il en soit, on dirait de prime abord que le lecteur est déglingué, mais c'est en réalité un autre problème DMA. J'ai essayé un STE avec un DMA -38 qui fonctionnait bien autrement, j'ai abandonné sur celui-là, alors j'ai branché une de mes machines de test STFM (IMP DMA, incidentallement le 5V possède une diode sur la pin 40 du DMA, j'ai vu ça aussi sur les MEGA, bizarre) et j'ai eu exactement le même problème de lecteur de disquette..

Là j'ai essayé un autre EPSON 380 et ce lecteur fonctionnait parfaitement. Alors j'ai essayé l'autre, et a échoué à lire de manière fiable. J'ai fais des allers et retour pendant presque 2 heures avec ça, et à chaque fois j'aurais eu tendance à conclure que le lecteur de disquette est en panne. MAIS..

Je viens de mettre 10K de "pull ups" sur le bus de données DMA, et ce lecteur "en panne" a juste chargé correctment ECOPY et formaté correctement une disquette. Avant j'avais la chance d'arriver jusqu'au bureau GEM et d'ouvrir la fenêtre du lecteur A:. Donc c'est encore des problèmes DMA

Donc à ce point là, j'en suis amené à chaudement recommander à tout ceux qui possèdent un STFM avec une puce DMA IMP ou -38 de mettre des "pull ups" sur les lignes de données DMA. Je me suis pas encore penché sur le "nouveau DMA 001A", comme suggéré auparavant, ça semble mieux marcher des "pull downs", donc ce sont des problèmes similaires, mais le "Fix" est différent. Je dois absolument me pencher la dessus plus en profondeur..

Ces problèmes DMA commencent sérieusement à devenir chiant "

Donc clairement, ça prouve que :

1) j'avais raison, tu pouvais me traiter de con, mais au final c'est moi qui disait la vérité !
2) Vous êtes tellement bouchés sur Atari ST dans l'ensemble, que même quand il y a un problème grave, vous vous en tapez !
3) Il se pourrait que ce soit une forme de suicide hardware des atari ST.

Ce qui m'amène à ce petit théatre belge :

D: "Y a un sérieux problème sur ces machines, faut faire quelque chose"

R: "Nannn, t'es un mytho, le hardware du ST, il est bô, il est puissant, taggle!"

D: "Hé ho Jeannot !! Les ST s'auto-détruisent !!! Ouhou allo la terre ici Bruxelles ! "

R: "C'est pô vraihinnnn, l'amigô l'ôna plein des bugs hardware, alors pouvez fermer vos grandes buuuches ! "

D: "C'est quand même étrange, t'es le premier à défendre l'atari ST, et quand on te met sous le nez un vrai problème, et pas un simple en plus, t'es dans le déni."

R: "Naannn, c'est pas vrai, jeu prend pô de droguehiiinnn, l'atari ST il est tu bô, tu puissant, il a la frite  !!!"

D: "Ces ataristes ont décidément toujours la frite, mais comme l'huile, irrécupérables "

Bref, même moi qui ait une préférence pour l'amiga, ce problème sur le ST (STF et STE + STFM), m'interpelle, mais toi non, t'en as rien à fouttre, même si ça signifie que les atari disparaitront encore plus vite.

Et la source de tout ce bordel est malheureusement aussi ce que je disais plus haut :

L'extrêmement basse qualité des composants utilisés dans les Atari. C'est ça la source véritable du problème.

Car sache-le Rocky, si Exxos au terme de ces tests s'aperçoit que le problème vient des condos des alims, qui en se vidant (via un gros leak !) flingue + ou - la puce DMA en lui enfilant une surdose de courant dans la gueule,
ça veut dire que les Atari ST deviendront au final ce qu'ils étaient vraiment au départ : de la quicaillerie de mauvaise facture.

Tu peux le prendre de travers, je m'en tape, mais moins au moi je regarde les problèmes en face, et je fais pas ma jeune fille dans le déni comme c'est ton cas

[stapha92]

Babsimov, 

Concernant tes questions sur une architecture AGA digne de ce nom : 

Oui, il aurait fallu augmenter le nombre de DAC pour avoir plus de canaux et/ou passer en 16 bits. Je voulais dire qu'avec une fréquence doublée et un passage du chipset en 32 bits, tout le chipset aurait été 4 fois plus rapide. Du coup Paula aurait pu passer à 16 canaux 8 bits ou 8 canaux 16 bits. 

Pour le chunky : Ajouter à Denise cette fonctionnalité aurait obligé à adapter le blitter pour qu'il puisse gérer ce mode efficacement (Par exemple : appliquer une transparence lors de la copie d'un objet graphique ne se fait pas de la même façon). Et ce n'est pas le pire : il aurait fallu adapter l'OS. Et c'est un sacré boulot. 
Par contre dans cette optique, un blitter 4 fois plus rapide aurait pu s'occuper de faire la C2P sans surcout processeur. Il aurait été facile d'ajouter des fonctions de qui s'en occuperait dans l'OS. Dans l'ideal, le blitter aurait pu être amélioré pour intégrer cette fonction : là il aurait fait une C2P 256 couleurs en 1/5 de frame. 
N'oublions pas non plus qu'avec un cpu rapide, une c2p n'a aucun surcout avec un Amiga AGA d'aujourd'hui. Donc le chunky n'était pas le problème : c'est bien la faiblesse du cpu qui l'était. 
Un DSP était bien. Mais à choisir, je préfère un 68040/60 seul à un 68020+DSP. En tenant compte du coup d'implémentation, ça ne devait pas être plus cher. Quand à l'exploitation : un 68040 accélère toutes les applis Amiga, pas un DSP... 
Et pour les processeurs qui suivirent, c'est pire : ils intègrent des amélioration qui rendent les DSP obsolètes (Altivec, SSE, 3DNow...). 


Pour ta question sur le 14 bits et Paula : 

Si tu veux disposer de 2 canaux 14 bits, c'est totalement gratuit ! Alors, comment ça marche ? 

Pour que tous les interessés comprennent : 
Le 8 bits permet d'échantilloner un son en attribuant une valeur parmi 256 à chaque sample qui compose le son. (2 puissance 8) 
Le 14 bits permet d'avoir 16384 valeurs différentes (2 puissance 14). Soit 64 fois plus. 
Mais ça ne veut pas dire que la courbe aura une amplitude 64 fois plus élevée ! (ça se traduirait par un son 64 fois plus fort). 
ça veut dire qu'entre 2 valeurs qui étaient possible en 8 bits, on trouvera 64 valeurs possibles supplémentaire. 

Pour illustrer : il faut imaginer une pente que l'on tranfsorme en escalier : La pente est le son original (analogique) et l'escalier le son numérisé. 
Supposons qu'en 8 bits, chaque marche fasse 64 cm. Et bien en 14 bits, chaque marche fera 1 cm. Entre 2 marches, le passage en 14 bits aura permit d'en insérer 64. 
l'escalier sera beaucoup plus ressemblant à la pente : le son numérisé sera plus proche du son original. 

Revenons au mig. Chaque canal dispose d'un volume qui lui est propre et qui va de 0 à 64. à 0 le volume est coupé. A 1 le volume est 64 fois moins fort qu'à 64. 
En mettant le volume d'un canal à 1, on dispose donc des fameuses 64 valeurs intérmédiaires dont je parlais (Pour reprendre l'analogie, les marches feront 1 cm). 
Problème : l'amplitude de notre courbe est également 64 fois plus petite (normal, puisque le son est 64 fois moins fort)... 

Comment faire ? C'est simple : on va jouer notre son en utilisant 2 canaux : on met le volume du premier à 64 et le volume du second à 1. Les 2 volumes vont d'additioner et voilà ! 

la seule contrainte est la façon de stocker les samples. Au lieu de stocker les 14 bits ensembles au sein de mots qui se suivent pour former le sample, ll faudra les stocker sous forme de 2 samples : l'un contiendra tous les 8 bits de poids forts (ceux de gauche) au seins d'octets qui se suivront. L'autre contiendra les 6 bits de poids faible. 
Bien sur, la méthode de stockage n'entraine aucun surcout processeur. 

Du coup, on ne dispose plus que de 2 canaux. Mais c'est totalement gratuit pour le 68000. 



Au fait babsimov, si l'affichage d'un répertoire est lent, ce n'est pas parce que le lecteur est lent.
 
C'est le filesystem (OFS) qui est lent car il ne possède pas de FAT. Commodore a privilégié la sécurité à la rapidité. Le filesystem du mig permet beaucoup plus de récupération que celui du DOS (qui est celui utilisé par le ST). Une disquette abimée pouvait être récupéré par diskdoctor avec un taux de réussite beaucoup plus élevé que le DOS. 

Suffit de formater une disquette en ffs et tout s'accélère : ce système allie la sécurité de l'ancien tout en accélérant grandement les accès disque. Mais il faut un KS 1.3 associé à un patch (bof... sauf pour ceux qui ont un HD) ou un KS 2.0. Evidemment, les éditeurs fournissaient leur disquette en OFS pour qu'elle soit compatible avec les amiga < 2.0
Tu peux même formater une disquette en DOS et tu verras que ça va aussi vite qu'un ST pour afficher son contenu (Idem : il faut crossdos ou un KS 2.0) 

la capacité à utiliser plusieurs filesystem en même temps est encore un point innovant pour le mig (et comme souvent, devenu une constante aujourd'hui...), il y en a eu plusieurs conçus pour le mig (OFS, FFS, Professional file system, Ami file system) dont un avec journalisation (Smart file system) et, bien sur, le mig pouvait gérer les file system d'autres plate-formes...

[stapha92]

@stapha92 tu as des exemples concrets d'utilisation detournée de paula (emul SID, synthese FM, tracker avec features spéciales, etc...) dans ce cas paula gère le truc tout seul ou il tire quand même sur le cpu pour sortir un son?

Alors hélas, je n'y connais rien en synthèse FM. Ce que je peux dire néanmoins, c'est que :

 - Paula ne sait jouer que des samples. Mais ces samples peuvent être créés avec le CPU. Très facile de générer un signal sinusoidal, carré, en triangle, etc...
 
 Après il faut appliquer des effets sur ce signal de départ. Maintenant seul un spécialiste de ce genre de manipulation pourrait répondre sur le cout cpu. Il y a surement moyen de préparer des tables d'effets pour accélerer le traitement. Je pense que le plus gros problème viendra des filtres dont le fonctionnement dépend de la fréquence : autant il est facile de le faire électroniquement, autant le faire de façon software est très couteux : il faut faire une transformée de fourrier. C'est largement hors de portée d'un 68000 en temps réel. 

 - Paula peut utiliser un canal pour moduler le volume et/ou la fréquence d'un autre canal. Il fait donc de la FM (modulation de la fréquence) et de l'AM (modulation d'amplitude, c'est à dire du volume). Mais je ne saurai pas te dire si cela est utilisé ou non... 

 Désolé de ne pouvoir te répondre plus précisément.

[stapha92]

"1985: il achète un ST, machine la plus avancée du moment. Il s'éclate plusieurs années"
"1989: l'écart se creuse avec les versions Amiga. Moqué par tous ses amis pour ses inferior, il se frustre, ne veut plus entendre parler des 16/32 bits et achète un PC 1512. Il est heureux, il y retrouve des scrollings en bloc, et des musiques abominables".
C'est une tranche de vie qui marque ça, il faut vite une psychanalyse! Après on s'étonne qu'il y en ait autant qui se soient extasiés devant le manoir de Morteville en CGA, ou devant Wing Commander sur des machines à 10 000F... Ils ont loupé tout un pan de l'histoire micro, ptet le meilleur!

[stapha92]

J'avais lu quelques échanges là-dessus sur des forums Amiga. En revanche je ne sais pas si des tests ont été fait concrètement. Sais-tu s'il existe des exemples audios, sans aller jusqu'à 1,76 Mhz, qui dépassent au moins la limite des 28Khz (en dehors de l'utilisation des modes videos 31Khz, dble PAL et autres) ?

Non, je ne connais pas d'exemple. Mais ça ne veut pas dire qu'il n'y en a pas : je ne maitrise vraiment pas ce qui est sorti sur ce point... 
 Il devrait y en avoir : sur mig ça ne coute pas très cher de jouer un sample en 50 khz : On lance Paula en 50 khz, on laisse le DMA l'alimenter en 25 Khz et le cpu (ou le copper) fera le reste. Comme le buffer de Paula contient 2 samples pour chaque canal, le CPU ne traitera que du 12,5 Khz. Et vu qu'il n'y a qu'une instruction assembleur, ça ne prendra pas beaucoup de cpu.

[stapha92]

stapha92 a écrit:
1) Tu te plains d'avoir du chercher l'icone sur lequel cliquer : C'est de la faute de l'OS si les gars de GFA ont mis le même icone ? Rien ne les empechait de mettre un icone particulier pour l'exe..

Sur ST, tu différencies toujours l'icone d'un programme et le reste, quoiqu'il arrive.  +1 Atari

N'oublie pas que le GFA est un produit ST : pas de la faute de l'OS si l'éditeur a fait des betises lors du portage... 
Rien ne l'empechait de mettre un icone différent pour le GFA. Ou de mettre les exemples dans un repertoire comme je l'ai fait.
 
Sur ST, tu différencies l'icone du programme mais... Et s'il y a plusieurs programmes, comme sur ta disquette ? 

Tu as vu l'aspect de la fenêtre GFA sur ST ? 
        Pleins de fichiers disposés aléatoirement, plusieurs exe, donc plusieurs fois le même icone. Obligation de faire défiler le contenu pour trouver l'icone du GFA. Toi même tu as failli cliquer sur un autre exe... 
        
Et tu as vu ma version sur le mig ? 
        3 icones différents. 2 pour les executable en haut et un pour le répertoire d'exemples en bas. Clair, simple. Les fichiers qui ne servent à rien n'apparaissent pas inutilement. Même en masquant les noms on pourrait s'y retrouver. Une fenêtre bien dimensionnée et positionnée dès qu'on l'ouvre.

Désolé mais montre ça à quelqu'un qui ne connait aucune des 2 machines et tu verras ce qu'il préfère... 

D'ailleurs, qu'en est-il des OS d'aujourd'hui ? 
        - Obligent-ils à afficher tous les fichier ? Non, comme le mig et contrairement au ST 
        - Possèdent-ils des icones personnalisés ? Oui, comme le mig et contrairement au ST 
        - Peuvent-ils être disposés librement et leur position sauvegardée ? Oui, comme le mig et contrairement au ST 
        - La taille et la position de la fenêtre peut elle être mémorisée ? Oui, comme le mig et contrairement au ST 
        
C'est sur : le ST est tellement convivial qu'aujourd'hui on utilise un système plus proche de celui du mig ! Alors que les possesseurs d'ordinateurs d'aujourd'hui sont beaucoup moins spécialisés, etant donné qu'aujourd'hui tout le monde possède un micro...

3) Tu te plains d'avoir du chercher l'icone sur lequel cliquer : Tu n'as pas remarqué que tu pouvais cliquer sur n'importe lequel ? Ben oui : ça lance le GFA et ça charge le source sur lequel tu as cliqué. Y a pas de truc comme ça sur ST ?

oui mais si je veux lancer le GFA SANS l'obliger à charger un source dont je n'ai pas besoin et perdre encore plus de temps ?  

Et bien tu te réfère à ma réponse 2 que tu n'as pas conservée : Tu lances le premier icone en haut à gauche. Et ce n'est pas un hasard qu'il soit là.

Ta disquette ne contient pas d'exemples : si la disquette du mig était identique, tu ne verrais qu'un seul icone. On peut faire plus simple ? NON.

Et la faculté de lancer un programme GFA aussi simplement est un avantage : tu fais une appli et tu n'as pas de compilateur. Il te suffit de mettre ton source sur une disquette avec le GFA et l'utilisateur de ton appli n'aura qu'à cliquer sur l'icone de ton source pour la lancer. Et tu pourras t'arranger pour que ce soit le seul icone et que même le GFA soit invisible.
Bon, tu peux aussi rendre ton programme bootable : il suffit de lancer le GFA avec le nom de ton source comme paramètre. Aucun problème avec une startupsequence. Avec un repertoire AUTORUN, c'est plus compliqué. Est-ce seulement faisable ? Hmmm....

Evidemment, avec un compilo y aura pas de pb.

Tu parles de 45 secondes. Mais tu oublies de dire que tu as laissé les lecteurs en fast : tous les chargements sont immédiats !
Pour booter avec un desktop.inf (pour arriver sur un bureau en moyenne résolution), il faut 10 secondes au ST

Tu pourrais nous donner le temps total sans tricher ? On dépasse largement la minute non ?

pas du tout, j'ai testé le boot d'un desktop.inf à l'instant sur un vrai ST, c'est immédiat.  je prépare une vidéo sur un vrai ST.
( et sincèrement j'ai pas triché, j'ai démarrer Steem dans sa config par défaut, je suis pas habitué, désolé si il y a une option cachée, à voir le clignotement du "lecteur" lors du chargement du GFA, cela me paraissait vitesse réelle.

Désolé je croyais que tu l'avais fait exprès par jeu : tu as laissé l'image du début ou l'on voit le réglage des lecteurs. 
Je n'ai pas voulu te traiter de tricheur. C'était pour rentrer dans le jeu. 

J'espère qu'aucun lecteur n'a pris ça au premier degré. Pour que ce soit clair : Un tricheur aurait caché l'image du début. Preuve que ce ne pouvait être qu'un jeu ou involontaire. 

Encore désolé... 

Bon tu es d'accord pour dire que ça va durer plus de 45 secondes. Et vu que le mig est à 1 min 05, l'écart sera minime ou inexistant. On va bien voir. 

Et ça donne 1 minute 5 secondes. Tu peux les jeter tes 4 minutes. Et le doc qui a du avoir une erection en voyant tes vidéos va pouvoir se calmer...

et tout ce que tu as fait, c'était à la portée du mec qui vient de s'acheter un amiga ?  non, le mec normal, il boot sa disquette workbench, et puis mets sa disquette GFA basic, et là, l'horreur se produit.

La preuve en est, que nous avons ici des super spécialistes de l'amiga et aucun n'a bronché sur ma vidéo à part toi, ce qui veut dire que le commun des utilisateurs Amiga ne savent pas préparer une disquette optimisée pour un boot plus rapide tellement c'est complexe. 

Euh... Non pas du tout. C'est la même chose que pour toutes les applications mig : tu mets ta disquette GFA et tu allumes l'ordi (dans cet ordre ou l'autre : le mig ne met pas plusieurs minutes à booter quand il n'y a pas de disquette...). 
16 secondes après tu te retrouves dans le Workbench. C'est pas plus compliqué. JE N'AI RIEN FAIT QUI CHANGE LE BOOT.

Et dlfrsilver t'avait dit de booter sur la disquette GFA

Essaie et tu verras. le WB apparait très vite. 

Quand je parlais de modifier la startupsequence. C'était pour l'hypothèse d'un utilisateur qui souhaiterait que le programme soit lancé automatiquement. Je me suis dit que quelqu'un qui utilisait régulièrement le GFA devait être capable d'ajouter une ligne dans un fichier texte... 
En tout cas, ça serait plus facile à faire que ce qui est nécessaire pour un lancement auto sur un ST... 
Au fait je l'ai fait : 21 secondes pour être dans l'editeur du GFA à peine.

Pour faire comme moi, voilà ce qu'il faut faire : 
        1) Supprimer les fichier exemples du GFA (et ça ira plus vite que dans ma vidéo) ou créer un répertoire et les déplacer dedans. Dans les 2 cas, ça se fait entièrement à la souris. 
        2) Copier Redit depuis la disquette Fred Fish qui va bien. Et encore, cette partie n'est là que pour notre petit jeu sans interet. Un utilisateur qui venait de s'acheter un mig se serait arreté à la première étape et il aurait 1 seul icone dans la fenêtre ! 

Et c'est tout ! Je n'ai rien fait d'autres ! 

dans ta vidéo, je comprends pas, le répertoire du contenu de ta disquette GFA se charge super vite, alors que chez moi c'est lent à mourir, comment cela se fait-il ?

Je ne sais pas. Version du Kickstart ? Dans ma vidéo c'est lent aussi.

La différence c'est qu'il n'affiche rien tant qu'il n'a pas fini le chargement. Tandis que dans la tienne, il affiche les fichiers au fur et à mesure qu'il les trouve. 
Et il y a les exemples qui ne sont plus là mais dans un réperoire. ça fait ça de moins à lire. Mais c'est equitable : y a pas d'exemples dans la version ST.

[stapha92]

pres avoir lu tout ca. c'est maintenant clair :le ST provoque la sénilité prématurément et fait vivre le le malade dans une realité alternative.  le patient se croit toujours en 1989 on peut aussi parler d'anachronisme perpétuel. les cas les plus atteints peuvent souffrir de crises d'angoisses nocturnes et se reveiller la nuit en hurlant "KICK OFF".

Celle là est trop forte !!!!

[Invité]

6 posts à la suite, ça s'arrange pas.

[Invité]

pres avoir lu tout ca. c'est maintenant clair :le ST provoque la sénilité prématurément et fait vivre le le malade dans une realité alternative.  le patient se croit toujours en 1989 on peut aussi parler d'anachronisme perpétuel. les cas les plus atteints peuvent souffrir de crises d'angoisses nocturnes et se reveiller la nuit en hurlant "KICK OFF".

Elle est pas mal celle là 

[Invité]

Juste un petit temps mort dans la guerre ..

Une demo PC (qui date,2001) de 64 ko faite par chaos, l'inventeur du rotozoom:


C'est énorme d'arriver à un truc pareil avec seulement 64ko ..

[babsimov]

Des vidéo de la GUI du 1200XL à base de 65816 à 7.16mhz.

c'est incroyable qu'un XL a un OS multitâche plus beau et plus complet que le Workbench.

Je vois que tu désarmes jamais ! Malgré que je t'ai dit que souhaitais faire une pause sur AmigaOS... 

Bon, puisqu'il faut te répondre, première observation, les goûts et les couleurs, comme on dit... 
Tiens justement, en parlant de couleur, le Workbench lui est en couleur (en haute résolution). Je préfère infiniment un bureau avec des couleurs à un bureau en noir et blanc comme sur le ST (en haute résolution). Mais, chacun ses goûts et tu as le droit de préférer le monochrome.

Deuxièmement, personnellement je dirais plutôt que ça devrait t'interpeller qu'un XL ait un OS multitâche plus beau que ne l'est le GEM. En plus avec des icones ayant des graphismes personnalisés pour chaque disquette. D'ailleurs, il fait furieusement penser à un copier coller du finder du MAC. En tout cas ça aurait été bien plus intéressant qu'un ST tout ça...

Tiens, pour te répondre, j'ai voulu vérifier l'apparence du GEM et devine sur quoi je tombe :

Une vidéo d'un 520ST+ de 1986 :



Tu trouve pas que c'est moche par rapport aux icones du XL ? Et t'as vu les icones floppy disk sont les mêmes pour les deux... 

Mais, ce n'est pas le plus intéressant. Ca se passe à 6 minutes dans la vidéo. Après un reboot, il charge une disquette et hop une bombe qui impose un reset... je croyais qu'un ST de 1985, il plantait pas... on m'aurait menti... en tout cas, un ST+ de 1986 il plante.
Ah, et j'oubliais, c'est toi qui me vantait la synthèse vocale du ST... ben c'est quand même pas terrible au début de la video du ST+. En plus c'est la version 2.0 du logiciel de synthèse vocale, il y a même pas l'excuse de dire que c'est la version 1.0 !

Ecoutons parler l'Amiga :



Et d'ailleurs, même un C64 fait mieux que le ST en synthèse vocale...



Heureusement que je ne me suis pas pris un ST à l'époque, quelle déception cette machine aurais été pour moi lorsque j'aurais enfin pu découvrir un Amiga (son pourri, synthèse vocale pourrie, graphisme limité, OS d'un autre age)... 

Et voilà, alors que j'étais tranquillement en pause, tu as réussi à me faire déraper... Allez, laisse moi retourner en pause sur l'AmigaOS, parce qu'on a déjà tout dit la dessus.

Que ça te plaise ou non, les ex-ingénieurs Atari construisaient des ordinateurs 8 bits et 16 bits bien mieux que les ex-ingénieurs de Commodore ne l'ont fait. La gamme XL tient la route face au C64 (pourtant plus récent) et l'Amiga surclasse en tout le ST (hormis le prix).

Puis je retourner en pause s'il te plait ?

EDIT : j'ai quand même, malgré tout voulu voir ce que donne un XL en synthèse vocale... c'est, là aussi meilleur qu'un ST... alors que la puce son date de 1979... ça confirme mon opinion sur Jay Miner.

J'ai trouvé deux programmes différents :



Et un second :

[babsimov]

rocky007]

Et ça donne 1 minute 5 secondes. Tu peux les jeter tes 4 minutes. Et le doc qui a du avoir une erection en voyant tes vidéos va pouvoir se calmer...

et tout ce que tu as fait, c'était à la portée du mec qui vient de s'acheter un amiga ?  non, le mec normal, il boot sa disquette workbench, et puis mets sa disquette GFA basic, et là, l'horreur se produit.

La preuve en est, que nous avons ici des super spécialistes de l'amiga et aucun n'a bronché sur ma vidéo à part toi, ce qui veut dire que le commun des utilisateurs Amiga ne savent pas préparer une disquette optimisée pour un boot plus rapide tellement c'est complexe.

dans ta vidéo, je comprends pas, le répertoire du contenu de ta disquette GFA se charge super vite, alors que chez moi c'est lent à mourir, comment cela se fait-il ?

Je me suis souvenu que j'avais lu cette remarque de ta part, après avoir répondu sur la GUI du XL.

Donc, tout d'abord, le coup de faire une disquette unique avec le GFA, le Workbench et notepad, contrairement à ce que tu dis, je te l'avais suggéré. Donc pas bronché, pas sur.

Attention, je ne prétend nullement être un super spécialiste de l'Amiga. Je n'étais qu'un utilisateur lambda qui s'intéressait à son ordinateur pour autre chose que jouer. J'ai un peu essayé l'AmigaBasic, mais c'est tout. J'avais acheté avec mon Amiga, le livre de l'AmigaDOS, le livre de l'AmigaBasic. Après j'ai vu que l'AmigaBasic c'était pas aussi rapide que ce je pensais et que pour faire ce que j'ambitionnais, j'avais pas le niveau. Car, en fait, j'étais fan de Galactica (1978) et je révais en 1988 de faire un jeu avec des décollages comme les viper, atterissages, combats, le tout avec une histoire épique... bref ce que fut plus tard WingCommander. Je n'avais clairement pas le niveau pour ça. 
Tu comprends donc pourquoi Wing Commander, à l'époque m'a fait lorgner du coté du PC. 

Bref, cette longue parenthèse pour te dire que, de toute façon si un Amigaïste commence à vouloir se lancer dans la programmation (même la base), il est forcément capable de se créer lui même sa disquette bootable car :

1 - Il s'est intéressé au fonctionnement de l'AmigaOS et donc de son DOS
2 - Il à les rudiments des scripts
3 - Il sait formater/copier/dupliquer les logiciels pour placer ce qu'il veut sur sa disquette personnalisée.

Donc ton argument du "mec normal" s'applique plus à celui qui ne fait que jouer sur un Amiga. Dès qu'on commence à vouloir programmer, surtout avec autre chose que l'AmigaBasic (qui était fournis avec l'Amiga) on entre dans la catégorie des "connaisseurs" au moins un minimum.

Ah et autre observation concernant le GFA version Amiga. Ta vidéo m'avait déjà mis la puce à l'oreille, mais celle de Stapha92 l'a confirmé.



A 36 secondes, il ouvre une boite de dialogue pour enregistrer son fichier. Cette boite de dialogue est bien une boite AmigaDOS.
A 56 secondes, il ouvre une boite de dialogue similaire dans le GFA... y a rien qui te parait différent ? 
Tout simplement cette boite n'a rien en commun avec une boite AmigaDOS... ce qui accrédite le transcodage pur et simple du code du ST sur Amiga, y compris dans l'interface des boites de dialogue qui ne font pas appel à intuition, semble t il.
Porter un langage de programmation du ST vers l'Amiga sans respecter (ou au stricte minimum) l'interface de l'AmigaDOS, j'appel ça du bâclage pur et simple. 
Ca laisse songeur sur le fait que les instructions du GFA version Amiga tirent partit des copros ? 
Ca me fait penser à l'AmigaBasic qui était un portage honteux du basic du MAC et qui n'utilisait pas les copros de l'Amiga. 
Tiens pour la démo musicale de l'AmigaBasic (pourtant impressionnante pour l'époque), le listing était remplis de poke pour taper directement dans Paula... Tu crois pas que le minimum aurait été d'avoir une commande de type "play" ou "sound" ou quelque chose comme ça, avec, par exemple ensuite les paramètres concernant le son à jouer ? 
J'ai quand même l'impression que pour le portage du GFA sur Amiga, ils se sont pas foulés.

Je comprends pourquoi AMOS a eut plus de succès ensuite. Là au moins, il y avait des commandes qui tiraient partit des copros. Et, hasard, n'ais je pas mis un lien, quelques pages auparavant, d'une interview de son auteur qui disait qu'il avait préféré l'Amiga et qu'il n'aimait pas le GEM sur ST... Il a donc fait l'effort de tirer parti de tout ce que l'Amiga offrait en plus.

Mais, j'avais dis que je voulais pas revenir sur ce débat... tu auras réussi à me faire digresser ce soir :)

Suis je autorisé à reprendre ma pause ?

[Seb]

Juste un petit temps mort dans la guerre ..

Une demo PC (qui date,2001) de 64 ko faite par chaos, l'inventeur du rotozoom:


C'est énorme d'arriver à un truc pareil avec seulement 64ko ..

C'est sans importance mais dans un soucis d'exactitude, il y a eu 2 rotozooms sur Atari ST avant la Word Of Commodore (sortie fin 1992). Chaos est souvent présenté à tort comme l'inventeur du rotozoom (ca n'enlève rien à ses qualités de coder):

Le rotozoom de Gigabyte Crew dans la Syntax Terror (Decembre 1990)


L'intro de Delta Force pour Maggie 10 (Juillet 1992)



Quant à la 64k de Farbrausch, elle n'existerait pas sans le packer de Ryg et le softsynth de Kb, c'est important de les mentionner car le packer et la synthèse audio sont une énorme partie du travail sur une 64k, Chaos n'a pas fait tout 

[babsimov]

Babsimov, 

Concernant tes questions sur une architecture AGA digne de ce nom : 

Oui, il aurait fallu augmenter le nombre de DAC pour avoir plus de canaux et/ou passer en 16 bits. Je voulais dire qu'avec une fréquence doublée et un passage du chipset en 32 bits, tout le chipset aurait été 4 fois plus rapide. Du coup Paula aurait pu passer à 16 canaux 8 bits ou 8 canaux 16 bits. 

Pour le chunky : Ajouter à Denise cette fonctionnalité aurait obligé à adapter le blitter pour qu'il puisse gérer ce mode efficacement (Par exemple : appliquer une transparence lors de la copie d'un objet graphique ne se fait pas de la même façon). Et ce n'est pas le pire : il aurait fallu adapter l'OS. Et c'est un sacré boulot. 
Par contre dans cette optique, un blitter 4 fois plus rapide aurait pu s'occuper de faire la C2P sans surcout processeur. Il aurait été facile d'ajouter des fonctions de qui s'en occuperait dans l'OS. Dans l'ideal, le blitter aurait pu être amélioré pour intégrer cette fonction : là il aurait fait une C2P 256 couleurs en 1/5 de frame. 
N'oublions pas non plus qu'avec un cpu rapide, une c2p n'a aucun surcout avec un Amiga AGA d'aujourd'hui. Donc le chunky n'était pas le problème : c'est bien la faiblesse du cpu qui l'était. 
Un DSP était bien. Mais à choisir, je préfère un 68040/60 seul à un 68020+DSP. En tenant compte du coup d'implémentation, ça ne devait pas être plus cher. Quand à l'exploitation : un 68040 accélère toutes les applis Amiga, pas un DSP... 
Et pour les processeurs qui suivirent, c'est pire : ils intègrent des amélioration qui rendent les DSP obsolètes (Altivec, SSE, 3DNow...).

Merci Stapha92 pour tes réponses, toujours aussi intéressantes. 

Je ne m'étais donc pas trompé, il fallait augmenter le nombre de canaux audio en hardware dans une hypothétique Paula 8 voix 16 bits. Je comprends mieux ta réponse d'origine comme ça. 
C'est vrai qu'avoir une Paula 4 fois plus rapide avec 8 voix 16 bit ou 16 voix 8 bits aurait été un must.

Concernant le Chunky, c'est intéressant ton idée de faire un C2P avec le blitter (planar) 4 fois plus rapide. 
Mais, en fait, le passage au Chunky je le voyais surtout pour tout ce qui était au delà de 256 couleurs. Ce qu'on appel les modes high color ou true color, soit 16 bit ou 24 bits. 
Il me semblait avoir lu, qu'à partir de ce type de modes, le planar est loin d'être idéal et que le Chunky prend un gros avantage en terme de vitesse d'affichage.
D'ailleurs le AAA avait un blitter Planar et Chunky, ce qui veut dire que c'était faisable techniquement. Il avait même un mode hybride, à la fois Planar et Chunky. Il semble d'ailleurs que ce mode était le plus intéressant de tous.
Si tu trouves un peu de temps pour étudier ça, ton avis serait certainement des plus intéressant.
Voici des liens vers des informations sur le AAA :
http://obligement.free.fr/articles/aaa.php
https://en.wikipedia.org/wiki/Amiga_Advanced_Architecture_chipset

Et surtout ici, toute la documentation sur le AAA, le 3000+, le DSP3210 (bref les prototypes), fournies par Dave Haynie en personne :
http://www.thule.no/haynie/

Il y a notamment un PDF de présentation du AAA datant de 1993 et qui entre dans les détails, notamment vitesse affichage etc.. Je pense que tu devrais apprécier sa lecture :
http://www.thule.no/haynie/research/nyx/docs/AAA.pdf

En ce qui concerne l'adaptation du workbench en chunky, c'était également prévu avec le RTG à terme.

Le DSP, je l'ai attendu longtemps... D'après ce qu'en dis Dave Haynie dans le 3000+ c'était vraiment excellent, bien au dessus du DSP du Next et Falcon. Il aurait eut son propre OS qui tournait en multitache avec AmigaOS et la puissance de calcul était dix fois celle d'un 68040 (en simple précision si j'ai bien compris). Bref, il aurait pu faire bien autre chose que du son (il parlait de vidéo).

http://www.thule.no/haynie/research/dsp3210/docs/notes.pdf
http://www.thule.no/haynie/research/dsp3210/docs/medeng.pdf
http://www.thule.no/haynie/research/a3000p/docs/a3000p.pdf 

Pour Altivec etc... je suis d'accord, mais en 1991 (date du 3000+) avoir eut un DSP + 68030/040 aurait remis l'Amiga au top hardware. Et qui sait ce que les codeurs aurait pu tirer d'un DSP en multitache avec le chipset Amiga. Au minimum, le 3000+ n'avait que l'AGA, le DSP apportait déjà le son 16 bit sur 8 voix qui pouvait être mixé avec les 4 voix de Paula (pour les effet sonores d'un jeux par exemple).
Et ce que dit Dave Haynie, c'est que le 3000+ n'aurait pas coûté plus cher à produire qu'un 3000 ECS de base... donc un prix de vente en 1991 dans les 17000 frs à comparer aux presque 24000 fr d'un 4000, un an plus tard, sans le DSP, sans controleur SCSI. 
Et c'est sans parler du 1000+ prévu, lui aussi pour 1991, avec un boitier de type 1000, un disque dur, 2 mo de chip, 2 mo de fast, un 68EC020 à 25 ou 28 mhz (peut être même un 680EC030 à 25 mhz) ainsi que deux port Zorro III en interne (pour recevoir une probable carte DSP)... et tout ça pour 800 $ (8000 frs). A comparer au prix d'un 1200 (sans fast, avec un processeur à 14 mhz et sans slot Zorro) à 3790 frs à sa sortie et auquel il fallait rajouter un disque dur (1500 fr minimum), soit un total de 5290 frs. Franchement j'aurais préféré mettre 8000 frs et avoir une machine à laquelle il ne fallait rien rajouter pour en tirer le maximum. D'autant plus que les logiciels auraient, du coup été dimensionnés, dès le départ, pour une machine à disque dur en standard, 4 MO et 25 mhz.

Mais, je m'excuse d'avoir dérivé un peu par rapport à ta réponse. 

EDIT : Peut être que cette discussion là serait plus à sa place sur le sujet officiel de l'Amiga ?

Pour ta question sur le 14 bits et Paula : 

Si tu veux disposer de 2 canaux 14 bits, c'est totalement gratuit ! Alors, comment ça marche ? 

Pour que tous les interessés comprennent : 
Le 8 bits permet d'échantilloner un son en attribuant une valeur parmi 256 à chaque sample qui compose le son. (2 puissance 8) 
Le 14 bits permet d'avoir 16384 valeurs différentes (2 puissance 14). Soit 64 fois plus. 
Mais ça ne veut pas dire que la courbe aura une amplitude 64 fois plus élevée ! (ça se traduirait par un son 64 fois plus fort). 
ça veut dire qu'entre 2 valeurs qui étaient possible en 8 bits, on trouvera 64 valeurs possibles supplémentaire. 

Pour illustrer : il faut imaginer une pente que l'on tranfsorme en escalier : La pente est le son original (analogique) et l'escalier le son numérisé. 
Supposons qu'en 8 bits, chaque marche fasse 64 cm. Et bien en 14 bits, chaque marche fera 1 cm. Entre 2 marches, le passage en 14 bits aura permit d'en insérer 64. 
l'escalier sera beaucoup plus ressemblant à la pente : le son numérisé sera plus proche du son original. 

Revenons au mig. Chaque canal dispose d'un volume qui lui est propre et qui va de 0 à 64. à 0 le volume est coupé. A 1 le volume est 64 fois moins fort qu'à 64. 
En mettant le volume d'un canal à 1, on dispose donc des fameuses 64 valeurs intérmédiaires dont je parlais (Pour reprendre l'analogie, les marches feront 1 cm). 
Problème : l'amplitude de notre courbe est également 64 fois plus petite (normal, puisque le son est 64 fois moins fort)... 

Comment faire ? C'est simple : on va jouer notre son en utilisant 2 canaux : on met le volume du premier à 64 et le volume du second à 1. Les 2 volumes vont d'additioner et voilà ! 

la seule contrainte est la façon de stocker les samples. Au lieu de stocker les 14 bits ensembles au sein de mots qui se suivent pour former le sample, ll faudra les stocker sous forme de 2 samples : l'un contiendra tous les 8 bits de poids forts (ceux de gauche) au seins d'octets qui se suivront. L'autre contiendra les 6 bits de poids faible. 
Bien sur, la méthode de stockage n'entraine aucun surcout processeur. 

Du coup, on ne dispose plus que de 2 canaux. Mais c'est totalement gratuit pour le 68000.

Donc, avoir du 14 bits c'est gratuit, je n'en étais pas certain, mais tu le confirmes. Y a pas à dire, le chipset Amiga était bien pensé. Même si je suppose que cette astuce n'avait pas été anticipée à la conception.

Ah, j'oubliais, ton explication est claire, j'apprécie vraiment ta façon d'expliquer à chaque fois.

Au fait babsimov, si l'affichage d'un répertoire est lent, ce n'est pas parce que le lecteur est lent.
 
C'est le filesystem (OFS) qui est lent car il ne possède pas de FAT. Commodore a privilégié la sécurité à la rapidité. Le filesystem du mig permet beaucoup plus de récupération que celui du DOS (qui est celui utilisé par le ST). Une disquette abimée pouvait être récupéré par diskdoctor avec un taux de réussite beaucoup plus élevé que le DOS. 

Suffit de formater une disquette en ffs et tout s'accélère : ce système allie la sécurité de l'ancien tout en accélérant grandement les accès disque. Mais il faut un KS 1.3 associé à un patch (bof... sauf pour ceux qui ont un HD) ou un KS 2.0. Evidemment, les éditeurs fournissaient leur disquette en OFS pour qu'elle soit compatible avec les amiga < 2.0
Tu peux même formater une disquette en DOS et tu verras que ça va aussi vite qu'un ST pour afficher son contenu (Idem : il faut crossdos ou un KS 2.0) 

la capacité à utiliser plusieurs filesystem en même temps est encore un point innovant pour le mig (et comme souvent, devenu une constante aujourd'hui...), il y en a eu plusieurs conçus pour le mig (OFS, FFS, Professional file system, Ami file system) dont un avec journalisation (Smart file system) et, bien sur, le mig pouvait gérer les file system d'autres plate-formes...

Oui, je savais que c'était le filesystem qui était lent, pas le lecteur. C'est juste que je ne m'en suis pas souvenu sur le moment quand j'ai répondu un peu vite. 
Mais, sur ce coup là, Rocky007 n'a pas tout à fait tord. Il me semble me souvenir que le FFS était réservé aux disques dur (mais pas certain). Je pense me souvenir qu'il avait été introduit avec le 1.3 (peut être seulement pour les disque dur justement). A partir du 2.0 les disquettes peuvent l'utiliser en standard.
Je me souviens qu'il y a eu aussi, peut être un peu après, une variante qui améliorait la vitesse de lecture des médias, pour peu qu'ils soient formatés en FFS Directory Cache. Par contre, je ne me souviens pas si le système Directory Cache a été introduit avec le 1.3 ou à partir du 2.0. Je m'en souviens par contre très bien sur le 3.0. 

J'ai trouvé ça :
https://en.wikipedia.org/wiki/Amiga_Fast_File_System

Dans le texte on peut lire :
"Amiga FFS is simple and efficient, and when introduced was more than adequate, and had many advantages compared to the file systems of other platforms."


EDIT : la réponse à dlfrsilver m'a fait me souvenir que je voulais confirmer pour la capacité de l'AmigaOS à gérer de manière transparente les filesystem d'autres OS (ainsi que divers filesystem conçu pour lui).

[dlfrsilver]

L'OFS est lié à l'A500 avec Wb1.3, tandis que le FFS est lié aux A500+/600 avec wb 2.04/5

[babsimov]

L'OFS est lié à l'A500 avec Wb1.3, tandis que le FFS est lié aux A500+/600 avec wb 2.04/5

Pas d'accord, le FFS, comme c'est indiqué dans le wikipédia a été introduit avec le 1.3, mais c'était pour les disques durs principalement (en tout cas, mon A590 est arrivé préinstallé avec en FFS). 
C'est pour les disquettes que j'ai un doute sur mon Amiga 500 (me souviens plus).

[dlfrsilver]

L'OFS signifie Original File System. C'est ce système de fichier qui est installé quand tu formattes une disquette sur amiga 500.

Les disques dur c'est autre chose.

Le FFS sur disquette c'est à partir du wb 2.0X sur A500+/600

[Invité]

D: "Y a un sérieux problème sur ces machines, faut faire quelque chose"

R: "Nannn, t'es un mytho, le hardware du ST, il est bô, il est puissant, taggle!"

D: "Hé ho Jeannot !! Les ST s'auto-détruisent !!! Ouhou allo la terre ici Bruxelles ! "

R: "C'est pô vraihinnnn, l'amigô l'ôna plein des bugs hardware, alors pouvez fermer vos grandes buuuches ! "

D: "C'est quand même étrange, t'es le premier à défendre l'atari ST, et quand on te met sous le nez un vrai problème, et pas un simple en plus, t'es dans le déni."

R: "Naannn, c'est pas vrai, jeu prend pô de droguehiiinnn, l'atari ST il est tu bô, tu puissant, il a la frite  !!!"

D: "Ces ataristes ont décidément toujours la frite, mais comme l'huile, irrécupérables "

je me tape des barres a chaque rois que je relis. t'es un grand malade

[dlfrsilver]

D: "Y a un sérieux problème sur ces machines, faut faire quelque chose"

R: "Nannn, t'es un mytho, le hardware du ST, il est bô, il est puissant, taggle!"

D: "Hé ho Jeannot !! Les ST s'auto-détruisent !!! Ouhou allo la terre ici Bruxelles ! "

R: "C'est pô vraihinnnn, l'amigô l'ôna plein des bugs hardware, alors pouvez fermer vos grandes buuuches ! "

D: "C'est quand même étrange, t'es le premier à défendre l'atari ST, et quand on te met sous le nez un vrai problème, et pas un simple en plus, t'es dans le déni."

R: "Naannn, c'est pas vrai, jeu prend pô de droguehiiinnn, l'atari ST il est tu bô, tu puissant, il a la frite  !!!"

D: "Ces ataristes ont décidément toujours la frite, mais comme l'huile, irrécupérables "

je me tape des barres a chaque rois que je relis. t'es un grand malade

Mais tu t'es jamais demandé si on était pas là aussi pour s'en taper des barres ?

Moi ça m'éclate de présenter ça comme ça façon petit théâtre de Bouvard

Et puis je te fais marrer, et ça, ça n'a pas de prix