Re: GUERRE ST-AMIGA, FIGHT !!!

[TotOOntHeMooN]

Mais justement, il s'est octroyé un monopole. Ceux qui s'octroie un monopole c'est pas trop génial en général.
J'espère qu'il sera possible de contourner ça.

De plus, c'est grace aux schémas des cartes Apollo qu'il a pu apprendre pour faire le design de ses cartes...
Et jusqu'à maintenant, il n'a pas vraiment de concurent sérieux et seul Phase 5 peut l'inquiéter.

Quand à Appolo Team, je leurs reproche principalement de ne pas savoir s'arrêter à un but fixe.
A toujours vouloir faire évoluer leur core, ils mettent sur la touche les premier pocesseurs de Vampire V1. Perso, je ne trouve ça pas vraiment mieux que "Jens" car il en sera de même pour la V2 lorsqu'un FPGA plus gros verra naitre la V3. C'est l'enchère à la puissance et même si je respecte le travail de Majsta et ses Vampire, pour le moment il n'y a rien de rassurant à acheter.

[Invité]

la contrainte étant qu'il n'y a qu'un bus à partager pour les accès CPU

Non puisque la fast est là pour ça, donner les cycles CPU au blitter,pendant que le CPU lui utilise 100% de ses cycles avec la fast .
Là le CPU et le blitter ne partagent plus rien, et fonctionnent à 100% en // tout les 2 .

Plus exactement donc, le blitter est bloqué par les autres composants.

Bah forcement, pendant l'affichage le blitter ne peut pas se permettre de prendre les ressources du copper ou du son, tu imagines bien les conséquences sinon .

Toutefois, le blitter du STE peut fonctionner pendant l'affichage, pas celui de l'Amiga.   

Mais bien sur que si, et heureusement d'ailleurs,mais il serra forcement moins efficace que hors affichage .

Mais le blitter d'Atari n'est pas si nul que ça

Es ce que j'ai dit le contraire ??   
C'est pas le blitter qui pose porblème, mais l'archi générale du ST/STE qui n'est pas prévu pour du fonctionnement //, c'est du soit l'un soit l'autre point barre .

. Ce n'est pas du bricolage. 

Si, vu que le blitter n'est pas capable de fonctionner au max, même pendant le vblank à cause du MMU,et qu'il bloque le CPU(cool qd tu dois jouer des samples,ou faire des effets hsync sur ST ou MST,TT,ou le hsync sur STE) .
Tu vois avec l'amiga le copper est capable de le piloter ,pendant que le CPU fait ses calculs,pas besoin d'utiliser les interruptions lentes du 68k pour les fins de blits 
Ca c'est pas une archi "credit la bricole" comme sur ST/STE .

[rocky007]

le vrai problème du blitter sur ST, c'est que la moitié des ST n'en possèdent pas, il n'a donc pas été exploité comme il l'aurait été si présent dans tous les ST.

[Invité]

le vrai problème du blitter sur ST, c'est que la moitié des ST n'en possèdent pas, il n'a donc pas été exploité comme il l'aurait été si présent dans tous les ST.

Ca c'est sur qu'il aurait apporté au ST, mais tu peux dire adieux au code timé,effets via interrutpions, avec utilisation du blitter .

[babsimov]

Il explique que la direction a obligé à stopper tout travail sur le DSP et à le retirer de la carte mère, qui ne pouvait servir qu'à titre de "recherche".

donc rien ne prouve que cela fonctionnait

Dave Haynie n'a rien à prouver. Surtout qu'il a dit tout cela après la faillite, justement pour que la communauté sache ce qu'elle a manqué.

Tu m'excusera de ne pas avoir lu ST magazine à l'époque. Pour moi, de mémoire c'était pour Novembre 1992.

tu m'excuseras d'être précis

Oui, pour une fois ça change 

Atari a donc présenté sa machine en Novembre 92 et l'a mis en vente en Avril 93, six mois après... Donc comme ils mettent six mois pour faire le "design" d'une machine, en fait c'était un proto non finalisé qu'ils ont présenté.

pff, mais qu'en sais-tu franchement ? crois tu qu'un retard est uniquement dû à un produit non finit ?  tu crois que les problèmes de fabrications, de fournisseurs, de trésorerie, de logistique etC.etc.. ne ralentit pas non plus le processus de commercialisation ?

C'était une boutade pour te provoquer, ça a fonctionné   

Dans Tilt ils disaient bien qu'il y avait un modèle en version finale de présenté (à côté d'un prototype). Comme je t'ai dit je voulais voir si tu allais réagir. Après tout, parfois tu as volontairement fait de la provocation pour me pousser à bout (et tu as réussi). Mais je n'irais pas aussi loin que toi.

Mais, pas du tout, nous parlons là des logiciels système, je n'ai pas perdu mes logiciels bureautique en passant sur Amiga 1200. On dirait que ce n'était pas le cas en passant sous MultiTOS.

parce que les programmes que tu avais étais correctement codé.  j'ai testé plein de soft ST sur Falcon, je n'ai eu aucun problème.

Avec le MultiTOS ?

Ca montre bien que si on respectait les consignes de Commodore dès le départ, pas de problème.

Et il bride surement lui aussi le 68030 dans le Falcon. Tu vois, c'est bien ce que je dis, toute la gamme se traine les bridages issus du premier ST, conçu trop vite.

il bride pas, il est inutile, nuance

Ben non, il est indispensable pour être compatible avec le ST, comme le bus 16 bit si j'ai bien compris. Donc quand il est utilisé par un logiciel écrit par le STE, il doit bien bloquer le processeur.

Commodore n'est pas responsable de la façon dont les protections étaient écrites.

de toute façon cela revient au même : une protection c'est quoi ?  c'est du software.  donc ils ont sorti un ordinateur non compatible avec 30% des logiciels, et nécessite la modification de ces derniers pour fonctionner.

Parce que maintenant Commodore aurait du modifier sa machine pour tenir compte de protection qui, la plus part du temps, utlisait des hacks et tricks qui ne respectaient pas la moindre des consignes de programmation de Commodore ? C'est le monde à l'envers ça.

J'avais bien compris. Les transputers ne se sont pas vendu, c'est surement parce qu'ils n'avaient pas l'intéret que tu prétends. Silicon Graphics étaient LA référence du graphisme pro.

pourquoi les transputer étaient utlisé de consoeur les silicons graphics

Les transputers ATARI ?

J'ai pas l'impression que ce soit bien répandu quand même :
http://www.verycomputer.com/16_5ac39942697f3668_1.htm
http://www.verycomputer.com/119_b834962760c9ea39_1.htm

Mais si tu as des informations, ce serait intéressant.

En tout cas, chez Atari ce ne fut pas un succès :
https://en.wikipedia.org/wiki/Atari_Transputer_Workstation

[th]Units shipped[/th]

350[1]

Très proche ? Toi même tu as dit que c'était pas faisable sur un C64 !
Je t'ai déjà expliqué, ils ne savent même pas comment fonctionne un ST ou un Amiga. Fallait pas attendre autre chose.

tel que présenté oui, mais le résultat possible sur C64 pourrait être très proche, en fait seul le framerate serait différent.  donc oui, c'est assez fidèle

C'est à géométrie variable avec toi, tu disais que c'était pas possible et maintenant à peut être que c'est assez proche. Ce terme veut dire "ils ont fait n'importe quoi, en proposant au public quelque chose qui ressemble de loin à ce que la technologie de l'époque, ne pouvait pas faire en fait".

Nombreux, vous êtes quand même pas beaucoup en dehors de ce forum.

va voir sur atariage et rends toi compte de la communauté Atari

C'est marrant, j'avais lu ici que sur Atariage, y avait pas débat, l'Amiga était devant.

Ben non on a vu les chiffres, le ST s'est mal vendu.

Les joueurs veulent toujours mieux, ne t'en déplaise.

non, j'ai cité les sources des 8.000.000 d'atari vendu.   
les joeurs ? pq certains ont acheté une megadrive plutot qu'un Snes ? pq bcp préfère la ¨gamecube à la PS1 ?  bref, c'est pas toujours qu'une question de qui a la plus grosse 

Et d'autres sources donnent 2 millions...

En règle général, un joueur ira toujours vers la machine qui en offre toujours plus techniquement. C'est ce qui a fait que le PC est entré chez monsieur tout le monde, quand les jeux sont devenus tout 3D texturé, d'abord software, puis hardware.

La Playstation, elle a du son succès à ses jeux ou au fait que c'était la première à avoir de la 3D texturé jolie et rapide ? 

Deux ou trois ici, ça fait plusieurs oui. Du reste toujours les mêmes.

idem du coté amiga, 2-3, toujours les mêmes

Tu oublies ceux les anciens Ataristes passé sur Amiga qui sont venu parfois dire, au fil du débat, qu'ils aimaient bien leur ST, mais qu'une fois sur Amiga c'était un autre monde qui s'ouvrait à eux.

Un ST émuler un PC ? En software, surement pas (ou à la vitesse d'un escargot). Du reste l'Amiga même chose.

cela émulait un 8086 en software, largement suffisant pour le travaux de bureautique

Ca ramait quand même bien, si mon souvenir est bon. Mais c'est vrai c'est les quelques hertz de plus du ST qui font toute la différence 

Si c'était juste l'utilisateur. Relis les réponses ici, tu verras que beaucoup sont allé dans mon sens.

je crois que tu es le seul à avoir découvert internet sur un amiga

Pas de chance, j'en ai connu plusieurs, dont le redacteur en chef d'AmigaNew à l'époque. C'est même lui qui m'a inscrit sur Internet à l'époque depuis son Amiga. 

On a vu que le multitâche de l'Amiga fonctionnait bien, sans plantage.
 nombreux témoignage ici disent le contraire.

et "guru medatation" est célèbre dans le monde, ce n'est pas pour rien

Je ne dis pas qu'il n'y avait pas de plantage, juste que pas à chaque boot ou à chaque programme comme tu le prétend. Tes vidéo on même montré que ce n'était pas le cas.

[Meditating Guru]

la contrainte étant qu'il n'y a qu'un bus à partager pour les accès CPU

Non puisque la fast est là pour ça, donner les cycles CPU au blitter,pendant que le CPU lui utilise 100% de ses cycles avec la fast .
Là le CPU et le blitter ne partagent plus rien, et fonctionnent à 100% en // tout les 2 .

Oui mais je comparais sans fast ram, quand il faut tout partager (Amiga 500?).
Et dans ce cas, on ne peut bien sûr avoir CPU + Blitter + Shifter pendant l'affichage.  

. Ce n'est pas du bricolage. 

Si, vu que le blitter n'est pas capable de fonctionner au max, même pendant le vblank à cause du MMU,et qu'il bloque le CPU(cool qd tu dois jouer des samples,ou faire des effets hsync sur ST ou MST,TT,ou le hsync sur STE) .
Tu vois avec l'amiga le copper est capable de le piloter ,pendant que le CPU fait ses calculs,pas besoin d'utiliser les interruptions lentes du 68k pour les fins de blits 
Ca c'est pas une archi "credit la bricole" comme sur ST/STE .

C'est une architecture plus simple, pas fautive, à nouveau les délais, et finalement le Blitter n'était même pas sur les premiers ST. Il y avait des compromis sur cette machine géniale? Certes.
Le blitter ne bloque totalement le CPU qu'en mode Hog. En mode Blit, les cycles sont partagés moitié moitié chaque scanline, donc le CPU ne va rien louper, sauf si on programme au cycle près, mais même ça c'est possible parce que les cycles sont plus faciles à déterminer qu'avec l'Amiga.
En pratique, il y a des demos "fullscreen" avec blitter.

Le bricolage    de l'Amiga est plus complexe, il permet de gagner quelques cycles, mais est délicat (plantage TAS et autres Guru Meditation en veux tu en voilà).

[babsimov]

Mais justement, il s'est octroyé un monopole. Ceux qui s'octroie un monopole c'est pas trop génial en général.
J'espère qu'il sera possible de contourner ça.

De plus, c'est grace aux schémas des cartes Apollo qu'il a pu apprendre pour faire le design de ses cartes...
Et jusqu'à maintenant, il n'a pas vraiment de concurent sérieux et seul Phase 5 peut l'inquiéter.

Quand à Appolo Team, je leurs reproche principalement de ne pas savoir s'arrêter à un but fixe.
A toujours vouloir faire évoluer leur core, ils mettent sur la touche les premier pocesseurs de Vampire V1. Perso, je ne trouve ça pas vraiment mieux que "Jens" car il en sera de même pour la V2 lorsqu'un FPGA plus gros verra naitre la V3. C'est l'enchère à la puissance et même si je respecte le travail de Majsta et ses Vampire, pour le moment il n'y a rien de rassurant à acheter.

Je pense qu'on est hors sujet là. Ne continuons pas dans ce sujet. Même le sujet Amiga officiel ne me parait pas indiqué, c'est trop polémique.

[Invité]

Oui mais je comparais sans fast ram, quand il faut tout partager (Amiga 500?).
Et dans ce cas, on ne peut bien sûr avoir CPU + Blitter + Shifter pendant l'affichage. 

Bah non justement sur amiga tout est prévu dés le départ, c'est pas du petit bonheur la chance,les perfs max sont avec de la fast .
Mais sans fast le blitter fonctionne pendant l'affichage, mais forcement pas au max .

En mode Blit, les cycles sont partagés moitié moitié chaque scanline, donc le CPU ne va rien louper

Tu parles comme si le blitter et le CPU avaient toute la scanline, n'oublies pas qu'en plein affichage tu as peu de cycles dispos,donc oui tu peux rater des trucs,surtout avec des accès mémoire en 4 cycles ou plus .
N'oublies pas que rien que la prise d'interruption c'est 64 cycles sur 68k .

En pratique, il y a des demos "fullscreen" avec blitter.

En tout cas leonard dans sa dernière demo, a été obligé de faire des effets tout au CPU pour pas le bloquer avec le blitter .

[rocky007]

Dave Haynie n'a rien à prouver. Surtout qu'il a dit tout cela après la faillite, justement pour que la communauté sache ce qu'elle a manqué.

tu le connais personnellement ? donc partant de ton postulat quand les grand ingénieurs n'ont rien à prouvé, tout ce que Shiraz dit est correct et jamais il ne faut le remettre en question

Ca montre bien que si on respectait les consignes de Commodore dès le départ, pas de problème.

tout comme chez Atari

Ben non, il est indispensable pour être compatible avec le ST, comme le bus 16 bit si j'ai bien compris. Donc quand il est utilisé par un logiciel écrit par le STE, il doit bien bloquer le processeur.

vu que c un soft STe ce n'est pas bien grave, je ne vois pas où est le problème.  c'est bcp plus problématique par contre de garder une vieux chip sonore démodé de 1979 probablement pour garder la compatibilité A500

Parce que maintenant Commodore aurait du modifier sa machine pour tenir compte de protection qui, la plus part du temps, utlisait des hacks et tricks qui ne respectaient pas la moindre des consignes de programmation de Commodore ? C'est le monde à l'envers ça.

donc voilà, tu l'avoues toi même : le A1200 n'est pas compatible avec les softs ne respectant pas les consignes, exactement comme le falcon

Mais si tu as des informations, ce serait intéressant.

non désolé, je sais juste que Pixar utilisait des Transputer au début.  mais franchement, j'y connais pas grand chose dans ce domaine

C'est à géométrie variable avec toi, tu disais que c'était pas possible et maintenant à peut être que c'est assez proche. Ce terme veut dire "ils ont fait n'importe quoi, en proposant au public quelque chose qui ressemble de loin à ce que la technologie de l'époque, ne pouvait pas faire en fait".

ben non, ta question était si c'était possible : ma réponse était non, même si un résultat assez proche est possible.  encore une fois, désolé d'être précis.  

C'est marrant, j'avais lu ici que sur Atariage, y avait pas débat, l'Amiga était devant.

sur l'hardware, oui, bien sûr...va plutot lire atariage plûtot que les commentaires biaisés d'amigaistes ici

En règle général, un joueur ira toujours vers la machine qui en offre toujours plus techniquement. C'est ce qui a fait que le PC est entré chez monsieur tout le monde, quand les jeux sont devenus tout 3D texturé, d'abord software, puis hardware.

La Playstation, elle a du son succès à ses jeux ou au fait que c'était la première à avoir de la 3D texturé jolie et rapide ?

non le joueur ira chez la machine que lui sera la mieux vendue, selon ses besoins et désirs, et pas forcément la meilleure.  sinon pourquoi il y aurait des acheteurs Xbox One ?

la playstation doit son succès probablement au piratage de masse

Tu oublies ceux les anciens Ataristes passé sur Amiga qui sont venu parfois dire, au fil du débat, qu'ils aimaient bien leur ST, mais qu'une fois sur Amiga c'était un autre monde qui s'ouvrait à eux.

tu oublies ceux qui ont eu un ST, puis un Amiga, et finalement ont préféré le ST

Ca ramait quand même bien, si mon souvenir est bon. Mais c'est vrai c'est les quelques hertz de plus du ST qui font toute la différence 

oui c'était pas super, mais pour bosser sur un traitement texte ou un tableur, je pense que c'était suffisant

Pas de chance, j'en ai connu plusieurs, dont le redacteur en chef d'AmigaNew à l'époque. C'est même lui qui m'a inscrit sur Internet à l'époque depuis son Amiga.

vous êtes deux alors... en tous cas, t'es le premier que je connais en tous cas

Je ne dis pas qu'il n'y avait pas de plantage, juste que pas à chaque boot ou à chaque programme comme tu le prétend. Tes vidéo on même montré que ce n'était pas le cas.

j'ai dû m'y reprendre à plusieurs fois ( véridique ! )

[Meditating Guru]

Oui mais je comparais sans fast ram, quand il faut tout partager (Amiga 500?).
Et dans ce cas, on ne peut bien sûr avoir CPU + Blitter + Shifter pendant l'affichage. 

Bah non justement sur amiga tout est prévu dés le départ, c'est pas du petit bonheur la chance,les perfs max sont avec de la fast .
Mais sans fast le blitter fonctionne pendant l'affichage, mais forcement pas au max .

C'est cela, oui. Comme les Amiga 500 avec de la vraie fast ram étaient super rares, les programmes... pardon, les jeux n'exploitaient pas cette possibilité.  

En mode Blit, les cycles sont partagés moitié moitié chaque scanline, donc le CPU ne va rien louper

Tu parles comme si le blitter et le CPU avaient toute la scanline, n'oublies pas qu'en plein affichage tu as peu de cycles dispos,donc oui tu peux rater des trucs,surtout avec des accès mémoire en 4 cycles ou plus .
N'oublies pas que rien que la prise d'interruption c'est 64 cycles sur 68k .

Non je dis juste que le CPU a la main chaque scanline, il ne reste pas bloqué pendant des siècles.
Mais partage des cycles il y a.

En pratique, il y a des demos "fullscreen" avec blitter.

En tout cas leonard dans sa dernière demo, a été obligé de faire des effets tout au CPU pour pas le bloquer avec le blitter .

A ma connaissance, lui aussi a fait des demos fullscreen avec blitter. Un cas n'est pas l'autre.

[babsimov]

Dave Haynie n'a rien à prouver. Surtout qu'il a dit tout cela après la faillite, justement pour que la communauté sache ce qu'elle a manqué.

tu le connais personnellement ? donc partant de ton postulat quand les grand ingénieurs n'ont rien à prouvé, tout ce que Shiraz dit est correct et jamais il ne faut le remettre en question

Non, bien entendu, mais il est connu dans la communauté Amiga et ses propos ont été corroboré par d'autres interview et d'autres anciens de Commodore dans plusieurs salon Amiga.

Shiraz Shijvi, un grand ingénieur... ben quand on lit l'interview que j'avais cité, il en raconte des trucs incohérents. En fait j'avais commencé à lire son interview le plus sérieusement du monde et au fil de ma lecture j'éclatais presque de rire à chacune de ses réponses. C'était plus de la communication pour faire rêver la communauté ST qu'autre chose. Il annonce des technologies pour 88/89 qui ne pourront être atteinte que dans le milieu des années 90 ! Il promet des choses qu'aucun modèle de ST/Falcon ne verra jamais, et il promet ça pour dans un an, deux au pire (de mémoire). C'est pas sérieux.

Mais, je ne demande qu'à lire une autre interview de lui où il est plus crédible, si tu en as une ?

Ca montre bien que si on respectait les consignes de Commodore dès le départ, pas de problème.

tout comme chez Atari

S'il y a un doute émis pour la compatibilité avec le MultiTOS ce que ce n'est peut être pas tout à fait le cas. Mais, je veux bien aller dans ton sens cependant.

Ben non, il est indispensable pour être compatible avec le ST, comme le bus 16 bit si j'ai bien compris. Donc quand il est utilisé par un logiciel écrit par le STE, il doit bien bloquer le processeur.

vu que c un soft STe ce n'est pas bien grave, je ne vois pas où est le problème.  c'est bcp plus problématique par contre de garder une vieux chip sonore démodé de 1979 probablement pour garder la compatibilité A500

Oui, c'est bien ce qu'ils ont fait dans le ST, un chip sonore 8 bits obsolète.

Tu as vu joué ça ou que Paula date de 1979 ? Le chipset Amiga (donc Paula) c'est 83/84 pour la version prototype en carte.

http://obligement.free.fr/articles/amiga_histoire_1983.php
http://obligement.free.fr/articles/amiga_histoire_1984.php

Comme déjà dit, est ce qu'un seul Amigaïste ici a prétendu être content que Paula ait été dans l'AGA ? Je ne crois pas. Il était tout à fait possible de changer Paula par mieux tout en restant compatible. La preuve :

http://obligement.free.fr/articles/chipsetamiga.php#mary


Mary est le contrôleur audio et de diverses entrées/sorties, c'est le remplaçant de Paula dans l'AAA.

Ses caractéristiques :

• Contrôleur audio 8 canaux stéréo de 8/16 bits avec échantillonnage jusqu'à 100 kHz.
  
• Les canaux peuvent être assignés à gauche ou à droite.
  
• Contrôleur disque gérant le format brut de 1, 2 et 4 Mo (2,88 Mo au format IBM) et tous les autres formats connus, y compris les disquettes Macintosh.
  
• Débit théorique de 11,4 Mo/s (20 fois plus que Paula).
  
• Décodage des formats GCR, MFM, RLL (2,7) et Biphase Mark.
  
• Gestion des périphériques comme les CD, les DAT et les radios numériques.
  
• Calcul de contrôle d'erreur CRC.
  
• Deux UART (émetteur-récepteur asynchrone universel) de 4 bits FIFO pour faire la liaison entre l'ordinateur et le port série.
  

C'était le seul composant du AAA qui était finalisé, il devait être réutilisé avec le chipset Hombre.

Le DSP du 3000+ était là pour compenser Paula dans l'AGA. Tout cela a été annulé par la direction, comme déjà expliqué. Le AA+ devait avoir une puce son qui semble assez proche de Mary.

Parce que maintenant Commodore aurait du modifier sa machine pour tenir compte de protection qui, la plus part du temps, utlisait des hacks et tricks qui ne respectaient pas la moindre des consignes de programmation de Commodore ? C'est le monde à l'envers ça.

donc voilà, tu l'avoues toi même : le A1200 n'est pas compatible avec les softs ne respectant pas les consignes, exactement comme le falcon

J'ai dit le contraire, je t'ai dit que les logiciels systèmes fonctionnaient directement. Ce que j'avais lu (à l'époque) c'est qu'avec le MultiTOS ce point là n'était pas totalement garantit. 

Mais si tu as des informations, ce serait intéressant.

non désolé, je sais juste que Pixar utilisait des Transputer au début.  mais franchement, j'y connais pas grand chose dans ce domaine

Mais, ça ne t'empêche pas de dire que c'était le plus puissant dans le domaine graphique.

Le Transputer, sur le papier ça faisait rêver (moi le premier), d'ailleurs quand Atari a sortit son Transputer je me suis dit "mais que fait Commodore". Plus tard, bien plus tard, j'ai pu lire que finalement le Transputer était surestimé.

C'est à géométrie variable avec toi, tu disais que c'était pas possible et maintenant à peut être que c'est assez proche. Ce terme veut dire "ils ont fait n'importe quoi, en proposant au public quelque chose qui ressemble de loin à ce que la technologie de l'époque, ne pouvait pas faire en fait".

ben non, ta question était si c'était possible : ma réponse était non, même si un résultat assez proche est possible.  encore une fois, désolé d'être précis.   

Un résultat assez proche pour toi c'est pareil qu'un résultat fidèle à ce qui était techniquement possible à l'époque ? Toi même tu viens, une fois de plus, de dire que ce n'était pas possible. Y a rien à ajouter, ils ont fait ce qu'ils voulaient pour raconter leur histoire qui n'a rien d'historique, mais juste une façon d'aborder des sujets actuels dans un contexte "original" des débuts de l'informatique. Les années 80 c'est à la mode.

EDIT : du reste le public visé (actuel) n'y a vu que du feu, pour eux, c'est du graphisme "année 80" donc c'est crédible. Autre remarque concernant les GUI, tu en as vu beaucoup dans la série, celle du premier MAC, celle de Windows95 et celle du Next. Normal dans "histoire officielles" il n'y a eu que le MAC, Windows95 et NeXT (MacOS X), le reste n'as pas vraiment existé pour le révisionnisme Apple/Microsoft. Le public qui a regardé ça n'y a vu que du feu. Ceux d'entres nous ont vu leurs machine d'époque, mais qui sont là comme anecdote et caution "historique" c'est tout. Tu n'aurais pas préféré qu'on le voit fonctionner le ST ou le TT, que l'un des personnage (surtout en 1985) disent que c'était au moins aussi bien qu'un MAC et moins cher ? Personnellement j'aurais bien aimé qu'on voit le workbench de l'Amiga au lieu d'un affichage qui n'avait rien à voir. J'aurais aimé que le personnage explique pourquoi il avait un Amiga chez lui. 
Mais tout ça ce n'était pas du tout le sujet de la série, comme déjà dit.

C'est marrant, j'avais lu ici que sur Atariage, y avait pas débat, l'Amiga était devant.

sur l'hardware, oui, bien sûr...va plutot lire atariage plûtot que les commentaires biaisés d'amigaistes ici

Les propos biaisé des ataristes ici me suffisent 

En règle général, un joueur ira toujours vers la machine qui en offre toujours plus techniquement. C'est ce qui a fait que le PC est entré chez monsieur tout le monde, quand les jeux sont devenus tout 3D texturé, d'abord software, puis hardware.

La Playstation, elle a du son succès à ses jeux ou au fait que c'était la première à avoir de la 3D texturé jolie et rapide ? 

non le joueur ira chez la machine que lui sera la mieux vendue, selon ses besoins et désirs, et pas forcément la meilleure.  sinon pourquoi il y aurait des acheteurs Xbox One ?

la playstation doit son succès probablement au piratage de masse

Mais bien sur, piratage CDROM à l'époque de la playstation 1... tu sais combien coutait un graveur de CDROM à l'époque, au moins le prix d'une playstation. Mais ça c'est le graveur, derrière il faut le PC qui va avec, le logiciel et pouvoir graver au format playstation. Sans parler du support réinscriptible qui coutait très cher. 

C'est bien plus tard que ça a commencé. Mais au début le CDROM était LE support qui était le plus "sur". 

Vers la fin de la carrière de la playstation, là on commençait à voir apparaître le phénomène, mais pas au début. Et dès le début la Playstation a écrasé les autres, justement parce que c'était vraiment un saut de génération technologique.

EDIT : Il suffisait à un joueur de simplement voir un jeu playstation pour immédiatement se rendre compte que c'était la console à acheter à cette époque.
Un titre me vient à l'esprit immédiatement : Ridge Racer. La première fois que je l'ai vu, j'en revenais pas (je n'ai pas acheté de Playstation, mais la machine m'avait impressionnée). J'ai déjà précisé que les consoles ne m'intéressait pas, c'est pour ça que je n'ai pas pris de console, mais graphiquement c'était une claque la playstation à l'époque.
Il y avait un jeu de combat aussi dont j'ai oublié le nom.

Tu oublies ceux les anciens Ataristes passé sur Amiga qui sont venu parfois dire, au fil du débat, qu'ils aimaient bien leur ST, mais qu'une fois sur Amiga c'était un autre monde qui s'ouvrait à eux.

tu oublies ceux qui ont eu un ST, puis un Amiga, et finalement ont préféré le ST

Ils sont assez rare quand même.

Comme déjà dit "il y a des poissons volants, mais qui ne constituent pas la majorité du genre".

Ca ramait quand même bien, si mon souvenir est bon. Mais c'est vrai c'est les quelques hertz de plus du ST qui font toute la différence  

oui c'était pas super, mais pour bosser sur un traitement texte ou un tableur, je pense que c'était suffisant

Tu penses mais tu n'a pas essayé. L'émulation software PC sur un 68000, c'était une curiosité rien de plus. 

Pas de chance, j'en ai connu plusieurs, dont le redacteur en chef d'AmigaNew à l'époque. C'est même lui qui m'a inscrit sur Internet à l'époque depuis son Amiga. 

vous êtes deux alors... en tous cas, t'es le premier que je connais en tous cas

Nous étions bien plus que ça. Comme je t'ai déjà dit, l'AmigaOS 3.x à cette époque n'avait pas à rougir face au PC, on pouvait y faire les mêmes choses au moins aussi bien et souvent mieux.

Je ne dis pas qu'il n'y avait pas de plantage, juste que pas à chaque boot ou à chaque programme comme tu le prétend. Tes vidéo on même montré que ce n'était pas le cas.

j'ai dû m'y reprendre à plusieurs fois ( véridique ! )

T'a vraiment pas de chance avec l'Amiga, on sait.

[Urbinou]

Ca ramait quand même bien, si mon souvenir est bon. Mais c'est vrai c'est les quelques hertz de plus du ST qui font toute la différence smile

Tes souvenirs sont bons babs, comme tu dis l'emulateur software pc, c'est une curiosité, de quoi dépanner, mais certainement pas bosser (j'ai tenté de faire un peu de dbase avec...)

Quant à la playstation mon cher guru, tu m'as bien faire rire avec ton piratage de masse, c'est une obsession dis-moi ? C'est surtout une assertion ridicule

[rocky007]

Shiraz Shijvi, un grand ingénieur...

oui je trouve...et toi tu ne trouves pas ?  qq'un capable de créer un ordinateur 16 bits en 6 mois , c'est de la merde ?

Le DSP du 3000+ était là pour compenser Paula dans l'AGA. Tout cela a été annulé par la direction, comme déjà expliqué. Le AA+ devait avoir une puce son qui semble assez proche de Mary.

le DSP ne peut pas compenser une sortie sonore limité.  Si la srotie est en 28Khz, tu ne pourras jamais avoir de la qualité CD, même avec un DSP.

Mais, ça ne t'empêche pas de dire que c'était le plus puissant dans le domaine graphique.

j'ai pas le dit * LE * plus puissant, mais faisant partie des plus puissants

Un résultat assez proche pour toi c'est pareil qu'un résultat fidèle à ce qui était techniquement possible à l'époque ? Toi même tu viens, une fois de plus, de dire que ce n'était pas possible. Y a rien à ajouter

qui a prétendu ici que c'est fidèle à 100% ?  personne... c'était très proche de la réalité, suffisamment pour se dire qu'ils voulait bel et bien montrer un PC et non un Amiga. (comme ils ont fait avec le Mac ou le Next )

Mais bien sur, piratage CDROM à l'époque de la playstation 1... tu sais combien coutait un graveur de CDROM à l'époque, au moins le prix d'une playstation. Mais ça c'est le graveur, derrière il faut le PC qui va avec, le logiciel et pouvoir graver au format playstation. Sans parler du support réinscriptible qui coutait très cher.

tu as tout faux : les graveurs existaient déjà depuis longtemps à la sortie de la playstation.  Je dis pas que tout le monde en possédait un, mais les pirates habituels étaient équipé depuis longtemps de Philips 2X et rapidement des Yamaha 4X lorsque que PS1 est sortie.  Les premières copies sont apparues immédiatement, puisque la protection était ultra bête : il suffisait de bloquer le bouton de détection capot avec un cure dent, démarrer un original pendant 3-4 sec, et ensuite l'échanger avec un jeu copié et ça bootait.  Donc tout un business a démarré avec cela, tu trouvais des copies partout à 50 FF.  Puis cela s'est industrialisé avec l'arrivé des premier modchip qui bootait directement les copies.  Non seulement il y avait sur le marché les copies gravées, mais aussi les copies pressées en usine venant tout droit de Chine.  Le marché était inondé de copie.  Il y avait à Hong Kong des immeubles comportant des centaines de boutiques, toutes vendant des copies pressées.  Donc oui, c'est le piratage de masse qui a probablement fait exploser les ventes de Playstation.  La aussi, les gens n'ont acheté la PS1 que parce qu'ils pouvaient avoir les jeux pas cher, voir gratuit.  Bien évidement c'était une super console.

C'est bien plus tard que ça a commencé. Mais au début le CDROM était LE support qui était le plus "sur".

j'ai possédé un graveur Philips dès que les premiers PC étaient équipé de CD ROM.  Il n'y avait aucune protection, faire des copies de CD ROM était un jeu d'enfant.  Par contre, en effet, j'avais dû me déplacer en UK pour l'acheter car ce n'était pas encore vendu en Belgique.  Mais cela ne change rien pour le piratage , tout comme pour amiga tu avais des sources pour tes jeux, là tu avais des sources pour avoir des CD ROMS copiés.

Vers la fin de la carrière de la playstation, là on commençait à voir apparaître le phénomène, mais pas au début. Et dès le début la Playstation a écrasé les autres, justement parce que c'était vraiment un saut de génération technologique.

La 3DO est sortie plus tôt, avec des jeux très impressionnants également et un gros saut technologique par rapport aux 16 bits.  A-t-elle connu le même succès que la PS1 ? non...pourtant son concept de console sous license était vraiment plus prometteur que la PS1.

Ils sont assez rare quand même.

rien que ce sur ce forum, ils sont tout aussi nombreux que les amigaistes, es-tu à ce point aveugle ?

Tu penses mais tu n'a pas essayé. L'émulation software PC sur un 68000, c'était une curiosité rien de plus.

oui je viens de voir les vidéos, c'est assez lent en effet.  mais bon, il y avait les cartes hardware

T'a vraiment pas de chance avec l'Amiga, on sait.

tout comme toi avec Win 95 et les modems

[Invité]

C'est cela, oui. Comme les Amiga 500 avec de la vraie fast ram étaient super rares, les programmes... pardon, les jeux n'exploitaient pas cette possibilité.  

Ah oui c'est vrai que l'amiga 500 était le seul amiga existant excuse moi, les AMIGA pros n'ont jamais existé dsl   
Ca montre une fois de plus que l'amiga a été conçu pour évoluer vers des machines plus puissantes,pour ceux qui avaient les moyens et les besoins, tout en restant abordable pour la majorité des gens .

Non je dis juste que le CPU a la main chaque scanline, il ne reste pas bloqué pendant des siècles. 
Mais partage des cycles il y a.

Ok, mais ça n'est tjrs pas équivalent à l'amiga car ce n'est pas un partage de cycles,donc plus efficace .

A ma connaissance, lui aussi a fait des demos fullscreen avec blitter. Un cas n'est pas l'autre.

Oui, mais il est obligé de faire des concessions sur le CPU, et ça veut pas forcement dire que ça tourne @50 fps .
Et d'ailleurs même leonard le dit que le blitter du STE n'est pas aussi performant que celui de l'amiga et qu'il ne tourne pas en // .
Y'a pas plus explicite comme argument .

[rocky007]

Oui, mais il est obligé de faire des concessions sur le CPU, et ça veut pas forcement dire que ça tourne @50 fps .
Et d'ailleurs même leonard le dit que le blitter du STE n'est pas aussi performant que celui de l'amiga et qu'il ne tourne pas en // .
Y'a pas plus explicite comme argument .

je t'ai déjà expliqué pas tout à fait vrai :

It might often not be possible to organize CPU code around BLiTTER
operations, but if you do, you might gain a lot of speed by placing
the right instructions directly in front of a BLiTTER operation.
As the BLiTTER might require a couple of cycles before actually doing
anything, the CPU usually has a chance of loading the next instruction
before the BLiTTER hogs the bus. If this instruction requires no
additional bus access, it will be carried out _in parallel_ to the
BLiTTER operation, making the Atari ST/STE a dual-processor system
for this short period.

[babsimov]

Shiraz Shijvi, un grand ingénieur...

oui je trouve...et toi tu ne trouves pas ?  qq'un capable de créer un ordinateur 16 bits en 6 mois , c'est de la merde ?

Je ne dis pas qu'il n'a pas fait le job (je l'ai déjà dit). Mais je ne le mettrais pas dans la même catégorie qu'un Chuck Peddle ou Jay Miner.

De ce que je vois, en six mois il a assemblé ensemble des pièces conçus par d'autres. L'architecture qu'il a créé est celle d'un 8 bit avec un processeur plus rapide. Il prévoyait un blitter, sans que son architecture soit capable d'en tirer pleinement avantage. Ouais, bof.

Mais, comme je l'avais dit aussi, à sa décharge il n'a eu que six mois. Il a surement fait au plus simple et rapide. Problème c'est que cette base la gamme ST l'a trainé jusqu'au bout, alors qu'elle était déjà clairement "très limité" dès le début (pour ne pas dire "obsolète" dans l'architecture).

Le DSP du 3000+ était là pour compenser Paula dans l'AGA. Tout cela a été annulé par la direction, comme déjà expliqué. Le AA+ devait avoir une puce son qui semble assez proche de Mary.

le DSP ne peut pas compenser une sortie sonore limité.  Si la srotie est en 28Khz, tu ne pourras jamais avoir de la qualité CD, même avec un DSP.

Ah bon, le DSP il peut pas sortir du son 16 bit qu'il mixera ou pas avec celui de Paula ? 

Tiens les caractéristiques audio du DSP 3210 dans le 3000+ (avec l'AGA donc).

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



The Hi-Fi Audio CODEC The second device on the A3000+ DSP serial bus is the Hi-Fi Audio CODEC. This device is a 16-bit bidirectional two-channel Σ∆ A/D-D/A converter. It maintains greater than 80 dB S/NR and THD, and supports a large variety of sample rates, including the audio-standard 44.1kHz and 48kHz rates. It supports programmable data formats, either signed two’s complement 16-bit linear, 8-bit µ-law, or 8-bit A-law encoding. Additionally, it has a programmable input source selection for microphone or line-level inputs. The DSP3210 Subsystem The Phone-Line CODEC works the same in either control or data modes of the serial bus, and the serial device address is zero. The DSP3210 is set up to use an external clock, with internally generated transmit load strobe, externally generated receive load strobe. The device itself contains nine addressable ixteen-bit registers, five for control purposes, four for data I/O, as show in Table 4-6. All transmissions consist of a 16-bit address word and a 16-bit data word. Writes to the device are initiated by the DSP3210. The address word contains the register address as bits zero through three, zeros for the reserved bits four through fourteen, and a zero as bit fifteen, indicating a write. To read a control register, the DSP3210 sends the address word, only with bit fifteen set high, followed by a dummy data word. This doesn’t immediatedly read that register, The Audio CODEC, with serial bus device address of one, has distinct control and data modes. Both modes use 64-bit data frames, transmitted LSB first. The control mode frame sets the sampling rate, data format, and various other initialization parameters, while the data mode frame is the normal I/O mechanism for D/A-A/D conversion. In control mode, the DSP3210 supplies both serial clocks, both load strobes, and the frame synchronization pulse. In Data mode, the Audio CODEC supplies both serial clocks and the frame synchronization pulse, while the DSP3210 supplies the load strobes. The control mode frame sets a number of parameters in the Audio CODEC. It selects the data format; either mono or stereo, 16-bit twos-complement PCM linear, 8-bit µ-law companded, or 8-bit A-law companded. It sets up the sampling configuration, which includes clock source and sampling frequency. It has optional loopback bits, which allow the system to be tested, with either ADC to DAC or DAC to ADC looping. And the revision code of the CODEC is available here too, to help device drivers adjust to future versions of the device. Data mode, as expected, contains the audio data, as defined in control mode. All frames allow programmable output attenuation on both left and right channels, from 0dB to 93dB, in 1.5dB steps, as well as full digital mute. Analog mute is also available on either output channel. Input gain can be set from 0db to 22.5dB, in increments of 1.5dB. Of course, the input source can be selected as either line or microphone. A programmable monitor mode allows the ADC output to be variably mixed with the DAC’s input, in steps of 0dB (fully mixed) to an attenuation of 84dB, in steps of 6dB, as well as completely unmixed. Finally, there’s an overrange indicator which indicates if either ADC channel is overdriven. One important note is the proper protocol must be observed for switching this device between control and data modes. To go from data to control mode, it is only necessary to lower the output volume to its maximum attenuation, then bring the D/C line low, via the bio port. Next, create the desired control frame and send it, with the DCB (Data Control Handshake) bit low. Read back the control frame and examine the DCB bit. Until it reads low, continue sending the control frame and reading it back. This allows multiple Audio CODECs to exist at the same serial bus device address. Once DCB reads back low, the control frame is written back once more, only with DCB set high. Now the CODEC is ready for the new setup. The D/C line is brough high, which will put the device into data mode and also execute an offset calibration on the selected input channel. More information on the Hi-Fi Audio CODEC, such as the detailed format of the various transmission frames, is available in Appendix 

On dirait bien qu'il parle de 44,1 khz et 48 khz, non ?

Mais tu en sait surement plus que lui sur les DSP et en particulier sur le DSP3210 qu'il a interfacé dans le 3000+ ?

C'est comme le blitter du ST soit disant en parallèle, tu en sais plus que les codeurs de démo.

Mais, ça ne t'empêche pas de dire que c'était le plus puissant dans le domaine graphique.

j'ai pas le dit * LE * plus puissant, mais faisant partie des plus puissants.

Je te cite donc, avec ma réponse :

c'était les stations graphiques les plus performantes à l'époque.  comme quoi atari était sur tous les marchés

Mais bien sur, Atari devant Silicon Graphics, ce qu'il faut pas lire d'un Fanboy. 


Mémoire à géométrie variable aussi chez toi, non ?

Un résultat assez proche pour toi c'est pareil qu'un résultat fidèle à ce qui était techniquement possible à l'époque ? Toi même tu viens, une fois de plus, de dire que ce n'était pas possible. Y a rien à ajouter

qui a prétendu ici que c'est fidèle à 100% ?  personne... c'était très proche de la réalité, suffisamment pour se dire qu'ils voulait bel et bien montrer un PC et non un Amiga. (comme ils ont fait avec le Mac ou le Next )

Mais, non je t'ai déjà expliqué ils ne savent même pas, si ça se trouve que le ST ou l'Amiga avaient une GUI. Et s'il le savent, de toute façon les producteurs ne recherchaient pas à être historique.

Et tu te demande pas pourquoi ils l'ont fait pour le MAC et le Next (et Windows95) ? Parce que c'est l'histoire officielle, en dehors de ça il y a rien eu de bien. La majorité des scénaristes à Hollywood travaillent sur MAC (MacOS X) tu penses qu'ils savent que le ST et l'Amiga faisaient mieux que le MAC de l'époque... Ils s'en foutent, c'est pas ce qu'ils voulaient raconter, c'est tout. Par contre, comme le NeXT est la base de MacOS X, ils vont pas dire autre chose que "oh génial".

Mais bien sur, piratage CDROM à l'époque de la playstation 1... tu sais combien coutait un graveur de CDROM à l'époque, au moins le prix d'une playstation. Mais ça c'est le graveur, derrière il faut le PC qui va avec, le logiciel et pouvoir graver au format playstation. Sans parler du support réinscriptible qui coutait très cher. 

tu as tout faux : les graveurs existaient déjà depuis longtemps à la sortie de la playstation.  Je dis pas que tout le monde en possédait un, mais les pirates habituels étaient équipé depuis longtemps de Philips 2X et rapidement des Yamaha 4X lorsque que PS1 est sortie.  Les premières copies sont apparues immédiatement, puisque la protection était ultra bête : il suffisait de bloquer le bouton de détection capot avec un cure dent, démarrer un original pendant 3-4 sec, et ensuite l'échanger avec un jeu copié et ça bootait.  Donc tout un business a démarré avec cela, tu trouvais des copies partout à 50 FF.  Puis cela s'est industrialisé avec l'arrivé des premier modchip qui bootait directement les copies.  Non seulement il y avait sur le marché les copies gravées, mais aussi les copies pressées en usine venant tout droit de Chine.  Le marché était inondé de copie.  Il y avait à Hong Kong des immeubles comportant des centaines de boutiques, toutes vendant des copies pressées.  Donc oui, c'est le piratage de masse qui a probablement fait exploser les ventes de Playstation.  La aussi, les gens n'ont acheté la PS1 que parce qu'ils pouvaient avoir les jeux pas cher, voir gratuit.  Bien évidement c'était une super console.

Tu racontes n'importe quoi, le commun il avait pas de graveur de CDROM ! En 1994 l'Amigaïste avec les configurations haut de gamme a voulu se prendre un graveur de CDROM, pour faire des compilations. Ca coûtait une fortune, il a renoncé, jusqu'à ce que les prix deviennent abordables deux ans après, de mémoire.

Je m'en souviens des modchip, je suivais ça de loin, mais c'était bien plus tard. Au début la playstation 1 s'est vendu sur ses capacités qui écrasait toutes les autres consoles. C'est ce qui a fait son succès initial et donc conduit à l'apparition des modchip. 

C'est bien plus tard que ça a commencé. Mais au début le CDROM était LE support qui était le plus "sur". 

j'ai possédé un graveur Philips dès que les premiers PC étaient équipé de CD ROM.  Il n'y avait aucune protection, faire des copies de CD ROM était un jeu d'enfant.  Par contre, en effet, j'avais dû me déplacer en UK pour l'acheter car ce n'était pas encore vendu en Belgique.  Mais cela ne change rien pour le piratage , tout comme pour amiga tu avais des sources pour tes jeux, là tu avais des sources pour avoir des CD ROMS copiés.

Mais, tu n'es pas représentatif de la majorité, cet équipement coûtait fort cher. 

Pourquoi il n'y avait pas de protection au début, justement ? Parce que ce support était considéré comme sur.

Vers la fin de la carrière de la playstation, là on commençait à voir apparaître le phénomène, mais pas au début. Et dès le début la Playstation a écrasé les autres, justement parce que c'était vraiment un saut de génération technologique.

La 3DO est sortie plus tôt, avec des jeux très impressionnants également et un gros saut technologique par rapport aux 16 bits.  A-t-elle connu le même succès que la PS1 ? non...pourtant son concept de console sous license était vraiment plus prometteur que la PS1.

La 3DO n'avait pas Sony derrière et a eu un marketing lamentable et assez peu de jeu si je me souviens bien.

Le succès d'une console c'est un tout. Il faut, la bonne technologie, le bon prix, le jeu qui épate tout de suite et le bon marketing puis d'autres jeux tout aussi impressionnant. Sony a réussi tout ça.

Ils sont assez rare quand même.

rien que ce sur ce forum, ils sont tout aussi nombreux que les amigaistes, es-tu à ce point aveugle ?

Les réguliers oui, mais ceux qui témoignent de temps en temps tu les oublie.

Tu penses mais tu n'a pas essayé. L'émulation software PC sur un 68000, c'était une curiosité rien de plus. 

oui je viens de voir les vidéos, c'est assez lent en effet.  mais bon, il y avait les cartes hardware 

Oui, mais là c'est autre chose. Dans ces conditions, comme je l'avais dit, c'était utilisable. L'Amiga avait ça de façon simple par des cartes passerelles pour le 2000/1000, et plus tard par des cartes sur le port d'extension mémoire pour l'Amiga 500.

Le ST, il fallait bricoler, une fois de plus.

T'a vraiment pas de chance avec l'Amiga, on sait.

tout comme toi avec Win 95 et les modems 

Mais pas du tout, ce n'était pas moi qui manipulait le PC, mais un PCiste confirmé en école d'informatique (DUT ou plus). Je n'avais pas de PC à ce moment là.

[Invité]

le DSP ne peut pas compenser une sortie sonore limité.  Si la srotie est en 28Khz, tu ne pourras jamais avoir de la qualité CD, même avec un DSP.

C'est faux 
Paula est limitée à 28khz ,parce que le DMA n'alimente le(s) DAC au mieux qu'a cette fréquence .
En mode manuel, tu peux monter à bcp plus, regarde le 1200, il peut faire du 56khz .
Plus tu montes en fréquences, plus tu as besoin d'accès à la ram(donc de cylces DMA) .
Tu comprends donc pk les 50khz du falcon/STE c'est du gros n'importe quoi,et pk les consoles 32 bits ont une mémoire dédiée aux samples/sons .

Et tu comprends aussi qu'une puce PCM 8 bits c'est pas si mal, car le DMA envoie 16 bits/accès donc tu as 2 samples pour 1 accès,ça /2 le nombre d'accès pour les 4 voix  .

[stapha92]

Vous parlez de fast ram mais ça n'existe pas sur le falcon. Il s'agit de RAM reliée directement au proc. Pour utiliser cette RAM il faut un  programme adapté : l'OS ne sait pas l'attribuer.

pas du tout, certe sens strict, le TOS d'origine ne détecte pas la " TTRAM ", mais ce n'est qu'un faux problème un TOS modifié était livré avec la carte dans sa mémoire flash, ou simplement par un patch à mettre dans le repertoire AUTO selon le type de carte.  Donc pour l'utilisateur, c'est complétement transparent.  Idem avec Mint, dont les distributions adaptées existent.  Donc tous les softs compatible TT RAM fonctionnent sur Falcon en fastram.

Non seulement le TOS ne détecte pas la TTRAM mais, surtout, il ne la gère pas. La seule gestion, héritée du TT, consiste à mettre l'executable en Fast au moment de son chargement si le header du fichier exécutable a été correctement trafiqué. 
Par contre, une fois que ce dernier s'execute, à chaque fois qu'il demandera de la RAM à l'OS, celui-ci lui en attribuera en ST-RAM, c'est le seul moyen d'assurer une compatibilité ascendante. 
Sur le mig, à chaque demande de RAM, le programme demande à l'OS le type de RAM dont il a besoin. Ainsi un logiciel mig ne s'amusera jamais à stocker des variables, un buffer, une pile d'exécution, etc... en chip RAM alors qu'il dispose d'une RAM ultra rapide sur une carte 68060. Le Falcon si...
Sur le mig, le concept de fast est pensé DES LE DEPART et totalement intégré à l'OS. Sur le TT, il a fallu bricoler...

Et après on nous dit que c'est le mig qui est un bricolage...

Votre carte CT60 est exploitée comment par tous les logiciels PRO du falcon ou du ST ? Vous avez essayé ? Vous devriez : ça vous fera retomber sur terre...

Calamus tourne nickel avec sa version patchée. 

D'accord donc pour profiter d'un falcon avec carte accélératrice, il faut trouver un logiciel compatible Falcon, ça restreint déjà le choix... Et il faut qu'il soit patché (qui a dit bricolage ?) !
Et le patch, c'est juste ce qui permet à l'exécutable d'être chargé en fast, ça ne règle pas les problème d'allocation que j'évoque plus haut. Donc il sera loin d'exploiter une CT60...
Dis moi : un Cubase ça tourne correctement sur Facon ? Parce qu'un Bar & Pipes n'a aucun problème. et lui saura exploiter les cartes accélératrices installées...

Parlons en de cette carte : vous osez comparer une carte (enfin un hack...) sortie BIEN APRES la mort du Falcon (et inexploitée par 95% des logiciels compatibles avec cette machine) et équipée de SDRAM et d'un 68060 à 100Mhz avec des cartes CONTEMPORAINES (donc 60 Mhz et pas du tout la même RAM) au mig ?

encore une erreur de ta part : les cartes accélératrice embarquant TT RAM + Proc sont sortie à peine 1 ou 2 deux après la sortie du Falcon.
elles sont donc parfaitement contemporaine.  CT63/60 est l'ultime carte, mais il en existait bien d'autres.

Je parle de la CT60 car c'est elle qui est mise en avant systématiquement quand on parle de Falcon accéléré. Si on se restreint aux cartes contemporaines, le Falcon est à poil à coté du 1200 (qui avait des carte PowerPC CONTEMPORAINES à plus de 266 Mhz par exemple).

Et encore c'est pas fair play : il s'agit encore d'une carte contemporaine et pas la plus rapide. Et il s'agit d'un vrai jeu sorti il y a longtemps...

5 ans après la sortie du A1200, bref, il est sorti quand la machine était déjà morte et est tout à fait faisable sur un Falcon, tu devrais le savoir

Non : le jeu tourne sur une configuration qu'on pouvait se procurer en allant à la FNAC. Pas en achetant un Falcon, en attendant 10 ans qu'une carte assez rapide sorte et qu'on ait appris à l'installer (parce qu'il ne s'agit pas d'une carte qui s'enfiche dans un port dédié, il faut le rappeler...).

On pourrait prendre une carte vampire qui vaut la moitié du quart de votre CT60 aussi...

toi aussi tu vas utiliser l'argument tu prix .?  "c'est moins bien mais c'est moins cher donc c'est mieux"

Non tu m'as mal compris : une carte Vampire vaut une fraction du prix d'une CT60 TOUT EN ETANT PLUS PERFORMANTE !!!
Exemple : lecture d'une vidéo mpeg en haute résolution (640 pixels/ligne) en 24 bits qui n'utilise que 50% du processeur. Le falcon ne suit pas, meme avec une CT60 et un superVidel.
Au fait, cette lecture vidéo : c'est sur un simple A600 + vampire...
Donc tu comprendras qu'il vaut mieux oublier toutes les extensions et se restreindre aux machines d'origine. D'ailleurs en terme d'extension, un Facon ou un ST sont du même niveau qu'un A600 qui est le parent pauvre de la gamme de ce coté...

Le GPU du falcon est tellement bien que les démos TBL n'utilisent pas son mode chunky : une C2P avec le 68060 est plus performante... Trop ridicule ! Et la palette 24 bits ? Oubliée par atari ? Super les dégradés fins sur Falcon...

faudrait savoir, plus haut tu parles que la CT60 n'est pas une carte contemporaine et tu viens critiquer que Videl, qui lui est contemporain n'est pas assez puissant pour supporter cette accélération.  Si tu prend une CT60, tu prends la Super-Videl qui va avec.  Ce qui est vraiment ridicule par contre, est un Amiga de 1992, sorti à l'ère du CD qui est incapable de gérer la qualité CD.  ça oui c'est ridicule

Ah ok, pour avoir une palette de 24 bits il faudra attendre plus de 10 ans que le super Videl soit disponible...
Sur Amiga, tu pouvait avoir des cartes audio CONTEMPORAINES (encore une fois...) à ce compte là.

Note que pour l'Audio, et à condition de prendre un Falcon MK2, le Falcon est une super machine. Je n'ai aucun mal à le reconnaitre puisque, en tant qu'amigaiste, je ne suis pas obligé de me voiler la face :
Son DSP, même si c'est un principe auquel je ne croyais pas (pour Babsimov : espace mémoire, moins performant que les CPUs, surtout quand ceux-ci auront des jeux d'instructions étendus type MMX ou Altivec. D'ailleurs, aujourd'hui il n'y a plus de micro avec un DSP...) est une bonne idée. Et la limite de bande passante imposée par son bus 16 bits ne pose pas de problème pour traiter de l'audio.

Par contre au niveau affichage, une palette de 18 bits en 92, c'est insuffisant...

Vous critiquez le 680EC20 et son absence de MMU : Vous l'utilisez la MMU sur le facon ? Et par rapport au 68020, vous savez ce que provoque le EC ? Ben ça limite l'adressage à 16 Mo : Y a un interet a mettre plus de 16 Mo dans un A1200 non accéléré ? Parce que  vu le prix de la mémoire valait mieux mettre l'argent dans une carte (une vrai ! pas un hack qui oblige à perdre sa garantie...) accélératrice limité à 8 Mo...
D'ailleurs, votre Falcon dispose d'un  68030 complet mais qui est limité à 14 Mo par la machine... Encore une fois ridicule...

au moins sur Falcon, on avait le choix d'utiliser la MMU ou non, c'est n'était pas imposé comme sur le A1200.  et comme tu le dis toi même, quel intérêt à mettre plus de 14 Mo dans un Falcon non accéléré ?  Il valait mieux investir une vraie carte.  Garantie ?  sais-tu qu'à l'époque c'était 1 an de garantie.  Les cartes à base de 68040 ne sont sortie que bien après l'expiration de la garantie, aussi bien sur Amiga que sur Atari.  

Le choix oui mais vous l'utilisiez ? ben non... Y a une protection mémoire dans le TOS (protection qui necessite une MMU) ? ben non...
Oui je suis d'accord : aucun interet de mettre 14 Mo dans un Facon non accéléré (surtout qu'il n'y aurait pas de fast dans ces 14 mo...). C'était pour répondre à ceux qui critiquaient le fait que le 68020 du A1200 est un EC et ne gère donc que 16 Mo. Merci donc d'aller dans mon sens...
Non : il y avait des cartes 68040 pour le mig bien avant la fin de sa commercialisation , donc bien avant la fin de sa garantie (qui était de 2 ans sauf pour le lecteur de disquettes dans mon cas...)

Pour terminer sur le 1200. Un bon jeu commercialisé il y a 15 ans :

oui qui tourne sur un A1200 68040/25 + carte graphique bvision.  pas très intéressant sur le plan technique, mais intéressant comme jeu.

Non ça tourne très bien avec l'AGA. Cherche d'autres vidéo sur le tube. Tu sais bien sur qu'avec un 68040 la conversion C2P n'a aucun surcout ?...
C'était surtout pour dire que le 1200 a eu droit a des tas de jeux commerciaux qui exploitent les cartes accélératrice, voire PowerPC.

@stapha92 a écrit:
Vous expliquez tranquillement que le Facon avec son DSP c'est 512 sprites de 16x16 en truecolor et ça devient le dieu de la 2D. Ok calculons : 

un sprite en  16x16 = 256 pixels. en true colors (2 octets par pixels) ça fait 512 octets. Donc ça 512 octets x 512 sprites = 256 Ko à lire + 256 Ko à écrire par frame. Au total 512 Ko. Avec 50 i/s ça fait 25 Mo/s. Regardez les chiffres postés par Rocky007 : c'est  4 à 5 fois plus que ce qu'il est possible d'obtenir avec la ST-RAM ! Faut garder les pieds sur terre...

...et pourtant c'est une réalité. Il est vraiment jouable sur mon Falcon030 (et en 31KHz de surcroit). J'ai même réussi à le terminer une (seule) fois.

Et que puis-je te dire ? Faire comme Galilée et dire "Et pourtant elle est ronde" ?
Il ne peut y avoir autant de sprites à 50 i/s, c'est juste IMPOSSIBLE.

Bon, je pense qu'on devrait oublier le Falcon et le 1200. De toute façon les ataristes n'ont pas acheté de Falcon, comme tout le monde. Inutile donc d'en parler...

Mais si ça intéresse quelqu'un, voici une analyse du super bus du Falcon effectuée par quelqu'un qui maitrise la machine :

https://mikro.naprvyraz.sk/docs/mikro/030_stram.html

C'est clair : super bien pensée...

C'est pas ce qu'on a lu ici, le blitter du ST bloquait le processeur quand il était utilisé. Atari conseillait même de ne l'utiliser que pour de tous petits traitements et surtout pas tout à la suite, sinon le processeur ne peut plus travailler. Quelle conception géniale... Mais, en fait, c'est normal, le ST n'a pas été pensé pour avoir des coprocesseurs. Ils ont mis le blitter parce que ça faisait bien sur le papier et parce que tout le monde en voulait parce que l'Amiga en avait un.

faux, tu as deux mode : travailler seul ou en cooperatif avec le CPU.  il n'y a pas de question, il accéléré l'affichage.  de nombreux jeux ou demo l'utilise pour les sprites etc..correctement programmé, il peut fonctionner en // avec le CPU, tout dépend du code 68000 ( toutes les instructions qui n'accèdent pas au bus ).  à t'entendre il ne fait que ralentir l'ordinateur quand on l'utilise.

C'est bien ce que j'ai lu ici, même Atari conseillait de ne pas trop l'utiliser pour que le processeur ait un peu de temps. Je pense même me souvenir que c'était dans une interview ou une citation de Shiraz Shijvi en personne qui disait que le blitter bloque le CPU.

apparemment même quand on t'explique, tu ne comprends pas.  je t'explique que le blitter Atari a une mode coopératif avec le CPU.  tout dépend comment tu l'emploies.

évidement dans un fullscreen qui doit être synchro au cycle près, c'est une autre histoire.... 
le CPU peut exécuter une instruction n'utilisant pas le bus en même temps que le blitter, ok c'est assez limité je l'admet, mais pendant ce moment il fonctionne en // avec le CPU !

Apparemment c'est toi qui ne comprends pas : le 68000 NE PEUT PAS fonctionner en même temps que le blitter. J'ai déjà expliqué ça ici. Tu n'es pas au courant que TOUTES les instructions d'un 68000 utilisent le bus ? ben oui, avant d'executer une instruction, le 68000 doit la lire, non ? et comment peut-il le faire sans utiliser le bus ?

Va lire la doc Atari et tu verras ce qu'ils préconisaient : faire des blits ligne à ligne afin de permettre au 68000 de répondre aux interruptions avec un décalage pas trop grand ! Juste ridicule !!!
Parce que oui : quand le blitter tourne le 68000 ne peut même pas repondre aux interruptions. Fais une interruption pour faire un raster (hyper classique dans les jeux ST) et ajoute après une copie de bloc avec le blitter et admire le résultat sur ta machine de rêve...

Du coup tu sais pourquoi ton ST ne chauffait pas assez : le 68000 était souvent à l'arret...

oui, il aura fallu 12 années pour arriver à programmer correctement un amiga...c'est long.

Et 25 ans pour arriver à faire un pacmania fluide sur STE. J'ai dit fluide parce quand ici je lis que ça vaut la version Amiga... deux fois moins de couleurs, une fenêtre au lieu de l'overscan...

c'est bien ce que je disais, vous ne savez que poster les sempiternelle 10 même vidéos , car en fait sur amiga, à part ces 10 jeux pas trop mal réalisé, c'est le vide totale, soit des jeux minables, soit des portages Atari ( heureusement pour vous qu'atari a été là pour vous donner des jeux ...quand on voit le résultat de vos créations "amiga" ...)

10 ? Hmmm... Heureusement qu'il y a longtemps que j'ai compris que tu n'avais pas eu d'Amiga à l'époque sinon j'aurai des doutes sur tes capacités cognitives...

Sur STE, le blitter est en compétition avec le CPU, mais sur Amiga aussi, la contrainte étant qu'il n'y a qu'un bus à partager pour les accès CPU, blitter, DMA et video, avec la priorité à la video.
Malgré cette contrainte, dont Atari ne se vantait pas trop, le Blitter permettait d'accélérer l'affichage parce qu'il pouvait faire plus que le CPU: copie avec masque. Avec un CPU plus performant comme sur le Falcon, le blitter perdait son avantage et devenait inutile.
Techniquement, sur ST comme sur Amiga, on peut lire ou écrire un "mot" (donnée de 16bit) tous les 2 cycles. Pendant l'affichage, la moitié des cycles va à la video, sinon l'image est corrompue.
L'avantage de l'Amiga est que le blitter prend les cycles non CPU en dehors de l'affichage, tandis que le blitter du STE fonctionne de la même façon, affichage ou pas.
Corrigez-moi si je me trompe, car je connais mal "l'architecture" (bricolage) de l'Amiga.

Relis mes anciens posts et tu verras quelle machine est un bricolage...

Alors oui tu te trompes : Sur le mig, le 68000 peut travailler pendant un blit, même sans fast ram. Avec de la fast (concept inexistant sur le ST...), il n'est absolument pas ralenti. Ensuite le blitter du STE, contrairement à celui du mig NE SAIT PAS FAIRE DE COPIE AVEC MASQUE !!! Pour ça il faut savoir gérer 3 sources. Or le blitter du STE n'en gère que 2. Résultat, il est obligé de le faire en 2 fois. Super comme conception...
Techniquement le 68000 peut lire ou écrire un mot tous les 2 cycles sur le mig mais tous les 4 cycles sur le ST : tu te trompes encore...
C'est pour ça que dans cette super machine toutes les instructions voient leur nombre de cycle arrondi au multiple de 4 suivant... Et c'est pour ça que quand Atari a conçu le mega STE il se sont confrontés à un problème : le 68000 tournant 2 fois plus vite, c'est comme si on divisait par 2 le nombre de cycles de chaque instructions. mais il faut l'arrondir à 4 après ! (en fait c'est pire : c'est le temps entre 2 accès au bus qui doit être arrondi, et beaucoup d'instructions font plusieurs accès...) Du coup y a presque aucun gain ! Et Atari a été obligé de mettre une mémoire cache pour compenser et obtenir une accélération moyenne de 50 % ! Ouaouhhh !!! Met un 68000 à 14 Mhz dans un mig et il ira 2 fois plus vite. Point barre.

Quand à dire que le 68030 va plus vite que le blitter, vous êtes 2 à l'avoir affirmé mais, vous appuyez cette déclaration sur quoi ? Faites une copie de bloc avec masquage et décalage de quelques bits (en gros  : simuler un sprite) avec un 68030 et un blitter et comparez : vous réaliserez que vous êtes à coté de la plaque.

Toutefois, le blitter du STE peut fonctionner pendant l'affichage, pas celui de l'Amiga.   
Au total, le blitter de l'Amiga a un peu plus de cycles, on est bien d'accord. Mais le blitter d'Atari n'est pas si nul que ça. Ce n'est pas du bricolage. 

Ah bon ? Le blitter du mig ne fonctionne pas pendant l'affichage ? Première nouvelle.
Non, il n'est pas si nul, mais il lui manque des tas de choses présentes dans celui du mig pourtant conçu bien avant...
Et son intégration dans le ST relève, elle, du bricolage. Relis mes anciens posts, tu comprendras pourquoi j'ai malgré tout du respect pour le ST et absolument pas pour le STE

En me documentant, j'ai lu que si on utilise l'instruction TAS sur un Amiga, on a droit au Guru Meditation car l'architecture bricolée perd les pédales. 

Tu t'es mal documenté. Tu sais à quoi sert cette instruction et quelle est sa spécificité ? Renseignes toi déjà là dessus et tu comprendras qu'il ne faut pas croire tout ce qu'on lit...

Le blitter ne bloque totalement le CPU qu'en mode Hog. En mode Blit, les cycles sont partagés moitié moitié chaque scanline, donc le CPU ne va rien louper, sauf si on programme au cycle près, mais même ça c'est possible parce que les cycles sont plus faciles à déterminer qu'avec l'Amiga.

Ah bon ? totalement faux. Le blitter bloque le cpu dès qu'il fonctionne sur ST.
Ah bon ? Les cycles plus faciles à déterminer sur ST ? Encore une fois c'est faux : sur le mig tu peux te baser sur la doc motorola alors que sur le ST, tu dois arrondir les accès à la RAM au multiple de 4 supérieur (pratique quand on sait que pleins d'instructions font plusieurs accès à la RAM). En fait sur Amiga on ne programme pas au cycle près parce que :
 - on n'en n'a pas vraiment besoin, on a le copper pour faire ce genre de chose.
 - ça enlève toute compatibilité avec des machines plus rapides.
 - c'est une technique utilisée sur les 8 bits. Donc obsolète à l'époque du ST et du mig

Vous êtes les rois pour asséner des betises avec un aplomb tel que ceux qui ne maitrisent pas ces machines ne peuvent qu'y croire. Le pire est que vous avez fini par y croire...

je t'ai déjà expliqué pas tout à fait vrai :

It might often not be possible to organize CPU code around BLiTTER
operations, but if you do, you might gain a lot of speed by placing
the right instructions directly in front of a BLiTTER operation.
As the BLiTTER might require a couple of cycles before actually doing
anything, the CPU usually has a chance of loading the next instruction
before the BLiTTER hogs the bus. If this instruction requires no
additional bus access, it will be carried out _in parallel_ to the
BLiTTER operation, making the Atari ST/STE a dual-processor system
for this short period.

C'est juste ridicule : le 68000 peut  charger une instruction après avoir lancé le blitter parce celui-ci met quelques cycles à se lancer... Et si cette instruction ne fait pas d'accès mémoire elle pourra s'executer...
Génial, le 68000 peut, parfois, effectuer 1 instruction pendant que le blitter tourne.
Continuer à vous voiler la face, ça nous fait rire ;-)

le DSP ne peut pas compenser une sortie sonore limité.  Si la srotie est en 28Khz, tu ne pourras jamais avoir de la qualité CD, même avec un DSP.

C'est faux  
Paula est limitée à 28khz ,parce que le DMA n'alimente le(s) DAC au mieux qu'a cette fréquence .
En mode manuel, tu peux monter à bcp plus, regarde le 1200, il peut faire du 56khz .
Plus tu montes en fréquences, plus tu as besoin d'accès à la ram(donc de cylces DMA) .
Tu comprends donc pk les 50khz du falcon/STE c'est du gros n'importe quoi,et pk les consoles 32 bits ont une mémoire dédiée aux samples/sons .

Et tu comprends aussi qu'une puce PCM 8 bits c'est pas si mal, car le DMA envoie 16 bits/accès donc tu as 2 samples pour 1 accès .

C'est encore pire que ça touko. Déjà avec l'aide du copper (qui peut compléter le travail du DMA), tous les amiga peuvent monter à plus que 50 Khz (paula peut dépasser 3 Mhz...). Ensuite, sans trick (et sans copper) les amiga ECS (donc les contemporains au STE) et AGA peuvent faire du 56 Khz.
Et tous les Amiga peuvent faire du 14 bits. Simplement il n'y aura plus que 2 voies au lieu de 4...

[Invité]

C'est cool que tu apportes plus de précisions .

[rocky007]

oui, et où sont alors les soundtracker en 56 Khz ?  ou une simple demo ?  je n'en ai jamais vu.

[Invité]

oui, et où sont alors les soundtracker en 56 Khz ?  ou une simple demo ?  je n'en ai jamais vu.

Pour les mêmes raisons que tu n'en vois pas à 50 sur STE/falcon,la place que ça prend,et sur STE/AMIGA surement trop de CPU.

C'est pas parce que c'est possible de sortir du 50/56khz, que tu peux avoir un module dans cette qualité .

the CPU usually has a chance of loading the next instruction
before the BLiTTER hogs the bus.

 
Ca veut dire que le reste du temps le CPu se prend un  de la part du blitter,effectivement c'est beau une machine bien pensée ..

[Meditating Guru]

Et 25 ans pour arriver à faire un pacmania fluide sur STE. J'ai dit fluide parce quand ici je lis que ça vaut la version Amiga... deux fois moins de couleurs, une fenêtre au lieu de l'overscan...

Pacmania STE utilise l'overscan vertical pour présenter les dimensions appropriées. Je ne passe pas mon temps à compter les couleurs mais je n'ai pu qu'entendre que la musique "stereo" sur l'Amiga était juste bonne à casser les oreilles. Quelle casserole.  

Sur STE, le blitter est en compétition avec le CPU, mais sur Amiga aussi, la contrainte étant qu'il n'y a qu'un bus à partager pour les accès CPU, blitter, DMA et video, avec la priorité à la video.
Malgré cette contrainte, dont Atari ne se vantait pas trop, le Blitter permettait d'accélérer l'affichage parce qu'il pouvait faire plus que le CPU: copie avec masque. Avec un CPU plus performant comme sur le Falcon, le blitter perdait son avantage et devenait inutile.
Techniquement, sur ST comme sur Amiga, on peut lire ou écrire un "mot" (donnée de 16bit) tous les 2 cycles. Pendant l'affichage, la moitié des cycles va à la video, sinon l'image est corrompue.
L'avantage de l'Amiga est que le blitter prend les cycles non CPU en dehors de l'affichage, tandis que le blitter du STE fonctionne de la même façon, affichage ou pas.
Corrigez-moi si je me trompe, car je connais mal "l'architecture" (bricolage) de l'Amiga.

Relis mes anciens posts et tu verras quelle machine est un bricolage...

Alors oui tu te trompes : Sur le mig, le 68000 peut travailler pendant un blit, même sans fast ram. Avec de la fast (concept inexistant sur le ST...), il n'est absolument pas ralenti. Ensuite le blitter du STE, contrairement à celui du mig NE SAIT PAS FAIRE DE COPIE AVEC MASQUE !!! Pour ça il faut savoir gérer 3 sources. Or le blitter du STE n'en gère que 2. Résultat, il est obligé de le faire en 2 fois. Super comme conception...

La Fast ne concerne pas l'Amiga 500.
Oui, le blitter ST c'est source + destination, mais c'est plus que ce que le CPU peut faire avec un MOVE, c'était le sens de la remarque. Du coup, tu as peut-être raison sur le 68030 vs blitter.

EDIT: un masque peut-être entré dans les registres du blitter, sous forme de 3 x 16bits (premier mot, autres mots, dernier mot).

Techniquement le 68000 peut lire ou écrire un mot tous les 2 cycles sur le mig mais tous les 4 cycles sur le ST : tu te trompes encore...
C'est pour ça que dans cette super machine toutes les instructions voient leur nombre de cycle arrondi au multiple de 4 suivant... Et c'est pour ça que quand Atari a conçu le mega STE il se sont confrontés à un problème : le 68000 tournant 2 fois plus vite, c'est comme si on divisait par 2 le nombre de cycles de chaque instructions. mais il faut l'arrondir à 4 après ! (en fait c'est pire : c'est le temps entre 2 accès au bus qui doit être arrondi, et beaucoup d'instructions font plusieurs accès...) Du coup y a presque aucun gain ! Et Atari a été obligé de mettre une mémoire cache pour compenser et obtenir une accélération moyenne de 50 % ! Ouaouhhh !!! Met un 68000 à 14 Mhz dans un mig et il ira 2 fois plus vite. Point barre.

Misères de la mémoire partagée...
Je parlais du bus, qui permet un R/W tous les deux cycles. Le 68000 a besoin de minimum 4 cycles pour un R/W. Le CPU et le MMU sont entrelacés. On sait que sur ST, le CPU n'a pas accès pendant les cycles MMU. En pratique, les cycles perdus par le CPU ne sont pas trop nombreux car les instructions ont tendance à s'arrondir à 4 cycles.

Ca arrive sur Amiga aussi.
"Some 68000 instructions do not match perfectly with the allocation of even
cycles and cause cycles to be missed. If cycles are missed, the 68000 must
wait until its next available memory slot before continuing. However, most
instructions do not cause cycles to be missed, so the 68000 runs at full
speed most of the time if there is no blitter DMA interference."

Toutefois, le blitter du STE peut fonctionner pendant l'affichage, pas celui de l'Amiga.   
Au total, le blitter de l'Amiga a un peu plus de cycles, on est bien d'accord. Mais le blitter d'Atari n'est pas si nul que ça. Ce n'est pas du bricolage. 

Ah bon ? Le blitter du mig ne fonctionne pas pendant l'affichage ? Première nouvelle.

Sans Fast, c'est affichage ou CPU ou blitter, pas les trois en même temps, même sur ta super console.

Non, il n'est pas si nul, mais il lui manque des tas de choses présentes dans celui du mig pourtant conçu bien avant...
Et son intégration dans le ST relève, elle, du bricolage. Relis mes anciens posts, tu comprendras pourquoi j'ai malgré tout du respect pour le ST et absolument pas pour le STE

Le blitter n'est pas propre au STE, sa conception date du STF, il était une des "attractions" du Mega. On peut critiquer mais le GEM affichait nettement plus vite avec le blitter.
N'étant pas un fanboy, je ne prétends pas qu'il est mieux que celui de l'Amiga. Mais ce n'est pas un bricolage, c'est une architecture à compromis.

En me documentant, j'ai lu que si on utilise l'instruction TAS sur un Amiga, on a droit au Guru Meditation car l'architecture bricolée perd les pédales. 

Tu t'es mal documenté. Tu sais à quoi sert cette instruction et quelle est sa spécificité ? Renseignes toi déjà là dessus et tu comprendras qu'il ne faut pas croire tout ce qu'on lit...

Tu parles au gens comme s'ils étaient des ignorants et que seul l'Amigaleux détenait la Vérité...  
Voici ma source:

  Avoid the TAS instruction.
  --------------------------
  The 68000 test-and-set instruction (TAS) should never be used in the
  Amiga; the indivisible read-modify-write cycle that is used only in
  this instruction will not fit into a DMA memory access slot.

Le blitter ne bloque totalement le CPU qu'en mode Hog. En mode Blit, les cycles sont partagés moitié moitié chaque scanline, donc le CPU ne va rien louper, sauf si on programme au cycle près, mais même ça c'est possible parce que les cycles sont plus faciles à déterminer qu'avec l'Amiga.

Ah bon ? totalement faux. Le blitter bloque le cpu dès qu'il fonctionne sur ST.

En mode Hog, le blitter bloque jusqu'à la fin de blit. En mode Blit, il rend la main au CPU toutes les scanlines.

Ah bon ? Les cycles plus faciles à déterminer sur ST ? Encore une fois c'est faux : sur le mig tu peux te baser sur la doc motorola alors que sur le ST, tu dois arrondir les accès à la RAM au multiple de 4 supérieur (pratique quand on sait que pleins d'instructions font plusieurs accès à la RAM). En fait sur Amiga on ne programme pas au cycle près parce que :
 - on n'en n'a pas vraiment besoin, on a le copper pour faire ce genre de chose.
 - ça enlève toute compatibilité avec des machines plus rapides.
 - c'est une technique utilisée sur les 8 bits. Donc obsolète à l'époque du ST et du mig

Ou parce ce qu'ils sont difficiles à déterminer avec ce blitter qui prend des cycles de façon anarchique, bricolée...
Sur ST, on programme au cycle près pour se synchroniser avec l'affichage et tricher sur les bordures (toutes ces demos overscan...).

Vous êtes les rois pour asséner des betises avec un aplomb tel que ceux qui ne maitrisent pas ces machines ne peuvent qu'y croire. Le pire est que vous avez fini par y croire...

Comme on vient de le voir, ce ne sont pas des bêtises.

Déjà avec l'aide du copper (qui peut compléter le travail du DMA), tous les amiga peuvent monter à plus que 50 Khz (paula peut dépasser 3 Mhz...). Ensuite, sans trick (et sans copper) les amiga ECS (donc les contemporains au STE) et AGA peuvent faire du 56 Khz.
Et tous les Amiga peuvent faire du 14 bits. Simplement il n'y aura plus que 2 voies au lieu de 4...

Mais oui... pourtant ça sonne plutôt casserole et 8bit en général.

[Invité]

La Fast ne concerne pas l'Amiga 500.

gné ???
C'est nouveau ça  !! 
Encore un qui va faire le malin avec la slow RAM 

Oui, le blitter ST c'est source + destination, mais c'est plus que ce que le CPU peut faire avec un MOVE, 

On est d'accord, mais tu peux pas dire que c'est comme sur amiga .

Sans Fast, c'est affichage ou CPU ou blitter, pas les trois en même temps, même sur ta super console.

Mais n'importe quoi, tu as un budget DMA et le codeur en fait ce qu'il en veut, avec priorité au copper et paula, mais tu peux utiliser les 4 sans soucis, juste que le blitter sera pas au max de ses perfs c'est tout,comme le CPU.
Le blitter et le CPU fonctionnent en //, c'est a dire que le blitter utilise les cycles non utilisés par le 68k puisque le 68k touche au bus tout les 4 cycles,donc le blitter va se servir des 3 cycles de latence du 68k au lieu qu'ils soient perdus.
Et si les 2 entrent en conflit, c'est le 68k qui devra attendre,c'est tout .

Le blitter n'est pas propre au STE, sa conception date du STF, il était une des "attractions" du Mega. On peut critiquer mais le GEM affichait nettement plus vite avec le blitter.

Le blitter est un concept qui définit certaines règles pour qu'une puce puisse être qualifiée comme ça.
Le terme blitter a été inventé pour l'amiga,mais pas le concept.

N'étant pas un fanboy, je ne prétends pas qu'il est mieux que celui de l'Amiga. Mais ce n'est pas un bricolage, c'est une architecture à compromis.

D'accord, un rajout plein de compromis n'est pas du bricolage, par contre une archi pensée autour de la coordination de plusieurs chips maximisant les perfs/cycle c'est du bricolage, tu n'est pas un fanboy, mais pas loin ou pire (au choix  ) .

The 68000 test-and-set instruction (TAS) should never be used in the
  Amiga; 

Je remarque que cette instruction ne doit presque être utilisé dans rien dés qu'il y a autre chose que le CPU sur la mobo(pour info sur la Md c'est pareil), encore une joyeuseté du 68K.

En mode Blit, il rend la main au CPU toutes les scanlines. 

Et comment il fait si il doit faire un blit de 512 octets (ou plus) par exemple ??
il les fait qd ses blits ?? parce qu'un écran pendant l'affichage n'est composé que de scanline, et comme le blitter du ST/STE ne fonctionne pas pendant le hblank, faut expliquer là .

Mais oui... pourtant ça sonne plutôt casserole et 8bit en général. 

Mais bien sur, j'ai rien vu arriver ne serrait ce qu'au mollet de paula, sur STE et son magnifique son DMA 50khz ..

[Zarnal]

Bon alors, le blitter fasté il peut m'ajouter mes sprites manquants dans flink en fait ? Sinon concrêtement, que fait on de plus avec un blitter fasté ?

En 2d bien sûr. merci.

[Invité]

Bon alors, le blitter fasté il peut m'ajouter mes sprites manquants dans flink en fait ? Sinon concrêtement, que fait on de plus avec un blitter fasté ?

Rien, seul le CPU peut accéder à la fast .

[Zarnal]

Bon alors, le blitter fasté il peut m'ajouter mes sprites manquants dans flink en fait ? Sinon concrêtement, que fait on de plus avec un blitter fasté ?

Rien, seul le CPU peut accéder à la fast .

Reformulation correcte :

Bon alors, le blitter avec ses cycles de récupérés  grace à la fast il peut m'ajouter mes sprites manquants dans flink en fait ? Sinon concrêtement, que fait on de plus avec un blitter qui récupère l'ensemble de ses cycles et n'a plus à partager avec le CPU? Merci.

[Invité]

tu as plus de temps pour utiliser le blitter, donc après c'est le coder qui choisis quoi faire.

[Meditating Guru]

La Fast ne concerne pas l'Amiga 500.

gné ???
C'est nouveau ça  !! 
Encore un qui va faire le malin avec la slow RAM 

C'est ainsi que je l'ai compris. Les extensions de 512K typiques seraient de la "Chip".

Et si les 2 entrent en conflit, c'est le 68k qui devra attendre,c'est tout .

Tiens donc. Le blitter bloque le CPU sur Amiga aussi.  

The 68000 test-and-set instruction (TAS) should never be used in the
  Amiga; 

Je remarque que cette instruction ne doit presque être utilisé dans rien dés qu'il y a autre chose que le CPU sur la mobo(pour info sur la Md c'est pareil), encore une joyeuseté du 68K.

Sur les bricolages oui. Sur ST, l'instruction s'appelle Test and Set (TAS) et fonctionne comme prévu.
Sur Amiga, elle s'appelle Test and Set Guru (TASG) . Le Guru Meditation indique que l'Amiga est conforme à son "architecture".

En mode Blit, il rend la main au CPU toutes les scanlines. 

Et comment il fait si il doit faire un blit de 512 octets (ou plus) par exemple ??
il les fait qd ses blits ?? parce qu'un écran pendant l'affichage n'est composé que de scanline, et comme le blitter du ST/STE ne fonctionne pas pendant le hblank, faut expliquer là .

Le blitter a le bus pendant 256 cycles, puis c'est le CPU, puis le blitter... jusqu'à la fin du blit (et le CPU reprend immédiatement la main à la fin).

Le concept est simple sur STE, pour chaque bloc de 4 cycles:
2 cycles CPU ou Blitter  / 2 cycles MMU (video, refresh, DMA...)
Contrairement à l'Amiga, le blitter du STE ne prendra jamais les cycles que j'appelle MMU. Ca évite les plantages (suivez mon regard...   ).

Mais bien sur, j'ai rien vu arriver ne serrait ce qu'au mollet de paula, sur STE et son magnifique son DMA 50khz ..

Tu sais, à 8bit, 50khz ou pas...

[rocky007]

Pour les mêmes raisons que tu n'en vois pas à 50 sur STE/falcon,la place que ça prend,et sur STE/AMIGA surement trop de CPU.

C'est pas parce que c'est possible de sortir du 50/56khz, que tu peux avoir un module dans cette qualité .

je comprends pas : vous dites que c'est possible et ensuite, en fait non, c'est pas possible...

faudrait savoir hein

Pour info :

Falcon :
Graoumf Tracker v0.8890  
by L.De Soras, Swe / YesCREW, SJX / Vectronix and Lp / YesCREW
 
32 Channels Hi-Fi quality (16bit/50kHz/Stereo) playback

Atari STe :


Zip file also includes the Protracker player tool (up to 50 kHz output) for Atari STe, Falcon and Atari TT by Equinox & Sharpman/The Black Cats

[Invité]

C'est ainsi que je l'ai compris. Les extensions de 512K typiques seraient de la "Chip".

Et ???
Alors tout d'abord la chip est une mémoire à 280ns @7,14 mhz,soit 1 accès tout les 2 cycles .
Le CPU est à 1 accès tout les 4 cycles soit 560ns(@7,14mhz) .
De plus tu te doutes bien que le copper/paula/blitter accédent à la chip plus vite que le 68K, donc même en ayant de la chip comme mémoire elle est largement plus rapide que ce que peut accéder le 68k .
ensuite le terme de slow ram, ne vient pas du fait que les puces utilisées pour la mémoire soit de la chip, mais du bus utilisé .
La slow RAM utilise la zone mémoire juste au dessus de la chip, donc le même bus que la chip, contrairement à la fast qui utilise en bus dédié,d'où les différences d'appellations .
Donc ceux qui sortent que la chip est appelée slow ram, faudrait qu'ils fassent preuve d'un minimum de réflexion avant d'affirmer ça,parce que sans connaitre l'amiga, l'évidence saute aux yeux, sauf pour celui qui veut pas la voir . .

Je comprends pas : vous dites que c'est possible et ensuite, en fait non, c'est pas possible..

C'est pas possible d'avoir ça dans un jeu,jouer un sample à 56khz c'est facilement faisable avec de la place,mais surement pas un mod .

J'aimerai bien voir un mod 4 voix en 50khz sur STE,sur falcon le CPu ne poserrait pas de soucis je pense ,entre le 68030 et le DSP,y'a de quoi faire,mais niveau place faudrait quelques MO(disque et RAM) a mon avis . .

32 Channels Hi-Fi quality (16bit/50kHz/Stereo) playback

Faudrait qu'il m'explique comment il fait pour garder une précision de 16 bit en mixant 4 samples 16 bits ensemble ..
Parce que chez moi 16+16+16+16 ça fait pas un nombre sur 16 bits .

[Meditating Guru]

C'est ainsi que je l'ai compris. Les extensions de 512K typiques seraient de la "Chip".

Et ???
Alors tout d'abord la chip est une mémoire à 280ns @7,14 mhz,soit 1 accès tout les 2 cycles .
Le CPU est à 1 accès tout les 4 cycles soit 560ns(@7,14mhz) .
De plus tu te doutes bien que le copper/paula/blitter accédent à la chip plus vite que le 68K, donc même en ayant de la chip comme mémoire elle est largement plus rapide que ce que peut accéder le 68k .
ensuite le terme de slow ram, ne vient pas du fait que les puces utilisées pour la mémoire soit de la chip, mais du bus utilisé .
La slow RAM utilise la zone mémoire juste au dessus de la chip, donc le même bus que la chip, contrairement à la fast qui utilise en bus dédié,d'où les différences d'appellations .
Donc ceux qui sortent que la chip est appelée slow ram, faudrait qu'ils fassent preuve d'un minimum de réflexion avant d'affirmer ça,parce que sans connaitre l'amiga, l'évidence saute aux yeux, sauf pour celui qui veut pas la voir . .

Sur mon Amiga, il y a une extension interne de 512K avec un switch on/off sur le côté. Ceci est-il de la mémoire "fast" dans le sens que le chipset n'y a pas accès, ou chip?

Si le programme est logé en Fast ram, le CPU ne sera ralenti par rien pour lire le programme ("fetching").
Mais le programme doit accéder à la mémoire chipset, pour par exemple préparer l'image... changer les sons, etc.
Donc en pratique, il y aura partage de cycles, et d'une façon difficile à prévoir, voire chaotique.
Ca me fait penser à un infâme bricolage.