Re: AMIGA * TOPIC OFFICIEL*

[babsimov]

Sur Falcon tu as un affichage Chunky 16bit. Même si le DSP avait accès la la chip RAM sur Amiga, il aurait fallu qu'il remplace le blitter pour rafraichir les 8 bitplans à chaque pixel en 3D... Et ça aurait été limité à 256 couleurs. Le DSP oui, mais avec un mode chunky 16bit. Sinon, ça fait de la 3D moche.

EDIT:
De plus, un code optimisé avec les connaissances d'aujourd'hui pour ne tirer que 1/8 de VBL, soit entre 6 et 7 fps, c'est juste une blague.
Personne ne se serait lancé dans un tel projet qui aurait forcément permis de faire moins bien, vu que ce genre n'existait simplement pas.

Bien sur que le chunky 16 bit du Falcon lui apporte un avantage supplémentaire. Mais, on peut imaginer le DSP qui utilise (et rend fluide) le mode HAM6/HAM8. 

La majorité des jeux 3D texturés au début des années 90 sont en 320x200 256 couleurs sur PC et on trouvait ça très bien. Donc je suis un peu surpris de ta remarque. Surtout qu'un peu plus tôt tu disais que l'AGA en 90 aurait permis d'avoir les jeux 256 couleurs du PC.

Pour l'optimisation, Team17 et autres ont cherché à créer un moteur 3D pour les shoot 3D toujours plus optimisé, justement parce qu'il y avait une demande pour ce type de jeux. Donc j'imagine bien au contraire que tous auraient cherché à exploiter toutes les astuces permises par Blitter+Copper+DSP. Je pense que tu sous estime la communauté Amiga de l'époque. Bien sur ce ne serait pas apparu tout de suite et parfait dès le début, mais je pense que ce serait apparu dans la vie commerciale de cette génération de machines.

EDIT 2:
Idem pour les players MP3 et tout ce que tu présentes qui est totalement anachronique.
Je me demande même si Commodore n'a pas mis de DSP uniquement parce qu'ils n'en voyaient pas d'usage concret.

Le lecteur MP3 n'est pas si anachronique que ça, il me semble avoir lu dans le sujet Falcon qu'il est apparu peu de temps après que le format MP3 s'est répandu. Forcément qu'il n'aurait pas existé en 1990, mais ce que je voulais mettre en avant c'est qu'avoir un DSP en standard donnait à la machine une longueur d'avance pour le future par rapport au reste. C'est ce qu'avait l'Amiga à sa sortie en 1985, on peut difficilement dire que ce fut le cas avec l'ECS ou l'AGA. Comme je l'ai dit l'AGA n'a apporté que des limitations à l'Amiga au fil des années, parce que déjà obsolète lors de sa conception. Mais je me répètes 

Concernant le DSP et Commodore, Dave Haynie l'a expliqué en long et en large. Le 3000+ et 1000+ ont été annulés parce que la nouvelle direction tenait absolument à faire passer les projets de la direction précédente comme stupides et inutiles (on a vu laquelle à eu les décisions les plus stupides, à commencer par le 600). 

Au contraire, le successeur de cette direction prévoyait que même l'entrée de gamme après l'AGA aurait un DSP en standard. Je te l'ai déjà dit, Jeff Porter (le créateur du 500) et Dave Haynie (celui du 2000 et 3000) ont conjointement décidé d'ajouter un DSP à l'AGA. Admettons que tu es des reproches à faire à Dave Haynie, en tout cas Jeff Porter a montré qu'il a su produire l'Amiga qui a permis à la plateforme de décoller (le 500).

Des détails fournis par Dave Haynie lui même quand il a vendu sa carte mère de 3000+ (carte mère vide).

http://eab.abime.net/showthread.php?p=1016463

"The other new feature in the A3000+ was a DSP subsystem. In late 1990, Jeff Porter and I took a trip out to AT&T in Bethlehem, PA. They had this new DSP chip, the AT&T DSP3210, that they were selling as a replacement for a whole board of electronics. We didn't want it for that -- we wanted it for a general purpose signal computing engine. They had an OS, called VCOS/VCAS, which was kind of a perfect match to interface to AmigaOS, which would have allowed multitasking of DSP work, something you didn't get with the typical DSP of the day. The DSP3210 could do some floating point operations (single precision only) ten times faster than the 68040. So anyway, the A3000+ had this chip -- which lived in the system as a bus master, sharing all of memory with the CPU slot processor -- and as well, two audio CODECs. One was for modem projects, a lower bitrate mono CODEC with phase correction, and the other was a 16-bit, CD-quality audio CODEC, for high quality audio I/O... the DSP would have been able to give us at least eight channels of playback at full CD quality."


Je maintiens donc que supprimer le DSP en complément de l'AGA fut la plus grosse bévue de cette nouvelle direction (par pure stupidité). Une décision pire que le 600, car le 600 a fait perdre beaucoup d'argent à Commodore, mais la décision de virer le DSP et de mettre de côté l'AGA a fait perdre une année entière à Commodore pour au final proposer deux machines AGA moins performantes que les machines AGA qui étaient en préparation début 91 !!! Et aussi de l'argent naturellement puisque le développement du 3000+ 1000+ et de toutes les autres version intermédiaires jusqu'au 4000/1200 ont coûté surement cher à Commodore alors que la société n'en avait déjà plus les moyens.  

Sans parler qu'en plus cette direction n'a pas produit assez de composant AGA pour éviter une pénurie de 1200 à Noël 92 (même chose au lancement de la CD32), mais par contre à produit à la même période trop de 600 (ECS) dont plus personne ne voulait parce que le 1200 était sortit !!! Ils ont du brader le 600 ensuite !!!

Je sais plus ou j'avais lu que Dave Haynie disait qu'à l'époque il disait que son chat aurait mieux dirigé Commodore que cette équipe là... Faut croire qu'il avait pas tord 

[TotOOntHeMooN]

Un DSP ce n'est pas un chapeau de magie. Hormis s'il est spécialement conçu pour afficher plus vite les bitplans (ce dont je doute vu que la direction de Jay Minner était plutôt d'utiliser un blitter par bitplan), aucun DSP du marché n'aurait correspondu à cet usage et autant ajouter un mode chunky.

En suite, ce que je veux mettre en avant c'est que toutes les applications montrées plus haut n'existaient pas. 
Donc, tu fais quoi concrètement avec un DSP entre 1985 et 1990 ? ^^

[Zarnal]

Je vais refaire mon lourd sur ce point mais je ne peux pas laisser écrire que les jeux bourrins sont difficilement faisables en AGA.

2 exemples OCS à la VBL qui parlent d'eux même :






Pour T2 c'est loin d'un contra spirits, mais nous ne sommes pas sur console.
Le problème est qu'à l'époque, grâce aux éloges de la presse entre autres beaucoup se sont persuadés que le 1200 pouvait faire aussi bien qu'une console. Cette légende urbaine persiste encore.

Plus fort encore avec le recul, lorsque je lis que Banshee peut se comparer à une borne d'arcade.

L'amiga a une tonne de bons jeux pas forcément techniques mais cela reste un micro.

Les budgets et les équipes attachés ne sont pas les mêmes non plus.

[babsimov]

Un DSP ce n'est pas un chapeau de magie. Hormis s'il est spécialement conçu pour afficher plus vite les bitplans (ce dont je doute vu que la direction de Jay Minner était plutôt d'utiliser un blitter par bitplan), aucun DSP du marché n'aurait correspondu à cet usage et autant ajouter un mode chunky.

De toute façon le mode chunky n'a jamais été au programme pour l'AGA, donc ils ne l'auraient pas ajouté en enlevant le DSP (la preuve ils ne l'ont pas fait dans la réalité).

Je ne sais pas ce que le DSP 3210 aurait réellement permis de faire, mais je suis certain qu'il aurait apporté un plus non négligeable à l'Amiga et que pleins d'astuces et utilisation inattendues auraient été imaginées et réalisées. Comme un moteur de jeu fluide en HAM6/HAM8 peut être. Après tout ca a été fait avec un 68060, on peut imaginer que le DSP aurait pu servir à la place du 68060.

Le blitter par plan du chipset Ranger ce n'est pas vraiment une certitude non plus, personne n'a vu ce chipset, hormis peut être certains de l'équipe originale, mais leurs informations sont contradictoires. Jay Miner n'était d'ailleurs plus impliqué dans les chipset Amiga à partir de 87/88 je crois.

En suite, ce que je veux mettre en avant c'est que toutes les applications montrées plus haut n'existaient pas. 
Donc, tu fais quoi concrètement avec un DSP entre 1985 et 1990 ? ^^

On parlait de DSP avec l'AGA non ? Ces applications c'est pour montrer ce qu'il est possible de tirer d'un DSP, peut importe l'époque, comme je t'ai expliqué c'est pas la faute du Falcon si cela a été fait assez tard. Mais je suis sur que tu avais compris   

Le DSP dans l'Amiga en 1985, c'est une information non confirmée et provenant d'une source que je pense peu fiable. Je n'ai pas retrouvé d'autre mention de cette information et je ne me souviens plus sur quel site j'avais trouvé ça. C'était une interview, mais laquelle ? En plus comme je te l'ais dit, j'ai l'impression qu'en fait le DSP 56000 n'existait pas au moment de la mise au point de l'Amiga. A moins qu'en fait la personne de l'interview ait confondu avec Ranger et que Jay Miner pensait ajouter un DSP avec son chipset de seconde génération ? Où même que j'ai mal interprété ou compris les propos rapportés.

Qu'aurait on fait d'un DSP entre 1985 et 1990, au minimum du son et un modem, mais j'imagine que les programmeurs auraient trouvé pleins de chose à faire avec. Je pense vraiment que tu sous estime la créativité de cette époque, sans vouloir t'offenser. Par contre ça aurait surement augmenté de façon importante le prix d'un éventuel Amiga équipé.

ZarnalJe vais refaire mon lourd sur ce point mais je ne peux pas laisser écrire que les jeux bourrins sont difficilement faisables en AGA.

2 exemples OCS à la VBL qui parlent d'eux même :

Je te trouve pas du tout lourd. Tu as légitimement le droit de poser la question sur les réelles capacités de l'AGA et sur le fait qu'il a peut-être (probablement ?) été sous exploité au final.

Le test d'Alien Breed dit bien que dans la partie action du jeu, c'est en 128 couleurs, alors qu'en fixe c'est 256 couleurs. Certes c'est un peu faible pour tirer des conclusions sur les capacités "arcade" de l'AGA, mais ça fait quand même s'interroger (déjà à l'époque pour moi). C'était aussi le premier jeu AGA de Team17 (super stardust AGA il est en combien de couleurs ?).

En tout cas, j'étais bien content de chaque jeu AGA qui sortait, même s'il ne m'intéressait pas, et j'avoue qu'à l'époque je pensais que l'AGA, comme l'OCS en son temps allait en remontrer aux autres plateformes. Je pense que là par contre je me trompais quand même lourdement.

Je ne demande qu'à être épaté un jour par l'AGA, voir un truc inimaginable dessus. J'ai lu dans un autre forum qu'il y aurait peut être encore de quoi nous épater avec l'AGA. Pourquoi pas après tout.

En tout une chose est sure, l'AGA au dessus de 320x200, en 256 couleurs c'est inutilisable au quotidien et ça je doute qu'une astuce puisse le changer. Même déjà en 128 couleurs en haute résolution c'est pas ça.

[TotOOntHeMooN]

On parlait d''AGA en 1990. Tu as étendu la discution à un DSP dès la création de l'Amiga. J'indique juste que le DSP n'aurait rien apporté de concret hormis une machine encore plus exotique. Ca ne correspond pas au marché des années 90, même si ça laisse rêveur... Et les rêves qui se concrétisent sur Falcon datent eux des années 2000...

[babsimov]

On parlait d''AGA en 1990. Tu as étendu la discution à un DSP dès la création de l'Amiga. J'indique juste que le DSP n'aurait rien apporté hormis une machine encore plus exotique. Ca ne correspond pas au marché des années 90, mais si ça laisse rêveur... 
Et les rêves qui se concrétisent sur Falcon datent eux des années 2000...

C'est le propre de toutes discussions une chose en amène une autre 

Là ou je suis pas d'accord c'est quand tu dis que le DSP n'aurait rien apporté de plus. Mais on tombera pas d'accord.

Comme pour le marché des années 90. Forcément que dans notre réalité avec les Amiga que nous ont sortit Commodore (ECS et AGA), la plateforme accusait son retard. Donc c'est logique que la machine n'ait eut en majorité que des portages de jeux PC qui avaient pris l'avantage en terme d'affichage (couleurs, affichage chunky et résolution).

On ne peut que présumer de ce qui serait arrivé si l'Amiga avait gardé un avantage technique d'une façon ou d'une autre, à minima un AGA en 1990 avec un DSP, mais pour moi un AGA en 1987 face au VGA, un AA+ fin 1989 avec DSP (pour le haut de gamme), et 1990 AA+ pour l'entrée de gamme avec option DSP, puis en 93/94 Hombre + DSP plus rapide. Là l'Amiga aurait eu encore un avantage technique face aux PC de l'époque et aurait pu rester la plateforme sur laquelle les jeux étaient développés en premier, puis porté sur le reste. 

Si on reste sur l'hypothèse AGA en 1990 (sans DSP), ça n'aurait pas changé grand chose, l'AGA était déjà obsolète. Les cartes VGA/SVGA de 1990 faisaient mieux en haute résolution. Franchement être incapable d'afficher 256 couleurs en 640x512 sans que ça rame lamentablement, ça aurait déjà pas fait sérieux en 1990 alors en 1992 c'était honteux. Bien sur à l'époque on était content de l'AGA parce qu'il y avait enfin plus de couleurs, on attendait ça depuis 1985 quand même ! 

C'est pas pour autant que je regrette la génération AGA, c'est celle que j'ai eu le plus longtemps, plus que mon 500. Et, comme je l'ai dit, l'AmigaOS 3.0 faisait toute la différence (par rapport au reste, qu'on ne se méprenne pas, l'AmigaOS 1.2/1.3 était déjà bien).

J'ai déjà répondu plus d'une fois pour ta remarque sur le Falcon 

[Invité]

tiens question pour les nerds.

un DSP, sorti d'un usage purement audio (lecture, mix et fx temps réel), ca peut faire quoi?

[Zarnal]

tiens question pour les nerds.

un DSP, sorti d'un usage purement audio (lecture, mix et fx temps réel), ca peut faire quoi?

ça entre autres :



Et pendant ce temps sur Amiga :



 

[Invité]

donc un coprocesseur a tout faire?

[Templeton]

Tower Assault tourne à 50 fps, et avec une fluidité incroyable :)

Dans le pays joyeux où c'est tous les jours le printemps, le jeu aurait pu être d'une fluidité incroyable sans doute...
Mais dans le monde réel ce n'est pas le cas hélas...
Tous les éléments qui se déplacent sur l'air de jeu tournent en 2vbl 50Hz, donc 25FPS.

L'effet de saccade (qui est accentué par la vitesse de déplacement assez élevé des BOB dans le jeu), est d'autant plus perceptible que le scrolling tourne lui en 1vbl 50Hz donc 50FPS.
Cette dichotomie engendrée par ce FrameRate mixte est assez perturbante au début, mais les yeux finissent par s'y habituer au bout d'un moment.

Bref la fluidité de ce jeu n'est pas digne de l'Arcade/Console.

Tower Assault AGA (128 couleurs), ça tourne aussi super bien.

Attention, peut être que je me trompe. C'est juste que c'est curieux qu'Alien Breed II n'ait utilisé que 128 couleurs quand on sait comme Team17 aimait repousser les limites de l'Amiga (où au minimum l'exploiter à sa pleine capacité).

Mais vous êtes sûrs pour vos 128 couleurs ?
Parlons nous là d'un vrai plan en 7 bits ?
On remarque bien qu'il y a quelques tramages en moins sur la version AGA mais pour le reste ce n'est pas transcendant.

Non, 8 BPL, mais seulement 7 d'utilisés.

Comme Zarnal je n'ai a pas l'impression de voir les 128 couleurs avancées par dlfrsilver dans l'air de jeu...
Pa conséquent, je suis aller voir ce qui se passait dans les entrailles de la bête avec le debugger de WinUAE.
Le HUD qui est séparé de la zone de jeu (dommage) utilise les 4 premiers BitPlans avec une palette qui lui est dédiée (via une copper list), donc 16 couleurs max.

L'aire de jeu principale utilise seulement les 6 premiers Bitplans... c'est donc un jeu en 64 couleurs !

Enfin ça c'est la théorie car en pratique AlienBreed TA n'affiche jamais réellement les 64 couleurs dans l'aire de jeu.

Si on résume :
Frame Rate mixte, pas de FullScreen mais seulement un léger Overscan qui fait apparaître des bandes noires disgracieuse autour de l'écran, nombres de couleurs analogues à une Megadrive, et Hud extérieur (pas d'incrustation) sont autant d’éléments qui déçoivent pour un jeu AGA sortit fin 1994.  Pourtant le 1200 était déjà sur le marché depuis plus de 2 ans.

Ruff'n'Rumble est le contre exemple parfait où les limitations techniques sont indéniables rien qu'en OCS. C'est beau, il y a des gros sprites/bobs, une bonne portion d'écran mais le framerate est ridicule.

En fait le framerate de Ruff'n R parait ridicule mais en vérité il ne l'est pas ! Le jeu est verrouillé en 2VBL 50Hz, donc il tourne en 25 FPS ce qui est honorable pour du vrai 32 couleurs.
Le problème c'est que le pas de déplacement du scrolling est trop élevé, et comme la fluidité est proportionnelle à la vitesse de déplacement, le jeu paraît extrêmement saccadé.
Battle Squadron, killing Game Show et Toki par exemple ont un scrolling qui tourne en 25 FPS, et pourtant ils paraissent beaucoup plus fluide parce que le pas de déplacement du scroll est très lent.

Plus fort encore avec le recul, lorsque je lis que Banshee peut se comparer à une borne d'arcade.    
L'amiga a une tonne de bons jeux pas forcément techniques mais cela reste un micro. 
Les budgets et les équipes attachés ne sont pas les mêmes non plus.

CQFD !
7 ans entre l'AGA et l'OCS ! Si Commodore avait fait progresser normalement l'Amiga, on aurait eu au moins la puissance d'une NéoGéo avec une meilleur palette.

A minima le DSP aurait ajouté 8 voies 16 bits au son de Paula qui commençait à dater.

Si tu fais allusion au système audio du Falcon, le DSP n'a rien à voir avec les 8 voies 16bits 50KHz, c'est deux autres puces appelées ''CODEC'' et SDMA qui gèrent le son.

Sur PC pour lire du MP3 il fallait quoi, un 486 (je dirais plus un Pentium) sans saccade.

J'avais un 486 DX 4-100 avec vesa local BUS. J'étais parfois obligé de désactiver la stéréo pour certains MP3 afin d'éviter les saccades, sur Falcon le même MP3 passait sans soucis.

un DSP, sorti d'un usage purement audio (lecture, mix et fx temps réel), ca peut faire quoi?

Le Falcon était fourni avec plusieurs applications qui exploitaient le DSP. Parmi celles-ci. il y avait un viewer JPEG ultra rapide.  Mon frère avait fait la comparaison à l'époque, pour une image qui s'ouvrait en 3 seconde sur Falcon, il fallait presque 1 mn sur  le 1200 (avec la même image) via un super viewer JPEG sortie bien des années plus tard,.

>>donc un coprocesseur a tout faire?

C'est un deuxième CPU, c'est même mieux que ça en fait, il possède un jeu d’instruction complexe,  son propre Bus Mémoire/Data, des ports externes, une ROM et sa propre mémoire dédiée (3 en réalité), c'est presque un ordinateur dans l'ordinateur.
C'est pour cela que tu peux faire tourner une application en parallèle sans ralentir la machine (en laissant 100% du temps CPU 68030) et sans l'O.S multitâche.

Atari vendait sa machine comme le premier ordinateur bi-processeur multimédia accessible au grand public

DSP est un acronyme fourre tout qui porte à confusion si on compare aux premiers DSP sur les cartes sonores PC et la SNES.
Sur ces machines ce sont de véritables coprocesseur sonore, tout est ''précablé'', tu ne peux rien programmer. Ils sont appelés Digital Sound Processor et ne sont dédiés qu'au son et uniquement au son (Sauf les DSP sur cartouche). Les DSP sur le Next et le Falcon sont appelés Digital Signal Processor. C'est un microprocesseur à part entière comme peut l'être un 68000, un ARM, un SH4, chacun ayant ses particularités.

[babsimov]

tiens question pour les nerds.

un DSP, sorti d'un usage purement audio (lecture, mix et fx temps réel), ca peut faire quoi?

ça entre autres :



Et pendant ce temps sur Amiga :



 

C'est bien pour ça que je regrette que l'AGA n'est pas eut le DSP prévu au départ. On aurait peut être eut ça à l'époque, la génération AGA s'est vendue malgré tout, à la différence du Falcon qui n'a pas eut la chance de pouvoir commencer une vraie carrière commerciale.

Clairement un DSP n'aurait pas été un luxe pour l'AGA, ni un exotisme mais une nécessité.

Templeton

Tower Assault tourne à 50 fps, et avec une fluidité incroyable :)

Dans le pays joyeux où c'est tous les jours le printemps, le jeu aurait pu être d'une fluidité incroyable sans doute...
Mais dans le monde réel ce n'est pas le cas hélas...
Tous les éléments qui se déplacent sur l'air de jeu tournent en 2vbl 50Hz, donc 25FPS. 

L'effet de saccade (qui est accentué par la vitesse de déplacement assez élevé des BOB dans le jeu), est d'autant plus perceptible que le scrolling tourne lui en 1vbl 50Hz donc 50FPS.
Cette dichotomie engendrée par ce FrameRate mixte est assez perturbante au début, mais les yeux finissent par s'y habituer au bout d'un moment.

Bref la fluidité de ce jeu n'est pas digne de l'Arcade/Console.

Tower Assault AGA (128 couleurs), ça tourne aussi super bien.

Attention, peut être que je me trompe. C'est juste que c'est curieux qu'Alien Breed II n'ait utilisé que 128 couleurs quand on sait comme Team17 aimait repousser les limites de l'Amiga (où au minimum l'exploiter à sa pleine capacité). 

Mais vous êtes sûrs pour vos 128 couleurs ?
Parlons nous là d'un vrai plan en 7 bits ?
On remarque bien qu'il y a quelques tramages en moins sur la version AGA mais pour le reste ce n'est pas transcendant.

Non, 8 BPL, mais seulement 7 d'utilisés. 

Comme Zarnal je n'ai a pas l'impression de voir les 128 couleurs avancées par dlfrsilver dans l'air de jeu... 
Pa conséquent, je suis aller voir ce qui se passait dans les entrailles de la bête avec le debugger de WinUAE.
Le HUD qui est séparé de la zone de jeu (dommage) utilise les 4 premiers BitPlans avec une palette qui lui est dédiée (via une copper list), donc 16 couleurs max.

L'aire de jeu principale utilise seulement les 6 premiers Bitplans... c'est donc un jeu en 64 couleurs ! 

Enfin ça c'est la théorie car en pratique AlienBreed TA n'affiche jamais réellement les 64 couleurs dans l'aire de jeu.

Si on résume :
Frame Rate mixte, pas de FullScreen mais seulement un léger Overscan qui fait apparaître des bandes noires disgracieuse autour de l'écran, nombres de couleurs analogues à une Megadrive, et Hud extérieur (pas d'incrustation) sont autant d’éléments qui déçoivent pour un jeu AGA sortit fin 1994.  Pourtant le 1200 était déjà sur le marché depuis plus de 2 ans.

Le test d'époque que j'avais cité parlais bien de 128 couleurs. Team17 aurait donc raconté n'importe quoi à l'époque on dirait ? 
En tout cas, la version AGA parait quand même plus "colorée" que la version OCS/ECS (je devais avoir les deux à l'époque pour comparer).

Plus fort encore avec le recul, lorsque je lis que Banshee peut se comparer à une borne d'arcade.      
L'amiga a une tonne de bons jeux pas forcément techniques mais cela reste un micro.   
Les budgets et les équipes attachés ne sont pas les mêmes non plus. 

CQFD !
7 ans entre l'AGA et l'OCS ! Si Commodore avait fait progresser normalement l'Amiga, on aurait eu au moins la puissance d'une NéoGéo avec une meilleur palette.

Tu penses vraiment qu'on aurait pu avoir la puissance d'une Néo Géo dans la génération 32 bits de ces hypothétiques Amiga qui auraient évolué normalement ?

La Néo Géo, ça reste de la basse résolution non (320x200), pas de hautes résolutions, pas de chunky (donc Wincommander, Wolfenstein 3D etc...même problème que sur AGA, difficile à faire et moche/lent).

A minima le DSP aurait ajouté 8 voies 16 bits au son de Paula qui commençait à dater. 

Si tu fais allusion au système audio du Falcon, le DSP n'a rien à voir avec les 8 voies 16bits 50KHz, c'est deux autres puces appelées ''CODEC'' et SDMA qui gèrent le son.

"Codec" c'est pas plutôt un composant qui gère le son du DSP pour lui donner les 8 voies.

Ma remarque ne concernait pas du tout le DSP du Falcon, mais bien celui de l'Amiga. Dave Haynie que j'ai cité un peu plus haut disait :

"So anyway, the A3000+ had this chip -- which lived in the system as a bus master, sharing all of memory with the CPU slot processor -- and as well, two audio CODECs. One was for modem projects, a lower bitrate mono CODEC with phase correction, and the other was a 16-bit, CD-quality audio CODEC, for high quality audio I/O... the DSP would have been able to give us at least eight channels of playback at full CD quality."

Donc si je comprends bien, il dit qu'il y avait deux codecs (composants) qui permettaient au DSP soit d'avoir au moins 8 voies 16 bits, soit d'être utilisé comme modem. D'ou la remarque pour le CODEC que tu cites du Falcon.

J'ai regardé le wiki du Falcon. SDMA parait bien être le composant sonore (ne m'en veut pas il fallait que je vérifie et que je comprenne mieux le rôle de ce composant).
https://en.wikipedia.org/wiki/Atari_Falcon

Tel que je le comprends, dans le cas du 3000+ PAULA aurait rempli un peu le rôle du SDMA (c'est à dire fournir le son de base) et le DSP aurait ajouté 8 voies 16 bits). Ce qui signifie que le Falcon devait donc pouvoir avoir au moins 16 voix 16 bits ? 8 de SDMA et 8 du DSP ?

Sur PC pour lire du MP3 il fallait quoi, un 486 (je dirais plus un Pentium) sans saccade.

J'avais un 486 DX 4-100 avec vesa local BUS. J'étais parfois obligé de désactiver la stéréo pour certains MP3 afin d'éviter les saccades, sur Falcon le même MP3 passait sans soucis.

C'est bien ce que je voulais dire, avoir un DSP dans une machine à cette époque était un sérieux atout.

un DSP, sorti d'un usage purement audio (lecture, mix et fx temps réel), ca peut faire quoi? 

Le Falcon était fourni avec plusieurs applications qui exploitaient le DSP. Parmi celles-ci. il y avait un viewer JPEG ultra rapide.  Mon frère avait fait la comparaison à l'époque, pour une image qui s'ouvrait en 3 seconde sur Falcon, il fallait presque 1 mn sur  le 1200 (avec la même image) via un super viewer JPEG sortie bien des années plus tard,.

Même remarque que précédemment   

>>donc un coprocesseur a tout faire? 

C'est un deuxième CPU, c'est même mieux que ça en fait, il possède un jeu d’instruction complexe,  son propre Bus Mémoire/Data, des ports externes, une ROM et sa propre mémoire dédiée (3 en réalité), c'est presque un ordinateur dans l'ordinateur.
C'est pour cela que tu peux faire tourner une application en parallèle sans ralentir la machine (en laissant 100% du temps CPU 68030) et sans l'O.S multitâche.

Alors imagine avec un OS multitâche côté Amiga et un OS multitâche spécifique pour le DSP, ce qui était prévu avec le 3000+

Atari vendait sa machine comme le premier ordinateur bi-processeur multimédia accessible au grand public 

Ca on en a déjà parlé, je trouve que le bi-processeur est quand même un peu "abusif" de la part d'Atari. Le vrai Bi-processeur, c'était la BeBOX avant non.

DSP est un acronyme fourre tout qui porte à confusion si on compare aux premiers DSP sur les cartes sonores PC et la SNES.
Sur ces machines ce sont de véritables coprocesseur sonore, tout est ''précablé'', tu ne peux rien programmer. Ils sont appelés Digital Sound Processor et ne sont dédiés qu'au son et uniquement au son (Sauf les DSP sur cartouche). Les DSP sur le Next et le Falcon sont appelés Digital Signal Processor. C'est un microprocesseur à part entière comme peut l'être un 68000, un ARM, un SH4, chacun ayant ses particularités.

Vu comme ça à la rigueur, mais personnellement je considère plus le DSP comme un super coprocesseur, il fallait bien qu'il soit à un moment piloté par l'OS sous 680x0. Mais, je l'ai toujours dit, chapeau bas à Atari pour le Falcon et surtout à son DSP.

EDIT : J'ai une question pour toi Templeton, puisque tu t'y connais en technique. Le DSP du Falcon n'avait pas de capacité de calcul sur les flottants (si je ne me trompe pas), juste sur les entiers. Celui prévu pour l'Amiga avait une capacité de calcul sur les flottants (simple précision, même si pour moi c'est pas parlant). Dave Haynie dit que dans ce cas le DSP calcul 10 fois plus vite qu'un 68040. Te parait il plausible que ce DSP ait pu servir à la façon d'un coprocesseur mathématique pour les logiciels de rendu 3D de type Lightwave, POV etc... ? Comme il parle de simple précision, je suppose que les coprocesseurs mathématique de Motorola sont plus précis, mais pour un particulier cela aurait il été suffisant pour la 3D (rendu et pourquoi pas en jeux texturés) ? Pour l'affichage des Jpeg cela aurait il permis un gain par rapport au DSP du Falcon, même question pour le MP3 ?

[Zarnal]

Plus fort encore avec le recul, lorsque je lis que Banshee peut se comparer à une borne d'arcade.      
L'amiga a une tonne de bons jeux pas forcément techniques mais cela reste un micro.   
Les budgets et les équipes attachés ne sont pas les mêmes non plus. 

CQFD !
7 ans entre l'AGA et l'OCS ! Si Commodore avait fait progresser normalement l'Amiga, on aurait eu au moins la puissance d'une NéoGéo avec une meilleur palette.

Tu penses vraiment qu'on aurait pu avoir la puissance d'une Néo Géo dans la génération 32 bits de ces hypothétiques Amiga qui auraient évolué normalement ?

La Néo Géo, ça reste de la basse résolution non (320x200), pas de hautes résolutions, pas de chunky (donc Wincommander, Wolfenstein 3D etc...même problème que sur AGA, difficile à faire et moche/lent).

Oui mais avec pleins de bons jeux énergiques.

[TotOOntHeMooN]

Le DSP n'aurait jamais permis cela en AGA... Arrête de rêver.
De plus, le DSP sur Falcon permet de faire de belles démo techniques, mais pas de jeux.

[babsimov]

Plus fort encore avec le recul, lorsque je lis que Banshee peut se comparer à une borne d'arcade.      
L'amiga a une tonne de bons jeux pas forcément techniques mais cela reste un micro.   
Les budgets et les équipes attachés ne sont pas les mêmes non plus. 

CQFD !
7 ans entre l'AGA et l'OCS ! Si Commodore avait fait progresser normalement l'Amiga, on aurait eu au moins la puissance d'une NéoGéo avec une meilleur palette.

Tu penses vraiment qu'on aurait pu avoir la puissance d'une Néo Géo dans la génération 32 bits de ces hypothétiques Amiga qui auraient évolué normalement ?

La Néo Géo, ça reste de la basse résolution non (320x200), pas de hautes résolutions, pas de chunky (donc Wincommander, Wolfenstein 3D etc...même problème que sur AGA, difficile à faire et moche/lent).

Oui mais avec pleins de bons jeux énergiques.

Jeux qui coûtaient une fortune si je me souviens bien (sans parler de la console aussi). Et uniquement des jeux 2D (si je ne me trompe pas), hors, ça c'était plus trop à la mode. Attention, je dis pas que les jeux Neo Geo que j'ai pu essayer sur émulateur ne m'ont pas impressionnés, c'est juste que j'ai l'impression que c'était bien trop calibré "arcade" pour pouvoir faire autre chose.

L'Amiga c'est un ordinateur, il lui FALLAIT donc de la haute résolution, le mode chunky qui lui a tant fait défaut, justement pour suivre (ou devancer le PC). Le AAA aurait pu apporter tout ça, mais il semble qu'il était vraiment trop cher à produire pour Commodore et pour être rentable. 

De toute façon c'est pas l'AGA qui pourra, à mon avis, faire un shoot comme celui vu sur le Falcon un peu plus haut. Si le Falcon avait eut une vie commerciale parallèle à celle de l'Amiga 1200, il est probable que ça aurait sérieusement fait de l'ombre à la génération AGA. Peut être que Commodore se serait bougé aussi pour sortir la carte DSP, par obligation à répondre à la menace du Falcon et de son DSP.

[babsimov]

Le DSP n'aurait jamais permis cela en AGA... Arrête de rêver.
De plus, le DSP sur Falcon permet de faire de belles démo techniques, mais pas de jeux.

Qu'est ce que t'en sait ? Personne n'a vu ce que le DSP 3210 pouvait donner dans l'Amiga. Seul Dave Haynie donne une liste impressionnante de capacités pour ce DSP. Capacités que le Falcon avec, selon certains propos controversés une architecture bancale héritée du ST, plus ou moins 16 bits, démontre avec brio. Donc l'Amiga avec une architecture semble t il mieux pensée (ou moins limitative) que le Falcon n'aurait pas fait autant (ou mieux), permet moi de douter de ton affirmation. L'AGA a beaucoup de défauts, mais à l'époque un DSP avaient beaucoup d'atouts.

EDIT : Ce qui est le plus triste dans tout ça, c'est que c'est la décision d'une seule personne qui n'y connaissait rien en informatique qui a fait qu'on ne saura probablement pas ce qu'aurait pu donner un DSP avec l'AGA. C'était pourtant la volonté de départ des ingénieurs, doter cette génération là du DSP. Quel gâchis !

EDIT2 : Templeton, ne m'en veut pas pour la remarque sur l'architecture du Falcon, je sais que ce n'est pas aussi simpliste que ça, après les échanges dans un autre sujet. C'était pour forcer le trait, j'espère que tu l'avais compris comme ça.

Pour ta remarque sur le Falcon.
Le shoot them up sur le Falcon c'est pas un jeu ? 
La course de voiture c'est pas un jeu ?
Le moteur 3D quake, là oui c'est une démo. Mais sur un Amiga 1200 de base c'est même pas envisageable à cette vitesse. Un moteur Wolfenstein ou Doom (moins gourmand, surtout pour le premier) aurait pu exister et on aurait pas entendu "Doom infaisable sur Amiga".

Mais même sans parler de jeux, on t'as cité l'affichage Jpeg en 3 secondes au lieu de 1 minutes, c'est certain qu'à l'époque c'était pas une prouesse ça... Le MP3 aussi voit ce que dit Templeton par rapport au PC.

C'était justement la force des architectures innovantes qui cherchaient à proposer autre chose que le PC, un processeur qui fait tout. Ca permettait de faire des choses mieux où impossible sur PC (avant longtemps).

Je vais donc résumer tout ça en une question :

Si en 1990 (dans notre hypothèse) ou 1992 (dans la réalité) pour le même prix tu avais eu l'AGA+DSP, au lieu de l'AGA tout court, tu va me dire que tu aurait dit "Ah non le DSP ça sert à rien" (alors que je t'ai donné plein d'exemples de l'apport d'un DSP, ne serait ce que sous workbench où pour avoir 8 voies 16 bit en plus des pauvres 4 voies 8 bits de Paula en 1992 !). Donc ta réponse c'est quoi ? Tu aurais refusé d'avoir le DSP en plus pour le même prix (c'était le cas du 3000+) ?

Pour ce qui me concerne je pense que tu connais déjà ma réponse 
J'attend la tienne.

[babsimov]

J'ai trouvé des informations sur la carte DSP 3210 prévue pour le 4000 dans une discussion d'époque :
https://groups.google.com/forum/#!topic/comp.sys.atari.st/X6PG847hmfE

J'ai pas encore tout lu, c'est très intéressant je trouve.

@Templeton

Il y a forcément comparaison avec le DSP du Falcon et donc des choses sont avancé pour expliquer qu'au final le DSP du Falcon est moins bien. Pourrait tu donner ton opinion (impartiale n'est ce pas  )  ?

Tiens je te cite des détails techniques :
"Here's some info on the AT&T 3210 DSP CHIP.... If anyone
has info on the newer 3207 chip, please post!
DSP3210 Overview
----------------
The DSP3210 is a full 32-bit floating point DSP implemented in .9 micron CMOS.
It provides many advantages over fixed point DSPs such as the Motorola 56000.
Some of the main features of the DSP3210 include:
  * 32-bit floating point arithmetic.
  * 32-bit addressing.
  * Large (8k) on-chip, zero wait-state memory.
  * Single cycle instructions (for up to 33 Mflops).
  * Share bus with Motorola or Intel style CPU.
  * Serial I/O with DMA transfer conters for up to 25 Mbits/second transfer:
      Serial data transfers occur without processor intervention.
      Cycles are stolen when necessary.
      DMA control for serial in and serial out.
  * Barrel Shifter for bit manipulation in graphics or data encryption.
  * Both mu-law and A-law encoding.
  * Bit I/O general purpose 8-bit I/O port for control of external hardware.
  * Programmable 32-bit timer for interval timing, rate generation, event
    counting or waveform generation.
  * Fully vectored interrupt structure with hardware context save:
      Allows very fast interrupt processing, up to 2 million/second.
  * Low power CMOS design.
No special programming is required on the DSP3210 to implement floating point
algorithms, or to process signals with a much larger dynamic range (in excess
of 1500 dB as opposed to < 300 dB for fixed point). The DSP3210 is also
designed to share a host memory bus with either a Motorola or Intel style CPU.
This greatly reduces system cost by removing the requirement for expensive
fast local memory for the DSP. This also removes any practical restrictions on
program or data size. A large on-chip cache (8k) combined with software that
intelligently utilizes the cache allows the DSP3210 to execute complex signal
processing algorithms without expensive local memory. All instructions execute
in a single cycle (four clock periods> 80 ns for a 50 MHz part or 60 ns for a
66 MHz part) and includes all floating point normalization (which is performed
automatically). A single instruction may have two floating point operations:
a floating point multiplication and a floating point addition. The DSP3210
also supports up to four memory accesses in a single instruction cycle (quad-
word transfer). The DSP3210 architecture features seven functional units:
  * Control Arithmetic Unit (CAU)
  * Data Arithmetic Unit (DAU)
  * On-chip memory (RAM0, RAM1, Boot ROM)
  * Bus Interface
  * Serial I/O (SIO)
  * DMA Controller (DMAC)
  * Timer/Status Control (TSC)

The Control Arithmetic Unit
---------------------------
The CAU is responsible for address calculation, branching control and all 16
and 32-bit integer logic and arithmetic operations. It is a RISC core
consisting of a 32-bit Arithmetic Logic Unit (ALU), a 32-bit Program Counter
(PC), 22 32-bit general purpose registers (r0-r22) and a 32-bit barrel
shifter. This core executes instructions at up to 16.7 million instructions
per second. There are special register considerations in the CAU:
  r0              hardwired to 0 (always)
  r1-r14          DA instruction memory reference (X,Y,Z) pointer registers
  r15-r19         DA instruction memory reference (X,Y,Z) increment registers
  r20             used by error exception facility to store old pc
  r21             stack pointer (sp)
  r22             pointer to the exception vector table (evtp)
The CAU provides the following branching and control instructions:
  if (COND) goto {N,rB,rB+N}       Conditional branch based on flags
  if (rM-->=0) goto {N,rB,rB+N}    Conditional branch using loop counter
  goto {N,rB,rB+N,M,rB+M}          Unconditional branch
  nop                              No operation
  call {N,rB,rB+N,M}(rM)           Call subroutine
  return {rM}                      Return from subroutine
  do K,{L,rM}                      Do next K+1 instruction(s) L+1 or (rM+1)
                                   times. K=0,1,2...127; L=rM=0,1,2...2047
  dolock K,{L,rM}                  Signals interlocked bus transfer
  doblock {L,rM}                   Signals quad-word transfers
  ireturn                          Return from interrupt
  sftrst                           Soft-reset; changes error level to base
                                   level; encoded as spc=(byte)r0
  waiti                            Wait for interrupt; encoded as spc=(long)r0
  where:  rB = pc, r0-r22
          rM = r1-r22
          N = 16-bit unsigned integer
          M = 24-bit unsigned integer
          COND = one of the DSP3210 condition codes (refer to DSP3210 manual)

The Data Arithmetic Unit
------------------------
The DAU consists of a 32-bit floating point multiplier, a 40-bit floating
point adder, four 40-bit floating point accumulators (a0-a3), a clip test
register (ctr), and a control register (dauc). The multiplier and adder
operate in parallel to perform up to 16.7 million computations per second
(12.5 million for a 50 MHz part) of the form (a=b+c*d), also known as a
multiply-accumulate. The DAU contains a four stage pipeline which is visible
to the application programmer. The DAU supports the following floating point
formats:
  Single precision (32-bit) in both DSP32 and IEEE format
  Extended single precision (40-bit) (uses 8 mantissa guard bits)
Single instruction data type conversions are done in the DAU hardware:
  DSP32 and IEEE 32-bit floating point
  16/32-bit integer
  8-bit unsigned
  mu-law and A-law
The DAU has a number of special instructions to greatly simplify data type
conversions and other common operations:
  [Z=] aN = ic(Y)      Input conversion mu-law, A-law, 8-bit linear to float.
  [Z=] aN = oc(Y)      Output conversion float to mu-law, A-law, 8-bit linear.
  [Z=] aN = float16(Y) 16-bit integer to float.
  [Z=] aN = float32(Y) 32-bit integer to float.
  [Z=] aN = int16(Y)   Float to 16-bit integer (round or truncate, dauc[4]).
  [Z=] aN = int32(Y)   Float to 32-bit integer (round or truncate, dauc[4]).
  [Z=] aN = round(Y)   Round to nearest, float(40) to float(32).
  [Z=] aN = ifalt(Y)   Condidional assignment/memory write.
  [Z=] aN = ifaeq(Y)   Conditional assignment/memory write.
  [Z=] aN = ifagt(Y)   Conditional assignment/memory write.
  [Z=] aN = dsp(Y)     IEEE to DSP format conversion.
  [Z=] aN = ieee(Y)    DSP to IEEE format conversion.
  [Z=] aN = seed(Y)    32-bit to 32-bit reciprocal seed.
Where [Z=] indicates that condition codes may be set. Note that Y may not be
a0-a3 for the dsp() special function.

Addressing Modes
----------------
DSP3210 assembler language exhibits a syntax very similar to 'C'. The notation
conventions are as follows: a0-a3 are the accumulators (DAU), and r0-r22 are
the CAU registers. Instructions take the following appearance:
  r2 = (long)r1      ; CAU register direct: store the contents of r1 in r2
  r1 = (long)*r1     ; store value pointed to by r1 in r2
  r1 = (long)r1 + 1  ; increment r1 by 1
  *r2++ = (long)r1   ; postmodify increment r2 after storing r1 there (in *r2)
  r3 = (long)r1 + r2 ; add two numbers in r1, r2: store result in r3
  r3 = (long)*r1++r2 ; post modify increment r1 by r2: store the result in r3
  a2 = a2 + *r2 * a3 ; use that pipeline!

The following table lists the various addressing modes supported by the
DSP3210:
------------------------------------------------------------------------------
                                       Instruction Type
Addressing Mode         CA Data      CA Data      CA Arithmetic/  DA M/A &
                        Move Group   Move Group   Logic Group     Special Func
                        (CAU Reg)    (I/O Reg)
------------------------------------------------------------------------------
Short Immediate         Yes
24-bit Immediate        Yes
Memory Indirect         Yes
CAU Register Direct     Yes          Yes          Yes
IO Register Direct      Yes
DAU Register Direct     Yes                                       Yes
Register Indirect       Yes          Yes                          Yes
Register Indirect with  Yes          Yes                          Yes
Postmodification
------------------------------------------------------------------------------"

@TotOOntHeMooN

Une spécification a retenue mon attention :


"Barrel Shifter for bit manipulation in graphics or data encryption."


On dirait bien que le DSP 3210 avait une gestion graphique intégrée, donc des moteurs graphiques auraient pu être envisagé pour tel ou tel type de domaine.

[Zarnal]

Comme Zarnal je n'ai a pas l'impression de voir les 128 couleurs avancées par dlfrsilver dans l'air de jeu...
Pa conséquent, je suis aller voir ce qui se passait dans les entrailles de la bête avec le debugger de WinUAE.
Le HUD qui est séparé de la zone de jeu (dommage) utilise les 4 premiers BitPlans avec une palette qui lui est dédiée (via une copper list), donc 16 couleurs max.

L'aire de jeu principale utilise seulement les 6 premiers Bitplans... c'est donc un jeu en 64 couleurs !

Enfin ça c'est la théorie car en pratique AlienBreed TA n'affiche jamais réellement les 64 couleurs dans l'aire de jeu.

Si on résume :
Frame Rate mixte, pas de FullScreen mais seulement un léger Overscan qui fait apparaître des bandes noires disgracieuse autour de l'écran, nombres de couleurs analogues à une Megadrive, et Hud extérieur (pas d'incrustation) sont autant d’éléments qui déçoivent pour un jeu AGA sortit fin 1994.  Pourtant le 1200 était déjà sur le marché depuis plus de 2 ans.

Ruff'n'Rumble est le contre exemple parfait où les limitations techniques sont indéniables rien qu'en OCS. C'est beau, il y a des gros sprites/bobs, une bonne portion d'écran mais le framerate est ridicule.

En fait le framerate de Ruff'n R parait ridicule mais en vérité il ne l'est pas ! Le jeu est verrouillé en 2VBL 50Hz, donc il tourne en 25 FPS ce qui est honorable pour du vrai 32 couleurs.
Le problème c'est que le pas de déplacement du scrolling est trop élevé, et comme la fluidité est proportionnelle à la vitesse de déplacement, le jeu paraît extrêmement saccadé.
Battle Squadron, killing Game Show et Toki par exemple ont un scrolling qui tourne en 25 FPS, et pourtant ils paraissent beaucoup plus fluide parce que le pas de déplacement du scroll est très lent.

Plus fort encore avec le recul, lorsque je lis que Banshee peut se comparer à une borne d'arcade.    
L'amiga a une tonne de bons jeux pas forcément techniques mais cela reste un micro. 
Les budgets et les équipes attachés ne sont pas les mêmes non plus.

CQFD !
7 ans entre l'AGA et l'OCS ! Si Commodore avait fait progresser normalement l'Amiga, on aurait eu au moins la puissance d'une NéoGéo avec une meilleur palette.

1/

Cela me fait penser à ce thread sur EAB où se sont glissées quelques erreurs :

http://eab.abime.net/showthread.php?t=80207

Tower Assault est placé en Full 50 par exemple.

Pour Apidya un coup c'est en mixé, un coup c'est en full 50. Je ne sais plus quoi en penser.
 
2/

En tout cas même si ce n'est qu'un portage avec le recul il y a de quoi s’interroger sur l'évolution :

MD Full 50 fps fullscreen






Amiga AGA : Mixé 50/25 (la taille d'écran change car le gars doit s'amuser au passage 50/60Hz dispo dans le jeu). Fenêtre de jeu plus petite.

[JSR]

Wonder girl in monster place est en développement pour le moment sur A1200,ils aimeraient également sortir d’autres épisodes sur CD32, CDTV et même Lynx, Commodore 64, Mega Drive, Super Nintendo.

[dlfrsilver]

Tout ces jeux ont été confirmés comme tournant à 50 fps avec la méthode de Toni Wilen : 

Alien Breed
Alien Breed II
Alien Breed Tower Assault
Assassin
Assasin Special Edition
Beastlord
Bram Stoker's Dracula
Overkill
Speris Legacy
ATR - All Terrain Racing
Goal!
Hagar the Horrible
Kid Gloves 2
StarRay
Insects in Space
Spindizzy Worlds
Deluxe Galaga
Death Trap
Cool World
Chrome
Cedric and the Lost Sceptre
Anarchy
Dennis
Kid Chaos
The Addams Family
Overdrive (Team 17)
Total Recall
Firefoce
Yoe Joe!
Rolling Ronny
Metal Law
Warp
Plutos
Vader
Dragon Spirit
Gemini Wing
Firefly
Hellbent
Sidewinder
Atax
Apano Sin
Cyberpunks
Cytron
Fantastic Voyage
Cliffhanger
Alien 3
Navy Seals
The Plague
Sword
Operation Firestorm
Ork
Marvin's Marvelous Adventure
Crazy Sue
Crazy Sue Goes On
Creatures
Oscar
P.P. Hammer and His Pneumatic Weapon
Pinkie
Quick the Thunder Rabbit
Rackney's Island
Scooby-Doo and Scrappy-Doo
The Simpsons - Bart vs. The Space Mutants
Ruffian
Terry's Big Adventure
Tearaway Thomas
Super Cauldron
Wiz'n Liz
wonder Dog
Woodys World
Beavers
Blues Brothers
Bubble and Squeak
Lolly Pop
Tin Toy Adventure in the House of Fun
Traps'n Treasures
McDonald Land
Flimbo's Quest
Jimmy's Fantastic Journey
Brian the Lion
Nicky Boom
Nicky II
BC Kid
Charly J Cool
Trolls
Puggsy
Roadkill
Rat Trap
Doofus
Titus the Fox
Apache
Super Frog
Soccer Kid
Sleepwalker
Wings of Death
Hybris
James Pond 1-3
Turrican Series
Lionheart 
Apprentice
Disposable Hero
Cardiaxx
Carcharodon - White Sharks
Chuck Rock
Chuck Rock II
X-Out
Silkworm
Gainforce
Phobia
Menace
Bio Challenge
Blastar
Zool
Zool II
Venus the Fly Trap
Uridium II
Twinworld
Seven Gates of Jambala
Slam Tilt
Pinball Dreams, Fantasies, Illusions
Pang
Mr. Nutz
Lethal Weapon
Rock'n Roll
Shadow of the Beast I - III
Great Giana Sisters
Leander
Jim Power
Hudson Hawk
Hard'n Heavy
Harlequin
Dyter-07
Caveman Ninja
Battle Valley
Switchblade II
Tony and his Friends in Kellog's Land
The Adventures of Quick & Silva
Odyssey
Universal Warrior
Sensible World of Soccer

[Zarnal]

Je me demande si la méthode est fiable à 100%. Prenons Addams Familly par exemple, j'ai toujours trouvé à l'oeil que les sprites étaient à 25. Bon il manque un tas d'étapes d'animation pour les sprites sur la version amiga (512k) par rapport à la SFC. Ceci explique peut être cela La preuve :

Amiga (n'est pas en plein écran normalement)



SNES

[TotOOntHeMooN]

Ce n'est pas parce que un jeu tourne à 50fps, que les "sprites" aussi.
On est pas sur un jeu 3D ou tout est réaffiché à chaque frame.

[dlfrsilver]

Ce n'est pas parce que un jeu tourne à 50fps, que les "sprites" aussi.
On est pas sur un jeu 3D ou tout est réaffiché à chaque frame.

La liste des jeux vérifiés plus haut, c'est 50 fps pour le scrolling et 50 ou 25 fps pour les sprites

Toni Wilen a mis un système en place dans Winuae pour déterminer avec précision si c'est du 25/25, 50/25, ou du 50/50. 

Addams Family, c'est 50 fps pour le scroll et 25 fps pour les sprites.

[dlfrsilver]

voici quelques jeux vérifiés à 25 fps : 

Apidya
Blood Money
Katakis
Ziriax
Watchtower
Agony
Z-Out
Project X
The Oath
Banshee
Battle Squadron
Mega Typhoon
Sarcophaser
Dragon Breed
Lunar-C
R-Type
Saint Dragon
Rainbow Islands
Midnight Resistance
Apache Flight
Bomber Bob
Foundation's Waste
Kamikaze
Killing Machine
Violator
Time Soldier
XP8
Scramble Spirits
Sonic Boom

[TotOOntHeMooN]

OK. Après, Toni Wilen sait parfaitement ce qu'il fait.
Par contre, est-ce que ces mesures sont bien faites avec une config A500 de base?

[dlfrsilver]

OK. Après, Toni Wilen sait parfaitement ce qu'il fait.
Par contre, est-ce que ces mesures sont bien faites avec une config A500 de base?

Oui, en fait, Toni a mis en place un système de couleur, qui permet de savoir précisément pour le scrolling et les sprites si c'est vraiment 50 ou 25 fps. 

info ici : http://eab.abime.net/showpost.php?p=1050498&postcount=140

[dlfrsilver]

en français : 

Ajouter la ligne "show_refresh_indicator=true" au fichier de config pour l'activer.

Une Barre apparait dans la bordure de gauche:

Gris = ligne a été changée 1 frame avant
Vert = ligne a été changé 2 frames avant
Bleu = ligne a été changée 3 frames avant
Noir = ligne a été changée 4 ou de frames avant.

En d'autres mots: gris constant = chaque frame est mise à jour. gris/vers clignotant = 25Hz et ainsi de suite.

Il compare seulement les données bitmap, les changement de couleur ou les sprites ne comptent pas comme étant changés.

Notez que ça peut augmenter la charge CPU de façon notable. (Toutes les lignes doivent être vérifiées et redessinées  en permanence).

[Zarnal]

Ce n'est pas parce que un jeu tourne à 50fps, que les "sprites" aussi.
On est pas sur un jeu 3D ou tout est réaffiché à chaque frame.

La liste des jeux vérifiés plus haut, c'est 50 fps pour le scrolling et 50 ou 25 fps pour les sprites

Toni Wilen a mis un système en place dans Winuae pour déterminer avec précision si c'est du 25/25, 50/25, ou du 50/50. 

Addams Family, c'est 50 fps pour le scroll et 25 fps pour les sprites.

Alors pourquoi est il dans la section 50/50 ?

Edit : il est bien en 50/50 je viens de vérifier.  

C'est donc un manque d'étapes d'anim uniquement et non des sprites à 25.

Et pour apydia c'est vert/gris et pourtant il est passé de la section mixée à la section full 50. Pour quelle raison ?

Et je confirme ce que Templeton écrivait

Alien breed 1/2 et Tower Assault c'est bien du 50/25. Alors d'accord si tu bouges la barre est totalement grise mais si tu ne bouges pas et que les sprites/bobs d'hélicos se pointent ou que les tourelles te tirent dessus cela passe en vert.



Par contre Turrican 3 les 2 robots sont à 50. Je suis également à l'arrêt.




Et pour Megatyphoon le scrolling est volontairement ralenti si j'ai bien compris. Il repasse à 50 pour les boss.

[dlfrsilver]

Ce n'est pas parce que un jeu tourne à 50fps, que les "sprites" aussi.
On est pas sur un jeu 3D ou tout est réaffiché à chaque frame.

La liste des jeux vérifiés plus haut, c'est 50 fps pour le scrolling et 50 ou 25 fps pour les sprites

Toni Wilen a mis un système en place dans Winuae pour déterminer avec précision si c'est du 25/25, 50/25, ou du 50/50. 

Addams Family, c'est 50 fps pour le scroll et 25 fps pour les sprites.

Alors pourquoi est il dans la section 50/50 ?

Edit : il est bien en 50/50 je viens de vérifier.  

C'est donc un manque d'étapes d'anim uniquement et non des sprites à 25.

Et pour apydia c'est vert/gris et pourtant il est passé de la section mixée à la section full 50. Pour quelle raison ?

Et je confirme ce que Templeton écrivait

Alien breed 1/2 et Tower Assault c'est bien du 50/25. Alors d'accord si tu bouges la barre est totalement grise mais si tu ne bouges pas et que les sprites/bobs d'hélicos se pointent ou que les tourelles te tirent dessus cela passe en vert.



Par contre Turrican 3 les 2 robots sont à 50. Je suis également à l'arrêt.

Addams Family, je vais te dire en toute honnête, les mecs qui ont bossé dessus sur Amiga ont fait de la merde. 

Même la version ST a la parallaxe, sur Amiga, ils l'ont désactivée ! Ils l'ont sorti pour Amiga 512k, alors qu'à ce moment là, les jeux tournaient avec 1mo de ram !

[Templeton]

""Codec" c'est pas plutôt un composant qui gère le son du DSP pour lui donner les 8 voies."

Non, le DSP 56K est un microprocesseur, pas une puce sonore.
Le CODEC c'est une puce entièrement dédiée au son, dedans se trouve le DAC (CNA en français) qui est le convertisseur numérique analogique, sans ça le Falcon serait muet.
Dedans tu trouves aussi un ADC (l'inverse du DAC) pour numériser du son (via l'entrée sonore) et un additionneur 16Bits qui permet d'ajouter une autre source sonore, sur le Falcon c'est le Yamaha.

Dans le domaine audio, le DSP est utile si tu veux faire des choses en temps réel (mixer plein de voix, faires des echos, flanger, etc.) à la place du CPU car il va le décharger de ces taches qui sont trop lourdes pour lui.
Quand Dave Haynie dit "the DSP would have been able to give us at least eight channels of playback at full CD quality." il se base sur les performances du DSP sur le papier pour imaginer qu'il aurait été capable de mixer au moins 8 voix 16 Bits en 44.1KHz.

"Tel que je le comprends, dans le cas du 3000+ PAULA aurait rempli un peu le rôle du SDMA (c'est à dire fournir le son de base) et le DSP aurait ajouté 8 voies 16 bits). Ce qui signifie que le Falcon devait donc pouvoir avoir au moins 16 voix 16 bits ? 8 de SDMA et 8 du DSP ?"

La philosophie audio de Paula est jetée à la poubelle (notamment la fréquence de replay libre) sur l'A3000+, pour la partie audio (cette puce fait d'autres choses) elle est juste là pour la compatibilité comme l'est le YM sur la machine d'Atari.
Les 8 canaux sonores 16 Bits qualité CD dont parle l'ingénieur n'ont effectivement rien à voir avec Paula.

Sur Falcon le SDMA c'est entre autre la matrice sonore qui se charge de faire le pont entres tous les composants (RAM, DSP, CODEC, etc.), une sorte de postier qui a 8 boites aux lettres à disposition pour réceptionner le courrier et 8 pour expédier.
Sur le 3000+ c'est un peu différent la partie triage se fait en toute fin. Elle est gérée par une puce de Philips appelé TDA8420.
Elle possède 2 entrées, sur l'une tu as Paula connecté dessus et sur l'autre le CODEC 16bits+Paula si tu veux l'entendre en même temps. La puce mixe si nécessaire le tout (si on veut utiliser Paula) et envoie ça sur ses 2 sorties sons.
Elle a d'autres fonctions comme le LMC du STE, elle peut servir de "mini équaliseur" puisqu'on peut modifier les basses, les aigus et le volume en temps réel.
Sur le 3000+ c'est comme sur Falcon avec son YM, on peut se passer de sa puce originelle (Paula) pour avoir du son.

Si tu veux plus que 8 voix sur Falcon tu pourrais très bien utiliser le 68K pour mixer des pistes supplémentaires comme le fait DigiBooster ou OctaMED sur Amiga pour outrepasser les limites de Paula.
Seulement sur Falcon il est plus judicieux de le faire au DSP car il est bien plus véloce et ça permet de décharger le 68030.
En terme de ratio qualité (fréquence) / nb de canaux, le DSP du Falcon bat le top de ce qui se faisait sur PC à l'époque avec la Gravis UltraSound (GUS).
Ecouter une musique XM 28 canaux comme la fameuse Onward de Jugi (la célèbre musique de la démo Dope par Complex) est tout à fait possible sur Falcon non overclocké.
Cela dit des Demomakers utilisent parfois la méthode de mixage au CPU pour conserver 100% de la puissance du DSP :)

"EDIT : J'ai une question pour toi Templeton, puisque tu t'y connais en technique. Le DSP du Falcon n'avait pas de capacité de calcul sur les flottants (si je ne me trompe pas), juste sur les entiers. Celui prévu pour l'Amiga avait une capacité de calcul sur les flottants (simple précision, même si pour moi c'est pas parlant). Dave Haynie dit que dans ce cas le DSP calcul 10 fois plus vite qu'un 68040. Te parait il plausible que ce DSP ait pu servir à la façon d'un coprocesseur mathématique pour les logiciels de rendu 3D de type Lightwave, POV etc... ? Comme il parle de simple précision, je suppose que les coprocesseurs mathématique de Motorola sont plus précis, mais pour un particulier cela aurait il été suffisant pour la 3D (rendu et pourquoi pas en jeux texturés) ? Pour l'affichage des Jpeg cela aurait il permis un gain par rapport au DSP du Falcon, même question pour le MP3 ?"

Virgule fixe ou flottant c'est "juste" une représentation des données qui diffère, tu peux très bien faire du flottant avec un DSP à virgule fixe et vice verca, même s'il vaut mieux utiliser le DSP dans le registre pour lequel il a été conçu histoire de maximiser au mieux ses perfs.
Maintenant, oui, le DSP du 3000+ aurait pu être utilisé pour faire un renderer 3D (lourde tache) ou afficher plus rapidement les polygones quand tu fais de la modélisation.
Pour ce qui est des codecs MPEG ou JPG, désolé mais leurs algos sont pensés en virgule fixe donc les DSP de ce type sont avantagés. Même encore aujourd'hui c'est le cas avec un codec comme le H.264.

"Il y a forcément comparaison avec le DSP du Falcon et donc des choses sont avancé pour expliquer qu'au final le DSP du Falcon est moins bien. Pourrait tu donner ton opinion (impartiale n'est ce pas  smile)  ?"

Je t'avais déjà répondu il me semble sur un autre topic, essaie de retrouver le message
Ils ont chacun leurs atouts et leurs inconvénients.
Mais en terme de performance pure (nombre d'instructions par secondes) la famille des DSP 56K est beaucoup plus rapide à fréquence égale que celle des AT&T implémenté par Commodore.
Le DSP choisi sur le 3000+ c'est 12.5MIPS à 50MHz, sur le Falcon c'est 16 MIPS à 32 MHz en sachant qu'il est facilement overclockable à 50MHz et qu'à cette fréquence tu obtiens 25 MIPS... comme on dit si bien, ya pas photo !
Bref à fréquence identique le 56001 est 2 fois plus véloce.
Le fanboy Amiga qui est venu trôler à l'époque sur fr.comp.sys.atari voulait s'auto-persuader que Commodore avait fait le bon choix mais quand il dit que le DSP d'AT&T est meilleur, il n'apporte aucun argument, il donne juste la fiche technique du DSP fourni par le constructeur.
Honnêtement je ne sais pas pourquoi C= a choisi un tel DSP, dans le domaine de l'acoustique pro ou le militaire, un DSP de type flottant a du sens mais pour le reste...

Les application grand public sont en général le domaine de prédilection des DSP à virgule fixe.
La majorité des DSP vendu à l'époque était des DSP à virgule fixe (et encore, majorité le mot est faible, au-dessus de 90% de parts de marché) et ceux de Motorola comme celui sur le Falcon ou le Next faisaient parti des best sellers.
Avec ce choix Commodore s'était isolé car pour trouver des exemples ou de l'aide cela aurait été dur dur pour les programmeurs, même si il vrai que le flottant permet de concevoir ses algo plus facilement...

Prendre un DSP 56k c'est rester dans un environnement Motorola connu, possédant son propre écosystème déjà bien fourni (libs, programmes, etc.) et qui permet donc d'échanger et porter ses programmes facilement.
De toute façon en règle général les DSP à virgule flottante sont plus lents, plus chers et chauffent plus.

Donc selon moi même si l'A3000+ était sorti, dans la majorité des cas le Falcon l'aurait devancé.
D'ailleurs pour l'anecdote, si les cartes Delphina sorties bien des années plus tard pour le 1200/4000 utilisent les DSP de la même famille que ceux sur Falcon ce n'est pas pour rien

"Une spécification a retenue mon attention :
"Barrel Shifter for bit manipulation in graphics or data encryption."
On dirait bien que le DSP 3210 avait une gestion graphique intégrée, donc des moteurs graphiques auraient pu être envisagé pour tel ou tel type de domaine."

Tu sais il y a aussi un barrel shifter dans le 68020.
Si tu as un BLITTER performant cette spécification n'a pas beaucoup d'intérêt...

Cela me fait penser à ce thread sur EAB où se sont glissées quelques erreurs :

Le problème sur la liste disponible sur EAB, c'est que le gars qui a ouvert ce ''topic'' n'est pas capable de faire la différence entre 25 et 50 FPS, et il n'a pas compris que l'option intégré par Toni dans WinUAE ne permet pas de vérifier si le frame rate est mixte pendant un scrolling...
Dans le cas contraire Wilen aurait forcement inscrit 2 couleurs sur le bord de chaque ligne....

Du coup, comme le scrolling fausse l'analyse dans le cas d'une dichotomie, les 2 listes donné par dlfrsilver sont donc truffées d'erreurs!
Si on sait faire la différence entre 1 et 2 VBL avec ses yeux , pas besoin de WinUAE et l'astuce de Toni pour se rendre compte que le gars sur EAB fait hélas mal son boulot...

Je me demande si la méthode est fiable à 100%. Prenons Addams Familly par exemple, j'ai toujours trouvé à l'oeil que les sprites étaient à 25.

Elle est fiable à 100% si on peut arrêter le scrolling, dans le cas contraire....

Concernant Adams Family, comme toi j'ai le souvenir d'un scrolling superbe mais d'un déplacement saccadé (voir très saccadé ) des sprites, j'ai donc regardé comment fonctionnait le jeu et le résultat est décevant mais aussi étonnant. En effet, il y a 2 Frames Rates mise en place suivant la taille de chaque level !
Alors le verdict ? 3VBL et 4VBL !
Oui tu as bien lu même pas de 25FPS... Selon les niveaux, les sprites se déplacent soit en 16 FPS soit en 12 FPS !

[Zarnal]

Je me demande si la méthode est fiable à 100%. Prenons Addams Familly par exemple, j'ai toujours trouvé à l'oeil que les sprites étaient à 25.

Elle est fiable à 100% si on peut arrêter le scrolling, dans le cas contraire....

Concernant Adams Family, comme toi j'ai le souvenir d'un scrolling superbe mais d'un déplacement saccadé (voir très saccadé ) des sprites, j'ai donc regardé comment fonctionnait le jeu et le résultat est décevant mais aussi étonnant. En effet, il y a 2 Frames Rates mise en place suivant la taille de chaque level !
Alors le verdict ? 3VBL et 4VBL !
Oui tu as bien lu même pas de 25FPS... Selon les niveaux, les sprites se déplacent soit en 16 FPS soit en 12 FPS !

C'est bien cela, toujours à l'arrêt.

En déplacement scrolling à la VBL en gris.



Par contre pour ce sprite c'est directement le bleu.  



Et quelques trucs amusants :

Brian le lion AGA a une partie de ses sprites à 25. Les gros sprites sont bien à 50.




Putty Squad est entièrement à 25 (scroll+sprites).

[babsimov]

""Codec" c'est pas plutôt un composant qui gère le son du DSP pour lui donner les 8 voies."

Non, le DSP 56K est un microprocesseur, pas une puce sonore.
Le CODEC c'est une puce entièrement dédiée au son, dedans se trouve le DAC (CNA en français) qui est le convertisseur numérique analogique, sans ça le Falcon serait muet.
Dedans tu trouves aussi un ADC (l'inverse du DAC) pour numériser du son (via l'entrée sonore) et un additionneur 16Bits qui permet d'ajouter une autre source sonore, sur le Falcon c'est le Yamaha.

Dans le domaine audio, le DSP est utile si tu veux faire des choses en temps réel (mixer plein de voix, faires des echos, flanger, etc.) à la place du CPU car il va le décharger de ces taches qui sont trop lourdes pour lui.
Quand Dave Haynie dit "the DSP would have been able to give us at least eight channels of playback at full CD quality." il se base sur les performances du DSP sur le papier pour imaginer qu'il aurait été capable de mixer au moins 8 voix 16 Bits en 44.1KHz.

Merci de ces explications, c'est un peu plus clair pour moi maintenant. 

"Tel que je le comprends, dans le cas du 3000+ PAULA aurait rempli un peu le rôle du SDMA (c'est à dire fournir le son de base) et le DSP aurait ajouté 8 voies 16 bits). Ce qui signifie que le Falcon devait donc pouvoir avoir au moins 16 voix 16 bits ? 8 de SDMA et 8 du DSP ?"

La philosophie audio de Paula est jetée à la poubelle (notamment la fréquence de replay libre) sur l'A3000+, pour la partie audio (cette puce fait d'autres choses) elle est juste là pour la compatibilité comme l'est le YM sur la machine d'Atari.
Les 8 canaux sonores 16 Bits qualité CD dont parle l'ingénieur n'ont effectivement rien à voir avec Paula.

Sur Falcon le SDMA c'est entre autre la matrice sonore qui se charge de faire le pont entres tous les composants (RAM, DSP, CODEC, etc.), une sorte de postier qui a 8 boites aux lettres à disposition pour réceptionner le courrier et 8 pour expédier.
Sur le 3000+ c'est un peu différent la partie triage se fait en toute fin. Elle est gérée par une puce de Philips appelé TDA8420.
Elle possède 2 entrées, sur l'une tu as Paula connecté dessus et sur l'autre le CODEC 16bits+Paula si tu veux l'entendre en même temps. La puce mixe si nécessaire le tout (si on veut utiliser Paula) et envoie ça sur ses 2 sorties sons.
Elle a d'autres fonctions comme le LMC du STE, elle peut servir de "mini équaliseur" puisqu'on peut modifier les basses, les aigus et le volume en temps réel.
Sur le 3000+ c'est comme sur Falcon avec son YM, on peut se passer de sa puce originelle (Paula) pour avoir du son.

La aussi merci de ces précisions, notamment pour le TDA8420. Je conclu que le 3000+ aurait pu fournir 4 voies 8 bit + 8 voies 16 bits (ça aurait pas fait de mal à l'Amiga).

Remarque importante, tel que je comprends tes explications, même avec un DSP 3210 dans l'Amiga, le Falcon aurait eu l'avantage en terme de son, puisqu'il aurait été capable d'avoir le YM+SDMA+DSP, là ou l'Amiga aurait eu PAULA+DSP seulement. 

Si tu veux plus que 8 voix sur Falcon tu pourrais très bien utiliser le 68K pour mixer des pistes supplémentaires comme le fait DigiBooster ou OctaMED sur Amiga pour outrepasser les limites de Paula.
Seulement sur Falcon il est plus judicieux de le faire au DSP car il est bien plus véloce et ça permet de décharger le 68030.

C'est aussi mon avis, pour le son il semble plus judicieux d'utiliser le DSP.

En terme de ratio qualité (fréquence) / nb de canaux, le DSP du Falcon bat le top de ce qui se faisait sur PC à l'époque avec la Gravis UltraSound (GUS).
Ecouter une musique XM 28 canaux comme la fameuse Onward de Jugi (la célèbre musique de la démo Dope par Complex) est tout à fait possible sur Falcon non overclocké.

C'est bien pour ça que je suis convaincu que l'ajout d'un DSP à la génération AGA n'aurait pas été un luxe. Cette génération, en terme de hardware, n'avait pas grand chose pour elle face au PC (à l'époque on le savait juste pas complètement). 

Je l'ai déjà dit, j'ai toujours admiré Atari pour le Falcon. Pour une fois ils ont sortit quelque chose de vraiment intéressant. Quel dommage de l'avoir lâché quasiment aussitôt.

Cela dit des Demomakers utilisent parfois la méthode de mixage au CPU pour conserver 100% de la puissance du DSP :)

Ca doit dépendre de ce qu'ils veulent faire comme effet, je suppose.

"EDIT : J'ai une question pour toi Templeton, puisque tu t'y connais en technique. Le DSP du Falcon n'avait pas de capacité de calcul sur les flottants (si je ne me trompe pas), juste sur les entiers. Celui prévu pour l'Amiga avait une capacité de calcul sur les flottants (simple précision, même si pour moi c'est pas parlant). Dave Haynie dit que dans ce cas le DSP calcul 10 fois plus vite qu'un 68040. Te parait il plausible que ce DSP ait pu servir à la façon d'un coprocesseur mathématique pour les logiciels de rendu 3D de type Lightwave, POV etc... ? Comme il parle de simple précision, je suppose que les coprocesseurs mathématique de Motorola sont plus précis, mais pour un particulier cela aurait il été suffisant pour la 3D (rendu et pourquoi pas en jeux texturés) ? Pour l'affichage des Jpeg cela aurait il permis un gain par rapport au DSP du Falcon, même question pour le MP3 ?"

Virgule fixe ou flottant c'est "juste" une représentation des données qui diffère, tu peux très bien faire du flottant avec un DSP à virgule fixe et vice verca, même s'il vaut mieux utiliser le DSP dans le registre pour lequel il a été conçu histoire de maximiser au mieux ses perfs.
Maintenant, oui, le DSP du 3000+ aurait pu être utilisé pour faire un renderer 3D (lourde tache) ou afficher plus rapidement les polygones quand tu fais de la modélisation.
Pour ce qui est des codecs MPEG ou JPG, désolé mais leurs algos sont pensés en virgule fixe donc les DSP de ce type sont avantagés. Même encore aujourd'hui c'est le cas avec un codec comme le H.264.

Merci de me confirmer ce que je supposais pour la 3D et le DSP3210, comme quoi ce n'était pas un ajout inutile et exotique   

Pour le JPEG et MPEG, le DSP 3210 faisait aussi du calcul fixe, donc il aurait pu servir aussi, je me trompe ?

"Il y a forcément comparaison avec le DSP du Falcon et donc des choses sont avancé pour expliquer qu'au final le DSP du Falcon est moins bien. Pourrait tu donner ton opinion (impartiale n'est ce pas  smile)  ?"

Je t'avais déjà répondu il me semble sur un autre topic, essaie de retrouver le message 
Ils ont chacun leurs atouts et leurs inconvénients.
Mais en terme de performance pure (nombre d'instructions par secondes) la famille des DSP 56K est beaucoup plus rapide à fréquence égale que celle des AT&T implémenté par Commodore.
Le DSP choisi sur le 3000+ c'est 12.5MIPS à 50MHz, sur le Falcon c'est 16 MIPS à 32 MHz en sachant qu'il est facilement overclockable à 50MHz et qu'à cette fréquence tu obtiens 25 MIPS... comme on dit si bien, ya pas photo !
Bref à fréquence identique le 56001 est 2 fois plus véloce.
Le fanboy Amiga qui est venu trôler à l'époque sur fr.comp.sys.atari voulait s'auto-persuader que Commodore avait fait le bon choix mais quand il dit que le DSP d'AT&T est meilleur, il n'apporte aucun argument, il donne juste la fiche technique du DSP fourni par le constructeur.
Honnêtement je ne sais pas pourquoi C= a choisi un tel DSP, dans le domaine de l'acoustique pro ou le militaire, un DSP de type flottant a du sens mais pour le reste...

Oui, je me souviens qu'on avait abordé ce point dans un autre sujet. Le lien que j'ai cité me semblait juste plus précis et complet sur le DSP 3210, c'est pour ça que je t'ai posé cette question.

Je dois bien admettre que je pensais que Commodore avait choisit un meilleur DSP (32 bit, virgule flottante) face au DSP 56001, mais que tes propos me font douter. C'est bien dommage qu'on ait pas vu ce match dans la réalité.

Du coup je te rejoins sur le choix de Commodore.

Les application grand public sont en général le domaine de prédilection des DSP à virgule fixe.
La majorité des DSP vendu à l'époque était des DSP à virgule fixe (et encore, majorité le mot est faible, au-dessus de 90% de parts de marché) et ceux de Motorola comme celui sur le Falcon ou le Next faisaient parti des best sellers.
Avec ce choix Commodore s'était isolé car pour trouver des exemples ou de l'aide cela aurait été dur dur pour les programmeurs, même si il vrai que le flottant permet de concevoir ses algo plus facilement...

Prendre un DSP 56k c'est rester dans un environnement Motorola connu, possédant son propre écosystème déjà bien fourni (libs, programmes, etc.) et qui permet donc d'échanger et porter ses programmes facilement.
De toute façon en règle général les DSP à virgule flottante sont plus lents, plus chers et chauffent plus.

Je suppose que les ingénieurs de Commodore avaient leurs raisons. L'OS multitâche du DSP3210 est mis en avant de leur part, c'est peut être ça qui a fait la différence. Il est aussi expliqué qu'AT&T et Commodore ont travaillé ensemble pour intégrer cet OS à l'environnement AmigaOS et pour avoir les outils de développement adapté au DSP3210. 

C'est certain que les programmeurs n'auraient pas pu porter directement leur logiciel DSP 56000 sur le DSP 3210, mais je suppose qu'ils auraient su adapter aussi. Dommage qu'on n'ait pas pu voir ça. 

Donc selon moi même si l'A3000+ était sorti, dans la majorité des cas le Falcon l'aurait devancé.
D'ailleurs pour l'anecdote, si les cartes Delphina sorties bien des années plus tard pour le 1200/4000 utilisent les DSP de la même famille que ceux sur Falcon ce n'est pas pour rien 

C'est peut être aussi une question de coût aussi. Ca date de 1996 aussi, sans l'existence de DSP officiel Commodore/ESCOM, c'est pas trop étonnant je pense. Et cette carte, si je ne me trompe pas, ne fait que de l'audio ?

J'ai trouvé un lien vers la présentation d'une carte DSP pour Amiga 2000 datant de 1990. Il semble bien que ce soit déjà un DSP AT&T qui avait été choisit :
https://groups.google.com/forum/#!topic/comp.dsp/KHtalVGLwTk

Il est dit que le DSP de Motorola est moins bon. La carte aurait pu avoir 2 DSP AT&T.

Je ne me souviens pas que cette carte soit sortie, cependant.

"Une spécification a retenue mon attention :
"Barrel Shifter for bit manipulation in graphics or data encryption."
On dirait bien que le DSP 3210 avait une gestion graphique intégrée, donc des moteurs graphiques auraient pu être envisagé pour tel ou tel type de domaine."

Tu sais il y a aussi un barrel shifter dans le 68020.
Si tu as un BLITTER performant cette spécification n'a pas beaucoup d'intérêt..

J'ignorais cela. Le Blitter de l'AGA n'était non plus une bête de course, cette fonction aurait peut être pu aider ?